Добрый день! Меня зовут Саша Беляев и сейчас я лидирую несколько направлений разработки вокруг аналитики, AI/ML, AB-test, внутри Х5 в продукте CVM. Подробнее о моём опыте можно посмотреть тут. Сегодня я хочу поделиться своими мыслями о проблемах, которые возникают при передаче в промышленную эксплуатацию решений на базе AI, а также попробую сформировать некоторый набор рекомендаций, которые смогут кому-нибудь облегчить жизнь в будущем.
В большинстве компаний развитие любого IT-решения проходит стадии от первичной идеи до MVP, а от MVP уже до полноценного продукта. И, в какой-то момент, после всей этой романтики приходит этап, когда “радость” бесконечной разработки чего-то нового сменяется постепенно или резко суровыми буднями поддержки и различными соглашениями по уровню сервиса вокруг неё (по типу SLA).
В целом, это естественный процесс, как и любой биологический процесс взросления. И уже есть определённые практики в классическом IT, которые сформировались за долгие годы и хорошо себя зарекомендовали для того, чтобы управлять этим процессом взросления. Но что происходит, когда на сцену выходят продукты, основанные на моделях/алгоритмах машинного обучения или, проще говоря, AI, он же ИИ?
Сейчас я хочу поговорить не про то, какие фреймворки или подходы лучше использовать – про них можно самостоятельно погуглить. Я, скорее, хочу поговорить про специфические проблемы, свойственные IT-решениям на базе AI. По этой причине статья будет, скорее, не про волшебные таблетки, а своего рода медитацией вокруг темы и попыткой выработать определённые рекомендации.
Отличия при разработке решений на базе AI от разработки классического ПО
Для того, чтобы поговорить про поддержку AI-решений, вначале попробую определить (на свой вкус) ключевые отличия в подходах к разработке классического ПО против разработки решений с применением так называемого AI. В обоих случаях мы, в том или ином виде, имеем дело с алгоритмической задачей.
Основные отличия заключаются в том, что:
В классической разработке при правильной реализации алгоритма и подачи на вход однозначных параметров вы получаете ожидаемый результат, а в разработке вокруг AI этот результат может быть неожиданным, и вариативность входных параметров может быть жёстко не ограничена.
В классической разработке сам алгоритм может быть отдельной задачей для разработчика со специфической логикой. В AI акцент в большей степени на работе с данными, а алгоритмы – это чаще известный набор библиотек.
Алгоритмы внутри классической разработки чаще дублируют понятную человеческую логику принятия решения. При разработке AI логика принятия решения может быть максимально непонятной для человека без глубокого дополнительного исследования, а порой и это не помогает. Человеческий мозг априори не может работать с таким числом входных параметров в том виде, в котором это может делать AI алгоритм.
В классической разработке бОльший акцент сделан на работу с логикой кода и на само кодирование. В AI разработке много акцента на обработке данных, а процесс кодирования – это лишь одна из важных частей всего процесса.
AI разработка, по своей сути, – это, скорее, междисциплинарная область, которая использует научные методы, алгоритмы и различный инструментарий для извлечения знаний и идей из структурированных и неструктурированных данных.
AI-разработка используется, как правило, в том случае, когда традиционные подходы разработки не могут с заданными требованиями решить определённую задачу.
и т. д.
Эти отличия определённым образом и формируют восприятие бизнеса по отношению к классической разработке ПО и решениям на базе AI. К классической разработке бизнес относится, скорее, как процессу автоматизации привычной и понятной человеческой деятельности, чтобы сделать её более эффективной в плане стоимости/скорости/точности.
К продуктам на базе AI часто относятся, как к серебряной пуле или волшебной палочке, которой главное – просто сформулировать желание в стиле “Сделай мне хорошо!”, а палочка уже сама догадается, и что значит “хорошо”, и придумает, как это сделать. Возможно, тут, как обычно, много вины в ложном маркетинге от различных консалтеров, которые это магическое мышление у бизнеса всячески формируют и лелеют, дабы продавать свои услуги дороже, чем они реально стоят. А может, люди просто тяготеют в своей массе к магическому мышлению больше, чем к научному.
И вот здесь очень важна роль главного человека по DS в компании, задача которого – объяснить разницу и поставить важный акцент. Если классическая разработка – это больше про оптимизацию и экономию, то разработка AI-решений – это тоже может быть про оптимизацию и экономию, но ещё чаще – это про дополнительный заработок для компании. Поэтому даже к бюджетированию в классической разработке и разработке вокруг AI надо подходить по-разному, включая оценки ФОТ, инфраструктуры, рисков и их стоимости.
Попробую проиллюстрировать это, возможно, не очень удачной, но максимально понятной мыслью: “Один сеньор разработчик AI-решений может быть дороже даже в несколько раз обычного сеньора разработчика или целой кучи бизнес-менеджеров. Но сеньор разработчик AI-решений может запилить в соло продукт, который будет зарабатывать для компании дополнительно сотни миллионов рублей, а то и больше. При этом тут такие же риски, как и в любом стартапе”.
Наверное, тут как раз повод немного отвлечься от суровой реальности и набросить романтики про профессию Data Scientist. Возьмём такой пример из моего опыта, но без названий конкретных компаний и товаров (сразу скажу, что это мой опыт до работы в Х5, и таких реальных примеров я знаю достаточно).
Представьте, что компания производит продукцию, которая потом продаётся через торговые сети РФ объёмом на 100 млрд рублей в год. И теперь представьте, что у них есть какая-то модель прогнозирования, построенная на комбинации классической статистики, каких-то эвристик и экспертных корректировок категорийной службы, которая даёт в среднем ошибку итоговую по всем SKU, например, 20%. Занимает этот процесс оценки, например, одну неделю. В процессе только получения оценки задействованы 20 человек.
И вот, вместо текущего процесса, один сеньор разработчик пишет ML-модель, которая с первой итерации уменьшает ошибку прогноза на пару процентов. Что это может означать для компании с оборотом в 100 млрд рублей в год? Как минимум, возможность более эффективно перераспределить свои затраты, которые ранее тратились на производство/хранение/логистику продукции, стоимостью около 2 млрд рублей при реализации.
Представим просто для упрощения, что себестоимость производства продукции равно 30% от стоимости реализации, тогда получается, что компания только за счёт внедрения более точной модели прогнозирования может экономить в год до 600 млн рублей оборотных средств. На самом деле, скорее больше, с учётом обслуживания смежных процессов и возможностью инвестировать эти доп. ресурсы в своё развитие. Много это или мало – каждый может решить сам. Возможно, я где-то немного слукавил, потому что таких кейсов сейчас не так много осталось по сравнению с тем, которые мне ещё 5 лет назад встречались, но они точно есть, и я про них знаю лично, т. е. это актуально и по сей день:)
Ключевые болевые точки процесса выстраивания поддержки решений на базе AI
Итак, учитывая всё вышесказанное, можно переходить уже к нашим “баранам”. Какой же в итоге звенящий аромат привносят решения на базе AI, когда возникает потребность переводить эти решения на поддержку/в промышленную эксплуатацию?
Для себя я выделяю следующие болевые точки:
Персонал.
Дрифт моделей, данных и самих пользовательских требований.
Технический долг в широком смысле этого термина.
Выстраивание процесса передачи так, чтобы это было похоже на командную работу, а не на битву двух шотландских кланов из средневековья или, ещё хуже, на “борьбу нанайских мальчиков”.
Итак, попробую разобрать проблемы более предметно и пофантазировать про оптимальные пути решения.
1. Персонал
В идеальной картине мира возможны два сценария:
- Во 2-ю и 3-ю линии вы сможете нанять сеньоров, т. е. сеньоры захотят работать в поддержке годами, и компания будет готова это оплатить.
- Продукт будет передан в поддержку с нулевым техдолгом. Качество работы решения на базе AI будет всегда стабильно высоким. Код, в том числе и его инженерная часть, будет написан так, что его сможет разобрать и понять любой джун, а лучше – стажёр за “5 минут”. А математика, условно, самого решения будет настолько прекрасна, что если провести соревнование на kaggle по этой задаче, то текущая реализация побьёт всех с большим отрывом.
Если у вас есть возможность воплотить любой из этих сценариев в реальность посредством какой-то магии в условиях ограничений по стоимости и скорости разработки готового решения, а также удастся одновременно соблюсти все требования по максимально высокому качеству, то дальше можно не читать. Вообще, с таким скилом можно смело идти в любую компанию мира и требовать много денег.
Скорее всего, при владении такой “чёрной магией” на деле, платить вам будут готовы больше, чем вы сможете разумно обосновать даже для самих себя. И даже если вы наберётесь смелости и попробуете эту сумму произнести вслух, то получится только шёпотом или дрожащим голосом.
Но вернёмся в реальный мир и посмотрим, насколько он далёк от утопичной для нас картинки. Тут кому как повезет, но как по мне – это примерно как шанс встретить динозавра в современном мире. Кто-то может не согласиться – это те счастливчики, у кого процесс в компании основан на трёх тезисах: дорого-долго-качественно. Как много таких реализаций в реальности? Тут у всех свой опыт и свои апостериорные вероятности.
В реальности же мы, как правило, получаем специфические требования к квалификации персонала на 2-ой и 3-ей линиях поддержки, ну или, как минимум, на 3-ей (зависит от вашего воображения и бюджета). И далее уже сами эти требования по цепочке создают свои дополнительные проблемы в части сложности удержания и развития, а также в разработке карьерного трека для сотрудников поддержки и многое другое.
И как же быть тогда тем, кому закрыт доступ к миру, который населяют исключительно розовые пони и единороги? Как работать с реальностью, когда нужно находить людей, способных решать поставленные задачи, как развивать этих людей и как их удерживать на какой-то разумный цикл? На самом деле, я для себя пока что не нашёл какой-то серебряной пули, и каждый отдельный кейс приходится решать индивидуально.
Общим, по моему опыту, оказывается пока то, что для решения подобного рода проблем, если решать их реактивно, т. е. когда уже наступает апокалипсис, требуется полное понимание конкретной ситуации в моменте. Начиная от того, какая задача ставилась, как она решалась, как эволюционировало решение, как оно валидировалось, какое текущее состояние решения в плане бизнес-метрик и насколько оно стабильно, насколько текущее решение прозрачно в части документации и читаемости кода, какой объём видимого подтверждённого тех. долга (в широком смысле) имеется уже и какой скрытый тех. долг может быть, какой уровень сервиса и модель поддержки ожидается и т. д. И, только понимая всё вышеописанное, можно будет говорить относительно уверенно про то, какие будут требования к компетенциям людей и какой объём персонала потребуется для того, чтобы обеспечить необходимые уровни сервиса и модели поддержки.
И всё бы ничего, ведь в классической разработке ещё есть возможность как-то это переварить, НО тут на сцену выходит AI, и к требованиям работы с кодом и логическими операциями прибавляются требования в части понимания алгоритмов машинного обучения и продвинутой аналитики со статистикой. А поскольку это уже рабочий продукт, то тема стрессоустойчивости и софт скилов тоже начинает становиться одной из ключевых.
Как итог, даже если брать джуна в поддержку при подобном раскладе, то требования к нему становятся выше, чем к джуну в команде разработки этого же продукта. И даже при условии одинакового уровня оплаты труда поддержки и разработки в рамках грейда (что не всегда получается обосновать бизнесу) всё равно нужно давать какой-то нематериальный бонус, который будет компенсировать разницу и специфику нагрузки и мотивировать человека работать именно в поддержке.
Что делать и как с этим жить
Многое здесь, точнее, почти всё, зависит от самого руководителя – от умения подбирать подходящих людей до умения правильно использовать их скиллы. Подходящие люди – это не значит, что они умнее или быстрее других. Подходящие – это значит, что их личностные качества максимально хорошо ложатся на скоуп типичных задач, а издержки работы в поддержке для них не сильно критичны. При условии, что руководитель им поможет даже на этой позиции прокачать свои скиллы до нового уровня, который они себе наметили.
Поэтому тема умения хорошо проходить собеседования без умения реально хорошо работать тут ещё острее стоит. Нужны не те, кто обязательно хорошо теорию ML знает и легко щёлкает задачи с литкода (хотя и тут нужен санитарный минимум), а те, кто максимально подходит для конкретной работы, возможно, даже на ограниченный период, пока им будет там полезно в том числе и для собственного развития.
Насчёт одного из видов нематериально бонуса можно сказать следующее: умный и опытный руководитель недостатки и сложности, возникающие в процессе поддержки текущего продукта, должен уметь превращать в интересные задачи и точки роста компетенций для сотрудников, т. е. проблемы для одних могут легко стать возможностью для других.
Или, например, предложить задачу по типу автоматизации аналитики для быстрой диагностики обработки инцидентов, в том числе и придумывание этой аналитики как логического процесса для ускорения скорости принятия решений в рамках SLA (общих договорённостях об уровне сервиса). И такая задача может оказаться не менее интересной, чем автоматизация пайплайна расчёта в продуктовой команде или придумывания новой фичи для модели.
2. Дрифт моделей, данных и прочий “токийский” вокруг продукта и внутренних процессов
Под дрифтом я в данном случае подразумеваю процесс деградации качественных метрик продукта, который вызван внутренними или внешними факторами. Видов его много и все они – проблемы, порождаемые этим дрифтом – опять начинают с прищуром поглядывать в сторону вопроса с персоналом и “потирать свои кровожадные ручонки”. Ведь тот персонал, который занимается поддержкой, потенциально должен уметь решать подобные проблемы, если/когда это потребуется в какой-то момент жизненного цикла продукта, особенно, если команда разработки уже “ушла в закат”.
Не секрет, что любая модель по тем или иным (объективным и субъективным) причинам может деградировать. Сама деградация может быть как растянутой во времени, так и мгновенной. Существует ряд полезных гигиенических практик, которые, как минимум, могут хорошо детектировать эту деградацию и поднимать различные красные флаги. И, всё бы ничего и как-то можно с этим жить, но что если модель пришла в полную негодность и требует полной переработки, а команда разработки уже распущена/проект развития закрыт? При этом само решение, как инструмент, является core компонентом в каком-то большом ключевом бизнес-процессе компании?
И получается, что если мы планируем эксплуатировать это решение на базе AI с ожидаемым качеством дольше, чем полгода, то мы просто не можем позволить себе полностью терять/ликвидировать компетенции в области разработки/развития. Как минимум, в формате запасного колеса нужно всегда (пока продукт актуален для компании) иметь возможность доехать до станции техобслуживания, а как максимум – иметь ресурс, чтобы быстро всё починить. Потому что стоимость простоя/деградации решения может исчисляться для компании миллионами рублей в день. И это только техническая часть, лежащая в плоскости специфики вокруг разработки и AI.
Но всегда есть, как правило, и та часть, которую я называю “дрифт пользовательских требований и ожиданий”. Хорошо, если у вас в компании запредельная зрелость в части обслуживания жизненного цикла IT-решений на базе AI. Есть отточенный процесс, чёткое разделение на вехи в развитии продукта, чётко понятно, где заканчиваются изменения и начинается только эксплуатация и поддержка. Все новые требования идут в отдельный беклог, который, условно, в следующем году можно будет опять вынести на обсуждение в части выделения бюджета и уже потом снова открыть проект изменений и запустить очередной виток развития продукта от версии 1.0 к версии 2.0 со всеми вытекающими.
Но даже при такой зрелости процессов в каждой компании есть свои “слоны в комнате”. Насколько сам бизнес будет готов ждать год-другой, чтобы неожиданные критически важные бизнес-фичи появились в продукте? Насколько быстро получится набрать квалифицированную команду под новый беклог изменений?
Исторически так сложилось, что инертность процессов всегда проигрывает скорости изменений реальности, если эти изменения меняют правила игры. Т. е. даже большие компании, которые не могут меняться со скоростью, близкой к изменениям реальности, платят за это из ранее накопленного потенциала и доходов просто ради того, чтобы остаться в игре. Причём, сама инертность – это тоже не всегда плохо, так как она как раз и даёт этим компаниям устойчивость в долгосрочной перспективе. Поэтому для каждого этапа жизненного цикла компании/продукта всегда нужно контролировать баланс между скоростью отклика на изменения реальности и устойчивостью/консервативностью.
И если возвращаться к вопросу дрифта пользовательских требований или новых требований реальности, то получается, что к вопросу поддержки и эксплуатации решений на базе AI надо подходить несколько иначе, чем к классической разработке (например, к разработке сервиса построения какого-то отчёта или сервису обмена артефактами между двумя системами). Т. е. для продуктов, в основе которых лежат компоненты на базе AI/ML/DS, более критично всегда сохранять какой-то процент возможности быстрого отклика к изменениям, которые могут порождаться новыми требованиями бизнеса или реальности. Это, в свою очередь, накладывает свои особенности на проектирование команды, обслуживающей продукт в период эксплуатации, в том числе исходя из требований по гибкости, которые нужно поддерживать до следующего большого цикла разработки продукта.
Самое главное, к чему я тут подвожу – это осознание того факта, что поддержка и эксплуатация решений на базе AI, в принципе, могут не оказаться дешевле разработки, особенно если оценивать стоимость на горизонте нескольких лет. Особенно учитывая тот факт, что поддержка AI решений – это, по сути, модель поддержки black box. В такой модели поддержки основная роль отводится работе с различного рода мониторингами, где лучший мониторинг – это обратная связь от пользователей. При такой модели поддержки много времени тратится уже на то, чтобы понять, а есть ли вообще проблема, не говоря уже об ответе на вопрос: “А где она и с чем она может быть связана?”.
Осознание приходит, когда начинаешь всё считать, когда надо учесть требования по доступности поддержки (99%, например) и её модели обслуживания (24/7), т. е. 99% инцидентов/обращений закрываются в пределах установленных SLA и сотрудники поддержки обслуживают решение 24 часа в сутки 7 дней в неделю. Здесь ещё раз важно вспомнить, что решения на базе AI – это в большей мере про зарабатывать больше дополнительно, а непытаться сэкономить.
3. Тех. долг отец и сын, внебрачные дети и прочий инбридинг
Здесь я имею ввиду учёт тех. долга в широком смысле, при расчёте бюджета на поддержку и, соответственно, его влияние на итоговые требования к квалификации персонала для поддержки конкретного решения.
К вопросу тех. долга всегда нужно подходить очень аккуратно. Я ещё не встречал кейсов, когда тех. долг было бы оптимально всегда закрывать сразу, как только он был выявлен. В большинстве случаев оптимальным выглядит его периодический контроль/актуализация и переоценка критичности. Причём, важнее именно динамика изменения критичности, а не отдельная точечная оценка. Т. е. если оценка критичности растет n-периодов подряд, то стоит задуматься, чтобы выделить на следующий период плановых работ ресурс, чтобы устранить этот тех. долг.
В итоге при такой модели работы с тех.долгом ресурсы используются более разумно, поскольку часть долга отмирает сама собой или становится неактуальной без траты на неё доп. ресурсов. Но тут важно именно закрывать вовремя то, что критически растёт, чтобы это в какой-то момент не утянуло на дно всю предыдущую работу.
Итак, когда мы подходим к вопросу передачи на поддержку, то нужно обязательно сделать итоговую ревизию критического имеющегося тех. долга по всем направлениям – от инфраструктуры до самой реализации решения, и оценить его стоимость в ресурсах/деньгах/людях. Делать это, в идеале, должна принимающая сторона или независимая экспертная сторона внутри компании. По сути, это будет перечень необходимых работ и стоимость этих работ в людях/компетенциях. Эта стоимость должна быть либо учтена в стоимости поддержки, либо команда разработки обязуется закрыть этот долг до итоговой передачи продукта на поддержку своими силами и ресурсами. Общая рекомендация – встроить в процесс первоначальной разработки процесс управления тех. долгом и настроить его (процесс) индивидуально, исходя из конкретных особенностей компании/проекта/продукта.
4. Выстраивание процесса передачи так, чтобы это было похоже на командную работу
Бывают, правда, кейсы, когда разработка ушла/закончилась, а поддержка просто занимает территорию и забирает всё хорошее и плохое, что осталось от разработки – это тоже очень плохой сценарий по многим причинам и его, по возможности, лучше избегать.
Когда я для себя пытался найти ответ на вопрос: “В какой момент в процессе разработки решения на базе AI должны включаться ребята из будущей поддержки?”, то в результате некоторых мысленных (и не только) экспериментов, а также после изучения различной литературы, я пришёл к выводу, что меньше всего проблем в будущем возникает, если поддержка (или её представитель) появляется на этапе окончательного проектирования целевого решения, которое происходит, как правило, после успешного запуска MVP.
В основном, кроме понимания общего контекста того, с чем придётся иметь дело, поддержка может контролировать уже на этапе разработки качество всей документации, которая ляжет в основу будущей “Базы знаний”, и даже взять частично на себя её ведение ради того, чтобы в будущем самим же было с ней комфортнее работать.
Поддержка будет более глубоко понимать эволюцию развития продукта, а также может помогать в контроле/оценке того же тех. долга в плане его критичности. В итоге, когда будет подходить срок передачи, поддержка достаточно легко сможет сформировать итоговый список входных артефактов для передачи решения в промышленную эксплуатацию, а не пытаться осмыслить и погрузиться в продукт с нуля. В итоге это сильно сократит время передачи решения на поддержку, повысит скорость и качество этой передачи, и, в конечном счёте, сделает процесс буквально дешевле в ресурсах/людях/деньгах.
Выводы и общие рекомендации
Пожалуй, по результатам всего вышеописанного, общий вид рекомендаций, выводов и предлагаемых решений у меня получился такой:
AI-решения – это в большей мере про зарабатывать больше дополнительно, а не пытаться сэкономить. Имеет смысл исходить из этого факта при бюджетировании, в том числе и поддержки.
Старайтесь привлекать сотрудников поддержки или начинать выстраивать эту функцию на более ранних этапах разработки решений на базе AI – это сэкономит в итоге много времени, сил и ресурсов, когда нужно будет передавать это решение в эксплуатацию.
Желательно полностью не распускать основную команду разработки после создания первой рабочей версии промышленного решения на базе AI.
Управление тех. долгом – один из ключевых процессов разработки вообще. Либо вы его будете своевременно закрывать, либо он сам вас закроет по итогу.
IT-решение, которое, по своей сути, должно быть качественным и зарабатывать компании много дополнительных денег, не может стоить дёшево в плане затрат на людей и инфраструктуру по справедливым рыночным ценам. И не стоить забывать, что дорого, по мнению компании, может быть дёшево, по мнению рынка. В этом случае лучше или пересмотреть амбиции и скорректировать планы, или пересмотреть бюджет.
Все эти практики мы используем у себя в Х5. Где-то у нас получается чуть лучше, где-то чуть хуже, чем хотелось бы, но мы продолжаем работать над собой и придумывать, как нам ещё улучшить рабочий процесс.
Вот вроде бы и всё, такие мысли получились вокруг да около. Надеюсь, кому-то этот текст было интересно читать и, возможно, он даже будет полезен в работе.