Какие failure modes уникальны для multi-agent систем (vs single agent)?

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

Multi-agent системы (MAS) в RAG — это архитектура, где несколько AI-агентов (например, ретривер, суммаризатор, верификатор) координируются для выполнения сложной задачи. В отличие от single agent, где вся логика в одном LLM, в MAS возникают специфические отказы: information loss (потеря информации при передаче между агентами), goal divergence (расхождение целей), communication overhead explosion (взрывной рост числа сообщений) и blame attribution problem (проблема определения виновного в ошибке). Понимание этих режимов отказа критично для проектирования надёжных агентных RAG-систем.

1. Терминология: single agent vs multi-agent

Single agent — одна LLM, которая самостоятельно выполняет все шаги (retrieval, reasoning, generation). Multi-agent — несколько специализированных агентов, каждый со своей ролью (например, Planner, Retriever, Critic), обменивающихся сообщениями.

2. Information loss между агентами

Information loss — потеря или искажение критических данных при передаче от одного агента к другому. Это может происходить из-за:

• Ограничения контекста каждого агента (агент А не помещает всю информацию в сообщение).
• Семантического сжатия (агент А суммаризирует, теряя детали).
• Ошибок сериализации (JSON с потерянными полями).

Пример: Агент-ретривер нашёл 10 документов, но передаёт только 3 лучших (потеря контекста). Агент-генератор не видит релевантный документ №7 → ответ неполный.

Формула вероятности потери

P(loss) = 1 - ∏_{i=1}^{n} (1 - p_i)

где p_i — вероятность потери на каждом шаге передачи. Если 5 шагов с p=0.1, то P(loss) ≈ 0.41 — почти 40% отказов.

Смягчение использование checkpointing (сохранение полного контекста в общей памяти), structured messages (обязательные поля), redundancy (дублирование ключевой информации).

3. Goal divergence

Goal divergence — ситуация, когда агенты оптимизируют разные прокси-цели (proxy goals), что приводит к конфликту или неоптимальному общему результату.

Пример: В RAG-системе:

• Retriever оптимизирует recall@k (найти как можно больше документов).
• Generator оптимизирует краткость ответа.
• Critic оптимизирует безопасность (отсекает «опасные» фразы).

Результат: Retriever передаёт 50 документов, Generator не может уместить их в контекст, Critic блокирует половину — ответ пустой.

Причина отсутствие единой глобальной функции полезности (global utility function). Каждый агент видит только свою локальную метрику.

Способы борьбы

• Общая награда (shared reward) — все агенты штрафуются, если конечный ответ плох.
• Иерархический контроль — супервайзер (supervisor agent) корректирует цели.
• Конституционные ограничения (constitutional AI) — фиксированные правила, которым следуют все.

4. Communication overhead explosion

Communication overhead explosion — квадратичный рост числа сообщений при увеличении числа агентов. В полносвязной топологии каждый агент общается с каждым: число сообщений = O(n²).

Формула

Messages(n) = n * (n-1) / 2   (для двусторонней связи)

Пример кода симуляции

import time

def simulate_overhead(n_agents, latency_per_msg=0.1):
    messages = n_agents * (n_agents - 1) // 2
    total_time = messages * latency_per_msg
    return messages, total_time

for n in [2, 5, 10, 20]:
    msgs, t = simulate_overhead(n)
    print(f"Агентов: {n}, сообщений: {msgs}, время: {t:.1f}с")

Смягчение

• Иерархическая топология (агенты общаются только с супервайзером) → O(n).
• Асинхронная очередь (message broker) — агенты не ждут ответа синхронно.
• Фильтрация сообщений — агент отправляет только изменения (delta).

5. Blame attribution problem

Blame attribution problem — невозможность определить, какой агент вызвал ошибку на последнем шаге, когда отказ проявился только в финальном ответе.

Пример: Пользователь получил неверный ответ. Причина может быть:

• Ретривер вернул нерелевантные документы.
• Генератор проигнорировал правильные документы.
• Критик ошибочно заблокировал правильный ответ.
• Планнер выбрал неверную последовательность действий.

Проблема в multi-agent системе ошибка может накапливаться и проявляться только в конце. Без трассировки (tracing) каждого шага невозможно локализовать источник.

Методы решения

• Логирование всех сообщений с уникальными ID (OpenTelemetry, LangSmith).
• Counterfactual analysis — перезапуск системы с заменой одного агента на «идеальный» (например, oracle retriever) и сравнение результатов.
• Gradient-based attribution (для differentiable агентов) — обратное распространение ошибки через граф вычислений.

6. Дополнительные failure modes

6.1 Coordination deadlock

Агенты ждут друг друга в цикле: А ждёт B, B ждёт C, C ждёт A. Возникает при неправильной топологии или отсутствии timeout'ов.

6.2 Resource contention

Несколько агентов одновременно пытаются использовать один ресурс (например, векторную БД или GPU). Приводит к деградации производительности.

6.3 Security & adversarial attacks

Злоумышленник может внедрить вредоносное сообщение в канал связи между агентами (man-in-the-middle). Single agent менее уязвим, так как нет внешних коммуникаций.

6.4 Semantic drift

Агенты начинают использовать разные термины для одних и тех же понятий (например, один называет «документ», другой — «чанк»). Со временем согласованность падает.

7. Сравнение failure modes: single agent vs multi-agent

8. Стратегии предотвращения и мониторинга

8.1 Проектирование протокола

• Использовать структурированные сообщения (Pydantic модели) с обязательными полями.
• Ввести контракты (interfaces) для каждого агента: что он должен принимать и возвращать.

8.2 Мониторинг в рантайме

• Dashboard с метриками: количество сообщений, latency, error rate.
• Alerting при превышении порога overhead (например, >100 сообщений за запрос).

8.3 Тестирование

• Unit-тесты для каждого агента изолированно.
• Integration-тесты с mock-агентами, симулирующими failure modes.
• Chaos engineering — случайное внесение задержек, потери сообщений, проверка устойчивости.

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

Задача Разработать multi-agent RAG-систему для ответов на вопросы по документации, которая устойчива к information loss и communication overhead.

Инструменты

• Python, LangGraph (или CrewAI) для оркестрации.
• ChromaDB / FAISS для векторного поиска.
• LLM: OpenAI API или локальная модель (например, Llama 3).
• Мониторинг: Weights & Biases или MLflow.

Шаги:

1. Реализовать трёх агентов: Retriever, Generator, Validator.
2. Добавить супервайзера (Supervisor), который координирует их через очередь сообщений (RabbitMQ или Redis).
3. Ввести checkpointing: каждый агент сохраняет свой контекст в общую базу (SQLite).
4. Создать симулятор отказов: с вероятностью 10% агент «забывает» передать часть данных.
5. Написать тест, который запускает 100 запросов и измеряет:
   • Долю успешных ответов (сравнение с эталоном).
   • Среднее число сообщений на запрос.
   • Время выполнения.
6. Сравнить с single agent (один LLM с тем же контекстом).

Ожидаемый результат Вы получите систему, которая при наличии отказов выдаёт не более 5% неполных ответов (против 30% без checkpointing), а overhead не превышает O(n) благодаря супервайзеру.

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

11. Навигация

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

Навигация

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