LangChain浦島太郎状態から v0.1.0とLCELについていきたい ChatGPT Meetup Tokyo #6 @kzk_maeda

自己紹介 Kazuki Maeda 𝕏 @kzk_maeda SRE/DRE/EM @atama plus AWS Community Builders AWS Startup Community Core Member

自己紹介 しばらく触ってないな・・

なんとか ついていきたい

Agenda ● LangChain v0.1.0のおさらい ● v0.1.0への移行 ● LECLに入門 ● まとめ

Agenda ● LangChain v0.1.0のおさらい ● v0.1.0への移行 ● LECLに入門 ● まとめ

Official Release Blogの概要 LangChain公式のRelease Blogには下記の項目でv0.1.0の紹介がされている ● Introduction ● Third Party Integrations ● Observability ● Composability ● Streaming ● Output Parsing ● Retrieval ● Agents ● LangChain 0.2 https://blog.langchain.dev/langchain-v0-1-0/

Introduction - Architectureの進化 ● packageを分割して堅牢性と拡張性を向上 ○ core ○ community ○ partner ○ … ● 個々にバージョン管理されていく ● Backward compatibilityのため langchain packageは残る

Third Party Integrations - パッケージの分割 ● 700+のIntegrationがあり、これがLangChainの強み ● これまでは個々のlibrary依存関係がupgradeの足枷になっていたが、その影響を軽 減可能に ● community ○ 多くの3rd party integrationのコードが記述されている ● partner ○ openaiやgoogle-vertexaiなどが個別のpackage化されており、 より安定して運用できる ● langchain packageには移設先のコードへのInterfaceが残され、後方互換を 担保している

Observability - LangSmithの拡大 ● LangSmithを用いた可観測性の拡大 ● 先日の発表でprivate-betaから GAされた ● in-VPCで立ち上がる Enterprise editionの計画もある

Composability - LCELを標準記法に ● LangChain Expression Language（LCEL）を標準記法として拡張していく ● Legacy VersionのChainがあるが、LCELが十分に浸透するまでLegacyを非推奨に することはないとのこと

Output Parsing - LLMをToolsとして扱う ● LLMをtoolとして、別のツールへのinputとするユースケースにおいて 下流のアプリケーションに渡すデータの構造化が課題 ● LLMの出力にデータフォーマットと型の指定を渡すことでシステム間連携 の容易性を上げる ○ JSON、XML、Yamlなどのファイルタイプ指定が可能 ● 完全に型強制をかけるというより、 promptの中で出力のデータ型を指定するという実 装だった ○ validationをかけられるParserもあるので、使用する場合は調査が必要

Other - その他項目のwrap up ● Streaming ○ 完全な応答を待たず、応答の家庭を streaming dataとして返す ○ LECLに対応 ● Retrieval ○ ingestion - index生成APIを公開 ○ retrieval - 学術的なretrievalや独自のロジックを実装 ■ retrievalの際、個人がアクセスできるdocsに認可制御をかけられる ● Agents ○ updateに関する話は少なめ ● LangChain 0.2 ○ すでに0.2の計画は立っており、今後は安定的な minor verupを予定

Agenda ● LangChain v0.1.0のおさらい ● v0.1.0への移行 ● LECLに入門 ● まとめ

install packageのバージョン更新 ● 手元のapplicationで、langchain v0.1.8への更新と、分割されたpackageの導入を実 施

packageの参照を更新 ● 種類によって、core/community/partnerのどれをimportするかが異なる ● text_splitterなど、langchain package自体に残っているものもある ○ architecture上、個別のusecaseに特化した機能はlangchain layerに残る

(余談)BedrockをPartner Packageに・・ ● OpenAIやVertexAIはPartner Packageに所属しているのに、Bedrockは Community Packageに所属している・・ ● Discussionを起票しているので、 賛同される型はvoteお願いします！ https://github.com/langchain-ai/langchain/discussions/17912

Agenda ● LangChain v0.1.0のおさらい ● v0.1.0への移行 ● LECLに入門 ● まとめ

(再掲)Composability - LCELを標準記法に ● LangChain Expression Language（LCEL）を標準記法として拡張していく ● Legacy VersionのChainがあるが、LCELが十分に浸透するまでLegacyを非推奨に することはないとのこと

LCELの構成要素 ● 基本的な prompt + model + output parser のパターン ● 各インスタンスをunix pipe operatorのように記述してデータの流れを宣言 ● Runnableと呼ばれるI/Fを実装しており、共通の呼び出しメソッドを持つ

改めて、LCELとは ● 複雑なchainをsimpleに記述することができる ● 公式ドキュメントの例→ ○ ※全てのusecaseを盛り込んだ場合の記述量の差

LCELはどのように実装されているか ● Runnable*という基底クラスの __or__ メソッドをオーバーライドすることで Unix Pipe Operator型のI/Fを実現 ● 個々のクラスはRunnable*を継承して実装されている

LCELはどう進化していく？(個人的主観) ● データパイプラインの実装がより直感的に記述できるようになっていく？ ○ Apache AirflowのようにDAGの実装をより直感的にできると嬉しい

Agenda ● LangChain v0.1.0のおさらい ● v0.1.0への移行 ● LECLに入門 ● まとめ

LangChain v0.1.0 / LECLについて ● LangChain初のstable versionがリリースされました！ ○ メインはarchitectureの進化で、これからの拡張に耐えられる ソフトウェア設計に移行されている ○ LCELはcoreに位置付けられ、今後はLCEL I/Fを中心に進化していく ● LCELはこれからbasic useになっていきます！ ○ 現状でも、シンプルにchainを記述できるようになります ○ DAGに則ったデータフローをよりシンプルに記述できるよう 進化してくれると嬉しいなぁ