Ti è mai capitato che un determinato prompt funzionasse bene per poi smettere improvvisamente di funzionare?
Ti è mai capitato di ritrovarti a correggere continuamente il prompt di sistema nel tentativo di migliorare i risultati, per poi scoprire che nulla funziona?
L’apprendimento del prompt di sistema potrebbe essere proprio ciò di cui hai bisogno.
L’apprendimento del prompt di sistema (SPL) è un ambito emergente che suscita interesse nella comunità dell’IA ed è stato ampiamente reso popolare da Andrej Karpathy su X a maggio.
L’apprendimento del prompt di sistema affronta i limiti dei sistemi di IA rigidi e fragili che si basano su prompt di sistema statici o su configurazioni di fine-tuning poco gestibili. Offre un altro modo per favorire l’apprendimento continuo nei sistemi di IA.
Prima di approfondire, ripassiamo brevemente alcuni concetti fondamentali sui prompt.
Quando sviluppiamo un agente o un modello personalizzato, dobbiamo innanzitutto progettare due componenti fondamentali:
Un prompt di sistema
Un prompt utente
I prompt di sistema stabiliscono le regole di base che definiscono il comportamento di un modello. Quando vengono scritti per soluzioni di IA personalizzate, spesso iniziano così:
“You are an intelligent assistant. Your role is to perform <insert task here>.
You must not do (A), (B), or (C).”
Al contrario, i prompt utente contengono in genere la richiesta dell’utente e altre informazioni pertinenti, come il fuso orario e le preferenze. Un prompt utente potrebbe essere formulato così:


I’m in the capital city of Portugal. Can you suggest some things I can do tonight?
Le fughe di prompt di sistema sono diventate comuni dopo il rilascio di nuovi modelli da parte dei principali laboratori di IA, poiché gli utenti applicano tecniche di jailbreak ai chatbot per svelarne le istruzioni sottostanti. Un popolare repository GitHub raccoglie ora molti di questi prompt di sistema in un unico luogo. Rivelano l’«ingrediente segreto» sviluppato nel tempo dai laboratori di IA per favorire un comportamento appropriato dei modelli. Ad esempio, il prompt di sistema di GPT-5 trapelato di recente (esposto all’interno di ChatGPT) contiene circa 6.000 parole, a dimostrazione della quantità di conoscenze e indicazioni da codificare per definire il comportamento del sistema.
Questi prompt di sistema esaustivi trattano generalmente diverse aree chiave, tra cui:
Istruzioni per la ricerca
Definizioni degli strumenti
Preferenze dell’utente
Istruzioni per le citazioni
Correzioni rapide per problemi noti
In pratica, durante il collaudo e il perfezionamento delle applicazioni, gli sviluppatori di sistemi di IA personalizzati correggono manualmente e in modo iterativo i prompt di sistema, affidandosi soprattutto alle valutazioni per orientare questo processo di miglioramento.
Altri modi per orientare il comportamento di un modello includono:
L’ingegneria dei prompt, inclusa la generazione aumentata tramite recupero (RAG), che controlla i contenuti forniti a un modello
Il fine-tuning (che modifica direttamente i pesi sottostanti del modello)
E se esistesse un altro modo per influenzare il comportamento del modello? Immagina un sistema che apprenda e perfezioni dinamicamente il proprio prompt di sistema usando pensieri, piani e strategie generati in precedenza. Potrebbe basarsi sia sul feedback degli utenti sia su valutazioni LLM-as-a-judge per esaminare i propri risultati.
Considera una sfida aziendale ricorrente che desideri automatizzare mediante un sistema agentico. Le soluzioni efficaci richiedono capacità di ragionamento che vanno oltre la semplice automazione dei flussi di lavoro. In questi casi, integrare nel sistema di IA un componente per la generazione dei piani diventa essenziale. Ciò consente al sistema di collaborare in modi diversi con più agenti, a seconda dell’attività. I singoli passaggi possono includere istruzioni per accedere ad altri agenti e completare attività secondarie oppure per utilizzare degli strumenti.


Nota: uno strumento di un agente è qualsiasi funzione esterna, API o risorsa che un agente di IA può richiamare per andare oltre il testo e compiere azioni concrete.
Potresti scegliere di fornire come «seme» al prompt di sistema del modello un piano che segua i passaggi logici adottati da una persona, anche se gli LLM richiedono in genere indicazioni più specifiche sull’uso degli strumenti, sulla formattazione dei risultati e su altri requisiti correlati. A volte la strategia ottimale potrebbe non essere chiara, oppure potresti affrontare un problema che non è più stato rivalutato perché in precedenza era considerato risolto. È qui che entra in gioco l’apprendimento del prompt di sistema (SPL).
L’SPL migliora iterativamente un prompt di sistema incorporando strategie generate in precedenza. Man mano che emergono nuovi problemi, il sistema accumula gradualmente conoscenze e diventa più robusto. È come creare un manuale per risolvere i problemi del proprio ambito.
L’SPL integra gradualmente nel prompt di sistema le indicazioni ricavate dal feedback degli utenti. Con la maturazione del sistema, potresti individuare problemi ricorrenti da sintetizzare in principi più generali e di livello superiore.
Vediamo più da vicino come funziona il processo, passaggio dopo passaggio:
Inizia dalla richiesta dell’utente, chiedendo al sistema di svolgere un’attività specifica.
Se il sistema affronta un solo problema, potresti adottare un approccio «greedy», selezionando le strategie con i punteggi più alti tra le esecuzioni precedenti. In alternativa, puoi favorire l’esplorazione campionando da una distribuzione che privilegi le strategie più apprezzate, includendo occasionalmente quelle con valutazioni inferiori. Questo è particolarmente utile quando hai appena iniziato a raccogliere strategie.
Per i sistemi progettati per gestire insiemi di problemi eterogenei, valuta l’aggiunta di un livello di classificazione oppure l’uso di embedding e similarità del coseno, le stesse tecniche generalmente impiegate nella RAG, per individuare approcci pertinenti. Ciò consente di selezionare strategie adatte al problema specifico, ad esempio quelle pensate per attività di programmazione.
Nota: gli embedding utilizzati con la similarità del coseno consentono di misurare quanto siano correlate due informazioni, facilitando l’abbinamento di documenti, richieste o idee anche quando la formulazione esatta è diversa.
Esempio di punto di partenza per un archivio semplificato di strategie dedicate ai problemi di programmazione.
Nota: le «strategie iniziali» qui mostrate hanno scopo illustrativo. Negli scenari di programmazione reali, le perfezioneremmo ulteriormente. I problemi aziendali di nicchia richiederebbero la raccolta di ulteriori indicazioni nel tempo.
Generation_id (ordine inverso) | Argomento | Punteggio | Strategy_text | Spiegazione |
|---|---|---|---|---|
4 | programmazione | 1 | Comprendi il problema, i vincoli e i casi limite. Progetta un algoritmo con le strutture dati appropriate. Convalida il piano usando esempi e invarianti. Implementa codice pulito e leggibile. Perfezionalo tramite refactoring, ottimizzazione e formattazione finale. Uso degli strumenti: quando usi uno strumento, spiega brevemente perché era necessario. | Integra e combina gli elementi migliori delle tre strategie riportate di seguito. |
3 | programmazione | 1 | Comprendi il problema, i vincoli e i casi limite. Progetta un algoritmo con le strutture dati appropriate. Convalida il piano usando esempi e invarianti. Implementa codice pulito e leggibile. Perfezionalo tramite refactoring, ottimizzazione e formattazione finale. | Una strategia più completa, ma senza indicazioni sull’uso degli strumenti. |
2 | programmazione | -1 | Comprendi il problema, i vincoli e i casi limite. Progetta un algoritmo con i dati appropriati. Implementa codice pulito e leggibile. Uso degli strumenti: quando accedi agli strumenti, fornisci un breve riepilogo del motivo per cui hai usato quello strumento. | Una strategia migliore che menziona l’uso degli strumenti, ma che può ancora essere perfezionata. |
1 | programmazione | -1 | Dai una rapida lettura al problema. Risolvi il problema. Crea test minimi. Invia qualsiasi cosa funzioni. | Menziona i test, ma nel complesso è una strategia debole. |
3. Dopo aver campionato N strategie, incorporale nel prompt di sistema. In questo modo, la generazione dei piani si basa sui precedenti feedback degli esperti, anziché lasciare che il modello crei piani con indicazioni minime. Invita il modello a «pensare fuori dagli schemi» e ad aggiungere passaggi quando necessario, anziché limitarsi a copiare alla lettera le strategie di esempio.


4. Con il prompt di sistema creato dinamicamente, genera una nuova strategia per rispondere alla richiesta dell’utente. Questo processo dovrebbe produrre attività aggiuntive che migliorino il risultato finale. L’obiettivo è la creatività: combina gli elementi migliori delle strategie precedenti, unifica i passaggi sovrapposti e aggiungi nuovi passaggi utili dove necessario.
Nota: ricorda che la temperatura è un parametro regolabile che permette di produrre risultati più vari e meno deterministici, utile quando si desidera maggiore creatività. Con una temperatura diversa da zero, ogni piano generato può essere differente.
5. Dopo aver ricevuto il risultato del modello, fallo valutare da una persona o da un LLM giudice in base a criteri specifici che definiscano una buona soluzione al problema. Per l’esempio delle attività in Portogallo citato prima, i criteri di valutazione potrebbero includere:
Concisione (una risposta limitata a una frase)
Pertinenza dell’attività suggerita
Accuratezza della località
6. In base a questa valutazione, usa un altro modello per perfezionare la strategia. Un ciclo di feedback facoltativo può integrare il contributo umano e favorire miglioramenti collaborativi. Salva la strategia perfezionata nel database insieme ai metadati necessari per tenere traccia delle versioni e delle modifiche.


Ma perché affrontare tutta questa fatica? Potresti esaminare manualmente i risultati e modificare di conseguenza il prompt di sistema. Tuttavia, i modelli di ragionamento più potenti possono perfezionare le strategie sfruttando sia il contesto del risultato sia il feedback umano. Sebbene le persone possano individuare facilmente i difetti degli approcci semplici, farlo diventa difficile e tedioso nei sistemi complessi che affrontano insiemi di problemi più ampi.
Gli LLM richiedono spesso istruzioni dettagliate e passaggi aggiuntivi per acquisire le conoscenze contestuali che le persone apportano naturalmente a un problema. Il numero di attività necessarie può crescere rapidamente quando un sistema si espande per affrontare insiemi di problemi più ampi. Ad esempio, chi affronta problemi di programmazione può comprendere intuitivamente il codice circostante, mentre un LLM potrebbe prima dover «leggere» più file.
Quando è utile: immagina di gestire un team di assistenza clienti in cui un agente di IA si occupa di classificare i ticket. Nel tempo, l’SPL potrebbe scoprire un metodo di categorizzazione a cui il team non aveva pensato, riducendo il tasso di escalation.
Quando non lo è: se requisiti di conformità o normative definiscono già i flussi di lavoro, come nella rendicontazione finanziaria, l’SPL può offrire scarso valore perché la creatività diventa un rischio anziché un vantaggio.
Quando è utile: nei ruoli ad alta intensità di ricerca, come l’intelligence di mercato o la strategia di prodotto, puoi collaborare con l’IA perfezionandone i piani, arricchendone i risultati e integrando questi miglioramenti per usi futuri. Ogni interazione aumenta l’efficacia del sistema.
Quando non lo è: se il team usa l’IA soprattutto per flussi di lavoro semplici con un intervento umano minimo, come l’elaborazione delle fatture, l’onere della collaborazione può superarne i benefici.
Quando è utile: supponi di espanderti in una nuova regione e che l’IA debba improvvisamente gestire domande sulla fiscalità locale. L’SPL consente di codificare rapidamente nuove regole ed euristiche man mano che emergono, evitando il ripetersi degli errori.
Quando non lo è: se l’ambiente è statico, come nel caso della conversione delle trascrizioni di riunioni in riepiloghi standardizzati, il continuo adattamento offre benefici minimi.
In teoria sembra tutto promettente, ma l’implementazione dell’SPL presenta sfide concrete. Di seguito ne esaminiamo alcune tra le principali:
Nelle fasi iniziali della generazione delle strategie, i progressi spesso si bloccano: i nuovi risultati non sviluppano quelli precedenti e lo slancio rallenta. In genere, ciò dipende da due problemi principali:
Soluzione: codifica in anticipo tutte le conoscenze aziendali disponibili, in modo che il sistema disponga di basi solide da cui attingere.
Soluzione: progetta una griglia di valutazione articolata che assegni un punteggio a diversi aspetti della risposta, come accuratezza, chiarezza e pertinenza, e adatta il campionamento a questi segnali.
Se il sistema genera centinaia di strategie ma riceve pochi feedback per distinguere quelle valide dalle altre, il campionamento diventa presto ingestibile. La soluzione è la potatura.
Quando perfezioni l’archivio delle strategie, considera:
Durata: ritira le strategie quando superano un periodo di tempo o un numero di generazioni prestabilito.
Punteggio: usa la griglia di valutazione per escludere le strategie che ottengono costantemente risultati scarsi. Combinando questo criterio con la durata, conserverai solo gli approcci che dimostrano il proprio valore nel tempo.
Valutazione tramite LLM: esamina periodicamente le strategie per individuare quelle che non aggiungono più contributi originali, dato che i loro elementi utili sono probabilmente già stati integrati nelle versioni più recenti.
Soluzione: tratta il database delle strategie come un sistema vivo: sottoponilo regolarmente a potatura affinché conservi solo conoscenze pertinenti e di valore elevato.
L’apprendimento del prompt di sistema è ancora agli inizi, ma ha un potenziale enorme. Le aziende che si affidano esclusivamente a prompt statici o a un fine-tuning continuo incontreranno limiti già noti: sistemi fragili, costi crescenti e sprechi di risorse. L’SPL offre una via d’uscita da questo ciclo, creando sistemi che migliorano nel tempo e codificano principi generali anziché correzioni isolate.
L’SPL è ancora in fase emergente, ma la direzione è chiara: i sistemi capaci di apprendere da sé supereranno quelli che non lo sono. È il momento di sperimentare, iniziare in piccolo, documentare gli insegnamenti e gettare le basi per sistemi di IA che migliorino a ogni interazione.