一、为什么需要 RAG？—— 大模型的"三大硬伤"

大模型（ChatGPT、文心一言、通义千问这些）虽然聪明，但它有三个绕不过去的短板：

硬伤	表现	举例
胡说八道（幻觉）	遇到不懂的事，不承认不知道，而是编一个听起来很合理的答案	你问"公司去年年假几天"，它编了个"5 天"——实际上公司去年是 10 天
知识滞后	训练数据有截止日期，之后发生的事一概不知	问 2026 年 6 月的新政策，它只能摇头
没有私域知识	互联网上公开的数据里，没有你公司的财务报表、考勤制度、合同条款	问"张三这个月出差报销了多少"，它完全不知道

以前怎么解决？—— 微调（Fine-tuning）

让大模型重新"挑灯夜读"，把新知识背下来。但这条路贵、慢、不好维护——每次知识更新都要重新训练。

现在怎么解决？—— RAG

核心思想非常朴素：别硬背了，我给你发张准考证，允许你"开卷考试"。

你不再是问一个闭卷考试的学霸，而是问一个随身带着参考书、遇到问题先去翻书、再用自己的话回答的学生。

这个模式就叫 RAG（Retrieval-Augmented Generation，检索增强生成），拆开三个字：

检索（Retrieval） → 翻书，找到相关段落增强（Augmented） → 把找到的段落摊在桌上做参考生成（Generation） → 用自己的话，基于参考资料回答问题

---

二、RAG 是怎么工作的？——"存 → 找 → 答"三步

第一步：存（知识库的数字化准备）

你不能直接把一万份 PDF 丢给大模型——它读不下，也找不快。需要先把文档"加工"好：

原始文档  ↓① 切块（Chunking）：把长文档切成几百字的小段落  ↓② 向量化（Embedding）：用一个模型把每个段落转换成一串数字（向量）  这串数字代表这段话的"语义坐标"——语义相近的段落，数字也相近  ↓③ 存入向量数据库（Vector DB）：比如 Milvus、Elasticsearch、Chroma 等

类比：相当于图书馆把每本书拆成卡片，每张卡片上标注了"这段话在说什么"的数学编码，然后分门别类放好。

第二步：找（精准捞出相关资料）

1. 1. 系统把用户的问题也用同一个模型转换成向量
2. 2. 去向量数据库里做数学运算，找语义最接近的段落
3. 3. 捞出 Top 3-5 个最相关的段落

第三步：答（阅读理解 + 生成回答）

系统把原始问题 + 捞出来的参考资料打包成一段提示词（Prompt），发给大模型：

【系统指令】请根据以下参考资料回答用户问题。如果资料里没有答案，就说"不知道"，不要瞎编。【参考资料】[资料1] 员工满一年享有10天带薪年假……[资料2] 年假需提前3天在OA系统提交申请……【用户问题】"我们公司年假几天？怎么申请？"【你的回答】

大模型收到后，现场做阅读理解题，给出精准、有据可查的答案。

---

三、光有"存→找→答"还不够——从初级 RAG 到高级 RAG

你可能会想：“听起来很简单啊，不就是搜索 + 拼提示词吗？”

实际落地中，简单的 RAG（Naive RAG）效果往往很差。常见问题：

问题	原因	后果
关键词搜不到	你问"差旅费标准"，文档里写的是"出差报销标准"——词不一样	漏掉关键文档
搜出来的太多太杂	向量数据库粗暴地返回前 20 条，好坏掺杂	大模型被噪音干扰
上下文被切断	一个完整的制度条款被切成了两半	大模型看到的是残篇，答案不完整
跨文档关联不上	"张三"在文档 A，"ERP 项目"在文档 B，两者关系在文档 C	大模型不知道这些信息之间有联系

这就是为什么需要下面这些"高级武器"。

---

四、BM25 —— 关键词检索的 “老兵不死”

BM25（全称 Okapi BM25，BM = Best Matching）是 1994 年诞生的经典算法，至今仍是全球所有搜索引擎（包括 Elasticsearch）的默认评分内核。它在 RAG 系统中扮演着"字面精准匹配"这一路的关键角色。

一句话理解

BM25 是一个只看字面、不懂语义的统计机器。它给每篇文档打一个相关性分数，分数高低取决于三个因素：

因素一：这个词有多"稀缺"？（IDF，逆文档频率）

如果一个词在所有文档里都频繁出现（比如"的"“了”“是”），它的权重就极低。
如果一个词非常罕见（比如"竞业限制"“NullPointerException”），它的权重就极高。

类比：在一个公司的规章制度库里搜"的"字，每份文档都有，没有任何区分度，这个词的权重就是零。搜"竞业限制"，只在 3 份文档里出现，这个词的权重就极高——只要命中，这篇文档大概率就是你要的。

因素二：这个词在文档里出现了多少次？（TF + 饱和度控制）

词出现得越多，这篇文档越相关。但不会无限加分，到一定程度就"饱和"了。

这是 BM25 相比它的前辈 TF-IDF 最关键的升级。在 TF-IDF 里，词频是线性增长的——如果一篇垃圾文档疯狂重复"年终奖"100 次，它的得分会是正常文档的 100 倍，轻松霸占第一名（这叫"刷词作弊"）。

BM25 通过引入了 k1 参数（通常设 1.2 ~ 2.0）来做饱和度控制：重复 5 次和重复 100 次，得分几乎一样。你刷不动。

因素三：这篇文档有多长？（长度归一化）

长文档天然包含更多词，所以在长文档里命中关键词"不算本事"，需要适当惩罚。

类比：在一本 10 万字的小说里找到"保密"两个字，不代表这本小说是讲保密的。但在一段 100 字的通知里找到"保密"，这篇通知大概率就是你要的。

BM25 通过 b 参数（通常设 0.75）来控制惩罚力度——b=1 表示按长度比例完全惩罚，b=0 表示不管长短一视同仁。

BM25 的优势和盲区

擅长	不擅长
型号、工号、法律条文编号的精确匹配	同义词：“差旅费"找不到"出差报销”
错误码 NullPointerException 一字不差地匹配	跨语言：“苹果手机"找不到"iPhone”
人名、地名、专有名词	模糊语义：“电脑卡顿"找不到"笔记本运行缓慢”
不会被刷词作弊（饱和控制）	理解否定：“不要走审批的请假方式”，它只看到"审批"和"请假"

---

五、Dense Embedding（稠密向量）—— 语义搜索的 “读心术”

如果说 BM25 是看"你说了什么字"，那 Dense Embedding 就是理解"你想表达什么意思"。它是现代 AI 搜索的核心技术，负责把文字翻译成机器能理解的"语义坐标"。

稀疏 vs 稠密：为什么要叫 “Dense”？

	稀疏向量（Sparse，如 BM25/TF-IDF）	稠密向量（Dense，如 Embedding）
维度	几万到几十万维（等于词典大小）	固定 768 / 1024 / 1536 维
值的分布	绝大多数位置是 0，只有命中的词有值	每一个位置都有非零值 ，共同编码语义
匹配原理	看有没有共同词	看语义坐标近不近

核心问题：计算机凭什么知道"苹果"和"iPhone"是一个意思？

这是每个人第一次接触 Embedding 时最困惑的问题。答案是：看一个词的"朋友圈"（上下文），而不是看这个词本身。

语言学里有一句名言："看一个词的邻居，就能知道它的含义。"大模型在训练时读了几千亿字的文本，它发现了一个规律：

"我昨天买了一部 iPhone，拍照很强，系统很流畅。""我昨天买了一部 苹果，拍照很强，系统很流畅。""库克在发布会上展示了最新的 iPhone。""库克在发布会上展示了最新的 苹果。"

久而久之，模型发现：“iPhone"和"苹果"这两个词，在天底下的文章里，身边出现的"邻居词”（库克、发布会、拍照、系统、屏幕、价格）几乎一模一样。 于是它在数学上把这两个词归到了同一个"朋友圈"。

标签游戏：用 4 个维度模拟真实模型

真实的大模型有 768 ~ 3072 个维度。为了便于理解，我们假设只有 4 个维度：

	是否电子产品？	是否水果？	价格高低？	科技属性？
iPhone	0.9	-0.9	0.8	0.9
苹果（公司）	0.8	-0.8	0.8	0.9
香蕉	-0.9	0.9	-0.7	-0.9

在高维空间里，iPhone 和苹果（公司）的坐标几乎重合，而香蕉躲在遥远的另一个角落。你用余弦相似度一算，iPhone 和苹果（公司）的相似度得分极高，香蕉则极低。

动态上下文：同样的词，不同的 Embedding

这是现代大模型相比十年前老技术最革命性的突破。

过去的老技术（Word2Vec 时代）：每个词只有一套固定的向量。"苹果"不管在什么句子里，永远是同一串数字。完全无法解决一词多义。

现在的大模型（Transformer 时代）：模型会先读完整个句子，用**注意力机制（Attention）**让周围的词去"修正"目标词的含义。

场景 A："多吃苹果对身体好"  → 模型注意到"吃""身体好" → 把【水果】【健康】维度拉满，【科技】维度清零场景 B："苹果下个月要开新品发布会"  → 模型注意到"新品""发布会" → 把【科技公司】【数码】维度拉满，【水果】维度清零

同一个词"苹果"，在不同句子里被赋予了完全不同的向量坐标。 这就是为什么你把一整段话输入 Embedding 接口时，吐出来的不是死板的字典释义，而是这段文字在当前语境下"活着的灵魂"。

维度到底要多少？

维度	梯队	典型模型	适用
384 ~ 768	轻量高效	BGE-small、BERT 标准版	端侧设备、海量数据低成本检索
1024	黄金性价比	Cohere Embed v3、BGE-large、阿里 GTE-large	企业级 RAG 首选 ，精度与成本最佳平衡
1536 ~ 3072	高精旗舰	OpenAI text-embedding-3-large	预算充足、语义要求极高的场景

黑科技：“动态裁剪”（Matryoshka 表征学习）

OpenAI 最新的 text-embedding-3 系列引入了一项技术：模型训练时，故意把最重要的语义特征压在向量的前几百个维度里，越往后越细腻。

这意味着你可以随意"砍掉"后面的维度：模型输出 3072 维，你只需要前 256 维或 1024 维，精度几乎不降。在 MTEB 评测上，被砍成 256 维的 v3-large，表现依然碾压当年 1536 维的旧款模型。

工程意义：调用最强模型 → 裁剪到 1024 维 → 存入向量数据库，在"理解能力"和"服务器账单"之间取得完美平衡。

---

六、多路召回 —— “兵分多路，广撒网”

理解了 BM25（字面路）和 Dense Embedding（语义路）之后，就可以讲清楚现代搜索系统的核心架构了。

为什么必须"多路"？

没有任何一种检索算法是完美的。如果只用一种：

• • 只用 BM25：搜"电脑卡顿"找不到"笔记本运行缓慢"→ 漏掉大量语义相关的结果
• • 只用向量检索：搜"404 错误码"可能因为过度联想，捞出一堆无关的网页开发教程 → 噪音淹没精准答案

多路召回的本质是"既要又要"——让不同算法优势互补，谁都别漏。

一个标准的多路召回架构

┌─→【第一路：BM25 关键词检索】──→ 捞出字面完全匹配的文档                 │  【用户提问】 ──┼─→【第二路：Dense Embedding 语义检索】→ 捞出意思相近的文档                 │                 └─→【第三路：知识图谱检索】──→ 捞出同一类别的关联实体                          │                          ▼                 【结果合并 + 去重】                          │                          ▼                 【Rerank 精排】──→ 选出 Top 3-5 喂给大模型

多路召回最棘手的问题：关公战秦琼

不同路返回的结果，分数不在同一个尺度上：

• • BM25 给文档 A 打了 18.5 分
• • 向量检索给文档 B 打了 0.92 分（余弦相似度）
• • 知识图谱给文档 C 打了 3 跳命中

这三个分数根本无法直接比大小。

解决方案：RRF（倒数排名融合）

RRF（Reciprocal Rank Fusion）是一种极其高效、不依赖模型的算法。它不看原始分数，只看排名：

RRF 得分 = Σ 1 / (k + rankᵢ)其中 k 是一个常数（通常取 60），rankᵢ 是该文档在第 i 路中的排名

例子：文档 A 在 BM25 路排第 1，在向量路排第 3，在知识图谱路排第 5。

RRF(A) = 1/(60+1) + 1/(60+3) + 1/(60+5)       = 0.0164 + 0.0159 + 0.0154       = 0.0477

三路排名汇总后重新洗牌，排名最高的文档胜出。简单、公平、不需要任何模型。

当然，更精细的做法是接一个 Rerank 模型做最终精排——这就是下一节要讲的。

一句话类比

多路召回就像企业招聘：HR 同时在招聘软件上用"关键词匹配"筛简历（BM25）、通过内部员工"熟人推荐"找气场相投的人（Embedding）、再通过"猎头指定"挖特定人才（知识图谱）。多管齐下，最后把所有候选人汇总到面试官（Rerank / 大模型）面前做最终选拔。

---

七、Rerank（重排序）—— 海选之后的"面试精选"

多路召回捞回来一堆候选（比如 15-20 篇），但质量参差不齐。Rerank 就是用更强的模型做第二轮精排。

两阶段检索架构

阶段	类比	目标	速度	精度
召回（Recall）	海选，快筛	从几十万篇里捞出 Top 50-100，“别漏掉”	快	一般
重排（Rerank）	复试，精选	从 50 篇里筛出 Top 3-5，“把最好的放前面”	较慢	高

为什么要 Rerank？两个硬理由

理由一：向量检索只看"神似"，不看"形似"。 它对否定词、精确关键词不敏感。比如用户问"不要走年假审批流程的请假方式"，向量检索可能把"年假审批流程"当成重点返回来，而 Reranker 能理解"不要"这个否定词的重要性。

理由二：大模型的"迷失在中间"（Lost in the Middle）现象。 如果你把 20 条资料直接塞给大模型，它往往只记住最开头和最结尾的，中间的关键信息会被忽略。Rerank 确保最精准的那几条排在最前面。

市面上有哪些 Rerank 模型？

重排模型的底层通常是交叉编码器（Cross-Encoder）——它会把你提的问题和每篇候选文档拼在一起，同时输入模型做深度比较。这比向量检索的成本高得多，但也准得多。

开源模型（适合私有部署）：

模型系列	特点
BAAI/bge-reranker 系列 （智源研究院）	中文及跨语言检索第一梯队。有 large（精度最高）、base（速度快）、v2-m3（支持长文本）等型号
Cohere Rerank	多语言效果出色，有开源版本
Jina Reranker	支持超长上下文（8K tokens），适合处理长段落

商业 API（免运维，开箱即用）：

Cohere Rerank API、硅基流动、阿里百炼、腾讯云等平台均集成了重排服务，按调用次数计费。

Rerank 工程的三个落地教训

1. 1. 不要对全部文档做 Rerank。 如果你的知识库有 1 万条文档，直接全量 Rerank，响应时间会从毫秒级飙升到几十秒。必须先粗筛到 100 条以内。
2. 2. 设置得分阈值。 如果粗筛捞出来的全是垃圾，Reranker 也只能"在矮子里拔将军"。设置一个硬性阈值，低于阈值直接回答"知识库未找到相关信息"。
3. 3. 算力不够时用小模型或 API。 没有 GPU 的情况下跑 bge-reranker-large 会很慢。优先评估商业 API，或在本地部署 bge-reranker-base 配合 ONNX Runtime 加速。

一句话总结

向量检索 + 多路召回 = 海选（快、糙、不漏）Rerank               = 精选（慢、精、去伪存真）海选从百万级捞 Top 50，精选从 50 条里筛 Top 3。先粗后精，性价比最高。

---

八、知识图谱（Knowledge Graph）—— 从"查字典"到"查族谱"

传统 RAG 的根本缺陷

传统 RAG 把文档切成一个个文本块（Chunk），存进数据库。每个块之间没有显式关联。

这就像一个图书馆把所有的书都撕成了小纸条，每张纸条上写了一段话。你查找时，AI 去找最相关的纸条，拼起来给你答案。

致命问题：如果一条信息分散在多张纸条上怎么办？

真实例子：你问"张三参与了公司的哪些项目？"

• • 纸条 A：“张三，技术部高级工程师”
• • 纸条 B：“ERP 升级项目由技术部牵头，主要参与人……”（没提张三）
• • 纸条 C：“2025 年优秀项目奖授予张三（ERP 升级项目）”

传统方法可能只找到 A 和 C，漏掉了 B 和整个技术部的项目关联。因为纸条之间没有连线——AI 不知道"技术部"这个关键词连接了张三和 ERP 项目。

知识图谱的解决思路

知识图谱把知识组织成**实体（节点）+ 关系（边）**的网络：

┌──────┐  属于    ┌──────────┐        │ 张三  │────────→│  技术部    │        └──┬───┘          └────┬─────┘           │ 参与               │ 牵头           ▼                    ▼        ┌──────────────┐  ┌──────────────┐        │ ERP 升级项目   │  │  AI 中台项目   │        └──────┬───────┘  └──────────────┘               │ 获得               ▼        ┌──────────────┐        │ 2025年优秀项目奖│        └──────────────┘

查询时，AI 在图上沿着关系边一步一步走（这叫"多跳推理"）：张三 → 技术部 → 参与的项目 → ERP 升级项目、AI 中台项目……所有关联信息被自动串联起来。

核心类比：传统 RAG 像查字典（按词条找定义），知识图谱 RAG 像查族谱（从一个名字出发，沿着关系线摸清所有关联）。

三种检索粒度（LightRAG 的核心创新）

模式	做什么	适合什么问题	类比
Local（局部检索）	从具体实体出发，沿关系边找邻居，向下钻取细节	“张三参与了哪些项目？”“保密协议第 7 条是什么？”	了解一个人的朋友圈
Global（全局检索）	对整个知识网络做社区检测和摘要总结，向上抽象主题	“公司技术部的整体业务方向是什么？”“这次合规审计的总体风险点在哪？”	看一个组织的全景地图
Hybrid / Mix（混合）	Local + Global + 向量检索三者融合	绝大多数实际查询	既要个人档案，也要部门背景，还要相关文档片段

“Light” 的由来 —— 对比微软 GraphRAG

微软的 GraphRAG 虽然强大，但构建图谱时需要生成庞大的"社区报告"（Community Reports），Token 消耗巨大、算力极贵、且无法增量更新。

LightRAG 抛弃了这些笨重的操作，用向量直接定位图节点，支持增量更新（新增一个文档，只局部织网，不用全网重建）。能耗和延迟都远低于微软方案，效果却不输，所以叫"Light"。

---

九、三款开源 RAG 产品横评 —— RAGFlow vs LightRAG vs Dify

这三个产品代表了 RAG 领域三个完全不同的演进方向。它们不是你死我活的竞争关系，而是互补关系。

速览对比

维度	RAGFlow	LightRAG	Dify
一句话定位	重型文档处理工厂	轻量级知识图谱引擎	完整的 AI 应用搭建平台
核心武器	自研深度学习模型做文档解析 + Agent 工作流	知识图谱原生检索（6 种模式）+ 极轻量	可视化工作流编排 + 完整产品生态
知识图谱	内置 GraphRAG（可选模块），支持三种抽取方案	核心能力 ，架构第一天就以图谱为中心	不支持
文档解析	工业级碾压 ：自研版面识别 + 表格结构识别 + OCR 三个神经网络模型	依赖外部引擎（MinerU / Docling）	基础提取，对复杂排版无能为力
检索模式	向量 + BM25 混合检索 + GraphRAG 补充	6 种 ：naive / local / global / hybrid / mix / bypass	3 种：语义 / 全文 / 混合
Agent 能力	25+ 组件 + 25+ 工具的可视化 DAG 工作流画布	无	可视化工作流编排
部署难度	重：需要 MySQL + ES + Redis + MinIO 等 6+ 服务	极轻 ：pip install 即用，零外部依赖	中等：PG + Redis + Worker + 向量 DB
企业级特性	多租户、RBAC 权限、文档审批流、OpenTelemetry 审计	基础 API Key / JWT 认证	最完善 ：租户→工作空间→成员，33+ 向量库
适合场景	复杂文档（合同/财报/扫描件）+ 需要 Agent 自动化	跨文档关系推理 + 快速原型 + 嵌入现有系统	快速搭建面向用户的 AI 产品

三者的角色类比

RAGFlow  = 印刷厂 —— 擅长把各种格式、各种质量的原始文档           加工成干净、结构化、可检索的内容LightRAG = 侦探   —— 擅长在大量信息之间建立关联网络，           做跨文档、跨段落的推理和串联Dify     = 购物中心 —— 把各种能力整合在一起，           给用户一个完整的产品体验

最佳实践：不是三选一，而是各取所长

┌────────────────────────────────────────┐│            Dify（产品层）                ││  工作流编排 + 用户前端 + 权限管控        ││    │                │                  ││    ▼                ▼                  ││  调用 RAGFlow      嵌入 LightRAG       ││  （复杂文档解析）   （轻量图谱检索）      │└────────────────────────────────────────┘

RAGFlow 做深度解析和知识图谱索引，Dify 做产品化封装和编排，LightRAG 作为轻量级图谱检索组件嵌入特定场景。

---

十、重点：RAGFlow 已经原生支持知识图谱，且已引入 LightRAG

这是目前开源社区最值得关注的融合趋势——这两个项目不是对手，RAGFlow 已经把 LightRAG "吃进去"了。

RAGFlow 的知识图谱有三种实现方案

在 RAGFlow 的分块配置中，你可以选择"提取知识图谱"作为分块方法。底层的 rag/graphrag/ 模块源码中明确引用了两家来源：

Reference:  - graphrag (微软/GraphRAG)  - LightRAG (HKUDS/LightRAG)

它提供了三套并行的知识图谱提取方案，用户可以自选：

方法	来源	原理	特点
Light	HKUDS/LightRAG	LLM 抽取实体 + 关系，轻量 Prompt	默认方法，Token 消耗少，速度快
General	微软/GraphRAG	LLM 抽取 → Leiden 社区发现 → 社区摘要	重量级，适合深度主题分析
NER	spaCy 预训练模型	基于规则 + 预训练 NER，零 LLM 参与	速度最快，零 API 成本

RAGFlow 图谱检索的完整链路

用户问题  ↓① 查询改写（LLM 提取实体词 + 类型关键词）  ↓② 向量召回实体 + 按类型精确过滤实体 + 向量召回关系  ↓③ N-hop 多跳扩展 —— 沿图谱发现关联实体（带路径 + 权重）  ↓④ 社区检索 —— 召回社区摘要（仅 General 方法适用）  ↓⑤ PageRank × 向量相似度综合排序  ↓⑥ 实体 + 关系转结构化上下文，注入 LLM 生成答案

和 LightRAG 原版的差距（也是后续优化方向）

维度	RAGFlow 当前	LightRAG 原版	改进空间
图存储	实体/关系作为特殊 Chunk 存 ES	原生图数据库（Neo4j / NetworkX / Memgraph）	无法做真正的图遍历，N-hop 靠预计算
查询模式	单一 KG 向量召回	6 种独立模式（local/global/hybrid/mix/naive/bypass）	缺少社区级全局和实体级局部的独立控制
增量更新	变更后全量重建	增量追加，保留已有图结构	大文档集重建成本高
Chunk 回填	无——实体描述本身就是检索结果	KG 结果反向映射到原文 Chunk	缺少原文溯源
角色 LLM	统一 LLM 配置	4 种角色独立 LLM（extract/query/keywords/vlm）	不能用便宜模型抽取、强模型回答

一句话总结这个融合

你可以直接在 RAGFlow 的可视化界面和工作流中，享受 LightRAG 带来的低成本知识图谱能力。 RAGFlow 提供平台底座（深度解析 + 管理后台 + Agent），LightRAG 算法提供高效图谱构建——强强联合。

---

十一、一个完整的检索链路长什么样？

把上面所有概念串起来，看一个真实的法律合同查询案例：

用户问：“我们公司的保密协议里，员工离职后保密义务持续多久？”

第 1 步：查询改写（Query Rewrite）  LLM 将问题优化为检索关键词：  → "员工 离职 保密义务 期限 竞业限制 保密协议"第 2 步：多路召回（并行执行）  ├─ BM25 关键词路    → 找到 8 篇包含"保密""离职""义务"的文档  ├─ 向量语义路       → 找到 5 篇讲"员工离职后权利义务"的文档  └─ 知识图谱路       → 从"保密协议"实体出发，沿关系边多跳扩展                        "离职 → 保密义务 → 期限 → 竞业限制"  → 三路去重合并，共 15 篇候选第 3 步：Rerank 精排  用 BGE-Reranker 对 15 篇候选做精细对比打分  → 取 Top 5 最精准的，剩余丢弃第 4 步：组装上下文 + 生成回答  将 Top 5 文档 + 问题打包发给大模型  → AI："根据《保密协议》第 7 条，员工离职后保密义务     持续到相关信息进入公共领域为止。竞业限制期为     离职后 2 年，期间公司按月支付补偿金。"第 5 步：溯源标注  每个结论后标注来源文档名、条款号、相关段落，  确保用户可以点回去验证。

---

十二、RAG vs 微调（Fine-tuning）到底怎么选？

很多企业做 AI 落地时最纠结的一个问题。

	微调（Fine-tuning）	RAG
类比	让大模型去考医学院、考法学院——改变的是底层的知识结构和表达风格	给大模型一本《公司规章手册》——不改变模型本身，只提供实时查阅的资料
成本	高（需要标注数据 + GPU 训练）	低（建好知识库即可）
更新速度	慢（每次更新要重新训练）	快（新增/修改文档即时生效）
适用场景	培养特定领域的专家（如法律文书写作风格、医学诊断逻辑）	查阅私域文档、解决时效性问题
本质差异	改变"脑子"	提供"参考书"

结论：90% 的企业级知识库、AI 助手项目，首选且核心的技术都是 RAG。微调是 RAG 做不好时的"升级手段"，不是替代方案。

---

十三、核心概念速查表

概念	一句话解释	类比
RAG	先查资料再回答，而不是靠脑子硬记	开卷考试
Embedding（向量化）	把文字转成一串数字，语义相近的数字也相近	给每段话拍一张"语义指纹"
Dense Embedding	固定维度、每个位置都有值的稠密向量，理解语义而非字面	给文字发一个 GPS 坐标，意思相近的靠得近
BM25	纯关键词匹配算法，按词频 + 稀有度 + 文档长度综合打分	图书管理员：知道哪些词稀有、哪些文档太长不值钱
向量检索	用数学算语义相似度来找文档	按"大概意思"搜，不是按字面搜
混合检索	BM25 + Dense Embedding 同时跑，结果融合	两条腿走路，一条看字面一条看语义
多路召回	多种检索方式并行，各路取 Top N 汇合	HR 同时用关键词筛简历、熟人推荐、猎头挖人
RRF	不看原始分数看排名，多路结果公平融合	评委打分标准不同，那就比排名不比分数
Rerank（重排）	对粗筛结果做第二轮精细打分	海选 → 复试 → 决赛
知识图谱	把知识织成"实体-关系"网，沿边游走发现关联	查族谱而不只是查字典
Local 检索	从具体实体出发，向下钻取细节	了解一个人的朋友圈
Global 检索	对全网络做社区总结，向上抽象主题	看一个组织的全景图
GraphRAG	RAG + 知识图谱的结合体	既有字典，也有族谱
Matryoshka 表征学习	Embedding 维度可裁剪，前 256 维就包含主要语义	俄罗斯套娃，最外面的壳已经够用了
RAGFlow	重型文档处理 + Agent 平台，强在解析	印刷厂 + 自动化车间
LightRAG	轻量图谱 RAG 库，强在关系推理和低开销	侦探 + 瑞士军刀
Dify	完整 LLM 应用平台，强在产品化和编排	购物中心，一站式

学AI大模型的正确顺序，千万不要搞错了

🤔2026年AI风口已来！各行各业的AI渗透肉眼可见，超多公司要么转型做AI相关产品，要么高薪挖AI技术人才，机遇直接摆在眼前！

有往AI方向发展，或者本身有后端编程基础的朋友，直接冲AI大模型应用开发转岗超合适！

就算暂时不打算转岗，了解大模型、RAG、Prompt、Agent这些热门概念，能上手做简单项目，也绝对是求职加分王🔋

📝给大家整理了超全最新的AI大模型应用开发学习清单和资料，手把手帮你快速入门！👇👇

学习路线:

✅大模型基础认知—大模型核心原理、发展历程、主流模型（GPT、文心一言等）特点解析
✅核心技术模块—RAG检索增强生成、Prompt工程实战、Agent智能体开发逻辑
✅开发基础能力—Python进阶、API接口调用、大模型开发框架（LangChain等）实操
✅应用场景开发—智能问答系统、企业知识库、AIGC内容生成工具、行业定制化大模型应用
✅项目落地流程—需求拆解、技术选型、模型调优、测试上线、运维迭代
✅面试求职冲刺—岗位JD解析、简历AI项目包装、高频面试题汇总、模拟面经

以上6大模块，看似清晰好上手，实则每个部分都有扎实的核心内容需要吃透！

我把大模型的学习全流程已经整理📚好了！抓住AI时代风口，轻松解锁职业新可能，希望大家都能把握机遇，实现薪资/职业跃迁～

这份完整版的大模型 AI 学习资料已经上传CSDN，朋友们如果需要可以微信扫描下方CSDN官方认证二维码免费领取【保证100%免费】