为什么要系统学 RAG
我有一个 Obsidian wiki 系统当第二大脑，63 个页面，覆盖 AI、投资、哲学、运动四个领域。页面之间有 wikilink 交叉引用，三层信息流（收集→结构→公理）。平时想查一个概念，得自己翻目录、点链接、拼上下文。
这就引出一个自然的需求：给 wiki 加一个问答入口。输入”佛学无常和投资周期有什么关系”，系统从 63 个页面里找到相关的段落，拼好上下文，生成回答。
这就是 RAG——Retrieval-Augmented Generation。技术本身不复杂，但 RAG 的基础 pipeline 正在被平台快速吸收。2023 年要自己搭的 chunk → embed → retrieve → generate 全链路，现在 OpenAI File Search 一个配置就搞定了。Anthropic 有 Contextual Retrieval，Google 有 Vertex AI RAG Engine，AWS 有 Bedrock Knowledge Bases。
真正值得花时间的是三件事：评估体系、Agentic Workflow、数据治理。 平台替代不了，也是 RAG 从”能用”到”好用”的关键。
三个阶段
第一阶段：基础 RAG 系统设计
目标不是搭 demo，是建立”组件之间怎么配合”的直觉。
要搞明白的东西：
- 文档处理：PDF/HTML/Markdown 的解析策略，表格和图片怎么处理
- Chunking 策略：按长度切、按语义切、按结构切，各适合什么场景。没有万能方案，但要知道 trade-off
- Embedding 模型选择：OpenAI text-embedding-3-large vs 开源（BGE、E5、GTE），中文场景的选型差异
- 检索方式：Dense retrieval（向量搜索）+ Sparse retrieval（BM25），Hybrid Search 为什么比单一方式好
- Reranking：检索后的重排序，Cohere Rerank 或 cross-encoder 模型
产出标准： 独立完成一个支撑 1000+ 文档的问答系统，跑通”用户提问 → 检索 → 生成 → 返回答案”全链路，能用真实数据验证检索质量。
时间参考： 2-3 周（每天 2-3 小时）。
第二阶段：评估与可观测性
RAG demo 和生产系统最大差距在于：你能不能区分出了什么问题。
demo 时检索不好手动调两下就行，生产环境出了问题你得知道是检索的锅还是生成的锅。评估能力通用性很高——学会了，换到推荐系统、搜索系统都能用。
要搞明白的东西：
- 测试集构建：怎么造出覆盖面够广的（问题，相关文档，正确答案）三元组。不能只测 happy path
- 分层指标：
- Retrieval 层：Precision@K、Recall@K、MRR、nDCG
- Generation 层：Faithfulness（生成内容是否忠于检索结果）、Answer Relevancy（回答是否切题）、Citation Coverage（引用覆盖度）
- 工具链：Ragas、TruLens、DeepEval 这类评估框架怎么用
- 线上监控：用户反馈闭环、回归测试、检索质量漂移检测
产出标准： 给第一阶段搭的系统加上评估层，能自动化跑评测、输出指标报告、定位问题出在哪一环。
时间参考： 2 周。
第三阶段：纵深方向
基础打好了，根据你的项目选一个方向深挖。
方向 A：Agentic Workflow / Context Engineering
从”写一段固定的检索代码”变成”设计一个能自己做检索决策的 Agent”。
- 检索变成 Agent 的工具调用：搜几轮、换关键词、追线索、判断什么时候该停止
- Multi-step retrieval：先检索概览，再根据概览细化查询
- Tool use + RAG：Agent 自己决定用哪个知识库、要不要搜索、要不要调 API
- 长上下文信息密度管理：context window 在变大，但塞太多不相关信息会稀释答案质量
以我的 wiki 问答系统为例：用户问”无常和投资周期有什么关系”，Agent 要决定——先查哲学分区的无常概念，再查投资分区的周期理论，然后查有没有现成的跨域对比页面。每一步都可能需要换关键词、扩大检索范围、或者判断”够了，可以生成回答了”。
方向 B：数据治理与权限控制
企业场景下这个能力直接决定系统敢不敢上线。
- RBAC/ABAC 访问控制模型
- 向量检索层的 metadata 预过滤
- 多租户场景下的数据隔离
- 审计日志和合规追溯
适合 ToB 业务或有合规要求的场景。
方向 C：评估体系专家
第二阶段继续深化，成为”AI 系统质量”方向的专家。不只 RAG 评估，而是所有 LLM 应用的评测方法论。通用性最强，迁移成本最低。
实战项目：Wiki 问答系统
拿自己的 Obsidian wiki 做实战项目。63 个页面，四个领域（AI、投资、哲学、运动），有 wikilink 交叉引用，有分层结构。数据量适中，内容熟悉，能快速判断检索质量好坏。
阶段一 → Wiki RAG Pipeline
├── 数据源：63 个 wiki Markdown 页面
├── Chunking：按 section 切（每个 ## 块为一个 chunk）
├── Embedding：BGE-M3（中英混合内容）
├── 检索：Hybrid Search（向量 + BM25）
├── Rerank：cross-encoder
└── 生成：基于检索片段 + 页面 wikilink 上下文生成回答
阶段二 → 加评估层
├── 测试集：手写 30 个跨领域问题 + 预期相关页面
├── 指标：检索命中率 + 回答 faithfulness + wikilink 覆盖率
└── 监控：回答质量主观评分（1-5）
阶段三 → Agentic 升级
├── 简单事实查询 → 单次检索直接回答
├── 跨领域问题 → Agent 多步检索，先查一个领域再追线索到另一个
├── 概念对比 → Agent 主动查找 comparison 类页面
└── 反馈闭环 → 用户修正的答案回流为新的知识条目
这个项目的好处：做完之后 wiki 真的能用了，输入问题就能检索知识，比手动翻目录快得多。学以致用。
学习资源
按优先级排：
基础概念：
- LangChain RAG 从零到一（官方 tutorial，概念清晰）
- LlamaIndex 官方文档（比 LangChain 更聚焦 RAG 场景）
- Pinecone 的 Learning Center（向量数据库基础 + RAG 模式）
评估体系：
Agentic RAG：
- LangGraph 的 Agentic RAG 示例
- Contextual Retrieval（Anthropic 的方案，contextual chunk 提升检索质量）
中文 RAG 实战：
几个坑提前知道
- Chunk size 不是调参游戏。 50 tokens 和 500 tokens 的差距是文档结构决定的。结构化文档按结构切，自由文本按语义切，别迷信固定窗口。
- Embedding 模型的选择对中文场景影响巨大。 用英文模型跑中文，检索质量直接拉胯。BGE-M3 或 GTE-Qwen2 是目前中文场景比较好的选择。
- 评估应该在搭系统之前做。 先定义”好的回答长什么样”，再搭系统。不然搭完了没法判断改好了还是改差了。
- 平台化是趋势但覆盖不了所有场景。 OpenAI File Search 能搞定 80% 的情况，多租户权限、复杂 Agent 编排、评估体系这些，还得自己来。
我的策略
用 4-6 周把三个阶段跑完，基础不恋战，重点放在评估和 Agent 方向。Wiki 问答系统是最好的实战场地——做完直接能用到自己的知识管理流程里。
RAG 不会长期作为一个独立技术存在，它会变成 AI 工程的基础能力。但”懂 RAG”的含义在快速变化：两年前是”会搭 pipeline”，现在是”懂评估、能做 Agent 编排、理解数据治理”。再往后，可能所有 RAG 都是 Agentic 的，那时候比的就不是”会不会 RAG”，而是”能不能设计出让 Agent 在正确时机获取正确信息的系统”。