A Query Engine for the Agents

Resumo Técnico: Um Motor de Consulta para Agentes

Declaração do Problema
Os dados de crescimento mais rápido em produção hoje são textos não estruturados, incluindo rastros de agentes, registros de chat, cadeias de raciocínio e saídas de modelos. Analisar esses dados exige perguntas que o SQL sozinho não consegue responder, como "mostre-me onde o agente ficou confuso", tornando necessária a integração de Modelos de Linguagem Grandes (LLMs) diretamente no caminho de consulta. No entanto, a infraestrutura de dados existente (Spark, Trino, armazéns gerenciados) é projetada para execução no lado do servidor e é inadequada para a nova classe de aplicações de IA que rodam no lado do cliente (por exemplo, Claude Code, Cursor, agentes baseados em navegador). Essas aplicações hospedam tanto usuários humanos quanto agentes LLM no mesmo processo (runtimes JavaScript como Node, Deno ou Web Workers) e exigem acesso imediato e de baixa latência aos dados, sem a sobrecarga de um gateway de consulta no backend. Além disso, motores tradicionais lutam com o custo e a latência de intercalar operadores analíticos com chamadas de inferência de LLM caras e cobráveis.

Metodologia e Arquitetura
Os autores apresentam o Hyperparam, um cliente de lakehouse nativo do navegador projetado para rodar inteiramente dentro do runtime JavaScript onde o agente opera. O sistema é composto por três bibliotecas JavaScript de código aberto, totalizando menos de 70 KB (comprimidos com gzip):

1. Hyparquet (14 KB): Um leitor Parquet que realiza leituras eficientes em intervalos. Ele busca apenas os blocos de colunas necessários por meio de solicitações de intervalo HTTP paralelas, ignorando grupos de linhas irrelevantes usando estatísticas de mínimo/máximo. Suporta tipos aninhados (cruciais para esquemas de rastro de LLM) e evita downloads de arquivos completos.
2. Icebird (32 KB): Um cliente Apache Iceberg do lado do cliente que resolve instantâneos e aplica exclusões por posição ou igualdade localmente. Utiliza um gancho custom-fetch para injetar credenciais (por exemplo, AWS SigV4, GCS HMAC) por solicitação, mantendo o motor agnóstico em relação às credenciais e permitindo acesso direto ao armazenamento de objetos sem um proxy de backend.
3. Squirreling (22 KB): Um motor SQL assíncrono e nativo, desenvolvido do zero. Sua inovação central é a execução preguiçosa por célula. Diferentemente de motores vetorizados que processam linhas em lotes, o Squirreling trata cada célula como um cálculo adiado (uma Promise).
   • Materialização Preguiçosa: Colunas não são buscadas, descomprimidas ou avaliadas até que um operador a jusante as exija explicitamente.
   • Operadores Nativos Assíncronos: Todos os operadores são implementados como AsyncGenerators em JavaScript. Isso permite que o motor encadeie operações, sobrepondo I/O e chamadas de inferência de LLM.
   • Integração com LLM: O motor suporta llm() como uma Função Definida pelo Usuário (UDF) de primeira classe. Devido ao modelo de execução preguiçosa, uma chamada llm() é acionada apenas se a linha passar por todos os filtros anteriores e atingir o limite de saída.

Principais Contribuições

• Distribuição Nativa em JS: O motor é integrado diretamente no runtime JavaScript existente da aplicação, eliminando a necessidade de um segundo runtime, Interface de Função Externa (FFI) ou coordenador no lado do servidor.
• Tamanho Extremo do Pacote: Toda a pilha tem menos de 70 KB, permitindo carregamento instantâneo em abas de navegador frias ou sandboxes de agentes por turno, uma redução significativa em comparação com o núcleo de ~8 MB (comprimido com gzip) do DuckDB-WASM.
• Execução Consciente de Custos: Ao adiar operações caras (buscas de rede, inferências de LLM) até que sejam absolutamente necessárias, o sistema alinha o custo à demanda. Por exemplo, uma consulta com LIMIT 5 acionará apenas cinco chamadas de LLM, independentemente de quantas linhas correspondam ao filtro, desde que a consulta não exija ordenação ou agregação global.
• Acesso Direto ao Armazenamento: O sistema lê Parquet e Iceberg diretamente do armazenamento de objetos (S3, GCS, Azure) usando credenciais do lado do cliente, removendo a latência e a complexidade de um gateway de consulta.

Resultados
O artigo fornece comparações empíricas contra o DuckDB-WASM, a obra mais próxima anterior:

• Latência: Em um cenário de "início frio" (carregando uma tabela Iceberg de 40 GB de rastros de agentes), o Hyperparam retorna a primeira linha em 0,6 segundos, comparado a 19 segundos para o DuckDB-WASM e minutos para clusters no lado do servidor (Trino/Spark).
• Eficiência de LLM: Em consultas limitadas por filtro (por exemplo, WHERE llm(...) = 1 LIMIT N), o Squirreling é 300× mais rápido que o DuckDB-WASM. Isso ocorre porque o DuckDB-WASM avalia linhas em lotes vetorizados (morsels) e não consegue empurrar o LIMIT além de um filtro em uma coluna gerada, fazendo com que avalie milhares de chamadas de LLM desnecessárias. O Squirreling interrompe o processo no limite.
• Custo do Agente: Em um benchmark onde um agente Anthropic Haiku respondeu a dez perguntas no estilo de analista em um conjunto de dados de 50.000 linhas, ambos os motores alcançaram 100% de correção. No entanto, o Squirreling alcançou isso com dois terços de custo menor ($0,067 vs $0,203 por passagem). A redução de custo foi impulsionada por uma redução de 3,67× nos tokens de entrada, pois os "dicas de você quis dizer" e o tratamento de erros do Squirreling permitiram que o agente resolvesse consultas em menos rodadas, evitando o crescimento quadrático dos custos de tokens de entrada associados ao histórico de conversação.
• Encadeamento: Mesmo quando as contagens de chamadas eram semelhantes (por exemplo, em consultas limitadas por ordenação), o Squirreling foi 192× mais rápido em tempo de relógio devido à sua capacidade de encadear até 256 invocações assíncronas concorrentes, enquanto a fronteira síncrona WASM do DuckDB-WASM limitava a concorrência a um.

Significado e Alegações
O artigo argumenta que a engenharia de dados, como disciplina, deve evoluir para suportar aplicações de cliente "nativas de IA". O caminho de leitura convencional, que coloca infraestrutura pesada entre o consumidor e os dados, quebra o loop "curar-revisar-agir" exigido por agentes. O Hyperparam demonstra que um motor leve do lado do cliente pode lidar efetivamente com a análise de texto não estruturado, intercalando operadores analíticos com interpretação baseada em modelos. Os autores posicionam isso não como uma substituição para clusters no lado do servidor para joins massivos ou cargas de trabalho de spill-to-disk, mas como a solução necessária para a forma específica de dados e consultas emergentes de fluxos de trabalho agênticos, onde o motor deve chegar ao consumidor para permitir limites de custo apertados e iteração rápida.