Una volta limitato il modello open source, la prima cosa a fallire è il giudizio di regressione.

Una volta che le restrizioni esterne cadono su un modello open source, la prima cosa che si rompe spesso non è “è ancora possibile scaricarlo?” ma “i risultati di questa volta possono essere visualizzati insieme a quelli dell’ultima volta?” Il nome del modello è ancora lì e l’interfaccia può ancora essere collegata. Ciò che diventa veramente difficile è che la linea di giudizio inizia a deviare: lo stesso insieme di parole immediate, lo stesso lotto di campioni e lo stesso flusso di lavoro, i risultati esauriti non corrispondono più alla stessa distribuzione di comportamento.

Questa cosa sembra semplice sulla carta, ma all’atto pratico diventa molto fastidiosa. Il formato di output precedentemente accettabile improvvisamente ha qualche spiegazione in più, la sequenza di chiamate di funzione precedentemente stabile inizia a cambiare, c’è un ulteriore livello di richieste di policy in alcune aree o la stessa richiesta ottiene lunghezze di contesto diverse sotto ingressi diversi. Ognuno di essi da solo non è un incidente, ma presi insieme confonderanno il giudizio del ritorno.

Ciò che si è rotto per primo è stato il calibro comparativo.

Molti team si concentreranno innanzitutto sui punteggi di riferimento, ma i punteggi sono adatti solo per indicare le capacità approssimative e non sono adatti a spiegare “se il comportamento attuale può ancora essere seguito dal vecchio processo”. Il vero punto in cui andare online non è che il modello venga eseguito da solo, ma che funzioni insieme al parser, alle chiamate agli strumenti, ai nuovi tentativi, alla memorizzazione nella cache, al controllo e al routing. Finché uno dei collegamenti cambia calibro, il punteggio perderà il suo significato di riferimento.

La situazione più tipica è che non si riscontrano problemi nel set di valutazione, ma la catena inizia a staccarsi online. I campioni di prova sono sufficientemente puliti e il modello risponde molto bene alle domande. Tuttavia, una volta ricevuto l’input reale, una piccola quantità di deriva del campo può influenzare i successivi passaggi automatizzati. Il risultato sembra “il modello può ancora essere utilizzato”, ma in realtà significa “il metodo di confronto ha fallito”.

La linea di base deve essere salvata in base al flusso di lavoro

Per eliminare tali modifiche, non ci basiamo sull’esecuzione di più cicli di elenchi, ma sul trasformare la base in un flusso di lavoro riproducibile. L’input deve avere una versione, l’output deve avere uno schema, la risposta dello strumento deve essere riproducibile e i campioni non riusciti devono mantenere il contesto originale. Solo così, dopo essere passati ad altri modelli, ad altre regioni e ad altre strategie, possiamo sapere se la deviazione risiede nel modello stesso o nei collegamenti anteriori e posteriori.

Questo tipo di linea di base ha soprattutto paura di memorizzare solo un punteggio e una conclusione. I punteggi serviranno a confortare le persone, le conclusioni serviranno a scrivere resoconti, ma mancano i dettagli veramente utili. Una volta inasprite le restrizioni, il team può solo ricostituire i campioni, ricaricare il calibro e riempire i limiti anomali, il che equivale a suddividere il lavoro di confronto che avrebbe potuto essere completato in una volta sola in diversi cicli di rielaborazione.

Il vero costo della migrazione è ristabilire la fiducia

Una volta limitato il modello, l’azione di migrazione sembra trasformarsi in un elemento disponibile, ma in realtà sta ristabilendo la fiducia che “questo processo è relativamente stabile”. La fiducia non si costruisce con una chiamata andata a buon fine, ma con una serie di risultati comparativi che possono essere verificati ripetutamente. Senza questa serie di risultati, sarebbe eseguibile solo temporaneamente se tornassimo al passato; con questa serie di risultati, se tornassimo al passato, rientreremmo nell’intervallo controllabile.

Questo è il motivo per cui alcune squadre hanno completato il ricambio in superficie, ma internamente devono ancora aspettare molto tempo prima di osare aumentare la propria capacità. Ciò che è realmente bloccato non è l’azione di accesso, ma a cui nessuno osa rispondere: se i confini più importanti del vecchio processo siano ancora validi nel nuovo modello. Finché a questa domanda non viene data una risposta chiara, qualsiasi affermazione secondo cui “la migrazione è stata completata” è solo una dichiarazione messa in scena.

Vale la pena ricostruire solo le parti adatte al test

Non tutti gli scenari sono meritevoli di rendere la catena di regressione così pesante. Conversazioni ad hoc, generazione leggera e riepiloghi una tantum hanno confini vaghi e la costruzione eccessiva è una perdita di tempo. Ma non appena il modello inizia a partecipare alla generazione del codice, all’estrazione delle informazioni, alle decisioni di routing e all’esecuzione degli strumenti, il giudizio sulla regressione non è più un accessorio, ma una parte del flusso di lavoro.

I vincoli esterni possono amplificare questa differenza. Se possa continuare ad essere utilizzato di solito è solo lo strato più superficiale; ciò che determina realmente se la squadra può essere stabile è se esiste un metodo stabile per confrontare i nuovi risultati con la vecchia linea di base per il confronto. Una volta stabilito il confronto, la migrazione è solo un problema di ingegneria; una volta fallito il confronto, tutti i giudizi successivi cominceranno a vacillare.