我的RAG扫盲
用博客上的历史博文作为知识库搭建了一个基于我的博文回答问题的 Agent，用了 RAG 的技术，帮助自己更好的理解RAG 技术栈。
最近在做 AI Agent 项目，一下子接触到了很多新的专业术语。很多术语我都停留在“大概知道是干嘛的”这个层次，真要让我解释清楚它是怎么工作的，我其实说不明白。
所以我准备 各个击破。每个重要的概念，做一个 toy project，自己跑一遍整个流程。
RAG 是我的第一个学习目标。RAG 听过很多遍了，有些是同事说起的，有些是在 B 站看到的，甚至在抖音的评论区也看过，可见这个技术的火热程度。学习之前，我对 RAG 的理解停留在“做知识库”这个层面。
所以这篇文章主要记录两件事：
- 我是怎么一步步把 RAG 的主流程搞明白的
- 我是怎么基于自己的博客，做出一个最小可运行的 toy RAG 项目的
项目地址先放这：
什么是 RAG，我们为什么需要 RAG
RAG 全称是 Retrieval-Augmented Generation，一般翻译成“检索增强生成”。
如果只看名字，它有点抽象。但换成更直白的话，其实就是：
先去外部知识库里找资料，再把找到的资料和用户问题一起交给大模型，让它基于这些资料回答。
我一开始对它的理解是：
“把大的知识库分片，然后挑出一部分发给 LLM，而不是把整个知识库都发给 LLM。”
这个理解不能说错，但还不够完整，因为它只解释了“RAG 大概有用”，没有解释“为什么需要它”。
RAG 存在的必要性，主要来自下面几个现实问题。
1. 大模型并不天然知道你的私有知识
大模型参数里有很多通用知识，但它不知道你的公司文档、你的个人博客、你的产品手册、你的代码仓库。
这些内容如果不额外接进来，模型就只能靠猜。
2. 把整个知识库都塞进 Prompt 是不现实的
最朴素的想法是：既然模型不知道，那我把所有资料一股脑贴进去不就行了？
理论上可以，实际上通常不行。因为知识库一大，会立刻遇到几个问题：
- 上下文窗口有限：模型能吃进去的 token 是有限的
- 成本高：每次都把大量无关资料送进去，token 消耗会很夸张
- 噪音大：资料太多时，真正有用的信息反而会被淹没
- 延迟高：输入越长，调用越慢
所以问题不只是“能不能发给模型”，而是“能不能只发最相关的那一小部分”。
3. 纯靠大模型回答，容易幻觉
如果模型没有拿到足够的外部依据，它往往也不会老老实实说“我不知道”，而是根据自己见过的相似模式给你补一个看起来很像真的答案。
RAG 的价值就在于：
它尽量先把资料找出来，再要求模型基于资料回答。这样回答的依据更明确，调试时也能知道它到底是“没检索到”还是“看到了但总结错了”。
4. 知识变化很快，不适合全靠训练更新
像博客、文档、FAQ、产品说明这类内容，变化是很频繁的。
如果每次内容更新都去重新训练模型，成本太高，也不现实。
RAG 的思路是把知识放在模型外部：
知识更新了，只要重新做索引，不用重新训练模型。
所以我现在会把 RAG 理解成：
它不是一个新模型，而是一种系统设计：把“检索外部知识”和“基于知识生成答案”串起来。
RAG 的执行过程是什么样的
我后来真正开始理解 RAG，是因为把它拆成了两个阶段看：
- ingest 阶段：建索引
- chat 阶段：问答
如果用一句话概括：
- ingest 阶段负责“把知识库准备好”
- chat 阶段负责“拿用户问题去查，再基于结果回答”
可以先看整个主流程：
toy project
为了把这套流程真正走一遍，我基于自己的博客做了一个最小可运行的 RAG 项目：
- 项目地址：https://github.com/huojian-jan/blog-rag-lab
- 数据源是
data/目录里的博客链接清单 - 程序会抓取网页正文，切成 chunk，做 embedding，然后写入本地 Chroma
- 问答阶段通过命令行提问，先检索相关片段，再交给模型组织答案
- 输出结果时还会把参考片段、来源链接和相似度一起打印出来，方便调试
核心就是 Python、LlamaIndex、Chroma 和 OpenAI 兼容接口。它没有做 Web UI，也没有上复杂的检索策略，容易看清楚 ingest 和 chat 这两条链路到底分别在做什么。
小结
把这条链路拆开以后，我对 RAG 的理解就清楚多了。它其实就是把几件事按顺序串起来：
- ingest 阶段把外部知识整理成可检索的形式
- chat 阶段根据用户问题召回最相关的内容
- 最后再由模型基于这些内容组织答案
切 chunk、做 embedding、文档清洗、检索质量和 prompt 组织…，每个阶段都有很多值得深入研究的地方，但是因为我的目的不是发论文，只是在广度上补充我缺失的领域知识，暂时学习到这个层次就够了。