Задача: заменить субъективную оценку воспроизводимой процедурой

Big Saint Food — испанская микрокомпания из 1–9 сотрудников, которая работает с животноводческим и агропродовольственным сектором и выпускает иберийскую продукцию. Один из её процессов зависел от экспертной оценки качества отдельных отрубов по внешним признакам. Такая оценка полезна, но плохо масштабируется: результат зависит от опыта конкретного человека, условий осмотра и того, насколько одинаково сотрудники понимают классы качества.

Вместо немедленной покупки промышленного 3D-сканера компания вместе с AIR Institute и хабом DIGIS3 начала с проверки гипотезы. На площадке изучили рабочее место, сделали первые фотографии для калибровки и выбрали 2D-съёмку обычным смартфоном. Целью было понять, достаточно ли доступного изображения для более систематичной классификации, а не автоматизировать весь контроль с первого дня.

Кейс опубликован Европейской сетью центров цифровых инноваций 13 июля 2026 года. Он полезен малому бизнесу не отраслью как таковой, а последовательностью решений: сначала стандартизировать получение данных, затем проверить модель и только после этого вкладываться в оборудование и интеграцию.

Почему смартфон оказался важнее «самой умной» модели

В компьютерном зрении модель видит не физический объект, а массив пикселей. Если угол, расстояние, фон и освещение каждый раз меняются, алгоритм может научиться распознавать съёмочную обстановку вместо качества продукта. Поэтому выезд на производство оказался не формальностью: команда определила положение камеры, использование штатива и однородного фона.

Обычная камера смартфона была выбрана вместо 3D-сканирования ради доступности, меньшей вычислительной сложности и быстрого сбора данных. В кейсе указано, что снимать образцы мог оператор без специальной технической подготовки. Это снижает стоимость входа, но не отменяет протокол съёмки: «любой смартфон в любых условиях» и «стандартный смартфон на фиксированном рабочем месте» — две разные архитектуры.

Для российского малого производства аналогичный пилот стоит начинать с простого вопроса: можно ли обеспечить одинаковое изображение на каждой смене? Если нет, бюджет сначала нужен на свет, держатель, фон, маркировку партии и инструкцию оператору. Более дорогая нейросеть не исправит нестабильный источник данных.

Как был устроен контур

Из официального описания известны основные компоненты:

  • 2D-фотографии со стандартной камеры смартфона;
  • извлечение признаков из изображений и обучение моделей классификации;
  • проверка через macro‑F1, чтобы учитывать качество по каждому классу, включая редкие;
  • FastAPI как серверный интерфейс;
  • Docker-контейнеры для воспроизводимого развёртывания;
  • AWS EC2 как вычислительная инфраструктура;
  • рабочая платформа, доступная компании для использования.

Macro‑F1 усредняет F1 по классам без веса, пропорционального их частоте. Поэтому многочисленный «нормальный» класс не может полностью скрыть слабое распознавание редкого дефекта. Это разумный выбор для несбалансированной выборки, но одной средней метрики недостаточно для производственного решения.

Для каждого класса нужны матрица ошибок, precision, recall и цена ошибки. Если система ошибочно понижает класс хорошего продукта, бизнес теряет маржу. Если пропускает проблемный образец, возникают претензии к качеству и прослеживаемости. Порог должен отражать эти разные последствия, а не только максимизировать общий балл.

Чего в публикации нет — и почему это важно

Официальный кейс не сообщает фактическое значение macro‑F1, размер набора изображений, количество классов, схему разделения train/test и результаты на новых партиях. Не указаны задержка ответа, стоимость одного анализа, доля ручной перепроверки и устойчивость к другому смартфону или освещению.

Поэтому материал подтверждает создание и рабочее развёртывание прототипа, но не доказывает готовность к полностью автономной сортировке. Авторы сами отмечают, что сокращение времени, вариативности и ошибок пока является потенциальным эффектом: для количественной оценки нужен более долгий период эксплуатации.

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

Что действительно изменилось у компании

По методике Digital Maturity Assessment общий показатель вырос с 33% до 40%. Компонент Human-Centric Digitalisation поднялся с 39% до 59%, Automation & Artificial Intelligence — с 36% до 52%, Green Digitalisation — с 25% до 35%. При этом Data Governance снизился с 52% до 39%, а Digital Readiness вырос только с 16% до 19%.

Такой разнонаправленный результат полезнее безусловно положительного графика. Он показывает, что внедрение одной AI-функции не закрывает управление данными и общую готовность инфраструктуры. Возможно, повторная оценка стала строже или выявила новые требования; официальный материал причины снижения не раскрывает, поэтому домысливать их нельзя.

Отдельно компания получила €30 000 финансирования по программе PADIH благодаря поддержке в подготовке заявки. Это подтверждённый финансовый результат, но его нельзя считать экономией от модели: он относится к механизму поддержки проекта.

Какие данные понадобятся в похожем пилоте

Минимальная единица данных — не просто фотография, а связанный набор:

  • идентификатор партии и образца;
  • класс, подтверждённый уполномоченным экспертом;
  • версия инструкции и критериев качества;
  • устройство, положение камеры и параметры съёмки;
  • условия освещения и фон;
  • дата, смена и оператор;
  • решение модели, уверенность и итоговое решение человека;
  • причина расхождения, если эксперт исправил результат.

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

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

Как адаптировать архитектуру для локального контура

Для малой компании рабочая схема может быть компактной:

1. Смартфон или закреплённая камера отправляет снимок во внутренний веб-интерфейс.
2. Сервис проверяет размер, формат, резкость и соответствие зоне съёмки.
3. Локальная модель возвращает класс и уверенность.
4. Бизнес-правило автоматически принимает только безопасные и уверенные случаи.
5. Остальные изображения попадают в очередь эксперту вместе с соседними классами и историей партии.
6. Подтверждённое решение записывается в учётную систему, а исправление — в набор для последующей переоценки.

FastAPI и Docker из исходного кейса не обязательны, но хорошо иллюстрируют разделение интерфейса и модели. Инференс можно разместить на небольшом сервере с GPU или CPU — выбор зависит от разрешения, архитектуры модели и требуемого времени ответа. Для нескольких десятков проверок в час часто важнее простота поддержки, чем максимальная пропускная способность.

Не стоит сразу подключать автоматический сортировщик. На первом этапе модель может быть «вторым мнением»: показывает оценку и расхождение с человеком. Следующий уровень — автоматическое подтверждение только простых случаев. Механическое действие допустимо после проверки отказобезопасности и экономики ошибок.

Экономика: считать не камеру, а стоимость решения

Смартфон делает пилот дешёвым, но полная стоимость складывается из других статей:

  • время экспертов на определение классов и разметку;
  • организация стабильного рабочего места для съёмки;
  • разработка, интеграция и тестирование интерфейса;
  • сервер или облачные вычисления;
  • повторная проверка спорных случаев;
  • мониторинг сдвига данных и переобучение;
  • простой процесса при недоступности системы;
  • стоимость ложного принятия и ложного отклонения.

Базовая модель расчёта проста: сравнить ежемесячную стоимость существующей проверки с затратами на новый процесс, добавить цену ошибок и учесть объём, который действительно можно обработать без дополнительного сотрудника. Если эксперт всё равно перепроверяет 100% снимков с той же скоростью, модель пока улучшает воспроизводимость или обучение, но не экономит труд.

Порог окупаемости появляется, когда система надёжно снимает часть однотипной работы, снижает дорогие ошибки или позволяет обслужить больший объём без пропорционального роста штата. Эти эффекты нужно измерять отдельно.

Пилот на четыре недели

Практический план для одного визуального процесса:

  • Неделя 1: зафиксировать классы, цену ошибок, протокол съёмки и текущие время/точность эксперта.
  • Неделя 2: собрать репрезентативные партии, провести двойную разметку спорных образцов и проверить качество изображений.
  • Неделя 3: обучить базовую модель, посчитать macro‑F1, метрики по классам и матрицу ошибок на отложенных партиях.
  • Неделя 4: включить режим второго мнения, измерить время, долю согласия, исправления эксперта и стоимость одного подтверждённого решения.

Продолжать стоит, если качество сохраняется на новых партиях, есть понятная зона автоматического решения и экономический эффект не исчезает после учёта ручной очереди. Если модель нестабильна, результат пилота всё равно полезен: он показывает, нужны ли новые данные, другая оптика или отказ от автоматизации этого участка.

Что взять руководителю

Главный урок Big Saint Food — начинать не с дорогой камеры и не с названия модели, а с воспроизводимого способа получить данные. Смартфон может быть достаточным датчиком для проверки гипотезы, если рабочее место стандартизировано, классы определены экспертами, редкие случаи не теряются в средней метрике, а человек сохраняет право последнего решения.

Перед бюджетом на промышленное зрение попросите команду провести один фиксированный эксперимент: одинаковая камера, одинаковый свет, новые партии, метрики по каждому классу и модельная экономика. Такой тест дешевле 3D-сканера и намного информативнее демонстрации на нескольких удачных фотографиях.