别被简单的向量检索骗了，生产环境下的 RAG 优化得这么做

很多刚接触 RAG（检索增强生成）的开发者，最容易掉进“Demo 陷阱”。在跑通最简单的流程——将文档 Embedding 后存入向量数据库，再由 LLM 回答——时，一切看起来都很完美。但只要把这个系统推向生产环境，面对真实用户的多样化查询，检索质量往往会断崖式下跌。

最核心的问题在于，单纯依赖向量检索（Vector Search）在处理特定场景时极其不精准。向量检索本质上是在计算高维空间的余弦相似度，它擅长捕捉“语义相近”的内容，但面对具体的产品型号、专业术语或特定的人名时，它经常会失效。比如用户搜索一个具体的型号“X-100-Pro”，向量检索可能会因为语义相近而给你返回一堆“X-200”或“Pro 系列”的文档，而无法实现精准匹配。

要解决这个问题，不能寄希望于更换一个更强的 LLM，因为如果召回环节（Retrieval）就拿到了错误的信息，模型无论怎么推理也只能产生“一本正经的胡说八道”。目前最稳妥的生产级方案是构建一套混合检索（Hybrid Search）架构，并引入重排序（Rerank）机制。

具体的落地逻辑可以分为三个阶段。首先是“初步召回”：不要只依赖向量库，而是同时启动两路检索。一路走传统的 BM25 关键词检索，确保精准匹配的词项能被抓到；另一路走向量检索，负责捕捉语义关联。在这个阶段，为了保证后续有足够的筛选空间，建议每路检索分别拉回前 50 个候选片段。

第二阶段是“权重融合”。由于关键词检索的分数（TF-IDF 逻辑）和向量检索的分数（余弦相似度）不在一个量级，不能直接相加。这里需要用到 RRF（Reciprocal Rank Fusion）算法。RRF 的核心逻辑是不看具体分数，只看排名。通过一个简单的倒数求和公式，将两路结果合并并重新打分，从而在保留语义能力的同时，给精准匹配的文档更高的权重。

第三阶段则是最关键的“精排过滤”。即便经过 RRF 融合，Top 20 的结果中依然可能包含噪音。此时需要引入一个专门的 Reranker 模型（例如 BGE-Reranker）。与 Embedding 模型不同，Reranker 是交叉编码器（Cross-Encoder），它会同时输入查询词和文档片段进行深度比对。将合并后的 Top 20 喂给 Reranker 进行二次打分，最后只截取相关度最高的前 5 个片段喂给 LLM。

虽然这种架构增加了请求的端到端延迟，但它能极大地缓解 LLM 的幻觉问题。

除了检索链路，文档切片（Chunking）的策略也决定了 RAG 的上限。很多初学者习惯使用固定长度切分（比如每 500 字一段），这会导致严重的语义断裂——关键信息可能正好被切在了两个片段之间，导致检索时无法获取完整上下文。建议尝试基于文档结构的递归切分（Recursive Character Text Splitter），优先按照段落、句子进行切分，尽量保持语义单元的完整性。

总结来说，如果你发现 RAG 系统回答得不对，先不要急着升级模型，建议先检查召回环节的命中率。在生产环境中，一个“关键词+向量+Rerank”的组合拳，远比单纯追求一个超大参数量的 LLM 要有效得多。