Soluzione · AI Operations
I tuoi prompt sono in produzione e nessuno sa con certezza quale versione sta girando
Il prompt è il pezzo che comanda di più sul comportamento della tua IA, e in quasi tutte le aziende si modifica a mano, senza revisione, senza storico e senza modo di tornare indietro. Montiamo e operiamo la funzione che lo trasforma in un artefatto versionato, testato prima di salire e reversibile in un minuto.
Il problema
L'artefatto che comanda di più sulla tua IA è l'unico che nessuno governa
- Nessuno può affermare con certezza quale versione del prompt sta servendo in questo momento, chi l'ha cambiata per ultimo né perché.
- Una modifica di una riga si pubblica direttamente su produzione, perché non esiste un ambiente dove provarla prima con casi reali.
- Quando la qualità cala, non si può tornare alla versione precedente: non è salvata da nessuna parte, oppure sta nello storico di una conversazione di chat.
- Lo stesso prompt vive duplicato nel codice, in uno strumento e negli appunti di qualcuno, e ogni copia deriva per conto suo da mesi.
- Quando il fornitore aggiorna il modello bisogna rivedere i prompt, ma nessuno sa quali ci sono, quali dipendono da quel modello né con quale criterio erano stati validati.
- Il team ha smesso di toccare i prompt. Non perché vadano bene: perché cambiarli fa paura e nessuno vuole essere quello che rompe la produzione di giovedì.
Il costo di lasciare tutto com’è
Stai operando un sistema il cui pezzo di maggior impatto non ha controllo delle modifiche. Il costo arriva da due lati insieme. Primo, la regressione che nessuno ha visto arrivare e che scopre un cliente. E poi, più caro, la paralisi: quando cambiare il prompt è una scommessa, il team smette di toccarlo e il sistema smette di migliorare proprio quando il mercato comincia a muoversi. A questo si aggiunge un terzo fronte, che salta fuori appena qualcuno chiede da fuori: senza storico non puoi ricostruire quali istruzioni governavano il tuo sistema il giorno in cui ha preso una decisione precisa.
La soluzione
Montiamo e operiamo la gestione del cambiamento dei tuoi prompt: versione, test, deploy a fasi e ritorno indietro
- 1Facciamo inventario e consolidiamo. Tiriamo fuori ogni prompt da dove sta —codice, strumenti, documenti, teste— e lo trasformiamo in un artefatto con identificativo, responsabile, versione e storico, con un'unica fonte di verità da cui leggono tutti gli ambienti.
- 2Separiamo gli ambienti e mettiamo un gate. Una modifica nasce fuori dalla produzione, passa dalla batteria di casi e sale solo se supera la soglia concordata. Lo stesso gate per tutti, senza eccezioni per urgenza: l'urgenza si gestisce con un percorso rapido documentato, non saltando il controllo.
- 3Costruiamo la batteria di test del prompt: un insieme di casi reali e avversariali, congelato e versionato, che gira contro ogni candidato e confronta la sua uscita con quella della versione viva. Senza confronto con la versione viva, un buon risultato non significa niente.
- 4Rilasciamo a fasi. La versione nuova entra prima su una porzione del traffico, con la precedente che gira in parallelo sugli stessi ingressi, e solo dopo su tutto. Il ritorno indietro è un cambio di puntatore: un minuto, senza rilasciare codice e senza riunione.
- 5Operiamo la funzione nel quotidiano: chi può cambiare cosa, cosa si rivede prima di salire, cosa resta registrato di ogni modifica per poterla ricostruire dopo, e la revisione programmata ogni volta che il fornitore muove il modello sotto.
Cosa cambia
Quello che smetti di perdere
La domanda «quale versione sta girando» smette di essere un'indagine e diventa una consultazione: c'è un identificativo, uno storico e un responsabile per ogni prompt in produzione.
Meccanismo
Una modifica smette di essere una scommessa: si confronta con la versione viva sugli stessi casi prima di salire, e sale a fasi su una parte del traffico.
Meccanismo
Il ritorno indietro smette di dipendere dal fatto che qualcuno ricordi il testo precedente: è un cambio di puntatore a una versione salvata, senza rilasciare codice.
Meccanismo
Cosa misuriamo: tempo da quando si rileva una regressione a quando viene annullata, % di modifiche che passano dal gate, modifiche annullate sul totale e numero di prompt in produzione senza un responsabile identificato.
Cosa misuriamo
Scheda tecnica
- Lavoro che elimina
- modificare prompt a mano su produzione, senza storico, senza confronto con la versione viva e senza modo di tornare indietro quando la qualità cala
- Implementazione tipica
- 4–8 settimane
- Ingresso
- una proposta di modifica su un prompt in produzione: un aggiustamento di istruzione, un cambio di modello o una correzione dopo un incidente
- Uscita
- una versione nuova testata contro la batteria di casi, confrontata con quella viva, rilasciata a fasi e reversibile in un minuto, con il registro di chi, quando e perché
- Compatibile con
- OpenAIAnthropicAzure OpenAIGoogle Vertex AILangSmithLangfusePromptfooBraintrustGitHub ActionsGitLab CI
- Può collegarsi con
- Tu repositorio y tu circuito de revisión de códigoTus registros de producción, de donde salen los casos de pruebaTu función de evaluación continua de calidad, si ya la tienes montadaTu registro de trazabilidad y tu inventario de sistemas de IA
- Cosa misuriamo
- tempo da quando si rileva una regressione a quando viene annullata% di modifiche che passano dal gate prima della produzione% di modifiche annullate sul totale rilasciatoprompt in produzione senza un responsabile identificato
- Adatto per
- aziende con IA in produzione e più persone che toccano prompt —CIO, COO o responsabile IA— che devono poter cambiare in fretta senza rompere e dimostrare cosa governava il sistema in ogni momento
- Non adatto per
- chi ha un solo prompt stabile che non si tocca da mesi, o chi vuole misurare se la risposta dell'agente è buona: quella è valutazione della qualità, una funzione diversa e complementare
Domande frequenti
Nel cosa governano. La valutazione continua misura se la risposta del tuo agente è buona oggi: campiona conversazioni reali, le valuta contro un criterio e rileva che la qualità è calata. Questa funzione governa il cambiamento dell'artefatto che produce quella risposta: dove vive il prompt, chi può toccarlo, quale test deve superare prima di salire, come si rilascia e come si torna indietro. Sono complementari e funzionano meglio insieme —la batteria di casi e le metriche di qualità si alimentano della stessa materia—, ma risolvono problemi diversi: una ti dice che qualcosa si è rotto, l'altra fa sì che romperlo sia reversibile e raro.
Git è la base e la usiamo, ma da sola risolve metà del problema. Ti dà storico e revisione, ed è già più di quello che ha la maggioranza. Quello che non ti dà: un ambiente dove provare il candidato contro casi reali prima di salire, il confronto automatico con la versione che è viva, il rilascio su una parte del traffico e il ritorno indietro senza rilasciare codice —che è ciò che ti serve alle undici di sera—. In più, in molti team chi scrive meglio i prompt non lavora nel repository, e obbligarlo a passare da una pull request per cambiare una frase finisce nella solita copia parallela.
Al contrario: quello che frena oggi è la paura. Nei team senza controllo delle modifiche i prompt si toccano poco e con il fiato sospeso, perché qualunque aggiustamento può rompere qualcosa che nessuno rileverà finché non si lamenta un cliente. Quando testare costa minuti e tornare indietro costa un minuto, il costo di sbagliare scende talmente che la gente ricomincia a sperimentare. Il gate non c'è per aggiungere burocrazia: c'è perché il cambiamento sia economico. E per ciò che è davvero urgente esiste un percorso rapido documentato, con revisione successiva obbligatoria.
Lo montiamo nella tua azienda?
Hai individuato il problema. Noi consegniamo la soluzione e la lasciamo misurata.