pgvector · 概念深潜 · 面向 RAG / Agent 工程师
pgvector：当向量检索成为 Postgres 的一种索引
专用向量库把向量检索当成独立系统来设计。pgvector 反过来——它把向量检索塞进关系库的既有规则里：MVCC、planner、vacuum、事务。这份教程讲清楚这个选择带来了什么能力，又让哪些"理所当然"的事变得需要你显式处理。
基于：pgvector 0.8.2（2026-02）· PostgreSQL 16/17 · text-embedding-3 | 阅读时间：~半天（深潜） | 代码验证状态：概念教程，含可运行 SQL，标注「未本地验证」处除外
▸适合谁
这份教程假设你具备以下三项能力。缺任意一项，先补再读会更省力：
前置能力（具体到可验证）
- 能用 SQL 写带索引的查询、会读
EXPLAIN，知道 B-tree 索引为什么把全表扫描从O(N)降到O(log N)——本教程反复对照"普通索引 vs 向量索引"。 - 接受 embedding 是"输入文本、输出一串定长
float数组"的黑盒，且"语义相似 = 向量距离近"——不需要懂模型内部。这块不熟，先读隔壁 vector-database 教程的 01 概念。 - 大致知道 MVCC 与 vacuum 是什么（行的旧版本不立即物理删除、由 vacuum 回收）——本教程的核心就是把向量索引放进这套机制里看。不熟可先翻 postgresql 教程的 02-MVCC / 03-vacuum。
▸不适合谁
下面两类读者，他山之石更合适：
- 想学通用 ANN 算法原理的人（HNSW 图怎么贪心搜索、IVF 怎么聚类、PQ 怎么量化）：那是算法侧课题，去读隔壁 vector-database 教程的 02 索引。本教程只讲"这些算法塞进 Postgres 之后发生了什么"，算法内部一律引用、不重讲。
- 只想跑通一个 RAG demo 的人：用 Supabase / LangChain 的五行 quickstart 即可，不必读 MVCC 与 planner。本教程是为"要在生产里 debug 召回、做选型、扛住高频写入"准备的。
▸读完之后你能做到什么
一个有五年经验的后端工程师，读完官方 README 后通常仍说不清的那句话，是这份教程的核心交付：
pgvector 里几乎所有让人意外的行为——过滤后只返回 4 条、删了一批行召回突然崩到接近 0、给查询加个 DESC 索引就不走了、建索引慢到像挂死——都不是 bug，而是同一件事的推论：向量索引是 Postgres 的一种「ORDER BY 距离 LIMIT k」排序访问方法，必须服从 MVCC 可见性、planner 成本估算和 vacuum。把这条主线吃透，你不用背 20 条 troubleshooting，就能从症状反推根因。
具体地，你将能够：
- 写出正确的建表 + 建索引 DDL：为 1536 / 3072 维选对类型（
vectorvshalfvec）、选对 opclass（匹配 embedding 训练时的度量）、设对m/ef_construction。 - 量化召回而不是凭感觉：用
enable_indexscan=off取精确基准，算出 recall@k，把ef_search/probes调到目标召回。 - 诊断三类生产事故——过滤后欠返、churn 后召回腐烂、planner 不走索引——并对每一类说出根因与修复。
- 选对带元数据过滤的 RAG 检索策略：iterative scan vs partial index vs 先过滤再排序，知道各自的代价。
- 判断该用 pgvector 还是 pgvectorscale / 专用向量库，说得出分界线落在数据量、过滤选择性、写入频率的哪个位置。
一句话本质
- 向量搜索在 pgvector 里不是一个独立子系统，而是 Postgres 的一种「排序索引访问方法」（
amcanorderbyop：只服务ORDER BY 距离 LIMIT k）。 - 于是它必须服从关系库的 MVCC 可见性、planner 成本估算、vacuum 规则。专用向量库里理所当然的三件事——过滤后仍够 k 条、删除立即生效、召回长期稳定——在这里都成了这套规则的推论，需要你显式处理。本教程的每一章，都是这条主线的一个推论。
已沉淀的稳定内核：HNSW 是默认索引（0.5.0，2023-08）；并行建图（0.6.0，2024-01）；halfvec（fp16）/ sparsevec / bit 类型与 binary_quantize（0.7.0，2024-04）。CREATE EXTENSION vector; 在 RDS / Aurora / Cloud SQL / Supabase / Neon / Azure 上都已是一行的事。照这套教没问题。
仍在快速变化（近 6–18 月）：iterative index scan（0.8.0，2024-10）修了"带 WHERE 过滤欠返"这个老问题，并改了 planner 成本估算；最新 0.8.2（2026-02，支持 PG18）。但真正的创新发生在 pgvector 周围——pgvectorscale 的 StreamingDiskANN + 二值量化 SBQ（Tiger Data，2025-05 benchmark 宣称 50M 向量上 28× 低于 Pinecone 的 p95）、VectorChord 的 RaBitQ（2025，宣称建索引快 pgvector ~100×）、Google AlloyDB 的 ScaNN 索引（2025 年中 GA，注意：用的不是 HNSW）、以及把真正的 BM25 带进 Postgres 的 ParadeDB pg_search。
已被取代，别再学旧法：纯 IVFFlat → HNSW（IVFFlat 退居 legacy，只在低内存 / 极快建索引时用）；裸 float32 全维存储 → halfvec / 量化；带 WHERE 过滤用 post-filter 硬扛 → 0.8.0 的 iterative scan 或 partial index；hybrid 检索里的 ts_rank 词法腿 → BM25 扩展。
这份教程会刻意在某些地方放慢、让你先预测再看答案。若你读的时候冒出下面三句话，那是熟悉感在冒充掌握，不是学会了：
「我读得很顺」——顺，往往因为每个词都眼熟，不等于你能在空白页上重建它。
「我做题很快」——快，往往因为题型见过，换个场景就卡。
「我没卡壳」——没卡壳，往往意味着没触碰到真正的难点。
对策：每个 自测 和 想一想，先合上屏幕在脑子里（或纸上）答完，再展开对照。
▸概念地图
这张图是后面所有细节的挂载点。主干是一条竖线——它是一条向量在 pgvector 里的一生：从一列数据，变成排序契约，落成索引，活在 MVCC 里，最后在 planner 手里被查询。每读完一章，回到这里确认新学的概念挂在哪段上。
▸学习路径建议
顶部面包屑是完整顺序。按你的目的，也可以走这三条捷径：
- 只想建立心智模型（面试讲原理）：
01 数据模型→03 生命周期→06 自测。排序契约 + MVCC 是这套教程的"门面"，自测章的辨析场景是高频追问。 - 正在搭 RAG / Agent 检索层：
01 数据模型→02 索引构建→04 过滤检索。直奔建表建索引、量召回、带租户/语言过滤的查询。 - 要做技术选型 / 评审：
01 数据模型（速过）→03 生命周期→05 选型前沿。聚焦 churn 行为、何时 pgvector 不够、与专用库的分界。
▸目录
▸学完之后
这份教程把"向量检索在 Postgres 里"讲透。沿着它往外，下一步可以补：
- RAG 检索增强全链路：pgvector 是存储底座，往上是 chunking 策略、query 改写、rerank 与上下文组装——给你的 schema 加上"检索结果如何喂给 LLM"。见隔壁 rag 教程。
- 专用向量库：Qdrant / Milvus / Weaviate 的过滤、量化、多向量设计——给你的 schema 加上"当 pgvector 不够时，专用库多做了什么"。见 vector-database 教程的 04 选型。
- Postgres 调优：向量表也是表——autovacuum、
work_mem、分区、连接池在高 QPS 检索下怎么配。见 postgresql-tuning 教程。