Il Prompt come libro di regole - Guidare gli Agenti LLM oltre le istruzioni di base

Nel nostro percorso di integrazione dei Large Language Models (LLM) con le API tradizionali, abbiamo visto come i prompt diventino i nuovi "documenti API", descrivendo ciò che uno strumento può fare. All'inizio sembra tutto meravigliosamente semplice. Si dà all'LLM l'accesso ad alcuni strumenti, li si descrive e voilà, si ha un agente intelligente! Ma come molti di noi stanno scoprendo, c'è una differenza cruciale tra un LLM che sa usare uno strumento e un LLM che usa uno strumento in modo saggio o efficace in un contesto più ampio. Questo affronta direttamente le sfide che abbiamo visto con il nostro semplice Assistente Calendario.

È qui che spesso si verifica quella che io chiamo la sindrome dello "stagista entusiasta". Il vostro agente LLM, proprio come uno stagista appassionato ma inesperto, segue diligentemente le istruzioni esplicite per i suoi strumenti. Tuttavia, potrebbe mancare il giudizio esperto di un dipendente esperto che considera intuitivamente regole non dichiarate, sottili fattori umani o il "miglior risultato complessivo". Gli attuali laureati in LLM sono eccezionalmente bravi a capire ed eseguire le istruzioni che gli vengono fornite, ma non riescono a cogliere il contesto non dichiarato o il "perché" sfumato che sta dietro a un compito e che spesso determina il vero successo.

Ciò significa che il nostro ruolo di sviluppatori si evolve. Non ci limitiamo più a descrivere le funzioni dello strumento, ma creiamo meticolosamente delle regole all'interno dei nostri prompt, guidando l'LLM attraverso processi decisionali complessi.

Caso di studio: L'assistente di calendario "premuroso

Rivediamo il nostro strumento "Assistente calendario" della seconda parte. Immaginiamo che il nostro agente LLM principale abbia accesso alle due funzioni principali che abbiamo definito:

1. CreateMeeting(attendees, subject, startTime, duration, location): Pianifica una riunione.
2. FindFreeTime(attendees, duration, timeWindow): Trova gli slot disponibili.

I nostri prompt iniziali per questi strumenti gestiscono l'interpretazione di base e sono configurati in modo da rispettare gli orari di lavoro standard dell'azienda, ad esempio dal lunedì al venerdì, dalle 8:00 alle 18:00 ora locale per ciascun dipendente.

Ora, un utente, che è un Team Lead con sede a Londra, fa questa richiesta: "Abbiamo bisogno di una sessione strategica di un'ora per il progetto Atlas all'inizio della prossima settimana. I partecipanti saranno io, Maria (anch'essa residente a Londra) e Ben (residente a Edimburgo). Questo richiede una preparazione significativa da parte di tutti i partecipanti. Vi prego di fissarla presso la nostra sede di Londra".

L'agente "stagista entusiasta" si mette al lavoro. Interroga i calendari utilizzando FindFreeTime e scopre che il lunedì alle 8:30 GMT è tecnicamente "libero" per tutti all'interno del loro orario di lavoro standard definito.

• Procede a chiamare: CreateMeeting(attendees=["lead@example.com", "maria@example.com", "ben@example.com"], subject="Project Atlas Strategy Session", startTime="<Next Monday @ 08:30 GMT>", duration="1 hour", location="London HQ").

Tecnicamente, una riunione è stata programmata. Ma è un buon risultato? Considerate le implicazioni:

1. Considerazione del viaggio ignorata: Per Ben, che vive a Edimburgo, un incontro di persona a Londra alle 8.30 del mattino è altamente problematico. Richiederebbe un viaggio estremamente anticipato il lunedì mattina o, più probabilmente, gli imporrebbe di viaggiare la domenica sera. L'agente, considerando solo le "ore lavorative disponibili dalle 8 alle 6" sul calendario, ha completamente omesso di considerare le implicazioni logistiche e l'impatto personale di una riunione di prima mattina che richiede un viaggio significativo. Non ha distinto una fascia oraria di 8:30 per un partecipante locale da una per un partecipante remoto che deve essere fisicamente presente.
2. Tempo di preparazione trascurato: L'utente ha dichiarato esplicitamente che si tratta di una "sessione strategica critica" che richiede una "preparazione significativa". Programmarla il lunedì mattina (8:30) implicitamente spinge i partecipanti a usare il loro tempo personale nel fine settimana per prepararsi, se vogliono essere pronti per un inizio così precoce.

Questo è il momento in cui, come sviluppatore, ci si rende conto che l'agente ha svolto il suo compito in base alla disponibilità esplicita del calendario, ma non ha tenuto conto di fattori umani impliciti e considerazioni pratiche cruciali. Manca la capacità di giudizio per garantire un risultato realmente efficace e rispettoso.

Codificare l'"esperienza" e la "considerazione" nei promemoria

Per elevare il nostro "stagista" a "assistente esperto", dobbiamo incorporare una logica più sofisticata nel sistema. prompt di guida dell'agente principale (o le istruzioni generali che segue nell'orchestrazione degli strumenti). Questo va oltre la semplice descrizione del FindFreeTime o CreateMeeting strumenti stessi. Dobbiamo dire all'agente come comportarsi in modo più rispettoso.

Spesso si tratta di istruire l'agente a cercare e utilizzare quello che possiamo definire un "terzo strumento" o un ulteriore livello di informazioni e di logica. In questo caso, si tratta di la posizione dei partecipanti, il contesto di viaggio e la natura della riunione. Il nostro agente potrebbe avere bisogno di implicitamente (o esplicitamente tramite un altro strumento come GetUserProfile(email)) accedere o dedurre:

• La sede di lavoro principale di ciascun partecipante.
• Il tipo di riunione (ad esempio, di persona o virtuale).
• Le implicazioni dell'importanza e della tempistica delle riunioni (ad esempio, "riunione critica del lunedì mattina").

Con l'accesso a questi "dati contestuali", dobbiamo aggiungere un elenco di istruzioni del tipo "se... allora..." al prompt principale dell'agente:

Snippet della logica del prompt dell'agente rivisto (concettuale):

"... Quando si è incaricati di programmare una riunione:

1. Raccogliere il contesto migliorato: Per ogni partecipante, determinare la sua probabile ubicazione (ad esempio, usando GetUserProfile(attendee_email)). Notare se la riunione è specificata come "di persona" e se i partecipanti sono remoti.
2. Considerare il viaggio per le riunioni di persona:
   • Se l'incontro è di persona, e un partecipante è remoto, e è stata proposta una fascia oraria mattutina (ad esempio, prima delle 10:00 ora locale della sede della riunione):
     • Quindi, segnalatelo al richiedente. Ad esempio: "Ben viaggerà da Edimburgo per questo incontro di persona. Per poter viaggiare comodamente lunedì, preferiresti iniziare la riunione alle 10:30 o più tardi, o dovrei esplorare le opzioni virtuali?".
3. Considerate il tempo di preparazione per le riunioni critiche:
   • Se una riunione è descritta come "critica", "importante" o che richiede una "preparazione significativa". e è stato programmato per una fascia oraria anticipata di lunedì (o subito dopo un giorno festivo):
     • Quindi, chiedete al richiedente una conferma. Ad esempio: "Per questa sessione critica del lunedì che richiede una preparazione, un orario di inizio alle 8:30 del mattino permetterebbe a tutti di avere abbastanza tempo il lunedì mattina stesso, o sarebbe più adatto un orario intorno alle 10:00 del mattino per consentire la preparazione in giornata?".
4. Gestire i conflitti generali tra fuso orario e orario di lavoro (come discusso in precedenza):
   • (Incorporare una logica per dare priorità alle "finestre sociali principali", gestire gli orari al di fuori di queste e chiedere conferma per gli orari scomodi in diversi fusi orari, se applicabile, anche per le riunioni virtuali).
5. Rispettare le sovrascritture esplicite dell'utente:
   • Se l'utente conferma esplicitamente un accordo scomodo (ad esempio, "Sì, Ben è al corrente e viaggerà domenica"), si procede, magari con una conferma finale: "Capito. Programmazione confermata".

Prompts: Dalle semplici descrizioni agli algoritmi complessi

Come si può vedere, il prompt del nostro agente principale si è evoluto in modo significativo. Non è più solo un elenco di strumenti disponibili. È un albero decisionale dettagliato e condizionato. È un algoritmo in miniatura espresso in linguaggio naturale. Queste affermazioni "se... allora..." diventano la spina dorsale del processo di "ragionamento" dell'agente, guidandolo non solo verso una soluzione, ma verso una soluzione migliore.

La sfida - e l'abilità emergente per gli sviluppatori - consiste nel prevedere queste potenziali insidie e nel codificare preventivamente l'"esperienza", la "politica aziendale" o la "comune cortesia" direttamente nelle istruzioni dell'LLM. Questo dimostra che, se gli LLM hanno un potere incredibile, il lavoro dello sviluppatore nel guidare questo potere verso applicazioni veramente utili e rispettose è più cruciale che mai. Si tratta di trasformare quel "tirocinante entusiasta" in un collega digitale affidabile ed esperto, una richiesta accuratamente elaborata alla volta.

In prospettiva, l'aspirazione è che questi agenti si evolvano al di là anche dei più dettagliati manuali di regole basati su prompt, consentendo loro di "imparare" veramente dai risultati delle loro azioni. Mentre oggi codifichiamo meticolosamente l'esperienza, la prossima frontiera prevede agenti in grado di perfezionare autonomamente le proprie strategie. Immaginate un agente che abbia accesso non solo a strumenti e dati per svolgere il proprio lavoro, ma anche a un feedback continuo sul successo o il fallimento di tali azioni nel raggiungere i risultati aziendali desiderati. Il nostro Assistente calendario, ad esempio, se osserva costantemente che gli inviti alle riunioni per le 12:00 vengono rifiutati da un particolare utente con la motivazione "fuori a pranzo", potrebbe imparare nel tempo a deprivilegiare o addirittura evitare di proporre questa fascia oraria per quell'individuo, senza che uno sviluppatore debba programmare esplicitamente una regola "niente riunioni a mezzogiorno per l'utente X".

Ora, estrapolate questa capacità di apprendimento a processi aziendali più complessi. Un agente inizialmente programmato con una serie di procedure per, ad esempio, l'accoglienza dei clienti o la logistica della catena di approvvigionamento, potrebbe, misurando gli indicatori di prestazione chiave e osservando i risultati del mondo reale, iniziare a identificare le inefficienze o a scoprire percorsi più ottimali. Nel corso del tempo, il sistema potrebbe perfezionare l'approccio, ridefinire le priorità o addirittura suggerire modifiche ai processi di base progettati dagli sviluppatori. Il futuro, quindi, potrebbe vedere gli sviluppatori non solo come architetti iniziali di questi comportamenti degli agenti, ma anche come coltivatori di sistemi in cui gli agenti affinano e ottimizzano progressivamente i propri "algoritmi" operativi, diventando realmente partner dinamici e in grado di apprendere nel raggiungimento degli obiettivi aziendali.

Scoprite come Akamai può alimentare i vostri carichi di lavoro AI su scala. Parlate con i nostri esperti oggi stesso.