ウェビナーのまとめLLMアプリケーションに最も関連性の高いコンテキストにアクセスするための検索テクニック
大規模言語モデル（LLM）を外部データソースと接続することは、多くのAIアプリケーションのパフォーマンスを向上させるために極めて重要である。これらの接続には、既存のデータコレクションとのリンク、ユーザーとの会話の想起、リフレクションによる「新しい記憶」の生成が含まれる。検索とは、接続された外部ソースから関連情報を抽出し、それをクエリに組み込んでコンテキストを提供することである。
先日のウェビナーでは、LangChainの共同設立者兼CEOであるHarrison Chaseと、ZillizのソフトウェアエンジニアであるFilip Haltmayerが、LangChainとベクトルデータベースによる検索、セマンティック検索、そしてそのエッジケースについて議論した。この投稿では、ウェビナーから得られた重要なポイントを探り、聴衆の未回答の質問にお答えします。
ウェビナーを見る](https://zilliz.com/event/memory-for-llm-applications-webinar)
検索とは何か、なぜ重要なのか？
一般的に検索とは、メモリやその他の記憶装置から情報にアクセスすることを指す。ウェビナーでハリソンは、MilvusのようなベクトルデータベースとLangChainのようなAIエージェントを使用して、LLMに外部の知識をもたらすために検索技術を活用する方法を説明した。
LLMは非常に強力ですが、事前に訓練された情報しか知らないため限界があり、更新が必要な場合があります。例えば、ChatGPTのデータは2021年までしかカバーしていないため、それ以降のことはわからない。また、LLMには、ドメイン固有の情報や専有情報、ビジネスやプロジェクトに関するデータもありません。さらに、たとえLLM内に情報があったとしても、それを認識することが困難な場合もある。このような場合、検索は、LLMにより正確な回答のための文脈を与えたり、LLMにすでにある対象情報を前面に出したりするための、大きな補助となります。
セマンティック検索の概要
セマンティック検索](https://zilliz.com/glossary/semantic-search)による検索は、最も重要なユースケースの一つである。最近のウェビナーで、ハリソンは典型的なCVPアーキテクチャ(ChatGPT+ベクターストア+コードとしてのプロンプト)の中で、セマンティック検索がどのように機能するかの概要を説明した。
次の図は、CVPスタックでセマンティック検索がどのように機能するかを説明しています。ユーザがLLMが答えられるような一般的な質問をした場合、LLMはその質問に直接答える。しかし、その質問がドメインに特化したものである場合、その質問はベクトルに変換され、すでに関連文書を含むMilvusのようなベクトル・データベースに送られる。ベクトルデータベースは、あらかじめ格納されたレコードをチャンクとエンベッディングに分解し、意味検索を実行してユーザーのクエリに最も関連性の高い「トップk」の結果を見つけ、これらの結果をユーザーのクエリとともにLangChainのようなAIエージェントに送信する。LangChainは結果をユーザーの質問と組み合わせ、LLMに送る。そして、LLMは満足のいく回答を提供する。
典型的なCVPスタックにおけるセマンティック検索の仕組み](https://assets.zilliz.com/CVP_stack_architecture_20230908_025613_654b318146.png)
セマンティック検索のエッジケース
セマンティック検索は以前から使われており、多くの課題に対処するのに役立っていることが証明されている。ハリソン氏はウェビナーの中で、セマンティック検索の5つのエッジケースを実演し、それぞれのケースを徹底的に分析した。
繰り返される情報
多数の類似文書やコピーされた文書を扱う場合、関連情報を検索することは困難である。このようなコンテンツはLLMには不向きで、不必要な文脈を作り出す可能性がある。Harrison氏はこの問題を克服するために3つの解決策を提案した：
LLMに送る前にセマンティック検索で類似文書をフィルタリングする。例えば、LangChainはChatGPTにプロンプトを送る前に、20-30個のドキュメントを検索し、エンベッディングによって類似したものを排除するか、LLMにバイパスする。
多様性を最適化するために最大限界関連性を活用する。この検索では、他の検索ベクトルとの類似性と多様性に注目する。
ベクトルデータベースに格納する前に文書を重複排除する。しかし、重複に相当する類似度スコアの決定には多くの労力を要するため、このアプローチは困難である。1つのベクトル要素が大きく異なる可能性があり、結果として大きな違いが生じる。
情報の矛盾
情報の矛盾は、複数のソースが質問に対して異なる回答を提供する場合に発生します。LLMにすべてのデータを提示すると、非常に混乱する可能性があります。例えば、会社の休暇制度について質問した場合、人事部の文書や無作為の会議メモなどから、異なる回答を得る可能性があります。
ハリソンはこの問題に対して2つの解決策を提案した：
ソースに優先順位を付け、その順位を検索に組み込む。
ソース情報を生成ステップに渡し、どのソースがより信頼できるかを LLM が判断できるようにする。
時間性
情報が時間と共に変化することを時間性と呼ぶ。例えば、あなたの会社の休暇規定が時々変更されるかもしれません。
この問題に取り組むために、ハリソンは3つの解決策を提案している：
検索における再帰性の重み付け：古い情報を完全にフィルタリングする。
情報生成時にタイムスタンプを含める：LLMに、より新しい情報に依存するよう求める。
振り返り：時間の経過とともにトピックの理解を修正すること。
メタデータの照会
ユーザーがコンテンツよりもメタデータについて質問することがあります。例えば、あるユーザーが1980年のエイリアンを扱った映画を検索するとします。エイリアンについての映画」は意味的に検索できますが、1980年は完全一致です。
では、どうすればこの問題を解決できるのだろうか？ハリソン氏は、意味検索を実行する前にメタデータフィルターを生成することを提案している。このアプローチでは、質問を2つの部分に分割する。メタデータフィルター（「year equals 1980」のような完全一致）とクエリ（この場合は「aliens or something」のような）である。
しかし、どのようにメタデータフィルタを適用するのでしょうか？多くのベクターストアでは、クエリに直接メタデータフィルタを含めることができます。それができない場合でも、検索後に結果をフィルタリングすることは可能です。
マルチホップに関する質問
時には、ユーザーが一度に複数の質問をすることがあり、セマンティック検索が元の質問から必要なすべての情報を取得することが難しくなります。
ハリソンは、この課題に取り組むためにLangChainのようなAIエージェントを使うことを提案した。LangChainは質問をいくつかのステップに分解し、言語モデルを推論エンジンとして使って必要な情報を取り出すことができる。しかし、この説得力のあるアプローチは、多くのLLMコールを生成し、より高いコストにつながる可能性がある。
FilipはGPTCache with LangChainを統合することを推奨した。なぜならGPTCacheはLLMによって生成された質問と答えを保存することができるからだ。GPTCacheは、LLMによって生成された質問と回答を保存することができるからです。ユーザーが次回同じような質問をするとき、GPTCacheはLLMに問い合わせる前に意味検索を行い、回答を返します。
Q&A
ウェビナーでは聴衆から多くの質問を受け、その参加に感謝した。HarrisonとFilipはQ&Aセッションでいくつかの質問に答えましたが、時間の関係で答えられなかったものもありました。以下に、質問と回答をまとめました。
Q: 外部知識ソースを使ってプロンプトを生成する方法について詳しく教えてください。どのような例やトリックがありますか？LangChainは最適化されたプロンプトを作成する機能を追加する予定はありますか？
プロンプト作成で重要なのは、何をしたいのかを明確にすることです。もしあなたがすべての意図と関連情報を明確に表現しなければ、LLMは何をすればいいのかわかりません。はい、プロンプトの最適化に関する機能を追加する予定です。
Q: 検索拡張世代の現在の状況をどのように見ていますか？Langchain、Llama Index、Vectaraなど多くのソリューションがあります。ルーター・クエリー・エンジンなども含め、検索ステップを微調整するための最適なソリューションは何でしょうか？検索で文書の重要度を区別できるとおっしゃっていましたが、これはすでにLangChainで利用可能なのでしょうか？
この分野全体はまだ初期段階であり、超高速で動いています。検索のステップと生成のステップを区別します。検索に関しては、LangChainはベクトルベースの検索システムをカスタマイズするための最も柔軟なモジュール性を提供していると言えるでしょう。Vectaraは、検索のための優れたエンド・ツー・エンドのフルマネージド・ソリューションで、細部の多くを抽象化している。LlamaIndexは、ツリーのような、より興味深いデータ構造を提供する。どの検索ステップを選んでも、生成ステップではLangChainを使います。カスタマイズされたプロンプトで差別化を図ることができます。
Q: LLMのコンテキストの上限が時間の経過とともに増加した場合、検索のユースケースや関連するトレードオフはどのような影響を受けると予想されますか？
Anthropicの100kコンテキストの長さのLLMのような拡張コンテキストのトランスフォーマーのために、ベクターデータベースが必要なのはなぜですか？ベクターデータベースは、より費用対効果の高いソリューションを提供します。これらのLLMに関しては、重い計算はすべてLLMが行い、ストレージはベクターデータベースが行います。計算費用はすぐにかさむので注意してください。つまり、LLMにもっと多くのコンテクストを詰め込みたいのであれば、増大するコストに対処しなければならない。そこでベクター・データベースの出番となる。なぜなら、ほとんどの経費は計算に関するものであり、計算には常に100倍以上のコストがかかるからです。
長距離の依存関係 - LLMは、トランスフォーマー・アーキテクチャーであっても、会話の「初期」から何かを忘れてしまう可能性がある。
Q: あらかじめベクトル化されたコンテンツを提供するオープンソースのプロジェクトについてはどうお考えですか？CohereはWikipediaを出したし、別のプロジェクトはarXivのアブストラクトを出した。オープンソースのベクターコンテンツを提供するための最良のモデルは何でしょうか？
セマンティック検索について学び、ベクトルを生成する余分な時間とコストを避けるのは素晴らしいアイデアだ。それ以外の点では、ベクターが事前に計算されていると、どのように埋め込むか、何を埋め込むかを変更することができないため、制限が厳しくなります。最良のモデルについては、あなたが使っているデータに対して最良の結果を与えるものはありません。
Q: LangChainのメモリサブパッケージはどのように機能しますか？なぜチャットメッセージの履歴はメモリから分離されているのですか？なぜこのように設計したのですか？
これをより明確にするために、メモリの刷新に取り組んでいます。
ウェビナーの全記録を見る！
ウェビナーの録画](https://zilliz.com/event/memory-for-llm-applications-webinar)で、LangChainとフィリップとハリソンのディスカッションをご覧ください。
読み続けて
Data Deduplication at Trillion Scale: How to Solve the Biggest Bottleneck of LLM Training
Explore how MinHash LSH and Milvus handle data deduplication at the trillion-scale level, solving key bottlenecks in LLM training for improved AI model performance.
Building RAG Pipelines for Real-Time Data with Cloudera and Milvus
explore how Cloudera can be integrated with Milvus to effectively implement some of the key functionalities of RAG pipelines.
DeepRAG: Thinking to Retrieval Step by Step for Large Language Models
Discover DeepRAG, an advanced retrieval-augmented generation (RAG) model that improves LLM accuracy by retrieving only essential data through step-by-step reasoning.