Langfuse ✖️ Clickhouse MCPサーバを活用した分析

Transcript

1. Langfuse 概要・ClickhouseのMCPサー バーによってできること Yuto Toya ガオ株式会社　
2. 自己紹介
3. スピーカー 遠矢侑音（Toya Yuto） 
 ガオ株式会社　エンジニア 
 
 主に、Langfuseを活用したLLMシステムの
 運用のサポートなどを行なってます。
 
 

4. Langfuseとは？
 LLMの開発~デバッグまでをサポートするOSSの
 LLMOpsプラットフォーム
 
 

5. Langfuse v2の課題
 v2の構成図
 Langfuse v2のスケール課題 PostgreSQLの限界に直面 • 毎分数万イベント :処理が必要な規模に成長 • 取り込み API: 50 秒:レスポンス（スパイク時） • プロンプト API: 7 秒:レイテンシ（p95） • 分析クエリ : 数十億行でダッシュボード使用不能 根本原因：行指向ストレージの限界 • IOPS 枯渇: 大量書き込みでI/O 限界 • CPU 消費: トークン化処理で CPU 急騰 • 分析性能 : 全列読み込みで非効率 • スケール困難 : 垂直スケールのみ、コスト急増 

6. Langfuse v3構成
 v3の構成図
 Langfuse v3の解決策 • ClickHouseによる改善 ◦ PostgreSQLの行指向ストレージから列指向 ストレージに移行することで、分析クエリを 30秒以上→1秒未満に改善 ◦ 数十億行のダッシュボードが使用不能から 高速表示に変化 ◦ ReplacingMergeTreeエンジンで更新処理を 挿入+バックグラウンド重複除去に変更し、 IOPSボトルネックを解決 ◦ ストレージを 5-10倍圧縮してコスト削減も実現 • Redis + 非同期処理による改善 • S3 + イベント駆動による改善
7. Clickhouse導入結果（ v3）

9. LLMシステム評価における主要課題 たとえば... • 評価の基準がハッキリしない • 評価するのが大変・時間がかかる • 評価しても次に活かせない 根本的な課題：改善サイクルの停滞 LLMの評価は複雑のため、その結果として「どのように改善すれば良いのか」 という具体的な道筋が見えにくい状況
10. 従来のデータ分析の限界と「眠れる Traceデータ」 従来のBIツールでは、LLMの複雑な挙動や背景にある「なぜ？」は深掘りできない 実は、そのヒントは「Traceデータ」に眠っている。しかし、その活用ができていないため、貯めているだ けのデータの塊になっている
11. 私たちの挑戦 この眠っているデータの塊である Traceデータに、 それによって、LLMの評価と改善を加速することを目指す 「Traceデータに価値を与える」 生成AIの力で「意味」と「価値」を与えたい
12. なので、LLMの出力結果等のトレースの情報を格納し ているDBを分析して、プロンプトの改善レポートを出 力するエージェントを作ってみた
13. 利用した主なツール・技術
14. 結果 まずはClickhouseのMCPを利用して、必要なデータを取得 （プロンプトにある程度のDB内の情報を記載済み）
15. 次に、Generation HTML MCPを利用してレポートの作成を行う
16. これが、Traceデータに「価値を与えた」結果としての分析レポート例です。 単なるデータの羅列ではなく、具体的な洞察や改善案に繋がります。 プロンプトの 改善案例 分析結果
17. これまでの分析との違い： BIツールを超えて 従来のBIツールでは見えにくかった「なぜこのスコアなのか？」 「どうすれば改善できるのか」という問いに直接的に迫れます。 静的なレポーティングからから動的な分析と改善が可能
18. LLMOpsにおける評価（ Eval）の進化 このアプローチにより、LLMOpsにおける評価は単なるスコアリングから、具体的な改善アクションに 直結する「意味のある活動へ」 進化します 継続的な改善サイクルを回すため強⼒なエンジンになる
19. まとめ • Traceデータの戦略的活用が鍵 ◦ LLMシステムの評価・分析において、Traceデータの収集・蓄積された不可欠 です。 • LLMによる進化した分析・評価 ◦ 従来のBIツールでは見えなかった「なぜ？」 に迫る分析・評価が、 Clickhouse MCPやADKの活用で誰でも簡単にデータ分析の実現を行うシス テムの作成が可能になります。 • AIエージェント開発の加速 ◦ MCPとADKを組み合わせることで、高度なAIエージェント開発も、 より迅速かつ容易になります。