Milvus
Zilliz
星標45.7K預約示範開始使用
  • 首頁
  • Blog

  • 一個實體、多個向量：使用 Milvus 3.0 StructArray 進行實體與元素層級搜尋

一個實體、多個向量：使用 Milvus 3.0 StructArray 進行實體與元素層級搜尋

  • Engineering
August 19, 2026
Chenjie Tang

大多數向量資料庫的 schema 都始於一個簡單的假設：一個實體對應一個嵌入向量。一個產品有一個向量，一份文件也有一個向量。使用者查詢會被嵌入，並透過近似最近鄰居（ANN）搜尋與這些向量進行比對。這個模型適用於第一代向量搜尋使用案例，包括 RAG、語意搜尋和推薦系統。

然而，真實世界的 AI 資料很少符合這個假設。一段影片包含多個片段、鏡頭或關鍵幀，每個都有各自的嵌入向量、時間範圍、字幕、場景標籤和信心分數。一個產品可能有多張圖片和多個觀看角度。一份長文件包含多個段落或章節，其局部意義比整個文件的單一嵌入向量更為重要。流行的晚期互動（late-interaction）模型在更細的粒度上暴露出相同的限制：ColBERT 為每個 token 產生一個向量，而 ColPali 為每個視覺區塊（patch）產生一個向量。

在上述每種情況下，父實體仍然是應用程式儲存、顯示、保護和回傳的單位。然而，相關性、過濾和結果解釋往往取決於該實體內部的元素。

新的 StructArray 功能為 Milvus 提供了符合此形態的原生資料模型：一個實體包含一個有序的 schema 定義 Struct 元素陣列，每個元素可以攜帶純量 metadata、向量嵌入，或同時攜帶兩者。Milvus 可以過濾屬於同一個元素的欄位、在實體層級比對兩個嵌入向量清單，或搜尋個別元素並回傳相符的偏移量（offset）。

本文以影片搜尋範例說明資料模型，然後依序探討 schema 設計、過濾、向量搜尋粒度、EmbeddingList 索引策略、混合結果的彙整（collapse），以及使此功能得以執行的實體佈局。

為什麼單一向量與單一扁平列模型已不再足夠

假設使用者正在影片目錄中搜尋「一個在廚房切菜的人」。相關的訊號可能位於一個八秒的片段中，而不是整部影片的嵌入向量裡。將每個片段、物體和動作壓縮成單一向量也許能保留大致主題，但可能沖淡局部細節。

相同的落差也出現在其他工作負載中：

  • 產品的相關性可能來自多張圖片或多個角度中的其中一個。
  • 文件可能因為某個段落而非整體主題而相符。
  • 代理（agent）記憶可能包含多個觀察結果，但只有其中一個對目前任務重要。
  • ColBERT 或 ColPali 記錄包含可變長度的 token 或 patch 向量清單，而非單一稠密向量。

另一種做法是將每個片段、圖片或段落拆分為獨立的資料庫列。這樣可以啟用局部搜尋，但也會將每個片段與其父實體分離。父實體的 metadata 可能在多列中重複，而實體層級的檢索則需要在片段搜尋之後進行分組、去重和重新排序。

僅靠巢狀儲存並不能解決查詢問題。JSON 可以儲存物件，但它無法為 Milvus 提供預先定義的子欄位 schema 來進行向量和純量索引。平行陣列可以儲存字幕、場景標籤和信心值，但應用程式必須自行維護偏移量對齊。除非這種關聯關係是資料模型的一部分，否則資料庫無法安全地推斷 scene_type[3] 和 label_confidence[3] 描述的是同一個片段。

StructArray 直接編碼了這種關聯關係。它將局部元素保留在父實體內部，同時將其對齊的子欄位暴露給 schema 驗證、索引、過濾和向量搜尋。

什麼是 StructArray 及其資料模型？

StructArray（也稱為結構體陣列，array of structs）在每個實體中儲存一組有序的 Struct 元素。StructArray 欄位是一個 Array，其所有元素都遵循一個預先定義的 Struct schema。以影片集合為例，邏輯形狀可能如下所示：

Plaintext
clips: ARRAY<STRUCT<
    clip_embedding_list: FLOAT_VECTOR,
    clip_embedding: FLOAT_VECTOR,
    start_sec: DOUBLE,
    end_sec: DOUBLE,
    caption: VARCHAR,
    scene_type: VARCHAR,
    label_confidence: FLOAT
>>

在此：

  • clips 是父級 StructArray 欄位。
  • clip_embedding_list、clip_embedding、start_sec 及其他屬性是子欄位。
  • clips[0] 是第一個片段。
  • 位於偏移量 0 的每個子欄位都屬於同一個片段。
  • 位於偏移量 3 的每個子欄位都屬於另一個片段。

這兩個向量子欄位服務於不同的搜尋模式。clips[clip_embedding_list] 使用 MAX_SIM* 度量進行索引，用於實體層級的 EmbeddingList 搜尋，而 clips[clip_embedding] 則使用一般向量度量進行索引，用於元素層級的搜尋。由於一個向量欄位或向量子欄位只能接受一個索引，因此如果需要兩種模式的集合，必須分別定義和索引兩個子欄位。

此模型支援三種不同的查詢語意。

1. EmbeddingList 搜尋回傳父實體

clips[clip_embedding_list] 中的向量構成該影片的嵌入向量清單。查詢也是一個 EmbeddingList。Milvus 使用 MAX_SIM* 度量將查詢清單與每個儲存的清單進行比對，並回傳實體層級的結果。

Plaintext
clips[clip_embedding_list] = [
    embedding_0,
    embedding_1,
    embedding_2,
    ...
]

2. MATCH_* 系列函式過濾父實體

MATCH_ANY、MATCH_ALL、MATCH_LEAST、MATCH_MOST 和 MATCH_EXACT 會針對 Struct 元素評估謂詞（predicate），計算有多少元素滿足該謂詞，並決定父實體是否通過過濾。

例如：

Plaintext
MATCH_ANY(clips, $[scene_type] == "kitchen" && $[label_confidence] > 0.8)

兩個純量條件必須在同一個片段偏移量上同時成立。Milvus 不會將某個片段的廚房標籤與另一個片段的高信心值組合在一起。

3. 元素層級搜尋回傳相符的元素偏移量

一般查詢向量可以獨立搜尋 clips[clip_embedding] 中的每個向量。每個命中結果都會識別父實體以及相符 Struct 元素的零起始偏移量。element_filter 可以限制哪些元素參與該向量搜尋。

這些操作共享一個前提：Milvus 知道哪些向量和純量值屬於同一個元素，以及哪些元素屬於同一個實體。

StructArray 不是通用的任意巢狀系統。其目前的模型是由支援的純量和向量子欄位組成的一個 Struct 元素 Array。這樣的邊界使得子欄位索引和元素感知的執行成為可行。

建立 schema、索引與插入路徑

以下簡化的 PyMilvus 範例建立一個影片集合，包含一個頂層向量和一個用於片段的 StructArray。它使用分開的片段向量子欄位，使同一個集合可以示範兩種搜尋模式。

from pymilvus import DataType, MilvusClient

client = MilvusClient(uri=“http://localhost:19530”)


schema = client.create_schema(auto_id=False, enable_dynamic_field=False)
schema.add_field(“id”, DataType.INT64, is_primary=True)
schema.add_field(“title”, DataType.VARCHAR, max_length=512)
schema.add_field(“video_embedding”, DataType.FLOAT_VECTOR, dim=768)


# Define the Struct schema explicitly.
clip_schema = client.create_struct_field_schema()
clip_schema.add_field(“clip_embedding_list”, DataType.FLOAT_VECTOR, dim=768)
clip_schema.add_field(“clip_embedding”, DataType.FLOAT_VECTOR, dim=768)
clip_schema.add_field(“start_sec”, DataType.DOUBLE)
clip_schema.add_field(“end_sec”, DataType.DOUBLE)
clip_schema.add_field(“caption”, DataType.VARCHAR, max_length=2048)
clip_schema.add_field(“scene_type”, DataType.VARCHAR, max_length=128)
clip_schema.add_field(“label_confidence”, DataType.FLOAT)


schema.add_field(
“clips”,
datatype=DataType.ARRAY,
element_type=DataType.STRUCT,
struct_schema=clip_schema,
max_capacity=1024,
)


client.create_collection(“videos”, schema=schema)

向量子欄位在搜尋前必須先建立索引。由於度量系列決定了搜尋模式，每個向量子欄位都會獲得自己的索引：

index_params = client.prepare_index_params()

# EmbeddingList search.
index_params.add_index(
field_name="clips[clip_embedding_list]",
index_type=“HNSW”,
metric_type=“MAX_SIM_COSINE”,
index_name=“clips_clip_embedding_list_maxsim_idx”,
params={“M”: 16, “efConstruction”: 200},
)


# Element-level search.
index_params.add_index(
field_name="clips[clip_embedding]",
index_type=“HNSW”,
metric_type=“COSINE”,
index_name=“clips_clip_embedding_cosine_idx”,
params={“M”: 16, “efConstruction”: 200},
)


client.create_index(“videos”, index_params=index_params)

純量索引是可選的，但經常出現在大規模過濾中的子欄位應使用相容的純量索引。例如，clips[scene_type] 可以使用反向索引（inverted index），而 clips[label_confidence] 等數字子欄位可以使用適合數字過濾的索引。

以自然的實體形狀插入資料：一個影片列包含一個片段物件陣列。為了讓範例更簡潔，它將同一個片段向量寫入兩個向量子欄位。

rows = [
    {
        "id": 1,
        "title": "cooking tutorial",
        "video_embedding": video_vec,
        "clips": [
            {
                "clip_embedding_list": clip_vec_1,
                "clip_embedding": clip_vec_1,
                "start_sec": 0.0,
                "end_sec": 8.0,
                "caption": "A person washes vegetables.",
                "scene_type": "kitchen",
                "label_confidence": 0.92,
            },
            {
                "clip_embedding_list": clip_vec_2,
                "clip_embedding": clip_vec_2,
                "start_sec": 8.0,
                "end_sec": 16.0,
                "caption": "A person cuts carrots on a board.",
                "scene_type": "kitchen",
                "label_confidence": 0.96,
            },
        ],
    }
]

client.insert(“videos”, rows)
client.flush(“videos”)
client.load_collection(“videos”)

在 API 邊界，clips 仍然是一個結構化物件陣列。在 Milvus 內部，每個子欄位都遵循其自身索引、過濾和輸出行為所需的型別路徑。這種區別在插入時是透明的，但對後續一切操作都至關重要。

同元素過濾是結構與平行陣列之間的差異

過濾的主要好處不是巢狀欄位的更簡短語法，而是在純量子欄位之間進行正確的關聯。

假設應用程式需要找出包含一個廚房片段且標籤信心值高於 0.8 的影片。僅包含某個廚房片段和某個高信心值片段是不夠的；必須是同一個片段同時滿足兩個條件。

StructArray 的 MATCH_* 系列函式直接表達了這一點：

Plaintext
MATCH_ANY(clips, $[scene_type] == "kitchen" && $[label_confidence] > 0.8)
MATCH_ALL(clips, $[label_confidence] > 0.5)
MATCH_LEAST(clips, $[scene_type] == "sports", threshold=3)
MATCH_MOST(clips, $[label_confidence] < 0.2, threshold=1)
MATCH_EXACT(clips, $[scene_type] == "intro", threshold=1)

Milvus 在每個元素偏移量上評估謂詞，然後套用運算子（operator）的量詞（quantifier）來決定父實體是否通過：

  • MATCH_ANY：至少一個元素相符。
  • MATCH_ALL：每個元素都相符。
  • MATCH_LEAST：至少 threshold 個元素相符。
  • MATCH_MOST：最多 threshold 個元素相符。
  • MATCH_EXACT：恰好 threshold 個元素相符。

如果相同的資料儲存在兩個獨立的陣列中，下列表達式將無法保留這種關聯：

Plaintext
array_contains(clips[scene_type], "kitchen")
AND
array_contains(clips[label_confidence], 0.9)

這兩個值可能出現在不同的偏移量上。對於不相關的屬性這可能是有效的，但當兩個條件描述的是同一個片段、產品圖片或文件段落時，這就是錯誤的。

StructArray 使元素身分成為資料庫謂詞的一部分，而不是應用程式必須強制執行的慣例。

兩種向量搜尋粒度，兩種結果識別

一旦一個實體儲存了多個向量，檢索就必須在 ANN 搜尋開始之前解決一個建模問題：

這些向量應該作為父實體的單一表示一起計分，還是每個元素向量應該獨立競爭？

StructArray 支援兩種模型，但它們使用不同的查詢形狀、度量系列、向量子欄位和結果識別。

EmbeddingList 搜尋：查詢向量清單找到一個實體

一個 EmbeddingList 查詢包含多個向量。一個查詢影片可能被分成多個片段；一個產品查詢可能包含多張參考圖片；一個 ColBERT 查詢包含每個查詢 token 一個向量。

對於每個實體，Milvus 將查詢清單與實體儲存的嵌入向量清單進行比對。在 MaxSim 風格的計分下，每個查詢向量在實體清單中選擇其最佳匹配，Milvus 將這些最佳匹配分數聚合為一個實體分數。最終的命中結果代表父實體，而不是某個特定的 Struct 元素。

from pymilvus.client.embedding_list import EmbeddingList

query = EmbeddingList()
query.add(query_clip_vec_1)
query.add(query_clip_vec_2)


client.search(
collection_name=“videos”,
data=[query],
anns_field="clips[clip_embedding_list]",
search_params={“metric_type”: “MAX_SIM_COSINE”},
limit=10,
)

這個搜尋回答的是：哪一部影片是這組查詢片段的整體最佳匹配？

它適用於影片對影片檢索、多圖片產品搜尋、ColBERT 和 ColPali 風格的檢索，以及其他查詢和儲存實體都由多個向量表示的情況。

元素層級搜尋：一個查詢向量找到實體內的片段

元素層級搜尋使用一般的查詢向量。clips[clip_embedding] 中的每個向量都作為獨立候選者參與 ANN 搜尋。每個命中結果都會識別父實體和相符元素的偏移量。

client.search(
    collection_name="videos",
    data=[query_vec],
    anns_field="clips[clip_embedding]",
    search_params={"metric_type": "COSINE"},
    limit=10,
    output_fields=["id", "title", "clips"],
)

若要只搜尋選定的片段，可附加一個 element_filter，其純量條件套用於同一個片段：

client.search(
    collection_name="videos",
    data=[query_vec],
    anns_field="clips[clip_embedding]",
    search_params={"metric_type": "COSINE"},
    filter='element_filter(clips, $[scene_type] == "kitchen" && $[label_confidence] > 0.8)',
    limit=10,
    output_fields=["id", "title", "clips"],
)

過濾器不會先選出一個廚房片段，然後再搜尋另一個不同的高信心值片段。兩個謂詞和向量候選者都指向同一個 Struct 元素。

未分組的回應可能如下所示：

Plaintext
id = 1, offset = 1, distance = 0.91
id = 8, offset = 4, distance = 0.88
id = 1, offset = 3, distance = 0.84

同一個實體可能出現多次，因為多個片段都可能相符。這在應用程式需要顯示的不僅是哪部影片或文件相關，還需要顯示哪個片段或段落產生了匹配時非常有用。

面向EmbeddingList 搜尋元素層級搜尋
查詢輸入EmbeddingList 中的一個或多個查詢向量一個一般查詢向量
範例目標clips[clip_embedding_list]clips[clip_embedding]
度量系列MAX_SIM*一般度量，如 COSINE、IP 或 L2
ANN 候選單位父實體的嵌入向量清單每個 Struct 元素向量
結果識別父實體父實體加上元素偏移量
典型使用案例將多向量查詢與多向量實體進行比對找出最相關的片段、圖片、段落、區塊或事實

若要在此單一集合中支援兩種模式，請分別定義和索引不同的向量子欄位。查詢形狀、度量系列和目標索引必須一致。

EmbeddingList 索引是一項品質與成本的抉擇

每個實體只有一個嵌入向量時，ANN 索引可以找到靠近查詢向量的實體。EmbeddingList 搜尋成本更高，因為相關性取決於兩個向量清單之間的成對互動。

對每個實體中的每個向量計算精確 MaxSim 會產生最乾淨的參考排名，但完整掃描通常對線上檢索來說成本過高。因此，Milvus 使用兩階段模型：

  1. 一個近似策略檢索候選父實體。
  2. 當啟用 emb_list_rerank 時，Milvus 在這些候選者上重新計算 MaxSim 以產生最終排名。

檢索更多第一階段候選者通常會提高真正頂級結果進入重新排名器的機會，但也會增加延遲和計算量。這三種策略的主要差異在於它們如何產生該候選集合。

策略第一階段候選表示適合的起點主要取捨
TokenANN索引每個嵌入清單中的每個向量。查詢向量獨立執行 ANN；在 MaxSim 重新排名之前，匹配結果會聚合回父實體。品質是優先考量、清單短或中等長度，且個別向量具有區辨力時。索引大小和第一階段搜尋工作量會隨著清單長度和查詢向量數量而成長。
MUVERA透過隨機投影將每個嵌入清單編碼為一個固定維度向量，然後執行一般 ANN。TokenANN 過於沉重，且偏好無需訓練管線的壓縮方式時。編碼會遺失資訊；更強的投影設定會增加編碼維度和 ANN 成本。
LEMUR訓練一個模型，將嵌入清單映射為固定維度的父實體向量。嵌入向量區辨力較低、清單較大，或工作負載屬於視覺或多模態時。需要訓練，且可能對語料庫分佈和文件長度偏差敏感。

沒有一種策略對所有工作負載都是最佳選擇。從目標資料和查詢分佈開始：

  • 在資料集規模允許的情況下，使用 TokenANN 作為品質優先的基準。
  • 當 TokenANN 的索引或候選檢索隨著清單長度增長而變得太昂貴，且你想避免訓練管線時，嘗試 MUVERA。
  • 當嵌入空間嘈雜或區辨力較弱，或工作負載屬於視覺或多模態時，評估 LEMUR。
  • 在測量延遲和索引大小的同時，也測量召回率（recall）或 nDCG。對短文本有效的策略，在長尾文件長度或數千個視覺區塊下可能會有不同表現。

StructArray 解決一個問題：如何在單一實體內部表示對齊的、可過濾的、攜帶向量的元素。EmbeddingList 策略解決另一個問題：如何在特定模型和語料庫下以可接受的成本近似 MaxSim。

混合搜尋使結果識別明確化

生產環境的檢索很少只遵循單一向量路徑。一個影片請求可能結合頂層影片嵌入、一個或多個片段層級嵌入、字幕或逐字稿訊號，以及一個重新排名器。

一旦元素層級候選者進入該管線，引擎就必須決定什麼識別最終候選者。

混合請求組成最終候選範圍結果識別
所有子搜尋都是元素層級，且目標是同一 StructArray 下的向量子欄位元素層級主鍵加上 StructArray 欄位加上元素偏移量
包含頂層向量欄位實體層級主鍵
包含 EmbeddingList 請求實體層級主鍵
元素層級請求目標為不同的 StructArray 欄位實體層級主鍵

第一種配置保留了元素識別，因為在給定的父 StructArray 下，偏移量 3 對每個子搜尋都指向同一個 Struct 元素。這適合在融合多個元素層級訊號後，想要回傳最相關片段或段落的應用程式。

其他配置混合了候選粒度或元素命名空間。因此，元素命中結果必須在最終重新排序之前被彙整為實體層級分數。Milvus 支援多種彙整策略：

彙整策略從回傳的元素命中結果得出實體分數重要條件
max最佳元素分數適用於支援的一般向量度量
sum所有回傳元素分數的總和請與正相關度量（如 IP 或 COSINE）搭配使用
avg回傳元素分數的平均值適用於支援的一般向量度量
topk_sum最佳 K 個回傳元素分數的總和需要正數 topk；請與 IP 或 COSINE 搭配使用
topk_avg最佳 K 個回傳元素分數的平均值需要正數 topk

彙整僅作用於該 ANN 子搜尋回傳的元素命中結果；它不會在檢索後掃描實體中的每個元素。因此，請求的 limit 控制哪些元素命中結果可用於彙整函式。

這個選擇塑造的是檢索語意，而不僅僅是輸出格式。如果應用程式呈現的是片段或段落，那麼在融合過程中保留偏移量是自然的。如果它呈現的是影片、產品或文件，那麼實體層級彙整是自然的。當訊號在不同粒度下運作時，系統需要一個明確的元素到實體計分規則。

StructArray 將這個識別與彙整問題從臨時的後處理移入搜尋執行模型。

Milvus 如何在執行 StructArray 時不將其視為不透明物件

使用者看到的模型是 ARRAY<STRUCT>。然而，將整個值儲存為一個不透明的 blob，會使子欄位索引、過濾和選擇性輸出變得不夠高效。

Milvus 採用「邏輯父欄位、實體子欄位」的設計。

在 schema 層，clips 是邏輯父欄位。它定義了 Struct schema、最大容量和可空性等屬性。其子欄位被正規化為 clips[clip_embedding_list]、clips[clip_embedding]、clips[scene_type] 和 clips[label_confidence] 等路徑。

純量子欄位遵循每個實體的純量陣列儲存路徑，而向量子欄位遵循向量陣列路徑。每個子欄位因此可以使用適合其型別的資料路徑：metadata 使用純量過濾和純量索引，嵌入向量則使用向量索引和 ANN 搜尋。

在攝入時，Proxy 將巢狀的 Struct 清單展開為型別化的子欄位。在執行期間，Milvus 維護每個實體元素與其父實體之間的關係。概念上，這種關係如下所示：

Plaintext
entity 0 -> elements [0, 1, 2]
entity 1 -> elements [3]
entity 2 -> elements []
entity 3 -> elements [4, 5, 6, 7]

當元素層級搜尋回傳實體元素 ID 時，Milvus 會將其映射回父實體和元素偏移量。當 element_filter 產生元素層級的 bitmap 時，引擎會將其與父實體可見性、刪除和其他過濾器對齊。

回傳結果時，Milvus 使用邏輯 schema 和共享偏移量來重建應用程式插入的 StructArray 形狀。系統可以在型別化的子欄位上執行，而使用者繼續讀寫自然的巢狀物件。這種實體佈局使 StructArray 不僅僅是型別化的 JSON：巢狀關係參與了索引和執行模型。

StructArray 適用之處與不適用之處

當以下所有條件都成立時，StructArray 是極佳的選擇：

  • 應用程式有一個有意義的父實體，例如影片、產品、文件、視覺頁面或記憶記錄。
  • 每個父實體包含一組有序、可變長度的局部元素。
  • 這些元素需要各自的純量 metadata、向量或兩者。
  • 搜尋或過濾必須保留同一個元素偏移量上子欄位之間的關聯。
  • 應用程式需要實體層級的多向量檢索、元素層級命中結果，或兩者。

StructArray 並非自動對每個集合都更好。一份短文件或簡單查詢可能只需單一稠密嵌入就足夠。多向量索引會增加儲存和搜尋成本，因此額外的表示必須透過提升檢索品質或更有用的結果粒度來證明其價值。

目前的 schema 和執行邊界也很重要：

  • Struct 僅作為 Array 的元素型別支援，不支援作為頂層集合欄位。
  • 一個 StructArray 中的所有元素共享一個預先定義的 schema。
  • max_capacity 是必填的，並限制每個實體的元素數量。
  • StructArray 內部不支援巢狀的 Struct、Array、ArrayOfStruct 和 JSON 子欄位。
  • 一個向量子欄位只能接受一個索引。當同時需要 EmbeddingList 和元素層級搜尋時，請使用分開的向量子欄位。
  • 向量子欄位在搜尋前必須先建立索引。大量用於過濾的純量子欄位應適當建立索引。
  • 子欄位 schema 在 StructArray 欄位建立後即固定，因此在生產環境上線前應先規劃元素屬性。

這些限制使模型比文件資料庫的任意巢狀更為狹窄，但它們也給了 Milvus 足夠的結構來推理元素身分、索引每個子欄位，並以兩種搜尋粒度執行。

StructArray 將局部證據視為一等公民，同時不失去實體

StructArray 為 Milvus 提供了一個扁平 schema 難以表示的檢索物件：一個帶有一組有序結構化元素的父實體。這些元素之間的關聯參與過濾、索引和搜尋，而不僅僅存在於儲存中。

每個元素保留自己的 metadata 和嵌入向量。這些元素可以滿足同元素純量謂詞、一起參與實體層級的 EmbeddingList 搜尋，或在元素層級搜尋中獨立競爭。同時，它們仍然依附於父實體，父實體的 metadata、權限和應用程式身分為它們提供了上下文。

對於影片片段、產品圖片、文件段落、視覺區塊和記憶片段，局部證據可以被搜尋和過濾，而不會失去其所屬的實體。其餘的設計選擇是明確的：選擇搜尋粒度、為每個向量子欄位指定匹配的度量和索引，並決定混合結果應該保留元素偏移量還是彙整回實體。

在 Milvus 3.0 中試用 StructArray

StructArray 已於 Milvus 3.0 中提供。從 StructArray 概覽開始。如果你正在評估實體層級的多向量檢索，請閱讀 EmbeddingList 策略指南。關於結果粒度和彙整行為，請參閱使用 StructArray 進行混合搜尋。

關於更廣泛的版本資訊，請參閱 Milvus 3.0 發布部落格、版本說明和 milvus-io/milvus 儲存庫。

Zilliz Cloud 也支援受管部署的 StructArray 和 EmbeddingList 搜尋。請參閱 Zilliz Cloud StructArray 指南以了解服務特定的限制。在 Zilliz Cloud 中，StructArray 的純量運算子目前僅記錄為支援 On-Demand 叢集。

若要與團隊討論 schema 或檢索設計，請加入 Milvus Discord 社群或預約 Milvus Office Hours 時段。

    Try Managed Milvus for Free

    Zilliz Cloud is hassle-free, powered by Milvus and 10x faster.

    Get Started

    Like the article? Spread the word

    繼續閱讀