Урок 7: Малые специализированные модели — не всё AI это LLM

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

• Отличать задачи, где LLM вообще не нужен, от задач, где он полезен только как верхний слой интерфейса
• Выбирать между YOLO, Detectron2, MMDetection и Anomalib для контроля качества и визуальной инспекции
• Подбирать стек для прогнозирования и аномалий во временных рядах: Prophet, Nixtla, sktime, darts, PyOD
• Понимать, какие Document AI-инструменты можно брать в production, а какие упираются в лицензию
• Ставить интегратору правильный вопрос: «какая специализированная модель решит задачу быстрее, дешевле и безопаснее, чем LLM»

Главная ошибка в промышленном AI — начинать разговор с ChatGPT. На заводе большая часть типовых задач живёт не в тексте, а в изображениях, сигналах, временных рядах и сканах документов. Там выигрывают не универсальные LLM, а специализированные модели: детекция дефектов, one-class anomaly detection, forecasting, OCR и document parsing. Универсальную цифру «80% производственных задач не требуют LLM» как отраслевой закон я не использую: без отдельного исследования по вашему предприятию это была бы натяжка. Но для большинства типовых сценариев цеха, ОТК и планирования специализированный стек действительно рациональнее.

flowchart TD
    A[Какая задача?] -->|Фото, видео, камера| B[CV-модель]
    A -->|Сигналы, датчики, спрос, отказы| C[Time series / anomaly]
    A -->|PDF, сканы, накладные, акты| D[Document AI]
    A -->|Свободный диалог, поиск по регламентам, суммаризация| E[LLM или RAG]
    B --> F{Нужен текстовый отчёт?}
    C --> G{Нужен текстовый отчёт?}
    D --> H{Нужно объяснение на естественном языке?}
    F -->|Да| I[LLM как верхний слой]
    G -->|Да| I
    H -->|Да| I

Где специализированные модели выигрывают сразу

Практическое правило простое: если задача описывается как «увидеть», «поймать отклонение», «спрогнозировать», «вытащить поля», то сначала ищите не LLM, а специализированную модель. LLM подключайте потом — для объяснения результата, суммаризации смены, ответа инженеру или генерации письма по итогам анализа.

1. Компьютерное зрение для ОТК: YOLO, Detectron2, MMDetection

Для визуального контроля на производстве нужен стек, который быстро учится на размеченных изображениях и уверенно работает на edge-устройстве или локальном сервере. Здесь LLM не конкурент. Она не умеет стабильно рисовать bounding boxes и не даёт приемлемой latency на видеопотоке.

У Ultralytics в 2026 году production-базой остаётся YOLO11, выпущенная 10 сентября 2024 года; в документации сама компания пишет, что для стабильных production-нагрузок рекомендует YOLO11 и YOLO26, а код распространяется по AGPL-3.0 или enterprise-лицензии (YOLO11 docs, Ultralytics docs). YOLO12 в публичной коммуникации Ultralytics фигурирует как отдельный релиз от 18 февраля 2025 года с attention-centric архитектурой, но для производственного baseline безопаснее фиксировать конкретный checkpoint и лицензионный режим — иначе нужна проверка (Ultralytics blog, 26.02.2025).

Что важно управленцу:

• YOLO удобна, но AGPL — это не «мелкий юридический шрифт». Если подрядчик ставит YOLO в коммерческий production без enterprise-лицензии, это надо отдельно согласовать с юристом.
• Detectron2 и MMDetection обычно спокойнее для корпоративного внедрения: Apache 2.0 проще в закупке и в комплаенсе.
• LLM можно подключать поверх CV, но не вместо него. Например: CV локально находит дефект, а LLM делает сменный комментарий «какой тип брака повторяется и что проверить технологу».

2. Когда классов брака мало или дефект вообще неизвестен: Anomalib

Классическая CV-детекция хороша там, где вы заранее знаете классы: царапина, вмятина, непрокрас, скол. Но в ОТК часто другая реальность: нормальных изделий много, а дефектов мало, и они каждый раз выглядят чуть по-новому. Для этого существует visual anomaly detection.

Anomalib — открытая библиотека для anomaly detection с фокусом на изображения и видео. Официальный репозиторий описывает её как библиотеку для benchmarking, разработки и деплоя алгоритмов аномалий, с CLI и Python API, готовыми датамодулями вроде MVTecAD, поддержкой edge inference и экспортом части моделей в OpenVINO (GitHub).

Как это применять в производстве:

• собрать эталонный набор нормальных деталей или поверхностей;
• обучить one-class модель видеть норму;
• на линии считать отклонением всё, что выбивается из неё;
• использовать тепловую карту аномалии как триггер на повторную проверку ОТК.

Это особенно полезно там, где невозможно заранее описать весь каталог брака. Например, новая линия, сложная текстура, партия сырья плавает, а дефектов исторически мало.

3. Временные ряды: Prophet, Nixtla, sktime, darts, PyOD

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

Prophet от Meta — библиотека forecasting для рядов с трендом, сезонностью и календарными эффектами; репозиторий описывает её как процедуру прогнозирования на аддитивной модели, устойчивую к пропускам и сдвигам тренда, лицензия MIT (GitHub). Это хороший старт для бизнес-планирования, где нужна интерпретируемая модель и быстрый baseline.

Nixtla развивает целую линейку: StatsForecast, NeuralForecast, MLForecast, HierarchicalForecast. У StatsForecast и NeuralForecast официальная лицензия Apache-2.0; первый пакет закрывает статистические модели вроде AutoARIMA и ETS, второй — нейросетевые модели вроде NBEATS, TFT и PatchTST (StatsForecast, NeuralForecast, Nixtla org).

sktime — это единый каркас для ML по временным рядам с лицензией BSD-3-Clause (GitHub org, PyPI). Darts от Unit8 — user-friendly библиотека для forecasting и anomaly detection на рядах с лицензией Apache-2.0 (GitHub). PyOD — библиотека для outlier detection с BSD-2-Clause; в 2026 году её репозиторий заявляет более 60 детекторов для табличных, временных, графовых, текстовых и image-данных (GitHub).

Практическое правило: для задачи «спрогнозируй» берите forecasting-библиотеку; для задачи «поймай странный режим» — anomaly detection; для задачи «объясни инженеру, что случилось» можно добавить LLM как верхний слой над уже посчитанными сигналами.

4. Document AI: OCR, layout, поля, но с жёсткой проверкой лицензии

С документами промышленный AI ломается чаще всего на двух местах: качество распознавания и лицензия. Если вы автоматизируете акты, накладные, протоколы испытаний, паспорта изделия или сканы первички, вам нужен не разговорный интеллект, а надёжный стек OCR и document parsing.

PaddleOCR — один из самых безопасных production-вариантов: официальный репозиторий сообщает о поддержке 100+ языков, лицензии Apache 2.0 и позиционирует проект как OCR toolkit для преобразования PDF и изображений в структурированные данные (GitHub). Для русскоязычной первички это удобная рабочая лошадка: сначала OCR и layout, потом уже downstream-логика.

Donut — OCR-free transformer для document understanding. Код и модель naver-clova-ix/donut-base опубликованы под MIT (GitHub, Hugging Face). Это хороший вариант для экспериментов с form understanding и extraction, когда вы готовы дообучать модель под собственный тип документов.

Nougat хорош именно для научных PDF и формул: официальный репозиторий пишет, что код MIT, а веса CC-BY-NC (GitHub). Для корпорации это значит простое правило: для production-парсинга договоров и техдоков Nougat — обычно не первый выбор.

Surya умеет OCR, layout analysis, reading order и table recognition в 90+ языках; репозиторий прямо пишет, что код GPL, а веса — modified AI Pubs Open Rail-M, бесплатно для research, personal use и стартапов с финансированием или выручкой ниже $2 млн (GitHub). Для крупного промышленного заказчика это почти всегда отдельный лицензионный разговор.

LayoutLMv3 полезен как foundation model для Document AI, но модель microsoft/layoutlmv3-base на Hugging Face помечена лицензией CC BY-NC-SA 4.0 (Hugging Face). Значит, брать её в корпоративный production без отдельной правовой оценки нельзя. Именно поэтому тезис «LayoutLMv3 не для коммерческого prod» для практики 2026 года уместен.

5. Датасеты, с которых имеет смысл начинать

Открытые датасеты нужны не для того, чтобы «обучить финальную модель на Kaggle». Они нужны, чтобы команда быстро проверила подход, стек и pipeline разметки.

Как выбрать специализированную модель без лишнего шума

1. Сначала назовите тип сигнала. Фото, видео, табличные признаки, временной ряд, скан PDF — это уже сужает стек сильнее, чем разговор о «самой умной модели».

2. Проверьте, есть ли готовый baseline. Для стали — NEU или Severstal, для anomaly — MVTec, для рядов — Prophet или Nixtla, для OCR — PaddleOCR.

3. Смотрите не только на качество, но и на лицензию. AGPL, GPL и non-commercial ограничения надо отсекать до пилота, а не после демонстрации CFO.

4. Отделите core-модель от верхнего слоя. CV, forecasting и OCR решают ядро задачи. LLM, если нужна, подключается сверху для интерфейса, пояснения и отчёта.

5. Свой датасет готовьте как можно раньше. Открытые наборы помогают стартовать, но production-качество почти всегда упирается в ваш материал, вашу камеру, ваш бланк и ваш процесс.

6. Если данные чувствительные, сразу сверяйте контур. Особенно для документов и изображений с людьми, пропусками, табелями и клиентскими реквизитами — это уже зона p.3/01.