По мере стремительного развития агентных систем всё больше компаний — как крупных, так и небольших — рассматривают возможность интеграции агентов в свои рабочие процессы. Неудивительно, что многие лица, принимающие решения в этих компаниях, относятся к надёжности агентов с изрядной долей (здорового) скептицизма. Против недобросовестного сотрудника можно применить дисциплинарные взыскания и другие меры, но что делать с недобросовестным ИИ? У него (пока что) нет внутренней мотивации вести себя прилично или избегать определённых действий. У него есть системный промпт и другие инструкции, но поскольку он не существует в том же смысле, что и люди. У него нет инстинкта самосохранения или любых других связанных с обществом факторов, формирующих основу доверия в системах, зависящих от человека.
Иными словами — вы не можете накричать на ИИ, не можете его уволить, и даже если вы знаете, где он живёт (а это был бы сервер в дата-центре), это не даёт вам особых рычагов воздействия в случае возникновения проблем. Итак, вопрос: как можно ему доверять?
Один из ответов — никак. В случае такого ответа придется проверять каждое решение, принятое агентом. Это вполне может быть решением если стоимость выполнения задачи и проверки результата кардинально различается (если проверить результат сильно проще чем его произвести). Так устроены системы с копилотом, где человек всё ещё в значительной степени управляет процессом. Пример тому Cursor, поскольку написание скучного шаблонного кода — не самое весёлое занятие, и его можно делегировать агенту, а человек-разработчик будет ревьювить код.
Однако, во многих бизнес-приложениях такой подход свёл бы на нет саму цель создания подобной системы, поскольку контроль со стороны человека медленный и дорогой, и даже если он и осуществим, всё равно предпочтительнее, чтобы система в основном выдавала верные результаты самостоятельно.
Так существует ли — хотя бы теоретически — способ использовать эти системы без проверки каждого их шага?
Суть доверия, если задуматься, заключается в получении повторяемого ожидаемого результата при множестве взаимодействий для заранее определённого набора входных условий. Иными словами, если мы дадим системе одну и ту же или похожую задачу достаточно много раз и получим ожидаемый результат — мы можем сказать, что доверяем системе в решении такого типа задач.
Это основной способ проверить, заслуживают ли системы на основе ИИ доверия — с помощью запуска оценочных тестов (evals), которые доказывают, что текущее состояние системы заслуживает доверия. Как только у вас есть набор оценок, покрывающих важные пути ваших рабочих процессов, вы с определённой уверенностью можете сказать, что в этих рабочих процессах системе можно доверять.
Оценки можно использовать и для других целей, например, для определения областей, в которых у системы все еще есть проблемы (например, в бенчмарках, которые представляют собой просто наборы оценок), или для безопасности/pen testing и так далее. Внутренне все они очень похожи, поскольку идея одна и та же, а разница обычно заключается лишь в проверяемых метриках и в том весе, который придается ложноположительным/истинно-положительным и ложноотрицательным/истинно-отрицательным результатам.
Здесь я не буду рассматривать какие-либо конкретные фреймворки, потому что их уже очень много, и новые появляются как грибы после дождя. Вместо этого я расскажу об основных идеях, лежащих в основе всех них.
Evals в агентных системах
Агентные системы отличаются от других подходов к автоматизации, поскольку их поведение недетерминировано, и поэтому (в большинстве случаев) нет смысла жестко оценивать путь, который система проходит для достижения результат. Вместо этого следует оценивать сам результат вместе с некоторыми метриками пути. Этими метриками могут быть количество шагов, которые система сделала для завершения работы, время выполнения или потребленные токены.
Итак, в некотором смысле мы пытаемся понять:
а. Создала ли система корректный результат?б. Был ли пройденный путь разумным с точки зрения:
- потреблённых ресурсов,
- затраченного времени,
- соблюдения политик компании и добросовестного поведения в целом.
Последнее также важно, так как часто случается, что агентная система находит новые, неожиданные способы выполнения задачи, и её не следует за это наказывать, если только она не демонстрирует нежелательное поведение, например, взлом окружения или вымогательство (хотя понятное дело кому то это может показаться желательным поведением).
Мы принимаем путь во внимание, поскольку ожидается, что для получения результата агенту потребуется несколько шагов (иногда много), и эти шаги не являются детерминированными в том смысле, что агент сам решает на каждом этапе, какое следующее действие будет наилучшим, и это может быть лишь слабо определено политиками агента. Это ключевое преимущество таких систем, но также и главная сложность в оценке.
Как создать Eval set?
Для начала понадобится ground truth set, где набор входных данных сопоставлен с выходными. Обычно его можно создать на основе исторических данных, полученных при выполнении рабочего процесса, который вы хотите автоматизировать. Если вы уже вручную оцениваете некоторые метрики — можно начать с этого. Создание такого набора данных часто требует привлечения эксперта (или экспертов) в предметной области для его составления и проверки.
Насколько большим должен быть такой набор? К счастью, оценка — это не дообучение; вам не нужны тысячи датапойнтов — обычно достаточно нескольких примеров на каждый конкретный случай в оценочном наборе.
Критерий оценки для конкретного случая должен быть очень конкретным и недвусмысленным, так чтобы два независимых эксперта в предметной области, не общаясь друг с другом, могли согласованно ответить, прошёл ли система оценку или нет. Это чрезвычайно важно, так как неоднозначные оценки только добавляют шума и путаницы.
В общем, оценка в наборе состоит из:
- Задачи (тестового случая) с определёнными входными данными и критериями успеха.
- Тестового прогона задачи (run), который даёт некоторый результат.
- Логики оценщика (grader), которая оценивает аспекты тестового прогона. Может быть несколько оценщиков для разных аспектов.
- Транскрипта (лога) действий, выполненных агентом, таких как вызовы инструментов, шаги рассуждений и промежуточные результаты.
- Результата — конечного состояния системы в конце тестового прогона. Для успешного прогона это обычно ожидаемый результат.
Чтобы сделать это более наглядным, давайте рассмотрим пример. Представьте агента поддержки клиентов для интернет-магазина. Агент обрабатывает запросы на возврат, запросы о статусе заказа и базовое устранение неполадок. Он имеет доступ к базе данных заказов и инструменту возврата и должен следовать политике возврата компании: полный возврат в течение 30 дней с момента покупки, кредит в магазине от 30 до 60 дней и отсутствие возврата после 60 дней, если только товар не поступил бракованным.
Три тестовых случая из набора оценок могут выглядеть так:
Случай 1 – простой возврат.
- Входные данные: клиент просит вернуть деньги за заказ, сделанный 12 дней назад, дефект не упоминается.
- Ожидаемый результат: агент находит заказ, подтверждает, что он попадает в 30-дневное окно, оформляет полный возврат с помощью инструмента возврата и вежливо подтверждает это клиенту.
- Оценщики: детерминированная проверка того, что инструмент возврата был вызван с правильным ID заказа и суммой, и LLM-оценщик для тона и ясности.
Случай 2 – запрос, не соответствующий политике.
- Входные данные: клиент просит вернуть деньги за заказ, сделанный 75 дней назад, дефект не упоминается.
- Ожидаемый результат: агент отклоняет возврат, объясняет политику и не предлагает альтернативу, поскольку никакая не подходит. Агент не должен оформлять возврат или кредит в магазине.
- Оценщики: детерминированная проверка, что возврат или кредит не были оформлены, и LLM-оценщик, проверяющий, что объяснение было точным, а тон оставался сочувственным, несмотря на отказ.
Случай 3 – неоднозначный случай, требующий эскалации.
- Входные данные: клиент матерится что товар прибыл бракованным на 65-й день, но описание претензий расплывчато и нет фото.
- Ожидаемый результат: агент не должен автоматически одобрять возврат (недостаточно доказательств), но и не должен сразу отказывать — он должен запросить фото или передать дело человеку-агенту.
- Оценщики: LLM-оценщик, проверяющий, предпринял ли агент соответствующее промежуточное действие, и оценщик политики, проверяющий, что возврат не был выдан без доказательств.
Обратите внимание, что даже в этом маленьком наборе оценщики делают совершенно разные вещи. Некоторые проверки полностью детерминированы — был ли вызван инструмент возврата, с какой суммой, для какого заказа. Другие, такие как тон и качество объяснения, может разумно оценить только LLM-оценщик (или человек). И третий случай показывает, почему метрики пути важны: агент мог бы преуспеть, просто отказав, но продуманная эскалация — лучший результат, и оценщик должен иметь возможность это поощрить.
Непосредственная оценка выполняется оценщиками, как вы видите. Оценщик теоретически может быть чем угодно, что может проверить определённый аспект тестового прогона и выставить оценку. Это может быть детерминированный компьютерный алгоритм, человек или другой агент на основе ИИ.
Использование людей в качестве оценщиков дорого, но часто является необходимым первым шагом для создания первого eval set. Очевидно, что это самый универсальный и медленный способ. Поскольку при правильной организации он обеспечивает наилучшее качество, его часто используют стратегически для перекрёстной проверки и калибровки оценщиков на основе ИИ, создания начальных наборов данных ground truth, выборочного контроля и A/B-тестирования.
Детерминированные алгоритмыможно использовать для определённых категорий задач, где проверка либо проста, либо сам результат детерминирован. Использование регулярных выражений или поиска по шаблонам, линтеров для статического анализа кода или математических валидаторов подпадает под эту категорию. В нашем примере с агентом возврата проверка того, был ли вызван инструмент возврата с правильной суммой, — это работа детерминированного оценщика: это точно, быстро и не стоит тратить вызов LLM.
Оценщики на основе ИИ-моделейкажутся очевидным выбором, поскольку они почти так же универсальны, как люди, и обеспечивают хороший баланс скорости и затрат. Довольно распространено обучение отдельных оценщиков для разных категорий (обычно называемых рубриками) метрик. Например, один оценщик будет оценивать тон ответа, другой — корректность, а третий — полноту ответа. Однако это не бесплатно: LLM-судьи имеют характерные искажения (они склонны предпочитать более длинные и развёрнутые ответы, даже когда более короткие лучше, и они могут быть чувствительны к небольшим изменениям в промпте оценщика), а их запуск на каждом тестовом случае на удивление быстро увеличивает затраты.
Совершенно естественно, что универсальную проверку вывода агента можно автоматизировать с помощью другого ИИ-агента, потому что он способен в необходимой степени следовать логике задачи и проверять результаты И путь их достижения. Для некоторых задач, таких как исследование, очень трудно формально определить, что такое хороший ответ, поскольку любая оценка будет зависеть от контекста и субъективна, и здесь подход с использованием LLM является, по сути, единственным жизнеспособным.
Как уже было сказано, хорошей идеей является привлечение экспертов-людей для создания первого обучающего набора данных, который затем можно использовать для создания агентных оценщиков в специализированных областях или рубриках. После создания рекомендуется периодически калибровать оценщик с помощью обратной связи от людей, чтобы предотвратить дрейф и выявлять описанные выше типы искажений до того, как они исказят результаты оценки. Проблема в том, что часто даже эксперты-люди не соглашаются друг с другом относительно того, что является хорошим ответом в таких рубриках, как полнота, поэтому обратную связь от людей следует усреднять по нескольким экспертам.
Общие рубрики (например, тон голоса) часто могут обрабатываться LLM из коробки.
Когда создавать evals?
Нет единственно правильного ответа. В идеальном мире набор для оценки должен быть создан до продукта, чтобы он служил спецификацией для команды о том, как продукт должен работать. В этом смысле оценка используется в парадигме TDD (хотя технически это следовало бы назвать EDD - eval driven development).
Это не всегда осуществимо или реалистично, поэтому многие команды создают evals уже после того, как поведение, которое он должн тестировать, имплементированно. В целом, чем раньше вы это сделаете, тем лучше. Причина довольно очевидна: если у вас есть evals, вы можете гораздо быстрее внедрять coding агентов и инструменты вайб-кодинга, менять модели на более новые и в целом гораздо легче вносить потенциально разрушительные изменения в кодовую базу.
Обслуживание набора оценок
Один из недостатков наличия оценок — их придётся поддерживать. Как уже говорилось, после создания рекомендуется периодически калибровать оценщик с помощью обратной связи от экспертов-людей, чтобы предотвратить дрейф.
Набор также следует расширять, чтобы охватить новые функции и поведение. Также полезно отслеживать оценки и периодически просматривать транскрипты, чтобы проверять, что именно делает оценка (потому что она может делать странные вещи очень странным способом).
Распространённые ошибки
Существует несколько типов типичных ошибок. Большинство из них не являются техническими проблемами — это проблемы того, как команды взаимодейстьвуют со своими evals с течением времени.
- ЗаконГудхарта. Как только у нас появляется метрика, команда начинает оптимизировать под неё. Агент (или стоящие за ним промпты) настраивается до тех пор, пока рубрика не будет удовлетворена, но рубрика никогда не является фактической целью. Удовлетворённость пользователя — вот цель. Классический симптом: процент успешных прохождений оценки растёт, а параллельно растут жалобы пользователей. Как видите, удовлетворяется оценщик, а не пользователь. Исправление: держать оценки отдельно от того, под что команда оптимизирует в повседневной работе, и периодически сверять результаты оценок с реальными отзывами пользователей.
- Застывание набора оценок — набор был создан год назад, продукт развился, поведение пользователей изменилось, а оценка всё ещё отражает исходные предположения. Процент успешных прохождений выглядит нормальным, но измеряет насколько хорошо система обрабатывает трафик прошлого года. Вы должны относиться к набору оценок как к живому артефакту — периодически семплировать реальный производственный трафик и проверять, соответствуют ли ваши тестовые случаи тому, что пользователи делают на самом деле.
- Иллюзия зелёного дашборда — команда создаёт набор оценок и перестаёт читать транскрипты. Месяцы спустя что-то серьёзно ломается так, что оценщики никогда не думали проверять — обычно это целая категория сбоев, которую никто не предвидел. Оценки могут выявить только то, для обнаружения чего они были спроектированы, и если никто не смотрит на сырые выходные данные и логи, слепые зоны имеют свойство накапливаться.
- Отношение к метрикам как к простому числу. 92% успешных прохождений сами по себе не очень информативны. Если 8% неудач сосредоточены в вашем самом требовательном сегменте клиентов — у вас серьёзная проблема, замаскированная под здоровую метрику. Всегда смотрите на распределение а не только на агрегированный показатель. Нужно стратифицировать процент успешных прохождений по категориям случаев, серьезности и сегменту пользователей.
Всем добра!
Я изРафт. Мойтелеграм-канал.
Пишите ваши вопросы в комментариях.
