Architetture

Un punto centrale, e troppo spesso sottovalutato, che riguarda l’architettura di una soluzione RAG è chi si occupa dell’AI generativa?
Il mio fornitore mi sta vendendo un sistema di integrazione con OpenAI, Claude o altri grandi cloud, oppure dispone di un’infrastruttura dedicata che acquisisce i dati e li espone a un chatbot che vive nell’infrastruttura?

Vediamo i due scenari più in dettaglio.

Sistema di integrazione con cloud esterni

Il fornitore non dispone di un’infrastruttura di AI generativa, ma inoltra tutte le elaborazioni verso cloud esterni. L’investimento che ha fatto è molto più limitato e con esso spesso anche il costo della prima implementazione.

È importante precisare che questo non lo mette necessariamente in un livello di competenze più basso: anche se non controlla direttamente la generazione, deve conoscere la materia in modo approfondito. Un’integrazione con le API ben sviluppata richiede competenze avanzate e molto specifiche. Si tratta solo di una diversa strategia, che però per te ha delle implicazioni importanti.

Se sei un professionista o un’azienda devi porre estrema attenzione a non condividere mai informazioni riservate, segreti industriali e dati sensibili dei clienti con piattaforme gestite da aziende extraeuropee, sulle quali hai un controllo limitato riguardo all’infrastruttura, alla localizzazione effettiva dei trattamenti e alle politiche di gestione dei dati. Si pensi, ad esempio, agli obblighi derivanti dal GDPR, e al possibile impatto.

Ma, indipendentemente dalla normativa, pensa alla reazione del tuo cliente che venisse a sapere che la sua corrispondenza o i suoi bilanci sono stati inviati a OpenAI. O pensa alla reazione della RTI se sapesse che hai appena mandato l’offerta di gara di un appalto milionario con la P.A. a Gemini. Questo non è serio e non è professionale.

Se la finalità è quella di esporre un chatbot pubblico tutto il problema non si pone e, ovviamente, il controllo dei contenuti lo devi fare in ogni caso. Ma se il RAG ha un uso interno all’azienda e serve proprio per elaborare dati riservati, senza queste garanzie l’asset complessivo sarà del tutto inutile.

Dal punto di vista economico questi servizi hanno costi basati sul consumo di token, le unità elementari di testo che il modello utilizza per elaborare le richieste e generare le risposte: più è lungo il testo inviato e più è lunga la risposta prodotta, maggiore sarà il numero di token elaborati e quindi il costo della richiesta.

Scegliendo un modello datato e, in generale, a basse prestazioni, i costi sono irrisori: si parla generalmente di pochi centesimi per milione di token in uscita. Ma la qualità del ragionamento e dell’interazione nei RAG specialistici, ad esempio in materia normativa e fiscale, medica e farmaceutica, ingegneristica o brevettuale, risulterà spesso insufficiente. I modelli in grado di garantire questi standard hanno costi per token che possono arrivare a decine di dollari per milione in uscita (50-60$ e oltre nei modelli più avanzati).

Il fornitore può quindi, alternativamente:

• escludere la copertura degli abbonamenti verso i cloud: in questo caso dovrai sopportare un costo mensile non prevedibile, che per modelli evoluti e in periodi di traffico consistente può raggiungere anche migliaia di euro
• includere tutto nel contratto di assistenza e manutenzione e mantenere una tariffa fissa: ma in questo caso, quando il volume di richieste sarà superiore a quello previsto, il fornitore potrebbe scegliere di scalare su modelli più economici, pregiudicando drasticamente la qualità dell’interazione

Alcuni operatori adottano la strategia di scalare il modello a seconda della complessità della domanda: la soluzione però non è priva di criticità. Queste valutazioni non sono deterministiche e il modello non riesce sempre a classificare il livello di complessità della domanda nel modo migliore. Il rischio di instradare una domanda a un modello non sufficientemente avanzato porta a risposte sbagliate e allucinazioni: questo non è sostenibile in un RAG tecnico.

Sistema integrato

In questo scenario il fornitore dispone di una propria infrastruttura AI, ospitata presso il cliente o in un’infrastruttura dedicata, che acquisisce i documenti, li indicizza e li rende interrogabili senza demandare l’elaborazione delle richieste ai grandi servizi cloud esterni.

Il primo vantaggio riguarda il controllo dei dati: le informazioni rimangono all’interno dell’infrastruttura prevista dal progetto e non vengono trasmesse, per l’elaborazione delle risposte, a piattaforme gestite da terzi. Questo semplifica gli aspetti legati alla riservatezza delle informazioni e rende molto più semplice affrontare i temi della governance dei dati e della conformità normativa.

Anche dal punto di vista economico cambia completamente il modello di costo: l’utilizzo dell’intelligenza artificiale non dipende più dal consumo di token fatturati da un provider esterno, ma dalle risorse computazionali necessarie a far funzionare l’infrastruttura (hardware, energia elettrica, manutenzione e aggiornamento dei modelli).

Questo significa che il costo operativo tende a essere stabile e prevedibile anche in presenza di un elevato numero di interrogazioni: se cento utenti interrogano contemporaneamente il sistema, il costo non cresce in modo proporzionale al numero di token consumati, ma dipende principalmente dal dimensionamento dell’infrastruttura.

Naturalmente questo approccio richiede un investimento iniziale maggiore: l’infrastruttura deve essere progettata e dimensionata correttamente, i modelli devono essere aggiornati nel tempo e il fornitore deve possedere competenze specifiche nella gestione dell’intelligenza artificiale, non limitandosi a integrare servizi sviluppati da terzi.

Per questo motivo è importante chiedere al fornitore quale modello di intelligenza artificiale utilizza, dove viene eseguito, chi ne gestisce gli aggiornamenti e quali garanzie offre sulla continuità delle prestazioni nel tempo.

La nostra soluzione

VRS (Vocra RAG System) si classifica come Sistema integrato: tutto il processo generativo risiede sui nostri server. VRS, però, può anche inoltrare le elaborazioni verso cloud esterni esclusivamente per la tipologia di contenuti pubblici indicati dal cliente.

Il sistema sfrutterà sempre i modelli interni ma, in casi eccezionali di sovraccarico e per i soli contenuti di pubblico dominio, può scalare su modelli cloud. L’architettura fa sì che si possano sfruttare sempre modelli di punta, essendo il loro utilizzo previsto solo in casi di eccezionalità. Laddove il traffico fosse tale da rendere frequenti questi casi, si provvederà a potenziare il sistema adeguatamente per farli tornare a essere eventi straordinari.

In altre parole, non si devono verificare mai situazioni di stallo dovute a un carico di richieste contemporanee fuori dal range previsto: il dimensionamento delle risorse hardware dei server rientra nella manutenzione a nostro carico.

Per i contenuti non pubblici, invece, non sarà mai prevista esternalizzazione e si accetta la possibilità del verificarsi di code. Considera che, dato che questi servizi saranno esposti solo in LAN e a un numero limitato di utenti, normalmente sarà molto più improbabile raggiungere situazioni di carico elevate.

Il documento ha lo scopo di indicare le linee direttrici principali, ma sono ovviamente valutazioni che dovranno essere fatte caso per caso. Quanto descritto è una fotografia, molto in prosa, dello scenario attuale, e ti invitiamo a usarlo come punto di partenza per un approfondimento sulle fonti che preferisci.