向量维度怎么选：省内存的钱，别省召回率

维度是什么账

Embedding（嵌入）模型把一段文本变成一串浮点数，这串数的长度就是维度（dimension）。

维度不是越大越好。

它同时决定三件事：检索质量的上限、内存占用、API 账单。

其中最容易被忽略的是第二件。我上次帮朋友算一个内部知识库的成本，翻车就翻在这里。

先算一笔内存账

一条 1536 维的向量，用 float32（32 位浮点数）存，是 1536 × 4 字节 = 6KB。

放大到规模：100 万条约 6GB，1000 万条约 60GB，1 亿条约 600GB。

这还只是裸向量。HNSW（分层可导航小世界图，主流向量索引结构）的图结构开销还没算进去。

3072 维（text-embedding-3-large 的默认维度）直接翻倍：1 亿条就是 1.2TB。

向量检索是内存密集型操作。HNSW 图放不进内存的那一刻，查询要读盘，p99 延迟（99 分位延迟）从毫秒级跳到几百毫秒。这个坎不是报错，是慢慢变卡，很容易误判成「网络问题」。

API 价格账

价格差距没有内存那么夸张，但也不小。

（价格核实日期 2026-10-12，来源 OpenAI 与 Voyage 官方定价页）

• OpenAI text-embedding-3-small：1536 维，$0.02/百万 token
• OpenAI text-embedding-3-large：3072 维，$0.13/百万 token
• Voyage voyage-4-large：$0.12/百万 token，voyage-4-lite $0.02/百万 token
• Voyage 的 voyage-4 一代每账户送 2 亿免费 token

按 1 亿 token/月的用量算，最贵的 Voyage large 也就 $12/月。

embedding 的钱通常是整个 RAG（检索增强生成）系统里最便宜的一环。

向量库的内存才是大头。

降维的正规姿势

OpenAI 的 v3 系列支持 dimensions 参数，可以把 3072 维砍到 1024。

这个技术叫 Matryoshka representation（套娃表示法），训练时就为截断做了优化。

from openai import OpenAI
client = OpenAI()
resp = client.embeddings.create(
    model="text-embedding-3-large",
    input="向量维度怎么选",
    dimensions=1024,
)

Voyage 的做法不同：模型本身就是多档位（large / 标准 / lite），换档位而不是传参数。

pgvector（PostgreSQL 的向量扩展）0.7.0 加了 halfvec 类型，用 16 位浮点存，存储直接减半，维度上限从 2000 提到 4000。

怎么定档位

我自己的经验值：768 到 1024 维够覆盖大部分应用，再往上收益递减得很快。

具体分档。

百万级以下文档用 1536 维 small 档就够。文档到千万级，先降维到 1024 再考虑换索引。

亿级以上，降维和量化（quantization，把 float 压成 int8 或二值）两件一起做。

一个容易踩的坑：换了 embedding 模型，全库向量必须重算。

新旧模型的向量空间不通，混着比相似度没有意义。

所以选维度要在建库前定好。中途改维度，迁移成本等于重建一遍库。

另一个坑是长度。

OpenAI 的上限是 8191 token，Voyage 是 32K。切文档超了会静默截断，超出部分直接丢掉。

检索质量莫名其妙变差时，先查这个。

怎么验证

不用信任何人的 benchmark（基准测试），自己跑一遍最快。

拿 50 条真实查询，人工标出每条的应命中文档。

然后分别用不同维度跑召回率（recall@5，前 5 条里命中几条）。一小时能做完。

结果比任何评测榜单都贴近你的真实数据。

我上次做这步时发现，1024 维和 3072 维的 recall@5 只差 1 条，但内存差了一倍。

这个结果直接决定了那次选型。