Il nuovo kit di strumenti: LLM, prompt e interazione con gli strumenti di base

Gli LLM interagiscono in modo diverso. Invece di verificare semplicemente i dati rispetto a uno schema, un LLM legge una descrizione in linguaggio semplice di ciò che uno strumento o un altro sistema può fare. Come sviluppatore, devo esporre le informazioni che un LLM chiamante può leggere, consumare e infine usare per capire come utilizzare la mia interfaccia. Non si fornisce all'LLM uno schema rigido. Si fornisce invece una descrizione che include lo scopo dello strumento, gli input e i risultati attesi.

L'LLM utilizza la sua comprensione del linguaggio per capire come utilizzare lo strumento in base a questa descrizione. È come passare dalla verifica di un modulo rigido alla comprensione di istruzioni verbali. Questo è più flessibile, soprattutto per i compiti meno strutturati, ma significa che l'interazione dipende dall'interpretazione, che può essere meno prevedibile rispetto ai formati rigidi. Questa metodologia viene utilizzata in diversi ambiti, dal Model Context Protocol (MCP) all'Agent Development Kit open-source di Google, di cui ho parlato nel mio ultimo blog.

I prompt sono i nuovi "documenti API".

Quindi, per gli LLM, il "contratto API" o la documentazione è essenzialmente il messaggio che si scrive per descrivere lo strumento o la funzionalità. Invece di scrivere annotazioni sul codice o file di schema, gli sviluppatori scrivono ora descrizioni chiare e dettagliate che indicano all'LLM:

• Cosa fa: La funzione principale dello strumento.
• Cosa serve: Gli input richiesti, magari con esempi o suggerimenti sul formato.
• Cosa restituisce: Il risultato o l'azione attesa.
• Qualsiasi regola: Vincoli o linee guida importanti.

Ciò significa che l'ingegneria dei messaggi sta diventando un'abilità cruciale. Affinché questi sistemi funzionino, è indispensabile che i team di sviluppo siano in grado di scrivere istruzioni che i LLM possano comprendere e agire in modo affidabile.

Un semplice esempio: Uno strumento di "assistente di calendario" per un LLM

Immaginiamo uno strumento più dinamico, come un assistente di calendario, e descriviamolo per un LLM:

Descrizione generale dello strumento: "Si tratta di uno strumento di assistenza al calendario. Può programmare nuove riunioni e trovare le fasce orarie disponibili per un gruppo di persone".

Funzione 1: Crea riunione Prompt: Nome dello strumento: CreateMeeting. Descrizione: Pianifica una nuova riunione nel calendario. Input richiesti: attendees (un elenco di indirizzi e-mail), subject (testo del titolo della riunione), startTime (la data e l'ora di inizio della riunione; cercare di interpretare orari relativi come "domani alle 15" o "lunedì mattina prossimo"), e duration (testo che descrive la durata, ad esempio "1 ora", "30 minuti"). Input opzionale: luogo (testo, ad esempio, "Sala conferenze B" o un link per la videochiamata). Risponde con un messaggio di conferma che include i dettagli finali della riunione o un errore se la pianificazione non riesce (ad esempio, conflitto di orario, partecipanti non validi). Se l'orario di inizio o la durata sono ambigui, chiedere all'utente un chiarimento prima di procedere. Si presume che gli orari siano nel fuso orario locale dell'utente, a meno che non sia specificato diversamente.

Come il LLM potrebbe utilizzarlo (dopo aver interpretato la richiesta dell'utente): CreateMeeting(partecipanti=["alice@example.com", "bob@example.com"], subject="Project Sync", startTime="2025-05-02T15:00:00", duration="45 minutes", location="Video Call")

Funzione 2: FindFreeTime Prompt: Nome dello strumento: FindFreeTime. Descrizione: Trova le fasce orarie comuni disponibili per un gruppo di persone in un intervallo di tempo specificato. Input richiesti: attendees (un elenco di indirizzi e-mail) e duration (testo che descrive la durata della riunione desiderata, ad esempio "1 ora"). Input facoltativo: timeWindow (testo che descrive quando cercare, ad esempio, "la prossima settimana", "questo venerdì pomeriggio", "entro i prossimi 3 giorni"; se non è specificato, il valore predefinito è la settimana lavorativa corrente). Risponde con un elenco di orari di inizio disponibili (data e ora) o con un messaggio che indica che non sono stati trovati orari comuni. Se si utilizza una finestra relativa come "la prossima settimana", è necessario specificare l'intervallo di date da ricercare. Assume che gli orari siano nel fuso orario locale dell'utente, a meno che non sia specificato diversamente.

Come il LLM potrebbe utilizzarlo (dopo aver interpretato la richiesta dell'utente): FindFreeTime(attende=["alice@example.com", "bob@example.com", "charlie@example.com"], duration="1 hour", timeWindow="next Tuesday")

In questo caso, i prompt guidano il LLM su come gestire gli elenchi, interpretare input potenzialmente confusi come date e durate e persino quando chiedere chiarimenti. Questo è più vicino a come funzionano le interazioni tra strumenti LLM nel mondo reale.

La sfida: Ambiguità e precisione del prompt (per la terza parte di questa serie)

La prima volta che uno sviluppatore crea uno strumento come questo, pensa a se stesso: "È fantastico! Scrivere questi agenti è un gioco da ragazzi". E poi, come spesso accade nella vita di uno sviluppatore, la realtà ti colpisce in faccia...

Mentre i prompt dell'Assistente calendario cercano di gestire alcune incertezze (come "domani alle 15"), affidarsi alle descrizioni in linguaggio naturale può introdurre nuovi ed entusiasmanti modi per far fare al software qualcosa che non ci si aspettava.

Considerate questi esempi:

• Richiesta di CreateMeeting in conflitto:
  • Utente: "Prenota un incontro di due ore per me e Charlie questo venerdì pomeriggio, ma assicurati che sia prima delle 14".
  • Problema: "Venerdì pomeriggio" di solito implica un orario successivo alle 12.00 o alle 13.00. "Prima delle 14" crea un potenziale conflitto o una finestra molto ristretta (ad esempio, dalle 13 alle 14). Il prompt non dice esplicitamente al LLM come gestire i vincoli in conflitto all'interno di un singolo parametro come l'ora. Deve dare priorità a "pomeriggio" o "prima delle 14"? Deve presentare all'utente il conflitto?
• Richiesta di FindFreeTime vaga:
  • Utente: "Trova il tempo per una breve chiacchierata con Dave la prossima settimana".
  • Problema: cos'è una "chat veloce"? Il parametro della durata deve essere più specifico, come "15 minuti" o "30 minuti". Il prompt attuale richiede una durata e non specifica un valore predefinito o come gestire termini vaghi come "chat veloce". L'LLM potrebbe fallire o dover tirare a indovinare.
• Assunzioni implicite in FindFreeTime:
  • Utente: "Trova un'ora per la riunione del team di mercoledì prossimo".
  • Problema: chi è "il team"? L'LLM ha bisogno dell'elenco dei partecipanti (indirizzi e-mail). Il prompt lo richiede, ma la richiesta dell'utente si basa sul fatto che l'LLM conosca il contesto del "team". Un buon flusso di interazione potrebbe prevedere che l'LLM chieda: "Chi fa parte del team?" se l'elenco dei partecipanti non viene fornito o è desumibile dalla cronologia della conversazione. In questo caso l'agente chiamante potrebbe chiamare un altro agente per capire chi è "il team".
• Fusi orari non specificati:
  • Utente (a Londra): "Fissa un incontro con Priya (a New York) per le 9 di domani mattina".
  • Problema: sono le 9 del mattino ora di Londra o le 9 del mattino ora di New York? Le richieste attuali includono un'ipotesi di base ("Assumi che gli orari siano nel fuso orario locale dell'utente, se non diversamente specificato"), ma gestire correttamente i fusi orari è complesso. Cosa succede se l'utente non lo specifica e i partecipanti si trovano in fusi orari diversi? Lo strumento ha bisogno di una logica di backend sofisticata per gestire i fusi orari o di istruzioni molto più esplicite nel prompt su come richiedere e confermare le informazioni sul fuso orario se sono coinvolte più sedi. Una semplice supposizione potrebbe portare a errori di programmazione.

Questi esempi dimostrano che, anche in presenza di prompt validi, l'ambiguità delle richieste dell'utente, le informazioni contrastanti o le ipotesi non dichiarate (come i fusi orari) possono portare a errori, azioni errate o frustranti cicli di chiarimento. L'efficacia dell'interazione LLM-API dipende direttamente dalla qualità e dalla completezza del prompt che descrive le capacità e i limiti dello strumento. Deve riguardare non solo il percorso felice, ma anche come gestire vaghezza, informazioni mancanti, potenziali conflitti e dettagli contestuali come i fusi orari.

Complessità: quando più agenti di intelligenza artificiale si parlano (transizione a questioni più profonde)

Descrivere accuratamente un singolo strumento è una cosa, ma diventa molto più complicato quando ci sono più agenti AI che cercano di lavorare insieme. Come si scrivono i prompt in modo che l'agente A capisca chiaramente cosa può o non può fare l'agente B, compreso il modo in cui quest'ultimo gestisce l'ambiguità? Come si coordinano? Come ci si assicura che lavorino insieme in modo affidabile senza problemi imprevisti causati dal modo in cui interpretano le istruzioni dell'altro? Capire come definire queste interazioni in modo chiaro e affidabile usando il linguaggio è una grande sfida che stiamo affrontando con l'evoluzione di questi sistemi.

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