На данный момент я прохожу 5-дневный интенсив по AI-агентам от Google и параллельно веду собственный конспект. Эта статья представляет собой перевод оригинального материала, выполненный с помощью Gemini и мной. В некоторых местах я немного упростила формулировки или обобщила идеи. В этом материале рассматривают то, что традиционные методы тестирования неприменимы к непредсказуемым AI-агентам, поэтому для обеспечения их качества и надёжности необходимо сместить фокус с оценки конечного результата на анализ всего процесса.

Оригинал статьи тут Agent Quality

Другие статьи:

Интенсивный курс «AI-агенты» от Google День 1

Интенсивный курс «AI-агенты» от Google День 2

Интенсивный курс «AI-агенты» от Google День 3

---

Введение

Мы стоим на заре эры агентов. Переход от предсказуемых, основанных на инструкциях инструментов к автономным, целеориентированным AI-агентам представляет собой один из самых глубоких сдвигов в разработке программного обеспечения за последние десятилетия. Хотя эти агенты открывают невероятные возможности, их внутренняя недетерминированность делает их непредсказуемыми и разрушает наши традиционные модели обеспечения качества.Этот документ (whitepaper) служит практическим руководством к этой новой реальности, основанной на простом, но радикальном принципе:Качество агента — это архитектурный столп, а не заключительный этап тестирования.

Это руководство построено на трёх ключевых идеях:

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

• Наблюдаемость (Observability) — это основа: Невозможно оценить процесс, который вы не видите. Мы подробно рассматриваем «три столпа» наблюдаемости — Logging (логирование), Tracing (трассировку) и Metrics (метрики) — как необходимую техническую основу для фиксации «мыслительного процесса» агента.

• Оценка — это непрерывный цикл: Мы объединяем эти концепции в «Agent Quality Flywheel» — операционную модель для превращения данных в практические выводы. Эта система использует гибридный подход, сочетая масштабируемых AI-оценщиков и незаменимую экспертную оценку Human-in-the-Loop (HITL) (человек в цикле) для постоянного совершенствования.

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

Качество агентов в недетерминированном мире

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

Чтобы понять этот сдвиг, сравним традиционное программное обеспечение с грузовиком доставки, а AI-агента — с гоночным болидом Формулы-1. Грузовик требует лишь базовых проверок («Завёлся ли двигатель? Следовал ли он по заданному маршруту?»). Гоночный болид, подобно AI-агенту, — это сложная автономная система, успех которой зависит от динамически принимаемых решений. Его оценка не может быть простым чек-листом; она требует непрерывной телеметрии для анализа качества каждого решения — от расхода топлива до стратегии торможения.

Эта эволюция коренным образом меняет наш подход к качеству программного обеспечения. Традиционные практики обеспечения качества (QA), надёжные для детерминированных систем, оказываются недостаточными для сложного и непредсказуемого поведения современного AI. Агент может пройти 100 юнит-тестов (unit tests) и всё равно катастрофически отказать в рабочей среде (production), потому что его сбой — это не баг в коде, а изъян в его суждениях.

Традиционная верификация ПО задаёт вопрос: «Правильно ли мы создали продукт?». Она сверяет логику с фиксированной спецификацией. Современная оценка AI должна задавать гораздо более сложный вопрос: «Создали ли мы правильный продукт?». Это уже процесс валидации — оценка качества, надёжности и достоверности в динамичном и неопределённом мире.

В этой главе мы рассмотрим эту новую парадигму. Мы разберём, почему качество агентов требует нового подхода, проанализируем технологический сдвиг, который делает наши старые методы устаревшими, и заложим основы стратегического фреймворка «Outside-In» для оценки «мыслящих» систем.

Почему качество агентов требует нового подхода

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

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

Организации, которые не осознают этот сдвиг, сталкиваются с серьёзными отказами, операционной неэффективностью и репутационным ущербом. Хотя такие проблемы, как алгоритмическая предвзятость (algorithmic bias) и дрейф концепций (concept drift), существовали и в пассивных моделях, автономность и сложность агентов усугубляют эти риски, затрудняя их отслеживание и устранение. Рассмотрим реальные примеры таких сбоев, представленные в Таблице 1:

Такие сбои делают традиционные подходы к отладке и тестированию неэффективными. Невозможно отладить галлюцинацию с помощью breakpoint (переломной точки/точки останова ) или написать unit test для предотвращения emergent bias (неожиданной предвзятости). Анализ первопричин (Root cause analysis) требует глубокого анализа данных, переобучения модели и системной оценки — а это уже совершенно новая дисциплина.

Смена парадигмы: от предсказуемого кода к непредсказуемым агентам

Ключевая техническая сложность связана с переходом от AI, сфокусированного на моделях (model-centric AI), к системному подходу (system-centric AI). Оценка AI-агента принципиально отличается от оценки алгоритма, потому что агент — это система. Эта эволюция проходила поэтапно, и каждый этап добавлял новый уровень сложности в процесс оценки.

1. Традиционное Machine Learning (машинное обучение): Оценка моделей regression (регрессии) или classification (классификации), хотя и нетривиальна, является чётко определённой задачей. Мы опираемся на статистические метрики, такие как Precision, Recall, F1-Score и RMSE, на отложенной тестовой выборке. Задача сложна, но определение «правильности» ясно.

2. Пассивные LLM (большие языковые модели): С появлением генеративных моделей мы лишились простых метрик. Как измерить «точность» сгенерированного абзаца? Вывод вероятностен. Даже при одинаковых входных данных результат может варьироваться. Оценка усложнилась, стала опираться на оценщиков-людей и сравнение моделей между собой (model-vs-model benchmarking). Тем не менее, эти системы были в основном пассивными инструментами формата «текст на входе, текст на выходе».

3. LLM+RAG (Retrieval-Augmented Generation): Следующий скачок привёл к появлению многокомпонентных систем (pipelines), впервые предложенных Льюисом и др. (2020) в их работе «Retrieval-Augmented Generation for Knowledge-Intensive NLP Tasks». Теперь сбой мог произойти как в LLM, так и в системе извлечения данных. Агент дал плохой ответ потому, что LLM ошиблась в рассуждениях, или потому, что vector database (векторная база данных) извлекла нерелевантные фрагменты? Область оценки расширилась: теперь она охватывала не только модель, но и производительность chunking strategies (стратегий разбиения), embeddings (эмбеддингов) и retrievers (систем извлечения).

4. Активный AI-агент: Сегодня мы сталкиваемся с глубоким архитектурным сдвигом. LLM — это уже не просто генератор текста; это «мозг», отвечающий за рассуждения в сложной системе, интегрированной в цикл, способный к автономным действиям. Эта агентная система обладает тремя ключевыми техническими возможностями, которые ломают наши модели оценки:

   • Планирование и многошаговые рассуждения: Агенты декомпозируют сложные цели («спланируй мою поездку») на несколько подзадач. Это создаёт траекторию (Thought → Action → Observation → Thought...). Недетерминированность LLM теперь накапливается на каждом шаге. Небольшой, случайный выбор слова на первом шаге может к четвёртому шагу направить агента по совершенно иному и необратимому пути рассуждений.

   • Использование инструментов и вызов функций (Tool Use, Function Calling): Агенты взаимодействуют с реальным миром через APIs и внешние инструменты (интерпретаторы кода, поисковые системы, API для бронирования). Это вносит динамическое взаимодействие с окружением. Следующее действие агента полностью зависит от состояния внешнего, неконтролируемого мира.

   • Память (Memory): Агенты сохраняют состояние. Кратковременная память (scratchpad memory) отслеживает текущую задачу, в то время как долговременная память позволяет агенту учиться на прошлых взаимодействиях. Это означает, что поведение агента эволюционирует, и входные данные, которые работали вчера, сегодня могут дать другой результат из-за того, что агент «узнал».

5. Мультиагентные системы (Multi-Agent Systems): Вершиной архитектурной сложности становится интеграция нескольких активных агентов в общую среду. Здесь оценивается уже не одна траектория, а системное эмерджентное явление, что создаёт новые фундаментальные проблемы:

   • Эмерджентные системные сбои: Успех системы зависит от спонтанных взаимодействий между агентами, таких как конкуренция за ресурсы, узкие места в коммуникации и системные взаимоблокировки (deadlocks), которые нельзя свести к сбою одного агента.

   • Кооперативная и конкурентная оценка: Сама целевая функция может стать неоднозначной. В кооперативных MAS (например, оптимизация цепей поставок) успех — это глобальная метрика, тогда как в конкурентных MAS (например, сценарии теории игр или аукционные системы) оценка часто требует отслеживания производительности отдельных агентов и стабильности всего рынка/окружения.

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

Столпы качества агентов: Фреймворк для оценки

Если мы больше не можем полагаться на простые метрики точности и должны оценивать систему целиком, с чего начать? Ответ кроется в стратегическом сдвиге, известном как подход «Outside-In».

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

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

Результативность (Effectiveness, достижение цели): Это главный вопрос при оценке системы как «чёрного ящика»: успешно и точно ли агент выполнил реальное намерение пользователя? Этот столп напрямую связан с пользовательскими метриками и бизнес-KPI. Для агента в сфере ритейла вопрос не в том, «нашёл ли он товар?», а в том, «привёл ли он к конверсии?». Для агента-аналитика данных — не «написал ли он код?», а «позволил ли этот код получить верные выводы?». Результативность — это итоговая мера успеха задачи.

Эффективность (Efficiency, операционные затраты): Насколько хорошо агент решил проблему? Агент, который для бронирования простого авиабилета совершает 25 шагов, пять неудачных вызовов инструментов и три цикла самокоррекции, считается низкокачественным, даже если в итоге добивается успеха. Эффективность измеряется в потреблённых ресурсах: общее количество tokens (стоимость), wall-clock time (реальное время выполнения, задержка) и сложность траектории (общее число шагов).

Надёжность (Robustness, устойчивость): Как агент справляется с трудностями и непредсказуемостью реального мира? Корректно ли он обрабатывает сбои, когда API не отвечает, меняется вёрстка сайта, отсутствуют данные или пользователь даёт неоднозначный запрос? Надёжный агент повторяет неудачные вызовы, при необходимости запрашивает у пользователя уточнения и сообщает, что и почему он не смог сделать, вместо того чтобы падать или галлюцинировать.

Безопасность и соответствие (Safety & Alignment, надёжность): Это обязательное условие. Действует ли агент в рамках определённых этических границ и ограничений? Этот столп охватывает всё: от метрик Responsible AI (ответственного ИИ) для оценки справедливости и предвзятости до защиты от prompt injection (инъекций в промпт) и data leakage (утечек данных). Он гарантирует, что агент придерживается задачи, отклоняет вредоносные инструкции и действует как доверенный представитель вашей организации.

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

Целостный фреймворк для оценки качества агента требует целостной архитектуры для обеспечения прозрачности его работы.

Искусство оценки агентов: судим по процессу

В Главе 1 мы определили фундаментальный переход от традиционного тестирования программного обеспечения к современной оценке AI. Традиционное тестирование — это детерминированный процесс верификации (verification), который отвечает на вопрос: «Правильно ли мы создали продукт?» в соответствии с чёткой спецификацией. Этот подход не работает, когда ключевая логика системы вероятностная, поскольку недетерминированный результат с большей вероятностью может привести к едва заметному снижению качества, которое не вызывает явных сбоев и может быть невоспроизводимым.

Оценка агента, напротив, — это целостный процесс валидации (validation). Он задаёт гораздо более сложный и стратегически важный вопрос: «Создали ли мы правильный продукт?». Этот вопрос является стратегической основой для фреймворка оценки «Outside-In», отражая необходимый переход от проверки внутреннего соответствия к оценке внешней ценности системы и её соответствия намерениям пользователя. Это требует от нас оценки общего качества, надёжности и ценности для пользователя, которую агент демонстрирует, работая в динамичном мире.

Появление AI-агентов, способных планировать, использовать инструменты и взаимодействовать со сложными средами, значительно усложняет ландшафт оценки. Мы должны перейти от «тестирования» результата к искусству «оценки» процесса. Эта глава предоставляет стратегический фреймворк именно для этого: для оценки всей траектории принятия решений агентом, от первоначального намерения до конечного результата.

Стратегический фреймворк: Иерархия оценки «Outside-In»

Чтобы не утонуть в море метрик на уровне отдельных компонентов, оценка должна быть нисходящим (top-down), стратегическим процессом. Мы называем это иерархией «Outside-In». Этот подход ставит во главу угла единственную метрику, которая в конечном итоге имеет значение, — реальный успех — и лишь затем предлагает погружаться в технические детали того, почему этот успех был (или не был) достигнут. Эта модель состоит из двух этапов: начните с «чёрного ящика», а затем откройте его.

Взгляд «Outside-In»: Сквозная оценка (End-to-End Evaluation) (Чёрный ящик)

Первый и самый важный вопрос: «Достиг ли агент цели, которую ставил пользователь, и был ли он эффективен?»

Это и есть взгляд «Outside-In». Прежде чем анализировать хотя бы одну внутреннюю мысль или вызов инструмента, мы должны оценить итоговую производительность агента относительно поставленной перед ним задачи.

Метрики на этом этапе фокусируются на общем выполнении задачи. Мы измеряем:

• Task Success Rate (процент успешного выполнения задач): Двоичная (или градуированная) оценка того, был ли конечный результат верным, полным и решал ли он реальную проблему пользователя. Например, процент принятых pull requests для агента-программиста, процент успешных транзакций с базой данных для финансового агента или процент завершённых сессий для чат-бота поддержки.

• User Satisfaction (удовлетворённость пользователя): Для интерактивных агентов это может быть прямая оценка от пользователя (например, лайк/дизлайк) или Customer Satisfaction Score (CSAT).

• Overall Quality (общее качество): Если цель агента была количественной (например, «составь краткое изложение этих 10 статей»), метрикой может быть точность или полнота (например, «Кратко ли изложены все 10 статей?»).

Если на этом этапе агент получает 100%, наша работа может быть закончена. Но в сложной системе такое случается редко. Когда агент выдаёт некорректный конечный результат, бросает задачу или не может прийти к решению, взгляд «Outside-In» говорит нам, что пошло не так. Теперь мы должны открыть «чёрный ящик», чтобы увидеть почему.

Практический совет:
Чтобы создать регрессионный тест для выходных данных с помощью Agent Development Kit (ADK), запустите веб-интерфейс ADK (командой adk web) и поработайте с вашим агентом. Когда вы получите идеальный ответ, который хотите использовать в качестве эталона, перейдите на вкладку Eval и нажмите «Add current session». Это сохранит всё взаимодействие как тестовый случай (Eval Case) в файле .test.json и зафиксирует текущий текстовый ответ агента в качестве эталонного (ground truth final_response). Затем вы можете запустить этот набор тестов (Eval Set) через CLI (с помощью adk eval) или pytest, чтобы автоматически проверять будущие версии агента на соответствие этому сохранённому ответу, отлавливая любые регрессии в качестве вывода.

Взгляд «изнутри»: Оценка траектории («стеклянный ящик»)

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

1. Планирование в LLM («Мысль»): Сначала мы проверяем логику рассуждений. Не в самой ли LLM кроется проблема? Сбои на этом этапе включают галлюцинации, бессмысленные или не относящиеся к теме ответы, «загрязнение» контекста или зацикливание вывода.

2. Использование инструментов (Выбор и параметризация): Агент хорош ровно настолько, насколько хороши его инструменты. Мы должны проанализировать, не вызывает ли агент не тот инструмент, не может ли вызвать нужный, «придумывает» ли названия инструментов или имена/типы их параметров, или вызывает инструмент без необходимости. Даже выбрав правильный инструмент, он может потерпеть неудачу, передав отсутствующие параметры, неверные типы данных или некорректно сформированный JSON для вызова API.

3. Интерпретация ответа инструмента («Наблюдение»): После того как инструмент корректно отработал, агент должен понять результат. Агенты часто допускают здесь ошибки: неверно интерпретируют числовые данные, не могут извлечь ключевые сущности из ответа или, что особенно важно, не распознают состояние ошибки, возвращённое инструментом (например, ошибку 404 от API), и продолжают работу, как будто вызов был успешным.

4. Производительность RAG: Если агент использует Retrieval-Augmented Generation (RAG), траектория зависит от качества полученной информации. Сбои включают извлечение нерелевантных документов, получение устаревшей или неверной информации, или ситуацию, когда LLM полностью игнорирует извлечённый контекст и всё равно «придумывает» ответ.

5. Эффективность и надёжность траектории: Помимо корректности, мы должны оценить сам процесс: выявить неэффективное использование ресурсов, такое как избыточное количество вызовов API, высокая задержка или лишние действия. Это также вскрывает проблемы с надёжностью, например, необработанные исключения.

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

Анализируя трассировку, мы можем перейти от вывода «конечный ответ неверный» («чёрный ящик») к выводу «конечный ответ неверный, потому что…» («стеклянный ящик»). Такой уровень диагностических возможностей и является главной целью оценки агента.

Практический совет:
Когда вы сохраняете Eval Case (тестовый случай), как описано в предыдущем совете, в ADK также сохраняется вся последовательность вызовов инструментов как эталонная траектория (ground truth trajectory). Ваш автоматический запуск через pytest или adk eval затем проверит эту траекторию на полное совпадение (по умолчанию).

Чтобы вручную оценить процесс (то есть отладить сбой), используйте вкладку Trace в веб-интерфейсе adk web. Она предоставляет интерактивный граф выполнения агента, позволяя вам визуально изучить его план, увидеть каждый вызванный им инструмент с точными аргументами и сравнить фактический путь с ожидаемым, чтобы точно определить шаг, на котором его логика дала сбой.

Оценщики: кто и как проводит оценку

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

Автоматизированные метрики

Автоматизированные метрики обеспечивают скорость и воспроизводимость. Они полезны для регрессионного тестирования (regression testing) и сравнения результатов (benchmarking). Примеры включают:

• Сравнение на основе строк (String-based similarity), такое как ROUGE или BLEU, для сопоставления сгенерированного текста с эталонами.

• Сравнение на основе эмбеддингов (Embedding-based similarity), такое как BERTScore или cosine similarity , для измерения семантической близости.

• Специализированные бенчмарки для конкретных задач, например, TruthfulQA.

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

Практический совет:
Внедрите автоматизированные метрики как первый барьер контроля качества в вашем CI/CD pipeline. Ключевой момент — рассматривать их как индикаторы тенденций, а не как абсолютную меру качества. Например, конкретное значение BERTScore 0.8 не означает однозначно, что ответ «хороший». Их реальная ценность — в отслеживании изменений: если ваша основная ветка (main branch) стабильно показывает средний BERTScore 0.8 на вашем «золотом наборе» данных (golden set), а новый commit кода снижает этот показатель до 0.6, вы автоматически обнаружили значительную регрессию. Это делает метрики идеальным, недорогим «первым фильтром» для массового отлова очевидных сбоев, прежде чем переходить к более дорогостоящей оценке с помощью LLM-as-a-Judge или человека.

Парадигма LLM-as-a-Judge

Как автоматизировать оценку качественных результатов, например, «хорошо ли это резюме?» или «логичен ли этот план?». Ответ — использовать ту же технологию, которую мы пытаемся оценить. Парадигма LLM-as-a-Judge (LLM как судья) предполагает использование мощной, передовой модели (например, Gemini Advanced от Google) для оценки результатов другого агента.

Мы предоставляем LLM-«судье» результат работы агента, исходный запрос (prompt), «золотой» или эталонный ответ (если он есть) и подробные критерии оценки (a detailed evaluation rubric), например: «Оцените полезность, правильность и безопасность этого ответа по шкале от 1 до 5 и объясните своё решение».

Этот подход обеспечивает масштабируемую, быструю и на удивление детальную обратную связь, особенно для оценки промежуточных шагов, таких как качество «мысли» (Thought) агента или его интерпретация ответа инструмента. Хотя это не заменяет человеческую оценку, это позволяет командам data science быстро оценивать производительность на тысячах сценариев, делая итеративный процесс оценки практически осуществимым.

Практический совет:
Чтобы реализовать этот подход, отдавайте предпочтение попарному сравнению (pairwise comparison) перед одиночной оценкой (single-scoring), чтобы снизить упомянутые риски предвзятости. Сначала прогоните ваш набор тестовых запросов (prompts) через две разные версии агента (например, старую рабочую и новую экспериментальную), чтобы для каждого запроса получить «Ответ А» и «Ответ Б».

Затем создайте LLM-судью, предоставив мощной LLM (например, Gemini Pro) чёткие критерии и prompt, который заставляет сделать выбор: «Учитывая данный запрос пользователя, какой ответ более полезен: А или Б? Объясните своё решение». Автоматизировав этот процесс, вы сможете в масштабе рассчитать соотношение побед/поражений/ничьих (win/loss/tie rate) для вашего нового агента. Высокий «процент побед» (win rate) — гораздо более надёжный сигнал об улучшении, чем небольшое изменение в абсолютной (и часто «шумной») оценке по 5-балльной шкале.

Prompt для LLM-as-a-Judge, особенно для надёжного попарного сравнения, может выглядеть так:

Парадигма Agent-as-a-Judge (Агент в роли оценщика)

В то время как LLM могут оценивать конечные ответы, агенты требуют более глубокой оценки их рассуждений и действий. Новая парадигма Agent-as-a-Judge использует одного агента для оценки полной трассировки выполнения (execution trace) другого. Вместо оценки только результатов, он анализирует сам процесс. Ключевые аспекты оценки включают:

• Качество плана: Был ли план логически структурирован и выполним?

• Использование инструментов: Были ли выбраны и корректно применены правильные инструменты?

• Обработка контекста: Эффективно ли агент использовал предыдущую информацию?

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

Практический совет:
Чтобы реализовать Agent-as-a-Judge, передавайте вашему оценщику соответствующие части объекта трассировки (trace object). Сначала настройте ваш фреймворк для агентов так, чтобы он логировал и экспортировал трассировку, включая внутренний план, список выбранных инструментов и точные переданные аргументы.

Затем создайте специализированного «Агента-критика» с prompt (критериями), который будет оценивать этот объект трассировки напрямую. Ваш prompt должен содержать конкретные вопросы о процессе: «1. Судя по трассировке, был ли первоначальный план логичным? 2. Был ли инструмент {tool_A} правильным первым выбором, или следовало использовать другой? 3. Были ли аргументы корректными и правильно отформатированными?». Это позволяет автоматически обнаруживать сбои в процессе (например, неэффективный план), даже если агент выдал конечный ответ, который выглядит правильным.

Оценка с участием человека (Human-in-the-Loop, HITL)

Хотя автоматизация обеспечивает масштаб, она не справляется с глубокой субъективностью и сложными предметными знаниями. Оценка с участием человека (HITL) — это ключевой процесс для улавливания важных качественных сигналов и тонких суждений, которые упускают автоматизированные системы.

Однако мы должны отойти от идеи, что оценка человеком даёт идеальную «объективную истину» (objective ground truth). Для крайне субъективных задач (таких как оценка креативности или тонких нюансов тональности) достичь полного согласия между оценщиками (inter-annotator agreement) удаётся редко. Вместо этого HITL является незаменимым методом для создания эталона, выверенного человеком (human-calibrated benchmark), гарантируя, что поведение агента соответствует сложным человеческим ценностям, контекстуальным потребностям и точности, требуемой в конкретной области.

Процесс HITL включает несколько ключевых функций:

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

• Интерпретация нюансов: Люди незаменимы для оценки тонких качеств, определяющих высококлассное взаимодействие, таких как тон, креативность, намерение пользователя и сложное этическое соответствие.

• Создание «золотого набора» (Golden Set): Прежде чем автоматизация станет эффективной, люди должны создать эталонный бенчмарк («золотой стандарт»). Это включает в себя подбор исчерпывающего набора для оценки, определение критериев успеха и разработку надёжного набора тестовых случаев, охватывающих типичные, пограничные (edge cases) и состязательные (adversarial) сценарии.

Практический совет:
Для обеспечения безопасности во время выполнения (runtime safety) внедрите процесс прерывания (interruption workflow). В фреймворке, подобном ADK, вы можете настроить агента так, чтобы он приостанавливал выполнение перед совершением критически важного вызова инструмента (например, execute_payment или delete_database_entry). Состояние агента и его планируемое действие затем отображаются в интерфейсе для проверки (Reviewer UI), где оператор-человек должен вручную одобрить или отклонить этот шаг, прежде чем агент сможет продолжить работу.

Обратная связь от пользователей и интерфейс для проверки

Оценка также должна включать сбор реальной обратной связи от пользователей. Каждое взаимодействие — это сигнал о полезности, ясности и доверии. Эта обратная связь включает как качественные сигналы (например, лайк/дизлайк), так и количественные метрики успеха внутри продукта, такие как процент принятия pull request (PR) для агента-программиста или процент успешных бронирований для агента по путешествиям. Лучшие практики включают:

• Простая и быстрая обратная связь: лайки/дизлайки, ползунки для быстрой оценки или короткие комментарии.

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

• Пользовательский интерфейс для проверки (Reviewer UI): двухпанельный интерфейс: диалог слева, шаги рассуждений справа, с возможностью помечать проблемы прямо в тексте (inline tagging), например, «плохой план» или «неправильное использование инструмента».

• Панели управления (Governance dashboards): агрегированная обратная связь для выявления повторяющихся проблем и рисков.

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

Практический совет:
Реализуйте вашу систему сбора обратной связи как событийно-ориентированный конвейер (event-driven pipeline), а не просто как статический лог. Когда пользователь нажимает «дизлайк», этот сигнал должен автоматически захватывать полную трассировку диалога со всем контекстом и добавлять её в специальную очередь на проверку в Reviewer UI вашего разработчика.

За рамками производительности: Ответственный ИИ (Responsible AI, RAI) и оценка безопасности

Последний аспект оценки — это не просто компонент, а обязательный и не подлежащий обсуждению барьер для любого агента в рабочей среде (production): Ответственный ИИ и Безопасность. Агент, который на 100% результативен, но причиняет вред, — это полный провал.

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

• Систематический Red Teaming (целенаправленное тестирование на уязвимости): Активные попытки «сломать» агента с помощью состязательных (adversarial) сценариев. Это включает попытки сгенерировать враждебные высказывания, раскрыть частную информацию, распространить вредные стереотипы или побудить агента к злонамеренным действиям.

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

• Следование принципам: Явная оценка результатов работы агента на соответствие заранее определённым этическим нормам и принципам для обеспечения согласованности и предотвращения непреднамеренных последствий.

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

Практический совет:
Реализуйте ваши защитные механизмы (guardrails) в виде структурированного Plugin (плагина), а не как изолированные функции. В этом паттерне callback (функция обратного вызова) — это механизм (хук, предоставляемый ADK), а Plugin — это создаваемый вами переиспользуемый модуль.

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

1. Метод вашего плагина check_input_safety() регистрируется с callback-функцией before_model_callback. Задача этого метода — запустить ваш классификатор prompt injection (инъекций в промпт).

2. Метод вашего плагина check_output_pii() регистрируется с callback-функцией after_model_callback. Его задача — запустить ваш сканер PII (Personally Identifiable Information, персонально идентифицируемой информации).

Такая архитектура плагинов делает ваши защитные механизмы переиспользуемыми, независимо тестируемыми и позволяет аккуратно накладывать их поверх встроенных настроек безопасности базовой модели (таких как в Gemini).

Наблюдаемость (Observability): Заглядывая в разум агента

От мониторинга к истинной наблюдаемости

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

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

Кухонная аналогия: повар на раздаче против шеф-повара

• Традиционное ПО — это повар на раздаче: Представьте себе кухню ресторана быстрого питания. У повара есть ламинированная карточка с рецептом бургера. Шаги жёсткие и детерминированные: поджарить булочку 30 секунд, жарить котлету 90 секунд, добавить один ломтик сыра, два огурчика, одну порцию кетчупа.

  • Мониторинг (Monitoring) в этом мире — это чек-лист. Правильная ли температура у гриля? Выполнил ли повар каждый шаг? Был ли заказ готов вовремя? Мы верифицируем известный, предсказуемый процесс.

• AI-агент — это шеф-повар в соревновании с «загадочной корзиной»: Шеф-повару ставят цель («Создай потрясающий десерт») и дают корзину с ингредиентами (запрос пользователя, данные и доступные инструменты). Единого правильного рецепта не существует. Он может приготовить шоколадный фондан, деконструированный тирамису или панна-котту с шафраном. Все эти варианты могут быть правильными и даже гениальными решениями.

  • Наблюдаемость (Observability) — это то, как ресторанный критик оценивал бы шеф-повара. Критик не просто пробует готовое блюдо. Он хочет понять процесс и логику. Почему шеф решил сочетать малину с базиликом? Какую технику он использовал для кристаллизации имбиря? Как он адаптировался, когда понял, что у него закончился сахар? Нам нужно заглянуть в его «мыслительный процесс», чтобы по-настоящему оценить качество его работы.

Это представляет собой фундаментальный сдвиг для AI-агентов — переход от простого мониторинга к истинной наблюдаемости. Фокус смещается с простой проверки активности агента на понимание качества его когнитивных процессов. Вместо вопроса «Работает ли агент?» критически важным становится вопрос «Эффективно ли агент мыслит?».

Три столпа наблюдаемости (Observability)

Итак, как нам получить доступ к «мыслительному процессу» агента? Мы не можем напрямую читать его мысли, но можем анализировать следы, которые он оставляет. Это достигается путём построения нашей практики наблюдаемости на трёх основополагающих столпах: логи (Logs), трассировки (Traces) и метрики (Metrics). Это инструменты, которые позволяют нам перейти от дегустации готового блюда к оценке всего кулинарного процесса.

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

Столп 1: Логирование — дневник агента

Что такое логи? Логи (Logs) — это основной строительный блок . Думайте о них как о записях с метками времени в дневнике вашего агента. Каждая запись — это необработанный, неизменяемый факт о дискретном событии: «В 10:01:32 мне задали вопрос. В 10:01:33 я решил использовать инструмент get_weather». Они говорят нам, что произошло.

Больше чем print(): что делает лог эффективным?
Полностью управляемый сервис, такой как Google Cloud Logging, позволяет хранить, искать и анализировать данные логов в больших масшта масштабах. Он может автоматически собирать логи из сервисов Google Cloud, а его возможности Log Analytics позволяют выполнять SQL-запросы для выявления тенденций в поведении вашего агента.

Лучшие в своем классе фреймворки упрощают эту задачу. Например, Agent Development Kit (ADK) построен на основе стандартного модуля logging в Python. Это позволяет разработчику настраивать желаемый уровень детализации — от высокоуровневых сообщений INFO в рабочей среде (production) до гранулярных DEBUG-сообщений при разработке — не изменяя код агента.

Анатомия критически важной записи в логе
Чтобы восстановить «мыслительный процесс» агента, лог должен быть богат контекстом. Структурированный формат JSON — это золотой стандарт.

• Основная информация: Хороший лог фиксирует полный контекст: пары prompt/response, промежуточные шаги рассуждений («chain of thought» (цепочка рассуждений) агента, концепция, исследованная Вей и др. (2022)), структурированные вызовы инструментов (входные данные, результаты, ошибки) и любые изменения во внутреннем состоянии агента.

• Компромисс: детализация против производительности. Очень подробный DEBUG-лог — лучший друг разработчика при поиске неисправностей, но он может быть слишком «шумным» и создавать нагрузку на производительность в рабочей среде. Именно поэтому структурированное логирование так эффективно: оно позволяет собирать детальные данные, но при этом эффективно их фильтровать.

Вот практический пример, демонстрирующий мощь структурированного лога, адаптированный из DEBUG-вывода ADK:

Практический совет: Эффективный паттерн логирования — записывать намерение агента перед действием и результат — после. Это позволяет сразу отличить неудачную попытку от осознанного решения не действовать.

Столп 2: Трассировка — следуем по пятам агента

Что такое трассировка? Если логи — это записи в дневнике, то трассировки (Traces) — это повествовательная нить, связывающая их в единую историю. Трассировка отслеживает одну задачу — от первоначального запроса пользователя до конечного ответа, — сшивая отдельные логи (называемые spans, промежутками) в полное, сквозное представление. Трассировки раскрывают ключевое «почему», показывая причинно-следственную связь между событиями.

Представьте себе доску с уликами у детектива. Логи — это отдельные улики: фотография, обрывок билета. Трассировка — это красная нить, соединяющая их и раскрывающая полную последовательность событий.

Почему трассировка незаменима

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

• Изолированные логи могут показать: ERROR: RAG search failed и ERROR: LLM response failed validation. Вы видите ошибки, но первопричина неясна.

• Трассировка раскрывает всю причинно-следственную цепочку: Запрос пользователя → Поиск RAG (неудача) → Ошибочный вызов инструмента (получен null) → Ошибка LLM (сбита с толку плохим ответом инструмента) → Неверный конечный ответ.

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

Ключевые элементы трассировки агента

Современная трассировка построена на открытых стандартах, таких как OpenTelemetry. Основные компоненты:

• Spans (промежутки): Отдельные, именованные операции в рамках трассировки (например, span для llm_call или tool_execution).

• Attributes (атрибуты): Богатые метаданные, прикреплённые к каждому span: prompt_id, latency_ms, token_count, user_id и т. д.

• Context Propagation (распространение контекста): Та самая «магия», которая связывает spans воедино через уникальный trace_id, позволяя бэкенд-системам, таким как Google Cloud Trace, собирать полную картину. Cloud Trace — это распределённая система трассировки, которая помогает понять, сколько времени требуется вашему приложению для обработки запросов. Когда агент развёрнут в управляемой среде выполнения, такой как Vertex AI Agent Engine, эта интеграция упрощается. Agent Engine берёт на себя инфраструктуру для масштабирования агентов в production и автоматически интегрируется с Cloud Trace, обеспечивая сквозную наблюдаемость и связывая вызов агента со всеми последующими вызовами моделей и инструментов.

Столп 3: Метрики — отчёт о здоровье агента

Что такое метрики? Если логи — это заметки шеф-повара, а трассировки — это критик, наблюдающий за процессом приготовления, то метрики (Metrics) — это итоговая оценка, которую публикует критик. Это количественные, агрегированные показатели здоровья, которые дают мгновенное, наглядное представление об общей производительности вашего агента.

Важно отметить, что критик не придумывает эти оценки, попробовав лишь финальное блюдо. Его суждение основано на всём, что он наблюдал. С метриками то же самое: это не новый источник данных. Они выводятся путём агрегирования данных из ваших логов и трассировок за определённый период. Они отвечают на вопрос: «Насколько хорошо, в среднем, он справился с задачей?».

Для AI-агентов полезно разделить метрики на две категории: напрямую измеряемые System Metrics (системные метрики) и более сложные, оценочные Quality Metrics (метрики качества).

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

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

Ключевые системные метрики для отслеживания включают:

• Производительность:

  • Latency (задержка) (P50/P99): Рассчитывается путём агрегирования атрибута duration_ms из трассировок для нахождения медианного (P50) и 99-го перцентиля (P99) времени ответа. Это говорит о типичном и наихудшем пользовательском опыте.

  • Error Rate (уровень ошибок): Процент трассировок, содержащих span с атрибутом error=true.

• Стоимость:

  • Tokens per Task (количество токенов на задачу): Среднее значение атрибута token_count по всем трассировкам, что критически важно для управления затратами на LLM.

  • API Cost per Run (стоимость API за запуск): Сочетая количество токенов с ценами на модель, вы можете отслеживать среднюю финансовую стоимость одной задачи.

• Результативность:

  • Task Completion Rate (процент завершения задач): Процент трассировок, которые успешно достигают определённого span, обозначающего успех («success»).

  • Tool Usage Frequency (частота использования инструментов): Подсчёт того, как часто каждый инструмент (например, get_weather) появляется в качестве имени span, что показывает, какие инструменты наиболее ценны.

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

Метрики качества: оценка процесса принятия решений

Метрики качества (Quality Metrics) — это метрики второго порядка, которые выходят за рамки простой работоспособности и оценивают сами рассуждения агента и качество его конечного результата. Они получаются путём применения оценочных фреймворков, описанных в Главе 2, к необработанным данным наблюдаемости (observability data).

Это не простые счётчики или средние значения. Примеры критически важных метрик качества включают:

• Correctness & Accuracy (Правильность и точность): Предоставил ли агент фактически верный ответ? Если он резюмировал документ, соответствовало ли резюме источнику?

• Trajectory Adherence (Следование траектории): следовал ли агент намеченному пути или «идеальному рецепту» для данной задачи? Вызывал ли он правильные инструменты в правильном порядке?

• Safety & Responsibility (Безопасность и ответственность): Не содержал ли ответ агента вредоносного, предвзятого или неуместного контента?

• Helpfulness & Relevance (Полезность и релевантность): Был ли конечный ответ агента действительно полезен для пользователя и релевантен его запросу?

Для получения этих метрик недостаточно простого запроса к базе данных. Часто требуется сравнение результата работы агента с «золотым» набором данных (golden dataset) или использование продвинутой LLM-as-a-Judge для оценки ответа по заданным критериям (rubric). Данные наблюдаемости из наших логов и трассировок — это необходимые доказательства для расчёта этих оценок, но сам процесс вынесения суждения — это отдельная, критически важная дисциплина.

Собираем всё воедино: от сырых данных к практическим выводам

Наличие логов, трассировок и метрик — это как иметь талантливого шеф-повара, хорошо укомплектованную кладовую и критерии для оценки. Но это лишь компоненты. Чтобы управлять успешным рестораном, нужно собрать их в рабочую систему для напряжённой смены. Этот раздел посвящён именно практической сборке — превращению данных наблюдаемости (observability data) в действия и выводы в реальном времени во время эксплуатации.

Это включает в себя три ключевые операционные практики:

1. Дашборды и оповещения: разделяем здоровье системы и качество модели

Одного дашборда недостаточно. Для эффективного управления AI-агентом вам нужны отдельные представления для системных метрик (System Metrics) и метрик качества (Quality Metrics), поскольку они служат разным целям и разным командам.

• Операционные дашборды (для системных метрик): Эта категория дашбордов фокусируется на состоянии системы в реальном времени. Она отслеживает ключевые «жизненные показатели» агента и в первую очередь предназначена для инженеров по надёжности (SREs), команд DevOps и операционных специалистов, отвечающих за работоспособность и производительность системы.

  • Что отслеживает: P99 Latency (99-й перцентиль задержки), Error Rates (уровень ошибок), API Costs (затраты на API), Token Consumption (потребление токенов).

  • Цель: Мгновенно выявлять системные сбои, снижение производительности или перерасход бюджета.

  • Пример оповещения (Alert): ALERT: P99 latency > 3s for 5 minutes. Это указывает на узкое место в системе, требующее немедленного внимания инженеров.

• Дашборды качества (для метрик качества): Эта категория отслеживает более тонкие, медленнее меняющиеся индикаторы результативности и корректности агента. Она необходима владельцам продуктов (product owners), специалистам по data science и командам AgentOps, которые отвечают за качество решений и результатов агента.

  • Что отслеживает: Factual Correctness Score (оценка фактической правильности), Trajectory Adherence (следование траектории), Helpfulness Ratings (рейтинги полезности), Hallucination Rate (уровень галлюцинаций).

  • Цель: Обнаруживать едва заметные отклонения в качестве работы агента, особенно после развёртывания новой модели или prompt.

  • Пример оповещения (Alert): ALERT: 'Helpfulness Score' has dropped by 10% over the last 24 hours. Это сигнализирует о том, что, хотя система может работать нормально (системные метрики в порядке), качество результатов агента снижается, что требует расследования его логики или данных.

2. Безопасность и PII: защищаем ваши данные

Это не подлежащий обсуждению аспект эксплуатации в production. Входные данные от пользователей, фиксируемые в логах и трассировках, часто содержат персонально идентифицируемую информацию (Personally Identifiable Information, PII). Надёжный механизм очистки от PII должен быть неотъемлемой частью вашего конвейера логирования до долгосрочного хранения данных, чтобы обеспечить соответствие нормам конфиденциальности и защитить ваших пользователей.

3. Ключевой компромисс: детализация против накладных расходов

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

• Лучшая практика — динамическое сэмплирование (Dynamic Sampling): Используйте высокодетализированное логирование (уровень DEBUG) в средах разработки. В production установите более низкий уровень логирования по умолчанию (INFO), но внедрите динамическое сэмплирование. Например, вы можете трассировать только 10% успешных запросов, но 100% всех ошибок. Это даст вам общие данные о производительности для ваших метрик, не перегружая систему, но при этом сохраняя богатую диагностическую информацию, необходимую для отладки каждого сбоя.

Заключение: Формирование доверия в мире автономных систем

Введение: От автономных возможностей к доверию на корпоративном уровне

В начале этого документа мы обозначили фундаментальную проблему: AI-агенты с их недетерминированной и автономной природой разрушают наши традиционные модели качества программного обеспечения. Мы сравнили задачу оценки агента с оценкой нового сотрудника — вы не просто спрашиваете, была ли задача выполнена, а интересуетесь, как она была выполнена. Была ли работа эффективной? Безопасной? Создала ли она положительный опыт? Действовать вслепую — не вариант, когда на кону стоят бизнес-риски.

Весь этот документ был посвящён созданию основы для доверия в рамках этой новой парадигмы. Мы обосновали необходимость новой дисциплины, определив Четыре столпа качества агента: Результативность (Effectiveness), экономическая эффективность (Cost-Efficiency), безопасность (Safety) и доверие пользователя (User Trust). Затем мы показали, как получить «глаза и уши» внутри разума агента с помощью наблюдаемости (Observability, Глава 3) и как оценивать его производительность с помощью целостного фреймворка оценки (Evaluation, Глава 2). Этот документ заложил основу для того, что измерять и как это видеть. Следующий критически важный шаг, который будет рассмотрен в последующем документе «День 5: От прототипа к продакшену» (Day 5: Prototype to Production), — это применение этих принципов на практике. Это включает в себя запуск прошедшего оценку агента в производственной среде с использованием надёжных CI/CD пайплайнов, безопасных стратегий развёртывания и масштабируемой инфраструктуры.

Теперь соберём всё воедино. Это не просто резюме; это операционная модель для превращения абстрактных принципов в надёжную, самосовершенствующуюся систему, которая устраняет разрыв между оценкой и производством.

Маховик качества агента: синтез всего фреймворка

Отличный агент не просто работает — он совершенствуется. Именно дисциплина непрерывной оценки отличает умное демо от системы корпоративного уровня. Эта практика создаёт мощную, самоусиливающуюся систему, которую мы называем «Маховик качества агента» (Agent Quality Flywheel).

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

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

• Шаг 1: Определите качество (Цель): Маховику нужно направление. Как мы определили в Главе 1, всё начинается с Четырёх столпов качества: Effectiveness (Результативность), Cost-Efficiency (Экономическая эффективность), Safety (Безопасность) и User Trust (Доверие пользователя). Эти столпы — не абстрактные идеалы, а конкретные цели, которые придают смысл нашим усилиям по оценке и связывают маховик с реальной бизнес-ценностью.

• Шаг 2: Обеспечьте прозрачность (Основа): Вы не можете управлять тем, чего не видите. Как подробно описано в главе о наблюдаемости (Observability), мы должны настроить наших агентов так, чтобы они создавали структурированные Logs (дневник агента) и сквозные Traces (повествовательная нить). Эта наблюдаемость является фундаментальной практикой, которая генерирует богатые данные, необходимые для измерения наших Четырёх столпов, обеспечивая топливо для маховика.

• Шаг 3: Оцените процесс (Двигатель): Обеспечив прозрачность, мы можем оценивать производительность. Как было рассмотрено в главе об оценке, это включает в себя стратегический подход «outside-in», оценивающий как конечный Output (результат), так и весь Process (процесс) рассуждений. Это и есть мощный толчок, который раскручивает маховик — гибридный двигатель, использующий масштабируемые системы LLM-as-a-Judge для скорости и «золотой стандарт» Human-in-the-Loop (HITL) в качестве источника истины.

• Шаг 4: Спроектируйте петлю обратной связи (Инерция): Здесь архитектура «evaluatable-by-design» (проектирование с учётом возможности оценки) из Главы 1 воплощается в жизнь. Создавая критически важную петлю обратной связи, мы гарантируем, что каждый сбой в production, будучи зафиксированным и аннотированным, программно превращается в постоянный регрессионный тест в нашем «золотом» наборе для оценки (Golden Evaluation Set). Каждый сбой делает систему умнее, раскручивая маховик быстрее и обеспечивая неуклонное, непрерывное совершенствование.

Три ключевых принципа для создания надёжных агентов

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

• Принцип 1: Относитесь к оценке как к архитектурному столпу, а не как к финальному этапу. Помните аналогию с гоночным болидом из Главы 1? Вы не строите болид Формулы-1, а потом прикручиваете к нему датчики. Вы проектируете его с нуля с портами для телеметрии. Агентные системы требуют той же парадигмы DevOps. Надёжные агенты спроектированы с учётом возможности оценки («evaluatable-by-design»), они с первой строки кода настроены на генерацию logs и traces, необходимых для анализа. Качество — это архитектурный выбор, а не финальный этап QA.

• Принцип 2: Истина — в траектории. Для агентов конечный ответ — это лишь последнее предложение длинной истории. Как мы установили в главе об оценке, истинная мера логики, безопасности и эффективности агента заключается в его сквозном «мыслительном процессе» — траектории. Это и есть оценка процесса (Process Evaluation). Чтобы действительно понять, почему агент преуспел или потерпел неудачу, вы должны анализировать этот путь. Это возможно только благодаря глубоким практикам наблюдаемости (Observability), которые мы подробно описали в Главе 3.

• Принцип 3: Человек — арбитр. Автоматизация — наш инструмент для масштабирования; человечество — наш источник истины. Автоматизация, от систем LLM-as-a-Judge до классификаторов безопасности, необходима. Однако, как было установлено при глубоком рассмотрении оценки с участием человека (Human-in-the-Loop, HITL), фундаментальное определение «хорошего», валидация тонких нюансов в результатах и окончательное суждение о безопасности и справедливости должны быть основаны на человеческих ценностях. ИИ может помочь оценить тест, но именно человек пишет критерии и решает, что на самом деле означает «отлично».

Будущее за агентами — и оно должно быть надёжным

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

Освоение концепций, изложенных в этом документе — то, что можно назвать «Инженерией оценки» (Evaluation Engineering), — станет ключевым конкурентным преимуществом для следующей волны развития ИИ. Организации, которые продолжат относиться к качеству агентов как к второстепенной задаче, застрянут в цикле многообещающих демо и провальных развёртываний. Напротив, те, кто инвестирует в этот строгий, архитектурно-интегрированный подход к оценке, смогут преодолеть хайп и развернуть по-настоящему преобразующие ИИ-системы корпоративного уровня.

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