Функции управления затратами MuleSoft помогают разобраться в потреблении токенов и найти возможности для снижения затрат на ваши агентские рабочие процессы. Обзор возможностей вы найдете в документации here.
Перед выпуском наших политик управления затратами мы провели внутренние тесты, чтобы оценить их влияние на стоимость и функциональность. Эти тесты также лежат в основе прогнозов потенциальной экономии в нашем рабочем пространстве управления затратами, помогая вам определить, какие политики стоит применить для вашего трафика.
Сегодня мы рассказываем о том, как настраивали эти эксперименты, каковы их результаты и в каких аспектах мы скорректировали наш подход.
Тестирование — снижение затрат
Мы выбрали популярные общедоступные MCP-серверы с вариантами использования, релевантными для клиентских рабочих нагрузок, и очевидными возможностями для применения политик. В число 18 рабочих нагрузок вошли инструменты для совместной работы, поисковые службы, базы данных и извлечение документации.
Для сравнения затрат мы используем эталонный набор запросов/ответов инструментов (golden set) — эталонный набор данных, который сопоставляет тестовые входные данные с ожидаемыми результатами. Эталонные наборы обеспечивают единую основу для проверки результатов при многократных оценках. Мы создали свой набор, сгенерировав MCP-ответы на основе схем выходных данных инструментов выбранных серверов и зафиксировав эти ответы в качестве тестовых входных данных.
Задачи задают цель для этих сравнений. Каждая задача определяет вопрос, ожидаемый инструмент и свод правил (рубрику), описывающий необходимые факты и утверждения, которых ответ должен избегать. Мы можем определять несколько тестовых случаев для одного и того же эталонного набора, задавая разные вопросы для тех же фиксированных ответов без пересоздания набора данных.
Задачи содержат нечеткие (fuzzy) и четкие (non-fuzzy) подсказки (промпты). Нечеткие промпты описывают цель в терминах, которые человек может использовать естественно, оставляя агенту задачу разобраться, как ее выполнить. Четкие промпты добавляют конкретику, такую как ожидаемый инструмент или последовательность вызовов, которую типичный пользователь не стал бы предоставлять. Эти детали делают предполагаемое действие явным и помогают нам оценивать агента по единой задаче.
Контролируемый цикл агента получает нечеткую подсказку задачи и определения инструментов, доступные модели. На каждом шаге агент определяет, завершена ли задача или требуется запросить дополнительную информацию. Если агент решает выполнить действие, он делает вызов инструмента через шлюз, получает обработанный политикой MCP-ответ и использует эту информацию для синтеза ответа.
Тестовый комплекс направляет весь трафик MCP через подготовленные Omni Gateways, настроенные с использованием политик оптимизации затрат, и сравнивает результаты с базовыми показателями без использования политик. Шлюз фиксирует исходные и преобразованные полезные данные, что позволяет нам измерять и сравнивать количество токенов.
Для этого сравнения затрат мы измеряем только те токены MCP, которые отслеживаются шлюзом. Токены, потребляемые средой выполнения агента, включая его промпты, рассуждения и окончательный ответ, остаются за рамками этого измерения.
Для проверки функциональной правильности мы используем гибрид детерминированных проверок и оценки с помощью LLM (LLM-as-a-judge), используя рубрику задачи и четкие промпты. Судья оценивает окончательный ответ по ключу ответов задачи и возвращает результат «пройдено» или «не пройдено», оценку и пояснение. Для повышения согласованности оценки мы используем нескольких судей LLM и перетасовываем промпты между запусками оценки.
Важно отметить, что результаты выполнения задач и использование токенов в рамках всего разговора остаются отдельными от сравнения токенов шлюза. Указанные ниже проценты экономии не означают эквивалентное сокращение затрат в полном агентском рабочем процессе и не доказывают неизменное качество ответов.
Результаты тестов
В таблице приведены все 18 протестированных рабочих нагрузок и заявленная прогнозируемая экономия токенов. Каждый столбец политики описывает отдельную обработку, поэтому проценты нельзя просто суммировать.
Из результатов очевидно, что эффективность политики сильно зависит от каталога инструментов сервера, структуры ответов и информации, необходимой для выполнения задачи. Политика, которая удаляет значительный контекст из одной рабочей нагрузки, может принести мало пользы в другой. В таблице ниже суммировано, где каждая политика дает наибольшую выгоду, а когда ее следует избегать.
Выводы
Наша первая попытка проведения теста заключалась в том, чтобы запустить агента для выполнения задач на работающих MCP-серверах, управляемых через Omni Gateway, и использовать трассировки агента для сравнения потребления токенов в каждом отдельном разговоре. Мы хотели зафиксировать, как применение политики влияет на последующие вызовы агента, включая его выбор инструментов и количество шагов, необходимых для завершения.
Самым сложным было отделить эффект политики от обычных вариаций в поведении агента. Мы кэшировали ответы инструментов, чтобы повторяющиеся вызовы получали те же данные от вышестоящего сервера, нормализовали эквивалентные запросы, чтобы незначительные различия в форматировании позволяли использовать один и тот же кэшированный ответ, и фиксировали изменяющиеся поля, такие как метки времени, чтобы входные данные оставались постоянными.
Мы также использовали низкую температуру модели и фиксированное случайное зерно (seed), чтобы уменьшить разброс в ответах модели. Более явные подсказки сужали выбор, который должен был сделать агент. Даже при таких элементах контроля агенты могли выбирать разные инструменты, выдавать разные промежуточные результаты или совершать разное количество шагов. Эта вариативность влияла как на базовые, так и на включенные с политиками запуски, из-за чего статистически значимые различия в затратах было трудно установить без проведения чрезмерного количества экспериментов.
Эта вариативность оказала большое влияние на затраты. Каждый дополнительный запрос модели несет в себе предшествующий контекст разговора, поэтому запуск с одним дополнительным шагом может потреблять значительно больше токенов, даже если политика уменьшает отдельные полезные нагрузки.
Поэтому мы перенесли сравнение затрат на фиксированные ответы MCP на границе шлюза. Эталонный набор сохраняет данные неизменными, в то время как политика изменяет их представление. Оценка агента решает отдельную задачу: поддерживает ли это представление выполнение задачи.
Что дальше
Следующий шаг — сделать прогнозы потенциальной экономии более привязанными к серверам и трафику каждого конкретного клиента. Результаты показывают почему: одна и та же политика может удалить значительный контекст из одной рабочей нагрузки и практически не затронуть другую.
Мы хотим, чтобы эти прогнозы отражали рабочие нагрузки, которые клиенты используют на практике, помогая им выбрать, где оптимизация заслуживает более пристального внимания. Лучшие оценки затрат и функциональная валидация в совокупности могут способствовать принятию более обоснованных решений в отношении политик.
Затраты — это лишь часть работы агентов в производственной среде. Чтобы узнать, как Omni Gateway справляется с ролью уровня управления для LLM-, RAG- и MCP-трафика, загрузите руководство по тестированию MuleSoft Omni Gateway. Чтобы получать регулярные обновления об интеграции, API и ИИ, подписывайтесь на Technically Speaking, рассылку MuleSoft в LinkedIn.
