RAG 从原理到落地理论
大模型局限性
如果一次性把企业文档各种记录扔给大模型，动辄可能几十万字的输入：
- 上下文窗口限制
- 推理成本高
- 响应速度慢
RAG 核心工作流程
一、整体框架
检索 ---> 增强 ---> 生成RAG（Retrieval-Augmented Generation，检索增强生成）可以拆成两条线来理解：
- 数据准备阶段（业务线）——把业务数据变成可检索的向量
- 回答生成阶段（用户线）——用户提问后，检索相关片段并生成回答
二、数据准备阶段（业务线）
1. 流程概览
业务数据 ---> Chunking（分片） ---> Chunks ---> Embedding 模型 ---> 向量2. 分片（Chunking）
- 切分方式：可以按照字数 / 段落 / 章节切分
- 分片目的：将长文档转化为易于管理的碎片，克服大模型“吃不下”长文的难题
3. 索引（Indexing）
分片 ---> 索引（Indexing）分片之后需要建立索引，方便后续快速检索。
4. 理解 Embedding
将文字“翻译”为高维坐标。
核心逻辑：文本被转化为高维空间中的向量点后，语义相近 = 空间距离近。
坐标系示意
Y
↑
| [小坛爱吃西瓜] (红框)
| 🟢 🔵
| [小坛喜欢吃水果] (红框)
| (两点距离很近)
|
<-------+----------------------------→ X
|
|
| 🟡
| [长沙天气怎么样]
| (距离上方点很远)
|图中要素解析
| 元素 | 说明 |
|---|---|
| 坐标轴 (X, Y) | 代表多维向量空间中的两个维度（实际应用中通常是几百到上千维）。 |
| 彩色圆点 (🟢🔵🟡) | 代表经过 Embedding 模型转换后的文本向量。 |
| 红框文本组 | 「小坛爱吃西瓜」与「小坛喜欢吃水果」。虽然字面不完全相同，但语义高度相似（都是关于“吃”和“水果/西瓜”），所以它们在空间中的距离非常近。 |
| 黄点文本 | 「长沙天气怎么样」。与上方文本主题（饮食）完全无关，因此它在空间中的位置距离很远。 |
核心结论（笔记重点）
- 语义向量化：计算机无法直接理解文字，需要将文本通过 Embedding 模型映射为高维空间中的向量点。
- 距离即相似度：向量空间中的距离（如余弦相似度、欧氏距离），可以用来衡量文本之间的语义相似度。
RAG 检索原理：
- 当用户提问时，系统将问题转化为向量。
- 在向量数据库中，寻找与问题向量距离最近的文档向量（即最相关的知识片段）。
- 距离越近，代表语义越相关，越应该被召回作为大模型的上下文。
- Embedding：将文字转化为向量
- 向量数据库：存储“向量 + 原始文本”的对照表
- 核心直觉：在高维坐标系中，距离越近的向量，语义越相近
三、回答生成阶段（用户线）
1. 流程概览
用户 ---> 问题 ---> Embedding 模型 ---> 向量 ---> 向量数据库RAG 回答生成阶段（完整流水线）
核心逻辑：这张图展示了 RAG 在“回答生成阶段”的完整闭环流程。用户提问后，系统通过向量检索找到相关上下文，最后连同问题一起交给大模型（LLM）生成回答。
流程图示意
[用户]
│
│ 提问
▼
[问题]
│
│ 输入
▼
[Embedding模型]
│
│ 向量化
▼
[向量]
│
│ 检索
▼
[向量数据库]
│
│ 匹配
▼
[Context]
│
│ 拼接
▼
[问题 + Context]
│
│ 输入
▼
[LLM]
│
│ 生成
▼
[Response]
│
└──► 返回给 [用户]图中各环节解析
用户：发起提问的起点，是整个流水线的触发者。
问题：用户输入的自然语言问题，作为后续检索和生成的输入。
Embedding 模型：将“问题”转化为计算机能理解的向量形式。图中标注为 Embedding模型。
向量：问题经过 Embedding 后的数学表示，是一个高维空间中的点。
向量数据库：存储了知识库中所有文档的向量。系统用“问题向量”去这里做相似度检索，找出最相关的文档片段。
Context（上下文）：从向量数据库中召回的、与问题最相关的知识片段。它是 RAG 的“外部知识来源”。
问题 + Context：将原始问题和召回的知识片段拼接在一起，形成完整的 Prompt 输入给 LLM。
LLM（大语言模型）：接收“问题 + Context”，基于这些信息生成最终的回答。
Response（回答）：LLM 生成的答案，最终返回给用户，完成整个 RAG 闭环。
核心结论（笔记重点）
RAG 回答生成阶段 = 检索 + 生成：
- 检索：问题 → 向量 → 向量数据库 → Context
- 生成：问题 + Context → LLM → Response
为什么需要 Context：LLM 本身的知识有限且可能过时，通过检索外部知识库，可以让 LLM 基于最新、最相关的事实来回答，减少幻觉。
完整闭环：从用户提问，到向量检索，再到 LLM 生成，最后返回用户，形成一个完整的 RAG 流水线。图中字幕“你看这就是 IG 完整的流水线”中的“IG”应为口误或识别错误，实际指的是 RAG。
2. 两个关键动作：召回 + 合成
RAG 检索与生成核心链路
核心逻辑：这张图是对 RAG 流程的高度抽象简化版，重点突出了“计算相似度”这一核心检索步骤，并展示了用户提问、检索、生成、返回的完整链路。
流程图示意
text
[用户提问] ─────────────────────────────────────────────┐
│ │
│ 输入 │
▼ │
[计算相似度 (余弦/欧式)] │
│ │
│ 匹配 │
▼ │
[相关文档片段] │
│ │
│ 输入 │
▼ │
[大模型] ◄──────────────────────────────────────────────┘
│ (用户原始提问作为上下文一并输入)
│ 生成
▼
[大模型最终回答]图中各环节解析
用户提问：整个流程的起点，同时也是后续输入给大模型的重要上下文之一。图中有一条线从“用户提问”直接连接到“大模型”，表示原始问题会与检索到的文档一起送入模型。
计算相似度（余弦/欧式）：RAG 检索的核心步骤。将用户问题转化为向量后，与向量数据库中的文档向量进行相似度计算。图中标注了两种常用度量方式：
- 余弦相似度：衡量两个向量方向的夹角，关注方向上的相似性，常用于文本语义匹配。
- 欧式距离：衡量两个向量在空间中的直线距离，关注位置上的接近程度。
相关文档片段：经过相似度计算后，筛选出的与用户问题最相关的文档内容。这些片段作为外部知识，用于补充大模型的知识盲区。
大模型：接收两个输入：
- 用户原始提问（从上方直接传入）
- 检索到的相关文档片段（从左侧传入）
大模型基于这两部分信息，生成最终回答。
大模型最终回答：整个 RAG 流程的输出结果，返回给用户。
- 召回（Retrieval）：在向量数据库中计算相似度，找出最相关的 Top-k 个片段
- 生成（Generation）：把召回片段交给大模型，指令为“根据这 Top-k 个片段回答，别瞎编”
四、一句话总结
RAG = 先把知识切片、向量化、存进向量库；用户提问时，用同样方式把问题向量化，召回最相似的片段，再让大模型基于这些片段生成答案。
商业化落地实战痛点
实现的挑战：从Demo到商业交付
原理很通透，落地全是坑
基础RAG流程逻辑很丝滑，但在实际商业场景中往往面临答非所问/找不到资料的致命问题。如果不解决细节，上线即失败。
痛点1：文档解析
真实业务场景需要面临各种文档格式，PDF、Word等等，包含许多排版错乱表格
- 解决方案：专用版面分析模型+OCR+人工复核反馈（RLHF），文档解析是AI落地的第一道门槛
补充：什么是 RLHF？
RLHF（Reinforcement Learning from Human Feedback，基于人类反馈的强化学习）是一种让模型“对齐人类偏好”的训练方法。核心思路是：
- 人类标注：让人对模型输出的多个结果进行排序 / 打分
- 训练奖励模型：用这些偏好数据训练一个“打分器”，学会判断什么样的输出更好
- 强化学习微调：用奖励模型的分数作为信号，引导大模型生成更符合人类期望的结果
在文档解析场景中，可以理解为：人工复核解析结果，把“哪里解析错了、正确应该是什么”反馈给系统，用来持续优化版面分析与 OCR 模型，让解析越来越准。
痛点2：颗粒度
如何切片
- 切太大=噪音多；切太小=语义丢失。需要根据业务场景大量测试分片策略
举例展开：
假设一份员工手册里有一条规定：“年假天数根据工龄计算：满 1 年 5 天，满 3 年 10 天，满 5 年 15 天。”
- 切太大：把整章“休假制度”作为一个 chunk，里面还包含病假、婚假、产假……用户问“年假几天”，召回的是几千字的大段落，噪音极多。
- 切太小：只切出“满 3 年 10 天”这一句，用户问“年假怎么算”，模型不知道这是年假规则，也不知道工龄档位，语义丢失。
- 合理做法：按“条款”粒度切分，保留小标题和上下文，必要时加 重叠（overlap），让每个 chunk 既完整又不臃肿。
痛点3：检索准确率
- 检索准确率决定RAG结果生死
朴素RAG检索准确率大概只有60%
可以混合检索（用向量去找也用传统关键词去找，然后进行重排模型给找出来的片段重新打分）
用户问题 ---> 向量检索 ---┐
├---> 重排模型 ---> Top-k 片段
用户问题 ---> 关键词检索 ---┘痛点 4：用户提问的模糊性
- 针对口语化、指代不明、语义模糊的提问，结合上下文进行信息补全与意图重构，是确保查询可执行的关键步骤。
举例：
“哪些货快没了，赶紧补” | v Query Rewrite（查询重写） | v “检索全国仓可售天数 < 15 天的 A 类商品，排除在途库存，按缺货风险生成补货单”
- 核心结论：用户说的是“人话”，系统要把它翻译成“机器能执行的查询”。
大模型选型与评估标准
- 逻辑推理能力
- 指令遵循能力
- 防幻觉能力
- 并不是所有的模型都适合做RAG，需建立系统化评估框架
进阶方案与总结
进阶方案：GraphRAG与Agentic RAG
补充理解：
- GraphRAG：在传统向量检索之外，引入知识图谱。把文档中的实体、关系抽出来建成图，检索时沿着图结构找关联信息。适合需要多跳推理、全局总结的场景（比如“这家公司所有子公司的风险点有哪些”）。
- Agentic RAG：把 RAG 交给 Agent（智能体） 来调度。Agent 可以自己决定“要不要检索、检索几次、换什么查询词、用哪个工具”，把单次检索变成多轮自主决策的过程。适合复杂、开放的任务。
总结：真正的壁垒在于工程细节
RAG 冰山模型
核心隐喻：RAG 框架的搭建看似简单（水面上），但真正的难点和核心工作量在于底层的工程优化（水面下）。
/\
/ \
/ \ <-- 水面之上 (可见部分)
/______\ 【RAG Framework / Demo】
~~~~~~~~
/ \
/ \ <-- 水面之下 (隐藏的庞大工程)
/ \ 【数据清洗、分片策略、多路召回、工程调优】
/______________\水面之上（冰山一角）：RAG Framework / Demo
- 含义：指的是 RAG 的基础流程框架或快速演示原型。
- 特征：通常只需调用现成的库（如 LangChain、LlamaIndex），连接大模型和向量数据库，几十行代码就能跑通一个“看起来能用”的 Demo。
- 陷阱：很多人误以为这就是 RAG 的全部，但往往在实际业务中效果不佳。
水面之下（冰山主体）：核心工程挑战
这部分才是决定 RAG 系统能否真正落地、能否精准回答问题的关键。图中列出了四个核心模块：
数据清洗 (Data Cleaning)
- 逻辑：原始文档（PDF、Word、HTML）往往包含大量噪音（页眉页脚、乱码、无关表格、格式错乱）。
- 目的：将非结构化数据转化为干净、可读、语义连贯的文本，这是高质量检索的基石。
分片策略 (Chunking Strategy)
- 逻辑：如何将长文档切分成适合向量化的小块（Chunk）。
- 目的：切得太碎会丢失上下文，切得太大会导致检索噪音大。需要根据文档类型（如代码、论文、合同）设计固定长度、重叠切分或语义切分策略。
多路召回 (Multi-route Recall)
- 逻辑：单一向量检索（Dense Retrieval）往往不够。
- 目的：结合关键词检索（BM25/Sparse）、向量检索、甚至知识图谱检索。通过多路召回融合（如 RRF 算法），提高相关文档的召回率和覆盖面。
工程调优 (Engineering Optimization)
- 逻辑：涉及整个系统的性能与效果迭代。
- 目的：包括 Embedding 模型微调、重排序（Rerank）模型引入、Prompt 模板优化、检索参数调整（Top-K）、以及系统延迟和并发处理等。
- 能够独立解决这些“脏活累活”，才是商业落地的核心价值所在