本文經(jīng)AI新媒體量子位（公眾號ID:QbitAI）授權(quán)轉(zhuǎn)載，轉(zhuǎn)載請聯(lián)系出處。

ChatGPT爆火，為何大模型卻依然沒有得到廣泛的應(yīng)用？

原因無它，受制于性能和成本。

最近，有這樣一個(gè)項(xiàng)目引發(fā)業(yè)內(nèi)關(guān)注和討論——GPTCache（https://github.com/zilliztech/GPTCache）。

它使用向量數(shù)據(jù)庫技術(shù)為各種 LLM 應(yīng)用提供一層語義緩存，能夠存儲(chǔ) LLM 響應(yīng)，從而顯著減少檢索數(shù)據(jù)所需的時(shí)間、降低 API 調(diào)用開銷、提升應(yīng)用可擴(kuò)展性。

簡單來說，有了 GPTCache，受制于性能優(yōu)化與成本的 LLM 應(yīng)用，可以掙脫這些束縛，真正做到省錢、省時(shí)、省力了。

AIGC人狂喜！

而背后的操盤手正是向量數(shù)據(jù)庫領(lǐng)域的全球領(lǐng)先者——Zilliz。

早在2019年，它就開源了全球首個(gè)向量數(shù)據(jù)庫項(xiàng)目Milvus，現(xiàn)在全球已經(jīng)擁有超過1000家企業(yè)用戶。

去年11月推出云端全托管的向量數(shù)據(jù)庫服務(wù)Zilliz Cloud（https://zilliz.com/cloud），一經(jīng)發(fā)布就在全球范圍內(nèi)引發(fā)了 LLM 和 AI 開發(fā)者的廣泛關(guān)注和使用。

上個(gè)月它才被英偉達(dá)老黃在GTC 2023上傾力推薦，更被 OpenAI 官方指定為 ChatGPT Retrieval Plugin 技術(shù)提供商。

來康康這究竟是個(gè)什么項(xiàng)目？Zilliz 為什么要做這樣一個(gè)項(xiàng)目？為了解答這些疑惑，我們找到了 GPTCache 項(xiàng)目的負(fù)責(zé)人—— Zilliz 合伙人、技術(shù)總監(jiān)欒小凡，他為我們講述了背后的故事。

源于一次午飯閑聊

GPTCache 的靈感起源是從一次午飯閑聊時(shí)開始的。

在展開講述前，先普及一個(gè)背景。我的團(tuán)隊(duì)負(fù)責(zé)開源項(xiàng)目 Milvus 的開發(fā)與維護(hù)，需要頻繁為社區(qū)用戶答疑解惑。在這個(gè)過程中，經(jīng)常會(huì)被問及一些基礎(chǔ)文檔相關(guān)或重復(fù)性的問題，加之不斷有新用戶進(jìn)群，最終便形成了一個(gè)「提問、解答、重復(fù)提問、重復(fù)解答」的循環(huán)。而站在用戶的角度，詢問和答疑不都是同步和即時(shí)的（盡管我們一直在努力，但很難做到 24 小時(shí)在線）。尤其在遇到緊急情況時(shí)，可能根本得不到有效反饋。

這就是 OSSChat 的起源。作為一個(gè)開源項(xiàng)目知識(shí)庫的集成者，它可以在 ChatGPT 的基礎(chǔ)上，幫用戶解決在 GitHub 上開源項(xiàng)目的很多問題，例如文檔查找、安裝指南等各種基礎(chǔ)問題。

https://osschat.io

OSSChat 問世后，我們很激動(dòng)，因?yàn)檫@是一個(gè)可以真正造福廣大開發(fā)者的應(yīng)用。但很快團(tuán)隊(duì)便遇到了新的考驗(yàn)，隨著使用OSSChat用戶越來越多，我們忽然意識(shí)到一個(gè)問題：ChatGPT 可能會(huì)成為阻礙 OSSChat 提升性能的瓶頸。

一來不穩(wěn)定的 ChatGPT 服務(wù)會(huì)拉低 OSSChat 響應(yīng)速度；
二來每次調(diào)用 ChatGPT 接口，都會(huì)產(chǎn)生新的費(fèi)用，這導(dǎo)致 OSSChat 的使用成本不斷拉升。

同時(shí)，這也驗(yàn)證了我之前的一個(gè)猜測：為什么在 ChatGPT 如此火爆的情況下，LLM 依然沒有得到最為廣泛的應(yīng)用？答案是因?yàn)槭苤朴谛阅芎统杀荆踔量梢赃@樣形容，性能和成本是 LLM 難以推廣、應(yīng)用以及獲取用戶增長的罪魁禍?zhǔn)住?/strong>

說回 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è)緩存層來存儲(chǔ) 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 會(huì)將其定義為兩個(gè)不同的問題。而事實(shí)上，這兩個(gè)問題表達(dá)的是同一個(gè)意思。無論是通過緩存整個(gè)問題還是僅緩存由分詞器生成的關(guān)鍵字，Redis 都無法命中查詢。

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

成本是 Redis 不適用于 AIGC 場景的另一個(gè)原因。邏輯很簡單，上下文越長，鍵和值越長，使用 Redis 存儲(chǔ)內(nèi)容所產(chǎn)生的費(fèi)用也可以就會(huì)高得離譜。因此，使用基于磁盤（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 的核心組件，具備以下三種功能：

• 緩存存儲(chǔ)，存儲(chǔ)用戶請求及對應(yīng)的 LLM 響應(yīng)
• 向量存儲(chǔ)，存儲(chǔ) 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í)，它從緩存和向量存儲(chǔ)中刪除數(shù)據(jù)。但是，在向量存儲(chǔ)系統(tǒng)中頻繁進(jìn)行刪除操作可能會(huì)導(dǎo)致性能下降。所以，GPTCache 只會(huì)在達(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)，后期處理器則會(huì)將請求轉(zhuǎn)發(fā)給 LLM 來生成響應(yīng)，同時(shí)生成的響應(yīng)將被存儲(chǔ)在緩存中。

測評環(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ù)測試中都會(huì)應(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ù)，我也會(huì)發(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