Создание системы оценки эффективности ИИ-агентов в производственной среде: структура из 12 метрик на основе более чем 100 развертываний.

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

Делиться

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

«Откуда вы знаете, что ваш агент не видит галлюцинаций, вызванных симптомами пациента?»

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

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

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

Краткий обзор структуры из 12 показателей

Категория	Метрическая система	Что именно измеряет	Критический порог
Извлечение	Контекстная релевантность	Соответствуют ли полученные фрагменты запросу?	>0.85
Извлечение	Воспроизведение контекста	Удалось ли нам получить всю доступную необходимую информацию?	>0.90
Извлечение	Точность контекста	Являются ли наиболее релевантными фрагменты, занимающие верхние строчки рейтинга?	>0.80
Извлечение	Задержка извлечения	Как быстро завершилась операция по извлечению?	<200 мс p95
Поколение	Ответ Верность	Соответствует ли ответ полученному контексту?	>0.95
Поколение	Релевантность ответа	Отвечает ли ответ на вопрос пользователя?	>0.90
Поколение	Частота галлюцинаций	Как часто модель выдумывает факты?	<2%
Агент	Точность выбора инструмента	Выбрал ли агент правильный инструмент?	>0.92
Агент	Успешное выполнение инструмента	Удалось ли осуществить вызов инструментов?	>0.98
Агент	Многоступенчатая когерентность	Сохранял ли агент логическую последовательность событий?	>0.85
Производство	Стоимость за запрос	Стоимость токена + инфраструктурные затраты за запрос	<$0,05 типичный
Производство	Задержка P99	Время отклика от начала до конца	<3s

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

Почему большинство команд пропускают оценку (и потом за это расплачиваются)

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

Шаблон 1: «Оценку добавим после создания минимально жизнеспособного продукта (MVP)».

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

Шаблон 2: «Точности достаточно».

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

Вариант 3: «Ручные выборочные проверки вполне допустимы».

Ручная проверка работает при 100 запросах в день. Она выходит из строя при 10 000. Команды, пытающиеся масштабировать ручную проверку, либо выжигают своих инженеров, либо смиряются с тем, что на самом деле они проверяют не тот объем, который заявляют. Автоматизированная оценка становится обязательной, как только количество запросов в день превышает несколько тысяч.

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

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

Структура из 12 показателей

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

Категория 1: Метрики поиска (4)

Если ваш агент использует поиск информации (RAG, поиск в базе знаний, поиск по документам), качество поиска является основой. Плохой поиск на начальном этапе означает, что никакие хитрые подсказки на последующих этапах не смогут спасти ответ.

1. Контекстная релевантность

Что измеряет: Какая доля полученных фрагментов действительно имеет отношение к запросу пользователя?

Почему это важно: Большинство сбоев RAG, которые мы наблюдаем в производстве, связаны с процессом извлечения данных, а не с их генерацией. Модель может работать только с тем, что вы ей предоставляете. Если вы извлекаете 10 фрагментов, и только 3 из них релевантны, вы загрязняете контекст и заставляете модель фильтровать сигнал от шума.

Как мы это измеряем: Для каждого запроса эксперт, выступающий в роли судьи, оценивает каждый полученный фрагмент по шкале релевантности от 0 до 1 относительно запроса. Мы усредняем результаты по k наиболее релевантным полученным фрагментам.

Целевой порог: средний уровень релевантности >0,85 по 10 лучшим фрагментам. Значение ниже 0,7 указывает на проблему с поиском, которую следует исследовать, прежде чем стремиться к улучшению модели.

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

2. Воспроизведение контекста

Что измеряется: Удалось ли нам получить ВСЮ необходимую информацию для ответа на запрос, или же мы упустили важные фрагменты?

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

Как мы это измеряем: Для этого требуется размеченный набор данных для оценки, в котором эксперты-оценщики определили все фрагменты, содержащие информацию, относящуюся к эталонному запросу. Затем мы вычисляем долю этих «релевантных эталонным данным» фрагментов, которые фактически были возвращены в результате поиска.

Целевой порог: показатель полноты >0,90 для эталонных запросов. Показатель ниже 0,80 означает систематическое отсутствие информации, что приводит к уверенным, но неверным ответам.

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

3. Точность контекста

Что измеряется: Из полученных фрагментов, находятся ли наиболее релевантные из них в верхней части списка?

Почему это важно: В большинстве производственных RAG-систем из-за ограничений по количеству токенов в контекстное окно LLM передаются только 3-5 верхних фрагментов. Если ваш верхний фрагмент нерелевантен, а релевантный находится на 7-й позиции, вы фактически ничего полезного не получили.

Как мы это измеряем: Мы вычисляем средний обратный ранг (MRR) — среднюю позицию первого релевантного фрагмента в результатах ранжированного поиска.

Целевой порог: MRR >0,80 — ваш первый релевантный фрагмент должен в большинстве случаев находиться на позиции 1 или 2.

Примечание для производственных целей: Точность значительно повышается при добавлении алгоритма переранжирования после первоначального поиска вектора. Мы наблюдали увеличение MRR с 0,55 до 0,92 при добавлении алгоритма переранжирования BGE поверх поиска вектора pg. Задержка составляет около 50 мс; прирост точности того стоит.

4. Задержка извлечения информации

Что измеряется: время от получения запроса до момента готовности извлеченных фрагментов, измеряемое на уровне p95.

Почему это важно: время отклика агента от начала до конца определяется масштабом обработки запросов. Если обработка запроса занимает 800 мс, пользователь ждет 800 мс, прежде чем LLM начнет обрабатывать информацию.

Как мы это измеряем: Стандартный мониторинг производительности приложения в службе получения данных. Мы регистрируем время получения данных для каждого запроса и сообщаем значения p50, p95 и p99.

Целевой порог: задержка извлечения p95 <200 мс. p99 <500 мс.

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

Категория 2: Показатели поколений (3)

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

5. Ответьте верно.

Что измеряет: Точно ли полученный ответ отражает контекст, или же он противоречит или искажает информацию?

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

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

Целевой порог: достоверность >0,95 в регулируемых отраслях. >0,90 в общих сценариях использования. Любое значение ниже 0,85 требует немедленного расследования.

Примечание для производственной среды: Снижение точности обычно указывает на одну из трех причин: слишком высокие значения параметров температуры (для производственной среды уменьшите их до 0,0-0,3), переполнение контекстного окна (полученные фрагменты текста плюс подсказка превышают пределы контекста, и модель выдает ошибку на основе обучающих данных) или шаблон подсказки, поощряющий экстраполяцию («Исходя из контекста, что вы думаете о…»).

6. Релевантность ответа

Что измеряет: Действительно ли сгенерированный ответ отвечает на вопрос пользователя или отклоняется от темы?

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

Как мы это измеряем: эксперт, выступающий в роли судьи, генерирует 3-5 вопросов, на которые был бы уместен ответ, а затем вычисляет семантическое сходство между этими сгенерированными вопросами и исходным запросом пользователя.

Целевой порог: релевантность >0,90. При показателе ниже 0,80 агент отвечает на смежные вопросы, а не на вопрос пользователя.

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

7. Частота галлюцинаций

Что измеряет модель: Как часто модель генерирует факты, имена, числа или утверждения, не имеющие под собой оснований в полученном контексте или в проверяемой реальности?

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

Как мы это измеряем: Ежедневно мы отбираем 5% производственных запросов и пропускаем их через специальный конвейер обнаружения галлюцинаций, который помечает утверждения, требующие проверки фактов, а затем проводит проверку отмеченной части вручную.

Целевой порог: <2% случаев галлюцинаций у агентов, используемых в производстве. <0,5% случаев при использовании в регулируемых отраслях промышленности.

Примечание для производственных целей: Галлюцинации усиливаются в зависимости от типа запроса. Открытые вопросы вызывают галлюцинации чаще, чем вопросы типа «да/нет». Числовые вопросы вызывают галлюцинации чаще, чем категориальные. Включите классификацию по типу запроса в свой конвейер оценки, чтобы целенаправленно проводить расследование.

Категория 3: Показатели, специфичные для конкретного агента (3)

Если ваша система ИИ представляет собой агента (многоэтапный, использующий инструменты, ориентированный на достижение цели), а не простой конвейер RAG, то важны три дополнительных показателя.

8. Точность выбора инструмента

Что измеряется: Когда у агента есть выбор инструментов, выбирает ли он тот, который соответствует намерениям пользователя?

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

Как мы это измеряем: Создаем размеченный набор пар (запрос, правильный инструмент) для оценки. Запускаем агента на основе этих запросов и вычисляем точность выбора инструмента в первой точке принятия решения.

Целевой порог: >0,92 для бинарного выбора инструмента. >0,85 для выбора из 5 и более инструментов.

Примечание для производственной среды: точность выбора инструментов снижается по мере увеличения их количества. Мы наблюдали, как точность в 95% при использовании 3 инструментов падала до 70% при использовании 12 инструментов. Решением обычно является более четкое описание инструментов, уменьшение количества инструментов на одного агента (разбивка на специализированные под-агенты) или тонкая настройка трассировки использования инструментов из производственной среды.

9. Успешное выполнение инструмента

Что измеряется: Какая доля вызовов инструментов, совершаемых агентом, выполняется успешно (правильные аргументы, корректные ответы, отсутствие ошибок)?

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

Как мы это измеряем: отслеживаем каждый вызов инструмента в рабочей среде со статусом успеха/неудачи, категоризацией ошибок и количеством попыток повтора. Вычисляем процент успешных вызовов для каждого инструмента, для каждого типа запроса и для каждого временного окна.

Целевой порог: показатель успешности выполнения инструмента >0,98. Показатель ниже 0,95 указывает на систематические проблемы с построением аргументов.

Примечание для производственной среды: наиболее распространенная ошибка заключается в том, что агент уверенно формирует аргументы в формате, не соответствующем фактической схеме инструмента (например, передает строку даты, когда API ожидает формат ISO 8601). Решение заключается в обеспечении структурированного вывода (вызов функций, проверка JSON Schema) на уровне инструмента.

10. Многоступенчатая когерентность

Что измеряется: Сохраняется ли логическая последовательность выполнения многоэтапного плана агентом на всех этапах?

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

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

Целевой порог: согласованность >0,85 на трассах, состоящих из 4 и более шагов. При согласованности ниже 0,75 ваш агент, по сути, выполняет несколько несвязанных одношаговых запросов.

Примечание для производственной среды: согласованность снижается с увеличением длины трассировки. Мы наблюдаем, как согласованность более 95% на двухэтапных трассировках падает до 60% на шестиэтапных. Решение заключается либо в декомпозиции (разделение шестиэтапной задачи на две отдельные трехэтапные задачи с явной передачей данных), либо в архитектуре памяти (сохранение состояния между шагами вместо повторного запроса полной истории каждый раз).

Категория 4: Показатели производства (2)

Первые десять показателей измеряют действия агента. Эти два показателя измеряют то, что важно для производства.

11. Стоимость одного запроса

Что измеряется: Общая стоимость (стоимость токенов + стоимость инфраструктуры + стоимость вызовов инструментов) на один пользовательский запрос, усредненная по всему производственному трафику.

Почему это важно: у агентов ИИ уникальный профиль затрат — один пользовательский запрос может инициировать от 5 до 15 вызовов LLM (переписывание, оценка качества поиска, выбор инструмента, генерация, проверка). Распределение токенов превращает запрос стоимостью 0,02 доллара в запрос стоимостью 0,30 доллара, и никто этого не замечает до тех пор, пока не придет ежемесячный счет.

Как мы это измеряем: регистрируем использование токенов для каждого вызова LLM, учитываем затраты на API для каждого вызова инструмента и рассчитываем пропорциональную стоимость для каждой зависимости инфраструктуры. Затем проводим агрегирование по каждому запросу, затем по типу запроса, а затем по временному интервалу.

Целевой порог: варьируется в зависимости от сценария использования. Внутренние инструменты для сотрудников: приемлемая стоимость <0,10 долл. США/запрос. Продукты для клиентов: стоимость <0,05 долл. США/запрос для обеспечения устойчивой экономики. В регулируемых отраслях стоимость имеет меньшее значение, чем другие показатели.

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

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

12. Задержка P99

Что измеряется: общее время от запроса пользователя до получения окончательного ответа, измеренное на 99-м процентиле.

Почему это важно: Средняя задержка скрывает сбои, которые раздражают пользователей. Система со средней задержкой в 1 секунду, но показателем p99 в 15 секунд приводит к тому, что пользователи прерывают сеансы после 4-5 медленных ответов. Именно показатель p99 запоминается пользователям.

Как мы это измеряем: Стандартный мониторинг производительности приложений. Мы регистрируем сквозную задержку для каждого запроса и сообщаем значения p50, p95, p99 и максимальное значение. Мы отслеживаем эти значения для каждого типа запроса, поскольку диалоговые запросы должны быть намного быстрее аналитических запросов.

Целевой порог: p99 <3 секунд для диалоговых агентов. p99 <10 секунд для аналитических агентов, выполняющих многоэтапное рассуждение. По истечении 10 секунд пользователи теряют интерес.

Примечание для производственной среды: задержка P99 почти всегда определяется одной из трех причин: получение данных (холодный кэш векторной базы данных), вызовы инструментов (тайм-ауты внешнего API) или генерация LLM для длинных выходных данных (столкновение с узкими местами потоковой обработки токенов). Определите основную причину, прежде чем оптимизировать неправильный слой.

Дерево решений: каким показателям отдать приоритет в первую очередь?

Одновременный мониторинг двенадцати показателей — это очень много. Вот как мы выстраиваем последовательность внедрения на разных этапах проекта.

Этап 1 (Подготовительный этап — Недели 0-2): Внедрение метрик поиска (контекстная релевантность, полнота, точность) плюс точность ответов. Эти четыре показателя позволяют выявить наиболее распространенные ошибки на этапе подготовки к запуску.

Этап 2 (мягкий запуск — недели 3-6): Добавить проверку частоты возникновения галлюцинаций, релевантности ответов и точности выбора инструментов. Эти функции позволяют выявлять проблемы, которые возникают только при работе с реальным пользовательским трафиком.

Этап 3 (стабильная работа в производственной среде — 7+ недель): Добавлены стоимость запроса, задержка P99, успешность выполнения инструмента, многошаговая согласованность и задержка получения данных. Эти параметры оптимизируют работающую систему, а не выявляют сбои, блокирующие запуск.

Модификаторы вариантов использования:

• Регулируемые отрасли (здравоохранение, финтех, юриспруденция): Приоритетными должны быть верность и частота галлюцинаций. С первого дня стремитесь к верности >0,97 и частоте галлюцинаций <0,5%.
• Для потребительских товаров с большим объемом продаж приоритет отдается стоимости запроса и задержке P99. Точность важна, но не в ущерб экономике единицы продукции.
• Внутренние инструменты для сотрудников: Приоритет отдается успешному использованию инструментов и согласованности многоэтапных процессов. Сотрудники прощают медленную реакцию, но не сбои в рабочих процессах.

Как эта платформа соотносится с существующими инструментами

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

Ragas хорошо охватывает контекстную релевантность, полноту, точность, достоверность и релевантность ответов. Это самая сильная отправная точка среди открытых источников метрик, специфичных для RAG. Не охватывает метрики, специфичные для агентов, или состояние производственной среды.

TruLens охватывает аналогичные метрики RAG, но обладает более мощными инструментами мониторинга. Лучшая интеграция с LangChain и LlamaIndex. Требует большей настройки, чем Ragas.

DeepEval предлагает более широкую библиотеку метрик с хорошей поддержкой, специфичной для каждого агента (выбор инструмента, точность). Более новая модель, чем Ragas, с меньшим сообществом.

LangSmith обеспечивает мониторинг и оценку производственных процессов для агентов на основе LangChain. Обладает сильными позициями в области трассировки и наблюдаемости, но слабыми — в оценке производительности в автономном режиме.

Почему мы создали собственную структуру: Ни один из существующих инструментов не охватывает все 12 метрик в одном месте, а метрики, специфичные для агентов (точность выбора инструмента, многошаговая согласованность), особенно недостаточно представлены. Мы используем Ragas для метрик RAG, пользовательские оценщики для метрик агентов и стандартные инструменты APM (Datadog, OpenTelemetry) для метрик состояния производственной среды. Представленная выше структура — это единое представление всех трех инструментов.

Реализация на практике: во сколько на самом деле обойдется создание этого продукта?

Настройка всей системы из 12 метрик занимает 2-3 недели целенаправленной работы инженеров, при условии, что у вас уже настроен оценщик LLM-judge.

Временная разбивка:

• Построение оценочного набора данных (помеченные запросы + эталонные данные): 4-6 дней
• Внедрение метрик (Ragas или собственные): 3-5 дней
• Интеграция CI/CD (запуск оценки при каждом запросе на слияние): 2-3 дня
• Оборудование для мониторинга производства: 3-5 дней
• Панели мониторинга и оповещения: 2-3 дня

Инструменты, которые мы используем во всех развертываниях:

• Оркестрация оценочных операций: Ragas + пользовательские оценщики на Python
• LLM в роли судьи: GPT-4 для оценки в сложных ситуациях, Claude Sonnet для оценки с учетом затрат, Llama 3 70B для полностью самодостаточных сред обеспечения соответствия требованиям.
• Хранение данных: PostgreSQL для результатов оценки, S3 для необработанных трассировок.
• Панели мониторинга: Grafana для производственных показателей, Streamlit для отчетов по результатам офлайн-оценки.
• Система оповещения: интеграция с PagerDuty для оповещения о превышении пороговых значений.

Типичные ошибки, которые, как мы наблюдали, допускают команды:

1. Использование одной и той же модели для генерации и оценки приводит к завышенным результатам. Для оценки следует использовать разные семейства моделей, отличные от семейства моделей для генерации.
2. Пропускаем размеченный оценочный набор. Без эталонных меток невозможно вычислить полноту или измерить регрессию. Затраты на разметку реальны, но окупаются в течение первого месяца.
3. Запускайте eval только для успешных случаев. В вашем наборе данных для оценки должны быть случаи сбоев, иначе вы никогда не обнаружите регрессии. Активно тестируйте сбои в производственной среде.
4. Оценочные баллы следует рассматривать как абсолютные значения. Отслеживайте тенденции и изменения, а не абсолютные значения. Показатель 0,85, который за неделю снижается до 0,78, более информативен, чем его абсолютное значение.

Часто задаваемые вопросы

Каковы минимальные требования к оценочному этапу для нового проекта по созданию ИИ-агента?

Для нового проекта внедрите релевантность контекста, достоверность ответов и точность выбора инструментов. Эти три параметра позволяют выявить 70% сбоев на этапе подготовки к запуску с минимальными затратами на настройку. Отложите сбор данных по производственным метрикам до тех пор, пока не получите данные по реальному производственному трафику.

Как часто следует запускать полный набор инструментов для оценки?

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

Следует ли нам использовать магистров права в качестве экспертов или же проводить оценку силами человека?

Оба подхода являются последовательными. Используйте LLM в качестве судьи для масштабирования (оценка 100% производственного трафика с низкими затратами), используйте оценку человека для калибровки (оценка выборки в 1-2% для проверки соответствия оценки LLM консенсусу человека). Когда оценка LLM и оценка человека расходятся, переобучите подсказку судьи.

В чём разница между офлайн- и онлайн-оценкой?

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

Как мы проводим оценку для недетерминированных агентов?

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

Какие показатели наиболее важны для систем RAG по сравнению с агентными системами?

Чистые RAG-системы: приоритет отдается четырем показателям поиска плюс достоверность. Агентные системы: к показателям RAG добавляются точность выбора инструмента, успешность выполнения инструмента и многошаговая согласованность. Показатели производительности (стоимость, задержка) одинаково важны для обеих систем.

Как мы измеряем удовлетворенность пользователей в рамках оценки?

Удовлетворенность пользователей зависит от 12 показателей, перечисленных выше. Если показатели лояльности, релевантности и задержки находятся в целевом диапазоне, удовлетворенность будет расти. Прямые сигналы удовлетворенности (лайки/дизлайки, уточняющие вопросы, отказ от сессии) полезны в качестве индикаторов работоспособности системы, но отстают от показателей, которые их вызывают.

Какова стоимость оценки — стоит ли она того?

Оценка запросов с использованием LLM в качестве эксперта обходится примерно в 30-50% от стоимости вывода результатов (каждый производственный запрос также оценивается LLM). При бюджете на вывод результатов в 4000 долларов в месяц ожидайте затрат на оценку в размере 1200-2000 долларов в месяц. Окупаемость инвестиций заключается в предотвращении единичного производственного инцидента, на устранение которого инженерам потребовались бы недели, а на восстановление доверия — ущерб. После первого предотвращенного инцидента оценка окупается неограниченно долго.

Заключительная мысль

Команды, успешно внедряющие ИИ-агентов в 2026 году, — это не те, у кого лучшие модели. Это те, у кого лучшая инфраструктура для оценки. Модели — это товар. Оценка — это конкурентное преимущество.

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

Ресурсы

• Ragas — открытая платформа для оценки RAG.
• TruLens — оценка и отслеживание заявок на получение степени магистра права.
• DeepEval — платформа для оценки программ магистратуры в области права с открытым исходным кодом.
• LangSmith — платформа для мониторинга и оценки от LangChain.
• OpenTelemetry — стандарт мониторинга в производственной среде
• Результаты тестирования HumanEval — Github
• Статья Ragas — автоматическая оценка RAG

Пратик К. Рупарелия — соучредитель и руководитель отдела стратегии компании Intuz, где он возглавляет стратегию внедрения ИИ в более чем 100 проектах в таких отраслях, как здравоохранение, финтех, производство и розничная торговля. Свяжитесь с ним в LinkedIn.

Пратик Р. Все материалы от Пратика Р.

Источник: towardsdatascience.com