Dopo che il modello open source cinese è stato limitato, la prima cosa da biforcare è la versione e il calibro di valutazione.

Una volta rimosse tali restrizioni, la prima cosa che non funziona di solito è “è ancora possibile scaricarlo?” ma “può ancora basarsi sullo stesso insieme di punteggi?”

Il modello in sé è ancora lì, e il mirroring può essere sincronizzato, ma il problema comincia a spostarsi dall’inizio al confronto. Una versione che funziona bene oggi presenterà lievi differenze su un’altra macchina a causa del peso, della versione del tokenizzatore, dei parametri di inferenza o dei ritardi di mirroring. Basta osservare ogni uscita, sembra che funzioni ancora; una volta reinserita nell’insieme di regressione, la curva inizia ad allargarsi. In passato bastava guardare un punteggio totale per decidere se eseguire l’aggiornamento, ma ora devi prima decomprimere “se questo cambiamento deriva dal modello o dallo stack di servizi”.

Il vero problema causato dalle restrizioni non sta nell’azione di download in sé, ma nella distruzione dei rapporti di confronto. In passato, dovevi concentrarti solo su una versione upstream, ma ora ci sono spesso fonti ufficiali, fonti mirror, cache interne, versioni quantizzate e versioni temporanee di rollback allo stesso tempo. È possibile eseguire ogni riga, ma i risultati non condividono più la stessa linea di base. Una volta che il set di valutazione viene biforcato, il team perderà rapidamente un linguaggio comune: la ricerca e sviluppo afferma che questa versione è stata migliorata e il prodotto afferma che l’esperienza online non è cambiata. Gli addetti alla risoluzione dei problemi devono prima confermare se il modello è cambiato o se è cambiato l’ambiente di inferenza.

La cosa più fastidiosa di questo tipo di forcella è che non si manifesta immediatamente come un malfunzionamento. Il primo giorno il divario tra i due ambienti era solo di 0,3 punti. Il secondo giorno, un certo campione di testo lungo ha cominciato ad andare alla deriva. Dopo aver effettuato il rollback il terzo giorno, ho scoperto che non era possibile riprodurre i vecchi risultati. In questa fase la discussione non riguarda più “possiamo ottenere il modello?” ma “se ciò che otteniamo è la stessa cosa”.

Ciò che dovrebbe essere realmente chiuso per primo non è l’ingresso del download, ma la linea di base. Bisogna definire almeno le seguenti cose:

• L’hash, la versione del tokenizzatore, il metodo di quantizzazione e i parametri di inferenza del file del modello.
• Set di valutazione, parole di richiesta, parametri di campionamento e logica di post-elaborazione.
• Incapsulamento dell’inferenza condiviso dai servizi online e regressione offline per evitare che i due insiemi di implementazioni vadano alla deriva.
• Conserva la vecchia immagine e la linea di base durante il rollback, senza fare affidamento sulla ricostruzione della memoria.

Queste cose possono sembrare banali, ma una volta che l’accesso al modello inizia a essere limitato, è questo livello di banalità che diventa davvero prezioso. Senza di loro, la squadra può solo scommettere sul prossimo aggiornamento con “sembra che questa volta vada bene”; con loro, possono almeno confermare se il problema risiede nel modello, nello stack di inferenza o nel set di dati stesso.

Quindi, quando la questione ricadrà finalmente sul progetto, il giudizio diventerà molto semplice: se il modello sarà ottenibile è solo l’inizio; se lo stesso set di input, lo stesso set di parametri e lo stesso set di campioni possono essere eseguiti continuamente sulla stessa linea determina se può ancora essere utilizzato stabilmente. Finché rimane il calibro comparativo, c’è ancora spazio di manovra nel modello; una volta che il calibro diverge per primo, la successiva sostituzione, il ripristino e la risoluzione dei problemi diventeranno più costosi.