构建大模型应用的可观测性指标体系

可视化演示

展示系统处理流水线、实时性能指标曲线及多方案对比分析，包含数据流转、吞吐延迟监控与方案评估。

SLO/SLI 概念：服务质量的三块基石

寿司店开在写字楼下，客人对出餐时间最敏感。店长在墙上贴出承诺书：“95% 的订单 15 分钟内上齐”。客人不会关心后厨如何安排流程，他们只关心承诺是否兑现。为了让承诺不是一句空话，店长每天随身携带一个黑皮笔记本，记下每一笔订单的实际等待时间。这个本子上记录的真实数字，就是 SLI（Service Level Indicator，服务水平指标）——它回答的是“服务现在到底怎么样”。

墙上的承诺书就是 SLO（Service Level Objective，服务等级目标）——它回答的是“我们希望服务做到什么程度”。两相对照，承诺是否兑现一目了然。但任何服务都不可能永远不出错，于是店长规定：每个月允许 5% 的订单迟到。这 5% 就是错误预算，它把“质量的余量”变成了一个可计算的数字，让团队在追求稳定和快速迭代之间找到平衡。

这三块基石构成了可观测性的最小闭环：先定目标、再测实际、后留余地。在 LLM 应用中，SLI 可以是请求延迟、回答正确率、幻觉率等任何可量化指标；SLO 是团队对用户服务质量的白纸黑字承诺；错误预算则成为发布策略和优化方向的决策依据。没有这三者，监控面板上就只剩下一堆与目标无关的跳动数字。

黑皮笔记本是整家店的底气所在。没有它，墙上的承诺书再漂亮也没人敢信；有了它，店长才能底气十足地说：“我们承诺的 95%，是用每一张订单的真实记录撑起来的。”

四类核心指标：性能与质量的两把尺子

店长每天盯着两块秒表：一块用来量“从下单到上菜”的时间，一块用来数“一分钟能翻多少桌”。前者是延迟，后者是吞吐量。在大模型应用里，一次请求的延迟远比想象中复杂：请求要先排队等待计算资源，再交给模型推理生成第一个字，随后逐字流式输出，最后还要经过安全过滤和格式整理。任何一环变慢，用户体感都会被放大。

传统监控喜欢看“平均延迟”，但平均数字会骗人：少数极快请求会拉低平均值，掩盖那批让用户抓狂的慢请求。因此业界更关注 p95、p99 分位延迟——即 95% 或 99% 的请求都能在某个阈值内完成。与此同时，吞吐量以 QPS（每秒查询数）衡量，刻画系统的容量天花板。延迟和吞吐量互相制约：并发一旦上升，排队时间就会变长，延迟随之恶化。

实践中，SLO 往往把两者写在一起，例如“95% 的请求在 2 秒内完成，且每秒至少处理 50 个请求”。测量时还要区分端到端延迟与模型单一调用延迟，前者更贴近用户体验。理解了延迟的构成，你才知道优化该往哪个环节使劲。

两块秒表让店长看清了店里的真实节奏：到底是排队等位太久，还是后厨做菜太慢，还是传菜员在路上磨蹭。有了数据，优化就不再是拍脑袋。

回答质量与幻觉率：LLM 的质检台

寿司店最怕的是什么？不是上菜慢，而是端上来的菜本身有问题。为此，店长设立了品控岗：每天随机抽几份寿司，切开看鱼料纹理、检查摆盘、亲口尝味道。在大模型应用里，回答质量就是“鱼料的新鲜度”，而其中最严重的问题，莫过于幻觉——模型一本正经地编造出与事实或上下文不符的内容，就像服务员端上了一道菜单上根本不存在的菜。

质量度量不是一个单一数字，而是多个维度的综合：相关性能否回答用户所问，忠实度是否基于已有信息作答，完整性是否覆盖问题要点，连贯性是否符合逻辑。实践中通常用“人工抽样 + 自动评估”双通道：自动评估借助 LLM-as-Judge（让另一个模型打分）或语义相似度计算；人工评估则针对高风险领域（法律、医疗）做重点复核。

幻觉率是“忠实度”的负面量化，在安全敏感场景中往往被单独设为一条 SLI。由于逐条标注全部响应成本过高，业界普遍采用采样统计的方式：从一段时间的请求中随机抽取样本，人工或自动标注其中哪些包含幻觉，计算其占比。相比传统的“关键词命中率”，幻觉率更贴近用户对内容可信度的真实感知。

质检台的意义在于：它不用拆开每一份寿司，却能让店长对整批食材的质量胸有成竹。同样，幻觉率不追求零，而是要控制在错误预算允许的范围内，超出警戒线立刻触发调查。

成本与限额：大模型的油表

寿司店每个月最肉疼的不是人力，而是鱼料账单。三文鱼和蓝鳍金枪鱼价格差好几倍，不同食材的用量和单价必须分开记。大模型的成本逻辑如出一辙：按 token（词元）计费，而且输入和输出往往单价不同——通常输出 token 更贵，因为生成比阅读理解更消耗算力。如果只算总账单，你永远不知道哪条“鱼”吃掉了大部分预算。

成本监控的颗粒度非常重要。成熟的做法是：按 API Key、业务线、会话、用户、甚至具体 prompt 模板维度拆分 token 消耗。这样既能找出“哪个业务最烧钱”，也能发现“哪次 prompt 调整让成本暴涨”。例如同一个客服机器人，接入长文档上下文后输入 token 翻了五倍，成本立刻失控。

与成本配套的是“限额”机制：设定单日或单月成本上限，超过阈值自动降级到小模型、切换缓存或熔断非核心功能。同时，成本应与质量联动分析——单纯追求低成本可能带来回答质量下降，因此要把成本指标和错误预算放在同一块看板上综合权衡。一个健康的 LLM 应用，应当是“该花的钱不省，不该花的钱一分不掏”。

会算账，店才能开得长久。成本指标就是大模型应用的油表——它不负责决定你开往哪里，但能在油量告急时提醒你：该省着花了，或者该换个更省油的引擎了。

监控工具链：Langfuse 与 Phoenix

寿司店生意越做越大，店长决定给后厨装上“全流程摄像头 + 订单追踪系统”：每一单从进店到上桌，每个环节谁接手、花了多久、结果如何，全部自动记录。这对应到 LLM 应用中，就是 Langfuse 与 Phoenix 这类可观测性工具肩负的使命。

Langfuse 的核心能力是端到端追踪：它会为每次用户请求生成一条 trace（追踪链路），内部包含多个 span（环节），比如检索了什么文档、调用哪个模型、输入输出是什么、用了多少 token、耗时多久、评分如何。一旦线上出问题，工程师可以从请求 ID 直接钻到具体环节，对比不同版本的效果。它还支持 prompt 版本管理、数据打标与评估，方便做回归检测。

Phoenix（Arize Phoenix）则更专注于检索与嵌入分析。它能把向量检索的命中结果可视化展示，帮助判断 RAG 系统是否召回正确文档。两者配合使用，就构成了一个完整链路：Langfuse 管全链路追踪，Phoenix 管检索质量深度分析。实践中通常按采样率上报，避免监控本身拖慢线上请求。

摄像头一装，整个后厨从黑箱变成了透明厨房。店长终于不用在出问题时满店找原因，而是打开回放，指认具体是哪一个环节掉了链子。

告警与响应：把风险掐在摇篮里

寿司店有个冰柜，专门存放容易变质的鱼料。店长给它装了一套温度报警器：温度超过 4 摄氏度，黄灯先亮；超过 5 分钟短信通知店长；若温度继续飙升，全店铃声大作，厨师长必须立刻按预案转移食材。这套分级报警机制，对应到 LLM 服务上就是多级告警策略。

告警不能建立在瞬间抖动上，而应建立在错误预算消耗率上——也就是“当前实际服务水平和 SLO 目标之间的差距，已经吃掉了多少预算余量”。消耗率低于 50%，属于正常波动，系统仅记录；达到 50% 触发警告，通知负责人开始关注；超过 80% 判定为紧急，要求值班工程师立即介入；超过 100% 则说明错误预算已被耗尽，应自动触发降级预案。告警消息本身要带上 trace 链接，让工程师一眼定位到出问题的请求链。

通知机制同样讲究“按需路由”：低级别告警发到监控群，高级别告警电话或短信直接呼叫值班人，避免全员被无关告警轰炸。每一级告警都对应预先写好的处置动作，例如切换到备选模型、开启缓存、限制并发等。这样做，告警系统才不会沦为人人无视的“狼来了”。

报警器不是用来添堵的喇叭，而是让店长能睡个安稳觉的守夜人。它把“会不会出事”的焦虑，转化为“何时该出手”的确定性信号。

错误预算治理：为持续优化指路

每月的最后一个周末，店长都会开一次复盘会：翻看黑皮笔记本，统计哪段时间迟到最多，计算这个月的迟到配额还剩多少，再决定下个月是尝试新菜单，还是先老老实实把备餐流程理顺。错误预算在此刻不仅仅是一个数字，而是团队的“速度控制器”。

错误预算的治理规则带来了清晰的发布决策：当预算剩余充足时，团队可以大胆做灰度发布、尝试新的 prompt 或升级模型版本；当预算消耗过半，新功能发布需要额外审批；当预算耗尽，则冻结一切非必要的发布，把全部精力投向可靠性和质量修复。这套以“预算”为门禁的机制，让稳定性从一句口号变成了可执行的研发流程。

回归检测是持续优化的另一只眼睛：每次发布新版本前后，对比关键 SLI 是否出现显著下滑，一旦发现异常立即回滚，或进入原因排查。长此以往，团队形成“指标 → 归因 → 行动 → 复测”的闭环。改进的幅度也可以用公式量化——新的 SLI 相比旧的提升了多少，相对于剩余的可改进空间又占了几成，让每一次优化都算得清楚、看得见回报。

错误预算不是绑住手脚的镣铐，而是方向盘：它告诉团队什么时候该踩油门加速迭代，什么时候该刹车先修底盘。一套用数据驱动的改进循环，能让系统像寿司店的招牌菜一样，越打磨越稳定。

AI 应用场景

Python 演示

import random class LLMService:    def __init__(self, slo_latency=1500, slo_quality=0.95, error_budget=0.05):        self.slo_latency = slo_latency        self.slo_quality = slo_quality        self.error_budget = error_budget        self.records = []     def call(self, latency, hallucinated):        ok = latency <= self.slo_latency and not hallucinated        self.records.append({"latency": latency, "hallucinated": hallucinated,                             "ok": ok})        return ok     def sli(self):        if not self.records:            return 1.0        good = sum(1 for r in self.records if r["ok"])        return good / len(self.records)     def leftover(self):        return max(0.0, 1 - (1 - self.sli()) / self.error_budget)  if __name__ == "__main__":    random.seed(42)    svc = LLMService()    for _ in range(1000):        latency = max(200, random.gauss(900, 300))        hallucinated = random.random() < 0.03        svc.call(latency, hallucinated)     sli = svc.sli()    print("采样请求数:", len(svc.records))    print("SLI:", round(sli * 100, 2), "%")    print("错误预算剩余:", round(svc.leftover() * 100, 2), "%")    print("结论:", "可以继续发布" if svc.leftover() > 0 else "预算耗尽，暂停发布")

1. class LLMService:定义一个模拟 LLM 服务的小类，把 SLO 参数和请求记录封装在一起。
2. def call(self, latency, hallucinated):模拟一次模型调用，同时判断是否达标（延迟够快且无幻觉）。
3. self.records.append(...)记录每次调用的原始数据，相当于店长的黑皮笔记本。
4. def sli(self):遍历所有记录，计算达标请求占比，得到服务水平实际值。
5. good = sum(1 for r in self.records if r["ok"])统计达标请求数量，用生成器求和避免手写循环。
6. def leftover(self):用公式 1 - (1-SLI)/(1-SLO) 计算错误预算剩余比例。
7. latency = max(200, random.gauss(900, 300))模拟延迟符合以 900ms 为中心的正态分布，下限截断到 200ms。
8. hallucinated = random.random() < 0.03模拟约 3% 的请求出现幻觉，贴近真实生成模型的表现。
9. if svc.leftover() > 0错误预算还有剩余，说明服务处于健康状态，可以继续发布迭代。

常见误区

面试题