Proposal: Unified Provider Configuration Management

[DAAE-Na-Yunchae]

Provider Configuration Enhancement

Is your feature request related to a problem? Please describe.
There are two main issues with the current configuration management:

1. Another provider (Azure OpenAI) settings are scattered between environment variables and config override files, making management complex.
2. The JSON-based configuration approach lacks type safety and flexibility.

Describe the solution you'd like

I propose two possible improvements:

ex1) Unified Azure OpenAI Configuration:

{
    "AZURE_OPENAI": {
        "API_VERSION": "2024-08-01-preview",
        "ENDPOINT": "your-endpoint",
        "API_KEY": "your-api-key"
        "EMBEDDING": "azure_openai:embedding-3-large"
    },
    "RETRIEVER": "tavily",
}

ex2) Type-safe Functional Configuration Approach:

@dataclass
class AzureOpenAIConfig:
    api_version: str
    endpoint: str
    api_key: str

@dataclass
class AppConfig:
    azure_openai: AzureOpenAIConfig
    retriever: str
    embedding: str
    # ... other settings

def configure_app(config: AppConfig) -> None:
    pass

Describe alternatives you've considered

1. Maintaining the current environment variables approach
2. Creating a separate Azure OpenAI configuration file
3. Using the Builder pattern for configuration setup

Additional context

Benefits of the functional approach:

• Type safety and IDE autocompletion
• Configuration error detection before runtime
• Easier dependency management between settings
• Improved testability
• Gradual adoption possible for backward compatibility with existing configuration methods

[ElishaKay]

Welcome @DAAE-Na-Yunchae

Sounds interesting

Happy to see the PR for what you have in mind

Also looping in @kga245 who laid the groundwork for the JSON config files & @danieldekay who's been polishing the Azure OpenAI support as we go