RAG com 11 000 arquivos confundia códigos de produto e entregava dados da máquina errada

Um bot de vendas que responde com base em documentação técnica erra com um custo maior do que o chat de suporte de uma loja virtual. O gerente recebe um número, repassa ao cliente, e o cliente compra a máquina errada. É exatamente esse o caso analisado no Habr: 11 000 arquivos de documentação técnica, mais de 100 gerentes de vendas e um bot RAG que citava com segurança números do manual de um modelo vizinho.

O que se sabe sobre o caso

A publicação no feed do Habr está disponível por enquanto apenas como anúncio, então nos baseamos somente no que foi declarado nele. O restante do texto é a lógica geral de engenharia desse tipo de sistema, e não um resumo de medições do autor.

• Corpus: cerca de 11 000 arquivos de documentação técnica.
• Público: mais de 100 gerentes de vendas.
• Sintoma: o bot responde com segurança, mas pega os parâmetros do manual de outra máquina.
• Classe do problema: consultas por código de produto e designação exata do modelo.
• Resultado declarado: o autor descreve o que acabou funcionando, com a análise das causas.

Por que o vetor confunde códigos de produto

Embeddings densos comprimem um trecho de texto em um vetor que reflete o significado. Para a pergunta "qual é a potência do spindle de um centro de usinagem", isso funciona bem. Para uma consulta por código, como "XYZ-4200-B", o cenário é outro. O tokenizador quebra essa string em subpalavras, e o modelo de embeddings não tem obrigação de tratar a diferença entre "4200-B" e "4200-D" como relevante. No espaço vetorial, essas designações ficam vizinhas.

Os manuais de produtos da mesma série agravam o problema. Eles seguem o mesmo modelo: as mesmas seções, as mesmas formulações, as mesmas tabelas. Só os números mudam. Do ponto de vista do embedding, é quase o mesmo documento, e a busca devolve tranquilamente no top-5 chunks de vários modelos ao mesmo tempo.

Daí em diante entra a mecânica comum dos LLMs. Ao receber no contexto um trecho plausível, o modelo o cita. Ele não sabe que o manual é o errado: a consulta tem o código, o contexto não, e ninguém verifica essa divergência. O erro surge na etapa de retrieval, e não na geração, de modo que ajustar o prompt de sistema aqui é quase inútil.

O que verificar no seu RAG

O conjunto de técnicas para esse tipo de tarefa é conhecido, e cada uma vale ser testada com consultas reais dos gerentes.

Primeira: busca híbrida. Um índice lexical, como o BM25, fica ao lado do vetorial, e os resultados são combinados por Reciprocal Rank Fusion ou por ponderação. A correspondência exata da string do código ganha um peso que o vetor não oferece.

Segunda: extração de identificadores da consulta. Se a pergunta contém um código, ele pode ser reconhecido por expressão regular ou por um catálogo de modelos e usado como filtro rígido nos metadados do documento. Assim, o manual de outra máquina simplesmente não entra nos resultados.

Terceira: contexto dentro do chunk. Se, ao fatiar os documentos, cada trecho receber o nome do modelo, a série e o nome do arquivo, a tabela de números deixa de ser anônima.

Quarta: reranker. Um cross-encoder aplicado sobre os top-N candidatos compara consulta e trecho melhor do que a comparação de dois vetores independentes.

Quinta, a mais barata: verificação antes da resposta. Se o código da consulta não aparece nas fontes que foram para o contexto, o bot deve dizer "não encontrei" em vez de chutar.

Para os testes, monte um conjunto de perguntas reais com códigos de produto, incluindo pares de modelos parecidos, e meça a proporção de casos em que o documento correto entrou no top-k. Essa métrica mostra o problema antes que o cliente o perceba.