Add support (provider) for Azure Openai (Europe / GDPR loves that)

So there are two separate things here that could be discussed:

1. Adding only resource name, deploy id and version into the normal OpenAI provider and then it switches over. This should be fairly simple to add, its just a question if it belongs in the OpenAI provider or another provider module.
2. Actually offer the whole Azure module catalogue for the type of operation types we offer: https://ai.azure.com/explore/models.

The second step is much (3-7 days) work, even more work if they want their RAG databases to be integrated as well. But maybe we could ask for sponsorship for that from Microsoft?

I think the first option is not that good as the Azure OpenAI API is somewhat different and may diverge even more. I noticed this when trying to use the openai-php/client library in a custom chat solution: the structure of a response message was slightly different and the library couldn't process it as it wrongly assumed an array key existing - I don't remember which one exactly though.

I asked if the library could support Azure OpenAI too but haven't gotten a reply yet: https://github.com/openai-php/client/issues/320

Now that I plan to start using this module too, I'd need a provider that would supports at least the chat operation to begin with. Currently that would require reinventing the wheel for the client library, if I'm not mistaken.

Thanks for the heads up on that jhuhta - that means that we will have to write our own client or fork it. I agree that this is important for enterprise since OpenAI is the most used provider and Azure is the only way to have it in a secure and GDPR friendly way.

All the more reason to reach out the Microsoft to sponsor this, they will recuparate that cost with the first 10 clients using it.

Hi, I've looked into this question a bit.

I'm not entirely sure how the Azure OpenAI API is different now or what to expect in the future. However, at this moment, we can continue using openai-php/client, at least for Chat operations it works.

I've made some changes to make the Chat operation work and was able to test it successfully with ai_api_explorer, ai_ckeditor, and ai_content submodules. I didn't test other operations because I don't have an Azure OpenAI deployment available (I hope to get one later).

Due to how Azure OpenAI works, the current implementation have limitation and allows the use of a single model (deployment) at a time. I have some ideas about implementing a plugin deriver to allow the use of multiple deployments, but I'm not sure if there is no better solution(I left multiple @todo comments in the PR). I'd be happy to discuss this, and if it's the right approach, I can contribute it.

Next steps:

• Test the Chat operation.
• Support using multiple deployments (models).
• Test, finish, and add other operations that Azure OpenAI offers.
• Test and finalize detailed models configuration.
• Consideration around openai-php/client vs new SDK.

Chat Operation should work, let's test it.

Update this branch with latest changes from 1.0.x and added changes to be able to use multiple deployments. Hope will find some time this week to do more progress here.

I found a way to test the text_to_image operation, and it works. Unfortunately, I ran into a slightly annoying limitation. My Dall-E model deployment is in a different region, with a different resource name and even a different API key. I’m not sure if there's a way to have multiple instances of one provider or if there are any plans for this. Any comments?

@mostepaniukvm - great!

The provider has a pre-query event and should have methods to change the configuration and authentication right before the query is sent. I think that would be one way of solving this. But the question is if it makes sense to make the provider configs into multi configurations by default as a interface. The enterprise providers like Azure, Google, Bedrock etc, needs it for sure.

Also the question is if we make a generic way of doing this, since the settings config schema should be replicable. This probably needs some generic filter rules on when which provider should run (uid, role, page, operation type etc.).

Maybe we should create a discussions ticket around the best way to solve it?

Thank you, @marcus_johansson.
I opened this issue 🌱 [Discussion] Support for Multiple API Connections per AiProvider Active , and we can continue the discussion there.
If there are no objections, I will mark this task as Unassigned in case someone else wants to help.

Hi, very much silence on this ticket - but we got sponsorship to build this now as a dedicated provider, so its the focus for this week! I will try how much the openai-php/client diverges and at best use it, otherwise fork it or at worst write a client from scratch that we can use for all openai-like providers.

I'm excited about this!

Would this be helpful? https://github.com/cosminimum/azure-open-ai

(Not my package. I just came across it.)

Tada :D

https://www.drupal.org/project/ai_provider_azure →

In the end openai-php/client did work, with a lot of configuration tweaks. It still suffers the same issue as Mistral has, that the error response is different from OpenAI, meaning that if you set something up wrong it would not give a human readable error message.

This is still under development until its first real release, but its possible to test already.

marcus_johansson → closed merge request !44

Sorry, lets set this to fix so I can credit correctly, since I looked at discussions and solutions here

Automatically closed - issue fixed for 2 weeks with no activity.