Урок 2: Минимальная достаточная модель — не берите GPT-5 для того, что закроет Qwen 3B

Чему вы научитесь

• Разводить задачи по трём шкалам: сложность рассуждения, цена ошибки и допустимая задержка
• Быстро отсекать две дорогие крайности: «топ-модель там, где нужен классификатор» и «дешёвая 7B-модель там, где нужен длинный анализ и верификация»
• Подбирать не только модель, но и класс решения: LLM, VLM, CV-модель или прогнозирование временных рядов
• Ставить интегратору правильный вопрос: «какая минимально достаточная модель закрывает задачу в моём контуре»
• Связывать выбор модели с юридическим и ИБ-контуром из модуля p.3, если в задаче есть ПД, КИИ или санкционные ограничения

Ошибка выбора модели в промышленном AI почти всегда дороже ошибки промпта. Промпт можно переписать за час. Неправильный класс модели тянет за собой лишний бюджет, неподходящее железо, проваленный SLA и иногда прямой конфликт с контуром данных. Если в запросах есть персональные данные, сначала смотрите урок 1 модуля p.3. Если система касается КИИ — урок 2 модуля p.3. Если вопрос упирается в санкционную доступность западных моделей — урок 5 модуля p.3.

Нулевое правило: сначала класс задачи, потом бренд модели

На уровне руководителя модель выбирают не по leaderboard, а по трём вопросам:

1. Насколько сложное рассуждение реально требуется?
2. Сколько стоит ошибка?
3. Какой отклик допустим по времени и объёму входных данных?

Если хотя бы на один вопрос нет ответа, разговор про «давайте возьмём GPT-5.4» преждевременен. Для извлечения ФИО из строки не нужен frontier-class LLM. Для due diligence подрядчика по 300 документам не годится «что-нибудь локальное на 7B», если оно не держит длинный контекст и не проходит верификацию человеком.

После этой развилки бренд модели становится вторичным. Именно поэтому в одном проекте одновременно могут жить YOLO12 для линии, Prophet для спроса, Qwen3.5 для дешёвого корпоративного чата и GPT-5.4 или Claude Opus 4.7 только для редких сложных кейсов.

Шкала 1. Сложность рассуждения: S → XXL

Ниже — рабочая сетка для промышленного проекта. Это не ГОСТ и не вендорский стандарт, а управленческая модель выбора внутри модуля p.2.

Практический смысл этой шкалы простой: S и M — зона частой переплаты, L — рабочая середина большинства офисных кейсов, XL и XXL — редкие дорогие сценарии, где ошибка дешёвой модели потом возвращается ручной переделкой.

flowchart TD
    A[Есть задача] --> B{Нужен ли вообще языковой вывод?}
    B -->|Нет| C[Берите специализированную модель: CV, time series, anomaly]
    B -->|Да| D{Нужно ли многошаговое рассуждение?}
    D -->|Нет| E{Нужен ли только JSON или извлечение полей?}
    E -->|Да| F[Малая или средняя модель, а лучше rules/NER]
    E -->|Нет| G[Средняя LLM]
    D -->|Да| H{Контекст длинный и документов много?}
    H -->|Да| I[Frontier-class модель или каскад с длинным контекстом]
    H -->|Нет| J[Сильная средняя модель]
    I --> K{Цена ошибки высокая?}
    K -->|Да| L[Human-in-the-loop и верификация обязательны]
    K -->|Нет| M[Можно автоматизировать частично]

Шкала 2. Цена ошибки: здесь определяется не качество, а режим управления риском

Эта шкала важнее, чем кажется. Одна и та же модель может быть достаточной для двух задач с одинаковой сложностью текста, но разной стоимостью ошибки.

Вывод один: с ростом цены ошибки сначала растёт объём контроля, а не размер модели. Формула «дороже модель = можно автоматизировать сильнее» неверна. Для критичных действий в технологическом контуре LLM должна оставаться советчиком, а не исполнительным контуром. Это особенно важно для тем КИИ и АСУ ТП из уроков p.3/02 и p.3/03.

Шкала 3. Latency и объём: не всё, что «умнее», годится в SLA

В реальном проекте модель проигрывает не по benchmark, а по времени ответа и способности переварить нужный объём входа.

• Realtime — зона десятков миллисекунд; обычно это не LLM, а CV или специализированная модель на edge. Примеры: YOLO12 для детекции объектов, Anomalib для нешаблонных дефектов (Ultralytics YOLO12; Anomalib GitHub).
• Chat — секунды, а не минуты. Здесь выигрывают средние модели или API-модели с приемлемой стоимостью и стабильным контекстом.
• Batch — ночь, регламентный прогон, аналитика. Тут можно включать более тяжёлые модели и длинные пайплайны.
• Long-context — сотни страниц, большие пакеты документов, мультимодальный набор. Здесь важно не только «ум», но и реальный размер контекстного окна: GPT-5.4 — 1M tokens, Claude Opus 4.7 — 1M tokens, Gemini 3.1 Pro — 1M tokens (1,048,576 input tokens), GigaChat 2 Max — 128 000 tokens (OpenAI Models; Anthropic Models Overview; Gemini 3.1 Pro; GigaChat 2 Max).

Здесь полезно запомнить один грубый, но рабочий принцип: чем ближе задача к линии, тем меньше должна быть модель и тем больше шанс, что это вообще не LLM.

Матрица: промышленная задача → класс модели → примеры → контур

Эта матрица нужна для двух вещей: не покупать frontier-model там, где достаточно средней или малой, и не тащить малую LLM туда, где нужен длинный проверяемый reasoning.

Где полезны конкретные модельные семейства

Ниже — не рейтинг, а рабочее позиционирование.

• GPT-5.4, Claude Opus 4.7 и Gemini 3.1 Pro — верхний слой для сложного reasoning и длинного контекста: 1M, 1M и 1,048,576 входных токенов соответственно (OpenAI Models; Anthropic Models Overview; Gemini 3.1 Pro).
• GigaChat 2 Max и YandexGPT Pro 5.1 — белый российский корпоративный слой, когда критичны русский язык, договор и предсказуемый контур (GigaChat 2 Max; Yandex AI Studio pricing).
• Qwen3.5, DeepSeek V3, GLM-4.5, Llama 3.3 70B, Mistral Small 4 — open-weight сегмент для локального reasoning-контура; выбор между ними — уже вопрос железа и инференс-стека (Qwen3.5; DeepSeek-V3; GLM-4.5; Llama 3.3 70B; Mistral Small 4).
• Phi-4, T-Pro 2.0 и Saiga — полезны как дешёвый локальный нижний и средний слой; у Phi-4 русский продакшн — нужна проверка, потому что модель ориентирована прежде всего на английский (Phi-4; T-Pro 2.0; Saiga/YandexGPT 8B).

Когда LLM вообще не нужна

Самая полезная фраза для CDTO в 2026 году звучит так: «Не всё AI — это LLM».

Если задача выглядит так, берите специализированный класс модели сразу:

• визуальный контроль качества — YOLO12, Detectron2, Anomalib;
• нешаблонные дефекты и one-class контроль — Anomalib;
• спрос, загрузка, прогноз, энергопотребление — Prophet, StatsForecast, NeuralForecast / Nixtla;
• анализ коротких структурированных полей — rules, regex, NER, классификатор;
• OCR и document parsing — не обязательно LLM-first, а часто OCR + layout-parser + маленькая LLM только на последней миле.

Именно здесь рождается большая часть экономии: вы снижаете не только стоимость inference, но и сложность железа, контура данных и объяснимости результата.

Практический алгоритм выбора модели

1. Отрежьте задачи, где LLM не нужна. Если это детекция, прогноз или аномалия, не начинайте с чата.
2. Поставьте задаче класс S/M/L/XL/XXL. Одного этого уже хватает, чтобы отсечь половину лишних закупок.
3. Определите цену ошибки. Она скажет, нужен ли вам человек на финале и можно ли делать auto-action.
4. Проверьте контур данных. Если есть ПД, КИИ или санкционные ограничения, возвращайтесь к урокам p.3/01, p.3/02 и p.3/05.
5. Только теперь сравнивайте 2–4 модели одного класса. Не десять подряд. Сравнивайте внутри класса задач, а не «все со всеми».
6. Замеряйте на своих кейсах. Не на общих benchmark, а на реальных регламентах, письмах, журналах, фотографиях дефектов и исторических рядах.
7. Фиксируйте порог качества письменно. Иначе команда почти всегда будет просить модель «ещё на 2% лучше», даже если бизнес это не окупает.