Observability в 2026: как реально наблюдать LLM-приложение

Короткая версия

Production observability в 2026 держится на пяти слоях:

1. Traces / spans
2. Usage / cost / latency
3. Context and tool visibility
4. Scores / feedback / eval link
5. Alerting и privacy controls

Что логировать обязательно

• trace_id, session_id, user_id или анонимный actor key;
• provider, model, model version;
• prompt version / prompt registry id;
• input, output, token usage, cached tokens;
• retrieval docs, tool calls, tool latency;
• business outcome и quality score;
• user feedback и refusal / guardrail events.

Пользователь пишет: «бот стал отвечать медленно и хуже». Что нужно увидеть в трейсе?

1. Наблюдать нужно не запрос, а workflow

В 2026 многие LLM-приложения уже не состоят из одного model call. Даже “простой чат” обычно включает:

• input normalization;
• routing;
• retrieval;
• prompt assembly;
• 1+ model calls;
• tool calls;
• output validation;
• scoring / feedback writeback.

Если это не размечено как trace со spans, вы не сможете ответить на базовые production-вопросы:

• что именно стало медленнее;
• какой prompt version ухудшил quality;
• на каком шаге выросла стоимость;
• где ломается structured output;
• какие tools чаще всего дают retries;
• какие retrieved chunks реально коррелируют с хорошим ответом.

2. Современный trace для LLM

Хороший trace в LLM-системе должен связывать техническую и продуктовую сторону.

Минимальный состав:

Это и есть разница между “мы что-то логируем” и “у нас реально есть observability”.

3. В 2026 observability = traces + scores

Старые статьи про observability часто останавливались на трёх вещах:

• latency;
• cost;
• errors.

Этого уже мало. Для LLM-систем нужны ещё scores:

• user thumbs up / down;
• LLM-as-judge score;
• factuality / groundedness score;
• business score;
• policy / safety labels.

Практически это означает, что observability и eval больше нельзя разводить по разным мирам. Хорошая система связывает:

• production trace;
• evaluation result;
• regression after release;
• feedback loop в dataset.

4. Что алертить на самом деле

Алерты по средней latency или общему error rate уже недостаточны. В LLM-приложениях полезнее алертить по комбинациям:

• p95 latency по конкретному route;
• резкий рост cost per successful outcome;
• падение judge-score после нового prompt version;
• скачок schema invalid / retry rate;
• рост tool timeout rate;
• рост refusal rate;
• просадка cache hit rate;
• рост retrieval miss / low-relevance pattern.

5. Privacy и data minimization

В 2026 observability почти всегда упирается не только в tooling, но и в data governance.

Что нужно решать заранее:

• логировать ли raw prompts и raw outputs целиком;
• как маскировать PII;
• где хранить conversations и tool arguments;
• как разделять dev/staging/prod data;
• кто имеет доступ к traces;
• как долго хранить sensitive spans.

Практический стандарт:

• redact PII до записи в trace или на ingestion layer;
• хранить full payload только там, где это действительно нужно;
• держать sampling rules для low-risk / high-volume traffic;
• не писать секреты, bearer tokens и DB results в spans.

6. Langfuse, LangSmith, Helicone: не одинаковые классы инструментов

Langfuse

Langfuse в 2026 хорош, когда нужен:

• vendor-neutral tracing;
• scores / evaluations рядом с trace;
• prompt management в том же контуре;
• self-hosted или open-source control.

Это хороший выбор, если observability нужна как собственная платформа, а не как thin addon к одной framework-экосистеме.

LangSmith

LangSmith особенно силён, если ваш стек уже живёт в LangChain / LangGraph.

Сильные стороны:

• глубокая trace visualization для agent graphs;
• datasets и eval workflow рядом с observability;
• alerting integrations;
• удобная диагностика trajectory / tool use / graph state.

Это не самый нейтральный вариант, но очень сильный, если вы уже внутри их оркестрационного слоя.

Helicone

Helicone остаётся удобным вариантом для gateway-first observability:

• быстрое включение через proxy / gateway;
• usage, spend и provider analytics почти без переписывания кода;
• кэш и policy-layer рядом с метриками.

Но gateway не заменяет глубокий app trace. Он хорошо закрывает ingress и provider-level telemetry, но не даёт автоматически весь ваш internal workflow.

OpenTelemetry

OpenTelemetry важен не как “ещё один продукт”, а как общий язык телеметрии. GenAI semantic conventions позволяют не зашивать всё намертво под одного вендора observability.

Это особенно полезно, если у вас уже есть:

• Datadog / Grafana / Tempo / Honeycomb;
• общий OTel pipeline;
• security и compliance требования на единый telemetry substrate.

7. Что чаще всего ломают команды

Самые типичные ошибки:

• логируют только final response;
• не связывают feedback со span/trace;
• не пишут prompt version;
• не маркируют retrieved documents и tool calls;
• алертят среднюю latency вместо route-specific p95;
• хранят слишком много raw sensitive data;
• не умеют разделить “provider issue” и “app orchestration issue”.

8. Practical stack для production

Хороший baseline в 2026 обычно выглядит так:

1. OTel или vendor SDK на уровне приложения.
2. Trace spans для retrieval, prompt assembly, model call, tools, validators.
3. Quality scores и feedback с привязкой к trace_id.
4. Prompt registry/version links.
5. Route-level alerts.
6. Privacy filters и sampling policy.

Это уже даёт гораздо больше ценности, чем “поставили одну красивую observability-панель”.

Langfuse: trace + scores

from langfuse import observe, get_client


@observe()
def answer_ticket(user_id: str, question: str) -> str:
    langfuse = get_client()
    langfuse.update_current_trace(
        user_id=user_id,
        session_id=f"support:{user_id}",
        tags=["prod", "support"],
        metadata={"route": "support_chat", "prompt_version": "v18"},
    )

    docs = retrieve_docs(question)

    langfuse.update_current_span(
        input=question,
        metadata={
            "retrieved_doc_ids": [d["id"] for d in docs],
            "retrieval_count": len(docs),
        },
    )

    answer = generate_answer(question, docs)

    langfuse.score_current_trace(name="judge_score", value=0.82)
    langfuse.score_current_trace(name="grounded", value=1)

    return answer

OpenTelemetry: GenAI span

from opentelemetry import trace

tracer = trace.get_tracer("llm-app")


with tracer.start_as_current_span("llm.generate") as span:
    span.set_attribute("gen_ai.system", "openai")
    span.set_attribute("gen_ai.request.model", "gpt-5.4-mini")
    span.set_attribute("gen_ai.usage.input_tokens", 1820)
    span.set_attribute("gen_ai.usage.output_tokens", 312)
    span.set_attribute("app.prompt.version", "support-v18")
    span.set_attribute("app.route", "billing_refund")

    response = call_model(...)

    span.set_attribute("gen_ai.response.finish_reasons", "stop")

Helicone: gateway-level tracing

from openai import OpenAI

client = OpenAI(
    base_url="https://oai.helicone.ai/v1",
    api_key="YOUR_PROVIDER_KEY",
    default_headers={
        "Helicone-Auth": "Bearer YOUR_HELICONE_API_KEY",
        "Helicone-Property-Route": "support_chat",
        "Helicone-Property-Prompt-Version": "v18",
        "Helicone-User-Id": "user_123",
    },
)

Route-level alerting idea

def should_alert(route_metrics: dict) -> bool:
    return (
        route_metrics["p95_latency_ms"] > 6000
        or route_metrics["judge_score_avg"] < 0.7
        or route_metrics["schema_retry_rate"] > 0.05
        or route_metrics["cost_per_success_usd"] > 0.04
    )

Практический аудит

У нас уже есть логи prompt/response и дневной spend dashboard. Чего не хватает для нормальной LLM observability?

Проверьте себя