.Net: Rename AzureChatCompletion to AzureOpenAIChatCompletion (and other types)

[stephentoub]

Important

Labeled Urgent because it may require a breaking change.

We have OpenAIChatCompletion and AzureChatCompletion, and OpenAIRequestSettings which appears to be what should be used with both. Should AzureChatCompletion (and related types) be renamed to have AzureOpenAI instead of Azure as the prefix? Will AzureChatCompletion work with everything "Azure" in the future and not just the "AzureOpenAI" service? Will someone seeing they need to pass an AIRequestSettings to work with AzureChatCompletion know that it's the OpenAIRequestSettings they need to use even though there's no Azure in the name?

[matthewbolanos]

The existing Azure Chat/Text completion connectors should make it clear that they're only for OpenAI models.

[stephentoub]

Looking at this again, why do the AzureOpenAIXx types/methods even need to exist? Isn't everything identical between the AzureOpenAIXx and OpenAIXx types, including implementation down to the OpenAIClient being used. and the only difference is whether an endpoint is supplied to the ctor?

[dmytrostruk]

why do the AzureOpenAIXx types/methods even need to exist

@stephentoub Even taking into account that for both Azure OpenAI and OpenAI services we use the same Azure .NET SDK, we need to remember that these are separately hosted services with different configuration. Each service has its own deployment model, retry strategy, throttling etc. I think it's good to differentiate them by .NET types, rather than passed settings in constructor. Also, there are things like AzureChatCompletionWithData, which extends Azure OpenAI functionality, while on OpenAI side there are things like "Function Calling" and potential features in the future.

But I 100% agree that Azure* types should be renamed to AzureOpenAI* types for better understanding.

[stephentoub]

But I 100% agree that Azure* types should be renamed to AzureOpenAI* types for better understanding.

👍

while on OpenAI side there are things like "Function Calling"

That exists in Azure OpenAI as well.

[stephentoub]

I don't feel super strongly about consolidating them. But having two completely separate type hierarchices, sets of extension methods, etc., is just extra work for anyone trying to be portable across OpenAI and Azure OpenAI, which is unfortunate given that at the end of the day they end up using the exact same OpenAIClient under the covers, share all of the same code to get there, etc. It seems like unnecessary friction. If we really believe there's going to be divergence in the future that would make consolidation problematic, ok... but I'd be curious what we think that'll be given that OpenAIClient is servicing both.

[dmytrostruk]

Ideally, I would use separate SDKs as these are separate services. But taking into account that we use only one, maybe it makes sense to have one type to handle both services.

On Python side, AzureChatCompletion inherits OpenAIChatCompletion:

semantic-kernel/python/semantic_kernel/connectors/ai/open_ai/services/azure_chat_completion.py

Lines 12 to 15 in f10d90f

	class AzureChatCompletion(OpenAIChatCompletion):
	_endpoint: str
	_api_version: str
	_api_type: str

In case we will have just one type to work with Azure OpenAI and OpenAI, we will have to differentiate both services somehow inside that type, for example for logging. It's important to see in logs which service responds and how.

[SergeyMenshykh]

We can find a middle ground here: keep the SK public API (WithAzureChatCompletionService, WithOpenAIChatCompletionService) as it is today but consolidate the connectors into one. Later, we can always add another connector in case of divergence without impacting SK consumer code.