企业 AI 可观测性怎么建设：从调用日志到业务失败定位

从单次模型调用，转向完整业务任务

AI 从辅助写作进入业务流程后，一个请求往往会触发多次模型推理、数据查询和外部操作。每个接口都成功，仍可能因为选错资料、使用旧口径或结果未被下游接收而交付失败。只统计模型响应时间与接口错误率，会把这些不同问题压成同一个绿色状态。

OpenTelemetry 在 2026 年 5 月发布的官方介绍，展示了如何记录模型调用、工具执行及 token 用量等信号。[1] 本文将其作为已有工程能力的例证，不把它包装成最近的新发布。当前 GenAI 约定仍标记为 Development，实施时应固定采用的约定与采集组件版本，避免字段随升级改变却未同步看板。[2]

对已有多阶段 AI 应用的企业，决策重点因此从“能否收集日志”转向“能否把一次业务失败连接到可处置的证据”。简单、低频、结果必经人工检查的助手，可以先用最小记录；跨部门、高并发或带业务写入的应用，才更需要系统化的追踪与结果核对。

本文把证据分为三层：运行层说明请求是否完成及耗时；业务层说明结果是否通过既定验收；诊断层说明采用了什么输入版本、执行分支和依赖响应。这是本文归纳的工程框架，不是行业统一标准。三层可以关联，但不能相互代替。

先写清一个失败应当留下什么

构造一个内部维修知识助手：用户询问设备 M2 的停机处理流程，检索服务返回了相似型号 M1 的手册，模型据此生成流畅答案，最终接口返回成功。若只保存模型输入 token 数和 HTTP 状态，运维团队既无法确认是检索问题，也无法判断哪些历史答案受影响。

最小诊断记录应连接业务任务编号与调用链标识，并区分一次任务和多次重试。记录应用发布版本、实际模型标识、提示模板版本、检索索引版本、候选文档标识及修订号、工具名称和结果状态。某项版本不可获得时应标为未知，不能用今天的配置补作昨天的执行证据。

在上述场景中，保留“请求型号 M2、返回文档修订 M1-R7、型号一致性校验失败”这样的受控诊断事实，通常比保存一份没有结构的完整对话更有用。检索候选是否包含正确手册、重排是否剔除了它、生成环节是否引用了它，分别对应不同修复责任。

记录的是可观察的输入、输出、版本和校验结果，而不是把模型事后解释当成它当时真实决策过程。即便调用链完整，也不能据此断言某个字段是唯一因果原因；必要时在隔离环境中固定材料、改变一个条件进行对照。

结果指标必须有独立的分母与证据

建议分别保留接口完成、业务验收通过、主动拒答、转人工、结果未知等状态。未知不应自动算成功，也不应与明确错误混为一类。业务成功率的分母要说明是全部受理任务、已完成任务还是已完成且有验收结果的任务；后者若漏掉大量未反馈任务，会产生乐观偏差。

质量证据可以来自规则对账、人工审核、用户确认或独立参考答案，各自回答不同问题。用户点击满意并不证明金额正确；规则通过也只证明被规则覆盖的条件。MLflow 文档提供了对生产追踪进行异步抽样评估的能力，但评审结论仍要另行校准，不能直接等同真实业务正确率。[3]

采集状态还要与业务状态分开。没有追踪记录，可能是请求没有发生，也可能是采样未选中、导出失败或队列溢出。MLflow 明确说明异步队列满时可以丢弃新追踪。[3] 因而应保留独立的受理计数、导出失败计数及可核对的业务完成记录，避免用遥测缺失证明系统无故障。

同样的追踪字段也应服务于企业大模型升级的业务回归与灰度发布：按发布版本、任务类型和负载时段查看失败，才能区分新配置退化与依赖服务异常。只看所有版本混合的平均值，可能把少量关键故障掩盖在正常流量里。

采样节省成本，也会改变你看见的故障

以下仅为构造算例：每日处理 5 万项任务，每项完整追踪平均占 40 KB，按十进制计算，原始数据约为每天 2 GB、30 天 60 GB；这尚未计入索引、副本、备份和读取费用。若完整记录增加到每项 400 KB，原始量也扩大十倍。因此先减少无助诊断的载荷，再讨论存储采购，往往更可控。

假设随机保留 10% 的完整追踪，平均原始量约降到每天 0.2 GB。但若某类罕见故障当天只出现一次，它仍有 90% 的概率不被该随机样本保留；这不是故障不重要，而是采样机制决定的盲区。示例比例不能作为推荐默认值。

OpenTelemetry 区分在请求早期决定的头部采样，以及依据较完整调用链决定的尾部采样。[4] 前者无法单独保证保留所有后续错误；后者可以按错误或延迟筛选，但需要缓存、计算和运维资源。若上游已经丢弃完整追踪，后续筛选无法把它恢复。

可行的分工是：用独立汇总统计描述总体，用代表性样本观察常态，用故障定向样本支持诊断，并为高后果操作保留所需的独立审计记录。错误样本被刻意多留之后，不能把其中的失败比例直接称为生产失败率；需要完整总体计数或有明确抽样概率的统计方法。

采样还应覆盖版本、租户业务类别和长任务，而不只是高频入口。尾部采样等待结束的时间过短，会截断长任务；采集服务负载过高则可能再次丢失证据。验收必须检查这些边界，而不是只验证平稳流量下看板有曲线。

日志不能成为第二份无边界的业务数据库

完整提示词、检索原文和工具参数可能含客户资料、商业信息或访问凭证。OpenTelemetry 的 GenAI 文档建议默认不采集可能敏感且体积较大的消息内容，提供显式选择采集的机制。[2] 这不意味着元数据天然无敏感性，文档名、用户标识和查询条件同样需要控制。

本文建议将诊断元数据与必要的原始证据分开存放：一般排障先查看版本、状态和脱敏标识；需要原文时，再按业务权限访问受控证据。记录保留期限、访问审计和删除路径，并验证业务数据撤销后，遥测副本是否仍残留。仅做字符串替换不能证明敏感信息已全部去除。

对于已经产生外部写入的工具调用，还应保留服务端业务回执与稳定操作标识。调用链标识便于串联，不必然等于幂等键；一份采样日志也不是完整交易账本。遥测系统短暂不可用时，是否继续业务，应由任务后果和独立审计能力决定，不能把同一策略套给所有入口。

不建议一开始就全量保存所有正文。可以从明确的故障问题反推最小证据，再在授权、限时和限范围的条件下增加内容采集，并测量对响应延迟、资源用量与数据管理的影响。

用故障演练决定是否值得继续投入

采购或上线验收可采用四类受控故障：错误文档版本、模型接口超时、工具返回业务拒绝、追踪导出失败。演练环境不产生真实业务副作用。要求值班人员仅凭获准查看的记录，指出失败阶段、受影响发布版本、仍未知的事项和下一步核对动作。

衡量从收到问题到形成有证据诊断的时间、已知故障中证据完整的比例，以及额外延迟、数据量和人工排障投入。定义证据完整时，应明确必须关联哪些阶段；不能用日志条数代替。没有真实演练结果前，不写“定位效率提升了多少”。

小团队可以先覆盖一类高频任务和一条可追踪的结果验收路径。若故障已能稳定定位，新增平台功能未必有价值；若关键失败仍无法区分是数据、模型还是执行层问题，再补对应证据。企业 AI 可观测性的投入回报，应体现在更快且更准确的处置，而不是越来越大的日志仓库。