Vai al contenuto
Blog

AI

Singola Chiamata LLM vs. Catene di Agenti Multi-Step

Le catene di agenti AI multi-step sembrano impressionanti nelle demo, ma spesso costano di più e falliscono più spesso rispetto a una singola chiamata LLM ben progettata. Ecco come decidere.

Di Pykero Agency · Engineering team19 lug 20266 min di lettura

TL;DR

Per default, si utilizzi una singola chiamata LLM ben definita, con un prompt solido e output strutturato; si aggiunga il chaining multi-step solo quando un'attività richiede davvero decisioni sequenziali o chiamate a strumenti che il modello non può gestire in un unico passaggio. Le catene moltiplicano latenza, costi e punti di failure senza un guadagno proporzionale in termini di accuratezza per la maggior parte dei casi d'uso aziendali.

monitor sala di controllo dashboard, Singola Chiamata LLM vs. Catene di Agenti Multi-Step

Una singola chiamata LLM ben progettata batte quasi sempre una catena di agenti multi-step su costo, latenza e affidabilità — a meno che l'attività non richieda davvero che il modello osservi un risultato intermedio prima di decidere cosa fare dopo. La maggior parte delle funzionalità "agente" che i founder ci chiedono di costruire non hanno questa necessità. Hanno bisogno di un buon prompt con output strutturato.

Perché le catene sono comunque il default

Le catene multi-step sono seducenti perché rispecchiano il modo in cui un essere umano risolverebbe il problema: ricerca, poi bozza, poi revisione, poi correzione. I framework rendono facile collegare quattro chiamate LLM con un planner davanti, e nelle demo funziona bene. Abbiamo costruito esattamente questa struttura per il nostro sistema di cold outreach: estrai i dati dell'azienda, poi sintetizza, poi scrivi l'email, poi un passaggio separato di "rifinitura" — quattro hop perché è così che lo farebbe una persona a cui si affida il lavoro un passo alla volta.

È anche il punto in cui questa struttura si rompe. Ogni hop è:

  • Un nuovo punto in cui perdere contesto. Il nostro step di "sintesi" vedeva solo l'output dello step di estrazione, non la pagina originale, quindi al momento della stesura dell'email si lavorava su un riassunto di un riassunto, con perdita di informazioni.
  • Una nuova tassa di latenza. Quattro chiamate sequenziali da 2-3 secondi ciascuna significano oltre 10 secondi prima che l'utente veda qualcosa, ancora prima di aggiungere i retry.
  • Una nuova superficie di failure. Nella nostra pipeline, lo step di "rifinitura" riscriveva regolarmente dettagli che lo step di estrazione aveva ottenuto correttamente, perché non aveva visibilità sul perché la bozza dicesse quello che diceva — vedeva solo una bozza e il mandato di migliorarla.

Le indicazioni di Anthropic su questo punto sono dirette: si inizi con la soluzione più semplice e si aggiunga complessità agentica — pianificazione multi-step, cicli di strumenti — solo quando una singola chiamata con buon contesto non è davvero sufficiente (Building Effective Agents). Non è una posizione di comodo: è il pattern che regge in produzione.

Cosa abbiamo imparato gestendo il nostro motore di outreach

Gestiamo un sistema di cold outreach interno: fa lo scraping del sito di un prospect con un'istanza self-hosted di Firecrawl e un LLM locale, poi scrive un'email personalizzata per ogni azienda. La nostra prima versione suddivideva il processo in fasi — estrai i dati aziendali, poi sintetizza, poi scrivi l'email, poi un passaggio separato di "rifinitura". Era più lento, costava più token per lead, e lo step di rifinitura sovrascriveva regolarmente dettagli che lo step di estrazione aveva ottenuto correttamente, perché non aveva visibilità sul perché la bozza dicesse quello che diceva.

Abbiamo collassato tutto in una singola chiamata: estrarre i dati e scrivere l'email in un unico prompt, con i campi di estrazione specificati come output strutturato prima del corpo dell'email. Il costo per lead è sceso e la qualità è migliorata — perché il modello manteneva il contesto completo, ovvero la pagina scraped effettiva, non un riassunto approssimativo, per tutta la durata della scrittura. La lezione si generalizza oltre l'outreach: se il vostro "agente" non fa altro che trasformare un input in un output senza decisioni intermedie con branching, suddividerlo in step è puro overhead.

Un test semplice prima di concatenare qualsiasi cosa

Ci si chieda se l'attività ha un punto di decisione che dipende da informazioni che il modello non ha ancora. Se sì, è probabile che serva almeno un ciclo — il modello deve agire, vedere cosa è successo, poi decidere l'azione successiva. Se no, l'input di ogni step è completamente noto prima dell'esecuzione del modello, e appartiene a una singola chiamata con un buon prompt, oppure a una pipeline di codice deterministica con l'LLM che gestisce una parte chiaramente definita.

Esempi che richiedono davvero l'iterazione:

  • Un agente che fa debug di codice contro una test suite in errore (deve eseguire il test per sapere cosa correggere)
  • Un agente che naviga un sito web dove il click successivo dipende da ciò che si trova nella pagina corrente
  • Un agente di supporto che deve fare una domanda di chiarimento prima di poter agire

Esempi che non ne hanno bisogno, indipendentemente da quanto sembrino "agentici" nel pitch deck:

  • Riassumere un documento ed estrarne campi strutturati
  • Classificare e smistare un ticket di supporto
  • Scrivere un'email, una spec o un aggiornamento di stato da input noti

Trattiamo la versione più ampia di questa decisione — quando un'attività è un workflow rispetto a un vero agente — nel nostro approfondimento su agenti vs. workflow. Se state scegliendo tra costruire in-house e acquistare una piattaforma, agente custom vs. piattaforma chatbot copre questa decisione adiacente.

I conti che interessano davvero ai founder

Le catene costano di più in tre modi che si sommano — il nostro pipeline di outreach li ha pagati tutti e tre prima che lo collassassimo:

  1. Costo in token. Ogni chiamata invia nuovamente il contesto (system prompt, output precedenti) per cui una singola chiamata pagherebbe una volta sola. La nostra versione a quattro step reinviava il riassunto della pagina scraped a ogni hop; la versione a singola chiamata paga la pagina completa una volta sola.
  2. Costo dei retry. Se uno step nella catena fallisce o restituisce output malformato, si fa il retry di quello step (aggiungendo latenza) o dell'intera catena (aggiungendo costo). Quando il nostro step di "rifinitura" restituiva qualcosa di malformato, la soluzione era rieseguirlo — ma a quel punto gli step di estrazione e bozza erano già stati eseguiti e pagati. Una singola chiamata fallisce una volta, non quattro.
  3. Costo di engineering. La nostra versione a quattro stage richiedeva codice di orchestrazione e passaggio di stato tra estrazione, sintesi, bozza e rifinitura — codice che è scomparso completamente una volta che abbiamo unito tutto in un unico prompt con output strutturato. Questa è una superficie di manutenzione continua, non solo un costo di sviluppo iniziale.

Se state stimando quanto costerà far girare una funzionalità AI a volume, è opportuno modellare entrambe le architetture su input campione reali prima di impegnarsi — si veda la nostra guida all'ottimizzazione dei costi LLM per come strutturare questa stima. Abbiamo anche scritto della domanda di due diligence che emerge quando un vendor vi propone un sistema multi-agente: chiedete di giustificare ogni hop, nel modo descritto in evals nei contratti con vendor AI.

L'output strutturato fa la maggior parte di ciò che i "planning step" promettono di fare

Molto di ciò per cui si usano le catene multi-step — estrai questo, poi formatta quello, poi valida quell'altro — si risolve meglio con l'output strutturato: un JSON schema o una specifica di function calling che il modello compila in un unico passaggio. I modelli moderni sono affidabili nel restituire dati strutturati ben formati quando si specifica chiaramente lo schema, il che elimina il principale motivo per cui i team ricorrono a uno "step di validazione". Si aggiunga un controllo deterministico a livello di codice dopo la singola chiamata (questo campo è parsabile? questo valore è nell'intervallo atteso?) invece di una seconda chiamata LLM per verificare il lavoro della prima.

Dove ci posizioniamo

Per default, una chiamata sola. Le si fornisca tutto il contesto necessario, si richieda output strutturato e si validi deterministicamente. Si ricorra a una catena — o a un vero ciclo agente con tool use — solo quando l'attività ha un punto di decisione reale che dipende da qualcosa che il modello non può sapere finché non agisce. Questa è una categoria più ristretta di quanto la maggior parte delle demo di agenti suggerisca, ed è la differenza tra una funzionalità AI economica e semplice da gestire e una che brucia silenziosamente budget ogni volta che rilegge il proprio output.

Se state definendo lo scope di una funzionalità AI e non siete sicuri da quale parte di quella linea si collochi, contattateci.

ai agentsllm architectureagent orchestrationcost optimization

Domande frequenti

Quando conviene davvero una catena di agenti multi-step?

Quando l'attività richiede che il modello esegua un'azione, osservi il risultato e decida il passo successivo — come navigare un sito web multi-pagina o fare debug di codice contro una test suite. Se ogni step è noto in anticipo, si tratta di una pipeline, non di un agente, e il chaining non è necessario.

Un'architettura a singola chiamata aumenta il rischio di allucinazioni?

Non intrinsecamente: una singola chiamata con output strutturato (JSON schema, function calling) e vincoli chiari è generalmente più affidabile di una catena, perché ogni hop nella catena rappresenta una nuova opportunità per il modello di deviare dal contesto originale.

Come si stima il costo prima di scegliere un'architettura?

Si realizzino prototipi di entrambe le versioni su 20-30 input reali, si registrino i conteggi di token e la latenza per ogni esecuzione, e si moltiplichi per il volume mensile atteso. Le catene tendono a costare 3-8x i token rispetto a una singola chiamata equivalente, una volta calcolati i retry.

Si può partire con una catena e semplificare in seguito?

Sì, ed è spesso l'ordine giusto: si rilasci la catena per capire cosa richiede davvero l'attività, poi si collassino in un'unica chiamata gli step che si rivelano deterministici o ridondanti.

Come può aiutare Pykero

Servizi collegati a questo articolo.

State costruendo qualcosa di simile?

Pykero Agency progetta e rilascia prodotti web, mobile, SaaS e AI pronti per la produzione.

Parliamone

Discussion

Be the first to comment.

Letture correlate