第10章 — 主要な評価フレームワーク

LLM Primer III: RAGで強化するエンタープライズAI を章ごとに紹介していくウォークスルー、第10回です。トライアドに道具立てがつきます — 2つの系統に分かれた8つのフレームワーク — そして、どのフレームワークもまだ解いていない部分についての、ひとつの正直な認識。

この章がなぜあるのか

第9章のトライアドは、何を測るかを語りました。それを本番でどう実行するかについては何も言いません。尺度は概念で、実装は — ジャッジへのプロンプト、主張の分解ロジック、類似度のための埋め込みの選択、コストのためのサンプリング戦略、ダッシュボード、アラート、人手レビューのループ。これをすべてゼロから組むチームはありません。

フレームワークは見分けがつく軸で分かれました。片側はメトリックファーストのライブラリ — RAGAS、TruLens、DeepEval — がトライアドを、文書化された再現可能な方法で計算します。反対側は可観測性プラットフォーム — Braintrust、LangSmith、Phoenix、Galileo、Opik — が本番トレースから始めて、評価を大きな作業フローのひとつの機能として統合します。両者の選択は機能比較というよりも、出荷の翌日にシステムに何をしてほしいかの問いです。

10.1 メトリックファースト — RAGAS、TruLens、DeepEval

RAGAS は、この分野でトライアドの参照実装にもっとも近いものです。保守的な尺度集合、文書化されたプロンプト、すべての LLM 呼び出しが露出されています。Faithfulness のパイプラインは2段の連鎖で — 回答を主張に分解し、各主張をコンテキストに対して確かめる — 中間の主張リストが結果に返るので、エンジニアはフレームワークが「裏付けられなかった」と判定した特定の主張を指差せます。研究、規制業界、方法論を擁護する必要のあるチームにとっては、RAGAS が既定値です。コストは、手触りがアカデミックなことです。尺度は計算しますが、ダッシュボードは出荷しません。

TruLens は、メトリックライブラリと可観測性プラットフォームの中間です。重心は計装にあり、フレームワークはアプリを関数レベルで包んで、検索呼び出しとモデル応答のすべてを構造化されたトレースに捉え、その上にトライアドを走らせます。トライアドの尺度はフィードバック関数として露出され、小さく組み合わせ可能で、独自のを書くのも簡単です。標準集合の外に評価ニーズが出るチームや、集約ダッシュボードよりも個別失敗の検査が中心になる作業フローのチームに合います。

DeepEval は3つ目の立場を取ります — pytest としての評価。テストケースを書き、pytest 風の CLI で動かし、失敗は PR をブロック。尺度集合は3つの中でもっとも広く、バイアス、毒性、ハルシネーションのチェックがトライアドの隣に並びます。代償は、広さに対する厳密さが均一でないことです。メニューから尺度を選んで実装を読まないと、思った意味と違う数を報告することになります。正しい規律は、小集合を選び、プロンプトを読み、手ラベルで較正し、残りはインスピレーションとして扱うこと。

10.2 可観測性プラットフォーム — Braintrust、LangSmith、Phoenix、Galileo、Opik

メトリックファーストのライブラリは「トライアドをどう計算するか」に答えます。可観測性プラットフォームは「本番で RAG システムをどう運用するか」に答えます。チームが当面、プロンプトを書き、モデル版を比較し、トレースを取り込み、ダッシュボードを見ることを前提にしている。評価は機能のひとつで、プロンプトのバージョニング、トレース探索、A/Bテスト、アラートも等しく価値の一部です。

Braintrust は開発者体験で攻めます — experiment という、データセット上のモデル挙動のバージョン管理された記録と、本当に気持ちのよいUIでのスコアの並列差分。LangSmith は LangChain に深く入っているチームにとって自然な選択で、アプリ計装の中心にいることを期待し、そのコミットに深さで報います。Phoenix は Arize の OSS の選択肢で、他がやや控えめな埋め込みドリフトとクラスタ分析が際立ちます — SaaS にトレースを送れないチームにとって現実解。Galileo はエンタープライズ寄りで、独自の Correctness スコアと、規制業界向けのオンプレ展開を備えます。Opik は Comet の最新の参入で、Phoenix のような OSS ファースト、Braintrust のように洗練されていて、LLM と古典機械学習の可観測性を1つのプラットフォームに統合する強みも持ちます。

5者の選択は機能というより組織の適合の問題です。LangChain ショップは LangSmith、グリーンフィールドのプロダクトエンジニアリングは Braintrust、OSSファーストなら Phoenix、規制エンタープライズなら Galileo、Comet ショップなら Opik。5者の尺度品質は概ね同等で — すべてトライアドを実装し、すべて LLM-as-Judge を使い、第9章で名指しした同じ根本的限界を背負っています。違いはワークフローで、計測そのものではありません。

10.3 評価ギャップと「3つのループ」パターン

フレームワーク巡りがいま流したばかりの、気まずい事実があります。上に挙げたほぼすべてのツールは 推論層 で評価します: 検索がすでに起きているとして、モデルはチャンクを尊重したか、回答は問いの形に合っていたか、チャンクはトピック上だったか。これらのどれも、深い意味で「検索がそもそも正しいチャンクを見つけたか」を教えてくれません。検索器の出力は推論層の入力で、推論層の尺度は出力を測りますが入力を測りません。検索が重要な文書を一貫して逃すなら、Faithfulness は高いまま(モデルは与えられたものを尊重した)、回答関連性も高いまま(答えは問いの形に合った)、それでもユーザーは誤った答えを受け取ります。

これが評価ギャップです。構造的な理由は、推論層の評価が参照なしであるのに対し、検索層の厳密な評価は正しいチャンクが何かを知る必要があり、それにはラベル付きか合成のセットが要るからです。回避策 — 合成の問い生成、Needle-in-a-Haystack のプローブ、下流影響の代理、クエリ条件つきの検索監査、自己に対する検索 — はどれも有用でどれも不完全。誠実なまとめは、検索層の評価は開いたフロンティアで、チームは自身の工学のいくらかを検索品質に直接投資することを覚悟したほうがよい、ということです。フレームワークは推論ループを助けますが、検索ループの大半はチームに残します。

成熟したチームが収斂するパターンは、1つではなく3つのループです。インナーループ: メトリックファーストのライブラリ(典型は RAGAS か DeepEval)が、意味のある変更ごとに固定回帰セットでトライアドを走らせる。速く、決定的、回帰を捕まえる方向。アウターループ: 可観測性プラットフォームが本番トレース保管、サンプル流量に対するオンライン尺度計算、ダッシュボード、アラートを扱う — 回帰セットが見落とすドリフト向け。スローループ: 小さな人手レビュー機能が LLM ジャッジを較正し、フラグつきトレースを監査し、製品の進化に合わせて回帰セットを保守する。インナーループだけのチームはドリフトする本番を出荷します。アウターループだけのチームはドリフトは見えるが直せません。両方あっても人手レビューがないチームは、静かに狂っていくジャッジを信じてしまう。3つすべてが必要で、フレームワークの価値は、各ループをどれだけ安く実践可能にしてくれるかにあります。

第10章を踏まえて

第9章のトライアドと第10章のフレームワークがあれば、チームには RAG システムを 計測する ために必要なものがそろいます — 語彙、その語彙が見落とすことの誠実な会計、そして計測をダッシュボードに変える少数の道具。システムは可読になります。けれど計測は本番の物語の半分に過ぎません。計測されているが保守されていないシステムは、それでも劣化します — 文書も、ユーザーも、その下のモデルも、変わるからです。品質が落ちたと知ることと、それを取り戻せることは別物です。

次回 — 第11章: 継続的なアップデートとパイプライン最適化。 CDC とインクリメンタルなインデックス更新、セマンティックキャッシュとモデル階層化、そして本番テレメトリを、走らせるほど良くなるシステムへと変える4段のフィードバックループ。