Annabell 在 Langfuse Academy 系列中讲解了 AI 工程监控的核心逻辑。这不是关于搭建仪表盘，而是关于建立从生产数据到系统改进的闭环。
AI 工程循环回顾
AI 工程循环连接生产环境（tracing、监控）和开发迭代（数据集、实验、评估）。每次发布的改进产生新数据，团队持续循环这个过程。
监控在循环中的位置：tracing 提供完整记录——每个请求、每个模型调用、每个工具使用。监控则是理解这些数据的方式：持续观察系统随时间的表现，以及发现值得调查的具体 traces——错误、用户行为模式、意外情况。
两类监控活动
聚合指标追踪回答"事情是否在变好或变坏"。成本、延迟、评估分数——这些成为可以观察和推理的趋势。上周二的 prompt 改动改善了什么吗？质量是否随使用增长而漂移？
信号检测回答"现在该看哪里"。它发现值得调查的个人 traces：错误、重试集群、用户中途放弃对话。信号有用是因为附带了触发它的具体 trace，这个 trace 是理解问题的起点。
数据来源
聚合指标和信号检测都依赖附加到 observations 的字段。很多数据在正确 instrument 后已经存在：延迟、token 成本、模型和路由元数据、工具结果、错误——这些从客户端和 provider API 自然流出，无需额外布线。
在此基础上，你添加评估：
- 显式反馈：直接评分、点赞/点踩、评论——信号明确但响应率低，不满意用户比满意用户更常回应
- 隐式反馈：从行为推导——用户是否重试查询、是否不同意系统、是否复制响应、是否接受建议、是否中途放弃对话。无需用户努力，生成高容量数据，但信号间接需要解释
评估器类型
- LLM-as-a-judge：用于质量信号或行为模式（如用户不同意）
- Code-based 评估器：精确检查，如响应是否包含特定词或超过长度限制
从哪里开始
从小处开始，从真实 traces 而非抽象想法构建监控：
- 先手动查看数据——阅读 traces，注意反复出现的东西
- 用错误分析发现值得追踪的模式——找到跨 traces 的重复问题
- 思考你的特定应用如何显示失败——应用特定的隐式信号通常比通用分数更可操作
- 当作迭代过程——使用模式变化、模型更新、新失败模式出现，持续精炼
下一步
当监控发现值得调查的东西时，你有几个选择：如果原因明显直接修复；如果看起来像模式则捕获到数据集；如果怀疑是系统性问题则运行结构化评估。
监控不是配置一次就离开的仪表盘。它是持续理解系统的实践。