一個模型搞定所有 K：OMEGA 讓向量搜尋不再糾結
Efficient Vector Search in the Wild: One Model for Multi-K Queries做 RAG 系統的人一定碰過這個問題：top-K 的 K 到底要設多少？有時候使用者只要最相關的 1 筆結果，有時候要 100 筆做後續 rerank。現有的 learned index 方法有個尷尬的限制 → 模型是針對特定 K 值訓練的，換個 K 就掉效能或掉準確度。上海交大、Boston University 和阿里巴巴的團隊提出了 OMEGA，一個模型就能處理任意 K 值的向量搜尋，延遲降低 6-33%，而且預處理時間只要現有方法的 16-30%。
🔍 為什麼固定 K 是個問題
先解釋一下 learned top-K search 是什麼。傳統的向量搜尋（像 HNSW、IVF）用固定的索引結構，不管你查 top-1 還是 top-100，走的路徑邏輯是一樣的。Learned search 的想法是：用機器學習模型來預測「對於這個 query，應該搜尋哪些 partition」，這樣可以跳過大量不相關的區域，又快又準。
但問題來了。如果模型是用 K=10 訓練的，碰到 K=1 的查詢，它會搜尋比必要更多的 partition → 浪費時間。碰到 K=100 的查詢，它搜尋的範圍又不夠 → recall 掉了。你可能會想：那就每個 K 都訓練一個模型？理論上可以，但預處理的時間會爆炸，在生產環境完全不可行。
真實世界的向量搜尋服務，K 值分佈是很雜的。一個搜尋系統可能同時收到 K=1 的精準查詢和 K=500 的批次查詢，你不可能為每個 K 都準備一個模型。
🛠️ OMEGA 怎麼解決的
OMEGA 的核心觀察很漂亮：一個在 K=1 上好好訓練的 base model，其實已經包含了「哪些 partition 離 query 最近」的關鍵資訊。從 K=1 出發，向上擴展到更大的 K 比從零開始訓練容易得多。
具體做法有兩個關鍵設計：
第一個是「trajectory-based features」。訓練時不只看最終結果，還把搜尋過程中的軌跡特徵也納入模型輸入。這些特徵記錄了「在尋找 top-1 的過程中，哪些 partition 差一點就被選上」。這個資訊對預測更大 K 值的答案非常有用 → 差一點沒進 top-1 的，很可能就在 top-10 裡。
第二個是「dynamic refinement」。對於比訓練 K 更大的查詢，OMEGA 不是重新跑一次完整搜尋，而是在 base model 的結果上做漸進式擴展。它利用 top-K search 的一個統計特性：隨著 K 增大，新增的結果通常在已找到結果的「鄰域」裡。所以只需要在附近的 partition 做局部搜尋就好，不用全局重算。
對於比訓練 K 更小的查詢，OMEGA 直接用 base model 的結果取前幾名，因為 K=1 的模型已經把最相關的 partition 排在最前面了，截斷就好，幾乎沒有額外開銷。
另外，他們還做了一個 model invocation 的優化：利用統計方法判斷什麼時候 refinement 可以提前停止，減少不必要的模型調用次數。
實測數字：
- 在相同 recall 目標下，平均延遲比 SOTA 方法低 6-33%
- 預處理時間只需要現有方法的 16-30%
- 在多個公開資料集和生產資料集上都驗證了
💡 對 RAG 基礎設施的啟示
我覺得這篇論文解決的是一個被低估的工程痛點。做 RAG 系統的時候，大家都在關注 embedding model 選哪個、chunk size 怎麼設，但 vector search 這一層的效率問題其實很容易成為瓶頸，特別是在 QPS 高的場景。
OMEGA 的 16-30% 預處理時間這個數字很吸引人。在生產環境，index 的建置和更新成本常常被忽略。如果你的資料每天都在增長，index 需要頻繁重建，預處理時間的節省直接轉化為基礎設施成本的降低。
不過我有幾個疑問。
第一，K=1 base model 的品質決定了一切。如果 base model 訓練得不好，上層的 refinement 也救不回來。論文用的資料集都是公開 benchmark 和阿里巴巴的生產資料，在其他分佈差異大的資料集上效果如何，還需要驗證。
第二，dynamic refinement 在極端大 K（比如 K=1000）的時候，局部搜尋的假設是否還成立？如果 K 大到接近資料集的一定比例，「鄰域」的概念就變得模糊了。
第三，這個方法跟現有的 vector database（Milvus、Qdrant、Weaviate）的整合門檻有多高？論文偏學術，沒有討論工程落地的細節。如果需要大幅修改底層索引結構，實際採用的阻力會不小。
不管怎樣，「一個模型服務多個 K」這個方向是對的。真實世界的搜尋系統需要的就是這種靈活性。如果你正在為 RAG pipeline 選型向量搜尋方案，OMEGA 的思路值得追蹤，特別是阿里巴巴自己也是作者之一，後續可能會落地到他們的雲端服務裡。
你的 vector search 層現在是怎麼處理多 K 查詢的？也許是時候重新評估了。
📎 論文連結
做 RAG 系統的人一定碰過這個問題：top-K 的 K 到底要設多少？有時候使用者只要最相關的 1 筆結果，有時候要 100 筆做後續 rerank。現有的 learned index 方法有個尷尬的限制 → 模型是針對特定 K 值訓練的，換個 K 就掉效能或掉準確度。上海交大、Boston University 和阿里巴巴的團隊提出了 OMEGA，一個模型就能處理任意 K 值的向量搜尋，延遲降低 6-33%，而且預處理時間只要現有方法的 16-30%。
🔍 為什麼固定 K 是個問題
先解釋一下 learned top-K search 是什麼。傳統的向量搜尋（像 HNSW、IVF）用固定的索引結構，不管你查 top-1 還是 top-100，走的路徑邏輯是一樣的。Learned search 的想法是：用機器學習模型來預測「對於這個 query，應該搜尋哪些 partition」，這樣可以跳過大量不相關的區域，又快又準。
但問題來了。如果模型是用 K=10 訓練的，碰到 K=1 的查詢，它會搜尋比必要更多的 partition → 浪費時間。碰到 K=100 的查詢，它搜尋的範圍又不夠 → recall 掉了。你可能會想：那就每個 K 都訓練一個模型？理論上可以，但預處理的時間會爆炸，在生產環境完全不可行。
真實世界的向量搜尋服務，K 值分佈是很雜的。一個搜尋系統可能同時收到 K=1 的精準查詢和 K=500 的批次查詢，你不可能為每個 K 都準備一個模型。
🛠️ OMEGA 怎麼解決的
OMEGA 的核心觀察很漂亮：一個在 K=1 上好好訓練的 base model，其實已經包含了「哪些 partition 離 query 最近」的關鍵資訊。從 K=1 出發，向上擴展到更大的 K 比從零開始訓練容易得多。
具體做法有兩個關鍵設計：
第一個是「trajectory-based features」。訓練時不只看最終結果，還把搜尋過程中的軌跡特徵也納入模型輸入。這些特徵記錄了「在尋找 top-1 的過程中，哪些 partition 差一點就被選上」。這個資訊對預測更大 K 值的答案非常有用 → 差一點沒進 top-1 的，很可能就在 top-10 裡。
第二個是「dynamic refinement」。對於比訓練 K 更大的查詢，OMEGA 不是重新跑一次完整搜尋，而是在 base model 的結果上做漸進式擴展。它利用 top-K search 的一個統計特性：隨著 K 增大，新增的結果通常在已找到結果的「鄰域」裡。所以只需要在附近的 partition 做局部搜尋就好，不用全局重算。
對於比訓練 K 更小的查詢，OMEGA 直接用 base model 的結果取前幾名，因為 K=1 的模型已經把最相關的 partition 排在最前面了，截斷就好，幾乎沒有額外開銷。
另外，他們還做了一個 model invocation 的優化：利用統計方法判斷什麼時候 refinement 可以提前停止，減少不必要的模型調用次數。
實測數字：
在相同 recall 目標下，平均延遲比 SOTA 方法低 6-33% 預處理時間只需要現有方法的 16-30% 在多個公開資料集和生產資料集上都驗證了
💡 對 RAG 基礎設施的啟示
我覺得這篇論文解決的是一個被低估的工程痛點。做 RAG 系統的時候，大家都在關注 embedding model 選哪個、chunk size 怎麼設，但 vector search 這一層的效率問題其實很容易成為瓶頸，特別是在 QPS 高的場景。
OMEGA 的 16-30% 預處理時間這個數字很吸引人。在生產環境，index 的建置和更新成本常常被忽略。如果你的資料每天都在增長，index 需要頻繁重建，預處理時間的節省直接轉化為基礎設施成本的降低。
不過我有幾個疑問。
第一，K=1 base model 的品質決定了一切。如果 base model 訓練得不好，上層的 refinement 也救不回來。論文用的資料集都是公開 benchmark 和阿里巴巴的生產資料，在其他分佈差異大的資料集上效果如何，還需要驗證。
第二，dynamic refinement 在極端大 K（比如 K=1000）的時候，局部搜尋的假設是否還成立？如果 K 大到接近資料集的一定比例，「鄰域」的概念就變得模糊了。
第三，這個方法跟現有的 vector database（Milvus、Qdrant、Weaviate）的整合門檻有多高？論文偏學術，沒有討論工程落地的細節。如果需要大幅修改底層索引結構，實際採用的阻力會不小。
不管怎樣，「一個模型服務多個 K」這個方向是對的。真實世界的搜尋系統需要的就是這種靈活性。如果你正在為 RAG pipeline 選型向量搜尋方案，OMEGA 的思路值得追蹤，特別是阿里巴巴自己也是作者之一，後續可能會落地到他們的雲端服務裡。
你的 vector search 層現在是怎麼處理多 K 查詢的？也許是時候重新評估了。
📎 論文連結：https://arxiv.org/abs/2603.06159
#VectorSearch #RAG #Efficiency #GenAI #InformationRetrieval #SearchEngine