大模型应用上线后，真正难处理的往往不是接口能否调用，而是三个更实际的问题：一次错误回答经历了哪些步骤、版本升级是否让整体质量退化、线上差评怎样变成下一轮可复用的测试样本。要回答这些问题，不能只增加日志，而要把追踪、评测、实验和反馈设计成同一条数据链路。
先明确：可观测与评测解决的问题不同
大模型可观测关注“发生了什么”。一次请求不应只有最终答案，还应能还原提示词版本、模型与参数、检索片段、工具调用、各步骤耗时、Token 用量、异常以及最终输出。对于 RAG 或 Agent 应用，建议把一次用户请求作为根 Trace，再将检索、重排、模型生成和工具执行拆成可识别的子步骤。
评测关注“结果是否合格”。它需要针对业务目标定义标准，例如：
- 结构化输出能否通过 JSON Schema 校验；
- RAG 回答是否获得了足够的证据支持；
- 工具选择、参数和调用顺序是否正确；
- 客服回答是否覆盖关键政策且没有越权承诺；
- 延迟、Token 消耗与质量是否处于可接受区间。
二者必须关联。只有 Trace 而没有评分，团队只能逐条翻日志；只有离线分数而没有 Trace，低分后又难以定位是数据、检索、提示词还是模型导致。
一条可落地的数据链路
建议给每次请求分配稳定的 trace_id，同时记录 session_id、应用版本、提示词版本、模型版本、租户或场景标签。链路可以按下面的方式组织：
用户请求
└─ Trace
├─ 输入治理与安全检查
├─ 检索 / 重排
├─ Prompt 渲染
├─ 模型生成
├─ 工具调用
└─ 输出校验与用户反馈字段设计要服务于后续筛选和比较。观测名称应保持稳定，不要直接用模型名称充当步骤名，否则切换模型后仪表盘和评测规则容易失效；模型、版本、实验分组等变化项更适合放在属性或元数据中。
对于提示词，也不要只保存一段最终字符串。更实用的做法是记录模板版本、变量摘要和发布环境，并把该版本关联到生成步骤。这样才能比较某个提示词版本的错误率、质量分和成本，而不是依靠人工回忆。
评测集怎么建，才能真正防止退化
第一版评测集不必追求规模，先覆盖高价值和高风险路径。样本可来自四类来源：
- 产品必须通过的典型任务；
- 历史故障和用户差评；
- 容易混淆的边界条件；
- 涉及权限、安全、合规的高风险输入。
每条样本至少应包含输入、必要上下文、期望行为和评分规则。能够确定判断的项目优先用代码评测，例如格式、字段、正则、工具参数和引用数量；语义正确性、完整性、语气等难以完全规则化的维度，可以使用人工评分或基于明确量表的模型评审。不要只保留一个“总分”，否则分数下降时无法判断是哪一项出了问题。
评测还应分成两层：
- 离线评测：在发布前用固定数据集比较提示词、模型或检索策略，适合回归测试和版本准入；
- 在线评测：对真实流量抽样，监测质量趋势、异常输出和新出现的边缘问题。
线上低分样本经过脱敏和人工确认后，再回流到离线评测集，才能形成持续扩展的回归边界。
Prompt 实验不要只比较平均分
A/B 实验的前提是候选版本已经通过离线评测。直接把未经筛选的提示词投向真实用户，不仅风险高，也会把明显错误混入实验结果。
实验时应固定分流规则，并同时观察多个维度：任务成功率、人工或模型评审分、用户反馈、端到端延迟、Token 消耗以及安全拦截率。平均分相近时，还要查看不同业务场景的分层结果和尾部表现。有些版本可能总体略高，却在高价值客户或关键任务上明显退化。
对小流量应用，不宜过早下结论。样本不足时，可以先把实验作为趋势信号，结合离线数据和人工复核决策，而不是包装成具有统计确定性的结果。
Langfuse、LangSmith 与 OpenTelemetry 怎么选
工具选型不应从功能清单出发，而应从现有技术栈、数据边界和维护能力出发。
- 团队深度使用 LangChain 生态，希望快速把追踪、数据集和离线/在线评测串起来，可优先评估 LangSmith；
- 希望采用开源方案、自托管，或让多种框架共享同一套大模型可观测平台，可评估 Langfuse；
- 已有 Prometheus、Grafana、Jaeger、Datadog 等运维体系时，可以用 OpenTelemetry 统一采集和传递遥测数据，再按用途输出到大模型观测平台与基础设施监控平台。
OpenTelemetry 解决的是遥测标准化和数据传输，不会自动替团队定义“回答是否正确”。相反，专用平台提供 Trace、数据集、实验和评分能力，也不能替代主机、容器、网络和数据库监控。更合理的架构通常是复用统一的 Trace 上下文，但让质量分析和基础设施运维各自使用合适的后端。
最小可用方案：分四步建设
第一步：先让问题可追溯
接入全链路 Trace，确保能看到输入、输出、检索、工具调用、模型参数、耗时和错误。产品侧增加点赞、点踩或问题类型反馈，并与 trace_id 关联。对敏感输入先脱敏，再决定是否存储全文。
第二步：建立发布前回归门槛
从典型任务和历史故障中整理一小批评测样本，配置确定性代码检查与少量人工或模型评审。将评测接入 CI，但门槛应按关键指标分别设置，避免总分掩盖严重退化。
第三步：再做版本实验
候选提示词、模型和检索策略先离线比较，通过后再小流量上线。所有实验分组都记录版本和配置，保证结果能够复现。
第四步：打通反馈回流
定期筛选差评、低分、异常高成本和关键业务 Trace，进入标注队列。确认后的问题样本加入评测集，修复完成后执行回归，再进入下一轮发布。
上线前容易忽略的四个风险
- 敏感数据泄露：Prompt、检索文档和工具参数可能包含个人信息、密钥或业务机密，需要脱敏、权限隔离和保留周期策略。
- 观测成本失控：全文保存、长链路和高采样率会增加存储与传输成本，应按场景设置采样并保留关键失败请求。
- 评审器漂移：模型评审本身也会变化，应固定评审模型与量表，并保留一部分人工校准样本。
- 指标被优化偏：团队如果只追一个分数，容易牺牲延迟、成本或安全性。发布决策应设置多个硬性约束。
结语
大模型可观测的价值，不是把每次调用记录得更详细，而是让线上问题能够被定位、复现并转化为评测样本。对个人开发者和小团队，最务实的路径是先打通 Trace 与用户反馈，再建立小而可靠的回归集，之后逐步增加 Prompt 实验和自动化评测。工具可以替换，但 追踪 → 反馈 → 标注 → 评测 → 实验 → 发布 这条闭环应当长期保留。