I rischi del modello open source ricadono innanzitutto sul livello di accesso

Nei giorni scorsi si è discusso se i modelli open source rimarranno bloccati dalle politiche restrittive degli Stati Uniti. La prima cosa che cambia nell’ingegneria non sono le capacità del modello, ma l’accessibilità predefinita. Il modello è ancora lì, così come i documenti. Ciò che veramente trema per primo sono l’indirizzo pull, la fonte mirror, la piattaforma di hosting, i termini di licenza e la disponibilità regionale. La prima cosa che spesso incontrano le persone che hanno accesso al lavoro non è “il modello non è abbastanza forte”, ma “possiamo ancora ottenerlo stabilmente oggi?”

Innanzitutto peggiora la raggiungibilità predefinita

In passato, il problema più fastidioso durante l’accesso al modello era “lo stesso modello poteva essere scaricato ieri, ma oggi improvvisamente ha ricevuto un 403”. Questo tipo di modifica sembra una piccola fluttuazione nella catena di fornitura, ma in realtà trascina l’intero collegamento in uno stato instabile: è necessario ritentare il download del peso, cambiare l’origine dell’immagine, ricalcolare il checksum, riconfezionare l’immagine di distribuzione e anche la cache nel CI diventerà non valida. In apparenza, solo la fase di acquisizione del modello è resa fragile, ma in realtà la premessa di “usabilità” viene eliminata dal sistema.

Il modello open source è spesso inteso come “una volta che il codice sarà open source, non sarà più controllato da altri”. Questa frase è corretta solo a metà. Il codice open source non significa che sia accessibile per impostazione predefinita, ed essere visibile nel magazzino non significa che l’ambiente di produzione possa essere avviato stabilmente. Chi lo ospita, in quale regione esiste, se la licenza è cambiata e se ci sono restrizioni sulla frequenza di download. Una volta che questi dettagli vengono bloccati dalla piattaforma, dalle politiche o dai termini commerciali, ciò che il team vede non è “il modello scompare”, ma “le cose che erano facilmente disponibili iniziano a diventare un’infrastruttura che deve essere mantenuta”.

L’interfaccia del modello verrà ampliata fino ai confini del sistema

In passato, quando scrivevo tutti i dettagli nel routing del modello, la cosa più difficile da raccogliere non era che il punteggio fosse inferiore di due o tre punti, ma che l’interfaccia del modello non fosse sufficientemente stabile. Una volta sostituita una base, le abitudini di prompt, la struttura di output, il formato di chiamata dello strumento e il comportamento del contesto lungo cambieranno di conseguenza. Il nome del modello sembra non essere cambiato, ma il parser, il set di valutazione, il registro di riproduzione e la gestione degli errori nel sistema devono essere rieseguiti. Ciò che in quel momento fu più facilmente scoperto fu che il sistema scambiava “un certo modello” per “una certa abilità”.

Questa è anche l’area più trascurata nelle discussioni relative ai modelli open source. Ciò che è veramente prezioso non è il nome in sé, ma l’insieme di funzionalità sostituibili che può fornire: completamento, classificazione, estrazione, dialogo, chiamata di strumenti, riepilogo di articoli lunghi e generazione di codice. Finché il livello di accesso lega queste funzionalità a modelli specifici, qualsiasi modifica successiva verrà amplificata in costi di migrazione. Se invece lo strato di interfaccia viene prima condensato in un contratto stabile, la base può essere sostituita come una dipendenza e il rischio sarà limitato solo in misura limitata.

Routing e fallback sono più importanti dei nomi

Indipendentemente dal fatto che il modello open source sarà “sigillato” o meno, l’impatto sul sistema finale di solito non è il nome del modello, ma se esiste una via d’uscita. Se un team affida tutte le attività su un unico modello remoto, qualsiasi restrizione geografica, restrizione di accesso o cambiamento nelle strategie aziendali causerà direttamente l’interruzione dell’attività. Al contrario, finché sono presenti modelli eseguibili localmente, fonti di hosting di backup, pool di modelli con diversi livelli di capacità e set di valutazione riproducibili, le limitazioni esterne aumenteranno nella migliore delle ipotesi i costi di cambiamento e non renderanno immediatamente il sistema non disponibile.

Pertanto, quando si esprimono giudizi a livello di modello, è meglio non chiedersi semplicemente “quale modello è più forte”, ma anche chiedersi “questa catena di capacità può essere sostituita con una base?” I pesi possono essere conservati in un magazzino controllabile? Le dipendenze possono essere bloccate in versioni fisse? Il routing, la memorizzazione nella cache, la riproduzione e il rollback possono essere integrati in un insieme completo di azioni? Queste domande sono più vicine al confine reale rispetto al nome del modello. Il rischio che il modello venga limitato non scomparirà per primo, ma cambierà prima la raggiungibilità predefinita; e ciò che il sistema deve mantenere non è mai un modello, ma un insieme di capacità che possono essere continuamente fornite.