Tem um momento específico que sempre aparece nos projetos. O agente funciona bem nos testes, responde com confiança, parece inteligente. Aí entra uma pergunta sobre a política de devolução da empresa, ou sobre as condições do contrato fechado no ano passado, ou sobre o procedimento interno de um departamento específico.
E o agente inventa.
Não por maldade. Ele genuinamente não tem a informação, então faz o que LLMs fazem quando não sabem: preenche a lacuna com algo plausível. Isso tem nome técnico, alucinação. Na prática é o agente afirmando com total segurança uma coisa que nunca existiu.
É aqui que RAG entra.
O que é RAG, sem rodeios
RAG, Retrieval Augmented Generation, é o padrão que resolve esse problema. Em vez de esperar que o modelo memorize tudo durante o treinamento (algo impossível para documentos internos da sua empresa, que ele nunca viu), você dá ao agente a capacidade de buscar informação relevante antes de responder. O modelo não precisa saber a resposta de cor. Ele precisa saber onde encontrar.
A mecânica é menos complicada do que parece.
Você tem um conjunto de documentos: manuais, contratos, FAQs, e-mails antigos, o que for. Você processa esses documentos e os converte em representações numéricas chamadas embeddings. Pense em embeddings como coordenadas num espaço de muitas dimensões, onde textos com significado parecido ficam próximos um do outro. Quando o usuário faz uma pergunta, o sistema transforma a pergunta nesses mesmos embeddings, busca os trechos mais próximos e manda esses trechos junto com a pergunta para o modelo. O modelo responde com base no conteúdo que você forneceu, não no que ele aprendeu no treinamento.
Simples assim. Não tem magia.
Onde guardar os vetores
O que tem é escolha. E aqui começa a parte que a maioria dos tutoriais pula.
Banco vetorial dedicado como Pinecone, Weaviate ou Qdrant é o mais elegante. Mas muita gente não precisa disso. Se você já tem PostgreSQL com a extensão pgvector instalada, dá pra fazer RAG robusto sem nenhuma infraestrutura extra. Já usei pgvector em produção com base de conhecimento de 50 mil documentos. Funcionou bem. O custo de busca vetorial num banco relacional bem indexado é baixo para volumes de negócio normais.
A escolha de banco vetorial é menos crítica do que parece nas primeiras semanas. A chunking strategy é onde você vai sofrer de verdade.
Chunking: onde mora a maior parte do trabalho
Chunking é como você divide os documentos em pedaços antes de gerar os embeddings.
Dividir por tamanho fixo parece simples. Corta a cada 500 tokens, pronto. O problema: você quebra parágrafos no meio, separa pergunta da resposta numa FAQ, divide a cláusula do contexto do contrato. A busca acha o chunk certo, mas o chunk não tem informação suficiente pra responder.
Já errei isso. O agente buscava o trecho correto, mas o trecho estava cortado exatamente no ponto onde estava a regra de negócio relevante. A resposta ficava incompleta e o modelo tentava completar com inferência. Que é outra forma de alucinação.
O que funciona melhor na prática: chunks que respeitam a estrutura semântica do documento. Seções inteiras. Parágrafos completos. Para FAQs, pergunta e resposta sempre juntas no mesmo chunk, nunca separadas. Overlap entre chunks, repetir as últimas frases no início do próximo, ajuda quando a informação está na fronteira entre dois pedaços.
É trabalhoso. Não tem atalho bom aqui.
RAG ou contexto longo?
Essa pergunta aparece cedo em todo projeto.
Com contexto longo você manda toda a base de conhecimento no prompt. Funciona até um certo tamanho. O Claude hoje aceita 200k tokens de contexto. Para bases pequenas e específicas, essa pode ser a abordagem mais simples e mais confiável. Sem infraestrutura extra, sem pipeline de embedding, sem chunking pra calibrar.
A limitação é custo e latência. Mandar 200k tokens em cada requisição custa e demora. Para bases maiores, fica inviável. RAG resolve isso: você busca só o que é relevante e manda uma fração do conteúdo.
Na prática, começo muitos projetos com contexto longo e migro pra RAG quando o volume de conteúdo ou o custo por requisição justificam a complexidade adicional. Não tem sentido construir pipeline de embedding pra base de conhecimento de 30 documentos.
O teste que a maioria pula
Tem um erro que vejo com frequência em projetos de IA que chegam até mim com problema.
As pessoas constroem o pipeline de RAG, testam com perguntas genéricas, acham que está funcionando e colocam em produção. As perguntas genéricas funcionam porque a base de conhecimento cobre bem o assunto em linhas gerais. O problema aparece nas perguntas específicas, nos casos de borda, nos documentos inseridos com qualidade ruim, nas perguntas que exigem combinar informação de dois documentos diferentes.
Testar RAG direito exige perguntas que só têm resposta em documentos específicos da base. Exige perguntas que parecem ter resposta mas não têm, pra ver se o sistema admite que não sabe em vez de inventar. Exige perguntas que cruzam múltiplos documentos.
Isso é mais trabalho do que parece. E é o trabalho que separa o agente que funciona em demo do agente que funciona segunda-feira às 9h com usuário real na outra ponta.
O problema que ninguém menciona no primeiro mês
Você inseriu os documentos, o RAG funciona, o agente está em produção.
Aí a empresa atualiza a política de devolução. Ou fecha um contrato com condições novas. Ou o procedimento de um departamento muda. Se você não tem processo para atualizar a base de conhecimento, em pouco tempo o agente responde com base em informação desatualizada. Com confiança total. Isso é pior do que não ter agente nenhum.
Parece óbvio mas raramente está nos planos do projeto. Aprendi cedo que qualquer implementação de RAG precisa de dois sistemas: o pipeline de ingestão inicial e o pipeline de atualização contínua. Se você construir só o primeiro, vai ter problema em três meses.
Aliás, isso me lembra de um ponto sobre a qualidade dos documentos de origem. Se os manuais da empresa estão desatualizados, incompletos ou escritos de forma confusa, o RAG vai entregar isso de volta com fluência. Lixo que entra, lixo que sai, só que agora em português bonito e com tom de autoridade.
Antes de construir qualquer pipeline, vale revisar o que vai entrar nele.
Desenvolvo sistemas com agentes de IA e implementações de RAG para empresas que precisam que a IA responda sobre o contexto delas, não sobre o mundo em geral. Se quiser conversar sobre o que faz sentido pro seu caso, entra em contato pelo gabriels.dev.br.