Какие сценарии включить в проверку AI-агента?
AI-агент — это программа, которая получает задачу, использует доступные ей данные и инструменты, а затем выполняет один или несколько шагов ради конкретного результата. Например, она может разобрать обращение клиента, найти сведения в базе знаний, подготовить ответ и передать сложный случай сотруднику. Поэтому принимать такого агента только по красивому диалогу на презентации нельзя.
Демо обычно показывает короткий и заранее подготовленный путь. Запрос сформулирован понятно, нужные сведения есть в системе, а спорных трактовок почти нет. В реальной работе всё иначе: люди сокращают слова, путают названия, задают несколько вопросов сразу и не сообщают важные детали. Проверка должна воспроизводить именно эту среду.
Я бы начал со списка реальных рабочих ситуаций. Не абстрактных команд вроде «ответить клиенту», а конкретных случаев: покупатель просит изменить заказ после оплаты, руководитель хочет сводку с необычным разрезом, сотрудник ищет правило, которое недавно обновили. Для каждого сценария стоит зафиксировать исходные данные, ожидаемый результат и допустимые действия агента.
Полезно разделить сценарии на несколько групп:
- обычные и часто повторяющиеся запросы;
- редкие, но важные случаи;
- неполные и противоречивые обращения;
- запросы с ошибками, разговорными формулировками и лишними деталями;
- попытки получить сведения, к которым у пользователя нет доступа;
- задачи, выходящие за полномочия агента.
Отдельно нужны связанные цепочки. Допустим, клиент сначала спрашивает об условиях возврата, затем уточняет свой случай и позже меняет одну из исходных деталей. Агент должен учитывать контекст, но не переносить в новый ответ сведения, которые уже стали неактуальными.
Хороший набор для приёмки собирают не только разработчики. Руководитель процесса знает правила, сотрудники помнят неудобные исключения, а специалисты поддержки видят реальные формулировки пользователей. Вместе они создают проверку, которую трудно пройти за счёт удачно подобранного демо.
Как проверить, что агент не придумывает отсутствующие сведения?
Главное отличие здесь не в красоте текста, а в происхождении утверждений. Обычная автоматизация работает по заранее заданным условиям: получила определённое значение — выполнила известное действие. Языковая модель формирует ответ вероятностно, подбирая подходящее продолжение. Текст может звучать уверенно, даже когда подтверждения нет.
Поэтому оценивать нужно не только итоговую фразу, но и её опору на данные. Если агент сообщает срок, статус заказа, условие договора или внутреннее правило, проверяющий должен понимать, откуда взялось это утверждение. В зависимости от задачи источником может быть документ, запись в учётной системе, карточка клиента или результат вызова внешнего сервиса.
Для проверки я бы подготовил пары похожих запросов. В первом случае нужное сведение действительно есть в доступном источнике, во втором его нет. Например, в базе указана дата одного платежа, но отсутствует дата другого. Если агент одинаково уверенно называет обе, значит, он достраивает пробелы вместо честной работы с данными.
Ещё один полезный приём — намеренно добавить конфликт. В инструкции указано одно условие, а в устаревшем файле — другое. Здесь важно увидеть не случайно правильный ответ, а предусмотренное поведение: какой источник считается главным, замечает ли система расхождение и сообщает ли о нём.
Проверке подлежат и ссылки на документы. Название реально существующего файла ещё не доказывает, что ответ основан на его содержании. Нужно сопоставлять конкретное утверждение с конкретным фрагментом источника. Если подтверждение нельзя показать, такой ответ нельзя считать надёжным только из-за убедительного тона.
Разработка ИИ-агентов требует заранее определить, какие утверждения допустимы без обращения к данным, а какие всегда нуждаются в проверяемом основании. Для приветствия источник не нужен. Для суммы задолженности, условия возврата или остатка товара — нужен обязательно.
Что должно происходить, если система не знает ответа?
Нехватка данных — нормальная рабочая ситуация, а не ошибка, которую надо скрыть любой ценой. Правильное поведение зависит от цены неверного решения и от того, можно ли безопасно уточнить запрос.
В простом случае агент должен прямо сказать, какого сведения ему не хватает, и задать понятный вопрос. Если пользователь просит проверить заказ, но не указал номер, система запрашивает номер, а не угадывает его по косвенным признакам. Если формулировку можно понять двумя способами, агент кратко обозначает варианты и просит выбрать нужный.
Для задач с низким риском допустим предварительный ответ с явной оговоркой. Например, система может предложить черновик внутреннего текста, отметив неизвестные поля. Но там, где ошибка влияет на деньги, обязательства, доступ к данным или отношения с клиентом, контроль человека должен быть жёстче. Агент готовит материалы и передаёт случай ответственному сотруднику, не совершая окончательного действия самостоятельно.
Есть задачи, которые хорошо подходят агенту: поиск по утверждённой базе знаний, разбор входящих обращений, подготовка черновиков, сбор сведений из нескольких доступных источников. Плохо подходят ситуации, где нет устойчивых правил, исходные данные нельзя проверить, а ошибка создаёт серьёзные последствия. Передача агенту права на возврат денег, изменение договора или публикацию чувствительной информации требует гораздо более строгих ограничений, чем подготовка проекта ответа.
Важно не маскировать отказ общей фразой «не удалось выполнить запрос». Полезный ответ объясняет следующий шаг: уточнить реквизит, приложить документ, обратиться к определённой роли или дождаться проверки. Пользователь должен понимать, остановилась ли система из-за отсутствия сведений, недостатка прав, конфликта источников или технического сбоя.
Какие результаты разработки нужно зафиксировать в критериях приёмки?
Критерии приёмки описывают не общее впечатление, а наблюдаемый результат. Формулировка «агент хорошо отвечает» слишком расплывчата. Нужны условия, которые разные участники проверки смогут трактовать одинаково.
Сначала фиксируется состав системы. В него входят сама языковая модель, инструкции для неё, источники данных, доступные действия и журнал работы. Инструкции задают правила поведения. Источники дают факты. Действия связывают агента с почтой, CRM или другой рабочей системой. Журнал сохраняет запросы, обращения к данным, ошибки и итоговые ответы, чтобы спорный случай можно было разобрать.
Для каждого проверочного сценария стоит записать:
- какой результат считается правильным;
- какие источники агент обязан использовать;
- какие действия ему разрешены и запрещены;
- когда он должен запросить уточнение;
- при каких условиях нужна передача человеку;
- что сохраняется в журнале;
- как система сообщает об ошибке или недоступности источника.
Отдельно фиксируются права доступа. Агент не должен получать сведения только потому, что умеет их найти технически. Доступ определяется ролью пользователя и правилами компании. Проверка должна подтверждать, что закрытая информация не появляется ни в прямом ответе, ни в пересказе, ни в приложенном документе.
Наконец, нужен согласованный набор тестовых случаев и сохранённые результаты их прохождения. Это становится отправной точкой для следующих изменений. После обновления инструкций, данных или подключённой системы те же сценарии запускают повторно и проверяют, не сломалось ли уже принятое поведение.
Сколько времени наблюдать за агентом до расширения его полномочий?
Универсального срока здесь нет. Календарная неделя сама по себе ничего не доказывает: агент мог обработать много однотипных запросов и ни разу не встретить важное исключение. Решение лучше связывать с достаточным разнообразием случаев, стабильностью результатов и разобранными ошибками.
На старте я бы ограничил область работы одним понятным процессом и минимальными полномочиями. Сначала агент может готовить черновики без самостоятельной отправки. Затем — выполнять безопасные действия с возможностью быстрой отмены. И только после устойчивой работы на реальных сценариях можно обсуждать более значимые операции.
Во время наблюдения полезно смотреть не только на долю удачных ответов. Важны характер ошибок, повторяемость сбоев, качество уточняющих вопросов, корректность обращения к источникам и понятность передачи человеку. Одна редкая, но серьёзная ошибка может быть важнее десятков нормальных диалогов.
Полномочия стоит расширять небольшими шагами. Для каждого шага заранее определяется, какое новое действие получает агент, как оно контролируется и при каком событии доступ будет ограничен обратно. Если появились новые типы запросов, изменились документы или подключилась другая система, часть наблюдения фактически начинается заново: прежняя статистика не полностью описывает изменившиеся условия.
Первый практический шаг — выбрать один реальный процесс и собрать несколько десятков разнообразных обращений без персональных и секретных данных. Затем отметить ожидаемый результат, обязательные источники и моменты передачи сотруднику. Если эти правила удаётся сформулировать однозначно, идею можно проверять на ограниченном участке; если участники процесса расходятся даже в правильном ответе, сначала нужно договориться о самом порядке работы.