Как измерять «коэффициент полезного делегирования» (сколько задач решено правильно)?

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

Коэффициент полезного делегирования (KPD) — это отношение числа правильно решённых задач к общему числу делегированных задач в агентной системе. Он позволяет оценить, насколько эффективно распределяются подзадачи между агентами или между агентом и человеком. Для корректного измерения необходимо учитывать тип делегирования (агент→агент, агент→человек, цепочки), а также задать чёткий критерий «правильно решённой задачи» — обычно это достижение цели при пользовательском фидбеке выше 4/5. KPD > 0,9 считается хорошим для автономного делегирования, > 0,95 — для делегирования человеку.

1. Термин: Делегирование в контексте Agentic RAG

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

• Прямое делегирование (A→B): Агент A отправляет задачу агенту B и ожидает результат.
• Каскадное делегирование (A→B→C): A делегирует B, B при необходимости делегирует C.
• Делегирование человеку (A→Human): Агент запрашивает эксперта или пользователя для выполнения подзадачи.

Коэффициент полезного делегирования (KPD, от «коэффициент полезного действия») — ключевая метрика, показывающая, насколько такие передачи задач эффективны: сколько из них завершились успешным результатом.

2. Зачем нужна метрика KPD?

• Оценка надёжности агента-оркестратора: если KPD низкий, агент плохо выбирает, кому и какие задачи делегировать.
• Баланс автономии и контроля: слишком высокий порог делегирования человеку (низкий KPD автономии) означает, что агент слишком часто перекладывает работу на человека.
• Выявление узких мест: если KPD для конкретного агента-исполнителя низок, его нужно дообучать или заменять.
• Сравнение стратегий: при A/B-тестировании разных алгоритмов делегирования KPD позволяет выбрать лучший.

3. Формула KPD и расшифровка

KPD = (число правильно решённых делегированных задач) / (общее число делегированных задач)

Важно: в знаменателе — все случаи, когда произошло делегирование (не считая отказов или перенаправлений без выполнения). Если задача была делегирована, но не выполнена (например, агент-исполнитель не ответил или ответил ошибкой), она считается нерешённой.

Пример:
Агент A делегировал 100 подзадач агенту B. Из них 85 завершились с результатом, удовлетворяющим критериям правильности.
KPD = 85 / 100 = 0.85 (85%).

4. Определение «правильно решённой задачи»

Задача считается правильно решённой, если выполнены два условия:

1. Достигнута цель подзадачи: результат корректен с точки зрения логики предметной области (например, найден верный ответ в документе, сгенерирован правильный SQL-запрос, получено подтверждение от человека).
2. Пользователь или система-инициатор довольны: обычно это фиксируется через фидбек (оценка от человека или метрика «success» от вышестоящего агента). На практике часто используют шкалу 1–5, и порогом берут >4 (или >=5 для критичных задач).

Нюансы:

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

5. Измерение KPD отдельно по типам делегирования

Одна общая метрика может скрыть проблемы. Рекомендуется декомпозировать KPD по следующим измерениям:

Измеряя KPD для каждого типа, можно понять:

• Какие агенты работают плохо (низкий KPD A→B);
• Насколько агент злоупотребляет помощью человека (низкий KPD A→Human, если делегирование человеку избыточно);
• Склонны ли каскадные цепочки к ошибкам (требуют дополнительного контроля).

6. Целевые пороги и интерпретация

Пороги зависят от критичности области: для финансов или медицины целевой KPD может быть 0.99 и выше. Для экспериментов или развлекательных систем — 0.8–0.9.

7. Сбор данных для расчёта KPD

Чтобы посчитать KPD, нужно логировать каждое событие делегирования:

• ID задачи, ID отправителя, ID получателя.
• Тип делегирования (agent, human, cascade).
• Результат: успех/неудача, фидбек (число от 1 до 5), время выполнения.
• Детали ошибки: если задача не решена — код ошибки или текст.

Формат лога (пример на Python):

delegation_log = [
    {
        "task_id": "t123",
        "from_agent": "router",
        "to_agent": "retriever",
        "type": "A->B",
        "success": True,
        "feedback": 5,   # оценка пользователя
        "timestamp": "2025-04-11T10:00:00"
    },
    # ...
]

По этим логам агрегируется KPD:

def compute_kpd(log, delegation_type=None):
    if delegation_type:
        subset = [e for e in log if e["type"] == delegation_type]
    else:
        subset = log
    total = len(subset)
    correct = sum(1 for e in subset if e["success"] and e["feedback"] > 4)
    return correct / total if total > 0 else 0.0

8. Пример расчёта KPD в реальной системе

Пусть агент-оркестратор за день делегировал задачи:

• Агенту по поиску документов: 50 задач, 45 успешных со средним фидбеком 4.6 → KPD = 0.90
• Агенту по генерации кода: 30 задач, 20 успешных (некоторые с ошибками синтаксиса) → KPD = 0.67 (плохо)
• Человеку: 10 уточнений, 9 успешных → KPD = 0.90

Общий KPD = (45+20+9)/(50+30+10) = 74/90 ≈ 0.822. Это ниже желаемого, и видно, что проблема в агенте-генераторе кода. После дообучения его KPD поднялся до 0.85, общий — до 0.87.

9. Подводные камни и ограничения

• Смещение фидбека: пользователи могут ставить оценки лениво или необъективно. Для внутренних подзадач лучше использовать автоматическую проверку (unit-тесты, валидация схемы).
• Чувствительность к порогу: если взять feedback >3 вместо >4, KPD может резко вырасти. Порог нужно выбирать в соответствии с бизнес-требованиями.
• Проблема «счастливого пути»: KPD не учитывает, насколько сложной была задача. Если все делегированные задачи тривиальны, KPD будет высоким, но это не значит, что агент хорошо работает со сложными случаями.
• Цепочки делегирования: если в цепочке (A→B→C) только последнее звено видит фидбек, а первое — нет, KPD для A→B может быть неинформативен. Нужно логировать success на каждом шаге.
• Отсутствие метрик отказов: KPD не учитывает, сколько задач агент вообще отказался делегировать (оставил себе или передал в fallback). Нужна дополнительная метрика — коэффициент автономии (доля задач, решённых без делегирования).

10. Как улучшать KPD

• Дообучение проблемных агентов: если KPD для конкретного агента низок, нужно улучшить его модель или правила.
• Уточнение критериев делегирования: возможно, агент-оркестратор слишком часто делегирует задачи, которые мог бы решить сам (это снижает эффективность). Установите правила: делегировать только если уверенность < 0.8.
• Каскад с обратной связью: после каждой ступени каскада проверять частичный результат. Если на первом шаге ошибка — не передавать дальше.
• Включение человека в контур: если KPD каскадов стабильно низок, можно добавить checkpoint с валидацией человеком на критических этапах.
• Мониторинг дрейфа: со временем данные или поведение агентов могут меняться. Регулярно (ежедневно/еженедельно) пересчитывайте KPD и сравнивайте с baseline.

11. Связь с другими метриками агентных систем

KPD хорошо дополнять метриками:

• Trust score (доверие к агенту-делегату) — можно усреднять по всем задачам.
• Надёжность (Reliability) — доля задач, выполненных без ошибок (независимо от делегирования).
• Latency — время выполнения делегированной задачи. Долгое выполнение может вызывать неудовлетворённость даже при правильном результате.
• Cost — стоимость делегирования (вызовы LLM, человеко-часы).

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

Задача: Создать дашборд для мониторинга KPD в мультиагентной системе поиска и генерации ответов на основе LangGraph.

Инструменты: Python, LangGraph (для оркестрации агентов), SQLite или MongoDB (для логов), Streamlit (дашборд).

Шаги:

1. Реализуйте двухуровневую систему: один агент-оркестратор, два агента-исполнителя (один ищет документы, другой пишет саммари) + канал делегирования человеку.
2. Во время выполнения логируйте каждое делегирование: отправитель, получатель, тип, success (автоматически проверяйте, содержит ли ответ ключевые слова), фидбек пользователя по окончании.
3. Напишите скрипт, который раз в минуту читает логи и агрегирует KPD по типам.
4. В Streamlit выведите:
   • Общий KPD (большое число).
   • KPD по каждому типу (столбчатая диаграмма).
   • Тренд KPD за последние 24 часа (линейный график).
   • Топ проблемных задач с низким KPD.
5. Установите пороговые цвета: зеленый (>0.9), желтый (0.7-0.9), красный (<0.7).

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

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

Навигация

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