Машинное зрение работает, и работает хорошо. За год количество проектов выросло с 5 до 36. Мы привлекли много подрядчиков и знатно пробежались по граблям.
А теперь я хочу рассказать про эти самые грабли.
Первые же серьёзные — проверка качества решений. Как оценить чужое решение и работает ли оно так, как надо нам? Тут много подходов и способов, например, использовать скрытые выборки, оценка на потоке и базовое — проверка кода и всего пайплайна, от разметки до метрик обученной модели.
Вторые — что не стоит оставаться наблюдателем на протяжении всей разработки. Если вы начинаете изучать систему только на приёмке, вас наверняка ждёт дивный мир сюрпризов. Включаемся сразу, ещё и раньше разработчиков (ТЗ никто не отменял).
А самая большая для меня боль года — донести и согласовать фразу «понятный и читаемый код» с каждой командой со своим чувством «прекрасного», и это не только про длину строк или формат докстрингов, но и про общие понятия в разработке.
Но давайте по порядку.
Меня зовут Анастасия Старобыховская, я руковожу направлением компьютерного зрения (CV) в ЦК DS (НЛМК ИТ). Одна из задач нашей команды — контроль качества решений, связанных с видеоаналитикой и искусственным интеллектом. Мы занимаемся поддержкой всех проектов, где есть такие модули компьютерного зрения, а также разрабатываем свои решения.
Из-за большого потока проектов физически разработать всё это нашей внутренней командой просто невозможно. Потому что сегодня в параллели у нас идёт порядка 20 проектов одновременно, и их количество только растёт. Наша команда из 9 человек это просто не в состоянии вывезти, и это одна из причин, почему мы привлекаем подрядные организации. Часть работ на сегодняшний день делают именно подрядчики, их периодически бывает много, прямо наплыв. Это большой скоп работ, административных и управленческих, и в рамках этого наплыва, иногда почти цунами, мы стараемся оптимизировать процессы.
Мы курируем и сопровождаем проекты, над которыми работают подрядчики, даём технические подсказки и следим за качеством работы. И ещё мы выступаем в роли центра компетенций в области computer vision в НЛМК и обеспечиваем контроль качества решений.
Почему количество проектов так резко увеличилось
Полтора года назад, когда я пришла в компанию, у нас в отделе было всего три человека и пять активных проектов. Предыдущая команда настроила процессы, и всё нормально работало с этим небольшим объёмом задач.
Когда проекты показали, что машинное зрение действительно даёт эффекты и результаты — бизнес и производство увидели, что это можно и нужно применять и поле возможного применения очень широкое. Потому что большую часть задач на производстве люди делают с помощью зрения, а инструменты, основанные на анализе визуальных данных, достаточно понятны и наглядны. Значит, какие-то из этих задач можно попробовать автоматизировать. То есть вот человек посмотрел номер, записал его. Отлично, мы можем убрать у человека эту рутину и дать ему в помощники машинное зрение. Так у нас появляются более точные измерения и статистика, и мы уже здесь можем точнее подстраиваться под производство, вычислять что-то, замерять, быстрее реагировать.
Например, шлак
Когда мы варим чугун, на его поверхности образуется шлак. Если шлак попадает в слив, это сильно портит качество продукта, поэтому, как только он появляется, нужно быстро перекрывать подачу.
Пока мы со своей автоматизацией не добрались до цеха, эту задачу решали люди. Сталевары через специальные стёклышки смотрели на яркий расплав и периодически восклицали: «Шлак пошёл! Я его чувствую, там что-то блеснуло! Перекрывайте!» — и жали на красивую кнопку. Всё это основывалось на опыте и ощущениях, но человеческий фактор мог иногда приводить к ошибкам.
А мы «посмотрели» на расплав тепловизором и поняли, что с его помощью можем очень точно определить, когда пойдёт шлак, потому что температура у него выше, чем у чугуна (спасибо физике и химии). Теперь время перекрытия определяет бездушная машина, и это оптимизирует процесс.
Подобных ситуаций на заводе довольно много. Вот ещё примеры: определение негабарита на конвейерах, контроль состояния оборудования, считывание номеров и маркировки продуктов — там, где раньше требовалось участие человека и его «глаз», теперь мы можем применить компьютерное зрение. Мы заменяем ручные операции визуальными сенсорами и автоматизированными системами, повышаем точность измерений и контролируемые параметры, и это позволяет настроить производство более эффективно.
За год наш отдел сильно изменился
Когда на 2024 год для нас запланировали больше 30 проектов, пришлось очень оперативно всё перестраивать. У нас не было шанса подготовиться к этому апокалипсису заранее — мы работали непосредственно внутри него. Нужны были команда побольше и новые процессы. В новых условиях текущие процессы не выдержат нагрузки — это было очевидно. Мы просто утонем в бюрократии, длительных и сложных, ручных и неподтверждённых процессах. Надо было выстраивать новые требования, приёмку, коммуникацию, общение, обучение подрядчиков для того, чтобы мы могли эффективно работать.
Мы быстро расширили команду до 9 человек. Этого было недостаточно для того, чтобы самостоятельно разрабатывать все проекты, но расширить штат ещё сильнее мы не можем из-за нестабильности нагрузки. У нас бывают пики и спады, и невозможно обеспечить постоянную и полную загрузку большему количеству разработчиков. Именно поэтому мы активно привлекаем подрядчиков. С ними нужно было быстро приходить к единому пониманию задачи, процесса и результата.
Про чёткое и одинаково всем сторонам понятное ТЗ
Бывает так, что одни и те же формулировки ТЗ, которые вроде бы очевидны, на деле трактуются по-разному.
Например, фраза «понятный и читаемый код» звучит просто, но что это значит на практике? Даже если попытаться уточнить требования, всегда есть риск уйти в детали — описывать каждую мелочь вроде запятых — или, наоборот, упустить что-то важное. Кто-то может сказать: «Ну есть же PEP 8 и куча книг, зачем изобретать велосипед?» Да, рекомендации-то есть, но подход к их применению бывает крайне своеобразным. Это как использовать молоток для закручивания гаек: возможно ли это? — конечно, если очень захотеть, однако точно ли стоит это делать?!
Или вот другой пример: формулировка «код должен содержать комментарии для повышения читаемости». Что бывает на практике? Одни вставляют комментарии вроде «картинки меняем» или «расчёты считаем». Формально комментарии есть, но толку от них никакого. Другие же ограничиваются парой строк комментариев на весь проект. И с точки зрения формального подхода всё отлично — ТЗ выполнено. Но по факту это ничуть делу не помогает.
Ещё одна проблема — когда команда берёт проект в работу, но ТЗ читают по диагонали, кое-как. Мы вроде всё расписали, сделали максимум, чтобы документ был понятным, а результат первой итерации — ноль. И это не потому, что ТЗ плохое, а потому, что его просто не читают полностью. Причём иногда даже с третьей попытки.
После таких случаев у нас сильно изменилось отношение к ТЗ и появились очень конкретные и максимально детальные требования к коду и оформлению, а также к промежуточным этапам и согласованию плана разработки. Мы прописываем все тезисы, все метрики и стараемся проработать всё, что только можно. И если раньше мы проверяли и дополняли ТЗ за день, то теперь на него уходит неделя. И пунктов в него входит уже не пять, а двадцать. Зато я точно знаю, что в нём не будет дыр, которые нужно будет затыкать в экстренном порядке.
Дерево метрик: связываем технические и бизнес-требования
Так как мы выступаем в роли медиатора между бизнесом и подрядчиками, нам нужно связать технический язык, на котором говорят вторые, с потребностями, которые есть у первых. При этом бизнесу совершенно всё равно, какие у нас есть метрики и точности и почему мы к ним так стремимся — их же пощупать нельзя. У них свои задачи и требования, связь которых с нашими данными для непосвящённых в нюансы не всегда очевидна. Из-за этого было много недопонимания.
Чтобы разрешить ситуацию, мы придумали дерево метрик, которое наглядно иллюстрирует связь эффектов бизнес-метрик с техническими. Теперь бизнес гораздо лучше понимает, что у нас происходит, а мы знаем, что делать, чтобы удовлетворить потребности бизнеса. А подрядчики могут ориентироваться на дорогие сердцу каждого технаря числа.
Составлять дерево метрик — задача мозголомная и довольно мучительная. Но эффект у них есть. На данный момент мы прорисовали деревья по трём проектам, и всем стало намного понятнее, что вообще происходит и что нужно учитывать в ТЗ.
Правила и стандарты среды
Каждый разработчик любит писать на своём языке и в своём стиле — это понятно. Мы умеем пользоваться разными языками и библиотеками. Однако, когда есть 15 подрядчиков, а у каждого подрядчика своя команда, то если каждый будет приходить со своим зоопарком — это будет невыносимо. Потому у нас есть свои правила и требования.
Мы задаём ключевые требования к функционалу, ограничения и критичные условия ещё до начала тендера.
Итоговый код должен быть сделан по единому шаблону и структуре. Это нужно, чтобы мы могли быстро разобраться в проекте, а не блуждать по произвольной структуре.
Кроме того, у нас есть очень конкретные жёсткие требования к функциональности. Например, мы принимаем не просто модель (файл с весами и архитектурой), а весь набор модулей, необходимых для её создания и вывода в продакшен. Это включает:
анализ данных (EDA),
блок подготовки данных,
обучение модели,
минимальную оптимизацию,
упаковку модели в сервис.
Такой подход помогает:
Гарантировать воспроизводимость. В научной среде эта проблема стоит остро: есть работа, где больше 70% исследователей пытались воспроизвести эксперименты других учёных, но не смогли, и более половины не смогли воспроизвести собственные эксперименты. Казалось бы, запускаешь алгоритм из статьи, а получаешь не космолёт, а ёжика.
Проверить корректность исследований. Ошибки могут быть где угодно: от расчёта precision до ликов в данных. Например, когда соотношение классов 1:300, а accuracy всё равно считают как обычно. Это не про то, что мы умнее всех, а про то, что человеческий фактор существует. Наши стандарты помогают снизить количество таких ошибок.
Чтобы упростить проверку и стандартизировать работу, мы создали платформу DSML. Она обеспечивает единые правила, процессы и функционал для всех подрядчиков. В этом окружении легко работать, а мы можем всё контролировать. Платформа позволяет ограничить, задать и реализовать глобальные идеи, и на финише мы должны увидеть совершенно определённую картинку.
В итоге мы получаем предсказуемый результат. Это честный подход: обе стороны с самого начала понимают, что ожидать друг от друга.
Вопросы лучше утверждений
Не менее важная часть наших будней — коммуникация. Я много раз наблюдала ситуацию, когда сталкиваются два спеца, каждый из которых считает себя суперпрофи, и ведут диалог в стиле: «Что это вы мне тут пытаетесь пропихнуть?» и «А почему вы мне тут указываете?»
Делу такой конфликт не помогает примерно никак. Мы взяли другой вектор коммуникации: стараемся перейти от утверждений и обвинений к вопросам и уточнениям. Тут стоит сказать о том, что команда у нас сложилась удивительная, примерно чудо света: технари, которые учатся говорить и грамотно общаться. И когда у человека спрашивают: «Правильно ли я понимаю, что это происходит вот так?» — начинаются чудеса. Мы беседуем и обсуждаем, вместе ищем и находим ошибку в логике размышлений — либо у нас, либо у подрядчиков. И дальше начинается конструктив и взаимопомощь.
Сопровождение подрядчика
Планирование, сбор данных, обучение модели — на каждом из этих этапов мы сопровождаем подрядчика и периодически с ним синхронизируемся. Понимать на каждом этапе, что происходит с проектом, дешевле для нервов и полезнее для работы, нежели подключаться в самом конце. Так у нас есть возможность в ключевые моменты внести свою экспертизу и представление о том, как надо делать, чтобы проектирование, архитектура, выбор подхода, решения и разметка данных были сделаны корректно, и мы с обеих сторон проработали бы все риски. Про ошибки и некорректные решения мы тоже узнаём сразу, а не в самом конце работы.
В разных проектах у нас встречается от одной до шестидесяти моделей, и править их все в экстренном режиме — то ещё удовольствие, особенно когда сроки горят со всех сторон. Когда я пришла работать в НЛМК на должность разработчика, мне дали проект, который нужно было проверить и принять на поддержку. Всё уже было реализовано до меня, деньги и ресурсы потрачены, до конца договора с подрядчиком оставался месяц… И тут выяснилось, что три месяца назад, в самом начале работы, подрядчики неправильно сделали разметку. Сюрприз. Колесо боли начинает свой оборот с самого начала, так как надо возвращаться к этапам работы с данными, снова анализировать, снова обучать и так далее. В итоге мы втроём с руководителем проекта и подрядчиком сумели, с горящими глазами и дымом из ушей, за месяц привести модель в порядок, но это было жёстко.
С подобными историями мы сталкивались несколько раз, и в результате либо получали конфликт с подрядчиком, либо выходили на новый виток исправлений. Оба варианта не очень.
А когда подрядчик на каждом этапе согласовывает план работ и гипотезы, вероятность внезапных проблем и сюрпризов сильно снижается. Это помогает работать стабильно, без авралов и переделок в последний момент.
После того, как разработка завершена, мы переходим к приёмке на поддержку. Это включает:
проверку качества моделей и алгоритмов,
code review,
проверку соответствия кода и документации требованиям ТЗ,
оценку работоспособности и стабильности.
Процесс трудоёмкий, а если параллельно идёт много проектов, можно просто утонуть в задачах. Чтобы этого избежать, мы решили автоматизировать проверки, сохраняя при этом высокое качество. Мы начали с базовых инструментов: CI/CD, линтеров, автоматических форматеров кода и других подобных решений.
Это уже сократило время проверки одной модели вдвое. Но мы понимаем, что ещё есть куда расти и над чем работать.
Как понять, что нам сдают хорошую работу?
Обычно мы сразу стараемся проговорить подрядчикам, как мы будем принимать работу и на что посмотрим в первую очередь. А дальше начинаем отслеживать, что они делают. Политики отслеживания и тестирования модели у нас есть разные. Одна из них — тестирование на нашем датасете (напоминает соревнования на Kaggle).
Работает это так: подрядчики устанавливают сенсоры, собирают данные и обучают на них модель. А мы в это время собираем с тех же камер свою выборку и проверяем, как оно работает именно на ней.
Если модель начинает ошибаться, мы первым делом смотрим изначальную разметку и проверяем, не засунули ли туда, кроме котиков и пёсиков, какую-нибудь лису. Проверяем ещё раз данные, корректно ли они собраны, не в один ли единственный день (вчера было пасмурно, модель научилась работать только в такую погоду, а сегодня солнце пришло к нам и всё порушилось), все ли целевые случаи присутствуют, точно ли модель хорошо обучилась и не показывает ли аномальное поведение? И если идут ошибки — снова то самое колесо боли возврата к началу.
Подрядчиков нужно готовить правильно. Себя тоже
С подрядчиками нужно формировать общую среду понимания — я много раз сталкивалась с тем, что, если не погрузить человека в свою сферу и не дать контекст, ему упорно будет казаться, что предъявляют странные, необоснованные или завышенные требования. Продуктивным и эффективным общение становится, когда я учусь языку собеседника (погружаюсь в термины, технологию, процессы работы), а он — готов вникнуть в суть моих вопросов и задач. В итоге мы начинаем говорить на одном языке.
Поэтому мы перед тем, как добавлять людей на платформу, проводим онбординг и учим на ней работать. У нас есть готовое обучение: туториалы, видеозаписи и примеры.
Мы всегда объясняем и показываем подрядчикам, в каком виде мы хотим принимать работу (по крайней мере, очень стараемся). Даём образ результата и представление о том, каким путём его достичь. Наша задача — подготовить их морально и физически к работе с нами и дать возможность оценить свои ресурсы. Просто чтобы они потом не говорили грустными голосами: «Ой, а мы думали, что тут работы на пару дней…»
Компаний-подрядчиков у нас сейчас порядка полутора-двух десятков, это разные команды, прошедшие наш тендер, и у каждой есть какие-то свои особенности, так что работать нам как минимум не скучно. Мы стараемся заранее найти слабые места во взаимодействии, всё разъяснить и закрыть их до того, как они станут проблемой. Но факапы всё же случаются. Например, в наших обучающих материалах есть примеры кода, которые показывают, как должна выглядеть структура и функционал. Так вот, некоторые из подрядчиков иногда воспринимают этот код как готовый эталон. Они почти ничего в нём не меняют, кроме пары мелочей, даже если этот код не подходит для конкретного проекта. В итоге получается настоящий Франкенштейн: первая часть кода не согласуется со второй, метрики считаются некорректно или вообще не подходят для задачи. А на наш вопрос, почему так, обычно звучит: «Но это же ваш код! Вы сами сказали, что он эталонный, мы ничего менять и не стали».
Но проекты-то разные, один универсальный код просто невозможен. Если бы всё можно было решить с помощью CTRL C — CTRL V, DS-специалисты давно бы стали не нужны.
Вжух и проект исчез
Иногда подрядчик вместе с проектом исчезает из поля зрения на месяц, а то и полгода. А у нас уже были планы о счастливом совместном будущем — но ожидание vs реальность, как говорится. Понятно, что есть юридические способы воздействия, да и нам процессы надо делать так, чтобы они не ломались и не рушили графики и планы, но реальная жизнь такова. Случается, что и планы двигаются, и тяжёлые долгие планирования ресурсов летят фанерой. Тут важно поймать волну и научиться балансировать на гребне цунами. Где можем — дорабатываем сами, переиспользуем данные с других проектов и даём результат. И делаем выводы.
У тебя есть карта? Лучше — у меня есть рисунок
Подрядные организации занимаются у нас не только разработкой, но и другими задачами, например, монтажом.
Когда мы берём разработку на себя, то начинаем готовиться сильно заранее: осмотр площадки, ТЗ, нефункциональные требования, отсмотр конфигурации оборудования, план работ и разметки, исследование гипотез и sota (если такие есть) и тому подобное. Нам важно проконтролировать монтаж. Есть проекты, где небольшая ошибка не сыграет заметной роли, но иногда крайне важно сделать всё точно — например, подобрать осветители, объективы и камеры, которые надо установить в нужных точках под определёнными углами.
И вот как-то мы попросили подрядчика выслать нам чертежи площадки с планом монтажа камер. И получили художественную зарисовку на тему.
Все три камеры идентичны по конфигурации. Ничего не смущает? Особо пытливым умам предлагаю вспомнить тригонометрию.
На вопрос, что это вообще такое, как одинаковые камеры смотрят так по-разному и что там будет на самом деле, мы получили ответ — на месте разберёмся. Конечно, разобрались, но на месте пришлось побывать не раз, не два и даже не пять…
Как понять, что всех наконец-то всё устроило
Это ровно та история, в которой отсутствие новостей — это уже очень хорошая новость. Значит, всё в порядке, полёт нормальный, режим штатный.
Есть несколько проектов, про которые нам постоянно говорят: «Ну до чего же круто оно работает! А давайте ещё вот сюда такое же сделаем!»
И мы уже можем сказать, что поезд тронулся — общая экспертиза растёт, планы на следующий год у руководства на нас такие, что скучно нам точно не будет — проектов много, они интересные и производству нужные.
Мы не просто научились работать с подрядчиками — нам удалось запустить процесс построения системы, в которой даже при цейтноте и хаосе можно получать качественные решения. Главное — прозрачность, общие правила игры и способность договариваться, задавая вопросы, а не выносить вердикты.