15 评估、反馈与持续改进

本章产出： 一套覆盖离线评测、上线门禁、线上监控、人工反馈和业务结果的持续评估闭环。

演示中的 Agent 往往显得聪明，因为演示者挑选了系统擅长的问题，熟悉正确问法，也会在失败时迅速换一个例子。生产环境没有这样的善意：用户表达含混，数据存在缺口，规则相互冲突，攻击者会试探边界，业务状态在回答生成期间继续变化。一次漂亮回答不能证明系统可靠，一个笼统的“准确率”也无法解释系统为何失败。

评估的目的不是给模型颁发分数，而是支持决策：是否允许上线，是否扩大人群，哪一层应该改进，风险是否仍可接受，投入是否产生业务价值。它必须把数据、检索、生成、工具、体验和流程分开观察，再通过共同任务标识连接起来。

15.1 先定义“好任务”，再定义“好答案”

不同任务的成功含义不同。知识查询可能要求事实正确、引用充分；诊断建议还要求步骤适用、风险提示完整；自动创建工单则要求参数正确、幂等和业务状态成功。评估对象不应只是最终文本，而是完整任务轨迹。

可以用任务契约描述：

用户、场景、输入与前置条件；
允许使用的数据产品和工具；
必须出现的事实、证据与限制；
允许的表达差异；
明确禁止的结论和动作；
证据不足时预期澄清、拒答或转人工；
成功的业务状态与最大风险；
延迟和成本边界。

山城精工的一个样本可以规定：给定某型号设备、固件和 E37 故障，助手应引用有效手册中的特定章节，给出三项排查步骤，不应使用已撤回旧版资料，不得承诺库存；若设备配置缺失，则必须先澄清。这样的样本比“答案与参考文本相似”更接近真实责任。

15.2 五层评估模型

15.2.1 数据与上下文

检查关键实体是否识别、字段是否完整、规则是否有效、数据是否在 SLO 内、权限与适用范围是否正确。若输入事实错误，后面即使忠实引用也可能错误。数据层指标应能定位到来源和负责人。

15.2.2 检索与证据

检查正确证据是否被召回、错误版本是否被过滤、排序是否进入有限上下文、引用是否可达、无证据问题是否被识别。关键词、向量、结构化查询和图关系分别评估，也评估组合规划。

15.2.3 生成与推理结果

检查事实支持、规则遵守、完整性、相关性、结构模式、语言清晰和不确定表达。不要要求保存或展示模型的隐藏思维过程；评估外部可验证的输入、证据、输出与决策状态即可。

15.2.4 工具与行动

检查工具选择、参数、权限、调用顺序、幂等、超时、重试、审批和最终业务结果。HTTP 返回成功不代表业务成功，必须确认权威系统状态。对禁止动作和提示注入单独评估。

15.2.5 业务与风险

检查任务完成时间、人工修改、采用、一次解决率、客户结果、单位成本、高风险错误、越权和安全事件。上层指标变差时，下层指标帮助归因；下层分数提高但业务无变化时，应重新审视场景和流程。

15.3 构建有代表性的评测集

评测集不应只来自产品经理编写的理想问题。它可以由以下来源组合：

历史真实任务与已确认结果；
业务专家设计的关键规则和高风险边界；
用户试点中的失败与澄清记录；
数据质量事件和历史事故；
权限、隐私和提示注入对抗样本；
新规则、新产品和长尾表达；
明确无答案或信息不足的问题。

样本按常见、困难、边界、对抗、无答案分层，并标注用户角色、实体、时间、预期证据、允许动作和风险权重。随机切分历史工单可能导致同一设备或模板同时出现在开发和测试，产生数据泄漏；应按时间、客户、设备或事件分组隔离。

黄金答案不必是一段固定文字。可以标注必须事实、可选事实、证据集合、禁止项和结果状态，让不同表达都能通过。对于复杂建议，由多名专家独立标注并解决分歧，分歧本身也揭示业务规则尚未统一。

评测集有生命周期。规则变化、数据范围扩大、用户表达演进后，样本需要版本和复审。已经用于反复调优的集合会被团队过度适配，应保留盲测集并定期引入新样本。

15.4 自动评估与人工评估

确定性内容优先用程序检查：模式、数值、日期、引用存在、权限过滤、工具参数、业务状态。语义正确和表达质量可以使用规则、相似度或模型评审辅助，但不能把另一个模型的判断当作绝对真相。

模型评审要有明确量表、参考证据和示例，检验与人工专家的一致性，并防止偏爱冗长或特定文风。高风险样本由专家复核，争议进入仲裁。自动化适合扩大覆盖和发现变化，人工评估负责校准含义与风险。

建议报告置信区间、样本构成和失败分布，不只给一个平均数。总体九成正确可能隐藏某类高风险问题全部失败。按设备系列、用户角色、语言、问题类型和风险等级切片，才能发现系统性偏差。

15.5 上线前的分级门禁

生产发布可以经历：

开发评测：组件和端到端集合持续运行；
红队与安全测试：越权、注入、恶意文件、异常工具序列；
影子模式：接收真实请求但不影响用户和业务；
内部试用：专家可见，所有建议由人判断；
小流量发布：限定角色、区域、数据和动作；
受控扩量：依据价值、质量、风险和成本逐步扩大。

每级都有进入、退出和回滚阈值。高风险错误、越权或不可恢复动作不应被平均指标抵消。门禁还包括运行准备：监控、值班、降级、审计、数据契约和人工接管都必须就绪。

模型、提示、数据、分块、索引、规则、工具或权限任一重大变更，都可能触发相应回归。不要只在更换模型时评估。

15.6 线上监控：观察现实分布

离线集合无法覆盖所有真实问题。线上至少监测：

请求量、任务类型、角色和数据范围变化；
无结果、澄清、拒答、转人工和超时；
证据召回、引用打开、人工采纳与替换；
工具选择、失败、重试、循环、审批与回滚；
数据新鲜度、契约失败、索引延迟和依赖事件；
响应时间、令牌、工具、基础设施和人工审核成本；
越权、敏感信息、注入、高风险错误和用户投诉；
任务完成、流程时间和业务结果。

线上不一定即时知道“正确答案”，可以利用延迟标签：工单结案后的真实原因、实际换件、客户回访和主管审核。系统要把这些结果与当时会话、证据和版本关联。

监控应识别分布漂移。新设备系列上线、政策变化、用户群扩大或输入语言改变，都可能让历史评测失去代表性。漂移不是自动等同故障，但应触发抽样复核和评测集更新。

15.7 反馈不是简单的赞与踩

点赞和点踩成本低，却信息有限。用户可能因为答案不合心意点踩，也可能对流畅但错误的答案点赞。更有行动价值的反馈包括：

哪个事实错误或缺失；
哪条证据不适用、过期或无权访问；
哪一步建议被删除、调整或重新排序；
工具参数被如何修改；
用户为何拒绝建议；
最终故障原因和实际动作；
业务结果是否成功。

反馈入口要嵌入工作流程，尽量从用户自然修改中采集，避免要求额外写长报告。山城精工可比较 Agent 工单草稿与工程师提交版本，并在结案时记录真实原因和备件。高风险反馈提供快速上报与立即停用路径。

15.8 反馈数据本身是数据产品

反馈可能包含客户、员工、设备和模型输出，需要定义所有者、模式、权限、保留、质量和使用条款。至少记录任务标识、时间、角色、数据与模型版本、反馈类型、修订、最终结果和审核状态。

反馈不是天然真相。用户可能误改，专家之间可能分歧，业务结果可能受其他因素影响。进入规则、知识库、评测或训练前，需要去重、脱敏、验证、标注来源和审批。尤其禁止把模型生成答案未经确认直接作为下一轮知识，否则错误会形成自我强化循环。

可按用途分流：

紧急安全反馈进入事件响应；
数据错误分派给源端或数据产品所有者；
检索失败进入分块、元数据或排序待办；
生成问题进入提示、模型或输出校验；
流程问题进入产品体验与组织培训；
已确认高价值案例进入评测和知识候选。

15.9 从失败分类到改进行动

建立统一失败分类可以避免“都怪模型”。一种实用分类是：

类别	典型症状	主要改进方向
数据	缺失、错误、陈旧、冲突	源流程、契约、质量
语义	口径或实体理解错误	术语、关系、规则
检索	漏召回、错版本、排序差	分块、过滤、索引、重排
生成	证据外发挥、格式失败	提示、模型、校验、拒答
工具	选错、参数错、重复执行	契约、权限、幂等、编排
体验	入口割裂、太慢、难信任	流程、界面、说明
业务	规则不清、结果未改善	场景、流程、组织

每周评审最重要的不是看总分，而是查看高影响失败、重复模式、根因和负责人。修复后把失败样本加入回归集，验证没有破坏其他能力。

15.10 实验与因果

业务改善不能全部归功于 Agent。可以使用分阶段推广、同类团队对照、上线前后同口径比较，控制设备难度、人员经验和区域差异。早期样本小，可以结合定量指标与结构化访谈，但要区分事实和判断。

实验同时观察护栏。例如缩短诊断时长是否增加错误换件，提升自动化率是否增加审批绕过，减少人工是否导致客户满意下降。实验要预先声明主要指标、护栏、观察窗口和停止条件，避免结果出现后选择最有利的口径。

单位经济性也是评估的一部分：模型、检索、API、基础设施、人工审核和运营成本，按成功任务计算。成本优化后必须重新评估质量，防止通过缩减上下文或选用便宜模型损害结果。

15.11 山城精工持续评估闭环

首期可以每周运行固定回归集，每次索引、规则或工具变更运行相关测试；上线采用建议模式，小范围工程师试用；所有答案带引用，所有草稿需确认；工单结案后回填真实故障和备件。

运营看板分四块：数据健康、任务质量、流程价值、风险成本。每周审查严重错误与高频失败，每月比较诊断时长、一次解决率和采用，每季度决定扩设备、扩区域、增加工具权限或停止。任何严重安全建议、越权或重复业务动作立即冻结相应能力。

改进过程保留版本：某次质量提升究竟来自手册适用元数据完善、混合检索、模型升级还是流程调整，可以通过实验和链路记录解释。这样组织积累的是可迁移的方法，而不是对某个模型的模糊印象。

15.12 本章交付物：评估与反馈计划

上线评审应提交：

任务契约、风险等级和成功定义；
评测集来源、分层、标注、版本与防泄漏设计；
数据、检索、生成、工具、业务和风险指标；
自动评估与专家评估的分工和校准；
影子、试点、扩量、回滚的门禁；
线上监控、漂移和延迟业务标签；
反馈模式、隐私、审核和分派流程；
实验设计、护栏、单位成本和停止条件；
运营节奏、负责人和修复回归机制。

评估不是项目结束时的一次考试，而是系统感知现实的神经。数据变化、业务变化、模型变化和用户变化都会让昨天的正确成为今天的风险。只有把评估、反馈、修复和再验证连接成闭环，企业才不是把一个 Agent 放进生产，而是在建立一种能够持续学习、又不会让错误不受控制地扩散的运行能力。