Что такое Path-level evaluation для Agentic RAG и чем оно лучше token-level?

Краткий тезис

Path-level evaluation — это подход к оценке Agentic RAG-систем, при котором анализируется не каждый токен ответа, а траектория (path) действий агента: какие инструменты были вызваны, в каком порядке, с какими аргументами, и достиг ли агент цели оптимальным маршрутом. В отличие от token-level evaluation, где оценивается точность каждого токена сгенерированного текста, path-level фокусируется на правильности процесса, а не только на финальном ответе. Это позволяет выявлять неэффективные или избыточные шаги, даже если итоговый ответ верен, и даёт более содержательную обратную связь для улучшения агента.

1. Контекст: Agentic RAG и необходимость новой оценки

Agentic RAG — это эволюция классического RAG, где система не просто ищет документы и генерирует ответ, а действует как агент: может вызывать несколько инструментов (поиск, калькулятор, API), принимать решения о следующем шаге, перепланировать маршрут. Пример: пользователь спрашивает «Какая средняя зарплата Python-разработчика в Берлине с учётом налогов?» Агент может: 1) найти медианную зарплату через поиск, 2) найти ставку налога для Берлина, 3) вычислить чистую сумму через калькулятор, 4) сгенерировать ответ.

Традиционные метрики (ROUGE, BLEU, BERTScore) оценивают токен-уровень: насколько сгенерированный текст совпадает с эталонным. Но для агента это неадекватно: агент может дать правильный ответ, но сделать это неоптимальным путём (например, вызвать 5 поисков вместо 2). И наоборот — может дать неверный ответ, но его траектория была разумной, а ошибка произошла из-за плохого источника. Поэтому требуется path-level evaluation.

2. Token-level evaluation: что это и её ограничения

Token-level evaluation — это классические метрики, сравнивающие сгенерированный текст с эталонным на уровне токенов (слов, субслов). Примеры:

• ROUGE-L — оценивает длиннейшую общую подпоследовательность.
• BLEU — n-gram precision с штрафом за длину.
• BERTScore — попарное косинусное сходство эмбеддингов токенов.

Проблемы для Agentic RAG:

1. Игнорирование процесса: два агента могут выдать одинаковый текст, но один сделал 2 вызова, другой — 10. Token-level не заметит разницы.
2. Нечувствительность к инструментам: если агент использовал не тот инструмент, но текст получился похожим, метрика может показать высокое качество.
3. Зависимость от эталона: для агентов часто нет единственного «правильного» текста — ответ может быть сформулирован по-разному.
4. Отсутствие диагностики: низкий BLEU не говорит, что именно пошло не так — плохой поиск, неверный вызов или ошибка генерации.

3. Path-level evaluation: определение и ключевые метрики

Path-level evaluation оценивает траекторию (path) агента — последовательность вызовов инструментов с аргументами и результатами. Основные компоненты:

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

Метрики path-level:

• Path Accuracy — доля шагов, совпадающих с эталонной траекторией (с учётом порядка).
• Tool Selection Accuracy — правильно ли выбран инструмент на каждом шаге.
• Argument Precision/Recall — насколько точно переданы аргументы (например, правильный запрос к поиску).
• Path Efficiency — отношение длины оптимального пути к длине фактического (чем ближе к 1, тем лучше).
• Goal Completion Rate — достиг ли агент конечной цели (бинарная метрика).

Пример эталонной траектории для запроса «Какая средняя зарплата Python-разработчика в Берлине с учётом налогов?»:

1. search(query="средняя зарплата python разработчик берлин 2024")
2. extract_salary(result) → 65000 EUR
3. search(query="налог на доход в германии берлин 2024")
4. extract_tax_rate(result) → 0.35
5. calculate(net = 65000 * (1 - 0.35)) → 42250 EUR
6. generate_answer("Чистая зарплата: 42250 EUR")

Фактическая траектория агента может отличаться: например, он может сделать два поиска вместо одного, или вызвать калькулятор до получения налога. Path-level метрики покажут эти расхождения.

4. Сравнение token-level и path-level evaluation

Почему path-level лучше:

• Прозрачность: можно точно сказать, на каком шаге агент ошибся.
• Обратная связь для улучшения: если агент часто выбирает неправильный инструмент, нужно улучшать промпт или fine-tuning.
• Робастность к формулировкам: неважно, как именно сформулирован ответ, важен маршрут.
• Эффективность: выявляются лишние вызовы, что критично для стоимости (каждый вызов LLM или API стоит денег).

5. Как реализовать path-level evaluation на практике

Инструменты:

• LangSmith / LangFuse — платформы для трассировки агентов, автоматически записывают шаги.
• Собственный evaluator на Python с использованием Pydantic для валидации траектории.

Общий подход:

1. Собрать траектории — логировать каждый вызов инструмента: имя, входные параметры, выход, время.
2. Определить эталонные траектории — вручную или с помощью LLM-as-a-judge (попросить LLM сгенерировать идеальный план).
3. Сравнить фактическую и эталонную траектории — через алгоритмы выравнивания (например, модифицированное расстояние Левенштейна для последовательностей шагов).
4. Агрегировать метрики по набору тестовых запросов.

Пример кода (упрощённый):

from typing import List, Dict
from dataclasses import dataclass

@dataclass
class Step:
    tool: str
    arguments: Dict[str, str]
    result: str

@dataclass
class Trajectory:
    steps: List[Step]
    final_answer: str

def path_accuracy(actual: Trajectory, expected: Trajectory) -> float:
    """Доля шагов, совпадающих по инструменту и аргументам (порядок важен)."""
    if not expected.steps:
        return 1.0 if not actual.steps else 0.0
    matches = 0
    for a_step, e_step in zip(actual.steps, expected.steps):
        if (a_step.tool == e_step.tool and 
            a_step.arguments == e_step.arguments):
            matches += 1
    return matches / len(expected.steps)

# Пример использования
expected = Trajectory(steps=[
    Step("search", {"query": "средняя зарплата python берлин"}, "65000"),
    Step("calculate", {"expression": "65000*0.65"}, "42250")
], final_answer="42250")

actual = Trajectory(steps=[
    Step("search", {"query": "зарплата python берлин"}, "65000"),
    Step("search", {"query": "налог германия"}, "0.35"),
    Step("calculate", {"expression": "65000*0.65"}, "42250")
], final_answer="42250")

print(path_accuracy(actual, expected))  # 0.5 (первый шаг совпал частично, второй не совпал)

Более продвинутые метрики могут учитывать частичное совпадение аргументов (через семантическое сходство) и допускать перестановки шагов, если они логически эквивалентны.

6. Преимущества path-level evaluation (детально)

1. Выявление неоптимальности: агент может достичь цели, но сделать лишние шаги. Token-level этого не покажет. Path-level даёт метрику Path Efficiency.
2. Улучшение промптов и fine-tuning: зная, на каком шаге агент ошибается (выбор инструмента, аргументы), можно точечно корректировать.
3. Контроль стоимости: каждый лишний вызов LLM или API увеличивает затраты. Path-level позволяет оптимизировать количество шагов.
4. Безопасность: если агент вызывает опасные инструменты (например, удаление файлов) не в том порядке, path-level это зафиксирует.
5. Интерпретируемость для бизнеса: менеджеры могут видеть не просто «качество 0.85», а «агент в 30% случаев использует поиск вместо калькулятора».

7. Ограничения и вызовы path-level evaluation

• Сложность создания эталонов: для каждого запроса нужно вручную или автоматически строить «идеальный» путь. Автоматизация через LLM-as-a-judge может внести свои ошибки.
• Неоднозначность: один и тот же результат может быть достигнут разными корректными путями. Нужны метрики, допускающие эквивалентные траектории.
• Затраты на логирование: требуется инфраструктура для сбора траекторий (LangSmith, OpenTelemetry).
• Чувствительность к деталям: если агент использует разные формулировки запроса, но семантически одинаковые, строгое сравнение аргументов может дать ложное расхождение. Нужны семантические метрики.

8. Пет-проект для закрепления

Задача: Реализовать простой Agentic RAG (агент с двумя инструментами: поиск и калькулятор) и написать evaluator, который сравнивает траектории на path-level.

Инструменты: Python, LangChain (или просто OpenAI API), Pydantic, pytest.

Шаги:

1. Создать агента, который на запросы вида «сколько будет X плюс Y?» вызывает калькулятор, а на «какая столица Франции?» — поиск (имитация).
2. Подготовить 10 тестовых запросов с эталонными траекториями (вручную).
3. Запустить агента, записать фактические траектории.
4. Написать функцию path_accuracy с учётом нечёткого сравнения аргументов (через эмбеддинги).
5. Вычислить метрики для каждого запроса и среднее.
6. Намеренно добавить ошибку в агента (например, заставить его всегда сначала вызывать поиск, потом калькулятор) и показать, что path-level метрика упала, хотя token-level (BLEU) может остаться высоким.

Ожидаемый результат: Вы получите численное подтверждение, что path-level evaluation чувствительнее к изменениям в логике агента, и сможете объяснить это на собеседовании.

9. Связь с другими вопросами

10. Навигация

• Предыдущий: 134
• Следующий: 136
• Индекс: 00. Индекс разборов

Навигация

• Предыдущий: 134
• Следующий: 136
• Индекс: 00. Индекс разборов