Back home

Una volta reso pubblico il modello open source, ciò che è veramente fragile è il percorso predefinito

Solo perché il modello può ancora essere scaricato non significa che l'ingresso predefinito sarà sempre disponibile.

Poni la domanda: “Gli Stati Uniti possono essere sigillati?” e la risposta è solitamente meno drammatica. I file di peso non scompariranno necessariamente dal mondo, ma i percorsi predefiniti possono essere facilmente sovrascritti. Finché si utilizzano naturalmente un indirizzo hub, un valore predefinito dell’SDK e un ingresso per l’inferenza online, l’automazione successiva sarà fragile.

Inizia da un indirizzo

Il modello open source è iniziato semplicemente come un indirizzo. Tirare, valutare, schierare, restituire, tutte le azioni puntano allo stesso ingresso. Quando il controcorrente non cambiava, questo percorso sembrava “liscio” e perfino naturale; quando l’upstream è cambiato, mi sono reso conto che ciò su cui facevo affidamento non era la capacità del modello, ma il percorso predefinito.

Il punto di interruzione più comune nel progetto non è “impossibile ottenere il modello”, ma “riesce ancora a ottenerlo, ma non quello originale”. La sincronizzazione del mirror è lenta, gli alias vengono cambiati, l’accesso regionale è limitato, la versione predefinita viene spostata, ma lo script è ancora in esecuzione al vecchio indirizzo. L’ontologia del modello esiste ancora, ma il processo ha cominciato a deviare.

L’errore si verifica prima nell’automazione

Non è difficile cambiare immagine manualmente, ma la difficoltà è che l’automazione non lo capisce da sola. CI, valutazione pianificata, costruzione di contenitori, record di esperimenti, esempi di documenti e script locali di colleghi possono tutti copiare lo stesso valore predefinito. Finché non cambierà nulla, il vecchio ingresso continuerà ad apparire.

Questo è anche il luogo in cui il termine “sigillo” è più fuorviante. Il vero cambiamento spesso non è che i pesi vengano cancellati, ma che i valori predefiniti vengano riscritti. Sembra ancora lo stesso nome dall’esterno, ma l’ingresso, la versione e le dipendenze sono state modificate all’interno. Per gli esseri umani, questo è solo un cambiamento; per l’automazione si tratta di un’ampia deriva comportamentale.

Il peso può essere spostato, ma il valore predefinito non può essere spostato.

Un vantaggio importante del modello open source è che i pesi possono essere copiati, sottoposti a mirroring, biforcati e salvati offline. Il problema è che viene copiato il file, non il percorso predefinito. Finché il consumatore continuerà a considerare un certo ingresso esterno come l’unica verità, non importa quanto aperto sia il peso, il metodo operativo sarà comunque influenzato da regole esterne.

Ciò che è ancora più problematico è che questa modifica potrebbe non causare necessariamente un errore immediato. Molte volte sembra che possa ancora funzionare, ma i risultati sono diversi: un set di valutazioni è stato passato sullo specchio A e un altro set è stato scosso sullo specchio B; una versione è disponibile localmente, ma diventa un altro set di patch quando raggiunge la pipeline; sotto lo stesso nome di modello, il comportamento reale ha cominciato a divergere.

Qui occorre distinguere due cose. Il problema della supply chain è più simile alla gestione dei file e alla gestione delle versioni, mentre il problema del routing predefinito è più simile al processo decisionale in fase di esecuzione. Il primo si preoccupa se esiste un backup e il secondo si preoccupa di quale percorso dovrebbe intraprendere per primo la richiesta. Finché il valore predefinito viene scritto esternamente, le azioni esterne possono sovrascrivere direttamente il flusso di lavoro.

Ciò che deve essere integrato è il percorso pin, mirror e fallback.

I rimedi non sono complicati, ma poche persone li considerano la prima priorità.

La versione dovrebbe essere fissata a un commit, un hash o un rilascio clear specifico e non fare affidamento su nomi come latest che possono andare alla deriva per molto tempo. È meglio mettere insieme pesi, tokenizzatori, configurazioni e immagini di inferenza nel magazzino interno, almeno per garantire che possano essere ricostruiti quando la rete viene disconnessa. L’ingresso predefinito deve avere un percorso di fallback e non può avere un solo indirizzo online. Anche i campioni di valutazione e i vecchi risultati devono essere conservati in archivio, altrimenti non si capirà nemmeno “quanto è cambiato”.

Queste cose sembrano tutte dettagli di funzionamento e manutenzione, ma in realtà stanno riprendendo il controllo dalle impostazioni predefinite esterne. Senza questo livello di chiusura, l’open source porterà solo “apparenza di libertà” ma non “effettiva controllabilità”.

Dopo che il modello open source è stato reso pubblico, ciò che è veramente fragile non è il peso in sé, ma il percorso predefinito. Finché l’ingresso è ancora controllato dai valori predefiniti di altre persone, il flusso di lavoro sarà comunque scosso quando il modello verrà riaperto.

FAQ

What to read next

Related

Continue reading