RAG 知识库 / 检索增强架构模板

代表产品 / 原型:RAGFlow、LlamaIndex、Haystack、Dify、各类「企业知识库问答 / 文档助手」 一句话定位:把你自己的文档切块、向量化、建索引,让大模型回答前先检索出最相关的片段塞进上下文——基于「你的资料 / 最新信息」作答,而不是只靠训练时的记忆。

1. 一句话定位

RAG(检索增强生成)= 让大模型「开卷考试」。

它不去重新训练模型,而是在用户提问的那一刻,临时把相关资料从你的知识库里检索出来,塞进 prompt,让模型「看着资料回答」。本质上,它是一个搜索引擎 + 一个大模型的缝合:搜索负责「找到对的资料」,模型负责「用资料组织出答案」。

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 的存储底座,详见向量数据库模板。
检索器 + 重排器:先广召回(向量 + 关键词),再精排选最相关的。为什么需要:召回 + 精排两阶段,和搜索引擎同源。
上下文组装 + 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:文本 + 向量 + 元数据 + 来源)。

数据	存储类型	为什么
块向量 + 元数据	向量库	要按语义相似度检索,见向量数据库
关键词 / 全文索引	搜索引擎	混合检索的关键词一路,见搜索引擎
原始文档	对象存储	大、不变、按 ID 取回展示
文档 / 块元数据	关系型	权限、来源、版本

8. 关键架构决策与权衡 ⭐

决策 1:RAG、长上下文、还是微调?(三条路线先选对)⭐

长上下文:把资料一股脑塞进 prompt。简单,但又贵又慢,资料一多就放不下、噪音还拉低质量。
微调:把知识训进模型。一劳永逸感强,但贵、慢、更新难、容易忘旧知识。
RAG:提问时临时检索。资料可随时更新、可溯源、性价比高。
取向:资料多 / 要常更新 / 要溯源 → RAG;资料极少且固定 → 长上下文;要改变模型「行为风格」而非「知识」→ 微调。三者也可组合。

决策 2:切块怎么切?(检索质量的隐形开关)⭐

固定大小切:简单,但可能把一句完整意思拦腰切断。
按语义 / 结构切 + 适当重叠:保留语义完整性,重叠避免边界信息丢失。
取向:从「固定大小 + 重叠」起步,质量不够就上「按结构 / 语义切」。切块是 RAG 里最被低估、却最影响效果的环节。

决策 3:纯向量检索,还是混合检索?⭐

纯向量:擅长语义近似,但对专有名词、精确关键词(产品型号、人名)反而不灵。
混合(向量 + 关键词 BM25):两者互补,通常显著更好。
取向:生产级 RAG 多用混合检索 + 重排。代价是更复杂、要维护两套索引。

决策 4:要不要给块补充上下文?

裸切块:一个块脱离原文后,可能语义残缺(「它涨了 20%」——「它」是谁?)。
上下文增强(如为每块补一句来源摘要再向量化):召回更准。
取向:对召回质量敏感的场景值得做(参见 Anthropic 的 Contextual Retrieval)。

9. 规模化与瓶颈

第一个瓶颈:向量规模增长。 → 破解:向量库分片 + 副本,见向量数据库。
第二个瓶颈:检索延迟。 → 破解:ANN 索引调参、缓存热门查询、重排只对少量候选做。
第三个瓶颈:embedding 成本(海量文档 / 频繁更新)。 → 破解:批量向量化、增量更新(只对变化的块重算)、缓存。
第四个瓶颈:多知识库 / 多租户。 → 破解:按知识库 / 租户做命名空间隔离 + 检索时按元数据过滤。

10. 安全与合规要点

🔴 检索内容是不可信输入:检索到的文档片段可能藏「忽略以上指令…」式的提示注入,要当不可信文本对待——和 AI 对话产品第 10 节同一个坑。
权限过滤:用户只能检索到自己有权限的文档;过滤要在检索阶段生效,不能「先检索出来再隐藏」(同搜索引擎)。
私有数据泄露:知识库常含敏感资料,要做租户隔离、传输 / 存储加密。
来源可信:引用要能指回真实出处,防止「编造引用」。

11. 常见误区 / 反模式

❌ 检索质量差,却怪模型笨 → ✅ RAG 的上限 = 检索的上限,先优化检索。
❌ 切块拍脑袋(太大 / 太小 / 无重叠) → ✅ 按语义 + 重叠,持续评估。
❌ 只用向量检索 → ✅ 混合检索 + 重排,尤其对精确关键词。
❌ 把检索到的内容当可信 → ✅ 当不可信输入,防注入。
❌ 不给引用 → ✅ 可溯源才可信、可核实。
❌ 能用长上下文 / 微调解决的硬上 RAG → ✅ 先选对路线。

12. 演进路线:MVP → 成长期 → 成熟期(不同阶段怎么设置)

阶段	规模量级	怎么设置(具体)	此时该操心什么
MVP	少量文档	用现成框架(LlamaIndex / Dify / RAGFlow),固定大小切块 + 纯向量检索,先跑通问答	验证「检索 + 回答」这条链路通不通
成长期	知识库上规模	混合检索 + 重排、按语义切块、引用溯源、权限过滤,并建立检索质量评测	把召回 / 准确率提上去,控成本
成熟期	海量 / 多租户	上下文增强检索、大规模向量库分片、检索质量持续评测、Agentic RAG(让 Agent 多轮检索)	检索质量、规模、成本、可观测

13. 可复用要点

💡 「开卷考试」思想:与其让系统「记住」一切(微调 / 大模型),不如让它「会查」(检索)。可查、可更新、可溯源,往往比硬记更划算。
💡 召回 + 重排两阶段漏斗,和搜索引擎完全同源——先广后精,是处理「海量里挑少数」的通用范式。
💡 质量决定于最弱一环:解析、切块、检索、重排,任何一环拉胯都拖垮全局。先找最弱环节优化。
💡 任何重新进入模型的外部内容,都是不可信输入——RAG 检索结果也不例外。

🎯 随堂检验

🤔RAG 知识库回答质量的上限,主要取决于?

A底层模型有多大
B检索得准不准(有没有找到对的资料)
Cprompt 写得多长

参考原型与延伸阅读

本模板基于以下真实开源项目与公开工程资料整理。想动手,这几个框架能让你最快跑通一套 RAG。

🔧 开源原型(可直接读代码):

infiniflow/ragflow — 主打「深度文档理解」的开源 RAG 引擎,解析 / 切块 / 检索 / Agent 一条龙。
run-llama/llama_index — 最流行的 RAG / 数据框架之一,300+ 集成,适合快速搭检索管线。
deepset-ai/haystack — 把 RAG / Agent 显式建模成「可替换的模块化管线」(检索器 / 重排 / 生成器)。
langgenius/dify — 带可视化的 LLM 应用平台,内置 RAG 管线与知识库管理。

📖 工程文章:

Anthropic: Contextual Retrieval — 用「为每块补充上下文」把检索失败率降低 49%(配重排达 67%),理解切块 / 检索优化的必读。

📌 一句话记住 RAG:它不是「更聪明的模型」,而是「让模型开卷考试」——所有设计都在回答『怎么在提问那一刻,把最该看的资料,准确地找出来塞给模型』。检索找得准,答案才靠谱。

RAG 知识库 / 检索增强 架构模板 ​

1. 一句话定位 ​

2. 业务本质:它在解决什么问题 ​

3. 核心需求与约束 ​

4. 架构全景图 ​

5. 组件职责 ​

6. 关键数据流 ​

7. 数据模型与存储选择 ​

8. 关键架构决策与权衡 ⭐ ​

9. 规模化与瓶颈 ​

10. 安全与合规要点 ​

11. 常见误区 / 反模式 ​

12. 演进路线:MVP → 成长期 → 成熟期(不同阶段怎么设置) ​

13. 可复用要点 ​

🎯 随堂检验 ​

参考原型与延伸阅读 ​