Оптимизация затрат на ИИ с помощью Agent Observability

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

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

Datadog Agent Observability связывает предполагаемые затраты на ИИ с приложениями и трейсами, которые их породили, поэтому расходы привязываются к структуре вашего агента, а не к ключу API. Страница Cost позволяет распределять расходы по приложениям и сравнивать их эффективность. Оттуда вы можете перейти к конкретному приложению, чтобы изучить его самые дорогие вызовы. Раздел Cost Savings Opportunities идет дальше, определяя источники избегаемых расходов (например, незакэшированный префикс промпта или история беседы, полностью пересылаемая при каждой итерации), оценивая потенциальный финансовый эффект и предоставляя рекомендации по устранению, которые инженеры могут изучить и проверить.

В этой статье мы покажем, как Agent Observability помогает вам:

• Понять, куда уходят средства на ИИ-агентов

Понять, куда уходят средства на ИИ-агентов

• Отслеживать дорогие вызовы через стек приложения

Отслеживать дорогие вызовы через стек приложения

• Применять возможности для экономии средств

Применять возможности для экономии средств

• Повысить эффективность использования токенов без ущерба для качества

Повысить эффективность использования токенов без ущерба для качества

Понять, куда уходят средства на ИИ-агентов

Страница Cost в Agent Observability представляет затраты на ИИ в контексте породивших их приложений и запросов. Она помогает ответить на три ключевых вопроса:

• Сколько вы тратите и растет ли эта сумма?

Сколько вы тратите и растет ли эта сумма?

• Куда уходят деньги?

Куда уходят деньги?

• Эффективны ли эти расходы?

Эффективны ли эти расходы?

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

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

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

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

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

Когда рост затрат требует дополнительного расследования, вы можете сгруппировать тенденции затрат по модели и провайдеру, типу токенов, окружению, сервису или версии. Каждая размерность помогает проверить определенное объяснение. Разбивка по провайдерам или моделям может выявить сдвиг в сторону более дорогой модели, а разбивка по типам токенов может показать, был ли рост вызван незакэшированным входом, кэшированным входом, записью в кэш, рассуждениями (reasoning) или выходом. Группировка по версии может помочь выявить развертывание, связанное с изменением стоимости или поведения кэширования.

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

Отслеживать дорогие вызовы через стек приложения

После того как вы определили приложение с высокими затратами, Agent Observability позволяет отследить расходы до конкретных запросов и операций. Таблица Most Expensive LLM Calls ранжирует вызовы по расчетной общей стоимости и включает такой контекст, как модель, токены ввода и вывода, а также превью входных данных.

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

Такой уровень детализации помогает различать различные паттерны затрат. Один запрос может быть дорогостоящим из-за единственного большого ответа, в то время как другой может содержать повторяющиеся вызовы, цикл агента, избыточную работу с инструментами или затратную подзадачу. Граф выполнения (Execution Graph) предоставляет дополнительное представление того же рабочего процесса, показывая, как связаны между собой агенты, вызовы LLM, инструменты и оценки.

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

Для приложений, которые также используют Datadog Application Performance Monitoring (APM), вы можете расширить расследование за пределы рабочего процесса, специфичного для LLM. Когда приложение инструментировано для обоих продуктов, соотнесенные спаны Agent Observability и APM позволяют переходить между ИИ-операцией и более широким трейсом приложения. Это может помочь определить, кроются ли задержки или ошибки в вызове LLM либо в восходящем или нисходящем сервисе.

Применять возможности для экономии средств

Cost Savings Opportunities помогают превратить измерения затрат в конкретную инженерную работу. Agent Observability анализирует наблюдаемое поведение приложения на предмет возможностей сокращения избегаемых расходов, а затем ранжирует рекомендации по приложениям и предполагаемому финансовому эффекту.

Представление возможностей экономии затрат (Cost Savings Opportunities) показывает общую оценочную сумму возмещаемых затрат за выбранный период и определяет поведение, связанное с каждой рекомендацией. Например, Agent Observability может выявить приложение, которое не использует кэширование промптов, динамический контент, который неоднократно изменяет повторно используемый префикс промпта, несогласованное форматирование сообщений, препятствующее попаданию в кэш, многократно воссоздаваемый ввод промпта или определения инструментов, изменяющиеся между вызовами.

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

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

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

В аналитике также описываются техническая причина, область анализа, затронутые вызовы и сеансы, наблюдаемое повторное использование токенов и репрезентативные сеансы, трассировки или спаны. Представление «Как мы это обнаружили» может раскрыть размер выборки, период наблюдения, фильтры, этапы рассуждений, подтверждающие наблюдения и ограничения, лежащие в основе анализа.

Эта прозрачность важна, поскольку оптимизация затрат может изменить поведение приложения. Инженеры могут изучить то, что проанализировал Agent Observability, и проверить подтверждающие доказательства перед изменением производственного кода.

Затем в разделе «Следующие шаги» выводы преобразуются в рекомендации по устранению проблем. В зависимости от проблемы он может определить, какое поведение при формировании запросов следует изменить, объяснить, как реорганизовать стабильный и динамический контент промптов, а также описать, как проверить результат. Инженеры также могут выбрать «Исправить с помощью Bits» (Fix with Bits), чтобы продолжить работу с Bits, или скопировать промпт агента для использования в другом рабочем процессе написания кода.

Повышайте эффективность использования токенов без ущерба для качества

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

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

Контролируйте расходы на ИИ с помощью контекста на уровне приложения

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

Datadog Agent Observability предоставляется бесплатно для клиентов, отправляющих до 40 000 LLM-спанов в месяц. Чтобы узнать больше о начале работы с Agent Observability, посетите страницу продукта и документацию.

Если у вас нет учетной записи Datadog, вы можете зарегистрироваться для получения 14-дневной бесплатной пробной версии.