# RAG 知识库 / 检索增强 架构模板 > **代表产品 / 原型**:RAGFlow、LlamaIndex、Haystack、Dify、各类「企业知识库问答 / 文档助手」 > **一句话定位**:把你自己的文档切块、向量化、建索引,让大模型回答前先检索出最相关的片段塞进上下文——基于「你的资料 / 最新信息」作答,而不是只靠训练时的记忆。 --- ## 1. 一句话定位 RAG(检索增强生成)= **让大模型「开卷考试」**。 它不去重新训练模型,而是在用户提问的那一刻,**临时把相关资料从你的知识库里检索出来,塞进 prompt**,让模型「看着资料回答」。本质上,它是**一个搜索引擎 + 一个大模型的缝合**:[搜索](../search-engine/README.md) 负责「找到对的资料」,模型负责「用资料组织出答案」。 ## 2. 业务本质:它在解决什么问题 通用大模型有三个硬伤:**会幻觉(一本正经地胡说)、知识会过期(训练截止后的事不知道)、不懂你的私有数据(公司内部文档它没见过)**。 RAG 一次性缓解这三样:把权威的、最新的、私有的资料作为「开卷材料」喂给模型,让答案**有据可查**。 典型场景:企业知识库问答、智能客服、产品文档助手、法律 / 医疗 / 财报等专业资料问答。它卖的是「**让通用模型,可靠地回答关于你的领域的问题**」。 ## 3. 核心需求与约束 **功能性需求:** - [ ] 文档接入(多格式:PDF / Word / 网页 / 表格…) - [ ] 切块(chunking)+ 向量化(embedding)+ 建索引 - [ ] 检索(向量语义检索 + 关键词检索) - [ ] 重排(rerank):从召回的候选里精选最相关的 - [ ] 组装上下文喂模型,生成**带引用来源**的答案 **非功能性需求 / 质量属性:** | 质量属性 | 目标 | 为什么对这类系统重要 | |---|---|---| | **检索质量(召回 + 准确)** | 越高越好 | RAG 的命脉:检索不到 / 检索错,模型必胡说 | | **可溯源** | 答案能指回原文 | 「有据可查」才可信、可核实 | | **新鲜度** | 新文档尽快可检索 | 知识库要能持续更新 | | **成本** | embedding + 检索 + 生成都要钱 | 三段都烧钱,要可控 | **关键约束(不可逾越的边界):** - 🔴 **检索质量决定上限**:RAG 的回答好坏,**上限就是检索的好坏**——garbage in, garbage out。 - 🔴 **上下文窗口有限**:塞不下全部资料,只能塞最相关的几块,所以「选哪几块」至关重要。 - 🔴 **相似 ≠ 相关**:向量相似度高的片段,未必真能回答问题。 - 🔴 **检索到的内容是不可信输入**:可能藏着提示注入。 ## 4. 架构全景图 ``` ═══════════ 离线:建知识库(把文档变成可检索的形态)═══════════ ┌────────┐ ┌────────┐ ┌──────────┐ ┌──────────────────────┐ │ 文档源 │─▶│ 解析 │─▶│ 切块 │─▶│ 向量化(embedding) │ │ PDF/网页│ │ 提取 │ │ chunking │ │ + 建索引 │ └────────┘ └────────┘ └──────────┘ └──────────┬───────────┘ ▼ ┌──────────────────────────────┐ │ 向量库(块向量+元数据+来源) │ │ + (可选)全文/关键词索引 │ └───────────────┬──────────────┘ ═══════════ 在线:检索 + 生成 ═══════════ │ ┌────────┐ ┌──────────────┐ ┌────────────────▼─────────────┐ │ 用户 │─▶│ 检索器 │─▶│ ① 混合检索(向量 + 关键词)召回 │ │ 提问 │ │ │ │ ② 重排(rerank)精选 top-K │ └───▲────┘ └──────────────┘ └────────────────┬─────────────┘ │ ▼ │ ┌────────────────────────────────────────────┐ └─────────│ 组装 prompt(问题 + 检索到的片段)→ LLM 生成 │ 带引用答案 │ → 输出答案 + 引用来源 │ └────────────────────────────────────────────┘ ``` > 灵魂是「**离线把资料组织好 + 在线把对的资料找出来**」这两步。模型本身只是最后那个「读着资料写答案」的环节——**RAG 的功力,八成在检索,两成在生成**。 ## 5. 组件职责 - **文档解析 / 加载**:把各种格式的文档抽成干净文本(含表格、版面)。*为什么需要*:垃圾输入直接拉低后续一切;解析质量是隐形的地基。 - **切块器(Chunker)**:把长文档切成适合检索和喂给模型的小块。*为什么需要*:块太大噪音多、块太小丢上下文,切块直接影响检索质量(见决策 2)。 - **Embedding 模型**:把文本块转成向量。*为什么需要*:向量是「语义检索」的基础。 - **向量库**:存块向量 + 元数据,做相似度检索。*为什么需要*:这是 RAG 的存储底座,详见 [向量数据库模板](../vector-database/README.md)。 - **检索器 + 重排器**:先广召回(向量 + 关键词),再精排选最相关的。*为什么需要*:召回 + 精排两阶段,和 [搜索引擎](../search-engine/README.md) 同源。 - **上下文组装 + LLM**:把问题和检索到的片段拼成 prompt,生成带引用的答案。*为什么需要*:这是「生成」环节;引用让答案可溯源。 ## 6. 关键数据流 **场景一:文档入库(离线索引)** ``` 1. 上传一批文档 ──▶ 解析成文本(含表格、标题层级) 2. 切块:按语义 / 结构切成带重叠的小块 3. 每块 ──▶ embedding ──▶ 得到向量 4. 向量 + 原文 + 来源元数据 ──▶ 写入向量库(+ 可选全文索引) ``` **场景二:一次问答(检索 + 生成)** ``` 1. 用户问「我们的退款政策是几天?」 2. 问题向量化 ──▶ 在向量库做相似度检索 + 关键词检索 → 召回 ~20 个候选块 3. 重排(rerank)→ 精选最相关的 top-3~5 块 4. 组装 prompt:[系统提示 + 这几块资料 + 用户问题] ──▶ 喂给 LLM 5. LLM 基于资料生成答案 ──▶ 附上「依据:政策文档第 3.2 节」的引用 ``` > 第 3 步的重排很关键:**向量召回是「广而粗」,重排是「精而准」**,没有重排,塞进去的常有滥竽充数的块。 ## 7. 数据模型与存储选择 核心实体:`文档` ─ `块(chunk:文本 + 向量 + 元数据 + 来源)`。 | 数据 | 存储类型 | 为什么 | |---|---|---| | 块向量 + 元数据 | 向量库 | 要按语义相似度检索,见 [向量数据库](../vector-database/README.md) | | 关键词 / 全文索引 | 搜索引擎 | 混合检索的关键词一路,见 [搜索引擎](../search-engine/README.md) | | 原始文档 | 对象存储 | 大、不变、按 ID 取回展示 | | 文档 / 块元数据 | 关系型 | 权限、来源、版本 | ## 8. 关键架构决策与权衡 ⭐ **决策 1:RAG、长上下文、还是微调?(三条路线先选对)⭐** - 长上下文:把资料一股脑塞进 prompt。简单,但又贵又慢,资料一多就放不下、噪音还拉低质量。 - 微调:把知识训进模型。一劳永逸感强,但贵、慢、更新难、容易忘旧知识。 - RAG:提问时临时检索。资料可随时更新、可溯源、性价比高。 - **取向**:**资料多 / 要常更新 / 要溯源 → RAG**;资料极少且固定 → 长上下文;要改变模型「行为风格」而非「知识」→ 微调。三者也可组合。 **决策 2:切块怎么切?(检索质量的隐形开关)⭐** - 固定大小切:简单,但可能把一句完整意思拦腰切断。 - 按语义 / 结构切 + 适当重叠:保留语义完整性,重叠避免边界信息丢失。 - **取向**:从「固定大小 + 重叠」起步,质量不够就上「按结构 / 语义切」。**切块是 RAG 里最被低估、却最影响效果的环节。** **决策 3:纯向量检索,还是混合检索?⭐** - 纯向量:擅长语义近似,但对专有名词、精确关键词(产品型号、人名)反而不灵。 - 混合(向量 + 关键词 BM25):两者互补,通常显著更好。 - **取向**:生产级 RAG 多用混合检索 + 重排。代价是更复杂、要维护两套索引。 **决策 4:要不要给块补充上下文?** - 裸切块:一个块脱离原文后,可能语义残缺(「它涨了 20%」——「它」是谁?)。 - 上下文增强(如为每块补一句来源摘要再向量化):召回更准。 - **取向**:对召回质量敏感的场景值得做(参见 Anthropic 的 Contextual Retrieval)。 ## 9. 规模化与瓶颈 - **第一个瓶颈:向量规模增长。** → 破解:向量库分片 + 副本,见 [向量数据库](../vector-database/README.md)。 - **第二个瓶颈:检索延迟。** → 破解:ANN 索引调参、缓存热门查询、重排只对少量候选做。 - **第三个瓶颈:embedding 成本(海量文档 / 频繁更新)。** → 破解:批量向量化、增量更新(只对变化的块重算)、缓存。 - **第四个瓶颈:多知识库 / 多租户。** → 破解:按知识库 / 租户做命名空间隔离 + 检索时按元数据过滤。 ## 10. 安全与合规要点 - 🔴 **检索内容是不可信输入**:检索到的文档片段可能藏「忽略以上指令…」式的提示注入,要当不可信文本对待——和 [AI 对话产品](../ai-chat-product/README.md) 第 10 节同一个坑。 - **权限过滤**:用户只能检索到**自己有权限**的文档;过滤要在检索阶段生效,不能「先检索出来再隐藏」(同 [搜索引擎](../search-engine/README.md))。 - **私有数据泄露**:知识库常含敏感资料,要做租户隔离、传输 / 存储加密。 - **来源可信**:引用要能指回真实出处,防止「编造引用」。 ## 11. 常见误区 / 反模式 - ❌ **检索质量差,却怪模型笨** → ✅ RAG 的上限 = 检索的上限,先优化检索。 - ❌ **切块拍脑袋(太大 / 太小 / 无重叠)** → ✅ 按语义 + 重叠,持续评估。 - ❌ **只用向量检索** → ✅ 混合检索 + 重排,尤其对精确关键词。 - ❌ **把检索到的内容当可信** → ✅ 当不可信输入,防注入。 - ❌ **不给引用** → ✅ 可溯源才可信、可核实。 - ❌ **能用长上下文 / 微调解决的硬上 RAG** → ✅ 先选对路线。 ## 12. 演进路线:MVP → 成长期 → 成熟期(不同阶段怎么设置) | 阶段 | 规模量级 | 怎么设置(具体) | 此时该操心什么 | |---|---|---|---| | **MVP** | 少量文档 | 用现成框架(**LlamaIndex / Dify / RAGFlow**),固定大小切块 + 纯向量检索,先跑通问答 | 验证「检索 + 回答」这条链路通不通 | | **成长期** | 知识库上规模 | 混合检索 + 重排、按语义切块、引用溯源、权限过滤,并**建立检索质量评测** | 把召回 / 准确率提上去,控成本 | | **成熟期** | 海量 / 多租户 | 上下文增强检索、大规模向量库分片、检索质量持续评测、Agentic RAG(让 [Agent](../ai-agent-platform/README.md) 多轮检索) | 检索质量、规模、成本、可观测 | ## 13. 可复用要点 - 💡 **「开卷考试」思想**:与其让系统「记住」一切(微调 / 大模型),不如让它「会查」(检索)。可查、可更新、可溯源,往往比硬记更划算。 - 💡 **召回 + 重排两阶段漏斗**,和 [搜索引擎](../search-engine/README.md) 完全同源——先广后精,是处理「海量里挑少数」的通用范式。 - 💡 **质量决定于最弱一环**:解析、切块、检索、重排,任何一环拉胯都拖垮全局。先找最弱环节优化。 - 💡 **任何重新进入模型的外部内容,都是不可信输入**——RAG 检索结果也不例外。 ## 🎯 随堂检验 --- ## 参考原型与延伸阅读 > 本模板基于以下**真实开源项目**与**公开工程资料**整理。想动手,这几个框架能让你最快跑通一套 RAG。 **🔧 开源原型(可直接读代码):** - [infiniflow/ragflow](https://github.com/infiniflow/ragflow) — 主打「深度文档理解」的开源 RAG 引擎,解析 / 切块 / 检索 / Agent 一条龙。 - [run-llama/llama_index](https://github.com/run-llama/llama_index) — 最流行的 RAG / 数据框架之一,300+ 集成,适合快速搭检索管线。 - [deepset-ai/haystack](https://github.com/deepset-ai/haystack) — 把 RAG / Agent 显式建模成「可替换的模块化管线」(检索器 / 重排 / 生成器)。 - [langgenius/dify](https://github.com/langgenius/dify) — 带可视化的 LLM 应用平台,内置 RAG 管线与知识库管理。 **📖 工程文章:** - [Anthropic: Contextual Retrieval](https://www.anthropic.com/news/contextual-retrieval) — 用「为每块补充上下文」把检索失败率降低 49%(配重排达 67%),理解切块 / 检索优化的必读。 --- > 📌 一句话记住 RAG:**它不是「更聪明的模型」,而是「让模型开卷考试」——所有设计都在回答『怎么在提问那一刻,把最该看的资料,准确地找出来塞给模型』。检索找得准,答案才靠谱。**