深夜十一点，“深呼吸食堂”的后厨灯火通明。店长老周站在新装好的透明玻璃窗前，看着 AI 主厨锅铲翻飞——一道“哲学三问”汤从点单到出锅只用了 3 秒，但老周心里直打鼓：这道汤到底放了多少“事实盐”？火候够不够？有没有偷工减料？以前后厨是一堵黑墙，菜端出来才知道结果，出了问题只能干瞪眼。现在，他给厨房装了一套“透明观察系统”：每道工序都有记录，每个订单都可追溯，每勺汤都有温度计，食材真伪能被自动嗅出，客人意见也能实时汇总。这套系统，就是大模型应用里的“可观测性”（Observability）。 把你的 LLM 应用想象成那位神秘的 AI 主厨。可观测性就是给厨房装上透明玻璃、工序记录仪和智能仪表，让你能回答三个问题：刚才那次请求到底发生了什么？为什么回答质量下降了？用户在哪些地方感到不满意？本文会带你从零搭建一条完整链路，覆盖日志采集、链路追踪、推理质量监控、幻觉检测、用户反馈闭环、监控告警和工程化落地，让你的 AI 服务不再是“黑盒”。

岗位关联

掌握可观测性，你就从“等用户报障”升级为“主动洞察”。这是 LLM 应用工程师和 SRE 的核心竞争力，也是线上 AI 服务从“能用”走向“好运维”的分水岭。

目录
  1. 可视化演示
  2. 可观测性基础
  3. 日志采集体系
  4. 链路追踪技术
  5. 推理质量监控
  6. 幻觉检测方法
  7. 用户反馈闭环
  8. 监控告警体系
  9. 工程化落地
  10. AI 应用场景
  11. Python 演示
  12. 常见误区
  13. 面试题

可视化演示

本节配有交互动效（进入视口后自动加载，约 3KB）。

可观测性基础

老周在改造厨房时做了三件事：装透明玻璃窗，让所有人都能看到锅里发生了什么；给每道菜挂订单追踪卡，让菜做到哪一步一目了然；在墙边安装温度表、计时器和客流计，掌握整间厨房是否健康。这三件事对应着可观测性的三大支柱：日志、追踪和指标。没有这三样，后厨就是黑盒，问题只能等客人骂上门才知道。

在 LLM 应用里，一次请求会依次经过安全网关、提示词组装、模型调用、工具调用和结果后处理。任何一个环节悄悄出错，用户拿到的回答都可能“表面正常但质量崩塌”。可观测性要解决的核心问题，不是“有没有报错”，而是“能不能从外部现象反推内部状态”。三大支柱的分工非常清晰：日志回答“发生了什么”，追踪回答“在哪一步发生了什么”，指标回答“系统整体是否健康”。

建设可观测性不能凭感觉，要用覆盖度来量化。所谓覆盖度，就是一次请求从进入到返回，有多少环节能被日志、追踪或指标完整观测。

老周的厨房装上玻璃后，每道菜都有了“可回放”的工序记录。可观测性不是买三件工具摆着看，而是让每一个看不见的请求都变成看得见的工序。下一节，我们先从最基础的“工序记录本”说起——日志。

C=NcoveredNtotal×100%\displaystyle C = \frac{N_{\text{covered}}}{N_{\text{total}}} \times 100\%
$C$ 是可观测覆盖度。它衡量的是“透明区域占比”：覆盖度越高，说明系统里能被观察和回溯的请求越多，黑盒区域越少。
  1. 分子含义$N_{\text{covered}}$ 指被日志、追踪或指标完整覆盖的请求数量，是建设成果的体现。
    NcoveredN_{\text{covered}}
  2. 分母含义$N_{\text{total}}$ 指系统承接的全部请求数量，包含采样和未采样、成功和失败的请求。
    NtotalN_{\text{total}}
  3. 比例换算将两者的比值乘上 $100\%$ 得到百分比，方便团队设定目标，比如首季度覆盖度提升到 80%。
    ×100%\times 100\%

日志采集体系

老周给厨师们立了规矩：每道菜都要在工序本上写清楚“几点下锅、放了多少盐、出锅时油温多少”。这样一来，哪怕三天后有客人说汤太咸，他也能翻出记录，查出是哪个环节手抖。LLM 应用也需要这样的“工序本”，只不过它记录的不是盐和油，而是每次请求的输入、输出、模型版本和耗时。

日志采集的第一原则是结构化。不要写“用户提问成功”这种散文诗，而要写成有固定字段的记录：trace_id 用于关联链路，service 标记服务名，action 描述动作，latency_ms 记录耗时，token_usage 记录 Token 消耗，model_version 记录模型版本，status 标记成功或失败。只有结构化的日志，才能被过滤、聚合和自动分析。

日志不是越多越好，也不是越全越好。高价值请求（比如支付、多轮对话、企业客户）要全量记录，低价值请求可以采样以节省成本。同时必须做敏感信息脱敏：API Key、手机号、身份证号绝不能直接进日志库，否则日志库本身就是数据泄露隐患。日志质量可以用完整率来衡量：

只要工序本记得全、记得准，老周深夜接到投诉也能从容翻出那道菜的真实火候。但日志只是“点状记录”，菜从下单到上桌经历了哪些环节，还需要一张追踪卡把它们串起来。

R=NloggedNtotal×100%\displaystyle R = \frac{N_{\text{logged}}}{N_{\text{total}}} \times 100\%
$R$ 是日志完整率。它回答的问题是“该记的请求到底记全了没有”。完整率越高，出问题时可回查的证据就越充分。
  1. 分子含义$N_{\text{logged}}$ 指实际成功写入日志系统的请求数量，代表“记下来的工序”。
    NloggedN_{\text{logged}}
  2. 分母对比$N_{\text{total}}$ 指系统实际处理的总请求数，是“应该记录的全部工序”。
    NtotalN_{\text{total}}
  3. 完整率含义$R$ 越接近 100%，说明工序本越完整，故障时越容易还原现场。
    ×100%\times 100\%

链路追踪技术

透明厨房里，每张餐桌的点菜单都会夹上一张追踪卡。厨师每完成一步，就在卡上盖一个时间戳：洗菜、切菜、下锅、装盘、上桌。最后把时间戳连成时间线，就能看出时间都耗在哪一步。LLM 应用的链路追踪，做的就是同一件事。

系统为每个请求生成一个全局唯一的 TraceID，相当于订单号。这个 ID 会通过 HTTP 头或消息队列一路传下去：网关收到请求时生成 ID，模型调用、检索调用、工具调用都带上它。每个环节产生一个 Span，记录自己的名字、父 Span ID、开始时间、结束时间和业务属性。所有 Span 归属到同一个 TraceID 下，形成一棵“请求家族树”。

把这些 Span 按父子关系和时间轴展开，就得到瀑布图。瀑布图能一眼暴露耗时瓶颈：是模型调用太慢，还是检索工具超时？在串行链路中，整条请求的总耗时等于所有 Span 耗时之和：

以前客人问“为什么我的菜 20 分钟还没来”，老周只能赔笑。现在他能指着追踪卡说：不是炒菜慢，是排队取海鲜用了 15 分钟。这就是链路追踪的魅力——把模糊的“慢”拆成精确的“哪里慢”。但能看见流程还不够，我们还需要回答“菜到底好不好吃”，这就是推理质量监控。

Ttotal=∑i=1nTspan,i\displaystyle T_{\text{total}} = \sum_{i=1}^{n} T_{\text{span},i}
$T_{\text{total}}$ 表示一次请求从进入到返回的总耗时。注意：这个公式只适用于串行环节；如果多个 Span 是并行的，总耗时应取并行组里的最大值，而不是简单相加。
  1. 累加符号$\sum_{i=1}^{n}$ 表示把从第 1 个到第 $n$ 个 Span 的耗时逐一加起来，得到串行链路总耗时。
    ∑i=1n\sum_{i=1}^{n}
  2. 单项耗时$T_{\text{span},i}$ 表示第 $i$ 个环节的耗时，例如“模型调用 Span”消耗 800ms，“工具调用 Span”消耗 200ms。
    Tspan,iT_{\text{span},i}

推理质量监控

老周请了三位试菜员，分别从口味、摆盘、营养三个维度打分。每道菜出锅前，试菜员会给出一个综合分。LLM 应用也需要类似的“试菜员”，因为模型返回的内容不能只看“有没有报错”，还要看“回答得好不好”。

推理质量评估通常包含多个维度：相关性（答没答到点上）、忠实度（有没有胡编）、连贯性（前后是否通顺）、指令遵循度（是否按用户要求格式输出），以及安全性（有没有有害内容）。落地时常用两种手段：一是用“LLM 当裁判”，让一个更强的模型给输出逐项打分；二是用语义相似度或规则检查，把回答和标准答案作比较。每个维度还要配权重，因为不同业务对维度的重视程度不同。

把多维得分合成一个总分，能让质量趋势可监控。加权质量分公式：

试菜员从不会把“没放盐”和“摆盘精美”混为一谈，加权打分不仅让老周看到综合品质，还能让他看到是哪一维拉低了总分。然而，还有一种质量问题是普通打分很难发现的——大厨一本正经地用“想象出来的食材”做菜，也就是幻觉。

Q=∑k=1mwksk∑k=1mwk\displaystyle Q = \frac{\sum_{k=1}^{m} w_k s_k}{\sum_{k=1}^{m} w_k}
$Q$ 是最终的推理质量分。它按权重把多个维度的评分聚合成一个 0 到 1 之间的数值。质量分随线上流量持续记录，一旦下跌就要结合模型版本和提示词改动定位原因。
  1. 分子加权和$\sum_{k=1}^{m} w_k s_k$ 把第 $k$ 个维度的得分 $s_k$ 乘以对应权重 $w_k$，再全部相加，体现“重要维度影响更大”。
    ∑k=1mwksk\sum_{k=1}^{m} w_k s_k
  2. 分母权重和$\sum_{k=1}^{m} w_k$ 是所有维度的权重之和，用于对加权分数做归一化，避免权重总和不一致导致分数不可比。
    ∑k=1mwk\sum_{k=1}^{m} w_k
  3. 综合得分含义$Q$ 越接近 1，代表综合质量越高；当 $Q$ 突然下降，说明某个质量维度开始异常。
    QQ

幻觉检测方法

传说有位大厨尝试做“龙肉料理”，菜单上根本没有这种食材，但他描述得绘声绘色，要不是客人见多识广，差点就信了。LLM 的幻觉就是这样：模型捏造出不存在的知识、链接或结论，读起来流利自信，实则胡编乱造。可观测性必须专门设一道“食材真伪检测线”。

幻觉主要分两类：一是与外部事实不符，例如编造某位科学家说过的话；二是与上下文不符，例如对话前提是“用户是会员”，回答却说“用户没有登录”。检测的核心思路，是让回答与可信证据“对质”。

具体方法有三类。第一，事实一致性检查：把回答拆成多个断言，与检索到的知识库片段逐一比对。第二，上下文冲突检测：用规则或模型检查回答是否与对话历史矛盾。第三，不确定性估计：对同一问题多次采样，如果答案分歧很大或 token 概率普遍偏低，就怀疑是“编的”。比对语义时，经常用到余弦相似度：

老周在传菜口装了一台“食材真伪检测仪”，味道再香也得先过这一关。同样，幻觉检测不能只靠人工抽检，要把它变成自动化拦截的一环。但要真正压缩幻觉，光靠检测还不够——还需要听听“吃饭的人”怎么说。

sim(A,B)=∑iAiBi∑iAi2⋅∑iBi2\displaystyle \text{sim}(A,B) = \frac{\sum_{i} A_i B_i}{\sqrt{\sum_{i} A_i^2} \cdot \sqrt{\sum_{i} B_i^2}}
$\text{sim}(A,B)$ 是向量 $A$ 和 $B$ 的余弦相似度，取值在 -1 到 1 之间。把“回答的语义向量”和“证据文本的语义向量”代入，相似度低于阈值就标记为疑似幻觉，交给人工复核。
  1. 分子点积$\sum_{i} A_i B_i$ 把两个向量每个维度的数值相乘再求和，表示两个向量的“对齐程度”。
    ∑iAiBi\sum_{i} A_i B_i
  2. 分母模长$\sqrt{\sum_{i} A_i^2}$ 和 $\sqrt{\sum_{i} B_i^2}$ 分别是两个向量的模，用于消除文本长度带来的偏差，只比较方向。
    ∑iAi2⋅∑iBi2\sqrt{\sum_{i} A_i^2} \cdot \sqrt{\sum_{i} B_i^2}
  3. 相似度判断$\text{sim}(A,B)$ 越接近 1，表示语义越接近；业务上通常设定阈值，低于阈值就触发幻觉告警。
    sim(A,B)\text{sim}(A,B)

用户反馈闭环

老周在每张桌子上放了意见卡，上面只有三个选项：好吃、一般、有问题。但他很快发现，意见卡收回来一大摞，厨房却没有任何改变。于是他立下规矩：每周一上午，店长把所有意见卡分类，挑出高频问题改菜谱，改完再邀请提意见的客人试吃。这才是真正的“闭环”。

LLM 应用上线后，最真实的信号来自用户。要主动收集点赞、点踩、举报、“重新生成”点击和用户编辑行为。收集之后，不能把数据丢进数据仓库吃灰，而要形成完整的优化循环：收集反馈 → 人工标注原因 → 形成测试集 → 跑回归测试 → 优化 Prompt 或微调模型 → 小流量灰度 → 上线并监控质量分。

这个循环到底转得怎么样，可以用闭环率衡量。闭环率越高，说明用户的每一条真实意见都在推动系统进步：

意见卡不是摆设，而是老周改进菜品的指南针。用户反馈对整个 LLM 应用的意义也一样：没有闭环的反馈只是情绪，进入闭环的反馈才是资产。当质量分和幻觉率都进入可观测范围，我们还需要最后一道防线——告警。

F=NactedNfeedback×100%\displaystyle F = \frac{N_{\text{acted}}}{N_{\text{feedback}}} \times 100\%
$F$ 是用户反馈闭环率，表示已经真正推动改进（标注、优化或上线）的反馈占全部反馈的比例。反馈收集得再多，闭环率低也等于意见卡被锁在抽屉里。
  1. 分子推动数$N_{\text{acted}}$ 是已经进入优化动作的反馈数量，例如完成了人工标注并被用于模型迭代。
    NactedN_{\text{acted}}
  2. 分母反馈总数$N_{\text{feedback}}$ 是用户产生的全部反馈数量，包括点赞、点踩和举报。
    NfeedbackN_{\text{feedback}}
  3. 闭环率计算$F$ 越高，说明反馈真正驱动了模型改进，而不是只在数据库里“囤积”。
    ×100%\times 100\%

监控告警体系

透明厨房不可能靠人 24 小时盯温度计，老周装了火警铃：油温略高时，铃声提醒厨师；温度逼近着火点，直接呼叫店长；烟雾警报大作，全家人都要撤。告警的价值不是“报得多”，而是“报得准”。

LLM 应用的监控指标要覆盖四个层面：流量（QPS）、性能（P50/P95/P99 延迟）、错误（错误率）、成本（Token 消耗量），再加上业务层指标：质量分和幻觉率。指标之间不能孤立，一个异常指标要能一键跳转到对应的 Trace 和日志，形成“指标 → 追踪 → 日志”的下钻路径。

告警阈值不能一刀切。固定阈值（如错误率超过 5% 就报警）实现简单，但误报率往往很高。可以用动态基线让系统按小时或按天自适应正常波动范围。告警还需分级：P1 级线上完全不可用，立即电话通知；P2 级服务质量明显下降，发企业微信；P3 级潜在风险，进日报观察。同时要做告警降噪：相同 Trace 的告警聚合成一条、维护窗口内静默、自动恢复后自动清除。衡量告警要不要继续发，看精确率：

老周不希望温度微变就狂响铃，经过调教的火警铃只在真正危险时发声。告警体系也需要这样持续迭代。最后，我们还要把这一整套透明厨房复制到所有分店——这就是工程化落地。

P=TPTP+FP×100%\displaystyle P = \frac{TP}{TP + FP} \times 100\%
$P$ 是告警精确率。它回答的问题是“发出的告警里，有多少是真正需要处理的问题”。$TP$ 是真阳性（告警且确实出问题），$FP$ 是假阳性（误报）。精确率太低，就是“狼来了”效应。
  1. 命中数$TP$（真阳性）表示告警确实对应真实故障的数量，例如“P95 延迟升高”告警最终确认是模型服务过载。
    TPTP
  2. 误报数$FP$（假阳性）表示发出去但实际没有问题的告警数量，例如一次偶发抖动触发了阈值，但很快自动恢复。
    FPFP
  3. 精确率含义$P$ 越高，说明告警规则越可信，值班同学越愿意响应。
    TPTP+FP×100%\frac{TP}{TP + FP} \times 100\%

工程化落地

老周的透明厨房在某一家店实验成功后，紧接着的问题是：怎么复制到十家分店？答案不是多装几块玻璃，而是统一设备型号、写操作手册、培训每个厨师，并安排定期检查。可观测性的工程化落地，也是这样一套“组织行为”。

先做工具选型。开源生态里，OpenTelemetry 负责统一采集数据，Prometheus 加 Grafana 管理指标，Jaeger 或 Tempo 负责链路追踪，Elasticsearch 或 Loki 负责日志存储检索。选型不是追求最潮，而是看团队是否熟悉、社区是否活跃、能否和现有监控体系打通。

再建平台规范：统一 Agent 部署方式，统一字段命名规范，统一 Dashboard 模板。团队协作上要指定监控接口人，定义值班响应手册，每次故障后开复盘会：补全缺失埋点、修正告警阈值、更新排查手册。这套体系建得好不好，可以用实践成熟度来衡量：

透明厨房最终不是靠一块玻璃，而是一整套有人维护、持续改进的制度。可观测性也永远不是“装完就跑”，而是 LLM 应用工程团队的日常习惯。当你把日志、追踪、质量、反馈、告警全部串起来，那个曾经深不见底的 AI 黑盒，就会变成随时可以拉开检查的透明厨房。

M=NpracticesNrequired×100%\displaystyle M = \frac{N_{\text{practices}}}{N_{\text{required}}} \times 100\%
$M$ 是可观测性成熟度。$N_{\text{required}}$ 是目标实践项总数，比如“全链路日志结构化”“TraceID 全链路透传”“告警分级通知”；$N_{\text{practices}}$ 是已经落地的实践项数量。按季度设定提升目标，例如从 60% 提升到 80%。
  1. 目标项$N_{\text{required}}$ 是根据业务和团队规模圈定的必修实践项，例如必须覆盖日志脱敏、链路追踪、质量监控等。
    NrequiredN_{\text{required}}
  2. 落地项$N_{\text{practices}}$ 是已经稳定运行、有负责人和维护机制的实践项数量。
    NpracticesN_{\text{practices}}
  3. 成熟度计算$M$ 越接近 100%，说明团队把可观测性从“个人技巧”变成了“组织能力”。
    ×100%\times 100\%

AI 应用场景

智能客服线上故障排查

阶段：监控与告警

解决的问题：传统排查靠登录服务器翻日志，多服务调用链像一团乱麻，出了问题只能凭经验猜。LLM 可观测性用 TraceID 串联网关、检索和模型调用全链路，质量分和延迟异常能快速定位到具体环节，大幅缩短平均恢复时间 MTTR。

具体案例：某智能客服团队接入 OpenTelemetry 后，用户投诉“回答答非所问”。运维人员通过追踪瀑布图发现检索服务对部分长尾问题耗时 8 秒，导致上下文被截断。优化检索超时与降级策略后，满意度提升 15%。

内容生成平台的幻觉治理

阶段：质量评估与幻觉检测

解决的问题：新闻摘要用 LLM 自动生成后，偶尔出现与原文矛盾的内容。纯人工抽检成本高、覆盖低。通过事实一致性检查和语义相似度阈值自动筛出疑似幻觉，再走用户反馈闭环持续优化，幻觉率大幅下降。

具体案例：某新闻 App 对 AI 摘要做事实一致性打分，低于阈值的回答自动进入人工复核队列，并沉淀为“错误摘要库”。团队用这批数据迭代 Prompt 之后，线上幻觉率从 3.2% 降到 0.8%。

大模型网关的 SLO 保障

阶段：指标监控与降噪告警

解决的问题：告警轰炸导致值班同学麻木，真正的大故障反而被淹没。通过聚合 QPS、错误率、P95 延迟、Token 成本和幻觉率，并配合动态基线与分级通知，让团队只对“值得醒过来处理”的告警响铃。

具体案例：某公司大模型网关每天触发 2000 条告警，引入动态基线和相同 Trace 聚合后，告警量降到每天 40 条，P95 延迟异常平均 5 分钟内被确认处置，不再出现告警疲劳。

Python 演示

python90 行
# 演示 LLM 应用可观测性监控的核心流程import jsonimport randomimport time  class RequestLogger:    """模拟结构化日志采集器, 记录每个请求的关键字段"""     def __init__(self):        self.logs = []     def write_log(self, trace_id, service, action, latency_ms, meta):        record = {            "time": time.time(),            "trace_id": trace_id,            "service": service,            "action": action,            "latency_ms": latency_ms,            "meta": meta,        }        self.logs.append(record)        return record  class QualityScorer:    """模拟推理质量评估器, 按维度加权计算质量分"""     def __init__(self, weights):        self.weights = weights        self.scores = []     def score(self, output_length, has_answer, answer_ratio):        relevance = 0.9 if has_answer else 0.3        faithfulness = 1.0 - answer_ratio        coherence = min(1.0, max(0.0, output_length / 200.0))        dims = {            "relevance": relevance,            "faithfulness": faithfulness,            "coherence": coherence,        }        total_w = sum(self.weights.values())        q = sum(self.weights[k] * dims[k] for k in dims) / total_w        self.scores.append(q)        return q  class ObservabilityDemo:    """模拟一个带可观测性的 LLM 请求处理流程"""     def __init__(self):        self.logger = RequestLogger()        self.scorer = QualityScorer({            "relevance": 0.4,            "faithfulness": 0.4,            "coherence": 0.2,        })     def handle_request(self, req_id, has_answer, answer_ratio, latency_ms):        trace_id = f"trace-{req_id}"        self.logger.write_log(            trace_id, "gateway", "entry", latency_ms, {"path": "/chat"}        )        q = self.scorer.score(200, has_answer, answer_ratio)        self.logger.write_log(            trace_id, "llm", "generate", latency_ms, {"quality": q}        )        return trace_id, q     def summary(self):        total = len(self.scorer.scores)        avg_quality = sum(self.scorer.scores) / total if total else 0        hallucination = sum(1 for s in self.scorer.scores if s < 0.6) / total if total else 0        return {            "total_requests": total,            "avg_quality": round(avg_quality, 3),            "hallucination_rate": round(hallucination, 3),            "log_records": len(self.logger.logs),        }  if __name__ == "__main__":    demo = ObservabilityDemo()    random.seed(42)    for i in range(100):        has_answer = random.random() > 0.2        answer_ratio = random.random() * 0.3        latency_ms = random.randint(300, 1200)        demo.handle_request(i, has_answer, answer_ratio, latency_ms)    print(json.dumps(demo.summary(), ensure_ascii=False, indent=2))
目的：模拟 100 次 LLM 请求，在每次请求中写入结构化日志、计算推理质量分，并输出平均质量分和幻觉率，演示真实可观测性系统中的日志与监控指标采集方式。
  1. self.logger = RequestLogger()初始化日志采集器，相当于厨房的“工序记录本”。
  2. trace_id = f"trace-{req_id}"为每个请求生成唯一 TraceID，后续所有日志都能关联到同一次请求。
  3. self.logger.write_log(trace_id, "gateway", "entry", latency_ms, {"path": "/chat"})在网关写入入口日志，记录服务名、动作和耗时。
  4. q = self.scorer.score(200, has_answer, answer_ratio)调用质量评估器，按相关性、忠实度、连贯性三个维度综合打分。
  5. self.logger.write_log(trace_id, "llm", "generate", latency_ms, {"quality": q})在 LLM 调用环节把质量分写入日志，让日志与质量指标关联。
  6. quality_avg = sum(self.scorer.scores) / total if total else 0计算所有请求的平均质量分，类似试菜员的综合平均分。
  7. hallucination = sum(1 for s in self.scorer.scores if s < 0.6) / total if total else 0统计低于质量阈值的回答占比，用这个比例模拟线上幻觉率。
  8. random.seed(42)固定随机种子，让实验结果可复现，便于接入 CI 做回归验证。

常见误区

误区我只要在代码里加了 `print` 或者接了一个日志平台，把请求都记录下来，就算完成可观测性建设了。

正解日志只是三大支柱之一。没有 TraceID 串联，日志就是一座座孤岛；没有指标聚合，日志无法回答“系统整体是否健康”。可观测性要求日志、追踪、指标协作，才能定位“哪一次请求在哪一步出了问题”，而不是靠 grep 大海捞针。

为何常见：日志是三种数据里最容易理解的，也最容易先落地。很多团队从“先加日志”开始，于是误以为“加了日志”就等于“有了可观测性”。

误区用户没投诉，回答看起来也通顺，我就认为 LLM 应用没有问题，不需要做链路追踪。

正解LLM 应用的很多故障是“隐性”的：检索环节悄悄超时、工具调用失败后模型“硬编”了一个答案、Prompt 模板在某个分支下失效。只看结果，等用户投诉时已经晚了。过程数据（链路耗时、工具调用状态、上下文截断标志）比结果更能提前暴露风险。

为何常见：传统监控习惯盯“对错”和“成功率”，而 LLM 应用即使“成功”返回也可能质量很差，容易让人放松对过程监控的警惕。

误区检测幻觉很简单，检查回答里有没有出现“可能”“大概”这类模糊词，或者把回答和原文做字符串包含判断就行。

正解幻觉是语义层面的问题，模型可以用流畅的句子编造原文里根本没有的事实，关键词和字符串匹配根本发现不了。正确做法是事实一致性校验：把回答拆成断言，与证据做语义向量比对，同时结合上下文一致性和模型置信度综合判断。

为何常见：字符串匹配实现最快，幻觉又往往表现为“看起来合理”，于是工具不完善的团队容易停留在文本匹配的浅层检测上。

误区用户点踩数据已经每天落到数据库了，团队也定期看报表，这就够了。

正解反馈的价值在于推动模型改进。如果只看报表，不标注原因、不进测试集、不回归 Prompt 或模型，反馈数据就只是“僵尸数据”。反馈闭环率比反馈总量更能说明问题：闭环率低于 20%，说明 80% 的用户情绪没有被转化为系统能力。

为何常见：收集反馈是开发动作，改模型是算法工程，很多公司团队分工割裂，反馈流到数据仓库后没有人力继续跟进，形成“只收不治”。

误区监控告警规则越多、阈值越敏感，系统就越安全，宁可错报一千，不可放过一个。

正解告警过多会造成“告警疲劳”，值班同学开始下意识忽略所有通知，真正的大故障反而被淹没。可观测性追求的是告警精确率：每条告警都对应真实问题。动态基线、分级通知、相同故障聚合和静默窗口，都是为了把告警数量降下来、质量提上去。

为何常见：管理者怕出事，宁可多挂规则；而告警疲劳的代价是缓慢但致命的，很容易被团队归咎为“最近运气不好”，忽略规则设计本身有问题。

面试题

Q1. LLM 应用可观测性的三大支柱是什么？

单选题 · easy

  • A.日志、指标、追踪← 正确答案
  • B.缓存、队列、重试
  • C.CPU、内存、磁盘
  • D.输入、输出、延迟

答案：A。可观测性三大支柱是日志（Logs）、指标（Metrics）和追踪（Traces）。日志回答发生了什么，指标回答系统是否健康，追踪回答在哪一步发生。缓存队列重试是架构手段，CPU 内存磁盘是基础设施监控，输入输出延迟只是部分信号。

Q2. TraceID 在一次 LLM 请求中的主要作用是什么？

单选题 · easy

  • A.加密网络传输
  • B.关联全链路日志← 正确答案
  • C.自动计算 Token
  • D.限制请求频率

答案：B。TraceID 像订单号一样，在一次请求经过网关、检索、模型调用等环节时一路透传，把所有 Span 和日志串起来。加密传输由 TLS 负责，Token 计算是计费模块，频率限制是网关策略，都不是 TraceID 的职责。

Q3. 日志完整率的正确含义是？

单选题 · easy

  • A.日志存储空间利用率
  • B.已记录请求数占总请求数比例← 正确答案
  • C.错误日志在所有日志中的占比
  • D.日志从产生到可检索的耗时

答案：B。日志完整率 $R=N_{\text{logged}}/N_{\text{total}}$，衡量的是“应该记的请求记全了没有”。存储空间、错误占比和写入延迟反映的是容量、业务质量和性能，而不是完整率。

Q4. 下列哪些信号可以用于监控 LLM 推理质量？

多选题 · mid

  • A.输出与预期语义相似度← 正确答案
  • B.回答是否遵循指令约束← 正确答案
  • C.系统每秒处理的请求数
  • D.模型对答案的置信度← 正确答案

答案：ABD。语义相似度、指令遵循度、模型置信度都能反映回答质量。每秒请求数 QPS 是流量性能指标，衡量系统吞吐，但不回答“回答得好不好”。如果请求量大但质量在下降，QPS 是看不出来的。

Q5. 哪种方法最适合检测“模型编造不存在的事实”这类幻觉？

单选题 · mid

  • A.回答与证据的事实一致性比对← 正确答案
  • B.对日志文件做压缩与归档
  • C.对服务端口进行安全扫描
  • D.提高模型推理时的批处理大小

答案：A。事实一致性幻觉的关键是把回答拆成断言，与可信证据比对语义，判断是否被证据支撑。日志压缩和安全扫描是运维手段，批处理大小是性能调优，与内容真实性无关。

Q6. 告警精确率描述的是下列哪种关系？

单选题 · hard

  • A.告警中确实存在问题所占比例← 正确答案
  • B.问题中成功触发告警的比例
  • C.两次告警之间的间隔时长
  • D.告警从产生到恢复的耗时

答案：A。精确率 $P=TP/(TP+FP)$ 衡量“发出的告警中真正有问题的那部分占比”。选项 B 是召回率，C 是告警频率，D 是恢复时长。精确率低说明误报多，会导致告警疲劳。

Q7. 一个完整的用户反馈闭环应该包含哪些环节？

多选题 · mid

  • A.收集用户点赞和点踩← 正确答案
  • B.人工标注反馈原因← 正确答案
  • C.用反馈数据迭代模型← 正确答案
  • D.把低质量反馈直接删除

答案：ABC。闭环要求收集、标注、优化、回归、上线。删除反馈会丢失信息，并且不推动任何改进。反馈即使是“低质量”，也可能提示规则或阈值出了问题，应该进分析流程而非直接丢弃。

Q8. 为什么只靠日志无法实现完整的链路追踪？

单选题 · mid

  • A.日志散落各处难以全局关联← 正确答案
  • B.日志格式无法做到统一
  • C.日志无法记录任何请求
  • D.日志只能反映系统异常

答案：A。没有统一的 TraceID 关联，A 服务日志和 B 服务日志就无法串成一条链路。日志格式可以统一，日志能记录成功请求，也能记录异常，但缺少关联标识就无法还原调用先后和父子关系，这正是追踪技术要解决的问题。

Q9. 监控指标中的 P95 延迟表示什么？

单选题 · hard

  • A.95%请求延迟低于该数值← 正确答案
  • B.95%请求延迟高于该数值
  • C.P95等于请求平均延迟
  • D.P95是最慢请求的延迟

答案：A。P95 是百分位指标，把请求按延迟从小到大排序，排在 95% 位置的值就是 P95。它代表绝大多数用户体验的上限，比平均值更能反映长尾问题。平均延迟会被少数快请求拉低，最大值则过度关注极端噪声。

Q10. LLM 可观测性工程化落地需要哪些团队规范？

多选题 · extreme

  • A.统一字段命名规范← 正确答案
  • B.明确SLO与告警级别← 正确答案
  • C.定期复盘并补全埋点← 正确答案
  • D.减少日志数量以降低成本

答案：ABC。统一字段命名让日志可检索、跨团队共享；SLO 和告警级别让响应有优先级；定期复盘推动埋点补全和监控体系演进。减少日志数量虽然能省钱，但会破坏完整率和故障还原能力，不应以牺牲可观测性为代价。