图 1：调优闭环四步走，一次只动一个变量。
聊混合检索的面试题里，混合检索只是「召回」这一个环节的对策。真到项目里 RAG 效果不好，问题可能出在流水线的任何一段。这篇文章把整条流水线摊开，给出一份「症状 → 环节 → 对策」的排查顺序——核心原则一句话：排查顺序就是数据流动的顺序，从前往后逐段对照，改一处、回归一次，再动下一处。
第零步：先分清「材料缺失」和「材料在但没答好」。
动手之前先人工抽查几条坏案例：把用户问题拿去知识库里翻，答案到底在不在库里？不在，那是知识库覆盖问题，加数据、清洗数据才是正解，调任何检索参数都没用；在，才进入下面的流水线排查。很多团队跳过这一步直接调 chunk 大小，方向就错了。
第一站：分块。症状是「答案被一切两半」。
检索回来的块里只有答案的前半句，或者上下文缺主语、表格和表头分家——典型的分块问题。对策是调块大小与重叠：块太小丢上下文，块太大稀释语义还占提示词预算。 LlamaIndex 默认 chunk 1024、重叠 20，这个起点可以调但没有银弹，正确做法是在固定测试集上跑指标对比，而不是凭感觉试。表格、代码这类结构化内容要用结构感知的切分，别一刀切。
第二站：嵌入。症状是「语义相近却召不回」。
换个说法就找不到，同义词、领域黑话全军覆没——嵌入模型和你的领域不匹配。对策是换更强的嵌入模型，或在领域语料上微调。注意一个昂贵的细节：换嵌入模型必须重建整个索引，而且索引和查询必须用同一个模型，这不是热插拔的零件，动它之前先确认分块和召回真的没问题。
第三站：召回。症状是「型号、编号、关键词漏检」。
材料在库里、分块也完整，但纯向量检索就是捞不上来——这就是混合检索的主场：向量路管语义，BM25 关键词路管字面命中，RRF 按名次融合。召回站还有一个旋钮是每路取多少候选（top-k），太小没原料，太大给后面的精排添噪音。
第四站：Rerank。症状是「对的段落排太靠后」。
召回 top-50 里有正确答案，但排在第 30 位，没挤进送给模型的前 5 条——加一道精排。召回用的向量模型是「双塔」打分，快但粗；Rerank 用交叉编码器把查询和候选放在一起逐条细评，慢但准。两者分工明确：召回求全，精排求准。 diversity 类重排还能避免前几条内容高度重复。
第五站：生成。症状是「材料齐全但答非所问」。
对的段落已经摆在提示词里，模型却自由发挥、编造或拒答失当——问题在提示词。对策包括：明确要求「仅根据给定材料回答，材料不足就说不知道」、要求引用来源、给出输出格式约束、控制注入材料的拼接方式（比如把最重要的内容放在首尾而不是中间）。这一站改起来最便宜，所以常被提前乱动——但如果没有先把前四站排除掉，改提示词只是在掩盖上游问题。
图 2：五张症状对策卡挂在流水线对应节点下方，按图索骥。
方法论比任何单点技巧都重要。
两条纪律贯穿始终。其一，一次只动一个变量：同时改块大小又换嵌入模型，效果变了你根本不知道是谁的功劳，而且换嵌入模型还要重建索引，试错成本翻倍。其二，固定测试集回归：准备几十条带标准答案的问答对，每次改动后复测同一批，用指标（命中率、答案正确率）而不是手感说话。RAG 调优的难点从来不是手段不够多，而是手段太多——这份排查顺序的意义就是让你每次都只在一个环节上做实验。
把这张地图和面试题对照着看也有意思：混合检索是召回站的对策，Rerank 是第四站，提示词约束是第五站——一道面试题其实只是整条链上的一个节点。你调 RAG 时踩过最深的坑在哪一站？是分块切坏了答案，还是嵌入模型水土不服？欢迎对号入座。