一个 AI 助手答错时，原因可能出在检索没有找到文档，也可能是模型选错工具，或者工具已经超时。只留最终回答，排查的人只能重新猜一遍，所以调用轨迹要把一次请求经过的模型、检索和工具操作按先后关系记下来。
我查了 OpenTelemetry 最新的生成式 AI 语义约定，它为推理、向量生成、检索、记忆和工具执行定义了不同的 span，一个 span 表示有开始与结束的一次操作。推理 span 应覆盖从发起请求到完整收到响应的时间，客户端自动重试时，整次逻辑操作仍放在同一个范围里。
先记能解释故障的字段
语义约定要求或建议记录操作名、提供方、请求模型和响应模型，调用失败时还要写入低基数的错误类型，例如超时或服务端状态码。输入与输出 token、缓存读取 token 也有统一字段，便于按模型与功能核对用量。
检索操作可以单独记录数据源标识、查询和返回文档，工具执行则记录工具名、调用标识与错误。这样一条慢请求能被拆开看。团队可以知道时间耗在模型生成、向量检索，还是外部系统响应。
会话标识能把同一轮对话里的请求关联起来，提示词名称和版本则帮助比较改版前后的表现。请求模型与响应模型也要分开记录，因为网关或托管平台可能把请求转到另一个实际模型。只写一个含糊的“AI 接口成功”，这些变化都查不出来。
字段统一以后，告警才容易写清。比如同一模型的错误率突然上升，某个检索源连续返回空结果，或一个工具的九成请求都超过预期时间。质量评测仍要另做，轨迹主要负责还原系统做过什么。
提示词和回答默认不要全量记录
OpenTelemetry 特别提醒，系统指令、用户消息和模型输出往往又大又敏感，里面可能有个人信息，因此规范建议工具默认不采集正文，需要时由使用者主动开启。生产环境若必须留内容，可以放到有独立权限的外部存储，在 span 里只记引用。
默认收少一点更稳。日志需要回答谁在什么版本上调用了哪一步、花了多久、用了多少 token，以及怎样失败。正文只有在明确的排查目的和保留期限下才进入记录。
这条边界很重要。为了排查一次回答，把客户合同、邮件全文和身份证号长期复制到日志系统，会新增一处访问面。更稳妥的做法是先记请求标识、版本、耗时、token、错误和文档标识。确实要看正文时，再经过脱敏、短期保留和权限审批。
建设生成式 AI 可观测性可以从一条用户请求开始。让它串起检索、模型和工具三个操作，检查失败状态能否被查到，再核算每天产生多少数据。轨迹能回答故障发生在哪一步，也要保证排查系统本身没有收走不该收的内容。