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

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

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

Меня зовут Иван Крутько, я руковожу управлением SMB и Digital в «Софтлайн Решениях» (ГК Softline). Я занимаюсь трансформацией российских компаний и каждый день вижу разницу между тем, что ИИ-проекты обещают, и тем, что они делают. Разработчики есть, платформы есть, бюджеты на ИТ есть, но между «как было бы круто» и «это работает» по-прежнему пропасть. И открывается она не на пилоте, а уже на прототипе.

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

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

Что считать рабочим прототипом

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

Если совсем коротко: демо доказывает, что агент может. Прототип — что он делает, и делает не один раз.

Требования к нему можно свести к пяти пунктам. Прототип рабочий, если:

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

• решение справляется с новым примером из того же класса задач, которого команда не видела при отладке;

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

• команда обозначила, где заглушки, где ручные шаги и что пока не подключено.

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

Теперь о ситуации из заголовка. Отчет агента сам по себе ничего не гарантирует: фразу «заявка создана» он напишет так же легко, как любую другую. Правду знает только тестовая система.

В Шэньчжэне это сформулировали так: проверяется не то, ответил ли агент, а то, изменил ли он статус в CRM, ERP или учетной системе. Ответ — это слова. Измененная запись — это работа.

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

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

Демо, прототип, MVP и продакшен

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

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

Полезно держать в голове и вторую шкалу — не продукта, а самого агента. Он проходит три ступени:

1. Умеет говорить. Отвечает на вопросы и ищет информацию. Это чат-бот, даже если его называют агентом.

2. Умеет работать. Встроен в процесс: вызывает инструменты, работает с документами и системами, доводит операцию до конца.

3. Выходит на должность. Сам ведет участок, отвечает за результат и имеет свой KPI. Человек задает цель и границы, агент сдает готовую работу.

Прототип должен доказать вторую ступень. Третья — это пилот и продакшен. Обещать ее на прототипе — самый надежный способ разочаровать заказчика. А выдавать первую ступень за вторую — именно та ошибка, с которой началась эта статья.

Что может доказать прототип

«Будет ли ИИ работать в этой компании?» На такой вопрос прототип не ответит. Зато он может проверить конкретную гипотезу. Какую именно, определяют на берегу: от этого зависит, чем подтверждать результат.

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

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

Как выглядит хорошая задача

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

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

• Данные и доступы. У команды есть все необходимое: примеры обращений, сведения о заказах и правила ответов, причем доступ к ним заранее согласован.

• Признаки успеха. Известно, какой результат заказчик считает правильным.

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

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

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

• Безопасный эксперимент. Все происходит на тестовых данных, реальным клиентам ответы не уходят.

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

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

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

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

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

Какими будут данные

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

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

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

• Связи. Если нужно сопоставлять несколько документов, после замены названий и ID они должны по-прежнему быть связаны между собой.

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

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

• Свежесть. Агент должен видеть, насколько стары данные. Остатки склада месячной давности — это уже история, и об этом он обязан сказать.

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

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

То же с правами. Агент получает ровно те права, что и сотрудник, от имени которого работает: чего не видит человек, не должен видеть и агент. Права администратора «чтобы не мешали» — самый быстрый способ собрать прототип, который работает в песочнице и никогда не заработает в реальной системе. Каждое значимое действие агента пишется в журнал и может быть откачено.

Как отличить прототип от красивого демо

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

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

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

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

• соответствие задаче заказчика;

• корректность технической реализации;

• потенциал внедрения;

• степень готовности решения;

• качество презентации;

• автономность агента;

• безопасность работы с данными;

• экономика эксплуатации.

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

Вместо вывода

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

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

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

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