AITOPAI热报
ProductsSelected

Milvus 3.0 StructArray Multi-Vector Search

Milvus@milvusio
Post
View the post
Why we picked it

Milvus 3.0 StructArray enables more efficient vector search for applications handling complex multimedia content in ASEAN markets.

Milvus 3.0 introduces StructArray for multi-vector search within a single entity. The feature allows videos to store clip embeddings, documents to store passage embeddings, and products to store image embeddings. It supports three retrieval patterns: entity-level multi-vector search, element-level vector search, and same-element filtering. StructArray bridges element-level relevance with entity-level results while maintaining parent context.

Original · Milvus

Milvus 3.0 StructArray brings multi-vector search inside a single entity. A video can keep all its clip embeddings, a document all its passage embeddings, and a product all its image embeddings—without flattening every element into a separate database row. Each element remains attached to its parent while carrying its own vectors and scalar metadata. This enables three retrieval patterns: 𝟭.𝗘𝗻𝘁𝗶𝘁𝘆-𝗹𝗲𝘃𝗲𝗹 𝗺𝘂𝗹𝘁𝗶-𝘃𝗲𝗰𝘁𝗼𝗿 𝘀𝗲𝗮𝗿𝗰𝗵 EmbeddingList search uses MaxSim-style scoring to compare a multi-vector query with all the vectors stored inside an entity. 𝟮.𝗘𝗹𝗲𝗺𝗲𝗻𝘁-𝗹𝗲𝘃𝗲𝗹 𝘃𝗲𝗰𝘁𝗼𝗿 𝘀𝗲𝗮𝗿𝗰𝗵 Search individual clips, passages, images, or visual patches. Each result identifies both the parent entity and the matching element’s offset. 𝟯.𝗦𝗮𝗺𝗲-𝗲𝗹𝗲𝗺𝗲𝗻𝘁 𝗳𝗶𝗹𝘁𝗲𝗿𝗶𝗻𝗴 A filter such as: scene_type = "kitchen" AND confidence > 0.8 must match the same video clip—not two different clips within the video. Together, these capabilities bridge element-level relevance and entity-level results: a single clip, passage, or product image can drive the match, while the application returns the full video, document, or product. StructArray makes that local evidence searchable without losing its parent context. 𝗜𝘁 𝗮𝗹𝘀𝗼 𝘀𝘂𝗽𝗽𝗼𝗿𝘁𝘀 𝗹𝗮𝘁𝗲-𝗶𝗻𝘁𝗲𝗿𝗮𝗰𝘁𝗶𝗼𝗻 𝗿𝗲𝘁𝗿𝗶𝗲𝘃𝗮𝗹 𝗳𝗼𝗿 𝗺𝗼𝗱𝗲𝗹𝘀 𝘀𝘂𝗰𝗵 milvus.io/blog/milvus-3-… �𝗱 𝗖𝗼𝗹𝗣𝗮𝗹𝗶, where one entity is represented by many token or visual-patch vectors. Read the technical deep dive: https://t.co/bXZuMAsX6Q 💬 0 🔄 0 ❤️ 1 👀 32 ⚡

#Milvus#StructArray#multi-vector search#vector databases#embedding

Keep reading

Recent stories with the same tag or section
How-toBuildersSelected23:50
Zilliz tests Jev model as semantic cache gateway guard

Semantic caching usually forces a tradeoff between cost savings and serving wrong answers to slightly different queries; a cheap guard model shifts that balance toward accuracy. Engineers running RAG or agent workloads can plug this pattern into existing caches like GPTCache to cut LLM spend without degrading quality. Milvus and Zilliz have active developer communities across ASEAN, so the benchmark and blog are directly accessible to teams in the region.

#Milvus#Zilliz#Jev#semantic caching
Milvus@milvusioSource
How-toBuildersSelected01:06
Milvus Function Chain Reranks Search with XGBoost in One Call

Reranking inside the vector database itself removes the need for a separate reranking service and an extra network hop, which simplifies production search stacks. Builders running e-commerce, feed, or RAG systems can reuse the open-source demo to blend relevance with revenue-driving signals. It compares with the common pattern of exporting candidates from Milvus and reranking them in an external model server.

#Milvus#XGBoost#RAG#vector database
Milvus@milvusioSource
How-toBuildersSelected00:11
Milvus benchmark tests Jev against LLMs in agentic search

The benchmark suggests a practical routing rule: swap general-purpose LLM calls for Jev only on narrow, high-frequency decisions like stopping checks, and keep dedicated rerankers like Voyage rerank-3 for re-ranking. Teams running RAG pipelines can use the latency and cost figures to decide where Jev cuts spend without hurting recall. Full results are on Milvus's blog.

#Jev#Milvus#RAG#Voyage
Milvus@milvusioSource