Створення готової до виробництва системи перетворення тексту в 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, оскільки він забезпечує стандартизовану та добре встановлену базову модель. Він дозволяє нам виміряти, наскільки ефективно наш Data Agent розуміє раніше невідомі схеми баз даних та генерує правильний SQL-запит у реальних умовах.

На рисунку 2 підсумовано, як Spider 1.0 порівнюється з іншими поширеними тестами перетворення тексту в SQL.

Досягнення високої точності перетворення тексту в SQL не є просто питанням використання більшої мовної моделі. Протягом нашого процесу бенчмаркінгу ми виявили, що архітектура та управління контекстом мали більший вплив на продуктивність, ніж сам вибір моделі.

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

Як показано на рисунку 3 , архітектура складається з трьох основних етапів:

• Пошук інформації – Запитання користувача аналізується для визначення відповідних об’єктів бази даних, і зі сховища метаданих витягується лише необхідна інформація про схему.
• Самоочисний агент – Мовна модель генерує SQL, перевіряє запит на відповідність отриманій схемі та автоматично уточнює його щоразу, коли перевірка не вдається.
• Виконання та відповідь – Після перевірки SQL-запит виконується до цільової бази даних, а результати повертаються у вигляді структурованих даних або відповіді природною мовою.

Ця орієнтована на виробництво архітектура натхненна ідеями, представленими в DIN-SQL та DAIL-SQL , але адаптована для корпоративних середовищ, де надійність, зрозумілість та стійкість є такими ж важливими, як і точність еталонів.

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

Щоб забезпечити справедливе порівняння, ми оцінили кожну модель за допомогою точності виконання (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-SQ L, які поєднують великі мовні моделі з такими методами, як зв'язування схем, інженерія запитань, самоузгодженість та виправлення помилок.

Таблиця 3: Результати точності виконання різних методів на Spider 1.0 у дослідженні "Text-to-SQL Empowered by Large Language Models: A Benchmark Evaluation" [2]; вона показує вплив на точність не лише вибору моделі, але й таких методів, як швидка інженерія, зв'язування схем та самоузгодженість.

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

Бенчмаркінг — це не лише вимірювання точності, а й розуміння того, де і чому система дає збій. Протягом нашої оцінки ми аналізували неправильні прогнози та визначали кілька повторюваних закономірностей, які впливали на кінцеві результати.

Деякі помилки виникли в самому бенчмарку. У невеликій кількості випадків невідповідності в еталонних (золотих) SQL-запитах призводили до того, що логічно правильні прогнози були позначені як неправильні. Інші випадки стосувалися неоднозначних питань природною мовою або сценаріїв розв'язання нічиєї, коли кілька SQL-запитів могли законно давати однаково правильні відповіді.

Ми також спостерігали кілька специфічних для моделі поведінкових явищ, включаючи непотрібні перетворення типів, непослідовну обробку чутливості до регістру та періодичне надмірне ускладнення інакше простих SQL-запитів. Ці результати підкреслили важливість включення механізмів перевірки та самовиправлення в конвеєр агента даних.

Загалом, наш аналіз показав, що багато помилок, що залишилися, були спричинені не обмеженнями самої мовної моделі, а неоднозначностями в бенчмарку або граничними випадками під час генерації 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 забезпечив важливу основу для оцінки нашого Data Agent, але він є лише першим кроком до готового до виробництва корпоративного штучного інтелекту.

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

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

Посилання

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

[2] Dawei Gao, Haibin Wang, Yaliang Li, Xiuyu Sun, Yichen Qian, Bolin Ding, Jingren Zhou «Перетворення тексту в SQL на основі великих мовних моделей: порівняльна оцінка» arXiv. Червень 2026

https://arxiv.org/pdf/2308.15363 

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

https://arxiv.org/pdf/2304.11015

Ділшен ЙИЛДАР ХАВАЙЛАР, 

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