Превратить вопрос человека в корректный SQL — задача на удивление непростая. Большие языковые модели хорошо пишут валидный синтаксис, но легко промахиваются в логике: путают таблицы, соединяют не тем ключом, забывают 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 снижает ошибки: без него точность падала примерно на 5%.
-
Направляемая коррекция по таксономии — ключ к устойчивости: отключение этой петли давало до –10% точности на тех же данных.
-
Сильные reasoning‑модели (например, Claude Opus) особенно важны в ролях, где нужно понимать схему и планировать. Для механической генерации SQL можно использовать более дешевые модели — это позволяет снизить цену, почти не теряя в качестве.
Практика и стоимость
Запуск на полном Spider на сильной модели занял около пяти часов и стоил примерно 42–44 доллара при нулевой температуре. Гибридный режим — дорогую модель на схеме и планировании, дешевую на черновом SQL и финальной правке — дал ощутимую экономию и около 85% точности на пробной выборке. Да, из-за мультиагентности дольше контекст, больше запросов к API. Но здесь это окупается стабильностью.
Что работает, а что нет
-
Работает: сначала подумать, потом писать SQL. Явный план по шагам дисциплинирует модель и снижает галлюцинации.
-
Работает: корректировать с пояснением, какой именно тип ошибки произошел. Так меньше бесполезных повторов.
-
Не сработало: просто пересылать длинный список ошибок напрямую в агент генерации — лучше сначала обновить план и только потом править SQL. Также не помогло поднимать температуру или заводить множество независимых «ремонтников»: возникает конфликт правок и больше шума.
Где узкие места и что дальше
Пока что оценка ограничена семейством Spider, а таксономия не проверена на всех типах корпоративных схем. Система опирается на закрытые рассуждающие модели, что влияет на цену. Зрелым выглядит путь к дообучению более компактных моделей под конкретные роли: связывание со схемой и стратегия исправлений. Авторы прямо намекают на такой план: собрать корпус типичных ошибок и научить небольшой помощник быстро диагностировать и править.
Почему это важно
SQL-of-Thought аккуратно показывает простой принцип: структурированное рассуждение плюс понятная обратная связь побеждают голую перегенерацию по сигналам исполнения. В мире, где доступ к данным всё чаще идет через естественный язык, нам нужны системы, которые не только пишут валидный код, но и объясняют себе, что именно делают — и почему это нужно исправить.
***
Если вам интересна тема ИИ, подписывайтесь на мой Telegram-канал – там я регулярно делюсь инсайтами по внедрению ИИ в бизнес, запуску ИИ-стартапов и объясняю, как работают все эти ИИ-чудеса.
Автор: andre_dataist
