Материал подготовлен автоматически по первоисточникам: ссылки на них — в конце статьи.
Ritesh Kumar представил text2ql — открытый Python-фреймворк для преобразования естественного языка в запросы к данным; работа описана в препринте, не проходившем рецензирования. По замерам автора, детерминированный режим оказался быстрее режима с LLM и не требует внешнего API во время запроса. Это важно командам, которым одновременно нужны SQL и GraphQL, автономная работа или управляемое переключение между правилами и LLM.
Что сделали
В основе text2ql находится типизированное промежуточное представление QueryIR. Оно хранит сущность, выбираемые поля, фильтры, агрегаты, связи, сортировку и разбиение результата на страницы, но не определяет окончательный синтаксис запроса. Отдельные модули визуализации превращают один объект QueryIR в SQL или GraphQL.
Такое разделение меняет границу ответственности компонентов. Модуль разбора отвечает за интерпретацию пользовательской фразы и построение структуры запроса. Модуль визуализации знает правила целевого языка: например, как записать JOIN и GROUP BY в SQL либо вложенную выборку в GraphQL. По утверждению автора, новый целевой язык можно добавить отдельным модулем без изменения механизма разбора.
Детерминированный режим последовательно определяет сущность, поля, фильтры, агрегаты, связи, сортировку и ограничения результата. Для этого он использует конфигурацию схемы: имена таблиц и полей, деловые синонимы, допустимые значения фильтров, связи и маршрутизацию предметных выражений. Например, термин из интерфейса продукта можно заранее сопоставить с конкретным полем базы данных.
В режиме с LLM та же схема включается в запрос к модели. При использовании структурированного вывода модель возвращает объект, соответствующий QueryIR, а не готовую строку SQL. Если проверка объекта не проходит, text2ql может перейти к детерминированному результату.
Каждому результату присваивается оценка уверенности. Она складывается из заранее заданных сигналов: качества определения сущности, покрытия полей, наличия фильтров и связей. Ошибки проверки уменьшают оценку. Это не вероятность корректности, полученная из статистической калибровки, а эвристический показатель для маршрутизации: принять результат правил или передать запрос LLM.
Что показали
На выбранных авторами примерах детерминированный режим достиг 100% точности выполнения: результат выполнения сгенерированного запроса совпадал с эталоном. Медианная задержка составила 3,2 мс без обращения к API.
Режим с gpt-4o-mini показал 84–91% точности выполнения и 62–70% точного совпадения. Точное совпадение здесь означает соответствие сгенерированной записи эталонной записи, поэтому показатель штрафует за другой порядок полей или эквивалентную, но иначе записанную конструкцию.
Добавление полной конфигурации схемы в запрос к LLM повысило точное совпадение на 18,4 процентного пункта относительно варианта без схемы. По замерам автора, описание предметной области и синонимов дало больший эффект, чем одно перечисление сущностей.
У детерминированного режима не было ни одного точного совпадения с эталонной строкой, хотя все запросы прошли проверку выполнением. Это показывает не только особенность генератора, но и расхождение между двумя метриками: канонически оформленный запрос может отличаться от эталонного текста и при этом возвращать тот же результат.
Ограничения
Автор проверял систему на случайных выборках по 50 запросов из Spider и BIRD, а не на полных наборах. Все эксперименты с LLM проводились на gpt-4o-mini без дообучения и индивидуального подбора примеров. Поэтому результаты не показывают, как система ведёт себя с другими моделями, крупными промышленными схемами и реальным потоком пользовательских формулировок.
Spider и BIRD содержат эталоны SQL. Для GraphQL автор проверял только соответствие сущностей и полей схеме: сравнения с эталонными GraphQL-запросами в работе нет. Также не проводилась экспертная оценка того, действительно ли запрос отвечает намерению пользователя, особенно при неоднозначных аналитических формулировках.
Детерминированный результат зависит от полноты конфигурации схемы и покрытия деловых синонимов. В текущем QueryIR не выражаются некоторые подзапросы и коррелированные условия. Оценка уверенности построена из вручную заданных весов, а её соответствие фактической корректности отдельно не проверялось.
Сравнение со специализированными системами преобразования текста в SQL основано на опубликованных ими показателях, полученных с другими моделями и условиями эксперимента. Прямого запуска конкурирующих решений на той же выборке автор не провёл.
Что это значит
Работа меняет архитектурный план, но пока не даёт оснований выбирать text2ql как готовую замену существующему контуру без собственного испытания. Практически полезная часть — граница между интерпретацией фразы, промежуточной моделью и генерацией целевого языка. Она позволяет не связывать предметную логику непосредственно с SQL, GraphQL или конкретным поставщиком LLM.
Для ограниченного словаря и стабильной схемы детерминированный режим можно рассматривать как основной путь, а LLM — как резерв для сложных формулировок. При этом конфигурация сущностей, связей и синонимов становится версионируемым компонентом продукта, который нужно проверять вместе с изменениями схемы.
Командам с открытыми аналитическими запросами результаты не позволяют отказаться от LLM: правила не покрывают часть сложных конструкций, а качество зависит от ручного описания предметной области. Перед использованием автоматического переключения режимов оценку уверенности следует сопоставить с корректностью на собственных запросах. Главный результат работы — не доказанное превосходство конкретного генератора, а проверяемая архитектурная гипотеза: один QueryIR может обслуживать несколько языков запросов и разные способы разбора.
Источники
Похоже на вашу задачу?
Расскажите, что собираете. За полчаса разложим на этапы и назовём сроки — это бесплатно и ни к чему не обязывает.
