ИИ-агент, который умеет сказать «не знаю»: как мы проектируем передачу задачи человеку при создании ИИ-агента

Пятница, конец дня, у менеджера по логистике в почте висит письмо: «Перенесите, пожалуйста, отгрузку, как договаривались». Кто договаривался, какую отгрузку, на когда — непонятно. Опытный сотрудник пожмёт плечами и позвонит клиенту. Неопытный угадает и перенесёт не ту. А ИИ-агент, если его об этом заранее не позаботились, угадает уверенно, быстро и без тени сомнения. Эта история про то, как мы при создании ИИ-агента для разбора входящих заявок почти месяц учили его не отвечать на всё подряд. И почему именно это оказалось самой полезной частью проекта.

Сначала агент был слишком умным

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

Первая версия работала на GigaChat Pro, данные заказов лежали в PostgreSQL, поиск по переписке и договорам шёл через pgvector. На тестовых письмах всё выглядело прекрасно. Агент находил заказ, извлекал новую дату, предлагал перенос.

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

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

ИИ-агент что это, если не умеет остановиться

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

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

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

Почему «спросить модель, уверена ли она» не работает

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

Языковая модель оценивает уверенность так же, как пишет всё остальное, — правдоподобно. Она может поставить высокую оценку ответу, который целиком построен на догадке, потому что текст получился гладким. Самооценка модели отражает, насколько складно звучит ответ, а не насколько он верен. Это касается не только GigaChat — мы проверяли ту же идею на Qwen и YandexGPT, картина везде похожая.

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

Что мы стали проверять вместо этого

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

Структурные проверки

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

• Заказ найден ровно один — хорошо. Ноль или несколько — эскалация.
• Отправитель письма привязан к контрагенту этого заказа — хорошо. Письмо пришло с чужого адреса — эскалация, без вариантов.
• Новая дата в будущем и не противоречит статусу заказа — хорошо. Заказ уже отгружен, а просят перенести — эскалация.

Эти правила скучные, зато не ошибаются и не галлюцинируют.

Расхождение между прогонами

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

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

Явная категория «непонятно»

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

Опора на найденные документы

Если агент ссылается на договорённость, мы проверяем, нашёл ли он её в переписке или договоре. Слабое совпадение при векторном поиске означает, что опоры нет, и «как договаривались» остаётся на совести человека.

Грабли: сначала агент сдавался слишком часто

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

Мы ослабили пороги — и через неделю снова поймали уверенные ошибки. Классическая качель.

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

Остальные причины оказались честными — там действительно нужен человек.

Передать задачу — не значит бросить её

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

Сейчас в интерфейсе на Angular оператор видит карточку:

• исходное письмо;
• что агент понял и в чём уверен;
• причину, по которой он остановился, простыми словами;
• варианты, которые он рассматривал (например, два найденных заказа);
• черновик действия, если агент может его предложить.

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

Что изменилось в работе людей

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

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

Как создать ИИ-агента, которому доверяют

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

1. Эскалация — это функция, а не признак неудачи. Её проектируют так же тщательно, как основной сценарий.
2. Уверенность проверяется снаружи: сверкой с базой, повторными прогонами, наличием опоры в документах. Самооценке модели не верим.
3. У каждой передачи человеку есть конкретная причина, и эти причины собираются в статистику.
4. Человек получает не проблему, а почти готовое решение с вариантами.

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

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

Похожие статьи

• Как создать ИИ-агента, когда процесс живёт в голове одного сотрудника: мы сели рядом с закупщиком
• «Нам нужен ИИ-агент», а нужен был скрипт: как мы проверяем задачу перед созданием ИИ-агента
• С чего начать создание ИИ-агента для бизнеса: как мы выбираем первый пилот
• Обучение ИИ-агента для отдела рекламаций: почему «лучшие ИИ-агенты» из рейтингов не сели на живой поток