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

生产闭环不是“给每条 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。

推荐最小生产看板：

请求量、成功率、错误率。
root latency P50/P95/P99、LLM TTFT。
total/input/output tokens 与总成本。
关键 feedback 通过率。
按 release、provider/model、route、tenant tier 切片。
采样率、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。它适合建立单一发布门槛，但有三个前提：

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

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

八、多轮在线评估

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 用已标注例子迭代分类/评分器。有效流程：

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

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

十、Insights

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

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

十一、闭环

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

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