Capítulo 5 — Arquitetando o Pipeline de Recuperação

Quinto post do passeio capítulo a capítulo pelo LLM Primer III: Aprimorando a IA Empresarial com RAG. Uma única busca vetorial é onde a maioria dos protótipos para, e onde a maioria das falhas em produção começa. O capítulo percorre o caminho inteiro de uma query mal formada até os candidatos finais que chegam no gerador — e por que cada estágio existe.

Por que este capítulo existe

Os capítulos 2 a 4 produziram um vector store: documentos parseados, chunkados com cuidado, embedados, indexados. O próximo passo ingênuo é embedar a query do usuário, rodar um lookup de vizinho mais próximo e jogar os top-k para o gerador. Para corpora triviais isso funciona. Para produção quase nunca. Queries chegam subespecificadas e cheias de nomes próprios que o embedder nunca viu; corpora contêm quase-duplicatas que entopem o topo de qualquer ranking único; identificadores e códigos carregam significado que o embedder achata.

O Capítulo 5 é sobre a arquitetura para a qual sistemas maduros convergem. Não é um artefato de pesquisa. É o formato que times de fato rodam quando recall, precisão e latência precisam todos se segurar ao mesmo tempo.

Em uma linha: um pipeline de recuperação em produção é recuperação híbrida fundida por reciprocal rank fusion, um reranker cross-encoder sobre os candidatos fundidos, e um estágio de entendimento de query na frente que reescreve o que foi perguntado antes do sistema tentar responder.

5.1 Por que uma única busca vetorial não basta

Recuperação densa reescreve a economia da busca, mas a própria tolerância a paráfrase que torna embeddings úteis também os deixa frágeis. Tokens numéricos, citações de estatuto, códigos de transação, números de peça — qualquer coisa em que a forma de superfície é o significado — aterrissam em cantos arbitrários do espaço vetorial. BM25, que simplesmente conta o que está lá, não tem esse problema.

Os dois métodos falham em entradas disjuntas. Essa observação única é o caso inteiro para recuperação híbrida, e é o primeiro princípio sobre o qual o capítulo se assenta. O resto segue: se nenhum retriever sozinho basta, o pipeline tem que combinar vários, fundir os rankings com honestidade, gastar compute real numa passagem final precisa, e preparar a query antes de tudo isso começar.

5.2 Busca híbrida: vetores densos e BM25 em paralelo

Dois índices sobre os mesmos chunks: um índice denso HNSW ou IVF do embedder, e um índice invertido esparso de BM25 ou SPLADE. Os dois são consultados, os dois devolvem listas ranqueadas, e o pipeline de ingestão escreve nos dois em sincronia. BM25 não é legado; é a função de ranqueamento por palavra-chave mais confiável já desenhada, leve em parâmetros mas não isenta deles, e ao longo da suíte BEIR a recuperação híbrida supera a só-densa na maioria das tarefas fora de domínio. O gap cresce conforme o domínio se afasta da distribuição de treino do embedder.

Um modo de falha específico que vale nomear: BM25 tem que ser tokenizado corretamente para cada idioma em escopo. Subir um corpus em japonês com o analisador padrão de inglês silenciosamente transforma a perna BM25 em puro ruído, e o sistema aparenta funcionar só porque a perna densa está carregando tudo. Recuperação esparsa também avançou — modelos esparsos aprendidos no estilo SPLADE herdam a simplicidade operacional de BM25 com o comportamento de recall de um retriever denso.

5.3 Reciprocal rank fusion e reranking com cross-encoder

O jeito ingênuo de combinar duas listas ranqueadas é somar suas notas. Isso não funciona — magnitudes de BM25 são ilimitadas e dependentes de corpus; similaridades por cosseno ficam grosso modo em [-1, 1]. Não são comensuráveis, e qualquer ponderação fixa vira um problema perpétuo de tuning. Reciprocal Rank Fusion escapa do problema jogando fora as notas. Para cada candidato, a nota fundida é a soma de 1/(k + rank) sobre os retrievers, com k = 60. A forma é íngreme no topo e plana na cauda, resultados são insensíveis a k, e o algoritmo compõe naturalmente com expansão multi-query — seis listas de três paráfrases contra dois retrievers fundem-se com a mesma linha de código.

RRF não salva um documento que nenhum retriever trouxe à tona; esse trabalho é do rewriting de query. O que ele faz, barato e sem hiperparâmetros, é reconciliar retrievers que são atualizados e trocados independentemente — um pipeline cuja fusão não precisa ser retreinada quando uma perna muda é dramaticamente mais barato de manter.

Os bi-encoders que produziram esses rankings nunca viram query e chunk juntos. Um reranker cross-encoder vê — ele concatena o par e os roda em conjunto por um transformer afinado para emitir uma nota de relevância. Toda cabeça de atenção vê os dois lados ao mesmo tempo, e o modelo consegue atentar à frase específica na query que deveria casar com uma frase específica no chunk. Não dá para pré-computar, então é lento demais como retriever primário, mas é perfeito sobre os 50 a 200 candidatos que a recuperação híbrida traz. O ganho em NDCG@10 é tipicamente de 5 a 15 pontos — maior do que trocar de modelo de embedding dentro da família dos bi-encoders.

5.4 Entendimento de query: rewriting, expansão, HyDE

Tudo acima assumia que a query estava bem formada. Raramente está. Um usuário de help-desk digita "férias"; a política diz "direito a licença anual". Um desenvolvedor digita "auth falha 500"; o runbook descreve "serviço de autenticação retorna HTTP 500 com falha de validação de token". O trabalho tem que acontecer do lado da query. Três padrões compõem: rewriting da query para que ela se sustente sozinha (resolvendo pronomes, expandindo siglas, trocando idioma para casar com o corpus); expansão em um punhado de paráfrases que cada uma se ramifica para os dois retrievers; e HyDE, que pede a um modelo pequeno que escreva uma resposta hipotética e embeda essa em vez da pergunta. O corpus está cheio de respostas, e respostas se parecem mais com outras respostas do que com perguntas.

O padrão defensivo é manter a query original ao lado da reescrita e despachar ambas. A saída do rewriter é uma hipótese, não uma substituta. A maioria das "regressões de recuperação" em sistemas agênticos é, na verdade, regressão de rewriting, e elas são invisíveis sem telemetria por estágio.

Vale a pena guardar: o pipeline de produção tem seis estágios — classifica, reescreve, recupera em paralelo, funde por RRF, reranqueia com cross-encoder, gera — e o reflexo de usar o modelo mais poderoso disponível em cada estágio é a causa mais comum de sistemas RAG caros, lentos e medíocres. Um rewriter de 7B e um reranker de 110M, dimensionados para o trabalho, ganham de um modelo de fronteira em todo nó quase sempre.

O que o Capítulo 5 prepara

O pipeline desenhado é também toda a superfície que um atacante precisa subverter. Cada estágio recebe entrada, produz saída e confia nos dados sobre os quais opera. O corpus pode ser envenenado na ingestão; o embedder pode ser manipulado por chunks adversariais; o reranker pode ser enviesado; o gerador pode ser enganado por instruções escondidas no conteúdo recuperado. Daqui o livro abre a Parte IV, e o enquadramento muda de como recuperar bem para o que acontece quando a recuperação é atacada.

Próximo — Capítulo 6: Modelos de Ameaça e Vulnerabilidades em RAG. A mesma abertura que torna o RAG útil é também a superfície que os adversários exploram — envenenamento de corpus, recuperação adversarial, injection indireta de prompt, inversão de embedding e o deputado confuso.

Quer o panorama completo? O livro carrega a fórmula BM25 e sua derivação no Apêndice A, a matemática completa do RRF, ColBERT de interação tardia como uma terceira arquitetura entre bi- e cross-encoders, e um diagrama ponta a ponta de pipeline em produção com telemetria por estágio e orçamentos de latência. LLM Primer III na Amazon →