A Query Engine for the Agents

Resumen Técnico: Un Motor de Consultas para Agentes

Enunciado del Problema
Los datos de más rápido crecimiento en producción hoy en día son textos no estructurados, incluyendo trazas de agentes, registros de chat, cadenas de razonamiento y salidas de modelos. Analizar estos datos requiere preguntas que el SQL por sí solo no puede responder, como "muéstrame dónde se confundió el agente", lo que hace necesaria la integración de Modelos de Lenguaje Grande (LLM) directamente en la ruta de consulta. Sin embargo, la infraestructura de datos existente (Spark, Trino, almacenes gestionados) está diseñada para la ejecución en el servidor y es inadecuada para la nueva clase de aplicaciones de IA que se ejecutan en el cliente (por ejemplo, Claude Code, Cursor, agentes basados en navegadores). Estas aplicaciones alojan tanto a usuarios humanos como a agentes LLM en el mismo proceso (entornos de ejecución JavaScript como Node, Deno o Web Workers) y requieren acceso inmediato y de baja latencia a los datos sin la sobrecarga de una puerta de enlace de consultas en el backend. Además, los motores tradicionales luchan con el costo y la latencia de entrelazar operadores analíticos con llamadas de inferencia de LLM costosas y facturables.

Metodología y Arquitectura
Los autores presentan Hyperparam, un cliente de lago de datos nativo del navegador diseñado para ejecutarse enteramente dentro del entorno de ejecución JavaScript donde opera el agente. El sistema se compone de tres bibliotecas de JavaScript de código abierto que suman menos de 70 KB (comprimidas con gzip):

1. Hyparquet (14 KB): Un lector de Parquet que realiza lecturas eficientes por rangos. Obtiene solo los fragmentos de columna necesarios mediante solicitudes de rango HTTP paralelas, omitiendo grupos de filas irrelevantes utilizando estadísticas de mínimo/máximo. Soporta tipos anidados (crucial para los esquemas de trazas de LLM) y evita descargas de archivos completos.
2. Icebird (32 KB): Un cliente de Apache Iceberg del lado del cliente que resuelve instantáneas y aplica eliminaciones por posición o igualdad localmente. Utiliza un gancho custom-fetch para inyectar credenciales (por ejemplo, AWS SigV4, GCS HMAC) por solicitud, manteniendo al motor agnóstico a las credenciales y permitiendo el acceso directo al almacenamiento de objetos sin un proxy en el backend.
3. Squirreling (22 KB): Un motor SQL desde cero, nativo asíncrono. Su innovación central es la ejecución perezosa por celda. A diferencia de los motores vectorizados que procesan filas en lotes, Squirreling trata cada celda como un cálculo diferido (una Promesa).
   • Materialización Perezosa: Las columnas no se obtienen, descomprimen ni evalúan hasta que un operador aguas abajo las exige explícitamente.
   • Operadores Nativos Asíncronos: Todos los operadores se implementan como AsyncGenerators de JavaScript. Esto permite al motor canalizar operaciones, superponiendo E/S y llamadas de inferencia de LLM.
   • Integración con LLM: El motor soporta llm() como una Función Definida por el Usuario (UDF) de primera clase. Debido al modelo de ejecución perezosa, una llamada llm() solo se activa si la fila pasa todos los filtros previos y alcanza el límite de salida.

Contribuciones Clave

• Distribución Nativa de JS: El motor se integra directamente en el entorno de ejecución JavaScript existente de la aplicación, eliminando la necesidad de un segundo entorno de ejecución, una Interfaz de Función Externa (FFI) o un coordinador en el servidor.
• Tamaño de Paquete Extremadamente Pequeño: Toda la pila tiene menos de 70 KB, permitiendo una carga instantánea en pestañas de navegador frías o entornos aislados de agentes por turno, una reducción significativa en comparación con el núcleo de ~8 MB (comprimido con gzip) de DuckDB-WASM.
• Ejecución Consciente del Costo: Al diferir operaciones costosas (obtenciones de red, inferencias de LLM) hasta que sean absolutamente necesarias, el sistema alinea el costo con la demanda. Por ejemplo, una consulta con un LIMIT 5 solo activará cinco llamadas a LLM, independientemente de cuántas filas coincidan con el filtro, siempre que la consulta no requiera ordenación o agregación global.
• Acceso Directo al Almacenamiento: El sistema lee Parquet e Iceberg directamente desde el almacenamiento de objetos (S3, GCS, Azure) utilizando credenciales del lado del cliente, eliminando la latencia y la complejidad de una puerta de enlace de consultas.

Resultados
El documento proporciona comparaciones empíricas frente a DuckDB-WASM, el trabajo previo más cercano:

• Latencia: En un escenario de "arranque en frío" (cargando una tabla Iceberg de 40 GB de trazas de agentes), Hyperparam devuelve la primera fila en 0.6 segundos, en comparación con 19 segundos para DuckDB-WASM y minutos para clústeres en el servidor (Trino/Spark).
• Eficiencia de LLM: En consultas acotadas por filtros (por ejemplo, WHERE llm(...) = 1 LIMIT N), Squirreling es 300 veces más rápido que DuckDB-WASM. Esto se debe a que DuckDB-WASM evalúa filas en lotes vectorizados (morsels) y no puede empujar el LIMIT más allá de un filtro en una columna generada, lo que le hace evaluar miles de llamadas innecesarias a LLM. Squirreling se interrumpe en el límite.
• Costo del Agente: En una prueba de referencia donde un agente Anthropic Haiku respondió diez preguntas de estilo analista sobre un conjunto de datos de 50.000 filas, ambos motores lograron un 100% de corrección. Sin embargo, Squirreling logró esto con un costo un 66% menor (0.067 $ frente a 0.203 $ por pase). La reducción de costos fue impulsada por una reducción de 3.67 veces en los tokens de entrada, ya que los indicios de "¿querías decir?" y el manejo de errores de Squirreling permitieron al agente resolver consultas en menos rondas, evitando el crecimiento cuadrático de los costos de tokens de entrada asociados con el historial de conversaciones.
• Canalización: Incluso cuando los conteos de llamadas fueron similares (por ejemplo, en consultas acotadas por ordenación), Squirreling fue 192 veces más rápido en tiempo de reloj debido a su capacidad para canalizar hasta 256 invocaciones asíncronas concurrentes, mientras que el límite síncrono de WASM de DuckDB-WASM limitaba la concurrencia a uno.

Significado y Afirmaciones
El documento argumenta que la ingeniería de datos como disciplina debe evolucionar para soportar aplicaciones cliente "nativas de IA". La ruta de lectura convencional, que coloca infraestructura pesada entre el consumidor y los datos, rompe el ciclo "curar-revisar-actuar" requerido por los agentes. Hyperparam demuestra que un motor ligero del lado del cliente puede manejar eficazmente el análisis de texto no estructurado al entrelazar operadores analíticos con interpretación basada en modelos. Los autores lo posicionan no como un reemplazo para clústeres en el servidor para uniones masivas o cargas de trabajo que desbordan al disco, sino como la solución necesaria para la forma específica de datos y consultas que emergen de los flujos de trabajo de agentes, donde el motor debe llegar al consumidor para permitir límites de costos ajustados y una iteración rápida.