Un'applicazione classica cambia quando il suo codice o la sua configurazione evolvono. Un'applicazione generativa cambia anche quando il fornitore aggiorna un modello, quando un prompt viene modificato, quando un documento entra nell'indice o quando uno strumento espone un nuovo schema. Senza tracciabilità, due risposte diverse possono sembrare inspiegabili.
Il LLMOps riunisce le pratiche che permettono di valutare, distribuire, osservare e far evolvere questi sistemi. Estende il DevOps e il MLOps con le specificità dei modelli generativi, del RAG, degli agenti e del giudizio qualitativo.
Definire l'unità di produzione
Il prodotto non è solo un modello. Include:
- applicazione ;
- istruzioni ;
- modello e parametri;
- fonti ;
- pipeline di ingestione ;
- indice ;
- strumenti;
- politiche;
- formato di uscita ;
- valutazioni;
- infrastruttura.
Una versione consegnata deve identificare questo insieme. Cambiare un solo elemento può modificare qualità, costo o sicurezza.
I nove oggetti da versionare
1. Codice
Orchestrazione, API, interfaccia e post-elaborazioni seguono il ciclo software abituale.
2. Prompt e istruzioni
Sono archiviati come codice, rivisti, testati e collegati ai casi di valutazione.
3. Modelli
Fornitore, identificativo esatto, data, parametri e opzioni sono registrati. Un alias « latest » non è sufficiente per riprodurre.
4. Dati di origine
I documenti e le registrazioni hanno identificativo, versione e stato.
5. Pipeline di ingestione
Estrattore, suddivisione, embeddings, metadati e filtri sono versionati.
6. Indice
Una versione di indice corrisponde a delle fonti e a una pipeline. Può coesistere con quella vecchia durante una convalida.
7. Strumenti
Schema, comportamento, permessi e versione delle API sono conosciuti.
8. Politiche
Routing, rifiuti, limiti, approvazioni e regole dei dati sono versionati.
9. Valutazioni
Casi di gioco, rubriche, giudici e soglie evolvono con il prodotto.
Tracciabilità di una risposta IA alla versione del codice, del prompt, del modello, dell’indice, delle fonti, degli strumenti e delle politiche.
Ambienti
Sviluppo, test, pre-produzione e produzione devono isolare dati, chiavi, quote e strumenti. Gli ambienti non produttivi utilizzano set autorizzati e azioni simulate.
I modelli esterni possono differire a seconda dell'ambiente per quanto riguarda il costo, ma la validazione finale deve utilizzare la configurazione target. Le divergenze sono documentate.
Una catena di consegna
Una modifica attiva:
- controlli statici e schemi;
- test deterministici ;
- valutazioni rapide ;
- test di sicurezza;
- confronto con la baseline;
- rivista ;
- dispiegamento progressivo;
- osservazione ;
- promozione o ritorno.
Le soglie critiche bloccano. Un'eccezione ha un proprietario e una durata.
Distribuire progressivamente
Una nuova configurazione può essere attivata per un team, una parte del traffico o un tipo di compito. Il routing mantiene la versione utilizzata al fine di confrontare.
Il canary monitora la qualità del proxy, errori, latenza, costo e feedback. Per gli usi a rischio, viene temporaneamente attivata una revisione umana aggiuntiva.
Il rollback deve includere il modello, il prompt, l'indice e gli strumenti compatibili, non solo il codice.
Tracciare senza registrare tutto
Un traccia utile contiene:
- identificativo della richiesta;
- utente o pseudonimo secondo necessità;
- versioni ;
- passaggi e durate;
- strumenti;
- documenti identificati ;
- token e costo;
- errori;
- risultato della convalida;
- feedback.
Non conserva automaticamente prompt completi, documenti sensibili o ragionamenti privati. La minimizzazione, la mascheratura, i diritti e la conservazione sono definiti.
Osservabilità tecnica
Seguire disponibilità, errori, timeout, quote, code, tempi di ogni fase, dimensione del contesto, cache e risorse. Le tracce distribuite collegano API, ricerca, modello e strumenti.
Gli obiettivi di servizio riguardano il percorso: tempo fino al risultato, tasso di compito riuscito e modalità degradata.
Osservabilità di qualità
La qualità non si misura solo tramite registri tecnici. Alcuni segnali includono:
- rifiuto;
- assenza di fonte;
- errore di formato ;
- correzioni;
- scalate ;
- strumenti scartati;
- risposte abbandonate;
- casi sentinella;
- campioni rivisti.
I feedback sono categorizzati e aggiunti al set di regressione dopo la convalida.
Costo
Il monitoraggio attribuisce costi e token per team, caso d’uso, versione e fase. I budget attivano avvisi, instradamento o limiti.
Il costo per richiesta è completato dal costo per compito riuscito e dal costo di convalida umana. Una diminuzione del prezzo non giustifica una diminuzione della qualità.
Lineaggio
Per una risposta data, il team deve ritrovare:
- codice ;
- prompt ;
- modello ;
- indice ;
- fonti ;
- strumenti;
- politica;
- risultato;
- valutazioni associate.
Questa tracciabilità consente un'indagine, una riproduzione approssimativa e una notifica mirata se una fonte fosse errata. Non è necessario memorizzare una catena di pensiero.
Gestione dei cambiamenti del fornitore
Un fornitore può modificare un modello, dei limiti o una tariffa. Le versioni bloccate, i test periodici e gli avvisi contrattuali riducono le sorprese.
Uno strato di routing consente di testare un altro modello. Le differenze di formati e capacità rimangono esplicite piuttosto che nascoste.
Gestione degli indici
Un nuovo embedding o suddivisione richiede spesso una ricostruzione. L'indice viene creato accanto al vecchio, alimentato, valutato e poi attivato. Il ritorno resta possibile.
Gli errori di ingestione, i ritardi e le cancellazioni sono monitorati. Una fonte non indicizzata non deve passare inosservata.
Gestione dei prompt
I prompt hanno un proprietario, un'intenzione, dei test e una documentazione delle variabili. Evitano segreti e dati codificati in modo fisso.
Uno studio di prompt può facilitare la modifica, ma la fonte di verità rimane versionata e rivista. I cambiamenti in produzione senza storico sono vietati.
Gestione degli incidenti IA
Un incidente può essere:
- fuga ;
- azione non autorizzata;
- risposta pericolosa;
- modello non disponibile;
- costo anormale;
- deriva di qualità;
- fonte scaduta;
- indice incompleto.
Il piano prevede interruzione, modalità degradata, revoca, analisi, correzione, valutazione e comunicazione. I responsabili di prodotto, sicurezza, dati e tecnico collaborano.
RACI e responsabilità
Ogni sistema ha:
- proprietario del prodotto;
- responsabile tecnico;
- proprietari dei dati;
- sicurezza;
- conformità;
- supporto ;
- bilancio ;
- decisore di lancio.
Una piattaforma centrale può fornire le fondamenta, mentre ogni caso d'uso assume i propri dati e la propria qualità.
Iniziare piccolo
Un basamento minimo comprende versioning, set di valutazione, tracce correlate, monitoraggio dei costi, distribuzione progressiva e rollback. Una piattaforma complessa è necessaria solo man mano che i team e gli usi si moltiplicano.
Gli strumenti devono servire il processo, non sostituirlo. Una convenzione semplice e automatizzata vale più di un catalogo sofisticato non mantenuto.
Sfruttare l’IA come un prodotto
Le LLMOps trasforma una configurazione mutevole in un prodotto osservabile. Permette di sapere cosa è cambiato, cosa è migliorato e come tornare indietro.
Partitech può progettare la pipeline, le valutazioni, le tracce, la gestione delle versioni e l’utilizzo dei RAG e degli agenti. L’obiettivo è consegnare frequentemente senza perdere il controllo della qualità, dei costi e del rischio.
Parliamo del tuo progetto
Industrializzare le vostre applicazioni IA e la loro osservabilità con Partitech. Contatta Partitech.