Un'altra cache ancora, ma per ChatGPT
ChatGPT è una tecnologia impressionante che consente agli sviluppatori di creare applicazioni rivoluzionarie. Tuttavia, le prestazioni e il costo dei modelli di linguaggio (LLM) sono problemi significativi che ostacolano la loro ampia applicazione in vari campi. Ad esempio, mentre sviluppavamo un chatbot https://osschat.io/ per la comunità open-source, ChatGPT rappresentava un importante collo di bottiglia che impediva alla nostra applicazione di rispondere con la rapidità prevista. Anche il costo è un altro ostacolo che ci impedisce di servire più comunità open-source.
Durante un pranzo di team, mi è venuta in mente un'idea: perché non aggiungere un ulteriore livello di cache per le risposte generate dagli LLM? Questo livello di caching sarebbe simile a come Redis e Memcache sono stati creati in passato per accelerare e ridurre il costo dell'accesso ai database. Con questa cache, possiamo ridurre le spese per generare contenuti e fornire risposte in tempo reale più rapide. Inoltre, la cache può essere utilizzata per simulare risposte, il che ci aiuta a verificare le funzionalità della nostra applicazione senza sostenere spese aggiuntive per i nostri test.
Le cache tradizionali recuperano i dati solo quando la chiave è identica. Questa limitazione rappresenta un problema significativo per le applicazioni AIGC, che spesso lavorano con il linguaggio naturale e necessitano di restrizioni sintattiche più specifiche o di meccanismi aggiuntivi di pulizia dei dati. Per affrontare questo problema, abbiamo creato Yet Another Cache per applicazioni native AIGC, che abbiamo chiamato GPTCache (https://github.com/zilliztech/GPTCache) poiché è costruita nativamente per accelerare ChatGPT ed è ottimizzata per la ricerca semantica.
Con GPTCache, puoi memorizzare nella cache le risposte del tuo LLM con poche righe di modifiche al codice, rendendo le tue applicazioni LLM 100 volte più veloci. In questo post del blog, descriveremo come abbiamo costruito la cache semantica e alcune delle scelte progettuali che abbiamo fatto.
Perché una cache sarebbe utile nei nostri casi d'uso?
Il nostro chatbot consente agli utenti di porre domande generali sui progetti open-source su GitHub e domande dettagliate su specifici repository GitHub e sulle relative pagine di documentazione. Man mano che il nostro servizio guadagna popolarità, le spese associate alle chiamate alle API di OpenAI aumentano. Abbiamo osservato che alcuni tipi di contenuti, come argomenti popolari o di tendenza e repository GitHub molto seguiti, vengono consultati più frequentemente. Le domande del tipo "Che cos'è" sono le più comunemente consultate, insieme all'elenco di domande consigliate nella pagina principale del servizio.
Come nelle applicazioni tradizionali, l'accesso degli utenti per le applicazioni AIGC presenta località temporale e spaziale. Possiamo sfruttare questo aspetto implementando un sistema di cache che riduce il numero di chiamate a ChatGPT. Considerati il tempo di risposta lento e l'elevato costo delle API di OpenAI, questo sistema di cache è essenziale, poiché in genere vengono addebitati diversi dollari per 1M di token e richiedono alcuni secondi per rispondere. Eseguendo una ricerca vettoriale tra milioni di vettori memorizzati nella cache e recuperando il risultato memorizzato da un database, possiamo ridurre significativamente il tempo medio di risposta end-to-end del nostro servizio e abbassare il costo del servizio OpenAI.
Perché Redis non funziona negli scenari AIGC?
Sono un grande fan di Redis per la sua flessibilità e le sue prestazioni, che lo rendono adatto a vari casi d'uso. Tuttavia, non è la mia prima scelta per costruire una cache per ChatGPT. Redis utilizza un modello di dati chiave-valore e non può interrogare chiavi approssimative.
Ad esempio, supponiamo che un utente ponga domande come "Quali sono i vantaggi e gli svantaggi di tutti i framework di deep learning?" o "Parlami di PyTorch vs. TensorFlow vs. JAX?". In quel caso, stanno chiedendo la stessa cosa. Tuttavia, Redis non riesce a trovare una corrispondenza nella query, sia che si memorizzi nella cache l'intera domanda sia che si memorizzino solo le parole chiave generate da un tokenizer. Questo fallimento è dovuto al fatto che parole diverse possono avere lo stesso significato nel linguaggio naturale, e i modelli di deep learning sono migliori delle regole nel rivelare queste semantiche. Pertanto, dovremmo incorporare la ricerca per similarità vettoriale come parte di una cache semantica.
Un altro motivo per cui Redis potrebbe non essere perfetto per la cache AIGC è il suo costo elevato. Le chiavi e i valori sono grandi a causa del lungo contesto, quindi archiviare tutto in Redis può diventare rapidamente costoso. La memorizzazione nella cache con un database basato su disco potrebbe essere un'alternativa migliore perché le risposte di chatGPT sono lente, quindi non importa se la cache può rispondere in meno di un millisecondo o in decine di millisecondi.
Costruire GPTCache da zero
Siamo entusiasti di questa idea e ne abbiamo discusso durante la notte. Di conseguenza, abbiamo ideato un utile diagramma architetturale mostrato di seguito:
Architettura di alto livello di GPTCache | Zilliz
In seguito, abbiamo deciso di semplificare l'implementazione saltando il gestore del contesto. Nonostante queste modifiche, il sistema è ancora composto da cinque componenti principali. Di seguito abbiamo elencato le funzionalità significative per ciascuno dei componenti:
- Adapter LLM: Gli adapter convertono le richieste LLM nel protocollo della cache e i risultati memorizzati nella cache in risposte LLM. Il nostro obiettivo è rendere questa cache trasparente, senza richiedere sforzi aggiuntivi per integrarla nel nostro sistema o in qualsiasi altro sistema che dipenda da ChatGPT. L'adapter dovrebbe facilitare una facile integrazione di tutti gli LLM ed essere estendibile per futuri modelli multimodali. Inizialmente, abbiamo implementato gli adapter OpenAI e langchain perché il nostro sistema dipende fortemente da essi. Implementazioni multiple hanno anche garantito che la nostra interfaccia avesse senso per tutte le API LLM, così da poter estendere ulteriormente l'adapter.
- Generatore di embedding: Il generatore di embedding codifica le query in embedding, abilitando le ricerche di similarità. Per soddisfare le esigenze di utenti diversi, supportiamo due modi di generare embedding. Il primo è tramite servizi cloud come OpenAI, Hugging Face e Cohere. Il secondo è tramite un modello locale in esecuzione su ONNX. Inoltre, prevediamo di supportare generatori di embedding PyTorch e codificare immagini, file audio e altri tipi di dati non strutturati.
- Gestore della cache: Il gestore della cache è il componente principale di GPTCache, con tre funzioni: archiviazione della cache, che memorizza le richieste degli utenti e le relative risposte LLM; archiviazione vettoriale, che memorizza gli embedding vettoriali e cerca risultati simili; e gestione dell'eviction, che controlla la capacità della cache ed espelle i dati scaduti quando la cache è piena, utilizzando la policy LRU o FIFO. Il Gestore della cache utilizza un design pluggable. Inizialmente, lo abbiamo implementato con SQLite e FAISS come backend. Successivamente, lo abbiamo ampliato includendo altre implementazioni come MySQL, PostgreSQL, Milvus e altri database vettoriali, rendendolo ancora più scalabile. Il Gestore dell'eviction libera memoria rimuovendo da GPTCache dati vecchi e inutilizzati. Rimuove le entry sia dalla cache sia dall'archiviazione vettoriale quando necessario. Tuttavia, eliminazioni frequenti nella maggior parte dei sistemi di archiviazione vettoriale possono causare un calo delle prestazioni. GPTCache attiva operazioni asincrone come la creazione dell'indice o la compattazione una volta raggiunta la soglia di eliminazione per mitigare questo problema.
- Valutatore di similarità: GPTCache recupera dalla sua cache le prime k risposte simili e utilizza una funzione di valutazione della similarità per determinare se una risposta memorizzata nella cache corrisponde alla query di input. GPTCache supporta tre funzioni di valutazione: valutazione della corrispondenza esatta, valutazione della distanza degli embedding e valutazione del modello ONNX. Il modulo di valutazione della similarità è cruciale per l'efficacia di GPTCache. Dopo un'analisi, abbiamo utilizzato una versione fine-tuned del modello ALBERT. Tuttavia, c'è sempre margine di miglioramento utilizzando altri modelli linguistici fine-tuned o altri LLM come LLaMa-7b. Qualsiasi contributo o suggerimento sarebbe molto apprezzato.
- Post Processori: Il Post Processor aiuta a preparare la risposta finale per l'utente. Può restituire la risposta più simile o aggiungere casualità in base alla temperatura della richiesta. Se nella cache non viene trovata alcuna risposta simile, la richiesta verrà delegata agli LLM per generare e memorizzare nella cache una nuova risposta.
Valutazione
Per illustrare la nostra idea, abbiamo scoperto un dataset contenente tre coppie di frasi: campioni positivi con semantica identica, campioni negativi con semantica correlata ma non identica, e frasi tra campioni positivi e negativi con semantica completamente non correlata. Puoi trovare il dataset nel nostro repo.
Esperimento 1
Per stabilire una baseline, per prima cosa memorizziamo nella cache le chiavi di tutti i 30.000 campioni positivi. Successivamente, selezioniamo casualmente 1.000 campioni e utilizziamo i rispettivi valori peer come query. Ecco i risultati che abbiamo ottenuto:
| Cache Hit | Cache Miss | Positivo | Negativo | Latenza hit |
|---|---|---|---|---|
| 876 | 124 | 837 | 39 | 0,20s |
Abbiamo scoperto che impostare la soglia di similarità di GPTCache a 0.7 raggiunge un buon equilibrio tra il rapporto di hit e quello di risultati positivi. Pertanto, useremo questa impostazione per tutti i test successivi.
Per determinare se il risultato memorizzato nella cache è positivo o negativo rispetto alla query, usiamo il punteggio di similarità generato da ChatGPT e impostiamo la soglia positiva a 0.6. Generiamo questo punteggio di similarità usando il seguente prompt:
Valuta la similarità delle seguenti due domande su una scala da 0 a 1, dove 0 significa non correlate e 1 significa esattamente lo stesso significato.
Le domande "Quali sono alcuni buoni consigli per lo studio autonomo?" e "Quali sono i consigli intelligenti per studiare da soli?" sono molto simili, con un punteggio di similarità di 1.0.
Le domande "Quali sono alcune cose essenziali per la sopravvivenza nella natura selvaggia?" e "Quali sono le cose di cui hai bisogno per sopravvivere?" sono piuttosto simili, con un punteggio di similarità di 0.8.
Le domande "Che consiglio daresti al te stesso di 16 anni?" e "Dove dovrei promuovere la mia attività online?" sono completamente diverse, quindi il punteggio di similarità è 0.
Quindi, le domande "Quale app ti permette di guardare il calcio in diretta gratis?" e "Come posso guardare una partita di calcio in diretta sul mio telefono?" Il punteggio di similarità è
Esperimento 2
Abbiamo inviato query composte per il 50% da campioni positivi e per il 50% da campioni negativi (query non correlate). Di conseguenza, dopo aver eseguito 1160 richieste, abbiamo ottenuto i seguenti risultati:
| Cache Hit | Cache Miss | Positivo | Negativo | Latenza dell’hit |
|---|---|---|---|---|
| 570 | 590 | 549 | 21 | 0.17s |
Il rapporto di hit è quasi del 50%, e il rapporto negativo tra i risultati hit è simile a quello dell’esperimento 1, il che significa che GPTCache ha svolto un lavoro eccellente nel distinguere le query correlate da quelle non correlate.
Esperimento 3
Abbiamo condotto un altro esperimento, inserendo tutti i campioni negativi nella cache e usando i loro valori peer come query. Sebbene alcune coppie di campioni negativi avessero un punteggio di similarità elevato (maggiore di 0.9, secondo ChatGPT), con nostra sorpresa, nessuno degli esempi negativi ha generato un hit nella cache. Ciò è probabilmente dovuto al fatto che il modello utilizzato nel valutatore di similarità è fine-tuned su questo dataset, e quasi tutti i punteggi di similarità per i campioni negativi sono stati sottostimati.
Valutazione futura
Abbiamo integrato GPTCache nel nostro sito web OSSChat e ora stiamo lavorando alla raccolta di statistiche di produzione. Quindi restate sintonizzati per il rilascio del nostro prossimo benchmark, che includerà casi d’uso reali.
È la fine del blog, ma solo l’inizio per GPTCache
Siamo soddisfatti di quanto rapidamente siamo riusciti a implementare e rendere open-source un lavoro così straordinario in meno di due settimane. Bravo! Ci auguriamo che ora comprendiate pienamente l’idea di GPTCache, come è stato implementato, e abbiate una miriade di idee su come possa essere integrato nel vostro sistema.
Ricapitoliamo rapidamente alcuni dei punti chiave su GPTCache:
- ChatGPT è impressionante, ma a volte può essere costoso e lento.
- Come in altre applicazioni, possiamo osservare località nei casi d’uso AIGC.
- Per sfruttare appieno questa località, tutto ciò di cui avete bisogno è una cache semantica.
- Per creare una cache semantica, incorporate il contesto della vostra query e memorizzatelo in un database vettoriale. Quindi, cercate query simili nella cache prima di inviare la richiesta agli LLM.
- Ricordate di gestire la capacità della cache!
Stiamo attualmente lavorando all’integrazione di GPTCache con più LLM e database vettoriali. Presto rilasceremo il GPTCache Bootcamp, che spiegherà come usare GPTCache insieme a LangChain e Hugging Face, oltre ad altre idee per rendere GPTCache multi-modale. Accogliamo con piacere qualsiasi contributo o suggerimento e vi incoraggiamo a mostrarci come GPTCache vi aiuta nella vostra applicazione!
Scopri di più su GPTCache
Continua a leggere
A Developer's Guide to Exploring Milvus 2.6 Features on Zilliz Cloud
Milvus 2.6 marks a shift from “vector search + glue code” to a more advanced retrieval engine, and it is now Generally Available (GA) on Zilliz Cloud (a managed Milvus service).
Top 10 Context Engineering Techniques You Should Know for Production RAG
A practical guide to context engineering for production LLM systems, covering RAG, context processing, memory, agents, and multimodal context.
VidTok: Rethinking Video Processing with Compact Tokenization
VidTok tokenizes videos to reduce redundancy while preserving spatial and temporal details for efficient processing.