LLM 緩存層的想法讓我們看到了更多的可能性。其實(shí)，GPTCache 的邏輯類(lèi)似于過(guò)去在搭建應(yīng)用時(shí)，增加一層 Redis 和 Memcache，從而加快系統(tǒng)查詢(xún)效率并降低訪(fǎng)問(wèn)數(shù)據(jù)庫(kù)的成本。有了緩存層，在測(cè)試 OSSChat 功能時(shí)，就無(wú)需再額外調(diào)用 ChatGPT 的接口了，省時(shí)省事兒，說(shuō)的就是這個(gè)道理。

不過(guò)，傳統(tǒng)的緩存只在鍵值相同的情況下檢索數(shù)據(jù)，不適用于 AIGC應(yīng)用。

AIGC 需要的是語(yǔ)義近似的緩存，例如「蘋(píng)果手機(jī)」和「iPhone」實(shí)際上都是指蘋(píng)果手機(jī)。

所以，需要專(zhuān)門(mén)為 AIGC 應(yīng)用設(shè)計(jì)搭建了一種全新的緩存，我們給它命名為——GPTCache。

有了它，我們就能夠?qū)ι习偃f(wàn)個(gè)緩存的提問(wèn)向量進(jìn)行向量相似性檢索，并從數(shù)據(jù)庫(kù)中提取緩存的響應(yīng)回答。這樣一來(lái)，OSSChat 端到端的平均響應(yīng)時(shí)間便能顯著降低，也能節(jié)省更多成本。

簡(jiǎn)言之，它可以加速 ChatGPT 響應(yīng)速度并優(yōu)化語(yǔ)義檢索。有了 GPTCache，用戶(hù)只需修改幾行代碼便可緩存 LLM 響應(yīng)，將 LLM 應(yīng)用提速100多倍。

當(dāng)然，進(jìn)行到這里，GPTCache 還只是一個(gè)概念。是否真正具備可行性還需要進(jìn)一步驗(yàn)證。于是，團(tuán)隊(duì)對(duì) OSSChat 發(fā)起了多輪調(diào)研。幾番調(diào)查過(guò)后，我們發(fā)現(xiàn)用戶(hù)的確喜歡提問(wèn)某幾類(lèi)特定的問(wèn)題：

這意味著和傳統(tǒng)應(yīng)用一樣，AIGC 應(yīng)用的用戶(hù)訪(fǎng)問(wèn)同樣具有時(shí)間和空間的局部性。因此，可以完美利用緩存來(lái)減少 ChatGPT 的調(diào)用次數(shù)。

驗(yàn)證完可行性，便到了搭建系統(tǒng)的環(huán)節(jié)。這里我有一點(diǎn)必須要分享，在搭建 ChatGPT 緩存系統(tǒng)時(shí)，Redis 并不是我們的首選。

個(gè)人而言，我很喜歡用 Redis，它性能出色又十分靈活，適用于各種應(yīng)用。但是 Redis 使用鍵值數(shù)據(jù)模型是無(wú)法查詢(xún)近似鍵的。

如果用戶(hù)提出以下兩個(gè)問(wèn)題：

所有深度學(xué)習(xí)框架的優(yōu)缺點(diǎn)是什么？

告訴我有關(guān) PyTorch vs. TensorFlow vs. JAX 的區(qū)別？

Redis 會(huì)將其定義為兩個(gè)不同的問(wèn)題。而事實(shí)上，這兩個(gè)問(wèn)題表達(dá)的是同一個(gè)意思。無(wú)論是通過(guò)緩存整個(gè)問(wèn)題還是僅緩存由分詞器生成的關(guān)鍵字，Redis 都無(wú)法命中查詢(xún)。

而不同的單詞在自然語(yǔ)言中可能具有相同的含義，深度學(xué)習(xí)模型更擅長(zhǎng)處理語(yǔ)義。因此，我們應(yīng)該在語(yǔ)義緩存系統(tǒng)中加入向量相似性檢索這一環(huán)節(jié)。

成本是 Redis 不適用于 AIGC 場(chǎng)景的另一個(gè)原因。邏輯很簡(jiǎn)單，上下文越長(zhǎng)，鍵和值越長(zhǎng)，使用 Redis 存儲(chǔ)內(nèi)容所產(chǎn)生的費(fèi)用也可以就會(huì)高得離譜。因此，使用基于磁盤(pán)（disk-based）的數(shù)據(jù)庫(kù)進(jìn)行緩存可能是更好的選擇。加上 ChatGPT 響應(yīng)較慢，所以對(duì)緩存響應(yīng)速度的要求也不是很高。

話(huà)不多說(shuō)，先放一張 GPTCache 的架構(gòu)圖：

為了簡(jiǎn)化流程，我們最終決定了刪除上下文管理器，所以整個(gè) GPTCache 系統(tǒng)共包含五個(gè)主要組件：

適配器將 LLM 請(qǐng)求轉(zhuǎn)換為緩存協(xié)議，并將緩存結(jié)果轉(zhuǎn)換為 LLM 響應(yīng)。由于想讓 GPTCache 變得更加透明（這樣用戶(hù)無(wú)需額外研發(fā)，便可將其輕松集成到我們的系統(tǒng)或其他基于 ChatGPT 搭建的系統(tǒng)中），所以適配器應(yīng)該方便輕松集成所有 LLM，并可靈活擴(kuò)展，從而在未來(lái)集成更多的多模態(tài)模型。

目前，我們已經(jīng)完成了 OpenAI 和 LangChain 的適配器。未來(lái)，GPTCache 的接口還能進(jìn)一步擴(kuò)展，以接入更多 LLM API。

Embedding 生成器可以將用戶(hù)查詢(xún)的問(wèn)題轉(zhuǎn)化為 embedding 向量，便于后續(xù)的向量相似性檢索。為滿(mǎn)足不同用戶(hù)的需求，我們?cè)诋?dāng)下支持兩種 embedding 生成方式。第一種是通過(guò)云服務(wù)（如 OpenAI、Hugging Face 和 Cohere 等）生成 embedding 向量，第二種是通過(guò)在 ONNX 上使用本地模型生成 embedding 向量。

后續(xù)，GPTCache 還計(jì)劃支持 PyTorch embedding 生成器，從而將圖像、音頻文件和其他類(lèi)型非結(jié)構(gòu)化數(shù)據(jù)轉(zhuǎn)化為 embedding 向量。

緩存管理器是 GPTCache 的核心組件，具備以下三種功能：

緩存管理器采用可插拔設(shè)計(jì)。最初，團(tuán)隊(duì)在后端實(shí)現(xiàn)時(shí)使用了 SQLite 和 FAISS。后來(lái)，我們進(jìn)一步擴(kuò)展緩存管理器，加入了 MySQL、PostgreSQL、Milvus 等。

逐出管理器通過(guò)從 GPTCache 中刪除舊的、未使用的數(shù)據(jù)來(lái)釋放內(nèi)存。必要時(shí)，它從緩存和向量存儲(chǔ)中刪除數(shù)據(jù)。但是，在向量存儲(chǔ)系統(tǒng)中頻繁進(jìn)行刪除操作可能會(huì)導(dǎo)致性能下降。所以，GPTCache 只會(huì)在達(dá)到刪除閾值時(shí)觸發(fā)異步操作（如構(gòu)建索引、壓縮等）。

GPTCache 從其緩存中檢索 Top-K 最相似答案，并使用相似性評(píng)估函數(shù)確定緩存的答案是否與輸入查詢(xún)匹配。

GPTCache 支持三種評(píng)估函數(shù)：精確匹配（exact match）、向量距離（embedding distance）和 ONNX 模型評(píng)估。

相似性評(píng)估模塊對(duì)于 GPTCache 同樣至關(guān)重要。經(jīng)過(guò)調(diào)研，我們最終采用了調(diào)參后的 ALBERT 模型。當(dāng)然，這一部分仍有改進(jìn)空間，也可以使用其他語(yǔ)言模型或其他 LLM（如 LLaMa-7b）。對(duì)于這部分有想法的小伙伴可以聯(lián)系我們！

后期處理器整理最終響應(yīng)返回給用戶(hù)。它可以返回最相似的響應(yīng)或根據(jù)請(qǐng)求的溫度參數(shù)調(diào)整響應(yīng)的隨機(jī)性。如果在緩存中找不到相似的響應(yīng)，后期處理器則會(huì)將請(qǐng)求轉(zhuǎn)發(fā)給 LLM 來(lái)生成響應(yīng)，同時(shí)生成的響應(yīng)將被存儲(chǔ)在緩存中。

接下來(lái)便是檢驗(yàn)成果的重要一步了！為評(píng)估 GPTCache 的性能，我們選取了一個(gè)數(shù)據(jù)集，其中包含三種句子對(duì)：語(yǔ)義相同的正樣本、語(yǔ)義相關(guān)但不完全相同的負(fù)樣本、語(yǔ)義完全不相關(guān)的中間樣本。

為了確定基線(xiàn)（baseline），我們先將 30,000 個(gè)正樣本的鍵存入緩存中。接下來(lái)，我們隨機(jī)選擇 1,000 個(gè)樣本，并使用對(duì)應(yīng)的另 1,000 條句子（句子對(duì)中的另一個(gè)句子）作為查詢(xún)語(yǔ)句。

以下是我們獲得的結(jié)果：

我們發(fā)現(xiàn)，將 GPTCache 的相似性閾值設(shè)置為 0.7 可以較好地平衡命中率和負(fù)相關(guān)比率。因此，所有后續(xù)測(cè)試中都會(huì)應(yīng)用這個(gè)設(shè)置。

用 ChatGPT 生成的相似度分?jǐn)?shù)來(lái)確定緩存的結(jié)果是否與查詢(xún)問(wèn)題相關(guān)。將正樣本閾值設(shè)置為 0.6，使用以下 prompt 生成相似度分?jǐn)?shù)：

（注：以上 prompt 為中文翻譯。原文請(qǐng)見(jiàn)：https://zilliz.com/blog/Yet-another-cache-but-for-ChatGPT）

進(jìn)行包含 50％ 正樣本和 50％ 負(fù)樣本的查詢(xún)，在運(yùn)行 1,160 個(gè)請(qǐng)求后，產(chǎn)生了如下結(jié)果：

命中率幾乎達(dá)到了 50％，命中結(jié)果中的負(fù)樣本比例與實(shí)驗(yàn) 1 相似。這說(shuō)明 GPTCache 善于區(qū)分相關(guān)及不相關(guān)的查詢(xún)。

將所有負(fù)樣本插入到緩存中，并使用它們句子對(duì)中的另一個(gè)句子作為查詢(xún)。雖然某些負(fù)樣本獲得了較高的相似度得分（ChatGPT 認(rèn)為它們的相似度打分大于 0.9），但是沒(méi)有一個(gè)負(fù)樣本命中緩存。原因可能是相似性評(píng)估器中使用的模型針對(duì)該數(shù)據(jù)集進(jìn)行過(guò)微調(diào)，所以幾乎所有負(fù)樣本的相似性打分都降低了。

以上就是團(tuán)隊(duì)進(jìn)行的典型實(shí)驗(yàn)，目前，我們已將 GPTCache 集成到 OSSChat 聊天機(jī)器人中，并努力收集生產(chǎn)環(huán)境中的統(tǒng)計(jì)數(shù)據(jù)。后續(xù)，我也會(huì)發(fā)布基準(zhǔn)測(cè)試報(bào)告，報(bào)告中還包含實(shí)際用例，可以期待一下！

在進(jìn)一步規(guī)劃上面，團(tuán)隊(duì)正努力在 GPTCache 中接入更多 LLM 模型和向量數(shù)據(jù)庫(kù)。此外，GPTCache Bootcamp也即將發(fā)布。大家可以通過(guò) bootcamp 學(xué)習(xí)如何在使用 LangChain、Hugging Face 等過(guò)程中加入 GPTCache，也可以 get 如何將 GPTCache 融入其他多模態(tài)應(yīng)用場(chǎng)景中。

僅僅兩周時(shí)間，我們便完成搭建了 GPTCache 并將其開(kāi)源。在我看來(lái)，這是一件了不起的事情，這離不開(kāi)團(tuán)隊(duì)每一位成員的付出。從他們的身上我一次又一次地感受到開(kāi)發(fā)者這個(gè)群體的沖勁，以及努力實(shí)踐“技術(shù)改變未來(lái)”的信念，感慨良多。

對(duì)于團(tuán)隊(duì)以外的開(kāi)發(fā)者，我也有一些話(huà)想說(shuō)。進(jìn)行這次分享的初衷是希望站在 AIGC 從業(yè)者的角度，和大家分享 ChatGPT 引領(lǐng)的浪潮下，開(kāi)發(fā)者「從 0 到 1」、「從 1 到 100」的探索經(jīng)歷和心得，以求和大家討論、共勉。

當(dāng)然，最最重要的是希望各位開(kāi)發(fā)者能參與到 GPTCache 的共建中。作為一個(gè)新生兒，它仍有很多需要學(xué)習(xí)的地方；而作為一個(gè)為開(kāi)源而生的項(xiàng)目，它需要大家的建議、指正。

GitHub鏈接：https://github.com/zilliztech/GPTCache

關(guān)鍵詞：