Создание готовой к использованию системы преобразования текста в SQL: достигнут результат 88.15% на тестовом наборе данных Spider 1.0.

Для создания готовой к эксплуатации системы преобразования текста в SQL требуется гораздо больше, чем просто генерация SQL-запросов с помощью обширной языковой модели. Корпоративные приложения требуют точного понимания схемы, извлечения контекста, проверки и исправления ошибок для получения надежных результатов в ранее не встречавшихся базах данных.

В этом исследовании мы провели сравнительный анализ нашего Data Agent на Spider 1.0 и достигли точности выполнения 88.15% с использованием модели Gemma 4 26B . Вместо того чтобы сосредотачиваться исключительно на результатах сравнительного анализа, в этой статье рассматриваются архитектурные решения, инженерные уроки и выводы, полученные в ходе сравнительного анализа.

Крупные языковые модели значительно улучшили генерацию SQL-запросов, но для создания готовой к использованию системы преобразования текста в SQL требуется гораздо больше, чем просто перевод естественного языка в SQL. Корпоративные приложения должны понимать сложные схемы баз данных, получать необходимый контекст, проверять сгенерированные запросы и выдавать надежные результаты в базах данных, с которыми они никогда раньше не сталкивались.

Для оценки этих возможностей мы провели тестирование нашего Data Agent на Spider 1.0, наиболее широко используемом бенчмарке для преобразования текста в SQL. Используя модель Gemma 4 26B , наша система достигла точности выполнения 88.15% , что демонстрирует, что архитектура и управление контекстом так же важны, как и выбор модели.

Выбор правильного эталонного набора данных так же важен, как и выбор правильной модели. Хотя новые наборы данных, такие как Spider 2.0 и BIRD, представляют более сложные корпоративные сценарии, Spider 1.0 остается наиболее широко используемым эталонным набором данных для оценки систем преобразования текста в SQL и сравнения результатов в различных исследованиях.

Для первоначальной оценки мы выбрали Spider 1.0, поскольку он предоставляет стандартизированную и хорошо зарекомендовавшую себя базовую модель. Он позволяет нам измерить, насколько эффективно наш агент данных понимает ранее неизвестные схемы баз данных и генерирует корректный SQL в реалистичных условиях.

На рисунке 2 представлено сравнение результатов Spider 1.0 с другими широко используемыми тестами преобразования текста в SQL.

Достижение высокой точности преобразования текста в SQL — это не просто вопрос использования более крупной языковой модели. В ходе нашего сравнительного анализа мы обнаружили, что архитектура и управление контекстом оказывают большее влияние на производительность, чем просто выбор модели.

Наш агент обработки данных разработан как многоступенчатый конвейер, который постепенно сужает круг задач, прежде чем запросить у LLM генерацию SQL-запроса. Вместо того чтобы предоставлять модели всю схему базы данных, система сначала извлекает только необходимую информацию о схеме и контексте, затем генерирует SQL-запрос, проверяет результат и автоматически исправляет распространенные ошибки перед выполнением.

Как показано на рисунке 3 , архитектура состоит из трех основных этапов:

• Поиск информации – Вопрос пользователя анализируется для выявления соответствующих объектов базы данных, и из хранилища метаданных извлекается только необходимая информация о схеме.
• Самоочищающийся агент – Языковая модель генерирует SQL-запрос, проверяет его на соответствие полученной схеме и автоматически уточняет его в случае сбоя проверки.
• Выполнение и реагирование – После проверки SQL-запрос выполняется к целевой базе данных, и результаты возвращаются в виде структурированных данных или ответа на естественном языке.

Эта ориентированная на производство архитектура вдохновлена ​​идеями, представленными в DIN-SQL и DAIL-SQL , и адаптирована для корпоративных сред, где надежность, объяснимость и отказоустойчивость так же важны, как и точность эталонных показателей.

Выбор правильной языковой модели был важной частью нашего процесса сравнительного анализа. Вместо того чтобы оценивать одну единственную модель, мы экспериментировали с широким спектром языковых моделей с открытым исходным кодом, включая Llama 3.1, Qwen 2.5, DeepSeek, SQLCoder, CodeGemma, Mistral, GPT-OSS и Gemma 4.

Для обеспечения объективности сравнения мы оценивали каждую модель, используя показатель точности выполнения (Execution Accuracy, EA) , стандартную метрику для бенчмаркинга преобразования текста в SQL. В отличие от метрик, основанных на синтаксисе, точность выполнения измеряет, возвращает ли сгенерированный SQL тот же результат, что и эталонный запрос, что делает его лучшим индикатором реальной производительности.

Наш процесс бенчмаркинга проиллюстрирован на рисунке 4. Мы начали с экспериментов на локальной рабочей станции, оснащенной RTX 4060 (8 ГБ видеопамяти) , где использование моделей меньшего размера позволило нам быстро вносить изменения и проверять наш конвейер. После установления стабильного базового уровня с использованием подмножества из 233 вопросов Spider 1.0, мы перешли к облачным графическим процессорам для оценки более крупных моделей на полном бенчмарке из 2,147 вопросов . Такой поэтапный подход позволил нам эффективно оптимизировать архитектуру, прежде чем инвестировать в крупномасштабные бенчмарк-запуски.

Мы оценили финальные модели на полной тестовой выборке Spider 1.0, содержащей 2,147 вопросов. Как показано в таблице 1, Gemma 4 26B показала наивысший результат (88.15%), за ней следует GPT-OSS 20B (86.63%). Эти результаты демонстрируют, что современные модели LLM с открытым исходным кодом в сочетании с эффективным конвейером поиска и проверки могут обеспечить высококонкурентную производительность преобразования текста в SQL. 

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

Таблица 2: Показатели точности моделей с закрытым исходным кодом, представленные в исследовании SQL-of-Thought на подмножестве набора данных Spider; в сравнительном плане видно, что результат 88.15%, полученный в данной работе, находится выше, чем у GPT-4o Mini (87%), и близок к уровню GPT-5 (89%).

В недавних работах, таких как SQL-of-Thought [1], сообщается, что ведущие модели с закрытым исходным кодом, включая Claude Opus 3, GPT-5 и GPT-4o Mini , достигают высокой точности на подмножествах бенчмарка Spider. Хотя прямые сравнения следует интерпретировать с осторожностью из-за различий в настройках оценки, подсказках и подмножествах бенчмарка, наша точность выполнения 88.15% демонстрирует, что модели с открытым исходным кодом могут достигать производительности в том же конкурентном диапазоне.

Хотя эти результаты получены в разных условиях оценки и не должны сравниваться напрямую, они предоставляют полезный контекст для понимания текущей ситуации с производительностью систем преобразования текста в SQL. Наш бенчмарк демонстрирует, что модели с открытым исходным кодом теперь могут конкурировать с ведущими альтернативами с закрытым исходным кодом при условии использования хорошо спроектированной архитектуры.

Мы также сравнили наши результаты с ориентированными на производство фреймворками Text-to-SQL, такими как DIN-SQL [3] и DAIL- SQL, которые объединяют большие языковые модели с такими методами, как связывание схем, разработка подсказок, самосогласованность и исправление ошибок.

Таблица 3: Результаты точности выполнения различных методов на Spider 1.0 в исследовании «Преобразование текста в SQL с использованием больших языковых моделей: сравнительная оценка» [2]; она показывает влияние на точность не только выбора модели, но и таких методов, как разработка подсказок, связывание схем и самосогласованность.

Наши результаты подтверждают вывод, разделяемый в недавней литературе: высокая производительность преобразования текста в SQL зависит не только от языковой модели, но и от окружающей архитектуры. Эффективное извлечение схемы, управление контекстом, проверка и самокоррекция зачастую так же важны, как и сама модель.

Бенчмаркинг — это не только измерение точности, но и понимание того, где и почему система дает сбой. В ходе нашей оценки мы проанализировали неверные прогнозы и выявили несколько повторяющихся закономерностей, которые повлияли на итоговые результаты.

Некоторые ошибки возникли из-за особенностей самого теста. В небольшом числе случаев несоответствия в эталонных (золотых) SQL-запросах приводили к тому, что логически правильные прогнозы помечались как неверные. Другие случаи касались неоднозначных вопросов на естественном языке или ситуаций, когда несколько SQL-запросов могли законно давать одинаково корректные ответы.

Мы также наблюдали ряд специфических для модели особенностей поведения, включая ненужные преобразования типов, непоследовательную обработку регистра символов и периодическое чрезмерное усложнение простых SQL-запросов. Эти результаты подтвердили важность включения механизмов проверки и самокоррекции в конвейер обработки данных Data Agent.

В целом, наш анализ показал, что многие оставшиеся ошибки были вызваны не ограничениями самой языковой модели, а неоднозначностями в эталонном тесте или граничными случаями при генерации SQL-запросов. Это говорит о том, что дальнейшие улучшения в извлечении, проверке и управлении контекстом могут вывести систему за пределы порога точности выполнения в 90%.

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

Одним из ключевых преимуществ нашего подхода является то, что он полностью основан на языковых моделях с открытым исходным кодом. На протяжении всего процесса разработки мы могли проводить большинство экспериментов локально, используя потребительскую видеокарту RTX 4060 (8 ГБ видеопамяти) , что позволило нам быстро вносить изменения без каких-либо затрат на API или токены. Более масштабные тесты производительности затем выполнялись на выделенных облачных графических процессорах только после проверки архитектуры.

Для полной оценки Spider 1.0 мы использовали RunPod Secure Cloud. Тест Gemma 4 26B выполнялся на графическом процессоре A100 PCIe 80 ГБ, а GPT-OSS 20B — на графическом процессоре RTX 6000 48 ГБ.

Затраты на инфраструктуру суммированы в таблице 4.

Хотя для проведения самых масштабных сравнительных тестов требовалась облачная инфраструктура, общий процесс разработки оставался экономически эффективным благодаря локальным экспериментам и моделям с открытым исходным кодом. Что еще важнее, полученная архитектура может быть полностью развернута в собственной инфраструктуре организации, что исключает зависимость от внешних API и обеспечивает больший контроль над конфиденциальностью данных, соответствием нормативным требованиям и операционными расходами.

Благодаря этому архитектура особенно хорошо подходит для организаций, работающих в условиях повышенной конфиденциальности, регулирования или изоляции сети, где безопасность данных и гибкость развертывания являются критически важными требованиями.

Бенчмарки предоставляют объективный способ оценки систем искусственного интеллекта, но они не являются конечной целью. Высокий балл бенчмарка ценен только в том случае, если он обеспечивает надежную работу в реальных приложениях.

В ходе этого исследования мы обнаружили, что создание готовой к использованию системы преобразования текста в SQL — это гораздо больше, чем просто генерация SQL-запросов. Понимание схем баз данных, получение необходимого контекста, проверка сгенерированных запросов и исправление некорректных результатов оказались столь же важными, как и сама языковая модель.

Наша точность выполнения 88.15% на Spider 1.0 демонстрирует, что модели с открытым исходным кодом в сочетании с хорошо продуманной архитектурой могут обеспечить высококонкурентную производительность для корпоративных задач преобразования текста в SQL. Что еще важнее, это подтверждает принципы проектирования нашего Data Agent , который был создан для надежной работы со сложными корпоративными базами данных, а не только с эталонными наборами данных.

Spider 1.0 представляет собой важную веху, но это только начало нашего пути. Наши следующие шаги включают оценку Data Agent на Spider 2.0 , более масштабные сравнительные тесты в масштабах предприятия и, что наиболее важно, работу в реальных клиентских средах, где схемы баз данных значительно больше, а бизнес-задачи гораздо сложнее.

Наша долгосрочная цель — не просто создать более совершенный генератор SQL-запросов. Мы стремимся разработать интеллектуальных агентов данных, которые позволят организациям взаимодействовать с корпоративными данными так же естественно, как они общаются с коллегами, объединяя поиск, рассуждения, проверку и объяснимый ИИ в надежную платформу поддержки принятия решений.

Бенчмаркинг — это не только измерение точности, но и понимание причин успеха или неудачи системы.

В ходе нашего исследования мы выявили несколько повторяющихся моделей ошибок. Некоторые из них возникли из-за неоднозначностей в самом бенчмарке, включая несоответствия в эталонных SQL-запросах и недостаточно четко определенные условия упорядочивания. Другие отражали типичное поведение LLM, такое как ненужное приведение типов или непоследовательная обработка значений, чувствительных к регистру.

Эти наблюдения подтвердили один из главных выводов нашей работы: архитектура имеет такое же значение, как и выбор модели. Поиск, связывание схем, проверка и самокоррекция вносят такой же вклад в конечную производительность, как и базовая языковая модель.

Хотя ограничения, установленные в бенчмарке, неизбежно влияют на итоговый результат, наш анализ показывает, что дальнейшее улучшение управления контекстом и проверки может вывести систему за пределы 90% точности выполнения.

Spider 1.0 послужил важной отправной точкой для оценки нашего агента обработки данных, но он представляет собой лишь первый шаг к созданию готового к внедрению корпоративного ИИ.

Далее мы сосредоточимся на оценке архитектуры на более сложных тестовых задачах, таких как Spider 2.0 , и, что более важно, на реальных корпоративных базах данных, где схемы значительно больше, документация часто неполная, а бизнес-вопросы гораздо сложнее.

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

Референсы

[1] Саумья Чатурведи, Аман Чадха, Лоран Биндшадлер arXiv. «SQL-of-Thought: Многоагентный текст-в-SQL с управляемой коррекцией ошибок». arXiv. Июнь 2026 г. https://arxiv.org/abs/2509.00581

[2] Давэй Гао, Хайбинь Ван, Ялян Ли, Сююй Сунь, Ичен Цянь, Болин Дин, Цзинжэнь Чжоу «Преобразование текста в SQL на базе больших языковых моделей: контрольная оценка» arXiv. июнь 2026 г.

https://arxiv.org/pdf/2308.15363 

[3] Мохаммадреза Пурреза, Давуд Рафией. «DIN-SQL: декомпозированное контекстное обучение преобразования текста в SQL с самокоррекцией» arXiv. Июнь 2026 г.

https://arxiv.org/pdf/2304.11015

Dilşen YILDAR HAVAYLAR, 

Старший инженер-программист, магистр наук.