嵌入尺寸：768、1536 或 3072 尺寸？

该英文文本是根据法文原文自动生成的，尚未经过审查。

该页面已自动翻译。英文版具有权威性。

本文基于 OpenAI 发布的官方文档、OpenAI 开发者社区讨论中收集的团队反馈以及 Aurabase 代码中验证的行为，该代码本机将这三个维度类路由到三个不同的向量列。每个外部图形都有日期和来源；有关我们应用于自己测量的方法，请参阅我们的基准测试方法支柱。

要点

对于大多数情况，1536 尺寸仍然是最平衡的选择：原生 text-embedding-3-small 或截断的 text-embedding-3-large，而不脱离 pgvector 的原生 HNSW 支持。
3072 维度 (text-embedding-3-large) 提供了 OpenAI 发布的最高 MTEB 分数（64.6% 与 62.3%），但超出了 pgvector 的 vector 类型的 2000 维度限制：HNSW 索引需要强制转换为 halfvec。
通过 OpenAI dimensions 参数（Matryoshka 技术）截断嵌入可以减少存储并加快搜索速度，但不会降低价格：这取决于查询的模型，而不是返回的向量的大小。
由于 halfvec 存储（每维 2 字节），3072 维向量在 Aurabase 中占用的原始磁盘空间与经典 vector 中的 1536 向量（每维 4 字节）相同：大约 6 KB。
Aurabase 本身支持 3 个维度类，768、1536 和 3072，每个维度类都有自己的列（在 aura-ai/src/embeddings/mod.rs中检查）：没有自由维度字段。

概述

768、1536 或 3072：每个级别的真正变化是什么

显然，在 text-embedding-3-small 和 text-embedding-3-large 之间进行选择首先相当于在 1536 到 3072 个原生维度之间进行选择，甚至在讨论截断之前。下表总结了 pgvector 在索引端本机识别的三个级别以及 Aurabase 路由的可验证事实。

标准	768尺寸	1536尺寸	3072尺寸
相关型号	OpenAI 截断，或遗留/开源（本机）模型	text-embedding-3-small（本机）或截断的 3-large	text-embedding-3-large（本机）
平均 MTEB 分数	OpenAI 并未以这种大小原生发布	62,3 %	64,6 %
OpenAI 指示性价格 / 100 万个代币	取决于查询的型号，而不是尺寸	0.02 美元（小）或 0.13 美元（大截断）	$0.13（文本嵌入-3-大）
总存储重量/矢量	3 KB（浮点数32）	6 KB（浮点32）	12 KB（矢量）或 6 KB（halfvec、Aurabase）
本地 HNSW pgvector 索引	是的	是的	否：需要投射 halfvec（>2000 暗淡）
Aurabase专栏（验证码）	嵌入_768	嵌入_1536	嵌入_3072

资料来源：OpenAI，官方博客“新嵌入模型和 API 更新”，2024 年 1 月 25 日（MTEB 评分和发布价格，使用前查看当前定价页面）； aura-ai/src/embeddings/mod.rs，Aurabase（列和索引支持，2026 年 8 月 24 日验证）。

存储

对存储的影响：改变一切的计算

嵌入像浮点数数组一样存储。在 pgvector 中，经典的 vector 类型将每个维度编码为 4 个字节 (float32)：因此，即使在计算 pgvector 标头和 Postgres 页面开销之前，768 个维度的每个向量的原始数据重量约为 3 KB，1536 个维度的重量约为 6 KB，3072 个维度的重量约为 12 KB。

这就是 halfvec 类型的 pgvector 的用武之地，它将每个维度编码为 2 个字节 (float16)，而不是 4 个字节。存储在 halfvec 中的 3072 维向量的重量约为 6 KB：正好是存储在经典 vector中的 1536 维向量的重量。

3KB

768 太阳

矢量，float32（4 字节/暗淡）

6KB

1536 太阳

向量，float32：与 halfvec 中的 3072 相同的权重

12KB

第3072章 太阳

经典向量，float32（转换 halfvec 之前）

直接且不直观的结果：在 Aurabase 中，从 1536 维到 3072 维不会使磁盘上的实际存储量增加一倍，因为 embedding_3072 列是通过 halfvec强制转换来查询的。因此，3072 维度的真正额外成本主要不是磁盘：而是相关 OpenAI 模型的价格，以及 vector类型的本机索引支持的输出，详细信息将在下一节中介绍。

pgvector / HNSW

为什么3072维度改变pgvector下的索引类型

pgvector 的 vector 类型不允许构建超过 2000 维的 HNSW 或 IVFFlat 索引。因此，3072 维超出了此限制：vector(3072) 列上的矢量搜索查询不能依赖近似索引，它依赖于完整的顺序扫描，在生产中的 RAG 语料库规模上不可用。

Aurabase 代码显式处理这种情况：在每个插入和搜索查询上，embedding_3072 列被转换为 halfvec(3072)，pgvector 可以索引最多 4000 个维度的这种类型。列 768 和 1536 仍然是原生的 vector，未强制转换，因为它们没有达到限制。

embeddings/mod.rs (extrait simplifié)rust

// 对于 3072 (>2000)，HNSW 不索引类型 `vector` → 转换 halfvec
fn vec_query_parts(dims: usize) -> AuraResult<(&'static str, &'static str, &'static str)> {
    match dims {
        768  => Ok(("embedding_768",  "", "::vector")),
        1536 => Ok(("embedding_1536", "", "::vector")),
        3072 => Ok(("embedding_3072", "::halfvec(3072)", "::halfvec(3072)")),
        other => Err(...), // 不支持的维度
    }
}

此细节还解释了为什么未在 [768, 1536, 3072] 中列出的嵌入维度在 Aurabase 端显式失败，而不是被接受然后索引不良：列名称始终来自固定的允许列表，而不是来自客户端发送的免费值。要深入了解在 Postgres 上构建除此特定案例之外的 HNSW 索引，请参阅我们的文章 HNSW 索引和 Postgres 向量搜索。

API成本

降低维度而不丢失一切：OpenAI 的 Matryoshka 截断

截至 2024 年 1 月，OpenAI 的 Embeddings API 接受 dimensions 参数，该参数可以缩短返回的向量，而无需重新调用不同的模型。该技术称为 Matryoshka 表示学习：该模型经过训练，将有用信息集中在向量的第一维中，以便截断逐渐而不是突然失去精度。

OpenAI在其公告中用一个具体例子说明了该技术的有效性：text-embedding-3-large，截断为仅256维，仍然超过了旧的text-embedding-ada-002在其全尺寸1536维下使用的MTEB分数（来源：OpenAI，官方博客，2024年1月25日）。在此特定基准测试中，小 12 倍的向量比完整向量的性能更好。

llm/openai.rs (extrait, requête d'embedding)rust

let body = json!({
    "model": self.embed_model,       // 例如“文本嵌入-3-大”
    "input": text,
    "dimensions": self.embed_dimensions, // 截断 3072 → 配置值
});

重要的一点，也经常被误解：截断并不会降低收取的价格。 OpenAI 根据查询的模型收费，而不是返回向量的大小，因为实际成本是对输入文本执行的计算。因此，从 text-embedding-3-large 请求 1536 个维度的成本与其 3072 个原生维度的价格相同（来源：OpenAI，官方博客，2024 年 1 月 25 日）；仅存储和搜索速度发生变化。

这正是 Aurabase 的默认选择，已在 config/mod.rs中验证：默认配置的模型是 text-embedding-3-large，但默认配置的输出维度是 1536，而不是 3072。因此，该服务为宽模型的表示付费，被截断以保留在本机 HNSW 中的可索引 vector 列上，而不需要 3072 所需的 halfvec 转换。

决定

根据您的用例选择哪个尺寸

1536 维仍然是大多数 RAG 或语义搜索项目的合理起点：text-embedding-3-small (62.3%) 的 MTEB 分数仍然接近大型模型的分数，存储仍然很轻，并且 HNSW 中经典的 vector 类型的 pgvector 索引无需任何特定配置。

当语料库不明确或技术性较高时，3072 维度是合理的，其中 62.3% 和 64.6% 之间的质量差距转化为您自己的查询（而不是一般 OpenAI 基准）上明显更好的搜索结果。 OpenAI 开发者社区讨论中记录的多个团队反馈都指向这个方向：3072 维度的增益是根据具体情况衡量的，不能假设。

当数量优先于细微差别时，768 维度特别适合：存储或计算预算是真正约束的大型语料库，或者使用 768 原生维度中已有的遗留嵌入模型。

决定前的简单规则

在您测量了自己语料库的代表性样本（而不仅仅是 OpenAI 发布的一般 MTEB 分数）的搜索质量之前，请勿设置维度。 MTEB对几十个异构任务进行平均；你的 RAG 语料库只是其中之一。

这种维度的选择是更大的 RAG 堆栈、嵌入、HNSW 索引、混合搜索的一部分，我们的页面 Native AI文档。

常见问题

我们最常被问到的问题

我们可以更改已索引的语料库的大小而不重新索引所有内容吗？+

不会。Aurabase 通过精确模型和维度（embedding_model 列 + 专用于维度的列）过滤每个语义搜索。以 1536 维度索引的语料库对于以 3072 维度执行的搜索来说是不可见的，反之亦然：更改维度需要在新类别下重新索引语料库。

双子座能让你超越3072维吗？+

不会。Aurabase 的 Gemini 客户端明确将维度上限限制为 3072 (outputDimensionality)。 3072 是 Aurabase 支持的三个类别（所有供应商的总和）所共有的上限。

您应该始终选择 3072 尺寸以获得最佳结果吗？+

不一定。面对 3072 所隐含的架构变化，1536 和 3072 之间的 MTEB 分数差异（根据 OpenAI，分别为 62.3% 和 64.6%）仍然不大：释放 vector类型的本机 HNSW 支持、强制 halfvec 转换以及宽模型的价格。在证明此成本合理之前，必须在您的语料库上验证收益。

用于生产中的 RAG 项目的 text-embedding-3-small 或 text-embedding-3-large？+

这取决于预算和语料库的性质，而不是普遍规则。 Text-embedding-3-small（1536个原生维度）以较低的成本覆盖了大多数情况； text-embedding-3-large 在不明确的语料库上是合理的，其中精度的增益是根据您自己的测试查询具体测量的，而不仅仅是一般 MTEB 分数。

综上所述

正确的选择不是最大的，而是最好的衡量的

768、1536 和 3072 尺寸不在单个轴上划分。 OpenAI 发布的 MTEB 分数提高了 3072，但离开了 pgvector 的原生 HNSW 支持，并付出了大型模型的代价，无论最终要求的尺寸如何。 1536 仍然是最常见的默认余额，包括 Aurabase。 768 服务于数量优先于细微差别的情况。

OpenAI 的 dimensions 参数改变了要问的问题：它不再是“选择哪个模型”，而是“接受哪个截断，在我的语料库上测得什么增益”。在最终确定生产选择之前，请在真实样本上测试搜索质量，而不仅仅是在一般基准上测试。我们的指南 RAG pipeline with pgvector 详细介绍了从摄取到混合搜索的完整设置。