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

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

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

1. Термин: Agentic RAG

Agentic RAG — это расширение классического RAG, где LLM-агент не просто генерирует ответ на основе найденных документов, а активно управляет процессом: решает, какие инструменты (retrieval, калькулятор, API, база знаний) вызывать, в каком порядке, анализирует промежуточные результаты и при необходимости повторяет шаги. Агент может выполнять multi-step reasoning и tool use.

Ключевые компоненты RAG|Agentic RAG

• LLM (планировщик) — принимает решения о следующем действии.
• Набор инструментов (tools) — retrieval, веб-поиск, код-интерпретатор, внешние API.
• Память (memory) — контекст предыдущих шагов.
• Цикл (loop) — агент повторяет шаги, пока не достигнет цели или не превысит лимит.

Пример сценария Пользователь спрашивает: «Какая средняя температура на Марсе в градусах Цельсия и как она соотносится с земной?» Агент должен:

1. Вызвать инструмент retrieval для поиска фактов о Марсе.
2. Вызвать инструмент калькулятор для перевода (если данные в Фаренгейтах).
3. Вызвать инструмент retrieval для данных о Земле.
4. Сгенерировать итоговый ответ.

2. Проблема token-level оценки для Agentic RAG

Token-level evaluation (оценка на уровне токенов) — традиционный подход, при котором сравнивается сгенерированный текст с эталонным ответом по точности токенов (exact match, BLEU, ROUGE, F1). Для простых RAG-систем это может работать, но для Agentic RAG есть фундаментальные недостатки:

• Игнорирование процесса: Token-level метрики смотрят только на финальный ответ. Если агент получил правильный ответ, но сделал лишние шаги (например, дважды вызвал retrieval без необходимости), метрика не покажет проблему.
• Нечувствительность к неверным инструментам: Агент может вызвать неправильный инструмент (например, калькулятор вместо retrieval), но случайно получить верный ответ — token-level accuracy будет высокой, хотя поведение агента ошибочно.
• Проблема длинных горизонтов (long horizon): Чем больше шагов делает агент, тем выше вероятность, что token-level метрика не заметит ошибку на промежуточном шаге, если финальный ответ корректен.
• Отсутствие объяснимости: Token-level метрика не говорит, почему ответ правильный или неправильный — из-за плохого планирования или из-за ошибки генерации.

Пример:

• Эталонный путь: retrieval → калькулятор → ответ.
• Путь агента A: retrieval → retrieval → калькулятор → ответ (лишний retrieval).
• Путь агента B: retrieval → веб-поиск → калькулятор → ответ (неправильный инструмент, но ответ верный).
• Token-level accuracy для обоих агентов может быть 100% (если финальный ответ совпадает с эталоном), но path-level оценка покажет, что оба пути неоптимальны.

3. Что такое Path-level evaluation

Path-level evaluation — это оценка траектории (trajectory) действий агента, а не только финального текста. Траектория — это последовательность пар (инструмент, аргументы, результат). Оценка включает:

• Корректность выбора инструмента: Правильный ли инструмент был вызван на каждом шаге?
• Корректность аргументов: Правильные ли параметры переданы инструменту?
• Порядок шагов: Соответствует ли последовательность шагов ожидаемой логике?
• Эффективность: Минимально ли количество шагов для достижения цели?
• Достижение цели: Достиг ли агент конечной цели (например, ответил на вопрос)?

Метрики path-level

Пример расчёта Tool Accuracy

• Эталонная последовательность инструментов: retrieval, calculator, response]
• Фактическая последовательность: retrieval, retrieval, calculator, response]
• Шаги: 1 (retrieval) – верно, 2 (retrieval) – неверно (должен быть calculator), 3 (calculator) – верно, 4 (response) – верно.
• Tool Accuracy = 3 / 4 = 0.75.

4. Чем Path-level лучше Token-level

Ключевое преимущество Path-level Оно позволяет диагностировать конкретные проблемы в поведении агента. Например, если Tool Accuracy низкая — нужно улучшать выбор инструментов (дообучать LLM или менять промпт). Если Step Order Accuracy низкая — проблема в планировании последовательности. Token-level метрика не даёт такой информации.

5. Как собирать данные для Path-level evaluation

Для path-level оценки нужны эталонные траектории (gold trajectories). Способы получения:

1. Ручная разметка: Эксперты создают для каждого запроса идеальный путь (инструменты, аргументы, порядок). Дорого, но качественно.
2. Автоматическая генерация с помощью сильного LLM: Использовать GPT-4 или Claude для генерации эталонного пути на основе запроса и известных инструментов. Затем валидировать вручную.
3. Использование логов успешных сессий: Если система уже работает, можно взять траектории, которые привели к правильному ответу (по token-level метрике), и считать их эталонными. Риск: они могут быть неоптимальными.
4. Синтетические датасеты: Создать запросы, для которых известен точный алгоритм (например, математические задачи с фиксированными шагами).

Формат хранения траектории (JSON):

{
  "query": "Какая средняя температура на Марсе в °C?",
  "gold_trajectory": [
    {"tool": "retrieval", "arguments": {"query": "средняя температура Марса"}},
    {"tool": "calculator", "arguments": {"expression": "x * 1.8 + 32"}},
    {"tool": "response", "arguments": {}}
  ],
  "agent_trajectory": [
    {"tool": "retrieval", "arguments": {"query": "температура Марса"}},
    {"tool": "retrieval", "arguments": {"query": "Марс температура"}},
    {"tool": "calculator", "arguments": {"expression": "x * 1.8 + 32"}},
    {"tool": "response", "arguments": {}}
  ]
}

6. Метрики Path-level: детальный разбор

6.1 Tool Accuracy (TA)

• Формула: TA = (число шагов с верным инструментом) / (общее число шагов)
• Интерпретация: Если TA < 0.8, агент часто выбирает не те инструменты. Нужно улучшать промпт или fine-tuning.
• Нюанс: Если агент сделал лишний шаг, он всё равно считается неверным (инструмент не соответствует эталону на этой позиции). Можно использовать soft matching: если инструмент верный, но не на той позиции — частичный балл.

6.2 Argument Accuracy (AA)

• Формула: AA = (число шагов с верными аргументами) / (общее число шагов)
• Сравнение аргументов: Для каждого аргумента можно считать точное совпадение (exact match) или семантическую близость (cosine similarity эмбеддингов).
• Пример: Инструмент retrieval с аргументом query="Марс" vs query="планета Марс" — семантически близко, можно считать верным.

6.3 Step Order Accuracy (SOA)

• Идея: Сравнить последовательность инструментов как строки. Использовать редакционное расстояние (Levenshtein distance).
• Формула: SOA = 1 - (lev_distance(gold_seq, agent_seq) / max(len(gold), len(agent)))
• Пример: gold = [R, C, Rsp], agent = [R, R, C, Rsp]. lev_distance = 1 (вставка лишнего R). max_len = 4. SOA = 1 - 1/4 = 0.75.

6.4 Path Efficiency (PE)

• Формула: PE = min_steps / actual_steps
• Интерпретация: Если PE < 0.5, агент делает в два раза больше шагов, чем нужно. Это может быть из-за неопределённости или плохого планирования.
• Ограничение: Не учитывает качество шагов — только количество.

6.5 Goal Success Rate (GSR)

• Бинарная метрика: 1, если агент достиг цели (например, ответил на вопрос), 0 иначе.
• Как определить успех: Можно использовать LLM-as-judge для проверки, что ответ корректен, или сравнение с эталонным ответом (token-level). Но для path-level GSR — это лишь часть оценки.

6.6 Composite Score

• Пример: Composite = 0.3*TA + 0.3*AA + 0.2*SOA + 0.2*PE
• Настройка весов: Зависит от приоритетов. Если важна точность инструментов — увеличить вес TA. Если важна скорость — вес PE.

7. Реализация Path-level evaluation на Python

import [json](/wiki/JSON)
from typing import List, Dict

def tool_accuracy(gold: List[Dict], [agent](/wiki/agent): List[Dict]) -> float:
    """Доля шагов, где инструмент совпадает с эталоном на той же позиции."""
    correct = 0
    for i, (g, a) in enumerate(zip(gold, [agent](/wiki/agent))):
        if g['[tool](/wiki/Tool)'] == a['[tool](/wiki/Tool)']:
            correct += 1
    # Если [agent](/wiki/agent) длиннее gold, лишние шаги считаются неверными
    # Если gold длиннее [agent](/wiki/agent), недостающие шаги считаются неверными
    max_len = max(len(gold), len([agent](/wiki/agent)))
    return correct / max_len if max_len > 0 else 0.0

def argument_accuracy(gold: List[Dict], [agent](/wiki/agent): List[Dict]) -> float:
    """Доля шагов, где аргументы совпадают (exact match)."""
    correct = 0
    for i, (g, a) in enumerate(zip(gold, [agent](/wiki/agent))):
        if g['[tool](/wiki/Tool)'] == a['[tool](/wiki/Tool)'] and g.get('arguments') == a.get('arguments'):
            correct += 1
    max_len = max(len(gold), len([agent](/wiki/agent)))
    return correct / max_len if max_len > 0 else 0.0

def levenshtein_distance(seq1: List[str], seq2: List[str]) -> int:
    """Расстояние Левенштейна между последовательностями инструментов."""
    n, m = len(seq1), len(seq2)
    dp = [500](/answers/500)

---


## Навигация
- Предыдущий: [500](/answers/500)
- Следующий: [502](/answers/502)
- Индекс: [00. Индекс разборов](/answers)