当同事能够依据知识助手的回答完成一项实际工作时，它才体现出价值。这比先比较哪个模型的演示更出色，更接近采购的起点。真正需要评估的是完整流程是否改善：找到正确的信息、核实信息，再据此采取行动。
本文提供一套建议的评估方法。文中的场景仅用于说明，并非 CNPS 客户交付案例。
1. 选择一项值得改善的业务决策
假设一家分销商的服务团队，需要根据已批准的产品手册回答安装问题。“回答公司的所有问题”不适合作为首个试点范围。“帮助服务人员查到指定产品版本的正确安装要求”，则明确了任务、使用者和判断结果的方法。
先记录当前流程：谁收到问题？去哪里查找？对不确定的答案由谁核实？完整任务需要多长时间？保留一些普通问题，也保留一些困难问题。基线必须包含核实信息的时间，因为这一部分仍然属于未来工作流程。
2. 为资料集合建立责任机制
把文档集合视为需要持续维护的业务资产。为每份资料确认负责人、产品版本、生效日期及适用人群。存在矛盾的手册，应先由业务人员澄清，不能期待知识助手自动裁决。保留有意义的标题、单位、表格上下文以及原始资料链接。
明确谁有权批准更新，以及如何从系统中撤回失效信息。上个季度正确的答案，可能已不适用于当前产品。试点应包含一次小规模更新和删除演练，以便观察内容变更如何传递到用户端。
3. 测试那些不容易回答的问题
在调优前建立问题集，涵盖常规事实查询、跨文档问题、表述不清的问题、证据不足的问题以及访问受限资料。为最终决策单独保留一组不参与调优的题目；如果反复针对所有测试题调优，测试结果的参考价值会下降。
| 测试项目 | 审核者需要检查的内容 |
|---|---|
| 事实回答 | 回答符合权威资料及正确版本 |
| 引用 | 引用段落确实支持回答中的具体陈述 |
| 证据不足 | 助手说明信息缺口，并提出有用的下一步 |
| 权限 | 用户无法获取其权限范围之外的资料 |
| 歧义 | 助手要求补充产品或使用背景 |
| 更新 | 变更或撤回的文档按约定方式处理 |
记录失败时，要保留问题、系统配置和资料版本。不要因为困难题会拉低分数，就把它们从测试中移除。
4. 衡量完整工作，而非只有回答速度
将形成可使用、已核实答案所需的时间，与原流程进行比较。同时记录修改成本、未解决的问题、预期使用量下的响应时间以及运行费用。流畅的初稿，只是服务工作中的一个环节。
测试前，与业务负责人共同确定门槛。把权限边界等必须满足的要求，与可以在成本和速度之间取舍的改进项分开。既看汇总数据，也看具体样例：少量严重错误，可能比一个看似方便的平均数更重要。
5. 明确系统背后的负责人
分别指定资料维护、用户权限、技术运维和业务验收的负责人。梳理所有接触文档或提示词的服务。应用部署在自己的服务器上，并不能单独说明所有相连模型及处理服务运行在哪里；应要求提供完整的数据流向。
当模型、文档解析器或检索配置变化时，安排复核。为未解决的问题保留转交同事的渠道。知识助手应纳入已有责任体系，明确上线后发现问题时由谁负责处理。
6. 把试点结果转化为采购决策
最终记录应列明任务、文档、配置、测量结果、已知失败和运行负责人。接下来可以选择推进、改善某项明确弱点、缩小范围或停止。每一种决定，都应能够从证据中找到依据。
使用知识助手试点清单和英文方法页Pick documents and one workflow for a UAE FastGPT first pilot收集必要输入。准备好后，可以与 CNPS 讨论知识助手评估。请提供任务、语言、用户数量、目的地、时间安排以及不含敏感内容的数据约束，让下一次沟通围绕可执行的范围展开。
