企业官网建设流程全解析

先打一个比喻：大模型像一个参加过海量知识竞赛的全能选手，你问他"光合作用的原理是什么"，他能一口气给你翻出教科书上的标准答案；但如果你问"我们公司昨天发布的新产品手册第17页的规格参数是多少"，他大概率会愣住，然后开始一本正经地编。原因很简单，他脑子里装的是训练截止日期之前的世界，而 RAG（Retrieval-Augmented Generation，检索增强生成）的出现，就是给这位选手配了一个随时可翻阅的资料库，让他从"闭卷考试"变成"开卷考试"。

RAG 和大模型的关系，这两年已经被聊得很高频了。但我在给企业做知识库、带团队落地大模型应用的过程中发现，真正能把两者关系讲透的人并不多。很多人以为 RAG 就是"先把文档喂给大模型再提问"，实际上远不止这么简单。这篇内容不会只给定义，我会从原理、链路、落地、排错到选型，把 RAG 与大模型之间的核心关系一次性拆开。适合正在做知识库问答、智能客服、文档分析，或者只是单纯想搞懂这个热词背后逻辑的朋友。

1. 两个"学霸"的分工：先把RAG与大模型的本质掰开看

1.1 大模型的本质：一个"闭卷考试"的记忆型选手

大模型本质上是一个在超大规模语料上做预训练的神经网络，它的所有"知识"都以参数的形式压缩在模型内部。无论是 GPT 系列、开源社区的 Qwen、Llama，还是国内各家商业模型，核心机制都是一样的：训练阶段见过海量文本，推理阶段根据上下文预测下一个 token。

这个机制带来一个很关键的特性——大模型的回答依赖的是"训练时见过的统计规律"。它学到的不是一份可以随时查阅的数据库，而是一套概率分布。所以它能写出逻辑通顺、风格自然的回答，也会在一些具体事实上翻车。你可以把大模型理解为一个阅卷无数的学霸，他有很强的"答题能力"，但他记忆里的世界是固定的，不会因为你给他看了新资料就实时更新。

这也解释了为什么大模型在通用问答、文本改写、代码生成、头脑风暴这些任务上表现惊艳，但一旦涉及实时信息、企业内部私有文档、长尾专业数据，就会显得力不从心。它并不理解"事实"与"虚构"的边界，只是根据概率输出最顺滑的文本。如果你不给他足够的证据，他会用最自信的语气把猜测说得像事实。

1.2 RAG的本质：一套"开卷考试"的检索外挂

RAG 并不是一个新的大模型，而是一种把"检索"和"生成"组合起来的架构模式。它的核心思路很直白：在模型回答之前，先从外部知识库中检索出与问题最相关的若干文本片段，把这些片段作为上下文塞进提示词，再让大模型基于这些资料生成答案。

整个过程大致分成三段：

• 索引阶段：把文档切块、向量化、存入向量数据库，构建一个可供检索的外部知识库。
• 检索阶段：把用户问题转成向量，从知识库中召回最相关的 Top-K 片段。
• 生成阶段：将检索到的片段和原始问题一起交给大模型，让模型"看着资料作答"。

这里的关键在于，RAG 不改变大模型内部的任何参数。它做的是"临场给资料"，让模型在生成时有了可以引用的上下文，从而大幅度提升回答的准确性和时效性。这也是它被称为"检索增强"的原因——增强的是生成过程的信息供给，而不是模型本身的记忆。

1.3 两者不是竞品，而是"脑子"和"参考书"的关系

很多人会把 RAG 和大模型当成两条可以互相替代的技术路线，这是最大的误解。实际上它们更像是"脑子"和"参考书"的关系：大模型负责理解、推理和表达，RAG 负责给它提供当下需要的素材。没有大模型，RAG 检索出来的内容只是一堆文本；没有 RAG，大模型面对动态信息只能靠猜。

我在企业项目里经常用一个比喻来解释两者的分工：大模型是员工，RAG 是文档柜。员工能力强不强，取决于模型本身的水平；但员工能不能准确回答公司内部问题，取决于他能否快速查到正确的那份文件。你不可能要求员工把所有文件都背进脑子里，也不可能把文件放在那儿不让他看就指望他答对。RAG 解决的正是"在正确的时间把正确的资料送到模型面前"这个问题。

2. 大模型天生有三个短板，RAG恰好补上的正是这些

2.1 知识截止日期：无法回答"今天"的事情

大模型的训练语料有一个明确的收集时间点。训练完成之后，它的知识就凝固了。哪怕你用的是最新最强的模型，它也不知道发布日之后发生的新事件、新政策、新产品参数。比如我今年做某个新项目时，客户问的是上月刚发布的内部采购流程，最新版文档在内部 Wiki 上，而大模型训练时根本没见过这份文档。这种情况下，无论你怎么追问，模型都无法给出正确答案。

RAG 对这个问题几乎是天然解法。因为外部知识库是可以在服务运行期间随时更新的：新增一份 PDF、改一条产品数据、同步一篇最新的运营日报，检索链路立刻就能感知。用户提问时，系统会把最新文档切片、向量化之后检索出来，再交回给大模型。知识库一变，回答就跟着变，不需要重新训练模型，也不需要等下一次迭代发布。

2.2 幻觉问题：一本正经地胡说八道

幻觉是大模型最头疼的问题之一。因为生成机制本质上是对下一个 token 的概率采样，模型为了生成通顺的回答，会在不知道答案时"编造"看起来合理的内容。更危险的是，这种编造往往语气坚定、细节丰富，用户很难凭直觉分辨真假。比如让模型总结某篇不存在的论文，它能给你列出作者、年份和结论；让模型回答一个公司内部制度的细节，它能编出完全不存在的条文。

RAG 能显著缓解幻觉，是因为它给模型提供了检索到的证据片段，并在提示词中明确要求"仅根据给定资料回答，不要编造不在资料中的信息"。有了这个约束，模型从"自由发挥"变成了"基于证据作答"。但这不意味着 RAG 能 100% 消除幻觉——如果检索到的资料本身是错的，或者提示词没有约束到位，模型依然可能把噪声当成事实。所以 RAG 不是幻觉的银弹，而是把幻觉风险从"必然发生"降低到了"可控范围"。

2.3 私有和垂直领域知识：大模型根本没见过

大多数企业的核心知识——SOP、产品手册、工程图纸、客户案例、历史项目复盘——都不在互联网公开语料里。通用大模型对它们的了解约等于零。就算这些知识碰巧被写进了训练数据，也是极少量的，模型根本无法稳定、精确地复用。同时，垂直领域还有很多独特术语和表达方式，通用模型对这些内容的生成质量往往很飘。

RAG 在这里发挥的作用是把"私有知识"导入模型的回答流程。你不需要把这些资料拿去训练大模型，只需要把它们切块、建立索引、存入外部知识库。提问时，系统检索出与问题相关的片段，大模型就相当于"开卷"阅读了一份它从未见过的内部文档。这个特性让 RAG 成为企业私有化知识库建设的最主流方案，也是为什么"知识库"这个关键词会跟 RAG 牢牢绑定在一起。

下表可以快速回顾这三个短板与 RAG 的对应关系：

3. RAG全链路拆解：从入库到出答案，每个环节都在影响结果

3.1 索引阶段：先让知识"住进"能检索的房子

初次接触 RAG 的人，往往会把精力全放在模型选择和提示词上，却忽略了真正决定上限的是"知识库怎么建"。索引阶段决定了你的知识能不能被检索到，也决定了检索出来的内容是否完整可用。

第一步是文档加载。PDF、Word、Markdown、HTML、TXT 是最常见的输入。这里有个容易被低估的坑：不是所有文档都能被直接解析。扫描版 PDF 需要先做 OCR，Word 里有复杂表格时需要保留结构，PPT 和图片里的文字要走多模态识别。很多团队在第一步就丢掉了大量有效信息，后面再怎么调都救不回来。

第二步是文本切分。你可以把整份文档直接丢进去，但实际效果非常差。因为大模型的上下文窗口有限，检索单元过大，会导致一个片段里混杂太多无关信息，回答时会显得散；切分单元过小，又会把连续的语义切断，模型拿到的只是碎片。常用策略是设置一个 chunk_size（比如 300-800 字）和 chunk_overlap（比如 50-100 字），或者按文档自带的结构标题切分。我自己的经验是：技术文档按章节切，法律法规按条款切，问答类内容按单条记录切，而不是一刀切地按固定字数处理。

第三步是向量化。切好的文本片段要通过 Embedding 模型转成向量。这里需要重点选择 Embedding 模型：通用领域可以用 OpenAI 的 text-embedding 系列、开源的 BGE 系列或 M3E 系列；中文垂直领域，尤其是有较多专业术语的场景，建议用针对该领域微调过的向量模型。向量模型的维度决定了向量库的规格，BERT 类模型常见是 768 维，大规模检索时你需要考虑存储和检索成本。

第四步是存储索引。向量数据库有 FAISS、Chroma、Milvus、Qdrant、pgvector 等多个选择。从轻量级项目到企业级分布式检索，选型差异很大。除了向量索引，很多团队会同时建立倒排索引，用于后续的混合检索。切分后的文本块还要保存元数据，比如来源文档、页码、章节标题等，这些信息在后面回答追溯和引用标注时非常关键。

3.2 检索阶段：把最相关的片段准确捞出来

检索是整个 RAG 链路里最容易被低估的环节。很多人以为"向量检索"就是无敌的，实际跑起来会发现：用户的问题是一句口语化的描述，知识库里的答案是书面化的、包含大量同义词和缩写，纯向量检索经常抓不准。

一个更稳健的做法是混合检索。向量检索擅长处理语义相近但措辞不同的问题，BM25 这种稀疏检索则擅长精确命中专业术语、型号编号、人名地名。两者结果合并后再交给重排模型。我先说说我在项目里常用的链路：先把原始问题做一次改写（比如"帮我查一下上个月华东区的退款率"改写为"查询华东区上个月的退款率数据"），然后同时跑向量检索和关键词检索，合并结果后，再由一个 Rerank 模型（如 BGE-reranker、Cohere Rerank）对候选片段打分，只保留 Top 3-5 个给大模型。

这里有一个参数需要格外注意：Top-K。K 设得太小，容易漏掉重要信息；K 设得太大，会往上下文里塞入大量噪声，反而干扰大模型生成。我从经验上建议：如果采用"检索后重排"的方案，前期召回可以取 20-50 条，重排后取 3-5 条作为最终上下文。如果你不做重排，直接取 5 条以下可能更稳妥。

检索还有一个进阶玩法是知识库路由。当系统里挂了多个知识库时，比如一个放产品文档、一个放运维手册、一个放客服话术，你需要先让大模型判断"这个问题该查哪个库"，或者用分类器做路由。这么做的意义在于缩小检索范围、提升命中率，避免跨库检索时把完全无关的内容也捞进来。

3.3 生成阶段：让大模型"看着资料作答"

检索到的片段最终要交给大模型，生成阶段的设计同样决定回答质量。这里最核心的是提示词结构。一个典型的 RAG 提示词包含三个部分：角色设定、检索资料、用户问题。尤其重要的是在提示词里明确约束生成行为。我会在 system prompt 里强调三点：

• 优先使用提供的资料，不要使用资料之外的知识。
• 如果资料中没有答案，直接告诉用户"未检索到相关内容"，不要猜测。
• 尽量标注信息出处，让用户知道答案来自哪份文档的哪一节。

生成阶段还需要考虑引用溯源。很多产品要求答案后面附带"参考来源"，让用户点击跳转到原文。要做到这一点，需要在检索阶段记录每条片段对应的文档名和页码，并在生成时要求大模型引用片段编号。这不仅是产品体验问题，也是建立信任的关键。用户看到"答案 + 引用"后，对系统判断的信任度会明显提升。

生成阶段另一个容易忽略的点是上下文压缩。检索回来的片段有时很长，可能超过上下文窗口，或者占据大量 token 导致成本飙升。可以考虑对检索片段做一次抽取式摘要，只保留与问题最相关的句子，再交给大模型。我在处理超长技术文档时就遇到过这种情况：检索命中了文档里的一个大章节，里面有一大段背景介绍，把上下文塞得满满当当。加上一个轻量级的"上下文压缩"步骤之后，回答的准确率和接口响应速度都明显提升。

4. 落地RAG的四种姿势：自己写、用框架、拖平台、本地部署

4.1 从零手写：最轻量的 RAG 脚本长什么样

最好的理解方式永远是动手写一遍。这里我给出一个非常简化的 Python RAG 流程示意，没有依赖重型框架，核心目的是让你看清 RAG 的数据流：

# 1. 加载并切分文档 from langchain_community.document_loaders import PyPDFLoader from langchain_text_splitters import RecursiveCharacterTextSplitter loader = PyPDFLoader("product_manual.pdf") documents = loader.load() splitter = RecursiveCharacterTextSplitter(chunk_size=500, chunk_overlap=50) chunks = splitter.split_documents(documents) # 2. 向量化并写入向量库 from sentence_transformers import SentenceTransformer import chromadb encoder = SentenceTransformer("BAAI/bge-large-zh-v1.5") client = chromadb.PersistentClient(path="./chroma_db") collection = client.get_or_create_collection("knowledge_base") for idx, chunk in enumerate(chunks): collection.add( ids=[str(idx)], embeddings=[encoder.encode(chunk.page_content).tolist()], documents=[chunk.page_content], metadatas=[{"source": chunk.metadata.get("source", "")}] ) # 3. 检索 query = "产品支持的最大并发连接数是多少？" query_vec = encoder.encode(query).tolist() results = collection.query(query_embeddings=[query_vec], n_results=5) # 4. 构造提示词并调用大模型 from openai import OpenAI context = "\n\n".join(results["documents"][0]) prompt = f"""仅根据以下资料回答问题，资料中没有的信息请明确说不知道。 资料： {context} 问题：{query} """ client = OpenAI(base_url="http://localhost:11434/v1", api_key="ollama") response = client.chat.completions.create( model="qwen2.5:7b", messages=[{"role": "user", "content": prompt}] ) print(response.choices[0].message.content)

这段代码虽然简化了很多细节，但完整展示了 RAG 四个核心步骤。自己手写的好处是你对每个环节都有完全的控制力，坏处是生产环境里还要处理并发、权限、增量更新、日志、评测、多知识库路由等问题，全部从零造轮子会非常耗时。所以我通常建议：初学阶段手写一个最小 Demo 来建立直觉，生产项目还是优先考虑框架或平台。

4.2 用现成框架：LangChain 和 LlamaIndex 帮你省掉大量底层工作

LangChain 和 LlamaIndex 是目前最主流的两个 RAG 框架。它们把文档加载器、文本切分器、向量数据库适配、检索器、重排器、提示词模板都封装成了组件，你可以在几十行代码内拼出一条完整的 RAG 链路。框架的价值不只是帮你少写代码，更重要的是它抽象了一套统一接口：今天用 Chroma，明天换 Milvus，改动很小；今天用 OpenAI，明天换本地模型，也只需要替换一个组件。

在实际项目中，我更多把 LangChain 当作"胶水层"来用：用它的 DocumentLoader 统一管理不同格式的文档，用它的 Retriever 接口对接不同的向量库和检索策略，再用它的 Chain 机制把检索和生成串联起来。LlamaIndex 则在"文档索引"和"结构化数据"上更精细，尤其是它对文档层级结构和元数据的处理更细，适合做知识密集型场景的工具。两个框架都不完美，但都比从零手写要稳太多。

4.3 低代码平台：Dify、FastGPT、RAGFlow们解决的真正问题

如果团队里没有专业开发人员，或者你需要快速验证一个业务场景，低代码平台往往是最高效的选择。Dify、FastGPT、RAGFlow 这类平台把知识库管理、文档解析、文本切分、向量检索、模型调用、工作流编排都做成了可视化界面。你可以上传文档、选择 Embedding 模型、调大模型 API、配置提示词，然后在平台上直接创建一个可对话的 RAG 应用。

这些平台真正的价值在于把"最佳实践"内置进系统。比如 RAGFlow 在文档解析环节做了大量工作，对复杂版式的 PDF 支持很好；Dify 的工作流引擎允许你在 UI 里串联"意图识别 -> 多知识库检索 -> 重排 -> 生成"这样的复杂逻辑。我用 Dify 给一个中小客户做过客服助手，从数据准备到上线只花了一个下午，这在纯编码路线上是不敢想象的。当然，平台也有锁定的问题：深度定制、性能调优、私有化部署的成本需要提前评估。

4.4 本地化私有部署：数据不出内网的 RAG 方案

很多企业对数据合规要求极高，文档不能出内网，大模型 API 也不能直接调用外部服务。此时就需要一套完全本地化的 RAG 方案。典型组合是：Ollama 运行开源大模型（如 Qwen、Llama、DeepSeek 系列）+ 本地向量数据库（Chroma、Milvus 或 pgvector）+ 本地 Embedding 模型。所有环节都在内网完成，数据不出门。

这里有一个很现实的建议：本地部署大模型不是越强越好，而是要匹配硬件预算。一个 7B 参数的量化模型在普通消费级显卡上就能跑得不错，一个 70B 模型则需要多张高端显卡。RAG 的优势在于，你可以用相对小的模型 + 高质量检索，达到接近大模型的效果。因为模型的推理负担被检索减轻了，它不需要记住大量细节，只需要做好"阅读理解"。我帮客户做的很多私有化项目，最终落地时甚至只用了一个 13B 或 7B 模型，配合精心调过的检索链路，效果已经足够满足业务需求。

四种落地方式的选型对比，可以画一张表：

5. 为什么你的RAG"检索对了答案还是错"：六个最容易翻车的环节

5.1 文档切分不合理：一个表格碎成八块，上下文全丢了

很多 RAG 项目第一次 Demo 效果不错，一上生产就崩，最常见的原因就是切分策略有问题。比如一个技术参数表格，被固定字数的切分器拦腰截断，导致"连接数上限"和"10000"这两部分被分到不同的 chunk 里。模型检索到了前半个表格，却看不到数字。类似的问题也会出现在代码示例、多级标题和列表场景。

我现在的做法是：优先识别文档结构，标题层级、段落、表格、列表各自有对应的切分逻辑；没有明显结构的纯文本，再用固定 chunk_size + overlap 做兜底。切分之后还要做一次"完整性检查"，比如表格块是否完整、代码块是否包含开始和结束标记。这一步花费的时间不多，但对最终的检索质量影响非常大。

5.2 向量模型选得不合适：语义相似不等于领域相关

向量检索的本质是"语义相似度"，但不同向量模型对"相似"的理解差别很大。通用向量模型在新闻、百科类文本上表现不错，但面对企业内部的工程术语、行业黑话、多语言混排文本，效果经常不尽人意。比如"异常告警"和"故障通知"在通用语义模型看来相似度很高，但在运维知识库里，二者可能对应完全不同的处理流程。

解决思路有两个：一是尽量选择与业务领域匹配的开源向量模型（中文场景可以考虑 BGE 系列、M3E 系列、text2vec 系列），二是收集一批典型的用户问题，构建一个小规模的领域评测集，对比不同 Embedding 模型的实际检索命中率。后者才是真正靠谱的做法，因为模型档位说明写得再好，也不如在自己数据上跑一遍来得直接。

5.3 只用向量检索，丢掉关键词这把利器

向量检索擅长处理"语义相似但表达不同"的查询，但它对精确匹配并不敏感。举个例子，用户问"如何升级到 v2.3.1 版本"，向量化后"v2.3.1"这个版本号可能被稀释在整句话的语义里，导致召回结果不准确。还有工单号、产品型号、缩写、人名、Base64 编码等字符型信息，向量模型的表现往往不如传统的倒排索引。

最稳妥的方案永远是混合检索：向量检索负责语义召回，BM25 或 Elasticsearch 负责关键词精确匹配，最后把两路结果加权合并。你可以把混合检索理解为"语义 + 字面双保险"。做过检索系统的朋友应该都有体会，实际线上查询里既有"大意相同"的需求，也有"必须一字不差"的需求，两者缺一不可。

5.4 没有重排环节：召回20条里前5条其实是垃圾

向量检索和 BM25 得到的 Top-K 结果，顺序并不一定代表最相关的就在最前面。尤其是混合检索之后，不同来源的结果直接拼接，排序质量通常很差。如果不加处理，只取前几条，可能把一个次要相关片段送进大模型，而真正有用的资料排在后面被丢弃。

Rerank 模型（交叉编码器）专门解决这个问题：它对每一条候选片段和用户问题做精细的相关性打分，而不是像向量检索那样把问题、文档分别编码再算相似度。我的习惯是：召回 20-50 条候选，用 Rerank 重排后取 Top 3-5 条进入生成阶段。这样可以明显提升答案的准确性。唯一的顾虑是 Rerank 会带来额外的计算开销，但在大多数业务场景中，这个成本是值得的。

5.5 提示词把"资料"变成了"干扰"

即使检索出来的片段是正确的，如果提示词设计有问题，大模型依然可能答错。我见过一种很典型的失败模式：开发者把检索到的所有片段一股脑塞进提示词，结果上下文里有 80% 的内容和问题无关，模型被这些噪声"带跑偏"，给出的答案好像"什么都说了一点，又什么都没说到"。这在检索质量不高、Top-K 取太大的时候尤其明显。

我的提示词设计原则是：明确告诉模型"资料中可能包含无关内容，请只依据与问题相关的部分回答"；如果资料互相矛盾，让模型指出冲突而不是强行二选一；资料不足时，明确输出"未找到相关信息"。同时，把问题和资料之间的分隔符做得足够清晰，让模型能区分哪些是待回答的问题、哪些是需要参考的材料。

5.6 没有一套评测集，改完不知道是变好还是变坏

RAG 项目的迭代非常依赖评测。很多团队上线之后只是人工抽测几个问题，凭感觉判断效果，"感觉变好了"就发版。但 RAG 链路里每一个环节的改动——换 Embedding 模型、改切分参数、调重排阈值、改提示词——都可能同时影响多个维度。没有稳定的评测集，你根本说不清改动是在提升还是伤害效果。

我建议每个 RAG 项目从第一天就开始积累"评测问题集"，最好按业务类型分层：常见问题 30 条、复杂多跳问题 20 条、边界情况 10 条。每个问题标注标准答案和关键来源文档。评测指标方面，检索环节看重"召回率、MRR、命中率"，生成环节更关注"答案正确率、引用准确率、幻觉出现率"。用这套评测集跑完一批变更，再决定要不要上线，比"感觉有效"要可靠得多。

6. RAG的边界与下一步：微调、长上下文、多模态和Agent化

6.1 RAG和微调不是二选一，而是组合拳

我在文章开头说过，RAG 不改变大模型参数。那如果需要改变呢？比如你希望模型始终用某种固定的客服话术回复、希望它学会某种特殊输出格式、希望它掌握某个领域的思考方式，这时候就需要微调（Fine-tuning）。微调是在模型内部调整权重，让模型本身"学会"某种行为模式。

合理的判断标准要看数据属性。如果数据是"知识点"层面的，比如产品参数、政策条款、项目记录，适合 RAG，因为这类信息更新频繁，用外部知识库可以随时改；如果数据是"行为模式"层面的，比如希望模型从特定角度回答问题、输出风格更像某个品牌、擅长解析某种行业表格，适合微调，因为这种能力对几乎每次生成都生效。

实际项目里最常用的是组合方案：先对基础模型做一次领域微调，让它理解行业术语和回答风格，然后在生产环节用 RAG 不断喂入最新知识。这样既有了"专业素养"，又有了"实时查资料"的能力。两边的侧重点不同，并不冲突。

6.2 长上下文时代，RAG还会被取代吗？

近两年大模型的上下文窗口一路飙升，有的已经支持几十万甚至上百万 token。很多人开始讨论：既然模型一次能看完那么长的内容，是不是直接把文档全塞进去就行，不需要 RAG 了？我的看法是：窗口变大确实能缓解一部分简单场景的压力，但距离"替代 RAG"还有不小的距离。

至少有三个现实问题：第一，成本。每次请求都带几十万字，token 费用和延迟都会暴涨，业务上很难接受；第二，"大海捞针"效应。即使模型有长窗口，序列越长，它对中间细节的关注度越低，很容易忽略埋藏在长文里的关键信息；第三，权限和更新。你不可能每次文档更新都重新拼接整个上下文池，也不可能为每个用户组装一份包含所有文档的超长上下文。RAG 用"只捞最相关片段"的策略，以很小的成本实现了精准的知识供给，在工程上依然是最优解。

6.3 多模态RAG与RAG智能体：下一代形态

RAG 的边界正在从纯文本向多模态扩展。文档里的图片、表格、流程图、音视频，都能成为检索对象。比如一份设备维护手册里有大量结构图，你希望用户问"根据图示，如何更换滤芯"时，模型能够检索到对应图片，并给出图片+文字结合的答案。这就需要多模态文档解析、多模态 Embedding 和视觉语言大模型配合，也就是"多模态 RAG"。

另一个重要方向是 Agent 化。传统 RAG 是一次"单轮检索+生成"，而 RAG Agent（检索增强智能体）可以多轮规划：它先判断这个问题需要哪些信息，再多次调用检索工具，一步步收集证据，甚至临时生成检索请求、反思结果缺失，继续第二轮检索。这种形态在复杂推理、多跳问答场景下效果提升明显，比如"对比 A 和 B 两款产品的售后政策差异，并给出最近三个月哪款口碑更好"——这类问题需要跨多个文档、多次检索、综合推理。

作为收尾，我把目前在实际项目中摸索出的一个体会放在这里：RAG 和大模型的关系，本质上是"知识供给"与"智能内核"的耦合。决定一个知识库问答系统能不能用的，往往不是大模型本身多强，而是检索链路是否扎实、知识库治理是否到位。如果你正在做 RAG 项目，我的建议是先把精力放在文档解析、切分、检索和评测上，模型可以往后放一放。把资料库管好，把检索调准，再配上合适的生成策略，你会发现哪怕一个 7B 的本地小模型，也能在企业场景里交出让人惊喜的答卷。