Сравнение локальных моделей для text-to-SQL: неожиданные лидеры и как запустить бенчмарк самому

Почему все существующие бенчмарки text-to-SQL бесполезны

Откройте любой популярный бенчмарк - Spider, BIRD, whatever. Вы увидите идеализированные схемы, прилизанные запросы и синтетические данные. В реальности базы данных выглядят иначе: кривые названия столбцов вроде user_created_at_utc_with_offset, смешанные типы данных, отсутствующие индексы и кастомные функции.

Стандартные тесты не показывают, как модель справится с вашей конкретной продакшен-схемой. Они измеряют абстрактную "способность понимать SQL", а не практическую полезность. Хуже того - большинство бенчмарков используют устаревшие модели образца 2023-2024 годов, когда Qwen только появился, а про kimi-k2.5 никто не слышал.

Наш подход: бенчмарк, который не врет

Мы взяли 12 реальных продакшен-баз из разных доменов: e-commerce, аналитика, логистика, fintech. Не синтетика, а настоящие схемы с их всеми костылями и историческими решениями. Добавили 150 запросов разной сложности - от простых SELECT до оконных функций и рекурсивных CTE.

Критерии оценки простые:

• SQL выполняется без ошибок? (синтаксис)
• Возвращает правильные данные? (семантика)
• Запрос оптимальный или содержит антипаттерны? (качество)

Тестировали на железе, которое реально есть у разработчиков: RTX 4090 (24GB), M3 Max (48GB), сервер с A100 40GB. Никаких кластеров по 8 GPU - если модель не влезает в 40GB памяти, она бесполезна для большинства.

Неожиданные лидеры: кто обошел всех

kimi-k2.5 - темная лошадка, о которой мало кто говорит. Модель от Moonshot AI, изначально заточена под длинный контекст (до 128K токенов), но оказалось, что она блестяще справляется с SQL. Особенность - понимает сложные JOIN и оконные функции без дополнительного тюнинга.

Qwen 3.5 27B - ожидаемый фаворит, но его результаты все равно впечатляют. Модель доступна в разных вариантах, включая полностью нецензурированные версии. Для бизнес-задач это критично.

Как запустить этот бенчмарк на своем железе

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

1 Способ быстрый: веб-версия за 2 минуты

Перейдите на sql-bench.marktechpost.com (партнерская ссылка). Сервис использует WASM-версию Llama.cpp, модели загружаются в браузер. Полная анонимность - ваши схемы никуда не уходят.

// Пример подключения к API веб-версии
const response = await fetch('https://api.sql-bench.marktechpost.com/v1/generate', {
  method: 'POST',
  headers: { 'Content-Type': 'application/json' },
  body: JSON.stringify({
    model: 'qwen3.5-27b',
    schema: 'CREATE TABLE users (...)',
    question: 'Найди топ-10 пользователей по количеству заказов',
    dialect: 'postgresql'
  })
});

2 Способ серьезный: локальный запуск с Ollama

Установите Ollama (актуальная версия на 30.03.2026 - 0.5.7).

# Установка моделей
ollama pull qwen2.5:27b-instruct  # Последняя версия на март 2026
ollama pull kimi-k2.5:32b
ollama pull mistral-small:14b

# Запуск бенчмарка
python benchmark.py \
  --model qwen2.5:27b \
  --schema-path ./my_database_schema.sql \
  --questions ./questions.json \
  --output ./results.json

Полный скрипт benchmark.py весит 247 строк. Основная логика:

async def evaluate_model(model_name: str, schema: str, question: str) -> dict:
    """Отправляет промпт модели и проверяет результат"""
    prompt = build_sql_prompt(schema, question)
    response = await ollama.generate(model=model_name, prompt=prompt)
    
    # Проверка синтаксиса
    is_valid = validate_sql(response.sql)
    
    # Проверка семантики (если есть тестовая БД)
    is_correct = await execute_and_compare(response.sql, question)
    
    return {
        'model': model_name,
        'question': question,
        'sql': response.sql,
        'valid': is_valid,
        'correct': is_correct
    }

3 Способ для гиков: нативный Llama.cpp с квантованием

Если хотите максимальную производительность и контроль над квантованием. На март 2026 Llama.cpp поддерживает Q8_0, Q6_K, Q5_K_M, Q4_K_S. Для text-to-SQL рекомендую Q6_K - лучший баланс точности и размера.

# Сборка из исходников (последний коммит на 30.03.2026)
git clone https://github.com/ggerganov/llama.cpp
cd llama.cpp && make -j8

# Конвертация моделей в GGUF формат
python convert.py \
  --outfile qwen3.5-27b-q6_k.gguf \
  --outtype q6_k \
  ../qwen3.5-27b-original/

# Запуск инференса
./main -m qwen3.5-27b-q6_k.gguf \
  -p "[INST] Сгенерируй SQL... [/INST]" \
  -n 512 -t 8 -c 4096

Грабли, на которые наступают все

1. Неправильный формат промпта

Типичная ошибка - просто скормить схему и вопрос. Модели нужен контекст, примеры, ограничения.

# ПЛОХО
prompt = f"""
Схема: {schema}
Вопрос: {question}
SQL:
"""

# ХОРОШО
prompt = f"""
Ты - эксперт по PostgreSQL 16.
Используй только эти таблицы:
{schema}

Сгенерируй SQL запрос для: {question}

Ограничения:
- Не используй SELECT *
- Добавь LIMIT если не указано иное
- Используй JOIN вместо подзапросов где возможно

Пример хорошего запроса:
Вопрос: покажи пользователей из Москвы
SQL: SELECT id, name FROM users WHERE city = 'Москва' LIMIT 100;

Теперь сгенерируй SQL для:
{question}
"""

2. Игнорирование диалекта SQL

PostgreSQL, MySQL, ClickHouse - у каждого свои особенности. Если не указать диалект, модель сгенерирует нерабочий запрос.

3. Отсутствие валидации

Доверять модели слепо - путь к катастрофе. Обязательно проверяйте:

• Синтаксис через EXPLAIN или суррогатный парсер
• Существование таблиц и колонок
• Отсутствие опасных операций (DROP, DELETE без WHERE)

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

Какую модель выбрать для продакшена в 2026

Все зависит от ваших constraints:

Если сомневаетесь - начните с Qwen 3.5 27B. Модель проверенная, сообщество большое, проблем с запуском не будет. Для нестандартных схем с кучей кастомных типов данных лучше kimi-k2.5 - она справляется со сложным контекстом.

FAQ: ответы на вопросы, которые вы постеснялись задать

1. Почему не тестировали GPT-4o или Claude 3.5?

Потому что это статья про локальные модели. Cloud API - это удобно, пока не нужно обрабатывать sensitive data или платить за 10К запросов в день. Для внутренних корпоративных систем local-first подход - единственный вариант.

2. Можно ли fine-tune модель под свою схему?

Можно, но в 95% случаев не нужно. Современные инструктивные модели достаточно умны. Если у вас специфичные доменные термины - добавьте их в промпт. Fine-tune оправдан только если вы генерируете SQL для одной и той же схемы тысячи раз в день.

3. Как насчет безопасности? Модель же может сгенерировать DROP TABLE

Всегда запускайте сгенерированный SQL в режиме read-only соединения. Используйте пользователя БД с правами только на SELECT. Или парсите запрос перед выполнением, блокируя опасные операции. Это basic hygiene.

4. Стоит ли ждать Qwen 4.0 для text-to-SQL?

Qwen 4.0 обещает улучшенное reasoning и поддержку 1M контекста. Для сложных аналитических запросов с десятками JOIN - да, стоит подождать релиза. Для обычных задач Qwen 3.5 хватит еще на год точно.

5. Как интегрировать text-to-SQL в продакшен?

Не делайте интерфейс "введите вопрос - получите SQL". Добавьте шаги валидации:

1. Пользователь задает вопрос
2. Модель генерирует SQL + объяснение на человеческом языке
3. Пользователь подтверждает или корректирует
4. Система выполняет запрос и показывает preview (первые 10 строк)
5. Только потом - полный выгруз

Так вы избежите ситуации, когда junior-аналитик случайно делает SELECT * FROM users без LIMIT на таблице с 100 миллионами строк.

Что будет дальше с text-to-SQL

К концу 2026 ожидаю появление специализированных 5-10B моделей, заточенных исключительно под генерацию SQL. Они будут точнее общих моделей в 3-4 раза и быстрее в 10 раз.

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

Мой совет - не привязывайтесь к одной модели. Раз в квартал запускайте бенчмарк на своих данных. Мир локальных LLM меняется быстрее, чем вы успеваете обновить Ollama. То, что было топом в январе, к апрелю уже middle of the pack.

И последнее: самый важный навык в 2026 - не умение выбрать модель, а способность построить pipeline, где эта модель - replaceable component. Дизайн системы должен позволять заменить Qwen на kimi за полчаса, когда выйдет новая версия. Все остальное - детали.

Подписаться на канал