Resumo Técnico: SANA - Estrutura de Ablação de Navegação de Agente de Busca

1. Definição do Problema

A Resposta a Perguntas Exploratórias (EQA, do inglês Exploratory Question Answering) sobre lagos de dados exige que um agente de LLM descubra iterativamente fontes relevantes, analise os dados recuperados e adapte suas ações com base em resultados intermediários. Diferente do QA padrão, o agente deve determinar quais tabelas, metadados, filtros ou computações são necessários para responder a uma pergunta de alto nível sem conhecimento prévio do esquema dos dados.

Os métodos de avaliação atuais dependem da precisão de ponta a ponta, o que confunde falhas em distintos componentes:

• Busca: Recuperação de fontes irrelevantes, incompletas ou ausentes.
• Planejamento: Decomposição da pergunta em subperguntas erradas ou incompletas.
• Análise de Dados: Escrita de consultas/códigos incorretos, interpretação errônea de resultados ou erros de esquema.
• Política do Agente: O processo de decisão ao nível de turno (Action Policy) que determina o que fazer a seguir, quando parar ou como sintetizar evidências.

Benchmarks anteriores (ex: LakeQA, KramaBench) e avaliações de agentes (ex: DCI, Metadata Reasoner) não isolam esses modos de falha. Consequentemente, permanece incerto se um agente falha devido a uma infraestrutura de recuperação pobre, cadeias de raciocínio fracas ou políticas de execução falhas.

2. Metodologia: A Estrutura SANA

Os autores propõem o SANA (estrutura de ablação de navegação de agente de busca), uma estrutura de ablação diagnóstica projetada para decompor as acurácias de tarefas de EQA de ponta a ponta em falhas de componentes específicos.

2.1 Perfil de Tarefa

O SANA transforma tarefas de EQA resolvidas em perfis de tempo de execução contendo informações de verdade fundamental (ground-truth):

1. Sequência de Fontes: A sequência ordenada de conjuntos de dados ideais ($D_{gold}$) necessária para cada subpergunta.
2. Subperguntas Sanitizadas: Uma sequência de subperguntas ($\tilde{Q}$) onde menções diretas a nomes de conjuntos de dados são removidas para evitar vazamento de alvos de busca (ex: substituindo "nypd_crimes" por "encontrar relatórios de crimes reportados pelo NYPD").
3. Registros de Execução: Especificações do conjunto de dados, a intenção de análise, o código/consulta correto e a resposta intermediária para cada etapa que requer análise de dados.

2.2 Ablação Baseada em Intenção

O SANA isola a contribuição dos componentes do sistema substituindo-os por versões idealizadas enquanto preserva a Política de Ação (Action Policy) do agente. A estrutura define três eixos para ablação:

• Ablação de Planejamento: O agente recebe a sequência de subperguntas sanitizadas ($\tilde{Q}$) e o objetivo de cada etapa, mas ainda deve formular consultas de busca e executar a análise. Isso testa se o agente consegue seguir uma decomposição correta.
• Ablação de Busca: A ferramenta de busca padrão é substituída por um operador de tipo oráculo ($f_{ideal}$) que restringe o espaço de busca estritamente a $D_{gold}$. O agente ainda decide o que buscar e quando, mas a precisão da recuperação é perfeita.
• Ablação de Análise de Dados: A ferramenta de execução padrão é substituída por $g_{ideal}$, que verifica se a intenção do agente corresponde ao registro de execução anotado. Se houver correspondência, retorna a resposta intermediária verificada; caso contrário, utiliza um modelo mais forte para gerar o código correto para a intenção declarada.

2.3 Configuração de Avaliação

A estrutura foi aplicada a dois benchmarks:

• LakeQA: Um cenário de lago de dados em larga escala (~40 milhões de documentos, 135 tarefas).
• KramaBench (Convertido): Um cenário de dados para insights em menor escala (1.764 fontes, 83 tarefas) adaptado para exigir descoberta de dados.

Os experimentos foram conduzidos com dois tamanhos de modelo (gpt-5.4-nano e gpt-5-mini) sob orçamentos fixos ($B=30$ chamadas de ferramenta) e tempos de execução. O estudo compara as configurações Naive (base), Standard (melhores práticas atuais) e Ideal (ablação).

3. Resultados Principais

3.1 Descobertas do LakeQA (Descoberta em Larga Escala)

• A Busca é um Gargalo Importante: A busca ideal (recuperação oráculo) melhorou a correspondência semântica (SM) em +14,1% para o gpt-5.4-nano e +13,3% para o gpt-5-mini em relação ao BM25. O carregamento prévio das fontes ideais gerou ganhos ainda maiores (+28,9% para o nano), indicando que agentes mais fracos lutam significativamente com a navegação de busca (formulação de consultas e compromisso com fontes).
• Análise de Dados é um Gargalo Consistente: A análise de dados ideal melhorou a SM em +18,5% para o gpt-5-mini, sugerindo que modelos mais fortes frequentemente identificam a intenção correta, mas falham na implementação (geração de SQL/Python).
• O Planejamento é Menos Limitante: O planejamento ideal proporcionou ganhos modestos (+3,0% para o nano, +9,6% para o mini). A análise revelou que os agentes podem frequentemente gerar planos semelhantes à decomposição de ouro, mas falham em seguí-los durante a execução (deriva de trajetória).
• Falhas de Política Residual: Mesmo com todos os componentes idealizados, permanece uma lacuna (ex: 76,3% de SM para o gpt-5-mini vs. 100% de potencial). As falhas incluem alucinar respostas finais, desperdiçar orçamento em loops ou falhar em validar evidências intermediárias.

3.2 Descobertas do KramaBench (Análise em Menor Escala)

• Análise de Dados Domina: Neste cenário, a análise de dados foi o principal gargalo, melhorando a SM em +24,1% (nano) e +14,5% (mini) quando idealizada.
• Busca é Menos Crítica: As melhorias na busca foram marginais (+2,4% a +6,0%), refletindo a escala menor e a natureza das tarefas, que estão mais próximas de pipelines de dados para insights do que de descobertas amplas.
• Impacto do Planejamento: A ablação de planejamento mostrou ganhos relativos mais significativos para o modelo mais fraco (nano) do que para o mais forte, sugerindo que a decomposição explícita ajuda mais os agentes mais fracos em tarefas de análise estruturada.

3.3 Análise de Falhas

A auditoria de rastros falhos revelou perfis de falha distintos:

• gpt-5.4-nano: As falhas foram distribuídas entre direcionamento de fonte, divergência de plano, desperdício de turnos (loops repetidos) e parada prematura.
• gpt-5-mini: As falhas concentraram-se em execução/computação (57,2% das falhas) e finalização (35,7%). Este modelo tipicamente alcança a evidência correta, mas falha em implementar a operação corretamente ou em sintetizar a resposta final.

4. Contribuições

1. Estrutura SANA: Uma estrutura de ablação diagnóstica que converte tarefas de EQA resolvidas em perfis de tempo de execução para construir interfaces idealizadas para planejamento, busca e análise de dados, preservando a política do agente.
2. Avaliação Controlada: Uma avaliação sistemática no LakeQA e no KramaBench convertido que isola as contribuições de ponta a ponta da busca, planejamento e execução sob condições fixas.
3. Diagnóstico Empírico: Evidência de que a análise de dados é uma limitação consistente entre os benchmarks, a busca é uma limitação importante na descoberta em larga escala, e as falhas de política residual (controle de trajetória, validação, critérios de parada) persistem mesmo quando os componentes são idealizados.

5. Significância e Alegações

O artigo alega que o SANA proporciona uma mudança necessária da avaliação de precisão de "caixa-preta" de ponta a ponta para uma abordagem diagnóstica que identifica modos de falha específicos em agentes de EQA.

• Desconstrução da Precisão: Os autores argumentam que a precisão de ponta a ponta sozinha não pode distinguir entre uma falha na busca, no planejamento ou na política do agente. O SANA permite comparações sistemáticas do progresso nessas áreas específicas.
• Qualidade da Política vs. do Componente: Os resultados sugerem que melhorias futuras em agentes de EQA exigem mais do que apenas melhores recuperadores ou geração de código mais forte. A "lacuna residual" indica a necessidade de políticas de tempo de execução mais fortes que possam rastrear o progresso dos subobjetivos, comprometer-se com fontes validadas, recuperar-se de derivas de trajetória e verificar evidências intermediárias antes de submeter uma resposta final.
• Gargalos Dependentes de Contexto: O artigo enfatiza que os gargalos não são universais; eles mudam com base na estrutura do benchmark (ex: a busca domina em grandes lagos, enquanto a análise domina em tarefas menores focadas em insights).

Limitações Reconhecidas pelos Autores:

• Aproximação Diagnóstica: Ferramentas ideais são aproximações de oráculos; elas podem não creditar fontes válidas alternativas fora do perfil.
• Escopo da Tarefa: As conclusões são específicas para os conjuntos de tarefas avaliados (LakeQA e KramaBench convertido) e podem não se generalizar para todos os benchmarks de agentes.
• Dependência de Juiz: Diversas métricas (correspondência semântica, trajetória de plano, rotulagem de falha) dependem de juízes LLM, o que pode introduzir falsos positivos/negativos.