ВЫБОР МОДЕЛИ ПОД ЗАДАЧУ

Прежде чем мерить — ответь на три вопроса.

Чек:

• Контекст ≤ 1K токенов на пару (посчитай через провайдерский tokenizer, не на глаз — привет это 1 токен, а здравствуйте уже 4–5)
• Output — closed-set classification, не generation
• Ground truth ≥ 15 размеченных примеров

Все три «да» — едем дальше.

Откуда брать. Самый удобный источник — твоя история. Если в системе уже происходили события «правильное соединение» (бот закрыл баг по PR, и человек подтвердил), это и есть твои правильные ответы.

Из истории отбираешь 6–8 случаев четырёх разных типов:

• Очевидно связаны (правильный ответ — да): прямое закрытие.
• Очевидно НЕ связаны (правильный ответ — нет): два разных бага, два разных тикета.
• На границе (общая тема, но разные детали): модель должна сказать «не уверен».
• Заведомо разные: две случайные несвязанные записи.

К реальным случаям добавляешь 3–5 синтетических — заведомо несвязанных пар, которые ты сочинил вручную. Они нужны как контрольная точка: если модель на них даёт «да» — значит, она ломается на твоём промпте, и проблема в формулировке, не в данных.

Итого 11–13 кейсов — этого достаточно.

Структура casebook (CSV):

case_id, kind,      ground_truth, text_a,   text_b,   note
1,       real,      yes,          "...",    "...",    прямое закрытие через PR
2,       real,      yes,          "...",    "...",    закрытие по ссылке в commit msg
3,       real,      no,           "...",    "...",    тематически близкие, разные баги
4,       real,      maybe,        "...",    "...",    серая зона, эскалейт
5,       real,      no,           "...",    "...",    разные модули
6,       real,      yes,          "...",    "...",
7,       synthetic, no,           "...",    "...",    контроль NO-1
8,       synthetic, no,           "...",    "...",    контроль NO-2
9,       synthetic, no,           "...",    "...",    контроль NO-3
10,      synthetic, maybe,        "...",    "...",    синтетический пограничный
11,      synthetic, no,           "...",    "...",    контроль NO-4

Распределение типов: ≈40% явно YES, ≈40% явно NO, ≈10% серая зона, ≈10% синтетический контроль.

Реальные кейсы — SQL-ом из таблицы событий:

SELECT a.id, a.text AS text_a, b.id, b.text AS text_b, e.verdict
FROM resolution_events e
JOIN entities a ON a.id = e.source_id
JOIN entities b ON b.id = e.target_id
WHERE e.verdict IN ('confirmed', 'rejected', 'escalated')
  AND e.created_at > now() - interval '90 days'
ORDER BY random()
LIMIT 30;

Из 30 рандомных руками отбираешь 6–8 нужных типов. Меньше 30 на старте — велик шанс плохого баланса.

Один и тот же промпт получают все модели. Иначе сравнение нечестное: дашь одной длинную инструкцию, другой короткую — увидишь разницу инструкций, а не моделей.

Готовый шаблон промпта приложен в наборе скриптов ниже (P02). Скопируй, замени описание задачи под себя, прогоняй.

Шаблон, протестировать на 1–2 кейсах перед массовым прогоном:

SYSTEM:
Ты определяешь, закрывает ли изменение A событие B.
Возвращай JSON: {"verdict": "YES"|"NO"|"MAYBE", "reason": "..."}
- YES: A напрямую закрывает B
- NO: A не связано с B или связано косвенно (общая тема, разные изменения)
- MAYBE: есть прямая связь, но не хватает доказательства закрытия
Reason — 1-2 предложения, по-русски.

USER:
A: <text_a>
B: <text_b>

Что критично:

1. Никаких few-shot примеров. Смещают распределение и маскируют истинный профиль.
2. Никаких «будь уверен». Это пресет, а ты как раз меряешь работу без него.
3. JSON-output. На 12 моделях × 11 кейсов разбирать произвольный текст — потеря времени.
4. Слово json в user message — обязательно для DashScope (Qwen). Без него response_format=json_object отвечает 400.
5. temperature=0 для воспроизводимости. Исключение — Anthropic extended thinking (там жёстко требуется 1.0).

Берёшь 4–6 моделей разного типа. Зачем именно разнотипных:

• одна американская премиум — для верхней границы качества
• одна-две китайские с дешёвым API — могут оказаться лучшим компромиссом
• одна российская, если ты в РФ-инфре — чтобы понять, есть ли смысл их использовать
• одна и та же модель в двух режимах: «с размышлением» и «без»

Прогон — 11 запросов к каждой модели. Если делать по очереди — займёт несколько часов. Если параллельно (все модели одновременно, все кейсы одновременно) — уложится в минуту-две.

Для каждого кейса каждой модели сохрани: ответ (YES/NO/MAYBE), обоснование, время ответа, стоимость. Стоимость считается по тарифу провайдера: токены на входе × цена за тысячу + токены на выходе × цена за тысячу.

Кандидаты в шорт-лист (пример из моего замера, под свой стек подбирать аналогично):

provider     model              mode       why
anthropic    claude-sonnet      default    премиум-якорь
anthropic    claude-sonnet      thinking   сравнить ON vs OFF
deepseek     deepseek-v4-pro    thinking   топ Codeforces, проверка гипотезы
zai          glm-5.1            thinking   китайский reasoner
zai          glm-5.1            default    он же без thinking
dashscope    qwen3.6-plus       thinking   китайский universal
dashscope    qwen3.6-plus       default    он же без thinking
openrouter   kimi-k2.6          thinking   через router
sber         gigachat-2-max     default    российский, нет thinking-toggle
yandex       yandexgpt-5.1      default    российский, silently игнорирует effort

Запуск через asyncio.gather с Semaphore(6) для лимита одновременных коннектов на провайдера. Готовый скрипт bench-runner.py приложен ниже (P03) — копируй, ставь свои API-ключи, запускай.

Логировать в JSONL по строке на (модель, кейс) — потом агрегировать pandas.read_json(lines=True).

Когда таблица собрана — не смотри на одну общую точность. Смотри на четыре вещи.

Что модель отвечает по типам кейсов

• На «очевидно да»: все должны сказать YES. Кто говорит NO — пропускает реальные связи. В проде это «не закрыли баг», который реально был закрыт. Клиент видит висящий тикет.
• На «очевидно нет»: все должны сказать NO. Кто говорит YES — это ложные тревоги. В антифроде — заблокировали невинного клиента. В дедупликации — слепили два разных бага в один.
• На границе: тут уже про характер. Кто часто говорит MAYBE, кто срезает в YES/NO.

Скорость

Если задача в чате с пользователем, секунда vs пять секунд это разные продукты. Если в фоне раз в час — скорость не важна.

Цена

На 100 тысячах запросов в день разница 0.005 vs 0.05 доллара за запрос — это 150 vs 1500 долларов в месяц.

Reading framework — четыре оси, не одна accuracy:

1. Confusion matrix per ground-truth class. Sensitivity на YES-truth (recall на положительном классе), specificity на NO-truth, поведение на MAYBE-truth (сохраняет или режет). Это реальный профиль.
2. Decision profile distribution. Доля YES/NO/MAYBE в ответах модели на одних и тех же 11 кейсах. Одна выдаёт 9/2/0, другая 6/2/3 — это два разных продукта. Какой нужен — вопрос архитектуры (есть ли эскалейт-канал), не вопрос модели.
3. Latency p50 / max. На 11 кейсах p99 нереалистичен, но p50 и max уже показательны. Если max > 30с — модель не подойдёт под inline-сценарии независимо от accuracy.
4. Cost per case. Учитывать reasoning_tokens отдельно — у некоторых провайдеров они тарифицируются как output, у других — отдельной строкой.

После такого чтения часто выясняется: топ по accuracy проигрывает по latency × cost, а decisive non-reasoning модель из второго эшелона даёт тот же decision profile в 5–10× дешевле.

Поставил выбранную модель — не забудь две вещи.

Запасной вариант

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

Повтор замера

Раз в 3–6 месяцев модели обновляются, цены меняются, появляются новые. Casebook у тебя уже есть — прогнать заново те же полчаса. Иногда обнаруживается, что текущая модель стала вдвое дешевле или появился кандидат, который её обходит. Без повтора этого не узнаешь.

Production-чек:

• Fallback model (тот же класс, цена ≤ 2× от основной, другой провайдер) с автоматическим переключением на 5xx / timeout
• Версионирование промпта в коде (PROMPT_V = "v3") для воспроизводимости при дрейфе
• Sample logging: 1–3% реальных запросов с полным input/output → S3 / pg, для еженедельного спот-чека на дрейф
• Calendar reminder на 6-месячный re-benchmark; тот же casebook + 3–5 новых кейсов из последнего квартала

Triggers для внеочередного re-bench:

• Major version у текущего провайдера
• Изменение прайсинга > 20%
• Появление нового кандидата с похожим профилем + меньшей ценой
• Дрейф accuracy на сэмпле > 5pp от исходной

Топ-модель программистских рейтингов (DeepSeek V4 Pro thinking, уровень grandmaster по соревновательному программированию) проиграла GLM 5.1 без размышления:

• На «явно да» (когда модель должна сказать YES): 1 правильный ответ из 2 против 2 из 2.
• На границе (когда нужен MAYBE): сказала NO (ошибка) против MAYBE (правильно).
• По скорости: 12.1с против 2.8с (в 4 раза).
• По цене за прогон: примерно равно с размышлением, но без размышления GLM уходит в копейки.

Топ-модель Codeforces (DeepSeek V4 Pro thinking, рейтинг 3206 — уровень grandmaster) проиграла GLM 5.1 без thinking:

• YES-truth recall: 1/2 vs 2/2
• MAYBE-truth: NO (false) vs MAYBE (correct)
• Latency: 12.1s vs 2.8s (×4.3)
• Cost per run: примерно равно с включённым thinking; без thinking GLM уходит в копейки

Та же Qwen 3.6 Plus в двух режимах:

• С размышлением: 6 NO, 2 MAYBE, 3 YES; 21 секунда, $0.023 за прогон.
• Без размышления: 8 NO, 1 MAYBE, 2 YES; 2.4 секунды, $0.0017 за прогон.

Характер ответов почти не меняется (одно решение перетекает MAYBE → NO). При этом скорость в 9 раз, цена в 13 раз.

Та же Qwen 3.6 Plus в двух режимах:

• thinking ON: 6 NO / 2 MAYBE / 3 YES; 21s; $0.023
• thinking OFF: 8 NO / 1 MAYBE / 2 YES; 2.4s; $0.0017

Decision profile почти не меняется (одно решение перетекает MAYBE → NO). Скорость ×9, цена ×13.

На short-context + чёткой ground truth thinking жжёт reasoning_tokens без прироста точности. На long-context / сложной логике — мерить отдельно, там может выиграть.

Две группы моделей с разным «характером ответов»:

• Decisive (всегда YES/NO): российские, китайские без размышления. MAYBE редко или никогда.
• Hedged (часто MAYBE): американские с размышлением, китайские reasoner-модели. Осторожные.

Какой характер нужен — не вопрос «лучше/хуже», а вопрос архитектуры:

• Есть менеджер, разбирающий «не уверен» → нужен hedged. Иначе MAYBE некуда деть.
• Автомат должен сразу решать → нужен decisive. Иначе MAYBE превращается в зависший тикет.

Выбирать модель по точности без учёта характера — менять одну непригодную модель на другую непригодную.

Две группы моделей с разным decision profile:

• Decisive: российские модели, китайские без thinking. Distribution YES/NO/MAYBE — 1/10/0 или 2/8/1.
• Hedged: американские с extended thinking, китайские reasoner-модели. Distribution — 1/5/5 или 2/6/3.

Архитектурный выбор:

• Hedged подходит, когда есть escalation queue для MAYBE-результатов
• Decisive подходит, когда система должна принимать решение без human-in-the-loop
• Hedged без эскалейт-канала = бессмысленно: MAYBE всё равно будет приведено к решению эвристикой

Гипотеза «российские модели лучше понимают русский, потому что обучены на русском корпусе» на спорных кейсах не подтвердилась. На пограничных случаях (общая тема, разные детали) российские модели проигрывают и Sonnet, и GLM по точности. Преимущество корпуса нивелируется отсутствием размышления и более простой архитектурой.

Гипотеза «native-language corpus advantage» на нашем casebook опровергнута: yandex-5.1 и giga-2-max показали 1/2 на YES-truth и NO на MAYBE-truth, в то время как GLM 5.1 (Mandarin/English-base) даёт 2/2 + MAYBE. Reasoning chain в hedged-моделях перевешивает языковое преимущество корпуса.

Спросил одну из моделей: «расскажи, какой у тебя контекст и cutoff». Ответила: «128K, май 2025». По документации провайдера — 1M, март 2026. Модели часто не знают свою точную спецификацию из training data: она появилась после обучения.

Похожая история с параметрами API. Один из российских провайдеров принимает параметр «думай больше» без ошибки, статус 200, ответ возвращается. Только дополнительных размышлений нет, скорость идентична обычному режиму, ответы те же. Параметр silently ignored — release notes провайдера явно говорят «не поддерживается в этой версии», но API его молча принимает.

Спросил DeepSeek V4 Pro: «what's your context window and training cutoff?». Ответ: «128K, May 2025». По официальной документации провайдера — 1M context, March 2026 cutoff. Модель не знает свою точную спецификацию из training data — она появилась после.

С API параметрами та же история. YandexGPT 5.1 принимает reasoning_effort: "high" со статусом 200, без ошибки. При этом reasoning_tokens=0, latency идентична default-режиму, decisions те же. Release notes провайдера прямо говорят: «not supported in this version» — но API молча принимает.