ChatGPTのキャッシュを追加しました。
ChatGPTは、開発者がゲームを変えるアプリケーションを作成することを可能にする印象的な技術です。しかし、言語モデルモデル(LLM)の性能とコストは、様々な分野への普及を妨げる重要な問題です。例えば、オープンソースコミュニティ向けにチャットボットhttps://osschat.io/を開発した際、ChatGPTが大きなボトルネックとなり、アプリケーションが期待通りに素早く反応することができませんでした。コストもまた、私たちがより多くのオープンソースコミュニティにサービスを提供することを妨げる障害となっています。
チームの昼食会で、あるアイデアが浮かびました：LLMが生成したレスポンスのために、別のキャッシュレイヤーを追加してはどうだろう？このキャッシュ層は、過去にRedisやMemcacheがデータベースへのアクセスを高速化し、コストを削減するために構築されたのと似ている。このキャッシュがあれば、コンテンツ生成にかかる費用を削減し、より高速なリアルタイム・レスポンスを提供できる。さらに、キャッシュはモック・レスポンスに使うことができ、テストに余分な費用をかけずにアプリケーションの機能を検証するのに役立ちます。
従来のキャッシュは、キーが同一である場合にのみデータを取得する。この制限は、自然言語を扱うことが多く、より具体的な構文制限や追加のデータ・クレンジング・メカニズムを必要とするAIGCアプリケーションにとって重大な問題となります。この問題に対処するために、私たちはAIGCネイティブアプリケーションのためのYet Another Cacheを作成しました。これは、ChatGPTを高速化するためにネイティブに構築され、セマンティック検索に最適化されていることから、GPTCache(https://github.com/zilliztech/GPTCache)と名付けました。
GPTCache](https://zilliz.com/what-is-gptcache)を使えば、わずか数行のコード変更でLLMレスポンスをキャッシュし、LLMアプリケーションを100倍高速化することができます。このブログポストでは、セマンティックキャッシュをどのように構築したか、また設計上の選択について説明します。
なぜキャッシュが私たちのユースケースに役立つのでしょうか？
私たちのチャットボットでは、ユーザーがGitHub上のオープンソースプロジェクトに関する一般的な質問や、特定のGitHubリポジトリや関連するドキュメントページに関する詳細な質問をすることができます。私たちのサービスが人気を集めるにつれて、OpenAIのAPIを呼び出すことに関連する費用が増加しています。私たちは、人気のあるトピックやトレンドのトピック、ホットなGitHubリポジトリなど、特定のタイプのコンテンツがより頻繁にアクセスされることを確認しています。"What is "の質問は、サービスのフロントページにあるおすすめの質問リストとともに、最もよくアクセスされています。
従来のアプリケーションと同様に、AIGCアプリケーションのユーザーアクセスには時間的・空間的な局所性がある。ChatGPTの呼び出し回数を減らすキャッシュシステムを実装することで、これを利用することができます。OpenAI APIのレスポンスタイムの遅さとコストの高さを考えると、通常1Mトークンあたり数ドル課金され、レスポンスに数秒かかるこのキャッシュシステムは不可欠です。キャッシュされた何百万ものベクトルの中からベクトル検索を行い、キャッシュされた結果をデータベースから取得することで、私たちのサービスのエンドツーエンドの平均応答時間を大幅に短縮し、OpenAIのサービスコストを下げることができます。
なぜAIGCシナリオではRedisが使えないのか？
私はRedisの大ファンです。Redisはその柔軟性とパフォーマンスから様々なユースケースに適しているからです。しかし、ChatGPTのキャッシュを構築するための最初の選択肢ではありません。RedisはKey-Valueデータモデルを使用しており、近似キーのクエリができません。
例えば、ユーザーが "すべてのディープラーニングフレームワークの利点と欠点を教えてください "とか、"PyTorch vs. TensorFlow vs. JAXについて教えてください "といった質問をしたとします。この場合、彼らは同じことを尋ねている。しかし、Redisは、質問全体をキャッシュしても、トークナイザーから生成されたキーワードのみをキャッシュしても、クエリをヒットすることができません。この失敗は、自然言語では異なる単語が同じ意味を持つことがあり、ディープラーニング・モデルはルールよりもこうしたセマンティクスを明らかにすることに長けているからだ。したがって、セマンティックキャッシュの一部としてベクトルの類似性検索を組み込むべきである。
RedisがAIGCキャッシュに完璧に適合しないもう一つの理由は、そのコストの高さである。長いコンテキストのため、キーと値が大きくなり、Redisにすべてを保存するとすぐに高価になります。chatGPTのレスポンスは遅いので、キャッシュがサブミリ秒で応答できるか数十ミリ秒で応答できるかは問題ではない。
ゼロからGPTCacheを作る
私たちはこのアイデアに興奮し、一晩中議論しました。その結果、以下のような有用なアーキテクチャ図を思いついた：
GPTCacheハイレベル・アーキテクチャ｜Zilliz](https://assets.zilliz.com/GPT_Cache_v2_902abd22f9.png)
その後、私たちはコンテキスト・マネージャーを省いて実装を単純化することにしました。これらの変更にもかかわらず、システムはまだ5つの主要コンポーネントで構成されています。各コンポーネントの重要な機能を以下に列挙する：
1.LLMアダプター：。 アダプタはLLMリクエストをキャッシュ・プロトコルに変換し、キャッシュされた結果をLLMレスポンスに変換する。我々はこのキャッシュを透過的なものにすることを目指しており、我々のシステムやChatGPTに依存する他のシステムに統合するための余分な努力は必要ありません。このアダプタは、すべてのLLMの容易な統合を促進し、将来のマルチモーダルモデル用に拡張可能であるべきです。 当初、私たちのシステムはOpenAIとlangchainに大きく依存しているため、OpenAIとlangchainのアダプタを実装しました。また、複数の実装を行うことで、私たちのインターフェースがすべてのLLM APIで意味を持つことを確認し、アダプターをさらに拡張できるようにしました。 2.埋め込みジェネレータ： 埋め込みジェネレータは、クエリを埋め込みにエンコードし、類似検索を可能にします。様々なユーザーのニーズに応えるため、埋め込みを生成する2つの方法をサポートしています。1つ目は、OpenAI、Hugging Face、Cohereのようなクラウドサービスを利用する方法です。もう1つは、ONNX上で提供されるローカルモデルです。さらに、PyTorch埋め込みジェネレータをサポートし、画像、音声ファイル、その他の種類の非構造化データをエンコードする予定です。 3.キャッシュマネージャ： キャッシュマネージャはGPTCacheのコアコンポーネントであり、3つの機能を提供します。キャッシュストレージはユーザーリクエストとそのLLM応答を保存し、ベクターストレージはベクター埋め込みを保存し、類似した結果を検索します。 キャッシュ・マネージャーはプラグイン可能な設計を採用している。当初はSQLiteとFAISSをバックエンドとして実装した。その後、MySQL、PostgreSQL、Milvus、その他のvector databasesといった他の実装を含むように拡張し、さらにスケーラブルになりました。 EvictionマネージャはGPTCacheから古い未使用のデータを削除することでメモリを解放します。必要なときにキャッシュとベクトルストレージの両方からエントリを削除します。しかし、ほとんどのベクター・ストレージ・システムでは、頻繁な削除はパフォーマンスの低下を引き起こします。GPTCacheはこの問題を軽減するために、削除のしきい値に達するとインデックス構築やコンパクションなどの非同期処理をトリガーします。 4.類似性評価器： GPTCacheはキャッシュから上位k個の類似した回答を取得し、類似性評価関数を使用して、キャッシュされた回答が入力クエリと一致するかどうかを判断します。GPTCacheは3つの評価関数をサポートしています：完全一致評価、埋め込み距離評価、ONNXモデル評価。 類似性評価モジュールはGPTCacheの有効性にとって極めて重要である。調査の結果、我々はALBERTモデルの微調整バージョンを使用した。しかし、他の微調整された言語モデルや、LLaMa-7bのような他のLLMを使用することにより、常に改善の余地があります。ご寄稿、ご提案をお待ちしております。 5.ポストプロセッサー*： ポストプロセッサーは、ユーザーへの最終的な応答を準備する手助けをする。最も類似した応答を返したり、リクエスト温度に基づいてランダム性 を追加したりすることができる。類似の応答がキャッシュに見つからない場合、リクエストは新しい応答を生成し キャッシュするためにLLMに委ねられる。
評価
私たちのアイデアを説明するために、3つの文のペアを含むデータセットを発見した。同一のセマンティクスを持つポジティブなサンプル、関連するが同一のセマンティクスではないネガティブなサンプル、そして全く関連しないセマンティクスを持つポジティブとネガティブのサンプルの間の文である。データセットは私たちのレポにあります。
実験1
ベースラインを確立するために、まず30,000個のポジティブサンプルのキーをキャッシュする。次に、ランダムに1,000個のサンプルを選択し、そのピア値をクエリとして使用する。以下が得られた結果です：
|:---------:|:----------:|:--------:|:--------:|:-----------:| | 876 | 124 | 837 | 39 | 0.20s |
GPTCacheの類似度しきい値を0.7に設定することで、ヒット率と正答率のバランスがとれることがわかりました。したがって、以降のテストではすべてこの設定を使用する。
キャッシュされた結果がクエリに対してポジティブかネガティブかを判断するために、ChatGPTによって生成された類似度スコアを使用し、ポジティブのしきい値を0.6に設定します。この類似度スコアは以下のプロンプトを使用して生成します：
Java 次の2つの質問の類似度を0から1のスケールで評価してください。0は関連性がないことを意味し、1は全く同じ意味を意味します。 独学で勉強するための良いコツは何ですか」と「独学で勉強するための賢いコツは何ですか」という質問はとても似ていて、類似度スコアは1.0です。 荒野でのサバイバルに必要なものは何ですか」という質問と「サバイバルに必要なものは何ですか」という質問はかなり似ており、類似度スコアは0.8である。 16歳のあなたにどんなアドバイスをしますか」という質問と、「オンラインで自分のビジネスをどこで宣伝すべきですか」という質問はまったく違うので、類似度スコアは0です。 では、"サッカーのライブ中継を無料で見られるアプリはどれですか？"と "スマホでサッカーのライブ中継を見るにはどうすればいいですか？"という質問。類似度スコアは
### 実験2
50％のポジティブサンプルと50％のネガティブサンプル（無関係なクエリ）からなるクエリを発行した。その結果、1160のリクエストを実行した結果、以下のような結果が得られた：
| キャッシュヒット｜キャッシュミス｜ポジティブ｜ネガティブ｜ヒットレイテンシー
|:---------:|:----------:|:--------:|:--------:|:-----------:|
| 570 | 590 | 549 | 21 | 0.17s |
ヒット率はほぼ50％で、ヒットした結果のうちネガティブな比率は実験1と同様で、GPTCacheが関連するクエリと関連しないクエリを見分ける素晴らしい仕事をしたことを意味する。
### 実験3
全てのネガティブサンプルをキャッシュに挿入し、そのピア値をクエリとして使用するという別の実験を行いました。いくつかのネガティブサンプルのペアは高い類似度スコア（ChatGPTによると0.9より大きい）を持っていましたが、驚いたことにネガティブサンプルはどれもキャッシュにヒットしませんでした。これは、類似度評価器で使用されているモデルがこのデータセットで微調整されており、ネガティブサンプルの類似度スコアのほとんどすべてが過小評価されているためと考えられます。
### 今後の評価
私たちは GPTCache を OSSChat のウェブサイトに統合し、現在本番用の統計情報を収集中です。実際のユースケースを含む次のベンチマークのリリースにご期待ください。
## ブログはこれで終わりですが、GPTCacheはこれからです。
このような素晴らしい作品を2週間足らずで実装し、オープンソース化できたことに満足しています。ブラボー！GPTCacheのアイデア、実装方法、そしてあなたのシステムにどのように統合できるか、たくさんのアイデアがあることを期待しています。
早速、GPTCacheに関するキーノートをいくつか振り返ってみよう：
1.1.ChatGPTは印象的だが、高価で遅い時もある。
1.他のアプリケーションと同様に、AIGCのユースケースでも局所性を見ることができる。
1.この局所性を完全に利用するために必要なのは、セマンティック・キャッシュだ。
1.セマンティックキャッシュを構築するには、クエリーコンテキストを埋め込み、それをベクターデータベースに保存する。そして、LLMにリクエストを送る前に、キャッシュから類似のクエリを検索する。
1.キャッシュの容量を管理することを忘れないでください！
現在、GPTCacheをより多くのLLMやベクターデータベースと統合する作業を行っています。近々、GPTCache Bootcampをリリースする予定です。GPTCacheをLangChainやHugging Faceと一緒に使う方法や、GPTCacheをマルチモーダルにするための他のアイデアを説明する予定です。また、GPTCacheがあなたのアプリケーションにどのように役立つのか、ぜひ教えてください！
GPTCacheについてもっと知る
* GPTCacheとは](www.zilliz.com/what-is-gptcache)
* OSS Chat, the inspiration to GPTCache](https://zilliz.com/blog/ChatGPT-VectorDB-Prompt-as-code)
* GPTcache githubページ](https://github.com/zilliztech/GPTCache)
* パフォーマンスとコスト改善のためのLLMクエリのキャッシュ](https://zilliz.com/blog/Caching-LLM-Queries-for-performance-improvements)
* Zilliz を無料で試す](https://cloud.zilliz.com/signup)
James LuanJames Luan is the VP of Engineering at Zilliz. With a master's degree in computer engineering from Cornell University, he has extensive experience as a Database Engineer at Oracle, Hedvig, and Alibaba Cloud. James played a crucial role in developing HBase, Alibaba Cloud's open-source database, and Lindorm, a self-developed NoSQL database. He is also a respected member of the Technical Advisory Committee of LF AI & Data Foundation, contributing his expertise to shaping the future of AI and data technologies.
読み続けて
Vector Databases vs. Graph Databases
Use a vector database for AI-powered similarity search; use a graph database for complex relationship-based queries and network analysis.
DeepSeek vs. OpenAI: A Battle of Innovation in Modern AI
Compare OpenAI's o1 and o3-mini with DeepSeek R1's open-source alternative. Discover which AI model offers the best balance of reasoning capabilities and cost efficiency.
Producing Structured Outputs from LLMs with Constrained Sampling
Discuss the role of semantic search in processing unstructured data, how finite state machines enable reliable generation, and practical implementations using modern tools for structured outputs from LLMs.