Feature? Add llm.yml

[MadBomber]

I'm not sure if this is a feature for the gem or something that the application needs to handle. The idea is that not every template has to use the same RubyLLM configuration. One template could be targeted to xAI while another to Ollama; within a template there may be different temperature, top_p etc. depending on the environment us classic rails database.yml style.

I'm going to explore this idea from the application side and will report back here.

[danielfriis]

I think it may definitely be a feature for this gem! Great idea! I suggest having a configuration.yml file in the same folder as the other prompts.

[MadBomber]

I've been trying to figure out where within the RubyLLM configuration sports it might hook. There are three areas:

1. global. The is things like API key, base url for the provider it is not a support one for example local providers which are OpenAI API compliant.

2. model specific using RubyLLM.chat.with_model(...)`

3. prompt specific using RUbyLLM.chat.with_parameters(...)

One of the things to watch out for in RubyLLM is that the API has two defined parameters that mean the same thing but have different names depending on which RubyLLM config process is used: chat(assume_model_exists: true). and chat.with_model(assume_exists: true)`

I am currently experimenting at the application level with a nested configuration file that uses myway_config. The three sections I have defined in that config file format are:

ruby_llm:
  item: value
with_model:
  item: value
with_params:
  item: value

This makes the author do the work of specifing where the config items should be placed.

So far I've only considered the simple text part of the completions process.

This config file also needs to ERB enabled.

[MadBomber]

For compatibility with Rails (or any other framework that has environments) this 3 section YAML file needs to include an environment layer.

defaults:
  ruby_llm:
    item: value
  with_model:
    item: value
  with_params:
    item: value
production:
development:
test:

Since the defaults are nested we need to do the deep merge inside of Ruby.