Проектируйте не идеального агента, а предел его ошибки

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

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

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

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

Модель ошибается, и это её свойство

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

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

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

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

Вопрос не в том, ошибётся ли агент. Вопрос в том, сколько будет стоить его худшая ошибка.

Радиус ошибки и как его померить

Радиусом ошибки я называю простую вещь. Это всё, что заденет одно неверное решение агента.

Мерить его удобно в трёх единицах.

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

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

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

Разница не в модели. Разница в том, что им разрешили.

Читать своё обращение и читать всю базу это разные права

Когда я спрашиваю, какие у агента права, мне чаще всего отвечают одним словом. «На чтение». Это не ответ, потому что в нём смешаны два разных вопроса.

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

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

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

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

Полномочие без числа и без срока

Полномочие, у которого нет числа и нет срока, это не полномочие. Это состояние.

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

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

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

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

У каждого агента свой ключ

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

В одной компании я нашёл учётную запись с именем вроде ai-bot, под которой в базу ходили три разных агента. Один отвечал клиентам. Второй собирал еженедельный отчёт для владельца. Третий раскладывал входящие документы по папкам. Права у записи были объединением того, что нужно всем троим. То есть каждый из агентов мог сделать всё, что умели остальные, включая то, что ему не требовалось никогда.

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

Есть и вторая причина, менее очевидная. Когда что-то пошло не так, по отдельным ключам сразу видно, кто это сделал. По общему ключу видно только, что это сделал ai-bot, и дальше начинается расследование на неделю.

Подтверждение и журнал стоят дороже точности

Два вида действий стоят дороже всех остальных. Те, что уходят наружу, и те, что нельзя вернуть.

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

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

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

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

Одна проверка, которая меряет радиус за пять минут

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

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

Что обычно ломается и чем это ограничивают

Три ошибки я встречаю чаще остальных.

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

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

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

С чего начать разговор с командой на этой неделе

Попросите одну страницу. Не архитектурную схему и не презентацию. Схема показывает намерение, а список прав показывает, что система позволяет на самом деле.

На странице четыре пункта.

1. Под каким доступом агент ходит в каждую систему. Списком прав, а не словами «ограниченный доступ только для чтения».
2. Какое самое дорогое действие он может выполнить без человека. Названное языком бизнеса: вернуть деньги, написать клиенту, удалить заявку.
3. Какие у него пределы по количеству, по сумме и по сроку. Если пределов нет, так и написать, что их нет.
4. Откуда завтра взять ответ на вопрос, что агент сделал вчера.

Четвёртый пункт обычно самый показательный. Если журнала нет, остальные три ответа проверить нечем, и вы читаете не отчёт о системе, а пересказ намерений.

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