Q73 · 你会怎么做大模型应用的可观测性？

用户问客服 Agent：“订单 A123 的退款多久到账？”系统最后回答了“7～10 个工作日”，用户却拿着最新版政策说应为“3～5 个工作日”。如果只保存最终回答，开发者无法分辨：模型自己编了数字、检索拿了旧政策、订单工具查错了单，还是某个工具超时后应用偷偷用了过期缓存。可观测性就是让应用在运行时留下足够、可关联且合规的证据，从外部看出它走了哪些步骤、耗时和失败在哪里，并持续发现同类问题。

一个可落地的做法是同时准备三类信号：**trace（链路追踪）**还原单次请求的步骤与关系；日志记录某个具体事件和原因；指标汇总许多请求的数量、错误率、耗时与成本。对大模型应用，还应记录模型版本、token 用量、检索命中的文档版本、工具结果、状态变化和人工审批决定。OpenTelemetry 将 trace、日志和指标作为可关联的遥测信号；其中 trace 的上下文可跨服务传播，日志也能带上 Trace ID 供回查，指标负责聚合观察。OpenTelemetry：Traces · Context propagation

术语、编号与本文假设

词或记号	先用日常话理解	例子里的对应物
Agent / 大语言模型（LLM）	Agent 是按任务选择模型和工具的应用流程；LLM 是其中负责理解和生成的模型	客服助手读取证据后回答到账时间
RAG / 检索	RAG 是回答前从外部资料找相关片段，再把片段交给模型；检索是“找”的那一步	从售后知识库找退款到账政策
trace / trace_id	一次请求的完整执行轨迹 / 给这条轨迹的唯一标识	一轮退款咨询里的检索、查单、模型回答
span / span_id / 父子关系	span 是有开始和结束时间的一段工作；每段有自己的标识，并可属于上一级 span	“检索知识库”是“处理这轮请求”的子 span
请求 ID R41、R42	应用给两次业务请求的编号，便于客服找回；它与底层 trace_id 可以关联，但并非同一个字段	R41 为正常咨询，R42 为故障咨询
事件 / 状态	事件是发生在某个时刻的事；状态是流程目前走到哪里	“检索超时”“进入待人工审批”
属性 / 标签	附在记录上的简短键值，用于筛选和比较	model_version、policy_version、outcome
日志 / 指标	日志说明单个事件；指标统计一段时间内大量请求的数量或分布	一条超时日志 / 近 15 分钟检索超时率
token / 首 token 时间	token 是模型处理文本的计量单位；首 token 时间是请求后多久出现第一段输出	用来观察模型耗费与用户等待
P2 / P1 / D7	本例虚构的当前政策版、过期政策版和知识库文档编号	D7@P2 写“3～5 个工作日”；D7@P1 写“7～10 个工作日”
A123 / u7	虚构订单号 / 已登录用户编号	订单属于 u7，且退款申请已经获受理
脱敏 / 采样	脱敏是去掉或遮住敏感数据；采样是只保留一部分 trace 以控制体量	记录文档编号和版本，不默认保存整份订单资料

这些数字与政策全是教学假设，并非真实商家的承诺：假设 u7 的订单 A123 已有获受理的退款记录，当前生效的 P2 规定到账预计 3～5 个工作日；知识库中还残留旧版 P1，写 7～10 个工作日。回答必须说明这是预计时间，不能承诺实际到账日。图中的“Trace R42”是便于阅读的业务标签；真实系统通常另有一个规范格式的 trace_id，应把两者安全地关联起来。

一次请求怎样拆成能排查的步骤

图只画 R42 的主步骤。实际故障处理中，“检索超时”之后还发生一次使用旧缓存的回退，这需要另外记录为事件或子 span；否则从图上的超时直接跳到回答，会不知道模型用的证据从哪里来。

以正常请求 R41 为例，应用建立一个代表“处理用户咨询”的根 span。它给“检索政策”“查询订单”“调用模型”“返回答复”分别建立子 span。每段至少记录开始/结束、结果状态和必要的非敏感属性。请求跨过应用服务器、检索服务和订单服务时，传递追踪上下文，让子服务继续使用同一 trace_id；不传递，排障时就会看到几条彼此孤立的链。OpenTelemetry 将 span 定义为工作单元，可携带时间、属性、事件和状态，并用相同 Trace ID 与父 span ID 连接成 trace。OpenTelemetry：Traces · Context propagation

下面是 R41 示意记录，不是某个框架可以直接复制的配置或真实追踪导出格式。ms 表示毫秒；每一行的输入、输出都在业务服务中经过授权后才产生。

工作段或时点	适合保存的证据	此次示意结果
请求根 span	request_id=R41、匿名化租户标识、应用版本、开始/结束、最终状态	完成；不把用户名和原始问题当作检索标签
检索子 span	查询意图、索引版本、权限过滤是否生效、命中文档 ID 与版本、命中数、耗时	命中 D7@P2，约 90 ms
订单工具子 span	工具名、授权结果、资源的受控引用、状态码、耗时	确认 A123 的退款已受理，约 120 ms
模型子 span	提供商与模型版本、提示词模板版本、输入/输出 token 数、首 token 时间、结束原因、耗时	使用 D7@P2 和订单事实；回答预计 3～5 个工作日
答复与质量记录	是否引用 D7@P2、是否通过“不得保证到账日”规则、用户反馈	返回带依据的答复；无风险动作

如果检索与订单查询并行，二者可以是同一个父 span 下的兄弟 span；总耗时不能简单把它们相加。模型工具调用会循环时，每次工具与模型调用都应分别形成可区分的段，并记录循环次数与停止原因。状态迁移也要可见，例如 waiting_tool → waiting_model → completed；这几个名称是本文业务示例，不代表 OpenTelemetry 固定字段。OpenTelemetry 认为有持续时间的操作适合 span，发生在某一时刻的状态变化、超时或审批结果适合事件；事件也可由结构化日志承载。OpenTelemetry：Traces，Span Events · Semantic conventions for events

若流程将来增加“替用户提交加急工单”这种写操作，审批必须单独追踪：记录何时提出申请、审批对象的受控编号、审批人角色、批准或拒绝、等待时长，以及最终是否执行写工具。批准事件不是执行成功事件；要在审批后的工具 span 里再记录实际结果。若跨数小时等待人工，不能依赖一直打开一个进程中的 span 来保存业务状态，应把 R41 或持久化工作流编号与审批事件关联，按所用追踪系统设计跨时段连接。不能把审批人姓名或完整工单内容随意作为可搜索属性。

故障 R42：沿 trace 找到错误答案从哪来

同一用户稍后再次问到账时间，产生新请求 R42。这次检索服务在 2.8 秒后超时；应用转而取了没有有效期校验的缓存 D7@P1，订单工具仍正确返回 A123 已受理。模型依据所见的旧政策答成“7～10 个工作日”。假设用户投诉后，排查顺序是：

1. 先定位这轮请求。 客服提供 R42，后台查到对应 trace_id，看到端到端耗时升高、最终答复内容被用户标为不准确。请求 ID 帮人找记录；trace ID 帮系统连接子步骤。不能把用户随手输入的 ID 当授权凭据，更不能允许跨租户用 ID 查看完整 trace。
2. 看最慢和失败的段。 “检索政策”子 span 在 2.8 秒标记超时，订单工具和模型调用均完成。关联的结构化日志保留超时类别、目标服务、重试次数和 trace_id，不写完整用户问题或数据库凭据。这样先排除“模型响应特别慢”与“订单接口宕机”。OpenTelemetry 日志可携带 Trace ID、Span ID，与 trace 直接关联。OpenTelemetry：Logs
3. 查模型实际拿到的证据。 回退事件写着 fallback=cache、doc_id=D7、policy_version=P1；模型 span 写着实际使用了 P1。对照生效的 P2，便能知道模型输出匹配了错误的上游证据。若只看到“模型说错了”，可能会误把问题归咎于提示词。
4. 修原因并防复发。 修复检索超时与过期缓存判断：取不到当前有效政策时不输出确定到账数字，改为说明暂不能核实并交人工或稍后重试；给政策版本冲突增加质量检查。用 R41、R42 及更多变体做回归评测，再观察检索超时率、旧版引用率与用户纠错率是否下降。这里只是示范排障路径，不意味着有 trace 就能自动识别哪份政策真实有效。

对“为什么答案错”的判断还需离线评测或人工复核：trace 说明模型拿了哪份证据，但不天然知道证据本身对不对。可以为带真值的退款案例建立评测集，分别测“检索是否命中生效版”“模型是否忠实使用依据”“不确定时是否停住”。用户点踩可作为发现线索，不能单独当成准确率真值。针对检索与生成的分开评测也能减少“检索失误被模型漂亮文案掩盖”。

指标与告警：从一条故障看一类故障

Trace 适合问“R42 到底经历了什么”，指标适合问“过去 15 分钟这种问题多不多”。把大量请求按时间窗口统计，例如端到端成功率、95 分位延迟、模型调用错误率和 token/费用、检索空结果与超时率、工具失败和重试率、旧版政策引用率、待审批队列积压。95 分位延迟指 95% 的请求不慢于该值，比只看平均值更能显示少数用户的长等待。OpenTelemetry 的指标用于聚合测量；延迟分布适合用直方图一类数据表达。OpenTelemetry：Metrics

指标标签应限制在低基数、可控的维度，如环境、服务、模型版本、工具类别、结果类别；不要把每个 trace_id、订单号、文档正文或用户问题都做成指标标签，否则序列数量和存储成本会爆炸，也会泄露数据。单次 ID 留在 trace 或受控日志中。费用也别只看模型 token：检索、外部工具、重试和人工审核都有代价。对于模型供应商未返回准确 token 用量的场景，应标明“估算”或“未知”，不要填零假装确定。

告警要对应能采取行动的异常，而不是每个模型调用失败都吵醒值班者。例如：连续窗口内检索超时率超过团队基线并伴随投诉上升；生效政策与回答引用版本不一致；未授权工具调用成功次数大于零；待审批任务超期积压。阈值应结合服务目标、流量大小和历史波动设定，避免低流量时一个失败就产生误报。告警携带服务、时间范围、受控的 trace 链接与排查手册；个人信息不应出现在通知正文。

链路数据量很大时可以采样，但要明确取舍：普通成功请求抽样，错误和高延迟请求优先保留；同时让指标覆盖全部请求，否则成功率会被抽样扭曲。OpenTelemetry 说明前置采样在看到后续结果前决定，尾部采样可根据完整 trace 的错误或耗时再决定是否保存；具体能力取决于部署链路。采样不应掩盖关键审计与审批记录，这些需要按业务留存策略独立保证。OpenTelemetry：Sampling

先设计隐私边界，再打开采集

用户原话、订单详情、检索段落、提示词、模型输出、工具参数与返回值都可能含个人资料或商业秘密。默认优先记录文档 ID、版本、结果类别、耗时和 token 数；确需保存原文用于质量复盘时，单独定义授权、采样范围、脱敏、保留期限、访问审计与删除机制。高敏场景甚至应只保存摘要或受控引用，不将内容送进第三方追踪平台。OpenTelemetry 指出系统无法自动判断业务数据是否敏感，采集者要审查自动埋点，并提供删除、过滤、转换属性的处理方式；简单哈希可预测的用户编号也未必达到匿名化效果。OpenTelemetry：Handling sensitive data

尤其不要在跨服务传播的上下文中塞 API 密钥、手机号或完整用户问题；传播上下文本来会跟随请求到下游，发送给外部服务时还需审视哪些字段可以离开系统。OpenTelemetry：Context propagation，Security best practices 生成式 AI 的通用属性名也仍在演进，当前 OpenTelemetry 文档把不少 gen_ai.* 属性标为 Development，并提醒原始提示词和输出属于敏感内容；工程上可以稳定地记录自己定义的业务字段，同时核对当前语义规范再映射，避免把某个实验字段当成永久标准。OpenTelemetry：Gen AI attributes · OpenTelemetry：GenAI observability

工具平台如何选

可以用 OpenTelemetry 的埋点与采集链路接现有日志、指标和追踪后端，也可以用 LangSmith 等专门查看 LLM/Agent 运行步骤的产品。LangSmith 有 trace、run 和评测能力，适合排查模型与工具交互；但“接入某个产品”不等于完成可观测性设计。无论选哪种后端，都要先定义 R42 这种业务请求如何关联 trace、哪些步骤与状态必须记录、哪些内容绝不能上传、哪些指标触发告警，以及如何从用户投诉回查真实执行。LangSmith 专题可看 Q13：LangSmith 是什么？如何用于 LLM 可观测性监控？。LangSmith：Observability

面试时可以这样说

我会先给每轮请求一个业务请求 ID，并建立一条能跨服务传播的 trace。模型调用、RAG 检索、工具执行分别做 span，记耗时、结果、版本和 token；状态切换、重试、超时及人工审批做带时间的事件，日志带 trace ID，指标汇总成功率、分位延迟、检索和工具错误率、质量与成本。用户说答案错时，先用请求 ID 找 trace，查模型实际拿了哪个文档版本和工具结果，再判断是检索、业务数据还是生成出了问题。原始提示词、用户资料和工具内容默认不全量记录，要脱敏、控制访问和留存。最后把可行动的异常做成告警，并用有真值的案例持续评测，而不是只装一个追踪平台。

面试官若追问“trace 和日志有什么不同”，可以答：trace 给出一次请求中各工作段的父子关系和时间，日志给出某个具体事件的原因，两者用 Trace ID 关联。若问“监控能否保证回答正确”，应答：不能；监控让错误更容易被发现和定位，正确性还需要可信数据、规则校验、评测和必要的人工复核。若问“记录所有提示词是不是更好”，应答：不一定，内容可能含敏感信息，必须按业务必要性、授权与保留策略决定，默认从最少的元数据开始。

资料依据

• OpenTelemetry：Traces · Context propagation：span、trace、跨服务关联与事件。
• OpenTelemetry：Logs · Metrics · Sampling：单次事件、聚合监控与采样。
• OpenTelemetry：Handling sensitive data · Gen AI attributes：敏感数据处理和生成式 AI 字段的当前状态。
• LangSmith：Observability：专门面向模型与 Agent 步骤的追踪产品能力。