最近在 CSDN 看到一篇讲 RAG 的文章，把文本嵌入、向量数据库、混合检索、重排序、Graph RAG、Agentic RAG 等概念放在一起梳理了一遍。这个话题很适合个人开发者继续拆开讲，因为很多人第一次做“知识库问答”时，容易把注意力都放在模型上：换更大的模型、换更贵的 API、换更长的上下文。
参考文章：https://blog.csdn.net/m0_65555479/article/details/160934582
但实际做下来，RAG 的瓶颈通常不在最后那个回答模型，而在前面的知识处理链路。模型只能基于你塞给它的上下文回答，如果检索出来的片段本来就不准，再强的模型也只是更流畅地编一个答案。
RAG 不是“把文档丢进向量库”
最粗糙的 RAG 流程看起来很简单：
- 把文档切块
- 用 Embedding 模型转成向量
- 存进向量数据库
- 用户提问时取 Top-K
- 把检索结果和问题一起发给大模型
这个流程能跑通 Demo，但离“可长期使用”还差很远。
问题通常出在三个地方。第一，原始文档解析不干净，PDF 页眉、目录、脚注、表格错位都混进了正文。第二，分块过粗或过碎，要么一个 chunk 里塞了太多主题，要么一句完整解释被切成两半。第三，只靠向量相似度检索，遇到产品名、版本号、错误码、函数名这类精确词时，反而不如关键词检索稳定。
所以 RAG 的第一步不是选哪个聊天模型，而是先问：知识能不能被正确拆开、正确召回、正确压进上下文。
私有知识库最怕“看似相关”
向量检索有个很迷惑的地方：它经常能找到“看起来相关”的内容。
比如你问“OpenClaw 技能怎么配置输入参数”，系统可能召回一段“OpenClaw 多 Agent 配置”的文章。主题都叫 OpenClaw，也都和配置有关，但真正回答不了你的问题。如果这些片段被送进模型，模型很可能会顺着上下文讲一段多 Agent，而不是老老实实说没有找到技能参数说明。
这就是为什么很多 RAG 系统刚开始看起来效果不错，用几天后就会暴露问题：常识性问题能答，具体到项目细节、错误排查、版本差异时就开始漂。
要减少这种漂移，至少要加两层处理：
- 检索阶段使用混合检索，把向量召回和关键词召回结合起来
- 生成前加入重排序，让更强的 rerank 模型重新判断哪些片段真正能回答问题
对个人项目来说，不一定一开始就上复杂架构，但“向量 + BM25 + rerank”这条路线值得优先考虑。它比盲目换更贵的大模型更直接。
分块策略比想象中重要
很多 RAG 教程会给一个固定 chunk size，比如 500 字或 1000 token。这个建议可以作为起点，但不能当成通用答案。
技术文档、博客文章、聊天记录、报错日志的结构完全不同。技术文档适合按标题层级拆，博客文章适合按小节拆，报错日志则可能要按一次完整请求或一次异常堆栈拆。如果全部按固定长度硬切，检索出来的内容就会缺上下文。
我更倾向于这样处理个人知识库：
- Markdown 和技术文章：优先按二级、三级标题拆分
- API 文档：接口说明、参数表、返回示例尽量放在同一个片段里
- 报错记录：错误信息、环境、解决方法不要切开
- 长教程：每个步骤可以单独成块，但保留标题路径
标题路径很有用。比如一个 chunk 的正文只有“执行 npm run build”，单独看没意义；如果元数据里带着“Cloudflare Pages 部署 AstroPaper / 构建命令配置”，模型就更容易理解它的适用场景。
什么时候需要 Agentic RAG
现在很多文章会提到 Agentic RAG，也就是让 Agent 自己判断要不要检索、检索几次、是否改写查询、是否调用工具继续验证。
这个方向很强，但不是每个知识库都需要一上来就做。
如果你的目标只是“根据固定文档回答问题”，普通 RAG 加上查询改写和重排就够了。Agentic RAG 更适合这类场景：
- 问题需要拆成多步，比如先查版本，再查配置，再查兼容性
- 知识来源不止一个，比如本地文档、GitHub issue、网页、数据库都要查
- 回答前需要执行验证，比如跑命令、查接口、打开页面确认
- 用户的问题本身不完整，需要结合上下文补全
换句话说，Agentic RAG 不是为了让架构看起来高级，而是当“单次检索”已经无法完成任务时，再引入规划和工具调用。
一个个人项目可落地的顺序
如果现在要给自己的博客、笔记或项目文档做一个 RAG 问答，我会按这个顺序来：
- 先整理 20 到 50 篇高质量文档，不急着把所有资料都塞进去
- 做干净的 Markdown 解析，去掉导航、广告、重复页脚
- 按标题层级切块，并把标题路径、来源链接、更新时间写进元数据
- 先用本地或低成本 Embedding 模型跑通向量检索
- 加入关键词检索，专门处理专有名词、命令、错误码
- 加 rerank，把 Top-20 压到真正可用的 Top-5
- 建一个小评测集，记录 30 个真实问题和理想答案
- 每次改分块、模型或提示词，都用这组问题回归测试
这套流程不花哨，但能避免大多数“Demo 很惊艳，实际很鸡肋”的问题。
最后
RAG 的价值不是让大模型显得更聪明，而是让它在回答时有可靠依据。
如果只是做一个演示，把文档向量化再拼进 prompt 就够了；如果要做一个每天都能用的个人知识库，就要把文档解析、分块、检索、重排、引用和评估都当成产品的一部分。
大模型负责表达，RAG 链路负责找证据。证据找错了，表达再好也没用。