Как проверять качество ИИ-сотрудников: KPI, тесты и корпоративные бенчмарки

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

Контроль качества ИИ начинается с определения результата и способа его проверки. Без этого «точность 95%» легко оказывается красивым числом без понятного знаменателя. Разберём, какие KPI нужны бизнесу, как собрать собственный набор испытаний и что мы предлагаем понимать под AI Office Bench.

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

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

Anthropic в техническом разборе оценки агентов отдельно различает записанный ход работы и фактическое итоговое состояние. Для бизнес-проверки это важная мысль: фраза агента «всё выполнено» не заменяет проверку результата в целевой системе. Anthropic · Demystifying evals for AI agents ↗

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

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

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

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

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

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

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

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

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

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

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

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

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

Представим вымышленный тест из 100 запросов на подготовку КП. В 84 случаях черновик принят без содержательных исправлений. Ещё 8 удалось принять после правок сотрудника. Остальные 8 не доведены до пригодного результата в рамках теста.

Можно честно сообщить о 92 принятых результатах, но нужно отдельно показать 84% без содержательных исправлений и ручную работу по остальным. Если время проверки исправленных случаев велико, именно оно определяет практическую экономику.

Теперь предположим, что среди 84 принятых документов обнаружилась одна отправка без положенного согласования. Её нельзя компенсировать красивым общим процентом. Это отдельное критичное нарушение, которое может блокировать запуск данного режима до исправления.

Этот пример показывает структуру отчёта, а не фактические показатели AI Office. Реальные значения, размер выборки и допустимые пороги должны появиться из согласованного испытания.

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

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

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

Это не повод отказаться от измерений. Напротив, нужно честно описывать, что проверено, сколько раз и какие случаи ещё не покрыты. Так ограничения становятся предметом управления, а не сноской после рекламного обещания.

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

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

При спорных примерах сохраняйте причину разногласия и уточняйте критерии. Если два опытных сотрудника понимают «правильное КП» по-разному, сначала нужно согласовать рабочее правило. Иначе система будет получать противоречивую обратную связь.

Не требуйте совпадения текста слово в слово там, где допустимы разные корректные формулировки. Проверяйте смысл, обязательные поля и фактическую опору. И наоборот, номер договора или сумму нельзя оценивать только по общему впечатлению.

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

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

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

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

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

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

Продакшен-наблюдение дополняет тесты: сотрудники сообщают ошибки, команда разбирает их и добавляет подходящие случаи в последующие испытания. Общий подход NIST AI RMF рассматривает управление рисками при проектировании, использовании и оценке ИИ; конкретный протокол компании остаётся её проектным решением. NIST · AI Risk Management Framework ↗

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

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

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