Il fossato per l’AI aziendale è RAG + Fine Tuning ecco perché

Il fossato dell'AI aziendale RAG + Fine Tuning, scopri perché

Per avere successo con l’IA generativa su larga scala, dobbiamo dare agli LLM la diligenza che meritano. Entra in gioco RAG e il fine tuning.

Foto di Volodymyr Hryshchenko su Unsplash.

L’euforia intorno agli LLM è senza precedenti, ma è giustificata. Dalle immagini generate dall’IA del Papa vestito interamente di Balenciaga all’assistenza clienti senza impulsi, l’IA generativa ha il potenziale per trasformare la società come la conosciamo.

E in molti modi, gli LLM renderanno i data engineer più preziosi – ed è entusiasmante!

Tuttavia, è una cosa mostrare al tuo capo una demo interessante di uno strumento di scoperta dei dati o un generatore di testo-SQL – è un’altra cosa usarlo con i dati proprietari dell’azienda, o ancora più preoccupante, i dati dei clienti.

Troppo spesso, le aziende si affrettano a costruire applicazioni di intelligenza artificiale senza un’accurata previsione dell’impatto finanziario e organizzativo dei loro esperimenti. E non è colpa loro – dirigenti e consigli di amministrazione sono responsabili della maggior parte della mentalità del “sbrigati e vai” attorno a questa (e alla maggior parte delle) nuove tecnologie. (Ricordate i NFT?).

Perché l’IA – in particolare l’IA generativa – abbia successo, dobbiamo fare un passo indietro e ricordarci come qualsiasi software diventa pronto per l’azienda. Per arrivare lì, possiamo prendere spunto da altre industrie per capire cosa significa essere pronti per l’azienda e applicare questi principi all’IA generativa.

Nella mia opinione, l’IA generativa pronta per l’azienda deve essere:

  • Sicura e privata: La tua applicazione di IA deve garantire che i tuoi dati siano sicuri, privati e conformi, con accessi adeguati. Pensate: SecOps per l’IA.
  • Scalabile: la tua applicazione di IA deve essere facile da implementare, utilizzare ed aggiornare, oltre ad essere efficiente in termini di costo. Non acquistereste – o costruireste – un’applicazione di dati se ci volessero mesi per implementarla, se fosse noiosa da usare e se fosse impossibile aggiornarla senza introdurre altri milioni di problemi. Non dovremmo trattare le applicazioni di IA in modo diverso.
  • Affidabile. La tua applicazione di IA dovrebbe essere sufficientemente affidabile e coerente. Sarebbe difficile trovare un direttore tecnico disposto a scommettere la sua carriera nell’acquisto o nella costruzione di un prodotto che produce codice inaffidabile o genera insights casuali e ingannevoli.

Con queste linee guida in mente, è ora che cominciamo a dare all’IA generativa la diligenza che merita. Ma non è così facile…

Perché l’IA aziendale è difficile da raggiungere?

In parole semplici, l’infrastruttura sottostante per scalare, proteggere e far funzionare le applicazioni LLM non è ancora pronta.

A differenza della maggior parte delle applicazioni, l’IA è ancora molto misteriosa. Sappiamo cosa mettiamo dentro (dati grezzi, spesso non strutturati) e sappiamo cosa otteniamo, ma non sappiamo come ciò sia stato ottenuto. E questo è difficile da scalare, proteggere e far funzionare.

Prendiamo ad esempio GPT-4. Mentre GPT-4 ha sorpassato GPT-3.5 in alcune attività (come sostenere l’esame SAT e AP di Calcolo AB), alcuni dei suoi output erano pieni di allucinazioni o mancavano del contesto necessario per portare a termine adeguatamente queste attività. Le allucinazioni sono causate da una varietà di fattori, dalle cattive incastonature ai limiti di conoscenza, e influiscono spesso sulla qualità delle risposte generate dai LLM pubblicamente disponibili o aperti addestrati su informazioni raccolte dal web, che sono la maggior parte dei modelli.

Per ridurre le allucinazioni e, ancora più importantemente, rispondere a domande commerciali significative, le aziende devono integrare LLM con i propri dati proprietari, che includono il contesto aziendale necessario. Ad esempio, se un cliente chiede a un chatbot di una compagnia aerea di cancellare il suo biglietto, il modello avrebbe bisogno di accedere alle informazioni sul cliente, sulle sue transazioni passate, sulle politiche di cancellazione e potenzialmente su altre informazioni. Tutto questo esiste attualmente nei database e nei data warehouse.

Senza questo contesto, un’intelligenza artificiale può ragionare solo con le informazioni pubbliche, di solito pubblicate su Internet, su cui è stata originariamente addestrata. E qui risiede il dilemma: esporre dati aziendali proprietari e incorporarli nei processi aziendali o nelle esperienze dei clienti richiede sempre una sicurezza, una scalabilità e una affidabilità solide.

Le due vie per un’IA pronta per l’azienda: RAG e tuninig fine

Quando si tratta di rendere pronta per l’azienda l’IA, le parti più critiche arrivano alla fine del processo di sviluppo di LLM: retrieval augmented generation (RAG) e tuning fine.

È importante notare, tuttavia, che RAG e tuning fine non sono approcci reciprocamente esclusivi e dovrebbero essere utilizzati – spesso in tandem – in base alle tue esigenze specifiche e al caso d’uso.

Quando utilizzare RAG

Immagine cortesia dell'autore.

RAG è un framework che migliora la qualità delle uscite di LLM dando al modello accesso a un database mentre cerca di rispondere a un prompt. Il database, essendo un insieme curato e affidabile di dati potenzialmente proprietari, consente al modello di incorporare informazioni aggiornate e affidabili nelle sue risposte e nel suo ragionamento. Questo approccio è particolarmente indicato per applicazioni di intelligenza artificiale che richiedono informazioni contestuali aggiuntive, come risposte di supporto clienti (come nel nostro esempio di cancellazioni dei voli) o ricerca semantica nella piattaforma di comunicazione aziendale.

Le applicazioni di RAG sono progettate per recuperare informazioni pertinenti da fonti di conoscenza prima di generare una risposta, rendendole adatte per interrogare fonti di dati strutturati e non strutturati, come database vettoriali e archivi di caratteristiche. Recuperando informazioni per aumentare l’accuratezza e l’affidabilità di LLM nella generazione delle uscite, RAG è anche molto efficace nel ridurre le allucinazioni e mantenere bassi i costi di addestramento. RAG offre anche ai team un livello di trasparenza poiché è possibile conoscere la fonte dei dati che vengono utilizzati per generare nuove risposte.

Una cosa da notare sulle architetture RAG è che le loro prestazioni dipendono fortemente dalla capacità di costruire pipeline di dati efficaci che rendano i dati aziendali disponibili per i modelli di intelligenza artificiale.

Quando utilizzare il tuning fine

Immagine cortesia dell'autore.

Il tuning fine è il processo di addestrare un LLM esistente su un set di dati più piccolo, specifico per compiti e con etichette, regolando i parametri e gli embedding del modello in base a questi nuovi dati. Il tuning fine si basa su set di dati pre-curati che forniscono informazioni non solo per il recupero delle informazioni, ma anche per le sfumature e i termini del dominio in cui si desidera generare le uscite.

Dalla nostra esperienza, il tuning fine è particolarmente adatto a situazioni specifiche del settore, come rispondere a prompt dettagliati con uno stile o un tono di nicchia, ad esempio una relazione legale o un ticket di supporto clienti. È anche una soluzione ideale per superare i bias informativi e altre limitazioni, come ripetizioni o incongruenze linguistiche. Diversi studi dell’ultimo anno hanno dimostrato che i modelli sintonizzati finemente sono significativamente migliori delle versioni pronte all’uso di GPT-3 e di altri modelli disponibili pubblicamente. È stato dimostrato che, per molti casi d’uso, un modello piccolo sintonizzato finemente può superare un modello generico di grandi dimensioni, rendendo il tuning fine un percorso possibilmente più efficiente in termini di costo in determinati casi.

A differenza di RAG, il fine tuning spesso richiede meno dati ma a spese di più tempo e risorse di calcolo. Inoltre, il fine tuning funziona come una scatola nera; poiché il modello internalizza il nuovo set di dati, diventa difficile individuare il ragionamento dietro nuove risposte e le allucinazioni rimangono una preoccupazione significativa.

Il fine tuning – come le architetture RAG – richiede la costruzione di efficaci pipeline di dati che rendano disponibili (etichettati!) dati aziendali al processo di fine tuning. Non è una cosa semplice.

Perché RAG probabilmente ha senso per il tuo team

Immagine cortesia dell'autore.

È importante ricordare che RAG e fine tuning non sono approcci mutualmente esclusivi, hanno punti di forza e debolezze diverse e possono essere utilizzati insieme. Tuttavia, per la grande maggioranza dei casi d’uso, RAG è probabilmente la scelta più sensata quando si tratta di fornire applicazioni AI generative aziendali.

Ecco perché:

  • La sicurezza e la privacy di RAG sono più gestibili: I database hanno ruoli e sicurezza integrati, a differenza dei modelli AI, ed è abbastanza compreso chi vede cosa grazie ai controlli di accesso standard. Inoltre, si ha un maggiore controllo su quali dati vengono utilizzati accedendo a un corpus sicuro e privato di dati proprietari. Con il fine tuning, qualsiasi dato incluso nel set di addestramento è esposto a tutti gli utenti dell’applicazione, senza modi ovvi per gestire chi vede cosa. In molti scenari pratici, soprattutto quando si tratta di dati dei clienti, non avere tale controllo è inaccettabile.
  • RAG è più scalabile: RAG è meno costoso del fine tuning perché quest’ultimo comporta l’aggiornamento di tutti i parametri di un grande modello, richiedendo una potenza di calcolo considerevole. Inoltre, RAG non richiede l’etichettatura e la creazione di set di addestramento, un processo intensivo di lavoro che può richiedere settimane e mesi per perfezionare per ogni modello.
  • RAG garantisce risultati più affidabili. In parole semplici, RAG funziona meglio con dati dinamici, generando risultati deterministici da un insieme curato di dati sempre aggiornati. Poiché il fine tuning agisce in gran parte come una scatola nera, può essere difficile individuare come il modello generi risultati specifici, diminuendo fiducia e trasparenza. Con il fine tuning, sono possibili e probabili allucinazioni e imprecisioni, poiché ci si affida ai pesi del modello per codificare le informazioni aziendali in modo approssimativo.

A nostro modesto parere, l’AI pronta per le aziende si baserà principalmente su RAG, con il fine tuning coinvolto in casi d’uso più sfumati o specifici del dominio. Per la grande maggioranza delle applicazioni, il fine tuning sarà un optional per scenari di nicchia e verrà utilizzato molto più frequentemente una volta che l’industria sarà in grado di ridurre i costi e le risorse necessarie per eseguire l’AI su larga scala.

Tuttavia, indipendentemente da quale metodo si utilizzi, lo sviluppo delle applicazioni di intelligenza artificiale richiederà pipeline che alimentano questi modelli con dati aziendali attraverso un qualche tipo di archiviazione dati (come Snowflake, Databricks, un database vettoriale autonomo come Pinecone o qualcos’altro). Alla fine della giornata, se l’AI generativa viene utilizzata nei processi interni per estrarre analisi e informazioni da dati non strutturati, verrà utilizzata… rullo di tamburi… una pipeline di dati.

Per far funzionare RAG, hai bisogno di osservabilità dei dati

All’inizio degli anni 2010, l’apprendimento automatico veniva presentato come un algoritmo magico in grado di compiere miracoli su comando se si fornivano i pesi perfetti alle sue caratteristiche. Quello che in realtà migliorava le prestazioni dell’IA, però, era investire in caratteristiche di alta qualità e, in particolare, in qualità dei dati.

Allo stesso modo, affinché l’IA aziendale funzioni, è necessario concentrarsi sulla qualità e affidabilità dei dati su cui dipendono i modelli generativi, probabilmente attraverso un’architettura RAG.

Poiché si basa su dati dinamici, talvolta aggiornati all’ultimo minuto, RAG richiede osservabilità dei dati per soddisfare le aspettative di prontezza aziendale. I dati possono rompersi per vari motivi, come dati di terze parti formattati erroneamente, codice di trasformazione errato o un job Airflow fallito. E accade sempre.

L’osservabilità dei dati offre alle squadre la possibilità di monitorare, segnalare, risolvere e affrontare problemi di dati o di pipeline su larga scala in tutto l’ecosistema dei dati. Da anni è un elemento indispensabile nella moderna architettura dei dati; mentre RAG cresce in importanza e l’IA evolve, l’osservabilità diventerà un partner fondamentale nello sviluppo delle LLM.

L’unico modo in cui RAG – e l’AI aziendale – funzionano è se puoi fidarti dei dati. Per raggiungere questo obiettivo, i team hanno bisogno di un modo scalabile e automatizzato per garantire l’affidabilità dei dati, così come un modo di livello aziendale per identificare la causa principale e risolvere rapidamente i problemi, prima che influiscano sugli LLM che servono.

Quindi, qual è lo stack LLM de facto?

L’infrastruttura e la roadmap tecnica per gli strumenti AI si stanno sviluppando mentre parliamo, con nuove startup che emergono ogni giorno per risolvere vari problemi e colossi dell’industria che sostengono di affrontare anche loro queste sfide. Quando si tratta di incorporare i dati aziendali nell’AI, vedo tre principali protagonisti in questa corsa.

Il primo protagonista: database vettoriali. Pinecone, Weaviate e altri si stanno facendo un nome come piattaforme di database indispensabili per alimentare architetture RAG. Anche se queste tecnologie promettono molto, richiedono la creazione di un nuovo componente dello stack e la creazione di flussi di lavoro per supportarlo dal punto di vista della sicurezza, della scalabilità e dell’affidabilità.

Il secondo protagonista: versioni ospitate di modelli creati da sviluppatori terzi di LLM come OpenAI o Anthropic. Attualmente, la maggior parte dei team ottiene la propria soluzione AI generativa tramite API di questi emergenti leader dell’AI grazie alla facilità d’uso. Collegati all’API di OpenAI e sfrutta un modello all’avanguardia in pochi minuti? Contate su di noi. Questo approccio funziona molto bene fin da subito se hai bisogno che il modello generi codice o risolva problemi ben noti e non specifici basati su informazioni pubbliche. Se vuoi incorporare informazioni proprietarie in questi modelli, è possibile utilizzare le funzionalità di afinamento o RAG integrate fornite da queste piattaforme.

E infine, il terzo protagonista: lo stack dati moderno. Snowflake e Databricks hanno già annunciato che stanno incorporando database vettoriali nelle loro piattaforme, oltre ad altre soluzioni per aiutare l’incorporazione dei dati che sono già memorizzati e elaborati su queste piattaforme negli LLM. Questo ha molto senso per molti, permette alle squadre di dati incaricate di iniziative AI di sfruttare gli strumenti che già utilizzano. Perché reinventare la ruota quando hai già le basi? Senza contare la possibilità di unire facilmente dati relazionali tradizionali con dati vettoriali… Come per gli altri due protagonisti, ci sono alcuni svantaggi in questo approccio: Snowflake Cortex, Lakehouse AI e altri prodotti MDS + AI sono ancora acerbi e richiedono un certo investimento iniziale per incorporare la ricerca vettoriale e la formazione dei modelli nei flussi di lavoro esistenti. Per uno sguardo più approfondito a questo approccio, ti consiglio di dare un’occhiata all’articolo di Meltano pertinent piece su perché lo stack LLM migliore potrebbe essere proprio quello che hai di fronte.

Indipendentemente dal protagonista che scegliamo, le domande di business di valore non possono essere risolte da un modello addestrato sui dati presenti in Internet. Deve avere contesto all’interno dell’azienda. E fornendo questo contesto in modo sicuro, scalabile e affidabile, possiamo ottenere un’AI pronta per l’azienda.

Il futuro dell’AI aziendale è nelle tue pipeline

Perché l’AI raggiunga questo potenziale, i team di dati e AI devono trattare l’integrazione LLM con la diligenza che meritano e fare della sicurezza, scalabilità e affidabilità una considerazione di primo piano. Che il tuo caso d’uso richieda RAG o afinamento – o entrambi – dovrai assicurarti che le fondamenta del tuo stack dati siano solide per mantenere i costi bassi, le prestazioni consistenti e l’affidabilità elevata.

I dati devono essere sicuri e privati; la distribuzione LLM deve essere scalabile; e i risultati devono essere affidabili. Mantenere un monitoraggio costante sulla qualità dei dati attraverso l’osservabilità è fondamentale per soddisfare queste richieste.

La parte migliore di questa evoluzione dai demo verso l’AI aziendale pronta consiste nell’offrire agli ingegneri dei dati il miglior ruolo nel possedere e guidare il ROI degli investimenti in AI generativa.

Sono pronto per l’ai aziendale pronta. E tu?

Lior Gavish ha contribuito a questo articolo.

Connettiti con Barr su LinkedIn per ulteriori approfondimenti sui dati, sull’AI e sul futuro della fiducia nei dati.