You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Currently, the configuration of the SK is done by using the following approach:
private static IKernel GetOpenAIKernel()
{
var kernel = new KernelBuilder()
.WithOpenAIChatCompletionService(
.WithAzureTextCompletionService
..
..
)
.Build();
return kernel;
}
This is all fine for learning and testing purposes. I'm looking for the following configuration:
KernelConfiguration settings = ...
var kernel = new KernelBuilder(settings)
Explenation
The currently provided approach is very important. The developer must change the code when changing the service and model. Once the application goes through the DEVOPS lifecycle, it should be possible to configure it by configuration only, without changing the code. It might be that SK already contains this, but I simply did;t see it.
If you provide the proposed constructor, the developers can decide how to materialize the kernel's configuration. It can use DI, can load settings from DB, environment variables, etc. This has already been an approach in place fro decades in. NET. Following your code samples shipped through the VS extension, it is can be noticed that 80% of the code of every sample is plumbing the configuration (files, secrets, environment variables, etc.) in a very unusual way.
Bootstrapping the NET application is an established process in enterprises, and the SK should also align with it.
It is not the task of the SK team to provide a new type of application. I see in the documentation very often "AI Apps". This is the wrong direction. The correct thinking would be, "We build .NET application, and the SK is a part of it leveraged through SK-SDK".
We are happy with possible new AI application types; however, that one should not slow us down today.
reacted with thumbs up emoji reacted with thumbs down emoji reacted with laugh emoji reacted with hooray emoji reacted with confused emoji reacted with heart emoji reacted with rocket emoji reacted with eyes emoji
-
Currently, the configuration of the SK is done by using the following approach:
This is all fine for learning and testing purposes. I'm looking for the following configuration:
Explenation
The currently provided approach is very important. The developer must change the code when changing the service and model. Once the application goes through the DEVOPS lifecycle, it should be possible to configure it by configuration only, without changing the code. It might be that SK already contains this, but I simply did;t see it.
If you provide the proposed constructor, the developers can decide how to materialize the kernel's configuration. It can use DI, can load settings from DB, environment variables, etc. This has already been an approach in place fro decades in. NET. Following your code samples shipped through the VS extension, it is can be noticed that 80% of the code of every sample is plumbing the configuration (files, secrets, environment variables, etc.) in a very unusual way.
Bootstrapping the NET application is an established process in enterprises, and the SK should also align with it.
It is not the task of the SK team to provide a new type of application. I see in the documentation very often "AI Apps". This is the wrong direction. The correct thinking would be, "We build .NET application, and the SK is a part of it leveraged through SK-SDK".
We are happy with possible new AI application types; however, that one should not slow us down today.
Beta Was this translation helpful? Give feedback.
All reactions