.Net: New Feature: VectorStore to provide supported key types

[adamsitnik]

I am currently working on Data Ingestion project, which is more or less an ETL that uses some cloud service to parse the file, some chunkers to split it into chunks, LLMs to extend them with info (keywords/summary etc) and MEVD to store the chunks in the Vector Store (and generate embeddings with MEAI on the fly).

Since the users can specify any number of custom metadata enrichers (add summary, classify, extract keywords), I am using the "dynamic" collections:

https://github.com/adamsitnik/dataingestion/blob/23e97338e0e491598e5b8dc2f7b1690f16309799/src/Microsoft.Extensions.DataIngestion/VectorStoreWriter.cs#L87-L88

And building the definition on the fly:

https://github.com/adamsitnik/dataingestion/blob/23e97338e0e491598e5b8dc2f7b1690f16309799/src/Microsoft.Extensions.DataIngestion/VectorStoreWriter.cs#L118-L152

It works really nice and is easy to use, but I have to ask the users to specify the TKey in explicit way:

https://github.com/adamsitnik/dataingestion/blob/23e97338e0e491598e5b8dc2f7b1690f16309799/src/Samples/Program.cs#L48

I would like to avoid that (so it's super easy to use and get started), and then choose following key generation strategy:

• for all the vector stores that support Guid as key, generate new Guid when inserting chunk records
• for all the vector stores that support string as key, generate a guid and get its string representation.

It would be great if VectorStore was capable of exposing information about supported key types. Then I would not need to ask the users to specify that.

My API proposal is to extend VectorStoreMetadata with IReadOnlyList<Type> SupportedKeyTypes property.

public class VectorStoreMetadata
{
    public string? VectorStoreSystemName { get; init; }
    public string? VectorStoreName { get; init; }
+   pulict IReadOnlyList<Type> SupportedKeyTypes { get; init; }
}

IReadOnlyList<Type> backed by array should be just enough to quickly check if given type is supported. HashSet would be better if there was more types, for this case it could just slow down the startup time by compiling another type.

cc @roji @westey-m please let me know what do you think, I am more than happy to send a PR.

[adamsitnik]

I took an attempt to implement it. Here are my findings:

1. InMemoryVectorSore supports all kinds of keys, so having a list of supported types is not enough to express it:

semantic-kernel/dotnet/src/VectorData/InMemory/InMemoryModelBuilder.cs

Lines 21 to 27 in 28ea2f4

	protected override bool IsKeyPropertyTypeValid(Type type, [NotNullWhen(false)] out string? supportedTypes)
	{
	supportedTypes = "";
	// All .NET types are supported by the InMemory provider
	return true;
	}

However, InMemoryVectorSore is very special (used only for testing), so in theory it could simply not provide this information.

2. CollectionModelBuilder already has a method for that:

semantic-kernel/dotnet/src/VectorData/VectorData.Abstractions/ProviderServices/CollectionModelBuilder.cs

Line 528 in 28ea2f4

protected abstract bool IsKeyPropertyTypeValid(Type type, [NotNullWhen(false)] out string? supportedTypes);

The CollectionModelBuilder is a public type that is supposed to be used only by the connectors. And it's created when a collection is created, as it requires to know TRecord. So VectorStore can't expose it.

3. CollectionModelBuildingOptions describes a lot of related information, but it's also only for connectors. And even if we change GetService to return it, a list of supported types is not able to support "all types are supported" scenario. So this type would need to be extended with a virtual IsKeySupported(Type type) method and support both (it would be OK for my case, as all I need to know is whether string or Guid are supported). The advantage of exposing CollectionModelBuildingOptions via GetService would be to expose more information for similar "power users".