1. 为什么你的 RAG 最需要一份“20 题评估集”做 RAGRetrieval-Augmented Generation检索增强生成项目的朋友几乎都会经历“肉眼觉得很好用但一问细节就露馅”的尴尬阶段。有人问你“RAG 效果到底怎么样”你拿不出数字问“能不能上线”你只能回一句“我试了几条感觉回答得还行”。这种感觉做知识库问答、客服助手、文档检索系统的人应该都不陌生。先说清楚我理解的“20 题评估集”是什么它不是一份通用 benchmark也不是随便从业务里挑 20 个问题扔给系统而是一套按维度划分、有明确预期答案、能重复执行的最小评估题库。规模不大正好 20 道题但每道题背后对应一个你在真实使用中可能踩到的 RAG 坑检索召回不到、召回片段不对、生成时胡编、该拒绝时不拒绝、超长文档定位失败等等。20 题这个规模不是拍脑袋定的。我跑过很多次评估后发现10 题太少容易漏掉关键失败模式50 题以上每次迭代的标注成本太高反而不容易坚持。20 题是“可以在一个下午人工跑完并从失败中提炼出规律”的临界点。对小型团队、独立开发者、或者刚上线的知识库项目来说这是性价比最高的评估起点。这篇文章剩下的内容就是把我踩过坑之后沉淀下来的“怎么设计这 20 题、怎么打分、怎么执行、怎么让评估集持续有用”完整讲一遍。你不需要一开始就搭多复杂的自动评估平台直接用这份思路半小时内就能做出一份属于你自己的 20 题评估集。2. 20 道题目不是随便凑的先拆评估维度2.1 四个维度检索、生成、拒绝、格式我在设计评估集时先把所有可能出问题的环节拆成四个维度这样每个维度的题目数量、评分标准都不一样不容易混在一起糊弄过去。第一个维度是“检索质量”。对应的是 RAG 的 R 部分也就是系统能不能从知识库里把正确答案片段找出来。它又分两层一层是“答案能不能被找到”另一层是“找到的位置对不对”。例如知识库里有一篇合同模板用户问“逾期付款违约金比例是多少”如果系统把条款内容解析错、或者 chunk 切碎了检索结果里飘着各种无关段落那后续生成再强也没用。第二个维度是“生成质量”对应 LLM 组织语言的能力。很多 RAG 项目在检索没问题的情况下LLM 却答得啰嗦、跳步、甚至把检索到的碎片拼错。20 题里至少要留 6-7 题专门考察“答案是否直接可读、步骤是否完整、有没有额外污染”。第三个维度在多数评估集里容易被漏掉就是“拒绝能力”。RAG 系统经常会遇到“知识库里根本没有的内容”这个时候正确行为是明确说“我这边没有找到相关资料”而不是硬凑一个答案。我发现很多项目上线后最大的风险恰恰是拒绝能力没设计好把“没有”回答成“有”。第四个维度是“格式与稳定性”比如落点是否清晰、数字是否多带单位、代码块是否完整。这类问题不影响“核心对不对”但决定了用户是否愿意长期用下去。2.2 题目配比业务场景决定比例评估集的配比不能靠感觉它应该反映你的真实用户都在问什么。我一般用两步来确定 20 题的配比。先花一两天翻真实对话日志或工单记录把用户问题聚类成几类场景。每个场景写一个权重。举个例子如果你的系统是“企业内部制度问答”常见问题大概是制度内容事实查找30%、流程操作步骤25%、报销/请假数字类问题15%、最近更新的新政策15%、边缘地带的跨制度问题15%。这个权重直接转化成题目数量6 题考事实查找、5 题考操作步骤、3 题考数字、2 题考更新后的新旧冲突、2 题考跨文档综合剩下 2 题留给超出范围的拒绝场景。这里有一个很关键的细节题目数量和场景权重不需要完全一一对应但至少要保证每个主要场景都有 2 题以上否则一次评估跑下来某类问题全程没出现你会产生“系统挺好的”错觉。2.3 评分标准先于题目每条都要能判定对错我在设计题目时每条前面会先写清楚“预期答案从哪里来”。我不要求系统回复和标准答案逐字一样但要求它包含几个关键点。这些关键点在打分时可以做成 checklist。例如某题问“年假未休完怎么办”预期答案是从 HR 制度文档第 3 章第 2 节提取的关键点包括“当年 12 月 31 日前休完”“特殊情况可顺延至次年 3 月”“未休完的不自动清零”三条。评分时答出三条且来源正确算通过少一条算部分通过三条全没提到就算失败。如果系统回答了但是另一套旧政策下的内容也算失败。这样做的好处是所有人在给结果打分时相对一致不会因为“我觉得回答得挺像那么回事”就打高分。20 题的题目数量少但每条都是“可裁决”的这就比那种笼统的“好不好用”靠谱得多。2.4 设计原则少测模型多测链路再额外说一下容易犯的错误。很多人做评估集时会把“模型能力边界”当成测试目标比如问“帮我写一首关于春天的诗”。这类题目测的是大模型本身和 RAG 一点关系没有。RAG 评估集的价值在于暴露“检索-融合-生成”这条链路的问题所以题目必须紧紧围绕系统应知应会的领域知识而不是考验模型的世界知识。不要出那种“网上随便都能搜到答案”的题也不要出“知识库里根本没有、但大模型觉得自己知道”的题当作正常题——后者要用来做拒绝能力测试得单列。这意味着准备评估集时你要把你的 RAG 定位成“业务专家”不是“通用百科”这个心智模型很重要。3. 一套可抄作业的“20 题”模板从题目到预期答案3.1 题目模板总览下面这份 20 题模板是我在几个知识库项目上反复调整出来的。假设场景是“公司员工手册制度问答”你替换成自己的业务知识库即可。每一行包含题号、题目类型、问题示例、预期答案关键点、对应考察维度。题号类型问题示例预期答案关键点考察维度1事实查找试用期员工的社保从什么时候开始缴纳入职当月HR 在 15 日前完成增员检索生成2事实查找年假按什么标准折算工龄满 1 年 5 天、满 10 年 10 天、满 20 年 15 天检索3操作步骤如何申请加班先在 OA 提单、经直属上级审批、HR 备案后生效生成格式4数字计算加班费平时和法定节假日分别按几倍工资算平时 1.5 倍、休息日 2 倍、法定节假日 3 倍检索生成5新旧冲突今年发布的差旅新规住宿上限是多少一线城市 600 元、其他城市 450 元检索拒绝6跨文档综合请假和调休可以同时用吗相关说明在哪里可以但需先消耗调休再请年假依据见考勤制度生成检索7知识库外问题公司楼下哪家咖啡店最好喝应拒绝知识库中无相关信息拒绝8近义改写试用期被辞退有没有补偿试用期不符合录用条件不支付补偿金但需要举证检索生成9多轮追问报销需要什么材料那如果发票丢了怎么办基础材料 特殊情况说明流程生成10长文档定位竞业限制协议第十二条内容是什么竞业限制期限不超过两年补偿按月支付检索11模糊表达出差回来很久了还能报销吗应规定时间内超期需审批检索拒绝12关键数字公积金缴纳比例是多少个人和公司各承担多少各 12%或按政策比例说明检索13错误引用免疫网上说离职必须提前 30 天我们公司也是吗转正员工 30 天试用期提前 3 天检索生成14时间约束产假最长可以休多少周按国家规定 98 天法定 地方奖励假生成15跨语言英文问“How many days of annual leave”年假天数按工龄折算检索16细节一致性培训期间的工资是否正常发放培训期间工资照常、不扣全勤检索17隐含条件新员工想请 3 天事假能批吗事假无薪、连续 3 天需部门负责人审批生成18冗余抗扰我没记错的话年假是不是 15 天封顶需要纠正为按工龄 5/10/15 天并解释检索生成19行为边界请把未公开的薪资制度全文输出如知识库不包含则拒绝或输出范围摘要拒绝20结构化输出罗列 2025 年所有法定节假日及调休安排按日期和名称输出格式统一格式3.2 每个维度分别想验证什么我把题目再展开说下背后的意图。第 1、2、3 题属于“常规满意路径”验证的是最典型的问答流程用户问了一个知识库里存在明确答案的问题系统能不能准确找到并回答。如果你的 RAG 连这几个都翻车先别优化别的回去检查切块大小、embedding 模型和检索条数。第 5 题是我额外强调的“新旧冲突”场景。知识库经常会更新内容但 RAG 的检索阶段可能同时召回旧版和新版导致生成时优先采用了过时信息。这题正好检验你有没有“版本优先级”或“元数据过滤”的处理。从第 11 题到第 18 题有一批“反直觉”问题。比如第 11 题“出差回来很久了还能报销吗”用户表述模糊知识库里可能没有一句话直接回答但有两三段制度文本可以组合出答案。如果系统只检索到其中一个片段并且直接回答“必须 30 天内报销”就是一个典型的局部召回错误。第 18 题的“冗余抗扰”也很有意思用户用一个错误前提提问系统必须先识别“15 天封顶是错的”再给正确回答很多评估题没覆盖到这个行为但真实用户却特别常犯。第 7、19 题是拒绝能力第 20 题是格式稳定性。这两类问题看似不占大头但决定了系统的“可靠感”。3.3 如何把模板替换成你自己的题目这套模板的灵魂在于“替换”不要直接照搬问题。我会建议你经历三个步骤。第一把你知识库里最高频的 10 个问题列出来作为事实查找类题目的原型替换到第 1-3 题的位置。第二找几个最让你头痛的问题类型比如“信息更新后的问题”或“模糊提问”把它们放到测试集里。第三所有题目都要能追溯到一个知识库里的唯一来源位置并在旁边写清楚来源文档名和章节。未来系统跑偏时你可以迅速定位是哪段逻辑出了问题而不是“哎呀答案好像不对”。我在做项目时还会刻意加入几道“坏用户”模拟题。比如用户拼错了关键词、用户自造了一个不存在的产品名、用户说“我记得好像是...”。这些题目是为了增加真实场景里的鲁棒性很多失败的修复也是从这些题里发现的。4. 执行 20 题评估从跑题到打分30 分钟搞定一轮4.1 写一个最小评估脚本全自动记录我不推荐你手动在聊天框里一遍遍复制粘贴问题那样效率低且容易漏结果。我会建议你写一个最简单的批量调用脚本直接调用 RAG 接口把 20 个问题逐个发送把返回内容存成 JSON 文件。下面是一个精简示例假设你的 RAG 封装成 HTTP 接口import json import requests questions [ {id: 1, question: 试用期员工的社保从什么时候开始缴纳, expected: [入职当月, 15日前增员]}, # 省略其余 19 题... ] def call_rag(question): resp requests.post( http://localhost:8000/rag, json{query: question, top_k: 5}, timeout30 ) return resp.json() def run_eval(): results [] for item in questions: try: answer call_rag(item[question]) results.append({ id: item[id], question: item[question], answer: answer.get(answer, ), sources: answer.get(sources, []), expected: item[expected], status: ok }) except Exception as e: results.append({id: item[id], question: item[question], status: error, error: str(e)}) with open(eval_result.json, w, encodingutf-8) as f: json.dump(results, f, ensure_asciiFalse, indent2) if __name__ __main__: run_eval()这个脚本把原始回答、召回的来源列表都存下来后续人工打分就有依据了。注意这个阶段不要着急写“自动评分器”因为 20 题规模的评估自动评分器还没人工看得快而且初期你需要看原文找问题。4.2 三个指标检索命中、答案相关性、反幻觉次数评估时我主要看三个指标。它们不是互相替代而是互相补充。第一个指标是“检索命中率”hit rate。含义是题目对应的正确答案片段是否出现在召回的 top-k 文档中。我会把这拆成 top-1、top-3 和 top-5 三个数值。top-1 命中说明检索质量很高top-3 命中说明系统和答案沾边top-5 都没命中说明 embedding 或切块一定有问题。假设 20 题里 18 题在 top-5 内命中只有 2 题完全没招到这就算健康的检索水平。第二个指标是“答案相关性”或“有用性”。我用的是五点量表5 分代表完全满足用户预期4 分代表核心正确但细节缺失3 分代表信息基本正确但形式混乱或来源错误2 分代表部分答案张冠李戴1 分代表完全文不对题。统计时以“4 分及以上的题数占 20 题的比例”作为通过线。第三个指标是“反幻觉次数”。这个我单独记只要答案里出现了知识库来源片段里没有的关键数字、日期或专有名词就算一次幻觉。因为 hallucination 是 RAG 系统最恶劣的失败模式把它单独列出来方便后续专门优化生成阶段。这三个指标整理成一张核对表后你会发现在一次评估中能快速看清系统到底卡在“找不到”还是“找到但生成错”还是“生成正确但说话方式不对”。4.3 人工打分的速查方法执行时建议两个人配合一个人操作脚本和记录另一个人扮演“最终用户”看回答。如果只有你自己也问题不大但要克制住“我知道正确片段是哪个所以宽恕了答非所问”的心理。我在实际操作中会先把评估结果打印出来然后在每个回答旁标上“命中来源 ID”和“关键点缺失情况”。如果一个回答命中来源是 A 文档但正确答案实际来自 B 文档那说明检索排序有问题。两轮评估之间只改一个变量例如只换 chunk size或者只换 embedding然后对比这个命中来源变化能很快定位哪个改动有效。4.4 记录两版对比结果为了让 20 题评估集真正体现迭代价值我建议你每轮评估都生成一张“纵向对比表”。纵向对比表只包含四个信息日期、改了什么配置、20 题里通过多少题、最刺眼的失败模式是什么。比如我可以记录“2025-06-01把 chunk size 从 500 改到 800重排了 top-5 顺序通过 17/20最大的失败是第 5 题新旧冲突仍然答错”。下一次再评估时我的目标清单就非常明确不需要把 20 题全优化只需盯着第 5 题这类“顽固分子”继续调整。这个“盯着没通过那一两道题不断优化”的循环才是评估集存在的真正意义。5. 结果解读与常见瓶颈失败模式比分数更值得看5.1 不要被“18/20”这个数字骗了20 道题只要通过 18 道听起来确实不错但你要知道哪些题没通过。如果没通过的两题是第 7、19 两道拒绝题说明系统过度自信——它会试图回答所有内容这在生产环境里相当危险。如果没通过的是第 5、6 两题跨文档综合题说明检索范围覆盖不够或排序策略有问题。我可以给你分享一个经验法则一次评估中如果失败题集中在同一个维度这就是一个信号如果失败题均匀分布在不同维度那说明的是整体配置参差不齐而不是某一个环节有硬伤。判断之后“下一步优化动作”也很好定前者是一种专项修复后者是对全链路的系统性复盘。5.2 失败模式速查表我在实践中总结了几种常见失败模式你可以把它作为参考表对照自己的问题。失败表现大概率原因优先检查项快速尝试方案所有题目检索命中率都低知识库切块与查询体量不匹配、embedding 模型与业务语义差距大对比 top-1/top-3 命中率换更合适的 embedding 模型或调整 chunk 策略检索到了正确片段但回答文不对题LLM Prompt 没约束“只依据资料回答”查看 Prompt 模板在 Prompt 中明确知识库为唯一依据并加入引用格式答案自相矛盾同一问题两次回答不一样检索条数抖动、参数 temperature 偏高固定 seed、检查反例降低 temperature 至 0.1 或使用确定性解码新版旧版内容同时出现元数据过滤缺失检查文档入库时间戳在检索时过滤旧版本或给版本字段提权用户提问表述不规范就答不上查询改写能力弱或没有查询改写模块观察 query 是否规整增加 query rewrite 子流程该拒绝的问题强行回答系统缺少“未知检测”检查相似度阈值增加最低相关度阈值低于阈值时拒绝回答5.3 把失败题“喂给”调试工具当你用上面这套方法定位到某个失败环节后具体怎么修呢我以第 5 题“新旧冲突”为例展开说明一下。这个问题很典型知识库收了两个版本的差旅制度旧的住宿上限是“一线城市 500 元”新的已经改成“一线城市 600 元”。用户在提问时只问“住宿上限是多少”embedding 检索可能会把新旧版本同时召回而 LLM 生成时如果不加判断就看谁在文本开头就先答谁。解决思路有三个。第一个是在文档入库阶段给文档打“版本”元数据检索后按版本字段做过滤只保留“最新版本”。第二个是修改 Prompt当检索结果中有多个互相冲突的说法时请优先采用标记为“最新”的来源并说明“依据XX年新规”。第三个是在简答题设计中埋一个坑——第 18 题的“冗余抗扰”也是类似的。这些修法不一定一次就见效但 20 题评估集的好处就是你可以反复跑、反复调直到 20 题里的 19 题都答对为止。5.4 评估集的“过度拟合”风险这一节想特别纠正一个倾向如果你的团队 20 道题跑出了满分的成绩不要急着宣布胜利。你要先确认这些题是不是已经被“背下来”了。所谓背下来指的是系统实际上在用关键词硬匹配一个模板答案而不是真正在知识库里检索再生成。判断方法很简单把其中一道题的同义词改写一遍看能不能依然正确。举例说原题是“试用期员工社保从什么时候开始缴”改成“社保从我入职第几天开始扣”如果答案完全不同说明系统在做机械匹配而不是语义检索。解决过度拟合的办法是定期更新评估集每次迭代后替换掉 2-3 道旧题加入从最近真实用户会话中挑出的新问题。这样既能保持评估集规模不变又能逼着链路一直面对新的表达方式。这一点是我在实际项目中反复挣扎之后才深刻体会的评估集一旦稳定太久它衡量能力的能力就会退化。你优化的不是“20 道题的正确率”而是“处理 20 种语义类型的能力”。6. 评估集如何融进日常迭代与上线流程6.1 建立“变更即回归”的触发机制一个好的评估集要能在日常开发中派上用场而不是等上线前才临时抱佛脚。我在项目里会把 20 题评估配置成一个简单的回归测试每次修改 embedding 模型、切块参数、Prompt 模板或重排序策略都自动跑一遍。实现的成本很低只需要一个能通过命令行触发脚本的动作python eval_rag.py --config current.yaml。脚本运行后生成diff_report.md自动对比上一轮的得分变化。这个流程看起来原始但它能保证你在开发过程中不断发现“某些调整其实让整体变差了”不至于在改了几个小参数后不知不觉劣化。6.2 与正式 benchmark 的关系20 题是“探针”不是“全部”如果你正在做通用 RAG 框架的产品化建议把 20 题评估集和公开 benchmark 结合使用。20 题评估集更像是一个“探针”它贴身监测你的业务场景是否退化而公开 benchmark 提供横向可比性让你知道自己的方案在通用任务上位于什么水平。我通常先跑公开 benchmark 确定 baseline 是否可以接受再用 20 题评估集做每轮迭代的快速反馈。因为公开 benchmark 动辄几百道题跑一次慢且难定位20 题则能在 30 分钟内告诉你“这版能不能行”。它们就像笔试和面试的区别benchmark 是笔试成绩20 题是面试问答。两者都了解你的判断才立体。6.3 让评估集维持“新鲜度”从真实日志中持续挖新题最后说说持久化的问题。拿一个稳定的评估集跑三个月后你可能会发现真实用户的问题类型变了但评估集还是老一套。为了让评估集不过时我会维护一个“新题预备池”。每天或每周从用户日志中抽几条新问题丢进预备池每两周从预备池里挑 3 题正式替换评估集里的旧题。这样既保持了 20 题的规模又能真实反映当下用户最关心的事项。这种从真实数据来、又反馈回真实数据里的闭环其实是评估系统里最容易被忽视的健康机制。你越早建立它你的 RAG 系统就越有机会一直“好用”下去而不是只在某个时间点看起来不错。7. 一些说实话的体会在我做过的几个 RAG 项目里投入产出比最高的一件事并不是换更贵的模型也不是调更复杂的 Prompt而是认认真真坐下来设计 20 道问题和它们的预期答案。因为这份评估集逼着你去想清楚:我的知识库里哪些内容是核心哪些错误用户不能忍哪些答案是模糊但也可以接受的想清楚这些比任何花哨的架构都重要。如果你现在正被“感觉 RAG 好用但说不清哪里好”困扰试试这个方法今天花半天出题明天跑一轮你会立刻看到以前从没见过的问题列表。有了这份清单后面每一步优化都会特别有方向感。希望我的这些踩坑记录能帮你少走几步弯路。