RAG知识库搭建技术要点与检索优化策略

很多团队做 RAG（检索增强生成）的时候，往往会走完全一样的弯路：找个现成的开源框架，把几十份 PDF 文件一股脑切成 500 字符的块，塞进向量数据库，配个开源 Embedding 模型，最后直接把检索出来的文本塞给大模型。在本地跑 Demo 时看起来挺好，但一上线就会被用户吐槽。用户搜一个具体的零件编号、报错代码或者年份，大模型就开始胡说八道；问一个跨章节的对比问题，系统找出来的全是毫不相干的内容。

做生产级 RAG 知识库，真正的难点从来不在最后调大模型的那一行 API 代码上，而在前面的数据清洗、切分颗粒度、混合检索与重排。如果前面召回的上下文本身就是残缺或者错误的，后面给模型配再好的 Prompt 也无济于事。

一、 数据预处理：垃圾进，垃圾出

很多系统检索不准，根源根本不在检索算法，而在第一步解析文档时就把内容弄丢了。

第一步：丢掉粗暴的文本提取工具。 如果知识库里有大量扫描件、双栏排版 PDF 或复杂表格，直接用基础的 `pypdf` 抽取，文字顺序经常是错乱的，表格内容会直接变成无法理解的一串乱码。在实际项目中，针对复杂排版，建议先使用专门的版面分析工具（如 Marker、MinerU 或基于视觉的版面分析模型）将原始文件转为干净的 Markdown。

第二步：保留结构层级与元数据。 纯文本会丢失文档的标题从属关系。一段正文如果没有“第一章 > 第二节 > 计费规则”这种父级标题做约束，向量化之后它的语义就会变得模糊。在解析时必须将文档路径、章节层级、更新时间、文件类型等字段作为 Metadata（元数据）附加到每一个切片上。检索时先通过元数据做硬过滤（比如限定只查“2024年产品手册”），能直接排除掉大半无关内容。

二、 切分策略（Chunking）：别搞一刀切

很多新手最常问的问题是：切块长度到底设 256 还是 512？实际上不存在一个放之四海而皆准的数字。块切得太小，会丢失上下文；块切得太大，会引入太多噪音，把大模型的注意力搞混，而且大幅增加 Token 开销。

为了搞清楚不同切分方式的差异，可以参考下面这个常见方案选型对比：

在真实业务中，最稳妥也最推荐的是父子块检索（Small-to-Big）模式。操作步骤如下：

1.先切大块（Parent Chunk）：以 800 到 1200 个 Token 为单位切分，或者直接按 Markdown 的三级标题进行段落划分，保证这一块讲的是一个完整的话题。

2.再切小块（Child Chunk）：在大块内部切出 150 到 200 个 Token 的子切片。

3.只对子块做向量化和检索。

4.检索命中子块后，通过关联 ID 追溯并取出它对应的父块内容，将完整的父块内容放进 Prompt 喂给大模型。这样既保证了检索的敏锐度，又保全了完整的上下文逻辑。

三、 检索优化：单靠向量检索一定会翻车

很多人把向量检索当成万能钥匙。但向量模型的本质是语义相近，它对数字、专有名词、精确型号极不敏感。例如用户检索“错误码 ERR-40401”，向量检索很可能召回“错误码 ERR-40402”，因为在向量空间里这两个词长得太像了。

必须引入混合检索（Hybrid Search）：向量检索 + 关键词检索（BM25）。

•密集向量检索（Dense Retrieval）：负责兜底。处理同义词、意图匹配、长句描述。例如用户输入“怎么注销账号”，能匹配到“用户账户注销流程”。

•稀疏关键词检索（Sparse / BM25）：负责精准命中。处理专有名词、手机型号、人名、错误码。

执行混合检索时，不能简单把两边的余弦相似度分数相加，因为两种算法的分数分布完全不在一个维度上。推荐使用倒数排名融合（Reciprocal Rank Fusion, RRF）算法来合并两边的候选列表。

RRF 的核心逻辑非常简单：它不看具体的分数，只看两个通道给出的排名。计算公式是：

$$RRF_Score = sum frac{1}{k + rank_i}$$

在工业界实践中，常数 $k$ 通常默认设置为 60。这个参数能平滑各通道排名的权重差距，防止某个通道的第一名独占所有注意力。

四、 重排阶段（Rerank）：决定准确率的关键一步

混合检索做完后，我们通常能拿到 20 到 50 个候选切片。如果把这些全部塞给大模型，不仅花钱多、响应慢，还会触发大模型的“迷失在中间”（Lost in the Middle）现象——模型往往只注意最前面和最后面的内容，忽略中间的核心依据。

这时候必须接入 Cross-Encoder 架构的重排模型（Reranker）。

向量检索用的双塔模型（Bi-Encoder）为了速度，把问题和文档分开编码，牺牲了交互细节。而重排模型把问题和候选文本拼在一起输入进去，进行全注意力交叉计算，打分精度要高得多。

下面是两阶段检索的具体参数和延迟参考：

操作避坑提示：重排模型的算力消耗比向量检索大很多。千万不要把几百个切片直接扔进重排模型，这会导致接口耗时直接飙到数秒。合理的做法是：混合检索召回 30 个，重排后只截取打分高于设定阈值（比如分数大于 0.6）的前 3 到 5 个切片输出给生成模型。

五、 查询优化与生成防护

用户输入的问题往往不是完美的搜索语句，尤其是多轮对话场景下，用户经常使用代词，比如“那第二个呢？”、“怎么收费？”。

1.Query 改写（Query Rewrite）：在检索前，先调用一个响应速度快的小模型，结合历史 2 到 3 轮对话，把用户的追问还原成独立完整的句子。比如把“那怎么收费？”改成“某某软件的企业版收费标准是什么？”。

2.严格的拒答机制：很多时候检索结果的分数普遍偏低，说明知识库里根本没有收录对应答案。在 Prompt 里必须严格限定模型行为：“请仅依据以下提供的参考资料回答问题。如果参考资料中没有明确说明，请直接回答‘知识库中未包含相关信息’，严禁自行推测。” 同时，在代码层如果重排后的最高分低于预设的最低置信度阈值，直接阻断大模型生成，走预设的兜底客服兜底话术。

搭建一个高可用 RAG 系统的本质，就是一条严谨的漏斗流水线：用结构化清洗保证输入质量，用父子切分兼顾粒度与语义，用混合检索把召回率拉满，再用重排模型把精度锁死。把这几个环节的基础打扎实，知识库的回答准确度就会得到根本性的改善。