Il vero lavoro viene prima del prompt
Il workshop sui prompt iniziato troppo tardi
Il workshop era stato prenotato per migliorare i prompt. Questo era il titolo nel calendario, con una simpatica icona a forma di bacchetta magica che qualcuno avrebbe poi rimpianto. Un gruppo di manager, analisti, operatori e ingegneri era seduto attorno a un tavolo con un documento condiviso. Il prompt corrente era sullo schermo. Chiedeva a un modello linguistico di esaminare le richieste dei clienti, identificare la policy corretta, abbozzare una risposta e segnalare i rischi. Era educato, strutturato e molto più lungo di quanto chiunque volesse ammettere. Ma non era il problema principale.
Il primo caso di test riguardava un cliente che chiedeva un'eccezione dopo una consegna in ritardo. Il modello aveva prodotto una risposta decente. Poi qualcuno delle operations disse che la policy di origine sullo schermo non era più quella che il team usava il venerdì, perché una regola temporanea del corriere era stata prorogata due volte ma mai integrata nella pagina principale della policy. Qualcuno dell'ufficio legale disse che le eccezioni superiori a un certo importo richiedevano un'approvazione, ma la soglia dipendeva dalla categoria di prodotto. La finanza chiese dove venivano registrati i crediti di cortesia. L'assistenza disse che il tono del modello andava bene, ma il cliente avrebbe richiamato perché la risposta non menzionava l'evento di tracciamento mancante. Il prompt se ne stava lì, con aria innocente.
Nessuno di questi problemi sarebbe stato risolto da un paragrafo di istruzioni migliore. Il modello non poteva dedurre quale pagina di policy fosse quella autorevole. Non poteva sapere che una regola temporanea era diventata realtà operativa. Non poteva decidere chi avesse l'autorità di approvare. Non poteva vedere che l'evento di tracciamento mancante era la vera causa del contatto successivo. Al prompt veniva chiesto di compensare un lavoro poco chiaro. Questo è un errore comune. Le persone arrivano al prompt con un cesto di ambiguità di processo e chiedono al modello di essere elegante a riguardo.
Il vero lavoro viene prima del prompt. È il lavoro di dare un nome al compito, definire i confini, selezionare le fonti, stabilire le autorità, preparare gli esempi, decidere i percorsi di errore, dare forma all'output, misurare la qualità e rendere possibile la correzione. Il prompt conta. Un brutto prompt può rendere goffa una buona impostazione. Ma un prompt bellissimo sopra un'operazione poco chiara è solo confusione ben scritta. Il modello può sembrare migliore. Il lavoro non diventerà più sicuro, più economico o più comprensibile per caso.
Un prompt non è una mappa di processo
Un prompt può dire a un modello come comportarsi in un contesto. Non può creare il contesto se l'organizzazione non lo ha già fatto. Può chiedere brevità, struttura, umiltà e citazioni. Può descrivere un ruolo. Può specificare un formato. Può avvertire il modello di non fare supposizioni. Tutto questo è utile. Ma è anche poco rispetto alle questioni di processo che determinano se un sistema di IA aiuta davvero o si limita a parlare con sicurezza vicino al lavoro.
Qual è il compito. È classificazione, estrazione, riassunto, bozza, instradamento, raccomandazione, verifica o azione. Quale parte è automatizzata. Quale parte resta umana. Quale stato cambia se l'output viene accettato. Chi è coinvolto. Quali record vengono toccati. Quale policy si applica. Quale prova è obbligatoria. Cosa succede quando la prova manca. Quali errori sono tollerabili. Quali errori causano danni. Queste domande determinano la forma del sistema. Un prompt che non poggia su risposte chiare diventa una supposizione educata con un cartellino col nome.
Molti piloti di IA falliti iniziano con un prompt perché il prompt è la maniglia più visibile. Sembra creativo e immediato. Puoi modificarlo durante una riunione. Puoi provare una nuova versione prima che il caffè si raffreddi. La progettazione del processo è più lenta. La pulizia dei dati è più lenta. La mappatura delle autorità è più lenta. La creazione del set di valutazione è più lenta. Purtroppo, lento non significa facoltativo. Le parti saltate prima del prompt tornano dopo sotto forma di allucinazioni, rilavorazioni, sfiducia, eccezioni alla policy e un grande foglio di calcolo chiamato problemi.
La sequenza migliore non è affascinante. Metti per iscritto il lavoro. Esamina casi reali. Identifica i sistemi di origine. Segna quali campi determinano gli esiti. Separa le regole dal giudizio. Decidi dove entrano gli esseri umani. Definisci i contratti di output. Costruisci esempi. Concorda il rifiuto. Testa con le persone che vivranno con il risultato. Solo allora il prompt diventa una leva utile. Prima di allora, è un volante decorativo su una scrivania.
Il compito richiede un confine abbastanza netto da poter essere testato
Il lavoro con l'IA spesso inizia con verbi troppo ampi. Aiutare con l'assistenza clienti. Supportare la revisione legale. Migliorare la pianificazione. Assistere negli acquisti. Rendere più intelligenti i report. Queste sono ambizioni, non compiti. Un modello non può essere valutato rispetto a un'ambizione. Può essere valutato rispetto a un compito con input, output, vincoli, criteri di successo e percorsi di errore. La descrizione più ristretta può sembrare meno entusiasmante. È anche il primo momento in cui il lavoro diventa realizzabile.
Un confine netto del compito dice cosa il sistema può vedere e cosa può cambiare. Dice se il modello sta leggendo materiale di origine, generando una bozza, estraendo campi strutturati, raccomandando un'azione o chiamando uno strumento. Dice quali output sono definitivi, quali sono consultivi e quali devono essere revisionati. Dice cosa il sistema rifiuta. Dice quando il modello dovrebbe chiedere più prove piuttosto che completare la risposta. Dice cosa è fuori ambito, perché fuori ambito è dove i piloti ambiziosi vanno a diventare rapporti sugli incidenti.
I confini rendono possibile la valutazione. Se il compito è redigere una risposta usando queste fonti e questa policy, la qualità può essere testata. Se il compito è migliorare la qualità del servizio con l'IA, ogni risultato può essere spiegato come progresso da qualcuno con abbastanza slide. Un confine protegge anche gli utenti da un'escalation accidentale. Uno strumento che inizia con una bozza può acquisire un pulsante che invia. Un classificatore può diventare un instradatore. Un instradatore può diventare una decisione. Senza un confine dichiarato, questa deriva sembra adozione. Con un confine, diventa una richiesta di modifica.
Il confine dovrebbe essere scritto in linguaggio operativo, non solo in linguaggio tecnico. Il responsabile del supporto dovrebbe capirlo. L'ufficio legale dovrebbe capirlo. Il proprietario dei dati dovrebbe capirlo. L'ingegnere dovrebbe poterlo testare. Se il prompt è l'unico posto in cui vive il confine, il confine è fragile. I prompt sono importanti, ma non sono documenti normativi portanti. Sono più simili a istruzioni per un lavoratore temporaneo molto talentuoso che non ha mai visto l'organigramma.
Le fonti non sono un mucchio di documenti
Molti team scoprono durante la creazione dei prompt di non sapere quali fonti siano autorevoli. Hanno pagine di policy, PDF, istruzioni via email, materiale di formazione, manuali legacy, messaggi in chat, macro per i ticket, fogli di calcolo di monitoraggio e la memoria di un'operatrice che tutti chiamano perché sa come funziona davvero. Al modello viene quindi chiesto di rispondere attingendo alla knowledge base. Quale knowledge. Quale base. L'espressione può nascondere una quantità eroica di omissioni.
La preparazione delle fonti non è affascinante, ed è per questo che spesso arriva in ritardo. Implica decidere quale documento vince quando le fonti sono in conflitto, come viene verificata la freschezza, come scadono le regole temporanee, come vengono rappresentate le eccezioni, come viene escluso il materiale riservato, come vengono preservate le versioni delle fonti e come gli identificativi di citazione sopravvivono alla risposta del modello. Non è burocrazia. È la differenza tra recupero e rovistamento.
L'IA rende la disciplina delle fonti più importante perché il modello può far sembrare accettabili pratiche deboli sulle fonti. Può cucire frammenti in prosa fluente. Può appianare le contraddizioni. Può produrre una risposta plausibile da materiale obsoleto. Un risultato di ricerca con lacune visibili sembra incompleto. Una risposta generata con le stesse lacune può sembrare completa. Migliore è la prosa, più importante è la provenienza. La fiducia non dovrebbe poter ripulire una catena di fonti debole.
Una buona preparazione delle fonti riduce anche la complessità del prompt. Un prompt pieno di avvisi su policy contrastanti, documenti obsoleti, campi mancanti ed eccezioni speciali è spesso un sintomo di negligenza a monte. Se il livello di recupero filtra già per autorità e freschezza, il prompt può essere più breve. Se la fonte porta con sé metadati strutturati, il modello non deve dedurli dai titoli dei paragrafi. Se le eccezioni sono rappresentate come regole, il modello non deve trasformarsi in un detective con limiti di token. Il miglior miglioramento di un prompt a volte è un indice migliore.
Gli esempi sono piccoli pezzi di governance
Gli esempi sono di solito trattati come strumenti di addestramento, ma sono anche governance. Un buon esempio dice cosa significa qualità in una situazione. Mostra come l'organizzazione gestisce l'incertezza, le prove mancanti, le policy in conflitto, il tono delicato, l'escalation e il rifiuto. Dice al modello e al team come appare una buona risposta, ma anche come appare una buona non-risposta. Questo è importante perché molti sistemi seri falliscono rispondendo quando dovrebbero fermarsi.
Costruire esempi impone decisioni che la discussione astratta evita. Prendi venti casi reali. Segna l'esito corretto. Segna le alternative accettabili. Segna le scorciatoie inaccettabili. Spiega il perché. Includi casi limite che hanno fatto esitare il personale esperto. Includi anche casi ordinari, perché i sistemi che si addestrano solo sul dramma imparano cattive maniere. Chiedi agli esperti di dominio di dissentire e registra il dissenso. Questo è più lento che chiedere al modello di essere cauto. Produce anche un linguaggio condiviso per la cautela.
Gli esempi dovrebbero includere casi negativi. Nessuna fonte trovata. Conflitto tra fonti. L'utente non ha l'autorità. Richiesta fuori dallo scopo. Il cliente chiede qualcosa che sembra semplice ma attiva una policy. Il modello dovrebbe imparare quando rifiutare, fare escalation, chiedere o restituire incertezza strutturata. Se gli esempi mostrano solo risposte di successo, il prompt tenderà verso il completamento. Il completamento non è sempre successo. A volte la risposta migliore è prove insufficienti, cosa difficile da celebrare in una demo ma utile in un sistema funzionante.
Gli esempi sono anche l'inizio della valutazione. Possono diventare fixture di test, casi di regressione, formazione per i revisori e campioni di monitoraggio. Quando accade un incidente, un caso corretto può diventare un nuovo esempio. Questo dà memoria al sistema. Senza esempi, i cambiamenti al prompt diventano cambiamenti di umore. Qualcuno dice che la risposta sembra migliore. Qualcun altro dice che sembra peggiore. Il modello sorride nel mezzo, imperturbabile dalle prove.
La forma dell'output è una decisione operativa
Le discussioni sui prompt spesso dedicano troppo tempo al tono e troppo poco alla forma dell'output. Il tono conta, soprattutto nella comunicazione con clienti o pubblico. Ma la forma dell'output decide se la risposta può essere verificata, instradata, archiviata, approvata, contestata o usata da un altro sistema. Un paragrafo può essere piacevole. Un output strutturato può essere operabile. Il lavoro serio sull'AI spesso richiede entrambi: prosa leggibile per gli esseri umani e campi che le macchine possono verificare.
La forma dell'output include campi obbligatori, riferimenti alle fonti, livello di confidenza o incertezza, motivi del rifiuto, flag di escalation, record interessati, azioni proposte e stato di approvazione umana. Specifica se il modello può lasciare vuoto un campo. Specifica se deve citare un identificatore di policy. Specifica se può inventare categorie o deve scegliere da un elenco controllato. Specifica cosa succede quando l'input è ambiguo. Queste scelte non sono dettagli estetici del prompt. Sono progettazione del flusso di lavoro.
L'output strutturato tiene anche il modello nel suo ambito. Se il sistema richiede un campo separato per le prove, le affermazioni non supportate diventano visibili. Se richiede un tipo di azione da un elenco consentito, l'uso creativo degli strumenti diventa più difficile. Se richiede che l'incertezza sia esplicita, i revisori possono fare triage. Se richiede un motivo del rifiuto, i casi bloccati possono essere analizzati. Il prompt può richiedere queste cose, ma il sistema circostante dovrebbe validarle. Chiedere gentilmente non è un controllo. È un suggerimento con formattazione.
C'è un lato umano. Le persone hanno bisogno di output che corrisponda al loro ritmo di lavoro. Un avvocato può aver bisogno di clausole di origine e note sul rischio. Un agente di supporto può aver bisogno di una bozza pronta per il cliente più codici di motivo interni. Un pianificatore può aver bisogno di una raccomandazione sul percorso e del vincolo che l'ha determinata. Un manager può aver bisogno di motivi aggregati, non di prosa individuale. Se la forma dell'output ignora l'utente, il prompt può essere tecnicamente corretto e operativamente irritante. È un risultato comune, ma non utile.
L'autorità non può essere implicata dall'utilità
Un modello utile invita alla fiducia. Questo è positivo finché l'utilità non viene scambiata per autorità. Se il modello redige una risposta, chi può inviarla. Se raccomanda un rimborso, chi può approvarlo. Se classifica il rischio, chi può agire sulla classificazione. Se estrae un campo, chi lo corregge. Se non trova prove, chi decide se procedere. Queste domande devono trovare risposta prima del prompt, perché il prompt non può concedere autorità istituzionale.
La progettazione dell'autorità include ruoli, soglie, code di revisione, diritti di override, percorsi di escalation e registri di audit. Distingue il suggerimento dalla decisione. Distingue la decisione automatizzata dalla decisione umana supportata dall'automazione. Specifica quando un essere umano deve vedere il materiale di origine piuttosto che solo la prosa del modello. Specifica quando una chiamata allo strumento è consentita e quando è bloccata. Specifica chi è responsabile di danni, ritardi, correzioni e comunicazioni. Il modello può aiutare all'interno di quella progettazione. Non dovrebbe essere la progettazione.
Questo è particolarmente importante quando l'IA viene aggiunta a flussi di lavoro esistenti. L'autorità esistente può essere informale. Una persona senior approva le eccezioni perché tutti sanno che bisogna chiedere a lui. Un team lead interpreta la policy perché ha visto i casi limite. Un foglio di calcolo contiene una regola temporanea perché il sistema non può. Quando entra l'IA, l'autorità informale diventa fragile. Il modello può amplificare la vecchia ambiguità più velocemente di quanto le persone possano intercettarla. Il lavoro prima del prompt è rendere l'autorità abbastanza esplicita che l'amplificazione non amplifichi semplicemente la confusione.
Vale la pena dire che l'autorità non è nemica della velocità. Un'autorità chiara spesso rende il lavoro più veloce perché le persone sanno cosa può procedere senza dibattito, cosa deve fermarsi e chi può decidere. Un'autorità vaga sembra flessibile finché non incontra il volume. Poi ogni caso difficile diventa una piccola crisi costituzionale, con thread di chat come giurisprudenza. Questo non è un sistema legale raccomandato.
La valutazione non è un controllo di impressione
Molte iterazioni sui prompt vengono giudicate a sensazione. Questa versione suona meglio. Quella versione è più concisa. Questa è meno impositiva. Questi giudizi possono essere utili, ma non bastano. Le operazioni di IA richiedono una valutazione che segua il compito. Il modello ha usato la fonte giusta. Ha omesso campi obbligatori. Ha rifiutato quando mancavano prove. Ha fatto salire di livello i casi ad alto rischio. Ha preservato gli identificativi delle policy. Gli esseri umani lo hanno corretto. I clienti hanno fatto meno domande di approfondimento. I team a valle hanno visto meno rilavorazioni.
La valutazione dovrebbe includere casi ordinari, casi limite, casi avversi, fonti obsolete, dati mancanti, policy in conflitto ed esempi di rifiuto accettabile. Dovrebbe essere ripetibile. Dovrebbe distinguere il fallimento del modello dal fallimento della fonte, dal fallimento del prompt, dal fallimento dell'interfaccia e dal fallimento del processo. Altrimenti ogni problema diventa un problema di prompt, perché il prompt è la parte che tutti possono vedere. La parte visibile non è sempre quella colpevole. Questo vale nel software e nelle riunioni.
La valutazione decide anche quando fermarsi. Senza un set di test e criteri di rilascio, il lavoro sui prompt può continuare all'infinito, perché la lingua si può sempre migliorare. Ci sarà sempre un altro aggettivo, un'altra istruzione, un altro esempio, un'altra modifica alla formattazione. La domanda non è se il prompt sia perfetto. La domanda è se il sistema svolge il compito entro i confini concordati di rischio, costo e qualità. La perfezione è un pessimo responsabile dei rilasci. Non porta il cercapersone.
Il lavoro dopo il prompt inizia prima del rilascio
I percorsi di correzione dovrebbero essere progettati prima che il primo utente in produzione segnali un problema. Come fa un utente a segnalare una risposta sbagliata. Dove va a finire quella segnalazione. Chi la esamina. Cambia la fonte. Cambia il deposito di esempi. Cambia il prompt. Cambia una regola. Cambia una soglia. Un essere umano riceve feedback. Il caso corretto diventa un test di regressione. Se la correzione non è progettata, il feedback diventa un mucchio. I mucchi sono il luogo dove l'apprendimento va a fare un lungo pisolino.
Anche il monitoraggio dovrebbe essere deciso prima del rilascio. Tieni traccia non solo di latenza e costi, ma anche dei tassi di rifiuto, dei tassi di fonte mancante, dei motivi di override, del carico di escalation, della rilavorazione a valle, dei temi dei reclami, delle citazioni obsolete e della deriva nel mix di compiti. La qualità delle risposte del modello è solo una parte della qualità operativa. Un sistema può rispondere bene e comunque instradare troppo lavoro verso gli esseri umani. Può rispondere rapidamente e comunque aumentare le correzioni. Può ridurre i ticket e comunque crearne di più difficili. Il monitoraggio dovrebbe vedere il lavoro, non solo i token.
Il lavoro preparatorio al prompt non finisce mai davvero. Emergono nuove policy. I sistemi sorgente cambiano. Gli utenti trovano scorciatoie. Il modello cambia. Il business cambia. Un prompt che funzionava a maggio potrebbe essere sbagliato a settembre, perché il lavoro si è spostato sotto di esso. Questo non significa che tutto sia fragile. Significa che le operazioni di IA hanno bisogno di una proprietà definita. Qualcuno deve mantenere la definizione del task, le fonti, gli esempi, la valutazione, l'autorità e la riparazione. Altrimenti il prompt diventa un fossile con un'ottima grammatica.
La lezione
Il lavoro vero viene prima del prompt, perché il prompt è il bordo visibile di un sistema operativo più ampio. Il modello ha bisogno di un task che possa eseguire, fonti di cui possa fidarsi, confini che non possa oltrepassare, output che possano essere verificati, esempi che codifichino il giudizio, autorità che dica a persone e strumenti cosa possono fare, e valutazione che sappia distinguere il miglioramento da una prosa più curata. Senza tutto questo, il prompt si fa carico di responsabilità che non può assolvere.
Questa visione non sminuisce il prompting. Lo rende più prezioso. Un prompt all'interno di un'operazione preparata può essere breve, chiaro, testabile e manutenibile. Può focalizzare il modello invece di compensare l'ambiguità. Può evolvere con esempi ed evidenze. Può essere modificato con sicurezza, perché il team sa cosa significa "buono". È meglio del misticismo del prompt, che per lo più produce prompt più lunghi e dubbi più silenziosi.
Prima di chiederti come fare il prompt al modello, chiediti quale lavoro l'organizzazione ha già fatto per il modello. Il task è nominato. Le fonti sono autorevoli. Gli esempi sono marcati. L'output è strutturato. L'autorità è esplicita. Il fallimento è sicuro. La valutazione è reale. La riparazione è progettata. Se queste risposte sono deboli, inizia da lì. Il prompt più utile nella stanza potrebbe essere quello che fa ammettere a tutti che il prompt non è il punto in cui inizia il lavoro.