PoC 的目标不是证明 AI 会回答问题
AI 知识库做出演示并不难，真正困难的是判断它能否稳定用于日常业务。企业启动 PoC（概念验证）时，应先回答一个更具体的问题：在约定的资料、用户和业务场景内，这套系统能否给出可核验的答案，并在不知道时保持克制？如果验收只看几次现场提问，结果很容易受到演示问题、临时调参和人工挑选资料的影响。
1. 先把 PoC 范围写成可验证的边界
第一阶段应明确服务对象、知识范围、问题类型、使用入口和不包含事项。例如“供售后团队查询已发布产品手册与标准排障流程”，就比“建设企业智能知识库”更容易验收。合同或需求说明中还应写清资料截止版本、账号数量、是否接入现有系统，以及哪些问题必须转人工，避免验收时不断扩大范围。
2. 评测问题要来自真实业务，而不是现场临时提问
建议由业务负责人、资料维护人和项目团队共同建立评测集。问题应覆盖高频标准问法、同义改写、多条件组合、资料中没有答案、存在旧版本冲突以及涉及权限的信息。每道题都要标注依据文档、可接受答案和风险等级。问题数量没有通用标准，关键是覆盖主要业务类型和高风险边界，而不是单纯追求样本越多越好。
3. 至少分别评估答案、引用和拒答
“回答正确率”不能只靠感觉打分。企业可以把结果拆成三个维度：答案是否符合业务事实，引用是否指向正确且有效的资料，当资料不足时系统是否明确说明无法确认。PoC 开始前应约定每项指标的分母、计分方法、通过阈值和失败判定，例如部分正确如何计分、错误拒答如何统计、引用有效是否要求文档版本和原文片段同时匹配。高风险问题可以单独分组并提高权重。具体阈值应由业务负责人根据风险确认，而不是套用一个行业通用数字。
4. 把权限隔离当成独立测试项
测试不能只验证“有权限的人能搜到”，还要验证“无权限的人确实搜不到”。应分别使用不同角色账号，检查搜索结果、引用片段、历史对话、导出内容和接口返回。若资料包含客户项目、报价或内部制度，还要确认日志是否能追踪访问行为。越权读取、跨知识空间泄露或敏感内容进入无权限回答，应被列为阻断上线的问题；不能通过隐藏按钮或提示文案代替真正的数据隔离。
5. 记录响应时间，也要记录一次回答的完整成本
PoC 应在接近真实使用的环境中记录响应时间、失败率和并发下的稳定性。测试前要固定模型、资料版本、并发量、超时定义和统计周期，并至少报告中位数与 P95 响应时间，避免只展示少量最快结果。成本要区分一次性投入与持续支出，并按预计调用量说明模型、OCR、向量化、重排、存储、监控、备份和运维费用；私有化方案还要核算固定算力、网络资源与软件许可。比较方案时应统一含税口径、使用量假设和固定成本摊销周期。
6. 验收交付物不能只有一个可访问的网址
一份完整的 PoC 交付，至少应包含约定范围内的可用系统、资料清单与版本、评测集、逐项评测结果、已知限制、权限说明、成本口径和后续优化建议。企业还应拿到资料更新与问题反馈流程，明确由谁审核新内容、如何下线旧版本、系统调整后如何做回归评测。这些材料是判断项目能否从演示转向持续运营的重要依据。
7. 用上线门槛做最终决策
PoC 结束后，不应只做“满意或不满意”的主观判断。业务负责人和项目负责人应依据预先确认的评测表签字确认。越权访问、敏感信息泄露、关键高风险问题给出错误答案且未触发人工复核，应作为上线阻断项；一般问题未达阈值则应修正后复测。结论可以分为进入有限范围试运行、整改后复测、暂缓上线三类。资料不足、权限边界不清或答案质量未达标时，不应为了赶进度进入试运行。
比较 AI 知识库方案时，建议确认这 8 件事
- PoC 具体覆盖哪些用户、资料和问题类型；
- 评测集由谁建立，标准答案和依据由谁确认；
- 答案、引用、拒答和权限分别如何验收；
- 哪些高风险问题必须进入人工复核；
- 报价包含哪些资料处理、接口适配和评测工作；
- 模型、OCR、检索、存储和运维成本如何计算；
- 交付后由谁维护资料并处理错误反馈；
- 未达到上线门槛时，整改和复测如何安排。
PoC 的价值，是帮企业更早发现不确定性
好的概念验证不会承诺 AI 在所有问题上都正确，而是把适用范围、质量水平、成本边界和剩余风险展示清楚。对中小企业来说，先用真实问题和明确指标验证一个核心场景，再决定是否扩大资料、用户和系统集成范围，通常更有利于控制投入，也更容易让知识库真正进入业务流程。