Семантическая наблюдаемость LLM: как отлавливать галлюцинации

Почему LLM-приложения ломаются тихо

Когда падает микросервис, это заметно: 504 Gateway Timeout, всплеск ошибок в Datadog, PagerDuty-алерт. Но LLM-приложения умирают иначе — они ошибаются вежливо. Пользователь спрашивает: «Какой у нас возврат для enterprise-клиентов?» — система возвращает красивый, структурированный, но полностью неверный ответ про индивидуальный тариф. Для мониторинга это успех: HTTP 200, задержка в норме, токены считаются. Это «мягкий сбой» — семантическое отклонение, когда система работоспособна, но функционально сломана.

Традиционные «Золотые сигналы» (задержка, ошибки, трафик, насыщение) пропускают главный режим отказа AI — галлюцинацию. Метрики вроде Time to First Token (TTFT) важны для планирования мощностей, но не говорят, правдив ли ответ.

Семантическая наблюдаемость: новый слой метрик

Нам нужен фреймворк, который рассматривает вывод LLM как вероятностную переменную, а не детерминированную строку. Сравните:

Традиционный мониторинг:          Семантическая наблюдаемость:
HTTP 200/500                      Faithfulness Score
CPU / Memory                      Context Relevance
p99 Latency                       Answer Relevance
Error Rate                        Hallucination Rate

«Сервис жив?»                     «Ответ истинен?»

Архитектура: OpenLLMetry и Shadow Logging

Стандартные спаны OpenTelemetry не содержат полей для отладки LLM: нужен полный промпт, ответ, температура модели, версия системного промпта. Записывать это в логи — путь к перерасходу хранилища и утечке PII. Вместо этого используем OpenLLMetry — открытое расширение OpenTelemetry с семантическими конвенциями для AI. Оно автоматически инструментирует вызовы к OpenAI/Anthropic, захватывая вход и выход как атрибуты спана.

Проблема: прогон сложной оценки на каждый запрос увеличивает задержку. Решение — Shadow Logging: поток приложения возвращает ответ мгновенно, а данные трейсов отправляются в асинхронную очередь (RabbitMQ, AWS SQS). Воркеры подхватывают трейсы и выполняют семантические оценки офлайн.

from traceloop.sdk import Traceloop
from opentelemetry import trace

# Инициализация OpenLLMetry с асинхронным экспортом
Traceloop.init(app_name="finance-rag-service", disable_batching=False)
tracer = trace.get_tracer(__name__)

def generate_answer(query: str, context: str):
    with tracer.start_as_current_span("rag_generation") as span:
        # Ручная установка атрибутов (если автоинструментация не используется)
        span.set_attribute("gen_ai.prompt.0.content", query)
        span.set_attribute("gen_ai.request.model", "gpt-4o")
        
        # Стандартный вызов LLM
        response = llm_client.chat.completions.create(
            model="gpt-4o",
            messages=[
                {"role": "system", "content": "Используй только предоставленный контекст."},
                {"role": "user", "content": f"Контекст: {context}\nЗапрос: {query}"}
            ]
        )
        answer = response.choices[0].message.content
        span.set_attribute("gen_ai.completion.0.content", answer)
        return answer

Разделение оценки и инференса защищает пользовательский опыт и сохраняет данные для анализа. Если пользователь жалуется на плохой ответ, мы находим точный trace ID в Arize Phoenix и видим, какие чанки привели к ошибке.

Количественная оценка качества: RAG Triad

Измерять качество RAG-системы одним «accuracy» недостаточно. Используем RAG Triad (популяризован TruLens), который разбивает пайплайн на три измеримых отношения:

• Context Relevance: насколько релевантна извлечённая информация запросу? Если векторная БД вернула 10 чанков, но только 8-й содержит ответ — релевантность низкая.
• Groundedness: основан ли ответ только на извлечённом контексте? Обнаруживает галлюцинации, когда LLM использует свои обучающие данные вместо ваших документов.
• Answer Relevance: отвечает ли ответ на намерение пользователя?

Для автоматизации используем библиотеку RAGAS, которая реализует те же метрики: Faithfulness (аналог groundedness), Context Precision (ранжированная релевантность), Answer Relevancy. В качестве «судьи» обычно выступает более сильная модель (GPT-4o), которая оценивает метрики от 0 до 1.

Golden Set: защита от регрессий

В production мы не полагаемся только на live-сэмплинг. Поддерживаем Golden Set — курируемый JSON-файл из 50–100 критичных троек «запрос-контекст-ответ». При CI/CD прогоняем текущий пайплайн на этом наборе. Если Faithfulness падает ниже порога (например, 0.85), сборка ломается. Это предотвращает регрессии при обновлении эмбеддингов или изменении стратегии чанкования. Без Golden Set вы гадаете, лучше ли новый промпт предыдущего.

LLM-as-a-Judge в масштабе

Прогонять модель-судью на 100% трафика дорого. При 1000 запросов в секунду каждый ответ с GPT-4o разорит проект. Вместо этого реализуем sidecar-сервис оценки, который сэмплирует 5% production-трафика.

Эвристика: «судья» должен быть способнее «рабочего». Если production-модель — Llama 3-8B, судья вроде Claude 3.5 Sonnet или GPT-4o — разумный выбор. Промпт для судьи должен использовать Chain-of-Thought (CoT) для точности. Заставляем судью извлекать конкретные цитаты из контекста перед вынесением вердикта.

from pydantic import BaseModel, Field
from typing import List

class RAGEvaluationSchema(BaseModel):
    # Порядок полей важен: сначала evidence и reasoning, потом score
    supporting_evidence: List[str] = Field(..., description="Прямые цитаты из контекста")
    reasoning: str = Field(..., description="Пошаговая логика для оценки")
    score: float = Field(..., description="Оценка от 0 до 1")

# Пример промпта судьи:
# «Оцени faithfulness ответа. Сначала перечисли все утверждения в ответе.
# Для каждого утверждения найди подтверждающее предложение в контексте.
# Если предложения нет — это галлюцинация.»

Принудительный структурированный вывод через Pydantic делает данные оценки машиночитаемыми. Мы агрегируем оценки в time-series БД и видим, вызвало ли обновление модели всплеск галлюцинаций.

Операционализация обратной связи

Финальный шаг — перенести семантические метрики из ноутбука исследователя в дашборд SRE. Используем кастомный Prometheus exporter, который собирает результаты от воркеров оценки. Это позволяет визуализировать Hallucination Rate рядом с CPU и Memory в Grafana.

Настройка «семантических алертов» — фундаментальный сдвиг в философии on-call. Вместо алертов только на 5xx, мы триггерим PagerDuty, когда средний Faithfulness падает ниже 0.8 за 5-минутное окно. Это часто ловит проблемы, которые пропускают системные метрики: повреждённый векторный индекс или эмбеддинг-провайдер, начавший возвращать нулевые векторы.

Цикл обратной связи:

Запрос пользователя → RAG-пайплайн → Ответ
                        ↓              ↓
                   OTel Trace    Eval Sidecar
                        ↓              ↓
                     Prometheus → PagerDuty

Также интегрируем пользовательскую обратную связь на уровне спанов. Когда пользователь нажимает «палец вниз» в UI, фронтенд отправляет trace ID в бэкенд наблюдаемости. Мы коррелируем эти ручные сигналы с автоматическими оценками RAG Triad. Если автоматический судья считает ответ «grounded», но пользователь его отвергает — мы нашли пробел в логике оценки. Это непрерывное уточнение превращает наблюдаемость из пассивного мониторинга в активный двигатель улучшения модели.

Практический вывод

Начните с малого: соберите Golden Set из 50 примеров, добавьте RAGAS-оценку в CI/CD, настройте Shadow Logging через OpenLLMetry. Как только увидите первый алерт по Hallucination Rate, вы поймёте, что без семантической наблюдаемости LLM-приложения — это чёрный ящик. Инжиниринг для LLM означает принятие того, что вывод никогда не будет идеальным, но он всегда может быть измеримым.