ИИ-агенты могут быть непредсказуемыми. Ваш слой контроля — нет.

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

Именно поэтому многоагентные системы принципиально отличаются от приложений с одним агентом. Анализ каждого агента по отдельности или простая проверка итогового ответа не позволяют понять, насколько успешно прошло само взаимодействие.

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

В этой статье представлен практический подход к оценке таких взаимодействий и использованию полученных результатов для создания более надёжных инженерных средств контроля. Цель не в том, чтобы сделать LLM детерминированными, а в том, чтобы сделать их непредсказуемое поведение видимым, измеримым, ограниченным и управляемым.

Почему взаимодействие агентов требует оценки

Большие языковые модели (LLM) по своей природе недетерминированы. В многоагентной системе эта неопределённость никуда не исчезает. Один агент генерирует информацию, другой получает её и интерпретирует, а его вывод затем может стать контекстом для следующего агента. Любая ошибочно сгенерированная или интерпретированная информация распространяется и усиливается по всему рабочему процессу.

По сути, агенты в многоагентной системе используют контекст друг друга. Его можно оценивать так же, как в системе генерации с дополнением извлечённой информацией (RAG). Взаимодействие агентов может подчиняться тем же принципам и методологии.

Типичный конвейер RAG можно представить так:

Запрос пользователя → модуль извлечения → извлечённый контекст (оценка) → генерация → сгенерированный ответ (оценка)

Мы отдельно оцениваем извлечение и генерацию контента, чтобы определить, возникла ли проблема на этапе поиска, связана ли она с качеством контекста или с генерацией.

Многоагентная система развивает эту идею:

Запрос пользователя → агент A → передача данных → агент B → общее состояние → агент C → проверка → итоговый результат

Оценка только итогового ответа — или даже каждого агента по отдельности — не позволяет понять, насколько успешно прошло само взаимодействие. Нужно видеть, что происходит между агентами.

Сбор трассировки выполнения многоагентной системы

Прежде чем оценивать взаимодействие, нужно наблюдать за всем рабочим процессом. Подобно тому как LangSmith может фиксировать промпты, извлечённые документы, вызовы инструментов и ответы модели в приложении RAG, трассировка многоагентной системы должна фиксировать:

• Какие агенты запускались и в каком порядке

• Входные и выходные данные каждого агента

• Данные, передаваемые от одного агента другому

• Решения о маршрутизации и делегировании

• Чтение и обновление общего состояния

• Вызовы инструментов и их результаты

• Повторные попытки, циклы и решения о завершении

• Задержку, расход токенов и стоимость каждого этапа

Трассировка фактически становится историей выполнения многоагентного рабочего процесса. Без неё мы можем знать, что итоговый результат неудачен, но почти не понимать, на каком этапе взаимодействие дало сбой.

Оценка тупиков и циклов в рабочем процессе

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

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

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

Такие сбои свойственны графу выполнения, а не обязательно какому-либо отдельному агенту. Поэтому мы оцениваем трассировку рабочего процесса с помощью следующих показателей:

Эти метрики позволяют определить, продвигается ли сеть агентов и достигает ли она корректного конечного состояния, а не просто выдаёт ли каждый агент по отдельности правдоподобный ответ.

Оценка передачи данных между агентами

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

Каждую передачу данных между агентами можно рассматривать как небольшой конвейер обработки информации:

Вывод агента A → контекст, переданный агенту B → интерпретация агента B

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

Оценка передачи контекста

Первый вопрос — действительно ли нужная информация, полученная от предыдущего агента, доходит до следующего.

Типичные вопросы:

• Была ли вся важная информация от агента A передана агенту B?

• Не потерялась ли при передаче какая-либо важная информация?

• Не включена ли лишняя или не относящаяся к делу информация?

• Содержит ли переданный агенту B контекст всё необходимое для выполнения его задачи?

На границе взаимодействия агентов можно применять те же метрики качества контекста, которые обычно используются при оценке RAG:

Оценка интерпретации следующим агентом

Передача правильного контекста — лишь половина задачи. Нужно также понять, правильно ли следующий агент усвоил и использовал полученную информацию.

Типичные вопросы:

• Подтверждается ли вывод агента B информацией, полученной от агента A?

• Сохранил ли агент B смысл результата предыдущего агента?

• Добавил ли он неподтверждённую информацией, полученной при передаче, информацию?

• Принял ли он правильное решение на основании предоставленных данных?

Здесь можно адаптировать те же принципы оценки качества генерации, которые используются при оценке RAG:

Для семантической оценки обычно используют LLM-as-a-judge. Такая оценка сопоставляет вывод предыдущего агента, контекст, полученный следующим агентом, и результат работы следующего агента.

Оценка целостности интерфейсов

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

По возможности агенты должны передавать друг другу структурированные результаты, а не произвольные ответы на естественном языке, даже если речь идёт о длинном тексте. JSON-схемы, модели Pydantic и другие типизированные контракты позволяют детерминированно проверить часть передаваемых данных до запуска следующего агента.

Полезные метрики:

Так мы получаем три взаимодополняющих уровня оценки передачи данных:

Вывод агента A → качество контекста → целостность интерфейса → интерпретация агента B

Метрики контекста показывают, передана ли нужная информация. Проверка интерфейса показывает, передана ли она в ожидаемой структуре. Метрики генерации показывают, правильно ли следующий агент понял эту информацию и использовал её.

Оценка общего состояния

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

Поэтому оценка состояния рассматривает каждый переход между состояниями как контрольную точку: сравнивает состояние до и после выполнения агентом задачи и проверяет, правильно ли сохранена важная информация.

Например, рассмотрим общее состояние рабочего процесса поддержки SaaS-клиентов:

{
  «customer_id»: «C1024»,
  «plan»: «Enterprise»,
  «issue»: «duplicate_charge»,
  «identity_verified»: true,
  «refund_eligible»: true,

  «refund reason»: xxx long text
}

Решение — создать функцию, называемую менеджером состояния, которая сможет оценивать обновлённое состояние с помощью двух типов проверок.

Детерминированные проверки проверяют свойства, которые можно описать правилами:

• Проверка схемы: Присутствуют ли обязательные поля и имеют ли они правильный тип?

• Проверка неизменяемых полей: Не изменил ли агент неожиданно customer_id или другое защищённое поле?

• Проверка согласованности: Не противоречит ли refund_eligible = true другому полю состояния или бизнес-правилу?

• Проверка актуальности: Не использует ли агент устаревшее или заменённое значение?

• Проверка размера контекста: Не превысили ли история диалога или общий контекст заданный порог?

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

• Не потеряны ли важные факты или ограничения?

• Не изменило ли суммирование смысл разговора?

• Не добавлена ли в состояние неподтверждённая информация?

• Отражает ли обновлённое состояние исходный запрос клиента?

• Не накапливается ли нерелевантная информация, отвлекающая следующих агентов?

Эти проверки можно измерять с помощью KPI на уровне состояния:

• Доля проверенных состояний: Процент переходов между состояниями, прошедших проверку схемы и бизнес-правил

• Доля согласованных состояний: Процент переходов без противоречащих друг другу значений состояния

• Доля сохранённых ограничений: Сохраняются ли важные требования при переходах между состояниями

• Точность сводки: Сохраняет ли сжатое состояние смысл и ключевые факты исходного контекста

• Доля устаревших состояний: Как часто следующие агенты используют устаревшую информацию

• Рост контекста: Увеличение объёма активного состояния или расхода токенов по мере продвижения рабочего процесса  

Таким образом, менеджер состояния выполняет функцию, схожую с контрольной точкой в конвейере обработки данных:

Предыдущее состояние → выполнение агентом задачи → обновлённое состояние → оценка состояния → следующий агент

Это позволяет оценивать не только корректность результатов отдельных агентов, но и то, остаётся ли общее представление о рабочем процессе точным по мере передачи информации между несколькими агентами.

Оценка коррелированных рассуждений (монокультура моделей)

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

Этот сбой возникает не внутри какого-либо одного агента, а из-за отсутствия независимости между агентами. Поэтому для выявления монокультуры моделей нужно измерять, действительно ли агенты предлагают разнообразные рассуждения, доказательства, решения и модели ошибок.

• Разнообразие выводов: Насколько похожи ответы агентов на одну и ту же задачу — косинусное сходство эмбеддингов, BERTScore, LLM-as-a-judge

• Разнообразие рассуждений: Используют ли агенты разные пути рассуждения — сходство трасс рассуждений, расстояние редактирования графов

• Разнообразие инструментов: Используют ли агенты разные инструменты или рабочие процессы — энтропия использования инструментов, распределение инструментов

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

• Разнообразие решений: Приходят ли агенты неизменно к одним и тем же решениям — энтропия решений, доля совпадающих решений

• Корреляция ошибок: Ошибаются ли агенты на одних и тех же задачах — доля совпадения ошибок, попарная корреляция ошибок

• Разнообразие перспектив: Рассматривают ли агенты проблему с разных точек зрения — классификация рассуждений на основе LLM  

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

От оценки к инженерному контролю

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

Проектирование передачи данных между агентами. Определите явные интерфейсы с помощью структурированных форматов вывода, таких как JSON Schema или модели Pydantic. Прежде чем результат получит следующий агент, проверьте обязательные поля, типы данных и бизнес-правила. Если проверка не пройдена, система может отклонить данные, повторно запустить предыдущий агент или направить рабочий процесс по альтернативному пути. Так семантические рассуждения остаются гибкими, а интерфейс взаимодействия — детерминированным.

Проектирование координации рабочего процесса. Уровень оркестрации должен явно отслеживать запуски агентов, решения о маршрутизации, передачи данных, итерации, время выполнения и конечные состояния. Именно здесь важна детерминированная оркестрация. Такие фреймворки, как LangGraph, позволяют представлять рабочие процессы в виде графов с состоянием, явными узлами, рёбрами, ветвлениями и контрольными точками. Детерминированные средства контроля — например, ограничения на число итераций, тайм-ауты и условия завершения — позволяют предотвращать тупики и бесконечные циклы, а не полагаться исключительно на решение LLM о том, когда остановиться. Затем трассировку выполнения можно фиксировать с помощью LangSmith, получая необходимую видимость для оценки продвижения рабочего процесса и диагностики аномального выполнения.

Проектирование управления состоянием. Общее состояние должен контролировать менеджер состояния, а не бесконечная цепочка передач между агентами.

Выполнение агентом задачи → менеджер состояния → обновление / очистка состояния → следующий агент

Менеджер состояния использует детерминированные правила, чтобы отслеживать размер контекста и определять, когда его нужно сокращать. При достижении порогового значения он запускает облегчённого агента для суммирования диалога. Затем менеджер состояния детерминированно заменяет более старые сообщения сводкой, сохраняя при этом недавний контекст. Так создаётся гибридная модель: LLM выполняет семантическое суммирование, а детерминированный код контролирует, когда и как меняется состояние. Это позволяет поддерживать компактность общего состояния и не даёт контексту бесконечно разрастаться.

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

Например, система поддержки SaaS-клиентов может использовать:

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

• Агент базы знаний и RAG: Модель, хорошо понимающую контекст и генерирующую ответы с опорой на источники.

• Агент транзакций: Более мощную модель рассуждения для интерпретации политик и определения допустимости действия.

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

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

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

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

Шухуа Сюй — ведущий инженер по данным.

Добро пожаловать в сообщество VentureBeat!

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

Читайте другие материалы нашей программы гостевых публикаций — и ознакомьтесь с правилами , если хотите предложить собственную статью!