Измерить качество ИИ-агента на своих данных — значит взять 200 реальных обращений из собственного журнала, заранее написать к ним правильные ответы, прогнать выборку через систему и посчитать четыре доли: правильные ответы, честные отказы, ошибки без последствий и критические ошибки. Вся процедура занимает 58 часов работы трёх человек, календарно — два-три дня, и повторяется потом раз в месяц за 15 часов.
Отдельная процедура нужна потому, что на глаз качество ИИ-системы не определяется. Языковая модель формулирует неверный ответ ровно тем же спокойным деловым тоном, что и верный: там нет ни оговорок, ни запинок, ни признаков неуверенности. Мы разбирали это подробно в статье о том, почему ИИ-агент врёт клиентам — и главный вывод оттуда прямо ведёт сюда: раз ошибку нельзя услышать, её надо считать.
Ниже — методика целиком: как выбрать задачу, сколько взять примеров, кто пишет эталоны, что считать критической ошибкой, как выглядит отчёт на одну страницу и сколько всё это стоит в часах и рублях. Модельная компания в примерах — клиентская поддержка с потоком около 6 000 обращений в месяц и агентом на базе знаний, тем же, на котором мы считали контуры защиты.
Пять шагов, из которых состоит замер
Порядок шагов важнее их содержания, и нарушается он почти всегда одинаково: сначала прогоняют примеры через систему, потом смотрят на ответы и по ходу дела решают, какие из них считать правильными. После этого результат превращается в предмет переговоров, а не в измерение. Правила подсчёта фиксируются до прогона — это единственная защита от подгонки, и она бесплатна.
- 1Шаг 1. Выбрать одну задачу
Не «оценить бота», а «ответы на вопросы о статусе и составе заказа» или «отнесение обращения к одной из восьми категорий». У разных задач разные правильные ответы и разные метрики, и в одном числе они не складываются. Если задач у системы три, замеров тоже будет три — и это нормально, второй и третий дешевле первого.
- 2Шаг 2. Собрать выборку из своего журнала
200 случайных обращений за последние 2–3 месяца плюс 50 специально составленных провокационных вопросов на денежные и правовые темы. Случайные показывают, как система работает на обычном потоке; провокационные проверяют границы, которые в обычном потоке встречаются редко, но стоят дорого.
- 3Шаг 3. Написать эталонные ответы вслепую
Предметный специалист отвечает на все 250 вопросов сам, не видя ответов системы. Эталон — это не литературный текст, а список фактов, которые обязаны быть в ответе, и ссылка на документ или запись, откуда они взяты. Порядок слов не проверяется, факты проверяются.
- 4Шаг 4. Прогнать выборку в боевом режиме
Через ту же конфигурацию, что работает с клиентами: та же база знаний, те же ограничители, те же доступы к учётной системе. Прогон на «тестовом стенде с расширенными правами» измеряет другую систему, и её результат к вашей не относится.
- 5Шаг 5. Посчитать по согласованным правилам
Каждый ответ попадает ровно в одну из четырёх корзин по чек-листу из четырёх-пяти пунктов. Спорные случаи не распределяются волевым решением, а собираются отдельно: если их больше 5%, значит, правила подсчёта написаны плохо и их надо дописать до следующего замера.
Горизонтальная схема из пяти блоков со стрелками: «1. Одна задача» → «2. Выборка: 200 случайных + 50 провокационных» → «3. Эталоны вслепую» → «4. Прогон в боевом режиме» → «5. Подсчёт по четырём корзинам». Шестым блоком справа — «Отчёт на одну страницу». Под блоками дорожки исполнителей: заказчик (шаги 1, 2), предметный специалист (шаг 3), инженер (шаг 4), совместно (шаг 5). Отдельная выноска к стрелке между шагами 3 и 4: «правила подсчёта зафиксированы до прогона». Чертёжный стиль, подписи по-русски.
Сколько примеров брать и почему 30 не хватает
Самый частый вопрос на старте — «может, хватит тридцати, чтобы понять картину». Не хватит, и это считается арифметически. Погрешность доли примерно равна удвоенному корню из произведения доли на её дополнение, делённого на число примеров: 2 × √(доля × (1 − доля) ÷ n). Для результата около 90% формула даёт вот такие числа.
| Размер выборки | Погрешность при результате около 90% | Что этим реально можно сделать |
|---|---|---|
| 30 примеров | ±11 п.п. — от 79% до 100% | Только увидеть, что система совсем не работает. Отличить 85% от 95% невозможно |
| 100 примеров | ±6 п.п. | Увидеть провал по задаче целиком, но не сравнить две версии между собой |
| 200 примеров | ±4 п.п. | Рабочий минимум: видно улучшение начиная примерно с 8–10 п.п. |
| 300 примеров | ±3,5 п.п. | То же плюс возможность разложить результат по трём-четырём темам |
| 500 примеров | ±2,7 п.п. | Нужно, только когда цена одной ошибки высокая: деньги, сроки, документы |
Практический вывод из таблицы один: 200 примеров — это не «побольше для солидности», а точка, после которой затраты растут быстрее пользы. Переход со 100 на 200 примеров сокращает погрешность в полтора раза, с 200 на 500 — ещё в полтора, но стоит уже втрое дороже. Поэтому рабочая схема такая: 200 случайных примеров как основа, и только для задач с высокой ценой ошибки — 300–500.
Кривая на двух осях. Ось X — размер выборки: 30, 100, 200, 300, 500. Ось Y — погрешность в процентных пунктах от 0 до 12. Точки: 30 → ±11, 100 → ±6, 200 → ±4, 300 → ±3,5, 500 → ±2,7. Точка 200 выделена и подписана «рабочий минимум». Слева над точкой 30 подпись «на такой выборке 85% и 95% неразличимы». Под графиком формула словами: «погрешность ≈ 2 × корень из (доля × (1 − доля) ÷ число примеров)».
Это главное отличие честного замера от отчёта в презентации. Если примеры для проверки подбирает тот же, кто настраивал систему, он с высокой вероятностью — и часто без злого умысла — соберёт их из того, что уже проверял при настройке. Закрытая выборка на стороне заказчика снимает вопрос полностью и ничего не стоит: обращения и так лежат в вашем журнале.
Эталоны пишет не тот, кто настраивал систему
Эталонный ответ — это ваша версия правильного, зафиксированная на бумаге до того, как вы увидели ответ машины. Без неё процент качества недоказуем в принципе: сравнивать не с чем, и любой спор сводится к тому, чьё мнение весомее.
Список фактов, которые обязаны прозвучать в ответе на конкретный вопрос, плюс ссылка на документ, регламент или запись в учётной системе, откуда эти факты взяты. Для задачи классификации эталон — одна метка из согласованного списка. Оценивается совпадение фактов и источника, а не формулировка: перефразированный ответ с теми же фактами считается правильным.
Писать эталоны должен предметный специалист — старший оператор, методист поддержки, бухгалтер или юрист, в зависимости от задачи. Не подрядчик, не инженер и не тот сотрудник, который участвовал в настройке системы. Причина не в недоверии, а в механике: человек, знающий, как система устроена внутри, непроизвольно формулирует эталон в терминах того, что она умеет, и вопрос «а могло ли быть лучше» из замера исчезает. Сколько таких примеров нужно под разные задачи, сколько времени они занимают и как проверяется согласованность двух разметчиков — в отдельном разборе разметки данных.
- Эталон пишется вслепую, до прогона. Иначе человек невольно подгоняет свою версию под уже увиденный ответ машины — это происходит даже у добросовестных людей и не исправляется предупреждением.
- Каждый эталон содержит ссылку на источник. Если предметный специалист сам не может назвать документ, из которого берётся ответ, то вопрос не к системе: у вас нет базы знаний по этой теме, и агент здесь не поможет.
- 40 примеров из выборки размечает второй специалист независимо. Совпадение ниже 80% означает, что задача сформулирована нечётко: сначала правится инструкция, потом измеряется система.
- Спорные примеры откладываются в отдельную корзину, а не распределяются силой. Их доля — самостоятельный показатель качества вашей собственной инструкции.
Что считать критической ошибкой: список утверждается до замера
Критическая ошибка — это ответ, после которого компания несёт деньги, обязательство или правовой риск. Отличие от обычной ошибки не в тоне и не в грубости формулировки, а в последствиях, и определяется оно вашим бизнесом, а не подрядчиком. Список составляется до замера, утверждается владельцем процесса и потом не меняется задним числом. Для клиентской поддержки типовой список выглядит так.
- Названа цена, скидка или условие оплаты, которых нет в действующем прайсе.
- Назван срок, который система не могла проверить: наличие на складе, дата доставки, время записи.
- Есть ссылка на пункт документа, которого не существует, или на документ, которого нет в базе.
- Подтверждено действие, которое не выполнялось: бронь, отмена, возврат, перенос записи.
- В ответ попали данные другого клиента или персональные данные сверх необходимого.
- Дан содержательный ответ по стоп-теме, где положено молча передать диалог человеку: возврат денег, жалоба, здоровье, претензия.
В отдельную корзину они выделены не потому, что их можно игнорировать, а потому, что решения по ним принимаются разные. Критическая ошибка означает остановку или немедленное ограничение прав агента. Ошибка без последствий — неточная формулировка, лишняя вежливость, неполный, но верный ответ — означает работу с базой знаний в плановом порядке. Смешивать их в одном проценте нельзя: тогда двадцать безобидных неточностей выглядят в отчёте страшнее одного обещания несуществующей скидки.
Четыре цифры, которые видит владелец
Результат замера — четыре доли, которые в сумме дают 100%, плюс отдельный список критических случаев поштучно. Доли считаются только по 200 случайным примерам: они представляют реальный поток. Результат по 50 провокационным вопросам в проценты не смешивается — он идёт списком «прошёл / не прошёл», потому что эта подвыборка специально смещена в сторону трудных тем.
| Доля в отчёте | Как считается | Первый замер, 200 примеров | Третий месяц, те же 200 |
|---|---|---|---|
| Правильные ответы | Все обязательные факты на месте, источник верный | 140 примеров — 70% | 168 примеров — 84% |
| Честные отказы и эскалации | Система не ответила и передала человеку либо предложила уточнить | 40 примеров — 20% | 24 примера — 12% |
| Ошибки без последствий | Ответ неточный или неполный, но не создаёт обязательства | 16 примеров — 8% | 8 примеров — 4% |
| Критические ошибки | Попадание в список из предыдущего раздела | 4 примера — 2% | 0 примеров — 0 из 200 |
Читать эту таблицу нужно с погрешностью в руках. При 200 примерах и результате 70% погрешность составляет около ±6 п.п., при 84% — около ±5 п.п. Значит, разница в 14 п.п. между первым и третьим месяцем реальна: она заведомо больше разброса. А вот разница в 3 п.п. между двумя соседними замерами на такой выборке не значит ничего, и дёргать настройки из-за неё — верный способ сделать хуже.
Правило простое: если событие ни разу не встретилось на выборке из n примеров, верхняя оценка его доли — примерно 3 ÷ n. Для 200 примеров это 1,5%, то есть на потоке 6 000 обращений в месяц — до 90 случаев. Именно поэтому замер на выборке не заменяет ни провокационную подвыборку, ни выборочный контроль диалогов в бою, ни ограничители в коде. Замер показывает уровень, а ловят критические случаи три контура защиты.
Две горизонтальные накопительные полосы одинаковой длины, каждая подписана «200 примеров». Верхняя — «первый замер»: правильные 70%, честные отказы 20%, ошибки без последствий 8%, критические 2%. Нижняя — «третий месяц»: 84%, 12%, 4%, 0%. У доли правильных ответов на обеих полосах показаны усы погрешности: ±6 п.п. на верхней и ±5 п.п. на нижней. Справа подпись «разница 14 п.п. больше погрешности». Внизу отдельной строкой: «0 из 200 означает не выше 1,5%».
Отчёт на одну страницу и что по нему решают
Отчёт должен помещаться на страницу и читаться за пять минут человеком, который не участвовал в замере. Всё, что длиннее, не читают, а значит, решение принимается по устному пересказу — и замер теряет смысл. Восемь строк закрывают задачу полностью.
- 1Задача и период: что именно проверяли и за какие даты собраны обращения.
- 2Выборка: сколько примеров, как отобраны, кто отбирал, сколько из них провокационных.
- 3Разметка: кто писал эталоны, когда, какое совпадение показала контрольная сверка на 40 примерах.
- 4Четыре доли с погрешностью — те самые 70/20/8/2 и рядом результат прошлого замера для сравнения.
- 5Критические случаи поштучно: номер диалога, вопрос, ответ системы, чем именно он опасен.
- 6Три самые частые причины неверных ответов — не «модель ошиблась», а «в базе нет документа по возвратам», «прайс обновлён в учётной системе, но не в базе знаний».
- 7Что меняем до следующего замера, кто отвечает за каждый пункт и к какой дате.
- 8Дата следующего замера и решение по системе: работает как есть, работает с ограничением, остановлена.
Нарисованный (не скриншот) макет листа А4 с восемью подписанными блоками сверху вниз: «Задача и период», «Выборка: 200 случайных + 50 провокационных», «Разметка: кто и когда, сверка 40 примеров», «Четыре доли: 70 / 20 / 8 / 2, погрешность ±6 п.п.», «Критические случаи: 4 штуки, списком», «Три причины ошибок», «Что меняем и кто отвечает», «Дата следующего замера». Блок с четырьмя долями выделен рамкой. В правом верхнем углу листа — поле «решение: работает / работает с ограничением / остановлена». Чертёжный стиль, всё по-русски.
Периодичность: первые три месяца эксплуатации — ежемесячно, дальше раз в квартал. Плюс внеочередной замер в трёх случаях: сменили модель или версию платформы, существенно переписали базу знаний, изменился прайс или регламент, на который агент ссылается. Каждое такое изменение — повод прогнать выборку заново, потому что улучшение в одной теме регулярно оказывается ухудшением в соседней.
Сколько это стоит: 58 часов на первый замер и 15 на повторный
Считаем по модельным ставкам, которые используем во всём этом разделе: руководитель или владелец процесса — 2 500 ₽/час, предметный специалист — 900 ₽/час, инженер — 3 000 ₽/час. Задача: ответы клиентской поддержки по базе знаний, выборка 200 случайных обращений плюс 50 провокационных вопросов.
Повторный замер дешевле в четыре раза, потому что эталоны уже написаны, скрипт прогона существует, а совпадения система сверяет сама — руками разбираются только расхождения и новые примеры.
Сравнивать эти 18 800 ₽ в месяц надо не с нулём, а с ценой незамеченной деградации. Один разобранный инцидент, где агент пообещал скидку на партию, мы считали отдельно — вышло 132 000 ₽ вместе с компенсацией, простоем и срочной доработкой. Семь месяцев регулярных замеров стоят как один такой эпизод, причём замер обнаруживает проблему до того, как её обнаружит клиент. Тот же принцип, по которому мы считаем окупаемость автоматизации: расход сравнивается не с идеальным миром, а с ценой его отсутствия.
Когда замер не нужен или преждевременен
Методика окупается не всегда, и честнее сказать это до того, как компания потратит на неё 58 часов. Есть четыре ситуации, в которых мы сами советуем не начинать.
- Поток меньше 100 обращений в месяц. Выборка в 200 примеров тогда набирается за два месяца и перестаёт отражать текущее состояние. Рабочая замена — сплошной просмотр всех диалогов раз в неделю: при таком объёме это 2–3 часа и точнее любой выборки.
- Система ещё не запущена в бой. Замер на придуманных вопросах измеряет фантазию того, кто их придумал. До запуска работает другой инструмент — тестовый набор из реальных обращений прошлого года, и результат по нему нельзя выдавать за качество в эксплуатации.
- Задача решается правилом. Если ответ однозначно выводится из справочника или условия в коде, там нечего измерять долями: правило либо срабатывает, либо нет, и проверяется десятком примеров. ИИ там вообще не нужен, а замер только легитимизирует лишнюю сложность.
- Нет владельца процесса. Если некому утвердить список критических ошибок и принять решение по отчёту, замер превращается в отчёт ради отчёта. Как это выглядит на длинной дистанции, мы разбирали в материале о том, что бывает, когда у процесса нет владельца.
И последнее. Замер не улучшает систему — он только показывает, где она стоит. Компании регулярно проводят два-три честных замера, аккуратно оформляют отчёты и не делают по ним ничего, потому что в отчёте нет строки «кто отвечает и к какой дате». Эта строка важнее самих процентов: без неё вы платите 18 800 ₽ в месяц за наблюдение за деградацией, а не за её предотвращение.
Процент качества без описания выборки — это не измерение, а мнение, оформленное цифрой.
