LLM 可观测性：为什么日志里要有 prompt、工具和引用

传统 Web 服务的日志通常记录请求、状态码和耗时。但 LLM 应用的失败可能发生在提示词、检索、工具调用、模型输出或引用拼接任何一步。没有可观测性，排查只能靠猜。

LangSmith 文档把 tracing 和 observability 用于观察 LLM 应用运行过程；OpenTelemetry 也在推进生成式 AI 相关语义约定。[obs-001][obs-002]

Trace 要覆盖完整链路

一次回答至少包含这些 span：

• 用户请求。
• 检索查询。
• 检索结果。
• 模型调用。
• 工具调用。
• 输出解析。
• 最终响应。

LLM 应用的可观测性目标，是复盘“模型为什么会这样回答”，而不只是知道接口返回了 200。

概念 trace：

{
  "trace_id": "req_123",
  "spans": [
    { "name": "retrieve", "top_k": 6, "duration_ms": 120 },
    { "name": "model_call", "model": "app-default", "tokens": 1800 },
    { "name": "parse_output", "schema_valid": true }
  ]
}

指标要能指导优化

建议记录：

1. 首 token 延迟和总延迟。
2. 输入/输出 token。
3. 工具调用次数和失败率。
4. 检索命中来源。
5. 结构化输出解析失败率。
6. 用户反馈和人工修正。

隐私和调试要平衡

记录 prompt 和上下文很有用，但可能包含敏感信息。生产环境应考虑脱敏、采样、访问控制和保留周期。

综合这些资料可以推断：LLM 可观测性不是额外装饰，而是评估、调试和成本优化的前提。

参考资料

1. [obs-001] LangSmith Docs, “Observability”, https://docs.langchain.com/langsmith/observability
2. [obs-002] OpenTelemetry Docs, “Semantic conventions for generative AI systems”, https://opentelemetry.io/docs/specs/semconv/gen-ai/