---
type: study
created: 2026-08-11
updated: 2026-08-11
sensitivity: standard
status: verified
tags:
  - langchain
  - langsmith
  - monitoring
  - evaluation
topic: LangSmith 监控、仪表盘、告警、自动化与在线评估
sources:
  - https://docs.langchain.com/langsmith/alerts
  - https://docs.langchain.com/langsmith/dashboards
  - https://docs.langchain.com/langsmith/insights
  - https://docs.langchain.com/langsmith/online-evaluations-code
  - https://docs.langchain.com/langsmith/online-evaluations-composite
  - https://docs.langchain.com/langsmith/online-evaluations-llm-as-judge
  - https://docs.langchain.com/langsmith/online-evaluations-multi-turn
  - https://docs.langchain.com/langsmith/optimize-classifier
  - https://docs.langchain.com/langsmith/rules
last_verified: 2026-08-11
---

# 监控、仪表盘、告警、自动化与在线评估

> [!summary]
> 生产闭环不是“给每条 trace 打分”，而是用稳定筛选定义观测人群，用低成本指标持续监控，用高成本评估抽样诊断，再把确认的问题转成数据集和回归测试。

## 一、能力分层

| 能力 | 回答的问题 | 适合 |
|---|---|---|
| Dashboard | 系统长期趋势怎样 | SLO、成本、延迟、质量 |
| Alert | 哪个阈值刚越界 | 实时运营和事故响应 |
| Rule / Automation | 匹配 trace 后做什么 | 评估、webhook、队列、保留 |
| Online evaluation | 当前输出质量怎样 | 持续质量信号 |
| Insights | 生产数据里有哪些未知模式 | 聚类、失败模式、专题报告 |

## 二、Dashboard

内置统计适合快速查看 error、latency、tokens、cost、feedback。Custom Dashboard 可配置：

- 时间序列、分类/分组图。
- count、rate、sum、avg、P50、P90/P99 等聚合。
- input/output/total token 与 cost。
- feedback、run type、metadata 和 tags 过滤/分组。

生产约束：

- 自定义分组通常只展示 Top 20，高基数尾部会被折叠；图上没有不等于数据不存在。
- metadata 不会自动从任意子 run 反向继承到 root。要按租户/版本看 root 指标，就在 root 写字段。
- 缺失时间点应被理解为“无数据”，不是零；近期图表已改为跨缺口连线。
- 极小成本可显示到 8 位小数，不要在业务层先粗暴舍入。
- P99 需要足够样本；低流量窗口应同时展示 count。

推荐最小生产看板：

1. 请求量、成功率、错误率。
2. root latency P50/P95/P99、LLM TTFT。
3. total/input/output tokens 与总成本。
4. 关键 feedback 通过率。
5. 按 release、provider/model、route、tenant tier 切片。
6. 采样率、trace 丢弃和 evaluator 错误率。

## 三、Alert

告警可围绕错误率、延迟、feedback 等指标，支持窗口、阈值和通知目标，包括 webhook 与 Slack。

设计原则：

- 阈值必须带最小样本量，避免 1/1 错误触发 100% 错误率。
- 同时定义触发与恢复；没有恢复语义会让通知长期失真。
- 窗口要匹配业务波动，5 分钟故障告警和 24 小时质量退化不能共用阈值。
- 告警消息包含 project、filter、窗口、当前值、阈值、run/trace 深链和 owner。
- webhook 接收端要验签、幂等和快速应答。

“测试 webhook”只证明 LangSmith 能向 URL 发请求，不会验证下游工单、PagerDuty 或聊天机器人已正确处理。必须做端到端演练。

## 四、Rules / Automations

Rule 由触发范围、filter、采样和 actions 组成，可用于：

- 运行 evaluator。
- 加入 annotation queue。
- 触发 webhook。
- 调整 trace retention。
- 其他反馈/数据操作。

执行语义：

- 同一 rule 内 action 按配置顺序运行。
- 不同 rules 之间没有全局顺序保证。
- 下游 action 不应假设另一条 rule 已先写 feedback。
- evaluator 或 action 失败要可见，不能把“未评分”当作“得分为零”。
- 无 filter 的预置 evaluator 当前默认只跑 root runs。

若流程存在依赖，把它们合并到同一 action pipeline，或由 webhook 下游显式编排；不要利用偶然执行时间建立隐式依赖。

## 五、Code evaluator

Code evaluator 适合确定性、低延迟规则，例如：

- JSON/schema 校验。
- 敏感词或长度。
- 工具是否被调用。
- 业务字段一致性。

要求：

- 纯函数、明确超时、固定依赖。
- 异常写 evaluator error，不产生虚假 score。
- 对缺失输入/输出定义策略。
- 把 evaluator 版本写入 feedback source/metadata。

代码评估器适合“能精确表达”的规则；不要用复杂启发式假装语义正确性。

## 六、LLM-as-a-judge

适合相关性、正确性、风格、完整性等语义指标。配置包括：

- judge prompt 与变量映射。
- 模型配置。
- score 类型和 rubric。
- 可选参考答案、上下文和 few-shot。

生产风险：

- judge prompt 和模型升级会改变分布。
- 被评输出可能 prompt-inject judge。
- 成本和延迟会随 trace 量放大。
- 同一 provider/model 既生成又评估可能产生相关偏差。

应先用人工标注样本做校准，按版本监控一致率，再逐步增加在线覆盖。

## 七、Composite evaluator

Composite 可对多个 evaluator 做 weighted average 或 weighted sum。它适合建立单一发布门槛，但有三个前提：

1. 所有子分数方向一致。
2. 缺失/错误分数有明确处理。
3. 权重来自业务影响，而不是为了让当前版本过线。

保留子指标，不能只看总分；相同总分可能代表完全不同的失败组合。

## 八、多轮在线评估

Multi-turn evaluator 面向 thread，能评估语义意图、最终结果和 Agent trajectory。它不是每个 run 独立打分。

文档中的当前限制包括：

- 每 5 分钟最多处理约 500 个 threads。
- 每 workspace 最多配置约 10 个多轮 evaluator。
- 只有满足完整会话条件的 thread 才应进入评估。

限制属于当前产品状态，部署前应在 UI/计划中再次核验。

生产设计：

- thread idle time 要覆盖迟到 turn。
- 去除仍在进行中的会话。
- 对超长轨迹定义截断/摘要策略。
- 将 thread feedback 与 run feedback 分开。
- 样本需覆盖成功、放弃、转人工、超时和工具失败。

## 九、Classifier 优化

Optimize classifier 用已标注例子迭代分类/评分器。有效流程：

1. 定义互斥、可判定标签。
2. 收集困难例和边界例，而非只收“明显样本”。
3. 拆分 train/validation/test。
4. 优化 prompt/模型后只在 validation 选择。
5. 在冻结 test 上报告每类 precision、recall 和混淆矩阵。
6. 上线后持续采集漂移样本。

对严重不平衡分类，accuracy 没有意义；告警应关注关键类 recall 与误报成本。

## 十、Insights

Insights 对生产 traces 做聚类、差交互分析和自定义报告，可定时按 daily、weekly 或 cron 运行。当前产品信息指向 Plus/Enterprise，并可能受区域/部署能力限制。

Insights 用于发现未知模式，不替代确定性告警。聚类摘要是模型推断，应回到代表性 traces 验证，再形成 rule/evaluator。

## 十一、闭环

    trace → dashboard/alert → 定位代表样本
          → 人工确认 → dataset
          → 离线评估/回归门槛
          → 新版本灰度 → 在线 evaluator
          → dashboard 持续比较

每个指标都应有 owner、定义、数据范围、版本、阈值依据和处理手册。