~/blog/rag-learning-notes.md

我花了两周啃完 RAG，这是我理解的全部

ai pm·2026-02-01·~4500 字·14 min read

一个 AI 产品实习生的 RAG 学习笔记。不是教程，是我真的搞懂了之后写给自己看的东西。

起因

实习的时候接了一个教育智能体的项目。用户问问题，AI 回答。听起来简单。

但模型会编。它会非常自信地告诉你一个完全错误的知识点。在教育场景里，这不是「小问题」。

然后 mentor 说：上 RAG。

嗯，好。那 RAG 是什么？

在 LLM 回答之前，先从你的知识库里找到相关内容，塞进 Prompt，让它「有据可依」地说话。

核心公式：

formula

回答 = LLM( 用户问题 + 检索到的相关文档 )

不是让模型「记住」你的数据，是每次提问的时候，把答案提前喂给它。

RAG 的核心流程

其实就三步。

离线建库 —— 原始文档 → 提取文本 → 切块(Chunking) → 向量化(Embedding) → 存进向量数据库

在线检索 —— 用户提问 → 问题也转成向量 → 在向量库里找最像的 K 段。「语义相近」的文本，向量距离就近。

生成回答 —— 系统 Prompt + 用户问题 + 检索到的文档块 → LLM → 回答。模型看着参考资料回答，不容易编了。

为什么不直接用长上下文？2026 年了，Claude 200K，Gemini 1M+。但实际跑下来：贵、慢、Lost-in-the-Middle。产业共识：知识库 < 500 页直接长上下文，> 500 页必须 RAG，最佳方案是组合拳。

每一步都有坑

流程看起来简单，但每一步的选择都会影响最终效果。

分块（Chunking）：切大了不行，切小了也不行。切太大语义稀释，切太小信息碎片化。生产环境推荐：精确问答 256-512 tokens，复杂推理 512-1024 tokens，Overlap 10-20%。一个数据：自适应分块 87% 准确率 vs 固定分块 67%。

Embedding 模型：选错了后面全白搭。中文场景首选 bge-large-zh-v1.5（智源），API 调用选阿里 text-embedding-v3。选模型看语言 → 部署方式 → 维度和性能 trade-off。

向量数据库：别纠结太久。原型用 Chroma（pip install 就能用），生产看 Qdrant/Milvus/Pinecone。先把 pipeline 跑通再说。

四代 RAG 架构

理解「为什么会这样演进」比背概念更重要。

Naive RAG（2020-2022） —— 查询 → 向量检索 → Top-K → 塞 Prompt → 生成。线性流水线，简单但脆，检索错了就全错。

Advanced RAG（2023-2024） —— 检索前加查询重写/HyDE，检索中混合检索（向量+BM25），检索后 Reranking。混合检索 NDCG 提升 22-28%，Reranking 精度 +33% 延迟仅 +120ms。

Modular RAG（2024） —— 所有模块拆开可插拔。路由、检索、过滤、重排、生成每个环节独立替换。灵活但复杂。

Agentic RAG（2025-2026） —— 让 Agent 自己决定要不要检索、检索哪个库、结果够不够好。2026 年共识：已从实验性升级为生产默认架构。

生产环境的六种死法

理论再好，上线挂了就是挂了。一个扎心的数据：40-60% 的 RAG 实现没能上线生产。根因基本都在检索层。

检索失败 —— 查询和文档措辞不同，检索不到。→ 用 HyDE、查询重写、Contextual Retrieval

上下文丢失 —— 关键信息被切在两个 chunk 里。→ Parent-Child 策略、增大 Overlap

幻觉仍然存在 —— 模型忽略文档用自己的「知识」瞎编。→ 强化 Prompt 指令 + 降低 Temperature + CRAG 纠错

检索到不相关文档 —— Top-K 里混进噪音。→ 加 Reranking、设置相关性阈值

Token 超限 —— 检索太多文档塞不进上下文。→ 上下文压缩、动态调整 K 值

延迟太高 —— 用户等不了 10 秒。→ 缓存高频查询、异步检索、Prompt Caching（可降 90% 成本）

我实际用到的技术栈

在字节实习的教育智能体项目里，我的迭代路径：

iteration

P0：纯向量检索（Naive RAG）  ↓ 准确率不够P1：加 Contextual Retrieval  ↓ 关键词场景还是漏P2：混合检索（向量 + BM25）  ↓ Top-K 里有噪音P3：加 Reranker 重排序

每一步都是被实际问题逼出来的。不是一开始就设计好「我要用 Advanced RAG」，是 Naive RAG 不够用了才一步步往上加。

技术选型：Embedding 用 text-embedding-v4，向量库 ChromaDB（原型阶段），框架 LangChain，模型 DeepSeek-V3.2。

几个我记住的结论

Reranking 是性价比最高的优化 —— 加一个 Cross-Encoder，精度 +33%，延迟才多 120ms。如果你只能做一件事，做这个。

Chunking 策略影响比你想象的大 —— 不要用默认固定分块。至少试试递归分割。

评估不是事后想起来再做的事 —— 从第一天就定好 metrics（Context Precision、Faithfulness、Answer Relevancy），不然根本不知道改了是变好还是变差。

长上下文不是 RAG 的替代品，是搭档 —— 两个一起用。

先跑通再优化 —— Chroma + 递归分割 + bge-large-zh，三件套先跑起来，有了 baseline 再说。

RAG 不难。每一步拆开看都不难。难的是把每一步串在一起让系统在生产环境里稳定地跑，难的是知道什么时候该加什么。

写于 2026 年 4 月。一个还在学习的 AI 产品实习生。参考了 25+ 篇论文和工程实践文档。