共计 5412 个字符，预计需要花费 14 分钟才能阅读完成。
🌟 写在后面
黄老板的一句【AI 的 iPhone 时刻已至】震撼了半个科技圈。或者，应该把这句话再扩大一下：AI 的 iPhone 时刻早已势不可挡，它不是平静随和地跟大家 say hi，而是作为一个强悍的伟人携着一把名为 ChatGPT 的斧子，重重地砸开了那扇通向 AI 新世界的大门。
接连几个月，ChatGPT、AutoGPT 等新事物的不断涌现继续刷新着大家的认知。与此同时，圈内一直有类 ChatGPT 或 ChatGPT 相干的新产品问世，当然，这其中也包含我的团队。
最终，咱们从本人的开源我的项目 Milvus 和一顿没有任何目标午饭中别离取得了灵感，做出了 OSSChat、GPTCache。在这个过程中，咱们也在一直承受「从 0 到 1」的考验。作为茫茫 AI 畛域开发者和探索者中的一员，我很违心与诸位分享这背地的故事、逻辑和设计思考，心愿大家能避坑避雷、有所播种。
这次，我想先讲讲 GPTCache。
01. 由一次午饭时闲聊开始的我的项目……
是的，你没看错，GPTCache 的灵感起源是从一次午饭闲聊时开始的。
在开展讲述前，先遍及一个背景。我的团队负责开源我的项目 Milvus 的开发与保护，须要频繁为社区用户答疑解惑。在这个过程中，咱们常常会被问及一些根底文档相干或重复性的问题，加之一直有新用户进群，最终便造成了一个【发问、解答、反复发问、反复解答】的循环。而站在用户的角度，询问和答疑不都是同步和即时的（只管咱们始终在致力，但很难做到 24 小时在线）。尤其在遇到紧急情况时，可能基本得不到无效反馈。
这就是 OSSChat 的起源。作为一个开源我的项目知识库的集成者，它能够在 ChatGPT 的根底上，帮用户解决在 GitHub 上开源我的项目的很多问题，例如文档查找、装置指南等各种根底问题。
OSSChat 问世后，咱们很冲动，因为这是一个能够真正造福宽广开发者的利用。不过，很快团队便遇到了新的考验，随着应用 OSSChat 的用户越来越多，咱们突然意识到一个问题：ChatGPT 可能会成为妨碍 OSSChat 晋升性能的瓶颈。一来不稳固的 ChatGPT 服务会拉低 OSSChat 响应速度；二来每次调用 ChatGPT 接口，都会产生新的费用，这导致 OSSChat 的应用老本一直拉升。
同时，这也验证了我之前的一个猜想：为什么在 ChatGPT 如此火爆的状况下，LLM（大型语言模型）仍然没有失去最为宽泛的利用？答案是因为受制于性能和老本，甚至能够这样形容，性能和老本是 LLM 难以推广、利用以及获取用户增长的罪魁祸首。
说回 OSSChat，如何在保障它在性能晋升的同时还能缩小应用老本，成为团队亟待解决的大问题。懊恼于这件事的解决方案，大家常常食不知味。
于是，我明确提出了吃饭时不聊工作的要求。又是一次午饭时间，大家你一言我一语地唠闲嗑。但你晓得，程序员聚在一起就那三个话题：计算机、买房和孩子。说着说着，话题就扯到了计算机的倒退：在冯·诺依曼的体系结构下有了 CPU、Memory、控制器……因为 CPU 和内存在速度上不匹配，缓缓又倒退出了在 CPU 之上的多级缓存。类比到 AI 时代，大模型就是新的 CPU，Vector Database 是内存。那在零碎运行很慢的状况下……
对了！缓存层！在零碎运行很慢的状况下，缓存层的重要性就显而易见了！
既然这样，为什么不增加一个缓存层来存储 LLM 生成的响应呢？！这样一来，咱们不仅能够晋升 OSSChat 的响应速度，还能节省成本。
这就是 GPTCache 诞生的最后过程。
02.LLM 缓存层的可行性到底有多少？
LLM 缓存层的想法让咱们看到了更多的可能性。其实，GPTCache 的逻辑相似于过来在搭建利用时，减少一层 Redis 和 Memcache，从而放慢零碎查问效率并升高拜访数据库的老本。有了缓存层，在测试 OSSChat 性能时，就无需再额定调用 ChatGPT 的接口了，省时省事儿，说的就是这个情理。
不过，传统的缓存只在键值雷同的状况下检索数据，不适用于 AIGC（人工智能主动生成内容）利用。而 AIGC 须要的是语义近似的缓存，例如【苹果手机】和【iPhone】实际上都是指苹果手机。
所以，须要专门为 AIGC 利用设计搭建了一种全新的缓存，咱们给它命名为——GPTCache。
GPTCache 能干什么？有了它，咱们就可能对上百万个缓存的发问向量进行向量相似性检索，并从数据库中提取缓存的响应答复。这样一来，OSSChat 端到端的均匀响应工夫便能显著升高，也能节俭更多老本。简言之，它能够减速 ChatGPT 响应速度并优化语义检索。有了 GPTCache，用户只需批改几行代码便可缓存 LLM 响应，将 LLM 利用提速 100 多倍。
当然，进行到这里，GPTCache 还只是一个概念。是否真正具备可行性还须要进一步验证。于是，团队对 OSSChat 发动了多轮调研。几番考察过后，咱们发现用户确实喜爱发问某几类特定的问题
- 热门话题相干内容
- 热门 GitHub repo
- “什么是 xxx”的根底问题
- OSSChat 首页举荐问题
这意味着和传统利用一样，AIGC 利用的用户拜访同样具备工夫和空间的局部性。因而，能够完满利用缓存来缩小 ChatGPT 的调用次数。
03. 为什么不是 Redis？
验证完可行性，便到了搭建零碎的环节。这里我有一点必须要分享，在搭建 ChatGPT 缓存零碎时，Redis 并不是咱们的首选。
集体而言，我很喜爱用 Redis，它性能杰出又非常灵便，实用于各种利用。然而 Redis 应用键值数据模型是无奈查问近似键的。如果用户提出以下两个问题：【所有深度学习框架的优缺点是什么？】【通知我无关 PyTorch vs. TensorFlow vs. JAX 的区别？】，Redis 会将其定义为两个不同的问题，而事实上，这两个问题表白的是同一个意思。无论是通过缓存整个问题还是仅缓存由分词器生成的关键字，Redis 都无奈命中查问。
而不同的单词在自然语言中可能具备雷同的含意，深度学习（Deep Learning）模型更善于解决语义。因而，咱们应该在语义缓存零碎中退出向量相似性检索这一环节。
老本是 Redis 不适用于 AIGC 场景的另一个起因。逻辑很简略，上下文越长，键和值越长，应用 Redis 存储内容所产生的费用也能够就会高得离谱。因而，应用基于磁盘（disk-based）的数据库进行缓存可能是更好的抉择。加上 ChatGPT 响应较慢，所以对缓存响应速度的要求也不是很高。
04. 从零搭建 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 和 Co here 等）生成 embedding 向量，第二种是通过在 ONNX 上应用本地模型生成 embedding 向量。
后续，GPTCache 还打算反对 PyTorch embedding 生成器，从而将图像、音频文件和其余类型非结构化数据转化为 embedding 向量。
- 缓存管理器（Cache Manager）
缓存管理器是 GPTCache 的外围组件，具备以下三种性能：
a. 缓存存储，存储用户申请及对应的 LLM 响应
b. 向量存储，存储 embedding 向量并检索类似后果
c. 逐出治理，管制缓存容量并在缓存满时依据 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 来生成响应，同时生成的响应将被存储在缓存中。
05. 激动人心的测评环节
接下来便是测验成绩的重要一步了！为评估 GPTCache 的性能，咱们选取了一个数据集，其中蕴含三种句子对：语义雷同的正样本、语义相干但不完全相同的负样本、语义齐全不相干的两头样本。
试验 1
为了确定基线（baseline），咱们先将 30,000 个正样本的键存入缓存中。接下来，咱们随机抉择 1,000 个样本，并应用对应的另 1,000 条句子（句子对中的另一个句子）作为查问语句。
以下是咱们取得的后果：
咱们发现，将 GPTCache 的相似性阈值设置为 0.7 能够较好地均衡命中率和负相关比率。因而，所有后续测试中都会利用这个设置。
用 ChatGPT 生成的类似度分数来确定缓存的后果是否与查问问题相干。将正样本阈值设置为 0.6，应用以下 prompt 生成类似度分数：
请将以下两个问题的类似度评分在 0 到 1 的范畴内，其中 0 示意不相干，1 示意完全相同的含意。问题“无关自学的一些好的技巧是什么？”和“自学的聪慧技巧是什么？”十分类似，类似度得分为 1.0。问题“野外生存的一些必需品是什么？”和“你须要什么货色能力生存？”相当类似，类似度得分为 0.8。问题“如果您 16 岁，您会给本人什么倡议？”和“我应该在哪里在线推广我的业务？”是齐全不同的，因而类似度得分为 0。*（注：以上 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 融入其余多模态利用场景中。
🌟写在最初
两周，仅仅用了两周，咱们便实现搭建了 GPTCache 并将其开源。在我看来，这是一件了不起的事件，这离不开团队每一位成员的付出。从他们的身上我一次又一次地感触到开发者这个群体的冲劲，以及致力实际“技术扭转将来”的信念，感叹良多。
对于团队以外的开发者，我也有一些话想说。正如开篇提到的，写这篇文章的初衷是站在 AIGC 从业者的角度，和大家分享 ChatGPT 引领的浪潮下，开发者【从 0 到 1】【从 1 到 100】的摸索经验和心得，以求和大家探讨、共勉。
当然，最最重要的是心愿各位开发者能参加到 GPTCache 的共建中。作为一个新生儿，它仍有很多须要学习的中央；而作为一个为开源而生的我的项目，它须要大家的倡议、斧正。
欢送大家复制链接【https://github.com/zilliztech/GPTCache】应用并参加 GPTCache 的开源我的项目！（千万！千万记得治理缓存的容量！）
（本文作者栾小凡系 Zilliz 合伙人、技术总监）
本文由 mdnice 多平台公布
