Смоделируем ситуацию. Оператор металлообрабатывающего станка после каждого цикла кладёт деталь в один из двух лотков: красный — брак, зелёный — годная. Простая операция, два сценария.

Компания поставила видеоаналитику, чтобы контролировать этот процесс автоматически. Камеры подключили, сценарий настроили. Через неделю выяснилось: модель ошибается в 35% случаев. Рука оператора перекрывает лоток в момент укладки. Освещение между сменами разное. Лотки стоят вплотную, и на видео граница между ними размывается. Вендор сказал, что это ограничение модели — она не обучалась на таких условиях. Операторы отключили звук тревог через три дня из-за ложных срабатываний.

Система работает ровно так, как была обучена. Но задача оказалась сложнее, чем сценарий, под который разработали данное коробочное решение.

Мы в NeuroCore разрабатываем и внедряем ИИ-решения и интеллектуальную видеоаналитику уже 8 лет, а, значит, похожую картину мы видим регулярно. Компания покупает готовое решение, запускает, получает результат хуже ожидаемого, пытается настроить, убеждается что дело не в настройках. Проходит несколько месяцев. Деньги потрачены, задача не закрыта.

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

Что такое коробочное решение — и в чём его логика

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

Типичный набор сценариев коробочного решения (готовых модулей видеоаналитики):

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

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

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

Модель знает то, на чём обучалась. 

Она хорошо работает в условиях, близких к обучающей выборке вендора. Когда условия начинают расходиться — специфическое освещение, нестандартная одежда, непривычный угол камеры, редкий тип объекта — точность падает. Это не дефект архитектуры, это математика: модель экстраполирует от того, что видела. Чем дальше реальные данные от обучающих, тем менее уверенно она работает.

Вторая граница — логика события. Коробочный продукт фиксирует факт: человек в зоне, каска отсутствует, огонь в кадре. Но производственный процесс часто требует контекста: нарушение возникает только при комбинации условий, зависит от времени суток, от статуса соседнего оборудования, от того, какая операция выполняется прямо сейчас. Такую логику нельзя задать настройками — её нужно проектировать и писать под конкретный процесс.

Третья граница — интеграция. Большинство готовых решений умеют оповещать: алерт на экран, уведомление в мессенджер, запись в журнал системы. Но во многих производственных сценариях результат должен попасть в ERP, SCADA, WMS или систему согласований — и не просто как уведомление, а как структурированное событие, которое запускает следующий шаг в процессе. Это уже задача интеграции, которая выходит за рамки типового продукта.

Ни одна из этих границ не означает, что продукт сделан плохо. Она означает, что продукт сделан под определённую задачу — и при выходе за её рамки нужен другой подход.

Пять признаков, что готовое решение не закроет задачу

Это не теоретические критерии, это кейсы из реальной практики наших клиентов, которые обратились к нам после того как коробка уже куплена и запущена.

1. Задача выходит за пределы каталога сценариев. 
   
   Коробочные продукты покрывают задачи, которые можно сформулировать одним предложением: «человек без каски», «посторонний в зоне», «огонь в кадре». Если ваша задача требует нескольких предложений — это первый сигнал. 
   Контроль правильности установки детали на станке. 
   Проверка последовательности операций техпроцесса. 
   Соответствие укладки продукции спецификации по геометрическим параметрам. 
   Это не нишевые задачи — они есть на большинстве производств. Правда в другом: вендор готового продукта физически не может собрать обучающую выборку под каждое из тысяч предприятий-заказчиков. Это не упущение — это экономика продуктовой разработки. Он выбирает то, что покрывает максимальное количество клиентов стандартным решением.
    

2. Визуальные условия вашего объекта отличаются от стандартных. 
   
   Качество работы AI-модели компьютерного зрения напрямую зависит от того, насколько реальные данные похожи на обучающую выборку. 

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

3. Результат должен запускать действие в смежной системе, а не только оповещать. 
   
   Коробочные решения, как правило, хорошо реализуют последний шаг уведомления: алерт на монитор охраны, push-уведомление, запись в собственный журнал. 
   
   Но производственный и операционный контекст часто требует другого: событие должно создать задачу в системе управления техобслуживанием, заблокировать следующий шаг в MES до устранения нарушения, записать структурированную запись в ERP с привязкой к конкретному заказу, инициировать цепочку согласований в системе документооборота. Это не надстройка над готовым продуктом — это отдельная интеграционная задача, которая требует понимания архитектуры ваших систем и разработки под неё.
    
4. Логика события составная и контекстно-зависимая. 
   
   Готовый продукт фиксирует атомарные факты: объект есть или его нет, зона нарушена или нет. Производственная реальность устроена иначе: нарушение возникает только при одновременном выполнении нескольких условий, часть из которых визуальные, а часть — операционные. 
   
   «Паллета установлена неправильно» означает одно в зоне хранения и другое в зоне отгрузки. 
   «Оператор в опасной зоне» — нарушение при работающем оборудовании и норма при плановом обслуживании. 
   
   Такая логика не описывается слайдером чувствительности. Она проектируется как отдельный программный слой поверх модели — и этот слой пишется под конкретный регламент конкретного предприятия.
    
5. Готовое решение уже запускали — результат не устроил. 
   
   Это самый весомый из пяти признаков, потому что он основан не на предположениях, а на факте. Компания прошла полный цикл: выбор продукта, пилот, попытки донастройки, финальная оценка. Если на выходе из этого цикла точность недостаточна, логика не перестраивается, а интеграция не реализуется средствами продукта — это не проблема конкретного вендора. Это граница класса решений. Следующий шаг — не искать другую коробку, а менять подход.

Чем кастомная разработка отличается от готового продукта "из коробки"

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

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

Кастомная разработка начинается с другого места: с ваших данных.

1. Сбор данных на объекте. Мы выезжаем и снимаем видео в реальных условиях эксплуатации — с вашим освещением, вашими углами камер, вашей спецификой сцены. Паровой туман над литейной ванной, блики на глянцевых металлических поверхностях, контровой свет из производственного проёма, нестандартная цветовая температура ночной смены — всё это входит в обучающую выборку. Это принципиально: модель, обученная на данных из открытых источников или на стандартных производственных сценах, при переносе на ваш объект столкнётся со смещением распределения входных данных. Никакая донастройка не компенсирует то, чего модель не видела при обучении.

2. Разметка с предметной экспертизой. 

   Разметка — это не технический процесс расстановки bounding box'ов. Это фиксация экспертного знания в форме, которую понимает модель. «Дефект» на вашем производстве — это конкретный класс отклонений с конкретными границами приемлемого, которые определяет технолог, а не разметчик-аутсорсер. Разметчик без понимания контекста размечает по визуальному сходству, а не по смыслу — и модель учится не тому. Поэтому перед разметкой мы проводим калибровочную сессию с вашими технологами: формализуем критерии, согласовываем пограничные случаи, выстраиваем таксономию классов. Это занимает время, но определяет качество всего, что будет дальше.

3. Выбор архитектуры под задачу. 
   
   Компьютерное зрение — это не одна модель на все случаи. 
   
   Под задачу бинарной классификации «брак / не брак» оптимален один подход. 
   Под детекцию нескольких классов объектов с локализацией — другой. 
   Под попиксельную сегментацию зон — третий. 
   Под трекинг объектов во времени с анализом траектории — четвёртый. 
   
   Выбор архитектуры влияет не только на точность, но и на латентность инференса, требования к вычислительному железу и возможность работы на edge-устройствах без подключения к серверу. В коробочном продукте этот выбор сделан один раз для всех заказчиков. В кастомной разработке он делается под вашу задачу, ваши ограничения по железу и ваши требования к скорости отклика.
    
4. Логика события как отдельный программный слой. 
   
   Модель компьютерного зрения решает одну задачу: классифицировать или локализовать объект на входном кадре. Она говорит «вижу объект класса А в зоне Б с уверенностью 0.87». Что делать с этим результатом — отдельная задача, которая к самой модели отношения не имеет. Это слой бизнес-логики: нужно ли накапливать несколько последовательных детекций перед срабатыванием, чтобы отсечь единичные ошибки модели; как событие соотносится с состоянием смежного оборудования; какие исключения предусмотрены регламентом; какой приоритет у этого события относительно других. Именно здесь живёт ваш производственный регламент — не в слайдере чувствительности, а в коде, который проектируется под вас и меняется при изменении процесса.
    
5. Интеграция с инфраструктурой. 
   
   Результат работы системы должен попасть туда, где с ним будут работать: создать запись в ERP с привязкой к производственному заказу, передать событие в SCADA, обновить статус в WMS, сформировать протокол ОТК, инициировать задачу в системе технического обслуживания. Это не «отправить алерт на почту» — это двусторонняя интеграция через API или прямое взаимодействие с базой данных целевой системы. Такая интеграция требует понимания архитектуры ваших систем, их API-контрактов, прав доступа и логики обработки входящих данных на стороне приёмника.

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

Когда стоит начать с коробки

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

Готовое решение — правильный выбор, когда выполняются три условия одновременно: задача попадает в стандартный каталог сценариев вендора, визуальные условия объекта достаточно близки к тем, на которых обучалась модель, и на выходе нужен алерт, а не действие в смежной системе.

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

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

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

Коробка бывает и осознанным первым шагом к кастому — и это нормальная инженерная стратегия.

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

Граница между "берите коробку" и "нужен кастом" проходит не по бюджету и не по амбициям. Она проходит там, где заканчивается область применимости готового продукта: нестандартные визуальные условия, составная логика события, необходимость интеграции с инфраструктурой, специфика данных, которой нет в обучающей выборке вендора. Если хотя бы один из этих факторов присутствует — коробка не закроет задачу независимо от того, сколько времени потратить на настройку.

Кастом или коробка: в чём разница

Если коротко — вот чем они отличаются по ключевым параметрам.

Как устроен кастомный проект в NeuroCore

Мы работаем поэтапно, с понятным результатом на каждом шаге.

• Проблемное интервью. Разбираем задачу, смотрим на инфраструктуру, понимаем, что уже есть и что нужно добавить. На выходе — понимание, решаема ли задача и каким путём.
• Сбор данных. Выезжаем на объект, собираем данные с ваших камер в реальных условиях. Более 20 специалистов по сбору и разметке, с опытом выезда на объекты. Размечаем под конкретную задачу — это фундамент модели.
• Разработка и пилотный запуск. Обучаем модель, настраиваем логику события, строим интеграцию с вашей инфраструктурой. Пилот — от одного месяца на вашем объекте с реальными метриками. На этом этапе видно, работает ли решение.
• После подтверждения пилота — масштабирование. Решение запускается на всех объектах, онлайн или оффлайн в зависимости от требований.

У нас есть собственные серверы с GPU и инфраструктурой для обучения моделей. Мы не зависим от внешних вычислительных мощностей и не теряем время на настройку среды.

60 реализованных проектов, 53 города пилотирования, более 10 000 распознаваний объектов в сутки нашими нейросетями. 

Итог

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

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

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

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

Кастомная разработка закрывает именно этот разрыв. Модель обучается на ваших данных в ваших условиях. Логика события проектируется под ваш регламент и меняется вместе с ним. Результат передаётся в ту систему, где с ним будут работать — в ERP, SCADA, WMS, протокол ОТК. Существующая инфраструктура не заменяется, а получает аналитический слой поверх.

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

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

 Оставить заявку в форме ниже |  Написать нам в ТГ