AI Day 5
AI Day 5: RAG架构 — 检索增强生成全链路
RAG (Retrieval-Augmented Generation) 是让 LLM "先查资料，再回答问题" 的架构模式——将外部知识库中的相关文档检索出来，注入到 Prompt 的上下文中，使模型基于真实证据生成回答，而不是仅凭记忆"编造"。
2026-04-06
RAGRetrieval-AugmentedChunkingEmbeddingRerankingHyDEGraphAgenticRAGAS
日期：2026-04-06
阶段：第一阶段 — AI/LLM技术深潜 (Day 1-15)
标签：RAG Retrieval-Augmented Generation Chunking Embedding Reranking HyDE Graph RAG Agentic RAG RAGAS
学习路径树
AI/LLM 深度技术学习 50天计划
├── 第一阶段：模型基础 (Day 1-15)
│ ├── Day 1: Transformer架构与LLM基础 ✅
│ ├── Day 2: 模型量化与本地部署 ✅
│ ├── Day 3: 训练过程深度：Pre-training / SFT / RLHF / DPO ✅
│ ├── Day 4: Prompt Engineering与上下文学习(ICL)原理 ✅
│ ├── Day 5: RAG架构：检索增强生成全链路 ← 你在这里
│ ├── Day 6: 向量数据库与Embedding模型
│ ├── Day 7: Fine-tuning实战：LoRA / QLoRA / Adapter
│ ├── Day 8: 推理优化：vLLM / TensorRT-LLM / SGLang
│ ├── Day 9: 长上下文技术：RoPE扩展 / Ring Attention
│ ├── Day 10: 多模态模型：Vision-Language架构
│ ├── Day 11: Reasoning模型：CoT / o1 / R1 / Extended Thinking
│ ├── Day 12: Agent框架：ReAct / Tool Use / Planning
│ ├── Day 13: MCP协议与Tool生态
│ ├── Day 14: 模型评估：Benchmark / Arena / 安全评估
│ └── Day 15: 阶段复习与架构总结
│
├── 第二阶段：工程实践 (Day 16-30)
│ ├── Day 16-20: LLM应用架构设计（微服务/网关/缓存/监控）
│ ├── Day 21-25: 生产级RAG系统（Chunking/Rerank/评估/迭代）
│ └── Day 26-30: Agent系统工程化（状态管理/错误恢复/成本控制）
│
├── 第三阶段：金融零售AI应用 (Day 31-42)
│ ├── Day 31-35: 金融AI（风控模型/智能投顾/合规/反欺诈）
│ ├── Day 36-40: 零售AI（推荐系统/智能客服/供应链预测/营销）
│ └── Day 41-42: CeFi x DeFi x AI融合架构
│
└── 第四阶段：面试冲刺 (Day 43-50)
├── Day 43-46: 系统设计面试（LLM平台/RAG/Agent/推荐）
├── Day 47-49: 产品/架构面试模拟
└── Day 50: 总结与作品集
核心概念
一句话定义
RAG (Retrieval-Augmented Generation) 是让 LLM "先查资料，再回答问题" 的架构模式——将外部知识库中的相关文档检索出来，注入到 Prompt 的上下文中，使模型基于真实证据生成回答，而不是仅凭记忆"编造"。
金融类比
RAG = 风控决策时先查征信报告，再做判断
传统 LLM（纯生成）：
信贷经理只凭个人记忆和经验做贷款审批
→ 可能记错利率政策、漏掉新规、编造客户信息
→ 类比：LLM 幻觉（Hallucination）
RAG（检索增强生成）：
信贷经理先调出征信报告、收入证明、最新政策文件
→ 基于真实材料做审批决策，每一条结论都有据可查
→ 类比：LLM 基于检索到的文档生成回答
┌─────────────────────────────────────────────────────┐
│ 客户提问: "我的贷款能批多少额度？" │
│ │
│ 纯 LLM: 凭"记忆"→ "根据一般情况，您可以贷50万" │
│ → 可能完全错误，没有依据 │
│ │
│ RAG: 1. 检索征信报告 → 信用分720 │
│ 2. 检索收入证明 → 月收入2万 │
│ 3. 检索最新政策 → LTV上限70% │
│ 4. 基于以上材料 → "根据您的信用分720和月收入 │
│ 2万，按照最新LTV政策，您最高可贷XXX万" │
│ → 有据可查，可审计 │
└─────────────────────────────────────────────────────┘
为什么 RAG 是 LLM 应用的第一架构模式
| 问题 | 纯 LLM | RAG 解决方案 |
|---|---|---|
| 知识过时 | 训练数据截止于某日期 | 实时检索最新文档 |
| 幻觉 | 编造不存在的信息 | 基于检索到的证据生成 |
| 领域知识不足 | 不了解企业内部知识 | 接入企业知识库 |
| 不可追溯 | 无法说明信息来源 | 每条回答附带引用出处 |
| 数据隐私 | 训练数据可能泄露 | 知识库独立部署，不需微调 |
| 更新成本 | 重新训练成本高昂 | 更新文档即可，秒级生效 |
2025-2026 行业现状：
企业 LLM 应用中 RAG 的采用率：
采用率 │
100% │ ████████
80% │ ████████ ████████
60% │ ████████ ████████ ████████
40% │ ████████ ████████ ████████ ████████
20% │ ████████ ████████ ████████ ████████
0% │─────────────────────────────────────────────
2023 Q1 2023 Q4 2024 Q4 2025 Q4
RAG 是落地最快、门槛最低、效果最直接的 LLM 架构模式。
估计 80%+ 的企业 LLM 应用第一步都是 RAG。
知识点1: RAG 基础架构 — 三大阶段
1.1 全链路总览
RAG 的完整流程分为三个阶段：Indexing（离线索引）→ Retrieval（在线检索）→ Generation（增强生成）。
┌──────────────────────────────────────────────────────────────────────┐
│ RAG 全链路架构 │
│ │
│ ============= 阶段1: Indexing（离线，一次性） ============= │
│ │
│ [文档源] [文档处理] [切分] [向量化] [存储] │
│ PDF/Word ──→ 解析提取 ──→ Chunking ──→ Embedding ──→ Vector │
│ HTML/MD 清洗格式化 策略选择 模型编码 DB │
│ 数据库 元数据提取 重叠/层次 批量处理 索引构建 │
│ API数据 │
│ │
│ ============= 阶段2: Retrieval（在线，每次查询） ========= │
│ │
│ [用户问题] [查询处理] [检索] [后处理] │
│ "XXX?" ──→ Query ──→ 向量检索 ──→ Reranking ──→ Top-K │
│ Rewriting 关键词检索 去重过滤 文档片段 │
│ HyDE扩展 混合检索 相关性阈值 │
│ │
│ ============= 阶段3: Generation（在线，每次回答） ======== │
│ │
│ [Prompt组装] [LLM生成] [后处理] │
│ System Prompt ──→ 模型推理 ──→ 引用标注 ──→ [回答] │
│ + 检索到的文档片段 生成回答 幻觉检测 带出处 │
│ + 用户问题 格式化 │
│ + 输出格式要求 │
└──────────────────────────────────────────────────────────────────────┘
1.2 每个阶段的关键决策
| 阶段 | 关键决策 | 选错的后果 | 金融场景考量 |
|---|---|---|---|
| Indexing | Chunk大小、Embedding模型选择 | 检索不到相关信息 | 合规文档结构复杂，需要层级切分 |
| Retrieval | 检索策略、Top-K数量 | 噪声太多或遗漏关键信息 | 金融问答需要精确匹配法条/政策编号 |
| Generation | Prompt模板、幻觉控制 | 生成错误信息 | 金融回答必须有出处，不能编造数据 |
1.3 Naive RAG vs Advanced RAG vs Modular RAG
RAG 架构演进（2023 → 2026）
┌──────────────────────────────────────────────────────────────────┐
│ │
│ Naive RAG (2023) Advanced RAG (2024) │
│ ┌──────┐ ┌──────────────────┐ │
│ │问题 │──→检索──→生成 │ 问题 → Query优化 │ │
│ └──────┘ │ ↓ │ │
│ 问题： │ 多路检索+Rerank │ │
│ - 检索质量差 │ ↓ │ │
│ - 无去噪/重排 │ 过滤+去重 │ │
│ - 幻觉严重 │ ↓ │ │
│ - 无法处理复杂问题 │ Prompt增强+生成 │ │
│ └──────────────────┘ │
│ │
│ Modular RAG (2025-2026) │
│ ┌─────────────────────────────────────────────┐ │
│ │ 可插拔模块化架构 │ │
│ │ ┌────────┐ ┌────────┐ ┌────────┐ │ │
│ │ │ Router │→│ Search │→│ Rerank │→ ... │ │
│ │ └────────┘ └────────┘ └────────┘ │ │
│ │ │ │
│ │ 特点： │ │
│ │ - 每个模块可独立替换 │ │
│ │ - 支持条件分支（Router决定走哪条路径） │ │
│ │ - 支持循环（Self-RAG判断是否需要重新检索） │ │
│ │ - 支持Agent驱动（让LLM决定检索策略） │ │
│ └─────────────────────────────────────────────┘ │
└──────────────────────────────────────────────────────────────────┘
知识点2: Chunking 策略 — 文档切分的艺术
2.1 为什么 Chunking 如此重要
Chunking 是 RAG 中最被低估但影响最大的环节。
类比：把一本500页的法规手册拆分给不同的律师阅读
- 切太小：一个律师只看到半句话，无法理解上下文
- 切太大：一个律师拿到50页，找关键信息如大海捞针
- 切错位：一条完整的法条被拆成两半，分给两个律师
Chunking 直接决定了：
1. 检索能否找到相关内容
2. 找到的内容是否完整
3. LLM 能否基于片段正确回答
2.2 五种主流 Chunking 策略
策略1: Fixed-size Chunking（固定长度切分）
方法：按固定 Token 数/字符数切分，相邻 Chunk 有重叠
[==== Chunk 1 (512 tokens) ====]
[==== Chunk 2 (512 tokens) ====]
[==== Chunk 3 (512 tokens) ====]
↑ overlap ↑ ↑ overlap ↑
优点：实现简单，速度快
缺点：可能从句子中间截断，破坏语义完整性
适用：通用文档、快速原型
策略2: Recursive Character Splitting（递归字符切分）
方法：按层级分隔符递归切分（LangChain 默认策略）
分隔符优先级：
1. "\n\n"（段落）→ 先尝试按段落切
2. "\n"（换行） → 段落太大，按行切
3. " "（空格） → 行太长，按词切
4. ""（字符） → 最后按字符切
[原文]
第一章 总则\n\n第一条 为了...\n第二条 本办法...\n\n第二章 业务规则\n\n...
[切分结果]
Chunk 1: "第一章 总则\n\n第一条 为了...\n第二条 本办法..."
Chunk 2: "第二章 业务规则\n\n..."
优点：保持语义完整，不会从词中间截断
缺点：Chunk 大小不均匀
适用：大多数文档（推荐首选）
策略3: Semantic Chunking（语义切分）
方法：用 Embedding 计算相邻句子的语义相似度，在语义断裂处切分
句子: S1 S2 S3 S4 S5 S6 S7 S8 S9
相似度: 0.9 0.85 0.3 0.88 0.92 0.25 0.87 0.9
↑ 断裂! ↑ 断裂!
[Chunk 1: S1-S3] [Chunk 2: S4-S6] [Chunk 3: S7-S9]
优点：语义一致性最好
缺点：计算成本高（需要先 Embedding 所有句子），速度慢
适用：高质量知识库、研报分析
策略4: Document Structure Chunking（文档结构切分）
方法：基于文档的固有结构（标题、章节、表格）切分
[合规手册]
├── 第一章 总则 → Chunk 1（含章节元数据）
│ ├── 第1条 → Chunk 1.1
│ └── 第2条 → Chunk 1.2
├── 第二章 业务规则 → Chunk 2（含章节元数据）
│ ├── 第3条 → Chunk 2.1
│ └── 第4条 → Chunk 2.2
└── 附表1 费率表 → Chunk 3（表格特殊处理）
优点：完美保留文档层级关系，支持精确引用
缺点：需要文档解析能力（PDF表格/多级标题），实现复杂
适用：法律文档、合规手册、技术文档（金融场景强烈推荐）
策略5: Agentic Chunking（Agent驱动切分，2025-2026新范式）
方法：用 LLM 自身来判断如何切分，理解内容后做语义完整的切分
流程：
1. 将文档分段送入 LLM
2. LLM 判断"这一段和上一段是否属于同一主题"
3. 如果是，合并；如果不是，在此处切分
4. LLM 为每个 Chunk 生成摘要作为元数据
优点：最高质量的语义完整性
缺点：成本高（需要 LLM 调用），速度慢，不适合大规模文档
适用：高价值文档（合同、研报）、对质量要求极高的场景
2.3 Chunking 策略对比表
| 策略 | 实现复杂度 | 语义完整性 | 速度 | 成本 | 推荐Chunk大小 | 推荐Overlap | 最佳场景 |
|---|---|---|---|---|---|---|---|
| Fixed-size | 低 | 差 | 极快 | 低 | 512-1024 tokens | 50-100 tokens | 快速原型 |
| Recursive | 低 | 中 | 快 | 低 | 500-1000 tokens | 100-200 tokens | 通用首选 |
| Semantic | 中 | 高 | 中 | 中 | 动态（200-800） | N/A | 研报、知识库 |
| Structure | 高 | 高 | 中 | 低 | 按章节/条款 | 含上级标题 | 金融合规 |
| Agentic | 高 | 极高 | 慢 | 高 | 动态 | N/A | 高价值文档 |
2.4 Chunk 大小的经验法则
┌────────────────────────────────────────────────────────────────┐
│ Chunk 大小选择指南 │
│ │
│ Chunk 太小 (< 200 tokens) │
│ ├── 优点：检索精度高，噪声少 │
│ └── 缺点：上下文不完整，LLM 可能无法理解 │
│ │
│ Chunk 太大 (> 2000 tokens) │
│ ├── 优点：上下文完整 │
│ └── 缺点：检索召回多余信息，稀释关键内容，成本高 │
│ │
│ 推荐起步值： │
│ ├── 通用文档: 512 tokens, overlap 50-100 │
│ ├── 法律/合规: 按条款切分, 含上级标题作为context prefix │
│ ├── 代码文档: 按函数/类切分 │
│ ├── FAQ/QA: 一问一答为一个 Chunk │
│ └── 研报/论文: 段落级, 800-1200 tokens │
│ │
│ 黄金法则：一个 Chunk 应该能独立回答一个问题。 │
│ 如果一个 Chunk 脱离上下文后无法理解，说明切分有问题。 │
└────────────────────────────────────────────────────────────────┘
2.5 Parent-Child Chunking（层级切分，2025最佳实践）
核心思想：用小 Chunk 做检索（精准），用大 Chunk 做生成（完整）
[大 Chunk (Parent) - 2000 tokens]
├── [小 Chunk 1 (Child) - 300 tokens] ← 用于检索
├── [小 Chunk 2 (Child) - 300 tokens] ← 用于检索
└── [小 Chunk 3 (Child) - 300 tokens] ← 用于检索
检索流程：
1. 用户问题 → 在 Child Chunks 中搜索 → 找到 Child 2 最相关
2. 通过 Child 2 的 parent_id 找到 Parent Chunk
3. 将完整的 Parent Chunk 送入 LLM 生成回答
效果：兼顾检索精度和上下文完整性
实现：LlamaIndex 的 SentenceWindowRetriever / ParentDocumentRetriever
知识点3: 检索策略 — BM25 / Dense / Hybrid
3.1 三种检索方式对比
┌───────────────────────────────────────────────────────────────────┐
│ 三种检索策略对比 │
│ │
│ 1. Sparse Retrieval (BM25 / 关键词检索) │
│ ┌──────────────────────────────────────┐ │
│ │ Query: "Aave V3清算阈值" │ │
│ │ ↓ │ │
│ │ TF-IDF / BM25 关键词匹配 │ │
│ │ 匹配: "Aave" + "V3" + "清算" + "阈值"│ │
│ │ ↓ │ │
│ │ 精确匹配到包含这些词的文档 │ │
│ └──────────────────────────────────────┘ │
│ 优点：精确关键词匹配、不需要 GPU、可解释 │
│ 缺点：不理解语义（"清算"和"liquidation"被视为不同词） │
│ │
│ 2. Dense Retrieval (向量检索) │
│ ┌──────────────────────────────────────┐ │
│ │ Query: "Aave V3清算阈值" │ │
│ │ ↓ │ │
│ │ Embedding Model → [0.12, -0.34, ...] │ │
│ │ ↓ │ │
│ │ 在向量空间中找最近邻 (Cosine/ANN) │ │
│ │ ↓ │ │
│ │ 找到语义相关的文档（即使用词不同） │ │
│ └──────────────────────────────────────┘ │
│ 优点：语义理解、跨语言、模糊匹配 │
│ 缺点：需要 Embedding 模型、精确匹配弱 │
│ │
│ 3. Hybrid Retrieval (混合检索) ← 2025-2026 推荐 │
│ ┌──────────────────────────────────────┐ │
│ │ Query: "Aave V3清算阈值" │ │
│ │ ↓ ↓ │ │
│ │ BM25 Dense │ │
│ │ 结果 结果 │ │
│ │ ↓ ↓ │ │
│ │ Reciprocal Rank Fusion (RRF) │ │
│ │ 或 加权合并 │ │
│ │ ↓ │ │
│ │ 合并排序后的 Top-K │ │
│ └──────────────────────────────────────┘ │
│ 优点：兼顾精确匹配和语义理解 │
│ 缺点：系统复杂度增加 │
└───────────────────────────────────────────────────────────────────┘
3.2 详细对比表
| 维度 | BM25 (Sparse) | Dense Retrieval | Hybrid |
|---|---|---|---|
| 原理 | 词频+逆文档频率 | 语义向量余弦相似度 | 两者结合 |
| 精确匹配 | 强 | 弱 | 强 |
| 语义理解 | 弱 | 强 | 强 |
| 专有名词 | 强（直接匹配） | 中（取决于训练数据） | 强 |
| 同义词/跨语言 | 弱 | 强 | 强 |
| 计算资源 | CPU即可 | 需要GPU/向量数据库 | 两者都需要 |
| 索引大小 | 小 | 大（每个Chunk一个向量） | 两者之和 |
| Cold Start | 无需训练 | 需要Embedding模型 | 需要Embedding模型 |
| 可解释性 | 高（能看到匹配的关键词） | 低（向量空间不可解释） | 中 |
| 金融场景推荐 | 法条/产品编号精确查询 | 模糊问题/意图理解 | 首选 |
3.3 Reciprocal Rank Fusion (RRF) 合并算法
RRF 是混合检索中最常用的结果合并算法：
公式：RRF_score(d) = Σ 1 / (k + rank_i(d))
k = 常数（通常60），防止高排名文档权重过大
rank_i(d) = 文档 d 在第 i 个检索器中的排名
示例：
BM25 结果: [Doc_A(rank=1), Doc_B(rank=2), Doc_C(rank=3)]
Dense 结果: [Doc_B(rank=1), Doc_D(rank=2), Doc_A(rank=3)]
Doc_A: 1/(60+1) + 1/(60+3) = 0.01639 + 0.01587 = 0.03226
Doc_B: 1/(60+2) + 1/(60+1) = 0.01613 + 0.01639 = 0.03252 ← 最高
Doc_C: 1/(60+3) + 0 = 0.01587
Doc_D: 0 + 1/(60+2) = 0.01613
最终排序: Doc_B > Doc_A > Doc_D > Doc_C
Doc_B 在两个检索器中都排名靠前，所以融合后排第一。
3.4 金融场景的检索策略选择
┌───────────────────────────────────────────────────────────┐
│ 金融场景检索策略决策树 │
│ │
│ [用户查询类型] │
│ │ │
│ ┌──────────┼──────────┐ │
│ ↓ ↓ ↓ │
│ 精确查询 模糊查询 复合查询 │
│ "第三章 "贷款利 "Aave的 │
│ 第12条" 率怎么算" 清算和 │
│ Compound │
│ │ │ 有什么不同" │
│ ↓ ↓ ↓ │
│ BM25 Dense Hybrid │
│ 精确匹配 语义理解 两者结合 │
│ │
│ 实际建议：金融场景 90% 用 Hybrid │
│ 因为用户问题往往同时包含精确术语和模糊描述 │
└───────────────────────────────────────────────────────────┘
知识点4: 高级 RAG 技术（2025-2026前沿）
4.1 Query Transformation（查询改写）
HyDE (Hypothetical Document Embeddings)
核心思想：先让 LLM 生成一个"假设性回答"，用这个回答去检索
传统 RAG：
Query: "DeFi借贷协议的清算机制" → Embedding → 检索
问题：短查询的 Embedding 信息量不够
HyDE：
Query: "DeFi借贷协议的清算机制"
↓
LLM 生成假设回答:
"DeFi借贷协议的清算机制是指当借款人的抵押率低于清算阈值时，
清算人可以偿还部分债务并获得折价的抵押品。例如Aave的清算
阈值通常设在80-85%，清算奖励为5-10%..."
↓
用这个假设文档的 Embedding 去检索
↓
检索质量大幅提升（因为假设文档和目标文档更相似）
效果：检索召回率提升 10-30%
缺点：增加一次 LLM 调用，延迟增加
适用：复杂问题、短查询、专业领域
Multi-Query（多查询扩展）
核心思想：将一个问题扩展为多个角度的查询，分别检索后合并
原始 Query: "如何评估DeFi协议的风险？"
↓
LLM 扩展为多个查询：
Q1: "DeFi协议的安全审计和智能合约风险"
Q2: "DeFi协议的经济模型可持续性风险"
Q3: "DeFi协议的治理和中心化风险"
Q4: "DeFi协议的流动性和清算风险"
↓
四个查询分别检索 → 合并去重 → Rerank → Top-K
效果：覆盖更全面的相关文档
4.2 Reranking（重排序）
┌──────────────────────────────────────────────────────────────┐
│ Reranking 的作用 │
│ │
│ 初始检索（Bi-Encoder）：快但不精 │
│ ┌──────────┐ │
│ │ Query │──→ Embedding ──┐ │
│ └──────────┘ │ 余弦相似度 │
│ ┌──────────┐ │ (独立编码) │
│ │ Document │──→ Embedding ──┘ │
│ └──────────┘ │
│ 速度快（毫秒级），但 Query 和 Doc 独立编码，交互不够深 │
│ │
│ ↓ Top-50/100 │
│ │
│ Reranking（Cross-Encoder）：慢但精 │
│ ┌──────────────────────────┐ │
│ │ [Query] [SEP] [Document] │──→ Transformer ──→ 相关性分数 │
│ └──────────────────────────┘ │
│ 将 Query 和 Document 拼接后一起编码，交互更深层 │
│ 速度慢（不能预计算），但精度高 │
│ │
│ ↓ Top-5/10 │
│ │
│ 最终送入 LLM 生成回答 │
└──────────────────────────────────────────────────────────────┘
主流 Reranking 方案（2025-2026）：
┌──────────────────┬───────────────┬────────────┬──────────┐
│ 方案 │ 提供方 │ 精度 │ 速度 │
├──────────────────┼───────────────┼────────────┼──────────┤
│ Cohere Rerank 3 │ Cohere API │ 极高 │ 中 │
│ bge-reranker-v2 │ BAAI (开源) │ 高 │ 中 │
│ ColBERT v2 │ Stanford │ 高 │ 快 │
│ Jina Reranker v2 │ Jina AI │ 高 │ 中 │
│ LLM-as-Reranker │ 任意LLM │ 极高 │ 慢 │
│ RankGPT │ GPT驱动 │ 极高 │ 慢 │
└──────────────────┴───────────────┴────────────┴──────────┘
4.3 Self-RAG（自反思RAG）
核心思想：LLM 在生成过程中自我判断——是否需要检索、检索到的是否相关、
生成的是否忠实于检索结果
┌──────────────────────────────────────────────────────────┐
│ Self-RAG 工作流 │
│ │
│ [用户问题] ──→ LLM 判断：需要检索吗？ │
│ │ │
│ ┌────┴────┐ │
│ 需要 不需要 │
│ │ │ │
│ ↓ ↓ │
│ [检索文档] [直接生成] │
│ │ │
│ ↓ │
│ LLM 判断：检索到的文档相关吗？ │
│ │ │
│ ┌────┴────┐ │
│ 相关 不相关 │
│ │ │ │
│ ↓ ↓ │
│ [基于文档生成] [重新检索/改写查询] │
│ │ │
│ ↓ │
│ LLM 判断：回答忠实于文档吗？有幻觉吗？ │
│ │ │
│ ┌────┴────┐ │
│ 忠实 有幻觉 │
│ │ │ │
│ ↓ ↓ │
│ [输出回答] [重新生成/标记不确定] │
└──────────────────────────────────────────────────────────┘
论文：Self-RAG: Learning to Retrieve, Generate, and Critique (Asai et al., 2023)
关键：模型训练时加入了"反思Token"（Retrieve/ISREL/ISSUP/ISUSE）
4.4 Corrective RAG (CRAG)
核心思想：对检索结果进行评估和纠正，避免使用低质量检索结果
流程：
1. 检索 Top-K 文档
2. 评估器对每个文档打分：Correct / Ambiguous / Incorrect
3. 根据评估结果采取不同策略：
- 全部 Correct → 直接用检索结果生成
- 部分 Ambiguous → 触发 Web Search 补充信息
- 全部 Incorrect → 完全使用 Web Search 结果
[检索结果评估]
│
┌────┼────────────────┐
↓ ↓ ↓
Correct Ambiguous Incorrect
│ │ │
↓ ↓ ↓
直接用 知识精炼 + Web Search
Web补充 替代
│ │ │
└───────┼────────────────┘
↓
[生成回答]
论文：Corrective Retrieval Augmented Generation (Yan et al., 2024)
4.5 Graph RAG（图谱增强RAG，2025-2026热点）
核心思想：从文档中提取实体和关系构建知识图谱，用图结构增强检索
传统 RAG 的局限：
问题："Compound的治理代币COMP和Aave的治理代币AAVE，哪个赋予了更多权利？"
→ 传统 RAG 分别检索到 COMP 和 AAVE 的文档片段
→ 但这两个片段之间没有直接关系，LLM 难以做深层对比
Graph RAG：
┌───────────────────────────────────────────────────────┐
│ 知识图谱结构 │
│ │
│ [Compound] ──发行──→ [COMP] │
│ │ │ │
│ │ 可用于投票 │
│ 借贷协议 │ │
│ │ [治理提案] │
│ │ │ │
│ [Aave] ──发行──→ [AAVE] │
│ │ │ │
│ 可用于投票 可用于质押 │
│ │ │ │
│ [治理提案] [安全模块] │
│ │
│ 关系类型：发行、投票、质押、治理、竞争... │
└───────────────────────────────────────────────────────┘
检索流程：
1. 从问题中提取实体：COMP, AAVE, 治理
2. 在图谱中找到相关子图
3. 将子图关系 + 文档片段一起送入 LLM
4. LLM 可以做更精确的对比推理
工具：
- Microsoft GraphRAG (开源，2024发布，2025持续迭代)
- Neo4j + LlamaIndex Graph Store
- LangChain + NetworkX
适用场景：
- 实体间关系复杂的领域（金融产品关系、监管层级）
- 需要跨文档推理（对比分析、因果链）
- 知识量大但结构化程度低（研报、新闻）
4.6 Agentic RAG（Agent驱动RAG，2025-2026最前沿）
核心思想：用 LLM Agent 来控制整个 RAG 流程，动态决定每一步策略
传统 RAG：固定管线，Query → Retrieve → Generate
Agentic RAG：LLM Agent 自主规划检索策略
┌──────────────────────────────────────────────────────────┐
│ Agentic RAG 架构 │
│ │
│ [用户问题] │
│ ↓ │
│ [Router Agent] ── 分析问题类型和复杂度 │
│ │ │
│ ┌────┼──────────────┬─────────────┐ │
│ ↓ ↓ ↓ ↓ │
│ 简单 多跳 对比 计算 │
│ 问题 推理 分析 推理 │
│ │ │ │ │ │
│ ↓ ↓ ↓ ↓ │
│ 单次 迭代 多源 工具 │
│ 检索 检索+推理 并行检索 调用+检索 │
│ │ │ │ │ │
│ │ │ (检索→推理 │ (同时检索 │ (调用计算器 │
│ │ │ →再检索 │ 多个知识库 │ +检索公式说明) │
│ │ │ →再推理) │ →合并对比) │ │
│ └─────┴──────────────┴─────────────┘ │
│ ↓ │
│ [Quality Agent] 评估回答质量 │
│ │ │
│ ┌──────┴──────┐ │
│ 合格 不合格 │
│ │ │ │
│ ↓ ↓ │
│ [输出回答] [反馈修正,重新检索] │
└──────────────────────────────────────────────────────────┘
框架实现：
- LlamaIndex Agentic RAG (SubQuestionQueryEngine)
- LangGraph RAG Agent
- CrewAI RAG Agent
- Haystack Agent Pipeline
金融场景示例：
问题："对比Aave和Compound在2025年Q1的TVL变化，
分析原因，并评估哪个更适合保守型投资者"
Agent 规划：
Step 1: 检索 Aave 2025 Q1 TVL 数据 (DeFiLlama API)
Step 2: 检索 Compound 2025 Q1 TVL 数据
Step 3: 检索两者的利率变化和事件
Step 4: 检索风险评估框架文档
Step 5: 综合分析并生成对比报告
4.7 高级 RAG 技术总结对比
| 技术 | 解决的问题 | 实现复杂度 | 效果提升 | 适用场景 |
|---|---|---|---|---|
| HyDE | 短查询检索效果差 | 低 | 10-30% | 通用 |
| Multi-Query | 单一查询覆盖不全 | 低 | 15-25% | 复杂问题 |
| Reranking | 初始检索排序不准 | 中 | 20-40% | 所有生产系统 |
| Self-RAG | 幻觉和无关回答 | 高 | 15-30% | 高精度需求 |
| CRAG | 检索结果质量不稳定 | 中 | 10-25% | 开放域问答 |
| Graph RAG | 跨文档关系推理弱 | 高 | 显著（关系类问题） | 知识密集领域 |
| Agentic RAG | 固定管线不够灵活 | 极高 | 显著（复杂问题） | 多步推理/对比分析 |
知识点5: RAG vs Fine-tuning vs Long Context 决策树
5.1 三种方案对比
┌─────────────────────────────────────────────────────────────────┐
│ 知识注入 LLM 的三种路径对比 │
│ │
│ ┌────────────┐ ┌────────────┐ ┌─────────────────┐ │
│ │ RAG │ │Fine-tuning │ │ Long Context │ │
│ │ 检索增强 │ │ 微调模型 │ │ 超长上下文窗口 │ │
│ │ │ │ │ │ │ │
│ │ 外挂知识库 │ │ 写入权重 │ │ 直接塞上下文 │ │
│ │ 每次查询 │ │ 一次训练 │ │ 每次发送 │ │
│ └────────────┘ └────────────┘ └─────────────────┘ │
│ │
│ 类比（金融）： │
│ RAG = 业务员桌上放着产品手册，客户问什么翻什么 │
│ Fine-tuning = 业务员经过3个月培训，把产品知识记在脑里 │
│ Long Context = 每次接待客户，先把整本手册读一遍 │
└─────────────────────────────────────────────────────────────────┘
| 维度 | RAG | Fine-tuning | Long Context |
|---|---|---|---|
| 知识更新 | 秒级（更新文档即可） | 需重新训练（小时级） | 秒级（更新上下文） |
| 知识量 | 无限（向量库可无限扩展） | 有限（受训练数据量限制） | 受窗口限制（128K-2M） |
| 可溯源 | 强（附带文档引用） | 弱（知识混入权重） | 中（可定位上下文位置） |
| 准确性 | 依赖检索质量 | 依赖训练数据质量 | 依赖上下文位置 |
| 成本 | 中（向量库+检索+生成） | 高（训练GPU费用） | 高（大量input tokens） |
| 延迟 | 中（检索+生成两步） | 低（直接生成） | 高（处理长上下文慢） |
| 幻觉 | 低（有证据约束） | 中 | 低（信息在上下文中） |
| 部署复杂度 | 中（需要向量库基础设施） | 低（替换模型即可） | 低（仅需支持长上下文的模型） |
5.2 决策树
你有一个知识密集型 LLM 应用，应该用哪种方案？
[你的需求]
│
知识量有多大？更新有多频繁？
┌───────────┼───────────┐
↓ ↓ ↓
知识量小 知识量中 知识量大
更新少 更新适中 更新频繁
(<50页) (50-500页) (>500页)
│ │ │
↓ ↓ ↓
Long Context 先试 RAG 必须 RAG
直接塞上下文 │
│ 效果够好？
│ ┌───┴───┐
│ 是 否
│ │ │
│ ↓ ↓
│ RAG方案 RAG + Fine-tuning
│ 上线 结合使用
│
效果够好？
┌───┴───┐
是 否
│ │
↓ ↓
Long Context 尝试 RAG
方案上线
2025-2026 趋势：
- 模型上下文窗口越来越大（Claude 200K→1M, Gemini 2M）
- 但 RAG 仍然不可替代，因为：
1. 上下文越长，Needle-in-Haystack 准确率越低
2. 长上下文的 Token 成本依然很高
3. RAG 提供可溯源性，Long Context 不提供
4. RAG 支持动态更新，不需要每次把整个知识库发过去
黄金组合（2026最佳实践）：
RAG（检索相关文档） + Long Context（放入更多上下文） + Reranking（精选最优）
5.3 常见的错误选择
┌──────────────────────────────────────────────────────────────┐
│ 常见误区和纠正 │
│ │
│ 误区1："我们有200K上下文，不需要RAG了" │
│ 纠正：200K ≈ 300页文档。看起来很多，但： │
│ - 金融合规手册通常 1000+ 页 │
│ - 全部塞入=每次调用花费 $0.6+（按 Claude Sonnet） │
│ - Needle-in-Haystack 在 100K+ 时准确率下降 │
│ → 正确做法：RAG 检索最相关的 5-10 页，不到 10K tokens │
│ │
│ 误区2："Fine-tuning可以让模型记住我们的知识库" │
│ 纠正：Fine-tuning 擅长改变模型的"行为模式"，不擅长注入知识 │
│ - Fine-tuning 适合：特定的输出格式、领域术语、语气风格 │
│ - Fine-tuning 不适合：记住大量事实性知识（容易幻觉） │
│ → 正确做法：RAG 负责知识，Fine-tuning 负责行为 │
│ │
│ 误区3："RAG太复杂了，先用最简单的方案" │
│ 纠正：2025-2026 的 RAG 框架已经极度成熟 │
│ - LlamaIndex/LangChain：10行代码搭建基础 RAG │
│ - 向量数据库：Pinecone/Weaviate 全托管 │
│ → 正确做法：从 Naive RAG 开始，逐步加入高级模块 │
└──────────────────────────────────────────────────────────────┘
知识点6: RAG 评估 — RAGAS 框架与幻觉检测
6.1 RAG 评估的挑战
RAG 比普通 LLM 应用更难评估，因为有两个独立的环节需要评估：
1. 检索质量：找到的文档对不对？
2. 生成质量：基于文档的回答对不对？
任何一个环节出错，最终回答就会有问题：
┌─────────────────────────────────────────────────┐
│ RAG 错误类型矩阵 │
│ │
│ 检索结果 │
│ 相关 不相关 │
│ ┌────────┬────────┐ │
│ 生成 │ 正确 │ 幻觉 │ │
│ 忠实 │ (理想) │ (检索 │ │
│ │ │ 失败) │ │
│ ├────────┼────────┤ │
│ 生成 │ 幻觉 │ 完全 │ │
│ 不忠实 │ (生成 │ 失败 │ │
│ │ 失败) │ │ │
│ └────────┴────────┘ │
│ │
│ 因此需要分别评估检索和生成两个环节 │
└─────────────────────────────────────────────────┘
6.2 RAGAS 评估框架
RAGAS (Retrieval Augmented Generation Assessment) 是 2024-2026 年最主流的 RAG 评估框架，提供四个核心指标：
┌──────────────────────────────────────────────────────────────────┐
│ RAGAS 四大指标 │
│ │
│ 1. Faithfulness（忠实度） │
│ 定义：回答是否忠实于检索到的文档？是否有编造？ │
│ 计算：将回答拆分为多个陈述(claim) │
│ → 检查每个陈述是否能在检索文档中找到支持 │
│ → Faithfulness = 有支持的陈述数 / 总陈述数 │
│ 范围：0-1，越高越好 │
│ 目标：>0.85 │
│ │
│ 2. Answer Relevancy（回答相关性） │
│ 定义：回答是否针对问题？是否答非所问？ │
│ 计算：从回答反推可能的问题 │
│ → 计算反推问题和原始问题的语义相似度 │
│ → Answer Relevancy = avg(cosine_sim(generated_q, original_q)) │
│ 范围：0-1，越高越好 │
│ 目标：>0.80 │
│ │
│ 3. Context Precision（上下文精度） │
│ 定义：检索到的文档是否都是相关的？有多少噪声？ │
│ 计算：在检索到的 Top-K 中，相关文档的排名越靠前越好 │
│ → 使用 Precision@K 的加权版本 │
│ 范围：0-1，越高越好 │
│ 目标：>0.75 │
│ │
│ 4. Context Recall（上下文召回率） │
│ 定义：该检索到的文档是否都被检索到了？有没有遗漏？ │
│ 计算：Ground Truth 中的关键信息是否在检索到的文档中 │
│ → Recall = 被检索到的关键信息数 / Ground Truth 中的总数 │
│ 范围：0-1，越高越好 │
│ 目标：>0.80 │
└──────────────────────────────────────────────────────────────────┘
6.3 评估实战流程
# RAGAS 评估代码示例（2025-2026版本）
from ragas import evaluate
from ragas.metrics import (
faithfulness,
answer_relevancy,
context_precision,
context_recall
)
from datasets import Dataset
# 准备评估数据集
eval_data = {
"question": [
"Aave V3的清算阈值是多少？",
"COMP代币有哪些用途？"
],
"answer": [
"Aave V3的清算阈值根据资产不同而变化...",
"COMP代币主要用于治理投票..."
],
"contexts": [
["Aave V3 文档片段1...", "Aave V3 文档片段2..."],
["Compound 文档片段1...", "Compound 文档片段2..."]
],
"ground_truth": [
"Aave V3的清算阈值：ETH 82.5%, USDC 85%...",
"COMP用途：治理投票、协议参数调整..."
]
}
dataset = Dataset.from_dict(eval_data)
# 运行评估
results = evaluate(
dataset,
metrics=[faithfulness, answer_relevancy,
context_precision, context_recall]
)
print(results)
# {'faithfulness': 0.87, 'answer_relevancy': 0.82,
# 'context_precision': 0.78, 'context_recall': 0.85}
6.4 幻觉检测与防护
┌──────────────────────────────────────────────────────────────┐
│ RAG 幻觉的三种类型 │
│ │
│ 类型1: 内在幻觉（Intrinsic Hallucination） │
│ 定义：回答与检索文档矛盾 │
│ 例子：文档说"清算阈值80%"，回答说"清算阈值90%" │
│ 检测：将回答中的事实与文档逐条对比 │
│ │
│ 类型2: 外在幻觉（Extrinsic Hallucination） │
│ 定义：回答包含检索文档中不存在的信息 │
│ 例子：文档未提及利率，但回答编造了一个利率数字 │
│ 检测：检查回答的每个事实是否能在文档中找到来源 │
│ │
│ 类型3: 推理幻觉（Reasoning Hallucination） │
│ 定义：文档中的事实被错误推理/组合 │
│ 例子：文档A说"ETH价格3000"，文档B说"1ETH=3000USDT" │
│ 回答推理为"1USDT=3000ETH" │
│ 检测：验证推理链的每一步逻辑 │
└──────────────────────────────────────────────────────────────┘
幻觉防护策略（生产系统）：
层级1：Prompt 层面
"只基于以下文档回答。如果文档中没有相关信息，请说'根据现有文档无法回答'。"
"每个事实性陈述必须引用来源文档的编号。"
层级2：后处理验证
- NLI（Natural Language Inference）模型检查回答与文档的一致性
- 用另一个 LLM 做 Fact-Check（LLM-as-Judge）
- 关键数字/日期用规则引擎二次校验
层级3：架构层面
- Confidence Score: 让模型对每个陈述输出置信度
- Citation Required: 强制引用，无引用则标记为不确定
- Human-in-the-Loop: 低置信度回答转人工审核
金融场景特殊要求：
- 利率、金额等数字必须精确匹配文档原文
- 监管条款引用必须精确到条、款、项
- 任何不确定的回答必须明确声明"请以官方文件为准"
6.5 RAG 评估指标对比总览
| 指标 | 评估对象 | 是否需要Ground Truth | 自动化程度 | 金融场景权重 |
|---|---|---|---|---|
| Faithfulness | 生成质量 | 否（用检索文档） | 高 | 极高（合规核心） |
| Answer Relevancy | 生成质量 | 否 | 高 | 高 |
| Context Precision | 检索质量 | 是 | 高 | 中 |
| Context Recall | 检索质量 | 是 | 高 | 高 |
| Answer Correctness | 端到端 | 是 | 高 | 极高 |
| Latency | 系统性能 | 否 | 高 | 高（交易场景） |
| Cost per Query | 成本效率 | 否 | 高 | 高 |
今日思考
思考题1: 为什么 RAG 在金融合规场景中几乎是唯一选择？
回答：
金融合规有三个硬性要求，只有 RAG 能同时满足：
-
可审计性：监管要求每一条合规建议都能追溯到具体法条。RAG 天然支持引用出处，Fine-tuning 的知识混入权重后无法追溯，Long Context 虽然信息在上下文中但不够显式。
-
实时性：金融法规更新频繁（如 MiCA 2025 年实施后持续修订）。RAG 更新文档即时生效，Fine-tuning 需要重新训练，延迟数天到数周，在合规场景中不可接受。
-
准确性：金融数字（利率、阈值、罚则）必须精确无误。RAG 基于原始文档生成，配合 Faithfulness 检测可以保证精度。纯 LLM 可能"记错"利率数字，这在金融场景中是致命的。
此外，RAG 的知识库可以实施访问控制（不同角色看到不同文档），这与金融行业的信息墙(Chinese Wall)制度天然契合。
思考题2: 如果让你设计一个银行内部知识库的 RAG 系统，你会如何设计 Chunking 策略？
回答：
银行内部知识库文档类型多样，需要差异化的 Chunking 策略：
银行知识库 Chunking 策略矩阵：
文档类型 Chunking策略 Chunk大小 特殊处理
─────────────────────────────────────────────────────────────────────
监管文件/办法 Document Structure 按条款切分 每个Chunk携带
(章→节→条→款) "第X章>第Y节"路径
产品说明书 Document Structure 按产品要素切分 标题作为prefix
+ Parent-Child (利率/期限/资格) 送入Context
FAQ/话术库 一问一答为一个Chunk 200-500 tokens Q和A一起作为Chunk
操作手册/SOP 按步骤切分 500-800 tokens 保留步骤编号
研报/分析报告 Semantic Chunking 800-1200 tokens 保留图表描述
会议纪要/邮件 按议题切分 300-600 tokens 保留日期/参与人元数据
关键设计决策：
- 所有 Chunk 都要携带元数据（文档标题、日期、版本号、章节路径）
- 使用 Parent-Child 策略：小 Chunk 做检索，大 Chunk 做生成
- 监管文件采用层级索引：先定位到章节，再定位到具体条款
- 对表格做特殊处理：转为 Markdown 表格或键值对，不要截断
思考题3: Long Context 模型（1M+ tokens）会杀死 RAG 吗？
回答：
不会。2025-2026 年虽然 Claude 支持 1M tokens、Gemini 支持 2M tokens，但 RAG 仍然不可替代，原因如下：
-
成本：1M tokens 输入 = 单次调用 $3-15（按 2026 价格）。如果每天有 10 万次查询，这是不可承受的。RAG 只检索相关片段（通常 2K-10K tokens），成本降低 100-500 倍。
-
Needle-in-Haystack 退化：研究表明，当上下文超过 200K tokens 时，模型对中间位置信息的提取准确率明显下降（Lost in the Middle 效应）。RAG 把最相关的信息放在上下文开头，避免了这个问题。
-
可溯源性：Long Context 中模型可能混合多个文档的信息，难以精确标注引用来源。RAG 每个回答自带文档出处。
-
动态更新：向量数据库支持增量更新，新文档入库即可搜索。Long Context 方案需要每次重新组装完整上下文。
正确的关系：Long Context 是 RAG 的增强工具，不是替代品。2026 最佳实践是"RAG 检索 Top-K → 放入长上下文窗口 → 生成"，利用 Long Context 放入更多检索结果，而不是把整个知识库塞进去。
面试表达
30秒版本
RAG 是让 LLM "先查资料，再回答" 的架构模式，解决了 LLM 知识过时、幻觉和不可溯源三大问题。全链路分为离线索引（文档切分+向量化）、在线检索（BM25/Dense/Hybrid + Reranking）和增强生成三个阶段。2025-2026 的前沿技术包括 Self-RAG 自反思、Graph RAG 知识图谱增强、和 Agentic RAG 让 Agent 动态规划检索策略。在金融场景中，RAG 几乎是唯一选择，因为它同时满足可审计、实时更新和精确引用的合规要求。
2分钟版本
RAG 是 Retrieval-Augmented Generation 的缩写，核心思想是让 LLM 先从知识库检索相关文档，再基于检索到的证据生成回答。这解决了纯 LLM 的三大痛点：知识会过时、会产生幻觉、无法追溯信息来源。
架构分三个阶段：第一是离线索引，将文档切分成 Chunks 并向量化存入向量数据库。Chunking 策略的选择至关重要——切太小丢失上下文，切太大引入噪声。金融场景推荐按文档结构切分，保留章节层级关系。第二是在线检索，2026 最佳实践是混合检索——BM25 关键词匹配加 Dense 语义检索，再用 Cross-Encoder 做 Reranking。第三是增强生成，将检索到的文档注入 Prompt，引导 LLM 基于证据回答。
2025-2026 年有几个重要的进展：HyDE 通过生成假设文档来提升检索质量；Self-RAG 让模型自己判断是否需要检索以及结果是否可靠；Graph RAG 用知识图谱增强跨文档推理；Agentic RAG 用 Agent 动态规划多步检索策略。
评估方面，RAGAS 框架提供四个核心指标：Faithfulness 检查回答是否忠实于文档，Answer Relevancy 检查是否答非所问，Context Precision 和 Recall 评估检索质量。
在金融合规场景中，RAG 是几乎唯一的选择，因为它同时满足可审计性（每条回答有引用出处）、实时性（更新文档秒级生效）和准确性（基于原始文档而非模型记忆）。即使模型上下文窗口达到 1M+ tokens，RAG 仍不可替代——成本差 100 倍以上，且长上下文存在 Lost in the Middle 效应。
追问准备
Q1: RAG 的检索质量差怎么优化？
按优先级排列：首先确认 Chunking 策略是否合理，这是最容易被忽视但影响最大的环节；其次加 Reranking 层，Cross-Encoder 通常能提升 20-40% 的精度；然后尝试 Query Rewriting，包括 HyDE 和 Multi-Query 扩展；最后如果是混合查询场景，用 Hybrid Retrieval（BM25 + Dense + RRF 融合）。如果以上都做了效果仍不理想，考虑 Agentic RAG 让 Agent 自主规划检索路径。
Q2: RAG 系统如何处理幻觉？
三层防护：Prompt 层面要求模型"只基于文档回答，无法回答时明确声明"；后处理层面用 NLI 模型或 LLM-as-Judge 检查回答与文档的一致性，数字/日期用规则引擎二次校验；架构层面输出置信度分数，低置信度转人工审核。金融场景尤其要注意数字的精确性——利率、金额、日期必须与文档原文完全一致。
Q3: 你会怎么选择 Embedding 模型？
三个维度评估：第一是领域匹配度，如果是中文金融文档，优先选中英双语模型如 BGE-M3 或 Jina Embeddings v3；第二是维度和性能，生产环境推荐 768-1024 维度，平衡精度和存储成本；第三是 MTEB 排行榜得分，但要注意通用排行榜不代表你的领域表现。最佳实践是用你自己领域的数据做小规模评测（50-100 个 Query），对比 3-5 个候选模型的检索准确率。Day 6 会详细展开。
学习资源
核心阅读（必读）
| 资源 | 链接 | 说明 |
|---|---|---|
| RAG 原始论文 (Lewis et al., 2020) | arxiv.org/abs/2005.11401 | RAG 概念的提出 |
| Self-RAG (Asai et al., 2023) | arxiv.org/abs/2310.11511 | 自反思 RAG |
| CRAG (Yan et al., 2024) | arxiv.org/abs/2401.15884 | 纠正式 RAG |
| Microsoft GraphRAG | github.com/microsoft/graphrag | Graph RAG 官方实现 |
| RAGAS 文档 | docs.ragas.io | RAG 评估框架 |
| Anthropic RAG Cookbook | github.com/anthropics/anthropic-cookbook | Claude RAG 最佳实践 |
框架和工具
| 工具 | 用途 | 适用场景 |
|---|---|---|
| LlamaIndex | RAG 全链路框架 | 快速构建 + 高级 RAG（推荐首选） |
| LangChain | LLM 应用框架（含 RAG） | 通用 LLM 应用 |
| Haystack | 生产级 RAG 框架 | 企业级部署 |
| Ragas | RAG 评估 | 质量监控 |
| Pinecone / Weaviate / Qdrant | 向量数据库 | 生产存储 |
| Unstructured.io | 文档解析（PDF/Word/HTML） | 索引阶段预处理 |
| Cohere Rerank API | Reranking 服务 | 检索后重排序 |
学术论文（推荐精读）
| 论文 | 年份 | 核心贡献 |
|---|---|---|
| RAG (Lewis et al.) | 2020 | 提出 RAG 范式 |
| HyDE (Gao et al.) | 2022 | 假设性文档增强检索 |
| Self-RAG (Asai et al.) | 2023 | 自反思判断检索和生成质量 |
| CRAG (Yan et al.) | 2024 | 检索结果纠正机制 |
| GraphRAG (Microsoft) | 2024 | 知识图谱增强 RAG |
| ColBERT v2 | 2022 | 高效 Late Interaction 检索 |
| Lost in the Middle (Liu et al.) | 2023 | 长上下文中间信息丢失现象 |
| Agentic RAG Survey | 2025 | Agent 驱动 RAG 综述 |
视频教程
| 资源 | 说明 |
|---|---|
| LlamaIndex YouTube 频道 | RAG 架构深度讲解和实战 |
| DeepLearning.AI RAG 课程 | Andrew Ng 团队出品，系统性强 |
| Weaviate RAG Masterclass | 向量数据库 + RAG 实战 |
明日预告
Day 6: 向量数据库与 Embedding 模型
Day 6 核心内容预览：
1. Embedding 的本质：将文本映射到高维向量空间
2. 主流 Embedding 模型对比：OpenAI / Cohere / BGE / Jina / E5
3. MTEB 排行榜解读：如何选模型
4. 向量数据库核心：ANN 检索算法（HNSW / IVF / PQ）
5. 主流向量数据库对比：Pinecone / Weaviate / Qdrant / Milvus / ChromaDB
6. 向量数据库的生产部署考量：分片/副本/过滤/多租户
7. Embedding 微调：提升领域检索效果
8. 金融场景：中文金融文档的 Embedding 选择