When using a collection with multiple vector fields, what value should be inserted into the collection when one of the vector value is missing?

[noob9527]

background:
let's say, I have a resume/profile collection, each record represents a person.
I have a text field stores the person's background, its length varing from 0-65535, as we've got maximum token limits for embedding model. I have to split the text and embed them into multiple vectors.
As milvus now supports multiple vectors. I think it would be better to store all vectors with this record because this way when I say top 40 people, I won't get duplicate person.

Q: when a person's text is short and can be embeded into 1 vector, what kind of value should I insert into the rest vector fields?

From what I've known, I think there isn't such a concept such as "Optional" vector field for now.

BTW, I already considered inserting zero-vectors as default value, but when I went through the hybrid search document, I think both the WeightedRanker and RRFRanker cannot handle such zero-vectors.

[yhmo]

Each collection is a table, each field is a column. When you define a collection, you must define how many columns in this table.
A resume could be 100 words, could be 1000 words, also could be tens of thousands of words. So, a resume could be 1 embedding, 10 embeddings, 100 or even more embeddings.
Is it a reasonable way to define the table with hundreds of columns? Absolute No.

All these embeddings are generated by one model, right? They should be computed within a column.
The solution is:

1. each resume has a resume_id
2. define a collection with one vector field, and a integer field to store the resume_id
3. each vector is one row, insert into collection, each row has an unique primary id.
4. vectors comes from the same resume has the same resume_id
5. search() returns a list of rows, some of them comes from the same resume, they have the same resume_id
6. rerank the results by your requirement

Let's say one search request return the top 10 items:

1. id=8, resume_id=99, distance=0.01
2. id=56, resume_id=5, distance=0.02
3. id=23, resume_id=14, distance=0.03
4. id=190, resume_id=32, distance=0.04
5. id=87, resume_id=5, distance=0.05
6. id=25, resume_id=99, distance=0.06
7. id=173, resume_id=32, distance=0.07
8. id=209, resume_id=5, distance=0.08
9. id=98, resume_id=8, distance=0.09
10. id=47, resume_id=21, distance=0.10

If you want "the more items in top10 is what I need", then resume_id=5 is the answer
If you want "the topmost item is what I need", then resume=99 is the answer.

[yhmo]

The key point is the embedding are generated by one model, they should be computed as a column. Normally, multi-vector-field is for different embeddings from multi models.

Group by also requires the embeddings in one vector field. In earlier versions, there are no "group_size" parameter, each group only return one item. You'd better use the latest milvus version and latest pymilvus version to try.

[noob9527]

I think it could be a common use case.

The problem is that most ML models that analyze text to generate dense vectors for ranking are limited to 512 tokens, which is roughly the size of a single paragraph. In other words, when dense vectors are required for vector search there will typically be sufficient text to require generating multiple vectors per document.

the above quote is from multi-vector-documents

It would be convenient if I can use multi-vector-field this way, and it won't be that hard, if we can figure out a way to:

1. allow to create "optional" vector field.
2. implement a "MAX" reranker, as it is mentioned in the reranking strategy

either method will solve my problem.

BTW, it seems grouping search doesn't work with hybrid search,
so for now, I think I have to implement a deduplication method at the application level.

[yhmo]

Elasticsearch is document-oriented, the data structure is similar to MongoDB.
Milvus storage is column-based, the concept "field" cannot be abused.

[xiaofan-luan]

@yhmo thank you for your detailed explanation.

A resume could be 100 words, could be 1000 words, also could be tens of thousands of words. So, a resume could be 1 embedding, 10 embeddings, 100 or even more embeddings.
Is it a reasonable way to define the table with hundreds of columns? Absolute No.

I was thinking about using around 1000 token as a chunk, and 10(vector fields) * 1000 token length would be able to cover 99% resume in our scenario, that's the reason I came up with this way.

the point for doing this, is, when I file a "top10" query, I want 10 different resume from 10 different people. i.e. I want 10 best matched resume instead of 10 best matched chunks.

Anyway, I'm currently looking into grouping search, which seems to fit my needs.

Groupby is generally what you need.

Multi vector could be even better for your use case

[xiaofan-luan]

Right now you need to store each chunk into one entitiy and groupby resume id to make sure all the top10 result is not duplicated.

Support array of vector could be a better data model

[yiwen92]

@noob9527 We will support group by in hybrid search in Milvus 2.5, it will coming soon!