Qual è la differenza tra un agente AI e una semplice chiamata a un LLM?
Una singola chiamata a un LLM riceve un prompt e restituisce una risposta senza alcun controllo su cosa accade dopo. Un agente esegue un ciclo: decide un'azione (di solito una tool call), un esecutore la compie, il risultato torna indietro e il modello decide di nuovo, ripetendo finché l'obiettivo non è raggiunto o non scatta una condizione di arresto. La distinzione chiave, secondo la guida di Anthropic, è che il modello dirige dinamicamente il proprio processo e usa strumenti, mentre una chiamata semplice è one-shot. Gli agenti sono più capaci ma più difficili da testare, più lenti e più costosi, quindi li si adotta solo quando il compito richiede davvero un controllo multi-passo diretto dal modello.
Quando dovrei costruire un agente invece di un workflow fisso?
Preferisci la cosa più semplice che funziona. Se puoi esprimere il compito come una sequenza fissa di passi LLM e di codice (un "workflow"), fallo, perché i percorsi prevedibili sono più economici, più veloci e molto più facili da testare e debuggare. Ricorri a un ciclo agentico solo quando il compito richiede che il modello decida a runtime il numero e l'ordine dei passi, per esempio ricerca aperta o debugging multi-passo dove il percorso non è noto in anticipo. Molti sistemi in produzione sono per lo più workflow deterministici con uno o due passi agentici, e questo è un pregio, non un compromesso.
Come riduco le allucinazioni in un sistema RAG?
Ancora ogni affermazione fattuale a evidenze recuperate e fai sì che il modello rifiuti quando l'evidenza manca. Concretamente: migliora il recupero perché i passaggi giusti arrivino davvero nel contesto (il generatore non può usare ciò che non vede mai), istruisci il modello a rispondere solo dal contesto fornito, richiedi citazioni a passaggi specifici e aggiungi una eval di faithfulness per intercettare le regressioni. Abbassare la temperature aiuta marginalmente, ma le leve dominanti sono la qualità del recupero e un prompt che permette esplicitamente "il contesto non copre questo" invece di forzare una risposta.
Qual è la giusta dimensione dei chunk per il RAG?
Non esiste un numero universale, ma un intervallo comune ed efficace è qualche centinaio di token (circa 300-600 caratteri per chunk nella pratica), suddiviso sulla struttura naturale come paragrafi o titoli, talvolta con un piccolo overlap. Chunk troppo grandi diluiscono la rilevanza e sprecano budget di contesto; chunk troppo piccoli perdono il significato circostante che un passaggio richiede per essere autosufficiente. L'approccio affidabile è partire da quell'intervallo, misurare recall del recupero e faithfulness delle risposte sul proprio eval set e aggiustare empiricamente anziché tirare a indovinare.
Mi serve un database vettoriale o basta pgvector?
Per la maggior parte delle applicazioni pgvector (l'estensione di PostgreSQL) è sufficiente ed è spesso la scelta migliore perché tiene gli embedding accanto ai dati relazionali, in un sistema che già gestisci. I database vettoriali dedicati come Pinecone, Weaviate o Qdrant valgono il loro costo a scala molto grande, con tuning specializzato degli indici, o quando servono funzionalità che Postgres non ha. Inizia con pgvector e un indice HNSW; migra a uno store dedicato solo quando hai una ragione misurata, non per default.
Come dovrei valutare un agente o un sistema RAG?
Costruisci un eval set fisso di domande rappresentative con risposte buone note e contesti di grounding, poi valuta ogni modifica rispetto a esso come gate di regressione in CI. Per il RAG misura faithfulness (la risposta è implicata dal contesto), answer relevancy e context recall, usando un framework come RAGAS, promptfoo o DeepEval. Per gli agenti misura anche la correttezza delle tool call e il completamento del compito end-to-end. La disciplina di eseguire le eval a ogni modifica è ciò che trasforma il ritocco dei prompt in ingegneria di cui fidarsi.
Cos'è il prompt injection e come mi difendo?
Il prompt injection è un attacco in cui istruzioni avversarie nascoste nell'input dell'utente o nei contenuti che l'agente recupera (una pagina web, un documento, un'email) dirottano l'agente a ignorare le sue vere istruzioni o a usare male i suoi strumenti. La forma più pericolosa è l'injection indiretto, dove il payload vive nei dati recuperati che il modello tratta come fidati. La difesa è a strati: isola ed etichetta chiaramente i contenuti non fidati, dai agli strumenti il privilegio minimo necessario, richiedi approvazione umana prima delle azioni irreversibili e non lasciare mai che il testo recuperato sovrascriva silenziosamente le tue istruzioni di sistema. Non c'è una singola soluzione, quindi difendi in profondità.
Quanti strumenti dovrei dare a un agente?
Il minor numero possibile, ciascuno chiaramente distinto e ben documentato. Insiemi di strumenti grandi e sovrapposti confondono il modello su quale chiamare e aumentano la probabilità di chiamate sbagliate o malformate. Scrivi descrizioni precise e schemi di input stretti (enum, campi obbligatori, tipi sensati), perché lo schema è il contratto rispetto al quale il modello pianifica. Se hai molte capacità, raggruppale o instradale invece di esporre decine di opzioni piatte, e testa direttamente l'accuratezza delle tool call con le eval.
Dovrei usare un sistema multi-agente?
Di solito non come prima mossa. Più agenti specializzati possono aiutare su problemi genuinamente scomponibili, ma moltiplicano costo, latenza e complessità di coordinamento, e introducono nuove modalità di fallimento attorno agli hand-off e allo stato condiviso. La guida standard è prima spingere il più possibile un singolo agente con buoni strumenti e buon contesto; adotta il multi-agente solo quando puoi dimostrare che il design a singolo agente è insufficiente. Quando lo fai, mantieni l'orchestrazione esplicita e osservabile.
Come controllo il costo di un'applicazione agentica?
Il costo si accumula su iterazioni del ciclo e tool call, quindi la leva maggiore è ridurre il numero di passi. Usa il prompt caching per il grande prefisso statico che reinvii a ogni turno, instrada i sotto-compiti facili a modelli più piccoli ed economici, limita il contesto recuperato a ciò che serve, imposta un numero massimo di iterazioni e traccia la spesa in token per ogni run. Misurare il costo per compito sul tuo eval set, accanto alla qualità, ti permette di barattarli deliberatamente invece di farti sorprendere dalla fattura.
Cos'è il Model Context Protocol (MCP) e mi serve?
L'MCP è uno standard aperto di Anthropic per connettere applicazioni LLM a strumenti, fonti di dati e prompt attraverso un'interfaccia client-server uniforme, così scrivi un'integrazione una volta e la riusi su host compatibili con MCP. Non è strettamente necessario, puoi collegare gli strumenti direttamente tramite l'API di function calling del tuo modello, ma l'MCP riduce la colla ad-hoc per ogni strumento e rende le integrazioni portabili. È più prezioso quando hai molte integrazioni o vuoi condividere server di strumenti tra applicazioni.
Come do a un agente memoria tra le sessioni?
Distingui memoria a breve termine da quella a lungo termine. La memoria a breve termine è semplicemente la cronologia della conversazione tenuta nella finestra di contesto, tagliata o riassunta man mano che cresce. La memoria a lungo termine richiede uno store esterno: persisti fatti, preferenze o risultati passati (spesso in un database o vector store) e recupera i rilevanti nel contesto a ogni nuova richiesta. L'agente stesso è privo di stato tra le chiamate, quindi ogni persistenza è qualcosa che progetti e possiedi tu, incluso cosa scrivere, quando recuperarlo e come evitare che gonfi il contesto.
Perché il mio ciclo agentico va avanti all'infinito o accumula costi enormi?
Quasi sempre una condizione di arresto mancante o debole. Ogni ciclo agentico deve essere vincolato: un numero massimo di iterazioni, un tetto di token o costo, una soglia di errori e un segnale chiaro di "risposta finale raggiunta". Senza questi, un modello che continua a scegliere di chiamare strumenti, o che oscilla tra due azioni, ciclerà finché non esaurisce il budget. Imposta sempre un tetto rigido di iterazioni e logga ogni passo così da vedere dove si blocca.
Dovrei fare fine-tuning di un modello o usare RAG e prompting?
Prova prima prompting e RAG; fai fine-tuning per il comportamento, non per i fatti. Il RAG è lo strumento giusto per iniettare conoscenza, perché la mantiene fresca, citabile e modificabile senza ri-addestramento. Il fine-tuning brilla quando servono stile coerente, aderenza al formato o l'integrazione di un'abilità ristretta, ma è più costoso, più lento da iterare e diventa obsoleto man mano che i dati cambiano. La progressione comune è prompt, poi RAG, poi fine-tuning solo se rimane un divario misurato.
Che temperature dovrei usare per un agente?
Per gli agenti e qualsiasi compito che richiede coerenza, output strutturato o tool call affidabili, usa una temperature bassa (spesso vicina a zero) così che il comportamento sia riproducibile e più facile da testare. Temperature più alte aggiungono varietà utile per il brainstorming o la scrittura creativa ma rendono gli agenti instabili e più difficili da valutare. Tratta la temperature come un parametro che imposti deliberatamente per compito, e ricorda che interagisce con top-p, quindi cambiarli entrambi insieme intorbidisce i risultati.
Come rendo sicure da ripetere le tool call di un agente?
Rendi idempotenti le operazioni sottostanti, così eseguire una tool call due volte ha lo stesso effetto di una volta sola. Poiché gli agenti ciclano e i retry sono comuni, un'azione non idempotente (addebitare una carta, inviare un'email) può scattare più volte. Passa una chiave di idempotenza su cui l'esecutore deduplica, progetta le operazioni di scrittura per essere sicure sotto replay e proteggi le azioni davvero irreversibili dietro un passo di approvazione umana. I retry sicuri sono ciò che permette a un agente di recuperare da guasti transitori senza causare danni.
Cos'è il reranking e quando vale la pena aggiungerlo?
Il reranking è un secondo stadio di recupero che riordina un insieme iniziale di candidati con un modello più accurato ma più costoso (tipicamente un cross-encoder), portando in cima i passaggi migliori prima che raggiungano l'LLM. Vale la pena aggiungerlo quando il recupero di primo stadio restituisce risultati grossomodo rilevanti ma i migliori in assoluto non sono costantemente in cima, cosa che danneggia la qualità delle risposte e spreca budget di contesto. Il pattern è recupero vettoriale veloce di molti candidati, poi rerank fino a un piccolo insieme finale ad alta precisione.