Far dialogare sistemi software diversi è una sfida classica per gli sviluppatori. Per anni abbiamo utilizzato API con regole ben definite per farlo. Ma ora i modelli linguistici di grandi dimensioni (LLM) stanno cambiando le carte in tavola, offrendo un nuovo modo di far interagire i sistemi basato sulla comprensione del linguaggio, non solo su formati rigidi. Questo apre possibilità interessanti, ma presenta anche una nuova serie di problemi da risolvere, dimostrando ancora una volta che il lavoro dello sviluppatore non è mai veramente finito!
Vediamo cosa significa per gli sviluppatori.
Come eravamo soliti collegare i sistemi: API tradizionali
Pensate a come di solito colleghiamo i sistemi. Usiamo cose come:
- API REST: Spesso utilizzando JSON, magari con una specifica OpenAPI (Swagger), le API indicano esattamente quali dati entrano ed escono da un sistema, compresi i tipi di dati (come stringhe o numeri).
- RPC (Remote Procedure Call): Strumenti come gRPC consentono ai sistemi di chiamare funzioni l'uno sull'altro tramite elementi come i buffer di protocollo per definire esattamente ciò di cui una funzione ha bisogno e che restituisce.
- SOAP/WSDL: è un metodo più vecchio, ma si basa anche su una descrizione dettagliata (WSDL) del servizio.
- Code di messaggi (ad esempio, Kafka, RabbitMQ): Questi sistemi inviano messaggi avanti e indietro, di solito seguendo un formato specifico e concordato.
L'aspetto fondamentale è che questi metodi si basano su regole e formati espliciti. Le macchine controllano se i dati corrispondono alla struttura predefinita (lo schema o la definizione del tipo). Gli sviluppatori leggono i documenti per capire cosa fanno le API e poi scrivono il codice per chiamarle nell'ordine necessario, elaborando i dati che restituiscono. È una danza che gli sviluppatori fanno dall'avvento dell'informatica.
Paradigmi emergenti: MCP, framework di agenti e API con promemoria
Il passaggio da API tradizionali rigidamente definite alle interazioni fluide e guidate dal linguaggio degli LLM non è sempre un salto diretto verso un linguaggio naturale puro e senza vincoli per ogni componente del sistema. Al contrario, stiamo assistendo all'ascesa di potenti paradigmi e framework intermedi progettati per colmare questo divario, consentendo ai sistemi esistenti e ai nuovi servizi di diventare "LLM-consumabili".
Al centro di questi approcci emergenti c'è il concetto di API "rinforzate da prompt". Invece di richiedere a un LLM di intuire la funzionalità da zero o a uno sviluppatore di scrivere un codice adattatore complesso, "decoriamo" o "avvolgiamo" le nostre API - che si tratti di venerabili servizi REST o di nuovi endpoint gRPC - con descrizioni ricche e in linguaggio naturale. Queste descrizioni agiscono come un manuale d'uso specifico per un LLM, spiegando lo scopo dell'API, come chiamarla, quali parametri si aspetta (e in quale formato) e cosa restituisce.
Il Model Context Protocol (MCP), ad esempio, esemplifica un modo più strutturato di esporre una serie di funzionalità diverse a un piano di controllo basato su LLM. I sistemi possono dichiarare i loro servizi e le azioni che supportano, insieme a metadati e descrizioni in linguaggio naturale. Un LLM può quindi interrogare questo "menu" di funzionalità dichiarate e orchestrare le chiamate a questi servizi sottostanti in base alle richieste dell'utente o a obiettivi di livello superiore, comprendendo cosa fanno e come usarli attraverso le loro interfacce dichiarate e simili a prompt.
Ciò si collega strettamente al mondo in rapida evoluzione dei framework di agenti. Questi framework spesso forniscono l'impalcatura per costruire un agente di controllo primario, alimentato da LLM. Questo agente centrale agisce come un orchestratore o un "cervello", capace di ragionare, pianificare e delegare compiti. Il vero potere arriva quando a questo agente di controllo viene dato accesso a una serie di "strumenti" o sub-agenti.
Questi subagenti possono variare in modo significativo:
- Alcuni potrebbero essere altri agenti specializzati basati su LLM, progettati per compiti specifici come l'analisi di dati complessi o la generazione di contenuti creativi.
- Altri potrebbero essere moduli software più semplici o, soprattutto, wrapper di API tradizionali esistenti. In questo scenario, uno sviluppatore crea un wrapper leggero attorno, ad esempio, a un'API interna per la gestione degli ordini. Questo wrapper non si limita a esporre gli endpoint tecnici, ma include messaggi accuratamente realizzati che descrivono le funzioni dell'API in linguaggio naturale: "Questo strumento consente di recuperare lo stato dell'ordine. Richiede un 'order_id' come input e restituisce lo stato attuale, la data di consegna prevista e gli articoli dell'ordine".
Il filo conduttore di questi paradigmi è chiaro: l'API, che si tratti di un microservizio nuovo di zecca o di un sistema legacy esposto tramite un wrapper, non è più solo un contratto tecnico. È arricchita da uno strato di suggerimenti descrittivi. Ciò consente a un LLM che consuma (in genere un agente di controllo) di scoprire, comprendere e utilizzare dinamicamente una vasta gamma di strumenti e funzionalità. L'LLM non ha bisogno di conoscere gli intricati dettagli di implementazione di ogni strumento; deve solo comprendere la descrizione basata su prompt di come utilizzarlo. Questo cambiamento cambia radicalmente il modo in cui pensiamo all'integrazione dei sistemi e pone un'enfasi ancora maggiore sulla chiarezza, la precisione e la completezza di questi prompt descrittivi, che analizzeremo ulteriormente.
Il futuro è... diverso
Passare da API rigide e basate sul formato e persino da queste interfacce emergenti con prompt, a interazioni veramente diffuse basate sul linguaggio con i LLM è un grande cambiamento. Come sviluppatore, mi sono abituato ad avere una chiara definizione dei possibili input, output e messaggi di errore. Lavorare con gli LLM offre un'enorme quantità di funzionalità che non abbiamo mai avuto. Ma sta anche per ridefinire il modo in cui si interagisce con gli altri sistemi. Come sviluppatori, capire come creare messaggi precisi ed esaurienti per descrivere le capacità sta diventando sempre più importante, soprattutto quando costruiamo sistemi in cui più agenti AI potrebbero dover collaborare.
Commenti