⚙️ Корпоративная observability-платформа для Amazon Quick: мониторинг AI-ассистентов в масштабе предприятия

AWS представила готовое решение для централизованного наблюдения за корпоративной AI-платформой Amazon Quick. Когда на платформе работают сотни и тысячи пользователей, бизнесу нужна прозрачность: кто использует AI, довольны ли пользователи ответами, какие функции наиболее востребованы. Без единой системы observability эти данные разбросаны по разным сервисам AWS и сложны для анализа.

Решение собирает логи взаимодействия из Amazon CloudWatch vended logs (чат-конversации, обратная связь, использование агентов и индексного хранилища) и события AWS CloudTrail в защищённое data lake на Amazon S3. Данные доступны через Amazon Athena для SQL-запросов, дашборды Quick Sight и кастомного чат-агента Quick для вопросов на естественном языке.

Архитектура включает CloudWatch subscription filters → Amazon Data Firehose с Lambda-трансформацией → S3 data lake. CloudTrail-события маршрутизируются через EventBridge. AWS Glue Data Catalog управляет метаданными, AWS Lake Formation — правами доступа на уровне таблиц и колонок. Все данные шифруются customer managed KMS-ключом с автоматической ротацией.

Для развёртывания потребуются AWS аккаунт с подпиской Amazon Quick, Python 3.9+, Node.js 20+, AWS CDK и AWS CLI V2. Решение покрывает четыре ключевые метрики enterprise-уровня: adoption (внедрение), satisfaction (удовлетворённость), cost (стоимость) и governance (управление).

#AI #AWS #AmazonQuick #Observability #EnterpriseAI #MLOps

⚙️ Amazon Bedrock AgentCore Observability: отладка production-агентов с новым инструментом мониторинга

Amazon представил AgentCore Observability — набор инструментов для отладки AI-агентов в production. Проблема в том, что агенты могут выдавать правдоподобные, но неверные ответы, уходить в бесконечные циклы рассуждений или выбирать неправильные инструменты без генерации ошибок. Стандартные логи и метрики не фиксируют процесс принятия решений.

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

Особенно полезно для диагностики трёх типов отказов: quality (галлюцинации, неверные расчёты), reliability (ошибки авторизации, потеря контекста сессии) и efficiency (высокая задержка, избыточное потребление токенов). Интеграция с Amazon CloudWatch и OpenTelemetry даёт готовые дашборды и алерты.

#AI #AWS #Bedrock #Observability #MachineLearning

⚙️ Deepgram расширяет observability для Amazon SageMaker AI с помощью Enhanced Metrics

Deepgram представила два новшества для своих speech-моделей на SageMaker AI — Deepgram Enhanced Metrics и поддержку Prometheus/OpenTelemetry. Решение закрывает давний пробел self-hosted распознавания речи: стандартные метрики показывали только доступность эндпоинта и число запросов, но не давали информации о биллинге, использовании функций и загрузке GPU.

Deepgram Enhanced Metrics публикует данные о потреблении и списаниях прямо в Amazon CloudWatch через Embedded Metric Format. Контейнер пишет метрики в stdout, а CloudWatch Logs автоматически превращает их в классические метрики. Для этого не нужны агенты, sidecar-контейнеры и дополнительные IAM-разрешения. Ключевая метрика — ConsumedUnits: это те же значения, которые используются для метеринга AWS Marketplace, поэтому билл можно сверять вплоть до модели и транспорта. Второй компонент — Prometheus-метрики движка и per-GPU метрики, которые собираются через SageMaker AI detailed observability и доступны через PromQL в CloudWatch, Grafana и других совместимых инструментах.

Важно, что всё работает в условиях network isolation для AWS Marketplace model packages: контейнеру не нужно открывать исходящие соединения, а данные остаются внутри аккаунта клиента. Это позволяет совмещать требования к residency и compliance с прозрачным мониторингом инференса.

#AI #Deepgram #SageMaker #AWS #Observability

⚙️ Свой LLM-прокси: реальные логи вместо красивых графиков провайдера

В блоге, разошедшемся по Hacker News, автор спорит с подходом «просто сидеть в веб-интерфейсе провайдера»: панели аналитики показывают милых маскотов и абстрактные картинки вместо временных рядов по токенам, по которым инженер мог бы принимать решения. Экспорт в OTel есть, но это лишь один аргумент из шести.

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

Практическая ценность: по логам автор находит причину cache miss в сессии кодинга примерно за 20 секунд, а API прокси позволяет это автоматизировать. Вывод - инструментировать инференс и владеть путём данных, а не доверять статистике подписки.

🎨 qvabo.studio/tg · картинки и видео

#Tech #LLM #AI #Development #Observability #MCP