В первой части мы разобрали теорию text‑to‑SQL: как LLM заменяют разработчиков, почему RAG и CoT спасают от галлюцинаций и зачем Scale AI дообучает ChatGPT-4. Но теория неполна без практики! В этом материале — жёсткое тестирование моделей (ChatGPT o3-mini‑high, ChatGPT 4.1, Claude Sonnet 4, ChatGPT o3, Gemini 2.5 Pro, DeepSeek R1–0528) на бенчмарке LiveSQLBench.

6 моделей, 10 задач, сложность от ★★ до ★★★★★★★★★★. Проверим, как они считают лунные помехи, генерируют SQL для криптобирж и ищут артефакты в музеях.

---

N. B. Это, по сути, вторая часть статьи!

Часть 1. Она фокусируется на истории методик text‑to‑SQL, разных подходах к промтингу и онлайн‑сервисах.

Часть 2. Бенчмарки через крупные языковые модели.

---

gaming_5: ищем лучшие аудиоустройства

Сложность: ★★☆☆☆☆☆☆☆☆

Наша база данных — это как высокотехнологичный арсенал геймера, где каждая таблица хранит свои секреты.

TestSessions — основа, с данными о сессиях тестирования: от точного времени (StampMoment) до таких деталей, как уровень батареи или задержка клика. Для аудиоустройств есть AudioAndMedia, где собраны параметры вроде громкости, чувствительности микрофона и индекса качества звука AQI, который рассчитывается по формуле: . Другие таблицы, такие как DeviceIdentity или Mechanical, добавляют информацию о брендах, долговечности и даже эргономике.

В этом тесте нужно не только найти нужные данные в AudioAndMedia, но и правильно посчитать AQI, ориентируясь на словарь знаний. Кто же из моделей проложит SQL‑маршрут без ошибок?

Промт полностью.

o3-mini‑high

4.1

Claude

o3

Gemini

DeepSeek

DeepSeek и o3 выдали лучшие запросы, ловко реализуя формулу AQI и добавляя MakerName с ModNum для читаемости. DeepSeek добавил фильтр DevScope = 'Headset', что показывает внимание к контексту, но слегка избыточно, так как AudioAndMedia уже ограничивает выборку. o3 впечатлил подробными комментариями (как и Gemini), но обе модели дублируют формулу AQI в SELECT и WHERE, что неоптимально, и игнорируют NULL.

Claude и Gemini корректны, но проще: Claude предусмотрительно фильтрует NOT NULL, а Gemini приводит SpkSenseDb к REAL (что может быть необязательным, например, в PostgreSQL).

4.1 выделяется COALESCE для NULL‑провеки, но, как и другие, упускает столбец DevScope (тип устройства).

o3-mini‑high выдал минималистичный запрос без MakerName и ModNum, что снижает информативность.

DeepSeek и o3 лидируют за счет полноты и стиля, но оптимизация может показаться недостаточной.

---

alien_3: лунные помехи под микроскопом

Сложность: ★★★☆☆☆☆☆☆☆

Наша база данных — это как бортовой журнал космического корабля. Таблица Observatories хранит данные об обсерваториях: от уникальных названий до фазы Луны (LunarStage), прозрачности атмосферы (AtmosTransparency) и углового расстояния до Луны (LunarDistDeg).

Таблицы вроде Signals и Telescopes дополняют картину информацией о сигналах и оборудовании, а словарь знаний раскрывает формулу lunar interference factor (LIF): . Этот показатель помогает понять, как Луна мешает наблюдениям, — чем он выше, тем сильнее помехи.

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

Промт полностью.

o3-mini‑high

4.1

Claude

o3

Gemini

DeepSeek

Все модели правильно применили формулу LIF и сгруппировали данные по ObservStation.

o3 выделился, добавив фильтр NULL для LunarDistDeg и AtmosTransparency, что делает запрос устойчивым к пропускам данных.

Claude впечатлил комментариями и псевдонимами вроде observatory_name, но его замена NULL нулями через COALESCE искажает LIF, что неожиданно для столь детального подхода.

4.1 и DeepSeek выдали надёжные запросы, но без фильтрации NULL, полагаясь на AVG (SQL‑функцию, считающую среднее арифметическое в столбце, которая уже отфильтровывает нулевые значения).

o3 лидирует по точности, Claude — по читаемости, остальные держат планку.

---

crypto_2: вычисляем order fill rate для криптобиржи

Сложность: ★★★★☆☆☆☆☆☆

Давайте разберёмся с базой данных, которая лежит в основе нашего теста. Это сложная система, где таблица Orders хранит всё про транзакции: от их объёма (DealCount) и цены (DealQuote) до статуса (OrderFlow) и типа (OrderTune). Связанная таблица OrderExecutions детализирует, сколько из транзакции уже исполнено (FillCount) и сколько ещё ждёт своей очереди (RemainCount). А вокруг них — целая экосистема из таблиц Users, AccountBalances, RiskAndMargin, MarketData и других, которые дают контекст: кто торгует, какие у них балансы, каковы риски и что происходит на рынке.

Здесь не просто запрос, а вызов, требующий от модели понимания, как связать таблицы Orders и OrderExecutions, правильно применить формулу  и выдать чёткий SQL‑запрос.

Промт полностью.

o3-mini‑high

4.1

Claude

o3

Gemini

DeepSeek

o3 показал себя лучше всех, выдав точный запрос с LEFT JOIN, чтобы учесть ордера без исполнений, и GROUP BY для суммирования FillCount — идеально для множественных записей в OrderExecutions. Защита от деления на ноль и COALESCE для NULL сделали его запрос надёжным.

Claude и 4.1 тоже выбрали LEFT JOIN, обеспечив полноту, но споткнулись на агрегации: Claude использовал RemainCount без суммирования, а 4.1 применил MAX(RemainCount), что может исказить остаток при нескольких исполнениях. Зато их пояснения, особенно у Claude с комментариями в коде, на высоте.

o3-mini‑high и Gemini сбились с курса: оба ограничились INNER JOIN, упустив ордера без исполнений, что критично для реальных данных.

Gemini корректно применил формулу с RemainCount, но также не учёл множественные исполнения, а o3-mini‑high ещё и рисковал с делением на ноль.

DeepSeek шокировал ошибкой: вместо он посчитал , что противоречит словарю знаний, несмотря на аккуратный код.

Все модели выдали читаемые запросы; Claude и o3 выделились чёткостью пояснений и комментариями в SQL. Для практики лучше доработать запрос o3, добавив индексы, или исправить агрегацию у Claude и 4.1.

---

alien_4: тест на космическую проницательность

Сложность: ★★★★★☆☆☆☆☆

Вновь обращаемся к знакомой базе данных, где ключевую роль играет таблица Observatories, известная нам по анализу лунных помех. На этот раз акцент смещается на таблицы Signals и SignalProbabilities, которые хранят характеристики сигналов (частота, мощность, тип модуляции) и вероятности их технологического происхождения.

Это задание с подвохом: модель должна не только соединить таблицы, но и сообразить, что «потенциальные экзопланеты» — это сигналы с высоким TechSigProb или аномальными характеристиками. Справятся ли модели с этим астрономическим ребусом?

Промт полностью.

o3-mini‑high

4.1

Claude

o3

Gemini

DeepSeek

4.1, o3 и Gemini точно определили «потенциальные экзопланеты» как сигналы с SigClassType = 'Candidate' (из таблицы SignalClassification). Их SQL‑запросы просты, безупречны синтаксически и возвращают список обсерваторий с числом кандидатов. Код чистый, с понятными псевдонимами, а у o3 — ещё и подробные комментарии.

o3-mini‑high и DeepSeek ошиблись, выбрав пустую таблицу SourceProperties с фильтром CelestObj = 'Planet', что сделало их запросы бесполезными, несмотря на аккуратность.

Claude удивил, фильтруя по BioSigProb > 0.3 («Высокая вероятность биосигнатур указывает на возможную жизнь») и TechSigProb > 0.5 («Высокая вероятность технологических сигнатур указывает на цивилизации»), но этот креативный подход кажется спекулятивным и не соответствует контексту.

o3, 4.1 и Gemini показали глубокое понимание схемы.

---

archeology_4: нейросети вычисляют качество сканов

Сложность: ★★★★★★☆☆☆☆

На этот раз у нас тест archeology_4. База данных — настоящий археологический пазл: 11 таблиц, включая Scans (данные о сканах), ScanPointCloud (разрешение и плотность точек), ScanRegistration (метрики точности) и другие.

Каждая таблица набита деталями: например, в ScanPointCloud есть ScanResolMm (разрешение в миллиметрах) и PointDense (плотность точек на квадратный метр), а в ScanRegistration — точность (LogAccuMm) и ошибки (ErrValMm). В словаре знаний прячется формула scan resolution index (SRI): , которая оценивает качество скана (меньше значение — лучше результат). Это лишь часть структуры, но уже понятно, что база сложная, как древний лабиринт.

Задача не из лёгких: нейросетям нужно не просто понять структуру базы, но и корректно вычислить SRI, опираясь на формулу из словаря знаний, а затем классифицировать результат по уровню доверия. Разберём, кто справился, а кто застрял в археологических дебрях.

Промт полностью.

o3-mini‑high

4.1

Claude

o3

Gemini

DeepSeek

o3 выбрал LogMethod (Target‑based/Hybrid/Automatic) как «тип скана» — неожиданный, но удачный ход, ведь метод регистрации напрямую влияет на её точность. Он правильно связал confidence level (достоверность регистрации) с registration accuracy ratio (коэффициент точности регистрации, RAR), как отмечено в 44-м определении словаря знаний:

Claude и DeepSeek предпочли отталкиваться от EquipForm, то есть типа оборудования, и добавили проверки на нули, но ошиблись, привязав коэффициент достоверности к коэффициенту качества сканирования (scan resolution index, SRI) вместо коэффициента точности регистрации (RAR). Ведь в том же 44-й пункте указан параметр RAR.

4.1 и Gemini пытались использовать RAR, но их JOIN’ы оказались некорректными, и запросы не запустятся.

o3-mini‑high вообще выбрал FmtFile (формат файла), что мимо цели.

Креативный o3 вновь лидирует. Claude и DeepSeek надёжны, но менее точны. 4.1 и Gemini допустили ошибки, а o3-mini‑high к тому же слишком упростил задачу. Лучший вариант — доработать o3, добавив фильтры и, возможно, EquipForm.

---

crypto_6: как нейросети считают спред и процентиль?

Сложность: ★★★★★★★☆☆☆

Мы возвращаемся к базе данных криптобиржи, где уже работали с таблицами Orders и OrderExecutions.

Теперь нас интересуют MarketData и MarketStats, содержащие JSONB‑снимки рынка с котировками, спредами и 24-часовыми метриками, такими как объёмы и волатильность. Нужно вычислить процент спреда по формуле  и определить его процентиль среди всех рынков, агрегируя по MktCombo.

Промт полностью.

o3-mini‑high

4.1

Claude

o3

Gemini

DeepSeek

Как оказалось, каждая модель по‑своему считает spread percentage и процентиль.

4.1 и o3 выдали точные запросы по формуле, причем o3 элегантно отфильтровал последние снимки через ROW_NUMBER.

Claude добавил категоризацию спредов, но перегрузил запрос лишними вычислениями.

DeepSeek и Gemini схитрили, взяв готовый SpreadRate, что нарушает условие задачи (ведь его использование может быть некорректным, если существующие данные в JSONB не соответствуют формуле).

o3-mini‑high и o3 упустили защиту от деления на ноль, а 4.1 учел это через NULLIF.

Claude порадовал читаемостью с русскими названиями столбцов, тогда как Gemini выдал лаконичный код. Лучшие — 4.1 и o3 — балансируют точностью и практикой. Claude аналитичен, но избыточен, а DeepSeek и Gemini не справились с этим тестом.

---

cross_db_1: запрос на топ-5 рискованных трансферов

Сложность: ★★★★★★★★☆☆

Наша база данных — целый мир, где потоки данных живут своей жизнью. Главная таблица DataFlow фиксирует всё: уникальные ID (RecordRegistry), время создания потока, страны отправления и назначения, протоколы вроде HTTPS или блокчейна, а также кучу метрик — от объёма данных до процента ошибок. К ней через ключи вроде RecordRegistry или FlowSign привязаны таблицы RiskManagement (где хранится risk exposure score) и DataProfile (с уровнем чувствительности данных, например High или Critical). Плюс ко всему есть словарь знаний, который задаёт правила расчёта метрик, таких как , чтобы всё было по науке.

Это задание с подвохом: нужно не только правильно интерпретировать «показатель риска» как RES из словаря знаний, но и связать таблицы DataFlow, RiskManagement и DataProfile, чтобы вытащить нужные поля.

Промт полностью.

o3-mini‑high

4.1

Claude

o3

Gemini

DeepSeek

o3 и 4.1 выдали валидные запросы, с правильным RES и NULLIF против деления на ноль. 4.1 также добавил фильтр high‑risk data flow (RES > 0,7, DSI > 100), которого не было в задании.

o3 «блестит», применяя WITH … AS … (повышающим читаемость) и комментариями в коде, 4.1 — точной обработкой DataSense.

Claude, DeepSeek и Gemini ошиблись, выбрав FlowTag вместо RecordRegistry, что ломает запрос, так как FlowTag неуникален.

Claude отличает читаемость, DeepSeek — точность с ::numeric, но оба требуют правок ошибок. Gemini удивил, добавив DataSense = 'Critical', однако промахнулись с тем же FlowTag и лишней связью RiskJoin. o3 лидирует за читаемость и надёжность. Кроме того, всем моделям нужна проверка на граничные случаи.

---

archeology_5: отправляем нейросети на SQL‑раскопки

Сложность: ★★★★★★★★★☆

Снова погружаемся в археологическую базу, где мы уже разбирались с качеством сканов. Теперь фокус на таблице Sites, хранящей данные о культурных периодах и состоянии сохранности участков, а также на ScanFeatures и ScanSpatial, где фиксируются количество артефактов и пространственные характеристики.

Тест archeology_5 требует вычислить плотность артефактов через формулу feature extraction efficiency из словаря знаний. Это не просто поиск по таблицам, а сейсмическая активность на 9 баллов, которая пошатнет нейронные связи наших электронных друзей.

Промт полностью.

o3-mini‑high

4.1

Claude

o3

Gemini

DeepSeek

Gemini выдал точный запрос. Плотность артефактов рассчитана через множество WITH … AS …, с защитой от деления на ноль.

4.1 и DeepSeek тоже посчитали плотность верно, но первый увяз в сложных подзапросах, а второй запутывает обратной шкалой сохранности (Excellent = 10, Critical = 90).

o3-mini‑high и o3 промахнулись: o3, например, поделил ArtiCount на TraitCount, уйдя от сути.

Claude добавил ConservationPriority на основе PresStat и StructState (из таблицы ScanConservation) — это уже интерпретация словаря знаний, что добавляет ценности. Однако отсутствие агрегации для ArtiCount и AreaM2 — ошибка, и запрос может вернуть некорректные результаты при наличии нескольких записей.

Gemini лидирует за чёткость и надёжность, 4.1 и DeepSeek — крепкие середнячки.

---

museum_5: Выявляем артефакты с риском быстрого износа

Сложность: ★★★★★★★★★☆

Наша база данных — это сердце музея, где хранится информация о каждом экспонате, от древних ваз до свитков династии Тан. Она состоит из 12 таблиц: ArtifactScore фиксирует код экспоната (ArtRegistry), его название, династию, возраст, материал и состояние. Таблица SurfaceAndPhysicalReadings следит за физическими параметрами: вибрацией, влажностью, риском плесени. Есть ещё UsageRecords (как часто экспонат выставляют или перевозят), ArtifactRatings (оценка исторической ценности) и EnvironmentalReadingScore (температура и влажность в витринах).

Словарь знаний задаёт правила игры: формулы вроде MDR (material deterioration rate) или сценария ускоренного ухудшения помогают понять, какие экспонаты под угрозой.

Задача с загвоздкой: нейросети нужно разобраться в формуле MDR и пороге ускоренного ухудшения (MDR > 5 и как минимум две высокие чувствительности из SensitivityData).

Промт полностью.

o3-mini‑high

4.1

Claude

o3

Gemini

DeepSeek

Все шесть моделей выдали рабочие SQL‑запросы, но с разной точностью.

4.1 и o3 лидируют, корректно рассчитывая фактор экологического риска (environmental risk factor, ERF) по четырём показателям чувствительности и используя WITH … AS … с ROW_NUMBER или MAX(ReadTimestamp) для выборки свежих данных. 4.1 выделяется обработкой NULL через COALESCE. В то же время оба добавляют лишний столбец deterioration_index (ведь в промте требовался не числовой показатель, а лишь ответ да/нет).

Gemini близок к лидерам, но пропуск ArtRegistry в выводе снижает удобство.

Claude и DeepSeek ошиблись, включив в ERF все одиннадцать показателей вместо четырёх, что ломает семантику. Claude ещё и некорректно фильтрует данные, а вот DeepSeek спасает LEFT JOIN.

o3-mini‑high, как ни странно, слабее всех в этом тесте — из‑за ошибочного ERF и дублирования данных. Только 4.1 учла NULL, что критично для реальных баз.

---

cross_db_8: кто лучше посчитает риск трансграничных данных?

Сложность: ★★★★★★★★★★

Мы вновь обращаемся к базе трансграничных данных, где таблица DataFlow уже знакома нам по анализу рисков. Теперь в центре внимания AuditAndCompliance и SecurityProfile, которые добавляют данные об аудите и защищённости.

Задача: перевести запрос пользователя в SQL, правильно вычислив риск объёма трансграничных потоков (cross‑border data volume risk, CDVR) — а это значит, разобраться с формулой из словаря, — округлить до двух знаков, отсортировать и показать топ-5. Серьёзный вызов, требующий понимания и базы, и формул, — давайте разберёмся, кто из испытуемых оказался на высоте в самом сложном тесте сегодняшнего эксперимента.

Промт полностью.

o3-mini‑high

4.1

Claude

o3

Gemini

DeepSeek

4.1 и DeepSeek выдали чёткие запросы, аккуратно следуя формуле CDVR. Оба защитились от деления на ноль через NULLIF, но 4.1 добавила лишние OrigNation и DestNation (эти столбцы не требовались по условию), а DeepSeek — ненужный оператор CAST.

o3 почти не отстаёт, но тащит в SELECT столбцы FlowTag, OrigNation и DestNation, которые опять же в запросе не указаны.

Claude удивил применением WITH … AS … и полезными строчными комментариями, а DeepSeek — лаконичностью.

Итог: в этом тесте лидируют 4.1 и DeepSeek.

---

Давайте узнаем результаты!

Соберём суммарный топ по всем десяти заданиям:

Итоговую оценку я рассчитал как среднее между первыми двумя столбцами (корректность + оптимальность). Полагаю, многие согласятся, что читаемость не так критична для выбора подходящего решения, ведь, скажем, мы же не стали бы оценивать качество ассемблер‑кода по степени читаемости (он априори запутанный).

Топ в этом разборе немного отличается от тех результатов, что были получены на сайте LiveSQLBenchmark:

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

---

Пользуясь случаем, я хотел бы поблагодарить Grok 3 и лично Илона Маска за неоценимую помощь в анализе всех результатов.

Тесты я проводил в BotHub — агрегаторе нейросетей, где доступно более 180 ИИ‑моделей (без VPN). При регистрации по этой рефералке дают бесплатные 100 000 «капсов». Там же я воспользовался и Grok 3 — было круто, когда переключаешься между всеми в едином интерфейсе.

---

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

В финале не осталось таблиц, лишь эхо вопросов: что есть риск без контекста? Что есть данные без интерпретации? Как сонет, написанный нулями и единицами, идеальный запрос — это отражение текущего знания. С каждым новым контекстом он переосмысляется и живёт заново.