How to develop an extension outside of the library

[alkampfergit]

Context / Scenario

I'm implementing Memory with ElasticSearch because I need some special functionalities for my use case, also I've tried the one I found on nuget and I got errors.

Question

I've already developed the adapter for MongoDb Atlas, but since this adapter is somewhat custom, I'm not sure that can be inserted in the base distribution of KM, nevertheless I'd like to test with the very same test case that all other memories uses.

Is it possible to publish those base test package in nuget so I can reference those from my project to add a series of tests that are aligned to the one used by the official library?

Actually the only way I can do the same test is copy/paste base test code from Kernel Memory source, but keeping everything alingned is not really easy.ly
Another alternative would be developing the adapter in my fork of kernel memory, then at a certain point I can try to pull request or leave it go alone, but I really preferred to reference some test base nuget package, it would probably be the best solution to develop adapters to kernel memory outside of the official repository.

[dluc]

I would follow the example provided by the existing ElasticSearch extension developed here https://github.com/freemindlabsinc/FreeMindLabs.KernelMemory.Elasticsearch - you could also consider extending it, or collaborating with @afederici75 to fix bugs - This blog post https://devblogs.microsoft.com/semantic-kernel/elasticsearch-kernelmemory/ might also be a useful read before starting.

If you choose to work in a separate repo and share your extension as a public nuget, you might want to consider the maintenance costs, e.g. keeping your nuget in sync with releases of the Abstractions package.

[alkampfergit]

It would be nice to be able to run the official set of tests from the original kernel-memory repository, that because I assume that if something changes the test also changed.

I was headed to use a separate implementation because I use usually a complete different approach using heavily dynamic mapping and I need to also be able to do BM25 standard search to mix vector and keyword search then rerank. So it is easier for me to rewrite the provider (I started from the one I wrote for MongoDb atlas).

[afederici75]

It appears some changes were not merged correctly in the MS repo. As far as improving or allowing for further customization I'd be cool with it. I am in Italy till the 18th and my mobility is a little compromised, but let me know if you are interested in talking some more about this.

[alkampfergit]

Actually I've created a different implementation to be able to experiment mixed BM25 and vector search, dynamic mapping and so on.
It is working fine so I'll proceed on this direction to be able to implement quickly features I need.

Thank a lot for the info

[afederici75]

Sounds good. Just an extra note: the tests (if merged correctly, which I will have to check) include all the MS tests plus about another 50 or so I created.

[alkampfergit]

Yes I looked at the code, i also created my own test suite, probably it is simpler, after all the basic tests from MS library are not complex :)

[dluc]

It would be nice to be able to run the official set of tests from the original kernel-memory repository, that because I assume that if something changes the test also changed.

I was headed to use a separate implementation because I use usually a complete different approach using heavily dynamic mapping and I need to also be able to do BM25 standard search to mix vector and keyword search then rerank. So it is easier for me to rewrite the provider (I started from the one I wrote for MongoDb atlas).

no problem, if you want we can host the provider in this repo too. I think it would be good to make the client configurable in terms of fields, how to search, etc. Your call 👍

[alkampfergit]

At the end of the day, I did yesterday night a small experiment but I think, that in term of maintenability, I can do the very same I did with MongoDB Atlas, developing directly in the kernel-memory project, it would be the best solution for maintenability.

Thanks for the info.

[alkampfergit]

Actually the package is in a repository of mine mainly because I can move to my speed breaking things without worrying to maintain too much past compatibility.

The code is stable enough to be moved inside main repository. Actually I use my provider to do vector search and a separate keyword search then reorder with cohere reranking.