Ваша AI-инициатива требует создания кастомизированного решения? В этой статье разбираем раздел фреймворка AI КОМП-АС, посвящённый архитектурно-продуктовому дизайну AI-сервисов. Подход позволяет снизить риски ошибочного старта и разработать продукт с контролируемой возвратностью инвестиций, соответствующий бизнес-целям.

Product Requirements Document (PRD)

Product Requirements Document (PRD), или Документ с требованиями к продукту (ДТП), — это верхнеуровневый документ, отвечающий на три ключевых вопроса: Что должно быть реализовано, Как это должно работать и Зачем это нужно. Наличие PRD помогает команде чётко понимать, что именно она создаёт, и принимать осознанные решения на всех этапах разработки и внедрения.

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

Зачем? — бизнес-гипотезы и метрики

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

Например, исходная гипотеза — рост ежемесячного регулярного дохода на 10% (MRR growth). На этапе 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 — её изменение напрямую покажет эффективность решения.

Что? — продуктовый дизайн и пользовательские сценарии

Опишите функциональные требования через пользовательские истории (User Stories). Для лучшего понимания и приоритезации используйте User Stories Mapping — визуализацию сценариев в порядке выполнения. Это помогает определить, что реализовывать в первую очередь.

Для сложных решений выделите Minimal Viable Product (MVP) — минимальную версию, которая приносит значимую ценность, но не требует всей функциональности. Это 20% функций, дающих 80% эффекта.

Учтите специфику AI:

• Human in the Loop: сохраняйте участие человека в критичных точках. Ответственность за результат лежит на пользователе, а не на системе. AI — как электрический инструмент в руках мастера: повышает эффективность, но качество результата зависит от оператора.
• Обратная связь: внедряйте встроенный контур обратной связи. Он может быть явным (оценка пользователя) или неявным (анализ логов и поведения).

Как? — архитектурный дизайн

Для описания архитектуры рекомендуется использовать C4-нотацию, включающую четыре уровня абстракции:

• C1 — Context: общий контекст системы, понятный бизнесу.
• C2 — Containers: основные приложения и сервисы.
• C3 — Components: внутренние компоненты контейнеров.
• C4 — Code: уровень реализации, предназначенный для разработчиков.

Это обеспечивает единую терминологию и понимание между всеми участниками проекта.

Ключевые принципы проектирования AI-сервисов:

• Используйте минимально достаточные инструменты. Приоритет — не технологическая новизна, а конечная стоимость. Избегайте тяжеловесных моделей: высокий Total Cost of Ownership (TCO) может свести на нет ожидаемую выгоду.
• Качество данных определяет качество выводов. Уделяйте особое внимание интеграциям и data-пайплайнам. Надёжная инфраструктура обработки данных снижает риски принятия решений на основе устаревших или некорректных данных.

Метрики решения

Определите тип ML-задачи — классификация, регрессия и т.д. — и выберите целевые метрики на основе отраслевых практик.

Установите бейзлайн — например, эффективность текущего ручного процесса — для сравнения с результатами AI.

Учитывайте контекст: например, в задаче удержания клиентов false negative (пропущенный отток) может быть дороже, чем false positive (лишняя скидка).

Инфраструктура

Выбор между облаком и on-premise зависит от ряда факторов. Ответьте на ключевые вопросы:

• Есть ли свободные вычислительные мощности (GPU)?
• Настроена ли MLOps-инфраструктура?
• Есть ли техническая команда для сопровождения?
• Какова предполагаемая нагрузка (RPS, DAU, пики)?
• Какие требования к SLA и доступности?
• Какие требования к безопасности (например, закрытый контур)?
• Какие требования комплаенса (например, 152-ФЗ)?
• Какие временные и бюджетные ограничения?

Облако обеспечивает быстрый старт, но может стать дорогим при росте нагрузки. On-premise снижает OPEX, но требует ресурсов на настройку. Выбор зависит от конкретных условий.

Риски

Составьте карту рисков, включая технические, бизнес-, организационные и регуляторные аспекты. Для каждого риска оцените:

• Импакт (влияние на инициативу)
• Вероятность возникновения

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

План разработки и внедрения

Формирование гипотез

Сфокусируйтесь на рисках с высоким импактом и вероятностью. На их основе сформируйте гипотезы и проверьте их через PoC (Proof of Concept) — небольшую фазу, направленную на минималистичную проверку ключевых предпосылок.

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

Формирование плана

На основе PoC, MVP и финального видения постройте итеративный план разработки. Оцените каждый этап по:

• Требуемой команде и трудозатратам
• Инфраструктуре
• Данным
• Зависимостям

Визуализируйте план, например, в виде диаграммы Ганта.

Оценка расходов и расчёт TCO

Переведите все затраты в денежный эквивалент:

• CAPEX — капитальные затраты: проверка гипотез, разработка, оборудование (для on-premise).
• OPEX — операционные расходы: мониторинг, обслуживание, обучение, инцидент-менеджмент, инференс в облаке.

Рассчитайте полную стоимость владения (TCO):

TCO = CAPEX + OPEX × Timeline

где Timeline — срок эксплуатации в годах.

Сравнив TCO с прогнозируемым экономическим эффектом, вы сможете рассчитать ROI и срок окупаемости, чтобы принять обоснованное решение о запуске проекта.

Заключение

Описанный подход к архитектурно-продуктовому дизайну AI-решений заменяет «чёрный ящик» на прозрачный и управляемый процесс. На каждом этапе мы отвечаем на четыре вопроса:

• Зачем? — через декомпозицию бизнес-гипотез и метрик.
• Что? — через продуктовый дизайн и Human-in-the-Loop.
• Как? — через понятную архитектуру и выбор оптимальных инструментов.
• Сколько стоит и что даёт? — через расчёт CAPEX, OPEX, TCO и ROI.

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

Ваша 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 трансформация, Рафт

Делюсь опытом внедрения ИИ в бизнес через поиск максимальной ценности:

https://t.me/aibobok