È fattibile inserire documenti di medie dimensioni (ad esempio, fino a 100 KB) nel contesto di una sessione di bot con una persona AI di Discourse tramite il prompt di sistema?
CASO D’USO
Una Persona AI personalizzata collegata a un LLM privato come Llama3-8b su un’istanza AWS dove il costo è orario, non per token. Cioè, il numero di token di richiesta/risposta non ha importanza e il server ha una notevole potenza CUDA, quindi le prestazioni sono buone. Cioè, RAG potrebbe essere opzionale?
(Caso d’uso alternativo: LLM Gemini.1.5, dove non ci sono costi per le chiamate API)
OBIETTIVO
Ridurre le parti in movimento nella pipeline e migliorare l’accuratezza evitando il recupero di similarità.
ESPERIMENTO
Test informale di Persona AI con Gemini 1.5 Pro in cui un documento di testo di circa 20.000 token è stato inserito nel prompt di sistema.
Ho posto diverse domande di cui sapevo che le risposte si trovavano solo nel documento. Ha risposto correttamente a tutte le domande. Quindi presumo che abbia letto i 20.000 token dal prompt e li abbia analizzati per ogni domanda?
Nei casi in cui le sessioni e il contenuto del contesto non sono troppo grandi, ci sono svantaggi in questo approccio?
NOTA A PIÈ DI PAGINA - Rimuovere il contesto dal prompt a metà sessione
Quando ho eliminato il contenuto di iniezione del prompt a metà sessione e ho continuato a porre domande, Gemini ha continuato a rispondere correttamente, ma dopo diverse domande non è più riuscito a trovare il contesto e ha fallito. Come era prevedibile, Gemini 1.5 può mantenere il contesto attraverso più turni conversazionali in una sessione, ma non indefinitamente.
Tutti i pensieri, commenti e indicazioni sono apprezzati!
Sì, abbiamo una logica di troncamento che dipende dalla quantità di token consentiti dall’LLM, abbiamo impostato la soglia piuttosto alta per i modelli gemini 1.5 (a 800k)
Dovrebbe funzionare, ma ogni interazione può essere molto costosa.
Nel complesso ho scoperto che limitare il contesto aiuta i modelli a rimanere più concentrati, ma a lungo termine (tra 2-5 anni)… il RAG potrebbe essere inutile e avremo così tanti token e concentrazione che non avrà importanza.
Nonostante le mie domande sul prompt stuffing… amo davvero il RAG.
IMO il lavoro che state facendo con i motori di embedding di alto livello è potente e utile in questo momento… ma concordo anche sul fatto che il RAG… potrebbe essere condannato.
Come ha detto Sam Altman in una recente intervista… attenzione ai modelli di business e ai piani di progetto che si frappongono all’LLM!! Vi schiacceremo! ..o qualcosa del genere..
Quindi, in definitiva… forse vorremo semplicemente dare le nostre cose all’LLM senza molte pipeline di pre-elaborazione che sono a bassa dimensionalità (input) poi ad alta dimensionalità (embedding) poi a bassa dimensionalità (prompting) poi ad alta dimensionalità (inferenza del transformer) poi a bassa dimensionalità (output).. Bob è tuo zio!
Ecco un po’ di background sul RAG rispetto al contesto lungo che ho appena scoperto… non l’ho ancora ascoltato tutto ma sembra rilevante forse… (non sono affiliato a nessuno in questo video :-))
Ho visto quel video su Gradient long-context LLama3.. ci ricorda che il contesto include tutto ciò che è in gioco..
Input dell’utente
Output dell’LLM
Token di controllo
Istruzioni di sistema
… mentre la finestra scorre, alcune cose vengono tralasciate.. ma hanno menzionato che ci può essere una ‘protezione’ del prompt di sistema in sessioni in cui la finestra di contesto si riempie..
ci sono anche i problemi di ‘dimensione massima di input’ e la ‘lunghezza della sequenza’ originale su cui il modello è stato addestrato che potrebbero entrare in gioco.
di seguito un esempio di prompt stuffing a lungo contesto in azione..
In generale sembra fattibile creare un team di persone AI di Discourse che ognuna abbia una grossa porzione di contenuto specializzato o codebase per l’interrogazione (tenendo presente l’avvertenza sull’alto costo quando si paga per token!)
Ma non è forse solo una versione “statica” di RAG (molto inefficiente e)?
Tutto ciò che RAG fa di diverso da questo approccio è selezionare e includere frammenti di contenuto pertinenti invece di includere tutto il contenuto.
Giusto, certo.. nessuna risposta semplice secondo me
Immagino che dipenda dal caso d’uso.
RAG funziona bene per alcune app, ma per altri casi target abbastanza deterministici (ad esempio, domande e risposte dei clienti, pagamenti, medicina, ecc.), io e altri abbiamo avuto problemi a ottenere una buona accuratezza con la ricerca vettoriale RAG nell’ultimo anno. Cioè, il bot o perde delle cose o inventa delle cose (scarsa recall, scarsa precisione in termini di IR), il che è ben documentato da Stanford, Google, ecc.
Quindi sorge la domanda.. perché dare un mucchio di chunk all’LLM se gli si può dare l’intero corpus. Almeno con l’iniezione di contesto, quando l’LLM non è accurato si hanno meno cose da ottimizzare..
Ok, non funzionerà per vaste librerie di documenti/codice.. ma per basi di contenuti piccole e moderate sembra funzionare benissimo finora… sto lavorando a un progetto che sta testando formalmente questo.. ! Altro presto.. grazie
PS. → per rendere le cose ancora più interessanti.. ho avuto fortuna con l’iniezione di contesto + il fine-tuning.. e ci sono approcci emergenti che combinano RAG e iniezione di contesto! .. ecc. ecc.
Ecco un test Q/A con un white paper (~20k token) messo in contesto tramite prompt injection vs RAG. (contenuto e impostazioni sono stati il più possibile gli stessi. LLM = Gemini-1.5-Pro)..
ANALISI:
RAG è incoerente.. a volte trova la risposta, a volte la manca.
Sono riuscito a far rispondere RAG alle domande dall’upload del file all’inizio del documento e, con qualche sforzo, potrebbe guardare al centro e alla fine.. quindi non è un fallimento totale.. ma è incoerente… costantemente, o più difficile da gestire secondo me : )
Ecco il file di test nel caso qualcuno voglia provarlo:
Il file contiene questi “aghi” del pagliaio BME che sono garantiti essere unici, cioè non presenti in copie esterne del documento su Internet.
Inizio:
Correttore di bozze: Felonius Monko
Metà:
Nota dell’editore: La serie di stabilità di Goldich è stata scoperta da Maurice Goldrch. Mentre l’ordine originale di Goldich del potenziale di alterazione dei minerali era qualitativo, lavori successivi di Michal Kowalski e J. Donald Rimstidt hanno inserito la serie in termini quantitativi. Grazie al Dr. Gomez Pyle della NMU per questo chiarimento.
Fine:
Dang, S. et al. Strutture cryo-EM del canale del cloruro attivato dal calcio TMEM16A. Nature 552, 426429 (2017).
Sono riuscito a rieseguire il test sopra con GPT4o (contesto 128k), assicurandomi di utilizzare impostazioni di token/chunk elevate. Tuttavia, è ancora molto inaffidabile per il mio caso d’uso di domande e risposte per white paper (perso nel mezzo, perso alla fine, ecc.). Ecco le mie impostazioni se qualcuno vuole duplicare e perfezionare. Mi piacerebbe molto se potessimo trovare le impostazioni giuste per questo caso:
|PERSONA AI PERSONALIZZATA||
|—|—|\n|||\n|Abilitato?|Sì|\n|Priorità|Sì|\n|Consenti chat|Sì|\n|Consenti menzioni|Sì|\n|Visione abilitata|No|\n|||\n|Nome|Rag Testing Bot 3|\n|Descrizione|Test RAG vs injection di prompt a contesto lungo|\n|Modello linguistico predefinito|GPT-4o-custom|\n|Utente| Rag_Testing_Bot_bot|\n|Comandi abilitati|Categories, Read, Summary|\n|Gruppi consentiti|trust_level_4|\n|||\n|Prompt di sistema|Rispondi nel modo più completo possibile dal contesto fornito sulla ricerca sulla rimozione del carbonio di Equatic nel file allegato. Non inventare contenuti. Non utilizzare contenuti esterni a questa sessione. Concentrati sui contenuti forniti e crea risposte da essi nel modo più accurato e completo possibile. |\n|||\n|Post del contesto massimo|50|\n|Temperatura|0.1|\n|Top P|1|\n|||\n| ||\n|Upload| Equatics-paper1-with-unique-haystack-needles-v116.txt|\n|||\n|Token chunk di upload|1024|\n|Token di sovrapposizione chunk di upload|10|\n|Chunk di conversazione di ricerca|10|\n|Modello linguistico per il consolidatore di domande|GPT-4o-custom|\n|||\n|BOT PERSONALIZZATO ||\n|||\n|Nome da visualizzare|GPT-4o-custom|\n|||\n|Nome del modello|gpt-4o|\n|||\n|Servizio che ospita il modello|OpenAI|\n|URL del servizio che ospita il modello|https://api.openai.com/v1/chat/completions|\n|API Key del servizio che ospita il modello|D20230943sdf_fake_Qqxo2exWa91|\n|||\n|Tokenizer|OpenAITokenizer|\n|Numero di token per il prompt|30000|
Successo prompt injection:
Fallimento RAG:
