OpenAI嵌入模型藏了个开关：1536维砍到256维，检索质量几乎不降

你接手了一个向量索引系统。600万个文本块，用text-embedding-3-small生成1536维向量，HNSW图索引吃掉40GB内存，pgvector实例频繁换页，每次批量导入租户数据时p99查询延迟就往上飘。账单还能接受，基础设施快扛不住了。

同事甩给你一篇OpenAI的新嵌入模型博客，里面藏着一段容易被忽略的话：第三代模型支持截断。你可以直接请求256维向量，或者把已有的1536维向量砍掉前256个浮点数。按OpenAI的说法，MTEB上的检索质量几乎不动，索引体积直接缩到1/6，ANN搜索变快——每次距离计算只碰六分之一的内存。

听起来像白捡的优化。有时候确实是。有时候不是，而且失败模式很隐蔽：长尾用户突然反馈"什么都搜不到了"，你才知道出事了。

关键要理解Matryoshka表示学习。Kusupati等人的原始论文训练嵌入模型时，让每个输出向量的前缀本身就是可用嵌入。前64维能用，质量低；128维更清晰；256维继续提升；1536维是完整向量。模型在训练阶段就把这个特性 baked in，不是事后加工。

这和事后做PCA完全不同。PCA要在特定语料上拟合，找到最大方差方向，然后旋转嵌入让前k个轴承载最多信号。它有效，但需要代表性数据做拟合步骤，投影质量取决于拟合语料。Matryoshka在训练时就内建了同样的属性，无需拟合，截断前k个浮点数就是全部操作。

OpenAI的text-embedding-3-small（原生1536维，可截断）和text-embedding-3-large（原生3072维，可截断）都是这么设计的。Cohere的Embed v4也支持，提供1536和256两种宽度。Voyage的voyage-3-lite文档显示原生512维。但老模型不一样：text-embedding-ada-002、原始BGE检查点、MiniLM都不是Matryoshka训练出来的，截断它们只会产生损坏向量，不是更小的嵌入。这些得用PCA。

一个笔记本就能跑的小实验：拉取公开检索数据集（BEIR的NFCorpus、FiQA、SciFact不错，覆盖三种不同领域形态），用text-embedding-3-small嵌入所有段落和查询，在四个截断宽度（1536、768、512、256）上评估nDCG@10和recall@10。再用Matryoshka-aware的开源模型（nomic-embed-text-v1.5或bge-m3）做同样的事。

你会看到的典型形状，和OpenAI帖子报告的MTEB结果一致：text-embedding-3-small在FiQA风格检索上，1536维recall@10为0.640、nDCG@10为0.503；砍到768维，两个指标分别降到0.633和0.498，跌幅1%；512维是0.625和0.491，跌2%；256维是0.604和0.474。曲线平缓，但256维确实开始明显下滑。

什么时候截断安全？当你的查询分布和MTEB评测集类似，且对长尾召回的容忍度较高。什么时候PCA仍值得做？当你有领域特定的代表性语料，且愿意承担拟合和投影的运维成本。怎么在上线前判断？看recall曲线，别只看平均数，要看你业务关心的那个分位点。