Chatbot personalizado com LLM: as decisões de arquitetura que definem o resultado

Montar um chatbot com LLM que impressiona numa demonstração leva um fim de semana. Montar um que aguenta mil conversas por dia, responde com o dado certo e não constrange a empresa é outro trabalho — e ele é feito quase todo fora do modelo.

Decisão 1: de onde vem o conhecimento

Essa é a bifurcação que mais gera desperdício em projeto de empresa.

RAG — recuperar trechos do seu acervo e entregá-los ao modelo junto com a pergunta — é o padrão para conhecimento que muda. A resposta se apoia em documento seu, dá para citar a fonte, e atualizar é reindexar um arquivo.

Fine-tuning ajusta a forma da saída: tom, formato, padrão de classificação. Ele não é o caminho para "ensinar os meus documentos ao modelo" — o conhecimento entra diluído nos pesos, sem fonte citável, e qualquer atualização exige treinar de novo.

A regra prática: conhecimento que muda vai para RAG; comportamento que se repete pode ir para fine-tuning. Na maioria dos casos, prompt bem escrito e RAG resolvem antes de o fine-tuning virar necessário.

Decisão 2: o que o modelo pode chamar

Um chatbot que só recupera texto responde sobre política e procedimento. Para responder sobre o seu pedido, ele precisa de ferramentas: funções que consultam o ERP, o CRM, a agenda, o sistema de estoque.

Cada ferramenta precisa de três coisas antes de existir: contrato de entrada e saída, regra de quem pode acioná-la, e log do que foi feito. Ferramenta de escrita — que altera algo no mundo real — pede ainda idempotência, para que um reprocesso não duplique lançamento.

Decisão 3: como a resposta é ancorada

O modelo gera a continuação mais provável do texto. Diante de uma pergunta cuja resposta não está no contexto, ele completa com o que soa plausível — com a mesma confiança de uma resposta correta.

A defesa é de sistema, não de modelo:

• Nenhum trecho recuperado acima do limite de similaridade? A resposta é "não encontrei", não texto livre.
• Valor, prazo e disponibilidade sempre vêm de consulta, nunca de geração.
• Toda resposta de base carrega a citação do documento e do trecho.
• Assunto sensível sai por resposta fixa ou vai para humano.

Não existe modelo que não alucine. Existe sistema em que a alucinação tem pouco espaço para acontecer e é detectada quando acontece.

Decisão 4: como você sabe que está bom

Esta é a etapa que quase todo protótipo pula e que quase todo sistema em produção precisa ter.

Monte um conjunto de perguntas com gabarito escrito pelo time que conhece o assunto — cinquenta já mudam a conversa, duzentas dão segurança. Ele roda a cada mudança de prompt, de modelo ou de índice, medindo acerto da resposta e acerto da citação.

Sem isso, toda alteração é aposta: melhora um caso, piora três, e ninguém percebe até o cliente reclamar.

Decisão 5: qual modelo, e por quanto tempo

A escolha do modelo deve ser configuração, não arquitetura. Coloque o modelo atrás de uma camada de abstração e a decisão vira reversível — importante porque preço, limite e qualidade mudam várias vezes por ano.

Vale também usar modelos diferentes por etapa: um modelo pequeno e barato classifica a intenção e extrai dado estruturado; o modelo maior entra só onde a redação importa. Em volume, essa separação corta uma fatia grande do custo sem mudar o que o usuário percebe.

Decisão 6: o que acontece depois do deploy

Sistema com LLM tem uma característica incômoda: pode piorar sem que nada no seu código mude. O fornecedor atualiza o modelo, o perfil das perguntas muda, o acervo cresce.

O mínimo de operação que um chatbot em produção precisa:

• Prompt versionado em repositório, com histórico e revisão — não colado numa tela de configuração.
• Log de entrada, saída e versão em toda chamada, para auditar decisão automatizada.
• Métrica de custo e latência por rota, com alerta.
• Conjunto de avaliação rodando antes de qualquer mudança ir para produção.
• Caminho de rollback que alguém já testou.

O erro estrutural mais comum

Começar pela ferramenta. A pergunta "qual plataforma de chatbot usar" chega antes de "qual pergunta da minha fila eu quero eliminar", e o projeto passa a ser moldado pelo que a plataforma faz — não pelo que a operação precisa.

Invertido, funciona melhor: escolha um assunto de alto volume, mapeie onde está a resposta, construa o caminho completo até o sistema de origem e só então decida o que comprar e o que construir. O escopo fica menor, entra em produção mais rápido, e o que vier depois já nasce em cima de algo que funciona.