上週我們邀請到了 LangChain 聯合創始人 Harrison Chase 分享【如何用 LangChain 和 Milvus 進行檢索】，Harrison 提到，多跳問題會給語義檢索帶來挑戰，並提出可以試用 AI 代理工具解決。不過，頻繁調用 LLM 會導致出現使用成本高昂的問題。
對此，Zilliz 軟件工程師 Filip Haltmayer 指出，將 GPTCache 與 LangChain 集成，可以有效解決這一問題。
GPTCache 是一個用於存儲 LLM 響應的語義緩存層。它可以爲 LLM 相關應用構建相似語義緩存，當相似的問題請求多次出現時，可以直接從緩存中獲取，在減少請求響應時間的同時也降低了 LLM 的使用成本。
本文爲解碼 LangChain 系列，將從 GPTCache 的適用場景出發，釐清 GPTCache 和 LangChain 集成的原理，並附贈集成教程。
01.
GPTCache 的功能和原理
GPTCache 能做什麼？
降低 LLM 使用費用：目前大多數LLM服務均通過請求token數進行計費，當請求使用緩存結果，自然降低請求次數，則減少了LLM使用成本；
性能優化：相比於大模型的推理時間，從緩存數據中獲取時間將降低一個數量級；
兼容性強，適用於多種應用場景：GPTCache 提供多種 LLM 的鏡像接口，只需修改 import 路徑，即可緩存 LLM 請求；
改善LLM服務的可擴展性和可用性：目前 LLM 服務都有請求速率限制，達到這一限制則服務無法進行響應。如果對於相似的問題使用緩存答案，將有效緩解服務無法響應這一問題。
GPTCache 的推薦場景有哪些？
某一垂直領域的 LLM 相關應用，如法律、生物、醫學等；
固定的 LLM 相關應用，如某公司內部或個人使用的 ChatBot；
開發的 LLM 應用在某些時間內的請求具有高度相似性，如節日祝福語模版等；
具有大用戶羣體的 LLM 應用，如果給用戶羣體進行分類，類似用戶用同一緩存。
LangChain 的大型語言模型（LLM）是一種革命性的技術，允許開發人員構建許多在以前不可想象的應用。然而，僅依靠單個 LLM 就創建一整套應用是幾乎不可能的。因此，我們需要將 LLM 與其他計算資源或知識源進行結合。 LangChain 就能幫助我們將 LLM 和其他知識相結合，從而開發出完美的應用。
02.
LangChain 緩存分析
LangChain 的緩存方式
在學習如何集成 GPTCache 之前，我們先來看看 LangChain 是如何實現緩存的。事實上，LangChain 緩存是通過字符串匹配來實現的。也就是說，如果有兩個請求字符串完全相同，那麼收到後一個請求時，可以從緩存中檢索出相應的數據。具體實現過程中使用了內存緩存（Memory Cache）、SQ Lite 緩存 （SQLite Cache）和 Redis 緩存（Redis Cache）。
LangChain 緩存的使用方法大致如下：
import langchain
from langchain.cache import InMemoryCache
langchain.llm_cache = InMemoryCache()
llm = OpenAI(model_name="text-davinci-002", n=2, best_of=2)
// CPU times: user 14.2 ms, sys: 4.9 ms, total: 19.1 ms
// Wall time: 1.1 s
llm("Tell me a joke")
// CPU times: user 162 µs, sys: 7 µs, total: 169 µs
// Wall time: 175 µs
llm("Tell me a joke")
從運行角度來看，如果請求命中緩存，那麼響應時間會顯著縮短。不過，我們還需要思考另一個問題，即 LLM 高昂的使用成本問題。
我們都知道，使用 OpenAI 和 Cohere 等在線服務通常需要 token，部署相應的 LLM 模型也會產生費用。單次 LLM 推理（inference）時間取決於你的計算資源量，包括 CPU、內存、GPU 等。如果需要同時處理多個請求，對計算資源的要求就更高。如果請求多次命中緩存，則可以減少對計算機資源的壓力，併合理地將更多的計算資源分配給其他任務。
LangChain 命中緩存的條件是兩個問題必須完全相同。但是在實際使用中，這種情況十分罕見，因此很難命中緩存。這也意味着，我們還有很多空間可以用來提升緩存利用率，集成 GPTCache 就是方法之一。
03.
集成 GPTCache
集成 GPTCache 能夠顯着提升 LangChain 緩存模塊的功能，增加緩存命中率，從而降低 LLM 使用成本和響應時間。GPTCache 首先將輸入的問題轉化爲 embedding 向量，隨後 GPTCache 會在緩存中進行向量近似搜索。獲取向量相似性檢索的結果後，GPTCache 會執行相似性評估，並將達到設置閾值的結果作爲最終返回結果。大家可以通過調整閾值來調節 GPTCache 模糊搜索結果的準確性。
以下示例中在 LangChain 中集成了 GPTCache，並使用了 GPTCache 進行向量相似性檢索。
from gptcache import Cache
from gptcache.adapter.api import init_similar_cache
from langchain.cache import GPTCache
import hashlib
def get_hashed_name(name):
return hashlib.sha256(name.encode()).hexdigest()
def init_gptcache(cache_obj: Cache, llm: str):
hashed_llm = get_hashed_name(llm)
init_similar_cache(cache_obj=cache_obj, data_dir=f"similar_cache_{hashed_llm}")
langchain.llm_cache = GPTCache(init_gptcache)
# The first time, it is not yet in cache, so it should take longer
# CPU times: user 1.42 s, sys: 279 ms, total: 1.7 s
# Wall time: 8.44 s
llm("Tell me a joke")
# This is an exact match, so it finds it in the cache
# CPU times: user 866 ms, sys: 20 ms, total: 886 ms
# Wall time: 226 ms
llm("Tell me a joke")
# This is not an exact match, but semantically within distance so it hits!
# CPU times: user 853 ms, sys: 14.8 ms, total: 868 ms
# Wall time: 224 ms
llm("Tell me joke")
以上就是關於 GPTCache 和 LangChain 集成的全部內容。大家如果想了解更多關於 LangChain 和 Milvus 集成的內容，可以閱讀《LLMs 諸神之戰：LangChain ，以【奧德賽】之名》。
預告一下，解碼 LangChain 系列的下一篇將詳解如何用 LangChain 和 Milvus 增強 LLM 應用，以及構建和優化 AIGC 應用的小祕籍，敬請期待！
🌟「尋找 AIGC 時代的 CVP 實踐之星」 專題活動即將啓動！
Zilliz 將聯合國內頭部大模型廠商一同甄選應用場景， 由雙方提供向量數據庫與大模型頂級技術專家爲用戶賦能，一同打磨應用，提升落地效果，賦能業務本身。
如果你的應用也適合 CVP 框架，且正爲應用落地和實際效果發愁，可直接申請參與活動，獲得最專業的幫助和指導！聯繫郵箱爲 [email protected]。
本文分享自微信公衆號 - ZILLIZ（Zilliztech）。
如有侵權，請聯繫 [email protected] 刪除。
本文參與“OSC源創計劃”，歡迎正在閱讀的你也加入，一起分享。