修改幾行程式碼就讓LLM應用提速100多倍!這個團隊兩週搭建ChatGPT快取層,曾被老黃OpenAI點贊

允中 發自 凹非寺

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

原因無它,受制於性能和成本。

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

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

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

AIGC人狂喜!

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

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

點選閱讀原文or複製連結,即可參與GPTCache 的開源項目!(千萬!千萬記得管理快取的容量!)

*本文系量子位獲授權刊載,觀點僅為作者所有。

相關文章

天線原理(最專業最全面的精華)

天線原理(最專業最全面的精華)

‍ ‍說在前面 ‍‍‍1.寫作目的‍‍‍ 天線作為微波系統的重要組成部分,也應該成為每個通訊工程師完善基礎理論的重要一環,從公眾號創建之初,...