Cosa aspettarsi dalla generazione con recupero amplificato e dagli LLM self-hosted

Cosa aspettarsi dalla generazione con recupero amplificato e dagli LLM self-hosted' -> 'Cosa aspettarsi dalla generazione con un potenziamento straordinario e dagli LLM auto-ospitati

Il recupero-generazione migliorato (RAG) è un framework di intelligenza artificiale progettato per potenziare un LLM integrandolo con informazioni recuperate da una base di conoscenza esterna. Sulla base dell’attenzione crescente che il RAG ha ricevuto ultimamente, è ragionevole concludere che il RAG sia ora un argomento di rilievo nell’ecosistema AI/NLP (Intelligenza Artificiale/Elaborazione del Linguaggio Naturale). Quindi, immergiamoci e discutiamo cosa aspettarci dai sistemi RAG quando abbinati a LLM auto-ospitati.

Nel post del blog intitolato: “Scopri il vantaggio delle prestazioni con il recupero generato migliorato,” abbiamo indagato su come il numero di documenti recuperati possa migliorare la qualità delle risposte di LLM. Abbiamo anche descritto come il LLM vettorizzato basato sul dataset MMLU, archiviato in un database vettoriale come MyScale, generi risposte più accurate quando integrato con conoscenze pertinenti contestualmente senza mettere a punto il dataset.

Quindi, il punto saliente è:

RAG riempie le lacune di conoscenza, riducendo le allucinazioni potenziando gli input con dati esterni.

• La guida completa dei Transformers Tutto ciò che devi sapere
• Benefici e Limitazioni dei Modelli di Diffusione
• Come evitare le allucinazioni AI con ChatGPT

Utilizzare le API di LLM esterne nella tua applicazione può comportare dei potenziali rischi per la sicurezza dei dati, ridurre il controllo e aumentare significativamente i costi, specialmente con un alto volume di utenti. Pertanto, la domanda che sorge spontanea è:

Come puoi garantire una maggiore sicurezza dei dati e mantenere il controllo del tuo sistema?

La risposta concisa è utilizzare un LLM auto-ospitato. Questo approccio non solo offre un controllo superiore sui dati e il modello, ma rafforza anche la privacy e la sicurezza dei dati migliorando l’efficienza dei costi.

Perché LLM auto-ospitati?

I modelli di linguaggio di grandi dimensioni basati su cloud come ChatGPT di OpenAI sono facili da accedere e possono aggiungere valore a una vasta gamma di domini applicativi, offrendo un accesso immediato e responsabile. Tuttavia, i fornitori pubblici di LLM possono violare la sicurezza e la privacy dei dati, oltre a sollevare preoccupazioni riguardanti il controllo aperto, le fughe di conoscenza e l’efficienza dei costi.

Nota: Se uno o tutti questi problemi ti risuonano, allora vale la pena utilizzare un LLM auto-ospitato.

Mentre continuiamo con la nostra discussione, parleremo in dettaglio di queste quattro importanti preoccupazioni:

Privacy

La privacy deve essere una preoccupazione preminente quando si integra LLM API nella propria applicazione.

Perché la privacy è così importante?

La risposta a questa domanda ha diverse parti, come evidenziato nei seguenti punti:

• I fornitori di servizi LLM potrebbero utilizzare le tue informazioni personali per l’addestramento o l’analisi, compromettendo la privacy e la sicurezza.
• Inoltre, i fornitori di LLM potrebbero incorporare le tue ricerche nei loro dati di addestramento.

I LLM auto-ospitati risolvono questi problemi in quanto sono sicuri; i tuoi dati non vengono mai esposti a un’API di terze parti.

Controllo

I servizi LLM, come OpenAI GPT-3.5, generalmente censurano argomenti come la violenza e richiedere consigli medici. Non hai il controllo su quale contenuto viene censurato. Tuttavia, potresti voler sviluppare il tuo modello di censura (e le relative regole).

Come adottare un modello di censura che soddisfi le tue esigenze?

La risposta teorica generale è che l’affinamento personalizzato di un LLM mediante la creazione di filtri personalizzati è preferibile all’uso degli input perché un modello tarato è più stabile. Inoltre, l’auto-ospitazione di un modello affinato offre la libertà di modificare e annullare la censura predefinita inclusa negli LLM di dominio pubblico.

Fughe di Conoscenza

Come descritto in precedenza, le fughe di conoscenza sono un problema quando si utilizza un server LLM di terze parti, soprattutto se si eseguono interrogazioni che includono informazioni aziendali proprietarie.

Nota: Le possibili fughe di conoscenza si verificano sia da parte degli input ai LLM che dalle risposte tornate all’applicazione interrogante.

Come evitare le fughe di conoscenza?

In sintesi, utilizza un LLM auto-ospitato, non un LLM di dominio pubblico, poiché la tua base di conoscenze aziendali proprietarie è uno degli asset più preziosi.

Efficienza dei Costi

È opinabile se i LLM auto-ospitati siano costo-efficienti rispetto ai LLM basati su cloud. La ricerca descritta nell’articolo: “Come il batching continuo consente un throughput 23 volte superiore nell’elaborazione dei LLM riducendo la latenza p50” riporta che i LLM auto-ospitati sono più convenienti dal punto di vista dei costi quando la latenza e il throughput sono correttamente bilanciati con una strategia avanzata di batching continuo.

Nota: Approfondiremo questo concetto più avanti in questo testo.

Massimizzare il tuo RAG con LLM autonomi

Gli LLM consumano risorse computazionali. Richiedono grandi quantità di risorse per dedurre e servire risposte. Aggiungere un RAG aumenterà solo il bisogno di risorse computazionali in quanto può aggiungere oltre 2.000 token ai token necessari per rispondere alle domande per una maggiore precisione. Purtroppo, questi token extra comportano costi aggiuntivi, specialmente se si interagisce con API LLM open-source come OpenAI.

Queste cifre possono migliorare ospitando autonomamente un LLM, utilizzando matrici e metodi come KV Cache e Continuous Batching, migliorando l’efficienza all’aumentare delle richieste. Tuttavia, d’altra parte, la maggior parte delle piattaforme di calcolo cloud-based core GPU, come RunPod, addebitano le ore di utilizzo e non il throughput dei token: buone notizie per i sistemi RAG autonomi, che comportano un costo minore per ogni token di richiesta.

La tabella seguente racconta la propria storia: gli LLM autonomi combinati con RAG possono offrire efficienza dei costi e precisione. Per riassumere:

• Il costo scende solo al 10% di gpt-3.5-turbo quando viene massimizzato.
• Il costo del collegamento RAG llama-2-13b-chat con dieci contesti costa solo $0.04 per 1840 token, un terzo del costo di gpt-3.5-turbo senza alcun contesto.

Tabella: Confronto Totale dei Costi in Centesimi USA

Nostra Metodologia

Abbiamo utilizzato text-generation-inference per eseguire un modello llama-2-13b-chat non quantizzato per tutte le valutazioni in questo articolo. Abbiamo inoltre noleggiato una pod di cloud con 1x NVIDIA A100 80GB, al costo di $1.99 all’ora. Una pod di questa dimensione può implementare llama-2-13b-chat. Degno di nota, ogni cifra utilizza la prima quartile al di sotto come limite inferiore e la terza quartile come limite superiore, rappresentando visivamente la diffusione dei dati mediante diagrammi a scatola.

Nota: Implementare modelli con 70B richiede più memoria GPU disponibile.

Spingere la Capacità di Throughput delle LLM ai Limiti

Il throughput complessivo dovrebbe essere la prima cosa da considerare. Abbiamo sovraccaricato gli LLM da 1 a 64 thread per simulare molteplici interrogazioni simultanee. L’immagine sottostante descrive come il throughput di generazione diminuisce con prompt più grandi. Il throughput di generazione converge intorno a 400 token al secondo, indipendentemente da come si aumenta la concorrenza.

L’aggiunta di prompt riduce il throughput. Come soluzione, raccomandiamo l’uso di un RAG con meno di 10 contesti per bilanciare precisione e throughput.

Misurare il Tempo di Avvio per Prompt più Lunghi

La reattività del modello è fondamentale per noi. Sappiamo anche che il processo di generazione per il casual language modeling è iterativo. Per migliorare il tempo di risposta del modello, abbiamo memorizzato nella cache i risultati della generazione precedente per ridurre il tempo di calcolo con KV Cache. Chiamiamo questo processo “avvio” quando si genera un LLM utilizzando KV Cache.

Nota: Sarà sempre necessario calcolare le chiavi e i valori per tutti i prompt di input all’inizio del processo.

All’aumentare della lunghezza del prompt, abbiamo continuato a valutare il tempo di avvio del modello. Il grafico seguente utilizza una scala logaritmica per illustrare il tempo di avvio.

I punti seguenti riguardano questo grafico:

• I tempi di avvio con meno di 32 thread sono accettabili;
• Il tempo di avvio della maggior parte dei campioni è inferiore a 1000 ms.
• Il tempo di avvio aumenta drasticamente quando aumentiamo la concorrenza.
• Gli esempi con 64 thread iniziano oltre i 1000 ms e terminano intorno ai 10 secondi.
• È troppo lungo per gli utenti aspettare.

La nostra configurazione mostra un tempo di avvio medio di circa 1000ms quando la concorrenza è inferiore a 32 thread. Pertanto, non raccomandiamo di sovraccaricare troppo il LLM, poiché il tempo di avvio diventerà ridicolmente lungo.

Valutazione della Latenza di Generazione

Sappiamo che la generazione di LLM con Cache KV può essere categorizzata come tempo di avvio e tempo di generazione; possiamo valutare la latenza di generazione effettiva o il tempo che l’utente deve aspettare per vedere il prossimo token nell’applicazione.

La latenza di generazione è più stabile rispetto al tempo di avvio perché è difficile inserire prompt più grandi nella strategia di batching continua. Quindi, quando hai più richieste contemporaneamente, devi aspettare che i prompt precedenti vengano memorizzati nella cache prima che venga visualizzato il token successivo.

D’altra parte, la generazione è molto più semplice una volta che la cache è costruita poiché la cache KV riduce il numero di iterazioni e la generazione viene pianificata non appena è disponibile uno spazio nel batch. La latenza aumenta a diversi passaggi, con questi passaggi che arrivano prima con prompt più grandi e il batch è saturo. Più richieste esauriranno presto il LLM, aumentando il limite mentre si servono più richieste.

È ragionevole aspettarsi sempre una latenza di generazione inferiore a 90 ms e persino intorno a 60 ms se non si spinge troppo sulle contestualizzazioni e la concorrenza. Di conseguenza, raccomandiamo cinque contesti con una concorrenza di 32 in questa configurazione.

Confronto dei Costi di gpt-3.5-turbo

Siamo molto interessati a cosa costa questa soluzione. Quindi, abbiamo stimato il costo utilizzando i dati raccolti in precedenza e creato il seguente modello di costo per il nostro processo:

• Cserv è il costo orario per il server cloud GPU.
• Tboot e Tgen sono il tempo di avvio e di generazione (in millisecondi) per ogni richiesta, rispettivamente.
• Nparallel calcola il numero di thread elaborati contemporaneamente (parallelismo).

Utilizzando la cache KV e il batching continuo, si migliora l’efficienza dei costi di sistema, riducendo potenzialmente i costi a un decimo di gpt-3.5-turbo con la giusta configurazione. Si consiglia una concorrenza di 32 thread per risultati ottimali.

Quale sarà il prossimo passo?

L’ultima domanda che ci poniamo è:

Cosa possiamo imparare da questi grafici e dove possiamo andare da qui?

Equilibrio tra Latenza e Throughput

C’è sempre un compromesso tra latenza e throughput. Stimare l’uso quotidiano e la tolleranza dell’utente per la latenza è un buon punto di partenza. Per massimizzare il rendimento per dollaro, ti consigliamo di aspettarti 32 concorrenze su 1x NVIDIA A100 80GB con llama-2-13b o modelli simili. Offrono il miglior throughput, una latenza relativamente bassa e un budget ragionevole. Puoi sempre cambiare la tua decisione; ricorda sempre di stimare prima il tuo caso d’uso.

Perfezionamento del Modello: Più Lungo e Più Potente

Ora puoi perfezionare il tuo modello con i sistemi RAG. Ciò aiuterà il modello ad abituarsi a contesti più lunghi. Ci sono repository open source che migliorano LLM per una lunghezza di input più lunga, come Long-LLaMA. I modelli perfezionati con contesti più lunghi sono buoni apprendisti in contesto e si comportano meglio dei modelli estesi attraverso RoPE rescaling.

Accoppiamento di MyScale con un Sistema RAG: Analisi del Costo del Sistema di Inferenza rispetto al Database

Accoppiando MyScale e 10 GPU A100 di RunPod con MyScale (database vettoriale), puoi configurare facilmente un sistema RAG Llama2-13B + base di conoscenza Wikipedia, che può gestire fino a 100 utenti contemporaneamente.

Prima di concludere questa discussione, consideriamo una semplice analisi dei costi di esecuzione di un tale sistema:

Note:

• Questi costi sono un’approssimazione basata sui calcoli dei costi evidenziati in precedenza.
• I sistemi RAG su larga scala migliorano significativamente le prestazioni di LLM con meno del 15% di costo aggiuntivo nel servizio di database vettoriale.
• Il costo ammortizzato per un database vettoriale sarà ancora più basso man mano che aumenta il numero di utenti.

In conclusione

È intuitivo concludere che gli extra prompt in RAG costino di più e siano più lenti. Tuttavia, le nostre valutazioni mostrano che questa è una soluzione fattibile per le applicazioni reali. Questa valutazione ha anche analizzato cosa ci si può aspettare dagli LLM auto-ospitati, valutando il costo di questa soluzione e le prestazioni complessive, aiutandoti a costruire il tuo modello di costo quando distribuisci un LLM con la base di conoscenza esterna.

Infine, possiamo vedere che l’efficienza di costo di MyScale rende i sistemi RAG molto più scalabili!

Quindi, se sei interessato a valutare le prestazioni di QA delle pipeline RAG, unisciti a noi su Discord o Twitter. E puoi anche valutare le tue stesse pipeline RAG con RQABenchmark!

Ti terremo aggiornato con le nostre ultime scoperte riguardo agli LLM e ai database di vettori!