Se hai sperimentato modelli linguistici di grandi dimensioni (LLM) per attività di ricerca e recupero, probabilmente ti sei imbattuto nella generazione aumentata di recupero (RAG) come tecnica per aggiungere informazioni contestuali rilevanti alle risposte generate LLM. Collegando un LLM ai dati privati, RAG può consentire una risposta migliore inserendo i dati rilevanti nella finestra di contesto.
RAG ha dimostrato di essere molto efficace per rispondere a domande complesse, attività ad alta intensità di conoscenza e per migliorare la precisione e la pertinenza delle risposte per i modelli di intelligenza artificiale, soprattutto in situazioni in cui i dati di addestramento autonomi potrebbero non essere sufficienti.
Tuttavia, questi vantaggi di RAG possono essere ottenuti solo se si monitora continuamente il sistema LLM nei punti di errore comuni, in particolare con le metriche di valutazione della risposta e del recupero. In questo articolo esamineremo i migliori flussi di lavoro per la risoluzione dei problemi relativi alle metriche di recupero e risposta inadeguate.
Vale la pena ricordarlo RAG funziona meglio quando le informazioni richieste sono prontamente disponibili. Se sono disponibili i documenti pertinenti focalizza le valutazioni del sistema RAG su due aspetti critici:
- Valutazione del recupero: Valutare l’accuratezza e la pertinenza dei documenti recuperati
- Valutazione della risposta: Misurare l’adeguatezza della risposta generata dal sistema quando è stato fornito il contesto
Tabella 1: Metriche di valutazione della risposta
Tabella 2: Metriche di valutazione del recupero
Esaminiamo tre potenziali scenari per risolvere i problemi relativi alle scarse prestazioni LLM in base al diagramma di flusso.
Scenario 1: buona risposta, buon recupero
In questo scenario tutto nell’applicazione LLM funziona come previsto e abbiamo una buona risposta con un buon recupero. Troviamo che la nostra valutazione della risposta è “corretta” e il nostro “Hit = True”. Hit è una metrica binaria, dove “Vero” significa che il documento rilevante è stato recuperato e “Falso” significa che il documento rilevante non è stato recuperato. Tieni presente che la statistica aggregata per Hit è il tasso di successo (percentuale di query con contesto pertinente).
Per le nostre valutazioni delle risposte, la correttezza è una metrica di valutazione che può essere effettuata semplicemente con una combinazione di ingresso (domanda), produzione (risposta) e contesto come si può vedere in Tabella 1. Molti di questi criteri di valutazione non richiedono etichette di verità di base etichettate dall’utente poiché gli LLM possono anche essere utilizzati per generare etichette, punteggi e spiegazioni con strumenti come Chiamata della funzione OpenAIdi seguito è riportato un modello di prompt di esempio.
Questi Valutazioni LLM può essere formattato come numerico, categorico (binario e multiclasse) e multi-output (punteggi o etichette multipli), dove categorico-binario è il più comunemente usato e numerico è il meno comunemente usato.
Scenario 2: risposta negativa, recupero errato
In questo scenario riscontriamo che la risposta non è corretta e il contenuto pertinente non è stato ricevuto. In base alla query vediamo che il contenuto non è stato ricevuto perché non esiste una soluzione alla query. Il LLM non può prevedere gli acquisti futuri, indipendentemente dai documenti forniti. Tuttavia, il LLM può generare una risposta migliore rispetto a una risposta allucinatoria. In questo caso sarebbe opportuno sperimentare il prompt che genera la risposta semplicemente aggiungendo una riga al modello di prompt LLM di “se non vengono forniti contenuti pertinenti e non viene trovata alcuna soluzione conclusiva, rispondere che la risposta è sconosciuta. In alcuni casi la risposta corretta è che la risposta non esiste.
Scenario 3: risposta negativa, metriche di recupero miste
In questo terzo scenario, vediamo una risposta errata con metriche di recupero miste (il documento pertinente è stato recuperato, ma il LLM ha avuto una risposta allucinante a causa delle troppe informazioni fornite).
Per valutare un sistema LLM RAG, è necessario sia recuperare il contesto giusto sia quindi generare una risposta appropriata. In genere, gli sviluppatori incorporeranno una query utente e la utilizzeranno per cercare blocchi rilevanti in un database vettoriale (vedere Figura 3). Le prestazioni di recupero dipendono non solo dal fatto che i blocchi restituiti siano semanticamente simili alla query, ma anche dal fatto che tali blocchi forniscano informazioni rilevanti sufficienti per generare la risposta corretta alla query. Ora devi configurare i parametri del tuo sistema RAG (tipo di recupero, dimensione del blocco e K).
Allo stesso modo con il nostro ultimo scenario, possiamo provare a modificare il modello di prompt o cambiare il LLM utilizzato per generare risposte. Poiché il contenuto pertinente viene recuperato durante il processo di recupero del documento ma non viene visualizzato da LLM, questa potrebbe essere una soluzione rapida. Di seguito è riportato un esempio di risposta corretta generata dall’esecuzione di un modello di prompt rivisto (dopo l’iterazione sulle variabili di prompt, sui parametri LLM e sul modello di prompt stesso).
Quando risolviamo i problemi relativi alle risposte errate con metriche prestazionali miste, dobbiamo prima capire quali metriche di recupero hanno prestazioni inferiori. Il modo più semplice per farlo è implementare soglie e monitoraggi. Una volta che vieni avvisato di una particolare metrica con prestazioni insufficienti, puoi risolverla con flussi di lavoro specifici. Prendiamo ad esempio nDCG. nDCG viene utilizzato per misurare l’efficacia dei documenti in cima alla classifica e tiene conto della posizione dei documenti pertinenti, quindi se recuperi il documento pertinente (Hit = ‘True’), ti consigliamo di implementare una tecnica di riclassificazione per ottenere il documento pertinente documenti più vicini ai primi risultati di ricerca classificati.
Per il nostro scenario attuale abbiamo recuperato un documento rilevante (Hit = ‘True’) e quel documento è in prima posizione, quindi proviamo a migliorare la precisione (percentuale di documenti rilevanti) fino a ‘K’ documenti recuperati. Attualmente la nostra Precision@4 è del 25%, ma se utilizzassimo solo i primi due documenti rilevanti allora Precision@2 = 50% poiché metà dei documenti sono rilevanti. Questo cambiamento porta alla risposta corretta da parte del LLM poiché vengono fornite meno informazioni, ma proporzionalmente più informazioni rilevanti.
Essenzialmente quello che vedevamo qui è un problema comune in RAG noto come perso nel mezzoquando il tuo LLM è sopraffatto da troppe informazioni non sempre rilevanti e quindi non è in grado di dare la migliore risposta possibile. Dal nostro diagramma vediamo che la regolazione della dimensione del blocco è una delle prime cose che molti team fanno per migliorare le applicazioni RAG, ma non è sempre intuitiva. In caso di overflow del contesto e problemi di perdita nel mezzo, un numero maggiore di documenti non è sempre migliore e la riclassificazione non migliorerà necessariamente le prestazioni. Per valutare quale dimensione del blocco funziona meglio, è necessario definire un benchmark di valutazione ed eseguire uno screening sulle dimensioni del blocco e sui valori top-k. Oltre a sperimentare strategie di suddivisione in blocchi, testare diverse tecniche di estrazione del testo e metodi di incorporamento migliorerà anche le prestazioni RAG complessive.
Le metriche e gli approcci di valutazione della risposta e del recupero in questo pezzo offrire un modo completo per visualizzare le prestazioni di un sistema LLM RAG, guidando sviluppatori e utenti nella comprensione dei suoi punti di forza e dei suoi limiti. Valutando continuamente questi sistemi rispetto a questi parametri, è possibile apportare miglioramenti per migliorare la capacità di RAG di fornire informazioni accurate, pertinenti e tempestive.
Ulteriori metodi avanzati per migliorare RAG includono riclassificazioneallegati di metadati, test di diversi modelli di incorporamento, test di diversi metodi di indicizzazione, implementazione Hydeimplementare metodi di ricerca per parole chiave o implementare la modalità documento Cohere (simile a HyDE). Si noti che mentre questi metodi più avanzati – come il suddivisione in blocchi, l’estrazione di testo, la sperimentazione di modelli di incorporamento – possono produrre blocchi più coerenti dal punto di vista contestuale, questi metodi richiedono più risorse. L’utilizzo di RAG insieme a metodi avanzati può apportare miglioramenti alle prestazioni del tuo sistema LLM e continuerà a farlo finché le metriche di recupero e risposta saranno adeguatamente monitorate e mantenute.
Fonte: towardsdatascience.com
