說回 OSSChat，如何在保證它在性能提升的同時(shí)還能減少使用成本，成為團(tuán)隊(duì)亟待解決的大問題。煩惱于這件事的解決方案，大家經(jīng)常食不知味。

于是，我明確提出了吃飯時(shí)不聊工作的要求。又是一次午飯時(shí)間，大家你一言我一語地嘮閑嗑。但你知道，程序員聚在一起就那三個(gè)話題：計(jì)算機(jī)、買房和孩子。說著說著，話題就扯到了計(jì)算機(jī)的發(fā)展：在馮·諾依曼的體系結(jié)構(gòu)下有了 CPU、Memory、控制器……由于 CPU 和內(nèi)存在速度上不匹配，慢慢又發(fā)展出了在 CPU 之上的多級緩存。類比到 AI 時(shí)代，大模型就是新的 CPU，Vector Database 是內(nèi)存。那在系統(tǒng)運(yùn)行很慢的情況下……

對了！緩存層！在系統(tǒng)運(yùn)行很慢的情況下，緩存層的重要性就不言而喻了！

既然這樣，為什么不添加一個(gè)緩存層來存儲 LLM 生成的響應(yīng)呢？！這樣一來，我們不僅可以提升 OSSChat 的響應(yīng)速度，還能節(jié)省成本。

這就是 GPTCache 誕生的最初過程。

LLM緩存層的可行性到底有多少？

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

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

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

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

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

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

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

• 熱門話題相關(guān)內(nèi)容
• 熱門 GitHub repo
• “什么是 xxx”的基礎(chǔ)問題
• OSSChat 首頁推薦問題

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

為什么不是Redis？

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

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

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

所有深度學(xué)習(xí)框架的優(yōu)缺點(diǎn)是什么？
告訴我有關(guān) PyTorch vs. TensorFlow vs. JAX 的區(qū)別？

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

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

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

從零搭建GPTCache

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

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

• LLM 適配器（LLM Adapter）

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

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

• Embedding 生成器（Embedding Generator）

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

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

• 緩存管理器（Cache Manager）

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

• 緩存存儲，存儲用戶請求及對應(yīng)的 LLM 響應(yīng)
• 向量存儲，存儲 embedding 向量并檢索相似結(jié)果
• 逐出管理，控制緩存容量并在緩存滿時(shí)根據(jù) LRU 或 FIFO 策略清除過期數(shù)據(jù)

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

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

• 相似性評估器 （Similarity Evaluator）

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

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

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

• 后期處理器（Post Processors）

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

測評環(huán)節(jié)

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

• 實(shí)驗(yàn) 1

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

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

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

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

（注：以上 prompt 為中文翻譯。原文請見：https://zilliz.com/blog/Yet-another-cache-but-for-ChatGPT）

• 實(shí)驗(yàn) 2

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

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

• 實(shí)驗(yàn) 3

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

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

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

One More Thing

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

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

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

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

復(fù)制鏈接，即可參與GPTCache 的開源項(xiàng)目?。ㄇf！千萬記得管理緩存的容量！）