Как меряют надёжность агентов на Западе — и что перенести в приёмку пилота

Почему «работает в демо» — не критерий приёмки

Исследование kili-technology (2026) фиксирует разрыв в 37% между лабораторными бенчмарками и production-поведением агентов. Агент, показывающий 92% accuracy на тестовой выборке, в реальных условиях сталкивается с распределением запросов, которого не было в демо: граничные случаи, нестандартные формулировки, цепочки из нескольких инструментов, временны́е зависимости.

PAEF (Production Agentic Evaluation Framework, arXiv 2026) описывает 7 режимов отказа, специфичных для production-среды. Ключевой вывод: стандартные метрики — ROUGE, BERTScore, accuracy — не обнаруживают 4 из 7 режимов. Среди незаметных для accuracy: дрейф качества во времени, накопление ошибок в многошаговых цепочках, сбои при передаче контекста между агентами (multi-agent handoff), «тихие» отказы — когда агент возвращает ответ без ошибки, но результат неверен.

Таксономия ICML 2026 (Cornford & Cross) добавляет принцип, который стоит вынести отдельно: финальный скор скрывает почти всё важное. Диагностика по трейсу — пошаговая проверка каждого вызова инструмента, каждого решения агента — обнаруживает то, что агрегированная метрика усредняет в «приемлемый» результат.

Если вы ещё выбираете, нужен ли агент и на какой стадии зрелости находится ваша организация — см. разбор Gartner-фреймворка в статье «Gartner и enterprise AI agents: что это значит для бизнеса в 2026». Здесь мы начинаем с момента, когда выбор уже сделан и пилот завершён.

Накопительный риск: математика, которую нельзя игнорировать

Для многошаговых агентов в ERP и документообороте действует простая, но неочевидная математика.

Если агент выполняет каждый шаг с надёжностью P, то вероятность успешного завершения цепочки из N шагов равна P^N.

При надёжности 90% на каждый шаг пятишаговая цепочка успешна только в 59% случаев. При 80% — в 33%. Это означает: агент, который «хорошо работает» на отдельных операциях, может быть неприемлем для сквозного процесса.

Вывод для ЛПР: перед приёмкой определите, сколько шагов в вашей цепочке, и установите требуемый end-to-end success rate. Затем посчитайте минимальный per-step success rate: для 5-шаговой цепочки с требованием 90% end-to-end нужно 98% на каждый шаг. Если агент не достигает этого порога — это не повод отказаться от агента, но повод добавить human-in-the-loop на критических узлах.

Метрики приёмки: таблица с порогами

Ни один из западных источников не даёт готовой таблицы «метрика → порог → что делать». Ниже — синтез PAEF, CLASSic (Cost, Latency, Accuracy, Stability, Security) и операционных рекомендаций Databricks, адаптированный под B2B РФ без ML-отдела.

Важно: latency измеряйте перцентилями, не средним. p99 определяет восприятие надёжности пользователем — один медленный запрос из ста разрушает доверие к системе.

Цена ошибки: какой порог достаточен для вашего процесса

Не все задачи одинаково чувствительны к ошибке агента. Вот рамка для установки порогов:

Для финансовых и ERP-операций правило однозначное: даже при task success rate 97% агент не должен выполнять необратимые действия без подтверждения человека. Это не недоверие к технологии — это управление операционным риском.

Офлайн-eval vs. онлайн-мониторинг: два разных инструмента

ЛПР часто путают эти два этапа, и это приводит к ложному ощущению безопасности.

Офлайн-eval — это приёмка до запуска. Вы берёте golden dataset из 50+ реальных задач (не синтетических), размечаете эталонные ответы, прогоняете агента и считаете метрики. Цель — зафиксировать baseline и принять решение «годен / не годен для продакшна».

Онлайн-мониторинг — это непрерывная проверка после запуска. Реальные запросы отличаются от golden dataset: меняется распределение тем, обновляется модель у провайдера, эволюционируют интеграции. Без мониторинга вы узнаёте о деградации от пользователей.

Данные Deloitte (через Thinking Company, 2026): непрерывный eval снижает production-инциденты на 67%. Без него качество деградирует за 30–60 дней после запуска.

Минимальная схема онлайн-мониторинга без специализированных платформ: еженедельная ручная выборка 5–10% выходов, оценка по рубрике (3–5 критериев, шкала 1–3), предметным экспертом — не IT-специалистом. Это и есть sampled review, который Anthropic и Thinking Company называют основным quality signal для high-stakes workflows.

Чеклист приёмки пилота

Офлайн-eval (до передачи в продакшн)

• Собран golden dataset: минимум 50 реальных задач из вашего процесса (не синтетика, не демо-сценарии)
• Для каждой задачи определён эталонный результат и критерий успеха
• Зафиксирован baseline: как тот же процесс выполнялся до агента (время, ошибки, стоимость)
• Измерен task success rate на golden dataset — соответствует порогу для вашего типа задач
• Измерен human intervention rate — не превышает установленный порог
• Проверена tool invocation accuracy: трейс каждого вызова инструмента сверен с эталоном
• Измерена latency p95 — соответствует SLA процесса
• Проведена проверка на hallucination: выборка 20+ ответов сверена с источниками
• Для задач с ПДн: проверен compliance check rate, настроен PII-фильтр на выходе
• Посчитан накопительный риск для вашей цепочки (N шагов × per-step reliability)
• Определены точки human-in-the-loop для необратимых операций

Онлайн-мониторинг (после запуска)

• Настроен лог всех запросов и ответов агента с timestamp
• Определена процедура еженедельной выборки: 5–10% выходов → оценка предметным экспертом
• Создана рубрика оценки (3–5 критериев, шкала 1–3) — согласована с бизнес-заказчиком
• Установлены пороги алертов: снижение task success rate >5% от baseline — эскалация
• Определена процедура при деградации: откат, дообучение или ручной режим
• Запланирован повторный офлайн-eval через 60 дней после запуска
• Зафиксирован cost per task — мониторинг роста >20% как сигнал неэффективности
• Для multi-agent систем: отдельный мониторинг handoff-точек между агентами

Как провести eval без LangSmith и ProxyAPI

Западные источники предполагают наличие LangSmith, LangChain observability или облачных LLM-as-judge. В реалиях РФ 2026 года это часто недоступно. Рабочие альтернативы:

Трейс-логирование: большинство фреймворков (LangChain, LlamaIndex, самописные) позволяют логировать каждый шаг агента в структурированный формат (JSON). Этот лог — основа для диагностики по трейсу без внешних платформ. Минимальный набор полей: шаг, инструмент, входные параметры, выход, время выполнения, статус.

Локальный LLM-as-judge: разверните модель через Ollama или аналог. Напишите промпт-рубрику с 3–5 критериями. Откалибруйте на golden dataset: запустите судью на 50+ примерах с человеческой разметкой, посчитайте Cohen's kappa. Kappa >0.6 — судья пригоден для мониторинга. Kappa <0.4 — меняйте промпт или модель.

Ручная выборка как основной инструмент: 50 размеченных примеров достаточно для старта (данные Databricks, 2026). Предметный эксперт, оценивающий 5–10% выходов еженедельно, даёт более надёжный сигнал, чем некалиброванный автоматический судья.

Специфика 1С и ERP-интеграций: tool invocation accuracy для 1С-коннекторов требует отдельного внимания. Агент может вернуть «успешный» ответ, получив от 1С пустой результат или ошибку, которую не распознал как ошибку. Это классический «тихий отказ» из таксономии arXiv 2606.14589. Решение: явная проверка кода ответа от 1С в трейсе, а не только финального текста агента.

Анти-паттерны приёмки

Западные источники и российская практика сходятся в одном наборе ошибок:

Принимать агента по демо. Демо-сценарии отбираются так, чтобы агент выглядел хорошо. Golden dataset из реальных задач обнаруживает граничные случаи, которых в демо нет.

Измерять только accuracy. Агент с accuracy 95% и latency p99 = 45 секунд неприемлем для интерактивного процесса. Агент с accuracy 90% и human intervention rate 25% перегружает операторов.

Считать eval разовым событием. Качество деградирует за 30–60 дней без мониторинга. Провайдер обновляет модель, меняется распределение запросов, эволюционируют интеграции.

Доверять LLM-as-judge без калибровки. Некалиброванный судья создаёт «зелёный дашборд», маскирующий реальные проблемы. Расхождение с человеческой оценкой >15% — сигнал перекалибровки.

Игнорировать накопительный риск. 90% per-step = 59% end-to-end при 5 шагах. Это не «хорошая надёжность» для финансового документооборота.

Не фиксировать baseline. Без измерения «как было до агента» невозможно доказать улучшение при приёмке и обосновать продолжение проекта.

Применять западные пороги без адаптации. Containment rate 70% приемлем для FAQ-бота, но катастрофичен для агента, маршрутизирующего финансовые заявки.

Eval — это не разовая процедура перед подписанием акта, а непрерывная практика управления качеством. Западные фреймворки дают инструментарий; задача ЛПР — адаптировать пороги под цену ошибки в своём процессе и обеспечить инфраструктуру мониторинга до передачи агента в продакшн, а не после первого инцидента.