企业 AI 项目验收怎么做？从 RAG 知识库到 AI Agent 建立可量化标准

很多企业做完 AI 知识库或 Agent 项目后，验收仍停留在“现场问几个问题，回答看起来不错”。这无法证明系统能否稳定检索、正确执行工具调用，也无法覆盖越权、提示注入和数据泄露风险。更稳妥的做法，是把 AI 验收拆成可重复测试的质量、安全和运维基线：先定义目标，再用测试集验证结果，最后检查人工兜底和监控。

1. 先把“能用”改写成验收基线

AI 项目的需求不能只写“支持智能问答”或“实现流程自动化”，而应改成可以观察和复核的验收条目。建议在立项或需求评审阶段形成一张基线表：

NIST 的 AI Risk Management Framework 将 Govern、Map、Measure、Manage 作为风险管理主线。对企业项目来说，这意味着验收不能只看模型输出，还要验收责任边界、风险识别、测量方法和问题处置流程。

2. 用测试集替代“现场演示”

测试集是 AI 项目验收的核心资产。它不应由开发人员临时挑选容易回答的问题，而应由业务人员、产品人员和技术人员共同整理，覆盖以下五类：

• 高频问题：来自客服记录、内部咨询、工单和搜索日志，验证日常使用价值。
• 复杂问题：包含多条件、跨文档或需要追问的问题，验证检索和上下文组织能力。
• 无答案问题：知识库没有依据的问题，检查系统是否明确说明未知，而不是编造内容。
• 边界问题：过期制度、冲突版本、模糊表述和大段文件，验证异常处理能力。
• 安全问题：越权查询、提示注入、敏感信息索取和恶意工具参数，验证防护能力。

每条测试用例至少记录问题、用户角色、期望结论、允许引用的资料、风险等级和人工判定结果。测试集不必一开始就很大，但必须有版本号；每次调整切分策略、Prompt、模型或工具，都要重新执行回归测试。

测试集可以分成离线集和在线集：前者用于发布前对比版本，后者来自脱敏后的真实问题，用于发现演示环境没有覆盖的表达方式。两者结合，才能避免“测试通过、上线失效”。

3. RAG 知识库要分开验收“检索”和“回答”

RAG 系统的问题经常被笼统归因于“大模型不够聪明”，但实际可能是文档解析错误、切分不合理、权限过滤失效或检索结果排序不佳。因此验收要分两层。

检索层：找没找到正确依据

对每个问题检查：相关文档是否进入候选结果、关键段落是否排在前面、文档版本是否正确、无权限资料是否被过滤。若企业有人工标注的相关文档，可以计算命中情况；没有标注时，也应由业务专家抽查检索片段的相关性和完整性。

Microsoft Foundry 的 RAG evaluators 将 Retrieval、Document Retrieval 作为过程评估，将 Groundedness、Relevance 和 Response Completeness 作为系统评估。这个区分很有参考价值：检索质量和生成质量是两个问题，不能用一个总分掩盖其中的短板。

生成层：回答是否有依据、完整且可读

建议至少检查四项：

• Groundedness：回答中的事实是否都能在引用上下文中找到依据。
• Relevance：回答是否直接回应问题，避免只复述无关资料。
• Completeness：是否遗漏了业务人员必须知道的关键条件。
• 拒答质量：没有可靠依据时，是否明确说明无法确认并引导用户找对的人。

对于制度、合同、财务和安全操作等高风险内容，不能只接受模型评分，还要由业务专家进行抽样复核。验收报告中应保存问题、检索片段、最终回答、引用来源、模型版本和判定结果，便于出现争议时还原现场。

4. Agent 项目要验收“动作链”，不只是对话

Agent 的价值在于调用业务系统完成任务，因此验收必须覆盖完整动作链。例如，销售助手查询客户信息时，要验证身份识别、数据范围过滤、CRM 查询参数、结果脱敏和日志记录；采购 Agent 生成补货建议时，要验证库存数据时间、计算规则、审批节点和异常回退。

可以按风险把工具分为三类：

• 只读工具：查询订单、库存、客户或制度，通常可自动执行，但要有数据权限。
• 可回滚工具：创建草稿、生成工单、更新待审核状态，需要显示执行计划并保留撤销方式。
• 高影响工具：付款、删除、权限变更、正式发送和发布，必须经过人工确认或审批。

MCP 工具规范明确提出，工具调用应进行输入校验、访问控制、限流和输出清理；对敏感操作，客户端应让用户确认并记录工具使用情况。无论采用 MCP、Function Calling 还是自定义 API，企业都应把工具当作高风险接口，而不是把模型的一句话直接转成生产操作。

5. 把安全验收纳入交付，而不是上线后补救

AI 系统的安全验收至少包括四组测试：

1. 提示注入：在用户问题、上传文件和知识库文档中加入诱导指令，检查 Agent 是否会忽略系统规则或泄露上下文。
2. 权限越界：用不同角色访问同一问题，验证组织、部门、项目和文档级权限是否真正生效。
3. 敏感信息保护：测试身份证号、手机号、合同金额、密钥等数据是否出现在不应出现的回答、日志或外部模型请求中。
4. 工具滥用：构造错误参数、重复调用、超时和接口返回异常，检查系统是否限流、熔断、回滚并通知人工。

OWASP GenAI Red Teaming Guide 建议从模型评估、实现测试、基础设施评估和运行时行为分析四个方面开展红队测试。对企业项目而言，至少应在上线前完成一轮攻击模拟，并将高风险问题闭环到责任人、修复版本和复测结果。

6. 验收交付物应当包含什么

一份可执行的 AI 项目验收包，建议包含：

• 需求基线、场景边界和角色权限矩阵
• 脱敏后的测试集、测试脚本和版本记录
• RAG 检索与回答评测报告
• Agent 工具清单、接口契约和失败回退说明
• 安全测试、红队测试和问题整改记录
• 模型、Prompt、知识库和配置的版本信息
• 监控告警、人工转接、知识更新和应急处理手册
• 培训材料、管理员账号交接和后续服务范围

企业可以参考 AI 智能系统解决方案 规划知识库、Agent 和业务系统集成，也可以结合 软件外包项目验收指南 与 AI Agent 安全与权限控制 补齐合同和安全条款。这样做的目的不是增加文档负担，而是让业务人员知道系统为什么这样回答，让管理者知道出了问题由谁处理。

数舵科技如何支持 AI 项目交付

数舵科技的公开服务范围包括企业 AI 应用开发、AI Agent、RAG 知识库、知识图谱、大模型私有化部署及与 CRM、ERP、OA 等业务系统集成。对于需要定制开发的企业，项目重点不应只放在模型接入，还要把需求边界、知识整理、权限设计、工具接口、测试评估和部署运维纳入同一条交付链路。涉及政企、招采或内部敏感数据的项目，还应根据客户的部署、审计和文档要求确定验收深度。

写在最后

AI 项目验收的本质，是把“模型看起来会回答”转化为“系统在规定边界内稳定工作”。RAG 要验证依据是否找对、回答是否忠实；Agent 要验证动作是否有权、过程是否可控；所有高风险场景都要保留人工责任链。企业若能在项目早期建立测试集、权限矩阵和发布基线，验收就不再是最后一天的演示，而会成为持续提升系统可信度的工程机制。