AI 应用的可观测性：LLM 调用的追踪与评估

LLM 进了核心链路，黑盒就太危险

工单助手上线后，运营反馈"有时候答非所问"。但 LLM 调用对我们来说是个黑盒：不知道每次花了多少 token、耗时多少、模型返回了啥。更糟的是出了错没法归因。我参照传统可观测性，给 LLM 调用也接上了 Trace、Token 统计和效果评估三件套，才算把这层黑盒照亮。

用 Trace 串起 LLM 调用

我们把每次 LLM 调用包成一个 span，挂在原有请求链路下，记录 prompt 摘要、模型名、耗时、token：

Span span = tracer.spanBuilder("llm.call")
    .setAttribute("llm.model", "gpt-4o-mini")
    .setAttribute("llm.prompt.length", prompt.length())
    .startSpan();
try (var s = span) {
    Response r = client.call(prompt);
    s.setAttribute("llm.tokens.total", r.usage().totalTokens());
    s.setAttribute("llm.latency.ms", elapsed);
} catch (Exception e) {
    span.recordException(e);
    throw e;
}

这样在 Grafana 里点开一条用户请求，能直接看到里面对应哪次 LLM 调用、花了多少 token，不用再去翻应用日志，定位"为什么这次这么慢"从 15 分钟缩到 1 分钟。

Token 统计要落到成本

token 不是数字游戏，是钱。我们把每个模型的单价配成表，按调用量实时算成本：

Prometheus 里 counter 累加每日 token，再乘单价推到看板。我们因此发现 30% 的调用其实用本地小模型就能答，迁过去月省 40% 费用。还能按接口维度看成本，哪个功能最烧钱一目了然。

效果评估体系

可观测不只是技术指标，还要回答"答得对不对"。我们建了一套离线评估，避免模型悄悄变菜没人知道：

• 沉淀 500 条标注问答对，定期回归，算精确匹配和语义相似度；
• 线上随机采样 2% 对话，运营打分（好评/差评）；
• 当某模型差评率连续三天大于 5%，自动降权重，切到备选模型。

# 评估任务每晚跑
python eval.py --dataset qa_500.json --model gpt-4o-mini
# 输出: accuracy=0.91, similarity=0.88, cost=$2.3/1000

小结

AI 应用的可观测性 = 传统链路追踪 + LLM 专属指标（token/成本）+ 业务效果评估。只监控"调通没调通"不够，要监控"答得准不准、花得值不值"。建议从第一天就把 LLM span 接进现有 Trace 系统，别等出问题再补。我们已经把它固化进内部的 AI 网关，所有模型调用强制打 span。

参考

• 官方文档：ai-agent
• Baeldung 上的相关实战
• StackOverflow 上的相关讨论