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
