Что такое «prompt observability» (мониторинг эффективности промптов в production)?

Краткий тезис

Prompt observability — это систематический подход к мониторингу и анализу поведения LLM-приложений в production, сфокусированный на каждом отдельном промпте. Он включает сбор метрик качества (faithfulness, answer relevance), производительности (latency, cost) и пользовательского опыта (feedback, rate|completion rate). Цель — быстро выявлять деградацию промптов после изменений, отслеживать регрессии и принимать решения на основе данных, а не догадок.

1. Зачем нужна prompt observability

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

• Изменение распределения входных запросов (data drift) — пользователи задают вопросы, которых не было в тестовом наборе.
• Дрейф контекста — для RAG-систем: содержимое документов меняется со временем, и старые промпты становятся неэффективными.
• Обновление модели провайдера — API-версия может незаметно измениться (например, GPT-4 → gpt-4-turbo-2024-04-09) и изменить поведение.
• Человеческий фактор — команда правит промпты в репозитории, но забывает проверить регрессию метрик.

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

2. Ключевые метрики

Метрики делятся на три категории. Черновик называет faithfulness, answer relevance, latency, cost, user feedback, completion rate — это основа. Расширим.

2.1 Метрики качества (Quality Metrics)

• Faithfulness (фактологическая точность) — насколько ответ LLM соответствует предоставленному контексту. Обычно оценивается от 0 до 1 с помощью LLM-асессора (другая LLM или специализированная модель). Для RAG особенно критична.
• Answer relevance (релевантность ответа) — насколько ответ покрывает запрос пользователя. Измеряется классификатором или LLM.
• Context relevance (релевантность контекста) — для RAG: насколько извлечённые документы релевантны запросу. Часто вычисляется через cosine similarity эмбеддингов.

2.2 Метрики производительности (Performance Metrics)

• Latency (задержка) — время от отправки запроса до получения полного ответа. Измеряется в миллисекундах, важно отслеживать p50, p95, p99.
• Cost (стоимость) — количество токенов (входных и выходных) × тариф модели. Критично для production при масштабировании.
• Completion rate (доля успешных завершений) — процент запросов, которые не упали с ошибкой (timeout, rate limit, server error).

2.3 Метрики пользовательского опыта (User Experience Metrics)

• User feedback (обратная связь) — лайки/дизлайки, оценки «палец вверх/вниз», звёзды.
• Completion rate (с точки зрения UX) — не просто успешные завершения, а завершения, после которых пользователь не покинул сессию.
• Session-level metrics — количество диалогов, retention, средняя длина диалога.

Таблица метрик с порогами алертов

3. Инструменты для prompt observability

3.1 LangSmith (от LangChain)

• Логирует каждый промпт, хранит метаданные: версия, модель, температура, время выполнения.
• Встроенные evaluator'ы: faithfulness, answer relevance, toxicity.
• Дашборд для сравнения версий промптов по метрикам.
• Алерты при падении метрик ниже порога.
• Поддерживает ручное тегирование (A/B-тесты).

3.2 Open-source стек: Grafana + Prometheus + OpenTelemetry

• Собираем latency, количество запросов, токены, ошибки через OpenTelemetry SDK.
• Prometheus хранит временные ряды.
• Grafana визуализирует: панели latency, throughput, cost per request, ошибки.
• Можно добавить кастомные эндпоинты для метрик качества.

3.3 Weights & Biases (WandB) / MLflow

• Используются для отслеживания экспериментов, но можно подключить к production для логирования версий промптов и метрик.

3.4 Собственное решение на ClickHouse

• Middleware пишет каждый запрос/ответ в ClickHouse.
• Фоновый воркер (Celery) вычисляет метрики качества (вызов дешёвой LLM для оценки).
• SQL-агрегации строят дашборд в Grafana.

Выбор инструмента зависит от масштаба: для стартапа хватит LangSmith, для enterprise — свой стек.

4. Как организовать мониторинг в production

4.1 Сбор логов (logging)

Каждый запрос к LLM должен содержать:

{
  "id": "req_12345",
  "timestamp": "2024-03-15T10:30:00Z",
  "prompt_version": "v2.3",
  "model": "gpt-4-turbo",
  "input": "Какой сегодня курс доллара?",
  "output": "Курс доллара составляет 90 рублей.",
  "context": ["doc1.txt", "doc2.txt"],
  "latency_ms": 1200,
  "tokens_in": 45,
  "tokens_out": 12,
  "user_id": "user_abc",
  "user_feedback": null
}

4.2 Агрегация метрик

Агрегируем по времени (5-минутные окна), по версии промпта, по модели, по пользовательской когорте.

Пример SQL (ClickHouse):

SELECT 
    prompt_version,
    avg(latency_ms) as avg_latency,
    quantile(0.95)(latency_ms) as p95_latency,
    sum(tokens_in + tokens_out) * 0.000002 as total_cost,
    countIf(user_feedback = 'negative') / count() as negative_feedback_rate
FROM prompt_logs
WHERE timestamp > now() - INTERVAL 1 HOUR
GROUP BY prompt_version

4.3 Дашборды

В LangSmith дашборды уже встроены. Для Grafana создаём кастомный:

• Row 1: Latency (p50, p95, p99) за последние 24 часа (line chart)
• Row 2: Cost per prompt version (stacked bar)
• Row 3: Faithfulness и Answer Relevance over time (line chart)
• Row 4: Completion rate и Negative feedback rate

4.4 Алерты

Настраиваем уведомления в Slack, Telegram или PagerDuty:

• Faithfulness < 0.85 → оповещение разработчика
• Completion rate < 95% → эскалация дежурному
• P95 latency > 3000 ms → авто-откат прошлой версии промпта

5. Как использовать observability для улучшения системы

• A/B-тестирование промптов: запускаем новую версию на 5–10% трафика, сравниваем метрики качества, стоимости и задержки.
• Детекция регрессий: при каждом деплое новой версии автоматически прогоняем тестовый набор запросов и сравниваем faithfulness с baseline.
• Оптимизация стоимости: находим промпты, генерирующие слишком длинные ответы, добавляем инструкцию «отвечай кратко».
• Выявление проблем контекста: если faithfulness низок, а context relevance высок — значит LLM игнорирует контекст; если context relevance низок — плохой retrieval.

6. Пример кода: логирование промпта через middleware на FastAPI

from fastapi import FastAPI, Request
import time
import json
import logging

app = FastAPI()
logger = logging.getLogger("prompt_logger")

@app.middleware("http")
async def log_prompt_metrics(request: Request, call_next):
    body = await request.body()
    start = time.time()
    response = await call_next(request)
    latency_ms = (time.time() - start) * 1000

    if request.url.path == "/llm" and request.method == "POST":
        log_data = {
            "timestamp": time.time(),
            "input": body.decode(),
            "latency_ms": latency_ms,
            "status_code": response.status_code,
        }
        logger.info(json.dumps(log_data))

    return response

7. Best practices

• Логируйте всё, оценивайте асинхронно: не блокируйте поток ответа вызовом LLM-асессора — используйте очередь (Celery, Kafka).
• Сэмплируйте: если трафик миллионы запросов в день, оценивайте 10–20% — этого достаточно для статистики.
• Используйте дешёвую модель для оценки: GPT-4o-mini или локальная модель (Llama 8B) снижают стоимость мониторинга.
• Версионируйте не только код промпта, но и метаданные: модель, temperature, top_p, системный промпт.
• Валидируйте метрики качества: LLM-асессор может быть смещён; раз в месяц проводите человеческую оценку на выборке.

8. Вызовы и ограничения

• Субъективность оценки: faithfulness и answer relevance зависят от того, какая LLM выступает в роли судьи — разные модели могут давать разные оценки.
• Шум в обратной связи: пользователи редко ставят лайки/дизлайки, выборка нерепрезентативна.
• Стоимость мониторинга: если оценивать каждый запрос дорогой LLM, затраты на observability могут превысить затраты на сами ответы.
• Масштабирование: при 10k+ запросов/сек нужно быстрое хранилище (ClickHouse) и продуманная агрегация.

Пет-проект для закрепления

Задача: Разработать систему prompt observability для RAG-бота, отвечающего на вопросы по корпоративной документации.

Инструменты: Python, FastAPI, Qdrant (векторная БД), ClickHouse (логи), Grafana + Prometheus, LangSmith (опционально).

Шаги:

1. Реализовать RAG-бот с эндпоинтом /ask.
2. Добавить middleware, которое сохраняет в ClickHouse: request_id, timestamp, prompt_version, user_id, input, output, context_ids, latency, tokens.
3. Написать воркер (Celery), который раз в минуту проверяет непроверенные запросы и вычисляет faithfulness через GPT-4o-mini.
4. Настроить Prometheus-метрики: latency histogram, counter запросов, gauge для последнего faithfulness.
5. Создать Grafana-дашборд с панелями latency, cost, faithfulness, negative feedback.
6. Настроить алерт в Slack при faithfulness < 0.8.

Ожидаемый результат:

• Дашборд, на котором видно, как меняются метрики при изменении промпта (например, смена инструкции).
• Автоматическое уведомление, если качество ответов падает.
• История версий промптов с привязкой к метрикам.

Связь с другими вопросами

Навигация

• Предыдущий: 806
• Следующий: 808
• Индекс: 00. Индекс разборов