🔄
LLMのEOLに備える：モデル切り替えのためのSide-by-Side評価調査

masakuri
2025/12/01に公開
こんにちは。ZENKIGENデータサイエンスチームの栗原です。現在は面接対話分析など自然言語処理周りの研究開発に携わっています。

所属チームで Xアカウント を運用しており、AIに関する情報を発信していますので、よろしければこちらも覗いてみてください。
Google Gemini や OpenAI GPT など、プロプライエタリLLMを使うサービスで避けて通れないのが、EOL（End of Life, モデルの廃止）です。

プロプライエタリLLMは現在、高性能なモデルの開発競争真っ只中[1]であり、短いスパンで新たなモデルがリリースされ、"古い"モデルは廃止されてゆきます。

例えばGeminiだと、現在様々なところで利用されているであろう gemini-2.5-flash や gemini-2.5-pro であっても、来年の6月で廃止と、リリースから1年という短いスパンで廃止がされることになっています。



図1: gemini-2.5-flashとgemini-2.5-proのライフサイクル（こちらから引用。2025年11月28日確認）
https://docs.cloud.google.com/vertex-ai/generative-ai/docs/learn/model-versions?hl=ja
EOLを迎える前に新たなモデルへの切り替え対応が必要になりますが、そこで重要になるのが 「切り替えによる挙動変化がサービス品質を損なわないか」 の評価です。
EOLを迎えるモデルを別のモデルに置き換える際、正解データを用意した自動評価や、少数のケースを目視確認したりするだけでは、実運用に近い品質差を捉えきれないことが多いです。

例えば、対話AIを構築する場合、ある時点におけるAIの出力がその状況において "適切か" を自動評価するのは（正解データをどう作るのかは）必ずしも簡単ではありません。
そこで今回は、2つのモデル出力を並べて比較する Side-by-Side評価 に注目します。

Side-by-Side評価は、A/Bどちらが「より好ましいか」を人間やLLMに選ばせることで、モデル切り替え時のデグレ検知や挙動の違いを捉えやすく、サービス運用の現場でも再利用可能な評価フローとして構築しやすい手法です。
本記事では、Side-by-Side評価に関連する論文として、
実運用されているSide-by-Side評価プラットフォーム Chatbot Arena
Side-by-Side評価結果を集計する分析ツール LLM Comparator
Side-by-Side人手評価とAI自動評価の比較
の3本を取り上げます。また、実際に評価環境を整備する上で使えそうなツールとして、
Label Studio
Stax
を紹介します。Side-by-Side評価の設計方法や特徴、実際の実施方法についてまとめました。

 Chatbot Arena: LLMをSide-by-Sideで評価するプラットフォームChatbot Arena: An Open Platform for Evaluating LLMs by Human Preference（Chiang, Wei-Lin, et al., ICML2024）

https://icml.cc/virtual/2024/poster/35068

 Chatbot Arena: Side-by-Side比較による選好度評価Chatbot Arenaは、ユーザーが入力したプロンプトに対し、世の中の様々なLLMの出力をSide-by-Sideで提示し、どちらの出力が「好みか」をユーザーに投票してもらい評価するオープンなプラットフォームです。



図1: Chatbot Arenaの画面スクリーンショット（論文から引用）

 Side-by-Side評価の採用理由Chatbot ArenaがSide-by-Side評価を採用している理由には、「一貫性の確保の難しさ」があります。

多様なユーザー層から評価をクラウドソーシングする場合、異なる人々が一貫した採点基準を設定し、それに従って絶対的なスコアを付与することは非常に困難です。

この問題に対処するため、Chatbot Arenaでは、ユーザーに2つのモデルの応答を比較させ、より良い方を選ぶというSide-by-Side比較メカニズムを採用しています。

この比較方式の方が、異なる人間間でより一貫した評価が得られると想定されています。

 評価の基本原則評価ガイドラインは特に設けられていません。

評価者は、単に「より好ましい」と思う方を選択する 選好度評価（Human Preference） を行います。

 評価の信頼性を高めるための工夫Chatbot Arenaは、ノイズの多い人間による評価の質を確保するため、いくつか重要な仕組みを導入しています。

 匿名の対戦（Anonymous Battles）評価の公平性を保つため、対戦の仕組みは匿名性を重視しています。

ユーザーに提示された回答が何のLLMによって生成されたかは伏せられ、ユーザーはモデルの提供企業や評判に影響されることなく評価を行うことができます。

モデルの身元（ID）は、ユーザーが投票を完了した後でのみ公開されます。

 柔軟な投票オプションユーザーの体験を向上させ、より実態に即した評価データを収集するために、柔軟な投票オプションが提供されています。

継続チャットと投票：

ユーザーが最初のターンで勝者を選べなかった場合でも、チャットを続けてから投票を行うことが可能です。

「引き分け」と「両方とも悪い」：

どちらの応答が優れているか決められない場合や、「両方の応答が不適切である」と判断した場合のために、「引き分け (Tie)」または「両方とも悪い (Both are bad)」のボタンも提供されています（図1参照）。

これにより、バイナリな勝敗判定に収まらない、人間の微妙な選好度を捉えることができます。

 統計的評価と効率的なランキングアルゴリズムChatbot Arenaで収集された大量のSide-by-Side比較データは、正確かつ効率的にモデルのランキングを推定するために、統計的手法によって処理されます。

 Bradley-Terry (BT) 係数の導入ランキングを推定するためのスコアリング関数として、Chatbot ArenaではBradley-Terry (BT) 係数（Bradley & Terry, 1952）[2]が採用されています。

以前のバージョンのオンラインインターフェースではEloスコア（Elo, 1967）[3]が報告されていましたが、BT係数は統計的推定の目的により適しているとして導入されました。

BTモデルでは、モデル間の勝敗確率がロジスティックな関係を通じてモデル化され、BT係数（ξ）というM個のモデルのスコアベクトルを推定します。

 効率的なサンプリングアルゴリズムの設計（アクティブサンプリング）Chatbot Arenaは、評価データの収集を効率化し、ランキングの収束を可能な限り早くするために、アクティブサンプリングと呼ばれるアプローチを採用しています。

どのモデルペアをユーザーに提示するかを積極的に選択する効率的なサンプリングアルゴリズムです。

具体的には、不確実性の高い（性能が近い）モデルペアに投票を集中させることで、安定した結果に到達するために必要な総投票数を削減しています。

この効率的なサンプリングアルゴリズムにより、Chatbot Arenaは、大規模でダイナミックなLLM評価環境において、統計的な妥当性を維持しつつ、サンプル効率を向上させています。

 LLM Comparator: Side-by-Side評価の結果を視覚分析するツールLLM Comparator: Interactive Analysis of Side-by-Side Evaluation of Large Language Models（M. Kahng et al., IEEE Transactions on Visualization and Computer Graphics）

https://ieeexplore.ieee.org/document/10670495

 LLM Comparatorとは

図2: LLM Comparatorの主要画面スクリーンショット（論文から引用）

LLM Comparatorは、Google Researchから発表された、Side-by-Side評価の結果を視覚的に分析するツールです。

https://github.com/PAIR-code/llm-comparator
集計された評価指標と個々の応答例の確認を容易に行うことができ、「いつ (when)」「なぜ (why)」「どのように (how)」あるモデルがベースラインモデルよりも優れているか、または劣っているかを理解するための視覚的なワークフローを提供しています。
提供されている機能を簡単に見ていきます。
Interactive Table

図2の左半分を占めている「Interactive Table」で、Side-by-Side評価のデータごとの結果を一覧できます。

テーブルの各行は、プロンプト、2つのモデルからの応答、および応答に対する評価者からの平均スコアからなっています。
Visualization Summary

図2の右半分にある「Visualization Summary」では、概要の可視化と多様なフィルタリングオプションを提供しています。

評価結果の集約されたサマリーを提供すると同時に、ユーザーが個々の事例を動的にフィルタリング可能です。図2に示されているパネルを簡単に紹介します。

スコア分布 (Score Distribution)

Side-by-Side評価のスコア分布を表示するパネル[4]。

プロンプトカテゴリ別メトリクス (Metrics by Prompt Category)

「いつ (when)」に該当する分析用。

どのような条件下でどちらのモデルが優れていたか[5]を視覚化するパネル。

根拠クラスター (Rationale Clusters)

「なぜ (Why)」に該当する分析用。

どのような理由でどちらのモデルが優れていると判断したか[6]を視覚化するパネル。

N-グラム、カスタム関数、事前計算フィールド (N-grams, Custom Functions, Precomputed Fields)

「どのように (how)」に該当する分析用。

2つのモデル間で出力にどのような差があるのかを低レベルの特徴を使用して分析するパネル。頻出するN-gram頻度の比較や、カスタム関数として特定の正規表現やフォーマット（箇条書きなど）の頻度や有無に基づく比較が可能。

 開発意図と設計思想
 開発意図LLM Comparatorのメインターゲットは、Side-by-Side自動評価[7]の結果の解釈サポートです。

Side-by-Side自動評価は、人間の評価者に頼らずに評価を低コストで実行できるため、スケーラビリティの面で大きな利点がありますが、この評価結果を分析する際に課題に直面します。

Google社内でのニーズを収集したところ、勝率などのスコアが得られても、なぜそのスコアになったのか、どのような特徴からそのモデルが優れている・劣っているのかを理解したいという強いニーズがあったとのことです。

LLM Comparatorはこれらの課題に対応し、いつ、なぜ、あるLLMが別のLLMに対して優れている・劣っているのか、そしてどのように応答が異なるのかを理解可能な分析ワークフローを提供する目的で開発されました。

 設計思想ユーザーが抱える課題（スプレッドシートやnotebookでの対応の限界、個々の事例の詳細な検証と集計データの分析の統合の難しさなど）に基づき、以下の3つの設計目標（DG, Design Goals）が設定されました。
DG1: 集計データと個別事例の間のシームレスな相互作用の促進

既存のツールでは、個々の事例の詳細なチェックと集計データの分析が効果的に統合されていない。

ユーザーがデータを様々な方法で探索し、関連する事例を検証できるようにするため、集計ビューと個別の事例ビューの間のスムーズな連携を可能にすることを目指した。
DG2: 主要な分析上の問いに答えるワークフローの提供

LLMの挙動を深く理解するために、以下の3つの質問に焦点を当てたワークフローの提供を目指した。

When（いつ）: あるモデルがベースラインモデルを上回る、または下回る条件は何か

プロンプトカテゴリなどのデータスライス全体でのパフォーマンスを可視化することで、モデルが特に優れている、または劣っている領域を特定。

Why（なぜ）: 自動評価者によって使用される一般的な根拠（rationales）は何か、また、あるモデルが他方よりも好まれる要因は何か

多数の根拠を代表的なテーマにグループ化し、評価者の選択の背後にある理由を理解しやすくする。

How（どのように）: 2つのモデル間の応答はどのように異なるか、どのような質的なパターンが出現するか、そしてこれらの洞察がデータセットやモデルの改善にどのように役立つか

N-gramカウント、正規表現やJavaScript式を用いたカスタム関数、および事前に計算されたフィールド（Precomputed Fields）を通じて、より低レベルの特徴を利用した分析を柔軟かつスケーラブルに支援。

DG3: 大規模な評価結果の分析のスケーリング

大量のプロンプトとモデル応答を処理できるように分析を拡張し、ユーザーがモデル間の性能差を確信を持って特定できることを目指した。

 Side-by-Side評価におけるLLM評価と人間評価Exploring Side-by-Side LLM Evaluation Through Human Alignment and Bias Mitigation（Titova et al., NLPOR 2025）

https://openreview.net/forum?id=kkcvlIENVq

本論文は、Side-by-Side評価をLLMが行う場合（自動評価）と人間が行う場合（人間評価）を比較し、自動評価と人間評価の相関を高める方法論を提案しています。
本研究は以下の2つのResearch Question（RQ）に取り組んでいます。

RQ1: 位置バイアス

Side-by-Side自動評価において、現在も位置バイアスはあるのか？ある場合、どのように対処すればよいか？

RQ2: 人間との整合性

人間評価と整合性が取れるようにするには、どのようなプロンプト設計が必要か？
それぞれのRQに対するアプローチと結果を見ていきます。

 RQ1: Side-by-Side自動評価において、現在も位置バイアスはあるのか？Side-by-Side自動評価をする上で、LLM評価者には、応答の提示順序によって評価が左右される「位置バイアス」が存在することが指摘されています。

位置バイアスが報告された当時からモデルはアップデートされていますが、現在主要なモデルにおいても位置バイアスは存在するのかの調査と、軽減策の検討がされています。

 位置バイアスの検証アプローチとして、Side-by-Side自動評価を行う際に、応答の前後を入れ替えて（スワップして）評価結果がどう変わるかを分析しました。



図3: Side-by-Side自動評価のモデルごとの位置バイアス検証結果。MPCC-Consistency, MPCC-∆^, PCon@ABの3指標で検証。（論文から引用）
!評価指標について簡単に説明します。
MPCC-Consistency

スワップありとなしで得られた2つの中央値セット間のピアソン相関係数（PCC）。この値が1に近いほど、順序変更に対して一貫性があることを示す。
MPCC-∆

スワップありとスワップなしで個別に計算されたMPCCの差分。この値が低いほど、位置バイアスが低いことを示す。
PCon@AB

応答の順序を入れ替える前と後で、評価結果が「A（最初の応答が良い）」または「B（2番目の応答が良い）」である場合に、その一致率を示す指標。この値が高いほど、モデルは応答の順序変更に対して一貫している（バイアスが低い）ことを示す。
図3がその結果で、依然として位置バイアスが存在することが確認されました。

 位置バイアスの軽減策位置バイアスを軽減するアプローチとして、「推論」のステップをプロンプトに追加する案が検証されました。

具体的には、プロンプトに以下のような文言を入れることです。

"Your evaluation must be thorough, reasoned, and step-by-step."（「評価は、徹底的に、推論的に、段階的に行う必要がある。」）


"Explicitly describe your train of thought for each criterion, explaining why one response is better than the other or if they are equal." （「各基準について、なぜ一方の応答が他方よりも優れているのか、あるいは同等であるのかを説明しながら、思考プロセスを明示的に記述してください。」）

この案を deepseek-r1-distill-llama と llama3.3-70b の2つのモデルで検証した結果が以下図4, 5です。

位置バイアス以外（後述）の結果も記載されていますが、ここでは位置バイアス（PCon@AB）の結果を見ていきます。



図4: deepseek-r1-distill-llama における、プロンプトの違いによる位置バイアス（PCon@AB）の変化。（論文から引用）


図5: llama3.3-70b における、プロンプトの違いによる位置バイアス（PCon@AB）の変化。（論文から引用）
Prompt Iが通常のプロンプト、Prompt IIが「推論」のステップを追加したバリエーションです。

この結果を見ると、deepseek-r1-distill-llama は Prompt I が結果が最もよく、「推論」のステップを追加したバリエーションでは位置バイアスはむしろ悪化しています（図4）。

一方、llama3.3-70b では、Prompt I から「推論」のステップを追加したバリエーションの一部（II-reason, II-fact-reason）で位置バイアスの改善が見られます（図5）。

この結果の違いについて、本論文では「プロンプトは個々のモデルに合わせて調整する必要があり、異なるLLM評価者間でそのまま転用できるわけではない」という結論を強調しています。

 RQ2: 人間評価と整合性が取れるようにするには、どのようなプロンプト設計が必要か？Side-by-Side人間評価はコストが大きいので、可能であればSide-by-Side自動評価で置き換えられると良いでしょう。

現在のモデルによる自動評価はどの程度人間評価と相関があるのでしょうか？

以下図6がその結果です。どのLLMも、人間評価との十分なレベルの一致度を達成していません。



図6: Side-by-Side評価における人間評価（manual）と様々なモデルの自動評価の相関分析結果。A~Dの4段階評価+Eの評決割合と、相関を示す評価指標 CK, MPCCの結果。（論文から引用）
!評価指標について簡単に説明します。
SBS results

A: 1つ目のモデルの応答の方が明らかに良い, B: 2つ目のモデルの応答の方が明らかに良い, C: どちらの応答も同程度に良い, D: どちらの応答も同程度に不十分, E: 評価モデルがA~D以下の評価を出力した場合 の各評決割合
CK

コーエンのカッパ（Cohen’s kappa）。偶然の一致を除いた評価者間の一致度（Nominal metrics）を測定する指標。この値が高いほど、専門家との判断の一致度が高いことを示す。
MPCC

中央値ピアソン相関係数。評価クラス（A, B, C, D）を実数にマッピングし、判断の中央値を計算することで、候補モデルがベースラインモデルと比較してどれだけ優れているかを示す値（0から1の範囲）を導出。人間評価者とLLM評価者の両方から得られた中央値のセット間でピアソン相関係数（PCC）を計算。この値が高いほど、LLMの評価が人間の評価と高い相関性を持つことを意味する。

 プロンプト設計人間評価との整合性を高めるため、複数のプロンプトバリエーションが設計・検証されました。

Prompt I実際のプロンプト

図7: Prompt Iのプロンプト（論文から引用）

Side-by-Side評価のタスクを簡潔に説明することを目的としたプロンプトです。評価要素として、応答の有用性、関連性、正確性、詳細性、創造性などを厳密に考慮し、応答の位置や順序に基づくバイアスを避けるよう指示されています。

Prompt II実際のプロンプト

図8: Prompt IIのプロンプト（論文から引用）

人手評価向けに記載されたすべての評価基準を詳細に記述し、モデルに遵守させることを目的としています。

さらに、最終評価を出す前に評価の思考プロセスを明示的に記述することを強制し、最終評価は二重括弧で囲んで出力させるなど、厳格なフォーマットを遵守させるいくつかのパターンが検証されました。


図9（図4の再掲）: Side-by-Side評価における人間評価（experts）と deepseek-r1-distill-llama での自動評価との相関分析結果。A~Dの4段階評価+Eの評決割合と、相関を示す評価指標 CK, MPCCの結果。（論文から引用）


図10（図5の再掲）: Side-by-Side評価における人間評価（experts）と llama3.3-70b での自動評価との相関分析結果。A~Dの4段階評価+Eの評決割合と、相関を示す評価指標 CK, MPCCの結果。（論文から引用）
結果は図9, 10の通りで、どちらのモデルにおいてもPrompt Iと比較し、人間との相関は向上傾向が見られました。

ただ、モデルによって最も効果的だったプロンプトは異なっており、RQ1の結論でもあったように、「プロンプトは個々のモデルに合わせて調整する必要があり、異なるLLM評価者間でそのまま転用できるわけではない」ようです。

 マルチエージェントアプローチの検証Chain-of-Thought（CoT）は評価性能の向上に役立ちますが、Degeneration-of-Thought（LLMが、たとえ間違っていても自身の推論に確信を持ち始めるという問題）が発生する可能性があります。

これに対処するため、マルチエージェントアプローチのスキームが提案されました。

2つのアプローチが提案されました。

Softアプローチ

エージェント1が評価を下し、エージェント2がそれに同意または不同意を表明し、その後エージェント判事（Judge Agent）が両方の評決に基づいて最終的な判断を下す方法。

Hardアプローチ

エージェント1が評価を下し、エージェント2が常にそれに反対し、その後エージェント判事が最終的な判断を下す方法。


図11: Deepseek-r1-distill-llama でのマルチエージェントアプローチの検証。softアプローチ、hardアプローチそれぞれでの人間評価（manual）との相関指標 CK を示している。（論文から引用）
結果は図11の通りで、特にSoftアプローチを用いることで、人間によるアノテーションとの相関性を高めることができました。

これは、2番目のエージェントが必ずしも矛盾するのではなく、時として最初の議論を補完し、エージェント判事が以前の推論に基づいてすべての主張を再評価することで、CoTの考えを発展させる強力な手法となるためと考察されていました。
最後に、実際にSide-by-Side評価を行うアノテーション環境の構築を可能にするツールとして、Label Studio と Stax を紹介します。

 Side-by-Side評価を行うためのアノテーションツール（触ってみた）
 Label Studiohttps://labelstud.io/

Label Studioはオープンソースのアノテーションプラットフォームです。

アノテーション用の様々な テンプレート が用意されており、その中にSide-by-Side評価用のテンプレートもあります。

https://docs.humansignal.com/templates/llm_side_by_side

このテンプレートを利用してアノテーションを開始するまでをステップバイステップで見ていきます。

 セットアップまず、Label Studioをインストールします。
pip install label-studio
Label Studioを起動します。
label-studio start
すると、http://localhost:8080 でLabel Studioが立ち上がります。



新規で始める場合は、Sign up でメールアドレスとパスワードを登録してアカウントを作成してください。

ログインできると、以下がホーム画面です。

「Create Project」 でアノテーションプロジェクトを作成していきましょう。


 Side-by-Side評価アノテーションツール構築Create Project をクリックすると、まず以下の画面になると思います。「Project Name」と「Description」を記載して[8]、「Labeling Setup」のタブに移動します。

「Labeling Setup」のタブには、様々なアノテーション用テンプレートが用意されています。

今回は、左のサイドメニュー一番下の「Custom template」を選択します。

「Custom template」を選択すると以下のような画面になるので、Side-by-Side比較のテンプレートページ から、labeling configurationをコピーして「Code」に貼り付けます。

Side-by-Side比較用テンプレートコード<View className="root">
  <Style>
    .root {
      box-sizing: border-box;
      margin: 0;
      padding: 0;
      font-family: 'Roboto',
        sans-serif;
      line-height: 1.6;
      background-color: #f0f0f0;
    }

    .container {
      margin: 0 auto;
      padding: 20px;
      background-color: #ffffff;
      border-radius: 5px;
      box-shadow: 0 4px 8px 0 rgba(0, 0, 0, 0.1), 0 6px 20px 0 rgba(0, 0, 0, 0.1);
    }

    .prompt {
      padding: 20px;
      background-color: #0084ff;
      color: #ffffff;
      border-radius: 5px;
      margin-bottom: 20px;
      box-shadow: 0 2px 4px 0 rgba(0, 0, 0, 0.1), 0 3px 10px 0 rgba(0, 0, 0, 0.1);
    }

    .answers {
      display: flex;
      justify-content: space-between;
      flex-wrap: wrap;
      gap: 20px;
    }

    .answer-box {
      flex-basis: 49%;
      padding: 20px;
      background-color: rgba(44, 62, 80, 0.9);
      color: #ffffff;
      border-radius: 5px;
      box-shadow: 0 2px 4px 0 rgba(0, 0, 0, 0.1), 0 3px 10px 0 rgba(0, 0, 0, 0.1);
    }

    .answer-box p {
      word-wrap: break-word;
    }

    .answer-box:hover {
      background-color: rgba(52, 73, 94, 0.9);
      cursor: pointer;
      transition: all 0.3s ease;
    }

    .lsf-richtext__line:hover {
      background: unset;
    }

    .answer-box .lsf-object {
      padding: 20px
    }
  </Style>
  <View className="container">
    <View className="prompt">
      <Text name="prompt" value="$prompt" />
    </View>
    <View className="answers">
      <Pairwise name="comparison" toName="answer1,answer2"
                selectionStyle="background-color: #27ae60; box-shadow: 0 4px 8px 0 rgba(0, 0, 0, 0.2), 0 6px 20px 0 rgba(0, 0, 0, 0.2); border: 2px solid #2ecc71; cursor: pointer; transition: all 0.3s ease;" />
      <View className="answer-box">
        <Text name="answer1" value="$answer1" />
      </View>
      <View className="answer-box">
        <Text name="answer2" value="$answer2" />
      </View>
    </View>
  </View>
</View>


最後に、「Data Import」の画面でアノテーション用データをインポートします。

フォーマットは Side-by-Side比較のテンプレートページ に記載されていますが、以下のようなjsonで、プロンプト（prompt）とSide-by-Side比較をする2つの応答（answer1, answer2）が必要です。
[
  {
    "data": {
      "prompt": "What is the capital of France?",
      "answer1": "Paris",
      "answer2": "London"
    }
  },
  {
    ...
  },
]
上記設定を終えたら、「Save」するとアノテーションが開始できる状態になります。

「Label All Tasks」での実際のSide-by-Side評価アノテーション画面は以下の通りです。

Side-by-Side評価以外にもテンプレートが多数用意されているので、用途に合ったアノテーション環境を簡単に用意できるのがよいなと思いました。

自由度も高くカスタマイズ性も優れているので、オープンソースのアノテーションプラットフォームとして様々な場面で活用できそうです。

 Staxhttps://stax.withgoogle.com/landing/index.html

Staxは、Googleが開発したAI評価用のプラットフォーム（"AI evaluation platform"）です。

Staxで行えるのは大きく以下の2つです。

Pointwise Evaluation

単一のモデルまたはシステムプロンプトの性能をデータセットに対して評価するために使用。

Side-by-Side Comparison

同じデータセット上で2つの異なるモデルまたはシステムプロンプトを直接比較するために使用。
今回は、「Side-by-Side Comparison」を見ていきます。

 セットアップStax（ https://stax.withgoogle.com/ ）はGoogleアカウントでログインすることで利用できるようになります。

ログインすると、以下のような画面になると思います。


 Side-by-Side評価アノテーションツール構築右上の「Add project」をクリックすると、以下のように、単一のモデルの評価を行う「Pointwise Evaluation」と2つのモデルの比較を行う「Side-by-Side Comparison」のどちらかを選択することが求められます。

今回はSide-by-Side評価を行いたいので、右側「Side-by-Side Comparison」を選択します。

選択すると以下のような画面になります。最も簡単に開始するには、「Import dataset」でデータをアップするだけです。

データフォーマットとしてはcsvを想定しており（参考ページ）、csvファイルをアップロードすると以下のように、Stax側が想定するカラム名とアップロードしたcsvファイル内のカラム名を対応づけすることを求められます。

対応づけが完了すればSide-by-Side評価環境の準備は完了です。以下がプロジェクト画面で、このページ上でアノテーション等を行えます。

アノテーションは中央付近の双方向矢印の列で「Left is better.」「It's a tie.」「Both are bad.」「Right is better.」のいずれかの選択をする形で行うことができます。

選択をすると左上の「Human Evaluation Win Rate」の値としてすぐさま反映され、どちらのモデルがどのような勝率かを確認することができます[9]。
Staxではこの他にも、様々なLLM APIと繋いでその場で評価用データセットを構築したり、LLM-as-a-judge的にLLMに評価をさせることもできます。

非常に簡単に評価用UIを用意できるので、そういう面で便利だなと思いました。

 まとめ以上、Side-by-Side評価に関するいくつかの観点（Side-by-Side評価設計、評価結果分析、人間評価とAI評価の特徴、評価用ツール）について調査・まとめました。
今回紹介した知見をEOL対応に紐付けると、
Chatbot Arena や LLM評価と人間評価の特徴 の論文から得た知見をもとに「Side-by-Side評価＋人間/LLMハイブリッド評価」の型を決めておくこと
LLM Comparator 的な視点で、ユースケースごとの勝ち負けパターンを把握できるようにしておくこと
Label Studio や Stax で評価UIとデータセットをテンプレート化し、新モデルが出たときにすぐ流し込めるようにしておくこと
が、毎回のモデル切り替えを同じフローで効率的に回す上でのスタートになりそうです。
プロプライエタリLLMのライフサイクルが短くなっている中、再利用可能なSide-by-Side評価の仕組みを整え、安心してモデルを切り替えられる体制を作っていくことが重要だと感じています。

 お知らせ少しでも弊社にご興味を持っていただけた方は、お気軽にご連絡頂けますと幸いです。まずはカジュアルにお話を、という形でも、副業を検討したいという形でも歓迎しています。

https://hrmos.co/pages/zenkigen/jobs?jobType=FULL

https://speakerdeck.com/zenkigenforrecruit/detailed-version-recruitment-materials-for-data-scientists

脚注
執筆している最中にも、GPT-5.1, Grok4.1, Gemini 3, Claude Opus 4.5など次々と発表がされました。 ↩︎
Bradley, R. A. and Terry, M. E. Rank analysis of incomplete block designs: I. the method of paired comparisons. Biometrika, 39(3/4):324–345, 1952. ↩︎
Elo, A. E. The proposed uscf rating system, its development, theory, and applications. Chess Life, 22(8):242– 247, 1967. ↩︎
図2の例は、Likertスケールで評価し、その結果を数値スコアに変換したものの分布です。例えば、「A is much better」は 1.5、「A is slightly better」は 0.5、「B is much better」は -1.5 といった形です。 ↩︎
ex. CodingではモデルAの勝率が高く、WritingではモデルBの勝率が高い ↩︎
ex.「より詳細な情報を提供している」という理由でモデルAが優れていると判断した数が 14 でモデルB（6）より多い, 「正確で明確」という理由でモデルAが優れていると判断した数が 2 でモデルB（4）より少ない ↩︎
LLM-as-a-judgeの一種で、LLMに2つのモデルの出力のどちらが優れているかを自動評価させる ↩︎
記載しなくてもいけます。 ↩︎
触ってみての感想ですが、個人的にはアノテーション作業中はこのようなアノテーション結果の統計等が見えることなくアノテーションに集中してもらえるような画面が用意されていると嬉しいなと思いました。 ↩︎
ZENKIGENテックブログPublication
私たちは「はたらく人の理想」をつくるために、ITと科学で組織課題に立ち向かうAIテックカンパニーです。「テクノロジーを通じて人と企業が全機現できる社会の創出に貢献する」のVisionのもと、人の感覚に寄り添うテクノロジーを用いたでサービスを展開しています。
Chatbot Arena: LLMをSide-by-Sideで評価するプラットフォーム

Chatbot Arena: Side-by-Side比較による選好度評価

Side-by-Side評価の採用理由

評価の基本原則

評価の信頼性を高めるための工夫

匿名の対戦（Anonymous Battles）

柔軟な投票オプション

統計的評価と効率的なランキングアルゴリズム

Bradley-Terry (BT) 係数の導入

効率的なサンプリングアルゴリズムの設計（アクティブサンプリング）

LLM Comparator: Side-by-Side評価の結果を視覚分析するツール

LLM Comparatorとは

開発意図と設計思想

開発意図

設計思想

Side-by-Side評価におけるLLM評価と人間評価

RQ1: Side-by-Side自動評価において、現在も位置バイアスはあるのか？

位置バイアスの検証

位置バイアスの軽減策

RQ2: 人間評価と整合性が取れるようにするには、どのようなプロンプト設計が必要か？

プロンプト設計

マルチエージェントアプローチの検証

Side-by-Side評価を行うためのアノテーションツール（触ってみた）

Label Studio

セットアップ

Side-by-Side評価アノテーションツール構築

Stax

セットアップ

Side-by-Side評価アノテーションツール構築

まとめ

お知らせ

Discussion
