FLARE: Geração Aumentada por Recuperação Ativa

Na semana passada, eu estava lendo o artigo fundamental sobre RAG de Lewis et al. — recupere uma vez, anexe o resultado, gere. Funciona, mas assume que você sabe de antemão o que precisará. O FLARE (EMNLP 2023) ataca essa premissa diretamente: e se o momento certo para recuperar for no meio da frase, exatamente quando o modelo começa a ficar incerto? Vale a pena refletir sobre essa questão cuidadosamente para qualquer sistema — como um agente Beancount — que precise raciocinar sobre o histórico do livro-razão que não cabe em uma única janela de contexto.

O artigo

"Active Retrieval Augmented Generation" de Zhengbao Jiang, Frank F. Xu, Luyu Gao, Zhiqing Sun, Qian Liu, Jane Dwivedi-Yu, Yiming Yang, Jamie Callan e Graham Neubig propõe o FLARE: Forward-Looking Active REtrieval augmented generation (Geração aumentada por recuperação ativa voltada para o futuro). O problema que eles estão resolvendo é a alucinação durante a geração de textos longos, onde um modelo deve extrair múltiplas partes de conhecimento ao longo de uma saída extensa. O RAG padrão recupera uma única vez no momento da consulta e espera que o trecho recuperado cubra tudo o que a geração precisará — o que é aceitável para respostas curtas, mas frágil para respostas de vários parágrafos.

O FLARE divide a geração em etapas ao nível da frase. Em cada etapa, ele gera uma frase candidata seguinte. Se algum token nessa candidata tiver uma probabilidade prevista abaixo de um limiar θ, o FLARE trata esses intervalos de baixa confiança como sinais de recuperação, utiliza-os (mascarados ou completos) para formar uma consulta, recupera da Wikipedia e regenera a frase com o contexto recuperado. O resultado é um sistema que recupera apenas quando e aproximadamente onde está incerto — não sobrecarregando a recuperação inicial com conteúdo que talvez nunca precise. Todos os experimentos foram realizados no GPT-3.5 (text-davinci-003) sem qualquer ajuste fino.

Ideias principais

• Confiança como gatilho de recuperação: a probabilidade do token abaixo de θ sinaliza que o modelo provavelmente irá alucinar; a recuperação é acionada apenas nesse momento, não por padrão. Os autores descobriram que acionar para 40–80% das frases normalmente funciona melhor.
• Consultas voltadas para o futuro: em vez de usar apenas o que já foi gerado como consulta (a abordagem de "janela anterior"), o FLARE usa a frase futura prevista — o que o modelo acha que dirá — como uma consulta de recuperação muito mais direcionada.
• Duas variantes: o FLARE-instruct mascara tokens de baixa confiança e usa o intervalo mascarado como consulta; o FLARE-direct usa a frase prevista inteira. No 2WikiMultihopQA, a variante direta atinge 51,0 de EM contra 42,4 da variante instruct.
• Os ganhos sobre a recuperação única são reais, mas desiguais: no 2WikiMultihopQA, o FLARE-direct alcança 51,0 de EM contra 39,4 para recuperação única e 28,2 para nenhuma recuperação — uma melhoria decisiva. No ASQA, a diferença é muito menor (41,3 vs. 40,0), e no WikiAsp (UniEval 53,4 vs. 52,4) é quase um empate.
• Casos de falha explícitos: os autores relatam que o FLARE não oferece ganhos no Wizard of Wikipedia e no ELI5, onde saídas curtas significam que a recuperação em várias etapas adiciona sobrecarga sem benefício.
• Custo: como a geração e a recuperação se intercalam, cada exemplo pode acionar múltiplas conclusões do LM e chamadas de recuperação. O cache não é trivial.

O que se sustenta — e o que não

A estrutura voltada para o futuro é a parte genuinamente inteligente. Usar o conteúdo previsto como uma consulta de recuperação é mais informativo do que apenas o prefixo, especialmente para tarefas de múltiplos saltos onde conclusões intermediárias determinam qual fato você precisará a seguir. A lacuna de 51,0 vs. 39,4 de EM no 2WikiMultihopQA corrobora isso.

No entanto, o sinal de confiança do FLARE depende inteiramente de quão bem o modelo está calibrado. As probabilidades de token de um modelo de conclusão base como o text-davinci-003 correlacionam-se razoavelmente com a incerteza. O mesmo não é verdade para modelos de chat ajustados por instruções ou por RLHF, que são frequentemente excessivamente confiantes — eles emitem tokens de alta probabilidade mesmo quando estão alucinando. Um acompanhamento de 2024, Unified Active Retrieval (UAR, arXiv:2406.12534), avalia o FLARE em um conjunto mais amplo de decisões de recuperação e descobre que ele atinge apenas 56,50% de precisão em diversos cenários, em comparação com 85,32% para a abordagem baseada em classificador do UAR. O problema da calibração não é um caso isolado; é a premissa central na qual o método se baseia.

Há também uma questão de granularidade de recuperação que o artigo não aborda totalmente. O acionamento ao nível da frase é uma heurística razoável, mas alguns fatos abrangem limites de orações e outros estão localizados em um único nome de entidade. Uma probabilidade baixa em um token numérico (um valor em dólar, uma data) provavelmente deveria acionar a recuperação de forma diferente de uma probabilidade baixa em uma conjunção. O artigo trata todos os tokens de baixa confiança simetricamente.

Finalmente, o loop "regenerar se incerto" introduz latência. Os autores reconhecem isso, mas não o quantificam em relação a um orçamento de latência, o que é importante para aplicações interativas ou em tempo quase real.

Por que isso importa para a IA financeira

Um agente Beancount que resume um livro-razão de vários anos não pode recuperar todos os lançamentos históricos antecipadamente — o contexto transbordaria e a maior parte seria irrelevante para a resposta em questão. O design do FLARE combina bem com esse problema: gerar um rascunho inicial do comentário de conciliação, notar baixa confiança no saldo atual de um fornecedor específico, recuperar apenas as transações relevantes e, então, regenerar essa frase. O padrão é sólido.

O problema da calibração, contudo, é uma preocupação séria. Agentes financeiros de produção utilizam quase universalmente modelos de chat ajustados por instruções (GPT-4, Claude, Gemini), não modelos de conclusão base. Se esses modelos forem excessivamente confiantes — o que frequentemente acontece com afirmações numéricas — eles pularão a recuperação exatamente quando deveriam estar acionando-a. Um agente de escrita do Beancount que alucina uma data de transação com alta confiança e nunca recupera dados para verificar é pior do que inútil.

A lição prática é combinar a construção de consultas voltadas para o futuro do FLARE com um gatilho de recuperação que não dependa apenas da probabilidade do token. Marcadores de incerteza explícitos (frases de cautela, números redondos, entidades nomeadas que o modelo não viu recentemente) poderiam suplementar o sinal de confiança. Ou adotar a abordagem UAR: treinar um classificador leve nos estados ocultos do modelo que seja mais robusto à má calibração do que os logits brutos.

O que ler a seguir

• IRCoT: "Interleaving Retrieval with Chain-of-Thought Reasoning for Knowledge-Intensive Multi-Step Questions" (arXiv:2212.10509) — acopla a recuperação com etapas de CoT em vez de confiança de token; vale a pena comparar diretamente com o FLARE em tarefas de múltiplos saltos.
• Unified Active Retrieval (UAR, arXiv:2406.12534) — o acompanhamento direto que expõe a lacuna de calibração do FLARE e propõe decisões de recuperação baseadas em classificador em quatro cenários de recuperação.
• "Adaptive Retrieval without Self-Knowledge? Bringing Uncertainty Back Home" (arXiv:2501.12835) — um artigo de 2025 que reexamina se gatilhos baseados em probabilidade de token podem ser reabilitados com melhores técnicas de calibração.