A Query Engine for the Agents

Technische Samenvatting: Een Query-engine voor Agents

Probleemstelling
De snelst groeiende data in productie vandaag is ongestructureerde tekst, inclusief agent-traces, chatlogs, redeneerketens en modeloutput. Het analyseren van deze data vereist vragen die SQL alleen niet kan beantwoorden, zoals "toon mij waar de agent in de war raakte", wat de integratie van Large Language Models (LLM's) direct in het query-pad noodzakelijk maakt. Echter, bestaande data-infrastructuur (Spark, Trino, beheerde datawarehouses) is ontworpen voor uitvoering aan de serverzijde en is ongeschikt voor de nieuwe klasse van AI-toepassingen die client-side draaien (bijvoorbeeld Claude Code, Cursor, browser-gebaseerde agents). Deze toepassingen hosten zowel menselijke gebruikers als LLM-agents in hetzelfde proces (JavaScript-runtimes zoals Node, Deno of Web Workers) en vereisen directe, laag-latente toegang tot data zonder de overhead van een backend query-gateway. Bovendien hebben traditionele engines moeite met de kosten en latentie van het afwisselen van analytische operatoren met dure, facturerbare LLM-inferentieoproepen.

Methodologie en Architectuur
De auteurs presenteren Hyperparam, een browser-native lakehouse-client die volledig binnen de JavaScript-runtime waarin de agent opereert, kan draaien. Het systeem bestaat uit drie open-source JavaScript-bibliotheken met een totaalgrootte van minder dan 70 KB (gegzipped):

1. Hyparquet (14 KB): Een Parquet-lezer die bereik-efficiënte lezingen uitvoert. Het haalt alleen de benodigde kolomchunks op via parallelle HTTP-range-aanvragen, en slaat irrelevante rijgroepen over met behulp van min/max-statistieken. Het ondersteunt geneste types (cruciaal voor LLM-trace-schema's) en vermijdt downloads van volledige bestanden.
2. Icebird (32 KB): Een client-side Apache Iceberg-client die snapshots oplost en positionele/gelijkheidsverwijderingen lokaal toepast. Het maakt gebruik van een custom-fetch-hook om per aanvraag referenties (bijvoorbeeld AWS SigV4, GCS HMAC) in te voegen, waardoor de engine referentie-agnostisch blijft en directe toegang tot objectopslag mogelijk is zonder backend-proxy.
3. Squirreling (22 KB): Een SQL-engine die van scratch is gebouwd en native async is. De kerninnovatie is uitvoering per cel, met vertraging. In tegenstelling tot vectorische engines die rijen in batches verwerken, behandelt Squirreling elke cel als een uitgestelde berekening (een Promise).
   • Lazy Materialisatie: Kolommen worden niet opgehaald, gedecomprimeerd of geëvalueerd totdat een downstream-operator ze expliciet vereist.
   • Async-Native Operatoren: Alle operatoren zijn geïmplementeerd als JavaScript AsyncGenerators. Dit stelt de engine in staat operaties te pipelinen, waarbij I/O en LLM-inferentieoproepen overlappen.
   • LLM-Integratie: De engine ondersteunt llm() als een User-Defined Function (UDF) van de eerste klasse. Vanwege het model van vertraagde uitvoering wordt een llm()-oproep alleen getriggerd als de rij alle voorgaande filters doorloopt en de outputlimiet bereikt.

Belangrijkste Bijdragen

• JS-Native Distributie: De engine wordt direct in de bestaande JavaScript-runtime van de applicatie gedropt, waardoor de noodzaak voor een tweede runtime, Foreign Function Interface (FFI) of server-side coördinator wordt geëlimineerd.
• Extreme Bundlegrootte: De volledige stack is kleiner dan 70 KB, wat instant laden mogelijk maakt in koude browser-tabbladen of per-beurt agent-sandboxes. Dit is een aanzienlijke reductie vergeleken met de ~8 MB (gegzipped) core van DuckDB-WASM.
• Kostenbewuste Uitvoering: Door dure operaties (netwerk-fetches, LLM-inferenties) uit te stellen tot ze absoluut noodzakelijk zijn, aligneert het systeem kosten met vraag. Bijvoorbeeld, een query met een LIMIT 5 zal slechts vijf LLM-oproepen triggeren, ongeacht hoeveel rijen aan het filter voldoen, mits de query geen globale sortering of aggregatie vereist.
• Directe Opslagtoegang: Het systeem leest Parquet en Iceberg direct vanuit objectopslag (S3, GCS, Azure) met client-side referenties, waardoor de latentie en complexiteit van een query-gateway worden verwijderd.

Resultaten
Het paper biedt empirische vergelijkingen met DuckDB-WASM, de dichtstbijzijnde voorganger:

• Latentie: In een "cold-start"-scenario (het laden van een 40 GB Iceberg-tabel met agent-traces) retourneert Hyperparam de eerste rij in 0,6 seconden, vergeleken met 19 seconden voor DuckDB-WASM en minuten voor server-side clusters (Trino/Spark).
• LLM-Efficiëntie: Bij filter-gelimiteerde queries (bijvoorbeeld WHERE llm(...) = 1 LIMIT N) is Squirreling 300× sneller dan DuckDB-WASM. Dit komt omdat DuckDB-WASM rijen in vectorische batches (morsels) evalueert en de LIMIT niet voorbij een filter op een gegenereerde kolom kan pushen, waardoor het duizenden onnodige LLM-oproepen evalueert. Squirreling maakt een kortsluiting bij de limiet.
• Agentkosten: In een benchmark waarbij een Anthropic Haiku-agent tien analist-achtige vragen beantwoordde op een dataset van 50.000 rijen, behaalden beide engines 100% correctheid. Squirreling behaalde dit echter tegen twee derde lagere kosten ($0,067 versus $0,203 per pass). De kostenreductie werd gedreven door een 3,67× reductie in input-tokens, aangezien de "bedoelde je dit"-hints en foutafhandeling van Squirreling de agent in staat stelden queries in minder rondes op te lossen, waardoor de kwadratische groei van input-tokenkosten geassocieerd met conversatiegeschiedenis werd voorkomen.
• Pipelining: Zelfs wanneer het aantal oproepen vergelijkbaar was (bijvoorbeeld in sort-gelimiteerde queries), was Squirreling 192× sneller in wandkloktijd vanwege het vermogen om tot 256 gelijktijdige async-aanroepen te pipelinen, terwijl de synchrone WASM-grens van DuckDB-WASM de concurrentie op één vastpind.

Betekenis en Claims
Het paper betoogt dat data-engineering als discipline moet evolueren om "AI-native" client-toepassingen te ondersteunen. Het conventionele leespad, dat zware infrastructuur tussen de consument en de data plaatst, breekt de "curate-review-act"-lus die door agents vereist wordt. Hyperparam demonstreert dat een lichtgewicht, client-side engine effectief ongestructureerde tekstanalyse kan verwerken door analytische operatoren te afwisselen met modelgebaseerde interpretatie. De auteurs positioneren dit niet als vervanging voor server-side clusters voor massale joins of spill-to-disk-werklasten, maar als de noodzakelijke oplossing voor de specifieke vorm van data en queries die voortkomen uit agentwerkstromen, waarbij de engine naar de consument moet komen om strakke kostenlimieten en snelle iteratie mogelijk te maken.