企业知识库上线前，真正该做的是用一套覆盖检索、精排、生成三层的评测集，把“能不能用”变成“每一层差在哪里、差多少”。没有量化分数的知识库验收，本质上是在凭印象放行。
为什么要单独搭一套 RAG 评测集
企业知识库不是搭完就能用的。很多项目在演示时看着像样，一上线就被真实问题问住：有的搜不到相关文档，有的搜到了却答非所问，有的回答流畅但事实是编的。
这三个问题分别对应 RAG 系统的三层：
- 检索层：能不能从知识库里找到对的那几篇文档
- 精排层：找到的文档里，最相关的能不能排在前面
- 生成层：基于这些文档，最终回答有没有忠实还原内容
只测最终答案，看不出问题出在哪一层。三层分开测，才知道该修检索策略、调精排权重，还是改提示词和生成参数。
适合什么企业
这套评测方法适合已经启动或准备启动知识库项目的企业，尤其是：
- 知识库即将上线，但验收标准只有“感觉回答还行”
- 内容类型复杂，既有产品手册、制度文件，也有销售话术和售后知识
- 回答错误会造成实际业务损失，比如合规、报价、操作规范类场景
- 后续要持续迭代知识库，需要一套可复用的质量基线
如果知识库只供内部少数人偶尔查一查，投入完整评测集的收益有限。但只要是面向客户、面向一线员工、会直接影响决策或服务的场景，评测集就应该在上线前建好。
先做什么：从真实业务问题开始
评测集的核心不是技术指标，是真实业务问题。
不要凭空编题。去找客服、销售、实施、售后这些真正会使用知识库的人，把他们在实际工作中已经问过、被问过的问题收上来。来源通常是：
- 客服工单里的高频问题
- 销售反复回答的客户疑问
- 新员工培训时最容易卡住的操作点
- 制度文件里容易产生理解分歧的条款
- 管理层最希望知识库能直接回答的决策类问题
每个问题都要配上一组标准依据：回答这个问题，应该引用知识库里的哪几份文档、哪些段落。这一步决定了后面打分是否有据可依。
收集完问题后，按业务价值和出现频率排序，选出有代表性的问题作为评测集。评测集不需要特别大，关键在于每道题都能代表一类真实问法。
三层评测各测什么、怎么打分
检索层：找没找对
检索层评测的是：给定一个问题，系统返回的文档列表里，是否包含标准答案所依赖的那些文档。
常用指标是召回率和命中率。通俗说：
- 命中率：标准文档有没有出现在返回结果里
- 召回率：多个标准文档里，找到的比例是多少
如果这一层分数低，问题通常出在分块方式、向量化策略、关键词与语义检索的配比上。修的是检索链路，不是提示词。
精排层：排没排对
检索层找到了文档还不够。如果最相关的文档排在第五名之后，而生成层只取前三名，回答照样会漏掉关键信息。
这一层可以看标准文档在返回结果中的平均位置，或者更简单地统计：标准文档进入前 K 名的比例是多少。
精排层分数低，说明需要调整排序权重、引入业务字段过滤，或者针对特定文档类型设置优先级。这一步的价值在于，它能把“找到但没用到”和“根本没找到”区分开。
生成层：答没答对、有没有编
生成层看的是最终回答质量，但评测方式不是“读起来顺不顺”，而是逐条对照标准依据。
建议从三个角度打分：
- 忠实度：回答内容是否都能在标准文档里找到依据
- 完整性：标准依据里的关键信息点，回答覆盖了多少
- 业务可用性：用户拿到这个回答，能不能直接解决问题
这三个维度里，忠实度最容易出问题。很多 RAG 系统生成的内容流畅自然，但会混入模型自己的推断。企业知识库场景下，这不是小事。客户问“这个功能是否支持”，回答里多一个“应该支持”，就可能带来售后纠纷。
生成层打分建议由熟悉业务的人来做，配合一套简单的打分说明，保证不同评测人员标准一致。
常见误区
只看最终答案，不看中间过程。 三层拆开测，就是为了定位问题。只测生成层，等于只看结果不看病灶。
评测集全是通用问题。 “介绍一下公司”“我们有哪些产品”这类问题太宽，检索层很容易混过去，测不出真实能力。评测集里必须有边界清晰的具体问题，比如“某产品在合同到期前多少天可以续费”“某流程需要哪些人的审批”。
评测集搭完就不再更新。 知识库会变，业务问题会变。评测集至少要按季度回看一次，把新出现的高频问题补进去，把已经失效的标准依据替换掉。
用技术指标代替业务判断。 检索命中率再高，最终回答让客户看不懂也没用。生成层的业务可用性必须由业务人员参与打分。
交付成果：一套可复用的质量基线
搭建完这套评测集，企业实际拿到的是三样东西：
一份评测问题集，每道题带有标准依据和业务背景；一套分层评分表，明确检索、精排、生成各层的打分方法和阈值；一个可重复执行的评测流程，后续每次调整知识库或更换模型，都能用同一套基线跑一遍，看分数有没有下降。
有了这套基线，知识库上线从“感觉可以”变成“分数达到 XX 分，可以上线”。上线后每次迭代，也能用数据判断是改进了还是退化了。
对于企业内部缺少这方面经验的团队，智未来 AI 的企业知识库与 RAG 系统服务可以协助完成从问题收集、分层评测到上线验收的完整过程。智未来（上海）智能科技有限公司作为企业 AI 落地服务团队，更关注的是把评测逻辑和业务验收标准真正跑通，而不是交付一套没人用的技术框架。
风险边界：评测集不是万能保险
评测集能降低上线风险，但覆盖不了所有情况。
评测集里的问题再多，也无法穷尽真实场景。它更适合作为上线前的质量门槛，而不是对系统能力的最终判断。上线后还需要持续收集真实问题，把没答好的问题回流到评测集中。
另外，评测集的质量取决于标准依据的质量。如果知识库本身内容陈旧、矛盾、缺失，评测得再严格，系统也只能在错误内容里打转。评测集能发现“系统没用好内容”，但替代不了知识内容的治理。
对于涉及个人微信、电话外呼、客户数据、未成年人信息的知识库内容，评测集必须加入权限核查项，确认这些信息不会被错误检索和生成，并保留人工确认环节。合规问题不能用“答对率”来验收。
---
常见问题
企业知识库上线前，RAG 评测集要建多少道题才够？
没有统一的数字，但建议按业务场景覆盖来定，而不是凑数量。每个核心模块至少有 3-5 道边界清晰的具体问题，覆盖常规问法、模糊问法和容易引起歧义的问法。对于直接影响合规和报价的场景，题目可以再加密。评测集的关键是每道题都能定位问题，不是越多越好。
我们已经有知识库了，但现在回答质量不稳定，还能补建评测集吗？
可以。已经上线的系统，反而更需要一套评测集来定位问题到底出在检索、精排还是生成。建议先收集最近一段时间真实问答中答得不好的案例，把这些问题和标准依据整理成评测集，再逐层跑分，看问题集中在哪一层。这样优化时不用全链路盲调。
RAG 评测集建好了，但内部没有人能持续维护怎么办？
至少要做到两点：一是指定一个业务负责人，定期回看评测集里的问题是否还代表当前业务；二是把评测流程简化到一键执行，内部只需要按表打分。如果内部实在没有人力，可以考虑让外部服务团队协助搭建首版评测集并培训使用，企业只保留日常维护动作。
评测集分数达到多少，知识库可以上线？
分数标准要按业务影响来定。合规、报价、操作安全类场景，生成层的忠实度应该要求更高，因为答错代价大；内部知识查询类场景，阈值可以适当放宽。建议由业务负责人和技术负责人共同确认每一层的及格线，而不是直接照搬行业通行标准。
老板想用 AI 知识库降本增效，但担心上线后答错被客户投诉，怎么用评测集说服他？
可以把评测集作为风险控制工具来呈现：上线前先用一套包含真实客户问题的评测集验证系统，把检索、精排、生成的分数拿出来，明确哪些问题系统已经能稳定答对，哪些还需要人工兜底。这样知识库上线就不再是一个“赌一把”的决定，而是一个有边界、有兜底、有数据支撑的业务动作。