Qual è la differenza tra RAG e fine-tuning?
Il RAG inserisce nel prompt al momento della query passaggi esterni rilevanti, così che il modello risponda da dati attuali o proprietari su cui non è mai stato addestrato, mentre il fine-tuning modifica i pesi del modello su un dataset curato per adattarne comportamento, formato o stile. Il RAG è lo strumento giusto quando il requisito è conoscenza fresca o privata con citazioni, perché puoi aggiornare il corpus senza riaddestrare. Il fine-tuning è giusto quando servono formato, tono o comportamento coerenti su un compito ristretto che il solo prompting non raggiunge. Sono complementari: molti sistemi in produzione fanno fine-tuning per il comportamento e usano il RAG per la conoscenza, e dovresti esaurire il prompt engineering prima di ricorrere a uno dei due.
Come riduco le allucinazioni in un'applicazione LLM?
Le allucinazioni si riducono ancorando il modello al contesto recuperato e istruendolo a rispondere solo da quel contesto, a citare i passaggi che usa e a dichiarare di non sapere quando il contesto è insufficiente. Migliora prima il recupero, perché il generatore non può usare evidenza che il retriever non fa mai emergere; aggiungi re-ranking e ricerca ibrida per aumentare la precisione. Poi imponi l'astensione nel system prompt e misura la faithfulness con un LLM-as-judge rispetto al contesto fornito, così da ridurre il tasso di allucinazione rilascio dopo rilascio. Nessun singolo trucco elimina l'allucinazione; è un problema stratificato di recupero, prompting e valutazione.
Quale dimensione di chunk dovrei usare per il RAG?
Non esiste una dimensione di chunk ottimale universale; dipende dai tuoi documenti e dalle tue query, quindi va misurata sul tuo eval set anziché copiare un numero. Come punto di partenza, passaggi di circa 300-600 caratteri (poche frasi) con una piccola sovrapposizione funzionano bene per il question answering, perché chunk troppo grandi diluiscono la rilevanza e sprecano token mentre chunk troppo piccoli perdono il contesto necessario a rispondere. La suddivisione consapevole della struttura per intestazioni o paragrafi di solito batte le finestre cieche a dimensione fissa. Regola dimensione e sovrapposizione osservando recall del recupero e faithfulness, non l'intuito.
Come valuto un sistema RAG?
Costruisci un eval set golden di domande rappresentative abbinate a risposte di riferimento e ai passaggi di grounding che le supportano, poi valuta ogni risposta generata per faithfulness (è supportata dal contesto recuperato?), answer relevancy (risponde alla domanda?) e context recall (il recupero ha fatto emergere l'evidenza necessaria?). Framework come RAGAS, promptfoo e DeepEval automatizzano queste metriche, spesso usando un LLM come giudice. Fai da gate ai rilasci con una soglia minima di faithfulness e tratta l'eval set come immutabile perché la misura resti onesta. Valuta recupero e generazione separatamente, perché un retriever debole pone un tetto alla qualità delle risposte per quanto buono sia il generatore.
Quando usare un agente invece di un workflow fisso?
Usa il pattern più semplice che risolva il problema: un singolo prompt, poi un workflow fisso (concatenazione di prompt, routing, parallelizzazione) e solo un agente autonomo quando il compito richiede davvero che il modello decida i propri passi a runtime. Gli agenti aggiungono flessibilità per compiti aperti ma costano di più in token e latenza e sono più difficili da rendere affidabili, perché il controllo del flusso è delegato a un modello non deterministico. Se puoi esprimere il compito come una sequenza prevedibile di passi, un workflow sarà più economico, veloce e facile da debuggare. Riserva gli agenti ai casi in cui il percorso non può essere noto in anticipo.
Come posso controllare il costo di una funzionalità LLM?
Le leve maggiori sono instradare le richieste facili a un modello più piccolo ed economico riservando il modello più potente a quelle difficili; usare il prompt caching per prefissi stabili come system prompt lunghi o documenti; e mantenere brevi gli output, dato che la generazione è il costo dominante. Riduci il contesto recuperato con il re-ranking invece di riempire la finestra, e fai cache delle risposte complete per query identiche ripetute. Misura il costo per richiesta end to end, non solo per token, perché embedding, ricerca vettoriale e re-ranking si sommano. Il costo totale di proprietà si vince con routing dei modelli, caching e disciplina sulla dimensione del contesto molto più che contrattando sul prezzo per token.
Cos'è la prompt injection e come mi difendo?
La prompt injection è un attacco in cui un input non fidato - testo dell'utente, un documento recuperato o il risultato di uno strumento - porta istruzioni che scavalcano il tuo system prompt e dirottano il comportamento del modello; l'injection indiretta nasconde quelle istruzioni dentro contenuti che il modello legge. Non esiste una difesa perfetta, quindi usa la difesa in profondità: tieni le istruzioni fidate nettamente separate dai dati non fidati, dai agli strumenti il privilegio minimo necessario, valida e vincola ogni chiamata e ogni output, e non eseguire mai l'output del modello (SQL, shell, codice, pagamenti) senza un controllo indipendente. Tratta tutto ciò che il modello legge come potenzialmente ostile. Monitoraggio e un modello guardiano separato aggiungono ulteriori livelli.
Conviene usare modelli open-source o un'API gestita?
Le API gestite (Claude, GPT, Gemini) ti danno i modelli più potenti senza infrastruttura da gestire e sono di solito la via più rapida a una funzionalità funzionante, a un costo per token e con i dati che escono dal tuo perimetro. Auto-ospitare modelli a pesi aperti (Llama, Mistral, Qwen) tiene i dati on-premise e può costare meno a volume alto e costante, ma sei tu a possedere la capacità GPU, lo scaling e il divario di qualità. La decisione dipende dai requisiti di privacy, dal volume sostenuto, dalla qualità che il tuo compito richiede davvero e dalla maturità operativa del tuo team. Molti team prototipano su un'API e auto-ospitano più tardi solo dove privacy o costo lo giustificano chiaramente.
Qual è la differenza tra embedding e database vettoriale?
Un embedding è il vettore numerico denso che rappresenta il significato di un testo, prodotto da un modello di embedding; un database vettoriale è il sistema che memorizza quei vettori ed esegue una rapida ricerca approssimata dei vicini più prossimi su di essi, di solito con filtraggio per metadati. Gli embedding li generi una volta in fase di ingestione e al momento della query, e il database vettoriale è ciò che rende rapido recuperare quelli più vicini su larga scala. Scegliere un modello di embedding incide sulla qualità del recupero; scegliere uno store vettoriale incide su scala, costo, filtraggio e operatività. Sono decisioni distinte ed entrambe contano per il RAG.
Come evito che il mio corpus RAG diventi obsoleto?
Tratta il corpus come un indice vivo: traccia quando ogni chunk è stato recuperato o ingerito, ricalcola gli embedding e reindicizza quando i documenti sorgente cambiano, e rimuovi o sostituisci i contenuti datati anziché lasciarli competere con informazioni attuali. Il drift - obsolescenza del corpus, spostamento delle intenzioni degli utenti e aggiornamenti silenziosi del modello del provider - degrada la qualità in modo silenzioso, perciò monitora la faithfulness delle risposte rispetto a un eval set fisso per coglierlo prima degli utenti. Versiona i contenuti così che una correzione crei una nuova versione invece di mutare la storia. La reindicizzazione pianificata più la valutazione continua sono il modo in cui un RAG in produzione resta accurato nel tempo.
Quale temperatura dovrei impostare in produzione?
Per il question answering fattuale, l'output strutturato, l'estrazione e il tool calling usa una temperatura bassa (spesso da 0 a 0,3) perché vuoi output coerenti, focalizzati e ripetibili; temperature più alte aggiungono varietà che aiuta il brainstorming ma danneggia l'affidabilità. La temperatura cambia solo la casualità del campionamento dei token, non la correttezza del modello, quindi non è una manopola di qualità - è una manopola di determinismo. Abbina temperatura bassa a grounding e validazione per compiti in cui la risposta deve essere giusta. Per la generazione creativa, alzala deliberatamente e accetta la variabilità.
Come dovrei gestire l'output strutturato di un modello?
Definisci esplicitamente la forma desiderata - tramite uno schema di funzione/strumento, la modalità JSON o la decodifica vincolata - e poi valida l'output del modello rispetto a quello schema nel codice anziché fidarti che sia conforme. I modelli emettono occasionalmente JSON malformato o non conforme allo schema, quindi analizza in modo difensivo e riprova o ripara in caso di errore. Mantieni gli schemi piccoli e univoci quanto il compito consente, perché schemi troppo grandi aumentano i tassi di errore. L'output strutturato affidabile è la combinazione di uno schema chiaro, di una funzione del modello che vincola la generazione e di un validatore programmatico al confine.
Quali metriche dovrei monitorare per un sistema LLM in produzione?
Monitora la latenza (time-to-first-token e totale, a p50/p95/p99), l'uso dei token e il costo per richiesta, i tassi di errore e di rate limit (429), e segnali di qualità come la faithfulness campionata da un LLM-as-judge, oltre al feedback degli utenti come pollici e rigenerazioni. Cattura tracce per richiesta con prompt completo, contesto recuperato, chiamate agli strumenti e output, perché lo stesso input può produrre output diversi e non puoi debuggare ciò che non hai registrato. Sorveglia il drift rieseguendo un eval set fisso su base programmata. L'observability per sistemi non deterministici si costruisce su un tracing completo, non solo su contatori aggregati.
Perché il mio sistema RAG recupera i passaggi sbagliati?
Le cause più comuni sono chunk troppo grandi o troppo piccoli, un modello di embedding poco adatto al tuo dominio, l'assenza di segnale lessicale per termini esatti e token rari, e la mancanza di re-ranking così che i candidati rumorosi restino in cima. Diagnostica ispezionando i passaggi effettivamente recuperati per le domande dell'eval che falliscono, anziché tirare a indovinare. Aggiungi la ricerca ibrida per combinare recall di keyword e vettoriale, aggiungi un re-ranker cross-encoder per migliorare la precisione e ritara il chunking. La qualità del recupero pone un tetto rigido alla qualità delle risposte, quindi sistemala prima di incolpare il generatore.
Come rendo sicure e affidabili le chiamate agli strumenti di un agente?
Vincola lo spazio delle azioni al set minimo di strumenti necessari al compito, dai a ogni strumento il privilegio minimo richiesto e valida ogni argomento che il modello propone prima di eseguirlo - non eseguire mai SQL, shell o codice generati dal modello senza controlli. Poni un tetto al numero di iterazioni così che un agente non possa iterare all'infinito, e rendi idempotenti le azioni con effetti collaterali (per esempio con una chiave di idempotenza) perché agenti non deterministici e retry possono emettere la stessa chiamata più di una volta. Registra ogni chiamata a strumento e il suo risultato per l'observability. Gli agenti affidabili nascono da scoping stretto, validazione rigorosa e loop limitati, non dal solo prompt più astuto.
Cos'è il Model Context Protocol e perché conta?
Il Model Context Protocol (MCP) è uno standard aperto introdotto da Anthropic che definisce come le applicazioni espongono strumenti, risorse e prompt ai client LLM attraverso un'interfaccia comune, così che un agente possa connettersi a molte sorgenti di dati e strumenti senza codice di integrazione su misura per ciascuno. Un server dichiara le proprie capacità e un client - un IDE, un'app di chat o un runtime di agente - le scopre e le invoca. Conta perché standardizza il livello di integrazione di cui ogni agente ha bisogno, riducendo la colla su misura e rendendo gli strumenti riutilizzabili tra applicazioni. Sta diventando un modo comune per collegare contesto e azioni nei sistemi LLM.