DIN-SQL: декомпозированное обучение в контексте для преобразования текста в SQL

На прошлой неделе я рассказывал о BIRD, бенчмарке, который показал, насколько сильно ошибаются LLM, когда преобразование текста в SQL переходит от выверенных «игрушечных» баз данных к реальным схемам с неаккуратными именами, специфическими знаниями предметной области и ограничениями эффективности. DIN-SQL — это работа, которую мне следовало прочитать первой: в ней определено, чего может достичь тщательно декомпозированный конвейер промптов для LLM на Spider и BIRD. Она была представлена на NeurIPS 2023 Мохаммадрезой Пуррезой и Давудом Рафиеи как раз тогда, когда GPT-4 стал широко доступен. Чтение этой статьи сейчас — после того как BIRD выявил «потолок» возможностей — позволяет гораздо яснее увидеть сильные и слабые стороны подхода.

Статья

DIN-SQL (arXiv:2304.11015) устраняет резкий разрыв в производительности. В начале 2023 года лучшие дообученные (fine-tuned) модели — RESDSQL-3B+NatSQL — достигали точности выполнения 79,9% на тестовом наборе Spider, в то время как GPT-4 с простым обучением на нескольких примерах (few-shot prompting) показала лишь 67,4% на наборе для разработки. Гипотеза Пуррезы и Рафиеи заключается в том, что этот разрыв — в основном проблема интерфейса: LLM достаточно мощны, но генерация SQL за один проход требует от них одновременного решения задач связывания схем, классификации сложности и синтеза запроса. Разделите их на последовательные подзадачи и передавайте каждое решение в качестве контекста — и ситуация изменится.

Их конвейер состоит из четырех этапов: (1) модуль связывания схем (schema-linking), использующий промпты «цепочки рассуждений» (chain-of-thought) для сопоставления вопроса на естественном языке с конкретными столбцами и значениями в схеме; (2) модуль классификации и декомпозиции, который распределяет запросы по категориям: простые (одна таблица, без объединений), сложные невложенные (объединения, но без подзапросов) или сложные вложенные (объединения, подзапросы, операции над множествами), а для вложенных запросов разбивает задачу на подзапросы; (3) модуль генерации SQL, в котором стратегия промптов соответствует классу сложности: простой few-shot для легких запросов, промежуточное представление NatSQL для невложенных и многоэтапная цепочка рассуждений для вложенных; и (4) модуль самокоррекции, который просит модель проверить собственный вывод на предмет мелких ошибок, таких как пропущенный DISTINCT или неверно расположенный DESC.

Ключевые идеи

• GPT-4 + DIN-SQL достигает точности выполнения 85,3% на отложенном тестовом наборе Spider, что на 5,4 процентных пункта выше, чем у тогдашней SOTA дообученной модели RESDSQL-3B+NatSQL (79,9%), без каких-либо специфических обучающих данных для задачи.
• На Spider dev конвейер декомпозиции поднимает показатели GPT-4 с 67,4% (базовый few-shot) до 74,2% — чистый прирост в +6,8 пункта. CodeX Davinci вырос с 61,5% до 69,9%.
• Исследование абляции подтверждает вклад каждого этапа: удаление только связывания схем снижает показатель CodeX с 69,9% до 65,9%; удаление классификации снижает его еще больше — до 63,1%.
• Прирост сосредоточен в простых и средних запросах. На «особо сложных» запросах даже полный конвейер DIN-SQL + GPT-4 достигает лишь 43,4% на Spider dev — декомпозиция не решает проблему сложности как таковую, она просто уменьшает количество предотвратимых ошибок в решаемых запросах.
• Самокоррекция чувствительна к модели: GPT-4 реагирует на «мягкие» промпты, предлагающие найти возможные улучшения; CodeX лучше реагирует на «общие» промпты, в которых предполагается, что SQL неверен. Это говорит о том, что модуль выполняет стилистическую чистку, а не реальную семантическую проверку.
• На BIRD dev связка DIN-SQL + GPT-4 набирает 50,72% против 46,35% у базовой GPT-4 — улучшение на +4,4 пункта, что существенно меньше, чем на Spider. К этому я еще вернусь.

Что подтверждается — а что нет

Основной результат реален. Декомпозиция преобразования текста в SQL на явные подзадачи улучшает производительность, а исследования абляции достаточно чисты, чтобы поверить в вклад отдельных модулей. Связывание схем важнее всего для сложных запросов, что логично: модель не может создать правильные JOIN, если она сначала не определила правильно, к каким таблицам и столбцам относится вопрос.

Однако некоторые моменты заставляют задуматься. Расхождение в 74,2% на dev-наборе против 85,3% на тесте выглядит подозрительно. Наборы для разработки обычно сложнее или как минимум такие же сложные, как тестовые, потому что модели неявно подстраиваются под них; скачок в +11 пунктов при переходе от dev к test необычен. Авторы не объясняют этого, и возникает вопрос: отличается ли распределение сложности запросов в тестовом наборе или есть особенности оценки отложенного теста (через официальный сервер Spider leaderboard), которые отличаются от их оценки на dev-наборе. Я бы не стал цитировать 85,3% без этой оговорки.

Разрыв в BIRD (50,72% dev) заметно меньше, чем прирост в Spider. Базы данных BIRD имеют неаккуратные реальные схемы с сокращенными именами столбцов, специфической терминологией и неоднозначными значениями. Модуль связывания схем DIN-SQL разрабатывался с учетом относительно чистых схем Spider; когда схемы становятся «грязнее», точность связывания падает, а вместе с ней деградирует и остальная часть конвейера. Это именно то, что измерялось в статье о BIRD, и DIN-SQL это не решает.

Стоимость и задержка являются проблемой для любой продакшн-системы: примерно 0,50 доллара и 60 секунд на один вопрос с GPT-4. Это приемлемо для аналитика данных, выполняющего десять запросов в день, но совершенно непригодно для интерактивного использования. В статье это упоминается как известное ограничение, но не предлагается пути его решения. DAIL-SQL (arXiv:2308.15363), появившаяся несколько месяцев спустя, показала, что лучший подбор примеров, а не явная декомпозиция, позволяет достичь 86,6% на Spider, превосходя DIN-SQL при значительно меньших затратах.

Модуль самокоррекции — самое слабое звено. Авторы признают, что он отлавливает «мелкие» ошибки. Чего он не может, так это обнаруживать семантические ошибки — случаи, когда сгенерированный SQL синтаксически верен и даже выполняется, но отвечает не на тот вопрос. Это наиболее сложный сценарий отказа для реальных пользователей.

Почему это важно для финансового ИИ

Beanquery (BQL) — это SQL-подобный язык запросов к данным главной книги Beancount. У него своя структура таблиц — transactions, postings, balance, prices — с иерархией счетов, тегами и полями метаданных, которые совсем не похожи на обычные схемы баз данных. Интерфейс на естественном языке для BQL — вещь реальная и полезная (уже существует экспериментальный сервер beanquery-mcp, реализующий именно это через MCP), и стратегия декомпозиции DIN-SQL является подходящей отправной точкой.

Связывание схем в BQL — задача, аналогичная связыванию схем в реляционных таблицах, но с двумя дополнительными нюансами: имена счетов представляют собой иерархические пути типа Assets:RU:Checking:Bank, а релевантная схема зависит от того, какой запрос задает пользователь (отчет о прибылях и убытках, балансовый отчет, движение денежных средств). Модуль классификации DIN-SQL подсказывает прямую адаптацию: сначала классифицировать интент запроса (баланс против потока или поиск цены), а затем направлять его в соответствующие шаблоны промптов.

Вывод бенчмарка BIRD о том, что реальная «неаккуратность» вредит LLM при преобразовании текста в SQL, напрямую применим. Книга Beancount тоже бывает «неаккуратной» — пользовательские имена счетов, непоследовательные символы валют, кастомные ключи метаданных. Улучшение в BIRD на 4,4 пункта против 6,8 пункта в Spider говорит мне о том, что режим структурированных чистых схем переоценивает пользу декомпозиции для реальных запросов BQL. На практике стоит ожидать меньшего прироста.

Ценовое ограничение реально, но здесь оно менее критично. Пользователь, ведущий личные финансы и выполняющий 10–20 запросов в день, может смириться с затратами на API в 5–10 долларов в день, если интерфейс действительно полезен. Задержка (60 секунд) — большая проблема для интерактивного использования; пакетная обработка аналитических запросов могла бы помочь обойти ее.

Что почитать дальше

• DAIL-SQL: Text-to-SQL Empowered by Large Language Models: A Benchmark Evaluation (arXiv:2308.15363) — систематическое исследование стратегий промпт-инжиниринга; достигает 86,6% на Spider, фокусируясь на выборе примеров, а не на архитектурной декомпозиции; полезный контрапункт к DIN-SQL.
• RESDSQL: Decoupling Schema Linking and Skeleton Parsing for Text-to-SQL (arXiv:2302.05965, AAAI 2023) — дообученная базовая модель, которую превзошла DIN-SQL; понимание того, в чем хорош метод дообучения, проясняет, где промпты все еще уступают.
• MAC-SQL: A Multi-Agent Collaborative Framework for Text-to-SQL (arXiv:2312.11242) — расширяет идею многоэтапной декомпозиции до явного мультиагентного конвейера с Селектором, Декомпозитором и Рефайнером; достигает 59,59% на BIRD с GPT-4 и является наиболее агентно-ориентированным подходом в этой области.