Playbook di fallback multi-modello per API AI affidabili

Punti chiave

Ripeti lo stesso percorso solo per guasti transitori come timeout e risposte 429.

Effettua il failover verso un modello che soddisfi gli stessi requisiti di capacità e di contratto di output.

Imposta un budget massimo di costo e latenza per l'intera richiesta, non per ogni tentativo.

Registra provider, modello, classe di errore, conteggio dei retry e percorso finale per ogni richiesta.

Separa retry e fallback

Un retry invia di nuovo la richiesta allo stesso percorso perché il guasto potrebbe essere temporaneo. Un fallback cambia provider o modello perché il percorso originale non è disponibile o non è adatto.

Trattare entrambe le azioni come un unico ciclo generico di retry rende gli incidenti più difficili da diagnosticare e può moltiplicare i costi senza migliorare il tasso di successo.

Retry: timeout, reset della connessione, risposta 429 o risposta 5xx temporanea.
Fallback: guasto ripetuto del provider, problema di capacità del modello o restrizione di policy.
Stop: richiesta non valida, parametro non supportato o validazione dell'output fallita.

Costruisci una tabella dei percorsi compatibile con le capacità

I modelli di fallback dovrebbero essere raggruppati per capacità, non per brand. Una richiesta visiva non può eseguire il fallback su un modello solo testuale, e un flusso JSON rigoroso non dovrebbe instradare verso un modello che viola regolarmente lo schema.

Modalità di input e output richieste.
Contesto minimo e lunghezza di output.
Supporto per tool calling e output strutturato.
Prezzo e latenza massimi accettabili.

Applica un budget a livello di richiesta

Il budget della richiesta dovrebbe coprire ogni tentativo di retry e fallback. Prima di avviare un altro tentativo, verifica se il budget residuo di latenza e costo può sostenerlo.

const routePolicy = {
  maxAttempts: 3,
  maxLatencyMs: 18_000,
  maxEstimatedCost: 0.12,
  retryOn: [408, 429, 500, 502, 503, 504],
  fallbackModels: ['primary-model', 'quality-fallback', 'fast-fallback'],
};

Misura la qualità del fallback, non solo la disponibilità

Una richiesta che termina con successo può comunque rappresentare un fallimento del prodotto. Traccia la validazione dell'output, il tasso di correzione da parte dell'utente e il completamento del task dopo un evento di fallback.

Dashboard consigliata: successo del percorso, tasso di fallback, latenza p95, costo stimato, tasso di superamento della validazione e punteggio di qualità per modello.

Domande frequenti

Ogni richiesta AI fallita dovrebbe usare un modello di fallback?

No. Parametri non validi, input non supportati e controlli di sicurezza falliti devono interrompersi immediatamente. Il fallback è appropriato quando un altro percorso compatibile può realisticamente completare lo stesso task.

Quanti tentativi di fallback dovrebbe consentire una richiesta AI?

La maggior parte dei flussi interattivi dovrebbe mantenere il totale a due o tre tentativi. Il limite corretto dipende dal budget residuo di latenza, dal valore del task e dal costo stimato.