Erros confiantes provocados por alto recall de RAG

Quando muitas equipes colocam o RAG no mercado pela primeira vez, o primeiro indicador em que se concentram geralmente é o volume de recalls.

Se 3 acertos não forem suficientes, ajuste para 8 acertos; se 8 ocorrências ainda não estiverem estáveis, continue a relaxar o limite de similaridade do vetor e, em seguida, empilhe o BM25, a filtragem de tags e a expansão de sinônimos. A taxa de acerto no painel parece boa e muitos problemas parecem estar “cobertos”. Mas depois de ficar online por um tempo, surgiu outro tipo de pergunta mais difícil: as respostas começaram a parecer cada vez mais verdadeiras e o tom tornou-se cada vez mais completo. No entanto, uma vez verificada cuidadosamente a fonte, ela foi misturada com regras de versões antigas, outros documentos de inquilinos, SOPs obsoletos e até mesmo instruções conflitantes.

Meu julgamento sobre esse tipo de problema é: **A confiabilidade do RAG geralmente sofre por “lembrar muitas coisas que não deveriam aparecer ao mesmo tempo”. Uma vez que o contexto esteja repleto de informações conflitantes, documentos expirados e conteúdo com permissões inconsistentes, o modelo não dirá honestamente que “as evidências entram em conflito e a resposta não pode ser respondida”. É mais comum seguir a inércia da linguagem e costurar esses fragmentos numa resposta que parece completa, mas na verdade a cadeia de evidências foi afrouxada. **

Esse tipo de problema parece inicialmente uma lembrança insuficiente, mas depois acaba sendo uma poluição do contexto.

Esta é a primeira vez que deixo esse julgamento claro. Superficialmente, parece que a resposta do modelo é muito curta, mas na verdade está mais perto de ser muito suave.

O cenário é uma sessão de perguntas e respostas de conhecimento interno dentro de uma empresa. O usuário fez uma pergunta bem específica no link de aprovação de reembolso: após uma viagem de negócios ao exterior ultrapassar o limite, entre ir primeiro ao supervisor direto para aprovação, ou ir primeiro ao centro de custo para análise. O sistema muitas vezes não consegue responder às perguntas no início, e o motivo é simples. Os sistemas relacionados estão espalhados em diferentes bases de conhecimento, e as pesquisas vetoriais muitas vezes só conseguem obter metade deles.

Então a equipe fez uma rodada típica de melhorias:

• TopK aumentado de 4 para 10;
• Adicionadas palavras-chave para relembrar os resultados financeiros;
• Combinação relaxada de expressões sinônimas;
• Junte anúncios históricos, perguntas frequentes e textos do sistema no conjunto de candidatos.

Funciona bem no curto prazo. A resposta não é mais “Nenhuma informação relevante encontrada”, mas agora pode organizar etapas completas. O problema começa aqui: os usuários relatam que a resposta “parece a resposta certa”, mas se realmente a seguirem, farão o pedido errado.

Mais tarde, quando desmontei uma resposta errada e olhei para ela, três tipos de materiais apareceram simultaneamente no contexto do modelo:

1. A cadeia de aprovação no antigo sistema há meio ano;
2. Cláusulas de exceção no texto do novo sistema;
3. Descrição de outra entidade regional no FAQ.

Cada um desses três materiais não é lixo e até parece “altamente relevante” quando visto individualmente. O problema é que eles não pertencem ao mesmo espaço de decisão. O que o modelo obtém é um monte de fragmentos relacionados em termos de palavras, mas com limites de negócios inconsistentes. No final, a resposta gerada foi misturar os três materiais em um novo processo.

É aqui que muitos projectos RAG são mais susceptíveis de serem mal avaliados: à primeira vista, parece que “a recolha tornou-se mais forte”, mas, em essência, actualiza o erro de recuperação de “falta de provas” para “provas sujas a entrar na fase de geração”.

Após mais recalls, o modelo não se tornará mais cauteloso, apenas se tornará melhor no reparo de costuras.

Uma situação comum é que, por padrão, fornecer mais informações ao modelo irá, na melhor das hipóteses, apenas deixá-lo escolher.

Mas a situação real está mais próxima de outro mecanismo: quanto mais longo o contexto, mais fragmentos e mais frouxa a relação semântica, mais fácil será para o modelo transformar “parcialmente razoável” em “verdadeiro global”. **

Isso ocorre porque a fase de geração se depara com uma sequência de texto que foi linearizada. Desde que estes textos possam literalmente colmatar uns aos outros, o modelo tenderá naturalmente a colmatar a lacuna. Esta tendência será particularmente forte nas seguintes situações:

• Os dois documentos têm conclusões diferentes, mas partilham muitos termos comerciais;
• Quando o novo sistema derrubou o antigo, não disse claramente “as regras antigas foram abolidas”;
• O FAQ resume o texto em termos coloquiais, mas omite as condições aplicáveis;
• O conteúdo multilocatário, multirregional e multiversão é recuperado em conjunto, mas só é diferenciado nos metadados.

Neste momento, o modelo não exporá diretamente “Vejo um conflito”, mas frequentemente fará três coisas:

1. Priorize as frases que melhor formam uma narrativa completa;
2. Preencher automaticamente as conexões de causa e efeito que não estão explicitamente declaradas no contexto;
3. Engula as condições de contorno e substitua-as por expressões que se pareçam mais com regras gerais.

No final, o que o usuário vê é uma resposta suave, completa e que parece ter sido julgada de forma abrangente. O perigo real é que isso provoca o conflito.

Documentos desatualizados não são ruído, eles diluirão ativamente o peso de novas evidências

Quando muitas equipes solucionam problemas de respostas incorretas do RAG, elas estão acostumadas a tratar documentos expirados como uma espécie de “ruído de baixa qualidade” e sentem que, desde que o número seja pequeno, não será um grande problema.

Mas durante a fase de geração, os documentos expirados são muitas vezes provas concorrentes que mudam activamente o foco da resposta.

Um exemplo mais típico que vi é a base de conhecimento de atendimento ao cliente. Uma determinada regra de reembolso foi alterada na nova versão da política, mas a versão antiga do FAQ tem maior probabilidade de ter uma classificação mais elevada na fase de recall devido ao seu alto número de visitas e expressões mais coloquiais. O texto da nova política está escrito com precisão, mas de forma rigorosa; o antigo FAQ é escrito sem problemas e possui um modelo retórico completo. Como resultado, quando o modelo responde, é muito fácil considerar a nova versão das regras como restrições locais e as antigas FAQ como a narrativa principal.

A resposta final geralmente é assim:

通常情况下用户可先申请原路退款，如遇活动商品则需进一步审核。

A coisa mais poderosa sobre esta frase é que quase todas as palavras podem ser encontradas no contexto, mas a frase inteira em si não existe em nenhuma fonte. A nova regra real pode ter sido alterada para “Produtos ativos não suportam reembolsos originais”, e o “normalmente” no antigo FAQ foi usado pelo modelo como uma frase geral, suprimindo diretamente a nova regra em uma exceção.

Portanto, o problema dos documentos expirados nunca é apenas o facto de “a informação antiga ter sido misturada”, mas a informação antiga ser muitas vezes mais parecida com a fala humana e ser mais fácil de ser usada como um esqueleto pelos modelos**.

Recuperar permissões inconsistentes é mais problemático do que respostas erradas porque criará respostas “aparentemente bem fundamentadas” que excedem a autoridade.

Outra questão que muitas vezes é subestimada são os limites de permissão.

Muitos sistemas RAG internos colocam a verificação de permissão no nível de “se o documento pode ser aberto”, pensando que, desde que o texto original não seja exibido ao usuário no final, tudo ficará bem. O perigo real do sistema generativo é: **Enquanto o documento restrito entra no contexto, mesmo que o texto original não seja postado no final, a própria resposta pode ter revelado julgamentos que não deveriam ser conhecidos. **

Por exemplo, quando o departamento de vendas faz uma pergunta sobre a aprovação de um contrato, existem apenas procedimentos gerais na base de conhecimento pública e há uma cláusula de exceção para clientes especiais na base de conhecimento jurídico. Se o estágio de recuperação apenas “lembrar primeiro e depois cortar”, então o modelo pode ter aproveitado essa regra de exceção no estágio de rascunho e, finalmente, produzir uma sugestão aparentemente neutra:

Esses clientes geralmente exigem aprovação regional adicional.

O usuário não pode ver o documento restrito, mas recebeu uma regra organizacional da qual não deveria ter conhecimento. Ainda mais preocupante é que esta frase é difícil de identificar como um vazamento em sua forma, porque é menos como copiar e colar e mais como o modelo “resumiu por si só”.

Portanto, a questão da permissão não pode ser entendida apenas como controle de acesso, mas deve ser entendida como controle da fonte de evidências. Assim que materiais que não pertencem à mesma faixa visível são alimentados juntos no modelo, o sistema cruzou uma linha. A subsequente dessensibilização e restrições de referência tratam apenas de contaminações que já ocorreram.

O que realmente precisa ser otimizado é deixar as evidências convergirem primeiro de acordo com o limite de decisão

Muitos sistemas RAG tornam-se cada vez mais caóticos posteriormente. Superficialmente, parece que o modelo é muito fraco. Na verdade, está mais próximo do estágio de recuperação e a própria direção de otimização é tendenciosa.

O que as equipes provavelmente farão é tratar os recalls como problemas de mecanismo de pesquisa:

• Se a correlação não for suficiente, adicione um canal de recall;
• Caso a cobertura não seja suficiente, adicione um pouco mais de topK;
• O método de consulta do usuário é instável, então reescreva mais a consulta.

Essas ações não são necessariamente erradas, mas se não houver restrições de “limite de decisão”, mais materiais que não deveriam aparecer ao mesmo tempo serão enviados para a fase de geração.

O que prestarei mais atenção posteriormente é outro conjunto de sequências de convergência:

1. Faça primeiro a convergência de intervalo e depois a classificação de correlação.

Muitas perguntas e respostas podem realmente limitar o escopo antes da recuperação semântica, como:

• entidade organizacional;
• região ou país;
• Tempo efetivo;
• Tipo de documento;
• Campo de permissões do usuário.

Se essas condições não forem levadas em consideração primeiro, e a classificação for baseada apenas na incorporação de similaridade, o resultado certamente incluirá coisas que são “semelhantes”. Isso ocorre porque o conjunto de candidatos está definido incorretamente.

2. Trate a versão e o tempo efetivo como cidadãos de primeira classe, em vez de metadados subsidiários

Muitas bases de conhecimento obviamente possuem os campos updated_at, version e status, mas eles são usados apenas na camada de apresentação e dificilmente participam da tomada de decisões ao recuperar e explicar o contexto. Dessa forma, o documento antigo e o novo documento são tratados igualmente, e o modelo não tem ideia de quem deve substituir quem.

Uma abordagem mais estável é lidar explicitamente com a relação de cobertura:

• Documentos obsoletos não entram no contexto de geração por padrão;
• Quando as regras antigas e novas entram em conflito, são diretamente marcadas como conflitos e o modelo não pode ser sintetizado livremente;
• As FAQ não podem cobrir o texto principal do sistema e só podem ser utilizadas como uma camada explicativa para complementá-lo.

3. Deixe o conflito ser exposto em vez de deixar o modelo ser o árbitro em vez do sistema.

Muitos sistemas são padronizados para unir vários materiais candidatos diretamente e entregá-los ao modelo, na esperança de que o modelo os “compreenda de forma abrangente” por conta própria. Esta etapa é precisamente a mais perigosa, porque terceiriza o tratamento de conflitos de evidências para a camada que melhor consegue corrigir as lacunas.

Se dois documentos de alto peso tiverem conclusões conflitantes, um comportamento mais razoável do sistema geralmente é informar explicitamente ao usuário:

• Foram encontradas regras conflitantes;
• Onde estão os pontos de conflito;
• Qual versão é usada atualmente por padrão ou é necessária confirmação manual.

Não parece tão sedoso, mas é realmente controlável. Reconhecer o conflito é mais parecido com um sistema confiável do que dar uma resposta completa, mas adulterada.

Um caso de falha particularmente comum: tratar o rearranjo como a solução final

Depois que muitas equipes descobrirem que “quanto mais recalls houver, mais caos haverá”, elas usarão imediatamente o reclassificador. Como resultado, a qualidade da classificação realmente melhorou, por isso eles consideram o problema resolvido.

Mas o que o reclassificador pode resolver é principalmente “quem é mais parecido com a resposta à pergunta”; não pode resolver “se esses candidatos pertencem ao mesmo espaço de fatos em fusão”.

Se o conjunto candidato contiver ambos:

• Regras da Região A 2024;
• Regras da Região B 2025;
• Instruções internas de exceção para administradores;
• FAQ para funcionários comuns;

O reclassificador classifica apenas dois ou três dos artigos acima. Ele não pode decidir fundamentalmente para o sistema se esses materiais podem ser alimentados juntos no modelo.

Isso também mostra que muitas análises de RAG parecem boas offline, mas começam a mudar assim que entram em cenas complexas online. As perguntas e respostas em coleções off-line geralmente são únicas, padronizadas e têm limites claros; a verdadeira complexidade das questões online é que elas estão relacionadas a versões, permissões, estruturas organizacionais e exceções. A classificação coloca apenas os materiais mais semelhantes em primeiro lugar e não gerencia a equipe automaticamente.

Limite aplicável: nem todos os cenários devem reduzir a quantidade de recall

Dizer que “muitos recalls tornam mais fácil cometer erros” não significa que todos os sistemas devam reduzir muito o topK.

Se você estiver fazendo perguntas e respostas exploratórias, coleta de dados e assistência à pesquisa, é razoável fornecer mais materiais, e os usuários estão dispostos a aceitar “há várias opiniões aqui”. Neste cenário, o objetivo do sistema é ajudar os usuários a navegar no espaço de informações.

O que realmente precisa controlar estritamente o limite de recall são os cenários em que a resposta será executada diretamente, como:

• Perguntas e respostas institucionais;
• Processo de aprovação;
• Calibre de atendimento ao cliente;
• Runbook de operação e manutenção;
• Suporte a decisões médicas, financeiras e de compliance.

Nestes cenários, a habilidade mais importante do sistema é “não combinar evidências mutuamente incompatíveis em uma instrução executável”. Uma vez que o custo de uma resposta errada é superior ao custo de não conseguir responder, a estratégia de busca não pode mais girar apenas em torno da cobertura.

Resumo

A coisa mais viciante sobre o RAG é que ele sempre pode fazer com que os dados do painel pareçam melhores no curto prazo, “lembrando um pouco mais”.

Mas depois de um sistema de conhecimento ser realmente lançado, a coisa mais difícil de recolher é se os materiais que entram no contexto pertencem ao mesmo conjunto de fronteiras factuais, à mesma semântica de versão e ao mesmo âmbito de autoridade.

Enquanto a questão não for resolvida primeiro, quanto mais recordações, mais o modelo se parecerá com uma pessoa que é particularmente boa a escrever resumos: pode não necessariamente dizer disparates deliberadamente, mas irá juntar provas que não devem ser reunidas numa resposta que se parece muito com uma conclusão.

Portanto, na próxima etapa da otimização do RAG, muitas vezes não devemos perguntar “quanto mais pode ser recuperado”, mas primeiro perguntar: **Qual conteúdo não deve aparecer junto no mesmo prompt. **