开篇：为什么我要给自己的博客搞一个 RAG 知识库
约 2702 字大约 9 分钟
2026-09-05
起因挺简单的
博客写了好几年，文章攒了两百多篇。前段时间我想回头翻一下自己写的 MyBatis 批量插入那篇文章——记得写过，里面做过一轮性能评估，想拿里面的结论来用。结果站内搜索输入「mybatis 批量插入」，愣是没搜出来。
我不信邪，翻了半天分类目录，最后才把那篇翻出来。一看标题我就明白了：当时起标题用的不是这几个词，我搜的关键词和标题的字面一个都对不上，站内搜索又是纯关键词匹配的，可不就找不着嘛。
这事让我愣了一下。文章就在那儿，知识就在那儿，但我自己——写这篇文章的人——想找它都得靠翻目录。那读者呢？他们更不可能知道我当年是怎么起标题的。
说白了，这就是关键词搜索的死穴：只认字面，不认意思。
而「认意思不认字面」，恰好是 RAG 最擅长的事。
所以这个系列要做的事情一句话就能说完：把我博客的文章全部喂给一个 AI，读者用大白话提问，AI 找到相关文章，读明白，然后替我回答。 顺便，我会把整个搭建过程写成系列文章——这些文章本身又会变成知识库的新语料。相当于博客在吃自己的狗粮，我感觉还挺有意思的。
为什么是 RAG，不是微调
先把最常见的疑问解决了：想让 AI 了解你的私有知识，不是还能微调吗？为什么选 RAG？
打个比方。微调像是让员工把公司手册背下来——背是背下来了，但你问他「上个月刚改的那条报销政策」，他还是答旧的，因为手册改版之后你得重新培训一遍。培训（微调）一次的成本高到离谱，动辄几天时间加不少显卡费用，而且改一条知识就得重来。
RAG 呢，像是给员工配一个随时能翻的公司手册——他不用背，你问什么，他先翻到对应那一页，照着最新版本回答。知识更新了？换个手册就行，员工不用重新培训。
对博客这个场景来说，答案太明显了：
- 我隔三差五就写新文章、改旧文章，知识是活的，RAG 重新灌一次语料就行，微调根本追不起这个更新频率
- 我希望答案能指出处——「这个结论出自你那篇 MyBatis 批量插入的评估」。微调把知识揉进模型权重里，出处就没了；RAG 天然知道答案来自哪几段
- 成本。个人项目，微调那个账单我看一眼都得缓缓
一句话记住
要模型的「风格」或「技能」，上微调；要的是「知识」，RAG 就够了。
所以这个系列只聊 RAG 路线。
那具体要做成什么样
先交代一下这个项目的形态，不然后面讲到一半你容易迷路。整个平台是一前端一后端：
- 管理端：我已经用 React + shadcn/ui 把壳子搭好了，叫 relax-admin。侧边栏按功能分了五组——「概览」「知识库」「运营」「系统」，语料管理、切片治理、会话洞察、评测中心、提示词安全、流量管控……这一系列的每一篇，几乎都能在它的侧边栏里找到对应的那一页。这个系列既是讲原理，也是讲「这一页背后的后端怎么实现」
- 后端：Spring Boot + Java AI（对接 realx-web，8031 端口），给管理端和聊天前台提供所有 API——这个系列要写的代码都在这头
- 聊天前台：给读者用的那个对话框，管理端管的是「厨房」，它管的是「餐厅」
📷 图片位（待补充）
应放什么图：relax-admin 整体界面全景截图（带侧边栏的主布局），最好展开「知识库」和「运营」两个菜单组，让读者第一眼看到整个系列要讲的功能版图。可以在图上把后续每篇要讲的菜单项简单标上序号。
对管理端来说，这个系列讲完的验收标准也很直白：侧边栏里每一个菜单项，点进去都有真实后端在响应，而不是现在的演示数据。
聊天这头的体验是这样的：你问「你之前写的那个防止重复下单是怎么弄的」，它会把相关文章片段翻出来，给你一段带引用的回答，每句话后面挂着类似「[1]《别让重复请求搞垮你的下单接口》」的来源标注，点进去能跳到原文。
拆开来看，这个「看起来就是个聊天框」的东西，背后其实是一条流水线：
离线这半条（文章入库）：
博客 Markdown → 解析 → 切分成小段 → 每段变成向量 → 存进 PGVector
在线这半条（用户提问）：
问题 → 改写 → 向量检索 + 关键词检索 → 精排 → 拼进 Prompt → 大模型生成 → 带引用的回答这两条线，就是这个系列的骨架。前面几篇讲离线那条（数据质量是 RAG 效果的根），中间几篇讲在线那条（检索怎么做准、回答怎么做可信），最后几篇讲怎么评测、怎么运营。目录已经放在 README 里了，这里不重复贴。
技术选型，以及为什么这么选
选型这事我先交底，顺便把理由说透——因为以后每一篇都在这个地基上盖楼。
语言和框架：Java + Java AI 1.1.x。 没什么可纠结的，我主力栈就是 Java，而且 Java AI 这两年的 API 已经相当成熟，ChatClient、VectorStore、ETL 管道这些抽象都有现成实现。
版本大坑
网上大量 Java AI 教程还停留在 1.0 之前的里程碑版本，包名和 API 跟 1.1.x 差别很大，照抄能让人怀疑人生。看资料认准 1.1.x 的官方文档。
向量库：PostgreSQL + PGVector，而不是 Milvus。 这可能是最有争议的一个决定，我先立个论点，第 07 篇会展开论证：向量库选型的第一问题不是「谁性能强」，而是「你的元数据过滤需求有多强」。 我这个场景要做「只搜某个分类下的文章」「排除草稿」「按时间过滤」这类操作，PG 一句 WHERE 就搞定，还能跟业务数据放同一个库里享受事务。至于性能——个人博客几百万 token 的量级，离 PGVector 的舒适区上限还远得很。加一个 Milvus 集群图什么？图运维吗？
模型：Embedding 必须选多语种模型，Rerank 单独选型。 中文知识库用纯英文语料训练的 Embedding 模型，等于让一个只会英语的人给中文做语义索引，效果可想而知。生成模型倒是随便，主流的都行。
语料：就是博客的 Markdown 文件，托管在 Gitee 仓库里。 relax-admin 里配了一个「Gitee 拉取型」知识库指向这个仓库，定时用 git diff 检测文章增删改，增量同步进管道——细节第 15 篇展开。另外 Markdown 自带标题层级、代码块这些结构信息，是做「结构化切分」的天然好材料。当然坑也有，第 04、05 篇细说。
我对这个系列的自我要求
写之前给自己立几条规矩，也让你知道能从这里指望到什么：
一，所有结论以跑通的代码为准。 前端壳子（relax-admin）已经就位，这个系列做的事是把它背后的后端整套补齐。文章里的代码都会真跑一遍，每个功能讲完，对应的管理端页面也就从演示数据变成了真实接口。
二，踩坑优先于顺利。 「按官方教程五分钟跑通」这种文章没有价值，有价值的是「第 4 分钟报了个维度不匹配的错，原因是这样这样」。所以你会看到大量失败模式的分析，我甚至给每个环节整理了「翻车方式清单」——有的是我自己预判会踩的，有的是这个领域公认的坑，我都会标清楚来路。
三，大白话，但不降低深度。 概念我一定用「翻译成人话」的方式讲（比如为什么换 Embedding 模型必须全量重建向量库——因为换模型等于换坐标系，北京的经纬度拿到上海坐标系里比位置，比出来的东西没有意义），但该到的深度一定到，不讲成朋友圈科普。
四，每篇独立成文。 通勤路上点开一篇能完整看完，不用翻前文。代价是偶尔要重复交代一两个背景，你多担待。
先泼一盆冷水
最后说点清醒的，免得你期待过高。
RAG 这东西，Demo 和能用的产品之间隔着一条鸿沟。网上「50 行代码搞定 RAG」的教程没骗你——确实 50 行就能跑，问「公司年假政策」它也能答得挺好。但等你真用了就会发现：换个问法它就抓瞎，专有名词搜不到，多聊两句它就开始胡编，引以为傲的「引用来源」有时压根对不上。
这些问题不是靠换更强的模型解决的，而是要在数据质量、检索策略、生成约束、评测体系这几层下笨功夫。这个系列的全部内容，说白了就是在填这些坑。
一个经验之谈
RAG 效果不好，八成问题出在数据（解析和切分），两成才是检索和模型。
所以你会发现这个系列的篇幅分配「头重脚轻」——讲怎么处理文章的篇幅比讲怎么调模型多得多。这不是比例失衡，这是优先级的真实样子。
行了，饼画完了。下一篇我们先把 RAG 这条管道从头到尾捋一遍，不写代码，就聊透一件事：数据从一篇 Markdown 变成一个有出处的回答，中间每一步到底发生了什么，以及每一步可能怎么搞砸。 搞明白这个，后面每一篇你都知道自己在哪一层干活。
有任何想让我优先讲的问题，评论区说，说不定就插队安排了。