Quase todo projeto de IA que chega na Conddiz começa igual: alguém montou um protótipo de RAG num fim de semana, ficou impressionado, e agora quer colocar "em produção". O protótipo responde lindamente nas 5 perguntas que a pessoa testou. O problema aparece na pergunta número 50 — feita por um cliente real, com dados que mudaram desde ontem.
O retrieval é 80% do problema
A maior parte da energia gasta com "prompt engineering" deveria ir para o retrieval. Se o trecho certo não chega ao contexto, nenhum prompt salva a resposta. Na prática, isso significa:
- Chunking que respeita a estrutura do documento. Quebrar a cada 500 tokens cega o modelo no meio de uma tabela ou de uma cláusula. Quebre por seção, não por contagem.
- Reranking depois do vector search. A busca vetorial traz candidatos plausíveis; um reranker decide quais realmente respondem à pergunta.
- Metadados como cidadãos de primeira classe. Filtrar por data, origem e permissão antes de buscar evita que o modelo cite um documento que o usuário nem deveria ver.
Dados que mudam quebram silenciosamente
Numa POC, o índice é estático. Em produção, os documentos mudam — e o índice precisa acompanhar. Sem um pipeline de reindexação, o sistema vai responder com confiança usando a versão antiga de uma política que mudou na semana passada. Esse é o tipo de erro que destrói a confiança do cliente, porque a resposta parece certa.
Uma resposta errada com tom seguro é pior do que um "não sei". Calibre o sistema para admitir incerteza.
Avaliação contínua, não um teste manual
A pergunta "está funcionando?" não se responde olhando cinco exemplos. Montamos um conjunto de avaliação com perguntas reais e respostas esperadas, e rodamos a cada mudança de prompt, modelo ou índice. Quando a precisão cai, sabemos antes do cliente reclamar.
O que levamos para cada projeto
- Retrieval primeiro, prompt depois.
- Reindexação automática atrelada à fonte de verdade.
- Um harness de avaliação que roda no CI.
- Um caminho explícito para "não sei".
RAG em produção não é mágica — é engenharia. E engenharia boa é justamente o que separa a demo bonita do sistema que o cliente usa todo dia.