Trajectory evaluation:
оценка последовательности действий

Почему мало финального ответа

Оценка только результата (task completion из урока про offline-метрики) отвечает «дошёл ли агент до цели». Но у агента путь к цели — часть качества, и по одному ответу невидимы целые классы проблем:

• Правильный ответ неправильным путём. Агент угадал итог, но вызвал не тот инструмент, проигнорировал данные, «повезло». В проде на другом входе везение кончится.
• Неэффективность. Тот же результат за 10 шагов вместо 2 — это латентность и деньги, которых в финальном ответе не видно.
• Зацикливание и блуждание. Агент ходит по кругу, повторяет вызовы, «размышляет» вхолостую — и всё же выдаёт ответ.
• Опасные действия. Дошёл до правильного ответа, но по дороге дёрнул инструмент удаления/оплаты, который не следовало.

Что такое траектория

Траектория (trajectory) — это записанная последовательность шагов агента от запроса до ответа: какие инструменты вызваны, с какими аргументами, что вернули, какие узлы графа посещены, сколько итераций. По сути это тот самый трейс из раздела observability, но рассматриваемый как объект оценки, а не отладки.

Оба агента на диаграмме дали верный ответ — outcome-оценка поставила бы обоим «pass». Но траектории кардинально разные: первый эффективен, второй блуждал, дёргал не те инструменты и «угадал». Trajectory evaluation делает эту разницу измеримой.

Сравнение с эталонной траекторией

Базовый подход: задать эталонную траекторию (какие инструменты в каком порядке ожидаются) и сравнить с фактической. Но «сравнить» — не всегда «точно совпасть»: у задачи может быть несколько правильных путей. Отсюда несколько режимов строгости:

# из трейса достаём фактическую последовательность вызванных инструментов
def tool_sequence(trace) -> list[str]:
    return [step.tool for step in trace.steps if step.type == "tool"]

expected = ["search", "summarize"]          # эталонная траектория
actual   = tool_sequence(run_trace)         # напр. ["search", "calc", "summarize"]

def exact_match(exp, act):    return exp == act
def in_order(exp, act):                       # exp — подпоследовательность act
    it = iter(act)
    return all(tool in it for tool in exp)
def any_order(exp, act):      return set(exp) <= set(act)

assert in_order(expected, actual)            # порядок соблюдён, calc — лишний
# для регрессии по траектории: эталон в golden dataset, режим — под задачу

Что оценивать в траектории

Сравнение с эталоном — лишь один аспект. Полная оценка траектории смотрит на несколько измерений:

• Tool selection. Выбраны ли правильные инструменты под задачу? Не вызван ли ненужный (или, хуже, опасный)?
• Аргументы вызовов. Переданы ли инструментам корректные параметры (правильный запрос в поиск, верные поля)?
• Эффективность. Число шагов/итераций, токены, латентность. Достигнут ли результат минимальным разумным путём?
• Отсутствие блужданий. Нет повторов, зацикливаний, «пустых» размышлений, лишних вызовов.
• Безопасность пути. Не дёрнуты действия, которых не следовало (удаление, оплата, запись) — даже если ответ верный.

LLM-судья по траектории

Многое в траектории — детерминированно (какие tools, сколько шагов) и проверяется кодом. Но некоторые вопросы требуют суждения: «разумна ли была эта последовательность?», «оправдан ли лишний вызов?», «логичен ли ход рассуждений?». Здесь — тот же LLM-as-judge, но судящий путь, а не ответ:

TRAJ_JUDGE = """Оцени РАЗУМНОСТЬ последовательности действий агента (не ответ).
Задача: {task}
Траектория (шаги агента):
{trajectory}

Критерий: были ли выбраны уместные инструменты, без лишних/повторных
вызовов, разумным ли путём достигнута цель? Шкала 1–5.
Сначала обоснуй, потом верни JSON {{"reasoning": "...", "score": <1-5>}}"""

def judge_trajectory(task: str, trace) -> dict:
    steps = format_steps(trace)     # человекочитаемый список шагов из трейса
    raw = llm(TRAJ_JUDGE.format(task=task, trajectory=steps), temperature=0)
    return json.loads(raw)

# всё из урока про judge применимо: калибровать по людям, следить за искажениями,
# детерминированное (число шагов, набор tools) — считать КОДОМ, а не судьёй

Типичные ошибки

Шпаргалка

АГЕНТ = вопрос → ЦЕПОЧКА решений → ответ. Оценивай ПУТЬ, не только пункт назначения.
  2 оси: OUTCOME (верный результат?) + TRAJECTORY (верным ли путём?)
  только outcome пропускает: верно-по-случайности · неэффективность · блуждание · опасные действия

ТРАЕКТОРИЯ = записанная последовательность шагов (= трейс как ОБЪЕКТ ОЦЕНКИ):
  какие tools + аргументы · порядок/число шагов · результаты · узлы графа · стоимость пути

СРАВНЕНИЕ С ЭТАЛОНОМ (режимы строгости):
  exact match — ровно те tools, тот порядок (единственно верный путь)
  in-order — ожидаемые по порядку, лишние ок · any-order — набор нужных, порядок не важен
  superset — все обязательные вызваны
  ⚠️ НЕ exact там, где путей несколько → штрафует верные нестандартные, флапает

ЧТО ОЦЕНИВАТЬ: tool selection (те ли tools?) · аргументы · ЭФФЕКТИВНОСТЬ (шаги/токены/latency)
  · отсутствие блужданий/повторов · БЕЗОПАСНОСТЬ пути (не дёрнут опасный вызов)
  эффективность = деньги+латентность, ловит «верно, но дорого» ДО прода

LLM-СУДЬЯ ПО ТРАЕКТОРИИ (для «разумности» пути):
  частный случай LLM-as-judge → калибровать по людям, следить за искажениями, temp=0
  детерминированное (# шагов, набор tools, опасный вызов) — КОДОМ, не судьёй

ГРАБЛИ: только финальный ответ · exact при неск. путях · игнор эффективности · судья вместо кода

Практическое задание

Что дальше

Раздел «Тестирование агентов» закрыт: юниты (компоненты), интеграционные (стыки), датасеты (тест-кейсы) и trajectory (путь) вместе с оценкой качества дают полную защиту агента как программы и как LLM-системы. Но даже идеально протестированный агент в проде встретит то, что не зависит от него: провайдер упадёт, API затаймаутит, придёт лимит. Следующий раздел — «Надёжность и обработка ошибок»: retry, fallback, rate limiting и graceful degradation.