结论：RAG 的瓶颈几乎从不在生成端，而在检索端。检索没捞到正确内容，再强的模型也只能编。检索工程是一个独立的、需要专门优化的系统。

一、分块（Chunking）决定上限

• 固定字数硬切会截断语义，是最常见的低质来源。

• 按结构切（标题、段落、代码块）优于按字数切。

• 块要"语义完整 + 足够小"：太大稀释，太小丢上下文。适度重叠（overlap）可缓解边界断裂。

• 给每块附元数据（来源、时间、章节），供过滤与引用。

二、混合检索优于单一向量

• 纯向量擅长语义相似，弱于精确匹配（型号、错误码、专有名词）。

• 关键词检索（BM25 类）擅长精确命中，弱于语义泛化。

• 实践：向量 + 关键词双路召回，再合并去重，覆盖面明显更广。

三、重排（Rerank）提升精度

初筛召回可以多，但进入上下文必须精。用重排模型对候选做二次排序，只把 top-k 交给生成端。召回追求"不漏"，重排追求"排对"，分工明确。

四、查询改写

用户问题常口语化、缺指代。先做查询扩展/改写（补全上下文、生成多个查询变体），再检索，命中率通常显著提升。

五、评估检索而非只看最终答案

要单独度量：召回率（该捞的捞到没）、精度（捞到的相关性）、排序质量。只看最终答案好坏，无法定位"是检索的锅还是生成的锅"（呼应 Evals 的分层思想）。

六、常见误区

• 只调生成模型不动检索；固定字数切块；只做向量不做关键词；召回直接全塞上下文不重排；不做检索评估；块无元数据导致引用不可溯。

七、检查单

• [ ] 分块按语义结构，带少量重叠

• [ ] 每块附来源与时间等元数据

• [ ] 向量 + 关键词混合召回

• [ ] 有重排环节，控制进入上下文的量

• [ ] 有查询改写与扩展

• [ ] 单独度量召回率、精度、排序质量

• [ ] 检索为空时明确告知模型，禁止脑补

• [ ] 答案可溯源到具体块