Uber QueryGPT: lenguaje natural a SQL — de 10 minutos a 3

• QueryGPT — Natural Language to SQL at Uber — Uber Engineering Blog, 2024-09-19
• A Deep Dive into QueryGPT: Uber's AI-Powered SQL Generator — Sequel (независимый разбор), 2024

Contexto

Uber es una empresa impulsada por datos en el sentido literal: precios, rutas, pagos a conductores y equilibrio de demanda funcionan en una plataforma de datos que maneja aproximadamente 1.2 millones de consultas SQL interactivas por mes. El mayor consumidor es la organización de operaciones, contribuyendo aproximadamente el 36% de todas las consultas. Eso significa miles de empleados que necesitan datos diariamente pero para quienes SQL no es su profesión principal.

La analítica interna en Uber descansa en miles de conjuntos de datos, y las tablas clave (tier-1) han crecido a 200+ columnas cada una. Crear una consulta no es solo sintaxis: debes encontrar las tablas correctas entre miles y entender el esquema y la lógica empresarial de los campos — cómo se calculan las fechas en un dominio dado, o qué significa una bandera particular.

QueryGPT nació de abajo hacia arriba, no por decreto ejecutivo: la idea fue propuesta en los hackathon internos de Generative AI de mayo de 2023, cuando Uber estaba buscando sistemáticamente aplicaciones LLM en toda la empresa. Del prototipo del hackathon al servicio de producción descrito en la entrada del blog de ingeniería de septiembre de 2024, el equipo de Data Platform pasó por más de 20 iteraciones de arquitectura.

El caso es valioso precisamente por su honestidad de ingeniería: Uber publicó no un anuncio de marketing sino un análisis detallado con evolución de versiones, métricas de evaluación y problemas sin resolver — incluyendo alucinaciones y no determinismo de evaluación. El análisis es firmado por un equipo de ocho ingenieros de Data Platform — desde un ingeniero principal hasta desarrolladores enfocados en productividad LLM; es el producto de una organización de ingeniería, no un laboratorio de IA. Para cualquiera que construya text-to-SQL en su propia empresa, es uno de los documentos públicos más útiles de la industria.

Problema

Un promedio de consulta tomó a su autor aproximadamente 10 minutos. La anatomía de esos minutos: encontrar las tablas correctas entre miles de conjuntos de datos, dar sentido a un esquema de doscientas columnas, recordar convenciones de dominio (cómo filtrar órdenes de prueba, en qué zona horaria están las fechas) — y solo después escribir el SQL en sí. A una escala de cientos de miles de consultas por mes esto es un enorme impuesto de productividad: los equipos de operaciones gastaron tiempo en mecánicas de consultas en lugar de análisis y decisiones.

El enfoque ingenuo — 'simplemente dale el esquema y la pregunta al LLM' — golpeó límites fundamentales. El esquema de una única tabla grande consumió 40–60 mil tokens, mientras que las ventanas de contexto del modelo antes de modelos de era 128K eran de 32 mil. Las consultas a menudo unen varias tablas: el esquema físicamente no cabía en el modelo, sin mencionar el costo y la latencia de tales llamadas.

El segundo problema fue la gente. Los prompts de usuario reales varían desde formulaciones detalladas y ricas en palabras clave a preguntas de cinco palabras con errores tipográficos. Un pipeline ingenuo que espera entrada ordenada se desmorona en tráfico en vivo: una pregunta corta y sin contexto lleva muy poca señal para la selección de tablas o para generar SQL correcto.

Y tercero: el costo del error. SQL generado que se ve plausible pero usa una columna inexistente o lógica empresarial incorrecta es peor que ninguna respuesta — o falla o, más peligrosamente, devuelve números incorrectos en los que se toman decisiones. Los usuarios, como dice el equipo, tienen un nivel alto: las consultas deben 'simplemente funcionar'.

Solución

La primera versión, reunida en el hackathon, era RAG clásico: búsqueda de vector k-nearest-neighbor sobre un pequeño conjunto de 7 tablas tier-1 y 20 consultas SQL de referencia, de las cuales 3 tablas y 7 muestras fueron tiradas al prompt, más instrucciones con convenciones específicas de Uber (manejo de fechas, términos empresariales). El prototipo probó demanda, pero la precisión cayó en la variedad real de preguntas y tablas — y las siguientes veinte iteraciones más convirtieron 'un prompt con RAG' en un pipeline de agentes especializados.

El primer movimiento estructural fue 'espacios de trabajo': conjuntos curados de tablas y muestras SQL para un dominio empresarial específico. La producción ejecuta 12+ espacios de trabajo del sistema (Mobility, Core Services, Platform Engineering, IT, Ads, y otros), más espacios de trabajo personalizados para casos de uso estrechos. La curación es trabajo manual de expertos en dominio, y es — no el modelo — lo que proporciona la mayor ganancia de precisión: la búsqueda se ejecuta no en toda la plataforma sino dentro de un subconjunto pre-digerido.

Una pregunta luego pasa a través del pipeline. El Intent Agent clasifica la consulta en dominios empresariales y elige un espacio de trabajo, estrechando el radio de búsqueda RAG. El Table Agent selecciona tablas específicas — y muestra la lista al usuario, quien puede confirmar o editarla: el equipo agregó este paso de human-in-the-loop después de quejas sobre selección incorrecta de tablas. El Column Prune Agent elimina columnas irrelevantes de esquemas — esto resolvió el problema de tokens: incluso con la ventana de 128K de GPT-4 Turbo (modelo 1106), los esquemas completos eran caros y lentos, y la poda redujo sustancialmente tanto la latencia como los costos de llamadas. Un prompt enhancer separado enriquece las formulaciones lacónicas del usuario con contexto antes de la generación.

Contra alucinaciones (tablas y columnas inexistentes son el principal modo de fallo) el equipo usa un modo de chat iterativo donde el usuario refina la consulta, y experimenta con un agente de validación que recursivamente encuentra y corrige errores en el SQL generado.

El sistema de evaluación merece atención especial. El equipo reunió un conjunto 'dorado' de pares pregunta→SQL de los logs reales del servicio en dominios y lo ejecuta en dos modos: Vanilla (la ruta completa de pregunta a SQL) y Decoupled (intención y tablas preestablecidas, para medir componentes en aislamiento). Las señales: precisión de intención, superposición de tablas seleccionadas con la referencia (0–1), éxito de ejecución de consulta, retorno de resultado no vacío, y una puntuación de similitud basada en LLM contra el SQL de referencia. Un hallazgo separado: las ejecuciones de evaluación no son deterministas, con hasta ~5% de varianza entre ejecuciones sin cambios de código — por lo que el equipo rastrea patrones de error durante períodos largos en lugar de reaccionar a cambios de métrica.

Resultado

QueryGPT produce consultas suficientemente confiables en aproximadamente 3 minutos versus ~10 minutos de autoría manual — aproximadamente 70% de tiempo ahorrado por consulta. En versión limitada el servicio promedió aproximadamente 300 usuarios activos diarios, 78% de los cuales dicen que las consultas generadas reducen el tiempo que hubieran gastado escribiendo a mano. A la escala de la plataforma de 1.2 millones de consultas por mes el potencial de escalabilidad es obvio — pero el equipo está deliberadamente implementando gradualmente, y en sus aprendizajes publicados nombra explícitamente elegir la audiencia inicial correcta (personas) como una lección propia: comenzar donde el beneficio es mayor y las necesidades de SQL son rutinarias — con equipos de operaciones, no con ingenieros de datos, quienes menos necesitan un borrador LLM.

Los aprendizajes publicados del equipo importan tanto. Primero: los LLMs funcionan excelentemente como clasificadores en tareas estrechas — un pipeline de agentes especializados (intención → tablas → columnas) consistentemente supera un gran prompt. Segundo: la pregunta del usuario por sí sola es entrada insuficiente para generación; debe enriquecerse con contexto antes de la llamada del modelo. Tercero: la multiplicidad de respuestas (la misma pregunta se resuelve correctamente con diferentes tablas y estilos SQL) hace que la evaluación automatizada sea inherentemente difusa — de ahí un juez LLM y comparación visual contra la referencia en lugar de una coincidencia binaria/sin coincidencia.

Enmarca los números correctamente: 10 y 3 minutos son las estimaciones del equipo de Uber; 78% es auto-reporte del usuario, no medición de cronómetro; el servicio estaba en versión limitada en la publicación. Uber no publica ni un porcentaje de precisión de generación ni un impacto financiero — y, en nuestra opinión, eso es más honesto que extrapolaciones de blogs de terceros que pintan el caso con cientos de miles de horas ahorradas.

En nuestra opinión, la lección principal transferible de QueryGPT es que text-to-SQL en producción es 20% modelo y 80% ingeniería de contexto: espacios de trabajo de dominio curados, poda de esquemas, enriquecimiento de prompts, y disciplina de evaluación en un conjunto dorado. Todo eso se transfiere a cualquier empresa con una plataforma de datos grande — y no requiere ni tu propio modelo ni la escala de Uber. La segunda lección es ritmo: del hackathon a producción llevó más de un año y 20+ iteraciones. Los equipos que esperan que text-to-SQL 'funcione en un sprint' subestiman precisamente la cola larga de sintonización de dominio, no la dificultad de los LLMs.

Lecciones aprendidas

1. La text-to-SQL en producción es un pipeline de agentes especializados (intención → tablas → columnas), no un gran prompt: los LLMs son más confiables como clasificadores en tareas estrechas.
2. Los espacios de trabajo curados con muestras SQL por dominio superan alimentar al modelo el esquema completo: la inversión principal es curación manual por expertos en dominio.
3. La poda de esquemas (Column Prune) trata sobre precisión y costo: menos tokens — más barato, más rápido, mejor; incluso una ventana de 128K no cancela la economía de contexto.
4. La entrada del usuario no puede ir al modelo tal como está: preguntas reales varían de verbosas a cinco palabras con errores tipográficos, y un prompt enhancer antes de generación es obligatorio.
5. Human-in-the-loop en el lugar correcto: la confirmación del usuario de selección de tablas fue agregada después de quejas reales — un paso barato que elimina la principal fuente de error.
6. Evalúa en un 'conjunto dorado' construido a partir de logs reales, midiendo componentes en aislamiento; y ten en cuenta el no determinismo de evaluación LLM (~5% entre ejecuciones) — rastrea patrones de error, no cambios de métrica.
7. El marco de calidad honesto es 'un borrador suficientemente confiable en 3 minutos', no 'SQL perfecto': un humano permanece como revisor — una condición de confianza, no una debilidad del producto.

Preguntas frecuentes