RAG 入门：用 pgvector 给自己的博客搭问答机器人
Words: 1157Read Time: 3 minLast edited: 2026-8-4
RAG 是什么：先查资料，再开卷考试
博客写了一年多，攒了一百多篇文章。有个想法很自然：能不能做个问答机器人，读者提问时，它根据我写过的内容来回答？
直接问大模型肯定不行——它没读过我的博客，要么老实说不知道，要么现场编一段，编得还挺像那么回事。RAG（Retrieval-Augmented Generation，检索增强生成）就是解决这个问题的标准套路，流程分四步：
- 切分：把文章切成小段落（chunk）。
- 向量化：每个 chunk 用 embedding 模型算成向量，存进数据库。
- 检索：用户提问时，把问题也向量化，找出语义最接近的几个 chunk。
- 生成：把检索到的内容拼进 prompt，让模型"看着资料"回答。
本质就是把闭卷考试变成开卷考试：模型不依赖记忆，而是基于检索到的资料作答，幻觉大幅减少，回答还能带上出处。
为什么选 pgvector
向量存哪？专门的向量数据库（Milvus、Qdrant 这些）我研究过，但我服务器上本来就跑着 PostgreSQL，数据量也就几百个 chunk——为这点数据再运维一个新数据库，纯属给自己找事。pgvector 是 PostgreSQL 的扩展，装完就能在表里存向量、做相似度查询，小规模场景刚刚好。
服务器上装好扩展后建表：
写入：切分、向量化、入库
切分用最简单的定长滑动窗口：300 字一截，重叠 50 字，防止一句话被从中间砍断：
然后遍历所有文章，逐 chunk 算向量、入库：
检索与生成：把搜到的内容拼进 prompt
查询侧，pgvector 的
<=> 运算符算余弦距离，按距离升序取前 3 条，就是最相关的资料：注意 prompt 里那句"资料里没有就说不知道"——这句话一定要写。不写的话，检索不到相关内容时模型会凭印象硬答，RAG 就白做了。
chunk 大小的坑
整个项目里调最久的参数是 chunk 大小，它直接决定检索质量：
- 切太大（比如 1000 字）：单个 chunk 混了好几个话题，向量表达变得"四不像"，检索不准；拼 prompt 时还浪费 token。
- 切太小（比如 50 字）：每段都缺上下文，"这个配置改成 16384"这种 chunk 就算检索到了也没用——改的是哪个配置？
- 我的经验值是 200~400 字配 10%~20% 重叠，比较适合中文博客的段落密度。如果文章结构清晰，按标题和段落切比定长切效果更好。
另外提醒一句：chunk 多了之后记得给 embedding 列建索引（pgvector 支持 HNSW）。几百条数据全表扫描无所谓，上了万条就有感知了。
机器人上线后，我拿自己文章里的细节考它，比如"你服务器上 PostgreSQL 装的哪个版本"，它能准确答出来——因为它真的把那篇文章的片段翻出来看了。这种感觉还挺奇妙的。
Loading...