Почему Text-to-SQL до сих пор ломается и как это исправить

Превратить вопрос человека в корректный SQL — задача на удивление непростая. Большие языковые модели хорошо пишут валидный синтаксис, но легко промахиваются в логике ^[1]: путают таблицы, соединяют не тем ключом, забывают ^[2] GROUP BY, ставят неправильные фильтры. Простая самокоррекция по факту выполнения помогает не всегда: запрос может успешно выполниться и даже вернуть что-то осмысленное, но не то, что спрашивал пользователь. Авторы работы SQL-of-Thought предлагают лечить не симптомы, а причину: дать модели структуру рассуждения и понятный словарь ошибок, чтобы править запрос не вслепую.

Как устроен SQL‑of‑Thought

Идея — разбить путь от вопроса к SQL на несколько ролей и заставить модели думать пошагово.

Конвейер включает:

• привязку к схеме базы: выделяем релевантные таблицы, колонки, связи;

• разбиение задачи на WHERE, JOIN, GROUP BY, ORDER BY и так далее;

• план запроса на естественном языке: цепочка рассуждений, которая объясняет, какие данные и как извлекаем;

• генерацию SQL по плану;

• направляемую коррекцию: если результат не совпал с эталоном, система не просто перегенерирует запрос, а сверяется с таксономией ошибок и строит план исправления.

Это не один умный промт, а мультиагентная система: разные роли можно выполнять разными моделями, подбирая баланс между качеством и стоимостью.

Зачем нужна таксономия ошибок

Ключевая новинка — явная классификация промахов модели. Авторы расширяют существующую таксономию до 9 категорий и 31 подтипа: от проблем со схемой и соединениями до агрегаций, подзапросов и операций над множествами. Когда запрос дал неверный ответ, агент коррекции не гадает, а формулирует диагноз: например, «не хватает соединения по внешнему ключу» или «агрегация без соответствующего GROUP BY». Далее строится короткий план исправления и уже по нему — новая версия SQL. Такой контекст обучает модель исправлять именно логику.

Что показали эксперименты

Система проверена на классическом Spider и двух его сложных вариантах — Realistic (убраны явные названия колонок) и SYN (синонимизация вопросов). Главная метрика — Execution Accuracy: считаем совпадение результатов выполнения, а не точное текстовое соответствие SQL. Итоги впечатляют: 91.59% на Spider, 90.16% на Realistic, 82.01% на SYN — это лучше текущих публичных систем на тех же наборах.

А что дают отдельные компоненты:

• Пошаговый план перед SQL снижает ошибки ^[3]: без него точность падала примерно на 5%.

• Направляемая коррекция по таксономии — ключ к устойчивости: отключение этой петли давало до –10% точности на тех же данных.

• Сильные reasoning‑модели (например, Claude Opus) особенно важны в ролях, где нужно понимать схему и планировать. Для механической генерации SQL можно использовать более дешевые модели — это позволяет снизить цену, почти не теряя в качестве.

Практика и стоимость

Запуск на полном Spider на сильной модели занял около пяти часов и стоил примерно 42–44 доллара при нулевой температуре. Гибридный режим — дорогую модель на схеме и планировании, дешевую на черновом SQL и финальной правке — дал ощутимую экономию и около 85% точности на пробной выборке. Да, из-за мультиагентности дольше контекст, больше запросов к API. Но здесь это окупается стабильностью.

Что работает, а что нет

• Работает: сначала подумать, потом писать SQL. Явный план по шагам дисциплинирует модель и снижает галлюцинации.

• Работает: корректировать с пояснением, какой именно тип ошибки произошел. Так меньше бесполезных повторов.

• Не сработало: просто пересылать длинный список ошибок напрямую в агент генерации — лучше сначала обновить план и только потом править SQL. Также не помогло поднимать температуру или заводить множество независимых «ремонтников»: возникает конфликт ^[4] правок и больше шума.

Где узкие места и что дальше

Пока что оценка ограничена семейством Spider, а таксономия не проверена на всех типах корпоративных схем. Система опирается на закрытые рассуждающие модели, что влияет на цену. Зрелым выглядит путь к дообучению более компактных моделей под конкретные роли: связывание со схемой и стратегия исправлений. Авторы прямо намекают на такой план: собрать корпус типичных ошибок и научить небольшой помощник быстро диагностировать и править.

Почему это важно

SQL-of-Thought аккуратно показывает простой принцип: структурированное рассуждение плюс понятная обратная связь побеждают голую перегенерацию по сигналам исполнения. В мире, где доступ к данным всё чаще идет через естественный язык, нам нужны системы, которые не только пишут валидный код, но и объясняют себе, что именно делают — и почему это нужно исправить.

📜 Полная статья ^[5]

***

Если вам интересна тема ИИ,  ^[6]подписывайтесь на мой Telegram-канал ^[7] – там я регулярно делюсь инсайтами по внедрению ИИ в бизнес, запуску ИИ-стартапов и объясняю, как работают все эти ИИ-чудеса.