Skip to content

.Net: Pack of changes from MEVD API review - #11882

Merged
Shay Rojansky (roji) merged 7 commits into
microsoft:feature-vector-data-preb3from
roji:ApiReviewPack
May 5, 2025
Merged

Shay Rojansky (roji) merged 7 commits into
microsoft:feature-vector-data-preb3from
roji:ApiReviewPack

Conversation

@roji

@roji Shay Rojansky (roji) commented May 4, 2025 •

Copy link
Copy Markdown
Member

Note: this PR is based on top of #11879 - ignore first commit.

This PR contains a pack of several unrelated changes from API review; each is quite simple on its own, so I submitted them as a single PR. I recommend reviewing this commit-by-commit.

@roji
Shay Rojansky (roji) requested a review from a team as a code owner May 4, 2025 14:59
@markwallace-microsoft Mark Wallace (markwallace-microsoft) added .NET Issue or Pull requests regarding .NET code kernel Issues or pull requests impacting the core kernel memory labels May 4, 2025
@github-actions github-actions Bot changed the title Pack of changes from MEVD API review .Net: Pack of changes from MEVD API review May 4, 2025
/// Initializes a new instance of the <see cref="VectorStoreDataProperty"/> class by cloning the given source.
/// </summary>
/// <param name="source">The source to clone.</param>
public VectorStoreDataProperty(VectorStoreDataProperty source)

Copy link
Copy Markdown
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

westey (@westey-m) please note this separate commit that also makes the record definition property types mutable.

We had this conversation previously in #10879, but since then we introduced the MEVD model, so the record definition is no longer referenced or used in any way after the model building step; that should make it safe to make it fully mutable, as it's only used during the construction of the collection (just like the option bags are only used during GetAsync, SearchAsync, etc).

Hopefully this all makes sense - if not let me know, I'm happy to pull this commit out of the PR and to have a separate discussion on it.

@adamsitnik Adam Sitnik (adamsitnik) left a comment

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I've reviewed each commit separately and overall it looks good to me. I've found few nits, feel free to address them before merging if you want to.

I know it's very subjective, but IMO 'VectorSearchOptions' was better name than RecordSearchOptions, but SimilaritySearchOptions would be even better.

Thank you Shay Rojansky (@roji) !

/// Gets or sets a value indicating whether the key should be auto-generated by the vector store.
/// </summary>
public bool AutoGenerate { get; init; }
public bool AutoGenerate { get; set; }

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I've just realized that the property was exposed, but we don't ever respect it (yet).

@roji Shay Rojansky (roji) May 5, 2025 •

Copy link
Copy Markdown
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yeah, true - good catch... Maybe safer to remove it for now, until we have at least one implementation which actually makes use of it - simply because we're not 100% sure yet what the feature will look like... Made a note, will do that in a separate PR later. Will remove this.

/// </summary>
public IReadOnlyList<VectorStoreProperty> Properties { get; init; } = s_emptyFields;
[AllowNull]
public IList<VectorStoreProperty> Properties

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I still believe that we should expose just the list rather than an ability to provide your own collection. Anyway, it could be just a List here as we don't really benefit from exposing an abstraction (in case of IReadOnlyList it could be an array)

Copy link
Copy Markdown
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I mainly did IList<T> to align with MEAI - see this comment. I don't really have strong feelings on this - if the user happens to have e.g. an array, IList allows that to be assigned directly (whereas List does not). Any specific thoughts/arguments for exposing List instead of IList?

(will go ahead and merge to move forward, but let's continue the conversation and I can always change it later)

IVectorSearch -> IVectorSearchable
IKeywordHybridSearch -> IKeywordHybridSearchable
GetRecordOptions -> RecordRetrievalOptions
GetFilteredRecordOptions -> FilteredRecordRetrievalOptions
VectorSearchOptions -> RecordSearchOptions
Originally these were generic in order to support custom mappers, but
these were removed.
@roji

Copy link
Copy Markdown
Member Author

I know it's very subjective, but IMO 'VectorSearchOptions' was better name than RecordSearchOptions, but SimilaritySearchOptions would be even better.

This was proposed during API review in order to align the SearchAsync option bag with the GetAsync ones; on the GetAsync side we (now) have RecordRetrievalOptions and FilteredRecordRetrievalOptions, so on the SearchAsync side the proposal was to have RecordSearchOptions (the verb Search in MEVD implicitly means "similarity" or "vector" search).

I can see where you're coming from though - VectorSearchOptions is possibly a little bit more clear. I'll go ahead and merge for now but I've taken a note to raise this again to see what people feel - we can always change it back.

This especially makes sense now that we have a model that gets
built based on the record definition (and attributes).

Closes microsoft#10879
@roji
Shay Rojansky (roji) merged commit 472e1d5 into microsoft:feature-vector-data-preb3 May 5, 2025

This branch was previously deployed

1 inactive deployment
integration — 3a260eaf Deployed May 5, 2025 by roji
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

kernel Issues or pull requests impacting the core kernel memory .NET Issue or Pull requests regarding .NET code

Projects

None yet

Development

Successfully merging this pull request may close these issues.

4 participants