Наблюдение за LLM в многомодельном шлюзе API: трассировки, реестры токенов, аналитика клиентов и безопасное ведение журнала подсказок
Практическая архитектура наблюдения для многомодельных шлюзов искусственного интеллекта: отслеживайте каждый вызов LLM один раз, присоединяйте телеметрию к реестрам токенов и затрат, согласовывайте счета поставщиков и выполняйте безопасную отладку без сохранения необработанных подсказок по умолчанию.
Совокупного количества запросов и ежемесячных расходов недостаточно, когда клиент спрашивает, почему вчера один рабочий процесс стал медленнее, дороже или менее надежен. Многомодельный шлюз API может ответить на этот вопрос, если он рассматривает возможность наблюдения как часть плоскости управления: каждый запрос получает трассировку, каждый вызов модели обновляет реестр использования, каждый клиент и рабочий процесс можно атрибуировать, а конфиденциальный контент защищен по умолчанию.
В этой статье описывается практическая разработка аналитики использования искусственного интеллекта и наблюдения за LLM в шлюзе, который взаимодействует с несколькими поставщиками через API, совместимый с OpenAI. Этот шаблон полезен, даже если вы не используете какого-либо конкретного поставщика: инструментируйте один раз на шлюзе, нормализуйте телеметрию модели, сохраняйте атрибуцию выставления счетов и фиксируйте содержимое подсказок только в соответствии с явной политикой.
Задача читателя: «Какой арендатор, модель, подсказка или путь поиска вызвали изменение?»
Большинство команд в конечном итоге сталкиваются с одним и тем же пробелом в отладке. Журналы приложений показывают, что функция не удалась. Информационные панели провайдеров показывают, что использование токенов увеличилось. Финансы видят законопроект. Ни одно из этих представлений само по себе не объясняет полный путь от запроса клиента к вызову модели, контексту получения и повторной попытке до выставленной стоимости.
Цель — не еще одна панель мониторинга с общим количеством токенов. Цель — ответить на оперативные вопросы, такие как:
<ул>Факты, рекомендации и прогнозы
Факты: OpenTelemetry документирует семантические соглашения и атрибуты генеративного ИИ для операций модели, включая имена операций, такие как Chat, Generate_content и Text_Completion. В той же документации предупреждается, что атрибуты входных и выходных сообщений GenAI могут содержать конфиденциальную информацию или PII и могут потребовать фильтрации или усечения. Крупные поставщики моделей также предоставляют панели мониторинга использования, API или экспорт, которые могут поддерживать сверку на стороне поставщика, хотя детали зависят от поставщика.
Рекомендации. Используйте OpenTelemetry для отслеживания, независимого от поставщика, но сохраняйте бизнес-аналитики, принадлежащие шлюзу, в своих собственных атрибутах и реестрах. Не сохраняйте необработанные запросы или выходные данные по умолчанию. Сначала сохраняйте метаданные, хеши, количество токенов, идентификаторы шаблонов приглашений, имена схем, классы ошибок и метки безопасности. Добавляйте захват контента только в качестве функции отладки с контролируемым доступом и кратковременным хранением.
Прогноз: Наблюдение за LLM будет сводиться не к панелям мониторинга изолированных поставщиков, а к плоскостям управления между поставщиками. Команды будут ожидать, что в одном месте можно будет исследовать задержку, стоимость, качество, события политики, поведение клиентов и разницу в выставлении счетов в разных моделях.
Эталонная архитектура: просмотрите весь путь запроса
Шлюз может отслеживать полный жизненный цикл запроса, не требуя от каждой группы приложений создания собственных телеметрических данных. Полезная модель трассировки начинается с одного родительского диапазона для входящего запроса клиента и дочерних диапазонов для шагов, которые влияют на стоимость, задержку и качество.
Рекомендуемая структура диапазона
<ул>Родительский диапазон должен содержать идентификаторы стабильной корреляции. Дочерние промежутки должны иметь нормализованные технические атрибуты. В журнале использования должны храниться надежные записи счетов и аналитики. Избегайте принудительного помещения всей информации в метки показателей; Значения с высокой мощностью, такие как идентификаторы клиентов, хэши запросов и идентификаторы документов, лучше хранить в трассировках, журналах или таблицах главной книги, а затем агрегировать на информационных панелях.
Нормализация метаданных, полученных при каждом вызове LLM
Каждый запрос модели должен создавать согласованную запись независимо от поставщика. Точная схема может отличаться, но практический минимум выглядит так:
{
"request_id": "req_01J...",
"trace_id": "4bf92f3577b34da6a3ce929d0e0e4736",
"tenant_id": "tenant_123",
"team_id": "team_456",
"app_id": "support_bot",
"gateway_key_id": "key_789",
"операция": "чат",
"провайдер": "имя_провайдера",
"модель": "идентификатор-модели-поставщика",
"model_alias": "быстрый чат поддержки",
"prompt_template_id": "refund_policy_v5",
"prompt_hash": "sha256:...",
"response_schema": "support_answer_v2",
"статус": "завершено",
«класс_ошибки»: ноль,
«латентность_мс»: 1842,
«входные_токены»: 2110,
«выходные_токены»: 384,
«cached_input_tokens»: 1200,
"estimated_cost_usd": "0,00492",
«final_billed_cost_usd»: ноль,
"finish_reason": "стоп",
«retry_count»: 0,
«fallback_used»: ложь,
"content_capture_policy": "только метаданные"
Разделите две идеи: телеметрия объясняет, что произошло, а журнал использования записывает, что должно взиматься, сверяться и сообщаться. Они ссылаются друг на друга с помощью идентификаторов запросов и идентификаторов трассировки, но не обязательно находятся в одной системе хранения.
Создайте реестр токенов и затрат, а не только счетчики
Счетчики токенов полезны для диаграмм, но их недостаточно для выставления счетов или расследования инцидентов. Реестр должен отражать переходы между состояниями. Создайте строку, когда шлюз принимает запрос, а затем обновляйте ее по мере выполнения запроса.
Полезные состояния бухгалтерской книги
<ул>Эта модель состояния помогает выявлять типичные ошибки выставления счетов и аналитики: потоковые ответы, когда клиент отключался, повторные попытки, которые оплачивались поставщиком, но были скрыты от пользователя, резервные пути, которые учитывали неправильную модель, и различия в учете кеширования между поставщиками.
Используйте соглашения OpenTelemetry GenAI, а затем осторожно расширяйте
Семантические соглашения OpenTelemetry GenAI предоставляют переносимый словарь для операций с моделью. Используйте эти соглашения для общих атрибутов, таких как имя операции, поставщик, модель, параметры запроса, причины завершения ответа, использование токена и статус ошибки, где они применимы.
Однако соглашения, нейтральные к поставщикам услуг, не охватывают все бизнес-аспекты шлюза. Добавьте принадлежащие шлюзу атрибуты или столбцы книги для:
<ул>Компромисс – кардинальность. Эти поля ценны для исследования, но они могут сделать метрики дорогими и зашумленными, если их повсеместно использовать в качестве меток метрик. Практическое правило таково: агрегаты низкой мощности переходят в метрики; Идентификаторы с высокой мощностью используются в трассировках, журналах и реестрах.
Разработайте безопасное ведение журнала запросов и вывода
Полное ведение журнала подсказок упрощает отладку, но повышает конфиденциальность, соответствие требованиям, хранение и подверженность инсайдерским рискам. Более безопасным вариантом по умолчанию является возможность наблюдения на основе метаданных.
По умолчанию: только метаданные
Для большей части производственного трафика храните:
<ул>Включение: контролируемый захват контента
Если вам нужен необработанный или отредактированный контент для глубокой отладки, потребуйте явную политику. Хорошие средства контроля включают в себя белые списки среды, согласие арендаторов, выборку, максимальную длину полезных данных, автоматическое редактирование, короткие окна хранения, шифрование, доступ на основе ролей, журналы аудита и путь утверждения для конфиденциальных инцидентов.
Не считайте редактирование идеальным. Это снижает риск; это не устраняет его. Для регулируемых или высокочувствительных рабочих нагрузок рассмотрите возможность хранения только хэшей и воспроизведения проблем в синтетическом пакете с утвержденными тестовыми данными.
Добавить наблюдаемость RAG как отдельный уровень
Генерация с расширенным поиском может изменить как качество, так и стоимость. Регистрация только последнего вызова модели скрывает основную причину, когда средство извлечения возвращает слишком много фрагментов, устаревших документов или нерелевантного контекста.
Для каждого этапа извлечения зафиксируйте:
<ул>Это позволяет отличить «модель ухудшилась» от «ретривер начал отправлять некачественный или избыточный контекст». Это также помогает определить рабочие процессы, в которых токены контекста доминируют в общей стоимости.
Согласовать использование шлюза с выставлением счетов поставщику услуг
Оценки шлюза доступны сразу. Данные о выставлении счетов на стороне поставщика обычно медленнее, но более достоверны. Используйте оба.
Ежедневное задание по сверке должно сравнивать строки книги шлюза с API использования поставщика, API затрат, экспортом информационной панели или экспортом счетов. Группируйте отклонения по поставщику, модели, проекту и временному окну. Отслеживайте различия отдельно для входных токенов, выходных токенов, кэшированных токенов, количества запросов и стоимости.
Общие различия при сверке
<ул>Если при сверке обнаруживается разница, избегайте незаметной перезаписи реестра. Сохраните исходную оценку, значение, согласованное поставщиком, источник сверки и код причины, если он известен.
Панели мониторинга, отвечающие на оперативные вопросы
Создавайте информационные панели с проблем читателей, а не с тщеславных показателей. Полезные представления включают в себя:
<ул>Для оповещений сочетайте технические и бизнес-сигналы. Внезапный скачок расходов арендаторов может быть более актуальным, чем небольшое глобальное увеличение задержки. Скачок резервной скорости после изменения псевдонима модели может указывать на проблему совместимости. Повторные ответы 401, 429 или 5xx могут указывать на ключевые проблемы, исчерпание квоты или нестабильность поставщика.
Минимальный процесс реализации прокси-сервера, совместимого с OpenAI
Для прокси /chat/completions порядок действий может быть простым:
request_id и контекст отслеживания.принято.Контрольный список внедрения
<ул>Заключение
Многомодельный шлюз — подходящее место для реализации наблюдения LLM, поскольку он видит запросы до того, как они достигнут какого-либо поставщика, и может привязывать бизнес-контекст, который поставщикам неизвестен. Самый сильный дизайн — это не «записывать все». Это многоуровневая модель: отслеживание выполнения, не зависящее от поставщика, надежный токен и реестр затрат для выставления счетов, аналитика арендаторов для управления, метаданные RAG для качества извлечения и ведение журнала подсказок с учетом конфиденциальности для безопасной отладки.
Начните с метаданных, переходов состояний и согласования. Добавляйте захват контента только тогда, когда будут готовы политика, хранение и контроль доступа. Эта последовательность дает разработчикам доказательства, необходимые для отладки задержки, качества и расходов, не превращая наблюдаемость в новый риск раскрытия данных.