Материал подготовлен автоматически по первоисточникам: ссылки на них — в конце статьи.
Систему, которая переводит вопросы на естественном языке в SQL, научили сохранять точность при смене диалекта базы данных. В препринте IBM Research и ETH Zurich, который не прошёл рецензирование и где замеры выполнили сами авторы, портативность решения с планами запросов составила не менее 0,96. Командам с несколькими базами предлагают отделить понимание вопроса от генерации исполняемого SQL.
Модель строит дерево операций, а не строку SQL
Обычная text-to-SQL-система сразу выдаёт запрос в синтаксисе конкретной базы. Модель, обученная на SQLite, запоминает названия функций, правила приведения типов, обработку NULL и другие особенности этого диалекта. При переходе на PostgreSQL, MySQL или ClickHouse часть запросов перестаёт выполняться либо меняет смысл.
В новой схеме модель выдаёт план запроса: дерево из чтения таблиц, фильтров, соединений, группировок, проекций и сортировок. План сериализуется в JSON и не содержит синтаксиса конкретной базы. Детерминированный компилятор на базе Apache Calcite превращает его в нужный вариант SQL.
Компилятор отвечает не только за кавычки и названия функций. Он добавляет явное приведение типов, согласует порядок NULL, заменяет чувствительное к регистру сравнение и воспроизводит более мягкие правила SQLite там, где PostgreSQL завершил бы запрос ошибкой. Поэтому знания о диалектах хранятся в проверяемом коде, а не распределяются между весами моделей и примерами в подсказке.
Конвейер работает и в обратную сторону. Эталонный SQL сначала преобразуется в логический план, на котором можно обучать модель, а затем снова компилируется для выбранной базы. При таком круговом преобразовании запросы сохранили смысл в 94–97% случаев в зависимости от диалекта и набора задач.
Результаты сравнивали с учётом порядка и ничьих
Стандартная метрика BIRD-EA считает результаты равными, если совпадают множества строк. Она игнорирует порядок и повторения, поэтому может принять неверный ответ на просьбу ранжировать клиентов. Обратная ошибка возникает при ничьей: две базы могут вернуть разных клиентов с одинаковым максимальным оборотом, хотя оба ответа верны.
Авторы ввели DF-Match, который сначала определяет по вопросу, важны ли порядок и число строк. Для ранжированных ответов он сравнивает позиции, но разрешает переставлять строки с одинаковым значением сортировки. Если ограничение результата проходит через группу с равными значениями, метрика принимает любой допустимый вариант на границе.
Это существенно для проверки переносимости. Иначе различия в порядке строк можно ошибочно записать в дефекты компилятора или модели. Однако надёжность DF-Match зависит от того, правильно ли отдельный классификатор понял требования вопроса; его проверяли одним разметчиком на случаях, где две метрики расходились, поэтому результат такой проверки стоит считать ориентиром.
Архитектуру стоит менять при нескольких базах
При прямой генерации SQL точность на худшем диалекте отставала от SQLite до 17 процентных пунктов. С планом запроса разрыв сократился до 2,3 пункта. Масштаб модели сам по себе проблему не устранил: SQL оставался привязан к диалекту и у крупных систем.
Без специального обучения план оказался более сложным форматом для малых и средних моделей. Перелом наступал примерно около 68B параметров: выше этой границы худший результат по диалектам сравнивался с прямой генерацией SQL или превосходил её. Основной лишний класс ошибок составлял некорректный JSON, а не неверно выбранные таблицы, фильтры или группировки.
Дообучение меняет этот выбор. При одинаковых данных и вычислительном бюджете Ministral-3-8B, обученный на планах, получил на SQLite 64,5% против 61,2% у варианта, обученного на SQL, и сохранил переносимость между базами. Это делает планы практичным целевым форматом даже для сравнительно небольшой модели, если команда готова готовить обучающие примеры.
Работу проверяли на разделах для разработки BIRD и Spider с английскими вопросами и эталонными запросами SQLite. В испытания вошли модели разных семейств и четыре открытые базы: SQLite, PostgreSQL, MySQL и ClickHouse. Snowflake и BigQuery в этот контур не входили, поэтому перенос результата на облачные хранилища потребует отдельной реализации диалекта и проверки преобразований.
Для продукта с одной базой и небольшой моделью прямой SQL остаётся более простой схемой. Если система должна работать с несколькими движками или поддерживать смену базы, план запроса меняет архитектурный выбор: модель отвечает за смысл, а диалект становится задачей компилятора. Новый движок тогда требует доработать один детерминированный слой, а не переобучать генератор и собирать для него отдельный корпус SQL.
Источники
Похоже на вашу задачу?
Расскажите, что собираете. За полчаса разложим на этапы и назовём сроки — это бесплатно и ни к чему не обязывает.
