LangSmith 02：观测、调试与反馈闭环

#1、本篇任务：把“用户说答错了”变成可重复诊断

Trace 是原始运行记录，Observability 是用 trace 回答运营问题：哪类请求在失败；从哪个版本开始；影响谁；应由哪个团队处理。

#2、一次投诉的固定排查顺序

收到 request ID 后：

1. 确认 environment、release、模型/prompt/index 版本。
2. 检查路由是否选择正确流程。
3. 检查 retriever 的 filter、chunk ID、得分和是否无命中。
4. 检查工具是否按正确用户执行，错误是权限还是依赖故障。
5. 检查模型实际获得的上下文，是否被预算裁掉。
6. 检查输出 schema、业务校验和前端适配。
7. 将最小复现输入加入数据集，再修改系统。

不要先改 prompt。很多“模型答错”实际是索引版本、ACL filter、工具数据或 UI 丢字段。

#3、把指标按系统层次组织

每个图表写 owner、正常基线、告警阈值和 runbook。只展示“调用次数”但没有行动规则，不算可观测性。

#4、用症状反查根因

P95 上升且工具耗时上升，先检查依赖/并发；拒答率突然升高且索引版本刚变，检查索引；工具次数暴涨且 prompt 刚变，检查路由与循环；成本上升但请求数不变，检查上下文长度和重试；引用有效率下降但检索命中稳定，检查生成和后处理。

按 release、tenant、intent、tool、model 分组比看总体平均更有用。平均值可能掩盖某个租户完全不可用。

#5、反馈必须能驱动修复

反馈键使用具体维度：correctness、citation_validity、tool_safety、helpfulness、ux_latency。同时记录 reviewer 类型和失败层：用户差评只是信号，运营/专家审核后才能成为可靠标签。

复制type Feedback = {
  runId: string;
  key: "correctness" | "citation_validity" | "tool_safety" | "ux_latency";
  score?: number;
  comment?: string;
  reviewer: "end_user" | "operator" | "auditor";
  failureLayer?: "routing" | "retrieval" | "tool" | "generation" | "ui";
};

低分 trace 去敏后进入审核队列；确认有代表性的案例再进入离线 dataset。不要自动用所有用户差评修改 prompt 或长期记忆。

#6、在线 evaluator 的限制

在线规则可检查 schema、引用 ID、工具安全和异常模式；LLM judge 可规模化评估语义质量，但必须用人工金标校准，观察假阳性与假阴性。安全问题不能只靠 judge，仍要确定性规则和人工复核。

在线评测会增加成本，应独立设置过滤器与采样率。发布新版本时提高采样，稳定后恢复。

#7、本篇验收

从一条“订单答错”反馈出发，15 分钟内定位到具体层和版本；仪表盘能区分检索空、工具 500、schema 失败；告警能链接到 runbook；修复后同一案例进入离线回归，而不是只写一份复盘。

下一课建立正式 Dataset、Evaluator 和实验比较，让修复结果可以量化。

官方阅读：Observability、Evaluation Concepts。