After saving vecotr, Can not searchVector by Microsoft.SemanticKernel.Connectors.Weaviate.

[liujiyuan]

When I run the code belowed:
`// Placeholder embedding generation method.
async Task<ReadOnlyMemory> GenerateEmbeddingAsync(string textToVectorize)
{
// your logic here
}

// Generate a vector for your search text, using your chosen embedding generation implementation.
ReadOnlyMemory searchVector = await GenerateEmbeddingAsync("I'm looking for a hotel where customer happiness is the priority.");

// Do the search.
var searchResult = await collection.VectorizedSearchAsync(searchVector, new() { Top = 1 });

// Inspect the returned hotel.
await foreach (var record in searchResult.Results)
{
Console.WriteLine("Found hotel description: " + record.Record.Description);
Console.WriteLine("Found record score: " + record.Score);
}`

I get a error:
`Microsoft.Extensions.VectorData.VectorStoreOperationException : Error occurred during vector search. Response: {"errors":[{"locations":[{"column":5,"line":3}],"message":"Cannot query field "skhotels" on type "GetObjectsObj". Did you mean "Skhotels"?","path":null}]}

at Microsoft.SemanticKernel.Connectors.Weaviate.WeaviateVectorStoreRecordCollection1.VectorizedSearchAsync[TVector](TVector vector, VectorSearchOptions options, CancellationToken cancellationToken) ...... --- End of stack trace from previous location ---

[liujiyuan]

@markwallace-microsoft Could you help me?

[liujiyuan]

Is there a complete Weaviate example? Similar code works fine with Qdrant. There are issues with both Weaviate and Milvus. It's very simple to use with Python. Since there are already fewer developers using C#, this is incredibly frustrating; I've been struggling with this for several days now, and it should have been a simple task. Recently started an AI course, and the instructor initially used the semantic kernel framework too but gave up eventually. Does Microsoft care or not? If this continues, there will be fewer and fewer C# programmers.

[westey-m]

@liujiyuan, thanks for raising the issue.
Weaviate requires collection names to start with an upper case letter. See here. This is ultimately what is meant by the error message returned by Weaviate, even if it is not immediately obvious.

If you change the collection name to 'Skhotels', it should therefore fix this error.

Apologies. It looks like our Weaviate docs page did not demonstrate this correctly. An update for that will go out shortly.

Please let us know what issues you are having with Milvus and hopefully we can help with that too.

[westey-m]

@liujiyuan, we have an end to end RAG console app sample that allows a choice of different Vector DBs including Weaviate:
https://github.com/microsoft/semantic-kernel/tree/main/dotnet/samples/Demos/VectorStoreRAG

Note the instructions in the README.md on how to set various dotnet secrets to allow the sample access to the chosen AI service and to configure access to the chosen vector db.

It also contains code to convert the configured collection name to start with an upper case letter for Weaviate avoiding the issue you encountered:
https://github.com/microsoft/semantic-kernel/blob/main/dotnet/samples/Demos/VectorStoreRAG/Program.cs#L109

[liujiyuan]

Thank you @westey-m . I followed your advice and changed the collection name to start with a capital letter, which resolved the issue. I was referring to the example in this Weaviate docs page link, where the collection names do not start with a capital letter. Could you please update the documentation accordingly?
The code for the demo in Weaviate docs page is as follows:
var collection = new WeaviateVectorStoreRecordCollection<Hotel>( new HttpClient { BaseAddress = new Uri("http://localhost:8080/v1/") }, "**skhotels**");

[liujiyuan]

Does Milvus still only support version 2.2? I tried both versions 2.2 and 2.3, but neither worked. My code is similar to that for Weaviate and Qdrant. I'm not sure what's wrong. Is there a complete, working code example available?

[westey-m]

We do not currently support Milvus with the new VectorStore abstractions. Here is the summary of our supported VectorStore implementations.

Milvus is only supported using the legacy MemoryStore abstractions at the moment, but this is a different interface with less functionality than than the newer VectorStore abstractions. Here is the list of legacy MemoryStore implementations, including a comparison between the VectorStore and MemoryStore abstractions.

The integration tests for the Milvus MemoryStore implementation is a good example of its usage, and they are currently passing successfully against the milvusdb/milvus:v2.3.10 docker container. The Milvus MemoryStore implementation was updated to use version 2.3.0-preview.1 version of the milvus .net client last year. See the commit here.

[westey-m]

Thank you @westey-m . I followed your advice and changed the collection name to start with a capital letter, which resolved the issue. I was referring to the example in this Weaviate docs page link, where the collection names do not start with a capital letter. Could you please update the documentation accordingly? The code for the demo in Weaviate docs page is as follows: var collection = new WeaviateVectorStoreRecordCollection<Hotel>( new HttpClient { BaseAddress = new Uri("http://localhost:8080/v1/") }, "**skhotels**");

Thanks for highlighting the issue in our documentation. It is now updated. We have also added a warning in the Limitations section that warns about the upper case requirement that Weaviate has.

[liujiyuan]

Thank you very much! Are there any plans to improve support for Milvus in the future? Why is the support for Milvus currently lacking? What are the reasons behind this? Which vector database does Microsoft currently recommend for production environments? Is Milvus not being promoted?

[sphenry]

Hi @liujiyuan we're updating our vector store connectors over time, but we welcome contributions from the vector store owners and from the community. For example, Elasticsearch recently created a connector that uses the new vector store abstractions: Announcing the Microsoft Semantic Kernel Elasticsearch connector

The connectors that don't use our new abstractions continue to work, is there a particular feature you're looking for?