Ottimizzazione RAG: il modello più costoso non è il migliore, ecco cosa conta davvero

Ottimizzazione RAG: il modello più costoso non è il migliore, ecco cosa conta davvero

Nel panorama in rapida evoluzione dei Large Language Models (LLM), l'implementazione di chatbot basati su Retrieval-Augmented Generation (RAG) è diventata una strategia chiave per le aziende che cercano di fornire risposte accurate e contestualizzate. Tuttavia, l'efficacia di questi sistemi non dipende solo dalla scelta dell'LLM, ma da una serie di fattori spesso trascurati. Un'analisi recente su un chatbot RAG di customer support ha messo in luce come il modello più costoso non sia necessariamente quello più performante, rivelando l'importanza cruciale di un'attenta valutazione e ottimizzazione dell'intera pipeline.

L'esperimento, condotto su una configurazione standard che includeva ChromaDB per il retrieval e un LLM per la generazione, ha evidenziato una lacuna comune: la mancanza di una misurazione oggettiva della qualità delle risposte. Inizialmente, un semplice script di keyword matching forniva metriche superficiali e prive di significato reale. Questo scenario è fin troppo comune in ambienti dove la velocità di deployment prevale sulla rigorosità della validazione, portando a decisioni subottimali e a un TCO più elevato nel lungo termine.

Lezioni dall'ottimizzazione del retrieval e della valutazione

Uno dei primi e più significativi apprendimenti è stato che i problemi di retrieval si mascherano spesso come difetti dell'LLM. Quando un utente pone una domanda generica, come "cosa fate?", e il bot risponde di non avere accesso a informazioni specifiche, l'istinto comune è quello di modificare il prompt o sostituire l'LLM. L'analisi ha invece rivelato che il problema risiedeva in una soglia di similarità troppo stringente (0.7 per la distanza coseno) in ChromaDB. Le domande informali non generavano embeddings sufficientemente vicini ai chunk per superare il filtro, risultando in zero documenti recuperati. L'LLM, in questo caso, riportava onestamente di non avere contesto.

La lezione è chiara: è fondamentale loggare sempre il contesto che l'LLM riceve effettivamente prima di attribuire la colpa alla generazione. Un altro punto critico emerso riguarda l'inefficacia degli evaluatori euristici. Il conteggio delle keyword o dei riferimenti alle fonti può produrre un numero, ma questo numero non ha alcuna correlazione con l'effettiva utilità per l'utente. Peggio ancora, può infondere una falsa fiducia nella validità della misurazione. La soluzione adottata è stata l'utilizzo di un LLM giudice (Claude Haiku 4.5 tramite OpenRouter), incaricato di valutare la pertinenza, l'accuratezza, l'utilità e la qualità complessiva delle risposte su una scala da 0 a 10. Questo approccio, sebbene comporti un costo di pochi centesimi per ogni ciclo di valutazione completo, si è dimostrato un'assicurazione economica e indispensabile per ottenere metriche significative.

Affinare il contesto e scegliere il modello giusto

L'ottimizzazione del contesto fornito all'LLM si è rivelata altrettanto cruciale. L'analisi ha mostrato che in alcune interazioni, il contesto includeva tre chunk FAQ quasi identici. L'implementazione di un controllo per la deduplicazione, che identificava sovrapposizioni di token superiori all'80% provenienti dallo stesso file sorgente, ha portato a un contesto più pulito e a un minor numero di token elaborati. Questo non solo ha ridotto i costi, ma ha anche eliminato le allucinazioni del bot in alcune risposte, probabilmente a causa della rimozione del "rumore" informativo.

Un'altra decisione importante riguarda il bilanciamento tra accuratezza e utilità. L'aggiunta di una regola che imponeva all'agente di dichiarare solo fatti presenti nei documenti recuperati ha aumentato l'accuratezza. Tuttavia, l'utilità è diminuita nelle situazioni di "knowledge-gap", dove il bot rispondeva "i documenti non specificano questo, contatta il supporto" invece di tentare di indovinare. Questa è la scelta giusta per un bot di supporto fattuale, ma deve essere una decisione consapevole, poiché gli utenti potrebbero percepire un peggioramento del servizio, anche se i punteggi interni indicano un miglioramento.

Infine, l'importanza di un'analisi comparativa dei modelli (model sweep) è stata dimostrata in modo inequivocabile. Partendo da Gemini 3.1 Flash Lite Preview, sono stati testati cinque modelli diversi. Gemma 4 26B ha ottenuto un punteggio superiore (7.88 contro 7.33) e ha ridotto i costi del 75% per sessione. Mistral Small 3.2 si è classificato al secondo posto. Questo evidenzia che il modello in produzione non è probabilmente sulla frontiera di Pareto in termini di costo-efficacia, e solo una misurazione rigorosa può rivelare queste opportunità. L'intero processo di valutazione è stato gestito con Neo AI Engineer, che ha costruito l'infrastruttura di test, gestito le esecuzioni e consolidato i risultati.

Implicazioni per i deployment on-premise

Questi risultati hanno implicazioni dirette per le organizzazioni che considerano deployment di LLM on-premise o in ambienti ibridi. La capacità di controllare ogni aspetto della pipeline RAG, dal retrieval alla generazione, diventa fondamentale per ottimizzare il TCO e garantire la sovranità dei dati. La scelta di un LLM più efficiente in termini di performance e costi, come dimostrato dall'esperimento con Gemma 4 26B, si traduce in minori requisiti hardware (meno VRAM, meno GPU) o in una maggiore capacità di throughput per la stessa infrastruttura.

Per chi valuta deployment on-premise, AI-RADAR offre framework analitici su /llm-onpremise per valutare i trade-off tra costi iniziali (CapEx), costi operativi (OpEx), consumo energetico e performance. La possibilità di eseguire test comparativi approfonditi, come quello descritto, è essenziale per identificare la configurazione ottimale che rispetti i vincoli di budget, sicurezza e latenza. La gestione interna di queste pipeline consente un controllo granulare sui dati sensibili e sulla compliance, aspetti critici per settori regolamentati. L'investimento in strumenti di valutazione robusti e in una metodologia di testing rigorosa è un passo necessario per massimizzare il ritorno sull'investimento in infrastrutture AI self-hosted.