大语言模型虽强但在实际业务应用中仍需RAG技术。本文深入解析RAG核心思想即结合模型内部参数化知识与外部非参数化知识解决大模型知识时效性、私有性、幻觉等问题。文章详细拆解RAG工作流程涵盖文档处理、向量检索、上下文构建等关键环节并探讨混合检索、Chunking策略、Rerank优化等实用技巧。此外本文还分析了RAG优化方法、评估体系构建以及从传统RAG到Agentic RAG的进阶路径为初学者提供系统化学习路线助力高效掌握大模型应用开发。最近几年大语言模型LLM的发展速度有目共睹。从最初的文本生成、问答交互到如今的工具调用、复杂推理以及自主执行任务大模型的能力边界正在不断扩展。但真正动手开发 LLM 应用时我们往往会遇到一个看似矛盾的问题模型越来越强为什么实际业务中仍然需要 RAG比如我们希望开发一个能够回答企业内部问题的智能助手。公司的知识分散在 PDF、Word、Markdown 和数据库中涉及产品文档、技术手册、业务规范以及不断更新的内部制度。如果直接把问题交给大模型它可能回答得头头是道但仔细核对之后就会发现有些内容早已过时有些信息根本不存在还有些答案虽然看起来合理却找不到任何依据。这时候我们自然会想到既然模型不知道能不能先把相关资料找出来再让它回答这就是 RAGRetrieval-Augmented Generation检索增强生成最直观的思想。不过理解这句话和真正掌握 RAG完全是两回事。一个最简单的 RAG Demo可能几十行代码就能实现。但要把它做成一个检索准确、回答可靠、成本可控的实际应用背后涉及的问题远比想象中复杂。这篇文章我们就从最基础的原理出发逐步拆解 RAG 的完整工作流程并讨论几个在实际开发中非常值得思考的问题。一、为什么有了大模型还需要 RAG先看大模型本身。我们知道LLM 通过大规模预训练将大量语言规律、事实知识和任务模式编码到模型参数中。这种知识通常被称为Parametric Knowledge参数化知识。你可以简单理解为模型通过训练把一部分知识“记”在了参数里。但问题在于模型参数并不是一个可以随时更新、精确查询的数据库。假设我们向模型提出一个问题“公司最新的差旅报销标准是什么”对于这样的问题模型可能面临几个困难。首先模型并不知道企业内部的私有知识。公司的制度、合同、会议纪要等信息通常没有进入模型的训练数据。如果没有外部信息模型自然无法保证回答准确。其次模型的知识存在时效性。即使模型在训练时接触过某项政策也不意味着它知道最新版本。对于经常变化的业务知识仅依赖模型参数显然不够。再者大模型可能产生幻觉Hallucination。LLM 的生成机制并不等同于事实查询。它可以生成语言上合理、逻辑上连贯却与真实情况不符的内容。尤其是在缺少必要知识时模型可能用已有知识进行补全而不是明确告诉用户“无法确定”。最后还有一个经常被忽略的问题答案从哪里来对于日常聊天我们未必需要追溯每一句话的来源。但对于企业知识库、法律法规或技术文档问答来源往往与答案本身同样重要。我们不仅希望模型告诉我们答案还希望知道它依据的是哪份文档、哪个版本、哪一段内容。这几个问题正是 RAG 希望缓解的核心痛点。1.1 RAG 的核心思想RAG 最早由 Lewis 等人在 2020 年的论文Retrieval-Augmented Generation for Knowledge-Intensive NLP Tasks中系统提出。论文的一个重要思想是将模型内部的参数化知识与外部的非参数化知识Non-parametric Knowledge结合起来。所谓非参数化知识可以理解为存储在外部知识库中的信息不需要通过修改模型参数来更新。具体来说当用户提出问题时系统先从外部知识库检索相关资料再将这些资料作为上下文交给大模型最后由模型生成答案。例如用户问题“2026 年员工出差住宿费用的报销上限是多少”RAG 系统首先检索相关制度文档找到类似的内容“根据 2026 年差旅管理办法一线城市普通员工住宿费用上限为每晚 500 元。”随后将这段资料与用户问题一起交给 LLM。模型不必依靠参数知识猜测报销标准而是可以根据检索结果组织答案并提供原始文档引用。看起来只是增加了一次检索但这个变化非常关键。我们不再要求模型记住所有知识而是让它在需要时访问知识。这也是理解 RAG 的第一步。需要注意的是RAG 并不能彻底消除幻觉。检索内容可能不准确模型也可能误解资料甚至生成没有依据的结论。它只是让答案有机会建立在外部证据之上并为进一步验证提供基础。二、RAG 的本质让知识存储与语言生成解耦在深入技术细节之前我觉得有必要先建立一个更重要的认识RAG 不只是给大模型增加一个搜索功能而是将知识管理与语言生成分离。在传统的 LLM 使用方式中知识主要存在于模型参数中。要改变模型掌握的知识通常需要借助模型更新、微调或者重新提供上下文。RAG 则引入了另一种思路。知识由外部系统负责存储、组织、更新和检索大模型负责理解问题、利用证据以及生成自然语言答案。两者各司其职。为了更直观地理解我们可以把 RAG 看成一个开卷考试系统。大模型相当于参加考试的学生外部知识库相当于允许查阅的资料。学生本身具备阅读、理解和推理能力但不需要提前背下资料里的所有细节。当遇到问题时先找到相关章节再结合已有能力组织答案。当然资料找错了答案仍然可能出错即使资料正确理解和推理也不一定完全正确。因此RAG 的效果取决于两个基础能力能否找到正确的知识以及能否正确使用找到的知识。用一个简化的数学表达可以将 RAG 建模为给定用户问题 (q) 和外部知识库 (D)检索器先获取相关证据随后生成模型根据问题和检索结果生成答案这是常见工程 RAG 的抽象并不是原始论文中所有 RAG 变体的完整概率定义。但它已经说明一个重要事实RAG 的输出质量不只取决于 LLM还依赖知识库、检索器以及上下文构建方式。有时候模型回答错误并不是因为模型不够聪明而是它从一开始就没有拿到正确的信息。三、拆开 RAG一条完整的工程链路理解 RAG 的定义并不难真正需要掌握的是它的内部工作流程。一个典型的 RAG 系统可以分成两个部分离线阶段Offline把原始文档处理成可检索的知识。在线阶段Online根据用户问题检索知识并生成答案。3.1 离线阶段让文档变得可检索离线阶段可以概括为文档加载 → 数据清洗 → 文档切片 → Embedding → 索引存储第一步是文档加载Document Loading。在真实场景中知识可能来自 PDF、Word、Markdown、网页或者数据库。这些资料的格式差异很大。尤其是 PDF文本内容可能包含复杂的双栏排版、表格、公式和图片。如果文档解析阶段把内容顺序弄错后续即使采用最先进的 Embedding 模型也很难挽回。举个简单例子。假设原始文档中有这样一张表员工级别住宿报销上限普通员工500 元部门经理700 元高级管理人员1000 元如果解析之后员工级别与对应金额的关系丢失那么检索系统就无法可靠地回答具体问题。这说明了一件事文档解析不是简单的格式转换而是在尽可能保留原始知识的结构和语义。第二步是文档清洗。我们通常需要清理重复的页眉页脚、乱码、无关格式信息同时尽可能保留文档标题、章节层级、表格关系等内容。第三步是文档切片Chunking。这是 RAG 中一个非常值得深入研究的环节。为什么不能直接把整篇文档存进去假设一份技术文档有 100 页而用户只想知道某个 API 的超时参数。如果每次检索都返回整篇文档不仅会浪费大量上下文还可能让真正有用的内容淹没在其他信息中。因此我们需要把文档拆分成若干较小的片段也就是 Chunk。但 Chunk 并不是越小越好。假设有这样一段内容“员工连续出差超过 7 天时可以申请额外住宿补贴。补贴金额按照实际出差城市等级确定。”如果恰好从中间切开一个 Chunk 可能只剩下“可以申请额外住宿补贴”另一个只包含“按照实际出差城市等级确定”。两个片段单独看都缺少必要条件。这会直接影响后续检索与生成。因此Chunking 的本质并不是机械地按字符数截断文本而是在检索粒度和语义完整性之间寻找平衡。第四步是向量化Embedding。Embedding 模型会把文本映射到一个高维向量空间让语义相关的文本在向量表示上具有一定的相似性。例如“员工住宿费报销标准是多少”与“差旅管理办法中的酒店住宿费用上限”虽然字面表达不同但语义比较接近因此理想情况下它们的 Embedding 也应该比较接近。常见的向量相似度计算方法是余弦相似度余弦相似度越高通常意味着向量方向越接近。但这里要特别注意向量相似度高不等于文档一定包含正确答案。Embedding 捕捉的是经过训练学到的语义关系而不是严格的事实一致性。另外查询和文档向量必须来自兼容的表示空间。最简单的方式是使用同一个 Embedding 模型对于采用不同查询和文档编码器的双塔模型则应使用其官方匹配的编码方式。完成向量化后就可以将向量、文本片段和元数据建立索引。常见的向量检索方案包括 FAISS、Chroma、Milvus 和 Qdrant。需要区分的是FAISS 主要是向量相似度搜索库而 Chroma、Milvus、Qdrant 等提供了更完整的向量数据管理能力。至此我们才真正完成知识库的初步构建。3.2 在线阶段从用户问题到最终答案在线阶段是用户实际感知到的部分。通常包括用户提问 → Query 处理 → 检索召回 → Rerank → Context 构建 → LLM 生成假设用户问“上海分公司的住宿报销标准是什么”首先系统需要理解 Query。在简单场景中可以直接将原始问题向量化。但用户提问往往比较口语化也可能存在上下文依赖。例如“那上海呢”如果缺少前面的对话信息检索器根本不知道用户具体在问什么。这时候就需要进行 Query Rewrite查询改写把问题还原为“上海分公司的住宿费用报销上限是多少”随后进入检索阶段。系统根据查询向量从知识库中找出相似度最高的一批候选 Chunk。但这里有一个关键问题召回的结果并不一定是最适合用来回答问题的结果。因此实际工程中经常会增加 Rerank重排序步骤。Rerank 模型会对 Query 和候选文档之间的相关性进行更精细的判断然后重新排序。最后系统选出一小部分质量较高的文档片段与原始问题一起组织成 Prompt交给生成模型。生成模型根据这些上下文给出答案并尽可能标注引用来源。这样RAG 的完整链路就跑通了。不过到这里为止我们得到的仍然只是一个基础 RAG 系统。真正值得研究的问题才刚刚开始。四、为什么 RAG 的检索结果经常不准确实际开发中经常会遇到这样的情况知识库中明明存在答案系统却没有检索出来。甚至有时检索出来的文档看起来很相关最终回答却完全不对。我认为理解这类问题比背诵 RAG 的完整流程更重要。因为这直接决定了我们能否真正调试和优化一个 RAG 系统。4.1 语义相似不等于事实相关向量检索擅长识别文本之间的语义联系但它并不天然擅长所有精确匹配问题。比如用户查询“产品 AX-1200 的最大并发连接数是多少”知识库中有两份文档AAX-1200 产品技术手册BAX-900 产品技术手册两份文档在内容结构、术语和技术描述上可能高度相似。如果只依赖语义相似度系统就可能检索到错误型号。类似问题还包括合同编号、错误代码、设备序列号和特定人名。这些信息的特点是语义相似性并不重要精确匹配反而更加关键。这就引出了混合检索Hybrid Search。一种常见方案是同时使用Dense Retrieval基于 Embedding 的语义检索。Sparse Retrieval基于 BM25 等方法的关键词检索。两种方法各有所长。向量检索擅长处理不同表达方式之间的语义联系关键词检索更适合产品型号、专有名词、精确术语等场景。实际系统可以通过 Reciprocal Rank FusionRRF融合两路结果。其典型形式为这种方法不要求不同检索器的原始分数处于相同尺度而是利用排名信息完成融合。它并不保证永远优于单路检索但对于混合了语义查询和精确术语查询的知识库通常值得作为一个重要的对照方案。4.2 Chunk 太小和太大都会出问题前面已经提到 Chunking但这里可以再深入一点。较小的 Chunk 通常更容易聚焦具体语义适合精准定位答案。问题在于它可能破坏上下文之间的联系。较大的 Chunk 能保留更多完整信息但也会引入无关内容降低检索粒度并占用更多 Context。于是就产生了一个经典矛盾检索时希望知识片段足够小生成时又希望知识上下文足够完整。一种常见的解决方案是 Parent-Child Retrieval父子块检索。它把文档分成两层。索引阶段使用较小的 Child Chunk提高检索粒度。当某个 Child Chunk 被命中时系统不直接把它交给 LLM而是找到对应的 Parent Chunk提供更完整的上下文。例如用户查询某个 API 的参数说明。检索时只需要定位到参数定义所在的小段落但生成答案时可能还需要同时提供这个 API 的使用条件、返回值和异常说明。父子块检索正是试图解决这种需求。不过它也有额外代价父块更长可能占用更多 Token还需要合理处理多个子块命中同一个父块的问题。所以Chunking 没有放之四海而皆准的最佳参数。具体选择需要结合文档结构、问题类型、上下文长度和实际评估结果。4.3 Rerank 不是万能的很多初学者在检索效果不好时第一反应就是增加 Rerank。这个想法并不总是正确。我们需要区分两个问题第一个是Recall召回即正确证据有没有出现在候选结果中。第二个是Ranking排序即正确证据出现以后有没有排在足够靠前的位置。Rerank 擅长解决第二个问题但无法凭空创造没有被召回的候选文档。如果正确答案根本没有进入候选集合那么无论 Rerank 模型多强都无法从错误的候选中找出正确证据。所以RAG 优化需要遵循一个基本顺序先保证正确证据能够被找到再考虑如何将它排到前面。这也是我认为新手需要建立的一个重要工程意识不要遇到效果差就盲目叠加组件而是先定位瓶颈。五、一个容易忽略的问题检索得越多回答就越好吗直觉上给大模型提供更多资料似乎就能让它做出更准确的判断。但实际情况并没有这么简单。2024 年发表在 TACL 的论文Lost in the Middle: How Language Models Use Long Contexts研究了语言模型利用长上下文信息的能力。研究发现在其测试的多文档问答和信息检索任务中当关键证据位于长上下文的中间位置时模型性能往往会明显下降。相比之下关键证据位于上下文开头或结尾时模型通常表现更好。这一现象也被称为 Lost in the Middle。它揭示了一个有趣的事实模型能够接收很长的上下文并不意味着它能够同样有效地利用其中的每一部分。这对 RAG 尤其重要。假设系统检索到了 20 个 Chunk其中只有 3 个真正与用户问题有关。如果我们把 20 个 Chunk 全部塞进 Prompt不仅会增加推理成本还可能让模型受到无关内容干扰。即使其中确实包含正确答案也未必能保证模型准确识别和使用。因此RAG 的上下文构建不应该只是简单的文本拼接。它还需要考虑证据的相关性、完整性、冗余程度以及最终输入模型的顺序。从这个角度看Rerank、Context Compression上下文压缩和去重并不只是成本优化手段也是提高上下文信噪比的方法。这里还可以联系到一个更大的概念Context Engineering上下文工程。在传统的 Prompt Engineering 中我们主要关注如何写好指令。但在真实的 LLM 应用中模型最终接收到的上下文不仅包括提示词还可能包含对话历史、检索文档、工具结果和系统状态。这些信息应该如果查询中包含大量产品编号或专有名词向量检索经常召回错误文档那么可以优先尝试混合检索。如果正确文档已经出现在候选列表中但经常排名靠后那么可以考虑增加 Rerank。如果检索结果只包含部分信息导致模型无法理解完整条件那么可以调整 Chunking或者尝试父子块检索。如果用户问题本身非常模糊或者依赖前面对话的上下文那么可以优先考虑 Query Rewrite。这样每一次优化都有明确的目标。下面这张表可以作为调试 RAG 时的参考。观察到的问题优先排查方向正确文档没有被召回Chunking、Embedding、混合检索产品编号、术语匹配错误BM25、精确匹配、元数据过滤正确文档排名靠后Rerank、融合策略证据被切断信息不完整父子块检索、结构化切片用户提问模糊或有上下文依赖Query Rewrite检索正确但回答错误Context 构建、Prompt、生成模型上下文过长延迟和成本偏高去重、压缩、动态 Top-K这里有一个我特别想强调的观点优化 RAG 并不等于不断增加技术组件而是根据失败原因选择成本最低且有效的解决办法。有时候调整文档解析方式比更换一个参数量更大的模型更有效。有时候增加一个简单的元数据过滤条件就能解决大量错误召回。甚至在某些场景下直接使用关键词检索就已经足够完全不需要复杂的向量检索架构。技术方案应该服务于问题而不是反过来。七、如何判断一个 RAG 系统到底好不好很多人完成 RAG Demo 后会随机提出几个问题观察模型回答是否流畅。如果答案看起来不错就认为系统效果很好。但这种评价方式很容易产生误判。原因很简单模型即使没有找到正确证据也可能生成一段看起来合理的回答。因此RAG 的评估不能只检查最终答案还应该拆开整个链路。我认为可以从三个层面理解。7.1 检索层正确证据有没有找到最直接的指标是 RecallK。假设某个问题有 4 个相关文档片段系统在前 5 个检索结果中找到了其中 3 个那么RecallK 可以衡量检索器对相关证据的覆盖情况。但它无法单独描述排序质量。例如正确证据位于第 1 名和第 5 名可能对最终答案产生不同影响。因此还可以结合 MRRMean Reciprocal Rank、nDCG 等指标评估排序质量。需要注意相关证据的标注粒度也很重要。对于简单事实问答可以标注包含答案的文档片段对于多跳问题可能需要标注多组必要证据而不是只标记一个 Chunk。7.2 生成层答案是否真正依据检索证据即使检索器找到了正确内容大模型依然可能产生错误回答。比如检索结果写的是“普通员工住宿上限为 500 元。”最终答案却写成“普通员工住宿费用可以报销 600 元。”这显然不是检索阶段的问题而是生成阶段没有忠实使用证据。因此可以评估 Faithfulness忠实度即答案中的事实性陈述是否有检索上下文支持。另一个重要维度是 Answer Relevance答案相关性也就是最终回答是否真正回应了用户的问题。需要注意忠实度高并不必然意味着答案正确。如果知识库中的内容本身错误或过时模型完全忠实于这些资料仍可能给出错误答案。因此对于要求较高的场景最好同时检查答案正确性、证据来源和引用对应关系。7.3 系统层质量之外还有成本和延迟RAG 不只是一个 NLP 算法问题也是一个工程系统问题。一个复杂方案可能带来更好的答案质量但同时增加多次检索、Rerank 和 LLM 调用。对于高并发应用这些额外开销可能并不容易接受。因此还需要关注请求延迟尤其是 P95 延迟Token 消耗与单次请求成本检索和生成阶段的失败率知识库更新与索引同步情况来源引用的准确性这里可以参考 RAGAS 等自动化评估框架对检索与生成过程进行多维度评价。但自动化评估也存在局限尤其当使用 LLM-as-a-Judge 时评价模型本身可能产生偏差。所以对于业务关键场景仍然需要保留人工标注或可验证的测试集。从工程角度看我更认可一种做法建立固定测试集记录每次优化前后的指标变化同时保留请求日志和检索结果。这样当系统效果下降时我们才能判断问题出在数据、检索、重排还是生成阶段。没有评估体系的 RAG 优化很容易变成凭感觉调参。八、从传统 RAG 到 Agentic RAG为什么检索开始需要决策能力到这里我们讨论的主要还是传统 RAG。它的基本思路是用户提问系统检索一次或按照预设规则检索若干次然后由 LLM 生成答案。这种方式对于企业 FAQ、产品说明书问答等场景通常比较合适。但如果问题本身很复杂呢例如“请对比 2025 年和 2026 年两版差旅报销制度找出上海分公司的特殊规定并判断哪些历史订单可能受到影响。”这个问题显然不是简单的一次相似度检索就能解决的。它至少涉及几个不同任务先找到两个年份的制度文件然后识别修改条款再检索上海分公司的补充规定最后关联历史订单数据。而且在执行过程中后续查询可能依赖前一步获得的新信息。这时固定的检索流水线就可能显得不够灵活。于是出现了 Agentic RAG。Agentic RAG 可以理解为在 RAG 系统中引入基于任务状态的动态决策使模型能够根据需要选择检索工具、拆分问题、评估证据必要时继续检索。它不再简单地遵循固定的“检索一次然后生成”流程。而是允许系统根据中间结果调整执行过程。例如第一次检索发现只有 2026 年政策缺少 2025 年的版本。系统可以继续查询历史文档库而不是直接开始生成答案。找到两个版本后系统再判断是否有足够证据进行比较。如果还缺少上海分公司的特殊规定就进一步检索指定地区的制度文档。直到关键证据足够或者达到检索预算上限再决定生成答案还是说明信息不足。这个变化与 Agent 中常见的规划、工具调用和反馈机制密切相关。Self-RAG、Corrective RAGCRAG和 Adaptive-RAG 等研究也从不同角度探索了按需检索、自我评估以及根据问题复杂度调整检索策略。不过需要说明的是这些方法的具体机制并不相同也不能全部直接等同于 Agentic RAG。它们体现的是一种共同趋势检索正在从固定执行步骤逐步演变为可以根据任务需求动态调整的过程。但这不意味着 Agentic RAG 一定比传统 RAG 更好。动态决策会引入额外的模型调用、工具执行、状态管理和错误恢复成本。如果一个问题通过单次检索就能找到答案增加复杂的 Agent 循环未必有意义。反而可能带来更高延迟甚至因为不必要的检索步骤引入新的错误。因此我更倾向于将它们看成两种适用于不同复杂度任务的系统设计。对于简单问题使用轻量、稳定的固定 RAG。对于需要多跳检索、多数据源访问以及动态证据验证的任务再考虑引入 Agentic RAG。系统越复杂越需要考虑收益是否足以覆盖额外成本。九、从 Demo 到生产环境还有哪些问题如果只是为了学习 RAG运行一个本地向量检索 Demo 已经足够。但在真实业务中至少还有几个问题不能忽略。首先是知识更新。RAG 的一个优势是可以独立更新外部知识库但这不意味着修改源文件后所有索引都会自动保持一致。文档被修改、删除或替换时系统需要同步维护对应索引。对于有版本管理需求的知识库还要区分“最新版本”与“指定历史版本”避免检索到已经失效的制度。其次是访问权限。企业内部不同员工可能只能访问部分文档。如果系统把所有文档都放入同一个知识库却没有严格的权限控制那么用户可能通过自然语言提问检索到无权访问的信息。因此权限过滤不能只依赖 Prompt 中的一句“不要泄露敏感信息”。它应该落实到检索和数据访问层确保进入模型上下文的内容本身就是经过授权的。再次是安全问题。外部文档不一定完全可信。如果文档中包含恶意指令试图让模型忽略原有要求、输出敏感信息或者调用危险工具那么系统可能受到 Prompt Injection提示词注入影响。对于普通问答系统风险可能主要表现为回答被污染。但对于拥有工具调用能力的 Agentic RAG问题可能更加严重因为模型输出可能进一步触发真实操作。最后是可观测性。一个可靠的 RAG 系统最好能够记录用户输入了什么 Query检索器找到了哪些候选文档Rerank 如何排序哪些 Chunk 最终进入 Context模型生成了什么答案以及整个过程消耗了多少时间和成本。这些信息并不是为了让日志看起来更完整。而是当用户反馈“这次回答错了”时开发者能够沿着调用链定位问题。从这个角度看RAG 已经不只是检索算法与语言模型的组合而是一个涉及数据、检索、生成、评估和治理的完整工程系统。这也与近年来 Context Engineering 和 Agent Harness Engineering 所强调的系统化设计思路相呼应。十、新手应该怎样学习 RAG如果现在重新开始学习 RAG我不会一上来就研究各种复杂框架也不会急着搭建一个功能齐全的 Agentic RAG 系统。我更建议沿着下面这条路线逐步深入。第一阶段理解基本原理。先搞清楚 RAG 为什么存在Embedding 是什么向量相似度如何计算以及检索结果如何进入 LLM 的上下文。这个阶段最重要的不是记住技术名词而是理解 RAG 的数据流动过程。第二阶段自己实现一个最简单的 RAG。可以选择一组 Markdown 或 PDF 文档完成文档解析、切片、向量化、索引和检索再调用一个 LLM 生成答案。技术栈不用太复杂。例如Python Sentence Transformers FAISS LLM API。这套组合已经能够覆盖基础 RAG 的关键环节。有了这个最小系统后续的每一种优化才有实验基础。第三阶段主动制造问题再尝试解决。准备一些不同类型的测试 Query。例如包含专有名词的问题、依赖上下文的问题、需要多个片段才能回答的问题以及知识库中根本没有答案的问题。观察系统会在哪些地方失败。然后分别尝试调整 Chunking、引入 BM25、增加 Rerank 或优化 Prompt。相比直接套用成熟框架这个过程更能帮助理解每个组件的真实作用。第四阶段建立评估体系。为测试问题准备参考答案和相关证据计算检索指标同时检查最终答案是否准确、是否忠于资料。每次只修改一个主要变量比较优化前后的差异。慢慢就会发现很多看起来复杂的 RAG 问题其实都可以拆解成具体、可测量的工程问题。第五阶段研究更复杂的架构。当基础 RAG 已经能够稳定工作再去学习 Query Routing、Adaptive Retrieval、Self-RAG、CRAG以及 Agentic RAG。这时关注的重点不再只是如何提升一次检索的准确度而是系统如何决定什么时候检索、使用什么检索策略以及什么时候停止。对于希望进一步深入研究的同学也可以开始关注检索策略学习、证据选择、动态计算预算以及质量与成本之间的权衡。这些问题与模型路由、Agent 工作流和上下文管理有很强的联系。十一、写在最后回过头看RAG 最初的想法其实非常简单大模型不知道的知识就从外部找出来再交给模型使用。但随着实际问题越来越复杂我们会发现仅仅找到一些相似的文本远远不够。系统还需要知道哪些文档值得检索哪些证据真正相关如何处理不完整或相互冲突的信息以及怎样在有限成本下生成可靠答案。这些问题不断推动 RAG 从最初的检索增强生成发展到更加复杂的检索优化、自适应检索和 Agentic RAG。我认为这其中最值得关注的并不是某个新的 RAG 框架或者检索算法。而是一个更一般性的工程思想大模型的能力不仅取决于模型本身也取决于我们如何为它组织外部知识以及如何让这些知识在恰当的时机发挥作用。从这个角度理解RAG 与其说是一种独立技术不如说是一种构建知识增强型 AI 系统的基本方法。对于初学者真正掌握 RAG 的标志不是能否快速搭建一个问答 Demo也不是使用了多少高级组件。而是当系统回答错误时能够判断问题出在哪里当需要优化时知道为什么选择某一种方法当业务需求变化时能够重新设计检索与生成之间的协作方式。理解原理只是开始能够分析和解决问题才算真正入门。大模型的知识又多又杂到底怎么学做这行久了被问最多的问题就一个大模型的知识又多又杂我到底先学啥翻了一堆资料看啥都像重点结果啥都没学进去。今天把我自己一路摸出来的顺序捋一遍零基础、应届生、转行的都适用。跟着走至少方向不乱、不瞎忙学完拿得出手。第一阶段10天初阶应用这一阶段就一个目标把大模型真正玩明白不是只会聊天那种而是能调教它、能用代码把大模型和业务接起来。大模型 AI 能干什么大模型是怎样获得「智能」的用好 AI 的核心心法大模型应用业务架构大模型应用技术架构代码示例向 GPT-3.5 灌入新知识提示工程的意义和核心思想Prompt 典型构成指令调优方法论思维链和思维树Prompt 攻击和防范…第二阶段30天高阶应用这阶段正式进实战目标很实在做出两个能拿出手的东西——一个私有知识库一个 agent 对话机器人。为什么要做 RAG搭建一个简单的 ChatPDF检索的基础概念什么是向量表示Embeddings向量数据库与向量检索基于向量检索的 RAG搭建 RAG 系统的扩展知识混合检索与 RAG-Fusion 简介向量模型本地部署…走完这 30 天Python 或 JavaScript 背景的基本能独立做一套 RAG 应用简历上也敢写大模型应用开发了。第三阶段约20天动手微调学到这你已经开始 “造” 模型了 —— 通过微调搞出垂直领域的专用小模型。为什么要做 RAG什么是模型什么是模型训练求解器 损失函数简介小实验2手写一个简单的神经网络并训练它什么是训练/预训练/微调/轻量化微调Transformer结构简介轻量化微调实验数据集的构建…恭喜你如果学到这里你基本可以找到一份大模型 AI相关的工作自己也能训练 GPT 了通过微调训练自己的垂直大模型能独立训练开源多模态大模型掌握更多技术方案。到此为止大概2个月的时间。你从 “只会用” 变成 “能造” 的 AI 小子。那么你还想往下探索吗想要入局AI大模型赛道、抢占行业红利的朋友微信扫描下方CSDN官方认证二维码即可100%免费领取全套学习资料第四阶段20天商业闭环部署落地技术学完落地才算数。这阶段带你搞明白大模型怎么真正跑起来、用起来。硬件选型带你了解全球大模型使用国产大模型服务搭建 OpenAI 代理热身基于阿里云 PAI 部署 Stable Diffusion在本地计算机运行大模型大模型的私有化部署基于 vLLM 部署大模型案例如何优雅地在阿里云私有部署开源大模型部署一套开源 LLM 项目内容安全互联网信息服务算法备案…想要入坑大模型的朋友给大家准备了一份2026 年最新 AI 大模型全套学习资料1、大模型系统化学习路线2、大模型学习视频教程3、大模型学习书籍电子文档4、AI大模型最新行业报告5、大模型项目实战配套源码6、2026大模型大厂面试真题7、为什么要学习大模型我国在A大模型领域面临人才短缺,数量与质量均落后于发达国家。2023年人才缺口已超百万凸显培养不足。随着AI技术飞速发展预计到2025年,这一缺口将急剧扩大至400万,严重制约我国AI产业的创新步伐。加强人才培养,优化教育体系,国际合作并进是破解困局、推动AI发展的关键。8、适合谁学传统后端 / Java / 前端开发想转型 AI 应用大学生、应届生想拿更好的 offer产品经理、运营想武装职业竞争力技术负责人想给团队落地提效学习是反人性的但回报是真金白银。技术会更新赛道会切换但只要你先动手机会就永远站在你这边。9、这些资料真的有用吗这份资料由我和鲁为民博士(北京清华大学学士和美国加州理工学院博士)共同整理现任上海殷泊信息科技CEO其创立的MoPaaS云平台获Forrester全球’强劲表现者’认证服务航天科工、国家电网等1000企业以第一作者在IEEE Transactions发表论文50篇获NASA JPL火星探测系统强化学习专利等35项中美专利。本套AI大模型课程由清华大学-加州理工双料博士、吴文俊人工智能奖得主鲁为民教授领衔研发。资料内容涵盖了从入门到进阶的各类视频教程和实战项目无论你是小白还是有些技术基础的技术人员这份资料都绝对能帮助你提升薪资待遇转行大模型岗位。想要入局AI大模型赛道、抢占行业红利的朋友微信扫描下方CSDN官方认证二维码即可100%免费领取全套学习资料好了就写到这。路线是死的人是活的卡住了随时来问我。觉得有用就点个收藏别让它进收藏夹吃灰——动起来比啥都强。 
长河君 · 2026/10/14 3:30:49 · 阅读 1.2k 小白/程序员快速上手大模型：详解RAG原理与实践（附代码Demo）
大语言模型虽强但在实际业务应用中仍需RAG技术。本文深入解析RAG核心思想即结合模型内部参数化知识与外部非参数化知识解决大模型知识时效性、私有性、幻觉等问题。文章详细拆解RAG工作流程涵盖文档处理、向量检索、上下文构建等关键环节并探讨混合检索、Chunking策略、Rerank优化等实用技巧。此外本文还分析了RAG优化方法、评估体系构建以及从传统RAG到Agentic RAG的进阶路径为初学者提供系统化学习路线助力高效掌握大模型应用开发。最近几年大语言模型LLM的发展速度有目共睹。从最初的文本生成、问答交互到如今的工具调用、复杂推理以及自主执行任务大模型的能力边界正在不断扩展。但真正动手开发 LLM 应用时我们往往会遇到一个看似矛盾的问题模型越来越强为什么实际业务中仍然需要 RAG比如我们希望开发一个能够回答企业内部问题的智能助手。公司的知识分散在 PDF、Word、Markdown 和数据库中涉及产品文档、技术手册、业务规范以及不断更新的内部制度。如果直接把问题交给大模型它可能回答得头头是道但仔细核对之后就会发现有些内容早已过时有些信息根本不存在还有些答案虽然看起来合理却找不到任何依据。这时候我们自然会想到既然模型不知道能不能先把相关资料找出来再让它回答这就是 RAGRetrieval-Augmented Generation检索增强生成最直观的思想。不过理解这句话和真正掌握 RAG完全是两回事。一个最简单的 RAG Demo可能几十行代码就能实现。但要把它做成一个检索准确、回答可靠、成本可控的实际应用背后涉及的问题远比想象中复杂。这篇文章我们就从最基础的原理出发逐步拆解 RAG 的完整工作流程并讨论几个在实际开发中非常值得思考的问题。一、为什么有了大模型还需要 RAG先看大模型本身。我们知道LLM 通过大规模预训练将大量语言规律、事实知识和任务模式编码到模型参数中。这种知识通常被称为Parametric Knowledge参数化知识。你可以简单理解为模型通过训练把一部分知识“记”在了参数里。但问题在于模型参数并不是一个可以随时更新、精确查询的数据库。假设我们向模型提出一个问题“公司最新的差旅报销标准是什么”对于这样的问题模型可能面临几个困难。首先模型并不知道企业内部的私有知识。公司的制度、合同、会议纪要等信息通常没有进入模型的训练数据。如果没有外部信息模型自然无法保证回答准确。其次模型的知识存在时效性。即使模型在训练时接触过某项政策也不意味着它知道最新版本。对于经常变化的业务知识仅依赖模型参数显然不够。再者大模型可能产生幻觉Hallucination。LLM 的生成机制并不等同于事实查询。它可以生成语言上合理、逻辑上连贯却与真实情况不符的内容。尤其是在缺少必要知识时模型可能用已有知识进行补全而不是明确告诉用户“无法确定”。最后还有一个经常被忽略的问题答案从哪里来对于日常聊天我们未必需要追溯每一句话的来源。但对于企业知识库、法律法规或技术文档问答来源往往与答案本身同样重要。我们不仅希望模型告诉我们答案还希望知道它依据的是哪份文档、哪个版本、哪一段内容。这几个问题正是 RAG 希望缓解的核心痛点。1.1 RAG 的核心思想RAG 最早由 Lewis 等人在 2020 年的论文Retrieval-Augmented Generation for Knowledge-Intensive NLP Tasks中系统提出。论文的一个重要思想是将模型内部的参数化知识与外部的非参数化知识Non-parametric Knowledge结合起来。所谓非参数化知识可以理解为存储在外部知识库中的信息不需要通过修改模型参数来更新。具体来说当用户提出问题时系统先从外部知识库检索相关资料再将这些资料作为上下文交给大模型最后由模型生成答案。例如用户问题“2026 年员工出差住宿费用的报销上限是多少”RAG 系统首先检索相关制度文档找到类似的内容“根据 2026 年差旅管理办法一线城市普通员工住宿费用上限为每晚 500 元。”随后将这段资料与用户问题一起交给 LLM。模型不必依靠参数知识猜测报销标准而是可以根据检索结果组织答案并提供原始文档引用。看起来只是增加了一次检索但这个变化非常关键。我们不再要求模型记住所有知识而是让它在需要时访问知识。这也是理解 RAG 的第一步。需要注意的是RAG 并不能彻底消除幻觉。检索内容可能不准确模型也可能误解资料甚至生成没有依据的结论。它只是让答案有机会建立在外部证据之上并为进一步验证提供基础。二、RAG 的本质让知识存储与语言生成解耦在深入技术细节之前我觉得有必要先建立一个更重要的认识RAG 不只是给大模型增加一个搜索功能而是将知识管理与语言生成分离。在传统的 LLM 使用方式中知识主要存在于模型参数中。要改变模型掌握的知识通常需要借助模型更新、微调或者重新提供上下文。RAG 则引入了另一种思路。知识由外部系统负责存储、组织、更新和检索大模型负责理解问题、利用证据以及生成自然语言答案。两者各司其职。为了更直观地理解我们可以把 RAG 看成一个开卷考试系统。大模型相当于参加考试的学生外部知识库相当于允许查阅的资料。学生本身具备阅读、理解和推理能力但不需要提前背下资料里的所有细节。当遇到问题时先找到相关章节再结合已有能力组织答案。当然资料找错了答案仍然可能出错即使资料正确理解和推理也不一定完全正确。因此RAG 的效果取决于两个基础能力能否找到正确的知识以及能否正确使用找到的知识。用一个简化的数学表达可以将 RAG 建模为给定用户问题 (q) 和外部知识库 (D)检索器先获取相关证据随后生成模型根据问题和检索结果生成答案这是常见工程 RAG 的抽象并不是原始论文中所有 RAG 变体的完整概率定义。但它已经说明一个重要事实RAG 的输出质量不只取决于 LLM还依赖知识库、检索器以及上下文构建方式。有时候模型回答错误并不是因为模型不够聪明而是它从一开始就没有拿到正确的信息。三、拆开 RAG一条完整的工程链路理解 RAG 的定义并不难真正需要掌握的是它的内部工作流程。一个典型的 RAG 系统可以分成两个部分离线阶段Offline把原始文档处理成可检索的知识。在线阶段Online根据用户问题检索知识并生成答案。3.1 离线阶段让文档变得可检索离线阶段可以概括为文档加载 → 数据清洗 → 文档切片 → Embedding → 索引存储第一步是文档加载Document Loading。在真实场景中知识可能来自 PDF、Word、Markdown、网页或者数据库。这些资料的格式差异很大。尤其是 PDF文本内容可能包含复杂的双栏排版、表格、公式和图片。如果文档解析阶段把内容顺序弄错后续即使采用最先进的 Embedding 模型也很难挽回。举个简单例子。假设原始文档中有这样一张表员工级别住宿报销上限普通员工500 元部门经理700 元高级管理人员1000 元如果解析之后员工级别与对应金额的关系丢失那么检索系统就无法可靠地回答具体问题。这说明了一件事文档解析不是简单的格式转换而是在尽可能保留原始知识的结构和语义。第二步是文档清洗。我们通常需要清理重复的页眉页脚、乱码、无关格式信息同时尽可能保留文档标题、章节层级、表格关系等内容。第三步是文档切片Chunking。这是 RAG 中一个非常值得深入研究的环节。为什么不能直接把整篇文档存进去假设一份技术文档有 100 页而用户只想知道某个 API 的超时参数。如果每次检索都返回整篇文档不仅会浪费大量上下文还可能让真正有用的内容淹没在其他信息中。因此我们需要把文档拆分成若干较小的片段也就是 Chunk。但 Chunk 并不是越小越好。假设有这样一段内容“员工连续出差超过 7 天时可以申请额外住宿补贴。补贴金额按照实际出差城市等级确定。”如果恰好从中间切开一个 Chunk 可能只剩下“可以申请额外住宿补贴”另一个只包含“按照实际出差城市等级确定”。两个片段单独看都缺少必要条件。这会直接影响后续检索与生成。因此Chunking 的本质并不是机械地按字符数截断文本而是在检索粒度和语义完整性之间寻找平衡。第四步是向量化Embedding。Embedding 模型会把文本映射到一个高维向量空间让语义相关的文本在向量表示上具有一定的相似性。例如“员工住宿费报销标准是多少”与“差旅管理办法中的酒店住宿费用上限”虽然字面表达不同但语义比较接近因此理想情况下它们的 Embedding 也应该比较接近。常见的向量相似度计算方法是余弦相似度余弦相似度越高通常意味着向量方向越接近。但这里要特别注意向量相似度高不等于文档一定包含正确答案。Embedding 捕捉的是经过训练学到的语义关系而不是严格的事实一致性。另外查询和文档向量必须来自兼容的表示空间。最简单的方式是使用同一个 Embedding 模型对于采用不同查询和文档编码器的双塔模型则应使用其官方匹配的编码方式。完成向量化后就可以将向量、文本片段和元数据建立索引。常见的向量检索方案包括 FAISS、Chroma、Milvus 和 Qdrant。需要区分的是FAISS 主要是向量相似度搜索库而 Chroma、Milvus、Qdrant 等提供了更完整的向量数据管理能力。至此我们才真正完成知识库的初步构建。3.2 在线阶段从用户问题到最终答案在线阶段是用户实际感知到的部分。通常包括用户提问 → Query 处理 → 检索召回 → Rerank → Context 构建 → LLM 生成假设用户问“上海分公司的住宿报销标准是什么”首先系统需要理解 Query。在简单场景中可以直接将原始问题向量化。但用户提问往往比较口语化也可能存在上下文依赖。例如“那上海呢”如果缺少前面的对话信息检索器根本不知道用户具体在问什么。这时候就需要进行 Query Rewrite查询改写把问题还原为“上海分公司的住宿费用报销上限是多少”随后进入检索阶段。系统根据查询向量从知识库中找出相似度最高的一批候选 Chunk。但这里有一个关键问题召回的结果并不一定是最适合用来回答问题的结果。因此实际工程中经常会增加 Rerank重排序步骤。Rerank 模型会对 Query 和候选文档之间的相关性进行更精细的判断然后重新排序。最后系统选出一小部分质量较高的文档片段与原始问题一起组织成 Prompt交给生成模型。生成模型根据这些上下文给出答案并尽可能标注引用来源。这样RAG 的完整链路就跑通了。不过到这里为止我们得到的仍然只是一个基础 RAG 系统。真正值得研究的问题才刚刚开始。四、为什么 RAG 的检索结果经常不准确实际开发中经常会遇到这样的情况知识库中明明存在答案系统却没有检索出来。甚至有时检索出来的文档看起来很相关最终回答却完全不对。我认为理解这类问题比背诵 RAG 的完整流程更重要。因为这直接决定了我们能否真正调试和优化一个 RAG 系统。4.1 语义相似不等于事实相关向量检索擅长识别文本之间的语义联系但它并不天然擅长所有精确匹配问题。比如用户查询“产品 AX-1200 的最大并发连接数是多少”知识库中有两份文档AAX-1200 产品技术手册BAX-900 产品技术手册两份文档在内容结构、术语和技术描述上可能高度相似。如果只依赖语义相似度系统就可能检索到错误型号。类似问题还包括合同编号、错误代码、设备序列号和特定人名。这些信息的特点是语义相似性并不重要精确匹配反而更加关键。这就引出了混合检索Hybrid Search。一种常见方案是同时使用Dense Retrieval基于 Embedding 的语义检索。Sparse Retrieval基于 BM25 等方法的关键词检索。两种方法各有所长。向量检索擅长处理不同表达方式之间的语义联系关键词检索更适合产品型号、专有名词、精确术语等场景。实际系统可以通过 Reciprocal Rank FusionRRF融合两路结果。其典型形式为这种方法不要求不同检索器的原始分数处于相同尺度而是利用排名信息完成融合。它并不保证永远优于单路检索但对于混合了语义查询和精确术语查询的知识库通常值得作为一个重要的对照方案。4.2 Chunk 太小和太大都会出问题前面已经提到 Chunking但这里可以再深入一点。较小的 Chunk 通常更容易聚焦具体语义适合精准定位答案。问题在于它可能破坏上下文之间的联系。较大的 Chunk 能保留更多完整信息但也会引入无关内容降低检索粒度并占用更多 Context。于是就产生了一个经典矛盾检索时希望知识片段足够小生成时又希望知识上下文足够完整。一种常见的解决方案是 Parent-Child Retrieval父子块检索。它把文档分成两层。索引阶段使用较小的 Child Chunk提高检索粒度。当某个 Child Chunk 被命中时系统不直接把它交给 LLM而是找到对应的 Parent Chunk提供更完整的上下文。例如用户查询某个 API 的参数说明。检索时只需要定位到参数定义所在的小段落但生成答案时可能还需要同时提供这个 API 的使用条件、返回值和异常说明。父子块检索正是试图解决这种需求。不过它也有额外代价父块更长可能占用更多 Token还需要合理处理多个子块命中同一个父块的问题。所以Chunking 没有放之四海而皆准的最佳参数。具体选择需要结合文档结构、问题类型、上下文长度和实际评估结果。4.3 Rerank 不是万能的很多初学者在检索效果不好时第一反应就是增加 Rerank。这个想法并不总是正确。我们需要区分两个问题第一个是Recall召回即正确证据有没有出现在候选结果中。第二个是Ranking排序即正确证据出现以后有没有排在足够靠前的位置。Rerank 擅长解决第二个问题但无法凭空创造没有被召回的候选文档。如果正确答案根本没有进入候选集合那么无论 Rerank 模型多强都无法从错误的候选中找出正确证据。所以RAG 优化需要遵循一个基本顺序先保证正确证据能够被找到再考虑如何将它排到前面。这也是我认为新手需要建立的一个重要工程意识不要遇到效果差就盲目叠加组件而是先定位瓶颈。五、一个容易忽略的问题检索得越多回答就越好吗直觉上给大模型提供更多资料似乎就能让它做出更准确的判断。但实际情况并没有这么简单。2024 年发表在 TACL 的论文Lost in the Middle: How Language Models Use Long Contexts研究了语言模型利用长上下文信息的能力。研究发现在其测试的多文档问答和信息检索任务中当关键证据位于长上下文的中间位置时模型性能往往会明显下降。相比之下关键证据位于上下文开头或结尾时模型通常表现更好。这一现象也被称为 Lost in the Middle。它揭示了一个有趣的事实模型能够接收很长的上下文并不意味着它能够同样有效地利用其中的每一部分。这对 RAG 尤其重要。假设系统检索到了 20 个 Chunk其中只有 3 个真正与用户问题有关。如果我们把 20 个 Chunk 全部塞进 Prompt不仅会增加推理成本还可能让模型受到无关内容干扰。即使其中确实包含正确答案也未必能保证模型准确识别和使用。因此RAG 的上下文构建不应该只是简单的文本拼接。它还需要考虑证据的相关性、完整性、冗余程度以及最终输入模型的顺序。从这个角度看Rerank、Context Compression上下文压缩和去重并不只是成本优化手段也是提高上下文信噪比的方法。这里还可以联系到一个更大的概念Context Engineering上下文工程。在传统的 Prompt Engineering 中我们主要关注如何写好指令。但在真实的 LLM 应用中模型最终接收到的上下文不仅包括提示词还可能包含对话历史、检索文档、工具结果和系统状态。这些信息应该如果查询中包含大量产品编号或专有名词向量检索经常召回错误文档那么可以优先尝试混合检索。如果正确文档已经出现在候选列表中但经常排名靠后那么可以考虑增加 Rerank。如果检索结果只包含部分信息导致模型无法理解完整条件那么可以调整 Chunking或者尝试父子块检索。如果用户问题本身非常模糊或者依赖前面对话的上下文那么可以优先考虑 Query Rewrite。这样每一次优化都有明确的目标。下面这张表可以作为调试 RAG 时的参考。观察到的问题优先排查方向正确文档没有被召回Chunking、Embedding、混合检索产品编号、术语匹配错误BM25、精确匹配、元数据过滤正确文档排名靠后Rerank、融合策略证据被切断信息不完整父子块检索、结构化切片用户提问模糊或有上下文依赖Query Rewrite检索正确但回答错误Context 构建、Prompt、生成模型上下文过长延迟和成本偏高去重、压缩、动态 Top-K这里有一个我特别想强调的观点优化 RAG 并不等于不断增加技术组件而是根据失败原因选择成本最低且有效的解决办法。有时候调整文档解析方式比更换一个参数量更大的模型更有效。有时候增加一个简单的元数据过滤条件就能解决大量错误召回。甚至在某些场景下直接使用关键词检索就已经足够完全不需要复杂的向量检索架构。技术方案应该服务于问题而不是反过来。七、如何判断一个 RAG 系统到底好不好很多人完成 RAG Demo 后会随机提出几个问题观察模型回答是否流畅。如果答案看起来不错就认为系统效果很好。但这种评价方式很容易产生误判。原因很简单模型即使没有找到正确证据也可能生成一段看起来合理的回答。因此RAG 的评估不能只检查最终答案还应该拆开整个链路。我认为可以从三个层面理解。7.1 检索层正确证据有没有找到最直接的指标是 RecallK。假设某个问题有 4 个相关文档片段系统在前 5 个检索结果中找到了其中 3 个那么RecallK 可以衡量检索器对相关证据的覆盖情况。但它无法单独描述排序质量。例如正确证据位于第 1 名和第 5 名可能对最终答案产生不同影响。因此还可以结合 MRRMean Reciprocal Rank、nDCG 等指标评估排序质量。需要注意相关证据的标注粒度也很重要。对于简单事实问答可以标注包含答案的文档片段对于多跳问题可能需要标注多组必要证据而不是只标记一个 Chunk。7.2 生成层答案是否真正依据检索证据即使检索器找到了正确内容大模型依然可能产生错误回答。比如检索结果写的是“普通员工住宿上限为 500 元。”最终答案却写成“普通员工住宿费用可以报销 600 元。”这显然不是检索阶段的问题而是生成阶段没有忠实使用证据。因此可以评估 Faithfulness忠实度即答案中的事实性陈述是否有检索上下文支持。另一个重要维度是 Answer Relevance答案相关性也就是最终回答是否真正回应了用户的问题。需要注意忠实度高并不必然意味着答案正确。如果知识库中的内容本身错误或过时模型完全忠实于这些资料仍可能给出错误答案。因此对于要求较高的场景最好同时检查答案正确性、证据来源和引用对应关系。7.3 系统层质量之外还有成本和延迟RAG 不只是一个 NLP 算法问题也是一个工程系统问题。一个复杂方案可能带来更好的答案质量但同时增加多次检索、Rerank 和 LLM 调用。对于高并发应用这些额外开销可能并不容易接受。因此还需要关注请求延迟尤其是 P95 延迟Token 消耗与单次请求成本检索和生成阶段的失败率知识库更新与索引同步情况来源引用的准确性这里可以参考 RAGAS 等自动化评估框架对检索与生成过程进行多维度评价。但自动化评估也存在局限尤其当使用 LLM-as-a-Judge 时评价模型本身可能产生偏差。所以对于业务关键场景仍然需要保留人工标注或可验证的测试集。从工程角度看我更认可一种做法建立固定测试集记录每次优化前后的指标变化同时保留请求日志和检索结果。这样当系统效果下降时我们才能判断问题出在数据、检索、重排还是生成阶段。没有评估体系的 RAG 优化很容易变成凭感觉调参。八、从传统 RAG 到 Agentic RAG为什么检索开始需要决策能力到这里我们讨论的主要还是传统 RAG。它的基本思路是用户提问系统检索一次或按照预设规则检索若干次然后由 LLM 生成答案。这种方式对于企业 FAQ、产品说明书问答等场景通常比较合适。但如果问题本身很复杂呢例如“请对比 2025 年和 2026 年两版差旅报销制度找出上海分公司的特殊规定并判断哪些历史订单可能受到影响。”这个问题显然不是简单的一次相似度检索就能解决的。它至少涉及几个不同任务先找到两个年份的制度文件然后识别修改条款再检索上海分公司的补充规定最后关联历史订单数据。而且在执行过程中后续查询可能依赖前一步获得的新信息。这时固定的检索流水线就可能显得不够灵活。于是出现了 Agentic RAG。Agentic RAG 可以理解为在 RAG 系统中引入基于任务状态的动态决策使模型能够根据需要选择检索工具、拆分问题、评估证据必要时继续检索。它不再简单地遵循固定的“检索一次然后生成”流程。而是允许系统根据中间结果调整执行过程。例如第一次检索发现只有 2026 年政策缺少 2025 年的版本。系统可以继续查询历史文档库而不是直接开始生成答案。找到两个版本后系统再判断是否有足够证据进行比较。如果还缺少上海分公司的特殊规定就进一步检索指定地区的制度文档。直到关键证据足够或者达到检索预算上限再决定生成答案还是说明信息不足。这个变化与 Agent 中常见的规划、工具调用和反馈机制密切相关。Self-RAG、Corrective RAGCRAG和 Adaptive-RAG 等研究也从不同角度探索了按需检索、自我评估以及根据问题复杂度调整检索策略。不过需要说明的是这些方法的具体机制并不相同也不能全部直接等同于 Agentic RAG。它们体现的是一种共同趋势检索正在从固定执行步骤逐步演变为可以根据任务需求动态调整的过程。但这不意味着 Agentic RAG 一定比传统 RAG 更好。动态决策会引入额外的模型调用、工具执行、状态管理和错误恢复成本。如果一个问题通过单次检索就能找到答案增加复杂的 Agent 循环未必有意义。反而可能带来更高延迟甚至因为不必要的检索步骤引入新的错误。因此我更倾向于将它们看成两种适用于不同复杂度任务的系统设计。对于简单问题使用轻量、稳定的固定 RAG。对于需要多跳检索、多数据源访问以及动态证据验证的任务再考虑引入 Agentic RAG。系统越复杂越需要考虑收益是否足以覆盖额外成本。九、从 Demo 到生产环境还有哪些问题如果只是为了学习 RAG运行一个本地向量检索 Demo 已经足够。但在真实业务中至少还有几个问题不能忽略。首先是知识更新。RAG 的一个优势是可以独立更新外部知识库但这不意味着修改源文件后所有索引都会自动保持一致。文档被修改、删除或替换时系统需要同步维护对应索引。对于有版本管理需求的知识库还要区分“最新版本”与“指定历史版本”避免检索到已经失效的制度。其次是访问权限。企业内部不同员工可能只能访问部分文档。如果系统把所有文档都放入同一个知识库却没有严格的权限控制那么用户可能通过自然语言提问检索到无权访问的信息。因此权限过滤不能只依赖 Prompt 中的一句“不要泄露敏感信息”。它应该落实到检索和数据访问层确保进入模型上下文的内容本身就是经过授权的。再次是安全问题。外部文档不一定完全可信。如果文档中包含恶意指令试图让模型忽略原有要求、输出敏感信息或者调用危险工具那么系统可能受到 Prompt Injection提示词注入影响。对于普通问答系统风险可能主要表现为回答被污染。但对于拥有工具调用能力的 Agentic RAG问题可能更加严重因为模型输出可能进一步触发真实操作。最后是可观测性。一个可靠的 RAG 系统最好能够记录用户输入了什么 Query检索器找到了哪些候选文档Rerank 如何排序哪些 Chunk 最终进入 Context模型生成了什么答案以及整个过程消耗了多少时间和成本。这些信息并不是为了让日志看起来更完整。而是当用户反馈“这次回答错了”时开发者能够沿着调用链定位问题。从这个角度看RAG 已经不只是检索算法与语言模型的组合而是一个涉及数据、检索、生成、评估和治理的完整工程系统。这也与近年来 Context Engineering 和 Agent Harness Engineering 所强调的系统化设计思路相呼应。十、新手应该怎样学习 RAG如果现在重新开始学习 RAG我不会一上来就研究各种复杂框架也不会急着搭建一个功能齐全的 Agentic RAG 系统。我更建议沿着下面这条路线逐步深入。第一阶段理解基本原理。先搞清楚 RAG 为什么存在Embedding 是什么向量相似度如何计算以及检索结果如何进入 LLM 的上下文。这个阶段最重要的不是记住技术名词而是理解 RAG 的数据流动过程。第二阶段自己实现一个最简单的 RAG。可以选择一组 Markdown 或 PDF 文档完成文档解析、切片、向量化、索引和检索再调用一个 LLM 生成答案。技术栈不用太复杂。例如Python Sentence Transformers FAISS LLM API。这套组合已经能够覆盖基础 RAG 的关键环节。有了这个最小系统后续的每一种优化才有实验基础。第三阶段主动制造问题再尝试解决。准备一些不同类型的测试 Query。例如包含专有名词的问题、依赖上下文的问题、需要多个片段才能回答的问题以及知识库中根本没有答案的问题。观察系统会在哪些地方失败。然后分别尝试调整 Chunking、引入 BM25、增加 Rerank 或优化 Prompt。相比直接套用成熟框架这个过程更能帮助理解每个组件的真实作用。第四阶段建立评估体系。为测试问题准备参考答案和相关证据计算检索指标同时检查最终答案是否准确、是否忠于资料。每次只修改一个主要变量比较优化前后的差异。慢慢就会发现很多看起来复杂的 RAG 问题其实都可以拆解成具体、可测量的工程问题。第五阶段研究更复杂的架构。当基础 RAG 已经能够稳定工作再去学习 Query Routing、Adaptive Retrieval、Self-RAG、CRAG以及 Agentic RAG。这时关注的重点不再只是如何提升一次检索的准确度而是系统如何决定什么时候检索、使用什么检索策略以及什么时候停止。对于希望进一步深入研究的同学也可以开始关注检索策略学习、证据选择、动态计算预算以及质量与成本之间的权衡。这些问题与模型路由、Agent 工作流和上下文管理有很强的联系。十一、写在最后回过头看RAG 最初的想法其实非常简单大模型不知道的知识就从外部找出来再交给模型使用。但随着实际问题越来越复杂我们会发现仅仅找到一些相似的文本远远不够。系统还需要知道哪些文档值得检索哪些证据真正相关如何处理不完整或相互冲突的信息以及怎样在有限成本下生成可靠答案。这些问题不断推动 RAG 从最初的检索增强生成发展到更加复杂的检索优化、自适应检索和 Agentic RAG。我认为这其中最值得关注的并不是某个新的 RAG 框架或者检索算法。而是一个更一般性的工程思想大模型的能力不仅取决于模型本身也取决于我们如何为它组织外部知识以及如何让这些知识在恰当的时机发挥作用。从这个角度理解RAG 与其说是一种独立技术不如说是一种构建知识增强型 AI 系统的基本方法。对于初学者真正掌握 RAG 的标志不是能否快速搭建一个问答 Demo也不是使用了多少高级组件。而是当系统回答错误时能够判断问题出在哪里当需要优化时知道为什么选择某一种方法当业务需求变化时能够重新设计检索与生成之间的协作方式。理解原理只是开始能够分析和解决问题才算真正入门。大模型的知识又多又杂到底怎么学做这行久了被问最多的问题就一个大模型的知识又多又杂我到底先学啥翻了一堆资料看啥都像重点结果啥都没学进去。今天把我自己一路摸出来的顺序捋一遍零基础、应届生、转行的都适用。跟着走至少方向不乱、不瞎忙学完拿得出手。第一阶段10天初阶应用这一阶段就一个目标把大模型真正玩明白不是只会聊天那种而是能调教它、能用代码把大模型和业务接起来。大模型 AI 能干什么大模型是怎样获得「智能」的用好 AI 的核心心法大模型应用业务架构大模型应用技术架构代码示例向 GPT-3.5 灌入新知识提示工程的意义和核心思想Prompt 典型构成指令调优方法论思维链和思维树Prompt 攻击和防范…第二阶段30天高阶应用这阶段正式进实战目标很实在做出两个能拿出手的东西——一个私有知识库一个 agent 对话机器人。为什么要做 RAG搭建一个简单的 ChatPDF检索的基础概念什么是向量表示Embeddings向量数据库与向量检索基于向量检索的 RAG搭建 RAG 系统的扩展知识混合检索与 RAG-Fusion 简介向量模型本地部署…走完这 30 天Python 或 JavaScript 背景的基本能独立做一套 RAG 应用简历上也敢写大模型应用开发了。第三阶段约20天动手微调学到这你已经开始 “造” 模型了 —— 通过微调搞出垂直领域的专用小模型。为什么要做 RAG什么是模型什么是模型训练求解器 损失函数简介小实验2手写一个简单的神经网络并训练它什么是训练/预训练/微调/轻量化微调Transformer结构简介轻量化微调实验数据集的构建…恭喜你如果学到这里你基本可以找到一份大模型 AI相关的工作自己也能训练 GPT 了通过微调训练自己的垂直大模型能独立训练开源多模态大模型掌握更多技术方案。到此为止大概2个月的时间。你从 “只会用” 变成 “能造” 的 AI 小子。那么你还想往下探索吗想要入局AI大模型赛道、抢占行业红利的朋友微信扫描下方CSDN官方认证二维码即可100%免费领取全套学习资料第四阶段20天商业闭环部署落地技术学完落地才算数。这阶段带你搞明白大模型怎么真正跑起来、用起来。硬件选型带你了解全球大模型使用国产大模型服务搭建 OpenAI 代理热身基于阿里云 PAI 部署 Stable Diffusion在本地计算机运行大模型大模型的私有化部署基于 vLLM 部署大模型案例如何优雅地在阿里云私有部署开源大模型部署一套开源 LLM 项目内容安全互联网信息服务算法备案…想要入坑大模型的朋友给大家准备了一份2026 年最新 AI 大模型全套学习资料1、大模型系统化学习路线2、大模型学习视频教程3、大模型学习书籍电子文档4、AI大模型最新行业报告5、大模型项目实战配套源码6、2026大模型大厂面试真题7、为什么要学习大模型我国在A大模型领域面临人才短缺,数量与质量均落后于发达国家。2023年人才缺口已超百万凸显培养不足。随着AI技术飞速发展预计到2025年,这一缺口将急剧扩大至400万,严重制约我国AI产业的创新步伐。加强人才培养,优化教育体系,国际合作并进是破解困局、推动AI发展的关键。8、适合谁学传统后端 / Java / 前端开发想转型 AI 应用大学生、应届生想拿更好的 offer产品经理、运营想武装职业竞争力技术负责人想给团队落地提效学习是反人性的但回报是真金白银。技术会更新赛道会切换但只要你先动手机会就永远站在你这边。9、这些资料真的有用吗这份资料由我和鲁为民博士(北京清华大学学士和美国加州理工学院博士)共同整理现任上海殷泊信息科技CEO其创立的MoPaaS云平台获Forrester全球’强劲表现者’认证服务航天科工、国家电网等1000企业以第一作者在IEEE Transactions发表论文50篇获NASA JPL火星探测系统强化学习专利等35项中美专利。本套AI大模型课程由清华大学-加州理工双料博士、吴文俊人工智能奖得主鲁为民教授领衔研发。资料内容涵盖了从入门到进阶的各类视频教程和实战项目无论你是小白还是有些技术基础的技术人员这份资料都绝对能帮助你提升薪资待遇转行大模型岗位。想要入局AI大模型赛道、抢占行业红利的朋友微信扫描下方CSDN官方认证二维码即可100%免费领取全套学习资料好了就写到这。路线是死的人是活的卡住了随时来问我。觉得有用就点个收藏别让它进收藏夹吃灰——动起来比啥都强。