なぜLangChainを諦めたのですか？

おそらく、LangChain は生まれたその日から、評判が二極化する製品となることが運命づけられていました。

LangChain について楽観的な人は、その豊富なツールやコンポーネント、統合の容易さを高く評価していますが、LangChain について楽観的ではない人は、LangChain は失敗する運命にあると信じています。この急速な技術変化の時代において、それを実現するのはまったく不可能です。すべてを LangChain で構築します。

少し誇張:

「コンサルティングの仕事では、人々に langchain や llamaindex を使用しないように説得することにエネルギーの 70% を費やしています。これで彼らの問題の 90% が解決されます。」

最近、LangChain の苦情が再び記事になりました。熱い議論の焦点:

著者の Fabian Both は、AI テスト ツール Octomind の深層学習エンジニアです。 Octomind チームは、複数の LLM を持つ AI エージェントを使用して、Playwright でエンドツーエンドのテストを自動的に作成および修正します。

これは、LangChainの選定から始まり、LangChainとの粘り強い闘いの段階に入るまでの1年以上続いた物語です。 2024年、彼らはついにLangChainに別れを告げることを決めた。

彼らが経験したことを見てみましょう:

「LangChain が最良の選択でした」

私たちは、2023 年の初めに開始して 2024 年に削除するまで、12 か月間以上実稼働環境で LangChain を使用していました。

2023 年には、LangChain が最良の選択となるようです。コンポーネントやツールが豊富に揃っており、その人気は急上昇しています。 LangChain は、「開発者が午後のうちにアイデアから実行可能なコードに移行できるようにする」と約束していましたが、ニーズがますます複雑になるにつれて、問題が表面化し始めました。

LangChain は生産性の源ではなく抵抗の源になります。

LangChain の柔軟性のなさが露呈し始めたため、私たちはシステムの根本的な動作を改善するために LangChain の内部をさらに深く調査し始めました。ただし、LangChain は多くの詳細を意図的に抽象化しているため、必要な基礎となるコードを簡単に記述することはできません。

ご存知のとおり、AI と LLM は急速に変化しており、新しい概念やアイデアが毎週登場しています。ただし、複数の新興テクノロジーを中心に作成された抽象的な概念である LangChain のフレームワーク設計は、時の試練に耐えることが困難です。

LangChain が抽象的な理由

最初は、単純なニーズが LangChain の使用上の想定と一致する場合にも、LangChain は役に立ちます。しかし、その高レベルの抽象化により、コードはすぐに理解が難しくなり、保守が困難になりました。チームが機能の構築と同じくらい LangChain の理解とデバッグに時間を費やしている場合、それは良い兆候ではありません。

LangChain の抽象的なアプローチの問題は、「英語の単語をイタリア語に翻訳する」という簡単な例で説明できます。

OpenAI パッケージのみを使用した Python の例を次に示します。

これは、1 つのクラスと 1 つの関数呼び出しのみを含む、シンプルで理解しやすいコードです。残りは標準の Python コードです。

これを LangChain のバージョンと比較してください:

コードはほぼ同じですが、類似点はそこだけです。

これで、3 つのクラスと 4 つの関数呼び出しができました。しかし、懸念されるのは、LangChain が 3 つの新しい抽象概念を導入していることです:

• プロンプト テンプレート: LLM のプロンプトを提供します;

• 出力パーサー: LLM からの出力を処理します。 Python の | 演算子について説明します。

• LangChain が行うことは、明白なメリットなしでコードの複雑さを増すだけです。

この種のコードは、初期のプロトタイプには適しているかもしれません。ただし、運用環境で使用する場合は、実際の使用条件で予期せずクラッシュしないように、各コンポーネントを合理的に理解する必要があります。指定されたデータ構造を遵守し、これらの抽象化に基づいてアプリケーションを設計する必要があります。

Python での別の抽象的な比較を見てみましょう。今回は API から JSON を取得します。

組み込みの http パッケージを使用します:

requests パッケージを使用します:

違いは明らかです。これが優れた抽象化の感じです。

もちろん、これらは些細な例です。しかし、私が言いたいのは、優れた抽象化によりコードが簡素化され、コードを理解するために必要な認知的負荷が軽減されるということです。

LangChain は、詳細を隠し、より少ないコードでより多くのことを実行することで、あなたの作業を楽にしようとします。ただし、これが単純さと柔軟性を犠牲にする場合、抽象化は価値を失います。

LangChain には、他の抽象化の上に抽象化を使用する習慣があるため、API を正しく使用するには、ネストされた抽象化の観点から考える必要があることがよくあります。これにより、必然的に、新しい機能を実装するのではなく、膨大なスタック トレースを理解し、自分が書いていない内部フレームワーク コードをデバッグすることになります。

開発チームに対する LangChain の影響

一般に、アプリケーションは AI エージェントを多用して、テスト ケースの検出、Playwright テストの生成、自動修正などのさまざまな種類のタスクを実行します。

単一の Sequential Agent アーキテクチャからより複雑なアーキテクチャに移行したい場合、LangChain が制限要因になります。たとえば、サブエージェントを生成し、それらが元のエージェントと対話できるようにします。または、複数の専門エージェントが相互に対話します。

別の例では、ビジネス ロジックと LLM の出力に基づいて、エージェントがアクセスできるツールの可用性を動的に変更する必要があります。ただし、LangChain にはエージェントの状態を外部から観察する方法が用意されていないため、LangChain エージェントの限られた機能に適応するために実装範囲を縮小する必要がありました。

削除したら、ニーズを LangChain に適したソリューションに変換する必要はなくなります。コードを書くだけです。

では、LangChain を使用しない場合は、どのフレームワークを使用する必要がありますか?もしかしたら、フレームワークはまったく必要ないかもしれません。

AI アプリケーションを構築するためのフレームワークは本当に必要ですか?

LangChain は初期の頃に LLM 機能を提供してくれたので、私たちはアプリケーションの構築に集中できるようになりました。しかし、今にして思えば、その枠組みがなかったほうが長期的には良かったでしょう。

LangChain コンポーネントの長いリストは、LLM を利用したアプリケーションの構築が非常に複雑であるという印象を与えます。しかし、ほとんどのアプリケーションに必要なコアコンポーネントは通常次のとおりです:

• LLM 通信用のクライアント

• 関数呼び出し用の関数/ツール

• RAG 用のベクトルデータベース

• 追跡、評価、もっと。

エージェント空間は急速に進化しており、エキサイティングな可能性と興味深い使用例をもたらしていますが、私たちのアドバイスは、エージェントの使用パターンが固まるまでは、今はシンプルにしておくということです。人工知能の分野における開発作業の多くは、実験とプロトタイピングによって推進されます。

上記は、過去 1 年間の Fabian Both の個人的な経験ですが、LangChain にまったくメリットがないわけではありません。

別の開発者 Tim Valishev は、もうしばらく LangChain を使い続けると述べました:

私は Langsmith がとても好きです:

• すぐに使えるビジュアルログ

• プロンプトプレイグラウンド、プロンプトを即座に修正できますログからテスト データ セットを直接作成し、ワンクリックでプロンプト内で簡単なテスト セットを実行する (またはコード内で実行する) オプションを使用して、ログから直接テスト データ セットを簡単に構築できます。テスト終了)

• テストスコア履歴

• プロンプトバージョン管理

チェーン全体のストリーミングを適切にサポートしますが、これを手動で実装するには時間がかかります。

さらに、APIだけでは不十分で、大手機種メーカーごとにAPIが異なり、「シームレスな切り替え」はできません。

どう思いますか？

元のリンク: https://www.octomind.dev/blog/why-we-no-longer-use-langchain-for-building-our-ai-agents

以上がなぜLangChainを諦めたのですか？の詳細内容です。詳細については、PHP 中国語 Web サイトの他の関連記事を参照してください。