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曲線，別只看平均數，要看你業務關心的那個分位點。