Каскадные ошибки в цепочках агентов: как их гасить

Многоагентные системы на базе больших языковых моделей за 2024–2025 годы перекочевали из демо в продакшн: связки вроде «планировщик → исполнитель → критик» собирают в LangGraph, CrewAI, AutoGen и Microsoft Semantic Kernel. Проблема одна и та же во всех фреймворках: если первый агент ошибся в разборе задачи, второй честно выполнит неправильную задачу, третий отчитается об успехе, а пользователь получит уверенно оформленный неверный результат. Это каскадная ошибка — и она дороже одиночной галлюцинации, потому что её сложнее заметить.

Почему ошибка размножается, а не гаснет

В цепочке агентов¹ выход одного шага становится входом следующего. Модель на промежуточном шаге не знает, что предыдущий агент ошибся: она получает связный, грамматически корректный текст и обрабатывает его как достоверный факт. LLM по своей природе стремится продолжить контекст, а не оспорить его.

Отсюда три механизма, которые превращают одну ошибку в системную:

• Накопление. Если вероятность корректного шага 0,9, то на цепочке из пяти шагов итоговая вероятность безошибочного прохода — около 0,59 (0,9 в пятой степени). Чем длиннее цепь, тем ниже надёжность, даже если каждый агент по отдельности хорош.
• Усиление уверенности. Каждый следующий агент переформулирует данные предыдущего в более уверенном тоне, стирая любые оговорки вроде «возможно» или «предположительно».
• Потеря источника. К концу цепочки уже не видно, откуда взялся конкретный факт — проверить его вручную становится трудно.

Одиночная галлюцинация — это шум. Каскадная ошибка — это шум, который система приняла за сигнал и построила на нём всё остальное.

Где именно рвётся цепь

Разбор задачи (парсинг входа)

Самая дорогая точка отказа — первая. Если планировщик неверно понял намерение пользователя, вся дальнейшая работа корректна технически и бесполезна по сути. Здесь помогает не усложнять модель, а добавить шаг подтверждения: агент возвращает своё понимание задачи в структурированном виде до начала работы.

Передача контекста между шагами

Свободный текст между агентами — источник потерь. Переход на строгую схему (JSON с обязательными полями, а не абзац прозы) отсекает часть неоднозначностей: следующий агент получает данные, а не пересказ.

Проверка результата

Без отдельного шага верификации система не отличает правдоподобный ответ от верного. Агент-критик, который перепроверяет вывод по исходным данным, а не по формулировке предыдущего агента, снижает долю пропущенных ошибок.

Приёмы, которые реально снижают риск

1. Сократите цепочку. Три надёжных агента лучше семи посредственных. Каждое лишнее звено — множитель к вероятности провала. Прежде чем добавить агента, спросите, нельзя ли объединить два шага в один вызов.
2. Структурированный обмен вместо прозы. Заставьте агентов передавать друг другу типизированные объекты с валидацией схемы. Невалидный вывод отклоняется сразу, а не тащится дальше.
3. Валидация на границах. Проверяйте выход каждого агента детерминированной проверкой (не другой LLM, а обычным кодом), где это возможно: диапазоны чисел, наличие обязательных полей, формат дат.
4. Агент-критик с доступом к первоисточнику. Верификатор должен смотреть на исходные данные, а не на пересказ. Иначе он проверяет связность, а не истинность.
5. Сохраняйте неопределённость. Если агент не уверен, это должно передаваться дальше как флаг, а не теряться при переформулировке. Поле confidence в структуре данных дешевле, чем ложная уверенность на выходе.
6. Логируйте трейс целиком. Полная трассировка «кто что получил и что вернул» — единственный способ найти, на каком шаге зародилась ошибка. Без неё отладка многоагентной системы превращается в гадание.

Подходы к архитектуре: чем платить за надёжность

Универсального решения нет — есть компромиссы между надёжностью, стоимостью и скоростью. Ниже сравнение трёх типовых схем.

Голосование (несколько независимых прогонов одной задачи с выбором ответа по большинству) снимает часть случайных ошибок, но не системных: если модель стабильно неверно понимает термин, все прогоны ошибутся одинаково. Против системных ошибок работает только смена формулировки задачи или другая модель на проверке.

Кому это пригодится, а кому нет

Пригодится:

• Командам, которые строят пайплайны обработки документов — извлечение данных, классификация, суммаризация по цепочке. Здесь одна ошибка парсинга портит весь выход.
• Тем, кто автоматизирует поддержку или ресёрч через связку «поиск → анализ → ответ»: без верификации по источнику агент уверенно пересказывает несуществующее.
• Разработчикам агентов, принимающих действия (запись в базу, отправка писем): цена каскадной ошибки тут не токены, а необратимое действие.

Не пригодится (или избыточно):

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

¹ Цепочка агентов (agent chain) — конфигурация, при которой несколько LLM-агентов выполняют задачу последовательно, передавая результат работы друг другу. Каждый агент обычно специализирован: один планирует, другой исполняет, третий проверяет.