Как создавать продукты с ИИ. От первых экспериментов до работающей системы

•

Обратная связь — это не «анализ результатов», а преобразование этих сигналов в основания для принятия решений о следующем цикле разработки и определения приоритетов экспериментов.

2.2 Что на самом деле передают стрелки на блок-схеме

Стрелки на блок-схеме — это не формальная передача ответственности, а передача информации, доказательств и решений.

•

Определение направления -> Проведение экспериментов: передаются определение проблемы, условия данных, ограничительные границы и экспериментальные гипотезы.

•

Проведение экспериментов → Построение системы: передаются доказательства возможностей после сходимости, модели сбоев, базовые показатели оценки и решения по продукту.

•

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

•

Аудит и допуск -> Производственная эксплуатация: передаются стратегия допуска, сценарии «Shadow»/поэтапного внедрения, требования к мониторингу и условия отката.

•

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

•

Циклическая обратная связь → Определение направления: передаются приоритеты следующего цикла, корректировки направления и вопросы, требующие повторного тестирования.

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

2.3. Помимо основной вертикальной линии этапов, существует также горизонтальная линия взаимодействия человека и машины

В черновике есть одно суждение, которое стоит вынести на первый план: помимо вертикальной основной линии «определение направления -> проведение экспериментов -> построение системы -> аудит и запуск -> эксплуатация -> обратная связь», в всей методологии существует ещё одна горизонтальная линия взаимодействия человека и машины.

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

Если свести это к одному общему принципу, то он будет следующим:

•

Человек отвечает за направление

, границы, принятие решений, одобрение и обеспечение резервного варианта.

•

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

В последующих главах — в главе 08 — это будет развернуто в модель взаимодействия человека и машины на уровне процессов, а в главе 16 — в дизайн сотрудничества человека и машины на уровне пользовательского опыта.

3. Что на самом деле является результатом каждого этапа

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

3.1. Результаты определения направления

Цель определения направления заключается не в том, чтобы расширить список требований, а в том, чтобы сформулировать определение направления, готовое для эксперимента. Оно должно, как минимум, отвечать на следующие вопросы:

•

Каковы

пользователи и бизнес-задачи.

•

Почему эту проблему стоит решать с помощью ИИ, а не традиционного программного обеспечения.

•

Достаточно ли внешних и внутренних бизнес-данных для проведения эксперимента?

•

Определены ли требования по обезличиванию данных, правам доступа, соблюдению нормативных требований и пределы рисков?

•

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

Поэтому типичным результатом определения направления обычно является не PRD, а документ, больше напоминающий краткое изложение направления (Direction Brief): определение проблемы, гипотезы о ценности, условия данных, ограничения и обоснование начала эксперимента.

3.2. Результаты проведения эксперимента

Цель проведения эксперимента заключается не в создании демо-версии, похожей на продукт, а в накоплении достаточно убедительных доказательств возможностей. В результате должны быть получены:

•

Результаты экспериментов по ключевым сценариям и примеры неудач.

•

Сравнительные выводы по промптам, рабочим процессам, агентам или способам подачи данных.

•

Основные критерии оценки и базовые показатели для

.

•

Рекомендации по сведению целей и принятию решений о продуктах.

•

Решение о целесообразности начала разработки системы.

Иными словами, результатом проведения экспериментов должны быть «доказательства» и «выводы», а не просто «шум».

3.3. Результаты построения системы

Цель построения системы заключается в преобразовании доказательств возможностей в системные возможности. После перехода на этот этап приоритеты команды изменятся:

•

Как способности инкапсулировать в навыки (Skill), рабочие процессы (Workflow), агенты (Agent) или сервисные модули.

•

Как обеспечить стабильную подачу данных, контекста, памяти и знаний.

•

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

•

Завершена ли переработка кода из экспериментальной версии в производственную.

Таким образом, результатом построения системы становится не «работающий эксперимент», а система, готовая к аудиту и принятию решения о вводе в эксплуатацию.

3.4. Результаты аудита и одобрения

Цель аудита и одобрения заключается не в том, чтобы поставить окончательную подпись, а в том, чтобы четко определить, можно ли запускать систему в эксплуатацию. В ходе аудита рассматриваются следующие вопросы:

•

права доступа, превышение полномочий, утечка данных и операционные риски;

•

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

•

тестовые среды «Shadow» и «Grey», ручная проверка, объем разрешения к эксплуатации и условия отката;

Заключение «go / no-go» и его обоснование.

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

3.5. Результаты эксплуатации в производственной среде

Цель эксплуатации в производственной среде — не просто «запуск в эксплуатацию», а получение реальных сигналов от системы в реальных условиях. Производственная среда обеспечивает:

•

данные о поведении пользователей и обратную связь;

•

реальные случаи сбоев и сценарии с высоким риском;

•

Информацию о затратах, задержках, стабильности и цепочках вызовов.

•

Какие

возможности действительно создают ценность, а какие лишь кажутся умными.

Вся эта информация в конечном итоге станет входными данными для цикла (Loop) и, в свою очередь, повлияет на определение направления и приоритетов экспериментов в следующем раунде.

3.6. Понимание этой основной линии в одном предложении

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

4. Переход между этапами осуществляется через контрольные точки, а не на основе интуиции

Рис. 4-2. Схема контрольных точек этапов

Определение направления -> Контрольный пункт 1: Наличие необходимых данных Начало испытаний -> Шлюз 2: поступил сигнал сходимости Построение системы -> Шлюз 3: доказательства системы полны Одобрение аудита -> Шлюз 4: Условия разрешения определены Производственная эксплуатация

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

4.1. «Шлюз» «Определение направления — развертывание эксперимента»

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

•

Проблема должна быть достаточно четко сформулирована и заслуживать применения ИИ.

•

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

•

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

4.2. Переход от экспериментальной фазы к построению системы

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

•

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

•

Причины неудач в основном поддаются объяснению с помощью метода

, и команда знает, что можно делать в пределах определённых границ, а что — за их пределами.

•

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

•

Команда сформировала четкое решение относительно продукта, а не продолжает просто накапливать эксперименты.

Другими словами, эксперименты достигли порога, позволяющего приступить к созданию системы: речь идет не о том, что «модель впечатляет», а о том, что «возможности уже достаточно стабильны и заслуживают воплощения в продукте».

4.3. Этап «Создание системы» → «Одобрение аудита»

Перед началом аудита и одобрения команда должна, как минимум, ответить на следующие вопросы:

•

Ясны ли границы системы?

•

Являются ли права доступа и цепочки поставки данных понятными?

•

Проведена ли базовая оценка ключевых возможностей и обеспечена ли их отслеживаемость?

•

Возможен ли откат, остановка системы или переход на ручное управление в случае сбоя

?

Если эти базовые условия не выполнены, то система ещё не соответствует даже критериям «готовности к аудиту».

4.4. Шлюз «Одобрение аудита» → «Производственная эксплуатация»

Этот этап — не просто «прохождение тестирования». Более полное решение о допуске обычно включает:

•

Сначала тестирование в тестовой среде (Shadow) или сразу постепенное внедрение (Grey Release).

•

На каких этапах сохраняются ручная проверка и ручное управление.

•

Каких пользователей

, какие задачи и какие сценарии следует разрешить в первую очередь.

•

При появлении каких показателей или событий необходимо выполнить откат.

Поэтому вывод аудита о запуске скорее заключается в том, «каким образом запустить», а не просто «можно ли запускать».

5. На самом деле в процессе происходит не линейное продвижение, а сближение целей

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

Наиболее типичный пример наблюдается на этапе развертывания эксперимента:

•

вначале, возможно, проверяется способность модели.

•

Затем выясняется, что действительно ключевым фактором является способ подачи данных.

•

Еще позже становится ясно, что проблема заключается не в качестве ответов, а в реорганизации процессов и форме продукта.

•

В конечном итоге наступает этап «конвергенции целей / принятия решений о продукте», на котором определяется, какие направления стоит продолжать, какие отложить, а какие прекратить.

Иными словами, развертывание эксперимента — это не один большой экспериментальный бассейн, а процесс постоянного сближения проблем, возможностей, формы продукта и оценок ценности. Создание системы также не завершается за один раз: часто возникающие новые проблемы заставляют вернуться к предыдущему этапу.

Поэтому методологию, описанную в этой книге, точнее назвать «циклической системой со шлюзами», а не строго последовательным «водопадным» процессом.

6. «Теневая система» — важный мост от эксперимента к производству

Shadow System играет очень важную роль во всей книге, поскольку предоставляет более надежный механизм перехода, чем «непосредственная замена исходной системы».

Под термином «Shadow» подразумевается не то, что ИИ сразу же берет на себя управление реальными бизнес-процессами, а то, что он работает параллельно в реальных условиях, постоянно сравнивая результаты и выявляя проблемы. Например:

•

позволить ИИ давать рекомендации по реальным заявкам в службу поддержки, но пока не отправлять их автоматически;

•

Пусть ИИ анализирует реальные оповещения, но сначала сравнивает свои выводы с выводами операторов.

•

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

Его ценность заключается в трёх аспектах:

•

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

•

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

•

Превратить переход к производственной эксплуатации из «резкого переключения» в «контролируемую эволюцию».

Таким образом, «теневая система» — это не просто отдельная концепция, а связующий механизм в рамках всей методологии, объединяющий проведение экспериментов, построение системы, одобрение аудита и запуск в производственную эксплуатацию.

7. Три цикла вместе составляют полную методологию

До этого момента в книге речь шла о самом основном цикле — цикле продукта (Product Loop). Однако одного цикла для понимания продукта ИИ недостаточно. Ведь продукт ИИ включает в себя не только «как его создать», но и «как обнаружить его ценность» и «как клиенты стимулируют его рост».

Поэтому в данной книге методология далее структурирована в виде трёх циклов:

Продуктовый цикл (Product Loop): Определение направления -> Проведение испытаний -> Построение системы -> Аудит и одобрение -> Производственная эксплуатация -> Возврат в цикл

Цикл обнаружения ценности (Value Discovery Loop): Проведение испытаний -> Выявление ценности -> Тестирование на рынке -> Определение цены -> Корректировка направления развития продукта

Цикл взаимодействия с клиентами (Customer Loop): Возможности для тестирования → Первые клиенты → Получение обратной связи → Улучшение продукта → Расширение клиентской базы

Эти три цикла отвечают на три категории вопросов:

•

Цикл продукта (Product Loop): как продукт постоянно совершенствуется.

•

Цикл обнаружения ценности (Value Discovery Loop): как ценность обнаруживается, проверяется и преобразуется в направление развития продукта.

•

Цикл взаимодействия с клиентами (Customer Loop): как реальные клиенты способствуют росту продукта, а не просто пассивно принимают его в конце.

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

8. Два уровня поддержки: уровень управления (Governance Layer) и уровень возможностей (Capability Layer)

Помимо трех циклов, в этой книге также используется концепция «двух уровней» для объяснения того, почему продукты AI Native отличаются от традиционного программного обеспечения.

Уровень управления (Governance Layer) Основной цикл продукта Уровень возможностей (Capability Layer)

8.1 Уровень управления (Governance Layer)

Уровень управления (Governance Layer) — это не просто окончательная проверка безопасности, а часть методологии, пронизывающая весь процесс. Он охватывает:

•

риски, полномочия, соответствие нормативным требованиям и границы данных.

•

оценку, объяснимость

, мониторинг и принятие решений о допуске;

•

ручное вмешательство, откат, реагирование на инциденты и непрерывное управление.

Иными словами, управление — это не дополнение к аудиту и одобрению, а логика принятия решений, пронизывающая каждый этап.

8.2. Уровень возможностей (Capability Layer)

Уровень возможностей (Capability Layer) представляет собой фундамент возможностей, лежащий в основе продукта. Обычно он включает:

•

Модель

•

Data

•

Инструмент

•

Навык

•

Агент

•

Память

•

Контекст

•

Система знаний

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

9. Как читать всю книгу

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

•

В главе 5 обсуждается определение границ направления, даются ответы на вопросы о том, как определять границы и как оценивать условия данных.

•

В главах с 06 по 10

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

•

В главах с 11 по 16 рассматривается построение системы и обсуждается, как способности превращаются в систему.

•

В главе 17 обсуждается процесс аудита и утверждения, а также дается ответ на вопрос, как система проходит утверждение.

•

Глава 18 посвящена производственной эксплуатации и отвечает на вопрос, как осуществлять мониторинг, обратную интеграцию и переход к следующему циклу.

•

В главах 22–24

рассматриваются циклы обнаружения ценности и циклы взаимодействия с клиентами.

•

В Приложении A приведены графические представления одностраничной структуры, модели «трех колец» и двухуровневой структуры.

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

10. Конечная цель данной методологии

Конечной целью методологии AI Native не является то, чтобы команда быстрее нагромождала функции, а то, чтобы она быстрее обнаруживала правильные способности, более уверенно воплощала их в продукты и более устойчиво преобразовывала продукты в обратную связь и сложные проценты.

Эта «сложная прибыль» в основном формируется за счёт трёх факторов:

•

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

•

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

•

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

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

Также следует добавить, что эта методология не предполагает своей вечной актуальности. По сути, она представляет собой этапный ответ на текущие реалии в области генеративного ИИ, агент-инжиниринга и продуктового инжиниринга. Если в будущем создание агентов (agent building) достигнет достаточной зрелости и сможет интегрировать в более стабильные платформенные возможности те задачи, которые сегодня в значительной степени требуют ручного выполнения — такие как определение направлений, проведение экспериментов, построение систем, аудит, проверка и управление эксплуатацией, — то эта методология, скорее всего, будет значительно упрощена или даже заменена новыми подходами. Иными словами, то, что действительно хочет сохранить эта книга, — это не какой-то фиксированный процесс, а способность постоянно переосмысливать подход к разработке продуктов в свете появления новых технологических парадигм.