Ваша AI инициатива требует разработки и внедрения своего кастомизированного решения? → В сегодняшней статье разбираем раздел AI КОМП-АС, описывающий подход к формированию архитектурно-продуктового дизайна AI сервисов, позволяющий снизить риски «войти не в ту дверь» и разработать продукт с контролируемой возвратностью инвестиций, отвечающий вашим целям.
Полное описание фреймворка можно найти здесь.
На предыдущем этапе фреймворка мы приоритезировали все инициативы в рамках процесса AI трансформации, свели воедино все "за" и "против", очертили дорожную карту - что называется, семь раз отмеряли. Можем ли резать?
Когда мы говорим про разработку ПО, то речь идет о процессе с высокой степенью нелинейности, когда мы говорим про разработку AI решений и других вероятностных решений, то здесь уже нелинейность, возведенная в степень. Соответственно проектно-строительный подход здесь, увы, уже не работает, и мерять приходится не семь раз, а на всей дистанции разработки, внедрения и эксплуатации, "от забора и до заката".
Чтобы быть уверенным, что построенное нами решение даст требуемый результат, нам необходимо будет протестировать сформулированные бизнес-гипотезы, очертить функциональные и нефункциональные требования и ограничения для нашей задачи, спроектировать продуктовый и архитектурно-технический дизайн решения, оценить риски, рассчитать стоимость владения итоговым продуктом. Для ответа на эти вопросы мы рекомендуем формировать PRD - Product Requirements Document или, если выражаться по-современному, в «а ля рюс» стиле, ДТП - Документ с Требованиями к Продукту. И здесь наконец-то мы уже можем найти что-то общее с классической стройкой - как ни одно строительство не начинается без технического проекта и сметы, так и ни одна AI разработка не обходится без PRD и архитектурно-продуктового дизайна.
Давайте ж разберем ключевые составляющие этого «зелья».
Product Requirement Document
Product Requirement Document (PRD) - это простой верхнеуровневый документ, объясняющий Что должно быть реализовано, Как это должно работать и Зачем это нужно. Имея такое видение, команда точно понимает, что она «строит», и может осознанно и эффективно принимать решения в ходе процесса разработки и внедрения.
Начнем с ответа на вопрос Зачем?
Описываем бизнес-гипотезу и связанные бизнес-метрики
Рекомендуем детально описать бизнес-гипотезу и привести бизнес-метрики, на которые окажет влияние наше решение в случае, если будет реализовано. В случае, если бизнес-метрики слишком высокоуровневые, и непосредственное влияние решения прослеживается сложно, то необходимо произвести их декомпозицию, выделив составные компоненты. На М-этапе( GAP-анализ) AI КОМП-АС фреймворка мы проделывали уже схожее упражнение - декомпозировали бизнес-метрики, чтобы «смапить» их c процессами организации. На данном этапе возможно придется сделать еще один шаг декомпозиции, выделив еще один уровень под-метрик.
Разберем на примере:
Допустим исходная бизнес гипотеза состоит в том, чтобы добиться роста ежемесячного регулярного дохода на 10%( MRR growth 10%).
На этапе GAP анализа была проведена декомпозиция, и исходная метрика была разложена на составные части:
MRR Growth = (New MRR + Expansion MRR) – (Contraction MRR + Churned MRR)
Допустим разрабатываемое AI решение позволят организации оптимизировать конверсию лидов, помогая с переходом от триала в платные подписки. Для выделения метрики, что "один в один" соответствует этой задаче нам необходимо двинуться дальше и провести декомпозицию под-метрики New MRR:
New MRR = (# of qualified leads) × (lead‑to‑trial conversion rate) × (trial‑to‑paid conversion rate) × (average initial contract value)
Таким образом, мы выделили целевую под-метрику trial‑to‑paid conversion rate, путем отслеживания которой мы напрямую сможем проверить гипотезу, связанную с данным AI решением.
А теперь к тому, Что мы строим?
Описываем продуктовый дизайн и пользовательские сценарии
Готовим продуктовый бэклог, описывая функциональные требования к решению в виде пользовательских историй (User Stories).
Для осмысления общей картины вашего решения и облегчения приоритезации также рекомендую провести User Stories Mapping - это подход, который позволяет получить полную, но при этом простую картину функциональности продукта в разрезе пользовательских сценариев, следующих в порядке их выполнения. Такая картина поможет вашей команде разработки определить очередность того, что реализовывать первым, а что отложить до поздних релизов. Подход описан вдоль и поперек (например, тут), поэтому не буду вдаваться в его детализацию.
При необходимости, если решение получается сложносоставным, рекомендуем также выделить Minimal Viable Product - минимальную жизнеспособную версию решения, внедрение которой несет значимую ценность для пользователя, но при этом не требует реализации всех «функциональных фич». Это те условные 20% решения, что несут 80% ценности.
Стараемся учесть специфику AI решений - любая современная модель начинает постепенно деградировать сразу же после ее деплоя, не может быть на 100% избавлена от галлюцинаций, дрифта данных, не может принимать решения в неизвестности, т.е. не готова к полной передаче ответственности за результат автоматизируемого бизнес-процесса:
Проектируя решение, сохраняйте присутствие человека в цепочке принятия решений, как минимум в критичных точках процесса, чтобы при неопределенности система могла возвращать управление ответственному сотруднику (Human in the Loop). Ответственность за результат лежит на пользователе AI решения, не на системе. AI инструменты - это как электрический рубанок в руке столяра вместо обычного, влияет больше на эффективность работы, а вот выйдет ли в итоге идеальный или кривой-косой продукт, зависит исключительно от умений самого столяра.
Ваше решение в идеале должно предусматривать встроенный контур обратной связи (ОС) со стороны пользователя. Запрос ОС может быть явным для пользователя или может быть реализован косвенно путем сбора и анализа логов, где ведется трекинг пользовательских действий и можно определить реакцию на предложенные моделью ответы.
Разобравшись, что мы хотим строить, давайте теперь решим, Как это делать!
Описываем архитектурный дизайн
При описании архитектуры решения рекомендуем использовать C4 нотацию - в деталях познакомиться с ней можно, например, здесь.
С4 нотация подразделяется на 4 уровня абстракции: C1 - Context (Контекст), С2 - Containers (Контейнеры), С3 - Components (Компоненты), С4 - Code (Код). Такое деление позволяет всем сторонам, участвующим в имплементации AI инициативы, обсуждать создаваемое решение, говоря на одном языке и синхронизироваться в понимании того, что будет реализовано. Так, например, архитектурная схема уровня C1( Контекст системы) позволяет эффективно вовлекать в обсуждение решения бизнес, сохраняя суть и не перегружая их излишними техническими деталями. Тогда как уровень абстракции С4( Код) уже дает возможность эффективной коммуникации непосредственно с командой разработки, обеспечивая погружение до уровня кода и реализации конкретных атомарных блоков архитектурного концепта и тех. дизайна.
Ниже подсвечу ключевые принципы, которыми рекомендуем руководствоваться при проектировании ваших AI сервисов:
Используйте минимально-достаточные инструменты для решения конкретной задачи, ставя конечную стоимость вашего решения выше технологической новизны. Старайтесь избегать использования тяжеловесных моделей и монструозных API - высокая стоимость инференса и соответственно высокая стоимость владения (Total Cost of Ownership, TCO) негативно скажутся на возвратности инвестиций в создаваемый сервис, в худшем сценарии даже превышая те экономический эффекты, которые вы ожидаете от внедрения вашей инициативы.
Качество данных на входе определяет качество информации на выходе. Главная составляющая успеха AI решения не столько в выбранной fancy модели, сколько в качественно подготовленных и доставленных до нее данных. При проектировании архитектуры уделяйте особое внимание интеграциям с источниками данных и data-пайплайнам. Инвестиции в надежную инфраструктуру процессинга данных (брокеры сообщений, кэширование, валидация на лету) радикально снижают стоимость поддержки и убирают скрытые убытки от принятия решений на устаревших или «битых» данных.
Описываем и приоритезируем метрики решения
Определитесь, какая именно ML задача вами решается - разрабатываете ли вы классификатор или это задача на регрессию? Отталкиваясь от типа создаваемого решения и ориентируясь на отраслевые стандарты и лучшие практики, вы сможете качественно подобрать целевые AI метрики.
Определитесь с бейзлайном, с которым вы будете сравнивать ваше решение. Например, для этого вы можете оценить по выбранным метрикам работу в рамках текущего, ручного, не автоматизированного процесса.
Учитывайте контекст решаемой проблемы. К примеру, насколько высока толерантность процесса к ошибке. Скажем, если вы решаете проблему оттока клиентов путем автоматизации назначения предлагаемой им скидки на ваш продукт, то false positive результат( предложение скидки не собирающемуся уходить клиенту) может быть вполне приемлемым и не слишком дорогим итогом, тогда как false negative( упущенный клиент) результат может быть уже довольно болезненным.
Описываем инфраструктуру
Для того, чтобы сделать осознанный выбор в части инфраструктуры, необходимо оценить, как целевые требования, предъявляемые к вашему решению, так и экономику, а также текущие и будущие ограничения для работы сервиса. Условно, чтобы определиться, двигаться ли вас с облаком или разворачивать on-premise, постарайтесь ответить на вопросы ниже:
есть ли у вас собственные свободные мощности( GPU)?
есть ли настроенная MLOps инфраструктура?
есть ли техническая команда, готовая взять «на баланс» ваше решение?
какова предполагаемая нагрузка на решение (RPS, DAU, нагрузка в пике)?
какой SLA и требования к доступности?
какие требования к безопасности со стороны ИБ? (например, неизбежен ли закрытый контур или нет)
какие требования со стороны комплаенса? (например, исполнение 152-ФЗ)
какие временные ограничения в рамках вашей инициативы? ( например, требуется показать быстрые эффекты, нет времени на формирование собственной инфраструктуры)
какие бюджетные ограничения в рамках вашей инициативы?
Облако может обеспечить быстрый старт, но может быть дорогостоящим при росте нагрузки; on-premise развертывание дает условно бесплатный инференс и снижение OPEX-а, но ресурсозатратно в плане сетапа - все инфраструктурные опции имеют свои плюсы, свои минусы, для принятия решения важно понять, что будет рабочей опцией именно для вас.
Описываем риски
Составляем карту рисков, относящуюся к процессу разработки и внедрения спроектированного решения. Перечисляем, как технические риски, так и те, что связаны с достижением бизнес эффектов, организационными и регуляторными трудностями.
Для каждого риска стараемся оценить его импакт (влияние) в контексте вашей инициативы и вероятность его реализации, а также по возможности формируем потенциальный план, позволяющий данный риск митигировать или же исключить вовсе . В точке не всегда возможно оценить импакт от риска в рублях или посчитать вероятность его реализации в процентах, поэтому рекомендуем карту рисков формировать, используя низко-гранулярную градацию, деля их по вероятности и влиянию на низкие, средние и высокие.
План разработки и внедрения
Формируем гипотезы
На данном шаге в первую очередь фокусируемся на отработке карты рисков, сопряженных с разработкой решения: если у вас есть риски в квадранте с высоким импактом и высокой вероятностью, то рекомендуем обратить на них особое внимание и сформировать на основании шагов по митигированию гипотезы, проверка которых позволит убедиться в реальности указанного риска и протестировать решение, позволяющее этим набором рисков управлять.
Для тестирования сформированной гипотезы рекомендуем запускать отдельную небольшую PoC фазу( Proof of Concept), предворяющую запуск основного проекта - цель этой фазы не в построении полноценного решения, а именно в проверке вашей гипотезы минимально возможными средствами.
В случае, если вы получили большое число гипотез требующих запуска PoC этапов или единый, но весьма объемный PoC этап, то возможно вам стоит сделать шаг назад и еще раз проанализировать ваш список AI инициатив и дорожную карту. На шаге П - прокладываем путь AI КОМП-АС фреймворка мы рекомендовали деприоритезировать те инициативы, что имеют низкую достижимость и высокие риски. Возможно та инициативы, для которой сейчас вы проектируете решение, на этапе составления дорожной карты была слишком оптимистично оценена в плане ее реализуемости.
Формируем план
Исходя из получившегося набора гипотез, требующих проверки в рамках PoC, очерченного минимального продукта( MVP) и итогового видения полноценного решения( Production Ready) нам предстоит сформировать итеративный план разработки и внедрения для нашей AI инициативы.
Для этого каждый из этапов - PoC, MVP, Production Ready - мы должны оценить с точки зрения требуемых ресурсов, а именно требуемой команды и трудоемкости этапа, требуемой инфраструктуры, требуемых данных и т.д. и выделить зависимости, если таковые есть.
Имея данную информацию мы сможем уже сформировать план разработки и внедрения решения, визуализировав его, например, в виде диаграммы Ганта.
Оцениваем расходы и рассчитываем TCO
Наконец-от мы на финишной кривой - здесь нам предстоит оценить получившийся план разработки и внедрения в твердой валюте, конвертируя все ресурсные и временные затраты в рубли.
Определяем, каковы будут капитальные затраты (CAPEX) на создание нашего решения - сюда будет входить стоимость проверки гипотез, часы на разработку версий вашего сервиса, в случае, если вы двигаетесь с развертыванием On-premise, стоимость требуемых вычислительных мощностей.
Определяем, каковы будут операционные затраты (OPEX), сопровождающие работу вашего решения на горизонте года - сюда будет входить стоимость мониторинга, обслуживания, обучения команды, инцидент-менеджмент, в случае, если вы выбрали путь использования облачных провайдеров, сюда же попадет стоимость инференса моделей.
Далее, исходя из продолжительности жизненного цикла вышей инициативы и сроков стратегического плана вашей организации, вы можете посчитать полную стоимость владения (TCO)
TCO = CAPEX + OPEX x Timeline,
здесь Timeline - количество лет эксплуатации решения.
Имея прогнозный экономический эффект и полную стоимость владения, вы уже сможете получить величину ROI и рассчитать сроки возвратности инвестиций, а соответственно взвешенно принять решение о запуске вашей инициативы в непосредственную разработку.
Заключение
Итак описанный выше подход к архитектурно‑продуктовому дизайну AI‑решений позволяет уйти от концепции «чёрного ящика» в пользу осознанного, управляемого процесса. На каждом этапе мы даём однозначные ответы на четыре ключевых вопроса:
Зачем? — через декомпозицию бизнес-гипотез и метрик, связывая AI‑инициативу с конкретными измеримыми эффектами.
Что? — через продуктовый дизайн, пользовательские сценарии и принцип Human‑in‑the‑Loop, исключающий «просадки» решения в случае высокой неопределённости.
Как? — через понятно описанную архитектуру и выбор минимально достаточных инструментов, обеспечивающих прозрачность и контролируемость реализации.
Сколько стоит и что дает? — через оценку CAPEX, OPEX, расчёт TCO и ROI, превращающих экономику проекта из догадок в ответ и пищу для принятия решения.
В такой концепции внедрение AI не воспринимается как «прыжок веры» с одной стороны, с другой стороны не ожидается уже и какая-то «чудесная магия» от внедрения. В результате подхода мы возвращаемся в пространство взвешенных решений с понятными рисками, предсказуемой стоимостью владения и чётко измеряемой бизнес‑ценностью. Такой подход позволяет запускать разработку не на надежде на "авось случится", а на твёрдых данных — с полным пониманием того, что, зачем и как мы строим, и во что это в конечном счёте обойдётся.
----------------
Алексей Бобок,
AI трансформация, Рафт
Делюсь опытом внедрения ИИ в бизнес через поиск максимальной ценности: