A Query Engine for the Agents

Riepilogo Tecnico: Un Motore di Query per gli Agenti

Enunciato del Problema
I dati in crescita più rapida nella produzione odierna sono testi non strutturati, inclusi tracciati degli agenti, registri di chat, catene di ragionamento e output dei modelli. L'analisi di questi dati richiede domande che il solo SQL non può rispondere, come "mostrami dove l'agente si è confuso", rendendo necessaria l'integrazione diretta dei Modelli Linguistici di Grandi Dimensioni (LLM) nel percorso di query. Tuttavia, l'infrastruttura dati esistente (Spark, Trino, magazzini gestiti) è progettata per l'esecuzione lato server e non si adatta alla nuova classe di applicazioni AI che vengono eseguite lato client (ad esempio, Claude Code, Cursor, agenti basati su browser). Queste applicazioni ospitano sia utenti umani che agenti LLM nello stesso processo (runtime JavaScript come Node, Deno o Web Workers) e richiedono un accesso immediato e a bassa latenza ai dati senza il sovraccarico di un gateway di query backend. Inoltre, i motori tradizionali faticano con i costi e la latenza dell'interleaving di operatori analitici con chiamate di inferenza LLM costose e fatturabili.

Metodologia e Architettura
Gli autori presentano Hyperparam, un client lakehouse nativo del browser progettato per essere eseguito interamente all'interno del runtime JavaScript in cui opera l'agente. Il sistema è composto da tre librerie JavaScript open source che totalizzano meno di 70 KB (gzip):

1. Hyparquet (14 KB): Un lettore Parquet che esegue letture efficienti per intervallo. Recupera solo i blocchi di colonna necessari tramite richieste HTTP range parallele, saltando i gruppi di righe irrilevanti utilizzando le statistiche min/max. Supporta tipi annidati (cruciali per gli schemi dei tracciati LLM) ed evita il download di file completi.
2. Icebird (32 KB): Un client Apache Iceberg lato client che risolve gli snapshot e applica localmente le cancellazioni per posizione o per uguaglianza. Utilizza un hook custom-fetch per iniettare le credenziali (ad esempio, AWS SigV4, GCS HMAC) per ogni richiesta, mantenendo il motore agnostico rispetto alle credenziali e consentendo l'accesso diretto all'archiviazione degli oggetti senza un proxy backend.
3. Squirreling (22 KB): Un motore SQL nativo asincrono e scritto da zero. La sua innovazione principale è l'esecuzione per cella e lazy. A differenza dei motori vettoriali che elaborano le righe in batch, Squirreling tratta ogni cella come un calcolo differito (una Promise).
   • Materializzazione Lazy: Le colonne non vengono recuperate, decompressate o valutate fino a quando un operatore a valle non le richiede esplicitamente.
   • Operatori Nativi Asincroni: Tutti gli operatori sono implementati come AsyncGenerator JavaScript. Ciò consente al motore di mettere in pipeline le operazioni, sovrapponendo I/O e chiamate di inferenza LLM.
   • Integrazione LLM: Il motore supporta llm() come funzione definita dall'utente (UDF) di prima classe. Grazie al modello di esecuzione lazy, una chiamata llm() viene attivata solo se la riga supera tutti i filtri precedenti e raggiunge il limite di output.

Contributi Chiave

• Distribuzione Nativa JS: Il motore si integra direttamente nel runtime JavaScript esistente dell'applicazione, eliminando la necessità di un secondo runtime, di un'interfaccia per funzioni esterne (FFI) o di un coordinatore lato server.
• Dimensione Estrema del Pacchetto: L'intera pila è inferiore a 70 KB, consentendo un caricamento istantaneo in schede browser fredde o sandbox di agenti per turno, una riduzione significativa rispetto al nucleo di ~8 MB (gzip) di DuckDB-WASM.
• Esecuzione Consapevole dei Costi: Rimandando le operazioni costose (recupero di rete, inferenze LLM) fino a quando non sono assolutamente necessarie, il sistema allinea il costo alla domanda. Ad esempio, una query con LIMIT 5 attiverà solo cinque chiamate LLM, indipendentemente da quante righe corrispondono al filtro, a condizione che la query non richieda ordinamento o aggregazione globale.
• Accesso Diretto all'Archiviazione: Il sistema legge Parquet e Iceberg direttamente dall'archiviazione degli oggetti (S3, GCS, Azure) utilizzando credenziali lato client, rimuovendo la latenza e la complessità di un gateway di query.

Risultati
Il documento fornisce confronti empirici rispetto a DuckDB-WASM, l'opera precedente più vicina:

• Latenza: In uno scenario di "avvio a freddo" (caricamento di una tabella Iceberg da 40 GB di tracciati degli agenti), Hyperparam restituisce la prima riga in 0,6 secondi, rispetto ai 19 secondi di DuckDB-WASM e ai minuti necessari per i cluster lato server (Trino/Spark).
• Efficienza LLM: Nelle query delimitate da filtri (ad esempio, WHERE llm(...) = 1 LIMIT N), Squirreling è 300 volte più veloce di DuckDB-WASM. Questo perché DuckDB-WASM valuta le righe in batch vettoriali (morsels) e non può spingere il LIMIT oltre un filtro su una colonna generata, causando la valutazione di migliaia di chiamate LLM non necessarie. Squirreling interrompe il processo al limite.
• Costo dell'Agente: In un benchmark in cui un agente Anthropic Haiku ha risposto a dieci domande di tipo analista su un dataset di 50.000 righe, entrambi i motori hanno raggiunto il 100% di correttezza. Tuttavia, Squirreling ha raggiunto questo risultato con un costo inferiore di due terzi (0,067 $ contro 0,203 $ per passaggio). La riduzione dei costi è stata guidata da una riduzione di 3,67 volte dei token di input, poiché i suggerimenti "intendevi?" e la gestione degli errori di Squirreling hanno permesso all'agente di risolvere le query in meno round, prevenendo la crescita quadratica dei costi dei token di input associata alla cronologia delle conversazioni.
• Pipeline: Anche quando i conteggi delle chiamate erano simili (ad esempio, nelle query delimitate dall'ordinamento), Squirreling è stato 192 volte più veloce in termini di tempo reale grazie alla sua capacità di mettere in pipeline fino a 256 invocazioni asincrone concorrenti, mentre il confine sincrono WASM di DuckDB-WASM vincolava la concorrenza a uno.

Significato e Affermazioni
Il documento sostiene che l'ingegneria dei dati come disciplina deve evolversi per supportare applicazioni client "nate per l'AI". Il percorso di lettura convenzionale, che colloca infrastrutture pesanti tra il consumatore e i dati, rompe il ciclo "curare-rivedere-agire" richiesto dagli agenti. Hyperparam dimostra che un motore leggero lato client può gestire efficacemente l'analisi del testo non strutturato intercalando operatori analitici con interpretazioni basate sui modelli. Gli autori lo posizionano non come sostituto dei cluster lato server per join massicci o carichi di lavoro che richiedono spill su disco, ma come la soluzione necessaria per la forma specifica di dati e query che emergono dai flussi di lavoro agenziali, dove il motore deve arrivare al consumatore per consentire limiti di costi stretti e iterazioni rapide.