Riepilogo del webinar: tecniche di recupero per accedere al contesto più rilevante per le applicazioni LLM
Collegare i modelli linguistici di grandi dimensioni (LLM) a fonti di dati esterne è fondamentale per migliorare le prestazioni di molte applicazioni di IA. Queste connessioni prevedono il collegamento a raccolte di dati preesistenti, il richiamo delle conversazioni degli utenti o la generazione di "nuovi ricordi" attraverso la riflessione. Il recupero consiste nell'estrarre informazioni pertinenti da fonti esterne connesse e incorporarle nella query per fornire contesto.
Nel nostro recente webinar, Harrison Chase, cofondatore e CEO di LangChain, e Filip Haltmayer, Software Engineer presso Zilliz, hanno discusso del recupero con LangChain e database vettoriali, della ricerca semantica e dei suoi casi limite. In questo post, esploreremo i punti chiave del webinar e risponderemo ad alcune delle domande rimaste senza risposta del pubblico.
Cos'è il recupero e perché è importante?
In generale, il recupero si riferisce all'accesso alle informazioni dalla memoria o da altri dispositivi di archiviazione. Durante il webinar, Harrison ha spiegato come potremmo sfruttare le tecniche di recupero per portare conoscenza esterna agli LLM utilizzando un database vettoriale come Milvus e un agente di IA come LangChain.
Sebbene gli LLM siano molto potenti, hanno dei limiti poiché conoscono solo le informazioni pre-addestrate, che potrebbero richiedere aggiornamenti. Ad esempio, i dati di ChatGPT arrivano solo fino all'anno 2021, quindi non sanno cosa sia successo dopo. Gli LLM inoltre non dispongono di dati su informazioni specifiche di dominio o proprietarie e di dati sulla tua azienda e sul tuo progetto. Inoltre, anche se l'informazione è presente all'interno dell'LLM, riconoscerla può essere difficile. In questi casi, il recupero può essere un ottimo complemento per fornire agli LLM più contesto per risposte più accurate o portare in primo piano le informazioni target già presenti nell'LLM.
Panoramica della ricerca semantica
Il recupero tramite ricerca semantica è uno dei casi d'uso più critici. Durante il recente webinar, Harrison ha fornito una panoramica di come funziona la ricerca semantica all'interno di una tipica architettura CVP (ChatGPT+Vector store+Prompt as code).
Il diagramma seguente spiega come funziona la ricerca semantica in uno stack CVP. Se un utente pone una domanda generale a cui l'LLM può rispondere, l'LLM risponde direttamente alla domanda. Tuttavia, se la domanda è specifica di dominio, viene trasformata in vettori e inviata a un database vettoriale, come Milvus, che contiene già documenti pertinenti. Il database vettoriale suddivide i record pre-archiviati in blocchi ed embedding, esegue ricerche semantiche per trovare i risultati top-k più pertinenti per la query dell'utente, quindi invia questi risultati a un agente di IA, come LangChain, insieme alla query dell'utente. LangChain combina i risultati con la domanda dell'utente e li invia all'LLM. L'LLM quindi fornisce una risposta soddisfacente.
Come funziona la ricerca semantica in un tipico stack CVP
Casi limite della ricerca semantica
La ricerca semantica è utilizzata da tempo e si è dimostrata utile nell'affrontare molte sfide. Harrison ha illustrato cinque casi limite delle ricerche semantiche durante il webinar e ha analizzato approfonditamente ciascun caso.
Informazioni ripetute
Quando si gestiscono numerosi documenti simili o copiati, recuperare informazioni pertinenti può essere difficile. Questo tipo di contenuto non è adatto agli LLM e può creare contesto non necessario. Harrison ha proposto tre soluzioni per superare questo problema:
Filtra i documenti simili tramite ricerche semantiche prima di inviarli all'LLM. Ad esempio, prima che LangChain invii i prompt a ChatGPT, recupera 20-30 documenti ed elimina quelli simili tramite embeddings oppure li bypassa verso l'LLM.
Sfrutta la max marginal relevance per ottimizzare la diversità. Questa ricerca si concentra sulla somiglianza e sulla diversità rispetto ad altri vettori recuperati.
Deduplica i documenti prima di archiviarli nel database vettoriale. Tuttavia, questo approccio può essere impegnativo, poiché determinare il punteggio di somiglianza che equivale a un duplicato richiede molto lavoro. Un singolo elemento vettoriale potrebbe essere estremamente diverso, generando differenze significative.
Informazioni in conflitto
Le informazioni in conflitto si verificano quando più fonti forniscono risposte diverse a una domanda, il che può creare molta confusione se presenti tutti i dati a un LLM. Ad esempio, se chiedi informazioni sulla politica ferie della tua azienda, potresti ricevere risposte diverse da fonti come il documento HR e alcune note casuali di riunione.
Harrison ha proposto due soluzioni a questo problema:
Dai priorità alle fonti e integra tale ranking nel retrieval.
Passa le informazioni sulla fonte alla fase di generazione, consentendo all'LLM di decidere quale fonte sia più affidabile.
Temporalità
Quando le informazioni cambiano nel tempo, si parla di temporalità. Ad esempio, la politica ferie della tua azienda può cambiare occasionalmente.
Per affrontare questo problema, Harrison propone tre soluzioni:
Ponderazione per recenza nel retrieval: filtrare completamente le informazioni obsolete.
Includere timestamp durante la generazione delle informazioni: chiedere all'LLM di basarsi su informazioni più recenti.
Reflection: rivedere nel tempo la comprensione di un argomento.
Query sui metadati
A volte, gli utenti pongono domande che riguardano più i metadati che il contenuto. Ad esempio, un utente potrebbe cercare film con alieni nel 1980. Mentre "film sugli alieni" può essere cercato semanticamente, 1980 è più una corrispondenza esatta.
Quindi, come possiamo risolvere questo problema? Harrison suggerisce di generare un filtro sui metadati prima di eseguire un retrieval tramite ricerca semantica. Questo approccio prevede la divisione della domanda in due parti: il filtro sui metadati (che è una corrispondenza esatta, come "year equals 1980") e la query (come "alieni o qualcosa del genere" in questo caso).
Ma come applichiamo il filtro sui metadati? Molti vector store consentono l'inclusione diretta di filtri sui metadati nella query. Se ciò non è possibile, è comunque possibile filtrare i risultati dopo il retrieval.
Domande multi-hop
A volte, gli utenti possono porre più domande contemporaneamente, rendendo difficile per la ricerca semantica recuperare tutte le informazioni necessarie dalla domanda originale.
Harrison ha suggerito di utilizzare agenti AI come LangChain per affrontare questa sfida. LangChain può scomporre la domanda in diversi passaggi e utilizzare il modello linguistico come motore di ragionamento per recuperare le informazioni richieste. Tuttavia, questo approccio efficace può generare molte chiamate all'LLM, portando a costi più elevati.
Filip ha consigliato di integrare GPTCache con LangChain perché GPTCache può archiviare domande e risposte generate dall'LLM. Quando gli utenti effettuano query simili la volta successiva, GPTCache esegue ricerche semantiche e fornisce risposte prima di interrogare l'LLM, facendo così risparmiare denaro agli utenti sulle chiamate all'LLM.
Q&A
Abbiamo ricevuto molte domande dal nostro pubblico durante il webinar e abbiamo apprezzato la loro partecipazione. Harrison e Filip hanno risposto ad alcune delle domande durante la sessione di Q&A, ma a causa dei limiti di tempo, alcune sono rimaste senza risposta. Di seguito, abbiamo compilato un elenco delle domande e delle risposte.
Q: Puoi parlare più approfonditamente della generazione di prompt utilizzando fonti di conoscenza esterne? Quali sono alcuni esempi o trucchi che hai utilizzato? LangChain prevede di aggiungere funzionalità che creino prompt ottimizzati?
La chiave del prompting è essere chiari su ciò che si vuole. Se non esprimi chiaramente tutte le tue intenzioni e le informazioni rilevanti, l’LLM non saprà cosa fare, proprio come un essere umano non saprebbe cosa fare. Sì, aggiungeremo alcune funzionalità per l’ottimizzazione dei prompt.
Q: Come vedi l’attuale panorama della retrieval augmented generation? Esistono molte soluzioni come Langchain, Llama Index, Vectara e altre. Qual è la soluzione migliore per ottimizzare le fasi di retrieval, inclusi router query engines e altri? Hai menzionato che la retrieval potrebbe differenziare l’importanza dei documenti: questo è già disponibile tramite LangChain?
L’intero settore è ancora in una fase iniziale e si muove molto rapidamente. Distinguerei la fase di retrieval dalla fase di generation. Per quanto riguarda la retrieval, direi che LangChain offre la massima flessibilità e modularità per personalizzare un sistema di retrieval basato su vettori. Vectara è un’eccellente soluzione end-to-end completamente gestita per la retrieval, che astrae molti dettagli. LlamaIndex offre alcune strutture dati più interessanti, come gli alberi, con cui sperimentare. Indipendentemente dalla fase di retrieval che scegli, tutte utilizzano LangChain durante la fase di generation: abbiamo integrazioni con tutte e tre. Puoi ottenere quella differenziazione con prompt personalizzati.
Q: Come ti aspetti che i casi d’uso per la retrieval e i relativi compromessi vengano influenzati man mano che i limiti di contesto degli LLM aumentano nel tempo?
Perché è ancora necessario avere un database vettoriale per transformer con contesto esteso come l’LLM di Anthropic con lunghezza di contesto di 100k? Beh, i database vettoriali offrono una soluzione molto più conveniente. Quando si tratta di questi LLM, svolgono tutto il lavoro computazionale pesante, mentre il database vettoriale si occupa dell’archiviazione. Tieni presente che le spese di calcolo possono aumentare rapidamente. Quindi, se vuoi inserire più contesto nei tuoi LLM, devi gestire quei costi maggiori. È qui che entra in gioco la bellezza di un database vettoriale. È un’alternativa conveniente perché la maggior parte delle spese è legata al calcolo, che è sempre 100 volte più costoso.
Dipendenze a lungo raggio — gli LLM possono ancora dimenticare cose delle fasi "iniziali" della conversazione, anche con l’architettura transformer.
Q: Cosa ne pensi dei progetti open-source per pubblicare contenuti pre-vettorializzati? Cohere ha pubblicato Wikipedia e un altro progetto ha pubblicato gli abstract di arXiv. Qual è il modello migliore per pubblicare contenuti vettoriali open-source?
È un’ottima idea per imparare la ricerca semantica ed evitare il tempo e il costo aggiuntivi della generazione dei vettori. Al di là di questo, avere i vettori precalcolati ti limita fortemente, poiché non ti consente di modificare come o cosa viene incorporato. Per quanto riguarda il modello migliore, non ce n’è uno che dia i risultati migliori per i dati che stai utilizzando: più popolare è il modello che usi, maggiore è la probabilità che il tuo dataset venga utilizzato.
Q: Come funziona il sottopacchetto memory in LangChain? Perché la cronologia dei messaggi di chat è separata dalla memory? Perché l’avete progettato in questo modo?
Stiamo lavorando a una revisione della memory per renderlo più chiaro.
Guarda la registrazione completa del webinar!
Guarda la registrazione del webinar per maggiori informazioni su LangChain e sulla discussione tra Filip e Harrison.
Continua a leggere
From Vector Database to Vector Lakebase
Zilliz offers a fully managed Vector Lakebase powered by Milvus, unifying real-time vector search, lake-scale discovery, and Al data operations.
DeepSeek-OCR Explained: Optical Compression for Scalable Long-Context and RAG Systems
Discover how DeepSeek-OCR uses visual tokens and Contexts Optical Compression to boost long-context LLM efficiency and reshape RAG performance.
Optimizing Embedding Model Selection with TDA Clustering: A Strategic Guide for Vector Databases
Discover how Topological Data Analysis (TDA) reveals hidden embedding model weaknesses and helps optimize vector database performance.