LLM 评测与可观测性：把一次回答变成可回归的工程指标

AI 功能上线后最危险的状态是“感觉还不错”。模型、提示词、检索库和工具都在变化，单看平均满意度无法定位回归。需要把每次请求记录为一条可脱敏的实验样本。

建立分层评测集

评测集至少分为黄金集、对抗集和线上采样集。黄金集覆盖核心业务路径；对抗集覆盖提示注入、越权、长上下文和空结果；线上采样集按租户和意图分层抽样。每条样本包含问题、期望结论、允许引用范围、不可出现的内容和评分规则。

评分不能只有一个总分

把质量拆成可解释的维度：事实正确性、引用覆盖、任务完成、格式合规、拒答准确、工具参数正确和安全拦截。规则评分适合 JSON、金额和字段完整性；模型评分适合语义相似和解释质量，但要抽样人工复核，监测评分模型漂移。

追踪完整链路

一次请求要关联 request_id、trace_id、model、prompt_version、retriever_version、tool_calls、token_usage 和 latency。每个 span 记录输入输出摘要与错误分类，默认不记录原始敏感文本。线上看 P50/P95 延迟、首 token 时间、失败率、人工接管率、每千 token 成本和拒答率。

上线门禁和回滚

提示词或模型变更先跑离线集，要求关键指标不低于基线，安全对抗集不得出现新高风险样本。灰度阶段按租户或流量比例发布，实时比较质量、成本和延迟；发现回归时只切换 model/prompt 配置版本，不重新部署整个应用。

评测系统最终要服务于决策：告诉团队哪一类问题变差、损失来自检索还是生成，以及修复后是否真的恢复。

参考资料：OpenTelemetry 文档。