用LLM做生产系统的人早晚会遇到一个问题AI回答错了但你不知道它为什么错。传统后端出问题了你看日志、看指标、看链路追踪几分钟就能定位。但LLM调用不一样——延迟波动大、成本跟结果绑在一起、输出是文本没法做断言。你加再多的日志也回答不了为什么AI会给出这个回答。这篇文章不讲概念讲我实际怎么做的。一、LLM调用和普通API到底差在哪三个区别理解了你就知道为什么传统三板斧不够用。第一个延迟分布完全不同。普通API调用一般在10-500msLLM调用在1-30秒而且方差极大。同一个模型、同一个Prompt响应时间可能差10倍。所以平均延迟这个指标毫无意义你得看P95。第二个成本和结果耦合。每次调用都按Token计费响应慢的请求不仅体验差还更贵。你不能只看延迟不看Token消耗也不能只看Token不看延迟这两个必须一起追踪。第三个输出没法做断言。普通API返回JSON你可以写个schema验证对不对。LLM返回文本你没法用简单规则判断对错。二、我实际在采集的指标分三类缺一不可。服务质量TTFT首个Token到达时间反映首屏感知、TPOT每个输出Token的生成时间反映流式响应速度、端到端延迟、错误率。成本输入Token数、输出Token数、单次调用成本。按模型分组聚合不然没意义。质量用户反馈率点赞/踩、语义相似度评分、人工抽检通过率。质量指标最难采集但最重要——没有质量指标的成本优化是盲目的你省了钱但不知道是不是在牺牲效果。三、调用链追踪怎么做AI应用的一个典型调用链是这样的用户请求 → 网关 → Agent编排层 → LLM调用 → 工具调用 → LLM调用 → 响应。传统追踪工具能追踪RPC调用但LLM的上下文远比RPC复杂。你需要知道这次用了什么Prompt、返回了什么内容、消耗了多少Token、有没有Function Calling的中间结果。我的做法是在OpenTelemetry基础上为LLM调用定义自定义Span属性记录model、request messages、token消耗、finish reason。但注意完整的Prompt和Response不要写入Span属性数据量太大而且可能包含敏感信息而是存到独立的Trace Store里通过trace ID关联。四、输出质量怎么验证这可能是最头疼的问题。我的做法分三层第一层格式验证。如果输出要求是JSON先验证能不能解析再验证字段完整性。第二层语义验证。用另一个LLMJudge LLM评估输出质量打分维度包括是否回答了问题、“是否有幻觉”、“是否遵循了指令”。第三层回归测试。维护一组固定的测试用例Golden Dataset每次模型升级或Prompt修改后跑全量对比输出与基准输出的语义相似度下降超过阈值就告警。不需要每次都跑全量但每次Prompt变更和模型版本升级是必跑的。五、工具链开源方案OpenTelemetry Prometheus做指标采集自定义Span做LLM追踪。适合有一定基础设施的团队。专用方案Langfuse、Arize Phoenix、LangSmith专门为LLM设计的观测平台开箱即用。适合不想折腾的团队。评估框架deep-eval、Ragas做Golden Dataset评估和自动评分。最后说一句AI应用的可观测性投入不是成本它是你唯一能在生产环境中回答为什么AI会这样回答的工具。没有可观测性每次用户反馈AI回答错了都是一次盲人摸象式的排查。关于这个话题的更多细节我博客aigcharness.com上有一篇更完整的文章包含完整的代码示例和配置有需要可以看看。