RAG 系统全链路实践：从文档切分、向量检索到增强生成

检索增强生成（Retrieval Augmented Generation，RAG）是当前大模型落地应用最广泛的架构之一。它的核心思想并不复杂：不重新训练模型，而是把相关信息"临时塞进"提示词，让模型基于外部资料作答。这套机制有效缓解了三个大模型原生痛点——训练数据过时、私有知识缺失、生成内容幻觉。但把 RAG 从"能用"做到"好用"，中间隔着大量工程细节：文档怎么切、向量怎么存、检索怎么排、答案怎么验。本文沿着 RAG 的完整流水线逐层拆解，每层都给出实践经验和踩坑教训。

一、RAG 的工作流全景

一个标准的 RAG 流程包含四个环节：

1. 文档预处理：加载文档、清洗、切分为适合检索的文本块，并向量化后存入向量数据库——这一步离线完成，只需做一次。
2. 2. 查询向量化：用户提问时，用与文档相同的嵌入模型把问题转为向量。
3. 3. 相似度检索：在向量库中找出与问题向量最接近的若干文本块。
4. 4. 增强生成：把检索到的文本块与用户问题拼装成增强提示词，交给模型生成带依据的答案。
      理解这套流程的关键在于认识到：RAG 的准确性上限由检索质量决定。检索不到相关文档，后面模型再强也白搭；检索质量上去了，生成环节才能发挥价值。所以工程重心应该放在检索链路上。

二、文档切分：最容易忽视却最影响质量的一步

文本切分决定检索粒度和语义完整性，是新手最常踩坑的地方。切得太粗，一个块里混着多个主题，检索召回的块相关度被稀释；切得太细，语义被截断，模型拿到的是残缺信息。

经验法则：

• 通用场景：chunk_size = 800，chunk_overlap = 150，重叠区保证跨块语义不断裂。
• • 代码文档：按函数、类等逻辑边界切，而不是纯按字符数。
• • Markdown：按标题层级切，天然保持章节完整性。
• • 长表格：单独处理，避免被切得支离破碎。
    进阶技巧是按语义边界切：用模型判断句子之间的语义转折点来定切分位置，成本高但质量明显更好。另一个常被忽略的点是块内补充元数据——记录块的来源文档、章节标题、页码，检索结果能溯源，也支持按文档过滤。

三、向量化与向量数据库选型

嵌入模型的选择直接影响检索效果。核心原则是：文档与查询必须使用同一个嵌入模型，且同一模型在不同语言的向量空间分布不同，中英文混合场景要选多语言模型。目前主流的嵌入模型在语义相似度上已相当可靠，选型时用自己领域的数据集实测对比，比看榜单更靠谱。

向量数据库的选择取决于规模与预算：

• 小规模原型：FAISS、Chroma 足够，轻量且免费。
• • 百万级生产：Milvus、Qdrant、Weaviate 等专业向量库，支持分布式和过滤能力。
• • 已有 PostgreSQL/Elasticsearch 的团队：优先用 pgvector、Elasticsearch 的向量能力，减少组件数量。
    存储层面还有两个优化点：一是增量更新，文档变更时只重新索引变更部分而不是全量重建；二是按权限过滤，多租户场景用元数据过滤让不同用户只能检索到自己的文档，这在大模型应用中常被忽视，却是合规的刚需。

四、检索：从单一向量到多路融合

只做向量相似度检索，会遇到两类典型问题：精确关键词（型号、编号、人名）命中率差，以及检索结果相关度不够精准。工程上通用的解法是混合检索加融合排序。

混合检索：同时执行向量检索（抓语义）和关键词检索（抓精确匹配），再把两路结果融合。BM25 是关键词检索的经典算法，对"稀缺精确词"的召回能力远强于纯向量。融合最简单有效的方式是 RRF（Reciprocal Rank Fusion）：对每路结果的排名取倒数分数求和，综合排序。它不需要调权重、对分数分布不敏感，是实践中最稳的融合手段。

重排序（Rerank）：检索阶段为了召回率通常取几十个候选块，但全塞进提示词既费 token 又稀释注意力。重排模型对"文档块-问题"对做精细相关度打分，只保留 Top 3 到 5 个最相关的块进入生成环节。重排带来的效果提升往往比换更大的模型更明显，是性价比最高的单点优化。

查询改写：用户的问题通常口语化、指代不清，直接把原始问题拿去检索效果有限。可以先让模型把问题改写为更清晰的检索查询，甚至拆分为多个子查询分别检索再合并结果。多路召回 + 重排 + 查询改写的组合，是生产级 RAG 检索链路的标配。

五、增强生成：把资料正确地喂给模型

检索结果进入生成环节，提示词的结构直接影响答案质量。要点如下：

• 明确指令：告诉模型"只基于提供的资料回答，资料中没有的信息要明确说不知道"——这是压制幻觉的最有效手段。
• • 保留引用：让模型在回答中标出依据来源（如 [1][2]），方便用户核验，也大幅提升可信度。
• • 控制上下文：只塞重排后的 Top-K 块，块与块之间用清晰分隔符，避免模型混淆不同来源。
• • 温度调低：生成阶段设 0 到 0.3，保证答案稳定。
    一个常见的错误是让模型"总结全部资料"——那是 Summarization 任务而非 QA 任务，两者提示词设计完全不同。QA 任务的重心是精准定位与忠实转述，不是泛泛概括。

六、评估：RAG 系统持续迭代的根基

没有评估体系的 RAG 系统，优化全靠玄学。建议从两个维度建立评估：

检索质量：指标是召回率与命中率——对测试问题，检索出的 Top-K 块里是否包含真正能回答问题的文档。这个指标可以在不调模型的情况下单独优化，反馈快、成本低。

生成质量：指标包括忠实度（答案是否完全基于检索资料，有没有编造）、相关性（答案是否切题）、完整性（是否覆盖问题所有要点）。现代做法是用强模型做自动裁判（LLM-as-a-judge），对"答案-资料-问题"三元组打分，替代人工标注，让评估可以规模化执行。

评估数据集的建设是长期工程：从真实用户日志里挑典型问题，人工标注标准答案与参考文档，持续扩充。有了这套数据，每次改动（换切分策略、换嵌入模型、加重排）都能量化对比，RAG 系统才能真正进入良性迭代。

七、进阶方向：超越朴素 RAG

基础的"检索-拼接-生成"流水线之上，还有几条明确的进化路径：

Agentic RAG：把检索做成智能体可调用的工具，让模型自主决定是否需要检索、检索几次、要不要修正查询。复杂问题不再一次性检索，而是多轮探索式获取信息，适合分析型、多跳型问题。

结构化知识增强：纯文本块的检索对"多约束条件"问题力不从心（比如"找 2024 年发表、作者是 X、主题是 Y 的论文"）。进阶方案是把文档抽取为知识图谱，把查询转化为子图匹配，用结构化证据支撑答案——这是 IJCAI 2026 上 MC-RAG 系统等最新研究的方向，代表 RAG 从"语义相似度匹配"走向"结构化约束满足"。

引用验证闭环：让答案的每条断言都能回溯到具体文档块，甚至加一个独立的"事实核查"环节，对模型输出逐条验证是否被检索资料支持，不支持的主动修正。

RAG 的价值在于把大模型的生成能力与私有数据的准确性结合，成本远低于微调且效果可控。把本文梳理的每一层——切分、向量化、检索、生成、评估——都做到位，一个可信赖的企业级知识问答系统就立住了。这也正是当前绝大多数知识库产品背后的真实工程图景。