Урок 4: Матрица «задача × модель × контур» — постер-шпаргалка для AI-чемпиона

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

• За 3-5 минут выбирать стартовый контур для типовой промышленной AI-задачи
• Отличать задачи, где нужен LLM, от задач, где правильнее взять CV, forecasting или anomaly detection
• Быстро отсекать опасные сценарии: ПД, КИИ, иностранный SaaS, прямое воздействие на оборудование
• Читать матрицу как управленческий инструмент: задача → тип модели → контур → бюджетный класс
• Ставить команде корректное ТЗ без фразы «давайте просто подключим GPT»

Эта шпаргалка нужна до пилота, а не после него. Сначала вы выбираете не модель, а рамку решения: где живут данные, какой класс ошибки допустим и нужен ли вообще LLM. Юридическая граница уже разобрана в уроке 1 про персональные данные, уроке 2 про КИИ и уроке 5 про санкционный контур. Здесь мы превращаем эти ограничения в практическую таблицу выбора.

flowchart TD
    A[Есть новая задача] --> B{Результат влияет на оборудование или безопасность?}
    B -->|Да| C[Сразу контур 5-6 и человеческая валидация]
    B -->|Нет| D{Есть ПД, КТ или чувствительные документы?}
    D -->|Да| E[Проверить допустимость контура по урокам p.3/01 и p.3/05]
    D -->|Нет| F{Задача про текст или про сигнал?}
    F -->|Текст и документы| G[Смотреть LLM или RAG]
    F -->|Изображение, ряд, аномалия| H[Сначала CV или TS-модель]
    G --> I{Нужен черновик или решение?}
    I -->|Черновик| J[Средняя или малая модель]
    I -->|Решение с высокой ценой ошибки| K[Топ-модель плюс валидация]
    H --> L[Edge, on-prem или private VPC]

Как читать матрицу

В колонке «Контур» используются шесть контуров из урока 1 этого модуля:

• 1 — consumer public
• 2 — public API
• 3 — облако enterprise-класса
• 4 — private VPC / dedicated tenant
• 5 — on-prem / self-hosted
• 6 — air-gap

Бюджет в таблице дан не суммой, а классом. Это намеренно. В одном заводе «дорого» — это пять инженеров и один локальный сервер, в другом — годовая лицензия на private VPC. Детальный TCO будет в уроке 6. Здесь достаточно четырёх меток:

• S — пилот или точечная автоматизация, обычно API или уже существующая инфраструктура
• M — отделенческий контур, интеграция в процесс, но без отдельной стойки под проект
• L — цеховой или заводской сценарий с локальным inference, журналированием и эксплуатацией
• XL — критичный контур, 24/7, высокая цена простоя или обязательные меры ИБ

Постер-шпаргалка: задача × модель × контур

Размер в таблице — это ориентировочный стартовый класс модели, а не рекомендация всегда брать «большой» вариант. Если задачу закрывает малая или специализированная модель, это и есть правильный первый выбор.

Что эта таблица говорит жёстко

Первый жёсткий вывод: не каждая текстовая задача — LLM-задача. Там, где данные выглядят как поток изображений, сенсоров или таблиц, стартовать нужно со специализированной модели. Для CV это обычно YOLO/Detectron2/MMDetection-класс; для редких дефектов — Anomalib; для прогноза — Prophet, Nixtla, sktime и близкие библиотеки (Detectron2; MMDetection; Anomalib; Prophet; Nixtla).

Второй жёсткий вывод: если ответ модели может повлиять на оборудование, режим безопасности или юридически значимое решение, модель не должна быть последней инстанцией. PLC-code generation, HSE-разбор и анализ первопричин всегда требуют детерминированного валидатора и человека в цепочке согласования. Это не перестраховка. Это нормальный промышленный дизайн.

Третий жёсткий вывод: для русскоязычного локального контура open-weight рынок уже зрелый. В исследовательском паке по модулю p.2 зафиксированы T-Pro 2.0 как 33B open-weight модель с MERA 0.660, Qwen3 как базовое open-family для корпоративного деплоя и Llama 3.3 70B как зрелый вариант для многоязычного использования (T-Pro 2.0 model card; Qwen3 repository; Llama 3.3 70B model card). Это означает простую вещь: для контуров 5-6 у вас уже есть рабочий выбор помимо закрытых западных API.

Где матрица чаще всего ломается

1. Команда ставит в одну корзину LLM и CV. Если задача начинается словами «увидеть дефект», «поймать отсутствие СИЗ», «заметить отклонение на видео», берите CV первым, а LLM — только для описания результата оператору.

2. RAG-проект пытаются лечить большей моделью. Если помощник по регламентам врёт, причина обычно не в том, что модель «слишком маленькая», а в OCR, chunking, retrieval и плохой базе документов.

3. В табличной задаче покупают флагманскую модель, хотя нужен классификатор. Классификация обращений, маршрутизация писем, разметка актов и претензий часто закрываются малой моделью или даже обычным классификатор без дорогого reasoning.

4. Всё чувствительное отправляют в внешний API «на пилот». Для ПД это сразу вопрос к уроку p.3/01. Для КИИ — к уроку p.3/02. Для западного SaaS в санкционном контуре — к уроку p.3/05.

5. ТЗ формулируют как «нужен AI-помощник». Правильное ТЗ звучит так: «Нужен grounded assistant по 800 документам с ответом не дольше двух минут, только в контуре 5, с журналом источников и без отправки ПД наружу».

Когда имеет смысл тестовый прогон на arckep.ru

arckep.ru полезен не как production-контур, а как полигон сравнения. Его место — в задачах, где вы хотите быстро понять, какой класс модели вообще нужен, не поднимая инфраструктуру.

Подход рабочий в трёх сценариях:

• сравнить 2-3 топовые модели на синтетическом кейсе «ответ на претензию» или «сводка по нескольким PDF»;
• проверить, нужен ли вам reasoning-класс вообще, или задача уверенно закрывается более дешёвым стеком;
• обкатать формулировки промптов до того, как ИТ-команда поднимет private VPC, локальный inference или корпоративный gateway.

Но правило здесь простое: реальные ПД, договоры, технологические карты, аварийные отчёты и всё, что относится к значимому объекту КИИ, в такой тестовый прогон не уходят. Для этого модуль p.3 уже написан.

Красные флаги: когда по матрице надо не «выбирать модель», а останавливать проект