pgvector 入门：用 PostgreSQL 搭你的第一个 RAG 检索层
发布：2026-10-02 · pgvectorAIRAG
RAG 应用的检索层未必需要独立向量数据库——如果你的主库已经是 PostgreSQL， pgvector 让你「一个库干完」。本文是从零到可用的最短路径。
参数与维度上限随版本演进，以 pgvector 官方 README 为准。
1. 安装与建列
CREATE EXTENSION IF NOT EXISTS vector;
-- 1536 对齐 OpenAI text-embedding-3-small；换模型就换成对应维度
CREATE TABLE docs (
id bigint PRIMARY KEY,
content text NOT NULL,
embedding vector(1536)
);2. 三种距离，三个操作符
| 距离 | 操作符 | 典型场景 |
|---|---|---|
| L2 欧氏距离 | <-> | 图像特征等量纲明确的向量 |
| 内积 | <#> | 已归一化向量的等价相似度（注意取负） |
| 余弦距离 | <=> | 文本 embedding 最常用 |
-- 建议入库存单位向量，检索一律用余弦
SELECT id, content
FROM docs
ORDER BY embedding <=> $1 -- $1 为查询文本的 embedding
LIMIT 5;3. 索引：ivfflat 与 hnsw 怎么选
不建索引 = 每次全表扫描比对（准确但慢）。两种近似索引：
| ivfflat | hnsw | |
|---|---|---|
| 构建 | 快 | 慢（写入友好度也一般） |
| 查询召回 | 依赖 probes 调参 | 通常更高更稳 |
| 内存 | 较低 | 较高 |
| 建议 | 数据量小/内存紧 | 大多数新项目默认选它 |
-- hnsw：余弦距离索引
CREATE INDEX ON docs
USING hnsw (embedding vector_cosine_ops);4. 召回不够？先调查询参数再换库
SET hnsw.ef_search = 100; -- 默认 40，越大召回越高、越慢
SET ivfflat.probes = 10; -- ivfflat 的对应参数一个实用判断：99% 的「向量检索不准」是 ef_search/probes 太低或数据没归一化， 不是 PG 不行。
5. 和普通 SQL 混用才是杀手锏
向量库做不了的「先过滤再检索」，在 PG 里是一条 SQL：
-- 只在租户自己的文档里做语义检索
SELECT id, content
FROM docs
WHERE tenant_id = 42 -- 结构化过滤
ORDER BY embedding <=> $1
LIMIT 5;配合 pgvectorscale（Timescale 开源的向量扩展，StreamingDiskANN 索引更省内存） 或分区表，千万级向量的场景也有可用的路径。
落地清单
- embedding 列统一存归一化向量；
- 检索一律走索引操作符（
ORDER BY embedding <=> $1），别用函数包装； - 批量写入后再建索引，比边写边建快得多；
- 上线前用真实分布的查询测召回率，再定 ef_search。
更多生态选型见生态目录。
本文为 pgcn.cc 原创内容，转载需授权并保留链接。勘误/投稿： 联系方式。