首頁
Blog
Milvus 3.0 發布：Lake-Native 向量搜尋與更強大的檢索引擎

Milvus 3.0 發布：Lake-Native 向量搜尋與更強大的檢索引擎

Announcements

July 27, 2026

Fendy Feng and Li Liu

今天，我們發布 Milvus 3.0，這是此專案的一個重大架構里程碑。它改變了 Milvus 能在哪裡建置與提供索引服務，也改變了可直接在引擎內完成多少檢索工作。

Milvus 3.0 引入湖原生路徑，可為位於物件儲存與開放資料表格式中的向量資料建立索引，包括 Parquet、Lance、Iceberg 與 Vortex。團隊可以讓常駐於資料湖的資料變得可搜尋，而無需在向量資料庫中維護另一份副本。
此版本也將 Milvus 擴展到初始候選檢索之外。伺服器端排序、聚合、分面搜尋、用於巢狀 doc/chunk 結構與 ColBERT 向量的 StructArray，以及重新設計的稀疏索引，將更多排名、分組與結果處理從應用程式碼移至檢索引擎中。

這些進展共同使 Milvus 成為生產級 AI 檢索，以及結合湖原生儲存與高效能向量檢索的 Vector Lakebase 架構的開源基礎。

快速瀏覽 Milvus 3.0 功能集

領域	功能	重要原因
湖原生檢索	基於 Parquet、Lance、Iceberg 與 Vortex 的 External Collections	搜尋常駐於資料湖的資料，而無需維護第二份服務副本
以 S3 為基礎的儲存	Loon (Storage v3)	降低服務型存取的點讀取放大，並支援結構描述演進
離線/批次工作流程與復原	Snapshots、Spark DataSource V2 與線上結構描述演進	將穩定的 collection 視圖帶入評估、去重、叢集與特徵管線
檢索引擎	ORDER BY、聚合、分面、StructArray 與改進的稀疏檢索	將更多結果處理與多向量評分移入 Milvus
資料模型與操作	可為 Null 的向量、TEXT LOB、TTL、MinHash、Woodpecker 與 ForceMerge	支援更豐富的資料模型與生產環境運作模式

湖原生基礎架構：在資料原本所在的位置建立索引並提供服務

Milvus 3.0 最大的架構變更在於系統可在哪裡建置與提供索引服務。向量資料可以保留在物件儲存上的開放格式中，同時由 Milvus 提供生產級索引、檢索與 API。

1. External Collections：直接在常駐於資料湖的資料上建立索引

許多團隊已經將嵌入儲存在資料湖中 — Lance 資料表、Iceberg 資料表、Parquet 檔案，或 S3、GCS、Azure Blob Storage 上其他開放格式的資料集。在 Milvus 3.0 之前，搜尋這些資料通常有兩種選擇。

將嵌入複製到向量資料庫。這提供低延遲搜尋，但會建立第二份副本以及必須保持同步的 ETL 管線。
直接查詢資料湖。這避免了重複，但若沒有 ANN 索引，向量搜尋會變成無法滿足生產延遲要求的暴力掃描。

External Collections 引入第三條路徑。你可以在仍保留於物件儲存中的資料之上定義 Milvus collection，將外部欄位對應到 Milvus 結構描述，並使用與原生 collection 相同的搜尋與查詢 API。來源檔案不會移動；Milvus 會在外部資料上建置並提供向量、BM25 倒排、JSON 與純量索引。

External Collections 是唯讀且零拷貝的，當治理、所有權邊界或營運成本要求來源資料集必須留在資料湖中時，這使它們特別有用。

當外部資料集變更時，Milvus 會讀取其儲存 manifest，並只為新加入的片段建立索引，而不是重建整個 collection。

import json
import os
import time
from pymilvus import DataType, MilvusClient
client = MilvusClient(uri=“”)
# Register an Iceberg table as a zero-copy collection.
schema = client.create_schema(
external_source=“s3://lake/docs/metadata/v1.metadata.json”,
external_spec=json.dumps(
{
“format”: “iceberg-table”,
“snapshot_id”: 123456789,
“extfs”: {
“cloud_provider”: “aws”,
“region”: “us-east-1”,
“access_key_id”: os.environ[“AWS_ACCESS_KEY_ID”],
“access_key_value”: os.environ[“AWS_SECRET_ACCESS_KEY”],
},
}
),
)
schema.add_field(field_name=“id”, datatype=DataType.INT64, external_field=“doc_id”)
schema.add_field(field_name=“emb”, datatype=DataType.FLOAT_VECTOR, dim=1024, external_field=“embedding”)
schema.add_field(field_name=“title”, datatype=DataType.VARCHAR, max_length=1024, external_field=“title”)
client.create_collection(collection_name=“docs”, schema=schema)
# Import the external table snapshot.
job_id = client.refresh_external_collection(collection_name=“docs”)
while True:
progress = client.get_refresh_external_collection_progress(job_id=job_id)
if progress.state == “RefreshCompleted”:
break
if progress.state == “RefreshFailed”:
raise RuntimeError(progress.reason)
time.sleep(1)
index_params = client.prepare_index_params()
index_params.add_index(field_name=“emb”, index_type=“HNSW”, metric_type=“COSINE”)
client.create_index(collection_name=“docs”, index_params=index_params)
client.load_collection(collection_name=“docs”)

對於受治理的環境，檢索可以在資料被允許所在的位置執行。對於大型 AI 系統，常駐於資料湖的資料集可以支援多個檢索部署，而無需在它們之間執行遷移作業。

External Collections 是一項增量能力。原生 Milvus collections 仍然是寫入密集、低延遲服務的主要路徑，而 External Collections 則是為系統記錄來源仍位於 Milvus 外部的資料集所設計。

更多詳細資訊，請參閱 Create an External Collection。

2. Loon (Storage v3)：用於湖原生檢索的高效率點讀取

External Collections 提出了一個顯而易見的問題：物件儲存是為規模與耐久性而設計的，但它能否支援 ANN 搜尋之後的窄範圍點讀取？

挑戰在於讀取放大。向量搜尋通常分為兩個階段：ANN 索引回傳候選 ID，系統再擷取這些候選項的所選欄位。為分析掃描最佳化的格式，可能會將窄範圍的邏輯查找轉變為更大的實體讀取。

Milvus 3.0 透過 Loon（也稱為 Storage v3）解決此問題，這是一個用於 S3 相容物件儲存、以 manifest 為基礎的欄式儲存引擎。Loon 將欄位組織成具有對齊 row ID 的 ColumnGroups，讓純量欄位偏向篩選與掃描，而向量與點讀取密集欄位則使用為較窄查找設計的配置。

Loon 將向量與倒排索引與檔案格式分離，而不是將它們嵌入其中。每個資料集版本都由不可變的 manifest 描述，記錄其 ColumnGroups，使同一個索引引擎能夠跨 Lance、Parquet、Iceberg 與 Vortex 運作。

manifest 設計也讓結構描述演進的干擾更小。新增或刪除欄位可以更新中繼資料，而無需重寫現有欄位。填入新欄位會寫入新的 ColumnGroup，同時讓現有 ColumnGroups 保持不變。

Vortex 是此路徑的預設格式。它是一種開放、與 Arrow 相容的欄式格式，具備彈性配置與巢狀編碼，更能匹配點查詢密集的 AI 資料。在一項使用 300 萬列、128 維向量、S3 與 256 個並行讀取器的內部基準測試中，每次點讀取的實測 I/O 從 Parquet 基準約 9.4 MB 降至搭配 Loon 的 Vortex 的 0.07 MB，約少了 135 倍。

Milvus 3.0 並不會讓物件儲存表現得像本機記憶體。它降低了原本會讓物件儲存不適合服務型點查找的讀取放大。格式層的謂詞下推以及本機 Vortex 變體是接下來的路線圖項目。

更多詳細資訊，請參閱我們的部落格：Why We Built Loon 以及 Vortex 專案。

3. Snapshots：無需資料複製的時間點視圖

即使生產環境 collections 持續接收寫入，離線作業也需要一致的資料視圖。Milvus snapshot 是一個時間點、唯讀視圖，它記錄對現有資料、索引與中繼資料檔案的參照，而不是複製完整資料集。

這使得 snapshots 的建立成本低到足以在模型替換、重新嵌入作業或結構描述遷移等高風險操作之前建立。還原 snapshot 可以透過物件儲存中的伺服器端複製重用現有資料與索引檔案，而不是重新匯入每一列並重建每個索引。這項功能對於 AI agents 這類快速變動的工作負載特別有用，因為資料不斷變更，而你需要頻繁且低成本的復原點，而不是偶爾進行沉重的備份。

同一個凍結視圖可以支援評估、去重、回填驗證與隔離測試，同時 live collection 持續接受寫入。snapshot 會穩定邏輯輸入，儘管工作負載仍可能共享物件儲存與網路頻寬等基礎架構。

Snapshots 並不取代備份。snapshot 參照由 live collection 擁有的檔案，最適合用於邏輯復原、複製與短期穩定視圖。備份則會建立獨立副本，用於長期保留與災難復原。

更多資訊，請參閱 Snapshots、Manage Snapshots 與 Snapshot Use Cases。

4. Spark connector：將 Milvus 連接到批次工作流程

穩定的 snapshot 只有在批次引擎能讀取它時才有用。Milvus 3.0 將 Milvus 暴露為 Spark DataSource V2，讓 Spark、Databricks 與 EMR 作業能在標準批次管線中從 Milvus 讀取並寫入 Milvus。

這項功能很重要，因為 AI 資料工作流程是迭代式的：去重提供重新嵌入的輸入，叢集提供評估的輸入，而評估會產生經策展的訓練或服務集合。穩定的 snapshot 為這些作業提供一致輸入，同時 live collection 持續提供服務。透過 Spark connector，一個作業的輸出會成為下一個作業的來源，而無需每次都將完整 collection 匯出 Milvus。

Milvus 3.0 也引入向量原生批次運算子，用於去重、異常偵測與叢集等任務，讓計算密集工作保留在線上查詢路徑之外，同時直接在向量資料上運作。

5. 線上結構描述變更與回填

結構描述在生產環境中很少會保持靜態 — 團隊會隨著時間加入新的嵌入模型、稀疏向量、標籤、中繼資料欄位與保留政策。Milvus 3.0 讓他們在服務持續運作的同時新增、填入與刪除欄位，而不是像過去那樣需要具破壞性的重建。

新增或刪除欄位不需要重寫現有資料。client.add_collection_field(...) 會加入新的可為 Null 欄位，而不使 collection 離線；client.drop_collection_field(...) 則可在執行時移除已棄用或實驗性欄位。兩者都不會重寫現有資料 — 每一項都是對 collection manifest 的變更，而不是對資料檔案的變更，這就是為什麼不需要重建。

Milvus 3.0 支援兩種回填路徑：

內部回填（3.0 中提供）適用於從現有欄位衍生出的值。Milvus 可以在核心內從文字欄位產生 BM25 稀疏向量，消除在建置 dense-plus-sparse 混合檢索時對用戶端編碼器的需求。
外部回填（路線圖中）將適用於在 Milvus 外部計算的值：取得 snapshot，讓 Spark 針對一致視圖執行，計算新欄位，將值寫回，並讓 Milvus 增量更新索引。這是大型重新嵌入作業的預期路徑 — 例如，在寫入持續進行的同時，為數億列新增新的嵌入欄位。

總之，線上結構描述變更與回填讓檢索管線更容易演進，而不必每次資料模型變更時都重建整個 collection。

用於端對端檢索的更強大引擎

Milvus 長期以來支援的不只是密集 ANN 搜尋，還包括基於 BM25 的稀疏檢索與混合搜尋。Milvus 3.0 沿著另一個軸向擴展引擎：它將更多多階段檢索管線帶入 Milvus 本身，減少過度擷取、重複的應用程式邏輯，以及對獨立後處理服務的依賴。

1. 伺服器端 ORDER BY：在引擎內依 segment 排序

過去排序需要應用程式過度擷取候選項，將它們移至用戶端，並在那裡排序。這會消耗頻寬，並使最終結果取決於用戶端截斷發生的位置。

Milvus 3.0 新增伺服器端 ORDER BY，讓查詢工作負載可以依 rating、price、freshness、inventory 或 timestamp 等純量欄位對篩選後的列進行排序。

在查詢路徑上，每個 segment 對其篩選後的結果集排序，query nodes 合併這些串流，proxy 回傳請求的切片。
在搜尋路徑上，ORDER BY 會在 Milvus 內對 ANN 候選集排序，減少用戶端過度擷取與重複後處理。它不會改變由 ANN 候選項所建立的召回邊界。

client.query(
    collection_name="products",
    filter="category == 'shoes'",
    output_fields=["price", "rating"],
    limit=10,
    order_by=["rating:desc", "price:asc"],
)

這對於將相關性與業務或使用者面向限制（例如 rating、price、freshness、inventory 或 timestamp）結合的搜尋特別有用。

更多資訊，請參閱 Sort Search Results by Scalar Fields 與 Sort Query Results。

2. 聚合與分面搜尋

Milvus 3.0 新增查詢端聚合，支援 count、sum、average、minimum 與 maximum 等操作，並可依一個或多個純量欄位分組。這移除了常見模式：團隊只是為了計數、分組或計算簡單統計，就將篩選後的列拉到用戶端程式碼中。

client.query(
    collection_name="orders",
    filter="in_stock == true",
    group_by_fields=["category"],
    output_fields=["category", "count(*)", "avg(price)", "max(rating)"],
)

Milvus 3.0 也新增用於分面搜尋的搜尋聚合。在 ANN 搜尋之後，Milvus 會依欄位對擷取到的命中結果分組，並回傳 bucket 計數、聚合統計與每個 bucket 的 top-N 範例命中 — 這正是依品牌、價格範圍、顏色、租戶或文件類型分組背後的模式。有一點需要注意：搜尋聚合是在 ANN 擷取到的結果集上運作，而不是整個 collection，因此分面計數是近似值。當你需要精確計數時，請使用查詢端聚合。

更多資訊，請參閱 Aggregate Query Results。

3. 用於巢狀向量與 late-interaction 模型的 StructArray

許多實體很自然地由多個向量表示。一篇長文件是一系列 chunk；一段影片是一連串 frame，你更希望將它們保留在同一列中，而不是分散到多列；一個產品有多張圖片或多個角度。Late-interaction 模型更進一步 — ColBERT 會為每個 token 產生一個向量，ColPali 會為每個視覺 patch 產生一個向量。在每種情況下，你真正想要儲存與搜尋的單位都是整個實體，而不是各個 fragment 本身。

StructArray 允許 Milvus 的一列包含可變長度的結構化元素陣列，包括多個向量，同時保留單一 entity ID 與單一組中繼資料。這避免了將文件拆成多列，並在 fragments 之間重複標籤、權限或其他欄位。

Milvus 支援兩種搜尋粒度。

元素層級搜尋會將一個查詢向量與清單中的每個元素比對，並回傳特定匹配元素及其 offset。當你想知道是哪個 chunk、token、patch 或 image 匹配時，這很有用。如果多個元素匹配，同一列可能會出現多次。
實體層級搜尋使用 MAX_SIM 搭配 MAX_SIM_COSINE metric，將查詢的完整向量清單與列中的向量清單比較。每個查詢 token 都會取得其在文件中的最佳匹配，然後將這些最佳分數加總。這讓 Milvus 在保持每份文件一列的同時，原生支援 ColBERT 與 ColPali 等 late-interaction 檢索模式。

為每個 token 向量建立索引可能成本高昂；因此 Milvus 3.0 新增多種加速路徑，包括 TokenANN、Muvera 與 Lemur，它們在索引大小、訓練成本與召回率之間做取捨。

策略	第一階段表示	成本概況	最適用於
TokenANN	每個 token 向量都會建立索引。	最高，精確	高辨識度模型與短文件
Muvera	使用 random-projection FDE，每份文件一個向量。	中等，無需訓練	長文件
Lemur	使用 learned MLP compression，每份文件一個向量	最低，需要訓練	低辨識度模型與視覺或 patch 向量

在我們的基準測試中，Lemur 在多數資料集上的召回率匹配或優於 TokenANN，同時將每份文件壓縮為單一向量；例外是長度變異很高的語料庫，在這種情況下 TokenANN 或其他策略較為安全。

對於大於記憶體的語料庫，Milvus 也支援 DISKANN 索引，可將 embedding lists 保存在磁碟上以降低 RAM 壓力。

元素層級搜尋已在 Milvus 2.6 中推出。Muvera、Lemur 與 StructList 的篩選則是 3.0 的新功能。

4. BM25 索引壓縮與 SINDI

Milvus 在較早版本中已支援稀疏向量搜尋。Milvus 3.0 透過區塊壓縮 postings（VByte 相關演算法加上 SIMD 解碼）與量化（內積使用 fp16，BM25 使用 u16）降低稀疏索引佔用空間。

在一組內部 BM25 基準測試中，新的實作在相近召回率下約比 Milvus 2.6 稀疏索引小 3 倍。較小的索引降低記憶體與頻寬壓力，並可改善受資料移動限制的工作負載速度。

Milvus 3.0 也引入 SINDI，這是一種新的稀疏檢索演算法，針對 SPLADE 等學習式稀疏嵌入最佳化。由於這些嵌入會產生比 BM25 更密集的 posting lists，重度剪枝的搜尋演算法可能會花費大量 CPU 時間決定要跳過哪些項目。SINDI 改為將 postings 組織成緊湊的 windows，並使用 SIMD 友善的分數累加來高效率處理它們，同時透過無損剪枝保留檢索準確性。

我們也將 SINDI 擴展到其原始設計之外，加入原生 BM25 支援，使 Milvus 能對學習式稀疏嵌入與傳統全文搜尋使用同一條最佳化的稀疏檢索路徑。

在我們跨 4 個 SPLADE 稀疏向量資料集的基準測試中，SINDI 在 learned-sparse vectors 上的 QPS 最高可達 MaxScore 約 10 倍，最差情況也約為 5 倍。

SINDI 是 Milvus 3.0 中稀疏內積搜尋的預設選項。

其他增強功能

TEXT LOB: 在向量旁儲存長篇來源文字。小於 64 KB 的文字維持內嵌；較大的值使用 Vortex LOB 參照。
擴展的密集索引支援： 在 Faiss 家族中新增更多索引選擇，包括 SVS、Panorama、PQ、IVFPQ 與 ScaNN，以滿足不同規模、記憶體與召回需求。
MinHash 與近重複搜尋： 在伺服器端產生 MinHash signatures，並使用 MINHASH_LSH 擷取近重複候選項。
可為 Null 的向量與新型別： 允許向量欄位為 NULL，並新增 TIMESTAMPTZ 以支援時間感知篩選與保留政策。
自訂全文字典： 在叢集上註冊字典、同義詞與停用詞資源，以支援多語言與領域特定 tokenization。
獨立 Woodpecker： 將 Milvus write-ahead log 作為可獨立擴展且可觀測的服務執行。
實體 TTL****: 透過 TIMESTAMPTZ 欄位使個別記錄過期，先進行 MVCC 篩選，再於 compaction 期間進行 garbage collection。
ForceMerge: 將小型 segments 壓縮至目標大小並重建索引，以在長時間讀取密集服務之前降低讀取放大。
以及更多

開始使用 Milvus 3.0

Milvus 3.0 現已在 Apache 2.0 授權下提供，並持續作為 LF AI & Data 專案。若要開始使用：

閱讀版本說明與快速入門，並在 github.com/milvus-io/milvus 取得原始碼。
加入 Milvus Discord 社群，或預約 Milvus Office Hours 時段，與維護者討論你的使用案例。

Milvus 3.0 與 Zilliz Vector Lakebase

Milvus 3.0 為生產級 AI 檢索與新興的 Vector Lakebase 架構奠定開源基礎，該架構在單一真相來源上結合湖原生儲存與高效能向量檢索，並讓各自以適當成本運作。

Zilliz Cloud 是由 Milvus 背後團隊打造的全託管 Vector Lakebase。它與 Milvus 共享相同的分散式湖原生架構，並完全相容於 Milvus API。Zilliz Cloud 由其專有 Cardinal 索引引擎驅動，相較標準開源索引方法可提供最高 10× 更佳的性價比，同時消除管理基礎架構的營運複雜度。企業功能包括 scale-to-zero compute、跨區域災難復原、BYOC 部署、企業級安全與合規（SOC 2、HIPAA、ISO 27001 與 GDPR），以及最高 99.99% SLA。