部署 RAG 系统后，紧接着就要面对一个现实问题：它答得好不好？哪里容易出错？怎么调才能明显提升效果？本节提供一套轻量、可操作的验证与调优方法，帮助你在一两个工作日内定位主要瓶颈，而不必陷入复杂的评估框架。
12.6.1 准备“探针问题集”
调优的第一步，是有一组能反映真实业务需求、覆盖不同难度的探针问题。不必追求数量，几十条精选问题远比几百条随意凑数的问题更有效。建议问题集包含三类：
- 事实查询型：答案明确存在于某份文档中，例如“年假天数是多少？”这类问题考察检索能否精准命中。
- 需综合归纳型：答案分散在多个片段，需要模型整合信息，例如“员工离职需要办理哪些手续？”考察检索的覆盖度和生成的整合能力。
- 边界与拒答型：询问知识库中不存在的内容，例如“公司是否提供租房补贴？”（实际未包含相关文档）。考察系统是否触发“无法回答”策略，而非编造。
同时，为每道题预先标记好“标准答案片段”和大致答案要点，作为后续验证的参照。
12.6.2 快速验证的核心维度
不要追求面面俱到的量化指标，重点观察四个维度，就能定位绝大多数问题：
1. 检索命中率
- 怎么测：对每条探针问题，检查返回的 top‑3（或 top‑5）片段中，是否包含预期答案所在段落。
- 判定方法：手工比对，或粗略计算“答案片段是否出现在检索结果中”。命中率低，说明问题在索引、切分或嵌入模型环节。
- 常见病因：文档切分过碎导致信息断裂、嵌入模型对领域术语理解不够、知识库缺少关键文档。
2. 答案事实准确性
- 怎么测：直接阅读模型生成答案，与标准答案片段对比，标记是否有事实错误、遗漏关键信息、或自行添加不存在的内容。
- 判定方法：可粗略分为“完全正确”“部分偏差”“明显错误”三档。
- 常见病因：检索到的片段本身就不完整、提示词未充分约束模型“仅依赖资料”、模型过于自由发挥。
3. 溯源标注情况
- 怎么测：检查回答中是否按预期附上了来源（如文档名、章节号），以及来源是否与所用片段吻合。
- 判定方法：统计成功标注来源的比例。即便答案正确但未标注，也是需要修正的合规问题。
- 常见病因：提示词未明确要求引用格式、检索时未携带元数据、后处理逻辑缺失。
4. 拒答行为
- 怎么测：用知识库外问题提问，观察系统是否直接回复类似“未找到相关信息”的标准话术，而不是胡编。
- 判定方法：统计无相关文档时，模型编造答案的比例。理想状况下这一比例应为零。
- 常见病因：未设置相关性阈值过滤、提示词未告知模型在信息不足时可以拒绝回答。
12.6.3 调优的优先级路径
根据验证结果，按“哪里最差先调哪里”的原则进行优化，避免同时改动多个环节导致无法归因。推荐以下顺序：
第一阶段：确保检索稳定（效果基底）
- 调整切分策略：如果检索命中率低，尝试增大 chunk 尺寸（如从 256 token 扩至 512 token）让上下文更完整，或增加重叠区避免关键句被一刀切断。对于结构化文档（如表格、条文），考虑按段落或条目切分，而非固定字数。
- 优化嵌入模型：如果领域术语多（如法律、医药），可评估换用在该领域表现更好的嵌入模型，或对高频术语建立同义词映射，在索引时扩展关键词。
- 清洗知识库：去除重复、过时、矛盾的内容，避免多个版本共存导致检索分散。
- 调整检索参数：增大 top‑k 召回数（例如从 3 增至 5），观察是否覆盖到正确答案，但要留意冗余信息对生成的干扰。
第二阶段：提升答案质量（生成端）
- 重写提示词：如果发现模型经常忽略资料瞎编，强化提示词约束，例如加入：“请严格基于以下资料回答问题，资料未提及的内容一律不要补充。如果资料不足以回答，请明确说明‘现有资料未覆盖’。”
- 控制模型温度：调低温度参数（如 0.1~0.3）减少随机性，让生成更确定性，减少“发挥”。
- 增加输出格式要求：明确要求分点作答、末尾附来源，既抑制长篇大论中的走偏，也更便于比对验证。
第三阶段：完善拒答与溯源（安全兜底）
- 设置相关性阈值：在检索后对召回片段的相关度分数做过滤，低于阈值的片段直接丢弃。若过滤后无剩余片段，直接返回预设的“抱歉，未找到相关信息”话术。
- 统一溯源格式：在提示词中固定来源引用的写法，如“【来源：{文档名} – 第{章节}节】”，并在后处理中检测该格式是否存在，缺失时预警。
12.6.4 极简验证流水线示例
假设你已有一套探针问题（20条），按以下步骤操作，半天即可完成一轮验证：
- 把问题逐条输入系统，保存每次的检索片段和最终回答。
- 用表格记录每条问题的四个维度结果（命中是/否，答案准确性等级，是否有溯源，是否不当拒答/编造）。
- 统计出问题最多的维度，如果是“检索命中率低”，则去检查对应问题的文档是否入库、切片如何；如果是“事实准确性差”，则对比检索到的片段和答案，看偏差来自检索内容不足还是模型表述。
- 根据统计结果集中调整 1~2 个参数或重写提示词，再次跑一遍问题集，对比效果变化。
一个真实案例：某团队在初次验证时发现 30% 的问题回答都在胡编，进一步检查发现是提示词中缺少“只能依据资料”的强制性语句，模型在信息不足时会自由发挥。补上这条约束后，编造率降至 2%。另一次问题则出在检索阶段——产品型号等信息由于切分时被截断，导致检索总是差一点命中。将切片从小段落改为以产品条目为单位后，检索命中率从 60% 提升至 95% 以上。
12.6.5 持续监控的轻量做法
调优不是一劳永逸，知识库更新或模型变更都可能引起效果波动。建议建立一个“袖珍回归集”：从探针问题中保留 10~15 条最核心、最有代表性的问题，每次知识库大更新或系统调整后，快速重跑一次这四个维度的检查。这能在几分钟内给你充分的信心：系统“至少还能处理好最重要的那些事”。
通过这种“探针驱动、四维观察、逐层优化”的方式，你可以在不投入过多资源的前提下，让 RAG 系统的效果快速收敛到可用水平，并为后续精细化迭代打下清晰的基础。