企业官网建设流程全解析

先回答一个问题：你凭什么说自己的 RAG 好用？靠拍胸脯，还是靠演示时挑几个精心准备的问题？我在过去半年里做过三套基于 LangChain 的 RAG 知识库，也帮朋友看过两个 RAG 项目，可以说，真正让 RAG 从“demo 很漂亮”变成“上线敢用”，靠的从来不是模型选得多大、向量库配得多花哨，而是一套能反复跑的评估集。这篇文章想讲的，就是我怎么用一套 20 题评估集来证明、逼出、兜住 RAG 系统的底线。

这套评估集不是什么学术论文里的 benchmark，而是我自己根据业务知识库整理出来的 20 道题，覆盖事实检索、跨文档整合、拒答、版本时效、边界追问五种能力。跑完一轮，你能得到三个东西：一个可复现的分数基线、一张失败案例清单、一份改进路线图。无论你是刚用 Ollama 搭了本地知识库的新手，还是在 LangChain4j 或 Spring AI 里做企业 RAG 的开发者，这套思路都能直接搬走用，造题、跑分、迭代三件事，不需要大型平台，一台普通电脑加一个评测用的 LLM 就够。

1. 为什么要做评估集：RAG 系统的信任危机

1.1 “感觉好用”和“真能用”之间的鸿沟

RAG 这个架构看起来不复杂：向量检索召回片段，拼接给大模型，再生成答案。但真正跑起来你就会发现，这个链路里每个环节都在悄悄“骗”你。检索召回的片段可能完全无关，大模型却照样编出一个流畅的答案；知识库里两个文档说法矛盾，模型往往挑了过时的那条；用户换个说法问同一个问题，结果答得完全不一样。这些问题在演示阶段几乎不会被发现，因为你下意识会选那些“模型肯定答得好”的问题。

我做第一版 RAG 的时候，内部测试了差不多十几轮，每轮都觉得“这回应该稳了”。结果一上内部员工真实提问，惨状立刻现形：业务问题答非所问、把旧版制度当现行政策、甚至直接编造不存在的操作流程。当时最大的挫败感不在于系统差，而在于我说不出到底差在哪——是检索没召回到？还是召回到了但提示词没引导好？还是切分太碎导致上下文丢了？没有评估集，这些问题只能靠肉眼一个个看，效率极低，而且换个人测又是另一种看法。

后来我意识到，RAG 评估的本质是建立一套“验收测试”。就像软件工程里不能只靠“跑起来没报错”来证明程序正确，RAG 也不能靠“问了几个问题都答了”来证明好用。你得有一组固定的题目，每次改动模型、切分策略、Embedding 或提示词之后，跑同一套题，对比前后分数，才能判断改动到底是变好还是变差。没有这个基线，你所谓的“优化”可能只是在拆东墙补西墙。

1.2 评估是 RAG 迭代的地基，而不是形式工程

很多人一听“评估集”，第一反应是“不就是整理几个问题测一下嘛”。实际操作后你会发现，评估集设计的质量直接决定了你能从跑分里挖出多少有效信息。它不只是验证工具，更是迭代工具。举个例子，我在第二版 RAG 里调整了文档切分的 chunk 大小，如果只看一两个测试问题，感觉好像差不多；但跑了完整的 20 题，才发现命中率从 68% 掉到了 55%，因为 chunk 变大后单条片段信息密度下降，精细问题反而召不回了。

RAG 系统里有几个核心指标，评估集就是围绕这些指标设计的：Hit Rate（检索命中率，看正确知识片段是否出现在召回结果里）、上下文相关性（召回片段与问题的匹配程度）、生成忠实度（答案有没有忠实基于上下文，而不是模型自由发挥）、回答完整性（该答的点有没有漏），以及拒答准确率（不知道的时候能不能老实说不知道）。没有评估集，这些指标就只能停留在口头讨论里；有了评估集，每个分数背后都是一条可定位的失败样本，你可以顺着它一路追踪到切分、Embedding、检索、重排、提示词任何一个环节。

所以，评估集不是“给领导看的东西”，它是你调试 RAG 时最有价值的杠杆。我见过不少人花了大量时间调 Embedding 模型、换向量数据库，效果始终不稳定，原因就是没有一套题告诉他“瓶颈到底在哪一层”。少做一步评估，后面优化的每一步都可能是在盲打。

2. 设计一个 20 题评估集：五类题目搭建评测骨架

2.1 先把测评的“维度”定下来

设计评估集之前，我建议先别急着编题，而是先想清楚自己要测哪几个能力维度。RAG 系统最常见的失败场景就那几类，评估题应当集中在它们身上，而不是均匀地“随便出 20 道”。

我最终定下来的是五个维度，每个维度对应一类题目：

第一类：基础事实题。这类题考察系统能否从知识库里准确找到并原样回答某个明确的事实点，比如“公司年假制度规定工作满一年有几天年假”。它检验的是基础检索能力和切分粒度是否合适，是 RAG 最核心的底线能力。

第二类：跨文档综合题。这类题需要系统把分散在不同文档里的信息拼接起来，比如“入职第一年的年假天数加上福利体检额度，一共能享受哪些福利”。它专门考察多文档召回和拼接生成能力，如果切分过碎、检索结果里缺了某个片段，这类题就会暴露问题。

第三类：否定与缺失题。这类题故意问知识库里不存在的内容，比如“公司是否提供免费午餐补贴”。正确的行为是明确拒答，而不是强行编造。很多 RAG 系统在这里现出原形——模型会一本正经地把没有的内容“补全”出来。

第四类：时效与版本题。知识库里的制度、政策经常更新，这类题考察系统能不能准确区分新旧版本。比如问“今年的报销上限是多少”，知识库里既有旧制度又有新制度，系统必须检索到正确版本并把旧版本排除。

第五类：边界与追问题。这类题不直接照抄知识库原文，而是换个说法、加个条件，或者在某个答案基础上继续追问，考察的是语义理解和泛化能力。很多检索系统在关键词完全匹配时表现良好，一问“引申含义”就崩。

这五个维度覆盖了我实际遇到的 90% 以上的 RAG 翻车场景，也对应了检索、召回、排序、生成、拒答全链路。

2.2 20 题的分布比例与结构建议

五类题目确定后，20 道题的分布比例需要根据你的业务场景来调，但我有一份默认配置可以供你起步时参考：

为什么把基础事实题放最多？因为这是 RAG 的立身之本——如果连明确写在文档里的东西都答不对，其他谈都不用谈。否定与缺失题我也放了 4 道，这是很多人忽略但实际业务里最容易出事的地方。用户会问你很多知识库里没有答案的问题，系统如果总是瞎编，上线后对信任度的杀伤力远大于“答不上来”。

这里有个关键原则：题目要出自真实用户提问，而不是你自己拍脑袋编。我建第一版评估集时犯过一个错，出的题全部是我自己对文档的理解，结果系统跑分很高，一到真实用户手里就崩。后来我把内部群里、客服后台、试用反馈里出现的真实问题全部收集起来，过滤掉那些太含糊、需要对话上下文的，再按五类维度归类筛选，才得到了真正有价值的 20 题。

关于难度控制，我建议 20 题里至少要有 3 到 4 题是“刁钻题”，比如某个事实藏在很长的段落中间、两个文档互相矛盾、或者用户用了一个和原文完全不匹配的说法。这类题的存在，是为了防止你的评估集“放水”。如果 20 题全是简单问题，评估分数看起来再高也没有参考价值。

3. 从零到一：一套 20 题评估集的全解析

3.1 每类题背后的能力验证点

前面说了设计框架，现在直接上一套可以对照参考的 20 题模板。这套题不是让你原样抄，它的价值在于让你知道每道题在考什么。我以“某公司内部制度知识库”为例子来写，你换成自己的领域即可。

基础事实题（6 题）：

1. 员工每年享有多少天带薪年假？ —— 验证从制度文档里精确检索并回答。
2. 申请加班需要提前多久提交审批？ —— 验证不同文档中同一主题的定位能力。
3. 年度体检的项目范围包括哪些？ —— 验证列表类信息的完整性，模型容易漏项。
4. 公司规定的报销流程首步是什么？ —— 验证步骤类信息的顺序准确性。
5. 绩效考核的评估周期是多久？ —— 验证定义类问题的单点召回能力。
6. 员工转正需要满足哪些条件？ —— 验证条件列表的完整抽取。

设计意图很明确：基础事实题必须保证 100% 答对，因为这些问题只要知识库里有，并且检索做对了，就不可能答错。如果有任何一题错了，说明你的检索链路存在基础性缺陷。

跨文档综合题（4 题）：

7. 如果我入职满一年，除了年假之外，还自动获得哪些福利？ —— 需要同时从休假制度、福利制度两个文档中提取信息。
8. 报销和加班审批两个流程中，哪个需要负责人和财务双重签字？ —— 需要从不同流程中做交叉判断。
9. 请假三天和请假一周的审批权限分别由谁负责？ —— 需要对比两个制度段落。
10. 试用期员工和正式员工的离职通知期有什么区别？ —— 需要同时定位两个文档并做对比。

跨文档综合题是 RAG 和普通搜索的最大区别所在，它考验的是系统能不能把碎片化知识“粘起来”。做这种题如果命中率不高，问题大概率出在切分策略和召回数量上。

否定与缺失题（4 题）：

11. 公司是否提供免费班车接送服务？ —— 知识库里没有提过这个政策，应拒答。
12. 入职满一年有没有额外的住房补贴？ —— 部分否定，需要回答“没有”而不能回避。
13. 员工健身房的开放时间是几点？ —— 知识库没有健身房信息，应明确说明“未找到相关信息”。
14. 公司是否有针对孕妇的专门福利？ —— 如果没有相关政策，应如实说“没有收录”而不是发挥。

否定与缺失题是我在所有项目里最强调的一类。很多 RAG 参考示例压根不测这类题，导致系统上线后成了“自信满满的骗子”。在评估系统时，我要的不是模型想象力，而是克制力。

时效与版本题（3 题）：

15. 根据最新版考勤制度，迟到多久算旷工？ —— 区分新旧版本，识别“最新版”。
16. 今年更新的差旅标准中，住宿报销上限是多少？ —— 需要从多个年份的政策中定位最新的。
17. 绩效等级为 A 的奖金系数在修订前后有什么变化？ —— 需要纵向对比版本差异。

这类题靠关键词检索特别容易翻车，因为“差旅标准”这个说法在旧版文档中也大量出现，源头到底取哪一段，对召回排序的精度要求很高。

边界与追问题（3 题）：

18. 如果员工在出差期间生病，医疗费用怎么报销？ —— 原文可能是“出差期间发生意外医疗费用”，需要语义匹配“生病”。
19. 提交报销后一般多久能收到打款？ —— 原文可能写的是“审核通过后 10 个工作日内发放”，考察同义转换。
20. 我已经把发票上传了，为什么流程一直停在待审核状态？ —— 这是典型的追问和场景化表达，需要系统理解用户意图并找到流程状态说明。

边界与追问题是最接近真实用户行为的一类，也最能拉开不同 RAG 系统的差距。如果你的召回只做关键词匹配，这类题大概率会漏召回。

3.2 标注参考答案与评判标准

题目只是评估集的一半，另一半是参考答案和判定标准。我建议每道题做两张卡：一张是“参考答案卡”，记录从知识库哪个文档的哪个片段可以推出答案；另一张是“评分标准卡”，定义 0 分、1 分、2 分三档。

举第 1 题为例：

• 参考答案：员工每年享受 15 天带薪年假，来源为《员工休假管理制度.docx》第三章第 2 条。
• 评分标准：2 分 —— 回答“15 天”且无附加错误；1 分 —— 回答“15 天左右”或“十天以上”；0 分 —— 回答错误、含糊、或编造其他数字。

这里我踩过一个很实际的坑：一开始我只写了标准答案，没有写“哪些表述也算对”，结果人工评估时两个人的打分一直有分歧。后来我在参考答案卡里补充了“等价表达示例”，比如“15 天”“十五天”“15个工作日（如果制度里确实写了工作日的话）”这些都算对，才把评估一致性拉上来。

参考答案卡还有一个用途：它可以反过来驱动你的检索链路验证。每道题我都记录了“标准来源文档”，跑完检索后，你能直接查召回列表里有没有包含这个来源，从而区分“检索失败”和“生成失败”。这个区分至关重要——同样是 0 分，原因可能一个在 retriever，一个在 LLM，处理手段完全不一样。

4. 评估实操：从手动跑分到自动化打分

4.1 人工评估怎么才做得准：对抗偏见的流程

当你第一次拿着 20 题去评估系统时，我强烈建议先做一轮严格的人工评估，不要急着接任何自动评估工具。原因很简单：你需要亲眼看到每一道错题到底错在哪，才能建立对系统的“体感”。机器打分可以告诉你分数，但很难告诉你“答案是因为漏了一段上下文才错的”。

人工评估有几个可以马上用起来的原则：

第一，评估人不能是写提示词的人。自己做的系统自己打分，很容易带着“我知道资料在哪儿”的先验去做判断，评估结果会有严重幸存者偏差。最理想的是拉一位不了解内部文档的同事来打分，你只负责记录。

第二，做双盲评估。把不同版本的输出打乱顺序再评分，不要连着看同一版本的 20 道题，防止评估人惯性打分。

第三，用统一的评分维度。我给每个维度设了 1 到 5 分，分别对应：完全错误、部分正确但缺关键点、正确但不完整、正确且完整、正确且简洁完整。稍微有点主观没关系，关键是每次评估用同一把尺子。

人工评估 20 题大概需要 30 到 40 分钟，如果以后系统迭代频繁，不可能每次都人工跑。所以我的做法是先人工跑一轮建立基线，确定哪些题是给机器打分时的“锚点题”，再用自动评估做日常回归。

4.2 用 LLM 打分替代人工？可行但有讲究

接入了自动评估之后，我通常用一个独立的评测模型来给 20 题打分。注意这个评测模型最好和 RAG 生成模型不是一个，避免风格过度拟合。

核心做法是在评测模型里放一个评估提示词，让它按标准答案给分：

question = "员工每年享有多少天带薪年假？" reference = "15 天，来源：《员工休假管理制度》" answer = rag_chain.invoke(question) judge_prompt = f""" 你是一个严格的 RAG 评估员。请根据参考答案判断模型回答是否正确。 参考答案：{reference} 模型回答：{answer} 评分标准： - 2 分：信息正确、与参考答案一致 - 1 分：部分正确但有遗漏或模糊 - 0 分：错误、编造或答非所问 请只输出分数，并简短说明理由。 """

这里我要提一个重点：自动评估必须结合参考答案，而不是只让 LLM 看着问题和回答自由评判。我一开始偷懒，直接让评测模型“这个回答是否准确”，结果它给大多数答案都打了高分，哪怕答案内容完全不是知识库里的。加上参考答案后，评测模型的准确率才明显提升。

自动评估跑完会得到一个总表，我会按三个维度统计：Hit Rate（召回了正确片段的比例）、答案得分率（2 分题占总题数的比例）、拒答正确率（否定题中正确拒答的比例）。这三个数字就是我以后每次改系统的“仪表盘”。

还有一个容易忽略的细节：自动评估时要记录每条答案对应的召回片段，哪怕答案是错的，也要存档。跑完一次评估后，我通常会保存一份完整的“评估快照”，包含题目、召回片段、生成答案、分数四列。以后任何一次模型或配置改动，都和这个快照做 diff，能极其清楚地看到动了哪里、影响在哪。

5. 跑分之后的坏消息：5 个高频失败点与排查技巧

5.1 命中率低：先查切分和召回 Top-K

20 题跑下来，如果基础事实题频繁丢分，第一件事查 Hit Rate。所谓 Hit Rate，就是 20 题里有多少题的正确答案片段被召回到了。我见过很多团队绕开 Hit Rate 直接看“答案对不对”，这是本末倒置。如果召回里根本没有正确答案，大模型再聪明也白搭。

命中率低最常见的三个原因：切分粒度不对、召回数量太少、Embedding 模型与文档领域不匹配。

切分粒度是我的第一排查目标。太碎，比如一个 200 字的小节被切到多个 chunk，检索时容易漏；太粗，一个 chunk 五千字，向量表征被稀释，语义不聚焦。我在知识库项目里常用的做法是按 Markdown 标题结构切分，让每个 chunk 有独立语义块，再控制在 300 到 500 个 token 左右。你可以先跑两版切分参数对比 20 题的 Hit Rate，选高的那版作为默认。

召回数量 Top-K 也值得检查。K 默认 4 不够用的时候，跨文档综合题就会挂。我后来普遍调到 6 到 8，配合重排来保留精度。这里有个权衡：K 越大，召回越全但噪声越多，生成质量可能下降；K 太小，综合题必挂。建议至少用 20 题里跨文档综合题的表现来定 K。

5.2 召回命中但答非所问：问题出在排序和重排

当 Hit Rate 很高、但答案依旧错误时，典型的症状是“答案该有的信息都散落在不同的召回片段里，但模型没捡全”。这个问题我在第一版系统里反复遇到，后来发现根因是排序：正确片段确实召回到了，但排在 Top-K 的最后一位，生成时被更靠前的无关片段占据了注意力。

这也是为什么后来我在所有 LangChain RAG 流程里都加了重排（rerank）步骤。做法很简单：先用向量检索召回 Top-50，再用交叉编码器对 50 个片段打分重排，取 Top-5 喂给大模型。加上这一步后，跨文档综合题的得分肉眼可见地提高，因为和问题语义真正相关的片段被顶到了前面。如果你的项目是零基础搭的本地知识库，暂时不想上重排，那么至少可以先试提高 Top-K，并注意在组装上下文时把片段按相关分数排序。

另一个常见问题是上下文组装顺序。模型看到长上下文时，注意力会偏向开头和结尾，如果你把最有用的片段埋在中间，答案就容易漏。我在提示词组装时会把“最相关的片段”放在开头，并且在片段前注明文档来源，模型的表现会稳定很多。

5.3 幻觉问题：否定题暴露得最彻底

如果说前两类问题还能靠调参数修，幻觉问题就要靠设计逻辑来治。否定与缺失题的目的就是专门逼出幻觉。模型看到“员工健身房”时，即使知识库里没有相关文档，它也倾向于生成一个“正常情况下健身房开放时间是早 8 点到晚 10 点”之类的答案。

我试过几个办法，效果从高到低排列：第一是在提示词里写死“只允许基于上下文中出现的信息回答，如果没有相关信息，明确回答‘知识库中未找到相关信息’”；第二是在答案生成后做一个“忠实度校验”，把生成答案和召回片段比对，如果答案里有片段中找不到的关键信息则标记为幻觉；第三是做兜底，如果检索到的片段相关度全部低于某个阈值，直接拒答而不让模型生成。这个阈值可以靠 20 题里的否定题逐步试出来。

这套组合拳下来，我评估集里的否定与缺失题基本能稳定答对 3 到 4 题。剩下偶尔翻车的那一题，通常不是模型的问题，而是某个文档里模棱两可地提到了相关概念，导致模型真的以为知识库里有答案。这种“模糊边界”场景很难靠提示词根治，只能把文档改清楚，或者在知识库里标注“此政策已废止”。

5.4 版本混乱：检索到了旧版文档

时效与版本题是 RAG 知识库在企业场景里最现实的挑战。旧版制度和新版制度同时存在时，模型往往把两版信息混在一起。知道“报销上限修订过”还不够，难的是让检索准确地抓住“新版”的关键片段并排除旧版干扰。

我这里有三条实用经验：一是在文档元数据里做版本标记，切分时把“版本号”和“生效日期”作为属性存进向量库，召回后按时间过滤；二是在每个片段前面加一个“版本前缀”，比如“【2024 版】”、“【2023 版】”，让模型看到上下文整体，降低混淆概率；三是在提示词里写明“优先以文档中标注的最新生效日期为准”。这三条全部用上之后，版本题的通过率能稳定超过三分之二。

5.5 语义泛化弱：同义改写几乎打不动

边界与追问题测试的是“用户不会按文档里的原话提问”这一现实场景。我在这类题上踩的坑最多：用户问“生病了怎么报销”，而文档里写的是“发生意外医疗费用如何处理”，关键词匹配完全失效。这里的核心解决思路是扩充索引，而不是换大模型。

我目前比较稳定的做法是双路召回：一路用向量语义检索，另一路用关键词检索（BM25 这类），两路结果合并重排。向量负责理解“生病=医疗费用”，关键词负责保证“报销”“发票”这种硬词不丢失。合并后发现边界与追问题的正确率提升非常明显，说明语义召回和字面召回并不是替代关系，而是互补关系。

6. 从 46% 到 91%：评估集见证的两轮迭代实录

6.1 第一轮：先救检索，再把切分理顺

这里分享一个真实项目的迭代记录，方便你理解评估集怎么带动优化。我接手某企业内部制度知识库 RAG 的第一版，系统用的是 Ollama 部署的本地模型加简易向量库，第一次跑 20 题评估，总分 46%，其中基础事实题错了一半，跨文档综合题全军覆没。

当时我立刻查看了召回记录，发现 Hit Rate 只有 52%——20 题里只有约 10 题把正确片段召回到了。原因和我预想的一样：切分完全按固定字节数硬切，很多句子被切断，语义碎片化严重。我把切分改为按标题结构切分，并且把 chunk 从 1000 字缩到 400 字左右，重新跑评估，Hit Rate 升到 78%，总分到了 64%。

这轮迭代里我学到的最重要的一件事是：先动检索，再动生成。很多人在系统表现不好时第一反应是换一个大参数模型，但 RAG 的瓶颈通常不在生成，而在于喂给模型的材料不对。20 题评估会告诉你答案，因为分数的变化可以不归因于模型聪明度，而归因于材料质量。

6.2 第二轮：重排与拒答并行改造

第二轮我做了三件事：在 LangChain 流程里加了重排步骤，把召回 Top-50 重排后取 Top-4；重写了提示词，加上了“只依据上下文回答”的限制，并补充了拒答指令；给版本类文档都加了元数据过滤。

改动后重新跑 20 题，总分升到 87%，其中基础事实题全对，跨文档综合题对了 3 题，否定与缺失题对了 3 题。接着我又针对丢分的 3 题逐条分析：一题是版本差异，旧版片段仍然被召回并干扰生成；一题是边界追问，用户问“发票上传后流程卡住”对应的是流程图类文档，纯文本检索没抓到；还有一题是综合题漏掉了福利名目，因为不同福利散落在相距较远的片段里。针对这三个失败点，我继续调了元数据过滤逻辑、加了流程图文档的文本转录、把福利制度合并成单一文档，最终一轮总分 91%。

这个数字当然不能说明系统“完美”，但它至少给了我一个明确的信号：每次改动到底有没有用，哪些能力维度已经稳固，哪些还需要继续投入。我以后的每一次迭代，都会以这个 91% 作为新基线。

7. 零基础快速复制：一个最小的可行评估闭环

7.1 从造题到跑分：五个步骤直接抄

如果你现在手里已经有一个 RAG 系统，但还没有评估集，我的建议是不要追求一开始就做成 20 题标准题库。先用一个最小闭环跑起来，再逐步扩充。

第一步，收集 10 到 20 个真实问题。从你的用户咨询记录、客服聊天、内部提问里找，不要自己凭空编。如果项目还没上线，就找几个同事假装用户来问。

第二步，按五类维度给问题分类，标好参考答案和来源文档。至少保证每一类里有两到三题。

第三步，写一个简单的跑分脚本，一次循环所有问题，把召回片段和生成答案都存下来。

第四步，按 Hit Rate、答案得分、拒答正确率三个指标做统计。这里有一个零基础也能用的办法：把生成结果导出成表格，然后逐个对照参考答案打 0/1/2 分。

第五步，挑出失败案例，回溯召回记录，区分是检索失败还是生成失败，然后对应修切分、修 Top-K、加重排或改提示词。

跑完一轮后，你手里就有了一套清晰的“下次改进清单”，而不是一堆含糊的“感觉哪里不太对”。

7.2 学会维护评估集：加题、更新标准、防止过拟合

评估集不是一次性资产，我一般每个月会过一遍，做两件维护工作。第一，淘汰失效题。知识库更新后，如果答案变化很大，旧题可能不再有区分度。比如制度版本更新后，那道“考勤迟到多久算旷工”的答案就变了，我需要同步更新参考答案卡。第二，补充新题。每次项目里遇到新的失败案例，我都会把它转成一道正式评估题收进题库。所以我的评估集会从 20 题慢慢长到 30 题、40 题，覆盖越来越全。

这里要特别提醒一个坑：评估集不要过度拟合调参。我见过有人为了刷评估分数，专门做规则去迎合那 20 题，结果评估分数涨了，真实用户问题照样稀碎。正确的做法是：评估题必须来自真实问题池的抽样，而不是从测试集里倒推优化。如果你的评估集题量只有 20 道，至少要保证它们是“有代表性的真实问题”，而不是“为了好答而选的问题”。

8. 高频避坑指南与通用排查速查表

这套 20 题评估集我跑了小半年，也帮朋友诊断过几个 RAG 项目，把高频坑整理成了一张速查表，按“现象 → 排查点 → 对策”的路径列出，你遇到问题时可以直接对着来：

再补充几个和评估集本身强相关的经验。第一，评估时不要只看总分，要把 Hit Rate、忠实度、拒答稳定性分开看，因为这三个指标分别对应检索、生成、控制三个不同环节，混在一起会让你无法定位问题。第二，每轮跑完评估之后要留一个“失败快照”，哪怕只是把错误答案复制到一个文档里，都比只记一个分数有用得多。第三，20 题只适合作为起步，当你开始频繁改动系统时，要扩充到 40 到 60 题，否则样本太少，几个随机波动都可能误导你的判断。

最后分享一个我个人很受用的习惯：每次跑完一轮新的 20 题评估，我总会在晚上睡前把所有错误答案按“错因”重新分一次类。看起来像是重复劳动，但归类做多了之后，你会慢慢建立起一种直觉——看到一类问题就知道应该去动检索还是动提示词。这套评估集最大的价值可能不是那个分数，而是它逼着你一遍又一遍地看清楚：你的 RAG 到底是把知识用起来了，还是只是把问题华丽地接住了。