← Вернуться в центр знаний

Наблюдаемость GenAI: какие трассы и метрики нужны без утечки промптов

Обычный мониторинг покажет, что API отвечает медленно, но не объяснит, почему ассистент выбрал неверный документ, вызвал лишний инструмент или внезапно стал дороже. Для GenAI нужна единая цепочка технических и прикладных сигналов.

К
Команда ИИ и инфраструктуры ВирТЭКАрхитектура вычислительных платформ

Начните с карты операции

Один пользовательский запрос может включать проверку доступа, поиск, ранжирование, несколько обращений к модели и вызов бизнес-инструмента. Представьте эти шаги отдельными участками одной трассы. Тогда задержку можно отнести к конкретному провайдеру, индексу или инструменту, а не к безличной метрике «ИИ работает медленно».

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

Не записывайте содержание по умолчанию

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

Фильтрация выполняется до отправки данных коллектору. Маскировка после попадания в общий журнал уже не устраняет утечку.

Соедините надёжность, качество и стоимость

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

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

Сделайте телеметрию частью приёмки

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

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

Нужна архитектура
под вашу задачу?

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

Обсудить с инженером↗︎