alexeyroslyakov

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

Я видел, как компании убивали целое направление одним неудачным выбором первого процесса. Не потому что технология не работала — а потому что начали не с того.

Обиднее всего, что снаружи это выглядит как поражение технологии. Руководитель докладывает собственнику: «попробовали ИИ, не взлетело». Хотя не взлетел не ИИ, а решение начать с процесса, который при любом подрядчике и любой технологии дал бы результат не раньше, чем через год. Ярлык «не работает» при этом цепляется ко всей идее автоматизации, а не к ошибке планирования. И снять его потом гораздо труднее, чем повесить.

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

Стоимость — это только половина уравнения

Чтобы не попадать в эту ловушку, мы давно не оцениваем процессы по одной цифре потерь. Каждый проходит через две независимые шкалы, от 1 до 10.

Первая — влияние на бизнес. Сколько денег, времени и риска снимет автоматизация.

Вторая — сложность реализации. Насколько тяжело это технически сделать: однозначные ли правила, есть ли данные, нужно ли дообучать модель, сколько систем придётся связать.

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

Баллы мы не берём с потолка. Влияние выводится из той самой диагностики, о которой шла речь в прошлый раз — часы, деньги, уровень риска, уже посчитанные по каждому процессу. Сложность оцениваем по конкретному чек-листу: есть ли готовые данные, однозначны ли правила, нужно ли дообучать модель, со сколькими системами предстоит интегрироваться. Две независимые оценки, каждая обоснована — поэтому карту потом и не получается оспорить «на ощущениях».

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

Шесть процессов, на которых видно, как это работает

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

Распознавание паспортов и сканов. Влияние 10, сложность 3. Специалисты вручную считывают данные из паспортов и ИНН и вносят в 1С. Объём большой, ошибки дорогие, риск с персональными данными прямой. А технически — это зрелая задача: распознавание документов, однозначные поля, минимум интерпретации. Высокое влияние, низкая сложность. Эталонный первый кандидат: пользы много, подводных камней почти нет.

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

Согласование договоров. Влияние 8, сложность 2. Бухгалтерия проверяет каждый договор, поток 3–8 в день, а каналы разные: часть приходит в 1С:Документооборот, часть по почте, часть в Битрикс24. Из-за этой разнородности договоры теряются и проверяются вручную на налоговые риски. Влияние высокое — это деньги и юридические риски.

И при этом сложность низкая: задача сводится к единому каналу данных и ИИ-помощнику с чек-листом рисков. Дорогой и лёгкий одновременно — редкое и потому ценное сочетание. Такие берут в работу не раздумывая.

Финансовое планирование, БДДС. Влияние 10, сложность 3. Бюджет движения денежных средств ведётся в Excel вручную, план платежей пересобирается дважды в неделю, фактически платежи постоянно выбиваются из графика. Влияние максимальное — речь о живых деньгах и кассовых разрывах. Сложность умеренная: данные о платежах структурированы, нужен планировщик сценариев. Ещё один сильный кандидат верхнего угла — и показатель того, что «дорого и сложно» вовсе не обязаны идти в паре.

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

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

Речевая аналитика звонков. Влияние 5, сложность 8. Контроль скриптов в отеле и продажах: вручную все звонки не прослушать, качество проседает. Польза есть, но средняя — пятёрка. А сложность почти на потолке: распознавание речи в реальном времени, отраслевой сленг, интеграция с телефонией, онлайн-подсказки оператору. Средняя отдача за максимальные усилия. Процесс не плохой — просто категорически не для старта.

Шесть процессов — шесть разных решений. И ни одно из них не выводится из одной только суммы потерь.

Паспорта и БДДС дорогие и лёгкие — вперёд. Договоры дорогие и лёгкие — тоже вперёд. Закупки дорогие, но коварные — подождут. Речевая аналитика средняя и тяжёлая — в хвост. Поручения дешёвые, но почти бесплатные в реализации — идеальны для разогрева.

Спор, который всё расставил по местам

Этот метод не раз снимал споры на старте проектов — сработал он и здесь.

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

Я не стал спорить аргументами. Открыл карту и показал две точки. Речевая аналитика: влияние 5, сложность 8 — средняя польза, максимальная трудоёмкость. Рядом — согласование договоров: влияние 8, сложность 2. Один процесс даёт меньше пользы и требует больше всего работы. Другой даёт больше пользы почти даром.

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

И это, пожалуй, главная ценность двух осей — даже не точность приоритезации, а то, что они снимают конфликт. У каждого руководителя свой процесс болит сильнее всего, и каждый искренне считает его первоочередным. Карта переводит спор из плоскости «чья боль важнее» в плоскость «что объективно выгоднее автоматизировать раньше». С таблицей не спорят так, как спорят с человеком.

Почему очередь важнее скорости

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

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

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

И это не отказ от дорогого процесса. Это отложенный заход на него — но уже с позиции заработанного доверия, когда у руководства нет вопроса «а оно вообще работает». Тот же контроль закупок гораздо проще запускать пятым, когда четыре предыдущих процесса уже принесли измеримый результат и спорить о состоятельности подхода никто не станет.

Что из этого стоит забрать

Найти, что автоматизировать, — несложно. Список кандидатов в любом холдинге набирается за пару недель.

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

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

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

Как выглядел наш питч два года назад

Мы приходили к клиенту с презентацией. Там были кейсы, технологии, ROI из зарубежных исследований. Директор слушал, кивал, говорил «интересно» — и потом ничего не происходило.

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

Потом я попал на одну встречу, где всё встало на место.

Мы презентовали программу автоматизации. Финансовый директор слушал минут двадцать, а потом спросил: «Хорошо. А сколько мы теряем прямо сейчас, если ничего не делать?»

Я не знал ответа. У меня был ROI от внедрения — но не было стоимости статус-кво. С технической стороны мы были готовы к любому разговору. С финансовой — нет. И в этот момент стало понятно, что весь разговор мы вели не с той стороны.

Первый проект, где мы сделали иначе

Следующий крупный проект мы начали не с предложения, а с замера.

Клиент — холдинг с девятью предприятиями: переработка отходов, агросектор, гостиничный бизнес, юридическое направление. Разные отрасли, разные системы, разные люди. Общего — только управляющая компания и хроническое ощущение у собственника, что «что-то где-то теряется».

Мы провели 28 интервью. Прошли 47 процессов. По каждому замеряли три величины: как часто он повторяется, сколько времени занимает один цикл и сколько человек в нём задействовано. Перемножаешь — получаешь часы в месяц, а из часов уже считаются деньги. Цифры со слов сотрудников перепроверяли по выгрузкам из 1С и Битрикс24: люди называют время, когда всё идёт по плану, а системы фиксируют реальность — с переделками, простоями и повторными заходами.

Через десять недель у нас была таблица. 47 процессов, у каждого — часы и рубли.

Дальше начался отбор. Автоматизировать всё подряд — плохая идея: часть процессов даёт копеечную экономию при дорогом внедрении, часть упирается в инфраструктуру, которой ещё нет, часть требует не алгоритма, а управленческого решения. Мы прогнали каждый из 47 процессов через три фильтра. Большой ли объём ручного труда — есть ли что высвобождать. Чёткие ли правила — может ли алгоритм работать без человеческого суждения на каждом шаге. Окупается ли — отобьётся ли внедрение в обозримый срок. Процесс проходил, только если давал «да» по всем трём.

Так из 47 осталось 11. Это не самые «громкие» процессы — это те, где автоматизация даёт измеримый эффект быстрее всего.

Только по этим одиннадцати набралось 2 464 человеко-часа в месяц на задачах, которые не требуют человеческого участия. 12 штатных единиц, занятых работой для алгоритмов. От 8,9 до 13,5 миллиона рублей потерь в год — по фактическим ставкам ФОТ, с начислениями.

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

Что нас удивило внутри проекта

Я ожидал, что самые дорогие потери будут там, где болит громче всего. Оказалось — нет.

Самой дорогой статьёй стала управленческая отчётность. Процесс, на который никто не жаловался. Ежедневный Excel с 178 метриками, девять предприятий, каждое утро — сбор данных вручную, сведение, конвертация в PDF, отправка директору. Привычная рутина.

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

Была и другая неожиданность. Хронометраж вскрыл не только потери времени, но и кое-что, что часами не меряется. В отчётности мы зафиксировали систематические изменения плановых значений после закрытия периода. Без злого умысла — просто так устроен процесс: между данными и финальным отчётом стоит человек с правом интерпретировать.

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

Директор в такой системе управляет не цифрами. Он управляет тем, что ему решили показать.

Это нигде не стоит отдельной строкой. Но именно это чаще всего и интересует собственника, когда он говорит про «что-то где-то теряется».

Что в итоге получилось на выходе

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

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

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

Именно в этот момент проект перестаёт быть IT-инициативой и становится управленческим решением.

Что пошло не так — и почему это нормально

Один раздел из 47 процессов мы взяли в работу осознанно, понимая риск — и он подтвердился.

Контроль закупок на предмет завышения цен и обхода тендеров. Большой объём, явная боль, прямой запрос от клиента. Технически — решаемо, мы делали подобное. Мы включили его в приоритетный список, договорившись проверить гипотезу на реальных данных.

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

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

Что мы изменили в своей работе

После этого проекта мы формализовали то, к чему давно двигались на практике.

Раньше: «Вот что мы умеем, вот кейсы, вот ROI». Теперь: «Прежде чем говорить про автоматизацию — давайте посчитаем, сколько стоит то, что вы делаете руками прямо сейчас».

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

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

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

Что получилось в итоге

Программа на 11 процессов. Три фазы, девять месяцев, CAPEX около 6 миллионов рублей. Первые четыре процесса окупаются меньше чем за четыре месяца.

Но главное не это.

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

Когда я рассказываю эту историю коллегам, они спрашивают: «Вы всегда так работаете или это был разовый случай?»

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

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

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

Мы предложили другой путь: оптимизировать систему так, чтобы она работала быстрее на том, что уже есть.

С чего начали

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

• каждый видеопоток подавался в нейросеть отдельно,

• обработка шла строго по очереди,

• процессор и видеокарта работали не синхронно и большую часть времени простаивали.

Отдельная история была с разрешением входных кадров. В сеть загонялись изображения 640×480. Для бытовой камеры это кажется скромным размером, но для нейросети это лишние пиксели. Сеть честно пыталась их проглотить, только толку от этого не было. Людей в кадре это не делало «более узнаваемыми», зато ресурсы уходили в никуда.

Почему уменьшение разрешения — не страшно

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

Мы начали постепенно уменьшать размер входных кадров. Эксперименты показали, что оптимальная точка — примерно 416×256. Это почти в полтора раза меньше исходного, но качество распознавания людей сохранилось. Зато скорость обработки резко выросла.

Параллельная обработка и балансировка

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

Здесь важно было грамотно распределить задачи между CPU и GPU. До оптимизации они работали несогласованно: GPU простаивал, пока процессор готовил данные, а процессор ждал, пока GPU «пережёвывает» ролик. Мы сделали так, чтобы GPU занимался инференсом, пока новые фреймы готовятся на CPU. Теперь оба ресурса загружены равномерно.

Результат

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

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

Что это показало

Опыт с этим проектом стал для нас хорошей иллюстрацией нескольких важных принципов.

Во-первых, в работе с нейросетями не всегда выигрывает максимальное разрешение. Иногда лишние пиксели только мешают.

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

И в-третьих, тюнинг моделей — это отдельная инженерная задача, которая требует экспериментов, тестов и внимательного анализа. Но результат того стоит.

Итог

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

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

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

Про “чёрный короб”

Да, идея хорошая и часто действительно спасает.
Но у нас было три метра конвейера, по которому летят зеркальные листы со скоростью 2 м/с.
А пыль, тепло, вибрации и необходимость обслуживать оптику делают «чёрный ящик» скорее лабораторным решением, чем промышленным.

Про поляризацию и металл

«Поляризаторы на металле не работают!» — писали вы.
И вы… почти правы.
На идеально зеркальной поверхности эффект действительно слабый.
Но на загрязнённых, частично матовых и неидеальных листах он даёт до 15–20 dB подавления бликов.
Не магия — просто физика, немного геометрии и много проб и ошибок.

Про “дешёвого человека с глазами”

Мы тоже любим людей с глазами. И даже работаем вместе.

Система не заменяет оператора — она отсекает рутину, где глаз устаёт, а блик обманывает.
Раньше контролёр тратил на проверку одного листа около 6–8 секунд и при этом пропускал до 10–12% микродефектов.

Теперь камера справляется за 1.2 секунды, а доля спорных случаев, которые уходят на ручную проверку, не превышает 3–5%.
Вместо бесконечного «вглядывания в зеркало» оператор теперь проверяет только то, где нейросеть не уверена — и делает это в разы быстрее.

Так что не «человек против машины», а человек + машина против скуки и брака.

Про “азов фотографии”

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

Про “всё равно не автономно”

Справедливое замечание.
Промышленное CV пока действительно не живёт без инженеров — но и не должно.
Как и любая сложная система, оно развивается итерационно: данные → обучение → адаптация → стабильность.
Главное, что теперь инженеры на линии решают не “почему камера не видит”, а “как улучшить метрики”.

На сладкое

Теперь точно знаем, что идеальных данных не бывает, что FTP живёт дольше всех,
и что на заводе «хорошее освещение» — это инженерное чудо, а не кнопка в настройках.

Спасибо всем, кто спорил, шутил и предлагал решения — ваши комменты были лучшим продолжением истории, чем любой отчёт по внедрению❤️

Больше живых кейсов моя команда разбирает в новом ТГ-канале https://t.me/brains2up
Подписывайтесь, если хотите чаще читать про настоящий ИИ.

С этого момента стало ясно: впереди не «проект на пару недель», а марафон, где придётся бороться не только с кодом, но и с реальностью цеха — вибрациями, пылью, бликами и древним MES, говорящим по OPC/Modbus.

Зачем всё это

Один крупный производственный заказчик (линия резки листового материала: зеркальная поверхность, скорость ~2 м/с) решил автоматизировать контроль дефектов.

Раньше инспекция была ручной — оператор просматривал каждый лист.

На старте задача выглядела так:

• Ставим камеру над линией: Basler ace2, 5 Мп, глобальный затвор; C‑mount 12 мм; FOV ≈ 600 мм; аппаратный триггер от энкодера; экспозиция 30–50 мкс; импульсный LED 630 нм с перекрёстной поляризацией.

• Режем изображение на тайлы: 1024×1024 px с overlap 20%; deskew по кромке листа; маска бликов.

• Детектим дефекты: царапины, пузыри, перекос, сколы (15 базовых классов); модель YOLOv5m, инференс FP16 (ONNX Runtime).

• Возвращаем результаты в MES/SCADA: JSON → XML/FTP (атомарный rename) с переходом на OPC UA; координаты дефектов в мм, sheet_id, статус OK/NOK.

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

Сюрприз №1: Светит, но не туда

Проблема: освещение и блики

На раннем этапе мы выяснили, что камера стабильно видит… блики, а не дефекты. Промышленное освещение оказалось агрессивным: холодные направленные прожекторы, паразитные отражения от оборудования и зеркальная поверхность листов. Сенсор клиппился по яркости, и каждый пересвеченный блик принимался за дефект. На старте ловили до 32% ложноположительных срабатываний.

Что сделали

• Свет и поляризация: заменили направленные прожекторы на диффузный купольный/низкоугловой свет под ~45°; поставили линейные поляризаторы на источник и анализатор на объектив под 90° (подавление бликов до ~15–20 dB). Перешли на узкополосные LED 625–660 нм.

• Экспозиция и синхронизация: включили строб с импульсом 30–50 мкс под триггер энкодера; глобальный затвор, постоянный токовый драйвер без 50/60 Гц мерцания. Отключили автоэкспозицию/автогейн/автобаланс; гамма = 1.0, фиксированный gain.

• Экраны и окклюзии: установили матовые чёрные экраны по бортам и над камерой, убрали паразитные отражения от рам и кромок.

• Онлайн-мониторинг яркости: ввели контроль доли насыщенных пикселей (P255) и динамического диапазона; кадры с P255 > 0.5% автоматически помечаются и не идут в инференс; гистограммы логируются.

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

Сюрприз №2: Камера не дружит с резкостью

Проблема: микровибрации и автофокус

Камера стояла над станком, всё казалось стабильным. Но каждые 30–40 секунд появлялась дрожь, тонкие дефекты «смазывались». Причина — микровибрации от привода/роликов (≈25–35 Гц) и отсутствие автофокуса при фиксированном рабочем расстоянии.

Что сделали

• Механика/крепёж: вынесли камеру на жёсткий кронштейн с виброизоляторами (fₙ ≈ 9–12 Гц, демпферы Shore A 30–40), отвязали от корпуса станка, добавили массу и развязку кабелей. Резонансные пики выше 60 Гц подавлены, передача вибраций < 0.3.

• Фокус: настроили фикс‑фокус на рабочее расстояние по slanted‑edge (MTF50 вырос с ~0.28 до ~0.36 cyc/px), зафиксировали кольцо (lock‑screw) и метки положения; регламент пересмотра при смене температуры/света.

• Экспозиция: привязали экспозицию к стробу 30–50 мкс — при 2 м/с смаз ≤ 0.1 мм.

• IMU‑контроль: поставили 6DoF‑датчик (1 кГц); логируем события при |ω|RMS > 0.8°/с или Δугла > 0.05° за 200 мс; при срабатывании помечаем кадры и уведомляем оператора.

• Онлайн‑метрика резкости: Tenengrad/Laplacian в ROI; кадры ниже τ исключаются из инференса или запрашивается повтор.

Вывод: стабильная механика и фикс‑фокус столь же критичны, как и модель. Развязка вибраций, короткая экспозиция и онлайн‑контроль резкости делают детектор предсказуемым

Сюрприз №3: один тайл — два дефекта и половина чужого листа

Ожидали: лист идёт ровно и по центру. Реальность: заезд под углом, частичное перекрытие соседним листом, дрейф по диагонали. В итоге один тайл нередко содержит две кромки разных листов — модель «плывёт» в предсказаниях.

Что сделали

• Маркеры и привязка к движению: наклеили ретрорефлективные метки по краям ленты; считывание в NIR (850 нм) с аппаратным триггером от энкодера (5k PPR). Детектируем leading edge и боковые кромки; дрожание меток < 0.5 мм.

• Лидар + фотодатчики: ToF-лидар 1 кГц для контроля lateral offset, три фотошторки по ширине для детекта перекрытия/наличия листа. События уходят в PLC и в CV-пайплайн; допуск смещения ±3 мм, время реакции < 5 мс.

• Динамический тайлинг и дескью:

  • грубая сегментация листа: Sobel/Canny → вероятностный Hough → RANSAC-линии кромок;

  • вычисляем гомографию и выполняем deskew; сетка тайлов якорится к кромке, а не к «сырому» кадру;

  • при перекрытии строим маску «серой зоны» вдоль шва (15–25 px): увеличиваем overlap, нежёстко понижаем вес предсказаний в NMS, логику объединения делаем по sheet_id;

  • если уверенность кромки < τ, включаем fallback: двойной overlap + предупреждение оператору.

• Слежение за листом: sheet_id по импульсам энкодера; пересборка карты дефектов в координатах линии, чтобы MES получал стабильные ROI.

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

Сюрприз №4: Модель любит однотипные дефекты, а у нас каждый раз сюрприз

Проблема: разнообразие артефактов

Обучались на 15 классах дефектов. В проде всплыли неожиданные: пятна клея, отпечатки перчаток, стружка, насекомые, следы чистки и др. За первый месяц зафиксировали 37 новых типов, отсутствовавших в трейне.

Что сделали

• Активное выявление «неизвестных» (OOD): отправляем в разметку тайлы при низкой уверенности (conf < τ), высокой энтропии, а также при расхождении ансамбля и классического CV; дополнили energy-score по логитам и расстоянием Махаланобиса в признаковом пространстве.

• Еженедельная разметка и инкрементальное обучение: выгружаем 8–12k «неопознанных» тайлов/нед. в LabelStudio (κ ≥ 0.82), дообучаем с rehearsal (30% старых данных), частично замораживаем backbone, применяем дистилляцию знаний и калибровку температурой.

• Гибридная схема CV + эвристики:

  • насекомые — временной фильтр (median-of-3 + оптический поток), отбрасываем движущиеся артефакты;

  • клей — NIR/поляризация, порог по отношению каналов (NIR/R) и по спектру блика;

  • отпечатки перчаток — частотные признаки (Габоры/FFT «гребёнки»);

  • стружка — вытянутость/эксцентриситет (elongation > 6), тонкие высококонтрастные компоненты.

• Управление таксономией: «прочее/ nuisance» как буферный класс; промоутим в полноценный класс при ≥200 размеченных примеров и precision ≥ 0.7 на валидации. Зоны с низкой уверенностью помечаем в UI для ручной проверки.

Вывод: CV — это не «обучил и забыл», а непрерывный цикл. Активный OOD-поток, регулярная разметка и инкрементальное обучение с гибридными эвристиками дают управляемость при появлении новых артефактов без деградации по базовым дефектам.

Сюрприз №5: API-интеграция с MES — это уже не про CV, но боль

Проблема: древняя MES-система

Документации нет. REST/GraphQL нет. Только XML-файлы по FTP, которые MES опрашивает раз в несколько секунд. Частые проблемы: частичные чтения, дубликаты, «зависшие» файлы, непредсказуемые задержки.

Что сделали

• Прокси-адаптер JSON→XML + надёжная файловая шина

  • CV выдаёт JSON с sheet_id, ts, speed, списком дефектов (bbox в мм, класс, уверенность).

  • Адаптер формирует XML по согласованной схеме, пишет атомарно: сначала в outbox/*.xml.part, затем rename в *.xml; после чтения MES кладёт *.ack.

  • Каталоги: outbox/ → processing/ → done/, ошибки в error/ с ретраем (экспоненциальная задержка, максимум 5 попыток), дедуп по sheet_id.

  • Кодировка UTF‑8 (без BOM), CRLF по требованию MES. Имя файла: INS_L1_20250912T101532Z_123456.xml.

• Мониторинг и SLA для FTP-интеграции

  • Тайм-аут чтения: если через 30 с нет *.ack — алерт (Prometheus/Alertmanager → Teams/Slack), автоперекладка файла в processing/ не повторяется до разборки инцидента.

  • Метрики: end-to-end задержка (CV→MES), число «подвисших» файлов, ретраи, доля дубликатов, размер очереди. Трассировка по sheet_id.

  • Безопасность: при возможности SFTP; иначе FTPS (TLS), учётка с минимальными правами и chroot.

• Переход на OPC UA через 2 месяца

  • Клиентский режим: сессия к серверу MES, SecurityMode=SignAndEncrypt, Policy=Basic256Sha256, keepalive 10 с, автопереподключение.

  • Узлы: ns=2;s=estralin/Sheet/{sheet_id}/Result, .../Defects (массив структур с bbox в мм и классом). Семплирование 100–200 мс, очередь 128, подтверждение обработкой статуса.

  • Фолбэк: при недоступности OPC UA — автоматический возврат на файловую шину, чтобы не терять данные

Вывод: интеграции — это отдельный проект. Согласуйте протоколы/схемы и SLA с IT-заказчика до старта, закладывайте атомарность, дедуп, мониторинг и фолбэк-канал; при возможности переходите на OPC UA с шифрованием.

Технологии и стек

• Камера: Basler ace2 (GigE, mono, global shutter, 5 MP @ 60 fps), C‑mount фикс-объектив 12 мм (F/4), FOV ≈ 600 мм, масштаб ≈ 0.20 мм/пкс. Аппаратный триггер от энкодера 5k PPR, экспозиция 30–50 мкс, строб узкополосного LED 630 нм с перекрёстной поляризацией; гамма 1.0, фиксированный gain.

• Модели: YOLOv5m (тайлы 1024×1024, overlap 20%), препроцессинг OpenCV (deskew по Sobel/Hough, CLAHE, маска бликов). Инференс ONNX Runtime CUDA/FP16; p50 7.8 мс/тайл, p95 11.2 мс/тайл (RTX A2000). Итог по листу p95 < 90 мс при 2 м/с. Качество: mAP50 0.96, F1 0.91, FPR 3.1% на холдауте.

• Разметка: LabelStudio, экспорт COCO/YOLO; двойная валидация, κ=0.84; гайдлайны по классам/границам; класс «nuisance/прочее» для OOD до промоушена.

• Интеграция: Python FastAPI (/infer, /healthz) → JSON; адаптер JSON→XML с атомарным rename и *.ack для legacy-FTP; основная шина — OPC UA (SecurityMode=SignAndEncrypt, Basic256Sha256), узлы ns=2;s=estralin/Sheet/{id}/Defects. Фолбэк на файловый канал.

• Мониторинг: Prometheus + Grafana. Метрики: p95/p99 инференса, очередь, GPU util/mem, доля клиппинга (P255), FPR/recall по сменам, OOD rate, задержка CV→MES/OPC. Алерты по таймаутам ACK (>30 с), росту FPR, падению FPS/энкодера.

• Деплой: On‑prem, Docker (Compose), NVIDIA Container Toolkit, закрепление версий драйверов/библиотек, healthchecks, автоперезапуск, локальный inference (latency‑critical), офлайн‑буферизация результатов и ретраи.

Финальные цифры

Что мы поняли

Оглядываясь назад, понимаем: часть проблем мы могли предсказать. Вот несколько инсайтов, которые пригодятся тем, кто только собирается внедрять CV на производстве.

Не верить в «идеальные данные»

• Пыль/блики/вибрации — норма. Введите авто‑контроль качества кадров: P255 ≤ 0.5%, средняя яркость в окне [90;160], резкость (Tenengrad) > τ, доля «горячих» пикселей ≤ 0.05%.

• Мониторьте дрейф окружения: деградация света (−5…−8%/мес), смещение экспозиции, рост шума; алерты и напоминания на очистку оптики каждые 8 ч или при падении SNR < 24 dB.

• Реплицируйте «грязную реальность» в данных: еженедельно добавляйте 5–10% свежих OOD‑тайлов, аугментации под бликами/смазом/пылью; калибровка порогов раз в смену.

  
  Закладывать бюджет на «внезапности»

• Резерв времени: +20–30% к срокам на интеграции/железо; бюджет: +10–15% на запасные части (камеры, БП, драйверы света, кабели).

• Операционные SLO: p95 инференса < 100 мс/тайл, p95 CV→MES < 1.2 с, потери данных 0, дедуп по sheet_id, MTTR инцидента интеграции ≤ 15 мин.

• Дежурство и плейбуки: on‑call 24/7 для линии, сценарии на «камера/энкодер/свет/OPC/FTP упал», фолбэк на файловую шину, офлайн‑буфер ≥ 24 ч.

  
  Общаться с технарями на месте

• Совместно с цехом: выбор света/крепежа/экранирования, допустимые окна простоя, точки триггера от энкодера, маршруты кабелей, HSE‑требования.

• Протоколировать фактические допуски: биение ленты, скорость, виброфон (целевой < 0.2 g), реальные ограничения на экспозицию/строб.

• Формализовать SAT/UAT: чек‑листы по классам дефектов, выборки на 1–2 смены, критерии приёмки (precision/recall/FPR), график регламентных чисток и перекалибровок.

Напоследок

Компьютерное зрение в промышленности — меньше про «красоту модели» и больше про свет, крепёж, синхронизацию и протоколы. Если идёте в прод, готовьтесь к реальному миру — тому, где рядом со Stack Overflow открыта вкладка «как дернуть автофокус через Modbus» и список запасных кабелей на складе.