前端学 LLM

可观测性：日志、Trace、监控与反馈闭环

AI 应用的线上问题很少只是一句“模型答错了”。

一个错误答案背后可能是权限过滤漏了文档、检索召回了旧版本、工具返回超时、prompt 版本切换、缓存命中过期结果、模型输出被截断，或者用户本来期待的是人工审批而不是自动建议。可观测性的目标，是让团队能从最终结果一路追溯到每个关键阶段，并把线上反馈变成可复现、可评估、可修复的样本。

1. 提出问题

在企业知识库助手里，员工会询问报销政策、合同条款、产品限制和客户状态。系统先检查用户权限，再检索内部文档，必要时调用 HR、CRM 或订单工具，最后生成带引用的回答。

上线后，产品经理收到几类反馈：

  • 有用户说答案引用了过期政策。
  • 有用户说回答很慢，但后端服务并没有 5xx。
  • 财务发现某些租户成本异常高。
  • 客服发现同类问题有时回答准确，有时缺少关键引用。
  • 运维看到模型供应商偶发 429，但不知道影响了多少业务请求。

如果系统只保存最终问题和答案，排查会陷入死角。团队不知道那次请求用了哪个 prompt 版本、检索到了哪些片段、工具有没有超时、缓存有没有命中、模型是否走了 fallback，也不知道用户点踩究竟对应哪类失败。

生产问题仅有最终日志时的困境需要补充的观测信息
引用过期不知道文档版本检索结果、文档版本、知识库索引版本
延迟升高不知道慢在哪一步trace 阶段耗时、TTFT、工具耗时
成本异常不知道是谁花的租户、功能、模型、token、重试、缓存
质量波动不知道版本差异prompt、模型、参数、路由和评估标签
用户差评不知道失败类型反馈原因、人工修改、样本归因

2. 分析问题

AI 可观测性要覆盖三类对象：模型调用、上下文链路和业务结果。

分析项具体判断工程含义
问题类型检索、生成、工具调用、路由、降级、反馈日志不能只围绕模型 API
收益来源快速定位问题、降低排查成本、支撑评估迭代可观测性是质量改进的前提
失败代价错答无法复盘、成本无法归因、回滚无依据核心链路必须记录版本和 trace
人工位置标注失败原因、确认高风险输出、参与事故复盘反馈需要结构化进入样本库

模型适合做的是生成答案、解释工具结果、对反馈进行辅助聚类。系统必须做的是记录、关联、聚合、告警和权限控制。

最小可用观测字段包括：

  • 请求维度：requestId、sessionId、tenantId、userRole、feature、environment。
  • 版本维度：promptVersion、model、modelParams、retrievalConfigVersion、toolVersion、schemaVersion。
  • 输入维度：输入长度、上下文摘要、知识片段 ID、工具参数摘要。
  • 输出维度：输出长度、结构化校验结果、引用 ID、最终状态。
  • 性能维度：TTFT、总耗时、检索耗时、工具耗时、队列等待、重试次数。
  • 成本维度：输入 token、输出 token、缓存命中、模型费用、工具费用或估算成本。
  • 错误维度：错误阶段、错误码、是否可重试、fallback 类型、人工接管状态。

日志还要处理隐私和权限。生产日志不应该无脑保存完整 prompt、完整工具返回和用户敏感数据；更稳妥的做法是记录摘要、哈希、引用 ID、脱敏片段和受控回放入口。

3. 列举方案

可观测性方案可以从简单日志逐步升级到完整反馈闭环。

第一层是基础日志。试点期至少要知道一次请求用了什么模型、多少 token、哪个 prompt 版本、成功还是失败。简单 prompt 足够的场景，也至少需要这层。

第二层是结构化事件。把一次请求拆成 context_built、retrieval_completed、tool_called、model_started、model_completed、fallback_used、response_persisted 等事件。这样能看见中间状态。

第三层是 trace。每个阶段成为 span，记录耗时、输入输出摘要、错误和父子关系。trace 不是为了炫技，而是为了回答“慢在哪里、贵在哪里、错在哪里”。

第四层是指标监控。把日志和 trace 聚合成可运营指标：成功率、错误率、TTFT、P95 延迟、单位任务成本、缓存命中率、fallback 率、引用缺失率、人工采纳率、用户差评率。

第五层是告警与降级触发。当模型 429、工具 P95 超时、成本预算接近上限、缓存命中率异常下降或引用缺失率上升时，系统应该告警，并可触发路由、限流、关闭工具或转人工。

第六层是反馈闭环。用户反馈、人工修改、质检结果和事故样本要被标注成失败类型，并进入评估集。没有这一步，可观测性只能帮助救火，不能帮助系统变好。

4. 决策判断

场景条件推荐方案不推荐方案判断理由额外成本
内部低风险试点基础日志 + 人工抽样建完整观测平台样本少，先确认失败类型字段设计、人工复盘
涉及检索引用检索事件 + 文档版本 + 引用监控只保存最终答案引用错误需要追溯证据来源索引版本和片段记录
涉及工具调用tool span + 参数摘要 + 结果摘要 + 错误阶段把工具结果混进 prompt 日志工具失败和模型失败要区分工具审计和脱敏
用户抱怨慢TTFT、总耗时、阶段耗时监控只看服务端总耗时感知延迟和链路瓶颈不同trace 埋点和看板
成本不可解释token 和费用按租户、功能、版本归因只看供应商总账单成本优化需要定位来源计费映射和报表
质量需要持续迭代反馈标注 + 样本库 + 回归评估只统计点赞率反馈要变成可复现样本标注规范和评审机制
高风险业务输出审计日志 + 回放 + 人工确认记录只记录模型请求需要责任边界和事故复盘权限、脱敏、保留策略

几个反模式需要明确避免。

第一，只记录自然语言日志。自由文本日志很难聚合、告警和归因。关键字段必须结构化，尤其是版本、阶段、错误、token 和成本。

第二，把完整敏感上下文直接写入日志。这样排查方便，但会制造新的数据风险。日志要有脱敏、访问控制、保留周期和最小必要原则。

第三，只监控技术成功率。HTTP 200 不代表 AI 成功。引用缺失、schema 校验失败、人工不采纳、用户点踩和 fallback 过高都应该进入质量指标。

第四，反馈没有归因。用户说“不好用”不能直接指导修复。需要标注为检索缺失、事实错误、格式错误、权限问题、工具失败、延迟过长、产品预期不符等类型。

5. 结论收束

可观测性不是上线后的附加项，而是 LLM 应用能否进入生产的基本条件。低风险功能可以先做基础日志；一旦涉及检索、工具、成本归因或用户反馈，就要把 trace、指标、告警和反馈闭环纳入设计。

上线前检查清单：

  • 场景边界：每个 AI 功能是否有明确 feature 名、租户、用户角色和业务流程。
  • 日志字段：requestId、promptVersion、model、token、耗时、错误阶段和输出状态是否完整。
  • Trace 分段：上下文、检索、工具、模型、解析、持久化是否有独立 span。
  • 监控指标：成功率、TTFT、P95 延迟、错误率、成本、缓存命中、fallback 和采纳率是否可看。
  • 成本归因：是否能按租户、功能、模型、prompt 版本和重试拆分。
  • 质量信号：点踩、人工修改、引用缺失、schema 失败和事故样本是否被采集。
  • 日志安全：敏感字段是否脱敏，完整回放是否有权限和审计。
  • 告警策略：成本突增、延迟升高、错误率上升、引用异常、工具失败是否有阈值。
  • 反馈闭环：线上失败是否能进入样本库、评估集和下一次发布门禁。
  • 回放能力：典型事故是否能从日志和 trace 复现关键链路。