Resumo Técnico: LAKEQA – Um Benchmark de QA Exploratório sobre um Data Lake de Escala de Milhões

Definição do Problema

Modelos de Linguagem de Grande Escala (LLMs) recentes demonstraram progressos significativos em Questionamento (QA) baseado em leitura, onde a evidência é fornecida explicitamente ou é trivialmente recuperável de corpora curados e estreitos. No entanto, cenários do mundo real frequentemente envolvem Questionamento Exploratório (EQA) sobre data lakes heterogêneos. Nesses ambientes, a evidência não é fornecida antecipadamente; em vez disso, ela está espalhada por coleções massivas de documentos estruturados (ex: CSV, JSON) e não estruturados (ex: PDF, HTML). Resolver tais problemas exige que agentes busquem iterativamente por arquivos relevantes, descubram entidades intermediárias e raciocinem através de múltiplos passos dependentes antes de formular uma resposta final.

Os benchmarks atuais falham em capturar essa complexidade simultaneamente. Datasets existentes ou possuem alta intensidade de busca (grandes coleções de documentos, mas baixa profundidade de raciocínio/poucos saltos) ou alta profundidade de raciocínio (mas operam sobre espaços de busca pequenos e curados). Há uma carência de um benchmark abrangente que exija tanto alta intensidade de busca (varredura de milhões de documentos) quanto alta intensidade de raciocínio (raciocínio de longo horizonte e múltiplos saltos com etapas intermediárias implícitas).

Metodologia

1. Construção do Benchmark (LAKEQA)

Os autores introduzem o LAKEQA, um benchmark projetado para avaliar capacidades de EQA sobre um data lake massivo e heterogêneo.

• Escala do Data Lake: O benchmark é construído sobre uma coleção de aproximadamente 9,5 TB de dados, compreendendo cerca de 40 milhões de documentos únicos.
• Fontes: Os dados são agregados de duas fontes de dados abertos complementares:
  • Wikipedia: Processada a partir do último dump em inglês para servir como um corpus de texto canônico.
  • Data.gov: Colhido do arquivo Harvard LIL data.gov, fornecendo artefatos governamentais públicos diversos e fracamente padronizados (tabelas estruturadas, metadados, relatórios).
• Design das Tarefas: Cada tarefa é uma questão complexa de linguagem natural que exige que um agente:
  1. Identifique documentos relevantes do conjunto de 40M.
  2. Extraia fatos de suporte.
  3. Encadeie etapas de raciocínio onde a saída de uma etapa serve como a condição de entrada para a próxima.
• Processo de Anotação: As tarefas são construídas via um processo de human-in-the-loop envolvendo especialistas de nível de doutorado e graduandos seniores. O processo envolve:
  • Construção de Subquestões: Os anotadores derivam fatos de documentos e formulam subquestões, encadeando-as de modo que $Resposta_i$ seja um pré-requisito para a $Pergunta_{i+1}$.
  • Reescrita da Pergunta: A cadeia é reescrita em uma única pergunta de sonoridade natural que oculta identificadores de documentos para evitar a descoberta trivial.
  • Controle de Qualidade: Cada tarefa passa por uma revisão de múltiplos estágios por anotadores independentes para garantir validade lógica, naturalidade e que a resposta final seja unicamente determinada pela evidência.

2. Configuração Experimental

• Modelos Avaliados: Sete LLMs de fronteira foram testados, incluindo modelos proprietários (OpenAI GPT-5.2, GPT-5-mini, Anthropic Claude Haiku/Sonnet/Opus 4.5) e modelos de código aberto (DeepSeek-R1, Llama-3.3-70B).
• Ambiente do Agente: Os modelos foram equipados com um conjunto de ferramentas que mimetiza fluxos de trabalho realistas de análise de dados, incluindo:
  • search(query): Busca por palavra-chave e semântica sobre o data lake.
  • list_files, download, inspect: Gerenciamento de arquivos e visualização prévia.
  • execute_code: Execução de Python para análise de dados local (filtragem, agregação).
• Baselines: Baselines de Geração Aumentada por Recuperação (RAG) foram testados usando busca BM25 e Híbrida (BM25 + Vetorial) sobre subconjuntos amostrados do data lake (10k–50k documentos).
• Métricas: O desempenho foi medido usando Exact Match (EM) para precisão de ponta a ponta, juntamente com Precisão, Recall e F1 ao nível de documento para eficácia de busca.

Principais Resultados

1. Lacuna de Desempenho

Mesmo com acesso a ferramentas de busca e inspeção, os LLMs de última geração lutam significativamente com o LAKEQA:

• Baixa Precisão: O modelo com melhor desempenho, Claude-sonnet-4.5, alcançou apenas 32,87% de Exact Match no benchmark completo (LAKEQA-full). O GPT-5.2 obteve 18,37%, e os modelos de código aberto tiveram desempenho ainda inferior.
• Troca entre Custo e Precisão: Embora modelos maiores (ex: Claude Opus) tenham mostrado maior precisão no mini-set (45,93%), eles incorreram em custos e tempo de execução significativamente maiores. Modelos menores e mais baratos frequentemente falharam devido à geração de código ineficiente ou raciocínio pobre.

2. Análise de Falhas

A análise de trajetória revelou que o principal gargalo é a descoberta de documentos, não o raciocínio sobre a evidência encontrada:

• Falha de Busca: Os modelos frequentemente falharam em recuperar os documentos "ouro" necessários para responder à pergunta. O Recall no conjunto recuperado ($D_{ret}$) foi baixo, indicando que os agentes não conseguiram trazer à tona os arquivos relevantes.
• Falha de Exploração: Mesmo quando documentos relevantes foram recuperados, os agentes frequentemente falharam em inspecioná-los ou analisá-los. Por exemplo, no LAKEQA-full, o Claude-sonnet-4.5 alcançou 42,36% de recall nos documentos recuperados, mas apenas 13,04% de recall nos documentos acessados ($D_{acc}$), sugerindo uma desconexão entre recuperação e exploração eficaz.
• Acúmulo de Erros: O desempenho degradou drasticamente conforme o número de saltos de raciocínio aumentava. Tarefas que exigiam >18 saltos viram uma queda drástica na precisão, indicando que a exploração de longo horizonte amplifica erros compostos de uma recuperação imperfeita e de restrições perdidas.

3. Baselines de RAG

Adicionar ferramentas de recuperação para subconjuntos reduzidos de documentos (10k–50k) melhorou ligeiramente o desempenho, mas não resolveu o problema. Os resultados sugerem que o EQA não é uma tarefa de recuperação de disparo único; os agentes devem inferir informações ausentes iterativamente, formular novas consultas e decidir quando a evidência é suficiente, uma capacidade que os sistemas RAG atuais carecem.

Significância e Alegações

O artigo posiciona o LAKEQA como um campo de testes realista para o desenvolvimento de agentes de LLM capazes de operar em ambientes modernos de data lake. Sua significância reside em:

1. Preencher a Lacuna: É o primeiro benchmark que escala simultaneamente tanto a intensidade de busca (40M de documentos) quanto a intensidade de raciocínio (cadeias de múltiplos saltos), abordando uma limitação de trabalhos anteriores como o OTT-QA (alta busca, baixo raciocínio) e MuSiQue (alto raciocínio, baixa busca).
2. Identificar Gargalos: Os experimentos demonstram que os agentes de LLM atuais ainda não são capazes de uma busca e exploração iterativas eficazes. O principal modo de falha é a incapacidade de descobrir e abrir os documentos de evidência corretos, e não a incapacidade de raciocinar uma vez que a evidência é encontrada.
3. Relevância no Mundo Real: Ao utilizar dados governamentais e da Wikipedia heterogêneos, o LAKEQA reflete a realidade desordenada e não estruturada dos data lakes do mundo real, indo além de corpora curados para desafiar os agentes com a complexidade de descobrir evidências no escuro.

Os autores concluem que, embora os LLMs tenham avançado na compreensão de leitura, a busca e exploração eficazes continuam sendo os principais gargalos para resolver questões complexas de domínio aberto sobre data lakes de grande escala.