Резюме в четырёх пунктах.

Ключевые цифры

Четыре цели.

1. Понять, какие LLM-модели реально справляются с генерацией Qlik Set Analysis.
2. Сравнить модели по точности, стоимости, скорости и стабильности.
3. Проверить гипотезу: можно ли промпт-инжинирингом дешёвую модель довести до уровня дорогой.
4. Сформировать data-driven рекомендации для возможной интеграции LLM в продукт.

Двухфазная схема, двойной судья.

Задачи — с обучающей платформы QATA. Они открыты: любой может решить их сам и проверить себя автопроверкой по эталону. Реальные кейсы, никаких выдуманных исследователем задач.

Источник задач

31 верифицированная задача Set Analysis из трёх доменов: Sports, HR, Sales. Использовали платформу QATA для автопроверки результатов с эталонами. Платформа доступа: OpenRouter (единый API к 300+ моделям), бюджет $20.

Phase 1 + Phase 2

Двойной независимый судья

Каждый ответ модели прогоняли через двух LLM-судей. Один смотрел что получилось, второй — как это написано. Когда расходятся — появляется «логический разрыв».

13 моделей · 4 категории.

Не брали устаревшие версии (Llama 2, GPT-3.5), variant fine-tunes (для roleplay/медицины), мелкие модели (≤8B параметров).

13 моделей, ранжированы по совпадению числа.

Один стандартный промпт × 31 задача. Колонка Coincidental — сколько раз модель «угадала» число через выражение, отличающееся от эталона.

* DeepSeek Coder V3 исключён — API broken (0/31).

Кто держится при варьировании промпта.

Топ-5 моделей × 31 задача × 3 уровня промпта = 93 ответа на модель. Ранжировано по совпадению логики.

Шесть технических открытий.

count(distinct {<Sex={"M"}>} Name)
/ count(distinct Name)

Count({<Sex={'M'}>} DISTINCT ID)
/ Count(DISTINCT ID)

{<Year = {'1996'},
   Season = {'Summer'}>}

{<Games = {'1996 Summer'}>}

$17.35 на весь бенчмарк.

~4 300 запросов, ~2.7M токенов. 70% бюджета съел LLM-as-judge (Claude Opus в Phase 1) — при повторе с Sonnet стоимость в 14 раз ниже за то же количество ответов.

Подтверждена гипотеза «использовать Sonnet/Haiku в роли судьи» — экономия 5–14× без потери качества оценки.

Если LLM пойдёт в продукт.

Три сценария интеграции с реалистичной точностью (с обязательным человеческим ревью) и стоимостью на 1 000 запросов.

* С обязательным человеческим ревью.

Четыре правила, без которых не идти в прод.

1. Никогда без ревью. Никогда не использовать без человеческого ревью или Qlik runtime-валидации. Лучшая модель (Gemini 2.5 Pro) — 47% строгой логики; примерно каждый второй ответ требует проверки.
2. Настроить reasoning-модели. GPT-5, Gemini 2.5 Pro требуют max_tokens=4000 + reasoning_effort=low. Иначе систематически заниженные результаты.
3. Не перегружать few-shot. Для большинства моделей обогащённый промпт снижает точность. Простой промпт + строгая валидация работают лучше.
4. Sonnet/Haiku в роли судьи. Не Opus. Экономия 5–14× без потери качества оценки — проверено на 868 ответах.

Какую open-source модель развернуть локально?

Отдельный вопрос: если LLM в облаке нельзя по политике безопасности — что брать on-prem.

Что мы узнали.

Исследование подтверждает: LLM могут генерировать корректный Qlik Set Analysis — но с серьёзной оговоркой по строгости оценки. По числу — до 68% у топ-моделей; по строгой эквивалентности эталону — до 47%. Отдельный вывод: примерно в 18% верных ответов формула модели грамотнее эталона — на целостных датасетах счёт по ключу надёжнее счёта по отображаемому полю.

Главная рекомендация — использовать только в режиме «ассистент для человека», не в режиме автоматической генерации без валидации. Главный технический инсайт — про настройку reasoning-моделей — критически важен для любой команды, которая будет интегрировать GPT-5 / Gemini Pro / o1 / o3 в production.

Главный методологический инсайт — про двойную проверку (число + логика) — должен стать стандартом для любых будущих LLM-бенчмарков в команде.

Краткое резюме по моделям