RAG（检索增强生成）应用的问答质量，往往先受检索链路限制，再受模型能力影响。知识库内容即使足够丰富，如果解析阶段混入页眉页脚，分块切断了表格或步骤，召回阶段又只依赖一种相似度，模型拿到的上下文仍可能不完整。
因此，搭建 RAG 不宜从“换一个更大的模型”开始，而应把数据处理、召回、排序和生成拆开观察。本文给出一条适合个人开发者和小团队的工程化路径：先把文档变成可检索的数据，再用向量检索与关键词检索互补，最后用重排序压缩送入模型的上下文，并根据问题类型调整参数。
先建立一张完整的 RAG 流程图
一条可维护的 RAG 链路通常包括：
- 文档解析与清洗：从 PDF、Word、PPT、网页或数据库中提取文本、标题、表格和元数据，去掉重复页眉、页脚、水印和无意义空白。
- 分块与索引：按照标题、段落、列表或语义边界切分文本，为每个分块保留文档名、章节、页码、更新时间等元数据，并分别建立向量索引和关键词索引。
- 查询处理：接收用户问题，必要时做改写、关键词抽取或过滤条件识别。
- 多路召回：用向量检索匹配语义相近内容，用 BM25 等关键词检索命中特定术语、编号、错误码和产品型号。
- 融合与重排序：把不同检索器的候选集合合并，再用 Reranker 按“问题—文本”的联合相关性排序。
- 生成与引用：只把经过筛选的上下文交给大模型，并要求回答区分资料中的事实与无法确认的内容。
这张流程图的价值在于定位问题：答案缺少某个事实，可能是解析或分块丢了内容；召回了很多相似但不适用的段落，可能是检索或排序问题；上下文正确而答案仍然偏离，才需要继续检查提示词、模型和生成参数。
文档解析：先保证“可读”，再追求“可搜”
原始文件不是天然适合检索的数据。解析时建议保留结构，而不是简单把所有页面拼接成一段字符串：
- 标题层级应转成明确的章节路径，便于后续按主题检索和展示来源；
- 表格应保留行列关系，必要时转换为“字段：值”的文本或独立记录；
- 代码、命令、配置项和错误信息应尽量保持原样，避免清洗器误删符号；
- 页眉、页脚、目录重复项、扫描乱码和推广内容应在入库前处理；
- 每个分块都应携带来源文件、章节、页码或 URL、更新时间等元数据。
对扫描 PDF、图片表格等内容，还要把 OCR 结果作为待校验数据。可以抽样检查标题、数字、版本号和命令是否被识别正确。若底层文本已经错误，后续再精调 Embedding 或 Reranker 也无法弥补。
Chunk 怎么切：从语义边界和评测结果出发
分块没有适用于所有资料的固定字符数。过大的分块携带了更多上下文，但会降低命中精度并增加生成成本；过小的分块容易命中关键词，却可能失去限定条件、步骤顺序和表格上下文。
可以按以下顺序设计：
- 优先按标题、段落、列表和代码块切分，避免在句子或操作步骤中间硬切；
- 对产品手册、故障排查和参数表使用较小分块，确保一个问题的关键字段尽量集中；
- 对流程说明、方案分析和长逻辑内容使用较大分块，必要时保留父章节摘要；
- 采用少量重叠保留跨段上下文，但不要让同一内容大量重复进入候选集；
- 将分块大小、重叠长度和 Top-K 都当作待评测参数，而不是直接套用固定模板。
实际调优时，准备一组包含“答案所在段落”“相似干扰段落”和“必须命中的术语”的测试问题，分别观察召回率、排名位置、上下文长度和最终答案正确性。这样比凭感觉修改 chunk size 更可靠。
为什么采用向量检索和 BM25 双路召回
向量检索适合处理同义改写和自然语言表达。例如用户问“服务器无法连接数据库怎么排查”，它有机会匹配到“应用侧连接超时的诊断步骤”。但对于版本号、错误码、类名、产品型号和专有名词，关键词检索通常更直接。
BM25 这类词法检索会利用词项出现情况和文档长度等信息进行相关性计算，适合精确命中；向量检索则通过 Embedding 表示语义关系。两路结果不必强行转换为同一分数，可以先分别取候选，再使用排名融合方法合并。一个常见做法是 Reciprocal Rank Fusion（RRF）：同一文档在多个结果列表中出现时获得更高的综合排名。
query
├─ 向量检索：召回语义相近的候选
├─ BM25：召回术语、编号和关键词匹配的候选
└─ RRF/加权融合：合并候选并去重
↓
Reranker
↓
送入大模型融合权重应由问题类型决定。自然语言问答可以让向量结果占更大比重；错误码、配置项和合同条款查询则应提高关键词检索的影响。不要只看最终答案，还应记录每个候选来自哪一路、融合前后的排名，以及被过滤的原因。
重排序：把“能召回”变成“值得提供”
多路召回的目标是尽量不漏掉相关内容，因此候选集里通常会有相似但不够准确的文本。Reranker 接收用户问题和候选分块，重新判断两者的匹配程度，再选出较少的上下文交给生成模型。它与只分别编码问题和文本的 Embedding 检索承担不同职责：前者更适合大规模粗筛，后者适合在较小候选集上精排。
一个可落地的起点是：先从两路检索得到几十条以内的候选，融合去重后交给 Reranker，再保留少量高相关结果。具体数量需要结合文档长度、模型上下文窗口、延迟和成本测试；如果候选过少，召回率可能下降，如果候选过多，重排序延迟和噪声都会上升。
当 Reranker 分数低于业务阈值时，不要强行生成答案。可以返回“资料中未找到足够依据”，或引导用户缩小问题范围。这比把低相关文本交给模型后得到一段看似流畅的猜测更安全。
按业务场景选择初始方案
通用知识问答
适合产品文档、内部知识库和帮助中心。采用结构化解析、按章节分块、向量为主的双路召回，再使用轻量重排序。重点观察口语问题能否命中正确章节，以及答案是否引用了过期版本。
精准参数和故障码查询
适合配置参数、错误码、版本兼容性和规章条款。分块要围绕字段和条件组织，BM25 可以提高术语命中率，向量检索负责补充自然语言表达。展示答案时应同时输出来源章节和版本时间。
流程和长逻辑分析
适合部署流程、架构方案和排障手册。应尽量保留步骤顺序与父章节关系，必要时把相邻分块或章节摘要一起送入重排序。评测重点不是只命中一句话，而是能否覆盖完整前置条件和后续动作。
上线前的评测与运维清单
RAG 调优应形成可回归的测试集，至少覆盖：
- 直接问法、同义改写、口语问法和带错别字的问法；
- 术语、编号、版本号、日期和数字等精确匹配问题；
- 需要跨多个章节组合信息的问题；
- 知识库没有答案时的拒答问题；
- 文档更新、删除和权限变化后的版本问题。
同时记录解析失败率、分块数量、各路召回命中率、融合后的排名、Reranker 延迟、输入 Token 数、拒答率和人工抽检结果。数据进入云端后，还要把原始文件、解析任务、索引版本和访问权限分开管理；对象存储适合保存原文件与中间产物，向量库和关键词索引则应支持按版本重建，避免更新文档时直接覆盖而无法回滚。
结语
RAG 的核心不是把文档向量化后接上一个大模型，而是建立一条从数据质量到生成结果都可观测的检索链路。先清洗和结构化文档，再依据语义边界分块；用向量检索覆盖表达差异，用 BM25 保留术语和编号的精确性；通过融合扩大候选范围，再用重排序压缩噪声，最后才把有限上下文交给模型。
如果问答效果不稳定，建议按“解析 → 分块 → 召回 → 融合 → 重排 → 生成”的顺序逐层排查，并用固定测试集验证每一次改动。这样既能控制云上推理和存储成本，也能让 RAG 应用从一次性演示逐步走向可维护的生产系统。