Ensure the -best model points to the appropriate language model

[stephan-buckmaster]

Added new method LanguageModel#effective_api_name. When the api_name of a LanguageModel ends in -best this method looks up the language model of its APIService that has the best flag set.

1. I don't think the Export class needs to resolve the (new) effective_api_name.
2. The Export functionality seems the only where the Assistant code references api_name. So no need to change the Assistant model code.
3. Added comment about the language model Test link (such a nice feature) that it should also take into account the API Service (File app/controllers/settings/language_models_controller.rb)

Fixes issue #592

[krschacht]

I reviewed this PR but I'm torn with regards to the implementation. The challenge with replacing all the api_name calls with effective_api_name is that we're not fully replacing this "virtual" language_model with the resulting language_model that we want it to act like. So code that references any other attributes of this language_model will potentially get wrong info (e.g. cost per token and flags like supports_image).

My first thought was: can we make the call to .language_model somehow recognize that it's a special "virtual/pointer/best" model and actually return the model that we want it to act like. But since language_model is an association, I couldn't figure out an appropriate way to hook in there.

So then I was thinking that we could let language_model be the virtual one, but within it, any call to any attribute would do a lookup of the actual best: true model and return that attribute instead. But @attributes is an ivar, not a method, and I couldn't figure out an elegant way to tap into that and intercept any attempt to reference an attribute.

I see how you ended up where you did. I can't think of a better solution. But I worry that this solution will be too brittle. There may already be subtle bugs in the code for places where we aren't using the correct language_model attribute. I don't have a good idea for how to resolve... I'm stuck... :)

[stephan-buckmaster]

I don't know, this seems to get very general. How often does the "best" of today change features compared to the "best" of yesterday?

[krschacht]

The more I think about it, I think the better change would be to remove support for any magical "best" model. For example, I can't objectively say which is the "best" OpenAI model these days. 4o is better in some ways and o3 is better in other ways and o1 is better in yet other ways.

These LLMs are really weird animals. Considering the technical complexity that "best" introduces plus the ambiguity around it, I think it was a mistaken feature.

Would you be up for reverting your work and instead:

• Remove the best column from the database with a migration and remove it from the UIs
• Make sure there is no lingering logic that tries to substitute one model for another?

I'm hoping it's actually fairly easy to back out this feature. Whereas if we really lean into it, we're introducing a lot of hacks throughout the code for a win that might not even be a win. :)