本文經AI新媒體量子位（公眾號ID:QbitAI）授權轉載，轉載請聯系出處。

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

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

最近，有這樣一個項目引發業內關注和討論——GPTCache（https://github.com/zilliztech/GPTCache）。

它使用向量數據庫技術為各種 LLM 應用提供一層語義緩存，能夠存儲 LLM 響應，從而顯著減少檢索數據所需的時間、降低 API 調用開銷、提升應用可擴展性。

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

AIGC人狂喜！

而背后的操盤手正是向量數據庫領域的全球領先者——Zilliz。

早在2019年，它就開源了全球首個向量數據庫項目Milvus，現在全球已經擁有超過1000家企業用戶。

去年11月推出云端全托管的向量數據庫服務Zilliz Cloud（https://zilliz.com/cloud），一經發布就在全球范圍內引發了 LLM 和 AI 開發者的廣泛關注和使用。

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

來康康這究竟是個什么項目？Zilliz 為什么要做這樣一個項目？為了解答這些疑惑，我們找到了 GPTCache 項目的負責人—— Zilliz 合伙人、技術總監欒小凡，他為我們講述了背后的故事。

源于一次午飯閑聊

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

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

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

https://osschat.io

OSSChat 問世后，我們很激動，因為這是一個可以真正造福廣大開發者的應用。但很快團隊便遇到了新的考驗，隨著使用OSSChat用戶越來越多，我們忽然意識到一個問題：ChatGPT 可能會成為阻礙 OSSChat 提升性能的瓶頸。

一來不穩定的 ChatGPT 服務會拉低 OSSChat 響應速度；
二來每次調用 ChatGPT 接口，都會產生新的費用，這導致 OSSChat 的使用成本不斷拉升。

同時，這也驗證了我之前的一個猜測：為什么在 ChatGPT 如此火爆的情況下，LLM 依然沒有得到最為廣泛的應用？答案是因為受制于性能和成本，甚至可以這樣形容，性能和成本是 LLM 難以推廣、應用以及獲取用戶增長的罪魁禍首。

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

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

對了！緩存層！在系統運行很慢的情況下，緩存層的重要性就不言而喻了！

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

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

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

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

不過，傳統的緩存只在鍵值相同的情況下檢索數據，不適用于 AIGC應用。

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

所以，需要專門為 AIGC 應用設計搭建了一種全新的緩存，我們給它命名為——GPTCache。

有了它，我們就能夠對上百萬個緩存的提問向量進行向量相似性檢索，并從數據庫中提取緩存的響應回答。這樣一來，OSSChat 端到端的平均響應時間便能顯著降低，也能節省更多成本。

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

當然，進行到這里，GPTCache 還只是一個概念。是否真正具備可行性還需要進一步驗證。于是，團隊對 OSSChat 發起了多輪調研。幾番調查過后，我們發現用戶的確喜歡提問某幾類特定的問題：

• 熱門話題相關內容
• 熱門 GitHub repo
• “什么是 xxx”的基礎問題
• OSSChat 首頁推薦問題

這意味著和傳統應用一樣，AIGC 應用的用戶訪問同樣具有時間和空間的局部性。因此，可以完美利用緩存來減少 ChatGPT 的調用次數。

為什么不是Redis？

驗證完可行性，便到了搭建系統的環節。這里我有一點必須要分享，在搭建 ChatGPT 緩存系統時，Redis 并不是我們的首選。

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

如果用戶提出以下兩個問題：

所有深度學習框架的優缺點是什么？

告訴我有關 PyTorch vs. TensorFlow vs. JAX 的區別？

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

而不同的單詞在自然語言中可能具有相同的含義，深度學習模型更擅長處理語義。因此，我們應該在語義緩存系統中加入向量相似性檢索這一環節。

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

從零搭建GPTCache

話不多說，先放一張 GPTCache 的架構圖：

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

• LLM 適配器（LLM Adapter）

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

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

• Embedding 生成器（Embedding Generator）

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

后續，GPTCache 還計劃支持 PyTorch embedding 生成器，從而將圖像、音頻文件和其他類型非結構化數據轉化為 embedding 向量。

• 緩存管理器（Cache Manager）

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

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

緩存管理器采用可插拔設計。最初，團隊在后端實現時使用了 SQLite 和 FAISS。后來，我們進一步擴展緩存管理器，加入了 MySQL、PostgreSQL、Milvus 等。

逐出管理器通過從 GPTCache 中刪除舊的、未使用的數據來釋放內存。必要時，它從緩存和向量存儲中刪除數據。但是，在向量存儲系統中頻繁進行刪除操作可能會導致性能下降。所以，GPTCache 只會在達到刪除閾值時觸發異步操作（如構建索引、壓縮等）。

• 相似性評估器 （Similarity Evaluator）

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

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

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

• 后期處理器（Post Processors）

后期處理器整理最終響應返回給用戶。它可以返回最相似的響應或根據請求的溫度參數調整響應的隨機性。如果在緩存中找不到相似的響應，后期處理器則會將請求轉發給 LLM 來生成響應，同時生成的響應將被存儲在緩存中。

測評環節

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

• 實驗 1

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

以下是我們獲得的結果：

我們發現，將 GPTCache 的相似性閾值設置為 0.7 可以較好地平衡命中率和負相關比率。因此，所有后續測試中都會應用這個設置。

用 ChatGPT 生成的相似度分數來確定緩存的結果是否與查詢問題相關。將正樣本閾值設置為 0.6，使用以下 prompt 生成相似度分數：

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

• 實驗 2

進行包含 50％ 正樣本和 50％ 負樣本的查詢，在運行 1,160 個請求后，產生了如下結果：

命中率幾乎達到了 50％，命中結果中的負樣本比例與實驗 1 相似。這說明 GPTCache 善于區分相關及不相關的查詢。

• 實驗 3

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

以上就是團隊進行的典型實驗，目前，我們已將 GPTCache 集成到 OSSChat 聊天機器人中，并努力收集生產環境中的統計數據。后續，我也會發布基準測試報告，報告中還包含實際用例，可以期待一下！

在進一步規劃上面，團隊正努力在 GPTCache 中接入更多 LLM 模型和向量數據庫。此外，GPTCache Bootcamp 也即將發布。大家可以通過 bootcamp 學習如何在使用 LangChain、Hugging Face 等過程中加入 GPTCache，也可以 get 如何將 GPTCache 融入其他多模態應用場景中。

One More Thing

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

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

當然，最最重要的是希望各位開發者能參與到 GPTCache 的共建中。作為一個新生兒，它仍有很多需要學習的地方；而作為一個為開源而生的項目，它需要大家的建議、指正。

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