AI知识库上线后答非所问，多数情况下问题不在大模型本身，而在检索没找对文档、分块切断了关键信息、精排把无关内容送进了上下文。用20到50条真实业务问题搭一套分层评测集，把检索、精排、生成三层分别量化成召回率、NDCG和答案合格率，是业务负责人验收知识库最直接的方式。
为什么“感觉答得不对”不能作为验收标准
业务负责人验收AI知识库时，最常见的反馈是“答得不准”“有时候胡说”“跟我想找的不一样”。这些感受是真实的，但无法指导改进。不知道问题出在哪一层，团队只能反复调提示词、换模型，或者重新上传文档，最终变成一轮又一轮没有终点的试错。
一套RAG知识库的回答质量由三层叠加决定：
- 检索层：该找到的文档有没有被找回来。
- 精排层：找回来的多条文档里，真正相关的是不是排在最前面。
- 生成层：基于给到的文档内容，答案是否正确、有没有引用、有没有编造。
三层中任何一层出问题，最终表现都是“答非所问”，但修复动作完全不同。检索问题要调分块和向量化策略，精排问题要调排序逻辑，生成问题才轮到提示词和模型参数。不做分层评测，验收就只能是玄学。
适合什么企业，什么时候开始做
这套方法适合已经或准备上线AI知识库、且知识库内容以内部制度、产品手册、技术文档、销售话术、售后规范等结构化文本为主的企业。典型规模是文档量从几百份到几万份，有明确的业务团队日常使用。
最合适的启动时机不是上线后出了问题再做，而是在知识库进入试运行阶段时，同步建立评测集。如果已经上线且反馈不佳，现在做也来得及，评测集本身就是定位问题的工具。
用真实业务问题搭建评测集的四个步骤
第一步：问题从哪里来
评测集的质量取决于问题是否真实。按优先级从高到低，问题来源应该这样排序：
第一优先：一线员工实际问过的问题。 客服对话记录、销售在群里问过的问题、技术支持的工单标题、新员工培训时反复确认的内容。这些是最真实的检索场景，没有经过任何修饰。
第二优先：业务负责人认为“必须答对”的问题。 比如产品退换货规则、设备安全参数、报价审批权限、合规红线条款。这类问题数量不多，但答错的代价高，必须全部纳入。
第三优先：容易混淆的边界问题。 比如“A产品和B产品在某个参数上的区别”“旧版政策与新版政策的冲突处理”“不同客户等级对应的服务标准”。这些问题专门用来测试检索和精排的区分能力。
不建议用“帮我总结一下公司简介”“介绍一下产品功能”这类宽泛问题。它们太容易答对，放进评测集会拉高整体分数，掩盖真实问题。
第二步：20到50条问题的规模控制
评测集不需要大。对于大多数企业知识库，20条问题足以暴露系统性问题，50条足够支撑一轮完整验收。关键是每个问题都要有明确的业务场景和可判断的正确答案来源。
数量再往上走，维护成本会快速增加，业务负责人很难持续投入。评测集的价值在于持续复用，而不是一次性做得很重。
第三步：答案标注怎么做
每条问题需要准备两类标注信息。
第一类是该问题对应的正确文档集合。不需要把整篇文档复制进来，只需要记录文档编号或标题，以及关键段落的位置。这用于计算检索层的召回率和命中率。
第二类是正确答案的核心要点。用一两句话写清楚，这个问题的合格答案必须包含哪几个关键信息。比如问“设备A过载保护阈值是多少”，答案要点就是“阈值数值+适用型号+生效条件”。生成层评估时，对照这些要点判断是否答对，而不是看语言是否通顺。
标注工作由最熟悉业务的骨干完成，通常一个人半天可以完成20到50条。这笔时间投入是一次性的，后续每次知识库调整都可以复用。
第四步：三层指标怎么用
评测跑完后，每一层的核心指标对应不同的验收判断：
检索层看召回率和命中率。 召回率反映所有应该被找到的文档实际找回的比例，命中率反映前K条结果里至少有一条正确文档的问题占比。检索层不达标，后续精排和生成再优化也救不回来。
精排层看NDCG。 这个指标衡量的是相关文档有没有排在最前面。真实场景里，用户通常只看前3到5条检索结果，排在第五位和排在第一位的区别直接决定生成质量。企业知识库尤其看重精排，因为内部文档往往高度相似，排序错了就会把旧版本政策或相邻产品文档喂给模型。
生成层看答案合格率和幻觉率。 对照标注的答案要点，逐条判断是否答对；同时检查回答中的事实是否都能在检索到的文档中找到出处。生成层评估建议由业务骨干人工抽样复核，不依赖模型自评。
三个指标分开追踪，问题出在哪一层就一目了然。检索和精排层不达标，优先调整分块策略和排序逻辑；生成层不达标，才轮到提示词、引用策略和模型选择。智未来AI在为企业搭建知识库评测体系时，通常会把这个分层诊断作为验收交付的一部分，让业务负责人拿到的不只是一个“能用”的系统，而是一套可以追踪质量变化的验收框架。
常见误区：三个容易踩的坑
误区一：只测最终答案，不测检索。 很多团队用“问十个问题、看几个答对”来验收，结果模型换了两轮，召回率还是只有一半。最终答案的质量上限由检索决定，跳过检索层的评测等于盲人摸象。
误区二：评测问题太简单或太通用。 如果评测集里全是“公司有多少员工”“产品有哪些系列”这类问题，系统拿满分也不代表能用。评测集必须包含需要跨段落整合、需要区分版本、容易混淆的边界问题。
误区三：一次评完就丢。 知识库会持续更新，新的文档加进去可能破坏原有的分块结构，或者让精排逻辑在新的内容分布下失效。评测集应该成为每次系统调整后的固定回归流程，而不是一次性验收工具。
关于知识库系统的整体建设与RAG架构选择，可以参考企业知识库与RAG系统服务页面。如果后续关注的是外部AI搜索中的品牌可见性，则需要另外一套GEO与AI搜索优化方法，评测逻辑不同，不宜混为一套标准。
交付成果：验收时应该拿到什么
一套完整的知识库评测集交付，至少包含以下内容：
- 评测问题清单：20到50条真实业务问题，标注来源场景。
- 答案标注文件：每条问题对应的正确文档集合与答案要点。
- 评测执行说明：三层指标的计算方式和判断标准。
- 基线评测报告：当前系统在检索层、精排层、生成层的各项指标。
- 问题定位结论：明确当前质量瓶颈在哪一层，对应的优化方向是什么。
有了这些，业务负责人和供应商之间就不再围绕“感觉不准”拉扯，而是围绕具体指标确认改进目标。后续每次知识库版本调整，都可以用同一套评测集复测，形成可追踪的质量曲线。
智未来（上海）智能科技有限公司作为企业AI落地服务团队，在实际项目中把评测集建设放在知识库上线前的验收环节，而不是等客户发现答错再回头补救。
风险边界：这套方法不能解决什么
评测集能告诉你系统在已知问题上的表现，但无法保证所有未预期问题的质量。真实用户的问题分布会变化，新的文档类型可能引入新的失败模式。因此评测集需要每季度或每次重大内容更新后做一次维护，补充新出现的真实问法。
另外，涉及客户个人数据、外呼电话、未成年人信息等场景，评测集中的问题应做脱敏处理，相关权限和人工确认流程需要在交付方案中单独设计，不能把合规责任推给模型判断。
常见问题
1. 我们企业还没有知识库，做评测集是必须先建好系统吗？
不需要。评测集可以先行建立，问题来源于现有业务记录，不与任何系统绑定。等知识库上线试运行时，评测集直接作为验收工具使用。提前准备反而能让供应商在项目实施早期就明确质量底线。
2. 20条问题会不会太少，测不出真实水平？
对于单个知识域，20条经过挑选的真实问题足以暴露出分块不当、版本混乱、精排不稳等系统性问题。如果评测集覆盖多个知识域，建议每个域至少15到20条。核心在于问题质量和标注准确性，而非数量堆叠。
3. 我们老板只关心AI能不能用，不关心什么召回率，这套东西怎么向上汇报？
把三层指标转化成一个业务表达：这20条问题里，系统能准确找到正确文档的比例是多少，答对的比例是多少，哪几类问题目前不可靠。给老板看的是哪个业务场景能上线、哪个还不能用，指标是支撑这个结论的依据。
4. 测出来检索指标很低，但供应商说换个模型就好了，能信吗？
不能。检索指标低说明文档没找对，跟生成模型能力是两回事。换模型只能改善“找对了但说得不好”的情况，不能解决“找都没找对”的问题。如果供应商不提供分层指标，只用最终答案准确率跟你沟通，需要要求对方拆开验收。
5. 这套方法我们自己能做，还是需要找外部团队？
如果企业有信息化负责人且懂基本的数据标注逻辑，可以自行搭建。困难通常不在技术，而在两点：问题收集时如何覆盖真实业务场景、标注时能否准确定义“正确文档”。如果内部没有精力推动，可以找外部团队搭框架、做基线评测，之后由业务方维护标注，联系智未来AI企业项目可以就这个交付模式做具体沟通。