There is an issue when using Azure OpenAI end points that are privately hosted and may not conform to public patterns. As a result, in the graphrag class and ._llm.py utility functions, the API endpoint can potentially be malformed, given the base_url of the primary ('best') model end point given in the .env file.
An example of the malformed end point is as follows.
If we have AZURE_OPENAI_ENDPOINT="https://<path_to_api>/gpt-4o", when utility functions such as azure_openai_complete_if_cache attempt to retrieve the mini version of the end point, the result can be https://<path_to_api>/gpt-4o/openai/deployments/gpt-4o-mini/chat/completions?api-version=2024-10-21. In this case, the end point is malformed because the actual end point reads as https://<path_to_api>/gpt-4o-mini/openai/deployments/gpt-4o-mini/chat/completions?api-version=2024-10-21. It is a minor issue in formatting the text of the end point but a major issue as it must be correct or it fails.
As a result, when attempting to perform insert functions with the graphrag class, the operation fails because the end point for the cheap model function does not exist.
The likely fix, specifically for Azure Open AI is to allow the user to optionally specify the mini end point (meant for the 'cheap' model) in the .env file; if given, to parse that endpoint for use throughout graphrag. The changes are primarily contained to ._llm.py where a new utility function called get_azure_openai_mini_client_instance can manually retrieve the environmental variable for "AZURE_OPENAI_MINI_ENDPOINT" and return the AzureOpenAI result with the fully formed API end point. The default (else) is to return the expected result from get_azure_openai_async_client_instance. In addition, the azure_openai_complete_if_cache function can be modified to switch to calling the new function based on the deployment name being equal to "gpt-4o-mini".
There is an issue when using Azure OpenAI end points that are privately hosted and may not conform to public patterns. As a result, in the
graphragclass and._llm.pyutility functions, the API endpoint can potentially be malformed, given thebase_urlof the primary ('best') model end point given in the.envfile.An example of the malformed end point is as follows.
If we have
AZURE_OPENAI_ENDPOINT="https://<path_to_api>/gpt-4o", when utility functions such asazure_openai_complete_if_cacheattempt to retrieve the mini version of the end point, the result can behttps://<path_to_api>/gpt-4o/openai/deployments/gpt-4o-mini/chat/completions?api-version=2024-10-21. In this case, the end point is malformed because the actual end point reads ashttps://<path_to_api>/gpt-4o-mini/openai/deployments/gpt-4o-mini/chat/completions?api-version=2024-10-21. It is a minor issue in formatting the text of the end point but a major issue as it must be correct or it fails.As a result, when attempting to perform insert functions with the
graphragclass, the operation fails because the end point for the cheap model function does not exist.The likely fix, specifically for Azure Open AI is to allow the user to optionally specify the mini end point (meant for the 'cheap' model) in the
.envfile; if given, to parse that endpoint for use throughoutgraphrag. The changes are primarily contained to._llm.pywhere a new utility function calledget_azure_openai_mini_client_instancecan manually retrieve the environmental variable for"AZURE_OPENAI_MINI_ENDPOINT"and return theAzureOpenAIresult with the fully formed API end point. The default (else) is to return the expected result fromget_azure_openai_async_client_instance. In addition, theazure_openai_complete_if_cachefunction can be modified to switch to calling the new function based on the deployment name being equal to"gpt-4o-mini".