ビジュアルショッピング、画像や文書の理解、チャート分析などのアプリケーションを構築する場合、モデルの出力がソース画像に基づいているかを検証する方法が必要です。テキストのみの評価器では、キャプションが画像を正確に説明しているか、抽出された請求書合計が文書と一致するか、スクリーンショットの要約がページに存在しないボタンを幻覚していないかを判断できません。Gartner は、2030年までにエンタープライズソフトウェアの80%がマルチモーダルになると予測しており、2024年の10%未満から増加しています。自動化されたマルチモーダル評価がなければ、高価な人間によるレビューと信頼性の低いテキストのみのプロキシの間で立ち往生することになります。
本日、Strands Evals SDK は、画像からテキストへのタスク向けに4つの新しいマルチモーダル大規模言語モデル（MLLM）評価器を発表します：全体的な品質、正しさ、忠実性、指示追従です。各評価器は、ソース画像に対して画像からテキストへの出力をスコアリングします。評価器は画像を直接マルチモーダル判定モデルに送信し、クエリ、応答、およびオプションの参照回答とともに送ります。判定モデルは画像に基づいたスコアと、デバッグに使用できる推論文字列を返します。これらの評価器は、既存の Strands Evals の Case → Experiment → Report ワークフローにおいてテキストのみの評価器のドロップイン置き換えとして使用でき、継続的インテグレーション（CI）にプラグインして、視覚的な幻覚、事実誤認、指示違反を自動的に捕捉できます。
この記事では、以下の方法を学びます：
- 4つのマルチモーダル評価器をセットアップし、画像からテキストへのタスクで実行する方法。
- 同じ評価器で参照ありと参照なしの評価を切り替える方法。
- ドメイン固有の基準に対するカスタムマルチモーダル評価基準を作成する方法。
- Amazon Bedrock 上で精度、コスト、レイテンシのバランスが取れた判定モデルを選択する方法。
- 実験で判定と人間の一致を改善したプロンプトデザインの選択を適用する方法。
前提条件：Python 3.10以降、必要なライブラリのインストール、AWSアカウントとAmazon Bedrockへのアクセス、AWS認証情報の設定、Strands Evals ワークフローへの familiarity。
テキストのみの判定が見逃す画像に基づく失敗：モデルがチャートに実際にはない傾向を自信を持って述べる、画像にない製品や人物を幻覚する、間違った質問に答えたり正しい形式で答えないなど。テキストのみの判定は出力を読み、画像を検証しないため、これらの失敗を見逃します。
4つの評価器は最も広く使われるマルチモーダルカテゴリを対象としています：入力は画像（または文書画像）とテキスト、出力はテキストです。これには画像キャプショニング、ビジュアル質問応答、チャートやインフォグラフィックの解釈、文書フィールド抽出、OCR、スクリーンショット要約が含まれます。各評価器の概要：
- 全体的な品質（Likert 1-5）：応答の全体的な質は？関連性の低さ、不正確さ、浅い回答、包括性の欠如を捕捉。
- 正しさ（二値）：画像とクエリに対して応答は事実的に正しく完全か？事実誤認、属性、カウント、位置、省略を捕捉。
- 忠実性（二値）：応答は画像に基づき幻覚がないか？架空のオブジェクト、根拠のない推論、外部知識の漏洩を捕捉。
- 指示追従（二値）：応答はクエリの制約に従っているか？フォーマット違反、カウントミス、話題以外の内容、範囲の無視を捕捉。
各評価器は参照ありモード（ゴールドアンサーと比較）と参照なしモード（画像のみから判断）をサポート。後者はラベル付きテストセットがない実稼働画像に有用。
エンドツーエンドのウォークスルー：チャート読み取りタスクの評価。入力は地域別の平均月額ストリーミング会員収入を示す棒グラフ。システムはグラフについての狭い質問に答える単純なビジョンエージェント。4つの評価器を同じ実験で実行。共通の MultimodalOutputEvaluator ベースクラスを共有し、ImageData を通じて画像を受け取る。 ステップ1：ケースと評価器を定義。ケースは画像と指示を MultimodalInput にラップし、expected_output を指定すると参照あり判定が有効になる。 ステップ2：タスクを配線して実験を実行。タスク関数は各ケースを受け取り、ビジョンモデルを実行して応答文字列を返す。 ステップ3：レポートを検査。各レポートにはケースごとのスコア、test_passes、reasons が含まれる。出力例ではすべての評価器が PASS を示し、推論文字列が表示される。各評価器がスコアに加えて理由文字列を返すことがデバッグに重要。同じケースが単一の実験で4つの独立した判定によってスコアリングされる。
カスタム評価基準：ベースクラスは任意のルーブリック文字列を受け入れる。例：医用診断精度用のルーブリック。
学んだこと：3つの設計上の質問
- 判定は画像を見る必要があるか？実験の結果、マルチモーダル判定（画像＋テキスト）は、詳細な画像説明を与えられたテキストのみの判定よりも人間のスコアとよく一致した。画像説明を生成するための追加のLLM呼び出しを考慮すると、テキストのみのルートは意味のあるコスト削減や高速化にはならない。
- Amazon Bedrock 上のどのモデルを判定として使用すべきか？Anthropic Claude Sonnet 4.6 が、テスト実行全体で精度とコストの最良のトレードオフを提供し、デフォルトの判定モデルとして使用される。より大きく推論能力の高いモデルがより信頼性が高く、同層内ではプレミアムモデルは中位モデルよりも顕著な精度向上を示さなかった。
- プロンプト設計：プロンプト設計の選択が判定と人間の一致にどのように影響するか？実験でのベストプラクティスには、画像証拠に基づいてスコアリングするよう明示的に要求すること、明確なスコアリング基準を提供すること、推論プロセスの出力を要求することが含まれる。
自動化されたマルチモーダル評価により、開発者はより信頼性の高いビジュアルAIアプリケーションを構築し、手動レビューの必要性を減らすことができます。