2.4 知识库质量评估：先给 AI 做一套摸底题

知识库建好了，平台上的索引也跑完了，团队里每个人都很兴奋，恨不得当天就挂上官网。我拦住了大家——这就像学生考前没做过一套题就上考场，考砸了都不知道是哪章没学会。上线之前，我给这个 AI 助手出了一套二十题的摸底卷，先把它不会的、会瞎编的全暴露出来。二十道题不多，但足够把最扎眼的问题全照出来。后来证明这是整个项目最值的两个小时，所有改动从此都有了对照基准。

这套评估方法最妙的地方在于它把感性的这 AI 靠谱吗变成了一组数字。团队里争论 AI 能不能用，再也不用靠喊，跑一遍测试集贴出分数就行。做技术的人信任指标，远胜过信任演示效果，分数本身就是最好的沟通语言。 多说一句为什么要坚持测：我们第一次给 CEO 演示的时候，问了个演示前刚测过的问题，结果答得磕磕绊绊——没人改过任何参数，只是提问的措辞换了一下。这件事让我意识到，凭感觉演示和凭指标上线完全是两回事。指标固定的好处就是它不讲情面，行就是行，不行就是不行，换了措辞照样测得出。关于怎么用工具快速搭评估流水线，可以看我写的Claude Code 指南。

摸底题怎么出

出题有个原则：不能只问标准答案工整的问题，那会让分数虚高。二十道题里，我刻意混了简单题、细节题、需要跨文档综合的题，还故意塞了几道知识库里根本没有答案的题——后者是专门测它会不会胡编。题目都从真实客服记录里挑，不用自己现编。

表中只列了八道作示例，实际二十题是照同样结构铺开的。来源文档这一列很关键，它让每道题都可追溯——答错了能立刻定位到是哪个文档、哪个切片出了问题，而不是对着一个低分干瞪眼。建议你也把超纲题的数量控制在两到三成，少了测不出幻觉，多了打击信心。

出题还有一条经验：尽量模仿用户的真实问法，包括错别字、简称和指代不清的表达。第一次我把题目写得太规整，测出来的分数很好看；第二次换成工单里的原话，比如价格咋算、那个退款能退不，分数立刻掉了一截。客户不会按文档的语言来提问，摸底卷也不能太客气。这些真实问法后来都沉淀进了提示词的示例和兜底规则里。

多补一条实战心得：题目出完先自己对着知识库手工答一遍。这一步能预先校准每道题的难度——有些自以为难的小细节题其实在文档里一目了然，有些自以为简单的综合题反而需要跨好几个文档拼接。手工答一遍之后再让 AI 考，判卷时心里有谱，不会被高分或低分意外带偏节奏。写题的过程还是一次知识库体检：写到发票题时我发现 FAQ 说三个工作日、帮助页写五个工作日，两处不一致趁出题就一起理顺了。

四个评估指标

判卷不能只看感觉，我定了五个可量化的指标，每项都有明确目标值。这些指标后面上线运营也会接着用，是同一套度量体系。

前四个指标互相牵制：只追召回率，模型会把什么问题都往已知答案上靠；只追准确率，它会动不动就说我不知道。真正的目标是召回和诚实都要，宁可少答也不能瞎编。判卷时还有个人工环节绕不开：幻觉率必须人工抽检，因为机器自己看不出自己编没编。我每次抽十道题人工对照来源文档，二十分钟搞定，但它是整套评估里唯一能真正防住胡说的环节。

这里特别强调一下无答案率。很多团队测 AI 助手只测它答得对不对，从来不出超纲题，结果上线后遇到不会的问题就编，直接变成大规模事故现场。敢于拒答、会触发兜底，比答对更多题更难也更重要。超纲题就是给模型装的刹车，刹车灵不灵，只有上路前测了才知道。

首轮结果与调优

首轮摸底成绩很难看：召回率只有百分之六十几，准确率八十几，最惨的是幻觉率偏高。我对着题表逐题排查，发现一个集中问题——价格和套餐类问题大面积召回失败。原因是 FAQ 相关条目被切得太碎，计费说明分裂在好几个块里，检索只捞到一半信息。处理办法是把这些条目的切片合并重建，把同主题的小块整合成语义完整的中等块；同时把检索的 top-k 从 3 调到 5，给模型更多候选段落。第二轮测试后，召回率升到百分之八十八，幻觉率降到百分之四以下，两轮调整一共花了一个多小时。

还有一类题答得不好值得单独说：第 7 题数据导出，答案在手册第 12 章，但模型总少报一句限管理员角色。排查发现是切片时这一句正好落在块边界上，被切进了相邻块，而相邻块讲的是别的主题，检索权重不够。解决办法是把权限说明这类关键约束单独并入主块，而不依赖相邻检索。这类细节不靠摸底题根本发现不了。

另外一个意外收获：第 20 道对比类问题，模型第一轮居然很认真地编了一通优缺点。这说明兜底提示词里没覆盖到比较类问题，于是我补了一条规则——涉及与其他产品比较的问题，一律先声明无相关资料再转人工。看到 AI 老老实实承认不懂的那一刻，我心里比它答对十道题还踏实。

调优这件事别指望一轮收工。从第一轮到指标全部达标，我们一共跑了四轮，每轮改的都是不同地方：第一轮补切片，第二轮调 top-k，第三轮改兜底提示词，第四轮把误导性强的几条工单记录整体剔除。每轮只动一个变量这点很重要——同时改三处，分数涨了也不知道功劳算谁的，分数掉了也不知道该回滚哪里。把每一轮的改动和分数记在表格里，这份记录在后面第 5.2 篇讲每周迭代时还会接着用。

还有一类坑是指标本身带来的。第四轮我把幻觉率压到百分之二，召回率反而掉了两个点——模型学乖了，遇到稍有把握不足的问题就触发兜底，宁可少答。这就是评估表里四个指标互相牵制的现实体现：单追一个指标永远能把它做好看，代价藏在别的指标里。最终上线版本我微调了兜底提示词的触发阈值，在召回和诚实之间取了个平衡点。

整套摸底测试做完，最大的收获其实不是那几个分数，而是团队共识变了。以前客服觉得 AI 是个会抢饭碗的黑箱，现在大家会说这道题它肯定答得出来、那道题它还没学会。指标让 AI 的能力边界清晰可见，边界清楚了，信任自然就有了。上线前最后一天，客服主管主动问我：以后我遇到拿不准的问题，能不能先问它再对我答案？那一刻我知道，这个工具真的能用起来了。

把测试集固化下来

摸底题不能测一次就扔。我把这二十题连同标注的标准答案、来源文档整理成了一份回归测试集，存进代码仓库，之后每次知识库有改动——加新文档、调切片参数、改提示词——都重跑一遍这二十题，分数掉了立刻回滚排查。这就像给知识库装了个保险丝，改动再小也不敢跳过验证。

回归测试集还要随业务一起长。我们定了两条规矩：第一，每周把客服新收集的高频问题里挑两三道加入测试集，题型覆盖保持平衡；第二，线上真实翻车的案例，也就是用户投诉答错的问题，必须转化成测试题补进去。半年下来测试集从二十题扩到五十多题，每一道背后都对应一次真实损失。测试集越贴近真实用户，它的保护力就越强。

测试题也要定期复查淘汰。有些题长期满分通过，说明对应知识已经稳定，它的存在只会增加跑一轮的时间；有些题答案滞后于产品更新，留着反而是错的校准线。我每季度梳理一遍，删掉十道左右的老题，补进同等数量的新题。保持测试集和真实业务同步，它才是一套活的体检表而不是陈年题库。评估脚本本身不复杂，配合大模型工具链很快能搭起来，具体见DeepSeek 工具链。

延伸阅读

• 评估脚本和回归测试怎么搭，见Claude Code 指南。
• 大模型调用与工具链的搭配方法，见DeepSeek 工具链。
• 上线之后效果指标怎么看，见第五篇效果评估一节。