RAG（检索增强生成）让AI Agent先从知识库检索资料再回答问题，是解决大模型幻觉和知识过时问题的主流方案。本文拆解其核心链路：文档切分、向量化、检索、重排序与生成五个环节的技术要点。

· 两大痛点：大模型的幻觉问题（编造事实）和知识时效问题（训练数据有截止日期），RAG通过外挂知识库同时缓解

· 核心链路五环节：文档加载与切分→Embedding向量化→向量数据库存储→相似度检索→上下文增强生成

· 检索质量决定回答质量：切分策略、Chunk大小、Top-K值、重排序模型是四个关键调优点

· 企业级价值：私有数据不出内网即可被大模型利用，兼顾数据安全与知识时效

· 与微调的分工：RAG管"知道什么"，微调管"怎么表达"，多数企业场景先做RAG

大模型为什么会一本正经地胡说八道？

用过ChatGPT类产品的人大多遇到过这样的场景：问一个公司内部规章或最新行业数据，模型回答得头头是道，细看却是编的。这就是幻觉（Hallucination）——大模型基于概率生成文本，当训练数据中缺少对应知识时，它会生成"看起来合理"而非"事实正确"的内容。

幻觉之外还有第二个痛点：知识时效性。模型的训练数据有截止日期，企业内部文档、产品手册、最新政策它天然不知道。让模型"重新学一遍"这些知识，成本高、周期长，而且文档一更新就要再来一次。

RAG（Retrieval-Augmented Generation，检索增强生成）正是针对这两个问题的方案：不改模型本身，而是在回答前先从外部知识库检索相关资料，把资料作为上下文交给模型，让它基于给定材料作答。这相当于给模型配了一个"开卷考试"的环境——答案来自检索到的原文，幻觉率大幅下降，知识库更新后立即生效。

RAG的核心链路：从文档到回答的五个环节

一个完整的RAG系统由离线索引和在线问答两条链路组成，共五个环节：

环节一：文档加载与切分（Chunking）。企业知识库的文档形态多样——PDF、Word、网页、数据库记录。系统首先将文档解析为纯文本，再切分成若干 Chunk（文本块）。切分不是越细越好：块太小会丢失上下文语义，块太大则检索粒度粗糙，实践中常见设置在200~800字符之间，并保留10%~20%的重叠（Overlap）避免语义在边界处断裂。

环节二：向量化（Embedding）。Embedding模型（嵌入模型，把文本转成高维向量的模型）将每个文本块编码为一个数百维的向量。语义相近的文本，其向量在空间中的距离也相近——"退货政策"和"退换货流程"的向量会非常接近，尽管字面只有部分重合。

环节三：向量数据库存储。向量被存入专门的向量数据库（如Milvus、Chroma、FAISS、Qdrant）。这类数据库支持ANN（近似最近邻）检索，能在亿级向量中毫秒级找到与查询最相似的若干条记录。

环节四：检索与重排序。用户提问被同样编码为向量，在数据库中检索Top-K条最相似的文本块。许多系统会在这一步之后追加一个重排序（Rerank）模型，对粗筛结果做精细排序，把最相关的块排在最前面，直接决定送入模型的内容质量。

环节五：上下文增强生成。系统将检索到的文本块与用户问题组装成提示词（Prompt），格式通常是"基于以下参考资料回答问题"，交给大模型生成最终回答。这样模型的任务从"凭记忆作答"变成"阅读理解"，可靠性质变。

决定RAG效果的关键参数：切分、Top-K与重排序

同样一套知识库，不同工程配置的效果可能天差地别。四个高频调优点值得重点关注：

切分策略。固定长度切分是最简单的方案，但对表格、代码、分级标题文档效果差。更好的做法是按结构切分——尊重Markdown标题层级、保留表格完整性。技术文档建议按"标题+段落"切，法律合同建议按"条款"切。

Top-K值。检索返回的文本块数量。K太小可能漏掉关键信息，太大则稀释上下文、增加Token成本。经验起点是K=3~5，配合后续重排序再裁剪。

检索方式组合。纯向量检索擅长语义匹配，但遇到专业术语、产品编号这类精确查询时，关键词检索（BM25算法，基于词频的经典检索算法）反而更准。生产系统普遍采用混合检索（Hybrid Search）：向量检索召回语义相关内容，关键词检索兜住精确匹配，两路结果合并后重排序。

Query改写。用户的原始提问往往口语化、缺主语，直接拿去检索命中率低。在检索前加一步"查询改写"——让小模型把"那个报销流程是啥"改写成"差旅费报销审批流程及所需材料"——是低成本高回报的优化。

AI Agent与RAG的结合：从问答到行动

单独的RAG是一个被动的问答管道；接入Agent架构后，RAG变成Agent可调用的一个工具（Tool），能力边界显著扩展。

在Agent框架（如LangChain、LlamaIndex）中，RAG通常被封装成Retriever工具。Agent收到用户问题后，可以自主决定：是直接调用知识库检索，还是先追问澄清，或者结合其他工具（数据库查询、API调用）交叉验证。这就是Agentic RAG的基本形态——检索不再是固定流程，而成为Agent决策链路中的一环。

典型的进阶模式有三种：多轮检索，Agent发现首轮检索结果不足以回答时，自动改写查询再检索一轮；路由式检索，系统有多个知识库（产品库、制度库、技术库）时，Agent先判断问题属于哪个域，再定向检索；溯源式回答，生成回答时附带引用来源，让用户可以点开原文验证。这三种模式在客服机器人、企业知识助手、技术文档问答等场景中已广泛应用。

RAG还是微调？企业落地的选型逻辑

企业想让大模型掌握私有知识，技术路线主要有RAG和微调（Fine-tuning，用自有数据继续训练模型）两条，二者的定位不同：

RAG解决"知道什么"的问题——知识放在外部库里，随时更新、可溯源、数据不出内网；微调解决"怎么表达"的问题——让模型学会特定的语气、格式、领域推理方式。一句话选型逻辑：知识频繁变化、要求可溯源、数据敏感的场景优先RAG；输出风格和推理模式固定的场景才考虑微调。两者也可以叠加：先RAG保证知识正确，再微调优化表达风格。

对企业开发者的落地建议是：从RAG起步，用真实用户问题持续评测（检索命中率、回答准确率），再决定是否需要微调。切忌一开始就微调——那是回报周期最长、试错成本最高的路线。

常见问题

RAG和直接把文档塞进提示词有什么区别？

直接塞提示词（长上下文方案）在文档量小时可行，但存在三个瓶颈：一是成本，每次请求都携带全部文档，Token消耗随文档量线性增长；二是性能，上下文过长时模型对中部内容的注意力会下降（"迷失在中间"现象）；三是时效，文档更新需要重新处理。RAG通过检索只取出最相关的几个块，成本可控、规模可扩展，是知识库规模超过几十页后的标准方案。

向量数据库应该怎么选？

按场景选：原型验证阶段用轻量方案（如Chroma，嵌入式数据库，pip安装即用）；生产环境中小规模（千万级向量以下）可选Qdrant、Weaviate；超大规模或需要分布式部署选Milvus；已有Elasticsearch或PostgreSQL技术栈的团队，可以直接用它们的向量检索扩展（pgvector），减少运维成本。选型时重点评测召回率、延迟和过滤查询能力三个指标。

RAG能完全消除大模型的幻觉吗？

不能完全消除，但能显著降低。RAG把回答依据从模型记忆变成检索材料，对"知识型幻觉"（模型不知道却编造）效果最好。但如果检索不到相关内容，模型仍可能强行作答。工程上的兜底手段是：在提示词中明确要求"资料中没有就回答不知道"，并设置检索相似度阈值——低于阈值时直接拒答或转人工。

零基础学习者入门RAG需要哪些前置知识？

三块基础：Python基础（能写函数和调用API）、对大模型API调用方式的基本了解、向量相似度概念的直观理解（余弦相似度）。有了这三块，就可以用LangChain或LlamaIndex这类框架的现成组件，在几天内搭建一个本地知识库问答原型，再在实践中逐步深入切分策略、混合检索、重排序等进阶主题。