LangChain、ベクトルデータベース以外の検索手法も利用可能に

要約：LangChain において、VectorDB オブジェクト以外の検索手法も容易に利用できるよう、抽象化レベルを見直しています。この変更の目的は、(1) 外部で構築された検索器を LangChain でより簡単に扱えるようにすること、(2) ハイブリッド検索などの代替検索手法の実験を促進することです。

今回の改修は後方互換性を保っており、既存のチェーンはこれまで通り動作します。ただし、将来的なサポートが最も充実するのは新しい Retrieval チェーンとなるため、できるだけ早く VectorDB チェーンから移行することを推奨します。

詳細は以下のドキュメントをご覧ください：

Python Docs

JS Docs

イントロダクション

ChatGPT の登場以来、多くの人が自社のデータに特化したカスタム ChatGPT を構築してきました。私たちも このためのチュートリアル を執筆し、数ヶ月前には 関連するコンペティション も開催しました。こうした動きは、ChatGPT には重要な限界があることを浮き彫りにしています。つまり、ChatGPT は「あなたのデータ」を知らないのです。もしそれが自社のデータを理解できていれば、多くのユーザーにとってさらに有用なツールになるはずです。

では、自社データを把握したチャットボットをどうやって構築すればよいのでしょうか？

その主要なアプローチが、「Retrieval Augmented Generation（検索拡張生成）」と呼ばれるプロセスです。この手法では、ユーザーの質問をそのまま言語モデルに渡すのではなく、まず回答に関連しそうなドキュメントを検索システムで「取得」します。その後、取得したドキュメントと元の質問を組み合わせて言語モデルに渡し、「生成」ステップを実行します。

LangChain のチームを含め、多くの人がリトリバル（情報検索）を行う主な方法は、セマンティック・サーチ（意味的検索）を利用することです。このプロセスでは、まずすべてのドキュメントに対して数値ベクトル（埋め込み表現：embedding）を計算し、そのベクトルをベクターデータベース（ベクトルの保存と照会に最適化されたデータベース）に格納します。その後、入力されたクエリも同様にベクトル化され、埋め込み空間上でクエリに最も近いドキュメントが検索結果として返されます。

ここでは詳細には立ち入りませんが、このトピックについてより深く解説したチュートリアルは こちら にあります。また、以下の図はこのプロセスをわかりやすく要約しています。

課題

このプロセスは概ねうまく機能しており、私たちが構築してきた多くのコンポーネントや抽象化（埋め込み表現：embeddings やベクターストア：vectorstores）も、このプロセスを円滑に進めるために設計されています。

しかし、私たちは2 つの大きな問題に気づきました。

1 つ目は、このリトリバルステップの実行方法には非常に多くのバリエーションがあることです。人々はセマンティック・サーチ以外のアプローチも求めています。具体的には以下の通りです：

LangChain では、2 つの異なるクエリメソッドをサポートしています。1 つは類似度のみを最適化するもので、もう 1 つは最大限の関連性（MMR: Maximal Marginal Relevance）を最適化するものです。

また、セマンティック検索を行う前に結果をフィルタリングするために、ユーザーがメタデータフィルターを指定したいという要望にも応えています。さらに、グラフなどの他の種類のインデックス こちら についても、多くの関心が寄せられています。

2 つ目の課題として、LangChain の外側でリトリーバーを構築するユーザーもいることに気づきました。例えば OpenAI は `ChatGPT Retrieval Plugin` をリリースしています。私たちは、LangChain 内で作成されたあらゆるリトリーバーを、できるだけ簡単に利用できるようにしたいと考えています。

しかし、私たちは VectorDBQA に中心を置いた抽象化を行うことで、自らのチェーンの利用を制限してしまっていたという過ちを犯していました。これにより、(1) 他の検索手法を実験したいユーザーや、(2) LangChain エコシステムの外側でリトリーバーを作成したユーザーにとって、利用が困難な状態になっていました。

解決策

では、私たちはどのようにこの問題を解決したのでしょうか？

最新の Python および TypeScript リリースにおいて、以下の対応を行いました：

• Retriever の概念を紹介しました。Retriever は、get_relevant_documents メソッドを公開することが期待されます。このメソッドのシグネチャは以下の通りです：def get_relevant_documents(self, query: str) -> List[Document]。これが Retriever に対して私たちが仮定している唯一の条件です。このインターフェースの詳細については、以下をご覧ください。

• VectorDB を使用していたすべてのチェーンを、Retriever を使用する形に切り替えました。これにより、VectorDBQA は RetrievalQA に、ChatVectorDBChain は ConversationalRetrievalChain へとそれぞれ名称変更されています。

なお、今後はチェーンがメモリを使用していることを示すために「Conversational」プレフィックスを、チェーンがチャットモデルを使用していることを示すために「Chat」プレフィックスを意図的に使用します。

LangChain 以外初の Retriever インスタンスとして、`ChatGPT Retrieval Plugin` を追加しました。これは OpenAI が昨日公開したモジュールで、企業が ChatGPT に接続するための検索エンドポイントを公開できるように支援するものです。なお、実質的には ChatGPT Retrieval Plugin の内部仕組みは、当社の VectorStores と極めて類似していますが、新たな柔軟性を示す手段としてこの統合を非常に嬉しく思っています。

Retriever インターフェースの拡張について：

私たちは、可能な限り柔軟性を保つため、メソッドは get_relevant_documents の 1 つのみを必須としています。また、これらの検索器の構築に関する統一されたメソッドについては（現時点では）要求していません。

引数についても、query: str を唯一のものとして強制しています。その他のパラメータ、メタデータフィルタリングを含むものはすべて、検索器自体のパラメータとして保持すべきです。これは、検索器がチェーン内でネストされて使用されることが多く、他のパラメータを外部から渡す手間を省きたいと考えているためです。

これらすべての設計は、LangChain のベクトルストア以外の代替検索器をチェーンやエージェントで使いやすくし、新たな検索手法へのイノベーションを促すことを最終目標としています。

Q&A

Q: インデックスとリトリーバーの違いは何ですか？

A: インデックスは効率的な検索を可能にするデータ構造であり、リトリーバーはそのインデックスを活用してユーザーのクエリに対して関連するドキュメントを検索・返却するコンポーネントです。リトリーバーがその機能を果たすためには、このインデックスが不可欠な要素となります。

Q: 以前、VectorDBQA チェーン（または他の VectorDB タイプのチェーン）で VectorStore を使用していた場合、現在は RetrievalQA チェーンで何を使用すればよいのでしょうか？

A: 既存のベクトルストアから VectorStoreRetriever を作成して利用できます。作成には、vectorstore.as_retriever() を実行します。

Q: VectorDBQA チェーン（または他の VectorDB 型チェーン）は現在も存在しますか？

A: はい、将来的にはこの機能に注力し続ける予定はありません。今後の開発は RetrievalQA チーンで行われることを想定してください。

Q: 新しい検索手法をライブラリに貢献できますか？

A: もちろんです！その目的のために、新たに langchain/retrievers モジュールを開始しました。

Q: これが実現する具体的なユースケースは何ですか？

A: 主な例は、文書に対する質問応答の精度向上です。さらに、過去のメッセージをインデックス化して検索できるようにすれば、AI の長期的な記憶能力として機能させることも可能です。