Hablar con datasets gigantes: el playbook técnico que nadie escribe

Cada pocas semanas aparece en Reddit el mismo tipo de hilo: alguien construye una app de “habla con tus datos”, la demo funciona, y luego el dataset real lo rompe. El último que vi —un desarrollador de r/microsaas contando lecciones técnicas de su app de talk-to-large-datasets— repite un patrón que lleva dos años en r/AI_Agents: la parte difícil no es el prompt, es todo lo que rodea al prompt cuando los datos no caben en la ventana de contexto.

Este artículo es el playbook que esos hilos insinúan pero nunca escriben entero. No es teoría: cada sección corresponde a un punto de fallo documentado por gente que ya lo ha roto en producción.

TL;DR

• Text-to-SQL directo muere con esquemas de más de ~30 tablas. Necesitas una capa semántica que traduzca conceptos de negocio a SQL.
• Si el dataset no cabe en memoria, el LLM no debe tocar los datos: genera una consulta contra un motor columnar (DuckDB, Parquet) y el motor hace el trabajo.
• La latencia se optimiza en tres sitios: prefiltrado por metadatos, caché de consultas canónicas y streaming parcial de resultados.
• Sin un set de preguntas doradas y regresión automática, cada cambio de prompt es un tiro a ciegas. Es la parte que casi nadie construye y la que separa producto de demo.

1. El LLM no debe leer tus datos, debe consultarlos

El error fundacional: volcar filas al contexto. Con 100 millones de filas no hay ventana de contexto que valga, y aunque la hubiera, el coste por pregunta sería absurdo.

La arquitectura que funciona invierte el flujo: el LLM genera una consulta —SQL, una expresión de filtro, una llamada a una API de agregación— y un motor real la ejecuta. DuckDB sobre archivos Parquet es hoy la combinación más práctica para analítica local: escanea columnas comprimidas a velocidades de cientos de millones de filas por segundo en un portátil, y el LLM solo ve el resultado agregado.

El hilo de r/microsaas lo resume desde la trinchera: la app no “entiende” el dataset, hace de traductor entre el lenguaje de usuario y el motor. Cuanto antes aceptes que el modelo es un traductor con mal día, mejor diseñas el resto.

2. Los esquemas grandes rompen el text-to-SQL ingenuo

Text-to-SQL funciona sorprendentemente bien en los benchmarks porque los benchmarks tienen 3 tablas. Un esquema empresarial real tiene 200, con nombres de columna heredados de un ERP de 2009.

Cuando el prompt no puede contener el esquema entero, el modelo alucina columnas. La solución conocida es una capa semántica: una descripción curada de las entidades de negocio —“ingresos = tabla facts_orders, columna total_net, filtrar status=‘paid’”— que alimenta al modelo en lugar del esquema crudo. Es curación manual y es aburrida, y es exactamente por eso por lo que funciona: estás condensando decisiones de negocio en un artefacto versionable.

Regla práctica de quienes lo han shipped: si tu capa semántica describe más de ~50 conceptos, divídela por dominio y enruta la pregunta al dominio correcto antes de generar SQL. Un clasificador barato delante de un generador caro.

3. Chunking: particiona por la pregunta, no por el archivo

Cuando sí hay que pasar contenido al modelo —documentos, texto libre, logs— el chunking por defecto (trocear a N tokens con overlap) genera respuestas mediocres en datasets grandes porque la recuperación trae fragmentos irrelevantes que igualmente consumen contexto.

Lo que funciona mejor en producción:

• Particionar por metadatos estables (fecha, entidad, fuente) y filtrar antes de recuperar, no después. La mayoría de preguntas reales son “¿qué pasó con X en Y?”, y el prefiltrado por metadatos elimina el 90% del espacio de búsqueda antes de que el embedding entre en juego.
• Chunkear respetando la estructura del dato: una fila de transacción, un evento, un párrafo con su encabezado de sección. Nunca a mitad de ambos.
• Guardar agregados precalculados para las preguntas que sabes que van a llegar. La caché de consultas canónicas resuelve más latencia que cualquier optimización de modelo.

4. La latencia se presupuesta, no se desea

“La respuesta tarda 40 segundos” es la queja recurrente en todos estos hilos. La forma profesional de atacarla es asignar un presupuesto en milisegundos y repartirlo:

Fase	Presupuesto típico	Palanca si te pasas
Clasificación/enrutado	<500 ms	Modelo pequeño o reglas
Recuperación/prefiltrado	<1 s	Índices, particiones, caché
Generación de consulta	1-3 s	Prompt más corto, few-shot curado
Ejecución	depende del motor	Agregados precalculados
Redacción de respuesta	2-5 s	Streaming token a token

El streaming es el truco psicológico más rentable: una respuesta que empieza a llegar en dos segundos se percibe el doble de rápida que una idéntica que llega entera en cinco, aunque el tiempo total sea el mismo.

5. Evaluación: las preguntas doradas que nadie quiere escribir

Aquí está la diferencia real entre demo y producto. Un eval para una app de talk-to-data es una lista de preguntas reales con la respuesta correcta conocida —50 para empezar, 200 cuando estés en serio— que ejecutas automáticamente en cada cambio de prompt, modelo o capa semántica.

Sin esto, cada iteración es vibes-driven: cambias el prompt, pruebas tres preguntas a mano, declaras victoria. Y tres semanas después descubres que el cambio rompió las consultas con fechas relativas, que eran el 30% del tráfico.

El componente mínimo:

1. Golden set de preguntas SQL-verificables con resultado esperado.
2. Runner que ejecuta la pipeline entera y compara resultados (no el texto: el dato).
3. Un umbral de regresión que bloquee el deploy si baja.

El hilo de marras menciona su stack de evaluación como una de las lecciones clave, y no es casualidad: es la parte que más duele construir y la que más paga.

6. Lo que la demo no enseña: fallos, permisos y expectativas

Tres cosas que solo aparecen en producción:

• Consultas imposibles: el usuario pregunta algo que los datos no contienen. El sistema debe decir “no puedo responder esto con estos datos” en vez de inventar una consulta plausible que devuelve un número falso. Este caso de fallo hay que entrenarlo y testearlo explícitamente.
• Permisos: la pregunta “¿cuánto gana cada empleado?” es legítima para RRHH y un incendio para el resto. El filtrado por rol tiene que ocurrir en el motor, no en el prompt.
• Expectativas: los usuarios asumen que la app “entiende” los datos. Cada respuesta debería mostrar la consulta generada —o al menos las tablas usadas— para que un humano pueda verificar. La auditabilidad es una feature, no un lujo.

Conclusión

La receta completa: motor columnar debajo, capa semántica en medio, LLM como traductor, prefiltrado por metadatos, presupuesto de latencia por fase, y un golden set que impida regresiones. Ninguna de las piezas es exótica. Lo excepcional es que casi nadie las junta, porque cada una por separado es trabajo sin demo impactante.

Si estás construyendo algo de esto, el hilo original de r/microsaas vale los diez minutos. Y si ya tienes algo en producción, cuéntame qué se te rompió primero — sospecho que fue la capa semántica.

Fuentes

• I make a “talk to large datasets” app. Here are a few technical lessons learned — r/microsaas, agosto 2026
• DuckDB — an in-process analytical database
• Discusiones de producción en r/AI_Agents sobre auditabilidad y fallos de agentes con datos (agosto 2026)