摘要：本文基于笔者学习 RAG（Retrieval-Augmented Generation）系列课程后的系统性总结，从"为什么需要 RAG"出发，深入拆解提示词过长的性能瓶颈、RAG 标准流程、核心使用原则，以及 Query 改写、Agentic RAG、逆向生成问题等高级检索技巧，最后探讨知识库构建的关键——信息提取与知识切片。无论你是刚接触 RAG 的新手，还是希望在生产环境中优化检索效果的工程师，这篇文章都能提供一条清晰的进阶路径。

一、为什么需要 RAG？——当提示词太长时，大模型"撑不住了"

在实际的大模型应用中，我们经常会遇到这样的场景：把大量的背景文档、历史对话、产品手册一股脑塞进 Prompt，希望模型能基于这些信息给出精准回答。但结果往往事与愿违——模型要么"迷失"在信息中，要么给出前后矛盾的答案。

为什么提示词内容多了，性能反而会下降？核心原因有以下五点：

1. 注意力被稀释（Attention Dilution）

Transformer 架构的自注意力机制虽然能处理长序列，但当输入过长时，每个 token 分配的注意力权重会被严重稀释。关键信息可能因为"淹没"在大量文本中而无法获得足够的注意力资源，导致模型"看不到"重点。

2. "迷失在中间"（Lost in the Middle）

大量研究表明，大模型对位于输入中间位置的信息记忆效果最差，而对开头（primacy effect）和结尾（recency effect）的内容更敏感。当你的关键上下文被夹在长篇文档的中间时，模型提取和利用这些信息的能力会显著下降。

3. 噪声与信号比下降（Noise-to-Signal Ratio Degradation）

输入越长，无关信息（噪声）的绝对量就越大，即使噪声比例不变，模型从海量内容中筛选出真正相关信号的难度也会指数级上升。这就像在嘈杂的菜市场里听清一个人说话——人越多，越困难。

4. 指令冲突与模糊（Instruction Conflict & Ambiguity）

当 Prompt 中混入多个来源的文本时，不同文本的表述风格、术语定义、逻辑结构可能不一致。模型会面临"到底听谁的"的困惑，导致输出质量不稳定，甚至出现自相矛盾的回复。

5. 推理路径变长（Extended Reasoning Chain）

模型需要在更长的上下文中进行推理和关联，这会增加计算复杂度，同时也提高了"走神"的概率。特别是在多步推理任务中，长上下文会让模型在中间的某一步"跑偏"，导致最终答案偏离预期。

结论：当提示词内容过多时，模型性能下降不是偶然，而是由架构特性决定的必然。因此，我们需要一种机制来动态筛选与当前问题最相关的上下文，而不是把所有信息都塞进 Prompt——这就是 RAG 的核心价值。

二、RAG 基础流程：从原始文档到可检索知识

RAG 的标准流程可以概括为三个阶段，但执行顺序有一个关键细节：

原始文档 → [Chunking] → [Embedding] → [Indexing] → 向量数据库 ↑ 用户 Query → [Embedding] → 相似度检索 → Top-K 相关片段

1. Chunking（分块）：知识的最小可检索单元

Chunking 是将原始文档切割成适合检索和嵌入的文本块。这个步骤决定了后续检索的粒度和质量。

• 块太大：包含过多无关信息，噪声增加，检索精度下降
• 块太小：可能丢失上下文语义，导致信息不完整
• 最佳实践：根据内容语义和下游任务需求，选择合适的分块策略（如固定长度、语义边界、递归分块等）

2. Embedding（向量化）：将文本转为语义向量

使用预训练的语言模型（如 BERT、Sentence-BERT、OpenAI 的 text-embedding-3 等）将文本块映射到高维向量空间。语义相近的文本在向量空间中距离更近，这是后续相似度检索的基础。

3. Indexing（索引）：构建高效检索结构

将向量化的文本块存入向量数据库（如 FAISS、Milvus、Pinecone、Weaviate 等），并构建索引结构（如 HNSW、IVF 等）以支持高效的近邻搜索（ANN）。

关键顺序：必须先Chunking再Embedding，最后Indexing。如果先对整个文档 Embedding 再切分，会导致语义向量丢失局部信息；如果先 Indexing 再 Embedding，则索引中存储的是无意义的原始文本。

三、RAG 使用核心原则：一致性是检索质量的基石

原则一：Query 和知识库必须使用相同的 Embedding 算法

这是 RAG 中最容易被忽视、却也最关键的原则。Embedding 模型的训练目标、向量空间分布、语义映射方式各不相同。如果你用模型 A 嵌入知识库，用模型 B 嵌入用户 Query，相当于在两种不同的"坐标系"里做距离计算——检索出来的结果可能完全偏离语义关联。

正确做法：

• 确定一个 Embedding 模型（如text-embedding-3-small、bge-large-zh等）
• 知识库文档和用户 Query 都经过同一个模型编码
• 检索时基于同一向量空间做相似度计算（如余弦相似度）

原则二：Augment Prompt 的正确公式

RAG 的核心不是替代 Prompt，而是增强Prompt。标准的 Augment Prompt 结构如下：

System Prompt（角色/任务定义） + 相关 Context（RAG 检索出的 Top-K 片段） + 用户 Query（原始问题） = Augment Prompt（最终输入给大模型的完整提示）

注意：这里不是简单地把检索结果拼接进去，而是需要结构化组织（如标注来源、分段落、去重等），让模型清楚地知道"哪些信息是背景知识，哪些是需要回答的问题"。

四、RAG 高级技巧：让检索与 Query "双向奔赴"

基础 RAG 能工作，但在生产环境中往往面临一个核心挑战：用户 Query 与知识库文本的语义鸿沟。用户可能用口语化、模糊、甚至与文档表述差异很大的语言提问，导致直接检索的相似度偏低。解决这个问题的思路是"双向奔赴"——既优化 Query，也优化知识库侧的检索策略。

技巧一：Query 改写（Query Rewriting）

用户原始 Query 往往是模糊、口语化的。直接用这样的 Query 去检索，效果有限。Query 改写的核心思想是：用 AI 先把 Query 改得更好、更具体、更明确，降低模糊性后再检索。

常见改写策略：

• 扩写：将简短 Query 扩展为更完整的描述
• 澄清：消除歧义，明确用户真正想问的维度
• 结构化：把自然语言转为更适合检索的"关键词+约束条件"格式

技巧二：Agentic RAG——让 Agent 先规划，再检索

在直接做 RAG 检索之前，先让一个 Agent 对用户的 Query 进行检索规划和判断：

1. 上下文汇总：收集用户的历史对话、当前对话的多轮信息
2. 核心诉求提炼：基于汇总信息，总结出用户的真实意图作为 Query
3. 检索策略判断：决定是否需要检索、检索哪个知识库、检索条件是什么

这种方式尤其适合多轮对话场景——用户的问题往往是上下文依赖的，直接用最后一句话检索会丢失前文的约束条件。

技巧三：逆向生成问题——弥合 Query 与文本的语义差异

当用户 Query 和知识库文本的表述差异很大时，直接检索的相似度会很低。一个巧妙的逆向思路是：

用 AI 扫描知识库文本，输出每个文本片段可能对应的问题。然后用这些 AI 生成的问题去和用户的 Query 做匹配。

这样做的好处是：用户提问的角度千变万化，但针对同一段文本可能提出的问题相对有限。通过"文本→问题"的逆向映射，可以把检索的匹配对象从"文本 vs Query"转变为"问题 vs Query"，后者往往语义更接近，检索效果提升明显。

进一步优化：最好把生成的问题和原始内容一起做成向量存入索引。这样即使某段内容没有被提取出对应的问题，原始内容本身仍然可以被检索到，避免信息遗漏。

五、知识库构建的核心：信息提取与知识切片

RAG 的效果上限，80% 取决于知识库的质量。而知识库构建的关键不在于用了多好的向量数据库或多强的 Embedding 模型，而在于信息提取和知识切片是否基于业务认知做出合理决策。

切片不是切得越小越好，而是切得越"语义完整"越好

一个好的切片应该满足：

• 信息自包含：单个片段内包含完整的语义单元，不需要依赖其他片段就能理解
• 粒度适中：既能精准匹配（不过大），又不丢失关键信息（不过小）
• 边界清晰：切分点选择在语义转换处（如段落、小节、主题切换处），避免把紧密关联的信息切断

实战案例：视频内容的知识切片

假设你有一段视频转文字后的长文本，需要构建知识库。一个可行的策略是：

1. 基于观察确定粒度：分析内容后发现，每个最小颗粒度的知识点不超过 1000 字
2. AI 辅助内容提取：结合大模型能力，让模型对每 1000 字左右的文本进行单知识点的内容提取
3. 生成结构化切片：每个提取出的知识点形成一个独立的文本块，同时保留原文索引以便溯源

关键洞察：切片策略必须基于对业务的深度认知和观察。同样的文本，面向客服问答和面向技术文档的切法完全不同。RAG 工程师最核心的能力，不是调 API，而是理解业务、观察数据、设计合理的知识组织方式。

六、AI 项目落地的启示：左手业务，右手 AI

学习 RAG 的过程中，有一个观点让我印象深刻：

AI 项目组大量的工作不是 Coding，而是梳理、测评、验收。

这句话揭示了一个容易被误解的真相：在 AI 应用项目中，写代码只是实现手段，真正的价值创造在于：

• 梳理：理解业务场景，明确问题边界，设计知识结构和检索策略
• 测评：建立评估体系，量化检索效果（如召回率、准确率、NDCG 等），持续优化
• 验收：定义"好"的标准，确保输出质量符合业务预期，而不是"能跑就行"

这要求从业者具备复合能力：左手懂业务（知道梳理什么、怎么测评），右手懂 AI（知道技术怎么实现、边界在哪里）。只会写代码的工程师，很难做出真正有价值的 RAG 系统；只懂业务的人，又无法把想法落地。两者的结合，才是 AI 项目的核心竞争力。

七、总结

RAG 看似简单——切分、向量化、检索、拼接——但要真正做好，需要在每一个环节中注入对业务和数据的深刻理解。希望这篇文章能为你在 RAG 的实践中提供一份清晰的路标。