Il tuo Agente IA non ha bisogno di un manifesto. Ha bisogno di una
specifica concisa e inequivocabile. Ecco come scriverne una.

Di recente abbiamo riscritto il prompt di sistema del nostro Receptionist IA. La versione precedente era lunga 450 righe, magnificamente strutturata, piena di politiche attentamente argomate e stava consumando così tanto spazio della finestra di contesto che l’agente aveva meno spazio per ascoltare effettivamente il chiamante! Per aiutarvi a evitare gli stessi problemi, questo blog, la Parte 1 ora e la Parte 2 a seguire, vi spiega come smettere di scrivere poesie e iniziare a scrivere istruzioni e prompt corretti, quindi continua a leggere per saperne di più!

Il primo errore che fanno tutti

Non siamo gli unici a commettere questo errore. Quasi tutti i clienti 3CX che modificano un prompt di sistema per la prima volta fanno lo stesso errore: trattano il prompt come un documento programmatico, un contratto legale o, peggio, un compito di scrittura creativa.

Ecco la trappola: poiché i prompt sono scritti in inglese (o in linguaggio naturale), le persone dimenticano che stanno scrivendo del codice. Scrivono paragrafi. Aggiungono aggettivi. Definiscono termini che il modello comprende già. Ribadiscono la stessa istruzione cinque volte perché sembra importante.

Il modello non legge la prosa come fanno gli esseri umani. Ogni parola nel prompt costa contesto, attenzione e, spesso, coerenza. Un prompt lungo non è un prompt più accurato. Di lavoro è un prompt peggiore.

Questa guida raccoglie ciò che abbiamo imparato riscrivendo il nostro. Se state modificando il prompt di sistema di un Agente IA 3CX, leggeta questa guida prima di procedere.

La trappola dell’inglese

Quando prompt engineering significava scrivere per un’API in JSON grezzo, la gente lo rispettava come una disciplina tecnica. Ora che le istruzioni sono in inglese, le persone scrivono nello stesso modo in cui scriverebbero un messaggio su Slack a un nuovo assunto.

Guardate questo frammento della vecchia versione del nostro prompt:

“Il motivo del chiamante è richiesto prima del trasferimento, ma non deve essere utilizzato per identificare, restringere, classificare, eliminare l’ambiguità, sostituire o ignorare la destinazione richiesta.”

Quella frase è grammaticalmente corretta, ben ponderata e quasi impossibile da seguire costantemente per un modello nel corso di una chiamata reale. Sei quasi-sinonimi. Due proposizioni. Una negazione che avvolge un requisito. Al terzo turno della conversazione, il modello la interpreta già in modo diverso rispetto al primo.

Ecco cosa è diventata:

“Non utilizzare la ricerca di informazioni per decidere chi deve ricevere una chiamata.”

Una frase. Un’istruzione. Zero ambiguità. Stesso comportamento.

Regola uno del prompt engineering: l’inglese è l’interfaccia, non il genere letterario. State comunque scrivendo istruzioni. Brevi, dichiarative, verificabili. Se una frase sembra uscita da un documento sui termini di servizio, cancellatela e riprovate.

Smettetela di definire le cose al modello

Il vecchio prompt conteneva questa perla:

“Un trasferimento è qualsiasi passaggio successivo consentito ed eseguito tramite una delle azioni elencate di seguito.”

Il modello sa cos’è un trasferimento. Sa anche cosa significano “inoltro”, “segreteria telefonica” ed “e-mail”. Definire termini quotidiani al modello è un’abitudine mutuata dalla scrittura tecnica per gli umani. In un prompt, serve solo a bruciare token e a creare spazio per potenziali interpretazioni errate da parte del modello.

Lo stesso vale per le intestazioni di sezione puramente cerimoniali. Il vecchio prompt aveva:

  • Applicazione obbligatoria
  • Ordine di priorità
  • Schema di base
  • Regole di selezione dell’azione

Sembrano uscite da una RFC. Non aggiungono alcun comportamento. Il nuovo prompt utilizza intestazioni come Stile, Instradamento, Ostilità — brevi etichette che descrivono l’argomento della sezione, non quanto sembri seria.

Regola due: se una riga non cambia ciò che fa il modello, cancellatela.

Ditelo una volta sola

Una delle peggiori abitudini nei prompt lunghi è la stessa regola che appare in quattro punti diversi. Nella nostra vecchia versione, “non trasferire se la destinazione è ambigua” appariva, con lievi variazioni, in:

  • Regola di ambiguità della destinazione
  • Filtro dell’azione di trasferimento
  • Regole della rubrica
  • Contratto di output riservato

Ogni ripetizione era leggermente diversa. Ognuna utilizzava parole leggermente differenti. Un essere umano che le legge vede quattro versioni della stessa idea e ne comprende l’intento. Un modello che le legge vede quattro regole distinte e quando non sono perfettamente d’accordo, deve scegliere. A volte sceglie in modo diverso alla terza chiamata del giorno rispetto alla prima.

Regola tre: ogni regola appartiene a un solo posto. Se vi trovate a rinforzare una regola ripetendola in una nuova sezione, non avete bisogno di una nuova sezione. Avete bisogno di una prima versione più chiara.

Smettetela di accumulare divieti

Guardate questo:

“Non scegliere il primo risultato, il miglior risultato, il risultato disponibile o il risultato più pertinente.”

Si tratta di quattro istruzioni negative quando basterebbe un’unica istruzione positiva. Ciò che la regola significa in realtà è:

“Se la ricerca restituisce più corrispondenze, chiedi al chiamante di chiarire.”

Le istruzioni positive dicono al modello cosa fare. Le istruzioni negative dicono al modello cosa evitare, lasciando aperta la questione su cosa fare invece — e il modello inventerà una risposta.

Regola quattro: preferite le istruzioni positive. Usate “non” solo quando non esiste un equivalente positivo.

Attenzione alle contraddizioni

Questo è il killer silenzioso. Il vecchio prompt conteneva due sezioni che, lette insieme, erano incoerenti:

  • Instradamento per motivo: quando il chiamante fornisce un motivo, consulta la rubrica per determinare una destinazione.
  • Instradamento per destinazione richiesta: quando il chiamante richiede una persona o un reparto, non utilizzare il motivo per l’instradamento.

Entrambe vere. Entrambe ragionevoli. Ma inserite in sequenza in un prompt lungo con esempi sovrapposti e sotto-regole di rinforzo, il modello si confonde su quale applicare — e questa confusione si manifesta come un comportamento incoerente che il cliente non riesce mai a riprodurre su richiesta.

Usate il Tokenizer di OpenAI per vedere come il modello scompone effettivamente il vostro prompt in token. Poi rileggete il prompt nell’ordine in cui è scritto, come se non sapeste nulla della vostra attività, senza contesto. Se due regole potessero plausibilmente applicarsi alla stessa situazione e portare ad azioni diverse, avete una contraddizione, anche se sapete spiegare perché non sono in conflitto.

Regola cinque: un prompt è coerente quando non si hanno due regole che possono applicarsi contemporaneamente ed essere in disaccordo. Non quando riuscite a razionalizzarne la differenza.

La prossima settimana pubblicheremo la Parte 2 di questa serie, dove esamineremo più da vicino cosa il modello può e non può fare, suggerimenti per i prompt engineer alle prime armi e altro ancora. Rimanete sintonizzati!

Forum 3CX

Unitevi alla discussione 3CX nei nostri forum dedicati ai Partner o ai Clienti. Seguiteci su X e LinkedIn per rimanere aggiornati sulle ultime novità e sui rilasci di funzionalità.