DIN-SQL: Декомпозоване навчання в контексті для Text-to-SQL

Минулого тижня я розповідав про BIRD — бенчмарк, який показав, наскільки сильно помиляються LLM, коли завдання text-to-SQL переходить від ретельно підібраних іграшкових баз даних до реальних схем із заплутаними назвами, специфічними знаннями предметної області та обмеженнями ефективності. DIN-SQL — це стаття, яку мені варто було прочитати першою: вона визначила, чого насправді може досягти ретельно декомпозований конвеєр промптів для LLM на Spider та BIRD. Вона була представлена на NeurIPS 2023 Мохаммадрезою Пуррезою та Давудом Рафіеї якраз тоді, коли GPT-4 став загальнодоступним. Читання її зараз — після того, як BIRD оголив межі можливостей — дозволяє набагато чіткіше побачити сильні сторони та обмеження.

Стаття

DIN-SQL (arXiv:2304.11015) вирішує значний розрив у продуктивності. На початку 2023 року найкращі донавчені моделі — RESDSQL-3B+NatSQL — досягли 79,9% точності виконання на тестовому наборі Spider, тоді як GPT-4 з наївним few-shot промптингом показав лише 67,4% на наборі для розробки (dev set). Гіпотеза Пуррези та Рафіеї полягає в тому, що цей розрив є переважно проблемою інтерфейсу: 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, до чого я ще повернуся.

Що підтверджується, а що — ні

Основний результат є реальним. Декомпозиція text-to-SQL на чіткі підзавдання покращує продуктивність, а абляційні дослідження достатньо переконливі, щоб повірити у внесок кожного окремого модуля. Прив’язка до схеми має найбільше значення для складних запитів, що логічно: модель не може згенерувати правильні JOIN, якщо вона спочатку не ідентифікувала правильно, на які таблиці та стовпці посилається питання.

Проте кілька речей змушують замислитися. Розбіжність між 74,2% на dev-наборі та 85,3% на тестовому виглядає підозріло. Набори для розробки зазвичай складніші або принаймні такі ж складні, як тестові, оскільки моделі неявно налаштовуються під них; стрибок у +11 пунктів при переході від dev до test є незвичним. Автори не пояснюють це, і це змушує мене задуматися, чи має тестовий набір інший розподіл складності запитів, чи є щось особливе в оцінці тестового набору (через офіційний сервер Spider), що відрізняється від їхньої власної оцінки. Я б не цитував 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:US:Checking:Bank, а релевантна схема залежить від того, який тип запиту робить користувач (звіт про прибутки та збитки, балансовий звіт, рух грошових коштів). Модуль класифікації DIN-SQL підказує пряму адаптацію: спочатку класифікувати інтент запиту (баланс проти потоку чи пошуку ціни), а потім спрямовувати до різних шаблонів промптів.

Висновки бенчмарку BIRD про те, що неідеальність реального світу шкодить LLM у завданнях text-to-SQL, безпосередньо стосуються нас. Леджер Beancount також «заплутаний» — назви рахунків, визначені користувачем, непослідовні символи валют, кастомні ключі метаданих. Покращення на 4,4 пункти в BIRD проти 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 і є найбільш агентно-орієнтованим підходом у цій галузі.