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

1.1. Почему генеративный ИИ делает эту методологию жизнеспособной

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

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

Говоря более конкретно, генеративный ИИ привёл как минимум к пяти непосредственным изменениям:

•

Он позволяет напрямую преобразовывать обсуждение проблем

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

•

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

•

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

•

Он позволяет команде уже на этапе запуска экспериментов напрямую создавать рабочие демо-версии, а не ограничиваться обсуждением на бумаге.

•

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

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

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

1.2. Для каких типов продуктов эта методология подходит больше всего

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

•

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

•

Сама проблема несет в себе неопределённость и не может быть полностью сформулирована в виде правил с самого начала.

•

Задачи зависят

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

•

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

•

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

Поэтому данная методология, как правило, лучше подходит для следующих типов продуктов:

•

AI Native-продукты на основе знаний, такие как корпоративные системы вопросов и ответов, «Copilot» на основе знаний, рабочие платформы на основе знаний.

•

AI Native аналитические продукты, такие как анализ данных, анализ эксплуатации и обслуживания, диагностика бизнеса, атрибуция в службе поддержки.

•

AI Native-продукты для совместной работы над процессами, такие как помощники по обслуживанию клиентов, помощники по продажам, операционные Copilot и помощники по внутренним процессам.

•

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

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

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

Для таких команд методология, изложенная в этой книге, также ценна, просто им лучше подойдет «упрощённая версия», а не «полная версия». Точнее говоря:

•

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

•

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

Другими словами, эта книга наиболее эффективно применима к продуктам, изначально разработанным с учетом ИИ (AI Native); однако вторая по значимости область её применения — это «программные команды, уже вступившие в эпоху ИИ-поддержки разработки». Говоря более прямо, этот уровень можно охарактеризовать как «ИИ продолжает использовать ИИ»: ИИ не только присутствует в продукте, но и начинает появляться в самом процессе разработки продукта.

1.3. Какие типы продуктов не подходят для прямого применения

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

К наиболее типичным непригодным формам относятся:

•

Чисто детерминированные инструментальные продукты, такие как калькуляторы, фиксированные отчеты, простые формы документооборота, системы CRUD с полностью понятными правилами.

•

Системы, в основном полагающиеся на обработку транзакций, а не на обработку возможностей

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

•

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

•

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

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

1.4. В каких сценариях нецелесообразно внедрять данную методологию

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

Наиболее распространённые категории неподходящих сценариев:

•

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

•

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

.

•

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

•

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

•

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

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

1.5. Метод быстрого принятия решений

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

•

Заключается ли основная ценность данной задачи в понимании сложной информации, принятии полуструктурированных решений или выполнении сложных задач?

•

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

•

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

и постоянную обратную связь?

•

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

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

1.6. Непосредственные преимущества данной методологии

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

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

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

Краткий обзор сферы применения и ограничений

Критерии оценки

Более подходит для полного применения

Не рекомендуется применять в полном объеме

Более подходит для упрощённого применения

Форма продукта

AI Native: продукты для знаний, аналитики, совместной работы и выполнения задач

Чисто детерминированные инструменты, простые операции CRUD, страницы однократного использования

Обычное программное обеспечение, но в процессе разработки широко используется ИИ

Типы задач

Понимание сложной информации, полуструктурированные суждения, выполнение сложных задач

Задачи с полностью ясными правилами, высокой определённостью и низкой степенью изменчивости

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

Условия данных

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

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

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

Структура рисков

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

Крайне низкая отказоустойчивость и отсутствие возможности ручного вмешательства в крайнем случае

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

Наиболее подходящий подход

Полное следование основной линии

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

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

Краткий обзор входов и выходов пяти этапов

Этап

Ключевые входы

Основные задачи

Типичные результаты

Определение направления

Поиск проблем, бизнес-цели, текущее состояние данных

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

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

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

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

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

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

Построение системы

Конвергирующие возможности, границы неудач, цепочки данных

Разбиение системы, организация контекста, интеграция знаний, мониторинг и откат

Инженерно-реализуемая система, интерфейсы управления, наблюдаемая структура

Аудит и одобрение

Структура системы, результаты оценки, доказательства «Shadow»

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

Заключение «go / no-go», стратегия запуска, ограничения при вводе в эксплуатацию

Производственная эксплуатация

Одобренная система, показатели мониторинга, пользовательский трафик

Наблюдение за реальным поведением, выявление сбоев, сбор обратной связи и ее использование

Новые образцы, новые тесты, новые проблемы, новый раунд приоритезации

1.7. Объяснение ключевых концепций и новых терминов данной главы

•

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

•

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

•

Продуктовый цикл (Product Loop): основной цикл от определения проблемы до обратной связи после запуска, отвечающий на вопрос «Как продукт создаётся на постоянной основе».

•

Цикл обнаружения ценности (Value Discovery Loop): цикл, проходящий от экспериментов к обнаружению ценности, проверке на рынке и корректировке направления развития продукта, отвечающий на вопрос «Как обнаруживается и проверяется ценность?».

•

Цикл взаимодействия с клиентами (Customer Loop): цикл, проходящий от раннего тестирования продукта клиентами до получения обратной связи, внедрения улучшений и расширения, отвечающий на вопрос «Как клиенты способствуют росту продукта?».

•

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

•

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

•

Этапные контрольные точки (Stage Gate): минимальные условия, которые команда должна выполнить перед переходом к следующему этапу; процесс не зависит от субъективных оценок.

•

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

•

Теневая система (Shadow System): система, позволяющая ИИ работать параллельно в реальных условиях, но не принимая непосредственного управления бизнесом; используется для сбора доказательств и выявления рисков.

•

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

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

Рис. 4-1 Общая схема методологии

Определение направления -> Проведение испытаний -> Построение системы -> Проведение аудита и выдача разрешения -> Производственная эксплуатация -> Циклическая закачка -> Определение направления обратного потока

Источник обратной связи: - Примеры неудач - Поведение пользователей - Сигналы из бизнес-процессов - Ручная корректировка

«Циклическая обратная связь (Loop)» в данном контексте не является отдельным крупным этапом, а означает, что мониторинг, обратная связь, случаи сбоев, поведение пользователей и бизнес-сигналы из производственной среды вновь поступают в следующий цикл определения направления и проведения экспериментов. Иными словами, производственная эксплуатация — это не конечная точка, а отправная точка для нового цикла обучения продукта.

Эти шесть этапов можно рассматривать как шесть последовательных вопросов:

•

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

•

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

•

Построение системы: как превратить проверенные возможности в стабильную систему?

•

Аудит и запуск: можно ли безопасно, надёжно и контролируемо ввести эту систему в эксплуатацию?

•

Эксплуатация: как система ведет себя в реальных условиях и какие новые проблемы при этом выявляются?

•

Обратная связь: как эти отзывы используются в следующем цикле определения задачи, экспериментов и построения?

Эта основная линия составляет «цикл продукта» (Product Loop), описанный в данной книге, и является самой ключевой частью всей методологии.

2.1. Что на самом деле означает каждый узел на блок-схеме

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

•

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

•

Начало тестирования — это не «проверка модели», а проверка возможностей, поиск оптимальной формы продукта и уточнение целей.

•

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

•

Одобрение аудита — это не «окончательное утверждение», а четкое определение границ допуска, ответственности за риски и способа запуска в эксплуатацию.

•

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