A Query Engine for the Agents

Résumé technique : Un moteur de requêtes pour les agents

Énoncé du problème
Les données en production qui connaissent la croissance la plus rapide aujourd'hui sont les textes non structurés, incluant les traces d'agents, les journaux de chat, les chaînes de raisonnement et les sorties de modèles. L'analyse de ces données nécessite des questions que le SQL seul ne peut pas répondre, telles que « montrez-moi où l'agent s'est perdu », ce qui impose l'intégration directe des grands modèles de langage (LLM) dans le chemin de requête. Cependant, l'infrastructure de données existante (Spark, Trino, entrepôts gérés) est conçue pour une exécution côté serveur et est mal adaptée à la nouvelle classe d'applications d'IA qui s'exécutent côté client (par exemple, Claude Code, Cursor, agents basés sur le navigateur). Ces applications hébergent à la fois les utilisateurs humains et les agents LLM dans le même processus (temps d'exécution JavaScript tels que Node, Deno ou Web Workers) et nécessitent un accès immédiat et à faible latence aux données, sans la surcharge d'une passerelle de requête backend. De plus, les moteurs traditionnels peinent avec le coût et la latence de l'entrelacement des opérateurs analytiques avec des appels d'inférence LLM coûteux et facturables.

Méthodologie et architecture
Les auteurs présentent Hyperparam, un client de lac de données natif du navigateur conçu pour s'exécuter entièrement dans le temps d'exécution JavaScript où l'agent opère. Le système est composé de trois bibliothèques JavaScript open source totalisant moins de 70 Ko (compressées) :

1. Hyparquet (14 Ko) : Un lecteur Parquet effectuant des lectures efficaces par plage. Il récupère uniquement les blocs de colonnes nécessaires via des requêtes HTTP par plage parallèles, en sautant les groupes de lignes non pertinents grâce aux statistiques min/max. Il prend en charge les types imbriqués (crucial pour les schémas de traces LLM) et évite le téléchargement complet des fichiers.
2. Icebird (32 Ko) : Un client Apache Iceberg côté client qui résout les instantanés et applique localement les suppressions par position ou par égalité. Il utilise un crochet custom-fetch pour injecter des identifiants (par exemple, AWS SigV4, GCS HMAC) par requête, maintenant le moteur agnostique des identifiants et permettant un accès direct au stockage objet sans proxy backend.
3. Squirreling (22 Ko) : Un moteur SQL asynchrone natif, développé depuis zéro. Son innovation centrale est l'exécution paresseuse par cellule. Contrairement aux moteurs vectorisés qui traitent les lignes par lots, Squirreling traite chaque cellule comme un calcul différé (une Promise).
   • Matérialisation paresseuse : Les colonnes ne sont pas récupérées, décompressées ou évaluées tant qu'un opérateur en aval ne les exige pas explicitement.
   • Opérateurs natifs asynchrones : Tous les opérateurs sont implémentés comme des AsyncGenerator JavaScript. Cela permet au moteur de mettre en pipeline les opérations, en chevauchant les E/S et les appels d'inférence LLM.
   • Intégration LLM : Le moteur prend en charge llm() en tant que fonction définie par l'utilisateur (UDF) de première classe. Grâce au modèle d'exécution paresseuse, un appel llm() n'est déclenché que si la ligne passe tous les filtres précédents et atteint la limite de sortie.

Contributions clés

• Distribution native JS : Le moteur s'intègre directement dans le temps d'exécution JavaScript existant de l'application, éliminant le besoin d'un deuxième temps d'exécution, d'une interface de fonction étrangère (FFI) ou d'un coordinateur côté serveur.
• Taille de bundle extrême : Toute la pile fait moins de 70 Ko, permettant un chargement instantané dans des onglets de navigateur froids ou des bac à sable d'agents par tour, une réduction significative par rapport au cœur d'environ 8 Mo (compressé) de DuckDB-WASM.
• Exécution consciente des coûts : En différant les opérations coûteuses (récupérations réseau, inférences LLM) jusqu'à ce qu'elles soient absolument nécessaires, le système aligne le coût sur la demande. Par exemple, une requête avec un LIMIT 5 ne déclenchera que cinq appels LLM, indépendamment du nombre de lignes correspondant au filtre, à condition que la requête ne nécessite pas de tri ou d'agrégation globale.
• Accès direct au stockage : Le système lit Parquet et Iceberg directement depuis le stockage objet (S3, GCS, Azure) en utilisant des identifiants côté client, éliminant la latence et la complexité d'une passerelle de requête.

Résultats
L'article fournit des comparaisons empiriques avec DuckDB-WASM, l'œuvre la plus proche antérieure :

• Latence : Dans un scénario de « démarrage à froid » (chargement d'une table Iceberg de 40 Go de traces d'agents), Hyperparam renvoie la première ligne en 0,6 seconde, contre 19 secondes pour DuckDB-WASM et des minutes pour les clusters côté serveur (Trino/Spark).
• Efficacité LLM : Dans les requêtes bornées par des filtres (par exemple, WHERE llm(...) = 1 LIMIT N), Squirreling est 300 fois plus rapide que DuckDB-WASM. Cela s'explique par le fait que DuckDB-WASM évalue les lignes par lots vectorisés (morsels) et ne peut pas pousser le LIMIT au-delà d'un filtre sur une colonne générée, ce qui l'amène à évaluer des milliers d'appels LLM inutiles. Squirreling s'arrête prématurément à la limite.
• Coût de l'agent : Dans un benchmark où un agent Anthropic Haiku a répondu à dix questions de style analyste sur un jeu de données de 50 000 lignes, les deux moteurs ont atteint 100 % de justesse. Cependant, Squirreling a atteint cela à deux tiers de coût en moins (0,067 $ contre 0,203 $ par passage). La réduction des coûts a été entraînée par une réduction de 3,67 fois des tokens d'entrée, car les suggestions « vouliez-vous dire » et la gestion des erreurs de Squirreling ont permis à l'agent de résoudre les requêtes en moins de tours, empêchant la croissance quadratique des coûts de tokens d'entrée associée à l'historique de conversation.
• Pipeline : Même lorsque les nombres d'appels étaient similaires (par exemple, dans les requêtes bornées par un tri), Squirreling était 192 fois plus rapide en temps réel grâce à sa capacité à mettre en pipeline jusqu'à 256 invocations asynchrones concurrentes, alors que la frontière WASM synchrone de DuckDB-WASM limitait la concurrence à un seul.

Signification et revendications
L'article soutient que l'ingénierie des données en tant que discipline doit évoluer pour soutenir les applications clientes « natives à l'IA ». Le chemin de lecture conventionnel, qui place une infrastructure lourde entre le consommateur et les données, brise la boucle « curator-examiner-agir » requise par les agents. Hyperparam démontre qu'un moteur léger côté client peut gérer efficacement l'analyse de textes non structurés en entrelaçant les opérateurs analytiques avec une interprétation basée sur le modèle. Les auteurs ne positionnent pas cela comme un remplacement des clusters côté serveur pour les jointures massives ou les charges de travail de débordement sur disque, mais comme la solution nécessaire pour la forme spécifique de données et de requêtes émergeant des flux de travail agentiques, où le moteur doit venir au consommateur pour permettre des limites de coûts serrées et une itération rapide.