Como funciona uma atividade sobre chat na prática
A maioria dos materiais que você encontra por aí fala de teoria de IA, mas eu preciso ser honesto: construir algo que realmente funciona é bem diferente. Quando comecei a montar minha primeira atividade sobre chat, pensei que era só configurar um LLM e pronto. Levei três semanas para perceber que o problema não era o modelo, e sim como você orquestra o fluxo. Vou explicar do jeito que fiz, porque a ordem certa importa mais do que você imagina.
Definindo a atividade sobre chat antes de abrir qualquer ferramenta
O erro número um é começar a programar sem ter definido o escopo. Eu vi muita gente configurar RAG, ajustar temperatura e otimizar prompts sem saber exatamente qual pergunta o sistema precisava responder. Resultado: um chat bonito que não resolve nada útil. Antes de escrever uma linha de código, escreva em uma frase qual é o objetivo. Por exemplo: "O chat precisa responder perguntas técnicas sobre o manual do produto X com fontes verificáveis." Quanto mais específico, melhor. Se a frase ficar longa, revise o escopo. Se ficar vaga, você vai perder tempo.
Arquitetura básica que eu recomendo
Depois de anos testando setups diferentes, cheguei a uma arquitetura que funciona na maioria dos casos. Não é a mais elegante, mas é previsível. Camada 1: Receptor de entrada
O usuário digita. A entrada passa por uma limpeza básica — remover caracteres extras, normalizar acentos, limitar tamanho máximo (recomendo 500 caracteres para a maioria dos casos). Isso evita que prompts maliciosos ou acidentais quebrem o fluxo. Camada 2: Classificador de intenção
Antes de mandar tudo para o LLM, use um classificador simples. Pode ser um modelo leve como BERT-tiny, ou até mesmo regras baseadas em palavras-chave se o domínio for muito restrito. A intenção define qual rota o sistema vai tomar. Sem isso, cada pergunta vai direto para o modelo, o que é lento e caro. Camada 3: Busca de contexto
Aqui entra o RAG se você precisar de conhecimento externo. Divida os documentos em chunks de 256 a 512 tokens, use embedding modelo como text-embedding-3-small ou equivalentes gratuitos, e armazene em um vector store. Eu uso ChromaDB para protótipos e Pinecone para produção. A diferença de custo é significativa depois de 10 mil queries. Camada 4: Gerador de resposta
O LLM recebe a pergunta, o contexto recuperado e as instruções do sistema. Recomendo temperatura entre 0.1 e 0.3 para respostas factuais. Temperatura alta aqui gera alucinação, e ninguém quer um chat que inventa informações. Camada 5: Pós-processamento
Isso é o que a maioria esquece. Antes de mostrar a resposta ao usuário, passe por um filtro que remove repetições, valida se as informações têm fontes no contexto recuperado, e corta excessos. Uma resposta de 300 palavras quando 100 bastam é resposta ruim.
👉 Clique no botão abaixo para saber mais sobre o assunto!
O problema que ninguém conta
Eu perdi dois dias inteiros com um caso que parecia impossível. Tinha um documento técnico com tabelas complexas e o RAG recuperava os trechos corretos, mas o LLM simplesmente ignorava os dados tabulares e respondia com informações genéricas. O problema era que o chunking padrão cortava as tabelas ao meio, e o embedding perdia a estrutura. A solução foi criar um chunker personalizado que detecta tabelas (busque por padrões de linhas com múltiplos delimitadores) e mantém a tabela inteira dentro de um único chunk. Além disso, converter a tabela para texto formatado com colunas alinhadas antes de embeddar fez a diferença. A precisão subiu de 40% para 89% nos testes.
Métricas que importam de verdade
Não meça apenas a latência ou o custo. Meça:
- Groundedness: a resposta usa apenas informações do contexto fornecido? Teste com um verificador que compara afirmações da resposta contra o contexto fonte.
- Relevância: a resposta responde à pergunta feita, não a uma pergunta similar?
- Completude: todas as partes da pergunta foram abordadas?
Use o RAGAS ou equivalentes para automação. Rodar esses testes manualmente é inviável depois de 50 queries.
Custos e limites
Vamos ser claros: atividade sobre chat com RAG + LLM é caro se escalar. Cada query gasta tokens de embedding + tokens de contexto recuperado + tokens de geração. Com um fluxo típico de 2048 tokens de contexto e 512 tokens de resposta, uma única query pode custar entre R$ 0,02 e R$ 0,08 dependendo do modelo. Para 10 mil usuários ativos diários, isso é entre R$ 200 e R$ 800 por dia. Não é insustentável, mas exige otimização. As duas coisas que mais reduzem custo sem quebrar qualidade são: redução agressiva do contexto recuperado (traga apenas os 3 chunks mais relevantes, não 10) e uso de modelos pequenos para classificação de intenção, reservando o modelo grande apenas para a geração final.
Se o orçamento for extremamente apertado, considere uma abordagem híbrida: use um modelo pequeno (Llama 3.2 3B ou equivalentes) para perguntas simples e um modelo grande apenas para queries complexas detectadas pelo classificador. Eu reduzi custos em 60% com essa estratégia.
O que não funciona
Ficarei feliz em listar o que tentei e não funcionou, porque isso economiza tempo para você: Não adianta aumentar o tamanho do chunk. Chunks maiores que 1024 tokens degradam a qualidade da recuperação porque o embedding perde foco. Não adianta usar temperature alta esperando criatividade em tarefas factuais. O modelo só vai alucinar mais. Não adianta confiar no primeiro ranking de similaridade — use re-ranking com modelos como BGE-Reranker, que melhora a precisão em 15 a 25 pontos percentuais.
Implementação mínima viável
Se você quer começar hoje, aqui está o caminho mais rápido: Use LangChain ou LlamaIndex como framework. Ambos têm abstrações que economizam horas de desenvolvimento. Armazene embeddings em ChromaDB localmente para protótipo. Para deploy, considere FastAPI como interface e coloca o serviço em um container com recursos limitados (2 vCPU, 4GB RAM) para o classificador e um serviço separado com GPU para o LLM. Separação de cargas evita que o classificador consuma memória GPU que o LLM precisa.
O setup básico leva cerca de 4 a 6 horas para funcionar em nível de demonstração. Para produção, considere entre 2 e 4 semanas dependendo da complexidade do domínio e da quantidade de documentos para processar.
Aviso importante
Atividade sobre chat nunca será perfeita. Modelos alucinam. Embeddings falham com domínio muito específico. Usuários fazem perguntas que você não previu. O segredo não é eliminar esses problemas, mas criar mecanismos de fallback: quando o sistema tem baixa confiança na resposta, ele deve dizer "não tenho certeza" em vez de inventar algo. Configure um threshold de confiança (geralmente 0.7 para groundedness) e redirecione para um humano ou para FAQs pré-definidas quando abaixo disso. Isso é mais valioso do que qualquer otimização de prompt. Um chat que admite ignorância constrói confiança. Um chat que inventa respostas convincentes destrói credibilidade em uma única interação.
