pg_embedding

背景：为什么向量搜索是 AI 时代的刚需

在 RAG（检索增强生成）场景中，"在海量文档中找到最相关的几段"是一个核心问题。传统的关系型查询（WHERE id = ?）无法回答"哪些段落和用户问题最相似"——这需要向量相似度搜索（Vector Similarity Search）。当你的知识库有百万条文档时，逐条比对 embedding 向量的计算成本是不可接受的，需要专门的索引加速结构。

pg_embedding 正是为解决这个问题而生——它在 PostgreSQL 内部实现了 HNSW（Hierarchical Navigable Small World）图索引，让你在熟悉的 SQL 环境中享受接近最优的向量查询性能，无需引入 Pinecone、Milvus 等独立的向量数据库。

起源：Neon 的技术押注与社区选择

pg_embedding 由云原生 PostgreSQL 平台 Neon 开发并开源（Apache-2.0），于 2023 年 7 月发布。项目基于学术界认可的 ivf-hnsw 实现，核心算法来自 2018 年 ECCV 论文 Revisiting the Inverted Index for Billion-Scale Approximate Nearest Neighbor Search（Malkov & Yashunin）。

2023 年 9 月，PostgreSQL 生态中最流行的向量扩展 pgvector 也正式引入了 HNSW 索引支持，Neon 随即宣布暂停 pg_embedding 的独立开发，将资源转向 pgvector 的 HNSW 实现。这意味着 pg_embedding 的核心价值已被 pgvector 吸收，但 pg_embedding 仍是研究 HNSW 算法在 PostgreSQL 落地方式的最佳参考实现。

技术原理：HNSW 是如何工作的

HNSW 是一种基于图的近似最近邻搜索算法，核心思想是构建多层缩略图：

1. 多层结构：最底层包含所有数据点；每上一层是下一层的随机采样子集，点数逐层减半。搜索时从最顶层入口，用贪婪法找到当前层的最近邻，然后下沉到下一层继续，直到最底层。
2. 邻居连接：每个数据点在每一层都与 M 个近邻相连（M 是可调参数）。M 越大索引越精确，但内存占用和建索引时间也越高。
3. 搜索复杂度：O(log N)，远优于暴力搜索的 O(N)，也优于 IVFFlat 的 O(√N)。

pg_embedding 提供了三种距离度量，通过 SQL 操作符直接使用：

• <-> 欧几里得距离（L2）
• <=> 余弦距离（Cosine）
• <~> 曼哈顿距离（L1）

创建 HNSW 索引只需一条 SQL，参数直观可调：

CREATE INDEX ON documents USING hnsw(embedding) 
WITH (dims=3, m=16, efconstruction=32, efsearch=32);

核心功能：从安装到生产级调参

部署方式是 pg_embedding 与 pgvector 最大的不同点——它不是 pip install 的 Python 包，而是需要从源码编译的 PostgreSQL C 扩展。这意味着：

• 需要 PostgreSQL 14+ 开发和运行环境
• 需要 postgres.h 头文件和 C/C++ 编译器（Makefile 指定 PG_CFLAGS += -Ofast 启用 GCC 自动向量化）
• 编译后在数据库内 CREATE EXTENSION embedding 启用

与 LangChain 的集成是 pg_embedding 的亮点。Neon 为 LangChain 提供专门的 PGEmbedding 封装，支持一键将文档切分、向量化并存储到 PostgreSQL：

from langchain.vectorstores import PGEmbedding
db = PGEmbedding.from_documents(
    embedding=embeddings, documents=docs, collection_name="my_kb"
)
db.create_hnsw_index(max_elements=10000, dims=1536, m=8, ef_construction=16)

调参指南：

性能对比：比 pgvector IVFFlat 快 5-30 倍

Neon 官方基准测试（GIST-960 数据集，960 维，100 万向量，k=100）在相同召回率下：

• pg_embedding HNSW 比 pgvector IVFFlat 快 5-30 倍
• 在 99% 召回率时，HNSW 性能优势最为显著

这背后的原因是：IVFFlat 基于聚类分区，查询需要扫描多个倒排列表；HNSW 基于图的贪婪搜索，O(log N) 的层间跳转比聚类扫描更高效。

但 pg_embedding 也有限制——早期版本 HNSW 索引完全存储在内存中（这也是速度快的部分原因）。Neon 后续版本已支持磁盘持久化 HNSW 索引，以适应 Neon 的无服务器架构（计算存储分离、无本地磁盘），代价是性能略有下降（~2x 差距）。

局限与风险：为什么现在更推荐 pgvector

pg_embedding 最大的风险是项目已停止维护（2023年9月），作者建议所有用户迁移到 pgvector。虽然代码仍可使用，但：

1. 无后续安全更新：PostgreSQL 版本升级可能带来兼容性问题，需要自己维护
2. pgvector 已是主流标准：pgvector 的 HNSW 实现由社区持续维护，与 PostgreSQL 核心版本保持同步
3. 功能差距：pgvector 支持内积距离（Inner Product），pg_embedding 不支持
4. 生产成熟度：pgvector 被数千个项目使用，经过大规模生产验证

行业意义：从"向量数据库"回归"数据库"

pg_embedding 和 pgvector 的竞争揭示了一个重要趋势：向量搜索不需要独立基础设施。当 PostgreSQL 本身能以接近专用向量数据库的性能处理嵌入向量时，"要不要引入新的技术栈"这个问题就变得值得重新审视。向量数据和业务数据共存于同一个事务中，备份、复制、权限管理都可以复用现有 PostgreSQL 生态，这是 pg_embedding/pgvector 这类扩展的核心价值所在。

579 个 GitHub stars 虽不算高，但作为 Neon 技术实力的展示和 HNSW 在 PostgreSQL 落地的参考实现，这个项目对理解向量搜索基础设施具有较高的技术参考价值。