Перейти к содержанию
Публикация AiManual

Как оценивать AI-агентов со скиллами: Strands Evals и Amazon Bedrock AgentCore

Strands Evals и Amazon Bedrock AgentCore Evaluations добавляют три проверки для агентов со скиллами: Skill Selection Accuracy, Skill Instruction Following и Ski

Коротко

Что будет в материале

  1. 01

    Почему качественный ответ агента ещё не значит, что скилл выбран и выполнен правильно

  2. 02

    Как работают оценщики Skill Selection Accuracy, Skill Instruction Following и Skill Invoked

  3. 03

    Откуда берутся данные: записанные траектории и OpenTelemetry-трейсы

  4. 04

    Как встроить оценку скиллов в CI/CD как deployment gate

Почему качественный ответ агента ещё не значит, что скилл выбран и выполнен правильно

Для агентов со скиллами Strands Evals SDK и Amazon Bedrock AgentCore Evaluations дают три отдельных проверки. Skill Selection Accuracy отвечает на вопрос, подошёл ли каждый вызванный скилл задаче, и возвращает бинарный результат по каждому вызову. Skill Instruction Following показывает, насколько полно агент выполнил инструкции вызванного скилла, и выдаёт пятиуровневую оценку с обоснованием по каждому предписанному шагу. Skill Invoked доступна только в Strands Evals и детерминированно проверяет, загрузился ли именованный скилл. Все три работают по записанным траекториям и OpenTelemetry-трейсам и дают то, чего не даёт оценка финального текста: понимание, сломался ли выбор скилла или его выполнение.

Что такое скиллы и почему они ломают привычную оценку

Скилл - это переиспользуемый набор инструкций, который обычно лежит в файле SKILL.md и учит агента одной доменной задаче: отредактировать договор, сверить счёт или соблюсти конвенции команды по pull request. Внутри скилл упаковывает один или несколько инструментов вместе с контекстом, нужным для их правильного применения: инструкции, привязки инструментов, знания, рабочий процесс и ограничения (guardrails). Скиллы следуют открытому стандарту Agent Skills, поэтому переносимы между совместимыми средами, а во время выполнения агент подгружает только нужный скилл вместо того, чтобы держать все процедуры в собственном ядре (Evaluate skill-equipped agents with Strands Evals and Amazon Bedrock AgentCore).

Модульность даёт измеримую выгоду: команда быстрее специализирует агентов, переиспользует уже проверенные процедуры, держит поведение согласованным и обновляет доменные инструкции без дообучения модели и переписывания ядра агента. Формат SKILL.md и механизм подгрузки контекста подробно разобраны в материале об открытых Agent Skills для healthcare и life sciences.

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

Два режима отказа: неверный скилл и неполное выполнение

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

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

Как работают оценщики Skill Selection Accuracy, Skill Instruction Following и Skill Invoked

Три проверки измеряют разные аспекты поведения и не заменяют друг друга. Первые две строятся на модели-судье, третья работает детерминированно (первоисточник Amazon).

Skill Selection Accuracy: бинарная проверка уместности скилла

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

Skill Instruction Following: пятиуровневая оценка полноты выполнения

Оценщик показывает, насколько полно агент следовал инструкциям вызванного скилла, и возвращает пятиуровневую оценку с обоснованием по каждому предписанному шагу. Шкала различает «шаг пропущен» и «шаг выполнен наполовину», а разбор по шагам указывает, какая именно инструкция выпала и на каком основании сделан такой вывод. Конкретные названия уровней шкалы Amazon в опубликованном описании не приводит, поэтому ориентируйтесь на фактические значения, которые вернёт SDK или сервис.

Skill Invoked: детерминированная проверка загрузки скилла

Skill Invoked проверяет, был ли успешно загружен именованный скилл, и доступна только в Strands Evals. Модель-судья здесь не участвует, поэтому результат стабилен от прогона к прогону и дешевле по токенам. Проверка не отвечает на вопрос об уместности скилла и не измеряет полноту выполнения шагов, зато надёжно ловит случай, когда нужный скилл вообще не загрузился. Это делает её удобным быстрым сигналом в тестовом наборе и в CI/CD.

ОценщикЧто проверяетТип результатаГде доступен
Skill Selection Accuracyуместность каждого вызванного скилла для задачибинарный результат по каждому вызванному скиллуStrands Evals, AgentCore Evaluations
Skill Instruction Followingполноту следования инструкциям скиллапятиуровневая оценка с обоснованием по каждому шагуStrands Evals, AgentCore Evaluations
Skill Invokedфакт успешной загрузки именованного скилладетерминированный результаттолько Strands Evals

Откуда берутся данные: записанные траектории и OpenTelemetry-трейсы

Оценка по записанной траектории в Strands Evals

Записанная траектория - это сохранённый прогон агента. По ней прогоняются Skill Selection Accuracy и Skill Instruction Following без повторного вызова агента, что для локальной разработки даёт прямую выгоду: проблемный прогон фиксируется один раз, а дальше видно, как правки в описаниях скиллов или в логике маршрутизации меняют результат. Тот же приём превращает баг в регрессионный тест: траектория с ошибкой остаётся в наборе и защищает от повторения.

Детерминированные проверки маршрутизации через Skill Invoked добавляются в тестовый набор рядом с остальными тестами и не требуют ни модели-судьи, ни сети.

Оценка по OpenTelemetry-трейсам в AgentCore Evaluations

Amazon Bedrock AgentCore Evaluations оценивает поведение скиллов по трейсам OpenTelemetry. Если агент уже отправляет телеметрию, отдельный сбор данных не нужен: те же трейсы дают материал для оценки выбора скилла и следования инструкциям (описание подхода в блоге AWS). Здесь есть жёсткая зависимость: качество оценки ограничено полнотой трейса. Если в спане нет информации о вызове скилла и о пройденных шагах, оценщику не из чего сделать содержательный вывод, и он выдаст либо отказ, либо формальный результат.

Обе части запускаются через AgentCore CLI. Конкретный синтаксис команд в источнике не раскрывается, поэтому интеграцию планируйте от возможностей CLI вашей версии, а не по угаданным флагам.

AgentCore Evaluations стоит рассматривать как слой поверх существующей наблюдаемости, а не как отдельную систему. Как этот слой сочетается с расследованием инфраструктурных сбоев, разобрано в материале о двухуровневом мониторинге продакшн-агентов.

Как встроить оценку скиллов в CI/CD как deployment gate

Детерминированные проверки маршрутизации в тестовом наборе

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

Пороговые значения и блокировка деплоя

Схема получается двухступенчатой: сначала дешёвые детерминированные проверки, потом более дорогие оценщики на основе модели по записанным траекториям или трейсам. Если значения Skill Selection Accuracy и Skill Instruction Following падают ниже порога, деплой блокируется.

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

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

Как интерпретировать результаты: ошибка маршрутизации или неполное выполнение

Смотреть нужно на результаты по каждому скиллу, а не на агрегат. Агрегат скажет, что прогон стал хуже, но не подскажет, что чинить. Ниже два сценария и типичные причины.

Когда чинить маршрутизацию

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

Когда чинить инструкции скилла

Признак: Skill Selection Accuracy в порядке, а Skill Instruction Following показывает неполное выполнение по конкретным шагам. Тут смотрят обоснование по каждому шагу, находят пропущенную или частично выполненную инструкцию и правят текст в SKILL.md. Частые причины: формулировка шага допускает двойное чтение, шаг спрятан в середине длинного списка, либо сам скилл перегружен и шагов больше, чем агент удерживает в рабочем контексте.

СимптомДиагнозКуда смотреть
Skill Selection Accuracy отрицательна по вызванному скиллуошибка маршрутизацииописания и условия выбора скиллов, пересечение их областей
Skill Selection Accuracy положительна, Skill Instruction Following неполнапроблема внутри скиллаобоснование по шагам, формулировки инструкций в SKILL.md
Skill Invoked отрицательнаскилл не загрузилсяпривязка скилла к агенту, доступность файла, конфигурация окружения

Ограничения и подводные камни оценки агентов со скиллами

  • Skill Selection Accuracy и Skill Instruction Following строятся на модели-судье. Результат зависит от качества этой модели и от того, насколько однозначно сформулированы задачи и инструкции.
  • Skill Invoked проверяет только факт успешной загрузки скилла. Уместность выбора и полнота выполнения остаются вне её зоны ответственности, подменять ею остальные метрики нельзя.
  • Оценка по OpenTelemetry-трейсам требует, чтобы трейсы содержали вызовы скиллов и пройденные шаги. Разреженная трассировка обнуляет практическую пользу оценки.
  • Нечёткие описания скиллов дают противоречивые вердикты: один и тот же прогон может оцениваться по-разному при повторной проверке.
  • Агрегированной цифры «качество агента» здесь нет. Результаты приходят per-skill, и для сводной картины их придётся собирать самостоятельно.
  • Метрики не заменяют ручной разбор сложных кейсов, особенно когда сбой вызван не скиллом, а внешним инструментом или качеством данных.

Кому и когда стоит внедрять оценку скиллов

Подход окупается, если вы строите агента на Strands или Amazon Bedrock AgentCore, у вас несколько скиллов и уже были случаи, когда агент выбирал не тот скилл или выполнял инструкции частично. Порядок внедрения логично выстроить от дешёвого к дорогому.

  1. Добавить Skill Invoked в тестовый набор: это даёт стабильный сигнал о загрузке скиллов почти без затрат.
  2. Записать несколько реальных прогонов и прогнать по ним Skill Selection Accuracy и Skill Instruction Following в Strands Evals, чтобы получить базовые значения метрик.
  3. Настроить пороги и подключить прогон в CI/CD как deployment gate, чтобы регрессии не доезжали до прода.
  4. Подключить оценку по OpenTelemetry-трейсам в AgentCore Evaluations, если трейсы уже собираются и содержат достаточно деталей о вызовах скиллов.

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

Подписаться на канал