AI 调用可观测架构：从散乱日志到 OpenTelemetry GenAI 字段统一

AI 能力从一个聊天入口扩展到客服、搜索、报表、批处理和内部助手以后，最先暴露的问题往往不是“模型不会答”，而是线上看不清：哪条业务用了哪个模型、输入输出 token 各是多少、首字延迟为什么变高、失败是供应商返回还是网关拦截。要把 AI 调用做成可运维能力，第一步就是把观测字段统一起来。

规模背景：AI 调用从单点接入变成平台依赖

很多团队最早接入大模型时，代码结构很简单：某个业务服务直接调用某个模型 SDK，失败就打日志，费用靠账单平台月底复查。这在低频试验阶段没有明显问题，但一旦进入多业务、多模型、多供应商阶段，调用链会变得很散。

典型变化有三类：

• 入口变多：Web 问答、后台助手、离线生成任务、知识库摘要都开始调用模型。
• 模型变多：同一个场景可能按成本、延迟、上下文长度选择不同模型。
• 结果变复杂：一次请求不只返回文本，还可能包含工具调用、检索片段、流式片段和安全拦截状态。

这时如果每个业务自己写日志字段，排查会很痛：一个服务叫 model，另一个叫 llm_model；一个记录 prompt_tokens，另一个只记录总 token；流式响应只看总耗时，看不到首个片段延迟。

原架构瓶颈：日志能查，但没法横向比较

散乱日志最大的问题不是完全没有数据，而是数据不能放在一起比较。比如客服助手说今天很慢，搜索摘要说费用突然升高，批处理说失败率上来了，如果字段不统一，平台侧只能临时写脚本拼数据。

原架构常见瓶颈可以整理成一张表：

这就是为什么 AI 观测不适合只靠业务日志自然生长。日志仍然有价值，但平台层需要一套稳定字段，让不同业务、不同模型、不同供应商的调用能进入同一张看板。

新架构：用 GenAI 语义字段统一采集层

OpenTelemetry 的 GenAI 语义约定把生成式 AI 调用拆成 spans、metrics、events 等信号，并定义了一批 gen_ai.* 字段。工程落地时可以先从最小字段集开始，不必一口气记录所有可选内容。

一个可落地的架构是：业务服务不直接把原始日志散落到各处，而是通过 AI 网关或统一 SDK 生成 span 和指标，再交给 OTel Collector，最后进入日志、指标、链路和告警系统。

type AITraceAttrs struct {
    Operation    string
    Provider     string
    RequestModel string
    Stream       bool
    InputTokens  int
    OutputTokens int
    ErrorType    string
}

func fillGenAIAttrs(span SpanLike, a AITraceAttrs) {
    span.Set("gen_ai.operation.name", a.Operation)
    span.Set("gen_ai.provider.name", a.Provider)
    span.Set("gen_ai.request.model", a.RequestModel)
    span.Set("gen_ai.request.stream", a.Stream)

    if a.InputTokens > 0 {
        span.Set("gen_ai.usage.input_tokens", a.InputTokens)
    }
    if a.OutputTokens > 0 {
        span.Set("gen_ai.usage.output_tokens", a.OutputTokens)
    }
    if a.ErrorType != "" {
        span.Set("error.type", a.ErrorType)
    }
}

这里的关键不是代码多高级，而是字段稳定。先把 operation、provider、request.model、input_tokens、output_tokens、error.type 这几类字段统一，平台就能做三件事：按模型看延迟，按业务看 token，按错误类型看可靠性。

建议从下面这组最小清单开始：

• gen_ai.operation.name：区分聊天、补全、向量、检索等操作。
• gen_ai.provider.name：区分供应商或内部模型平台。
• gen_ai.request.model：记录请求时指定的模型。
• gen_ai.response.model：记录实际响应模型，方便发现路由变化。
• gen_ai.usage.input_tokens：记录输入 token。
• gen_ai.usage.output_tokens：记录输出 token。
• gen_ai.response.time_to_first_chunk：流式响应首个片段延迟。
• error.type：低基数字段，用来聚合错误类型。

关键取舍：内容隐私、token 精度和采样比例

AI 调用观测最容易踩坑的地方，是把“看得见”误解成“什么都记录”。OpenTelemetry 的 GenAI 约定里，输入消息、输出消息、系统指令等内容字段通常属于可选或需要特别谨慎处理的部分，因为它们可能包含个人信息、内部资料、订单内容或业务密钥。

实际落地可以按三层处理：

1. 默认只记录结构化指标

模型名、供应商、token、耗时、错误类型、是否流式，这些字段足够支撑大多数平台看板。默认不要记录完整 prompt 和完整回复。

2. 对内容做摘要和脱敏

如果某些排查必须看输入输出，可以只记录摘要、哈希、长度、模板名、模板版本和风险标签。比如记录 prompt_name=refund_helper、prompt_version=v3，比记录完整用户对话更稳。

3. 高风险场景单独采样

客服、医疗、金融、内部代码助手这类场景，内容采样要有明确开关、保留期和访问权限。采样不是为了“多存点以后可能有用”，而是为了能复盘特定问题。

token 精度也要做取舍。有的供应商直接返回计费口径，有的返回模型消耗口径，有的还有缓存读写 token。平台最重要的是统一口径：报表里展示哪一种，就在接入层明确转换规则，并在字段说明里写清楚。

上线结果：用四类指标判断架构是否有效

统一字段上线后，先不要急着做复杂智能路由。第一阶段只看四类指标，判断观测架构是否真的生效：

如果统一字段做对了，问题定位会从“去每个业务服务翻日志”变成“先在平台看哪类模型、哪类业务、哪类错误异常”。这对规模化团队尤其重要，因为 AI 调用已经不再是某个单点功能，而是多个业务共享的基础能力。

后续改进：把观测数据反推路由和预算策略

观测架构稳定后，下一步可以把数据反推到治理策略里：

• 模型路由：低风险短文本走低成本模型，高风险长上下文走更强模型。
• 预算保护：按业务、租户、用户、任务类型设置 token 上限。
• 降级策略：当某个供应商 p95 延迟或错误率异常时，切换备用路径。
• 提示模板治理：按 prompt.name 和 prompt.version 看成本与失败率。
• 隐私审计：定期检查是否有人把完整输入输出写进高保留期日志。

这也是规模化架构深挖的核心：AI 网关、OTel Collector、指标库和告警系统不是为了“看起来专业”，而是为了让路由、成本、可靠性和隐私策略都能有数据支撑。

总结

AI 调用的可观测性建设，不应该停留在“每次请求打一行日志”。当业务入口、模型供应商、调用模式和计费口径都变多时，团队需要的是统一字段、统一采集、统一看板和明确的隐私边界。

落地建议按三步走：第一，把 AI 调用收口到统一 SDK 或 AI 网关；第二，按 OpenTelemetry GenAI 语义字段记录模型、供应商、token、耗时和错误类型；第三，在上线后用延迟、成本、可靠性和隐私四类指标复查。这样一来，AI 能力从“能调用”走向“能运维”，后续做模型路由、预算保护和质量治理才有稳固基础。