Dopo che il modello open source cinese sarà limitato, la prima cosa da aumentare sarà il costo della verifica.

Dopo che i modelli open source sono stati limitati, la prima cosa che diventa costosa di solito non è il modello stesso, ma la verifica. Se il modello possa ancora essere abbattuto è solo il primo strato; dopo che è stato rimosso, se il formato di output, la chiamata dello strumento, la politica di rifiuto, la lunghezza del contesto e i parametri di campionamento possono ancora essere allineati con la vecchia versione determinerà se il sistema continuerà a essere stabile.

Quello che sembrava un problema di fornitura si è trasformato in un problema tecnico per il team. Una volta che un modello entra nel processo, al livello di accesso raramente viene lasciato solo un indirizzo API. Le parole di richiesta, lo schema, i tentativi, i timeout, le posizioni di troncamento e le sequenze di chiamate agli strumenti diventeranno gradualmente premesse implicite. Quando la versione sarà stabile queste premesse potranno essere supportate dall’esperienza; quando il modello è limitato, l’immagine è biforcuta o le prestazioni della versione con lo stesso nome vanno alla deriva, l’esperienza comincia a fallire. La prima cosa che perde il suo effetto è spesso il giudizio di regressione, perché il set di test dice al sistema solo ciò che non è rotto e non può dire direttamente cosa è cambiato.

Il presupposto predefinito è che verrà legato e restituito per primo.

In passato, un gruppo di casse d’oro poteva funzionare a lungo. Nella maggior parte dei casi, si limitavano a verificare se l’output avesse evidentemente deviato. Il modello è fisso e anche la parola del prompt è fissa. Per impostazione predefinita, tutti visualizzeranno “questo collegamento è stato verificato”. Non appena compaiono le restrizioni, questa impostazione predefinita inizia a crollare. I modelli possono cambiare regione, immagine o versione e anche i modelli con lo stesso nome potrebbero comportarsi in modo diverso in periodi di tempo diversi. In questo momento, la regressione non consiste più nel giudicare se può essere utilizzata, ma nel giudicare su quale livello ricade il cambiamento e se vale la pena cambiare il valore del cambiamento.

La distribuzione e il rollback amplificheranno i piccoli cambiamenti

Dopo che il modello è stato limitato, le prime cose da fare sono il download, il mirroring, l’approvazione, il controllo e il rollback. In superficie, cambia semplicemente in un modello disponibile. Infatti aggiunge il blocco della versione, la sincronizzazione della cache, il controllo dei permessi e il failover. Finché la distribuzione dei modelli non avrà un livello indipendente, l’azienda riporterà queste attività al proprio ritmo di rilascio. Il risultato spesso non è “fare più adattamenti”, ma il contratto di input e output deve essere riconfermato ogni volta che viene aggiornato.

La prima cosa che il livello neutro disattiva non è l’abilità del modello.

Ciò che realmente dovrebbe essere separato di solito non è il modello stesso, ma lo strato di confini neutri attorno al modello: modelli di parole di prompt, verifica dello schema, strategie di instradamento, logica dei tentativi, log e valutazioni. Mettere insieme queste cose non significa perseguire l’ordine, ma consentire che i cambiamenti ricadano prima sullo stesso insieme di contratti. Il modello può essere sostituito, l’input e l’output non possono andare alla deriva e la linea di base della regressione non può disperdersi. Una volta stabilito il livello neutro, molti comportamenti predefiniti originariamente ricordati attraverso l’esperienza diventeranno cose che possono essere confrontate, ripristinate e riprodotte.

Non vale la pena eseguire prima questo livello per tutti i progetti.

Sono sufficienti abstract una tantum, esperimenti interni, script di breve durata, direttamente collegati al modello. Ciò che necessita di un livello neutrale è uno scenario in cui il modello ha iniziato a partecipare al giudizio sulla produzione e c’è un’alta probabilità che il fornitore o la regione cambieranno in seguito. Per questi sistemi, il vero problema non è mai scrivere qualche riga in più di adattamento, ma che i comportamenti originali di default non siano marcati esplicitamente. Senza questo strato, ogni volta che si cambia modello, sarà necessario ricalcolare nuovamente il ritmo di restituzione, distribuzione e rilascio.

Il cosiddetto sigillo spesso rimborsa immediatamente al team i costi di verifica, distribuzione e ripristino originariamente risparmiati. I modelli cambiano e i collegamenti non possono essere stabilizzati per fortuna. Dobbiamo smontare il collegamento di verifica prima di poter discutere se il modello può continuare a essere utilizzato.