企业官网建设流程全解析

大语言模型虽强，但在实际业务应用中仍需RAG技术。本文深入解析RAG核心思想，即结合模型内部参数化知识与外部非参数化知识，解决大模型知识时效性、私有性、幻觉等问题。文章详细拆解RAG工作流程，涵盖文档处理、向量检索、上下文构建等关键环节，并探讨混合检索、Chunking策略、Rerank优化等实用技巧。此外，本文还分析了RAG优化方法、评估体系构建以及从传统RAG到Agentic RAG的进阶路径，为初学者提供系统化学习路线，助力高效掌握大模型应用开发。

最近几年，大语言模型（LLM）的发展速度有目共睹。从最初的文本生成、问答交互，到如今的工具调用、复杂推理以及自主执行任务，大模型的能力边界正在不断扩展。

但真正动手开发 LLM 应用时，我们往往会遇到一个看似矛盾的问题：

模型越来越强，为什么实际业务中仍然需要 RAG？

比如，我们希望开发一个能够回答企业内部问题的智能助手。公司的知识分散在 PDF、Word、Markdown 和数据库中，涉及产品文档、技术手册、业务规范，以及不断更新的内部制度。

如果直接把问题交给大模型，它可能回答得头头是道，但仔细核对之后就会发现：有些内容早已过时，有些信息根本不存在，还有些答案虽然看起来合理，却找不到任何依据。

这时候，我们自然会想到：既然模型不知道，能不能先把相关资料找出来，再让它回答？

这就是 RAG（Retrieval-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 模型，也很难挽回。

举个简单例子。

假设原始文档中有这样一张表：

如果解析之后，员工级别与对应金额的关系丢失，那么检索系统就无法可靠地回答具体问题。

这说明了一件事：

文档解析不是简单的格式转换，而是在尽可能保留原始知识的结构和语义。

第二步是文档清洗。

我们通常需要清理重复的页眉页脚、乱码、无关格式信息，同时尽可能保留文档标题、章节层级、表格关系等内容。

第三步是文档切片（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 的最大并发连接数是多少？”

知识库中有两份文档：

A：AX-1200 产品技术手册

B：AX-900 产品技术手册

两份文档在内容结构、术语和技术描述上可能高度相似。

如果只依赖语义相似度，系统就可能检索到错误型号。

类似问题还包括合同编号、错误代码、设备序列号和特定人名。

这些信息的特点是：语义相似性并不重要，精确匹配反而更加关键。

这就引出了混合检索（Hybrid Search）。

一种常见方案是同时使用：

• Dense Retrieval：基于 Embedding 的语义检索。
• Sparse Retrieval：基于 BM25 等方法的关键词检索。

两种方法各有所长。

向量检索擅长处理不同表达方式之间的语义联系，关键词检索更适合产品型号、专有名词、精确术语等场景。

实际系统可以通过 Reciprocal Rank Fusion（RRF）融合两路结果。

其典型形式为：

这种方法不要求不同检索器的原始分数处于相同尺度，而是利用排名信息完成融合。

它并不保证永远优于单路检索，但对于混合了语义查询和精确术语查询的知识库，通常值得作为一个重要的对照方案。

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 时的参考。

这里有一个我特别想强调的观点：

优化 RAG 并不等于不断增加技术组件，而是根据失败原因，选择成本最低且有效的解决办法。

有时候，调整文档解析方式，比更换一个参数量更大的模型更有效。

有时候，增加一个简单的元数据过滤条件，就能解决大量错误召回。

甚至在某些场景下，直接使用关键词检索就已经足够，完全不需要复杂的向量检索架构。

技术方案应该服务于问题，而不是反过来。

七、如何判断一个 RAG 系统到底好不好？

很多人完成 RAG Demo 后，会随机提出几个问题，观察模型回答是否流畅。

如果答案看起来不错，就认为系统效果很好。

但这种评价方式很容易产生误判。

原因很简单：模型即使没有找到正确证据，也可能生成一段看起来合理的回答。

因此，RAG 的评估不能只检查最终答案，还应该拆开整个链路。

我认为可以从三个层面理解。

7.1 检索层：正确证据有没有找到？

最直接的指标是 Recall@K。

假设某个问题有 4 个相关文档片段，系统在前 5 个检索结果中找到了其中 3 个，那么：

Recall@K 可以衡量检索器对相关证据的覆盖情况。

但它无法单独描述排序质量。

例如，正确证据位于第 1 名和第 5 名，可能对最终答案产生不同影响。

因此，还可以结合 MRR（Mean 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 RAG（CRAG）和 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%免费领取全套学习资料！

好了，就写到这。路线是死的，人是活的，卡住了随时来问我。觉得有用就点个收藏，别让它进收藏夹吃灰——动起来比啥都强。