O RAG (Retrieval-Augmented Generation) se tornou a arquitetura de referência para conectar um LLM a dados empresariais. O princípio é simples: em vez de fazer fine-tuning de um modelo, fornecemos o contexto relevante no momento da consulta. Na teoria, é elegante. Na prática, a maioria dos projetos RAG ficam travados na fase de PoC.
Aqui estão as 5 armadilhas que encontramos com mais frequência nos nossos clientes, e como evitá-las.
1. O chunking ingênuo
O recorte dos documentos em blocos de tamanho fixo (500 tokens, 1000 tokens) é a primeira abordagem que todos testam. Funciona em demos, mas desmorona em documentos empresariais complexos.
O problema: um contrato de 50 páginas recortado em blocos de 500 tokens perde toda coerência semântica. Uma cláusula que referencia um artigo anterior fica isolada do seu contexto.
A solução: adote um chunking semântico. Use a estrutura do documento (títulos, seções, parágrafos) como fronteiras naturais. Para documentos não estruturados, modelos de segmentação como os propostos por LangChain ou LlamaIndex oferecem resultados significativamente superiores.
2. Ignorar a qualidade dos embeddings
Muitos projetos usam um modelo de embedding genérico (como text-embedding-ada-002) sem se questionar sobre sua relevância para o domínio de negócio em questão.
Um embedding treinado em texto generalista não capturará as nuances de um vocabulário jurídico, médico ou financeiro. Duas soluções:
- Fazer fine-tuning do embedding em um corpus representativo dos seus documentos
- Usar um re-ranker após a busca vetorial para refinar a relevância
Nas nossas implantações, a adição de um re-ranker melhora a precisão do retrieval de 20 a 35% sem mexer no restante da cadeia.
3. Negligenciar a avaliação contínua
Um sistema RAG não é um modelo que se treina uma vez. É um pipeline vivo cuja qualidade depende da atualidade dos dados, da relevância do retrieval e da precisão das respostas geradas.
Métricas essenciais para monitorar:
- Retrieval precision: o contexto recuperado é relevante?
- Faithfulness: a resposta é fiel ao contexto fornecido?
- Answer relevancy: a resposta responde à pergunta feita?
Frameworks como RAGAS permitem automatizar essas avaliações e detectar desvios antes que impactem os usuários.
4. Subestimar a engenharia de prompts
O prompt de sistema que enquadra as respostas do LLM é frequentemente tratado como um detalhe. É um erro. Um prompt mal concebido gera alucinações, respostas fora do assunto ou formatos inconsistentes.
Boas práticas:
- Definir explicitamente o papel do modelo e o perímetro de suas respostas
- Instruir o modelo a citar suas fontes
- Prever uma resposta padrão quando o contexto for insuficiente ("Não disponho dessa informação")
- Versionar os prompts como código
5. Esquecer a governança dos dados
O RAG conecta um LLM aos seus dados internos. Isso levanta imediatamente questões de controle de acesso, de confidencialidade e de atualidade.
Se um colaborador júnior puder consultar o sistema e obter informações às quais normalmente não teria acesso, é um problema de segurança grave. A camada de retrieval deve respeitar as permissões existentes do seu sistema documental.
O que recomendamos
Na Bomzai, implantamos arquiteturas RAG em produção com uma abordagem iterativa:
- Fase 1: PoC rápido em um perímetro restrito (1 fonte, 1 caso de uso)
- Fase 2: industrialização com monitoramento, avaliação e CI/CD
- Fase 3: extensão progressiva a outras fontes e casos de uso
Essa abordagem permite entregar valor em até 30 dias, ao mesmo tempo em que se constroem fundações sólidas para a escalabilidade.
