RAG come servizio o sviluppato internamente: costi e come scegliere

La generazione aumentata dal recupero, generalmente abbreviata in RAG, è il modello alla base della maggior parte delle applicazioni aziendali di IA che rispondono usando i propri documenti: prima il sistema cerca nella vostra base di conoscenza, poi il modello linguistico scrive una risposta basata sui contenuti trovati. Agenti dell'assistenza che citano il manuale, strumenti di vendita che recuperano informazioni dalla documentazione del prodotto, assistenti interni che rispondono sulla base di policy e ticket: di solito, dietro le quinte, sono tutti sistemi RAG.

Se state valutando l’uso del RAG nella vostra azienda, vi trovate di fronte alla stessa domanda da cui parte ogni decisione tra sviluppare e acquistare: pagare un servizio che lo gestisca o realizzarlo con il vostro team? Il prezzo iniziale è un punto di partenza naturale. Per confrontare equamente le due opzioni, considerate per cosa pagherete nel tempo e chi risolverà i problemi quando si presenteranno. Un fornitore potrebbe addebitare i costi in base all’utilizzo, mentre una soluzione interna richiede infrastruttura e tempo del personale. Anche i rischi sono diversi. Nel primo caso dipendete dal fornitore per risolvere le sue interruzioni del servizio, mentre con una soluzione interna il vostro team deve diagnosticare e risolvere i problemi. Queste differenze possono fare sì che l’opzione più economica al lancio risulti più costosa dal secondo anno. Analizzeremo i costi dell’acquisto e dello sviluppo e spiegheremo quando ciascun approccio è adatto.

Cosa significa davvero «RAG come servizio»

RAG come servizio significa che un fornitore gestisce per voi la pipeline di recupero. Voi collegate i vostri documenti, il servizio li indicizza e voi inviate le domande tramite la sua API o interfaccia. Il fornitore gestisce gli embedding, il database vettoriale, la logica di recupero, le chiamate al modello, gli aggiornamenti e la disponibilità del servizio. Il vostro team gestisce i documenti, le regole di accesso e le risposte fornite dal sistema.

L’ambito varia in base al fornitore. Alcuni servizi sono versioni in hosting di una pipeline standard: caricate i documenti, ponete le domande e ricevete risposte basate sulle fonti. Altri sono più simili a una piattaforma: connettori ai sistemi esistenti, recupero consapevole delle autorizzazioni, dashboard per la valutazione e code per la revisione umana. La distinzione è importante per i costi, perché una semplice pipeline in hosting e una piattaforma aziendale governata hanno prezzi da prodotti diversi, anche quando entrambe si definiscono RAG come servizio. Prima di confrontare i prezzi, chiedete cosa è incluso: indicizzazione, connettori, gestione delle autorizzazioni, valutazione, supporto e residenza dei dati sono spesso voci separate anziché parte del canone base.

Cosa significa davvero «sviluppare internamente»

Sviluppare internamente significa che il vostro team possiede la pipeline. Qualcuno sceglie il modello di embedding, configura l'archivio vettoriale, scrive la logica di recupero, collega il modello linguistico, realizza l'interfaccia e mantiene tutto operativo. Non si tratta di un unico progetto, ma di un sistema composto da parti che invecchiano a velocità diverse. Gli embedding migliorano, l'archivio vettoriale cresce, i documenti cambiano e la valutazione non finisce mai davvero.

Sviluppare internamente non significa necessariamente realizzare ogni componente da zero. La maggior parte dei team assembla componenti esistenti: un'API per gli embedding, un database vettoriale gestito o autogestito, un'API per il modello linguistico e codice personalizzato per il recupero e l'interfaccia. La scelta tra sviluppo e acquisto all'interno di un progetto interno è una decisione distinta. Ciò che rimane interno, per definizione, è la responsabilità: dell'architettura, della manutenzione e delle conseguenze quando le risposte sono errate.

Costi delle opzioni di implementazione del RAG

Nessuna delle due opzioni ha un prezzo unico. Entrambe comportano una spesa composta da diverse voci, che però non sono le stesse. Confrontatele voce per voce, non mettendo a confronto un totale con l'altro.

Un servizio RAG addebita in genere i costi in base all'utilizzo, agli utenti o ai documenti, oltre ai costi di onboarding. La spesa ricorrente di solito copre la pipeline ospitata, le chiamate al modello effettuate per vostro conto, lo spazio di archiviazione per l'indice e il supporto. A questi costi si aggiunge una spesa una tantum per l'onboarding: collegamento delle fonti, revisione delle autorizzazioni dei documenti e ottimizzazione del recupero per i vostri contenuti. I fattori di costo sono il volume delle domande, le dimensioni e la frequenza di aggiornamento dell'insieme di documenti, il numero di sistemi collegati e i requisiti di sicurezza e conformità che imponete. I costi variano in base a tutti e quattro, quindi un preventivo per l'insieme di documenti di un'azienda dice poco sul vostro.

Una soluzione interna ha una struttura diversa. Il primo costo è il tempo di progettazione: lo sviluppo vero e proprio, che per un progetto pilota circoscritto si misura solitamente in settimane, non in mesi, quando i documenti sono accessibili e il caso d'uso è ristretto. Il secondo costo è l'infrastruttura: hosting per il database vettoriale e l'applicazione, chiamate agli embedding e al modello per ogni domanda e spazio di archiviazione che cresce con l'insieme di documenti. Il terzo costo è quello che i team sottovalutano: la manutenzione. Qualcuno deve reindicizzare i documenti modificati, monitorare la qualità del recupero, gestire gli aggiornamenti del modello, risolvere i problemi di sicurezza e rispondere degli errori nelle risposte. Il quarto costo è la responsabilità: una persona o un team designato che esamini regolarmente il sistema. Senza questo responsabile, un sistema RAG interno si deteriora come qualsiasi sistema privo di un responsabile, e il deterioramento viene scoperto dagli utenti, non dai dashboard.

Considerate il costo totale come un modello da perfezionare, non come un numero da calcolare una sola volta. Un progetto pilota vi fornisce dati reali sui vostri documenti e sul vostro volume: costo per domanda, costo di indicizzazione per lotto di documenti e ore di manutenzione settimanali. Usate questi dati per confrontare le opzioni nella fase successiva, non la pagina di marketing con la stima.

Servizio RAG vs. soluzione interna

	RAG come servizio	Sviluppo interno
Tempo necessario per ottenere le prime risposte funzionanti	Da giorni a settimane, dopo l’attivazione	Settimane, per un progetto pilota circoscritto
Costo iniziale	Attivazione e configurazione	Tempo di progettazione per lo sviluppo
Costo ricorrente	Canoni di abbonamento o tariffe basate sull’utilizzo	Infrastruttura, chiamate al modello, manutenzione
Chi mantiene la pipeline	Il fornitore	Il vostro team
Controllo sul recupero	Limitato alle opzioni del fornitore	Completo, fino alla logica di classificazione
Gestione dei dati	Il fornitore ospita il vostro indice: verificate residenza e conservazione	Decidete voi dove risiedono i dati
Costo del cambiamento	Limiti di esportazione, nuova indicizzazione altrove	Ricostruzione delle integrazioni, la conoscenza resta con voi
Ideale per	Documenti standard, team piccolo, necessità di velocità	Dati sensibili, recupero personalizzato, integrazione approfondita

Considerate la tabella come un punto di partenza, non come un verdetto. La riga che determina la risposta raramente è quella del prezzo. Di solito riguarda il controllo, la gestione dei dati o chi manterrà il sistema nel secondo anno.

Quando il RAG come servizio è adatto

Un servizio è adatto quando la velocità e la concentrazione sulle attività principali contano più del controllo. Se i vostri documenti sono in formati standard da ufficio, il vostro team è piccolo e vi servono risposte operative entro poche settimane, un servizio elimina interamente l’onere di sviluppo e manutenzione. Il fornitore ha già risolto gli aspetti meno appariscenti: indicizzazione, suddivisione in blocchi, ottimizzazione del recupero e disponibilità. Il vostro team dedica il proprio tempo ai documenti e alle risposte, non alla pipeline.

Un servizio è adatto per un progetto pilota. Quando non sapete ancora se il RAG aiuta la vostra attività, pagare un servizio è un modo più economico per scoprirlo rispetto a finanziare uno sviluppo interno. Eseguite domande reali su documenti reali, misurate le risposte e decidete sulla base dei dati. Se il pilota dimostra il valore e il servizio è adatto, continuate a utilizzarlo. Se dimostra il valore ma il servizio non è adatto, avrete capito cosa sviluppare invece di procedere per supposizioni.

Un servizio è adatto anche quando l'utilizzo è discontinuo. Un assistente per l'assistenza che risponde a centinaia di domande al giorno richiede una configurazione diversa da uno strumento interno utilizzato da venti persone. Con un servizio pagate in base all'utilizzo e potete aumentare la scala senza assumere personale per la pipeline. Con uno sviluppo interno, il costo di manutenzione resta più o meno lo stesso sia che il sistema risponda a dieci domande sia che ne risponda a diecimila.

Quando sviluppare il RAG internamente

Uno sviluppo interno funziona bene quando il recupero stesso è il prodotto. Se i vostri documenti richiedono una suddivisione in blocchi personalizzata, la classificazione deve seguire regole aziendali o le risposte dipendono dall'unione di diversi sistemi, ciascuno con le proprie autorizzazioni, la pipeline standard di un servizio vi ostacolerà. Sviluppare internamente vi permette di adattare il recupero al contenuto, invece di adattare il contenuto al fornitore.

Funziona bene quando la gestione dei dati non è negoziabile. Alcuni documenti non possono lasciare la vostra infrastruttura, alcuni settori richiedono tracce di audit che il fornitore non offre e alcuni contratti specificano dove possono risiedere i dati. Se il fornitore non è in grado di rispettare tali condizioni, il confronto dei prezzi è irrilevante. Verificate la residenza, la conservazione e se i vostri documenti vengono utilizzati per addestrare modelli condivisi prima di confrontare qualsiasi altro aspetto.

Funziona bene quando l'utilizzo è elevato e costante. A volumi elevati, le tariffe per domanda o per utente si accumulano, mentre il costo dell'infrastruttura di uno sviluppo interno cresce più lentamente. Il punto di equilibrio dipende dal vostro volume, dai vostri documenti e dai prezzi del fornitore; per questo è importante un pilota basato su numeri reali: eseguite lo stesso carico di lavoro in entrambi i modi e confrontate la fattura mensile, non la brochure.

Funziona bene quando disponete già del team necessario. Se i vostri tecnici gestiscono già un archivio vettoriale, un sistema di ricerca o una piattaforma dati, il costo marginale della gestione interna del RAG è inferiore rispetto a quello di un team che parte da zero. Lo sviluppo è un'estensione dei sistemi che già mantengono e la conoscenza resta all'interno dell'organizzazione.

Costi comuni a entrambe le opzioni

Alcuni costi non dipendono dall'opzione scelta e sono quelli che sorprendono maggiormente gli acquirenti.

La preparazione dei dati viene prima di tutto. Il RAG è efficace solo quanto i documenti in cui effettua la ricerca. Pagine obsolete, versioni duplicate, politiche contraddittorie e documenti senza un responsabile chiaro portano tutti a risposte errate. Risolvere questi problemi richiede tempo, sia che la pipeline sia vostra sia che appartenga a un fornitore. Prevedete questo lavoro nel progetto, non come un extra facoltativo.

La valutazione viene al secondo posto. Vi serve un insieme di domande di test con risposte corrette note e una procedura che le esegua dopo ogni modifica ai documenti o ai modelli. Senza valutazione, la qualità peggiora senza che ve ne accorgiate. Ne hanno bisogno entrambe le opzioni e, in ogni caso, il team che se ne occupa è il vostro.

La sicurezza e le autorizzazioni vengono al terzo posto. Il RAG deve rispettare chi può vedere cosa. Un documento ricercabile da tutti è una fuga di dati in attesa della domanda giusta. Il recupero consapevole delle autorizzazioni è un requisito, non una funzionalità, e deve essere testato con account utente reali, non dato per scontato sulla base di una pagina delle impostazioni.

Il deterioramento è il quarto aspetto. I documenti cambiano, i prodotti cambiano e cambia anche il modello alla base delle risposte. Un sistema RAG che nessuno esamina per mesi non è in produzione: è abbandonato a se stesso. Nominate il responsabile prima del lancio e mantenete la frequenza di revisione finché il tasso di errore non è stabile.

Come decidere

Passate in rassegna queste cinque domande con i documenti e il volume effettivi, non con una checklist generica.

1. Dove possono risiedere i documenti? Se la risposta pone restrizioni ai fornitori, la decisione è già presa. Verificate innanzitutto la residenza dei dati, la conservazione e l'utilizzo per l'addestramento.

2. Quanto è personalizzato il recupero? Documenti standard con domande standard si prestano a un servizio. Chunking personalizzato, regole aziendali applicate al ranking o join tra più sistemi indicano piuttosto uno sviluppo interno.

3. Quanto costa il progetto pilota per ciascuna opzione? Un progetto pilota basato su un servizio comprende l'onboarding e un mese di utilizzo. Un progetto pilota interno richiede alcune settimane di sviluppo. Confrontate questi due numeri, non le proiezioni annuali.

4. Chi ne sarà responsabile nel secondo anno? Un servizio richiede una persona responsabile, dalla vostra parte, dei documenti, delle autorizzazioni e della valutazione. Uno sviluppo interno richiede una persona responsabile di tutto questo, oltre che della pipeline. Se nessuno se ne assume la responsabilità, nessuna delle due opzioni funziona.

5. Quanto costa cambiare soluzione? Chiedete al fornitore come esportare il vostro indice e lo storico delle valutazioni. Chiedete al vostro team quanto sarebbe difficile sostituire un'integrazione personalizzata. L'opzione più economica da adottare non è sempre quella più economica da abbandonare.

Se le risposte indicano direzioni diverse, iniziate con un progetto pilota del servizio. Un mese di utilizzo reale produce i numeri che risolvono la discussione: costo per domanda, qualità delle risposte e ore di manutenzione effettivamente impiegate dal vostro team.

Le insidie

Scegliere in base al prezzo di listino. Il canone di abbonamento e la stima dello sviluppo non sono numeri dello stesso tipo. Il primo esclude la preparazione dei dati, la valutazione e la responsabilità; la seconda esclude il supporto del fornitore e il tempo di disponibilità. Confrontate il costo totale su un anno di utilizzo reale, incluso il lavoro svolto dal vostro team in entrambi i casi.

Saltare la preparazione dei dati. Acquistare un servizio non ripulisce i documenti e sviluppare una pipeline non risolve le politiche contraddittorie. Il team che salta questo passaggio ne paga le conseguenze con risposte errate in entrambi i casi.

Nessun set di valutazione. Senza domande di test e risposte corrette note, non è possibile stabilire se una modifica abbia migliorato o peggiorato il risultato. Entrambe le opzioni richiedono una valutazione, e un servizio che non consente di esaminare la propria valutazione chiede di fidarsi di una demo.

Vincoli da entrambe le parti. Un servizio può creare dipendenza attraverso i limiti all'esportazione e i costi di reindicizzazione. Uno sviluppo interno può creare dipendenza attraverso integrazioni personalizzate che nessun altro comprende. Ponete la domanda sulle possibilità di uscita prima di firmare o iniziare a sviluppare, non dopo.

Trattare il RAG come una casella di ricerca. Il RAG non è una casella di ricerca con un modello linguistico sopra. È un sistema che recupera informazioni, fonda le risposte sulle fonti e risponde; la sua qualità dipende dall'insieme dei documenti, del recupero e del ciclo di revisione. Una demo che risponde a cinque domande preparate dimostra ben poco. Domande reali, documenti reali e un tasso di errore misurato dimostrano tutto il resto.

Domande frequenti

Che cos'è il RAG come servizio?

Il RAG come servizio è una pipeline ospitata di generazione aumentata dal recupero: un fornitore indicizza i vostri documenti e risponde alle domande basandosi su di essi tramite un'API o un'interfaccia. Voi possedete i documenti, le regole di accesso e le risposte. Il fornitore possiede l'embedding, l'archivio vettoriale, la logica di recupero, le chiamate al modello e la disponibilità del servizio.

In che modo il RAG differisce dal fine-tuning?

Il fine-tuning addestra un modello sui vostri dati affinché si comporti in modo diverso. Il RAG lascia invariato il modello e gli fornisce i vostri documenti al momento della risposta, così la risposta si basa su fonti che potete verificare e aggiornare. Il RAG è adatto a conoscenze che cambiano spesso; il fine-tuning è adatto a comportamenti e toni che rimangono stabili. Molti sistemi usano entrambi, per parti diverse del lavoro.

I nostri dati sono al sicuro con un servizio RAG?

Dipende dalla configurazione e dovreste chiederlo prima di impegnarvi. Verificate dove sono archiviati i vostri documenti, se i vostri dati vengono utilizzati per addestrare modelli condivisi, per quanto tempo il fornitore li conserva e se il recupero rispetta il vostro modello di autorizzazioni. Una configurazione affidabile offre autorizzazioni rigorose, termini di conservazione chiari e una risposta diretta a ciascuna di queste domande.

Quanto tempo richiede ciascuna opzione?

Un servizio raggiunge in genere le prime risposte funzionanti in un periodo che va da alcuni giorni ad alcune settimane, dopo l'onboarding e il collegamento dei documenti. Un progetto pilota interno circoscritto richiede in genere alcune settimane, quando i documenti sono accessibili e il caso d'uso è limitato. Le tempistiche si allungano quando i documenti sono sparsi, le autorizzazioni non sono chiare o l'ambito continua ad ampliarsi. Un ambito pilota definito con una chiara misura del successo è la protezione migliore contro un progetto che non finisce mai.

Quanto costa il RAG?

Dipende dal volume delle domande, dalle dimensioni e dalla frequenza di aggiornamento dell'insieme di documenti, dai sistemi coinvolti e dal fatto che acquistiate un servizio o sviluppiate internamente. È esattamente per questo che si inizia con un progetto pilota circoscritto: trasforma una stima vaga in un numero reale basato sui vostri documenti e sul vostro volume, prima che vi impegniate in qualcosa di più grande.

Possiamo passare successivamente da un servizio a una soluzione interna, o viceversa?

Sì, e pianificare questo aspetto fa parte della decisione. Chiedete al fornitore come esportare il vostro indice, i vostri documenti e la cronologia delle valutazioni. In ogni caso, conservate i documenti e le domande di test nei vostri sistemi, così la conoscenza acquisita durante il progetto pilota rimane con voi. Il progetto pilota è anche il momento per capire quanto costerebbe cambiare soluzione, mentre la posta in gioco è ancora bassa.

In sintesi

Il RAG come servizio e lo sviluppo interno non sono rispettivamente un'opzione valida e una sbagliata. Sono risposte diverse a vincoli diversi: velocità e focalizzazione orientano verso un servizio, controllo e gestione dei dati verso uno sviluppo interno, mentre volumi elevati e costanti possono far pendere l'ago della bilancia in una direzione o nell'altra. Il criterio sbagliato è scegliere in base al prezzo indicato. Quello giusto è un progetto pilota su documenti reali con domande reali, valutato in base al costo per domanda, alla qualità delle risposte e alle ore che il vostro team dedica alla gestione della soluzione.

Presso Ridiculous Engineering, offriamo RAG gestito e aiutiamo i team a sviluppare sistemi che possano gestire autonomamente. Se state valutando queste opzioni, parliamone. Attraverso il nostro servizio di sviluppo e automazione dell'IA possiamo aiutarvi a scegliere quali documenti utilizzare, verificare quanto bene il sistema trovi le informazioni corrette e misurare la qualità delle risposte in un progetto pilota prima di assumere un impegno maggiore.