在上一篇博客中，我们全面解析了 PostgreSQL（PG）的核心特性、实操落地场景，并对比了其与 MySQL 的核心差异，明确了 PG 在 AI 项目中的绝对优势——凭借 pgvector 插件，PG 可无缝实现向量存储与相似度检索，无需额外部署独立向量数据库。

而在 AI 项目（如 RAG 知识库、图片相似度检索、人脸比对）的实操过程中，最容易踩坑、也最核心的知识点，就是 pgvector 的向量算子与索引选型。
很多开发者明明建了索引，却依然查询卡顿、全表扫描，本质就是没搞懂算子与索引必须严格匹配；也有不少人混淆三种向量距离用法，导致检索结果不准、性能拉胯。

本文聚焦 pgvector 核心：向量算子、索引类型、场景选型、实操 SQL、避坑要点，完全承接上篇博客风格，看完直接可用到 RAG、图片检索、人脸比对等 AI 项目中。

一、前置基础：为什么向量检索必须懂算子和索引？

AI 项目中存储的文本 Embedding、图片特征都是高维向量（768维、1536维等），核心需求：给一个向量，快速找出最相似的 Top-N。

pgvector 高效检索依赖两个核心：

1. 向量算子：规定「用什么公式计算两个向量相似度」
2. 向量索引：给向量建目录，避免全表暴力遍历，实现毫秒级召回

一句话核心规则：

用什么算子查询，就要建对应类型的索引，不匹配直接索引失效、全表扫描

二、pgvector 三大向量算子原理与适用场景

核心速查表

向量算子	距离类型	核心特点	适用业务场景	匹配索引后缀
<=>	余弦距离	只看向量方向，忽略长度	RAG知识库、大模型文本语义、问答机器人	vector_cosine_ops
<->	欧氏L2距离	高维空间直线距离，关注整体数值差异	图片相似度、人脸比对、图像去重、特征校验	vector_l2_ops
<#>	向量内积	需向量提前归一化	推荐系统、算法精排、归一化向量检索	vector_ip_ops

1. 余弦距离 <=>：AI 文本 RAG 标配

原理
只判断向量夹角方向，不关注向量长度。
句子长短不一样，但语义相近，余弦距离依然很小。

适用场景

• 大模型 RAG 知识库
• 文章语义相似度
• 智能问答、文档召回

检索规则
数值越小越相似，排序用 ORDER BY xxx ASC

实操 SQL 示例

SELECT id, title, content,
       embedding <=> '[0.12,0.35,0.22,...]' AS similarity
FROM rag_knowledge
ORDER BY similarity ASC
LIMIT 10;

2. 欧氏距离 <->：图片/人脸验证专用

原理
计算高维空间中两个向量的直线距离，特征数值越接近，距离越小。

适用场景

• 图片相似度检索
• 人脸 1:N 比对
• 图像去重、内容校验
• 坐标类特征向量

检索规则
数值越小越相似，同样升序排序。

实操 SQL 示例

SELECT id, img_url,
       embedding <-> '[0.45,0.28,0.67,...]' AS similarity
FROM image_vector
ORDER BY similarity ASC
LIMIT 5;

经验：工业界图片、人脸比对默认都用欧氏距离，不用余弦。

3. 内积 <#>：归一化向量/推荐系统专用

原理
向量点积，必须先做归一化，否则结果完全不准。

适用场景

• 电商商品推荐
• 用户特征匹配
• 算法层已归一化的向量

检索规则
和前两个相反：数值越大越相似，需要 ORDER BY xxx DESC

实操 SQL 示例

SELECT id, product_name,
       embedding <#> '[0.32,0.56,0.19,...]' AS similarity
FROM product_vector
ORDER BY similarity DESC
LIMIT 8;

三、pgvector 两种向量索引：HNSW 与 IVFFLAT

全称与基础认知

• HNSW：Hierarchical Navigable Small World，层次化可导航小世界图
• IVFFLAT：Inverted File with Flat Compression，倒排平铺索引

1. HNSW 索引（90% AI 项目首选）

优点

• 检索速度极快、召回率高
• 无需复杂调参，开箱即用
• 适合百万级以内向量库

缺点

• 内存占用略高

适用场景
RAG 知识库、中小型向量库、追求简单高性能。

创建索引模板（余弦）

CREATE INDEX idx_emb_hnsw
ON rag_knowledge
USING hnsw (embedding vector_cosine_ops);

创建索引模板（欧氏）

CREATE INDEX idx_img_hnsw
ON image_vector
USING hnsw (embedding vector_l2_ops);

2. IVFFLAT 索引（海量千万级向量专用）

优点

• 内存占用低
• 适合千万级以上超大向量库

缺点

• 需要手动设置聚类 lists 参数
• 数据频繁插入场景性能不如 HNSW

适用场景
海量图库、大规模推荐向量、超大数据量检索。

创建索引示例

CREATE INDEX idx_emb_ivfflat
ON rag_knowledge
USING ivfflat (embedding vector_cosine_ops)
WITH (lists = 100);

四、最重要铁律：算子与索引必须严格配对

1. 查询用 <=> 余弦 → 索引必须 vector_cosine_ops
2. 查询用 <-> 欧氏 → 索引必须 vector_l2_ops
3. 查询用 <#> 内积 → 索引必须 vector_ip_ops

不匹配后果

• 索引完全失效
• 走全表扫描
• 数据量大直接超时、卡死

五、AI 项目最简选型口诀

• 做 RAG、大模型、文档问答 → 余弦 <=> + HNSW + vector_cosine_ops
• 做图片比对、人脸验证、图像去重 → 欧氏 <-> + HNSW + vector_l2_ops
• 做推荐系统、归一化向量 → 内积 <#> + 对应 ops
• 千万级超大向量库 → 改用 IVFFLAT

六、总结

1. pgvector 三大算子各司其职：余弦给文本、欧氏给图片、内积给归一化推荐；
2. 索引后缀必须和算子一一对应，是性能优化的底线；
3. 绝大多数 AI 业务直接用 HNSW，简单省心、毫秒级检索；
4. 只有千万级海量向量，才需要考虑 IVFFLAT。

掌握这套规则，就能在 PostgreSQL + pgvector 中优雅实现 RAG 知识库、图片检索、人脸比对等 AI 能力，完全不用额外部署沉重的专业向量库。