Возможности наблюдаемости для корпоративных агентов ИИ с использованием Langfuse и OCI
Почему журналы событий, метрики и трейсы недостаточны для агентов генеративного ИИ, и как отслеживать запросы, вызовы инструментов, токены и сессии с помощью open-source Langfuse в OCI Agents.
Источники: Observability for Enterprise AI Agents: an open-source solution
Журналы событий, метрики и трейсы не покажут вам, почему корпоративный ИИ-агент дал некорректный ответ. Чтобы понять такие системы, необходимо также рассмотреть запросы, контекст, передаваемый модели, вызовы инструментов, использование токенов, время отклика и качество результата. В этой статье объясняется, почему генеративному ИИ требуется иной подход к возможности наблюдения за работой систем, а затем приводится конкретная настройка с использованием Langfuse, которая интегрируется с корпоративными ИИ-агентами OCI благодаря совместимости с API OpenAI Responses.
Почему это важно
Термин «агент» используется для обозначения любого рабочего процесса, в котором применяются одна или несколько больших языковых моделей для получения результата. Это затрудняет четкое разграничение. Настоящий агент обеспечивает автономность, возможность использования инструментов и управление контекстом, что в свою очередь приводит к значительно большей операционной сложности.
Вторая проблема ещё более актуальна в корпоративных организациях. Внимание сосредотачивается на «магии» искусственного интеллекта, в то время как работа, необходимая для надёжной, контролируемой и качественной работы этих систем, остаётся без внимания. Видимость является одним из ключевых аспектов в этом списке. Для сложного агента генеративного ИИ это не техническая деталь — это то, что позволяет понимать поведение, анализировать ошибки, оценивать качество ответов и контролировать затраты и задержки.
В первой половине текста определяется понятие видимости и её роль в генеративном ИИ. Во второй половине рассматривается open-source решение, легко запускаемое на OCI, с примерами собираемых данных и объяснением того, почему они полезны.
Что означает видимость
Наблюдаемость — это свойство сложных систем. Проще говоря, система является наблюдаемой, если её внутреннюю работу можно определить по сигналам, которые она излучает и которые можно собрать и проанализировать. Более формально, два разных внутренних состояния должны быть различимы по внешним сигналам. То, что излучает система, должно надёжно отражать происходящее внутри неё.
Из этого следуют два вывода. Наблюдаемость имеет наибольшее значение там, где много компонентов, зависимостей и взаимодействий. Кроме того, недостаточно просто наблюдать извне, поскольку систему необходимо спроектировать и оснастить инструментами для генерации полезной информации. Правильная работа такого агента искусственного интеллекта в корпоративной среде подразумевает сбор телеметрических данных, которые раскрывают его состояние, поведение, аномалии и производительность.
Именно в этом аспекте наблюдаемость отличается от классического мониторинга. Мониторинг отвечает на вопросы, которые вы заранее предусмотрели, такие как количество CPU, используемое сервисом, или скорость обработки запроса. Наблюдаемость же должна позволять вам расследовать неожиданности — проблемы и вопросы, которые никто не предвидел на этапе проектирования, их часто называют «неизвестными неизвестными».
Наблюдаемость до появления генеративного ИИ
Под «традиционными системами» здесь подразумеваются приложения, созданные до того, как генеративный ИИ стал широко распространённым, примерно до 2023 года. Их наблюдаемость основывалась на трёх видах данных: логах, метриках и трейсах.
Логи и метрики — это что-то знакомое. Трейс представляет собой полную запись одного запроса или взаимодействия, состоящую из спанов, описывающих отдельные этапы. В архитектуре микросервисов один трейс может охватывать всю транзакцию приложения, включая спаны для вызова API, запроса к базе данных или обращения к внешнему сервису. Чтобы такой подход был эффективным, он должен отслеживать запрос на протяжении всех компонентов, с которыми он взаимодействует.
Для агентов на основе генеративного ИИ этой классической модели недостаточно самой по себе. Помимо логов, метрик и трейсов необходимо также отслеживать, что делает модель, какой контекст она получала, какие инструменты она использовала и насколько хорошими были её ответы.
Что меняется с появлением генеративного ИИ
Традиционное программное обеспечение довольно предсказуемо. Системы, построенные на генеративном ИИ, менее предсказуемы, особенно когда у них есть свобода принятия решений. Результат работы большой языковой модели зависит от гораздо большего количества факторов, чем ввод данных пользователя, и все эти факторы должны быть видимы.
Система для отслеживания работы системы на основе большой языковой модели должна фиксировать по меньшей мере четыре аспекта:
- модель и параметры вызова
- инструкции и фактически отправленный запрос
- предоставленный контекст, включая предыдущую историю общения
- способ выполнения системы, включая вызовы инструментов, промежуточные результаты, задержку и использование токенов
Ограничиваться только окончательным ответом недостаточно. Чтобы понять систему генеративного ИИ, необходимо иметь возможность воссоздать для любого следа всё, что способствовало формированию ответа.
Это ещё более верно, когда у модели есть свобода действий. Если она может сама выбирать, какие инструменты использовать, в каком порядке выполнять действия, какие источники обращаться и когда останавливаться, тогда просто вводные данные и результаты недостаточны. Необходимо видеть сам процесс принятия решений, включая последовательность вызовов инструментов, временные рамки и промежуточные результаты.
Даже полная трассировка часто не может показать, хорош ли полученный результат. Для этого к каждой трассировке обычно привязываются оценки. Они могут формироваться на основе традиционной логики или с помощью другой ЯИИ — распространённой в настоящее время техники «ЯИИ в роли судьи».
Рассмотрим оценку ответа, сгенерированного с использованием технологии RAG. Он может быть частично верным или казаться правдоподобным без подтверждения из извлеченных источников. В таком случае необходимо выделить как минимум две проблемы: первопричину, такую как процесс извлечения информации, переориентация рейтингов или генерация текста, и основание ответа, то есть наличие подтверждения в извлеченных документах. Проверка основания позволяет выявить необоснованные утверждения и, следовательно, возможные галлюцинации.
Все это означает, что обычная платформа для мониторинга не подойдет для технологий GenAI. Необходим инструмент, который способен нативно собирать такую информацию при минимальных усилиях по настройке мониторинга. Настоящая разница заключается в объеме контроля: для GenAI необходимо отслеживать инфраструктуру и скорость работы, как и раньше, а также контекст, с которым работал модель, принятые ею решения, качество генерируемого контента и стабильность ее поведения.
От теории к рабочей конфигурации
Поэтому возможности отслеживания для корпоративных агентов должны включать подсказки, контекст, вызовы инструментов, время отклика, расход токенов, качество вывода, а также вероятные причины ошибок или плохих ответов, помимо классических сигналов. Практический вопрос заключается в том, как получить всё это простым и эффективным способом, подходящим для корпоративной среды. Ниже приведён пример решения с открытым исходным кодом, которое легко внедрить в OCI.
Langfuse
Среди инструментов с открытым исходным кодом для обеспечения наблюдаемости LLM и агентов выделяется Langfuse. Это платформа для отслеживания, наблюдаемости и оценки (рейтингования) приложений на основе LLM, которая охватывает большинство вышеупомянутых данных: промпты, результаты, трейсы, метаданные, время отклика, использование токенов, вызовы инструментов и оценочные баллы. Это не просто сервис логгинга — он предоставляет структурированный обзор реального поведения приложения на основе искусственного интеллекта, организованный по трейсам и сессиям, а не по простому потоку текстовых строк, в котором приходится искать нужную информацию.
Почему OCI облегчает интеграцию
OCI Enterprise AI Agents предоставляет API, полностью совместимый с API OpenAI Responses. Это важно не только из-за удобства, но и потому, что это позволяет использовать инструменты, библиотеки и паттерны разработки широкой экосистемы, совместимой с OpenAI. Для Langfuse это значительно сокращает объем работы по сбору телеметрии с вызовов моделей и созданию слоя наблюдаемости, поэтому больше времени уделяется анализу, а не технической настройке. Именно поэтому OCI и Langfuse хорошо сочетаются в корпоративной среде.
Быстрое развертывание в рамках демонстрации концепции
Для демонстрационной проверки Langfuse легко устанавливается на OCI, например, на виртуальную машину Linux, с использованием официального скрипта развертывания Docker Compose из репозитория Langfuse. Это не обязательно окончательная архитектура для производственной корпоративной среды. Однако она вполне подходит для проверки идеи, сбора реальных данных и определения возможностей анализа после интеграции. На практике это позволило быстро создать рабочую платформу, доступную через браузер и готовую принимать данные от приложений на основе Python LLM.
Подключение кода
После запуска инстанса Langfuse следующим шагом является настройка приложения так, чтобы телеметрия вызовов модели передавалась автоматически. Благодаря совместимости с API Responses это просто для Python-приложений, уже написанных с использованием вызовов в стиле OpenAI. Приложение продолжает вызывать модель так же, как и раньше, а Langfuse записывает важные детали.
Изменения незначительны:
- Установите несколько переменных окружения.
- Используйте клиент, предоставляемый библиотекой Langfuse, который уже настроен для сбора и отправки трейсов.
- Передавайте
conversation_idвместоsession_id, чтобы запросы из одного разговора связывались в одной сессии. - По желанию можно принудительно отправить трейс сразу; в противном случае он будет отправлен автоматически через несколько секунд.
Что собирается
После интеграции Langfuse автоматически собирает множество полезных данных. Для операторов это включает не только входные и выходные данные модели, но также информацию о процессе выполнения: промежуточные этапы, вызовы инструментов и временные показатели, которые помогают восстановить процесс получения результата.
Самые важные элементы включают:
- модель и её версия
- отправленный промпт
- сгенерированный результат
- метаданные, привязанные к вызову
- структура трейса и все его элементы
- показатели задержек, включая те, которые видны пользователю, такие как время до появления первого токена
- количество входных и выходных токенов, необходимое для анализа затрат
- вызовы инструментов и их детали
- баллы и оценки, связанные с трейсом
Не всё полезное поступает автоматически, и это предусмотрено заранее, поскольку платформа не может знать, что ваш бизнес считает хорошим ответом. Оценки, специфичные для конкретной области, пользовательские показатели и метаданные бизнеса могут, а иногда и должны, добавляться приложением. Именно сочетание автоматического сбора данных и целенаправленного их обогащения делает инструмент эффективным.
Сессии
Langfuse может связывать несколько треков одной сессии пользователя с помощью session_id. В такой конфигурации разговор идентифицируется стандартным conversation_id API Responses, поэтому при установке session_id в его значение все запросы из одного разговора связываются между собой. Затем сессии можно просматривать в интерфейсе, где каждая из них содержит несколько треков.
Просмотр содержимого трека
Результаты анализа становятся очевидными в процессе его выполнения. Интерфейс Langfuse позволяет подробно изучать каждое взаимодействие, выявляя информацию, которая в противном случае была бы рассеяна среди журналов приложений, разрозненных метаданных и кода. Для отдельной трассы можно увидеть фактически отправленный запрос, используемую модель, её параметры, время выполнения, количество потребленных токенов, последовательность всех вызовов и результаты на каждом этапе. Это особенно важно при расследовании необычного поведения, проблем с задержками, роста затрат или ответов недостаточного качества. Например, медленный ответ может быть связан с длинной цепочкой вызовов инструментов, слишком длинным запросом или медленным генерированием первого токена, причем для каждой из этих проблем требуется свое решение. Без одновременного отображения времени выполнения на уровне отдельных этапов и количества токенов пришлось бы догадываться, в чем причина проблемы.
Практической привычкой, которая из этого следует, является рассмотрение каждого разговора как чего-то, что можно воспроизвести позже. Когда пользователь сообщает о плохом ответе спустя неделю, возможность просмотра сессии позволяет открыть точные записи, прочитать исходный запрос и контекст, а также увидеть, какой инструмент вернул какой результат, вместо попыток воссоздать ситуацию из памяти.
Ограничения, о которых следует помнить
Использование Langfuse не решает всех проблем с возможностью наблюдения и оценки в системах генеративного ИИ. Обширные записи с подробным контекстом необходимы, но не всегда достаточны. Наиболее полезные показатели обычно зависят от области применения и должны быть специально разработаны. Кроме того, реальные корпоративные среды требуют тщательного учета аспектов безопасности, конфиденциальных данных, хранения телеметрических данных, контроля доступа и архитектуры развертывания.
Тем не менее, платформа с открытым исходным кодом в сочетании с полной совместимостью API OCI представляет собой прочную основу для создания реального решения по обеспечению наблюдаемости для корпоративных агентов.
Вывод
Для корпоративных ИИ-агентов наблюдаемость — это не техническая деталь или дополнительная опция. Это предпосылка для понимания их поведения, анализа ошибок, оценки качества ответов, а также снижения времени отклика и операционных затрат. Отслеживание инфраструктуры, логов приложений и стандартных метрик недостаточно. Также необходимы данные, более тесно связанные с действиями агента: запросы, контекст, вызовы инструментов, расход токенов, воспринимаемая пользователем задержка и оценочные баллы.
Langfuse представляет собой особенно интересный вариант с открытым исходным кодом, поскольку он собирает и организует значительную часть такой телеметрии, а API, совместимое с OpenAI, в OCI Enterprise AI Agents облегчает интеграцию. Однако ни одна платформа не может решить всё сама по себе. Безопасность, управление, обработка конфиденциальных данных и разработка показателей, специфичных для конкретной области, по-прежнему остаются критически важными.
Если эти агенты должны выйти за рамки демо-версий и стать надёжной частью реальных систем, наблюдаемость не может оставаться второстепенной. Их сложность невозможно устранить, но её можно и следует сделать видимой.
Логичным следующим шагом является обогащение трейсов показателями, более систематически оценивающими качество, особенно показателями, генерируемыми ИИ в роли судьи, чтобы каждый трейс содержал оценки качества ответа наряду с техническими данными выполнения.
Связанные материалы
- Как хранилище браузера тайно повреждает данные пользователей и как этого избежать — Потерянные обновления, устаревшие снимки состояния, изменения структуры данных и утечки информации с общедоступных устройств могут повредить данные localStorage без каких-либо ошибок. Шаблоны для определения владельцев, версионирования и проверки данных.
- Практические рекомендации: системы RAG: полное руководство от начала до конца (издание 2026 года) — Подробное пошаговое руководство по использованию систем RAG: полное руководство от начала до конца (издание 2026 года), включающее шаблоны контрактов, проверок и готовые фрагменты кода для команд, внедряющих такие решения.