We are .NET shop (server side at least), so the opportunity to find something that works with .NET was a huge plus for us. I heard similar comments made by Java developers, in regards to SK for Java.
I have been following Semantic Kernel since April and I have been focused on Kernel Memory recently.
Having to learn LLMs, how they work, prompting, vector databases, RAG, tokens, chunking, etc. is hard enough: if we had had to switch to Python entirely it would have been too much to handle.
In other words: while probably everything we need is out there (and oftentimes in more mature forms), we cannot feel comfortable by also adopting an entire new way of doing basic things like microservices, having a REST/GraphQL interface, and to re-learn how to write code and which frameworks to use...
We will use Pyhton, too, and the fact we can have C# and Pyhton in pipelines will allow us to scale our development team with people who are familiar with Python.
So once again, a big plus for a small .NET shop.
That was the primary reason SK was picked.
The fact SK is highly modular (i.e. it allows to switch models and model providers, including self-hosted ones, it allows for custom connectors, such as the one to Elasticsearch we are building) was the second reason.
---
So, at the beginning (up to August) we made sure all the things we needed from SK work.
They did, for the most part.
We can use custom-embeddings/models from HuggingFace, we have access to LLama and then both OpenAi and the Azure OpenAI right now.
My biggest concern was related to pre-filtering large quantities of data, before starting to do semantic searches. The approach SK used was a bit too restrictive and over simplified.
So I started looking into solutions, and now I found out that what I intended to do (filtering wise) is very similar to what the KM team is doing already, so I was happy to see that my problems were being addressed somehow, and we adapted accordingly.
I am trying to see how well KM helps us save reinventing the wheel, and so far I am optimistic. The fact I have access to the KM code and can easily debug it in C# makes us confident we can find ways to get around (or fix) issues and see what it's truly doing.
Finally, the Semantic Team is incredibly active and responsive. They host weekly Teams meetings with the community and they are very dedicated to make this work.
The amount of blog posts and YT videos they produce is quite large.
I have been following Semantic Kernel since April and I have been focused on Kernel Memory recently.
Having to learn LLMs, how they work, prompting, vector databases, RAG, tokens, chunking, etc. is hard enough: if we had had to switch to Python entirely it would have been too much to handle.
In other words: while probably everything we need is out there (and oftentimes in more mature forms), we cannot feel comfortable by also adopting an entire new way of doing basic things like microservices, having a REST/GraphQL interface, and to re-learn how to write code and which frameworks to use...
We will use Pyhton, too, and the fact we can have C# and Pyhton in pipelines will allow us to scale our development team with people who are familiar with Python. So once again, a big plus for a small .NET shop. That was the primary reason SK was picked.
The fact SK is highly modular (i.e. it allows to switch models and model providers, including self-hosted ones, it allows for custom connectors, such as the one to Elasticsearch we are building) was the second reason.
---
So, at the beginning (up to August) we made sure all the things we needed from SK work. They did, for the most part.
We can use custom-embeddings/models from HuggingFace, we have access to LLama and then both OpenAi and the Azure OpenAI right now.
My biggest concern was related to pre-filtering large quantities of data, before starting to do semantic searches. The approach SK used was a bit too restrictive and over simplified.
So I started looking into solutions, and now I found out that what I intended to do (filtering wise) is very similar to what the KM team is doing already, so I was happy to see that my problems were being addressed somehow, and we adapted accordingly.
I am trying to see how well KM helps us save reinventing the wheel, and so far I am optimistic. The fact I have access to the KM code and can easily debug it in C# makes us confident we can find ways to get around (or fix) issues and see what it's truly doing.
Finally, the Semantic Team is incredibly active and responsive. They host weekly Teams meetings with the community and they are very dedicated to make this work. The amount of blog posts and YT videos they produce is quite large.