Quando una richiesta riuscita è comunque un fallimento
Immagina di parlare con lo stesso personaggio da settimane. La sua voce è familiare, la lingua è coerente e le risposte sembrano brillanti e vive.
Poi, senza cambiare né personaggio né modello, qualcosa comincia a non tornare.
La risposta successiva impiega dieci secondi per iniziare. Una funzione che dipende dall’output strutturato smette improvvisamente di funzionare. Il personaggio comincia a divagare, inserisce frammenti di un’altra lingua o risponde con uno stile che sembra appartenere a un modello molto più debole.
Dal punto di vista del server, nulla è fallito. L’API ha restituito 200 OK, i token sono arrivati e la richiesta è stata fatturata.
Dal punto di vista dell’utente, il modello è appena peggiorato.
È per colmare questa distanza che abbiamo costruito per Reverie un sistema di sonde canary e quarantena delle rotte per provider.
Un nome di modello, molti ambienti di inferenza
OpenRouter è il nostro gateway principale per i modelli. Uno dei suoi punti di forza è che un singolo modello può essere servito da molti provider di inferenza indipendenti. Se uno non è disponibile, un altro può accettare la richiesta. Otteniamo così più capacità, prezzi competitivi e maggiore resilienza rispetto alla dipendenza da un solo endpoint.
Ma nasce anche una variabile invisibile.
Il nome del modello può restare identico mentre l’infrastruttura che lo esegue cambia da una richiesta all’altra. Ogni provider può usare un motore di inferenza, una configurazione hardware, un livello di quantizzazione, un parser, un template di chat, una coda o un ulteriore livello di policy differente.
La documentazione sul routing dei provider di OpenRouter spiega che il routing predefinito considera disponibilità recente e prezzo, mantenendo altri provider come fallback. Sono segnali importanti, ma un endpoint può essere online, economico e produrre comunque un risultato inaccettabile per un prodotto specifico.
OpenRouter ha anche parlato pubblicamente delle differenze misurabili tra provider che servono lo stesso modello. In teoria, gli stessi pesi alla stessa precisione dovrebbero comportarsi in modo simile. In produzione, eseguire un modello di grandi dimensioni è complesso e le differenze emergono.
Cosa intendiamo per “degrado del modello”
“Degrado del modello” non è un’unica diagnosi standardizzata e non significa automaticamente che un provider abbia sostituito intenzionalmente il modello con uno più piccolo.
Usiamo il termine in senso operativo: un endpoint di inferenza è degradato quando non conserva più il comportamento, le capacità o le prestazioni interattive che ci aspettiamo dal modello richiesto su prompt rappresentativi, anche se la richiesta risulta tecnicamente riuscita.
Per Reverie, le forme più evidenti sono:
- Degrado della latenza: la connessione riesce, ma il tempo al primo token è abbastanza lungo da spezzare la sensazione di una conversazione dal vivo.
- Degrado delle capacità: un endpoint che dovrebbe supportare output strutturati restituisce testo malformato o smette di rispettare lo schema.
- Degrado comportamentale: le risposte diventano corrotte, incoerenti, inaspettatamente ripetitive o passano chiaramente a un’altra lingua.
- Incompatibilità di policy: un host aggiunge il proprio livello di filtro, trasformando una scena supportata da Reverie in un rifiuto, una risposta vuota o un testo troncato.
Le cause possibili sono molte. La quantizzazione a precisione inferiore può danneggiare i prompt difficili, come indicano sia la documentazione di OpenRouter sia le ricerche pubblicate sulla quantizzazione. Ma non è una spiegazione universale: bug del motore di inferenza, parser degli strumenti, errori del tokenizer o del template di chat, code sovraccariche e middleware del provider possono essere altrettanto importanti. OpenRouter ha osservato che, nelle chiamate agli strumenti, i parser causano spesso più variazioni della sola precisione.
La domanda importante non è “quale causa sembra più sospetta?”, ma “possiamo isolare l’endpoint e riprodurre il problema?”.
Due casi che hanno reso concreto il problema
Per noi non era una preoccupazione teorica.
In un confronto fissato su singoli provider, uno di essi ha corrotto l’inizio di 19 risposte su 20, inserendo punteggiatura o il frammento di un token estraneo. Sugli altri quattordici host dello stesso modello, il problema si è verificato 0 volte in 49 risposte. Nel roleplay, dove il primo carattere è spesso un marcatore Markdown di enfasi, un solo byte anomalo poteva rompere anche la formattazione dell’intera risposta.
In un altro test, un endpoint ha prodotto una grave mescolanza di portoghese e spagnolo in 3 generazioni su 3. Lo stesso prompt è rimasto in portoghese sull’host ufficiale del modello e sugli altri provider testati della stessa classe di precisione. “Il modello è semplicemente incoerente” non era più una buona spiegazione: il difetto seguiva l’endpoint.
Questi guasti sono difficili da individuare perché non generano necessariamente eccezioni. Il monitoraggio tradizionale vede un’API sana. L’utente vede un personaggio che all’improvviso non sa più parlare correttamente.
La nostra risposta: testare ogni rotta, non solo il modello
Ogni trenta minuti, il nostro canary rileva i provider attivi che servono il modello di chat predefinito di Reverie. Invia poi a ciascuno un piccolo gruppo di richieste sintetiche, fissate esclusivamente su quel provider e con i fallback disattivati.
Fissare la rotta è essenziale. Se una sonda può usare il fallback, un secondo provider sano può nascondere il problema del primo. Dobbiamo sapere esattamente quale ambiente ha prodotto il risultato.
Il sistema verifica quattro contratti mirati e valutabili dal codice.
1. Tempo al primo token
In una conversazione in streaming, il throughput è solo metà dell’esperienza. Il primo token determina per quanto tempo l’utente guarda un indicatore di caricamento.
Lo misuriamo direttamente nello stream. Un provider che non produce testo entro dieci secondi fallisce la sonda di latenza. La soglia è intenzionalmente generosa e un solo round lento non basta per rimuovere un host: la pressione temporanea sulle code può accadere.
2. Filtri e rifiuti silenziosi
Inviamo una continuazione di roleplay fissa, rappresentativa del traffico supportato da Reverie. La sonda controlla il motivo di conclusione, i pattern di rifiuto ad alta confidenza e gli output vuoti.
Eseguiamo il test anche contro host noti per il filtraggio, usandoli come controlli positivi. Se un controllo passa inaspettatamente, non dichiariamo sani tutti gli altri provider: segnaliamo che la sonda stessa è diventata debole. Un test che non rileva più il suo errore noto non dimostra nulla.
3. Output strutturato
Richiediamo un piccolo oggetto con schema fisso e validiamo il risultato. Un errore di trasporto e un output malformato vengono trattati diversamente: una connessione interrotta indica che il provider era irraggiungibile; una generazione completata che non rispetta lo schema è prova di una regressione di capacità.
“L’endpoint dichiara di supportare il parametro” e “l’endpoint lo rispetta in modo affidabile” non sono la stessa promessa.
4. Integrità linguistica
Reverie supporta 17 lingue dell’interfaccia, quindi uno smoke test solo in inglese non rileverebbe alcuni problemi che i nostri utenti incontrano davvero.
Il canary ruota tra le lingue supportate usando prompt sintetici di roleplay. Un rilevatore locale e deterministico cerca un cambio netto della lingua dell’intera risposta, una mescolanza linguistica prolungata e corruzioni evidenti della codifica. Non usa conversazioni reali e non chiede a un altro modello un giudizio soggettivo.
Un output ambiguo o troppo breve è inconcludente, non un fallimento. Quando viene rilevata un’anomalia linguistica, il canary esegue subito altri due tentativi e richiede una maggioranza. La stessa lingua viene ripetuta nel round successivo, così il provider non può evitare la regola dei round consecutivi solo perché la rotazione è avanzata.
Un sistema progettato per dubitare delle proprie conclusioni
Rimuovere automaticamente capacità di inferenza è utile, ma un falso positivo può provocare un’interruzione più grave del difetto iniziale. Per questo il canary ha diversi freni:
- Gli errori di trasporto non contano come problemi di qualità. Timeout, rate limit e risposte 5xx congelano il punteggio invece di far avanzare una serie verso la sospensione.
- Un round negativo non basta. Un provider deve fallire due round consecutivi eseguiti ogni mezz’ora.
- Osservazione e applicazione sono separate. Possiamo eseguire l’intero sistema in modalità osservazione, registrare quali host verrebbero sospesi, avvisare gli amministratori e misurare i falsi positivi prima di attivare le azioni automatiche.
- La capacità ha una soglia minima. Il canary non sospende un provider se questo lascerebbe meno di due host di produzione. Avvisa invece un amministratore.
- Anche il recupero viene testato. I provider sospesi continuano a ricevere sonde. Due round puliti consecutivi ripristinano anticipatamente un host.
- I problemi ripetuti aumentano gradualmente la durata. La prima sospensione dura un giorno, la seconda tre e le successive sette. Dopo quattordici giorni senza una nuova sospensione, lo storico perde peso e la scala riparte.
L’obiettivo non è punire i provider. È allontanare il traffico degli utenti da una rotta il cui malfunzionamento è riproducibile, mantenendo un percorso chiaro per il rientro quando il problema viene risolto.
Tre livelli di protezione
La decisione finale di routing combina tre tipi di esclusione:
- Esclusioni integrate e sottoposte a revisione per difetti o incompatibilità di policy già misurati e che non vogliamo reintrodurre per errore.
- Esclusioni operative per incidenti che un amministratore può aggiungere subito, senza attendere un nuovo deploy.
- Sospensioni temporanee del canary per i provider che superano la soglia automatica di errore.
Questi elenchi vengono uniti nella preferenza provider.ignore di OpenRouter quando Reverie costruisce una richiesta. L’utente non deve riprovare finché il caso non sceglie un provider migliore: la rotta problematica viene rimossa dai candidati.
Ogni decisione automatica viene registrata, gli amministratori ricevono notifiche nelle transizioni importanti e una sospensione può essere rimossa manualmente quando necessario.
Cosa garantisce il sistema — e cosa non garantisce
Il canary è volutamente circoscritto. Il codice può giudicare latenza, validità dello schema, filtri ad alta confidenza, integrità linguistica e codifica. Non pretende di assegnare un voto a quanto un personaggio sia divertente, emotivamente perspicace o fedele a una personalità complessa.
Queste domande più ampie richiedono ancora valutazioni basate su prompt rappresentativi, revisione umana, telemetria di produzione e, soprattutto, segnalazioni degli utenti.
Il sistema non significa nemmeno che ogni risposta strana provi un degrado. I modelli generativi sono probabilistici. Una conversazione lunga può accumulare contesto contraddittorio e la definizione di un personaggio può contenere istruzioni in conflitto. A volte una risposta strana è soltanto una risposta strana.
Ciò che cambia è che “è lo stesso modello” non conclude più la nostra indagine. Ora possiamo isolare la rotta, riprodurre errori oggettivi e tenere lontano il traffico successivo.
Affidabilità significa preservare l’esperienza
Il routing multi-provider rimane prezioso. Offre a Reverie la capacità e la resilienza per mantenere disponibili le conversazioni quando singoli endpoint non funzionano.
Ma la resilienza non è soltanto ricevere una risposta HTTP. Una risposta che inizia troppo tardi, perde la struttura richiesta, rifiuta contenuti supportati o cambia improvvisamente lingua non è sana solo perché la fattura indica che la richiesta è riuscita.
Per un prodotto di personaggi AI, l’affidabilità ha un significato più umano: il personaggio deve continuare a sembrare lo stesso personaggio, qualunque macchina stia parlando al suo posto.
È questo lo standard che le nostre nuove protezioni di routing sono state create per difendere.
Se noti un cambiamento improvviso nella qualità o nella lingua delle risposte, inviaci una segnalazione con il nome del modello e l’orario approssimativo. Queste informazioni ci aiutano a collegare ciò che hai visto alla rotta esatta che lo ha prodotto.