第 14 章 RAG 的基础架构¶

RAG 常被描述成“检索增强生成”，但从工程视角看，它不是一句口号，而是一条完整的数据和推理链路。只要这条链路中某一环设计得不好，最终模型输出就会受影响。本章按基础流程拆开 RAG：文档进入、切分、索引、检索、重排和注入。

14.1 文档进入系统¶

RAG 的起点不是检索，而是 ingestion，也就是资料如何进入知识系统。文档格式、清洗质量、元数据完整性和版本管理，都会影响后续召回效果。很多检索问题，根源其实在文档进入阶段。

切分决定检索单元。切得太粗，召回噪声高；切得太细，语义上下文被破坏。一个好的 chunk 策略通常要在语义完整性、召回精度和索引规模之间做平衡，而不是机械按固定长度切。

文档切好之后，需要进入可检索结构。常见做法是 embedding 向量索引，也可能配合关键词索引、元数据过滤或结构化字段。索引阶段的关键是：你到底希望系统按什么维度找到知识。

flowchart LR
    A["资料入库"] --> B["清洗与切分"]
    B --> C["索引构建"]
    C --> D["候选检索"]
    D --> E["重排筛选"]
    E --> F["上下文注入"]
    F --> G["模型生成"]

检索是从候选集中找可能相关的片段，重排则是把更适合当前问题的内容往前提。很多系统停在“向量搜 top-k”，但在复杂场景中，不加重排往往会出现错召回和无关信息前置的问题。

检索结果不是直接等于可用知识。进入模型前，系统仍然需要决定：

RAG 的最后一环其实又回到了 Context Engineering：知识只有被正确装配进上下文，才真正对模型有用。

RAG 不是“搜一下再喂给模型”这么简单，而是一条从文档进入、切分、索引、检索、重排到上下文注入的完整链路。任何一环都可能成为效果瓶颈。下一章会进一步讨论这些环节里的核心取舍：应该怎样在召回率、精度、延迟和成本之间做平衡。