Как измерять AI-агента в продакшене: traces и evals

AI-агент в продакшене нельзя измерять только временем ответа и числом ошибок. Между пользовательской задачей и финальным результатом могут находиться планирование, несколько обращений к модели, поиск контекста, вызовы инструментов, повторные попытки и проверки результата. Чтобы понять, где система ошиблась, сколько стоило её поведение и можно ли доверять оценке качества, нужна связка из traces, стабильного telemetry contract и непрерывных evals.

Ниже — практическая архитектура такой связки по состоянию на 27 августа 2026 года. Важно различать подтверждённые свойства стандартов, заявления поставщиков и редакционные рекомендации. В частности, соглашения OpenTelemetry для GenAI ещё развиваются, а заявленная совместимость системы оценки с разными фреймворками не означает, что она прочитает произвольный OTLP trace без нужной AI-семантики.

Коротко

• Факт: OpenTelemetry GenAI Semantic Conventions вынесены в отдельный репозиторий, имеют статус Development, а указанный schema URL — gen-ai/1.42.0. Названия и зрелость отдельных полей ещё могут меняться.
• Факт: agent conventions описывают spans create_agent, invoke_agent, invoke_workflow, plan и execute_tool.
• Факт: OpenInference задаёт AI-специфичную семантику поверх OTLP. Каждый OpenInference trace остаётся валидным OTLP, но произвольный OTLP trace не обязательно содержит сообщения, сведения об инструментах и другие данные, нужные AI-анализатору.
• Ограничение: «framework-agnostic» означает независимость от фреймворка только при совместимом instrumentation scope, полном дереве spans и наличии необходимых message/tool attributes.
• Риск: prompts, ответы, аргументы инструментов и retrieved documents могут содержать PII, токены доступа и коммерческие секреты. Их сбор должен быть opt-in, проходить redaction и подчиняться retention policy.
• Редакционная рекомендация: считать главным артефактом не конкретный backend, а версионируемый telemetry contract: какие операции образуют trace, какие поля обязательны, как распространяется контекст, что запрещено экспортировать и как из traces строятся evals.

Почему обычных логов недостаточно

Лог отвечает на вопрос «что сообщил конкретный компонент». Для агента этого мало: ошибка может проявиться в финальном ответе, хотя её причина возникла раньше — в выборе инструмента, неполном контексте, повторном планировании или результате внешней операции. Несколько строк с одинаковым request ID помогают поиску, но сами по себе не описывают причинную структуру.

Trace добавляет эту структуру. Он связывает операции через trace ID, parent-child отношения и, где это необходимо, links. Span фиксирует границы операции, её статус, длительность и атрибуты. Межсервисная передача контекста опирается на W3C Trace Context, поэтому один пользовательский путь можно продолжить через несколько сервисов при условии, что контекст действительно передаётся.

Интерпретация: observability AI-агентов — это не «логирование prompt». Это реконструкция поведения системы: какой агент принял задачу, какой план сформировал, к каким моделям и инструментам обратился, что получил, что повторил и по какому результату был оценён.

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

Trace как единица поведения агента

Удобно определять trace не как один HTTP-запрос, а как выполнение одной бизнес-задачи с ясной границей. Для синхронного помощника эти границы могут совпасть. Для длительного workflow один пользовательский запрос способен породить несколько этапов и фоновых операций. Решение о границе должно быть записано в telemetry contract, иначе команды будут сравнивать разные сущности под одним названием «запуск агента».

Уровень	Что представляет	На какой вопрос отвечает	Типичная ошибка
Trace	Выполнение задачи или workflow	Что агент сделал от входа до результата?	Разрывать одну задачу на несвязанные сервисные traces
Span	Операцию: вызов агента, планирование, инструмент, модель	Где возникли задержка, ошибка или повтор?	Записывать весь агентный цикл одним непрозрачным span
Attribute	Структурированный признак операции	Какая версия, тип инструмента или политика использовались?	Складывать всё в неструктурированное сообщение
Link	Связь с другой работой, не выраженной одним parent	Какие асинхронные ветви относятся к задаче?	Подменять link случайной строковой корреляцией
Eval	Оценку trace, шага или результата	Насколько поведение соответствует критерию?	Хранить score без версии evaluator и рубрики

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

Практический вывод: перед внедрением SDK нарисуйте эталонный trace для трёх сценариев: успешного, частично деградировавшего и ошибочного. Если по дереву нельзя объяснить решение агента без чтения сырых payloads, контракт недостаточно выразителен.

Минимальное дерево spans

Agent conventions OpenTelemetry описывают операции create_agent, invoke_agent, invoke_workflow, plan и execute_tool. Это полезный каркас, но статус Development означает, что названия и конкретный состав атрибутов нужно сверять с используемой версией схемы.

invoke_workflow
  invoke_agent
    plan
    model_or_generation_step
    execute_tool
      external_operation
    model_or_generation_step
  evaluator

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

Элемент контракта	Минимум	Зачем	Безопасный режим
Идентичность операции	Trace/span context, тип операции, scope и версия инструментации	Связать дерево и понять, кто создал данные	Не включать пользовательские данные в имена spans
Версия поведения	Версии агента, workflow, prompt template и tool schema	Сравнивать одинаковые конфигурации	Хранить идентификаторы или хеши вместо полного текста
Результат шага	Статус, категория ошибки, число попыток	Отделять технический сбой от плохого решения	Не копировать stack trace с секретами без фильтра
Время и объём	Длительность, доступные usage-показатели	Считать задержку и ресурсный вклад	Проверять, не раскрывают ли атрибуты содержимое
Tool metadata	Идентификатор инструмента и версия схемы	Проверять выбор и совместимость вызова	Аргументы собирать по allowlist или не собирать
Eval metadata	Evaluator, версия, rubric, score и решение	Воспроизводить оценку	Отдельная политика доступа и retention

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

OpenTelemetry GenAI conventions

Факт: GenAI semantic conventions находятся в отдельном репозитории OpenTelemetry. На дату среза их статус — Development, schema URL — gen-ai/1.42.0. Карта GenAI conventions объединяет области и сигналы, относящиеся к generative AI systems.

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

Редакционная рекомендация: фиксировать в каждом deployment четыре версии: semantic schema, instrumentation library, telemetry contract приложения и набор evaluator. Если хранить только версию агента, позднее будет невозможно понять, изменилась модель поведения или способ её измерения.

Семантические conventions не отменяют обычную эксплуатационную telemetry. Агентный span должен коррелировать с нижележащей работой, но не обязан дублировать все сетевые и сервисные атрибуты. Полезное разделение: GenAI-уровень объясняет намерение и шаг поведения, инфраструктурный уровень — исполнение этого шага.

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

OpenInference и OTLP

OpenInference — AI-специфичная семантика, совместимая с OTLP. Её semantic conventions описывают атрибуты и виды spans для LLM, tools, retrievers и evaluators.

Здесь важно не смешивать два вида совместимости. Транспортная переносимость означает, что данные можно представить и передать как OTLP. Семантическая совместимость означает, что принимающая система понимает назначение spans и полей. Каждый OpenInference trace валиден как OTLP, но не каждый OTLP trace содержит достаточную AI-семантику.

Проверка	OTLP-переносимость	Семантическая совместимость
Данные принимаются endpoint	Да, это основная задача формата передачи	Недостаточно
Сохраняются trace ID и parent-child связи	Должны сохраняться при корректном pipeline	Ещё не доказывает понимание AI-шагов
Распознаётся tool call	Не гарантируется самим OTLP	Нужны ожидаемые span kind и attributes
Читаются сообщения и evaluator results	Не гарантируется	Зависит от семантики и полноты полей
Можно сменить backend без потери смысла	Возможность передачи помогает	Требуется тест контракта на целевой стороне

Практический вывод: успешный экспорт без ошибок не является приёмочным тестом. После экспорта нужно проверить, что downstream-система распознала agent, tool, retriever и evaluator spans, а не просто сохранила их как произвольные операции.

Что читает AgentCore Evaluations

26 августа 2026 года AWS заявила, что Amazon Bedrock AgentCore Evaluations может оценивать несколько agent frameworks. Это заявление компании, а не результат независимой проверки.

Ключевое условие находится не в названии фреймворка. Telemetry reader должен увидеть узнаваемый instrumentation scope и необходимые message/tool attributes. Если scope называется иначе, spans неполны или отсутствуют tool schemas, формально валидная telemetry может оказаться нечитаемой для оценки.

Интерпретация: «evaluate any agent framework» корректнее понимать как «оценивать разные фреймворки, если их telemetry соответствует ожидаемому контракту». Независимость от runtime не равна независимости от схемы данных.

Как проверять: отправить небольшой набор эталонных traces, включающий успешный вызов инструмента, ошибку инструмента, несколько сообщений, повтор и trace без контента. Затем сравнить, какие шаги reader распознал, какие проигнорировал и какие поля потребовал. Такой contract test важнее демонстрации одного счастливого сценария.

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

Offline и online evals

Offline eval запускается на сохранённом или подготовленном наборе случаев. Он подходит для сравнения версий prompt, агента, инструмента, rubric или evaluator до выката. Online eval работает на потоке production traces либо на его выборке и показывает, как система ведёт себя на реальном распределении задач.

Режим	Основная цель	Преимущество	Главный риск
Offline	Регрессии и сравнение кандидатов	Повторяемый набор и контролируемые версии	Dataset перестаёт отражать production
Online синхронный	Решение во время выполнения	Можно применить результат немедленно	Дополнительная задержка и зависимость
Online асинхронный	Мониторинг потока после ответа	Не удлиняет пользовательский путь	Оценка приходит позднее и требует links
Incident replay	Разбор конкретного сбоя	Фокус на проблемном классе	Повтор может быть невозможен без исходного контекста

Связь между режимами должна быть замкнутой, но не автоматической. Production traces помогают находить новые классы случаев; после безопасной очистки и разметки часть из них попадает в offline dataset. Новый evaluator сначала проверяется на зафиксированном наборе, затем запускается в shadow-режиме и только после этого может влиять на алерты или решения.

Редакционная рекомендация: хранить отдельно наблюдение и решение. Score — числовой результат evaluator. Pass/fail — решение по порогу и политике. Изменение порога не должно переписывать исторический score.

Eval может относиться к финальному результату, отдельному tool call, retrieval step или всему trace. Без явной target-связи агрегирование вводит в заблуждение: низкая оценка ответа и неправильный выбор инструмента — разные дефекты и требуют разных владельцев.

Метрики качества и стоимости

Одна «оценка качества» слишком груба для эксплуатации. Набор метрик должен разделять итог задачи, процесс, надёжность, задержку и ресурсный вклад. Ниже — редакционная схема, а не обязательная часть OpenTelemetry.

Группа	Пример метрики	Как считать	Что проверять
Результат	Task success rate	Успешные задачи / все оценённые задачи	Определение успеха и покрытие evals
Инструменты	Tool success rate	Успешные вызовы / все вызовы данного типа	Не смешивать отказ инструмента и неверный выбор
Поведение	Повторные планы	Число plan spans после первого на trace	Повтор не всегда является дефектом
Задержка	End-to-end и вклад шагов	Длительность trace и spans по категориям	Параллельные spans нельзя просто суммировать
Ресурсы	Usage на успешную задачу	Суммарный доступный usage / успешные задачи	Неполные данные и разные единицы
Стоимость	Оценочная стоимость задачи	Сумма usage × зафиксированные ставки	Версия прайсинга и неучтённые компоненты
Оценивание	Eval coverage	Оценённые traces / eligible traces	Sampling и ошибки evaluator pipeline

task_success_rate = passed_tasks / evaluated_tasks
eval_coverage = evaluated_eligible_traces / eligible_traces
estimated_task_cost = sum(usage_unit × rate_at_pricing_version)

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

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

PII, secrets и redaction

Полные prompts, ответы, tool arguments и retrieved documents являются потенциально чувствительными данными. В них могут оказаться персональные сведения, токены, секреты интеграций и коммерческий контекст. Рекомендации по безопасной эксплуатации telemetry следует сверять с OpenTelemetry Security Guidelines, но конкретная политика всегда зависит от системы и её модели угроз.

Базовый принцип: метаданные собираются по умолчанию только в объёме, необходимом для измерения; сырой контент — opt-in. Redaction нужно выполнять до выхода данных за доверенную границу, а не только при отображении в интерфейсе.

1. Запретить экспорт authentication headers, access tokens, session secrets и содержимого секретных переменных.
2. Для prompts и responses разделить режимы: выключено, структурированные признаки, очищенный фрагмент, полный контент по исключению.
3. Аргументы инструментов пропускать через allowlist полей; неизвестные поля удалять, а не разрешать автоматически.
4. Для retrieved documents по умолчанию хранить идентификатор, версию и технические признаки, а не полный текст.
5. Псевдонимизировать пользовательские и tenant identifiers; не считать обычный хеш гарантией анонимности.
6. Записывать факт применения redaction policy и её версию.
7. Разделять retention для метаданных, очищенного контента и incident samples.
8. Ограничивать доступ к trace content строже, чем к агрегированным метрикам.

Интерпретация: observability backend становится хранилищем производственных данных, даже если команда воспринимает его как технический инструмент. Поэтому экспорт, резервное хранение, поиск, eval datasets и ручная разметка должны входить в единый data-flow review.

Ограничение: агрессивная очистка уменьшает диагностическую ценность. Решение — не включать всё, а заранее определить минимальные признаки, которые позволяют воспроизвести класс ошибки: версии, категории, размеры, идентификаторы схем и безопасные outcome codes.

Sampling и репрезентативность

OpenTelemetry описывает head и tail sampling. При head sampling решение принимается до того, как известен полный исход trace. Tail sampling использует завершённую или накопленную информацию, но требует соответствующего pipeline и не отменяет ресурсных ограничений.

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

Практически стоит разделить три потока:

• Базовая вероятностная выборка — для оценки распределения, latency, usage и качества.
• Условная выборка — для ошибок, необычно длинных traces, повторов и других заранее определённых сигналов.
• Защищённая incident-выборка — ограниченный набор для расследования с отдельными доступом и retention.

Для каждой записи или агрегата нужно знать sampling policy и вероятность включения. Иначе сравнение двух версий агента может отражать изменение выборки, а не поведения. Если evaluator запускается только на части traces, знаменатель должен быть eligible sampled traces, а не весь трафик без оговорки.

Как проверять репрезентативность: сравнивать sampled и unsampled агрегаты по безопасным признакам, доступным до отбора: тип задачи, версия deployment, класс клиента, статус и диапазон длительности. Большое расхождение — сигнал пересмотреть policy, а не автоматически «исправить» score коэффициентом.

Версионирование prompts и evaluators

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

• Prompt template ID, версия и безопасный fingerprint вместо обязательного полного текста.
• Версия agent workflow и конфигурации deployment.
• Идентификатор модели и релевантная версия конфигурации, если эти сведения доступны.
• Tool schema version и версия адаптера инструмента.
• Версия retrieval-конфигурации и корпуса, если retrieval участвует в задаче.
• Evaluator name, version, rubric version, threshold policy и dataset version.
• Semantic schema, instrumentation scope name и scope version.

Evaluator — такой же изменяемый программный компонент, как агент. Новый score нельзя напрямую сравнивать со старым, если изменились rubric, входные данные или порог. Для миграции полезен период двойного расчёта: старая и новая версии оценивают один и тот же безопасный набор traces, а различия анализируются до переключения.

Редакционная рекомендация: не перезаписывать исторические оценки. Новая версия evaluator должна создавать новый результат, связанный с тем же target span или trace. Это сохраняет аудит и позволяет пересчитать решения без потери исходных наблюдений.

Как проверять telemetry contract

Контракт нужно тестировать как API. Валидация только на уровне «endpoint принял OTLP» обнаруживает транспортную проблему, но не семантическую потерю.

1. Создать набор golden traces с заранее известным деревом spans.
2. Проверить продолжение W3C trace context через все сервисные границы.
3. Убедиться, что асинхронные ветви имеют parent или осмысленный link.
4. Сопоставить фактические scope name и version с ожидаемыми reader.
5. Проверить обязательные message/tool attributes без требования полного сырого контента.
6. Сравнить число реальных tool calls с числом соответствующих spans.
7. Проверить поведение при ошибке, отмене, timeout и повторе без публикации опасных payloads.
8. Запустить privacy scan и убедиться, что запрещённые классы данных удалены до экспорта.
9. Проверить, что backend различает версии prompt, schema и evaluator.
10. Выполнить offline eval на известном наборе и сверить target-связи и знаменатели.
11. Смоделировать sampling policy и проверить сохранение редких классов.
12. Повторить тест после обновления instrumentation library или semantic schema.

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

Практическая схема внедрения

Шаг 1. Определить границу задачи

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

Шаг 2. Составить эталонное дерево

Нарисуйте spans для нормального пути, ошибки инструмента и повторного планирования. Используйте agent conventions как основу, но не создавайте операций, которых нет в архитектуре.

Шаг 3. Зафиксировать семантический профиль

Выберите версии OpenTelemetry GenAI conventions, OpenInference-полей или собственного расширения. Составьте mapping и запретите неявное смешение одинаковых названий с разным смыслом.

Шаг 4. Спроектировать безопасный payload

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

Шаг 5. Провести контекст через систему

Проверьте межсервисное распространение W3C Trace Context и отдельно обработайте очереди, фоновые jobs и fan-out. Потерянный контекст нельзя надёжно восстановить по времени и похожим именам.

Шаг 6. Добавить eval layer

Начните с offline dataset и версионируемых evaluator. Затем добавьте асинхронные online evals на репрезентативной выборке. Синхронную оценку используйте только там, где её задержка и отказоустойчивость сознательно приняты.

Шаг 7. Ввести sampling и контроль покрытия

Разделите базовую и условную выборки, публикуйте eval coverage и следите за изменением состава sampled traces. Без этого график качества нельзя интерпретировать.

Шаг 8. Сделать контракт частью релиза

Любое изменение prompt, tool schema, evaluator, instrumentation scope или semantic schema должно проходить contract tests. Обновление observability-компонента способно изменить метрику без изменения агента — это нужно видеть в истории deployment.

Чек-лист production readiness

1. Граница trace для каждой категории задач определена и задокументирована.
2. W3C Trace Context сохраняется на синхронных и асинхронных переходах.
3. Agent, workflow, plan и tool operations представлены отдельными spans там, где они реально существуют.
4. Для каждого span определены владелец, смысл, обязательные атрибуты и допустимая кардинальность.
5. Semantic schema, instrumentation scope и версии библиотек фиксируются в telemetry.
6. Tool name и schema version доступны без обязательного экспорта полных arguments.
7. Prompts, responses, retrieved documents и tool payloads собираются только по opt-in policy.
8. Secrets и запрещённые PII удаляются до экспорта, а версия redaction policy записывается.
9. Retention разделён для метаданных, очищенного контента, eval datasets и incident traces.
10. Golden traces проверяют успешный путь, отказ, повтор, асинхронную ветвь и неполный контент.
11. OTLP-приём проверяется отдельно от распознавания AI-семантики downstream-системой.
12. Offline dataset имеет версию, происхождение и правила включения примеров.
13. Evaluator хранит name, version, rubric, target, score и threshold policy.
14. Online eval coverage публикуется вместе с показателями качества.
15. Sampling policy и вероятность включения доступны для интерпретации агрегатов.
16. Метрики стоимости помечены как оценки и связаны с версией расчёта.
17. Изменение schema, scope, prompt или evaluator блокирует релиз при провале contract tests.
18. Доступ к сырым traces ограничен сильнее, чем доступ к агрегированным дашбордам.

Ограничения

• Зрелость стандарта. OpenTelemetry GenAI conventions имеют статус Development. Поля и рекомендации могут измениться, поэтому текущая реализация требует версионирования и миграционных тестов.
• OTLP не гарантирует смысл. Валидный trace может быть семантически недостаточным для reader или evaluator.
• Заявление поставщика не равно независимой проверке. Поддержку нескольких frameworks в AgentCore Evaluations следует подтверждать на собственных traces.
• Evals не являются объективной истиной. Они зависят от rubric, входных данных, evaluator, порога и покрытия.
• Sampling создаёт смещение. Особенно если сохраняются только ошибки, длинные traces или случаи, уже отмеченные другим evaluator.
• Redaction уменьшает диагностическую полноту. Однако это не основание экспортировать весь production content без ограничений.
• Не вся причинность помещается в дерево. Асинхронные workflow, fan-out и повторная обработка требуют links и ясных правил корреляции.
• Стоимость приблизительна. Usage может быть неполным, а внешние операции — неучтёнными.

Что нас ждёт

Ниже — редакционный прогноз, а не объявленная дорожная карта стандартов или компаний.

По мере развития GenAI conventions главным полем конкуренции станет не доставка OTLP, а качество semantic mapping. Инструменты будут всё чаще проверять scope, версии схем и полноту agent/tool/evaluator spans до того, как данные попадут в дашборд.

Вторая тенденция — сближение observability и evaluation. Trace станет не только объектом диагностики, но и входом для regression datasets, online quality monitoring и анализа стоимости. При этом автоматическое действие по score потребует более строгого контроля evaluator, чем обычный информационный график.

Третья тенденция — минимизация сырого контента. Чем больше traces используется для evals, тем выше цена ошибочного экспорта. Практичнее развивать структурированные outcome attributes, версии, безопасные fingerprints и выборочное раскрытие, чем превращать observability-хранилище в полную копию пользовательских диалогов.

Наконец, переносимость будет проверяться тестами, а не декларациями. Команды, которые заранее отделят OTLP transport от AI-семантики и зафиксируют telemetry contract, смогут менять instrumentation и readers с меньшим риском тихой потери данных.

FAQ

Достаточно ли экспортировать traces по OTLP?

Нет. OTLP обеспечивает транспортную совместимость, но принимающей системе нужны ожидаемые AI spans, instrumentation scope и attributes. Успешная доставка не доказывает семантическую совместимость.

Нужно ли сохранять полные prompts для observability?

Нет. По умолчанию лучше собирать структурированные метаданные, версии и безопасные признаки. Полный контент допустим только по opt-in policy, после redaction и с отдельным retention.

Что считать одним trace агента?

Одну явно определённую бизнес-задачу или workflow. Граница может совпадать с запросом, но для длительных и асинхронных процессов её нужно задавать отдельно.

Действительно ли AgentCore Evaluations не зависит от фреймворка?

AWS заявляет поддержку нескольких frameworks, но reader зависит от узнаваемого instrumentation scope и необходимых message/tool attributes. Независимость условна и требует contract test.

Чем OpenInference отличается от OpenTelemetry?

OpenTelemetry и OTLP дают общую модель и переносимость telemetry, а OpenInference добавляет AI-специфичную семантику для LLM, tools, retrievers и evaluators поверх OTLP.

Чем online eval отличается от offline eval?

Offline eval работает на зафиксированном наборе для сравнений и регрессий. Online eval оценивает production traces или их выборку и лучше отражает текущий поток, но зависит от sampling и покрытия.

Можно ли оценивать качество только на sampled traces?

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

Как понять, что telemetry contract работает?

Прогнать golden traces и проверить дерево spans, context propagation, scope, обязательные attributes, redaction, sampling, распознавание downstream-reader и связь eval с правильной целью.

Источники

1. Evaluate any agent framework with Amazon Bedrock AgentCore Evaluations — подтверждает заявление AWS о поддержке нескольких agent frameworks и требования telemetry reader к instrumentation scope и message/tool attributes.
2. OpenTelemetry GenAI Semantic Conventions repository — подтверждает отдельный репозиторий, статус Development и schema URL gen-ai/1.42.0.
3. Semantic conventions for generative AI systems — подтверждает карту GenAI-сигналов и областей semantic conventions.
4. GenAI agent and framework spans — подтверждает agent spans create_agent, invoke_agent, invoke_workflow, plan и execute_tool.
5. OpenInference Specification — подтверждает OTLP-совместимость OpenInference и наличие AI span kinds.
6. OpenInference Semantic Conventions — подтверждает семантику атрибутов для LLM, tools, retrievers и evaluators.
7. W3C Trace Context — подтверждает стандарт межсервисного распространения trace context.
8. OpenTelemetry Security Guidelines — подтверждает необходимость учитывать угрозы и безопасную эксплуатацию telemetry.
9. OpenTelemetry Sampling — подтверждает модели head и tail sampling и необходимость учитывать ограничения выборки.