Dopo che il modello open source è stato limitato, la prima cosa che deve essere indipendente è il livello neutrale del modello.

Una volta che un modello open source inizia ad essere limitato, la prima cosa esposta spesso non è la voce di download, ma i presupposti predefiniti nel codice. Il nome del modello è stato cambiato, ma l’interfaccia è ancora lì, ma il processo aziendale non è più sincronizzato con il vecchio comportamento: formato di output, sequenza di chiamate di funzione, tono di rifiuto, lunghezza del contesto, parametri di campionamento, ognuno di essi può essere visualizzato individualmente, ma impilarli insieme trascinerà l’intero collegamento.

Questo tipo di problema è solitamente difficile da considerare come un problema architettonico. Durante la fase di sviluppo ho visto solo “può funzionare”. Dopo essere andato online, ho scoperto che la selezione del modello era già stata scritta nella logica aziendale. Alcuni campi si adattano solo a un formato di ritorno, alcuni tentativi riconoscono solo un metodo di rifiuto e alcune eccezioni di fallback vengono impostate automaticamente sul modello originale per fornire una spiegazione più lunga. Una volta imposte le restrizioni, tutti questi cumuli nascosti furono scoperti.

Il comportamento predefinito collegherà il modello all’azienda

Nella fase di accesso, il modello viene spesso considerato come l’aggiunta di un SDK, la connessione di un’API e l’aggiunta di una parola di richiesta. Dopo la connessione, la cosa più difficile da ripulire non è la chiamata in sé, ma i rami che sono cresciuti attorno al comportamento predefinito. Se l’output deve essere rigorosamente JSON, se la chiamata allo strumento deve essere riprovata dopo un errore, dove troncare l’input troppo lungo e su quale livello inserire le richieste di controllo del rischio. Questi problemi spesso rientrano nel codice aziendale.

Una volta che un modello open source viene limitato o rimosso dagli scaffali, oppure l’immagine locale e la versione upstream iniziano a biforcarsi, questi comportamenti predefiniti non sono più affidabili. In superficie si tratta semplicemente di cambiare il modello, ma sotto sotto è necessario modificare allo stesso tempo l’analisi, il monitoraggio, il rollback e il test. La parte più difficile non è scrivere qualche riga in più di adattamento, ma che l’insieme dei presupposti originali non sia esplicitamente segnato dall’inizio alla fine.

Il ruolo del livello neutrale è quello di diffondere le ipotesi implicite

Gli strati neutrali rispetto al modello non sono astratti per amore dell’astrazione. La sua funzione è molto semplice: mettere parole di prompt, verifica dello schema, instradamento, riprova, downgrade, log e valutazione in un unico posto, in modo che le differenze del modello passino prima attraverso lo stesso insieme di confini. In questo modo, anche se il modello viene sostituito da cloud, open source, inferenza locale o altri provider, l’azienda vedrà comunque un contratto di input e output unificato.

Una volta stabilito questo livello, molte cose che inizialmente non erano chiare diventeranno improvvisamente chiare. Quali campi sono valori obbligatori, quali campi sono solo preferenze del modello, quali errori possono essere ritentati, quali errori devono essere ripristinati, quali contesti verranno troncati e quali indicatori possono realmente essere confrontati, tutto cambierà da “ricordato dall’esperienza” a “limitato dalle interfacce”. L’impatto causato dal modello limitato non viene più inserito direttamente nel codice aziendale, ma prima nello strato neutrale.

Non tutte le scene meritano questo livello

Per alcune scene non è necessario che gli strati siano così spessi. Riepiloghi una tantum, generazione temporanea, esperimenti interni e catene di strumenti bloccate completamente a modello singolo, sono sufficienti per collegare il modello in questi luoghi. La creazione di uno strato neutro completo per un processo di breve durata non farà altro che sovraccaricare i costi in anticipo.

Questo livello è necessario laddove il modello parteciperà realmente al giudizio aziendale. Ad esempio estrazione, instradamento, esecuzione di strumenti, risposta del servizio clienti, assistenza alla revisione e riscrittura batch. In questi scenari, il modello non è un giocattolo, ma una parte del processo. Finché il modello può cambiare, o i vincoli esterni possono destabilizzare un certo ingresso, lo strato neutro non è decorazione ma un muro che mantiene il cambiamento entro i confini.

Ciò che realmente costringe a limitare il modello open source non è l’alternativa di un fornitore specifico, ma se il team tratta le “differenze di modello” come cittadini di prima classe. Quanto prima viene distribuito il comportamento predefinito nel codice, tanto meno passivo sarà quando si modificheranno i modelli in un secondo momento. Il modello può cambiare, ma i confini non possono seguire.