RAG（Retrieval-Augmented Generation）最常被简单描述成“先检索，再生成”。这个说法没有错，但它太容易让人误以为：只要把文档切块、做 embedding、接一个向量数据库，RAG 就算完成了。真正落地后你会发现，系统表现往往不是卡在“有没有接上 RAG”，而是卡在检索到的证据是否真的对、是否足够、是否干净。
更准确地说，RAG 不是给大模型外挂一个知识库，而是把“找证据”这件事从参数记忆里拆出来，变成一条可以单独设计、调试、评估和迭代的流水线。也因此，RAG 的核心从来不只是生成，而是如何组织知识、如何召回证据、如何控制噪声。
TL;DR
| 问题 | 简短结论 |
|---|---|
| RAG 的本质是什么？ | 不是“外挂知识库”，而是把证据获取做成独立流水线。 |
| RAG 最容易做错的环节是什么？ | 往往不是生成，而是 chunking 和 retrieval。 |
| 为什么只做向量检索不够？ | 因为真实问题往往还需要关键词匹配、查询改写、重排与压缩。 |
| 什么时候考虑 GraphRAG？ | 当问题需要显式关系建模、多跳推理或全局结构视图时。 |
| 面试里最常被追问什么？ | chunking、hybrid search、rerank、evaluation、RAG vs fine-tuning。 |
为什么 RAG 会成为大模型应用的默认增强路径
很多实际系统的演进顺序都很相似：先尝试提示词工程，再接入 RAG，最后才考虑微调。原因并不神秘。提示词工程成本最低，但它无法给模型注入真正的新知识；微调可以改变模型参数，却成本更高、更新更慢，也更难保证答案始终基于最新数据。RAG 刚好位于两者之间：它不改模型参数，却能让模型在回答前先读取外部证据。
从工程视角看，RAG 的价值主要来自三个方面：
- 可更新：知识变化时更新索引，不必重新训练模型。
- 可控：回答质量可以拆解到数据、检索、重排、生成各个环节。
- 可追溯：理论上可以定位答案来自哪些证据，而不是完全依赖模型隐式记忆。
但这并不意味着只要使用 RAG，幻觉问题就会自动消失。RAG 能否真正提升质量，取决于一个更具体的问题：系统能否把最相关的证据，在合适的粒度上，以足够低的噪声送进上下文窗口。
RAG、Prompt Engineering、Fine-tuning 该怎么选
| 方案 | 最适合解决的问题 | 优势 | 局限 |
|---|---|---|---|
| Prompt Engineering | 任务格式控制、输出风格、简单推理 | 成本最低、迭代最快 | 不能注入新知识 |
| RAG | 外部知识更新、证据约束、问答检索 | 可更新、可追溯、无需改模型参数 | 依赖检索质量 |
| Fine-tuning | 风格迁移、领域表达、任务模式固化 | 能稳定改变模型行为 | 成本更高，知识更新不灵活 |
一个常见误区是把三者对立起来。更常见也更有效的做法，其实是组合使用：用 prompt 控制行为，用 RAG 注入证据，用 fine-tuning 固化特定任务习惯。
一条完整的 RAG 流水线到底包含什么
如果把 RAG 压缩成最小闭环，它通常包含四步：
- 数据准备：加载 PDF、Word、Markdown、HTML 或数据库记录。
- 索引构建：把文档分块，计算 embedding，并存入索引系统。
- 在线检索：把用户问题转成检索请求，召回候选证据。
- 增强生成：把问题和候选上下文一起交给 LLM 生成答案。
这个流程看似直接，但几乎每一步都能决定最终质量。真正做过 RAG 系统的人通常会很快意识到：模型回答不好，很多时候不是“模型不会答”，而是检索阶段根本没有把正确证据送进去。
下面这张图更接近工程上的理解：RAG 不是单块组件，而是一组可被分别优化的模块。
数据准备：第一步不是向量化，而是把知识变成可处理的文本
RAG 的起点不是 embedding，而是数据加载。文档加载器的任务，是把 Word、PDF、网页、Markdown 或数据库记录，转换成后续流程能消费的统一文本表示。在这一步，最重要的不是“支持多少格式”，而是能否保留足够的结构信息。
如果原始文档本身带有标题层级、表格边界、段落分隔、代码块或章节结构，那么这些结构信号往往比纯文本本身更重要。因为后续的分块策略，通常正是依赖这些边界来尽量避免语义被粗暴截断。
这也是为什么实际系统里，数据加载常常不是一个纯 I/O 步骤，而是知识工程的入口：你需要决定保留哪些字段、怎样处理表格、是否提取图片文字、是否把元数据（时间、作者、来源、类别）一起写入索引。
进入索引前，通常要处理哪些东西
| 数据类型 | 常见处理方式 | 对检索的影响 |
|---|---|---|
| PDF / Word | 提取正文、标题、页码、表格 | 决定 chunk 是否保留文档语义边界 |
| Markdown / HTML | 保留标题层级、列表、代码块 | 有利于结构化分块 |
| 截图 / 图片 | OCR 或版面理解 | 决定图中知识是否能进入索引 |
| 业务记录 / 数据库行 | 字段拼接 + 元数据写入 | 便于后续 filter 与 routing |
文本分块：RAG 质量最容易被低估的环节
文本分块（chunking）是 RAG 中最关键、也最容易被误解的一步。它的目标不是机械地把长文切成固定长度，而是在 embedding 模型和 LLM 上下文窗口的限制下，找到适合检索、又足以支撑生成的知识粒度。
为什么必须分块？因为两个核心组件都有输入上限：
- embedding 模型不能无限长地编码文本；
- LLM 也不能把整个知识库一股脑吞进上下文窗口。
因此，RAG 必须先把长文档切成更小的知识单元，再围绕这些单元做索引和召回。
固定窗口与递归分块
最简单的方法是固定窗口分块：例如每 500 或 800 个 token 切一次，并保留一定 overlap。这种方法实现简单，但经常把一个本应完整表达的语义单元切断。
更常见的改进，是递归字符分块（Recursive Character Text Splitting）：
- 先尝试按段落切；
- 段落仍过长，再按换行切；
- 还过长，再按句子或更细粒度切；
- 实在不行才退化为硬切窗口。
它的核心思想是：先尊重语义边界，再满足长度约束。这比简单固定窗口更接近真实文档的组织方式，也更容易召回完整证据。
语义分块与结构化分块
除了基于字符和分隔符的分块，还有两类更“聪明”的方法。
第一类是语义分块。它不再只关心字符数，而是尝试检测相邻句子之间的语义跳变，把明显的主题切换点当成断点。这类方法通常更适合长篇说明文或教程，因为它能更自然地把不同子主题拆开。
第二类是基于文档结构的分块。对于 Markdown、HTML、LaTeX 这类本身结构清晰的文档，可以直接利用标题、列表、表格、章节边界来切分。相比“盲切文本”，这种方式更容易保持知识单元的完整性。
分块并不存在放之四海皆准的最优值
RAG 中一个长期存在的权衡是：
- 小块检索更精确，但上下文可能不足；
- 大块上下文更丰富，但噪声也更大。
所以，chunk size 不是越小越好，也不是越大越好。真正重要的是：你的块是否对应了用户查询时真正会被引用的知识单位。如果用户经常问定义、规则、结论，小而完整的句段往往更有效；如果用户经常问流程、推导、上下文依赖强的问题，过小的块反而会让生成阶段失去必要背景。
面试里常被追问的一个点：chunk overlap 到底有什么用
Overlap 的本质，是减少边界切割带来的信息丢失。如果一个答案恰好跨越两个 chunk 的交界，没有 overlap 时，两边都可能各自“不完整”；有了 overlap，至少有一个 chunk 还能保留较完整的上下文。
但 overlap 也不是越大越好。它的代价包括：
- 冗余索引变多；
- 检索结果更容易重复；
- prompt 里更可能出现相似内容堆叠。
因此 overlap 的合理角色，是修补边界，而不是替代好的分块策略。
Embedding：把文本变成可比较的语义坐标
Embedding 的作用，是把文本块映射为稠密向量。这样一来，系统就能在一个连续语义空间里比较“问题”和“文档块”之间的接近程度。
离线构建索引时，系统通常会：
- 把每个 chunk 编码成向量；
- 将向量与原始文本、元数据一起存储；
- 为后续相似度搜索建立索引。
在线查询时，则会：
- 用同一个 embedding 模型把用户问题编码成向量；
- 在向量库中查找最相似的候选 chunk；
- 取 Top-K 结果进入下一阶段。
这里最容易忽略的一点是：embedding 模型本身决定了“什么叫相似”。如果你的应用高度依赖术语、专有名词、结构字段或行业表达，那么通用 embedding 模型未必能给出最理想的召回结果。
多模态 embedding 的意义
如果知识库不仅包含文本，还包含图像、图表甚至版面结构，那么问题就不再是“如何把文本向量化”，而是“如何把不同模态映射到同一个可检索空间”。
CLIP 就是一个典型例子：它通过对比学习，把图像与文本对齐到共享嵌入空间中。这样一来，系统既可以做图文检索，也可以把“图像内容”转成与文本同维度的语义表示。这类思路在多模态 RAG 中尤其重要，因为很多业务知识并不只存在于正文，也可能存在于图示、截图、页面结构或图表里。
Dense Retrieval 与 Sparse Retrieval 的差别
| 维度 | Dense Retrieval | Sparse Retrieval |
|---|---|---|
| 核心表示 | 稠密向量 | 词项权重 / 稀疏向量 |
| 擅长 | 语义相近匹配 | 精确关键词匹配 |
| 常见优势 | 能找“意思相近” | 能保住术语、编号、函数名 |
| 常见短板 | 可能丢关键词 | 不懂语义改写 |
这张表的结论其实很直接：很多系统最后走向 hybrid，不是因为 dense 不先进，而是因为真实世界的问题同时需要“懂语义”和“别漏关键词”。
向量数据库：不是存向量这么简单，而是做近似最近邻搜索
向量数据库的核心任务，不是“保存 embedding”，而是在海量高维向量中高效找到最相似的候选。如果每次查询都暴力扫描全部向量，数据规模一大，延迟和成本都无法接受。
这正是 ANN（Approximate Nearest Neighbor）索引存在的原因。它允许系统牺牲一部分精确性，换取显著更低的搜索成本。常见策略包括：
- FLAT：精确查找，结果最准，但速度最慢；
- IVF：先把向量聚成多个桶，查询时只搜索部分桶；
- HNSW：构建多层近邻图，在图上逐步逼近目标区域。
工程上，这些方法并不是谁绝对更好，而是要看数据规模、延迟预算、召回要求以及在线更新频率。向量数据库也通常不会单独存在，它往往与传统数据库配合使用：结构化字段、业务元数据放在普通数据库里，语义检索部分放在向量索引里。
面试里常问：向量数据库和传统数据库是什么关系
最准确的回答不是“替代”，而是互补。
- 传统数据库擅长结构化字段过滤、事务和精确查询；
- 向量数据库擅长高维相似性检索；
- 真正的 RAG 系统通常两者一起用：先按业务字段过滤，再做向量召回，或者反过来先召回再过滤。
检索阶段：为什么“能搜到”不等于“搜得对”
最基础的 RAG 检索，是把问题向量与 chunk 向量做相似度搜索，返回 Top-K。这个闭环足以跑通一个最小原型，但通常不足以支持稳定生产效果。
原因在于，用户的问题并不总是天然适合直接拿去搜：
- 可能太短、太模糊；
- 可能带有复杂过滤条件；
- 可能同时包含多个子问题；
- 可能需要关键词精确匹配与语义匹配共同成立。
因此，真正的 RAG 系统很少停留在“单次 dense retrieval”。
Hybrid Search：把词法匹配和语义匹配放在一起
混合检索（Hybrid Search）结合了两种不同信号：
- 稀疏检索：基于词项、词频、BM25 或稀疏向量，擅长精确匹配关键词；
- 稠密检索：基于 embedding，擅长匹配语义相近但字面不同的表达。
两者的优缺点恰好互补。关键词检索更容易命中产品型号、函数名、法规编号等必须字面一致的内容；向量检索则更容易命中“意思相近但措辞不同”的文段。
实际系统中，混合检索通常不是二选一，而是并行执行两条检索链路，再把结果做融合排序。RRF（Reciprocal Rank Fusion）是一种常见策略，它不依赖不同检索器的原始分数，只依赖各自结果中的排名，因此在工程上很稳健。
Query Transformation：问题不一定直接拿去搜
很多时候，用户的原始提问并不适合作为检索输入。于是系统会先做查询改写（query transformation），把自然语言问题转换为更利于检索的形式。
常见做法包括：
- query rewrite：把模糊问题改写得更明确；
- multi-query：把复杂问题拆成多个子问题，分别检索再合并；
- step-back prompting：先抽象出背后的通用原理，再回到具体问题；
- HyDE：先让 LLM 生成一段“假设性理想答案”，再用这段答案去做向量检索。
HyDE 很有代表性，因为它绕开了“短 query 难以表达完整语义”的问题。系统不直接用用户问题做检索，而是先构造一个更像“目标文档”的假设文本，再把检索从 query-to-document，转成更容易的 document-to-document 匹配。
Query Routing：不同问题走不同检索路径
当系统背后连接多个数据源、多个索引，或者同时具备结构化查询和向量检索能力时，就需要做查询路由（query routing）。它的核心问题不是“搜什么”，而是“先决定去哪里搜”。
例如：
- FAQ 类问题走短文本向量库；
- 结构化统计问题走 SQL；
- 关系推理类问题走图数据库；
- 高召回要求的问题走 hybrid retrieval + rerank。
从系统设计上看，查询路由本质上是在回答：哪一种检索路径，最适合这类问题。
一张对比表看懂常见检索增强手段
| 方法 | 主要解决什么问题 | 典型收益 | 代价 |
|---|---|---|---|
| Query Rewrite | 原问题太模糊 | 提升首轮召回质量 | 可能引入改写偏差 |
| Multi-query | 单个 query 覆盖不全 | 召回更全面 | 成本更高，结果更杂 |
| HyDE | 短 query 表达力不足 | 更接近目标文档语义 | 依赖生成质量 |
| Hybrid Search | 关键词与语义都重要 | 兼顾 lexical + semantic | 实现更复杂 |
| Routing | 数据源异构 | 延迟与精度更可控 | 需要稳定分类逻辑 |
检索后处理：真正决定上下文质量的往往是 rerank 和 compression
很多 RAG 系统的误区在于，只盯着 first-stage retrieval，却忽视了检索后的加工。实际上，第一阶段检索更像是“先多抓一批候选”，而不是直接把最终上下文送给 LLM。
Re-ranking：先多召回，再精排
第一阶段 ANN 检索速度快，但它是近似的，且更偏向“粗召回”。为了降低漏召回风险，系统往往会先取更大的候选集合，再做更精细的重排序（reranking）。
常见 reranker 有三类：
- RRF：基于多检索器排名融合，简单稳健；
- Cross-Encoder：把 query 和 candidate 拼接后整体建模，精度通常更高；
- LLM-based reranker：直接让 LLM 判断候选与问题的相关性。
其中 Cross-Encoder 很典型。它不再分别编码 query 和 document，而是把两者一起送入模型，直接输出一个相关性分数。因此它更贵，但往往也更准，特别适合作为第二阶段精排器。
Compression：不是所有召回内容都值得塞进 prompt
即使候选文档是相关的，也不代表其中每一句都值得进入上下文。很多 chunk 虽然整体上相关，但内部可能夹杂大量与当前问题无关的噪声。
于是就有了压缩（compression）阶段。它通常有两种做法：
- 内容提取：从候选文档中只抽出与查询最相关的句子或片段；
- 文档过滤：把虽然被召回、但细看后并不关键的整段内容剔除掉。
从效果上看，compression 的价值在于：它让 prompt 中的 token 更集中地承载“证据”，而不是浪费在无关背景上。
Rerank 与 Compression 分别在做什么
| 环节 | 输入 | 输出 | 目标 |
|---|---|---|---|
| Rerank | 候选文档列表 | 重新排序后的候选 | 把最相关文档排到前面 |
| Compression | 候选文档内容 | 更短、更聚焦的证据片段 | 把噪声从 prompt 中剔除 |
一句话区分：rerank 解决“谁更值得进来”，compression 解决“进来之后保留什么”。
评估：RAG 不应只看最终答案，还应看证据链是否健康
RAG 的另一个优势，是它比纯生成系统更容易做拆解评估。你不只可以问“答案对不对”，还可以问“检索是否找到了对的上下文”“生成是否忠实于证据”。
一个很实用的框架是 RAG 评估三元组：
| 维度 | 关注对象 | 核心问题 |
|---|---|---|
| 上下文相关性 | 检索器 | 检索回来的证据是否与问题相关？ |
| 忠实度 / Groundedness | 生成器 | 答案是否真正基于上下文，而不是模型自由发挥？ |
| 答案相关性 | 端到端系统 | 最终答案是否直接、完整、有效地回答了问题？ |
这三个指标很容易被混为一谈，但它们对应的故障点不同。
- 如果上下文相关性低，问题通常出在 chunking、embedding 或检索策略；
- 如果忠实度低，说明模型没有被证据很好约束，容易 hallucinate；
- 如果答案相关性低，说明系统虽然可能找到了证据，却没有把它转化成真正回答问题的输出。
也正因为如此，RAG 系统不能只靠人工“看几个案例”。如果没有评估集和拆解指标，你很难判断一次改动究竟改善了召回、改善了生成，还是只是碰巧对了几题。
线上排障时，可以怎么定位问题
| 现象 | 更可能的原因 | 优先检查什么 |
|---|---|---|
| 回答完全答非所问 | 检索没召回 / query routing 错误 | top-k 结果与 query 是否相关 |
| 回答看起来像对，但编造细节 | groundedness 不够 | 提示词约束、引用证据、压缩策略 |
| 回答只答了一半 | top-k 太少 / chunk 太碎 | chunk 粒度、overlap、compression |
| 回答重复、啰嗦 | prompt 里上下文冗余 | overlap、rerank 去重、compression |
从 Naive RAG 到 GraphRAG：什么时候需要更重的结构
当知识库规模持续扩大、问题跨文档关系更强、仅靠 chunk 相似度很难找到答案时，传统 RAG 会逐渐暴露局限。例如：
- 多跳关系难以通过相邻文本块直接表达；
- 文档之间的实体关系没有被显式建模；
- 用户需要的不只是局部证据，而是全局结构化视图。
这时就会自然走向 GraphRAG 或更一般的知识图谱增强检索。它的核心不是“把向量检索替换掉”，而是显式表示实体、关系和路径，把原本隐含在文本里的结构抽出来。
典型的 GraphRAG 流程通常包括三步：
- 图谱构建：从文本抽取实体、关系与属性；
- 图谱检索：围绕实体、路径、子图做查询；
- 增强生成：把图结构证据与原文证据一起交给 LLM。
它的优势在于更适合全局视角、多跳推理和关系密集型任务；但代价也很明确：图谱构建、更新、一致性维护和查询系统都比普通 RAG 更重。
Naive RAG、Advanced RAG、GraphRAG 怎么区分
| 形态 | 核心特征 | 适用场景 | 常见问题 |
|---|---|---|---|
| Naive RAG | 分块 + embedding + top-k + generation | 小型知识库、快速原型 | 漏召回、噪声大、答案不稳 |
| Advanced / Modular RAG | 加入 rewrite、hybrid、rerank、compression、routing | 大多数生产问答系统 | 系统复杂度上升 |
| GraphRAG | 显式实体关系、路径检索、图增强生成 | 多跳关系、全局结构理解 | 构建与维护成本高 |
所以一个很重要的判断标准是：你的问题，究竟是“文本证据召回不够”，还是“需要显式关系推理”。前者往往先优化 chunking、hybrid search、rerank 就能解决；后者才真正需要 GraphRAG。
一个实用的工程顺序：先把简单闭环做好，再逐层加复杂度
如果你要从零搭一个 RAG 系统，一个务实顺序通常是：
- 先做最小闭环：文档加载、基础分块、dense retrieval、生成。
- 先查分块：如果召回差，优先怀疑 chunking 和数据清洗，而不是先换模型。
- 再加 hybrid search：当关键词精确匹配很重要时，引入 sparse + dense 融合。
- 再加 rerank / compression：把粗召回变成可直接喂给 LLM 的高质量上下文。
- 最后考虑复杂路由或 GraphRAG：只有当问题确实需要多数据源调度或关系推理时，再引入更重的模块。
这个顺序背后的原则很简单：复杂度应该来自问题本身，而不是来自我们想把系统做得“更高级”。
手撕式回答模板
下面这几段，不是“标准答案全文”，而是更适合在面试里 30 秒到 2 分钟内展开的回答骨架。它们的共同特点是：先下定义，再拆链路，最后补 trade-off。
模板 1：什么是 RAG
短答版：
RAG 是一种把外部知识检索和大模型生成结合起来的方法。它的核心不是让模型“记住更多”，而是让模型在回答前先去找证据，再基于证据生成答案。
展开版：
如果让我用工程语言来解释，我会说 RAG 是把“知识获取”从模型参数里拆出来，变成一条独立流水线。典型链路是：文档加载、分块、embedding、检索、重排、再交给 LLM 生成。所以它的优势是知识可更新、回答可追溯、效果可拆解；它的难点是检索质量往往比生成模型本身更决定结果。
模板 2：RAG 和 Fine-tuning 有什么区别
短答版：
RAG 改的是推理时能访问到的证据，Fine-tuning 改的是模型参数本身。
展开版：
如果问题是“模型不知道最新知识”，优先考虑 RAG；如果问题是“模型总是输出风格不对、流程不稳、格式不一致”，优先考虑 Fine-tuning。很多真实系统里两者并不冲突，而是组合使用：RAG 负责注入最新证据，Fine-tuning 负责把模型行为调到更稳定。
模板 3：为什么很多 RAG 项目效果不好
短答版：
通常不是因为 LLM 不够强，而是因为证据链出了问题。
展开版：
RAG 效果差，我会按链路排查：先看数据清洗，再看 chunking，再看 embedding 和检索策略，然后看 rerank、compression，最后才看 prompt 和生成模型。因为只要前面某一环出问题，最后都会被表现成“模型答错”，但根因其实不在 LLM 本身。
模板 4：为什么 Hybrid Search 往往更稳
短答版：
因为真实查询同时有语义匹配需求，也有精确关键词不能漏的需求。
展开版：
Dense retrieval 擅长找语义相近内容，但可能漏掉产品型号、函数名、错误码这类必须字面命中的信息；Sparse retrieval 正好补这个短板。所以 hybrid search 的价值，不是“更复杂”，而是更符合真实问题结构：既要懂意思，也不能漏掉关键字面信号。
模板 5：怎么回答 Top-K 应该怎么设
短答版：
Top-K 没有固定最优值，它依赖 chunk 粒度、是否有 rerank，以及上下文窗口预算。
展开版：
Top-K 太小会漏证据，太大会带噪声。所以我不会单独拍脑袋定一个数，而是先看 chunking，再看是否有二阶段 rerank，最后用评估集去选一个在上下文相关性、忠实度和答案质量之间更平衡的范围。也就是说，Top-K 是 retrieval pipeline 的结果，不是孤立参数。
模板 6：什么时候才需要 GraphRAG
短答版：
当问题需要显式关系建模、多跳推理或全局结构视图时，才更值得考虑 GraphRAG。
展开版：
如果问题本质上还是局部文本证据召回，那普通 RAG 加上 hybrid search、rerank 往往已经够了。GraphRAG 真正适合的是实体关系密集、跨文档路径推理明显、用户需要的不只是局部文本，而是结构化关系图的时候。它更强，但也更重，所以不是默认答案。
面试高频问题
1. RAG 和 Fine-tuning 的本质区别是什么
最核心的区别在于：RAG 改的是推理时可访问的证据，Fine-tuning 改的是模型参数中的行为偏好与表示。
- 如果问题是“模型不知道最新知识”，优先考虑 RAG；
- 如果问题是“模型总是用错语气、格式或流程”，优先考虑 fine-tuning；
- 如果问题两者都有，往往是组合使用。
2. 为什么很多 RAG 项目效果差，不是因为 LLM 弱
因为 LLM 只是最后一跳。前面的任何问题——OCR 质量差、chunk 切断语义、embedding 不适配领域、关键词漏召回、rerank 不稳定、上下文冗余——都会在最后被表现成“模型答错”。
所以面试里如果被问“RAG 效果差怎么办”，更好的回答不是“换更强的模型”，而是按链路拆解：数据 → chunking → retrieval → rerank → compression → prompt → evaluation。
3. Top-K 应该怎么设
不存在通用最优值。Top-K 太小会漏掉答案证据，太大则会把噪声带进 prompt。更合理的回答方式是：
- 先看 chunk 粒度；
- 再看是否有 rerank；
- 最后用离线评估集去选一个对上下文相关性和答案质量更平衡的范围。
也就是说，Top-K 不是单独调的，它依赖于整条 retrieval pipeline。
4. Hybrid Search 为什么常常比纯向量检索更稳
因为真实查询既有“语义相近”需求，也有“关键词不能错过”需求。产品型号、函数名、错误码、法规编号这类信息，一旦漏掉，dense retrieval 再聪明也可能把结果带偏。Hybrid Search 正是在补这类短板。
5. Reranker 为什么能提升效果
因为 first-stage retrieval 追求的是高召回，而不是高精排。只要先把“可能相关”的候选抓回来，第二阶段 reranker 就能用更贵但更准的模型重新判断相关性，把真正该进 prompt 的内容排到前面。
6. GraphRAG 一定比普通 RAG 强吗
不一定。GraphRAG 强在关系结构与多跳推理，不强在“所有任务都自动更好”。如果问题本质上仍是局部文本证据召回，那么普通 RAG 加上 hybrid search 和 rerank 往往已经足够。GraphRAG 的正确使用前提，是你确实需要显式图结构。
总结
RAG 的本质，不是给大模型外挂一个搜索框，而是把“证据获取”从模型参数里拆出来，变成一条可以单独优化的工程链路。只要把这条链路展开，你就会发现：真正决定效果的往往不是生成模型本身，而是分块是否合理、检索是否召回、重排是否稳定、上下文是否干净。
因此，理解 RAG 最好的方式，不是把它视为一个单点技术，而是把它视为一种系统设计方法：让模型先基于证据思考，再基于证据回答。
如果只记住一句话，那么应该是：Naive RAG 只是起点；真正可用的 RAG，是一条可观察、可替换、可评估的证据流水线。
参考资料
- Lewis et al. Retrieval-Augmented Generation for Knowledge-Intensive NLP Tasks
- Gao et al. Precise Zero-Shot Dense Retrieval without Relevance Labels
- LlamaIndex Documentation. Advanced RAG / Retrieval Patterns
- LangChain Documentation. Text Splitters
- Milvus Documentation. What Is a Vector Database?
- Datawhale. All in RAG