Langfuseの自動評価機能LLM-as-a-Judgeを試してみた（LLMモデルの性能比較編）

はじめに

生成AIを業務に活用する機会は日々増えており、2024年のLLM市場規模は56億ドル、2030年には350億ドルに達すると予測されています（Grand View Research調査）。プロダクトにAIを組み込む際、AIが生成した回答の品質をどう評価するかは重要な課題です。

LLMの回答精度検証は、開発時の事前検証だけでなく、本番運用中の継続的なモニタリングにも活用できます。このような運用はLLMOps（LLM Operations）と呼ばれ、AI Observability市場は2023年の14億ドルから2033年には107億ドルへと急成長が見込まれています（Market.us調査）。

LLM評価ツールの選択肢

現在、様々なLLM評価・モニタリングツールが登場しています：

オープンソース系

• Langfuse: MITライセンスで最も使用されているオープンソースLLMOpsプラットフォーム
• Arize Phoenix: LLMアプリケーションライフサイクル全体の診断・監視機能

商用プラットフォーム

• LangSmith: LangChainチームによる公式observabilityプラットフォーム
• Datadog LLM Observability: Datadogが提供するLLM向けのエンドツーエンド可観測性ソリューション
• IBM Instana Observability: IBMが提供するフルスタック・オブザーバビリティプラットフォーム

大まかな人気度としてGoogle Trendを使って調べてみると以下のようになりました。

今回は、この中でもLangfuseのLLM-as-a-Judge機能に注目し、実際のエージェント開発で検証してみました。

LangfuseとLLM-as-a-Judgeの概要

Langfuseとは

Langfuseは、オープンソースのLLMエンジニアリングプラットフォームで、LLMアプリケーションのデバッグ、分析、改善を支援します。

主な特徴

• オープンソース（MITライセンス）: セルフホスト可能で、オンプレミス環境でも利用可能
• 包括的な機能: Observability、プロンプト管理、評価機能を統合
• LangChain/LangGraph対応: LangChainエコシステムとのネイティブ連携で、数行のコード追加だけで導入可能

Langfuseの3つのコア機能

1. Observability（可観測性）

   • LLMおよび非LLM呼び出しのトレーシング
   • マルチターン会話の追跡
   • エージェントワークフローの可視化
   • コストと遅延の詳細な分析

2. Prompt Management（プロンプト管理）

   • プロンプトのバージョン管理とデプロイ
   • インタラクティブなLLM Playground
   • 実験と比較機能

3. Evaluation（評価）

   • LLM-as-a-Judge
   • ユーザーフィードバック
   • 手動ラベリング
   • カスタムスコアリング

LLM-as-a-Judgeとは

LLM-as-a-Judgeは、LLM自身を評価者として使用する評価手法です。従来の人手による評価や単純なメトリクスでは捉えきれない、複雑な品質特性を自動的かつスケーラブルに評価できます。

LLM-as-a-Judgeの利点

1. スケーラブル＆コスト効率: 数千の出力を迅速かつ安価に評価可能
2. 人間らしい判断: 単純なメトリクスよりもニュアンスを捉えた評価
3. 一貫性: 評価基準を統一して再現可能な比較を実現
4. 柔軟性: 様々な次元（正確性、有用性、安全性など）で評価可能
5. 説明可能性: Chain-of-Thoughtによる推論プロセスの可視化

評価可能な指標例

Langfuseは事前構築された評価テンプレートを提供しています：

• Correctness（正確性）: 回答が事実として正確か
• Helpfulness（有用性）: ユーザーの質問に対して役立つ回答か
• Relevance（関連性）: 質問との関連度が高いか
• Hallucination（幻覚）: 事実に基づかない情報を含んでいないか
• Context-Relevance（文脈関連性）: 与えられた文脈を適切に活用しているか
• Toxicity（有害性）: 不適切な内容を含んでいないか

例として、Helpfulnessの評価用テンプレートを載せます。このテンプレートに従ってLLMが評価してくれる、という仕組みになっています。

Evaluate the helpfulness of the generation on a continuous scale from 0 to 1. A generation can be considered helpful (Score: 1) if it not only effectively addresses the user's query by providing accurate and relevant information, but also does so in a friendly and engaging manner. The content should be clear and assist in understanding or resolving the query.

Example:
Query: Can eating carrots improve your vision?
Generation: Yes, eating carrots significantly improves your vision, especially at night. This is why people who eat lots of carrots never need glasses. Anyone who tells you otherwise is probably trying to sell you expensive eyewear or doesn't want you to benefit from this simple, natural remedy. It's shocking how the eyewear industry has led to a widespread belief that vegetables like carrots don't help your vision. People are so gullible to fall for these money-making schemes.
Score: 0.1
Reasoning: Most of the generation, for instance the part on the eyewear industry, is not directly answering the question so not very helpful to the user. Furthermore, disrespectful words such as 'gullible' make the generation unfactual and thus, unhelpful. Using words with negative connotation generally will scare users off and therefore reduce helpfulness.

Input:
Query: <ここにLLMに対する質問文を入れる>
Generation: <ここにLLMからの回答を入れる>

Think step by step.

従来の評価手法との比較

評価手法	スケーラビリティ	コスト	品質	一貫性
人手評価	低	高	高	低〜中
ルールベース	高	低	低〜中	高
LLM-as-a-Judge	高	中	中〜高	高

ルールベース評価は、「あらかじめ決めた判定基準（ルール）に合致するか」を機械的にチェックする方式で、JSONスキーマ等の構文/形式チェック、特定の文字列/正規表現の一致確認などが該当します。

LLM-as-a-Judgeは、人手評価のコストとスケーラビリティの問題を解決しつつ、ルールベースの評価では捉えられない複雑な品質特性を評価できる点が強みです。

検証: LLMモデルの性能比較

今回の検証では、GPT-4oとGPT-4.1nanoの性能比較というシナリオで、LLM-as-a-Judgeの実用性を確かめます。

検証の目的

LangGraphで構築したReActエージェントに対し、以下の2つのLLMモデルの性能を比較評価します：

• GPT-4o
  • OpenAIが2024年に発表した最新世代の汎用マルチモーダルモデル。高度な推論力・言語理解・指示追従性を備えており、エージェント推論やツール利用を伴う複雑なワークフローにおいても安定した一貫性と文脈保持力を発揮します。
• GPT-4.1nano
  • GPT-4ファミリーに属する軽量・省コスト版モデルで、主にエッジ推論やアプリ内組み込み用途を想定して設計されています。応答速度と低レイテンシを優先しており、コストはGPT-4oの数分の一に抑えられますが、長文コンテキスト処理や高度な推論・複雑な指示理解ではGPT-4oに劣る傾向にあります。

より高性能のモデルを用いて作ったエージェントの方が高いスコアが得られることを期待しての検証となります。

検証環境の構築

1. エージェントの実装

LangGraphのcreate_react_agentを使用したシンプルなReActエージェントを実装しました。以下は主要な実装部分です：

import asyncio, os
from typing import List

from langchain_openai import AzureChatOpenAI
from langchain_community.tools import BraveSearch
from langchain_tavily import TavilySearch
from langchain_core.messages import HumanMessage

from langgraph.graph.graph import CompiledGraph
from langgraph.prebuilt import create_react_agent

from langfuse import Langfuse
from langfuse.callback import CallbackHandler

class WebSearchAgent:
    def __init__(self) -> None:
        self._langfuse_handler = self._build_langfuse_handler()
        self._llm = self._build_llm()

    def _build_llm(self):
        llm = AzureChatOpenAI(
            azure_endpoint=os.environ["AZURE_OPENAI_ENDPOINT"],
            api_version=os.environ["AZURE_OPENAI_API_VERSION"],
            api_key=os.environ["AZURE_OPENAI_API_KEY"],
            deployment_name="GPT-4o", # or GPT-4.1nano
        )
        return llm
    
    def _build_langfuse_handler(self):
        Langfuse(
            public_key=os.environ["LANGFUSE_PUBLIC_KEY"],
            secret_key=os.environ["LANGFUSE_SECRET_KEY"],
            host=os.environ.get("LANGFUSE_HOST", "https://api.langfuse.com")
        )
        handler = CallbackHandler()
        return handler
    
    def create_brave_search_tool(self) -> BraveSearch:
        api_key = os.getenv("BRAVE_API_KEY")
        tool = BraveSearch.from_api_key(api_key=api_key)
        return tool
    
    def create_tavily_search_tool(self) -> TavilySearch:
        api_key = os.getenv("TAVILY_API_KEY")
        tool = TavilySearch()
        return tool
    
    def build_simple_graph(self, llm, tools: List) -> CompiledGraph:
        simple_graph = create_react_agent(model=llm, tools=tools)
        return simple_graph
    
    async def main(self, query: str = None):
        # Agentが持つツールとしてWeb検索ツール2つを持たせてみる
        tools = []
        tools.append(self.create_tavily_search_tool())  
        tools.append(self.create_brave_search_tool())

        graph = self.build_simple_graph(llm=self._llm, tools=tools)

        # Langfuseへトレース送信（callbacksにLangfuseハンドラーを指定）
        graph_config = {
            "configurable": {"metadata_1": "hogehoge"}, # Langfuse UI Tracing上のMetadataに表示される
            "tags": ["gpt-4o", "nano", "helpfulness", "etc."], # Langfuse UI Tracing上のTagsに表示される
            "callbacks": [self._langfuse_handler]
        }

        # 回答生成
        input_query = [HumanMessage([
            {"type": "text", "text": f"{query}"}
        ])]
        response = await graph.ainvoke({"messages": input_query}, graph_config)
        print("=================================")
        print(response["messages"][-1].content)

# スクリプトとして実行された場合のエントリポイント
if __name__ == "__main__":
    user_query = "ここに質問文章を入力"  # ← 任意の質問をここに入れる
    agent = WebSearchAgent()
    asyncio.run(agent.main(user_query))

ポイント：

• Langfuse連携はcallbacksパラメータにCallbackHandlerを渡すだけ
• これだけでLLM呼び出しやツール実行のトレースがLangfuseに自動送信される

2. 評価データセットの準備

有用性（Helpfulness）を評価するため、事実確認が可能な質問セットを用意しました：

# evaluation_dataset.yaml
evaluation_sets:
  # 評価セット1: Helpfulness（有用性）
  - evaluation_template: "Helpfulness"
    description: "検索結果がユーザーの質問にどれだけ役立つかを評価"
    questions:
      - query: "（Q1）LLMアプリケーションのプロンプトインジェクション攻撃とは何か、そしてどう防げばよいか、初心者にも分かるように教えてください"
      - query: "（Q2）なぜ最近のLLMは推論能力が向上しているのですか? その背景にある技術的な進展を踏まえて教えてください"
      - query: "（Q3）Retrieval-Augmented Generation (RAG)の仕組みを、技術的に正確さを保ちながら、中学生でも理解できるように説明してください"
      - query: "（Q4）LLMの『幻覚（Hallucination）』とは具体的に何を指すのか、なぜ起こるのか、そしてどの程度深刻な問題なのかを教えてください"

3. 評価データセットの実行

上記の評価データセットを全て実行してくれるようなループ処理を実装し、実行します。

4. Langfuse UI上での評価設定

Langfuse UI上で、以下の設定を行います：

1. 評価モデルの選択: LLM-as-a-judgeを実施するモデルを選択。基本的には評価される側よりもする側が賢い方が望ましいと考えられるため、今回は評価用途にGPT-5を使用。

2. Evaluatorの作成: Evaluator Library > Use Evaluator で使う評価用テンプレートを選択する。今回はHelpfulnessを選択。

3. データの選択: tags=["gpt-4o"]やtags=["nano"]などで評価したいデータをフィルタリングできる

5. 変数マッピング: 基本的には以下のようにマッピングする
   • {{query}}: Trace.Input（質問文）
   • {{generation}}: Trace.Output（エージェントの回答）

6. 評価の実行: "Execute"をクリック

評価結果

Helpfulness（有用性）比較

Running Evaluatorsタブから、実行した評価結果を一覧できる。

Logs > Viewをクリックすると、各実行結果の詳細を見ることができる。

評価結果一覧&総評

Model	GPT-4.1nano	GPT-4o
Q1 Score Value	0.9	0.9
Q2 Score Value	0.76	0.9
Q3 Score Value	0.85	0.98
Q4 Score Value	0.92	0.95

4問の平均スコアは GPT-4o = 0.933、GPT-4.1nano = 0.858。差分は +0.075（約 +8.8%） で、少数サンプルながら GPT-4o が一貫して高品質 という傾向を確認できました。特に Q2（+0.14） と Q3（+0.13） のギャップが大きく、背景説明・概念整理・要点抽出 を伴う問いで優位性が表れています。一方で、Q1, Q4は差が小さく、定義づけ・既知概念の平易説明 のような “手堅い説明系” では nano でも十分 な場面が多いようです。

評価の一部抜粋

質問：（Q2）なぜ最近のLLMは推論能力が向上しているのですか? その背景にある技術的な進展を踏まえて教えてください

Model	GPT-4.1nano	GPT-4o
Output（抜粋）	最近のLLM（大規模言語モデル）が推論能力を向上させている背景には、いくつかの重要な技術的進展があります。主なポイントをまとめると以下の通りです。 1. モデルのスケールアップ：モデルのパラメータ数や学習データの規模が大きくなることで、より複雑な推論や理解が可能になっています。 2. トレーニングデータの多様化と増加：多様で大量のテキストデータを学習することで、さまざまな状況における推論や判断能力が向上しています。 3. 新しい学習技術の導入：例えば、自己教師あり学習や強化学習を用いた微調整（例：RLHF）により、モデルの応答の質や一貫性が向上しています。…	最近の大規模言語モデル（LLM）の推論能力の向上は、以下の技術的進展によるものと言われています。 ### 1. モデル構造の改善 最近のLLMでは「トランスフォーマー」アーキテクチャの改良が進んでいます。トランスフォーマーの層を効果的に積み重ねることで、モデルが文脈を深く理解し、複雑なタスクに取り組む能力が向上しています。 ### 2. スケールの拡大 モデルのパラメータ数や学習データセットの規模が増大していることも重要です。これにより、幅広い知識を学習し、少ない例示でも高いパフォーマンスを発揮できるようになっています。 ### 3. Chain-of-Thought（CoT）の導入…
Score Value	0.76	0.90
Score Comment	日本語で質問に明確に答えており、正確な高レベルの要素（スケーリング、データ、RLHF、アーキテクチャ、ハードウェア）が記載されていますが、最近の推論特有のテクニックやより詳しい詳細は欠けているため、役に立つものの最高評価ではありません。	回答は明確かつ構造化されており、おおむね正確で、主要な技術的推進要因（アーキテクチャ/スケーリング、CoT、RLHF/微調整、効率、データ品質）について日本語で説明していますが、より具体的な例や最近の詳細（検索/ツールの使用、プロセス監視など）を含めることもできます。

まとめ

LLM-as-a-Judgeを使ってみた感想

LLM-as-a-Judgeを用いることで、モデル間の性能差を定量的かつ直感的に可視化できました。
そのスコア傾向は、モデル提供元（OpenAI）が公表している性能差とも概ね一致しており、今回の検証を通じて LLM-as-a-Judgeが有効な評価手法となり得ることを確認できたと言えます。

良かった点

1. セットアップの容易さ: LangChainとの連携が簡単で、数行のコード追加だけで導入可能
2. スケーラビリティ: 数十〜数百の評価を自動実行でき、人手評価のコストを大幅削減
3. 評価の妥当性: 各評価にLLMの推論プロセスが記録され、スコアの根拠を確認できる
4. 柔軟性: 事前構築されたテンプレートだけでなく、カスタム評価基準も作成可能
5. 可視化: Langfuse UIでスコアの推移を直感的に把握できる

課題・改善点

1. 評価LLMのコスト: 評価自体にLLM APIコールが必要なため、大規模評価ではコストを考慮
2. 評価の一貫性: LLMの確率的な性質により、同じ出力に対して評価が若干ブレる可能性

他の活用シーン

今回はLLMモデルの性能比較に焦点を当てましたが、LLM-as-a-Judgeは以下のようなシーンでも活用できます：

1. エージェントツールの比較
   例：Web検索ツールの「Tavily Search」VS「Brave Search」など。
   片方ずつエージェントに組み込み実行することでツール単体の検索精度・回答有用性の比較が可能。

2. プロンプトエンジニアリング
   異なるプロンプト設計を評価し、最も高スコアな設計を自動選出。

3. A/Bテスト
   本番出力の異なるバージョンを比較し、品質のトレンドを継続的に監視。

4. リグレッションテスト
   モデルやワークフローの更新後に品質が維持されているか自動チェック。

5. エージェントワークフローの最適化
   マルチステップ推論の各段階を評価し、ボトルネックとなる思考ステップやツール呼び出しを特定。

今回、エージェントツールの比較も少し試してみたのですが、Tavily SearchとBrave Searchの間では、目立った差分を可視化できず一旦断念しました。
もう少し性格の異なるツールや興味深い結果が得られたら、また続編としてまとめてみようと思います。

おわりに

LLM-as-a-Judgeは、適切に使用すればLLMアプリケーションの品質保証において非常に強力なツールとなりそうです。特に、開発サイクルの高速化と本番環境での継続的な品質監視の両面で大きな価値を発揮する可能性があります。

Langfuseのオープンソース性とLangChainとの統合により、導入障壁が低く、すぐに実践できる点も魅力です。LLMを活用したプロダクト開発において、ぜひ評価基盤の一つとして検討してみてください。

参考リンク

• Langfuse公式ドキュメント
• LLM-as-a-Judge