Add fallback model

[GregoireGaonach]

Hi!

AI providers are not always stable and can often fail. To avoid the user request actually returning an error, one option would be to use a try and catch pattern and switch providers.

However, this could quickly become cumbersome and repetitive:

try {
    return Prism::text()
        ->using(Provider::Anthropic, 'claude-3-sonnet')
        ->withSystemPrompt(view('prompts.system'))
        ->withPrompt('Explain quantum computing to a 5-year-old.')
        ->asText();
} catch ($e) {
    Log::error('Anthropic model not available, falling back to OpenAI.');

    try {
        return Prism::text()
            ->using(Provider::OpenAI, 'gpt-4o')
            ->withSystemPrompt(view('prompts.system'))
            ->withPrompt('Explain quantum computing to a 5-year-old.')
            ->asText();
    } catch {
        throw new Exception('No available models: ' . $e->getMessage());
    }
}

Proposal:

Prism::text()
    ->using(Provider::Anthropic, 'claude-3-sonnet')
    ->fallback(Provider::OpenAI, 'gpt-4o')
    ->withSystemPrompt(view('prompts.system'))
    ->withPrompt('Explain quantum computing to a 5-year-old.')
    ->asText();

[pushpak1300]

like the idea.

[uchm4n]

What kind of failure are we talking about?
If you send something incorrectly in code (for example model name) this will resolve in Prism exception (Which is clients responsibility), but if you try to chain some result and change the providers based on result then, that would be totally different feature. In this case heaving array of providers make sense:

Prism::text()->using([
       Provider::Anthropic => 'claude-3-sonnet',
       Provider::OpenAI => 'gpt-4o'
    ])
    ->withSystemPrompt(view('prompts.system'))
    ->withPrompt('Explain quantum computing to a 5-year-old.')
    ->asText();

I think this will complicate overall code base a lot. It will add lot of juggling with exceptions and abstractions.

[GregoireGaonach]

I completely agree that the codebase should not be unnecessarily complex, and I actually prefer your API approach.

I was just thinking about catching specific exceptions like "timed out" or PrismProviderOverloadedException errors from the provider, which happen more often than people think.

[ChrisB-TL]

The discussion on #300 is relevant here. This would imply all providers map 1:1 onto each other, which currently they do not.

I personally am not a fan of making them map 1:1 both from a maintenance and DX perspective (difficult to debug or realise what is actually happening).

However, if we did make them all map, I can see this being useful. Or if we went for an dev definable adapter/transformer.