Uber QueryGPT: SQL-запрос из естественного языка — 10 минут превратились в 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

Контекст

Uber — компания, управляемая данными в буквальном смысле: цены, маршруты, выплаты водителям и балансировка спроса считаются на дата-платформе, которая обрабатывает около 1,2 миллиона интерактивных SQL-запросов в месяц. Крупнейший потребитель — операционная организация: на неё приходится около 36% всех запросов. Это тысячи сотрудников, которым данные нужны ежедневно, но SQL для которых — не основная профессия.

Внутренняя аналитика в Uber опирается на тысячи датасетов, и ключевые (tier-1) таблицы разрослись до 200 с лишним колонок каждая. Написание запроса — это не только синтаксис: нужно найти правильные таблицы среди тысяч, понять схему и бизнес-логику полей — например, как в конкретном домене считаются даты или что означает конкретный флаг.

QueryGPT родился снизу, а не по указанию сверху: идею предложили на внутреннем хакатоне Generative AI Hackdays в мае 2023 года — Uber тогда системно искала применения LLM по всей компании. От хакатон-прототипа до продакшен-сервиса, описанного в инженерном блоге в сентябре 2024 года, команда Data Platform прошла более 20 итераций архитектуры.

Этот кейс ценен именно инженерной честностью: Uber опубликовала не маркетинговый анонс, а подробный разбор с эволюцией версий, метриками оценки и нерешёнными проблемами — включая галлюцинации и недетерминированность оценок. Разбор подписан командой из восьми инженеров Data Platform — от принципал-инженера до разработчиков, сфокусированных на LLM-продуктивности; это продукт инженерной организации, а не ИИ-лаборатории. Для всех, кто строит text-to-SQL для своей компании, это один из самых полезных публичных документов в индустрии.

Проблема

Средний запрос занимал у автора около 10 минут. Анатомия этих минут такова: найти нужные таблицы среди тысяч датасетов, разобраться в схеме на две сотни колонок, вспомнить доменные соглашения (как фильтровать тестовые заказы, в какой таймзоне даты) — и только потом написать сам SQL. На масштабе в сотни тысяч запросов в месяц это огромный налог на продуктивность: операционные команды тратили время не на анализ и решения, а на механику написания запросов.

Попытка «просто дать LLM схему и вопрос» упиралась в фундаментальные ограничения. Схема одной крупной таблицы занимала 40–60 тысяч токенов — а контекстное окно моделей до появления 128-тысячных лимитов составляло 32 тысячи. Запросы же часто требуют соединения нескольких таблиц: вся схема физически не помещалась в модель, не говоря уже о стоимости и задержке таких вызовов.

Вторая проблема — люди. Реальные запросы пользователей варьируются от подробных, богатых ключевыми словами формулировок до вопросов из пяти слов с опечатками. Наивный конвейер, ожидающий аккуратного входа, разваливается о живой трафик: короткий вопрос без контекста не содержит достаточно сигнала ни для выбора таблиц, ни для генерации корректного SQL.

И третья: цена ошибки. Сгенерированный SQL, который выглядит правдоподобно, но использует несуществующую колонку или неверную бизнес-логику, хуже отсутствия ответа — он либо падает, либо, что опаснее, возвращает неверные цифры, на которых примут решение. У пользователей, как формулирует команда, высокая планка ожиданий: запросы должны «просто работать».

Решение

Первая версия, собранная на хакатоне, была классическим RAG: векторный поиск ближайших соседей по небольшому набору из 7 tier-1-таблиц и 20 эталонных SQL-запросов, из которых в промпт подтягивались 3 таблицы и 7 примеров, плюс инструкции с уберовской спецификой (обработка дат, бизнес-термины). Прототип доказал спрос, но на реальном разнообразии вопросов и таблиц точность падала — и следующие двадцать с лишним итераций превратили «один промпт с RAG» в конвейер специализированных агентов.

Первый структурный ход — «workspaces»: курируемые наборы таблиц и SQL-примеров под конкретный бизнес-домен. В проде — более 12 системных workspace (Mobility, Core Services, Platform Engineering, IT, Ads и другие), плюс возможность создавать кастомные под узкие задачи. Курирование — ручная работа доменных экспертов, и именно она, а не модель, даёт основной прирост точности: поиск идёт не по всей платформе, а по заранее осмысленному подмножеству.

Дальше вопрос проходит конвейер. Intent Agent классифицирует запрос по бизнес-доменам и выбирает workspace, сужая радиус поиска RAG. Table Agent подбирает конкретные таблицы — и показывает список пользователю, который может подтвердить его или поправить: этот human-in-the-loop-шаг команда добавила после жалоб на неверный выбор таблиц. Column Prune Agent выбрасывает из схем нерелевантные колонки — это решило проблему токенов: даже со 128-тысячным окном GPT-4 Turbo (модель 1106) полные схемы были дороги и медленны, а после обрезки существенно упали и задержка, и стоимость вызовов. Отдельный «prompt enhancer» обогащает скупые пользовательские формулировки контекстом до подачи в генерацию.

Против галлюцинаций (несуществующие таблицы и колонки — главный режим отказа) работают итеративный чат-режим, в котором пользователь уточняет запрос, и эксперименты с валидационным агентом, который рекурсивно находит и чинит ошибки в сгенерированном SQL.

Особого внимания заслуживает система оценки. Команда собрала «золотой» набор пар вопрос→SQL из реальных логов сервиса по разным доменам и гоняет его в двух режимах: Vanilla (полный путь от вопроса до SQL) и Decoupled (интент и таблицы подставлены заранее — чтобы мерить компоненты изолированно). Сигналы: точность интента, пересечение выбранных таблиц с эталоном (0–1), успешность исполнения запроса, возврат непустого результата и LLM-оценка похожести на эталонный SQL. Отдельная находка: прогоны оценки недетерминированы, разница до ~5% между запусками без изменений кода — поэтому команда смотрит на паттерны ошибок за длинные периоды, а не на колебания метрики.

Результат

QueryGPT выдаёт достаточно надёжные запросы примерно за 3 минуты вместо ~10 минут ручного написания — экономия около 70% времени на каждом запросе. В режиме ограниченного релиза сервисом пользуются порядка 300 активных пользователей в день, и 78% из них говорят, что сгенерированные запросы сокращают время, которое они потратили бы на написание вручную. На объёме платформы в 1,2 миллиона запросов в месяц потенциал масштабирования очевиден — но команда сознательно раскатывает сервис постепенно и в опубликованных выводах прямо называет выбор правильной стартовой аудитории (персон) отдельным уроком: начинать нужно там, где польза максимальна, а требования к SQL типовые, — с операционных команд, а не с дата-инженеров, которым черновик от LLM нужен меньше всего.

Не менее важны опубликованные выводы команды. Первый: LLM отлично работают как классификаторы на узких задачах — конвейер специализированных агентов (интент → таблицы → колонки) стабильно бьёт один большой промпт. Второй: пользовательский вопрос сам по себе — недостаточный вход для генерации; его нужно обогащать контекстом до вызова модели. Третий: множественность правильных ответов (один и тот же вопрос корректно решается разными таблицами и стилями SQL) делает автоматическую оценку принципиально нечёткой — отсюда LLM-судья и визуальное сравнение с эталоном вместо бинарного «совпало/не совпало».

Важно понимать рамку цифр: 10 и 3 минуты — оценки команды Uber; 78% — самоотчёт пользователей, а не замер по таймеру; сервис на момент публикации — в ограниченном релизе. Uber не публикует ни точность генерации в процентах, ни финансовый эффект — и, на наш взгляд, это честнее, чем экстраполяции сторонних блогов, дорисовывающих кейсу сотни тысяч сэкономленных часов.

На наш взгляд, главный переносимый урок QueryGPT в том, что text-to-SQL в проде — это на 20% модель и на 80% контекст-инжиниринг: курируемые доменные workspace, обрезка схем, обогащение промпта и дисциплина оценки на золотом наборе. Всё это переносимо в любую компанию с большой дата-платформой — и не требует ни своей модели, ни уберовских масштабов. Второй урок — темп: от хакатона до продакшена прошло больше года и 20+ итераций. Команды, ожидающие, что text-to-SQL «заработает за спринт», недооценивают именно длинный хвост доменной настройки, а не сложность LLM.

Уроки для индустрии

1. Text-to-SQL в проде — это конвейер специализированных агентов (интент → таблицы → колонки), а не один большой промпт: LLM надёжнее всего работают как классификаторы узких задач.
2. Курируемые workspaces с примерами SQL по доменам дали больше точности, чем попытки скормить модели всю схему целиком: главная инвестиция — ручное курирование доменными экспертами.
3. Обрезка схемы (Column Prune) — одновременно про точность и про стоимость: меньше токенов — дешевле, быстрее и лучше; даже 128K-окно не отменяет экономию контекста.
4. Пользовательский ввод нельзя подавать в модель как есть: реальные вопросы — от развёрнутых до пяти слов с опечатками, и «prompt enhancer» перед генерацией обязателен.
5. Human-in-the-loop в правильном месте: подтверждение выбора таблиц пользователем добавили по итогам реальных жалоб — это дешёвый шаг, снимающий главный источник ошибок.
6. Оценка — на «золотом наборе» из реальных логов с изолированным измерением компонентов; и помните о недетерминированности LLM-оценок (~5% между прогонами) — смотрите на паттерны, а не на колебания.
7. Честная формулировка качества — «достаточно надёжный черновик за 3 минуты», а не «идеальный SQL»: человек остаётся ревьюером, и это условие доверия, а не слабость продукта.

Частые вопросы