Por que descartamos 70% da base corporativa sem escrever uma linha de código: a anatomia de engenharia do RAG empresarial

• Participação dos problemas de dados: 70–80% de todas as falhas do RAG corporativo (30% versões antigas, 20% duplicatas, 15% OCR corrompido)
• Caso real de limpeza da base: a redução de 12 000 para 3 800 documentos gerou um crescimento multiplicado na precisão da busca
• Ganho do Tool-based RAG: até +70% na qualidade da resposta na migração da pré-busca "cega" para o function calling
• Parâmetros de chunking de regulamentos: Parent-Child (child de busca com 200–300 tokens, parent contextual com 1500–2000)

Ao desenvolver assistentes de IA e bases de conhecimento de projetos na AlpinaGPT (hoje a plataforma reúne mais de 8 000 usuários ativos e mais de 40 clientes corporativos), estudei dezenas de implementações de RAG de terceiros. Quase sempre o cenário se repete: os engenheiros montam um protótipo bonito em uma semana, defendem o orçamento e, um mês após o lançamento em produção, o sistema começa a citar com confiança ordens canceladas há três anos e a inventar cláusulas contratuais inexistentes.

Os clientes tentam resolver isso trocando o LLM ou adotando a moderna busca em grafo. Mas minha experiência prática mostra uma proporção rígida: 80% das tarefas corporativas são resolvidas muito bem com o RAG avançado clássico com metadados, sem a complexidade excessiva do GraphRAG, e 70–80% de todas as falhas estão na engenharia de dados, não nos pesos da rede neural.

Por que o RAG corporativo gera alucinações e encontra regulamentos

desatualizados?

Entre a pasta com documentos corporativos e a resposta correta do modelo existem quatro gargalos sistêmicos:

1. Corpus de entrada poluído (Data Engineering): quando o cliente nos entrega 10 000 arquivos corporativos, 30% deles acabam sendo edições desatualizadas sem data, 20% são quase duplicatas completas, e 15% são PDFs escaneados malfeitos com lixo pós-OCR e cabeçalhos/rodapés. Em uma implementação, dos 12 000 documentos entregues com a marca "atual", após a auditoria restaram exatamente 3 800.

Simplesmente excluímos três quartos do cemitério de arquivos (apresentações de 2020 e rascunhos), e a qualidade das respostas aumentou várias vezes sem um único commit no código. A regra de verificação principal da primeira semana: observar a proporção de arquivos com data de modificação superior a um ano. 2.

Falhas da busca vetorial em russo: o modelo padrão `text-embedding-3-large` da OpenAI costuma falhar na terminologia setorial russa. Segundo nossas medições, em regulamentos em cirílico, `multilingual-e5-large` e `jina-embeddings-v3` funcionam visivelmente melhor. Além disso, a busca vetorial pura se perde em consultas do tipo "item 4.

2.1 da ordem nº 47" — nesse caso, é obrigatório um circuito híbrido `vetor + busca lexical BM25` com reranqueamento posterior. 3.

Degradação silenciosa sem monitoramento: a base é atualizada, e em dois meses a precisão cai. Além do trio básico de métricas do RAGAS (`Faithfulness`, `Answer Relevancy`, `Context Recall`), a versão v0.2 trouxe uma métrica criticamente importante para empresas, a `Noise Sensitivity` — a resistência da resposta a um contexto poluído.

E o indicador precoce mais barato de que o RAG está quebrando em produção é o gráfico semanal do comprimento médio da resposta em tokens: assim que o modelo deixa de encontrar o fato exato, ele começa a "enrolar" e inflar os parágrafos de 2 a 3 semanas antes das primeiras reclamações dos usuários. 4. Limite estrutural: o RAG trabalha com instantâneos estáticos e não substitui um banco de dados transacional (CRUD) para estoque ou preços em tempo real.

Como funciona o fatiamento correto de chunks para regulamentos, código e FAQ?

Enfiar um PDF de 80 páginas em um único vetor ou fatiar documentos sem preservar metadados (fonte, data, seção, autor) é uma forma garantida de destruir a busca. Não existe um tamanho único de chunk; ajustamos a estratégia à física de cada documento:

• Contratos jurídicos e regulamentos internos: estratégia `Parent-Child`. A busca ocorre por um fragmento filho estreito de 200–300 tokens (máxima precisão no acerto), e no prompt do modelo é inserido um bloco pai amplo de 1500–2000 tokens, para não perder condições e ressalvas.
• Documentação de engenharia e descrições de API: janela fixa `Fixed-size` de 500 tokens com sobreposição (`overlap`) de 100 tokens, para não cortar uma ideia pela metade.
• Código-fonte de repositórios: fatiamento estritamente semântico pelos limites de funções e classes.
• Manuais curtos e bases de FAQ: método `Sentence window` — buscamos por uma única frase e entregamos ao modelo uma janela de `±N` frases vizinhas.

O que fazer na prática: por que o

Tool-based RAG supera a busca nativa em 70%?

Nas implementações primitivas, a busca é fixada antes de cada chamada ao modelo (Native RAG): o usuário escreve no chat "Olá, como vai?", e o sistema obedientemente traz da base vetorial cinco trechos aleatórios do estatuto da empresa, queimando tokens e confundindo o modelo.

Nós migramos a arquitetura para Tool-based RAG: o mecanismo de busca é conectado ao modelo como uma ferramenta externa via `function calling`. O agente decide por conta própria se precisa consultar a base de conhecimento, reformula a pergunta do usuário em uma consulta de busca precisa e, se necessário, faz 2–3 chamadas direcionadas a diferentes coleções. Em nossos projetos, essa única mudança já gera um ganho de até 70% na qualidade das respostas, e dois dias dedicados a escrever um parser limpo de DOCX/PDF para Markdown estruturado economizam meses de luta contra alucinações.

Detalhamos toda a engenharia de design de RAG com pgvector e ferramentas de agentes nos cursos técnicos da [Hamidun Academy](https://academy.hamidun.com) e nas análises de arquitetura do [Vibe Club](https://hamidun.

com/club).