[📌 Часть 1/2] — 12 июля 2026 г. в 21:35:48.932
[📌 Часть 1/2] Semantic Drift-мониторинг инференса: от логирования прокси до автоотката через векторные пороги Традиционные метрики (latency, QPS, time-to-first-token) не фиксируют деградацию качества ответов. Модель может отдавать токены быстро, но начинать галлюцинировать или терять контекст после обновления веса или смены промпта. Решение — real-time semantic drift monitoring поверх векторного хранилища. Архитектура строится на трёх слоях: захват трафика через sidecar-прокси, асинхронное вычисление embedding-векторов для пар prompt/response и сравнение с baseline-корпусом через cosine similarity. При превышении порога дисперсии Prometheus генерирует алерт, который ловит Flagger для автоматического rollback канареечного деплоя. Логирование нельзя делать синхронно в основном потоке инференса — это убьёт p95 latency. Выносим захват на уровень Ingress или Service Mesh. Envoy filter перехватывает HTTP/2 фреймы, парсит JSON payload и шлёт нормализованные события в Kafka topic inference-logs-v1. В топике храним только хеш промпта (для дедупликации), timestamp, model_version, raw_prompt и raw_completion. Для compliance добавляем simple regex scrubber для PII перед записью. Потребитель — лёгкий Go-сервис или python worker с sentence-transformers, который батчит запросы в Qdrant. Индекс строится с HNSW (m=16, ef=32) для баланса скорости поиска и памяти. Базовый корпус формируется из первых 5000 успешных ответов после релиза. Вычисление drift сводится к rolling average cosine similarity между текущим ответом и centroid baseline-кластера. Если метрика падает ниже динамического порога (обычно 0.82–0.86 для domain-specific моделей), срабатывает webhook. Важно не использовать статические пороги — разные эндпоинты имеют разную семантическую плотность. Тонкая настройка выполняется через A/B тесты: канарейка получает 5% трафика, drift-метрика агрегируется за 10 минутное окно, после чего Flagger принимает решение о promote или rollback. GPU на embedding-сервисе не обязательны — ONNX runtime с CPU inference и batch size 64 справляется с ~2k req/s при субсекундных задержках.