0
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

エグゼクティブサマリ

  • Databricks上でRAGチャットボットを開発する中でLangChainを採用した
  • 採用理由は、Databricksの研修で触れており認知負荷が低く、Azure OpenAIとの親和性も高かったため
  • 一方で、開発当初は「LangChainを使うと何が嬉しいのか」が腹落ちしていなかった
  • MLflow TracingでLangChainの処理を親子関係として可視化したことで、RetrieverやLLM呼び出しなどの処理フローを把握しやすくなった
  • 可視化した結果、自分が想定していた処理フローと実装に差があることにも気づいた
  • 今後のGraphRAGやWeb検索、Agentic RAGへの拡張を見据え、LangGraphによるワークフロー管理を検討している

本記事では、LangChainの機能そのものではなく、なぜ採用し、なぜ価値を理解できず、何をきっかけに認識が変わったのかを実体験ベースで整理する。

背景

  • Databricksを利用したRAGチャットボットを開発している
  • RAG実装にあたりLangChainを採用した
  • Databricksの生成AI関連研修でLangChainが紹介されていたことが採用のきっかけだった
  • Azure OpenAIとの連携もしやすく、既存環境への適用が容易だった
  • 一方で、「なぜLangChainを使うのか」という問いには明確に答えられない状態で開発を進めていた

技術選定時の判断

採用理由

  • Databricks研修で事前知識があった
  • 新規技術と比較して認知負荷が低かった
  • Azure OpenAIとの親和性が高かった
  • RAG構築に必要な機能を満たしていた
  • 既存環境へ無理なく組み込めた

当時の意思決定

LangChainが他の選択肢より絶対的に優れていたからではなく、既存知識・既存環境・要件との適合性が高かったため採用した

課題認識

  • LangChainを利用してRAGを実装できていた
  • RetrieverやPrompt、LLMなどを利用することもできていた
  • 一方で、自前実装との差分が分かりづらかった
  • 「処理を部品化できる」という説明だけでは、実務上の価値を実感できなかった
  • そのため、利用は継続していたものの技術選定理由を十分に言語化できていなかった

転機:MLflow Tracingによる可視化

DatabricksのMLflow Tracingを利用してLangChainの処理を確認した。

可視化によって以下を把握しやすくなった。

  • ユーザー入力
  • Retrieverへの入力
  • 検索結果
  • Prompt生成
  • LLMへの入力
  • LLMからの出力
  • 各処理の親子関係
  • 処理時間
  • エラー箇所

これにより、コードを追うだけでは把握しづらかった処理全体を、一つの実行フローとして確認できるようになった。

得られた示唆

MLflowで処理を可視化したことで、LangChainに対する理解が変化した。

Before

RAGやLLMアプリを簡単に構築するための便利なライブラリ

After

LLM、Retriever、Promptなどの処理に一定のインターフェースを持たせることで、処理を組み合わせやすくし、Tracingや評価にもつなげやすくする基盤

特に、実装を簡単にすることだけでなく、処理を観測可能な単位として扱いやすくなることに価値を感じた。

可視化によって判明した実装上の課題

MLflow上のTraceを確認したところ、自分が想定していた処理フローと実際の構造に差があった。

想定していた構造:

ユーザー質問
    ↓
Classifier
    ↓
├─ RAG
├─ GraphRAG
└─ Web Search
    ↓
回答生成

一方で、実際のTraceでは処理が途中で終了して見える箇所があり、処理フローが明示的に表現されていないことに気づいた。

このことから、

  • LangChainを利用するだけでは、アプリケーション全体の処理フローは自動的に整理されない
  • Python側の条件分岐に制御ロジックが埋め込まれている
  • 今後処理経路が増えると、さらに複雑になる

という課題を認識した。

今後の対応方針

今後はLangGraphを利用し、処理フローそのものを明示的に管理することを検討している。

想定構成

START
  ↓
Classifier
  ↓
├─ RAG
├─ GraphRAG
└─ Web Search
  ↓
Answer Generation
  ↓
END

既存のRAGやClassifierを置き換えるのではなく、各処理をNodeとして配置し、EdgeとStateによってワークフローを管理する。

今後の検証事項

  • 既存RAG処理のLangGraph化
  • Classifierによる分岐のGraph表現
  • RAG / GraphRAG / Web検索の個別Trace確認
  • MLflow上のTraceと設計上のGraphの整合性確認
  • 各処理単位での評価
  • Agentic RAGへの拡張性確認

まとめ

今回の学びは、LangChainの新しい機能を知ったことではない。

実際に利用し、MLflowで処理を可視化したことで、

  • なぜLangChainを使うのか
  • 自分の実装にどのような課題があるのか
  • なぜ次にLangGraphを検討するのか

を一連の流れとして理解できた。

技術の価値は、機能一覧を確認するだけでは理解しきれないことがある。

実装し、観測し、課題を確認することで、初めてその技術がどのような問題を解決するためのものなのかを理解できた。

0
0
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
0
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?