False positive rate у агента поддержки: как считать без самообмана

Вы подключили ИИ-агента к поддержке, дашборд показывает точность 94 процента, и кажется, что всё под контролем. Проблема в том, что «точность» без разбивки на типы ошибок ничего не говорит о риске. Клиент, которому агент уверенно назвал неправильный срок возврата или придумал несуществующий тариф, не утешится тем, что в 94 случаях из 100 система была права. Ключевая метрика для поддержки — не общая accuracy, а false positive rate: как часто агент выдаёт ответ, который выглядит корректным, но на деле ошибочен или выдуман.

Что считать ложным срабатыванием у агента поддержки

Сначала нужно договориться, что вообще считается ошибкой. Для классификатора всё просто: предсказал класс А, а был класс Б. У диалогового агента исход сложнее, потому что «правильность» ответа многомерна. Ответ бывает точным по фактам, но не по тону; уместным по смыслу, но с выдуманной деталью; корректным, но не решающим задачу клиента.

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

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

Формула, которую легко посчитать неправильно

False positive rate в классической постановке — это доля ложных срабатываний среди всех случаев, где верным ответом было «нет»:

FPR = FP / (FP + TN)

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

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

Как собрать данные для честного расчёта

Метрика хороша ровно настолько, насколько честна разметка. Дашборд провайдера сам по себе не знает, где агент ошибся: он знает, что ответ был выдан, а не что он был верным. Верность придётся размечать отдельно.

1. Соберите репрезентативную выборку. Не последние 50 диалогов, а случайную выборку за период — например, 300–500 обращений, распределённых по типам вопросов. Перекос в сторону простых тем занизит FPR.
2. Зафиксируйте эталон. Для каждого вопроса нужен «золотой» ответ: что было верным решением и должен ли был агент отвечать сам. Разметку делают люди, знающие продукт, а не сам агент.
3. Разметьте исход каждого диалога по таблице выше: TP, FP, TN, FN.
4. Разведите два вида FP. Отдельно считайте фактические ошибки (агент соврал по существу) и процедурные (ответил там, где нужно было передать человеку). Лечатся они по-разному.
5. Проверьте согласованность разметчиков. Если два человека по-разному оценивают верность одного ответа, метрика будет плавать. Спорные случаи выносите в отдельную категорию, а не приписывайте к удобному классу.

Одна цифра точности успокаивает. Разбивка на типы ошибок показывает, где агент опасен — а именно за это, а не за среднее, придётся отвечать перед клиентом.

Порог уверенности и как он двигает метрику

Большинство агентов можно настроить так, чтобы при низкой уверенности они передавали диалог человеку. Порог уверенности напрямую управляет балансом: поднимаете его — падает FPR, но растёт число лишних эскалаций (false negative), и нагрузка на людей увеличивается. Опускаете — агент закрывает больше обращений сам, но чаще ошибается.

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

Чего не покажет FPR в одиночку

False positive rate — важная, но не единственная метрика. Рядом стоит держать:

• False negative rate — сколько решаемых вопросов агент зря отдал человеку. Высокий FNR означает, что вы платите за автоматизацию, но не получаете экономии.
• Долю галлюцинаций — подкласс FP, где ответ не просто неверен, а содержит выдуманные факты. Для RAG-агентов* это критично: проверяйте, опирается ли ответ на реальные документы из базы.
• Тяжесть ошибки. Неверный ответ про часы работы и неверный ответ про условия возврата денег — не одно и то же. Взвешивайте FP по цене ошибки, а не считайте их равными.

Кому это нужно, а кому можно проще

Считать FPR обязательно, если:

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

Можно ограничиться выборочным аудитом, если:

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

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

* RAG (retrieval-augmented generation) — подход, при котором модель перед ответом достаёт релевантные документы из базы знаний и опирается на них, а не только на то, что «запомнила» при обучении. Снижает риск выдумок, но не убирает его: модель может неверно интерпретировать найденный текст.