見出し画像

LangChain v0.1.0 の発表内容

鈴木いっぺい (Ippei Suzuki)

Clip source: LangChain v0.1.0

自然言語処理、会話型エージェント、データ分析、オートメーションなどに向けた、オープンソースのLLMアプリ開発フレームワークとして広く使われてます。
v0.1.0 が発表され、かなりアーキテクチャ的に大きな性能や品質が改善されている面が特徴です。特にLangChainの強みはサードパーティツールとの連携です。

LangChain v0.1.0

Jan 8, 2024
本日、弊社は「langchain 0.1.0」のリリースを発表します。これは初の安定版であり、完全に後方互換性を備えています。PythonおよびJavaScriptの両方で利用可能であり、機能性とドキュメンテーションの両方を通じて改善されたフォーカスを提供します。LangChainの安定版は、開発者の信頼を獲得し、ライブラリを体系的かつ安全に進化させる能力を私たちに与えます。

最初に

LangChainは1年余り前に登場し、LLMアプリケーションを構築するためのデフォルトフレームワークとして成長するにつれて、多くの変更が加えられました。1か月前に予告した通り、プロジェクトをより整理し、基盤を強化するために、LangChainパッケージアーキテクチャに大幅な変更を加えることを最近決定しました。
具体的には、二つの大きなアーキテクチャ変更を行いました：langchain-coreの分離と、langchainからパートナーパッケージの分離（langchain-communityへの組み込みまたはスタンドアロンのパートナーパッケージとして）。
ちなみに、langchain-coreには主要な抽象化、インターフェイス、およびコア機能が含まれています。このコードは安定しており、少し前からより厳格なバージョニングポリシーに従っています。
しかし、langchain自体はまだ0.0.xバージョンに留まっていました。すべてのリリースをマイナーバージョン0にすることでいくつかの課題が生じました：

  • ユーザーはアップデートしても破壊的変更がないと確信できなかった

  • 破壊的変更と非推奨通知を減らすために「すべてを維持する」アプローチを取ることで、langchainのコードは膨れ上がり、不安定になりました

しかし、本日のlangchain 0.1.0のリリースをもって、今後のすべてのリリースは新しいバージョニング基準に従います。具体的には：

  • 公開APIに大規模な変更がある場合、マイナーバージョン（2番目の数字）が増加します。

  • バグ修正や新機能の追加は、パッチバージョン（3番目の数字）を増加させます。 私たちは、これらの変更が以下の効果をもたらすと考えています：

  • 破壊的変更があった場合にはそれを明確に伝え、開発者が自信を持ってアップデートできるようにする

  • 古いコードを公式に非推奨として削除するための方法を提供し、膨張を減らす

  • 統合（そのSDKがLangChainと同じくらい速く変化していることが多い）をより責任を持って扱う 0.2バージョンをリリースした後でも、0.1のブランチを維持することを約束しますが、重要なバグ修正のみをパッチします。この投稿の後半で、その計画について詳しく説明します。

安定した0.1リリースへの道を目指してパッケージを再構築する過程で、何百人もの開発者にLangChainを使う理由や好きな点について話をしました。このフィードバックが私たちの方向性と焦点を導きました。また、この機会にPython版とJavaScript版のコアエリアでの均等性を図りました。
特定の統合やより周辺的なチェーンは言語固有かもしれませんが、コアの抽象化と主要機能はPythonとJavaScriptの両方のパッケージで等しく実装されています。
私たちは、LangChainの継続的な改善計画と共に、聞いたことを共有したいと思います。これらの学びを共有することで、私たちの考え方や決定への透明性を高め、他の人がLangChainをよりよく使い、理解し、貢献するのに役立てることを願っています。結局のところ、LangChainの大きな部分は私たちのコミュニティーです - ユーザーベースと2000人以上の貢献者 - そして、私たちは皆さんにも一緒に経験をしてもらいたいと思ってます。

サードパーティ統合

LangChainが提供する最も評価されている点の一つは、どのスタックでも構築を始めることが簡単になる点です。LLMからベクトルストア、エージェント用ツールに至るまで、約700もの統合を提供しています。
LangChainは、LLMアプリを構築するために必要なさまざまな要素を結合する「接着剤」としてよく使われます。そのため、堅牢な統合エコシステムを優先することは、私たちにとって重要です。
約1か月前から、統合の堅牢性、安定性、スケーラビリティ、および一般的な開発者体験を向上させると思われる変更を始めました。すべてのサードパーティ統合をlangchain-communityに分離しました。これにより、統合固有の作業を集中させることができます。また、個々の統合を独自のパッケージに分割し始めました。これまでに、OpenAI、Google、Mistralなどの約10のパッケージでこれを行いました。これによる一つの利点は、依存関係の管理の改善です。以前はすべての依存関係がオプショナルであり、特定のバージョンをインストールしようとするときに頭痛の種になっていました。今では、統合が独自のパッケージにある場合、その要件をより厳格にバージョン管理でき、インストールが容易になります。もう一つの利点はバージョニングです。サードパーティの統合には変更が頻繁にあり、それにより破壊的変更が必要になることがあります。これらは今や、スタンドアロンの統合パッケージ内で適切なバージョニングによって、個々の統合ベースで反映することができます。

オブザーバビリティ

LLMアプリケーションの構築は、システムの中心に非決定論的なコンポーネントを置くことを意味します。これらのモデルはしばしば予期せぬ結果を出力するため、システム内で正確に何が起こっているかを把握することが不可欠です。
私たちは、langchainをできるだけ観測しやすく、デバッグしやすくすることを目指しています。これは、アーキテクチャの決定や私たちが構築するツールを通じて行います。
これをいくつかの方法で取り組んでいます。
主な方法は、LangSmithの構築です。LangSmithが提供する主要な価値提案の一つは、LLMアプリケーションに対する最先端のデバッグ体験です。私たちは、どのステップが行われているか、各ステップの入力と出力、各ステップにかかる時間、その他のデータを正確に記録します。これをユーザーフレンドリーな方法で表示し、どのステップが最も時間を要しているかを特定し、予期せぬLLMの応答をデバッグするためのプレイグラウンドに入ることができます。トークン使用量の追跡なども可能です。プライベートベータ版でさえ、LangSmithへの需要は圧倒的であり、今後数ヶ月で公開ベータ版をリリースし、一般公開するためにスケーラビリティに多大な投資をしています。また、厳格なデータプライバシーポリシーを持つ企業向けに、VPC内デプロイメントを備えたエンタープライズバージョンもすでにサポートしています。
また、観測可能性に関して他の方法でも取り組んでいます。長い間、パイプライン全体で異なるレベルのロギングのためのVerboseモードとDebugモードを組み込んでいました。最近では、作成したチェーンを視覚化する方法や、使用されたすべてのプロンプトを取得する方法を導入しました。

構成可能性

既成のチェーンで始めるのは便利ですが、多くのチームがこれらのアーキテクチャから逸脱し、チェーンをカスタマイズしたいと考えています。プロンプトだけでなく、オーケストレーションのさまざまな部分をカスタマイズしたいのです。
過去数ヶ月間、我々はLangChain Expression Language（LCEL）に大きく開発投資してきました。これにより、任意のシーケンスの構成が可能となり、データエンジニアリングのパイプラインに対するデータオーケストレーションツールが提供する多くの同様の利点（バッチ処理、並列化、フォールバック）が提供されます。
これは、LLMワークロードに固有の利点も提供します。主にLLM固有の観測可能性（上記でカバー）、およびストリーミング（この投稿の後半でカバー）です。
LCELのコンポーネントはlangchain-coreにあります。私たちは、LangChainの特定のチェーンに対して高レベルのエントリーポイントを作成し始めました。これらは徐々に既存の（現在は「レガシー」）チェーンを置き換えることになります。なぜなら、LCELで構築されたチェーンは、ストリーミング、カスタマイズの容易さ、観測可能性、バッチ処理、リトライを自動的に提供するためです。私たちの目標は、この移行をシームレスに行うことです。以前は以下のように行っていました：

ConversationalRetrievalChain.from_llm(llm, …)

私たちはそれを単純に以下のようにしたいと思います：

create_conversational_retrieval_chain(llm, …)

内部的には、特定のLCELチェーンを作成して返します。ロジックを変更したい場合は問題ありません！LCELで書かれているので、サブクラス化したりメソッドをオーバーライドしたりすることなく、一部を簡単に変更できます。
LangChainには多くのチェーンがあり、その多くが頻繁に使用されています。代替のコンストラクタ関数が存在し、使用されて十分にテストされるまで、レガシー版のチェーンを非推奨にすることはありません。

ストリーミング

LLMは応答するのに時間がかかることがあります。エンドユーザーに対して、何も表示されない画面を見つめるのではなく、作業が進行中であることを示すことが重要です。これは、LLMからのトークンのストリーミングや、もしチェーンやエージェントが長時間実行される場合の中間ステップのストリーミングの形で行われることがあります。
私たちはこの両方に大きく投資しています。LCELで構築されたすべてのチェーンは、標準のstreamおよびastreamメソッドを公開し、LLM呼び出しの外部でのストリーミングを保証するために多くの作業を行ってきました（例えば、出力パーサー内で）。また、すべてのチェーンは、LCELチェーンのすべてのステップをストリーミングする標準のastream_logメソッドも公開しています。これらは、中間ステップやその他の情報を簡単に取得するためにフィルタリングすることができます。
ストリーミング（トークンおよび中間ステップ）は、ほとんどのLLMアプリケーションにとって重要なUXコンポーネントであり、LangChainではこれを無料で利用できます。

出力解析

LangChainの主な使用例の一つは「ツールの使用」です。これは、LLMを使用して他のツールを呼び出すことを指します。
LLMが下流のアプリケーションで使用できる構造化された形式で情報を返すことを確実にすることは、LLMがアクションを取ることを可能にするために重要です。
私たちは、出力パーサーの概念を中心に、これを実現するために良い開発者体験を提供することに多くの投資をしています。
これを行う主な方法の一つは、OpenAI Function callingです。出力形式を指定するだけでなく（Pydantic、JSONスキーマ、または関数を使用）、応答を簡単に扱うことも容易にしました。また、OpenAI Function callingをサポートしないモデルでこれを行いたい場合や、プロンプティングを使用する必要がある場合に備えて、さまざまなエンコーディング方法（JSON、XML、Yaml）もサポートしています。プロンプティングを使用する場合は、LLMにどのように応答するかを適切に指示する必要があります。すべての出力パーサーには、これらの指示を取得するget_format_instructionsメソッドが装備されています。
また、出力パーサーを使用して、部分的な結果を生成されるにつれてストリーミングすることで、ユーザー体験を向上させるようなより高度な機能にも投資しています。これには、JSON、XML、CSVなどの構造化された形式からの部分的な結果のストリーミングが含まれます。出力解析では、これが時々難しい場合があります。例えば、JSONブロブを解析するためには、ほとんどのJSONパーサーは完全なJSONブロブを必要とします。私たちの多くの出力パーサーには、この部分的な解析を行うための組み込みロジックが含まれています。

情報検索

開発者が構築しているアプリケーションの主なタイプの一つは、プライベートデータと対話するアプリケーションです。
LLMとデータを簡単に組み合わせることができる能力は、LangChainの非常に重要な部分です。
これは一般的に、2つの異なるコンポーネント、つまりデータの取り込み（データの準備）と検索（データの取得）を含みます。これらの両方について私たちは開発を進めてきました。
データ取り込みの側では、取り組んでいるテキストをチャンクに分割することが大きな部分です。これは簡単なように思えるかもしれませんが、最適な方法はしばしば繊細で、取り扱っている文書の種類に特有のものです。私たちは、HTMLやMarkdownなどの特定の文書タイプに最適化されたものを含む、15種類の異なるテキストスプリッターを持っており、開発者がこのプロセスを最大限にコントロールできるようにしています。しかし、関連データはしばしば変化するもので、私たちのデータ取り込みシステムはプロダクションレベル、スケールアプリケーション向けに設計されています。私たちは、インデックスAPIを公開しており、変更されていない部分を無視してコンテンツを再取り込むことができます。これにより、大量の作業量にかかる時間とコストが節約されます。
検索の側では、より高度な方法に投資すると同時に、検索をよりプロダクションレディにしています。我々は、アカデミアからの高度な検索戦略（FLAREやHydeなど）を実装し、独自のもの（Parent DocumentやSelf-Queryなど）を作成し、他の業界ソリューションからのもの（検索で一般的に使用されるクエリ拡張から派生したMulti-Queryなど）を適応しました。また、複数のユーザーの文書を一緒に保存している場合に不可欠な、ユーザーごとの検索など、プロダクションの懸念事項をサポートするようにしています。
重要なことに、LangChainは高度な検索システムを構築するための必要なコンポーネントを提供していますが、その方法については過度に主張しません。これにより、LangChainの上に構築された多くの他のライブラリが、より主観的なアプローチを提供することになりました。例えば、EmbedChainやGPTResearcherなどです。


エージェント

LangChainが初期から知られるようになったのは、エージェント型のワークロードです。これには2つの意味があります：

  1. ツールの使用：LLMが関数やツールを呼び出すこと。

  2. 推論：LLMが複数回ツールを呼び出す最適な方法とその順序（またはツールを全く呼び出さない場合）。

ツール使用の側面では、私たちは以下のような重要なコンポーネントを大部分カバーしています：

  1. 多くのサードパーティツールとの統合。

  2. それらのツールの入力スキーマに合わせてLLMの応答を構造化する方法。

  3. それらのツールが呼び出されるべきカスタムな方法を指定する柔軟な方法（LCEL）。

推論の側面では、いくつかの異なる「エージェント」メソッドを持っており、これは大まかにはループで動作するLLMと考えることができます。各反復で、呼び出すべきツール（もしあれば）を決定し、そのツールの結果を観察します。私たちは、初期のプロンプティング戦略であるReActを最初から取り入れ、OpenAI Function Callingを使用するもの、新しいツール呼び出しAPIを使用するもの、会話に最適化されたものなど、多くの他のタイプを迅速に追加しました。
柔軟で拡張可能なツールサポートと高度な推論能力を通じて、LangChainはLLMがアクションを取るためのデフォルトの方法となりました。
情報検索と同様に、LangChainはエージェントの構築ブロックを提供しますが、その上に構築されたいくつかのより主観的なフレームワークも見られます。その素晴らしい例の一つがCrewAIで、これはLangChainの上に構築され、マルチエージェントワークロードのためのより簡単なインターフェースを提供しています。

LangChain 0.2

LangChain 0.1をリリースしたばかりですが、すでに0.2について考えています。私たちが特に重視している点は以下の通りです：

  • LCELでのレガシーチェーンの書き直し（より良いストリーミングとデバッグサポートを含む）

  • 新しいタイプのチェーンの追加

  • 新しいタイプのエージェントの追加

  • プロダクションのデータ取り込み機能の向上

  • 古い、使用されていない機能の削除

重要なことは、古いコードやレガシーなコードを取り除いてLangChainをスリムで集中的にすることにワクワクしている一方で、古いバージョンをまだ使用している人たちへのサポートを維持したいと考えていることです。そのため、0.2リリース後少なくとも3ヶ月間は、0.1を安定したブランチとして維持し（重要なバグ修正をパッチとして適用）、今後のすべての安定リリースでこれを行う予定です。
また、貢献を始めたいと思っている方にとって、今が最適な時期です。最近、GitHubに初心者向けの良いイシューを追加しましたので、始める場所を探している方はぜひご覧ください。

もう一つのお知らせ

LangChain v0.1.0の大きな部分は、上述したコアエリアに対する安定性と集中です。LangChainに対する人々の好意的な評価エリアを特定した今、より高度で完全なツールをそこに追加する作業を進めることができます。
LangChainに対する人々の好意的な評価の一つは、エージェントに対するサポートです。ほとんどのエージェントは、ある種のループでLLMを実行するという形で定義されています。これまでのところ、それを行う唯一の方法はAgentExecutorを使用することでした。私たちはAgentExecutorに多くのパラメータと機能を追加しましたが、それは依然としてループを実行するための一つの方法に過ぎませんでした。
langgraphのリリースを発表できることを嬉しく思います。これは、グラフとして言語エージェントを作成するための新しいライブラリです。
これにより、ユーザーはよりカスタムな循環的な動作を作成することができます。明示的な計画ステップや反省ステップを定義することができますし、特定のツールが常に最初に呼び出されるように簡単にハードコーディングすることも可能です。
このライブラリは、PregelやApache Beamに触発されており、現在公開されているインターフェースはNetworkXに触発されたもので、以下のような外観です：

from langgraph.graph import END, Graph 
workflow = Graph() 
workflow.add_node("agent", agent) 
workflow.add_node("tools", execute_tools) 
workflow.set_entry_point("agent") 
workflow.add_conditional_edges(
     "agent",
     should_continue,
     {
         "continue": "tools",
         "exit": END
     }
 ) 
workflow.add_edge('tools', 'agent') 
chain = workflow.compile()

過去6ヶ月間、このプロジェクトに取り組み、ユーザーとのベータテストを行ってきました。現在はOpenGPTsを動かしています。次の数週間で、さらに多くの例とドキュメントを追加する予定です。このプロジェクトにとても興奮しています！
こちらでお試しください。

結論

LangChainは、エコシステムと共に大きく進化しました。私たちは、私たちを押し進め、共に構築してくれるコミュニティとユーザーに非常に感謝しています。この0.1リリースにおいて、私たちはLLMフレームワークにおいてあなたが何を望み、必要としているかを理解する時間を取りました。そして、それを構築することに引き続きコミットしています。コミュニティのニーズが進化するにつれて（または何かが欠けている場合）、私たちはあなたのフィードバックを聞きたいと思っています。そうすることで、私たちはそれに対処することができます。「千里の道も一歩から始まる」と言いますが、私たちの場合は「バージョン0.1から」です。

この記事が気に入ったらサポートをしてみませんか？