Un router multi-LLM sceglie quale modello può eseguire una richiesta e come reagire quando quel percorso fallisce. La scelta deve rispettare capacità tecniche e regole del cliente prima di confrontare costo e velocità.
In AI Multisite, la documentazione tecnica descrive un wrapper basato su Prism e configurazioni per provider, servizio, sito e account. È una base per gestire più integrazioni. Il comportamento affidabile dipende poi dalle decisioni applicative attorno alla chiamata.
Definire i requisiti della richiesta
Per ogni tipo di lavoro annoterei input accettati, formato di uscita, limite di tempo, eventuali strumenti e destinazioni consentite per i dati. “Generare un testo” può significare preparare una bozza oppure compilare un documento strutturato: i criteri di riuscita cambiano.
La documentazione Prism presenta un’interfaccia comune e rimanda alle capacità dei singoli provider. L’astrazione riduce il codice di integrazione, ma non dimostra che due modelli accettino gli stessi parametri o producano risultati equivalenti.
Eliminerei dalla selezione i candidati che non soddisfano un requisito obbligatorio. Un punteggio complessivo alto non dovrebbe compensare un formato incompatibile o una destinazione dei dati non autorizzata.
Misurare qualità e costo sul compito
Confronterei i modelli su esempi rappresentativi e criteri di accettazione. Un JSON valido può contenere informazioni errate; una risposta ben scritta può omettere un vincolo. Il controllo deve riguardare anche il significato.
Gli output strutturati documentati da Ollama mostrano uno strumento per vincolare la forma. Anche in quel caso, la validazione applicativa deve controllare dati e regole del dominio.
Per il costo includerei tutti i tentativi necessari a ottenere un risultato valido. Il self-hosting ha hardware, energia, manutenzione e capacità occupata: l’assenza di un prezzo API per token non rende il lavoro gratuito.
Progettare i fallback prima dell’errore
Distinguerei errori temporanei, quota, input incompatibile e credenziali non valide. Ripetere la stessa richiesta non risolve automaticamente tutte queste condizioni. I tentativi devono avere un limite e rispettare il tempo totale disponibile.
Un timeout del client non prova che il provider abbia interrotto il lavoro. Il sistema può ricevere una risposta tardiva o sostenere un costo anche se decide di proseguire altrove. Per operazioni con strumenti ed effetti esterni servono controlli aggiuntivi contro le duplicazioni.
Il fallback deve rimanere dentro la lista autorizzata. Se nessun candidato ammesso è disponibile, preferisco uno stato esplicito di attesa o fallimento a uno spostamento silenzioso dei dati verso un servizio diverso.
Separare interazione e lavorazioni differibili
Una richiesta interattiva ha bisogno di un budget di latenza leggibile. Una rielaborazione dell’archivio può usare una coda con altri tempi, purché siano visibili progresso, errori e possibilità di riprendere il lavoro.
Limiterei concorrenza e retry per evitare che un provider in difficoltà riceva un’ondata di nuovi tentativi. La gestione del sovraccarico riguarda anche il client che chiama il servizio, non soltanto il server che risponde.
Per uno stream distinguerei tempo al primo contenuto utile e tempo al risultato completo. Interrompere a metà e ricominciare con un altro modello può produrre un’esperienza incoerente: il comportamento deve essere previsto nell’interfaccia.
Una cache deve rappresentare il contesto
Una risposta riutilizzabile dipende da input, istruzioni, modello, versione dei dati e autorizzazioni. Il solo testo della domanda può non essere una chiave sufficiente.
La somiglianza semantica è ancora più delicata: due richieste vicine possono differire per una data, una negazione o il cliente a cui si riferiscono. Valuterei il riuso soltanto nei casi in cui quei rischi sono controllabili, mantenendo isolamento e scadenza coerenti.
Conserverei nei log modello effettivo, tentativi, motivo del fallback, tempi ed esito della validazione, limitando i dati di contenuto raccolti. La domanda operativa è poter spiegare perché una richiesta ha seguito quel percorso e se il risultato è utilizzabile.