LangChainを用いた効率的なAIアプリケーション実装
会員限定コンテンツです。無料登録すると制限なしでお読みいただけます。
レビュー投稿日の情報になります
atama plus株式会社 / kzk-maeda
CTO・VPoE / VPoE / 従業員規模: 101名〜300名 / エンジニア組織: 11名〜50名
最終更新日投稿日
利用プラン | ツールの利用規模 | ツールの利用開始時期 | 事業形態 |
---|---|---|---|
OSS | 11名〜50名 | 2023年6月 | B to B B to C |
利用プラン | OSS |
---|---|
ツールの利用規模 | 11名〜50名 |
ツールの利用開始時期 | 2023年6月 |
事業形態 | B to B B to C |
アーキテクチャ
アーキテクチャの意図・工夫
- アプリケーションからLLM APIを実行する部分(図で言うとBedrock/Anthropic)に対してLangChainを用いている
- また、LangSmithによるモニタリングを導入している
- 社内アプリケーションの構成は以下を参照:
導入の背景・解決したかった問題
導入背景
ツール導入前の課題
- 最初の生成AIアプリケーションの実装を始めた2023年前半ごろ、LangChainも未成熟で、OpenAI APIをそのまま実行するような実装が世の中ではまだ一般的だった
- 登場し始めていたRAGという概念に必要な周辺ツールとの接続なども自前で実装するかどうか、という時期で、世間的に模索状態だったと思われ、弊社でも同様の状況だった
- OpenAI社以外もモデルの提供を徐々に始めてきた時、LLM APIを直接実行する実装では、モデルごとの精度比較のために毎回再実装が必要で非効率だった
どのような状態を目指していたか
- どのLLM APIを実行するか、という知識とアプリケーションロジックの知識が切り離された設計
- そのために自前のレイヤー実装をするのではなく、デファクトスタンダードとなりうる技術を選定したかった
- 周辺エコシステムとの簡単な連携
比較検討したサービス
- guidance
- OpenAI APIなど、素のLLM API実行
比較した軸
- 世の中にナレッジが豊富にあり、デファクトスタンダードとなること(2023年時点では今ほど差がなかった)
- Modelの入れ替え容易性(アプリケーションを運用しながら、OpenAIのモデルやAnthropicのモデルなどを適宜スイッチングして精度検証しながら育てていくことを想定していた)
- 周辺ツール・エコシステムとの連携容易性
- OSSとしての進化スピードの速さ
選定理由
【導入当時】
- 2023年当時にLangChainを選定した時は、上記の点がクリアになるかどうかは不透明であったものの、期待値が高いだろうと想定して社内アプリケーションから導入を始めた
- 合わせて、周辺ツールとの接続で足りない部分はLangChainにコミットすれば比較的容易に取り込んでもらえるだけのOSSエコシステムが育ちつつあった
【現在】
- 上記の社内向けアプリケーションでの実績があったこと、その際にモデル入れ替えが非常に容易だったこと(OpenAI API → Anthropic Claudeに変更した)から、ユーザー向けアプリケーションの機能にもLangChainを用いることを決めた
- その際はLangChainとしてもstable versionのリリースが終わり、coreやcommunityなどのpackage分離も進んでいたことから、必要な機能を選定してより軽量に導入することができると判断した
- また、OSSエコシステムは継続して成長しており、現在では連携していない周辺ツールを見つける方が難しいくらいには充実している。また、新しいモデルの対応速度も早く(大きなモデル変更は大体即日で取り込まれる)、ライブラリを利用することで時流に遅れるようなことも少ないと判断した
導入の成果
改善したかった課題はどれくらい解決されたか
- アプリケーションロジックはLLMレイヤーの知識を持たなくても済む実装ができている
- OpenAI APIからAnthropic Claude(w/ Bedrock)に変更する際、非常にスムーズに変更できた
- Claude 3.7 Sonnetがリリースされた際も、LangChainが即日対応を入れてくれたので、翌日には新しいモデルの検証をすることができるなどスピーディな新技術検証にも追従できている
どのような成果が得られたか
- 上記の課題解決に加えて、
- JS版のライブラリも成熟してきているので、チームによってはJS版のLangChainを導入することで、プロダクトとの技術スタック親和性が高い中で同様のメリットを享受できている
- LangSmithによるモニタリングも実施しており、セッションレベルで実際にプロダクトで行われているLLMとのやりとりを見てデバッグやtoken試算など行うことができている
導入時の苦労・悩み
- 2023年当時はナレッジが少なく、また、ドキュメントも未成熟で実装のためにコードを追わないと理解できない部分が多くて苦労した
- 現在はドキュメントもかなり充実しているので、あまり迷うことはないと思われる
導入に向けた社内への説明
上長・チームへの説明
- 技術選定の意思決定者なので上長説明は特になし
- ユーザー向けアプリケーションの実装の際は、社内アプリケーションで実績があること、メリットを享受できていること、その後stable versionがリリースされていることなどを用いて説明
活用方法
よく使う機能
- model wrapper
- prompt template
- memory
- chain
- LangSmith
ツールの良い点
- アップデートが早い
- 周辺ツールの対応が最も豊富
- Python版だけでなく、JS版も選択できる
- デファクトスタンダードとして世に知見が多いことと、ドキュメントが充実していることから、CursorなどのAIコーディング支援ツールとの相性もいい
ツールの課題点
- packageが複数に分かれており、かつpackage間のバージョン依存関係もあるので、追従に少し負荷がかかる
- 稀にバージョンを上げると後方互換されていないケースがある(stable version化以降は少ない印象)
今後の展望
- LangSmithのプロンプト管理機能や、LangGraphなどより便利に利用できそうなツールがたくさんアップデートされているので、適宜検証して運用に取り込んでいきたい
- LangChainファミリーで複数のpackageに分割されており、バージョン追従の負荷が上がっているので、効果的にバージョン追従しつつ品質を担保できる仕組みの導入を目指したい
atama plus株式会社 / kzk-maeda
CTO・VPoE / VPoE / 従業員規模: 101名〜300名 / エンジニア組織: 11名〜50名
よく見られているレビュー
atama plus株式会社 / kzk-maeda
CTO・VPoE / VPoE / 従業員規模: 101名〜300名 / エンジニア組織: 11名〜50名
レビューしているツール
目次
- アーキテクチャ
- 導入の背景・解決したかった問題
- 活用方法