LangChain v0.1 の概要
以下の記事が面白かったので、かるくまとめました。
1. はじめに
「LangChain」 の目標は、LLMを使用したコンテキスト認識推論アプリの開発をできるだけ簡単にすることです。「LangChain」はこの1年でそれは大きく成長しました。 この成長により、パッケージのアーキテクチャの再考が余儀なくされました。
開発者のエクスペリエンスを向上させるために、古いlangchainパッケージを3つのパッケージに分割します。
これは、「LangChain Templates」「LangServe」「LangSmith」、その上に構築されたその他のパッケージなど、「langchain 」を中心とした急成長するエコシステムをサポートするために行われます。
すべて下位互換性のある方法で行われます。
2. LangChain SDK
「LangChain」のSDKには、次の3つの主要なパーツがあります。
以前は、これら3つのパーツはすべて同じライブラリでした。これは最初は機能していましたが、統合とユースケースの数が時間の経過とともに増加するにつれて、複雑さが持続できなくなりました。再アーキテクチャの主な部分は、これらを 「langchain-core」「langchain-community」「langchain」という個別のパッケージに分離することです。
3. LangChain Core
「langchain-core」は、「Core」と「LangChain Expression Language」 で構成されます。
3-1. Core
「LangChain」の「Core」は、モジュール式で可能な限りシンプルになるように設計されています。これらの抽象化の例には、「Language Model」「Document Loader」「Embedding Model」「Vector Store」「Retriever」などの抽象化が含まれます。
3-2. LangChain Expression Language
「LangChain」の初期リリースには、コンポーネントを結合する共通の方法がありませんでした。キャッチフレーズは「構成可能性によるLLM アプリの構築」でしたが、元の「LangChain」は実際にはそれほど構成可能ではありませんでした。
「LangChain Expression Language」を使用すると、ユーザーは任意のシーケンスを一緒に構成し、LLMアプリを構築する際に重要ないくつかの利点を得ることができます。これらのシーケンスを「Runnable」と呼びます。
すべての「Runnable」は、単一、バッチ、ストリーミング、非同期メソッドを備えた同じインターフェイスを公開します。LLMアプリを構築する場合、単一の同期インターフェイスだけでは十分ではないため、この設計は役立ちます。 バッチは、多くの入力を効率的に処理するために必要です。 ストリーミングは、進捗状況をユーザーに示すために必要です。 非同期インターフェイスは、運用環境に移行するときに便利です。 「LangChain Expression Language」を使用すると、これらすべてに対して複数の実装を作成する必要がなく、実行可能ファイルを一度作成すれば、それをさまざまな方法で呼び出すことができます。
また、一般的なタスクをオーケストレーションするための「Runnable」も作成しました。 すべての「Runnable」は .map メソッドを公開し、その「Runnable」をリストのすべての要素に並行して適用します。 すべての「Runnable」は、エラーが発生した場合のフォールバックを定義できる .with_fallbacksメソッドも公開します。 これらは、LLMアプリを構築するときに一般的で役立つオーケストレーション タスクです。
これらの実行可能ファイルは、以前の「Chain」よりもはるかに検査可能でカスタマイズ可能です。 以前の「Chain」は主に、langchainソース コード内のカスタム クラスでした。これにより、内部で何が起こっているのかを理解することが非常に困難になり、動作を変更することはさらに困難になりました。 「Runnable」は、実行可能ファイルは宣言的な方法で定義されるため、ロジックの理解とパーツの変更が容易になります。
4. LangChain Community
「LangChain」は約700の統合を行っています。この幅広い統合の選択肢は開発者にとって力になりますが、欠点もあります。非常に多くの統合により、すべての依存関係をオプションにしました (LangChain を軽量にするため)。 残念ながら、これにより、特定の統合にどの依存関係が必要なのかを知ることが混乱してしまいます。同じパッケージ内に非常に多くの統合があると、それらを適切にバージョン管理することもほぼ不可能になります。 基礎となる統合自体が急速に変化しています。 いつ変更されたかを知ることが難しいため、統合の不安定性の一因となっています。これらの統合は「LangChain」の他の部分にバンドルされていたため、パッケージ全体の不安定性の原因となりました。
これらの問題に対処するために、すべての統合を別の「langchain-community」パッケージに移動しました。これは、統合コードを分離して区別するのに役立ちます。統合コードには、多くの場合、異なるセットアップ、異なるテスト方法、異なるメンテナンスが必要になります。今後 1 か月間、パートナーと協力して主要な統合をスタンドアロンパッケージに分割する予定です。
5. LangChain
「langchain」パッケージに残るのは、アプリの認知アーキテクチャを構成する「Chain」「Agent」「高度なRetrievalメソッド」「その他の一般化可能なオーケストレーション」の部分です。
これらの一部は、「RAG」を行うための最も人気のあるChainの1つである「ConversationalRetrievalChain」など、古いレガシーチェーンになります。今後もこの種のチェーンをサポートし、維持していきます。 ただし、「LangChain Expression Language」にますます移行していきます。
6. Python と JS の同等性
Python と JS パッケージが相互にどのように関係しているかについて、多くの質問を受けています。 パッケージを分割することで、その方針を説明できます。
7. LangChain Experimental
「langchain-experimental」は、より実験的なツール、チェーン、エージェントを配置する場所として残ります。実験的には、新しすぎてまだ安定していないものと、潜在的なリスクがあるものが含まれます。
8. LangChain Templates
「LangChain Templates」は、GenAIアプリの構築を開始する最も簡単な方法として、2か月前にをリリースしました。 これらは、LangServe を使用して簡単にデプロイできるエンドツーエンドのアプリです。
9. LangServe
「LangServe」は、LangChainアプリをデプロイする最良の方法として、3 か月前にをリリースしました。「LangServe」は、基本的に「FastAPI」をラップして LangChainオブジェクトのエンドポイントを自動的に追加するオープン ソースの Python ライブラリです。複数のエンドポイントを自動的に追加し、それらのエンドポイントの入出力を自動的に推論します。
10. LangSmith
「LangSmith」は、LLMアプリのコントロール センターです。クラス最高のデバッグ エクスペリエンスを提供します。「Chain」と「Agent」のすべてのステップをログに記録することで、次のことが簡単に行えます。
「LangSmith」には、アプリをプロトタイプから本番環境に移行することを目的とした一連の追加ツールも含まれています。
11. ロードマップ
ロードマップは、次のとおりです。
この記事が気に入ったらサポートをしてみませんか?