TL;DR：RAG（Retrieval-Augmented Generation，检索增强生成）不是“把模型变聪明”的魔法，而是给模型加上一套“先查资料、再组织答案”的外部记忆系统；在真实项目里，效果往往更取决于数据清洗、切块、检索、重排和评测，而不只是模型名字。
先把范围说清楚
- 适用范围：本文聚焦文本型知识库问答、企业知识助手、文档问答这类最常见的 RAG 场景
- 读者前置知识：知道“大模型能聊天”就够了，不要求你先懂向量数据库
- 本文不覆盖：底层数学推导、所有论文细节、所有框架 API
读完你能带走什么
- 你会真正搞懂：RAG 到底是什么，不是什么
- 你会分清：经典 RAG、增强型 RAG、GraphRAG、Self-RAG、CRAG、Agentic RAG 分别在干嘛
- 你会知道：调优时先抓哪些地方最值，哪些地方最容易白忙
- 你会建立一个很重要的直觉：RAG 的问题，很多时候不是“模型不够强”，而是“资料没找对”
开场：为什么大家都在聊 RAG
你让大模型回答“公司 2024 年差旅报销上限是多少”，它可能一本正经地编一个数字；你让它总结内部产品手册，它又根本没见过那份文档。于是问题来了：模型本身很会“说”，但它未必“知道”，更不保证“知道的是你现在要它知道的东西”。
这就是 RAG 出场的原因。哼，这名字看着有点学术，拆开以后其实很乖：先去你的知识库里找相关资料，再把这些资料塞给模型，让它依据证据回答，而不是靠参数记忆硬猜。这样一来，私有知识、最新知识、可引用证据这三件事，就都开始变得可落地了 (๑•̀ㅂ•́)و✧
一句话先讲明白
人话版：
- RAG = 先检索资料，再让大模型根据资料生成答案。
稍微严谨一点的版本：
- RAG 是把“大模型的生成能力”和“外部知识库的检索能力”拼在一起的一种系统设计。
- 大模型负责理解问题、组织语言、综合答案。
- 检索系统负责从外部文档里把最相关的证据找出来。
你可以先记一个心智模型：
- 大模型像一个表达能力很强的学生。
- 知识库像一本允许带进考场的资料。
- Retriever（检索器）像图书管理员。
- Reranker（重排器）像一个二次筛选的助教。
- 最终答案，是“看着资料写出来”的，而不是“凭印象背出来”的。
关键术语速览
| 术语 | 一句话解释 | 常见误解/陷阱 |
|---|---|---|
| RAG | 先检索再生成的系统方案 | 不是一种单独模型，更不是某个固定框架 |
| Chunk | 切分后的文档片段 | 切得越细不一定越好，可能把上下文切碎 |
| Embedding | 把文本表示成向量，便于相似度检索 | 有 embedding 不代表检索一定准 |
| Vector DB | 存向量并做相似搜索的数据库/索引 | 做 RAG 不一定非得上“独立向量库” |
| BM25 / Keyword Search | 基于关键词匹配的传统检索 | 传统检索没有过时，很多场景非常重要 |
| Hybrid Search | 关键词检索 + 向量检索一起用 | 很多人一上来只做向量检索，效果反而一般 |
| Reranker | 对初筛结果做更精细排序 | 没有 rerank，Top-K 里很容易混入噪声 |
| Recall@K | 前 K 个结果里，是否把该找的证据找回来了 | 只看最终答案，会把检索问题误判成生成问题 |
| Faithfulness | 回答是否忠于给定证据 | “说得像真的”不等于“确实有依据” |
| Metadata | 文档的时间、部门、标题、权限等附加信息 | 不用 metadata，很多检索会又慢又歪 |
这东西到底解决什么问题
RAG 最擅长解决这几类问题：
- 私有知识：比如公司制度、产品文档、项目周报、内部 FAQ
- 最新知识：比如最近几个月才更新的规则和文档
- 可追溯回答：希望答案能对应到原文证据，而不是空口胡说
- 高频问答自动化：把“找资料 + 组织答案”这件事交给系统
它不擅长或者说不一定最优的场景，也要顺手记住：
- 纯风格任务：比如“把我的文案写得更口语”，这更像提示词或微调问题
- 超小知识库：如果资料本来就很少、能直接塞进上下文，未必要上完整 RAG
- 强事务/强计算任务：如果任务核心是调用工具、执行流程、精确计算，RAG 可能只是配角
- 证据根本不存在：资料库里没有答案时，RAG 也变不出来真相
它是怎么跑起来的
图 1：整体流程
flowchart TD
A[用户提问] --> B[查询预处理: 改写/补关键词/加过滤条件]
B --> C[检索: 向量检索、关键词检索或混合检索]
C --> D[重排: 挑出最相关的少量证据]
D --> E[上下文组装: 拼成给模型看的提示]
E --> F[LLM 生成答案]
F --> G[带引用回答或明确说证据不足]
这张图表达的是 RAG 的最常见主链路：先找，再筛，再答。最关键的不是“把所有可能相关的东西都喂进去”，而是把“真正有用的少量证据”交给模型。很多系统失败，不是败在模型不会说，而是败在前面两步把噪声也一起塞进去了。这个坑很会装无辜，线上一炸就知道它有多坏。
图 2：关键交互时序
sequenceDiagram
autonumber
participant U as User
participant A as RAG App
participant R as Retriever
participant K as Knowledge Base
participant X as Reranker
participant L as LLM
U->>A: 提问
A->>R: 发送查询
R->>K: 检索候选片段
K-->>R: 返回候选结果
R-->>A: 初筛结果
A->>X: 对候选结果重排
X-->>A: 返回高相关证据
A->>L: 问题 + 证据 + 规则
alt 证据充分
L-->>A: 基于证据生成答案
else 证据不足
L-->>A: 返回不知道/需要更多信息
end
A-->>U: 最终回答
这张图强调的是“系统边界”：App 不只是把问题原封不动丢给模型，它还要负责调检索、做过滤、做重排、控制上下文。最容易“看起来没问题但其实错了”的地方，是检索已经偏题，模型却还能写出一段非常顺滑的话。排查时应该先看 Top-K 结果和最终 prompt，而不是第一时间怀疑模型参数。
关键机制：把它拆成两大阶段就够了
1. 建库阶段（离线）
- 解析文档：PDF、网页、表格、Markdown、知识库页面
- 清洗文档：去掉页眉页脚、重复导航、版权噪声、无意义模板文本
- 切块：把长文切成可检索的小片段
- 生成索引：做关键词索引、向量索引，顺手存 metadata
2. 问答阶段（在线）
- 处理问题：改写 query、识别时间范围、加过滤条件
- 检索候选：向量、关键词或混合检索
- 结果重排：让真正相关的片段排到前面
- 组织上下文：把有限的高质量证据喂给模型
- 生成答案：要求模型只根据证据回答，必要时拒答
你会发现，RAG 其实更像一个“搜索 + 生成”的系统工程，而不是某个神奇单点算法。这个认知很重要，真的。
打个类比帮你记住它
把 RAG 想成“开卷考试”。
- 不带资料进考场：靠死记硬背，这更像纯大模型参数记忆
- 带了一堆资料但没目录：翻半天找不到，这像差检索
- 资料找对了，但把十几页全部塞给学生：他也会慌，这像上下文污染
- 资料找得准、页码清楚、重点高亮：这时候生成答案才会稳
类比的边界也要讲清楚：现实里的 LLM 并不是“真正看懂书的学生”，它是在做条件生成。所以它依然会受 prompt、上下文顺序、证据噪声、模型能力影响。别把“开卷”误会成“绝对不会答错”。
目前主流有哪些 RAG
先给你一个最容易记的框架：
- 如果按工程复杂度看，可以从
经典 RAG -> 增强型 RAG -> 自适应/Agentic RAG这样记 - 如果按学术综述看，常见会把它们分成
Naive RAG、Advanced RAG、Modular RAG - 如果按处理链路看，调优通常分成
检索前、检索中、检索后、生成时
下面这张表，你拿来当“地图”最合适：
| 路线 | 核心想法 | 适合场景 | 代价/风险 |
|---|---|---|---|
| 经典 RAG（Classic / Naive RAG） | 用户一问，系统直接去检索，再把结果塞给模型回答 | 文档问答、FAQ、知识助手入门版 | 简单，但容易受切块和检索误差影响 |
| 增强型 RAG（Advanced RAG） | 加入 query 改写、混合检索、metadata 过滤、reranker 等组件 | 大多数正式项目 | 效果通常明显更好，但链路更复杂 |
| 模块化 RAG（Modular RAG） | 把检索、压缩、过滤、生成等拆成多个可替换模块 | 需要长期迭代的工程系统 | 设计更灵活，也更考验评测体系 |
| Self-RAG | 让模型自己决定要不要检索，并对答案做自我反思/批评 | 复杂问答、证据不稳定、需要自检 | 成本更高，流程更长 |
| CRAG（Corrective RAG） | 先判断检索结果靠不靠谱，不靠谱就纠偏或走补救链路 | 检索质量波动大的场景 | 需要额外的“检索质量评估器” |
| GraphRAG | 把文档里的实体、关系、社区结构建成图，再做局部或全局检索/总结 | 跨文档关系分析、全局总结、复杂实体关联 | 建图成本更高，索引流程更重 |
| RAPTOR | 先把文档做树状摘要，再在不同层级上检索 | 长文档、多层级总结、既看细节又看全局 | 预处理较重，适合高价值知识库 |
| LightRAG | 用更轻量的图结构和双层检索兼顾速度与效果 | 想要图式增强，但预算有限 | 生态还在快速演化，要谨慎验证 |
| Agentic RAG / Agentic Retrieval | 让 agent 把复杂问题拆成子问题，分步检索、综合、必要时调用工具 | 多跳推理、复杂调研、长任务 | 成本、延迟、可控性压力都更大 |
| Multimodal RAG | 检索对象不只是文本，还可能包括图片、图表、截图、PDF 页面 | 手册、票据、设计图、图文混合资料 | 解析和索引难度明显更高 |
如果你现在是入门者，我建议你这样记：
- 第一层：先把
经典 RAG做通 - 第二层：再补
混合检索 + metadata + rerank - 第三层：最后再理解
GraphRAG / Self-RAG / Agentic RAG
这才是正常升级路径，别一上来就想把所有论文都装进脑子里，脑子不是向量库 (￣▽￣)／
几种代表路线，到底各自强在哪
1. 经典 RAG
这是最朴素也最值得先做的版本：
- 文档切块
- 做索引
- 用户提问
- 检索 Top-K
- 把 Top-K 放进提示词
- 让模型回答
它最大的价值不是“最先进”，而是它能帮你建立一套最关键的判断力：到底是检索错了，还是生成错了。
2. 增强型 RAG
真实项目里，很多系统一旦从 demo 变成产品，都会很快走到这一层：
- Query Rewrite：把用户问题改写得更适合检索
- Hybrid Search：关键词检索 + 向量检索一起上
- Metadata Filtering：先按时间、部门、文档类型过滤
- Reranking：对候选结果做二次精排
- Context Compression：把长证据压缩成更紧凑的支持片段
这一层才是大多数团队真正的主战场。你会慢慢发现，很多所谓“模型升级带来的提升”，其实换成“检索链路优化”也能拿到，而且更便宜。
3. GraphRAG
普通 RAG 很适合问“某个具体问题的答案在哪”。但如果你的问题变成：
- “这个项目过去一年里最常被提到的风险是什么？”
- “A 团队、B 团队、C 模块之间有哪些关键关系？”
- “请总结这 300 份报告背后的主要主题和相互关联”
这时候单纯靠相似度检索就容易抓局部、不抓全局。GraphRAG 的思路是把实体、关系、主题社区抽出来，形成图结构，再做局部检索或全局总结。它更像“先理解知识网络，再回答”，而不是“只抓最像的几段字”。
4. Self-RAG
Self-RAG 的关键词是“自适应”和“自我反思”。
- 不是每次都无脑检索
- 模型会判断当前是否需要取外部证据
- 生成过程中会引入“反思/批评”信号，帮助调整回答
你可以把它理解成：模型不只是“查资料”，还在一定程度上“检查自己是不是该查、查得够不够、答得靠不靠谱”。
5. CRAG
CRAG 的切入点很实用：先评估这次检索结果质量如何。
- 如果检索结果靠谱，就继续生成
- 如果检索结果不靠谱，就做补救，比如改写 query、换检索源、补充外部搜索
它解决的是一个非常现实的问题：很多 RAG 不是“没有检索”，而是“检索到了看似相关、实则不够支撑答案的东西”。
6. Agentic RAG
这是近两年非常明显的趋势。面对复杂问题，系统不再只做“一次检索 + 一次回答”，而是会：
- 把大问题拆成多个小问题
- 分步检索不同子问题
- 中间做计划、判断和回溯
- 最后综合成答案
如果问题是“比较 5 个方案、拉通 20 份材料、找出冲突点并给建议”，Agentic RAG 往往比单次检索更合适。但要记住，它也更贵、更慢、更难控。
最小可复现示例
下面这个例子不是某个框架 API，而是最通用的伪代码。你先把流程吃透，框架只是外壳。
question = "2024 年差旅报销上限是多少？"
# 1) 可选：把原问题改写得更适合检索
queries = [
question,
"差旅 报销 上限 2024 财务制度",
]
# 2) 先做混合检索，再拿到较多候选
candidates = hybrid_search(
queries=queries,
filters={"doc_type": "policy", "department": "finance"},
top_k=20,
)
# 3) 用 reranker 选出真正相关的少量证据
top_docs = rerank(question=question, docs=candidates)[:5]
# 4) 构造约束明确的提示
prompt = f"""
你是企业制度问答助手。
只能依据给定资料回答。
如果资料不足，请明确说“根据当前检索到的资料无法确认”。
回答时给出引用片段编号。
问题：
{question}
资料：
{top_docs}
"""
# 5) 交给大模型生成
answer = llm.generate(prompt)
print(answer)
预期输出大概像这样：
根据资料 [2] 和 [4]，2024 年国内差旅报销上限为……
如果超过该金额，需要部门负责人额外审批。
这个流程为什么有效？
hybrid_search避免只靠向量或只靠关键词的单一路线filters先把明显不相关的文档排掉，减少噪声rerank把“表面像相关”但其实不够支撑的问题片段压下去- 提示词明确要求“证据不足就承认”，可以减少硬编答案
RAG 调优，真正有效的抓手在哪里
很多人一提调优，就想改 embedding、换向量库、上更大的模型。先别乱冲，跟我一步一步来。RAG 真正高性价比的调优，通常按下面这个顺序做。
1. 先做评测，不然你根本不知道自己在调什么
这是第一原则。
- 先手工做一小套评测集：50 到 200 个高质量问题，足够你看趋势
- 每个问题最好带上“标准证据”或至少带“应该命中的文档”
- 检索指标和生成指标分开看
你至少要盯住这些指标：
- 检索召回：该找回来的证据，有没有出现在 Top-K 里
- 检索精度：返回结果里，噪声比例高不高
- Faithfulness：答案是不是忠于证据
- 延迟和成本：效果好到离谱但慢成 PPT，也没法上生产
如果你只看最终答案好不好看，就会陷入一种很常见的幻觉：明明是检索问题，你却一直在折腾模型和 prompt。
2. 数据准备，往往是最大杠杆
这是很多新手最容易低估的地方。
文档解析
- PDF 不是“看起来能打开”就算解析成功
- 表格、双栏、页眉页脚、脚注、图片说明都可能把检索打歪
- 手册、制度、报表这类文档，版式保真非常重要
文档清洗
- 去重
- 去导航栏、页脚重复文案
- 去“版权所有”“联系我们”这类对问答没帮助的噪声
- 保留标题层级、章节名、时间戳、来源信息
Chunking（切块）
初学时先记住三句话：
- Chunk 太小：信息碎，主语宾语上下文断掉
- Chunk 太大：噪声多，检索不准，模型读上下文也更吃力
- 没有绝对最优 chunk size，必须用评测集试
一个很实用的起步法：
- 从 256 / 512 / 1024 tokens 三档开始试
- 对说明文、制度文档可适当大一些
- 对 FAQ、短知识片段可适当小一些
- 用标题和段落边界切，不要只按固定字符数硬砍
如果你进阶一点，可以进一步理解这些常见玩法：
- 语义切块：按语义边界切，而不是纯长度切
- Parent-Child Chunk：检索时用小块命中，回答时回带更大父块
- Contextual Retrieval：给每个 chunk 补一小段“它在整篇文档里扮演什么角色”的上下文摘要
3. 检索阶段，最该优先做的是这四件事
混合检索
在很多真实场景里，关键词检索 + 向量检索 比只做其中一个更稳。
- 关键词检索擅长精确术语、编号、日期、专有词
- 向量检索擅长语义相似、同义表达、自然语言提问
- 混合起来，往往能减少“术语命不中”或“语义飘太远”这两类问题
Metadata 过滤
别小看这个动作，它常常是又快又猛的优化：
- 按部门过滤
- 按年份过滤
- 按文档类型过滤
- 按权限过滤
如果用户问的是“2024 年财务制度”，你却让系统从“全部年份 + 全部部门 + 全部文件”里乱搜，那它不跑偏才奇怪。
Query Rewrite / Multi-Query
用户的问题经常不适合直接拿去检索：
- 太口语
- 太短
- 缺少关键词
- 指代不清
所以常见做法是：
- 先改写成更适合搜索的形式
- 一次生成多个 query 变体
- 必要时做 HyDE 这类“先生成一个假想答案，再用它帮助检索”的策略
Reranker
这是 RAG 中非常值钱的一层。
- 第一阶段检索负责“广撒网”
- Reranker 负责“精挑细选”
没有 rerank 时，Top-K 很容易混入“看着像相关，但不足以回答”的片段；而一旦混进来，模型就可能沿着错误证据写出自信答案。
4. 生成阶段，别把上下文塞爆
不是检索越多越好，也不是 prompt 越长越好。
你应该优先做的是：
- 只给模型最相关的少量证据
- 明确要求“只能根据资料回答”
- 明确要求“资料不足就说不足”
- 尽量保留出处信息，方便回溯
- 对长文档做压缩，不要把整章整节原封不动塞进去
一个很常见的误区是：Top-K 从 5 提到 30，心里觉得“信息更多更保险”。现实往往是：噪声跟着一起膨胀，最终答案反而更飘。
5. 高级调优：什么时候该上 Self-RAG、CRAG、GraphRAG、Agentic RAG
这几个方向都不是“默认就该上”，而是有明确触发条件。
- 如果你的问题经常需要“判断是否该查资料、查了以后再自检”，考虑 Self-RAG
- 如果你的检索质量波动很大，需要识别“这次找得靠不靠谱”，考虑 CRAG
- 如果你的任务强调“跨文档关系、全局总结、主题社区”，考虑 GraphRAG
- 如果你的任务天然是多跳、多子问题、多轮调研，考虑 Agentic RAG
记住一个原则：
- 复杂结构解决的是“普通 RAG 明确解决不好的问题”
- 不是为了追热点，把简单问答系统强行做成一个小型太空工程
6. 嵌入模型、微调、换库，应该排在后面
这三件事能不能带来收益？能。
但通常顺序应该是：
- 先把数据质量搞对
- 先把检索链路搞对
- 先把评测体系搭起来
- 最后再比较 embedding、reranker、向量索引、是否需要微调
如果前面三步都没做，你后面换再多组件，也很容易只是“把噪声更快地检索出来”。
一个很实用的调优顺序
| 步骤 | 为什么重要 | 怎么做 | 通过标准 |
|---|---|---|---|
| 先做评测集 | 避免盲调 | 准备 50-200 个问题和标准证据 | 能稳定复测同一组问题 |
| 修文档解析 | 原始输入错了，后面全歪 | 手查 PDF/表格解析结果 | 文本结构和原文大体一致 |
| 调 chunk 策略 | 直接影响召回与噪声 | 对比不同 chunk size 和边界策略 | Top-K 命中率明显提升 |
| 上混合检索 | 兼顾关键词与语义 | BM25 + vector | 专有词和自然语言都能命中 |
| 加 metadata 过滤 | 低成本减少噪声 | 时间/部门/类型/权限过滤 | 候选结果明显更聚焦 |
| 上 rerank | 提升最终证据质量 | 对前 20-50 个候选做重排 | 前几条结果更贴题 |
| 优化 prompt | 控制幻觉与格式 | 强制引用、允许拒答 | 答案更忠于证据 |
| 再考虑高级路线 | 避免过度设计 | 按痛点选择 GraphRAG 等 | 新复杂度换来真实收益 |
常见坑与排查
| 现象 | 常见原因 | 如何验证 | 解决方案 |
|---|---|---|---|
| 答案很顺，但事实不对 | 检索结果不支撑答案 | 看 Top-K 结果和引用片段 | 加 rerank、收紧 prompt、先提升检索质量 |
| 命中了文档，但还是答偏 | Chunk 切碎了上下文 | 打开命中的 chunk 原文检查 | 试更大 chunk、Parent-Child、保留标题层级 |
| PDF 文档效果异常差 | 文档解析错位 | 把解析文本和原 PDF 对照 | 换更强的版面解析/OCR |
| 一加大 Top-K 就更差 | 噪声过多，污染上下文 | 比较 K=3/5/10/20 的表现 | 控制 K、加 rerank、做压缩 |
| 老文档和新文档混答 | 没有时间过滤或索引没更新 | 检查 metadata 与索引更新时间 | 增量更新索引、按时间过滤 |
| 系统很慢很贵 | 候选太多、模型太大、链路太长 | 分阶段测延迟 | 缓存、减候选、换更快 reranker/模型 |
| 回答经常“差一点” | Query 太口语或太模糊 | 记录原 query 与改写后 query | 做 query rewrite / multi-query |
上生产前的最佳实践
- 可维护性：把“解析、切块、检索、重排、生成、评测”拆成独立模块，别全写死在一个函数里
- 可观测性：保留 query、Top-K、rerank 后结果、最终 prompt、延迟、失败原因
- 安全性：做权限过滤，别让 RAG 把不该看的文档检索出来
- 新鲜度：给文档打时间戳，建立增量更新机制
- 拒答策略：证据不足时宁可保守，也不要自信乱答
- 人工抽检：线上表现再好，也要定期人工看真实问答样本
初学者最容易混淆的几件事
RAG 和微调不是一回事
- RAG 解决的是“给模型外部知识”
- 微调更偏“改行为、改风格、改任务习惯”
如果你的问题是“模型不知道我公司的知识”，优先想 RAG。 如果你的问题是“模型回答方式总不符合我的要求”，才去考虑 prompt 工程或微调。
RAG 和 Agent 也不是一回事
- RAG 的核心是“找知识”
- Agent 的核心是“做计划、拆任务、调用工具、执行动作”
它们能组合，但别混成一个词就以为是一个东西。
向量数据库不是 RAG 的全部
很多初学者一学 RAG，就把注意力全放在“选哪个向量库”。其实向量库只是其中一个组件。文档质量、chunk 设计、混合检索、rerank、评测，通常影响更大。
常见问答
Q：RAG 能彻底消除幻觉吗？ A：不能。它能显著降低“无依据乱编”，但前提是检索到的证据本身正确且相关，模型也被约束得足够好。
Q：做 RAG 一定要向量数据库吗？ A：不一定。小系统可以直接用搜索引擎、数据库全文检索，或者混合方案。关键是“能不能稳定找对证据”。
Q：知识库很小，还需要 RAG 吗？ A：不一定。如果资料量很小、能稳定放进上下文，而且更新频率也低，直接长上下文有时更简单。
Q：为什么我换了更大的模型，效果提升还是不明显？ A：因为瓶颈可能不在生成，而在检索前的数据质量、切块、过滤和重排。
Q：Top-K 应该设多大？ A：没有固定答案。常见做法是从 3、5、10 开始测。K 太小会漏证据，K 太大又会引入噪声。
Q：我应该先学 GraphRAG 吗？ A：不用。先把经典 RAG 和增强型 RAG 做扎实，再去理解图式检索会轻松很多。
Q：RAG 最值得先学的能力是什么？ A：不是会不会调库，而是能不能看着失败案例判断：问题出在解析、切块、检索、重排，还是生成。
什么时候该用，什么时候别硬上
- 如果你的核心问题是“模型缺少私有或最新知识”，就用 RAG
- 如果你的核心问题是“要让回答能追溯到证据”，就用 RAG
- 如果你的知识库很小、结构很简单，先试长上下文，别急着上全套 RAG
- 如果你的任务本质是执行流程、调用工具、自动操作系统，RAG 可能只是辅助，不是主角
- 如果你拿不准，先做一个小评测集，再比较“长上下文 vs 经典 RAG vs 增强型 RAG”
小结
- RAG 的本质，是把外部知识检索接到大模型前面
- 它解决的是“模型不知道你的最新/私有知识”这个问题
- 真实效果高度依赖文档质量、切块、检索、重排和评测
- 混合检索、metadata 过滤、rerank，通常是最值得优先做的三板斧
- GraphRAG、Self-RAG、CRAG、Agentic RAG 是在经典 RAG 基础上的增强路线
- 不是所有项目都需要最复杂的 RAG，合适比先进更重要
- 新手最应该建立的是“分层定位问题”的能力
如果你只记住 3 句
- 1）RAG = 先查资料，再回答；重点不是“炫技”，而是“让回答有依据”。
- 2）RAG 调优先看数据和检索，后看模型和微调。
- 3）复杂变体只有在经典 RAG 明显不够用时才值得上。
你下一步可以继续挖的方向
- 对比：长上下文、经典 RAG、Agentic RAG 到底怎么选
- 深入：Embedding、BM25、Reranker 各自原理是什么
- 实战：用一个企业 FAQ 或产品文档做最小 RAG demo
- 评测：怎么构建自己的 RAG 测试集
- 进阶：GraphRAG、RAPTOR、Contextual Retrieval、Self-RAG 的适用边界
如果你现在刚入门，我给你的学习顺序会很朴素：
- 先做一个最小经典 RAG demo
- 故意制造几个失败案例，学会看 Top-K 和引用
- 再补混合检索、metadata、rerank
- 最后再看各种“名字很酷”的高级路线
这条路不花哨，但很稳。真学会的人，通常都是这样走出来的，不是靠背缩写背出来的 (ง •_•)ง
