用30个问题给知识库做检索验收，输出未命中清单

一句话结论

准备30个真实问题跑一遍知识库，统计命中率，再把没命中的逐条归因，就是一份可交付的检索验收报告。

这篇解决什么问题

知识库上线前，大家习惯翻几篇文档随手问两句，觉得答得上来就算过了。这种抽查靠的是运气，换个同事问就露馅。

我在做质检侧的验收时更愿意把它做成一次可复现的跑批：固定问题、固定判定标准、固定输出格式，谁跑都是同一个结果。

适用：知识库刚搭完、刚重切过切片、或者准备交接给别的团队时。不适用：文档总共不到十篇，或者业务口径本身还没定下来。

开始前要准备什么

• 一个能正常提问的知识库入口，扣子或 Dify 免费额度够用
• 30 个真问题，从工单、群聊提问、交接记录里抄，别自己现编
• 一张三列表：问题原文、命中文档、判定档位
• 预计耗时：整理问题半小时上下，跑批加归因一个下午能收尾

具体怎么做

第 1 步 · 攒够 30 个真问题

别从文档里反推问题，那样问法天然贴着文档用词，测不出真实分歧。从用户嘴里说出来的话里挑。

我把过去三个月的工单标题和群聊提问导出来粗略筛了一遍，剩下四十来条，然后交给模型归并同义说法。

你是一名检索测试集的设计者。下面是我从工单标题和群聊里摘出来的原始问句，已经做过脱敏处理，一共四十条左右。
请帮我做三件事：
1. 合并同义说法，压缩成 30 个互不重复的测试问题；
2. 给每条标注类型：事实型（问某个具体参数或规定）、流程型（问具体怎么办）、边界型（问例外和特殊情况）；
3. 输出一张表，列是：编号、问题原文、类型、来源渠道。
注意三点：问题保留用户原本的口语说法，不要改写成书面语；类型实在判断不了的标成“待定”，不要硬猜；如果某个类型凑不够条数，直接告诉我缺哪一类，不要编问题。

预期产出：一张 30 行的表，事实型最多、边界型最少，这个比例跟真实提问结构基本对得上。

第 2 步 · 先把命中标准写死

这一步最容易被跳过。同一个回答，两个人打出来的分能差三档，报告就废了。

我的做法是先出一张四档判定卡，开跑之前团队先对一遍，有分歧当场改，改完再动手。

我要给一个内部知识库做检索验收，需要一张判定卡，标准要能被不同的人复现。
背景：使用者是客服和质检同事，日常问三类问题——规定参数类、操作流程类、例外情况类。
请输出一张两列的表：判定档位、一句话说明。必须覆盖下面四种情况：
– 答案正确，并且我能看到出处文档；
– 答案方向对，但漏了关键条件或限定范围；
– 检索到了相关文档，但答非所问；
– 没有检索到任何相关内容。
档位最多四档，不要用“较好”“一般”“基本可以”这类模糊词。最后再补一句：这四档里，哪几档算命中。

预期产出：一张四档判定卡，通常落在“完全命中、部分命中、答偏、未召回”这个骨架上，前两档计入命中。

第 3 步 · 跑一遍 30 个问题并逐条打档

扣子和 Dify 都能在调试窗口里逐条提问。我习惯一个窗口问，另一个窗口开着表格，边问边把出处记下来。

这一步不建议全交给模型。先让模型按判定卡预打分，人只复核它拿不准的那几条，效率最高。

下面是我逐条提问的记录，一共 30 条，每条包含：问题、知识库的回答、系统返回的出处文档名（没有就写“无”）。
这是我用的判定卡：
完全命中——答案正确且有出处；部分命中——方向对但漏关键条件；答偏——检索到文档但答非所问；未召回——没检索到相关内容。
请你按这张卡给每条预打分，输出一张表：编号、判定档位、一句话理由。理由里要指出具体缺了哪个条件，或者答偏到了哪个话题。拿不准的标“待人工复核”，不要猜。

预期产出：一张 30 行的预打分表，标“待人工复核”的通常不超过十条，人只需要盯这一小撮。

第 4 步 · 给未命中条目做归因

光统计有多少条没命中，对整改没什么帮助。真正有用的是知道它为什么掉。

我把未命中分成四类：文档压根没写、写了但切片切碎、术语对不上、召回排序靠后。四类对应的动作完全不同。

下面是这一轮未命中的条目，每条包含问题原文、判定档位、模型给的理由，以及命中的或没命中的文档片段摘要。
请逐条归因到下面四类之一，只能四选一：
A 文档缺失——知识库里根本没有能回答这个问题的内容；
B 切片问题——内容存在，但被切得太碎或跨段，检索时拼不起来；
C 术语不一致——用户说法和文档用词对不上，比如用户说“退货”，文档里只写“逆向物流”；
D 排序问题——相关内容被召回了，但排在后面没进最终答案。
输出一张表：编号、问题原文、归因类别、一句话整改建议。整改建议要具体到动作，不要写“优化文档”这种空话。

预期产出：一张归因表。按我的经验，术语不一致和切片问题往往占大头，这两类改起来也最快。

第 5 步 · 拼成一份能交付的验收报告

报告不是把表格堆在一起。看报告的是负责人，他要的是结论和下一步动作，不是三十行明细。

请把下面这些材料整理成一份检索验收报告，材料包括：30 个测试问题及类型分布、逐条判定档位、命中率统计、未命中归因表。
报告按这个结构写：
一、结论（两三句话，直接说这轮检索能不能用，哪些场景要谨慎）；
二、命中情况（总数、各类问题的命中率，指出掉得最厉害的是哪一类）；
三、未命中清单（按归因类别分组，每条一句话说清问题出在哪）；
四、整改建议（按投入产出排序，先做哪几件）。
语气克制，不要用“显著提升”“全面优化”这类词。凡是材料里没有的数字，宁可不写，也不要估算。

预期产出：一份两三页的验收报告，能直接贴进项目文档，也能当作下一轮重测的对照基线。

实测记录

跟以前的做法比，差别主要在可复现。过去是随手抽几条，问完就忘，下次换个人又从零开始。

现在这份报告留着，下一轮重测拿同一批问题跑，命中率的变化才有意义。

最容易错的 3 个地方

1. 自己编问题。文档反推的问句用词太一致，分数虚高。改从工单抄原话。
2. 标准没定就开跑。两人打档对不上，命中率谁都不认。先对齐判定卡。
3. 只报命中率。看不到未命中清单，没人知道该改哪儿。清单才是主菜。

可复用的东西

这一套下来，能复用的是五段提示词：清洗问题、生成判定卡、预打分、四类归因、拼报告。单独拎哪一段出来都能用，串起来才是验收。

我一般把它们存成一个文件，换项目只改三处：问题来源、判定卡的档位措辞、归因类别名。其余原样搬过去。

判定卡和归因表建议留着当模板，下一轮重测用同一份，两轮数字才对得上。

30 个问题跑完，“我感觉还行”就变成了一张能签字的表。方法不复杂，难的是每次都按同一批问题、同一张卡来跑。

你们现在验收知识库，是随手抽几个问题，还是有一份能反复跑的固定问题集？

如果你也经常要做这件事，欢迎在评论区说说你的卡点和做法；也可以留言告诉我，你想看哪个岗位的哪件活怎么用 AI 拆。

admin 普通

收藏 海报 链接