Por que a documentação importa
Sistemas de Retrieval-Augmented Generation permitem que modelos de linguagem respondam perguntas com base no conhecimento real da empresa, em vez de depender apenas do que foi aprendido durante o treinamento. A promessa é poderosa, um assistente que sabe da política de reembolso, do histórico de um cliente ou do processo interno de aprovação.
Na prática, porém, o desempenho de um RAG está diretamente ligado à qualidade da documentação que o alimenta. O princípio é simples: o sistema só consegue recuperar o que está lá, e só consegue usar bem o que está bem escrito. Documentos desatualizados, redundantes ou mal estruturados produzem respostas imprecisas, mesmo com a melhor arquitetura de recuperação.
Este artigo cobre o que acontece antes da implementação técnica para um RAG de sucesso, como preparar a documentação da empresa para que a knowledge base funcione de verdade.
Escolhendo os documentos certos
O primeiro passo não é técnico, mas sim é entender o que a empresa tem e o que vale a pena incluir. Uma auditoria documental precisa responder três perguntas fundamentais:
Com o inventário em mãos, aplique um filtro de seleção. Nem todo documento precisa entrar na knowledge base. Priorize o que é consultado com frequência, o que é fonte de erros recorrentes quando não está acessível, e o que tem owner claro para manutenção contínua. Documentos sem responsável definido tendem a ficar desatualizados rapidamente.
Como montar os documentos
A característica mais importante de um documento para RAG é ser autocontido, ou seja, qualquer trecho retirado de contexto ainda precisa fazer sentido. Isso difere bastante de como a maioria das empresas documenta processos, que geralmente pressupõe que o leitor conhece o contexto.
Algumas regras práticas que fazem diferença na qualidade de recuperação:
O que funciona na prática
O formato do documento afeta diretamente a qualidade do texto extraído durante a ingestão. Os formatos têm características bem distintas:
| Formato | Qualidade de extração | Observação |
|---|---|---|
| Markdown / texto plano | Excelente | Formato ideal. Estrutura semântica preservada na ingestão. |
| PDF com texto nativo | Boa | Funciona bem. Atenção a cabeçalhos, rodapés e numeração de página que contaminam o texto. |
| PDF escaneado | Variável | Depende de OCR. Qualidade cai em documentos antigos ou de baixa resolução. |
| Planilha (Excel/CSV) | Baixa | Dados tabulares não são recuperados bem por busca semântica. Converter em texto narrativo quando possível. |
| Apresentação (PowerPoint) | Baixa | Conteúdo fragmentado por slide. Exportar como texto e reescrever em formato narrativo. |
Documentos com tabelas e imagens merecem atenção especial. Tabelas de dados são extraídas com qualidade variável dependendo da ferramenta de ingestão. A abordagem mais confiável é adicionar um parágrafo descritivo ao lado da tabela explicando o que ela representa e quais são as conclusões principais. Imagens, gráficos e diagramas são invisíveis para sistemas de busca semântica baseados em texto, ou seja, se a informação está apenas na imagem, ela não será recuperada.
Em relação ao versionamento, a prática mais importante é não manter múltiplas versões do mesmo documento na base. O sistema não sabe qual é a atual e pode recuperar ambas, gerando respostas conflitantes. Mantenha apenas a versão vigente e arquive as anteriores em um local separado, fora do escopo de ingestão.
Otimizando a recuperação
Com os documentos selecionados, estruturados e nos formatos certos, é hora de pensar em como eles serão processados pelo sistema de recuperação. Algumas decisões nessa etapa têm impacto direto na qualidade das respostas:
Chunking: durante a ingestão, cada documento é dividido em pedaços menores chamados chunks. Esses chunks são vetorizados e armazenados no índice. Na consulta, apenas os chunks mais similares à pergunta são recuperados e enviados ao modelo. O tamanho do chunk importa, onde muito pequeno perde o contexto necessário para a resposta, muito grande injeta informação irrelevante e eleva o custo de tokens. Para a maioria dos documentos corporativos, chunks de 300 a 600 tokens com uma sobreposição de 10 a 15% entre chunks adjacentes funcionam bem como ponto de partida.
Metadados como filtros: os campos de metadados definidos nos documentos (área, data, tipo, versão) podem ser usados como filtros na recuperação. Isso permite que o sistema priorize documentos da área de RH quando a pergunta é sobre férias, ou ignore documentos com mais de dois anos quando o contexto exige informação recente. Quanto mais ricos os metadados, mais preciso o filtro.
Hierarquia de confiança: nem todos os documentos têm o mesmo grau de autoridade. Uma política oficial aprovada pela diretoria deve ter peso maior do que anotações de uma reunião. Definir um campo de tipo de documento (política, procedimento, referência, nota) e usá-lo como critério de ranqueamento melhora a consistência das respostas.
Teste antes de ligar o modelo: antes de integrar o sistema de recuperação ao LLM, vale testar a recuperação isolada. Monte um conjunto de 20 a 30 perguntas representativas dos casos de uso esperados e verifique se os chunks recuperados contêm a informação necessária para respondê-las. Se a recuperação falha, o modelo não consegue compensar, independentemente da sua capacidade.
Para entender a arquitetura técnica de um sistema RAG na AWS, como o Amazon Bedrock Knowledge Bases, OpenSearch e o processo de vetorização, leia nosso artigo técnico:
Checklist de prontidão documental
A qualidade de um sistema RAG é determinada muito antes da primeira linha de código. A lista abaixo cobre o essencial para garantir que a documentação está pronta para alimentar uma knowledge base:
Seguir esse processo antes da implementação técnica reduz significativamente os ciclos de ajuste após o lançamento e aumenta a confiança dos usuários no sistema desde o primeiro dia de uso.