运维 / 评估与可观测性
评估与可观测性
度量没有唯一正确答案的智能体——结果与轨迹评测、LLM 作裁判、追踪与基准。
- 为什么评估智能体很难非确定性、多步复合误差、没有唯一标准答案、路径依赖、评估成本与数据集腐烂——单个干净数字是谎言的六个原因。
- 在线评测与离线评测离线评测在发布前抓住回归；在线评测抓住你伪造不出来的用户行为——为何你两者都需要，以及它们各自会在哪里骗你。
- 结果评估 vs 轨迹评估终态谓词与给决策序列打分：各自何时为正解、部分给分，以及作为最高杠杆安全检查的工具调用断言。
- 用 LLM 作为智能体评判者评分量表设计、成对 vs 单点、能颠倒裁决的偏差、针对人类标注校准，以及那些绝不该用评判者的情形。
- 批判地阅读智能体基准SWE-bench、GAIA、τ-bench、WebArena 实际测量什么，污染与框架敏感性为何让名次成为弱信号，以及真正做决定的小型自定义集。
- 智能体的追踪与可观测性轨迹是数据结构而非日志：每步记录什么、span 与 OpenTelemetry GenAI 约定，以及作为通往评估之桥的轨迹回放。
- 评估驱动的智能体开发评估是智能体唯一的规格：分层 CI 关卡、黄金轨迹、离线 vs 在线、生产到评估的飞轮，以及无回归棘轮。
- OpenTelemetry GenAI 语义约定埋点是数据模型决定，不是看板决定：agent/workflow/tool/model 四类 span、为何 Development 状态是钉版本而非等待的理由、在 collector 处把结构性遥测与提示词内容分流，以及那一跳让此后每个厂商选择都可逆的 collector。
- 质量回归检测生产环境没有标签，而一个靠评判的指标要看清五个百分点的下滑需要约 1,400 次打分运行；因此探测器是运行的形状——撞上限比例、按工具报错、终止构成——评判只是确认环节。
- 生产反馈信号点赞点踩来自不足百分之一的会话，且奖励自信甚于正确；而"智能体输出"与"用户最终交付物"之间的差异，是一份稠密、免费、由领域专家写下的标签——把每个反馈信号当作通往评测集的路由器，而不是要优化的指标。
- 标注运营裁判的准确率不可能高过校准它的那批标签，所以如果你的两位专家在 72% 的轨迹上一致，一个 72% 的裁判早已触顶——先量标注员间一致率，把一致率低读作评分标准的缺陷，并把分歧路由去裁决而不是平均掉。
- 轨迹采样与保留在运行开始时抽 10%，你就只留下了 10% 的失败，而第零步没有任何东西能预测哪次运行会出问题——所以缓冲到运行结束，把每一次失败、撞上限与超贵的运行整条留下，把成功狠狠砍掉，并把保留期当作一个关于"你还没建起来的那个评测集"的决定。
- 智能体评估中的模拟用户每一个多轮智能体分数量的都是两套系统，而第二套是一个没有版本、扮演客户的模型，它单凭自己就能把你的数字挪动好几个点——把它的模型 ID、提示词与随机种子像依赖一样钉住、拿真实对话记录去校准它、绝不让它来评判自己满不满意，并给评分者一个显式的"模拟器故障"裁定项。
- 度量智能体延迟一条十五步的轨迹会把"百分之一的慢调用"变成"七分之一的慢任务"，所以单步的 p99 比它的 p50 更能预测用户体验——请度量轨迹而不是调用、把模型时间、工具时间与排队时间拆开，并把"到首个有用输出的时间"与"到做完的时间"分开来看。
- 维护一套评测集评测集是被拟合掉的，不是放烂的：你每修好一个回归，就把一条有区分力的用例变成一次永久通过——所以要量"所有候选都已通过"的用例占比，按"改变过多少次别人的主意"给用例打分，并用一个常设的更换速率取代周期性大扫除。
- 智能体的线上实验要看清任务成功率三个百分点的提升，在算上智能体特有的因素之前，每组就已经需要约 3,700 次会话，而按用户聚类通常还要再乘三——所以按用户而不是按请求随机分组，事先锁定唯一一个按方差挑选出来的决策指标；当算术告诉你这个实验做不起时，就改跑一次带护栏的灰度发布，并如实这样标注它。