Привет! Меня зовут Олег Андриянов, в ИТ я работаю 6 лет. Начинал инженером в службе технической поддержки, а последние 3 года развиваю интеллектуальные механизмы в Directum Ario.

Сейчас я тимлид в команде ML-инженеров. Вместе с коллегами мы много работаем над качественным улучшением интеллектуальных механизмов продукта. Из реализованного: добились безошибочного распознавания ИНН в 94% случаев, а распознавания всех фактов в СНИЛС – в 82% случаев без единой опечатки.

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

Но сначала пару слов о масштабах проблемы.

Провал проекта – это норма? Мировой опыт и наша практика

Исследование VentureBeat в июле 2019 года показало, что 87% Data-Science-проектов не доходят до продакшена. Ganttic пишут, что от 25% до 85% проектов проваливаются в IT в принципе.

Чем выше неопределенность в проекте, тем больше риск, что он не достигнет результата. По статистике выше видно, что процент неуспешных работ в Data-Science не отличается от IT кардинально. Но что вообще такое неудачный проект? Приведу пример из нашего опыта.

Пример из практики

Бизнес-заказчик поставил задачу – повысить метрику извлечения фактов. Например, из 100 фактов, которые есть во входящих письмах, извлекалось 70, а 30 не находилось.

Факт – полезная информация из документа. В письмах это порядковый номер, дата и т.д.

Наша команда за два месяца проверила множество разных моделей и добилась улучшения – теперь в среднем извлекается 72 факта из 100. Но новая модель требует в 3 раза больше вычислительных ресурсов. Это не устроило бизнес-заказчика – обработка замедлилась в несколько раз, а извлечение фактов улучшилось лишь на 2%.

В этот момент от клиентов пришла другая более приоритетная задача, и этот проект мы отложили. Так, он пополнил копилку проектов, которые никогда не увидят продакшен.

Как мы научились копить не только жизненный опыт: 4 инсайта

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

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

1. Мы изменили способ приоритизации гипотез.

2. Начали оформлять прототипы в виде микросервисов.

3. Улучшили код-ревью проводимых экспериментов и их документирования.

4. Заменили Scrum на Kanban.

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

Несколько слов о LeanDS

В момент, когда мы с командой осознали, что большинство проблем кроется в процессах, нам помог управленческий фреймворк Lean Data Science. Выделю два фактора, которые повлияли на наш выбор этого открытого подхода к управлению DS-проектами:

• успешный опыт применения в смежной команде;

• в теории LeanDS рассматривались актуальные для нас проблемы и предлагались готовые решения.

Мы внедрили гибкое управление проектами, и это нам помогло.

Как мы изменили способ приоритизации гипотез

Гипотеза в ИИ – это работы команды, которые приводят к улучшению интеллектуальных механизмов. Есть два основных способа повысить качество:

1. Доработать обучающую выборку (увеличить датасет, убрать выбросы в данных и т.п.).

2. Попробовать применить другой механизм (обучить новую нейросеть, вместо одной модели начать использовать несколько и т.п.).

Когда гипотеза берется в работу, то ее описание оформляется по шаблону:

«Мы полагаем, что [используя данные] и [метод обучения], мы получим [метрику] не менее [значения]»

Пример гипотезы из нашего бэклога:

«Мы полагаем, что на текущих данных улучшится качество извлечения текста, если перед его распознаванием будет увеличиваться контрастность и понижаться яркость изображения. При этом метрика точности определения символов увеличится на 2-5%».

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

• кто-то в команде уже делал подобную задачу;

• в интернете есть мануалы по решению задачи;

• у модели/библиотеки есть репозиторий и документация (или научная статья).

И мы в первом же проекте поймали себя на логической ошибке. Понятно – не значит просто.

Пример до внедрения практики

Мы зашли в репозиторий нейросетевой архитектуры, обученной для решения NER’a. На момент старта проекта она занимала топ-1 место в рейтинге по этой задаче на одном из классических датасетов.

На GitHub хранилось около сотни файлов, 10 из которых – разные конфиги запуска модели. Документация проекта выглядела подробной, и мы взяли эту архитектуру как гипотезу. Задача стала одной из самых приоритетных, так как всё казалось понятным и очень перспективным.

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

В итоге мы просто отложили гипотезу и начали проверять другие модели.

От простого к сложному

Тогда мы еще не знали об исследовании, показавшем, что только в 4% Jupyter тетрадок, найденных на GitHub, удалось воспроизвести эксперименты. В остальных 96% либо метрики оказываются хуже, либо запустить проект просто не получится, так как его выложили в нерабочем состоянии.

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

• оно так же хорошо справится с твоей задачей;

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

В итоге наша команда перешла на более объективную приоритизацию – от простого к сложному. А ещё мы решили, что не будем брать гипотезы, если не поверим, что они улучшат качество работы интеллектуальных механизмов. То есть при оценке приоритетов учитывали трудоемкость и потенциальный рост метрик. И вы уже могли заметить, что мы просто адаптировали популярный ICE метод приоритизации под специфику ML. В этом нам сильно помог LeanDS.

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

Начали оформлять прототипы в виде микросервисов

История началась с того, что раньше ML-инженеры нашей команды были ответственны за два участка работ:

• проверку ИИ-гипотез;

• встраивание успешных гипотез в конечный продукт.

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

Пример до внедрения практики

Мы проверяли, как можно улучшить качество извлекаемого текстового слоя. За время проекта наша команда за несколько итераций добилась улучшения метрик лишь на 1%. При этом каждая новая гипотеза встраивалась в сервисы, собирались метрики. Некоторая часть сервисов была заточена под Tesseract OCR, мы каждый раз изменяли ее под разные другие OCR. Я думаю, что в этом проекте не менее четверти трудоемкости ушло на инженерные работы по встраиванию.

Фокусируемся на части пайплайна

После вышеприведенного проекта мы решили выделять место в пайплайне, которое собираемся улучшать, в отдельный микросервис. При таком порядке работ можно улучшать модели и поставлять промежуточные результаты. Бизнес-заказчик теперь не всегда может пользоваться нашими улучшениями в моменте, но зато во время проекта делается меньше инженерных работ. А значит результат поставляется быстрее, и работа команды становится более прозрачной.

Улучшили код-ревью проводимых экспериментов

Раньше мы работали с ИИ-гипотезами примерно по такому алгоритму:

1. Проверяли ИИ-гипотезу.

2. Если гипотеза успешна, то встраивали ее в сервисы и делали ревью.

В нашей команде исторически сложилось, что код, встраиваемый в сервисы, проходит ревью. Этот процесс нужно было адаптировать под новые реалии – в исследовательских проектах далеко не весь наш код уходит в сервисы.

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

1. Оцениваем качество кода (код-ревью).

2. Получаем аналогичные результаты на компьютере ревьюера.

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

Пример после внедрения практики

Интересно, что новый подход к ревью дал плоды уже в первые месяцы. У нас отловился баг, из-за которого у автора гипотезы и ревьюера были разные метрики. Дело было в различных семействах процессоров. Оказалось, что библиотека, выполняющая предобработку изображений перед их отправкой в нейросеть, возвращала отличающиеся результаты на разных процессорах. Мы заменили библиотеку и получили прирост по метрикам на 6%. Иногда успешные ИИ-гипотезы абсолютно неочевидны.

Заменили Scrum на Kanban

Этот инсайт выглядит довольно спорным. Любой фреймворк можно сделать успешным и результативным в исследованиях. Просто некоторым командам из-за разных контекстов их работы больше подходят разные процессы.

В нашем случае оказалось, что Scrum содержит много артефактов, на которых мы фокусировались больше, чем нужно.

Пример 1. Получали инкремент продукта каждый спринт. Иногда всё, что ты делаешь на итерации – это проверка работоспособности моделей. Такие результаты не ложатся прямым образом на понятие инкремента. Да и вообще работа по закрытию User Story не сильно линейна в исследованиях. Примеры на рисунке ниже, взятом из книги Асхата Уразбаева, слева – закрытие US в разработке, справа – закрытие US в ML-проектах:

Пример 2. Команда брала обязательства на спринт в виде определенной цели спринта. При этом мы часто не понимали, как ее достичь. В таком формате теряется смысл ставить цели на итерации.

В итоге мы заменили Scrum на Kanban. Теперь у нас пять обязательных артефактов в процессах:

1. Ограничение количества историй в работе (WIP).

2. Демо по готовности. Оно может быть каждую неделю, а может быть раз в месяц – всё зависит от стадии проекта и сложности гипотез в работе.

3. Daily Meeting.

4. Backlog Refinement.

5. Ретроспектива.

И это снова повысило прозрачность процесса.

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

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

Бонус от LeanDS

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

Работы в ИИ делятся на три вида. К каждому из них есть свой перечень шаблонных вопросов:

1. User Story – здесь описано, как будет работать наш конечный продукт. В чек-листе 7 вопросов по этой теме.

2. Data Hypotheses – какие изменения в данных могут улучшить работу нашего сервиса. Например, с чек-листом команда не забудет сразу выяснить, совпадает ли обучающий датасет с тем, что видит модель у заказчика на продакшене. В LeanDS приводится 13 вопросов по этой теме.

3. Method Hypotheses – какие доработки интеллектуальных механизмов могут улучшить работу нашего сервиса. В чек-листе 4 вопроса по этой теме, пример одного из них: «Как эту ИИ-задачу делают эксперты сейчас?».

Полный список вопросов можно найти в книге по LeanDS.

Выводы

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

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

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

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

А что делали вы, чтобы повысить результативность команды на исследовательских проектах? Делитесь в комментариях. Всегда интересно узнавать опыт коллег.

Также недавно я начал вести телеграм-канал о том, как быстрее прокачать свою карьеру в IT. Подпишись, будем развиваться вместе!