知识库问答上线后最常卡在两个地方：一是答错了说不清错在检索还是生成，二是老板问「现在效果好不好」时拿不出数字。这篇按进料、检索、生成三段拆开讲原理，重点放在怎么建评测集、怎么打分、怎么把评测接进日常迭代，让每次改分块或换模型都能验证到底有没有变好。
知识库问答上线以后，团队最常卡在两个地方：答错了说不清是检索没捞到还是模型没写好，老板问效果怎么样时又拿不出一个能看的数。这篇把 RAG 从进料到生成拆成几段讲清楚，重点放在怎么建评测集、怎么打分、怎么把评测塞进日常改动流程里，让每次调分块或换模型都能验证到底有没有变好。
需要先说明的是，这套方法针对的是「靠外部资料查事实」的知识服务。如果你的资料总量很小，直接整段塞进上下文反而更省事；如果你的目标只是让模型换一种说话风格、学一种输出格式，那该走的是提示词或微调，不是 RAG。判断标准很简单：答案对不对取决于「资料里有没有这条事实」，才轮到 RAG 上场。
一条 RAG 请求到底经过了哪几段
把一条请求拆开看，依次经过进料清洗、切片与向量化、召回与重排、拼装提示词、生成五段。这么拆不是为了画架构图好看，而是因为每段出错的表现完全不同：进料脏了会答出过期或矛盾的版本，切片切坏了会把一句话劈成两半，召回没捞到就是干脆答非所问，拼装和生成出问题则表现为答案里有原文没提过的内容。定位顺序永远是先看召回片段，再怀疑模型。
| 链路段落 | 典型故障表现 | 先查什么 |
|---|---|---|
| 进料清洗 | 答案里出现已被删除的旧条款 | 源文档去重、更新时间是否同步 |
| 切片与向量化 | 答一半就断、上下文接不上 | 切片长度、重叠比例、是否切断表格 |
| 召回与重排 | 问的问题资料里明明有却答不出 | 命中片段排名、召回条数够不够 |
| 拼装与生成 | 答案带了原文没有的细节 | 提示词是否要求只用给定材料作答 |
什么情况下不该用 RAG：资料量小到能整段放进上下文；或者你要的是模型学会一种新的表达风格，而不是查某条事实。这两种情况硬上 RAG，只会多一层检索噪音。各家嵌入模型和向量库的能力口径会变，想横向核对，到 /models 看当时整理的条目，别拿半年前听来的说法当准。
评测集怎么建才算有用
评测集最容易犯的错是自己坐在工位上编题，编出来的题又干净又标准，跟真实用户的问法差很远。正确做法是从真实问题里抽，尤其是客服工单、群聊里被反复问的那种。起步不用贪多，先攒五十到一百条，每条都能对上一个标准答案和出处，就足够支撑日常迭代了。
- 按类型分层：事实查找、多跳拼合、否定与边界、资料里根本没有的问题，各占一定比例。
- 最后一类专测它会不会硬编，资料里没有就该说没有，这是最容易被忽略也最伤信任的一档。
- 每条样本记录四样：问题原文、期望命中的原文片段、可接受的答案要点、必须拒答的情况。
- 标注分工要定死：熟悉业务的人定标准答案，算法同学只定格式，避免两边标准打架。
样本量到多少算够，取决于你的问题类型有多分散。经验判断是：如果新增二十条样本，正确率波动还超过几个点，说明样本太少或类型没盖全，这时候的分数字不能用来做上线决策。具体怎么抽样、怎么分档，站内评测与质量检测工具页通常有当时的口径说明，先对齐再动手。
打分看哪几个数，别只盯一个总分
只报一个「准确率」是最省事也最没用的做法，因为它涨跌了你也知道该往哪改。建议拆成两层看：第一层是召回命中率，也就是该捞到的原文片段有没有进到前几名；第二层才是答案正确率。第一层不过关，后面那层数字没有意义，改提示词也救不回来。
- 召回命中率
- 标准答案对应的原文片段有没有出现在传给模型的那几条里，不进就别看下一层。
- 答案正确率
- 在召回过关的前提下，生成内容是否覆盖了答案要点，且没有编造。
- 拒答准确率
- 资料里确实没有时，它是老实说没有，还是硬凑一个看起来像的答案。
- 耗时与花费
- 单次问答的时间与成本，答得对但每次慢到用户跑掉、贵到用不起，都不算过关。
人工评分建议用二值加理由，也就是对或错，再写一句为什么，别用五分制。五分制听着精细，实际上几个评委之间很难对齐，两个人给同一条打的分能差两档，最后谁也没法拿这个数做决策。有分歧的样本单独挑出来复盘，往往能暴露出一条模糊的验收标准，这比多标一百条更值。
把评测接进日常改动流程
评测集建好以后放着不跑，等于没建。真正有用的是把它变成一份固定回归集，每次动切片长度、换嵌入模型、调提示词，都跑同一套题，只看涨跌不看绝对分数。这样你改一个参数，至少知道它是把哪几类问题改好了、哪几类改坏了。
- 先记基线动任何东西之前，用当前线上配置跑一遍回归集，把每条的通过情况存下来，否则后面涨了跌了都说不清。
- 一次只变一个变量切片长度和嵌入模型一起换，就算结果变好你也不知道是谁的功劳，等于白跑一轮。
- 线上挂低成本监控记录问题、召回片段编号、最终答案和耗时，按周抽样人工看，发现新类型问题就回流进评测集。
- 明显退化先回滚别在生产上边查边改，先切回上一个已经验证过的配置，把用户影响止住，再慢慢定位根因。
如果你同时接了好几条外部服务，想确认当前用的是哪家的哪条链路、花了多少，到 /price-watch 核对当时的数字，别凭印象估。评测这件事没有一劳永逸的终点，问题类型会随着用户用法变化，评测集也要跟着长。
下一步先去站内评测与质量检测工具页对照口径，确认你现有的评测集有没有覆盖拒答那一档，再决定要不要补样本。→常见问题
没有标注团队，小团队怎么快速做评测？
不用一开始就做全量标注。先让两三个人各自写下最常被问的二十个问题，标出答案要点和出处，凑出一份几十条的固定集就能用。关键是每次都跑同一份，让改动可比。后面再按错误类型慢慢补题，别等标注做完才上线。
RAG 效果不好，先改检索还是先换模型？
先看召回。把该命中的原文片段检查一遍，如果压根没进候选，换再强的生成模型也没用，先查切片粒度、嵌入模型和关键词召回。如果片段进了但答案还是错，再去看提示词里怎么组织资料、要不要加约束，最后才考虑换模型。
拒答率太高或者太低怎么办？
拒答太高通常是召回阈值卡太严或切片没覆盖到，先把该命中的片段捞回来；拒答太低说明提示词没给「资料里没有就说不知道」的约束，模型会自己编。两类都调完，还要拿资料里根本没有的问题单独测一轮，别只看正常问题。
