Модель в Jupyter выглядела убедительно: F1 выше 0.9, демо на трёх PDF прошло без ошибок. Через две недели в production точность упала, пользователи жаловались на «галлюцинации» полей, а команда не могла ответить, какая версия модели сейчас на сервере. Это классический разрыв между ML-прототипом и ML-продуктом.

В OtherCode мы строим Python-контуры для OCR и NLP в URAP AI, для разбора документов в Content Factory и для вспомогательных классификаторов в промышленных и SaaS-продуктах. Ниже — как мы доводим модели до production: версионирование, eval-наборы, CI, мониторинг дрифта и жёсткое разделение «эксперимент» и «релиз».

Прототип ≠ продукт: где ломается цепочка

Прототип отвечает на вопрос «можно ли». Продукт отвечает на вопросы «стабильно ли», «сколько стоит», «как откатить» и «кому звонить ночью».

В URAP AI распознавание и извлечение полей из документов — не разовое демо, а ежедневный поток: разные сканеры, качество печати, шаблоны актов и счетов. Без MLOps-контура любая «улучшенная модель» — лотерея.

Архитектура ML-контура в OtherCode

Типовой путь от сырых документов до ответа API:

[Загрузка документа]
      ↓
[Предобработка / OCR]  ← Python-сервис (URAP)
      ↓
[Извлечение / NLP / классификация]
      ↓
[Валидация + rule engine]
      ↓
[API / очередь Redis] → [PostgreSQL]
      ↓
[Feedback / разметка] → [Eval set] → [Retrain]

Python здесь — основной язык пайплайна: предобработка изображений, OCR, постобработка текста, лёгкие классификаторы и оркестрация вызовов LLM. Тяжёлые модели упаковываем в отдельные контейнеры, лёгкие — в worker рядом с API.

Для асинхронных задач (длинные PDF, пакетная обработка) используем Redis-очереди — тот же подход, что и в остальных backend-сервисах студии. Подробнее про очереди и кэш мы писали в статье про Redis.

Как это стыкуется с остальными продуктами

• URAP AI — ядро OCR/NLP: модели и пайплайны версионируются, eval прогоняется в CI перед релизом.
• Content Factory (Telegram) — генерация и разбор контента: правила + модели, без «магического» промпта в проде без метрик.
• Synapse Stream / Game API — геоданные и realtime на PostGIS; ML здесь точечный (классификация событий), но тот же принцип: модель = артефакт с версией.
• Typhoon (STM32/Modbus) и Galvatec — телеметрия и промышленные контуры; ML не «вместо» протокола, а поверх нормализованных сигналов.
• Diom (Flutter) и клиенты на Next.js — UI показывает confidence и даёт human-in-the-loop, а не слепо доверяет модели.

Версионирование моделей и данных

Без версий нельзя воспроизвести баг и нельзя честно сравнить две модели.

Что мы версионируем

Правило студии: один релиз = один неизменяемый артефакт (Docker-образ с зафиксированными весами и конфигом). Не «подтянули свежие веса на VPS ночью».

Семантические версии для моделей

Используем схему, понятную продукту:

• MAJOR — ломающее изменение выхода (другая схема JSON, другие классы).
• MINOR — улучшение качества при совместимом API.
• PATCH — hotfix препроцессинга, баг в постобработке.

В API URAP клиент видит model_version в ответе — это упрощает разбор жалоб: «в v2.3.1 поле ИНН ломалось на сканах с поворотом».

Eval-наборы: метрика важнее ощущения

Демо на «красивых» документах обманывает. Eval-набор — это контракт качества.

Как собираем eval в URAP

1. Стратификация: типы документов (счёт, акт, паспорт, произвольный скан), качество (хороший/шум/повёрт), источники (мобильное фото / МФУ).
2. Hold-out: тестовый набор не участвует в обучении и в подборе порогов.
3. Золотые поля: не только «текст в целом», а точность по ключевым полям (ИНН, сумма, дата, номер договора).
4. Human baseline: сколько ошибок делает оператор — чтобы не гнаться за нереалистичным 100%.

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

Практика OCR-пайплайнов (предобработка, движки, таблицы) разобрана отдельно: OCR и распознавание документов на Python.

CI для ML: не только «собрать образ»

GitLab CI у нас — общие docker runners. Для ML-пайплайна типичные стадии:

1. lint / unit — чистый Python: парсеры, валидаторы схемы, препроцессинг без GPU.
2. smoke inference — прогон 5–20 эталонных документов на CPU-образе (быстро ловит сломанный импорт и несовместимость зависимостей).
3. eval job — полный eval на runner с нужными ресурсами; артефакт — JSON/HTML отчёт.
4. build & push — образ в registry только если eval прошёл пороги.
5. deploy — staging → production (PM2/compose на VPS или сервис в Yandex Cloud), с возможностью отката на предыдущий тег.

Параллельные runners ускоряют «обычный» backend и ML-ветки, но GPU-eval планируем отдельно: дорогой ресурс не должен блокировать каждый merge мелкого фикса в UI Next.js.

Важно: notebook не является артефактом релиза. Код эксперимента переносится в пакет (src/urap_ocr/...), покрывается тестами и только потом попадает в образ.

Мониторинг дрифта и деградации

Модель стареет не потому что «веса портятся», а потому что меняется мир: новые бланки, другой сканер в филиале, смена шрифта в ERP заказчика.

Что мониторим в production

В URAP feedback от оператора (исправленное поле) — золотой источник для следующего eval и дообучения. Без замкнутого цикла «ошибка → датасет → релиз» MLOps превращается в театр.

Rule engine рядом с моделью

Модель предлагает, правила страхуют. Для документов это критично:

• форматные проверки (ИНН, даты, суммы);
• согласованность полей («сумма прописью» vs число);
• маршрутизация: низкий confidence → очередь человека;
• запрет автозаписи в ERP без подтверждения на критичных полях.

Тот же принцип гибрида «ИИ + правила» мы используем, когда встраиваем LLM в продукты: модель не заменяет доменную логику. Общий взгляд на AI в продуктах — в материале Разработка с AI.

Инфраструктура: где крутятся модели

• Разработка: Docker Compose локально, те же образы, что уедут в CI.
• CI: GitLab docker runners; тяжёлый eval — по расписанию или по тегу ml-release.
• Production: для большинства сервисов othercode.ru и клиентских VPS RU — Docker + PM2 для Node-слоя, Python-workers в compose; при необходимости — Yandex Cloud (в т.ч. GPU под обучение/batch, не обязательно под каждый online-запрос).
• Стоимость: online-инференс стараемся держать на CPU/оптимизированных форматах (ONNX), GPU — для обучения и пакетных джобов.

Kubernetes включаем, когда реально нужны автоскейл и много сервисов с жёстким изоляционным контуром. Для многих продуктов студии compose + PM2 на выделенном VPS проще и дешевле — без потери дисциплины артефактов.

От эксперимента к API: рабочий процесс команды

Внутри студии ML-задача почти никогда не живёт «в голове одного data scientist». Типичный цикл для URAP или похожего контура:

1. Продукт формулирует SLA — какие поля критичны, какая доля ручной проверки допустима, какой p95 ответа API.
2. Собираем или расширяем датасет — с разметкой и источником (клиент, синтетика, публичные бланки только как черновик).
3. Базовый пайплайн без «тяжёлой» модели — правила + OCR + эвристики; это нижняя планка качества и стоимости.
4. Модель как улучшение — сравниваем с baseline на том же eval, а не с ощущением «стало умнее».
5. Упаковка — сервис с ясным контрактом JSON, таймаутами, идемпотентностью для очередей.
6. Канареечный выкат — часть трафика на новую версию, сравнение error rate и правок операторов.
7. Ретро после двух недель — что деградировало, какие типы документов добавить в train/eval.

Для Content Factory цикл короче: шаблоны и стоп-слова часто важнее fine-tune. Для Synapse/Game API классификаторы событий появляются точечно — только если правило не закрывает кейс. В Typhoon и Galvatec сначала нормализуем регистры и единицы измерения; «нейросеть на сыром Modbus» без словаря сигналов мы не делаем.

Роли и ответственность

Без владельца метрики модель «сиротеет» после первого релиза — это частая причина тихого дрифта.

Экономика инференса и очередей

Production ML упирается в деньги так же часто, как в F1.

• Синхронный путь — только для коротких документов и ясного UX-ожидания.
• Длинные PDF и пакеты филиалов — в Redis-очередь, статус задачи в PostgreSQL, webhook или polling для клиента.
• Кэш результатов по хешу файла экономит повторный OCR одного и того же скана.
• Батчинг на GPU имеет смысл, когда очередь стабильно непустая; иначе платим за простой карты.

На VPS RU и в Yandex Cloud мы явно разделяем бюджет online API и budget batch/retrain. Иначе «ночной эксперимент» внезапно становится строкой в счёте клиента.

Документация, которую реально читают

Минимум рядом с сервисом:

• как воспроизвести eval локально (Compose + фикстуры);
• таблица breaking changes API и model_version;
• runbook: «точность упала» → какие дашборды, как откатить тег, кого звать;
• описание полей feedback из UI оператора.

Это скучно по сравнению с новым fine-tune, но именно это отличает продукт студии от прототипа подрядчика.

Чеклист: готовность модели к production

• Есть версионированный train/val/test и описание источников данных
• Eval-метрики согласованы с бизнесом (не только «accuracy»)
• Модель упакована в immutable Docker-образ с конфигом
• CI прогоняет smoke + eval до деплоя
• В ответе API есть model_version
• Есть мониторинг latency, ошибок и proxy качества
• Есть план отката на предыдущий тег
• Human-in-the-loop на низком confidence
• Документирован retrain-процесс (кто, как часто, на каких данных)

Типичные ошибки, которых мы избегаем

1. Релиз «с ноутбука» — невоспроизводимо и небезопасно.
2. Один общий test set на все эксперименты — незаметный data leakage.
3. Оптимизация только average accuracy — просадка на редком, но дорогом классе документов.
4. Игнор latency — модель точнее на 2%, но p95 вырос втрое.
5. Нет владельца метрики — «ML-инженер ушёл, F1 никто не смотрит».

Итог

Python в OtherCode — не про красивые графики в Colab, а про управляемый путь: данные → eval → образ → CI → production → feedback. URAP AI живёт в этом контуре; соседние продукты (Synapse, промышленные интеграции, Flutter/Next.js-клиенты, Telegram Content Factory) забирают тот же инженерный стандарт: версия, метрика, откат.

Если нужна команда, которая доведёт OCR/NLP или классификаторы до стабильного API, а не до слайда — оставьте заявку.