Model Options Support

[tzolov]

With the new ModelOptions mechanism you can set any model-specific configurations on startup or at runtime.

For example: seed, model, temperature, logitBias, topP… in case OpenAIChatClient or num-thread, top-k, num-gpu ... for the OllamaChatClient.

Use the auto-configuration options properties to set the default (e.g. start-up) options common for all model requests.
Example for OpenAiChatClient:

spring.ai.openai.api-key=YOUR_API_KEY
spring.ai.openai.chat.options.model=gpt-35-turbo
spring.ai.openai.chat.options.temperature=0.7

or use the dedicated options builders, to create the options programmatically.

var options = OpenAiChatOptions.builder()
        .withModel("gpt-35-turbo")
        .withTemperature(0.4)
        .withMaxTokens(200)
    .build()
  
var chatClient = new OpenAiChatClient(...).withDefaultOptions(options); // default options common for all request.

var prompt  = new Prompt(messages, options); // request-specific options that override the default such.

var response = chatClient.call(prompt);

NOTE: The runtime options override the default one.

For more information, check the updated openai-chat , and openai-embeddings documentations.

Gradually we will enable the options support to all model clients.
The Azure OpenAI Chat/Embeddings Options PR is underway: #286 and the OllamaChatClient has a partial support.

Following diagram illustrates the data (and processing) flow for all model types:

[tha2015]

I have some concerns regarding Options-related logic. Currently at startup time, a (default) Options is created, and at runtime, a (runtime) Options is created, then some logic will build (native) Options from these two Options using different merge methods.
And the flow is like:

1. Create (native) Options
2. Copy values from (default) Options to (native) Options
3. Copy values from (runtime) Options to (native) Options

I believe that writing logic to merge is error prone especially when copying values from different Options types (e.g. ChatOptionsImpl/PortableFunctionCallingOptions/AzureOpenAiChatOptions) to (native) Options (i.e. ChatCompletionsOptions). Also it is impossible to clear a default value at runtime (i.e. use a null value at runtime instead of a non-null default value).

Can we reconsider how to support portable options (without merging) to avoid these issues? Thanks.