【AI】一文讲清 RAG：从大模型局限到企业级知识库落地流程

👨‍💻程序员三明治 ：个人主页
🔥 个人专栏 : 《设计模式精解》《重学数据结构》
《AI探索日志》《从0带你学深度强化学习》

🤞先做到再看见！

- [一、为什么需要 RAG？](#一、为什么需要 RAG？)
- - [1. 大模型是怎么工作的？](#1. 大模型是怎么工作的？)
  - - [1.1 训练阶段：从海量文本中学习规律](#1.1 训练阶段：从海量文本中学习规律)
    - [1.2 推理阶段：根据上下文预测后续内容](#1.2 推理阶段：根据上下文预测后续内容)
- 二、大模型在企业应用中的五个典型局限
- - [1. 幻觉问题：看起来合理，但内容可能是错的](#1. 幻觉问题：看起来合理，但内容可能是错的)
  - [2. 知识时效性问题：模型可能停留在过去](#2. 知识时效性问题：模型可能停留在过去)
  - [3. 专业领域深度不足](#3. 专业领域深度不足)
  - [4. 私有数据无法直接获取](#4. 私有数据无法直接获取)
  - [5. 回答来源不可追溯](#5. 回答来源不可追溯)
- 三、一个企业知识问答场景中的问题
- 四、为什么传统关键词搜索也不够？
- [五、RAG 是什么？](#五、RAG 是什么？)
- [六、RAG 的核心流程](#六、RAG 的核心流程)
- - [1. Ingest：导入数据源](#1. Ingest：导入数据源)
  - [2. Chunk：把长文档切成小块](#2. Chunk：把长文档切成小块)
  - [3. Embed：把文本转换成向量](#3. Embed：把文本转换成向量)
  - [4. Index：存入向量数据库](#4. Index：存入向量数据库)
  - [5. Retrieve：根据用户问题检索相关内容](#5. Retrieve：根据用户问题检索相关内容)
  - [6. Answer：基于检索结果生成回答](#6. Answer：基于检索结果生成回答)
  - [7. RAG 流程小结](#7. RAG 流程小结)
- [七、RAG 的优点与局限](#七、RAG 的优点与局限)
- - [1. 优点一：成本低，上手快](#1. 优点一：成本低，上手快)
  - [2. 优点二：知识更新方便](#2. 优点二：知识更新方便)
  - [3. 优点三：答案可以追溯](#3. 优点三：答案可以追溯)
  - [4. 局限一：效果依赖知识库质量](#4. 局限一：效果依赖知识库质量)
  - [5. 局限二：系统复杂度明显增加](#5. 局限二：系统复杂度明显增加)
  - [6. 局限三：检索耗时需要关注](#6. 局限三：检索耗时需要关注)
- [八、RAG 的典型应用场景](#八、RAG 的典型应用场景)
- - [1. 企业内部知识库](#1. 企业内部知识库)
  - [2. 智能客服](#2. 智能客服)
  - [3. 专业领域助手](#3. 专业领域助手)
  - [4. 代码与技术文档助手](#4. 代码与技术文档助手)
- [九、为什么做好 RAG 并不容易？](#九、为什么做好 RAG 并不容易？)
- - [1. 数据入库并不简单](#1. 数据入库并不简单)
  - [2. 用户问题往往需要重写](#2. 用户问题往往需要重写)
  - [3. 意图识别决定流程走向](#3. 意图识别决定流程走向)
  - [4. 检索质量是 RAG 的核心](#4. 检索质量是 RAG 的核心)
  - [5. 多轮会话会增加复杂度](#5. 多轮会话会增加复杂度)
  - [6. 一个完整系统还需要很多配套能力](#6. 一个完整系统还需要很多配套能力)
  - - [6.1 引导澄清](#6.1 引导澄清)
    - [6.2 请求风控](#6.2 请求风控)
    - [6.3 停止生成](#6.3 停止生成)
    - [6.4 模型负载均衡](#6.4 模型负载均衡)
    - [6.5 答案溯源](#6.5 答案溯源)
    - [6.6 效果监控和反馈收集](#6.6 效果监控和反馈收集)
- 十、总结

AI 这一波浪潮，Java 程序员已经很难绕开了。

不管你现在做的是业务系统、中间件，还是企业内部平台，面试和实际项目中都越来越容易遇到 AI 相关问题：RAG 是什么？Agent 怎么实现？MCP 用来解决什么问题？这些内容已经从"加分项"逐渐变成了"必答题"。

但对于大多数应用层开发者来说，直接去死磕大模型微调、蒸馏、Transformer 底层原理，投入产出比未必最高。更实用的方向，反而是先掌握 RAG、Agent 这类应用层能力：能落地、能出活，面试时也能讲清楚。

问题在于，很多人跟着视频或 GitHub Demo 跑了一遍，就以为自己懂了。结果面试一深入，或者真正做企业项目时，立刻发现 Demo 和生产环境之间差距很大。

所以，在正式介绍 Ragent 项目之前，我们先系统聊一聊 RAG：它解决什么问题、核心流程是什么、适合哪些场景，以及为什么真正做好 RAG 并不容易。

一、为什么需要 RAG？

在理解 RAG 之前，先要搞清楚一个问题：大语言模型本身为什么不能直接解决所有企业知识问答问题？

1. 大模型是怎么工作的？

大语言模型，也就是 LLM，可以简单理解为一个通过海量文本训练出来的语言模型。它在训练阶段学习语言规律、通用知识和一定的推理能力；在推理阶段，则根据用户输入一步步预测后续内容。

1.1 训练阶段：从海量文本中学习规律

大模型训练的过程，可以简单理解为让模型阅读互联网上大量文本，从中学习规律和知识。

经过训练后，模型主要学会了三类能力：

语言规律：知道一句话怎么组织才通顺。
世界知识：掌握历史、科学、常识等通用信息。
推理能力：能够进行一定程度的逻辑推断和因果分析。

1.2 推理阶段：根据上下文预测后续内容

当你和大模型聊天时，它本质上是在根据你的输入，不断预测后面最可能出现的内容。

plain 复制代码

你的输入：请帮我写一段接口说明
模型预测：这 → 个 → 接 → 口 → 主 → 要 → 用 → 于 → ...

这有点像"高级文字接龙"：模型根据训练阶段学到的语言规律和知识，每次预测一个最可能的词或字，最终组成完整回答。

这里有一个关键点：模型的通用知识主要来自训练阶段。推理时，如果没有额外工具或外部数据接入，它无法主动获取最新或私有信息。

二、大模型在企业应用中的五个典型局限

理解了大模型的基本工作方式，就很容易理解为什么它在实际业务中会遇到问题。

1. 幻觉问题：看起来合理，但内容可能是错的

大模型最典型的问题之一，就是会生成一些看起来很像答案、但实际上并不正确的内容。

例如你故意编一个不存在的人名或产品名，模型有时仍然会给出一段看似完整的介绍。虽然现在很多高版本模型已经通过联网搜索、工具调用等方式降低了幻觉问题，但在没有外部信息校验的情况下，幻觉仍然是需要重点关注的问题。

原因在于：大模型本质上是在预测概率最高的下一个词。当它对某个问题不确定时，并不一定会主动说"不知道"，而是可能生成一个"看起来像答案"的内容。

2. 知识时效性问题：模型可能停留在过去

大模型的知识通常会冻结在训练数据截止时间附近。

对于企业应用来说，这个问题尤其明显：

产品功能在更新；
内部制度在调整；
价格策略会变化；
项目文档持续迭代。

如果模型没有接入最新数据，它自然无法知道这些变化。

3. 专业领域深度不足

虽然大模型训练数据规模很大，但在特定专业领域中，它的理解往往不够深入。

plain 复制代码

用户：我们公司的 XG-3000 工业网关固件升级流程是什么？

模型：抱歉，我没有关于贵公司特定产品的信息...

对于企业内部产品、私有系统、定制化方案，公开训练数据中通常没有相关内容。模型即使能给出通用建议，也很难回答到业务真正需要的细节。

4. 私有数据无法直接获取

大模型通常基于公开数据训练，它无法天然访问企业内部资料，例如：

公司内部文档；
客户数据；
未公开的研究资料；
个人私有信息；
内部系统数据。

这意味着，如果用户问"我们公司的远程办公申请流程是什么"，模型本身是答不上来的。除非你把这部分资料通过某种方式提供给它。

5. 回答来源不可追溯

大模型直接生成的回答，很多时候无法明确告诉你"这句话来自哪份文档"。

plain 复制代码

用户：这个合规建议的依据是什么？

模型：这是基于一般合规知识给出的建议...（无法提供具体出处）

在医疗、法律、金融、企业制度等场景下，答案是否正确并不是唯一问题，更重要的是：这个答案有没有出处，能不能被验证，出现问题后能不能追溯。

单纯依赖大模型生成回答，很难满足这一点。

三、一个企业知识问答场景中的问题

假设你接到一个需求：给公司做一个智能知识问答系统。员工可以用自然语言提问，系统需要根据公司内部文档给出准确回答。

你可能会想到直接接入大模型，比如通义千问、DeepSeek 等。但很快就会发现，上面提到的问题都会出现。

大模型局限	在企业知识问答中的表现
幻觉问题	编造不存在的制度、流程或系统功能
知识时效	不知道最近刚更新的审批流程
专业深度	对内部系统的复杂操作说明不清
私有数据	无法访问公司 Wiki、制度文档、项目资料
不可追溯	用户问"这个规定在哪份文档里"，系统答不上来

结论很直接：大模型只掌握训练阶段学到的通用知识，并不知道你公司的内部文档、业务系统和最新规则。直接让它回答，结果很容易不准确。

四、为什么传统关键词搜索也不够？

有人可能会问：既然大模型不知道公司文档，那我直接做关键词搜索不就行了吗？比如在数据库里写：

plain 复制代码

LIKE '%路由器%'

如果用户的问题非常精准，关键词搜索确实能起作用。但现实中，用户提问往往很口语化，和文档里的标准表达并不一致。

用户的问题	文档里的表述	关键词匹配结果
这个设备连不上网怎么办	网络连接故障排查流程	❌ 匹配不上
管理后台怎么登录	控制台访问方式	❌ 匹配不上
忘记管理员密码了	账号凭证重置说明	❌ 匹配不上

问题的本质是：关键词搜索只能匹配字面内容，无法真正理解语义。

人能理解"设备连不上网"和"网络连接故障排查"说的是同一类问题，但传统数据库并不理解这层语义关系。

这时，RAG 就派上用场了。

五、RAG 是什么？

RAG 的全称是 Retrieval-Augmented Generation，检索增强生成。

结合前面的分析，问题可以总结为：

大模型懂语义，但没有企业私有知识；
传统搜索有数据，但不懂自然语言表达；
企业应用既需要理解用户问题，又需要基于可靠资料回答。

RAG 的思路就是把两者结合起来：先从知识库中检索相关资料，再把检索结果交给大模型生成回答。

RAG 概念最早由 Meta，当时还是 Facebook AI，的研究团队在 2020 年提出。它的核心思路并不复杂：与其让模型把所有知识都记在参数里，不如让模型"先查资料，再回答"。

简单来说，RAG 的流程可以概括为四步：

把企业文档处理后存入一个支持语义检索的知识库；
用户提问时，先从知识库中检索相关内容；
把检索到的内容和用户问题一起交给大模型；
大模型基于参考资料生成回答。

这就像开卷考试：模型不需要把所有知识都背下来，只要能找到相关资料，并基于资料回答即可。

六、RAG 的核心流程

一个典型 RAG 系统的完整链路可以概括为：

plain 复制代码

ingest → chunk → embed → index → retrieve → answer

这六步可以分为两个阶段：

准备阶段 ：ingest → chunk → embed → index
运行阶段 ：retrieve → answer

准备阶段通常离线执行，有新文档时再增量更新；运行阶段则在每次用户提问时触发。

下面逐步拆解。

1. Ingest：导入数据源

第一步是把数据源接入系统。

企业里的数据格式通常很多，包括：

PDF 产品手册；
Word 内部文档；
网页内容；
Markdown 文档；
数据库中的结构化数据。

不同格式需要不同的解析方式。PDF 要提取文字，Word 要读取正文，网页要爬取并清洗。

这一步的目标只有一个：把各种格式的数据，尽可能处理成干净的纯文本。

2. Chunk：把长文档切成小块

企业文档通常比较长，不能直接整篇塞给模型。主要有两个原因：

大模型上下文窗口有限，放不下太长的文档；
检索时希望找到最相关的小片段，而不是整篇文档。

因此，需要对文档进行切块。

例如一份 50 页的设备运维手册，可以按章节切，也可以固定每 500 字切一块。

切块大小需要权衡：

切得太大：检索不够精准，还可能超出上下文限制；
切得太小：语义不完整，容易丢失上下文。

常见做法是每块 500 到 1000 字，相邻块之间保留一定重叠，比如重叠 100 字，避免关键信息刚好被切断。

3. Embed：把文本转换成向量

这是 RAG 的核心步骤之一。

前面说过，传统关键词搜索不理解语义。那机器如何知道"设备连不上网"和"网络连接故障排查"是相关的？

答案是：把文本转换成向量。

向量可以理解为一串数字，例如：

plain 复制代码

[0.23, -0.45, 0.67, ...]

这串数字编码了文本的语义信息。语义越接近的文本，在向量空间中的距离也越接近。

plain 复制代码

"设备连不上网怎么办"  → [0.23, -0.45, 0.67, ...]

"网络连接故障排查流程" → [0.25, -0.42, 0.65, ...]  ← 很接近

"今天晚饭吃什么"      → [-0.89, 0.12, 0.03, ...]  ← 差很远

这个转换过程由专门的 Embedding 模型完成，例如 Qwen3 的 Qwen3-Embedding-8B，或者开源的 bge、m3e。

4. Index：存入向量数据库

文本向量生成后，需要有地方存储和检索。

普通数据库更擅长存储结构化数据和精确匹配；向量数据库则专门用于存储向量，并支持相似度搜索。也就是说，给它一个向量，它可以找出距离最近的 N 个向量。

常见的向量数据库包括：

Milvus
Pinecone
Weaviate
Faiss
Chroma

从目前调研来看，Milvus 在向量数据库中更新迭代较快、社区活跃度较高，同时也提供了相对完善的可视化界面，上手和管理都比较方便。因此，后续课程将以 Milvus 作为示例工具进行讲解与演示。

需要注意的是，存储时不能只存向量，还要同时保存：

原始文本；
文档来源；
标题、章节等元数据；
权限、时间、分类等辅助信息。

这样后续检索到向量后，才能把对应原文提供给大模型，并支持更精准的数据筛选。

5. Retrieve：根据用户问题检索相关内容

当用户提问时，例如：

plain 复制代码

设备连不上网怎么办？

系统通常会做两件事：

把用户问题也转换成向量；
用这个向量到向量数据库中检索最相似的文档块。

因为语义相近的文本向量距离也更近，所以用户说"连不上网"，文档里写的是"网络连接故障排查流程"，也可以被匹配出来。

这就是语义检索的价值：不是只比较字面是否相同，而是比较含义是否接近。

6. Answer：基于检索结果生成回答

最后一步，是把检索到的内容和用户问题一起发给大模型。

plain 复制代码

你是一个企业知识库助手，请根据以下参考资料回答用户问题。

参考资料：
【文档1】网络连接故障排查流程：1. 检查网线连接状态...
【文档2】控制台访问方式：设备默认管理地址为 192.168.1.1...

用户问题：设备连不上网怎么办？

请基于参考资料回答。如果资料中没有相关内容，请说明。

这时，大模型不再是完全凭记忆回答，而是基于系统提供的参考资料组织答案。

7. RAG 流程小结

RAG 的准备阶段一般不需要每次都执行，只有在新增或更新文档时才需要重新处理。运行阶段则是用户每次提问都会经过的流程。

阶段	步骤	作用
准备阶段，离线	Ingest	导入原始文档
准备阶段，离线	Chunk	将文档切成小块
准备阶段，离线	Embed	将文本转换成向量
准备阶段，离线	Index	存入向量数据库
运行阶段，在线	Retrieve	检索相关文档片段
运行阶段，在线	Answer	由大模型生成回答

先建立这个整体印象即可。

真正落地时，每一步都有不少细节：文档怎么切效果最好？Embedding 模型怎么选？检索结果要不要重排序？这些都没有统一标准，需要结合数据特点和业务场景来调整。

七、RAG 的优点与局限

RAG 能火起来，不是没有原因的。它确实解决了不少企业应用中的实际问题。

1. 优点一：成本低，上手快

如果想让大模型理解企业业务知识，通常有两条思路：

用企业数据微调模型；
用 RAG 把相关知识作为上下文提供给模型。

微调需要准备训练数据、消耗算力和时间，整体成本更高。RAG 相对简单很多：把文档处理后灌入向量库，当天就可以跑出一个原型。

换句话说，微调更像是让模型"重新学习一遍"，把知识记进模型参数里；RAG 更像是让模型"带着资料回答问题"。

2. 优点二：知识更新方便

微调后的模型，知识基本固化在模型参数中。如果业务知识更新，往往需要重新微调。

RAG 则不同。只要知识库中的文档更新，重新处理或增量更新即可。对于制度、产品、价格、流程频繁变化的场景，这一点非常关键。

3. 优点三：答案可以追溯

RAG 在回答时可以保留引用来源。用户看到答案后，可以进一步查看它参考了哪些文档。

这在金融、医疗、法律、企业制度等对准确性要求很高的场景中非常重要。因为答案不只是要"看起来对"，还要能被验证。

当然，RAG 也不是万能的。

4. 局限一：效果依赖知识库质量

RAG 非常依赖知识库本身的质量。

如果文档内容过时、结构混乱、表达不清，检索出来的结果也很难高质量。所谓"垃圾进，垃圾出"，在 RAG 系统里表现得非常明显。

5. 局限二：系统复杂度明显增加

原本直接调用大模型即可，现在多了文档解析、切块、向量化、索引、检索、排序、溯源等多个环节。

链路变长后，任何一个环节出问题，都会影响最终效果。调试复杂度也比单纯调用大模型高很多。

6. 局限三：检索耗时需要关注

RAG 多了检索环节，响应时间一定会增加。有研究提到，检索环节可能占整个 RAG 流程较高比例的耗时。

如果业务对延迟敏感，就需要重点优化检索速度、索引结构、top-k 数量、重排序策略等环节。

总体来说，RAG 适合知识密集、更新频繁、需要答案可追溯的场景。但它不是银弹，最终效果取决于知识库质量和系统设计能力。

八、RAG 的典型应用场景

理解了原理后，再看实际场景就比较清楚了。

RAG 适合的场景通常有几个共同点：

知识量大；
更新频繁；
用户问法不固定；
答案需要有依据。

1. 企业内部知识库

这是 RAG 最典型的应用场景。

员工想查询报销制度、请假流程、技术规范、项目说明，以前可能需要翻 Wiki、搜文档，或者直接问同事。接入 RAG 后，员工可以直接用自然语言提问，系统给出答案，并标注出处。

典型知识来源包括：

公司制度文档；
产品手册；
技术文档；
历史项目资料；
会议纪要。

如果只是查询文档，它是一个知识库助手；如果进一步接入业务系统，它就可以升级为企业智能助手。

借助 MCP（Model Context Protocol）或类似的工具调用能力，可以让 RAG 系统和企业内部系统打通。例如：

这个月我有几次考勤异常？还剩几天年假？------对接 HR 系统；
华南区上个月销售额是多少？环比如何？------对接 BI 系统；
帮我查一下订单 #A20260510001 的物流状态------对接订单系统；
我名下有哪些待审批流程？------对接 OA 系统。

在这种场景下，大模型先理解用户意图，再调用对应工具获取数据，最后组织成自然语言返回。

知识检索、数据查询和工具调用结合起来，才能形成更完整的企业级智能助手。

这个截图是后续要讲的 Ragent 项目前端界面，整体观感还是比较清晰的。

2. 智能客服

传统客服机器人主要依赖关键词匹配和预设问答对。覆盖不到的问题，往往就回答不上来。

接入 RAG 后，可以把产品文档、FAQ、历史工单等资料导入知识库。用户即使用不同问法提问，只要知识库中有相关内容，系统就有机会检索到并组织回答。

这对降低人工客服压力、提升响应效率非常有帮助。

这里可以观察到一个变化：阿里云 AI 助理的流程或提示词可能做了收敛。此前在带前置描述的情况下，模型可能会输出明显的拟人化、角色扮演内容。比如用户随口给一个夸张身份，模型可能顺着这个身份继续发挥。

这类输出虽然有趣，但在 ToC 客服场景中容易带来风格漂移和严谨性不足的问题。因此，对输出风格进行收敛，是一次比较合理的优化。

3. 专业领域助手

法律、金融、医疗等行业，对答案准确性要求很高，大模型不能随意编造回答。

RAG 在这类场景中的价值主要体现在两点：

能检索专业资料；
能提供答案依据。

例如：

法律：检索相关法条、判例，辅助律师进行案情分析；
金融：基于研报、财报、公告回答投资相关问题；
医疗：检索医学文献、用药指南，辅助生成参考建议。

这些场景不仅要求答案尽可能准确，还要求能够追溯到具体法规、文献或资料。RAG 天然适合这类需求。

4. 代码与技术文档助手

开发团队同样是 RAG 的高频使用者。

把公司的代码仓库、技术文档、API 文档接入系统后，新人可以直接提问：

这个接口怎么调用？
这块业务逻辑在哪个模块？
某个错误码是什么意思？
这个配置项在哪里维护？

系统可以检索相关代码和文档，再辅助生成回答。

GitHub Copilot、Cursor 这类工具背后，也大量使用了类似检索增强的思路。

九、为什么做好 RAG 并不容易？

看到这里，你可能会觉得 RAG 原理并不复杂。确实，跑通一个 Demo 级别的 RAG 系统，也许一下午就够了。

但从"能跑"到"好用"，中间有很多坑。

1. 数据入库并不简单

企业知识通常不会以干净的纯文本形式存在。

实际数据可能来自：

PDF；
Word；
PPT；
网页；
Markdown；
数据库。

光是把这些内容解析成干净文本，就有很多细节要处理。PDF 中的表格、扫描件、双栏排版，都可能影响解析质量。

文档切块同样有难度：

按段落切？
按固定字数切？
按语义切？
不同文档是否采用不同策略？

切得太大，检索不精准；切得太小，上下文又容易丢失。没有一种切块策略适用于所有场景。

2. 用户问题往往需要重写

用户输入的问题，很多时候不能直接拿去检索。

常见情况包括：

口语化表达
用户问"怎么走报销"，直接拿这句话检索，效果未必好。系统可以将其改写为"公司报销流程是什么，需要准备哪些材料"。
多轮对话
第一轮用户问"年假有多少天"，第二轮问"怎么申请"。如果只拿"怎么申请"去检索，系统不知道用户问的是年假申请。需要结合上下文改写为"年假怎么申请"。
多意图问题
"请假流程是什么，另外帮我查下我还剩几天年假"其实包含两个任务：一个要检索制度文档，一个要查询业务系统数据。
复杂问题
"我想申请调岗到上海，需要满足什么条件，流程是什么，大概要多久？"这类问题可能涉及多个文档和多个子问题，直接检索可能覆盖不全。

问题重写的本质，是弥补用户表达和检索系统之间的 gap。做不做、做多深，会直接影响检索质量。

3. 意图识别决定流程走向

用户发来一句话，系统首先要判断它想做什么。不是所有请求都应该走 RAG。

例如：

闲聊问题
用户问"你是智能助手吗？"这类问题没必要检索知识库，直接由模型回答即可。
知识问答和工具调用的区别
"报销制度是什么"需要检索知识库；"我这个月的报销单到哪一步了"则需要调用业务系统接口。
多知识库路由
企业可能有 HR 政策库、产品文档库、技术文档库。用户的问题应该去哪个库检索？如果全部检索，成本高、噪音大；如果只查一个库，选错了就检索不到。
是否应该回答
涉及敏感信息、超出系统能力范围、恶意试探的问题，需要识别出来，并给出合适的拒绝或引导。

意图识别做不好，后面的检索和生成再完善也没有意义。方向错了，流程越复杂，错误越明显。

4. 检索质量是 RAG 的核心

检索是 RAG 最关键、也最容易出问题的环节。

常见问题包括：

向量检索对精确匹配不够友好
纯向量检索擅长语义相似，但对编号、人名、型号、订单号这类精确信息不一定敏感。比如用户问：

plain 复制代码

BRD-2026-0418 这个需求的状态是什么？

如果只依赖向量检索，可能找不到最准确的结果。

混合检索需要权衡
为了弥补向量检索的不足，通常会结合关键词检索。但两边结果如何融合、权重怎么设置，不同场景下策略可能不同。
top-k 选多少很关键
返回结果太少，可能漏掉关键信息；返回结果太多，又可能把无关内容塞给模型，反而干扰生成质量。
是否需要重排序
向量相似度高，不一定代表最终最相关。很多时候需要增加 Reranking，用更精细的模型对结果重新排序。这能提升效果，但也会增加延迟和成本。
召回了不代表能直接使用
检索到的内容可能过时、相关度不够，或者用户没有权限查看。在交给模型之前，还需要进行过滤和筛选。

5. 多轮会话会增加复杂度

单轮问答相对简单，多轮对话会复杂很多。

主要问题包括：

上下文带多少
用户聊了 20 轮，全部塞给模型会增加 Token 成本，也容易引入无关信息；只保留最近几轮，又可能丢失关键上下文。
历史对话如何压缩
可以对历史对话做摘要，用摘要代替完整记录。但摘要过程可能丢失细节，如果摘要错了，后续回答也会错。
是否需要长期记忆
有些场景要求系统记住跨会话信息。用户上周问过的问题，这周再来时系统还能接上。这涉及记忆的持久化存储和检索。
记忆如何更新和遗忘
如果用户纠正了之前的信息，系统需要更新记忆。过时的信息也需要遗忘，不能一直被带入后续对话。

6. 一个完整系统还需要很多配套能力

除了 RAG 主流程，一个完整的企业级系统还需要处理很多边界问题。

6.1 引导澄清

用户问题太模糊时，系统应该主动澄清。

比如用户只输入：

plain 复制代码

报销

这时系统需要判断用户可能想问的是：

报销流程；
报销材料；
报销单状态；
新建报销申请。

系统不能盲目回答，而应该引导用户补充信息。

6.2 请求风控

总会有人尝试让系统输出不该输出的内容，或者套取敏感信息。

因此，系统入口需要做一层过滤，识别恶意请求、敏感请求和越权请求。如果知识库中包含公司隐私数据，还需要考虑本地模型部署、限流和风控机制。

6.3 停止生成

用户发现问题问错了，或者答案方向不对，可能希望中断生成。系统需要支持停止生成，及时终止输出，而不是继续返回无效内容。

6.4 模型负载均衡

线上流量较大时，单个模型实例可能扛不住。需要通过负载均衡在多个模型实例之间分发请求。

如果使用第三方模型 API，还要处理限流、降级、多供应商切换等问题。

6.5 答案溯源

用户看到答案后，可能会问：这个结论来自哪里？

系统需要标注答案对应的文档来源、章节或片段，让用户可以点击查看原文。这对建立信任和方便核查都很重要。

6.6 效果监控和反馈收集

系统上线后，还需要知道它答得好不好。

常见做法是收集用户反馈，例如点赞、点踩、纠正内容，并监控检索命中率、回答满意度、响应耗时等指标，为后续优化提供依据。

十、总结

RAG 的核心思路并不复杂：先检索，再生成。

它通过引入外部知识库，让大模型可以基于企业私有文档、最新资料和可追溯信息来回答问题，从而缓解幻觉、知识过时、私有数据无法访问、答案不可追溯等问题。

但 RAG 并不是简单地"把文档丢进向量库"就结束了。真正要做好，需要系统性处理：

数据解析；
文档切块；
向量化；
向量数据库；
问题重写；
意图识别；
检索策略；
结果重排序；
会话记忆；
权限控制；
答案溯源；
反馈监控。

每个点单独看都不算特别难，但组合成一个完整系统后，复杂度会明显上升。

如果我的内容对你有帮助，请辛苦动动您的手指为我点赞，评论，收藏。感谢大家!!

【AI】一文讲清 RAG：从大模型局限到企业级知识库落地流程

目录

一、为什么需要 RAG？

1. 大模型是怎么工作的？

1.1 训练阶段：从海量文本中学习规律

1.2 推理阶段：根据上下文预测后续内容

二、大模型在企业应用中的五个典型局限

1. 幻觉问题：看起来合理，但内容可能是错的

2. 知识时效性问题：模型可能停留在过去

3. 专业领域深度不足

4. 私有数据无法直接获取

5. 回答来源不可追溯

三、一个企业知识问答场景中的问题

四、为什么传统关键词搜索也不够？

五、RAG 是什么？

六、RAG 的核心流程

1. Ingest：导入数据源

2. Chunk：把长文档切成小块

3. Embed：把文本转换成向量

4. Index：存入向量数据库

5. Retrieve：根据用户问题检索相关内容

6. Answer：基于检索结果生成回答

7. RAG 流程小结

七、RAG 的优点与局限

1. 优点一：成本低，上手快

2. 优点二：知识更新方便

3. 优点三：答案可以追溯

4. 局限一：效果依赖知识库质量

5. 局限二：系统复杂度明显增加

6. 局限三：检索耗时需要关注

八、RAG 的典型应用场景

1. 企业内部知识库

2. 智能客服

3. 专业领域助手

4. 代码与技术文档助手

九、为什么做好 RAG 并不容易？

1. 数据入库并不简单

2. 用户问题往往需要重写

3. 意图识别决定流程走向

4. 检索质量是 RAG 的核心

5. 多轮会话会增加复杂度

6. 一个完整系统还需要很多配套能力

6.1 引导澄清

6.2 请求风控

6.3 停止生成

6.4 模型负载均衡

6.5 答案溯源

6.6 效果监控和反馈收集

十、总结