传统软件出错会抛异常，而 LLM 应用经常是“没报错，但答得不对”。可观测性（Observability）建设，是 LLM 应用从演示走向生产的关键一步。

【一、需要记录什么】
- 每次调用的输入（提示词、检索到的上下文）、输出、模型名称与版本、参数（temperature 等）。
- token 用量、耗时（TTFT 与总时长）、成本估算。
- 工具调用的名称、参数、返回结果与错误。
- 用户反馈：点赞/点踩、是否转人工、是否重新提问。
注意脱敏：日志中可能包含个人信息或机密，需要做好访问控制和保留期限管理。

【二、链路追踪（Tracing）】
一个请求可能包含查询改写、检索、重排、多次模型调用和工具调用。用 trace/span 的方式把整条链路串起来，才能定位“到底是哪一步出了问题”。OpenTelemetry 是通用的追踪标准，社区也有不少面向 LLM 的开源追踪与评估平台，可按需选择，注意查看许可证与部署方式。

【三、提示词与配置的版本管理】
- 把提示词当作代码管理：放进版本控制，每次修改有记录、可回退。
- 每条日志都记录提示词版本号，便于对比不同版本的效果。

【四、回归测试】
- 维护一个评测集（参见模型版相关帖子），每次修改提示词、更换模型、更新知识库时自动运行。
- 结合规则检查（格式、长度、敏感词）与模型打分。
- 设定阈值：关键类别分数下降超过一定幅度时阻止发布。

【五、线上监控与告警】
- 监控错误率、延迟、成本、拒答率、转人工率的变化趋势。
- 定期抽样人工审查线上对话，发现评测集没有覆盖的新问题，并补充到评测集中。

【常见坑】
- 只记录最终输出，不记录检索内容，无法判断问题出在检索还是生成。
- 模型服务商静默更新版本，导致效果变化却无从追查。尽量固定带日期或版本号的模型名称。

讨论：
1. 你们使用什么工具做 LLM 调用的追踪与评估？
2. 回归测试中，你们如何平衡自动打分与人工审查？