在pgvector的实际使用中，维度选择往往是最容易被忽视却影响最深远的一个决策。维度选低了，向量的语义表达能力不足，检索结果不相关；维度选高了，索引体积膨胀、内存吃紧、查询延迟上升。这篇文章就来系统地聊一聊，PostgreSQL场景下向量维度到底该怎么选。
一、向量维度的本质：语义压缩的信息瓶颈
首先要明确一点：向量维度通常不是你自由决定的，而是由嵌入模型决定的。OpenAI的text-embedding-ada-002输出1536维，text-embedding-3-small默认1536维但支持降维到256甚至更小，BGE系列多为1024维或768维，一些轻量级模型只有384维。所以在讨论"选多少维"之前，真正的问题是：选哪个嵌入模型，以及要不要对高维向量做降维。
从信息论角度看，维度代表了模型对输入语义的压缩程度。高维向量能保留更多细粒度特征，比如文本中的情感倾向、专业术语的微妙差异等；低维向量则会丢失部分区分度。但这个关系并非线性——text-embedding-3在1536维降到256维后，MTEB基准上的性能损失非常有限，这说明很多维度携带的是冗余信息。
因此选择维度时的第一条原则是：优先跟随模型的原生输出维度。手动截断高维向量（比如只取前256维）在多数模型上会严重破坏语义，除非模型本身声明支持降维（如通过Matryonka策略训练的模型，截断前若干维后性能平滑下降）。这一点很多人踩过坑：直接把1536维向量砍成512维存进pgvector，检索质量断崖式下跌，还以为是索引参数配错了。
二、维度对pgvector索引性能的实际影响
pgvector目前支持两种主流索引：HNSW和IVFFlat。维度对两者的影响路径不同，需要分开看。
对于HNSW索引，每个向量节点在图中存储完整的向量数据。假设使用halfvec类型（float16，每维2字节），1536维向量的原始数据就是3KB。HNSW的构建过程需要大量距离计算，维度翻倍意味着每次距离计算的CPU开销近似翻倍，构建时间随之增长。在一个千万级数据集的实测中，768维向量的HNSW构建耗时约为384维的1.8倍左右，查询延迟也高出60%以上。
对于IVFFlat，维度主要影响倒排列表中存储的向量大小和扫描成本。查询时需要与候选列表中的向量逐一比较，维度越高，单次比较越贵，召回阶段的开销线性增长。可以看下面的对比：
-- 创建不同维度的向量列 CREATE TABLE items_384 (id bigserial PRIMARY KEY, embedding vector(384)); CREATE TABLE items_1536 (id bigserial PRIMARY KEY, embedding vector(1536)); -- 分别建HNSW索引，观察构建时间与大小差异 CREATE INDEX ON items_384 USING hnsw (embedding vector_cosine_ops); CREATE INDEX ON items_1536 USING hnsw (embedding vector_cosine_ops); -- 查询，观察延迟差异 SELECT id FROM items_384 ORDER BY embedding <-> '[0.1,0.2,...]' LIMIT 10;
存储方面也要算账：float32下每维4字节，一亿条1536维向量光是向量数据就超过600GB，而384维只需要约150GB。再加上索引开销，维度选择直接决定了你的硬件预算。如果内存放不下索引的工作集，查询会大量走磁盘，延迟会从毫秒级恶化到百毫秒级。
三、不同场景下的维度建议与压缩手段
结合实际场景，给出几条可参考的建议。
文本语义检索：如果追求效果上限且预算充足，1536维（text-embedding-3-small级别）是稳妥选择；如果是中小规模知识库（百万级以下），768维的BGE类模型性价比更高，效果与1536维的差距在多数业务上感知不明显。
图像与多模态特征：CLIP类模型输出512维，这个维度经过大规模数据训练验证，直接采用即可，没有必要再做降维。
推荐系统粗排：粗排阶段对召回率要求相对宽松，64到128维的二值化向量或量化向量能极大降低成本，配合pgvector的bit类型甚至可以做汉明距离检索。
当维度必须压缩时，有两条路径。一是模型自带降维，如text-embedding-3系列支持dimensions参数直接输出低维向量；二是事后量化，pgvector 0.7+提供了halfvec类型和二进制量化，halfvec将存储减半且精度损失极小，二进制量化后用向量积代替真实距离做粗筛再精排，可以把存储压缩到原来的十六分之一：
-- 使用halfvec列存储，存储减半
CREATE TABLE items_half (id bigserial PRIMARY KEY, embedding halfvec(1536));
CREATE INDEX ON items_half USING hnsw (embedding halfvec_cosine_ops);
-- 二进制量化做粗筛，原始向量精排
SELECT id, embedding <-> '[0.1,0.2,...]' AS distance
FROM items
WHERE binary_quantize(embedding) <~> binary_quantize('[0.1,0.2,...]')
ORDER BY embedding <-> '[0.1,0.2,...]' LIMIT 10;
最后给一个决策顺序：先根据效果要求选定嵌入模型，默认使用原生维度；当数据规模超过千万、索引内存成为瓶颈时，优先考虑halfvec和量化而不是换低维模型；只有在资源极度受限且效果要求不高时，才主动选择低维模型。记住一点，维度决策的核心从来不是"哪个数字最好"，而是在召回率、延迟、成本三者之间找到你的业务能接受的平衡点。
PostgreSQL向量维度pgvector向量数据库修改时间：2026-09-16 03:42:31