04. 大模型系统为什么特别强调日志、监控和 Tracing？

简单回答

因为大模型系统有三个传统系统不具备的特性：输出不确定（同一输入可能产生不同输出）、推理链路不透明（中间推理过程是黑盒）、成本按 token 计（需要精细追踪用量）。这导致传统的"看日志排查 bug"方式失效，必须有完整的 Prompt-Response-Token-Latency 的全链路记录才能定位问题。

详细解释

传统系统 vs 大模型系统的调试差异

在传统系统中，同一个输入必然产生同一个输出（确定性系统），bug 是可复现的。但大模型的输出受温度参数、采样策略、上下文内容等多重因素影响，"用户投诉回答不对"时你可能根本无法复现当时的输出。这就要求每一次请求都必须完整记录：发送给模型的完整 Prompt（包括 system prompt、历史消息、RAG 结果）、模型的完整 Response、使用的模型和参数（temperature、top_p 等）、token 消耗（input tokens + output tokens）、延迟分解（Prompt 组装耗时、推理耗时、后处理耗时）。

日志的特殊要求

大模型应用的日志需要记录的信息量远超传统应用。一条请求日志至少要包含：request_id / trace_id、session_id（关联会话上下文）、完整的 Prompt（可能很长，需要考虑存储）、完整的 Response、模型名 + 版本 + 参数、input_tokens + output_tokens + total_tokens、latency 分段（TTFT、TPS、总耗时）、是否触发 Guardrails 及原因。

如果是 RAG 场景，还需要记录：检索 query、返回的文档 chunks、rerank 分数。如果是 Agent 场景，需要记录每一步的 thought → action → observation 链。

日志存储上要注意，Prompt 和 Response 可能很长（几千到几万字），直接写入关系型数据库不合适，通常存对象存储或日志系统（Elasticsearch、ClickHouse），用 trace_id 关联。

监控指标

核心指标分三类。性能类：TTFT（Time To First Token，首 token 延迟）、TPS（Tokens Per Second，生成速度）、P50/P99 总延迟、推理队列深度。质量类：Guardrails 拦截率、用户反馈（点赞/点踩率）、RAG 召回为空的比率、格式错误率。成本类：每日 token 消耗、每用户 token 消耗、API 调用失败率。

这些指标需要做成实时 Dashboard，而且要设告警阈值。比如 P99 延迟超过 30 秒要告警，Guardrails 拦截率突然飙升要告警（可能 Prompt 模板被改坏了）。

Tracing

大模型应用的链路往往很长：用户请求 → Prompt 构建 → RAG 检索 → Rerank → Prompt 组装 → 模型推理 → 后处理 → Guardrails → 返回。如果中间某个环节出了问题，没有 Tracing 很难定位。

OpenTelemetry 是目前最主流的 Tracing 框架。也有一些专门为 LLM 应用设计的可观测性工具：LangSmith（LangChain 生态）、Langfuse（开源）、Phoenix（Arize AI）。这些工具除了标准的 Tracing 功能，还提供了 Prompt 版本管理、token 统计、质量评估等 LLM 特化的功能。

为什么说可观测性是"基础设施"

大模型应用的迭代核心是 Prompt 迭代和上下文优化。如果没有完整的日志和 Tracing，你无法回答"为什么这个 case 回答不好"这个最基本的问题。是 Prompt 写得不好？RAG 召回了错误的文档？上下文太长被截断了？模型本身的能力不足？每一种原因需要不同的优化策略，而定位问题完全依赖可观测性数据。

面试时可以这样答

大模型系统强调可观测性，核心原因是它和传统系统有三个本质区别。第一，输出不确定——同样的输入可能产生不同的输出，bug 不可复现，所以每次请求必须完整记录 Prompt、Response 和参数。第二，链路长且黑盒——从 RAG 检索到 Prompt 组装到模型推理到后处理，任何环节都可能出问题，没有 Tracing 根本没法定位。第三，成本按 token 计——需要精确追踪用量才能做计费和预算控制。

日志上，每条请求至少要记录完整 Prompt、完整 Response、模型参数、token 消耗和延迟分段。RAG 场景还要记检索 query 和返回的 chunks，Agent 场景要记每一步的 thought-action-observation 链。

监控指标分三类：性能的 TTFT、TPS、P99 延迟；质量的 Guardrails 拦截率和用户反馈；成本的 token 消耗。这些都需要实时 Dashboard 和告警。

工具上现在有 Langfuse、LangSmith 这些 LLM 专用的可观测性平台，比纯 OpenTelemetry 更贴合大模型场景。

常见追问

1. Prompt 日志很长、数据量很大，存储成本怎么控制？
2. 怎么从日志中自动发现"回答质量差"的 case？
3. LangSmith 和 Langfuse 的区别是什么？怎么选？