你接手了一個向量索引系統。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曲線,別只看平均數,要看你業務關心的那個分位點。
特別聲明:以上內容(如有圖片或視頻亦包括在內)為自媒體平臺“網易號”用戶上傳并發布,本平臺僅提供信息存儲服務。
Notice: The content above (including the pictures and videos if any) is uploaded and posted by a user of NetEase Hao, which is a social media platform and only provides information storage services.