前端学 LLM

持续评估、质量门禁与线上反馈闭环

一次离线评估只能说明某个版本在某批样本上表现如何。生产系统的问题是，模型、prompt、知识库、工具、用户输入和业务规则都会持续变化。

持续评估要把 Eval 接入发布、灰度、监控和标注流程，让质量不再依赖上线前的一次人工确认。

提出问题：为什么评估报告不能停在离线阶段

假设客服 AI 每周都会发生变更：周一更新知识库，周二调整 prompt，周三增加一个发票工具，周四灰度新模型，周五运营 Agent 加入自动草拟任务。

每次变更都能跑一次离线评估，但线上仍可能出现问题：

  • 新文档格式变化导致检索召回下降。
  • 新模型更便宜，但引用准确率降低。
  • 工具返回字段变了，模型开始传错参数。
  • Agent 在灰度流量里遇到离线集没有覆盖的异常状态。
  • 用户点了差评，但没有进入评估集，下次仍然复现。

所以评估报告必须进入工程流程：变更前跑回归，发布时设门禁，灰度中看线上指标，事故后补样本，人工标注持续校准。

分析问题：持续评估要覆盖变更、门禁和反馈

持续评估不是单一指标，而是三条链路。

链路解决的问题关键机制失败风险
离线回归改动是否破坏已知样本黄金集、自动评分、人工抽检样本陈旧、指标不可解释
发布门禁低质量版本是否被阻断阈值、owner、豁免、回滚门禁过松或过严
线上反馈新失败是否沉淀为样本用户反馈、人工修改、trace 回放、标注队列反馈无法归因、无人处理

RAG、Tool 和 Agent 的持续评估重点不同。

类型离线重点线上重点门禁重点
RAG Evalrecall@k、faithfulness、citation accuracy、拒答无答案率、引用点击、差评、文档更新后退化黄金证据召回和引用准确率不能低于阈值
Tool Eval工具选择、参数准确、权限校验、确认工具失败率、无权限率、重复写入、人工取消率高风险工具不能绕过确认和权限
Agent Evaltask success、plan adherence、loop、recovery步数异常、超预算、人工接管、恢复失败loop rate、误写入、目标漂移必须阻断

模型可以参与线上反馈归因，但业务 owner 必须负责最终分类。否则差评、纠错和事故会变成一堆无法行动的标签。

列举方案：从 CI 回归到线上闭环

第一层，变更触发离线评估。

以下变更都应该触发评估：

  • 模型、temperature、系统 prompt 或工具描述变化。
  • RAG 的 chunk、embedding、rerank、过滤规则变化。
  • 知识库批量更新或权限策略变化。
  • 工具 schema、返回字段、runtime 策略变化。
  • Agent 的 planner、预算、工具集合或恢复策略变化。

第二层，建立质量门禁。

门禁不应该只有一个总分。更合理的是按风险设置硬门禁和软门禁。

门禁类型示例处理方式
硬门禁schema pass rate 低于 99%，高风险工具绕过确认阻断发布
硬门禁RAG 高风险样本 citation accuracy 下降超过阈值阻断或降级
软门禁低风险文案完整性轻微下降owner 审批后灰度
趋势门禁成本或延迟上升超过预算进入性能评审
人工门禁judge 与人工分歧集中在高风险类目专家复核

第三层，灰度和影子评估。

高风险变更不应直接全量发布。可以使用：

  • Shadow evaluation：新版本只评估不对用户生效。
  • Canary：小流量灰度，观察关键指标。
  • Champion / challenger：旧版本和新版本并行比较。
  • Human review lane：高风险样本进入人工审核后再生效。

第四层，线上反馈闭环。

线上反馈不只是点赞点踩。更有价值的是结构化反馈：

反馈来源可转化为样本的内容
用户差评问题、答案、原因、期望答案
人工编辑原答案、修改后答案、修改字段
工具取消模型建议动作、用户取消原因
转人工触发条件、上下文、人工处理结果
事故复盘trace、根因、修复方案、回归样本

第五层，标注和再训练评估流程。

反馈样本进入队列后，要经过脱敏、去重、分类、标注、仲裁和入库。不是所有差评都应该进入黄金集：有些是产品预期不一致，有些是知识库缺文档，有些是权限策略正确拒绝。持续评估要把问题归因到数据、检索、prompt、工具、Agent 策略或用户预期。

决策判断：质量门禁应该卡什么

场景条件推荐门禁不推荐门禁判断理由额外成本
结构化输出入库schema pass + 字段校验 + 重试失败率只看文本评分入库错误必须硬拦截校验器和错误分类
RAG 对外回答retrieval recall + faithfulness + citation accuracy只看用户满意度用户可能无法识别误引用证据标注和 judge 抽检
查询类工具工具选择 + 参数准确 + 权限通过只看 API 成功率API 成功不代表业务正确工具 trace
写入类工具权限 + 人工确认 + 幂等 + 审计自动 judge 放行副作用必须可控确认 UI 和动作日志
Agent 多步骤任务task success + loop rate + plan drift + recovery只看最终回复过程错误可能造成副作用trace 回放和轨迹评分
高频低风险文案抽样 judge + 用户反馈趋势每条人工审核风险低，人工成本不划算抽检和趋势监控

明确判断是：质量门禁要卡“不可接受的风险”，而不是卡所有质量波动。过松的门禁挡不住事故，过严的门禁会让团队绕过评估。合理门禁应该区分硬失败、可灰度问题和需要人工审批的争议样本。

常见反模式包括：

  • 门禁只看平均分，掩盖高风险类目的退化。
  • 线上反馈只展示在仪表盘，不进入样本和 owner 流程。
  • 事故修完代码但不补回归样本。
  • Judge 评分下降无人分析，最后门禁被长期关闭。
  • 只监控模型输出，不记录检索、工具调用和 Agent trace，导致无法归因。

结论收束：持续评估让质量进入日常工程

持续评估的推荐方案是：离线黄金集负责已知风险，质量门禁负责发布控制，灰度监控负责发现真实流量问题，线上反馈和人工标注负责更新评估集。

上线前检查清单：

  • 触发条件：哪些变更必须运行哪些评估。
  • 指标分层：RAG、Tool、Agent 和最终输出是否分开报告。
  • 门禁阈值：哪些指标硬阻断，哪些指标进入审批或灰度。
  • Owner 机制：每个失败类目是否有人负责判断和修复。
  • 人工标注：反馈样本是否有脱敏、去重、标注和仲裁流程。
  • 线上采集：是否记录用户反馈、人工修改、工具取消、转人工和事故 trace。
  • 回放能力：是否能复现一次请求的 prompt、上下文、检索、工具、模型版本和输出。
  • 灰度策略：是否支持 shadow、canary、回滚和降级。
  • 成本延迟：质量提升是否伴随不可接受的费用或响应时间上涨。
  • 复盘闭环：每次事故是否补充回归样本和门禁规则。

当系统低频、低风险、人工全量复核时，持续评估可以先从小型回归和人工抽查开始。当系统进入高频生产、自动执行工具或 Agent 自主流程时，质量门禁和线上反馈闭环就不是锦上添花，而是上线条件。