Executando verificação de segurança...
Em resposta a RAG em Documentos Longos: Desequilíbrio entre Contexto Global e Precisão Local
3
Oletros

Meus 2 cents,

Obrigado por compartilhar - este eh um problema bem interessante no uso do RAG.

Para quem esta lendo este texto e eh novato em RAG e nao percebeu a nuance do problema - basicamente eh o seguinte: voce tem muitos documentos onde um termo aparece de forma constante (no caso do exemplo: nome da empresa) e a pergunta eh feita usando tambem este termo, sendo que ele eh irrelevante para o contexto geral da pergunta/resposta.

O que acontece: na hora que os trechos/documentos sao recuperados para analise, como o termo tambem eh usado nesta pesquisa (mesmo sendo irrelevante), acaba "contaminando" e trazendo dados que nao sao uteis.

Entao, fica a questao: como eliminar termos "contaminantes" em uma pesquisa para RAG ?

Uma sugestao: usar o modelo de chunks 'pai/filho' no embending (Parent-Child (Small-to-Big) Retrieval)

Explicando: na hora de criar os indices de pesquisa dos documentos, usar chunks curtos (aprox 128/256 tokens), mas armazenar junto o chunk do 'pai' (que pode ser o paragrafo inteiro). Pesquise pelo 'filho' (micro-chunk) e retorne o 'pai' (macro-chunk) para o LLM fazer a analise. Geralmente os chunks 'filhos' com material irrelevante acabam nao tendo peso (score) suficiente para contaminar os resultados mais uteis. (Particularmente tenho usado esta tecnica).

A parte ruim eh ter de criar o banco vetorial um tanto diferente do que voce esta acostumado (p.ex. preparacao de chunks 'pais' e campo extra para o chunk 'pai').

Alguns autores sugerem usar a busca apenas pelos metadados para evitar isso - mas depende muito de como tua solucao precisa trabalhar (gosto de usar metadados como fonte auxiliar ou como pre-filtro e nao como principal).

Uma outra sugestao eh complementar (ou substituir) o RRF com 'Cross-Encoder' apos a pesquisa para fazer re-rank (o que pode ser uma opcao bem interessante) e tentar eliminar falsos positivos (pois percebe que o texto nao responde aa pergunta, apesar de ter a palavra-chave).

Saude e Sucesso !

Carregando publicação patrocinada...
2
Firmino

Obrigado pelo tempo gasto me ajudando, você explicou exatamente o tipo de nuance que costuma passar despercebida.

No meu caso, o sistema que está em produção já usa uma arquitetura híbrida bem mais profunda do que apenas RRF: o Qdrant faz o prefetch combinando dense + BM25, aplica late interaction (ColBERT) dentro do próprio banco e, depois disso, ainda passo os candidatos por um cross-encoder na aplicação para tentar eliminar falsos positivos. Isso resolve muitos casos práticos, mas ainda não é suficiente quando o problema acontece na fase de prefetch, onde os cabeçalhos com termos recorrentes preenchem todas as vagas antes mesmo do reranker ter chance de ver os chunks relevantes.

Achei interessante a sua sugestão do modelo small-to-big com relação pai/filho. Eu já fiz alguns testes nessa direção, mas seguindo um fluxo um pouco diferente. Do jeito que você descreveu, micro-chunks para buscar, macro-chunks para entregar contexto, faz bastante sentido como estratégia para evitar que headers “fortes” matematicamente coloquem os trechos específicos para fora do top-K inicial.

Agradeço pela explicação detalhada e pela sugestão prática. Vou testar essa lógica de parent-child retrieval de forma mais sistemática nos próximos ciclos. Excelente contribuição, obrigado mesmo!

2
Oletros
  • Autor
    Autor

Meus 2 cents extendidos,

Fico contente se agregou algo.

Espero que voce consiga achar uma solucao que adequada para tua situacao.

E, se nao for segredo industrial - por favor, nao esqueca de compartilhar o caminho seguido (este tipo de problema eh instigante).

Saude e Sucesso !