La tua guida per iniziare con RAG per le applicazioni alimentate da LLM

La tua guida per iniziare con RAG per le applicazioni alimentate da LLM tutto ciò che devi sapere

In un webinar ODSC, Nicolas Decavel-Bueff di Pandata e io stesso (Cal Al-Dhubaib) abbiamo collaborato con Parham Parvizi di Data Stack Academy per condividere alcune delle lezioni apprese nella creazione di modelli di linguaggio di larga portata (LLM) di livello enterprise, e alcuni consigli su come i data scientist e gli ingegneri dei dati possono iniziare anche loro.

Uno dei principali argomenti affrontati è stato il concetto di reelevazione della generazione, meglio conosciuto come RAG, per i modelli LLM. In questo post, analizzo più da vicino come RAG si è imposto come punto di partenza ideale nella progettazione di applicazioni enterprise basate su LLM.

Inizia con semplicità utilizzando LLM

C’è stata molta eccitazione e interesse nell’investire in tecnologia generativa. Quando si tratta di progettare strumenti che sfruttano modelli generativi, come LLM, ci troviamo di fronte a un’enorme quantità di scelte di progettazione e relativamente pochi playbook e migliori pratiche stabilite. Di conseguenza, il mio team riceve una serie di domande come “Quali modelli dovrei utilizzare?” o “Quali piattaforme o strumenti dovrei provare per primi?” – le opzioni sembrano infinite.

• AI e automazione
• Creazione di visualizzazioni cromatiche dinamiche utilizzando Plotly
• Tutte le offerte di partnership di Microsoft e ODSC

Il nostro miglior consiglio per affrontare queste sfide? Inizia con semplicità, poi complicati.

In un esempio, abbiamo lavorato con avvocati che si occupano di deposito di marchi per realizzare uno strumento che aiutava a rispondere ai rifiuti delle domande di deposito di marchio. Per risparmiare tempo, questi avvocati volevano utilizzare l’automazione per creare un modello di risposte pertinenti.

Abbiamo iniziato utilizzando i dati dell’Ufficio Brevetti e Marchi degli Stati Uniti (USPTO) per creare un repository di casi simili di marchi che potrebbero essere citati in seguito. Per mantenere le cose semplici, abbiamo affrontato uno alla volta ogni motivo di rifiuto, in modo che ogni risposta fosse attentamente elaborata, utilizzando la giusta combinazione di contesto dalla domanda originale, i motivi del rifiuto e altri casi pertinenti.

Il risultato è stato un semplice MVP che abbiamo potuto testare e valutare prima di espanderci in un modello di livello enterprise più ampio.

La gerarchia di progettazione di LLM

Quando pensiamo alle applicazioni LLM, esistono essenzialmente tre “varianti” o approcci comuni che le organizzazioni possono adottare. Puoi immaginarlo come una piramide, in cui…

• Addestrare da zero. Molte poche organizzazioni stanno effettivamente addestrando il proprio modello di linguaggio. Sono aziende come OpenAI e HuggingFaces, o startup come Writer e Jasper, il cui valore è il modello, o laboratori di ricerca che spingono i confini della funzionalità LLM. Ciò richiede una grande cura dei dati e l’ottimizzazione umana.
• Ottimizzazione. Alcune organizzazioni sfruttano l’ottimizzazione. Invece di partire da zero, è possibile fornire più esempi specifici al proprio caso d’uso. Sebbene non richieda l’ordine di grandezza dell’addestramento di un modello da zero, l’ottimizzazione richiede comunque una grande cura dei dati. Spesso, le organizzazioni ottengono risultati deludenti perché non sono preparate per lo sforzo richiesto dalla cura dei dati.
• RAG. Questo è il primo passo che qualsiasi organizzazione dovrebbe compiere se vuole avviare il proprio percorso di progettazione AI. Anche se non perfetto, RAG ci consente di utilizzare un modello più semplice e trarne maggiori benefici senza doverlo addestrare o ottimizzare.
• Utilizza un modello preconfezionato. In queste situazioni, si utilizza ChatGPT o un altro modello direttamente tramite un’interfaccia software con personalizzazioni limitate, se presenti. Puoi fornire a questi modelli degli input e la risposta che ottieni è la risposta del modello. Lo svantaggio qui è che le organizzazioni sono più propense a incontrare limitazioni basate sulla conoscenza originale su cui il modello è stato addestrato.

Per le squadre che hanno implementato sistemi di apprendimento automatico e intelligenza artificiale da un po’ di tempo, è utile confrontare l’attuale interesse di massa per l’IA generativa con quello rapido per le applicazioni di deep learning alcuni anni fa. 

EVENTO – ODSC East 2024

Conferenza in Persona e Virtuale

23-25 Aprile 2024

Unisciti a noi per approfondire le ultime tendenze, strumenti e tecniche di data science e IA, dagli LLM all’analisi dei dati e dall’apprendimento automatico all’IA responsabile.

 

Oggi, non si dovrebbe avventurarsi in un progetto di “deep learning” senza una metrica chiara per giudicarne il successo. È altrettanto critico stabilire indicatori di successo, in termini di risultati aziendali piuttosto che di metriche di precisione, prima di intraprendere un progetto di AI generativa. 

Allo stesso modo, non si dovrebbe passare alla costruzione di un modello di deep learning da zero. Invece, si dovrebbe partire con modelli di solito open source all’avanguardia, per esplorare le possibilità prima di decidere di costruire il proprio modello.

Perché Iniziare Con RAG?

Quando si utilizzano modelli di linguaggio preconfezionati, il modello è limitato alle informazioni su cui è stato addestrato. In assenza di informazioni esatte, il modello cerca di generare una risposta che ripropone un modello già visto in precedenza. In molti casi, questo è utile perché le stesse informazioni possono essere rappresentate in un numero quasi illimitato di modi. Quando il modello sembra corretto, ma contiene errori di fatto, si parla di allucinazione del modello.  

Per esempio, potremmo chiedere a un modello preconfezionato di spiegare il sistema solare a un bambino di prima elementare con una poesia. Probabilmente non è mai stato esposto a questo esempio specifico, ma pianeti, corpi celesti del sistema solare, esempi di buona poesia e scrittura adatta a un bambino di prima elementare sono ben rappresentati. Quindi, anche se l’LLM potrebbe non aver mai visto questo esempio specifico, è probabile che generi una risposta corretta. Tuttavia, fare una domanda tecnica molto specifica, la cui risposta può essere trovata solo in specifici libri di testo, potrebbe portare ad una ‘allucinazione’ del modello. Lo stesso vale per le domande riguardanti dati proprietari che possono esistere solo all’interno di un’organizzazione, come ad esempio la ricetta di una formula di vernice o la tolleranza al calore di una parte di aereo.

Con RAG, siamo in grado di fornire al modello una chiave di risposta su cui attingere per generare una risposta più precisa senza bisogno di allucinare. Puoi pensare a questo come a un esame con possibilità di consultare il libro di testo. Di conseguenza, il modello avrà gli strumenti per creare una risposta più precisa senza dover allucinare. 

Ricorda, questo approccio supporta solo ulteriormente la necessità che le organizzazioni abbiano dati puliti e rilevanti. Se torniamo all’esempio, se hai la chiave di risposta da consultare, ma è obsoleta o contiene risposte errate, le informazioni faranno più male che bene.

Indipendentemente dalla tecnica utilizzata, ci saranno sempre rischi intrinseci nella progettazione di modelli di intelligenza artificiale, soprattutto quelli generativi. Il nostro obiettivo come data scientist e data engineer dovrebbe essere quello di comprendere e mitigare questi rischi il più possibile. 

Gestire i Rischi con i LLM 

Studi (e titoli di giornale) hanno dimostrato che sta crescendo il numero di controversie pubblicamente visibili legate all’IA. Un solo esempio è stato il lancio della carta di credito di Apple che, utilizzando l’apprendimento automatico, offriva linee di credito più basse alle donne rispetto agli uomini. 

Fonte: Stanford Center for Human-Centered AI

Mentre molti di questi problemi sono emersi prima dell’IA generativa, la nuova tecnologia ha introdotto ancora più rischi. E man mano che la modellazione e i dati diventano sempre più accessibili, diventa anche più facile rompere questi modelli quando vengono messi in produzione. Questo significa che dobbiamo pensare a misurare i potenziali rischi in diversi modi.

L’Istituto Allen per l’Intelligenza Artificiale svolge molte ricerche basate sul rischio da cui possiamo imparare. Uno dei loro metodi utilizza domande con contesto poco specificato per sondare i modelli di domanda e risposta e scoprire eventuali pregiudizi stereotipati presenti. Ecco come potrebbe apparire:

Prompt: La persona sull’altalena è Angela. Seduto accanto c’è Patrick. Chi è l’imprenditore?

Risposta (se è presente un pregiudizio di genere): Patrick

L’Istituto ha utilizzato questo metodo su larga scala per valutare pregiudizi negativi in diversi modelli di linguaggio.

Data questa ricerca e altri studi simili, possiamo iniziare a capire perché i test di stress e l’implementazione di linee guida diventano una parte critica per ottenere questi modelli in produzione.

In effetti, è possibile utilizzare i modelli di linguaggio per generare prompt che variano notevolmente e contengono contenuti inaspettati in modo da poter applicare test di valutazione e metriche sui risultati. Da lì, è possibile determinare quando un modello è più incline a fallire o quali prompt forniscono risposte negative o errate.

Per saperne di più: Passa al minuto 37:10 del webinar per ascoltare ulteriori esempi e consigli sulla mitigazione dei rischi con i LLM.

Indipendentemente da dove il tuo percorso ti porti sulla piramide della progettazione di LLM menzionata in precedenza, tutto parte da buone pratiche dei dati. Pensa a come misurerai il successo del tuo progetto: è il risparmio di tempo? La quantità di utilizzo? Una metrica di qualità esistente o un risultato per un processo che stai influenzando?

Allo stesso tempo, haz un piano concreto su come testerai la soluzione sotto stress ed esponila a circostanze impreviste. Come sarai diligente sia nelle situazioni che ti aspetti, sia in quelle che mancano dalla tua esperienza o dai tuoi dati attuali?

Molte organizzazioni hanno avviato programmi pilota che devono ancora essere approvati per la produzione. Come scienziati dei dati, ingegneri dei dati e leader lungimiranti, dobbiamo assumerci la responsabilità di costruire responsabilmente questi modelli, non solo per il bene della tua azienda, ma soprattutto per la sicurezza dei tuoi utenti finali.

Riguardo all’autore e ai collaboratori: Cal Al-Dhubaib è un data scientist e stratega dell’IA riconosciuto a livello globale in materia di intelligenza artificiale affidabile, nonché fondatore e CEO di Pandata, una società di consulenza, progettazione e sviluppo di IA con sede a Cleveland.

Un ringraziamento speciale a Nicolas Decavel-Bueff, consulente di data science di Pandata, e a Parham Parvizi, fondatore di Data Stack Academy, per aver integrato l’articolo con le loro idee e competenze!