評価バイアスを修正して、Amazon Bedrock でより優れたモデルを解き放つ

この記事は、Property FinderのKhaled Thabit、Meriem Boughrara、Mohamed Desoukyとの共著です。

そのエンジニアリングチームは プロパティファインダー,ある不動産デジタルアプリケーションは、評価ラベルの96.8パーセントが人間の専門家による検証ではなく、単一のモデルの予測からそのまま引き継がれたものであることを発見しました。彼らの正解データは既存のモデルに体系的に偏っており、すべての代替モデルが劣って見えるようになっていました。ラベルには誤りもありましたが、客観的なモデル比較を妨げていたのはこのバイアスでした。彼らがこれに気づいたのは、ビジョンAIのワークロードを、よりコスト効率の良い選択肢に移行した際のことでした。 Amazon Bedrock.

Property Finderは中東・北アフリカ（MENA）地域で毎日数万件の不動産画像を処理しています。同社のシステムは画像ごとに11の品質属性を評価します。これにはウォーターマーク検出、部屋の分類、家具の有無、写真の品質、建設状況の指標などが含まれます。1件あたり平均15枚の画像が付いた数千件の新規物件リストが、公開前にすべて品質評価を必要とします。

Property Finderはより費用対効果の高い選択肢を必要としていた。しかし、それらのラベルと比べると、どの代替案も不利な立場にあった。

一番難しかったのは、より良いモデルを見つけることではなかった。彼らの評価手法そのものがボトルネックだと気づいたことだった。

この記事では、Property Finderが評価バイアスを特定し、バイアスのないグラウンドトゥルースを構築し、進化的プロンプト最適化を適用してAmazon Bedrock上で適切なモデルを選択し、コストを86%削減しながらより高い精度を達成した方法を紹介します。手法とイテレーションの例を通じて、皆様自身のワークロードに応用できる教訓を解説します。

以下の図は、Property Finder と AWS Generative AI Innovation Center のチームが Amazon Bedrock 上で分類精度を反復的に改善するために使用したプロンプト最適化ループを示したものです。

図1: プロンプト最適化ループのアーキテクチャ

この図は、反復的なプロンプト最適化のサイクルを示しています。物件の画像が Amazon Bedrock によって処理され、予測された属性が JSON 形式で出力されます。最適化の過程では、これらの予測が256枚の画像からなる専門家注釈付き開発セットに対して Micro F1 でスコア化されます。その後、エラー分析によって失敗した画像が精査され、視覚的なパターンが特定され、それが次のプロンプトバージョンに反映されます。このループは v0 から v27 まで実行されました。AI アシスタントがプロンプトの改善を支援し、後半のバージョンでは自動最適化が使用されました。

あなたの評価は嘘をついているかもしれません

多くのチームがこのシナリオに遭遇します。ビジョンモデルを比較したいので、評価データセットを構築します。ラベルを取得する最も一般的な方法は、現行のモデルを実行し、その出力を正解データとして扱うことです。そのモデルは本番環境で稼働していて誰も不満を言っていないのだから、ラベルは十分に良いはずだ、というわけです。

しかし、これでは循環的な評価が生まれ、どんな代替案も実際の正しさではなく、既存の挙動にどれだけ一致しているかで判断されることになる。

Property Finderの評価データセットには、まさにこの問題がありました。ラベル付きサンプルのうち96.8パーセントが、独立した人間による検証ではなく、既存の視覚言語モデル（VLM）の予測に直接由来していました。そのため、代替モデルは1枚の画像も処理される前に、構造的に不利な立場に置かれていたのです。

隠れた誤差がその深刻さを裏付けました。ウォーターマークテキストの抽出では、幻覚によるブランド名や欠落した文字など、文字レベルの誤りが正解として扱われていました。写真の分類では、複数の部屋タイプが写る画像に単一のラベルが強制的に割り当てられていました。

残りの3.2パーセントの人手によるラベル付けサンプルでは、アノテーターが元の仕様外のカテゴリーを導入していた。たとえば Office プロンプトにそのようなラベルが存在しなかった場所にラベルが出現します。置き換えようとしているモデル自身が解答キーを作成していた場合、モデル比較はその妥当性を失います。

信頼できるグラウンドトゥルースの構築

この悪循環を断ち切るには、実際のドメイン知識を持つ人間の専門家が、過去のモデル出力を参照せず、既存モデルが予測した内容にもアクセスできない状態で、独立して新しいアノテーション作業を行う必要があります。

データセットの範囲

Property FinderのチームはUAEの画像356枚と、別のエジプトの画像一式に手動でアノテーションを付けました。チームはこれらを、業界の代表的なセグメントにわたるラベルなしの本番リスティングから選定しました。本投稿ではUAEの画像に関する結果を報告します。エジプトの画像は230枚で地域横断的な検証に用いられましたが、ここでは報告しません。アノテーションが付けられた最初のUAE画像256枚が、チューニング用の開発セットとなりました。最終的なモデル比較の評価セットには356枚すべてを使用しており、開発実行後にアノテーションされた100枚が追加されています。356枚の画像一式は、モデル間の中程度の差異を検出するにはおよそ十分な規模です。個々の属性における稀なクラスは例数が少ないため、それらの属性に関する小さな差異は検出できない可能性があります。

専門家によるアノテーション

不動産戦略と分析の専門家がすべての画像にアノテーションを付けました。この専門家は、不動産物件掲載の品質基準に関する専門知識を持っていました。AWS Generative AI Innovation Centerのチームは、専用の確認セッションを通じて体系的な品質レビューを実施しました。これらのレビューにより曖昧なケースが解決され、データセット全体でラベル付けの一貫性が保たれました。

マルチラベル遷移

不動産の画像には、ドア越しに複数の部屋が写っていたり、重なり合う品質特性が表示されたりすることがよくあります。シングルラベルからマルチラベル分類への切り替えにより、人為的な曖昧さの主要な原因が解消されました。

ドアの向こうに寝室が見える廊下の写真は、文字どおりその両方です。複数のラベルを許容すれば、モデルが正しく判定できたことを測定でき、もっともな二次的な予測をペナルティとして課すことがなくなります。

ハイブリッドなアプローチがこの手法を補完しえます。異なるファミリーのモデルが候補ラベルと不一致点を抽出し、人間の専門家がすべてのケースを裁定することで、モデルの出力がそのままラベルとして使われることはありません。これにより、将来のデータセット拡張におけるアノテーションの負担が軽減されるでしょう。

メトリクスの選択

Micro F1 を主要な評価指標として採用しました。これは各予測を等しく重み付けするもので、ラベル全体の正確性というビジネス上の目標に合致するためです。一方、Macro F1 も併せて報告しました。なぜなら Micro F1 は出現頻度の高いクラスに支配され、まれな属性における弱いパフォーマンスを隠してしまう可能性があるからです。ラベルごとの適合率と再現率は、具体的な失敗パターンを特定するのに役立ちました。サンプルごとの IoU（Intersection over Union）は、各画像について予測ラベルが専門家のラベルとどれほど重なっているかを測定しました。回転やウォーターマーク検出などの9つの単一ラベル属性には、画像ごとに1つの正解があります。AWS チームはこれらについても完全一致精度、すなわち回答が専門家のラベルと一致する画像の割合で評価しました。

強化学習としてのプロンプト最適化

客観的な評価が整ったら、改善を始めることができます。正しく測定できないものは、改善できません。

この最適化は、強化学習に類似したループに従って行われました。各プロンプトバージョンをエージェント、Micro F1 スコアを報酬シグナル、エラー分析を改善のための勾配と考えてください。この考え方は、 GEPA(遺伝的パレート反射型プロンプト進化)に似ており、プロンプトのコンポーネントを変異させ、適応度を評価し、生存者を選択し、反復します。今回の取り組みでは、AWSチームはほとんどのバージョンをエラー分析から改良し、AIアシスタントが失敗した画像をレビューして変更案を提案しました。

MIPROv2は、 DSPy ライブラリの自動プロンプト最適化フレームワークで、v27の写真分類タスクにおいてこの手作業のプロセスを補完しました。

出発点

最初のプロンプト(v0)は汎用的な分類指示を使用していました。説明のために簡略化すると次の通りです:

「この画像を以下のカテゴリのいずれか1つに分類してください:リビングルーム、キッチン、ベッドルーム、バスルーム…」

プロプライエタリモデルA(Property Finderの本番環境のベースライン)は、256枚の開発セットで Micro F1 0.55 を獲得しました。このモデルは、そのモデルファミリー向けにチューニングされたプロンプトである v22 を使用しました。v21より前のスコアは以前のシングルラベル設定で測定されたものであり、直接比較はできません。

反復ごとの改善

AWSチームは初期のバージョンを複数の候補モデルでテストし、構造化出力フォーマットと属性ごとの定義を追加しました。

最も示唆に富む修正は、画像レベルのエラー分析から得られました。初期のシングルラベルバージョンでは、モデルはドア越しに見える部屋を一貫して二次的な部屋タイプとして分類していました。AWS Generative AI Innovation Center のチームは、フレームの大部分を占める部屋に基づいて分類するよう明示的な指示を追加しました。その後のマルチラベル出力への切り替えでは、主要な部屋をラベルとして維持しつつ、ドア越しに見える部屋を追加ラベルとして認めました。

地域ごとのカスタマイズが次の改善をもたらしました。一部の地域では、物件の掲載写真に透かしではない装飾的なアラビア語テキストのオーバーレイが含まれています。そのテキストに対するルールにより、あるカテゴリの偽陽性がまるごと排除されました。

v21のプロンプトでは写真分類と部屋カテゴリがマルチラベル出力に切り替えられ、すべてのモデルの共通の出発プロンプトとなりました。これにより、Meta の Llama 4 Maverick 17B Instruct が開発セットで Micro F1 0.75 を達成しました。そこから、AWSチームは各モデルのプロンプトを個別にチューニングしました。このモデルでは、v24が部屋サイズの過大評価、マルチラベルの処理、出力形式を対象としました。次に、自動的に最適化されたバージョンである v25 が、重要なタスクを先頭に移動しました。v27では、MIPROv2 が写真分類タスクを再構築し、そのタスクにおけるモデルの Micro F1 は 0.76 に達しました。

最終到達点

最終プロンプトである v27_PF は、v27 に Property Finder が追加した、レンダリング画像、枠やフレーム付きの画像、廊下に関するルールを加えたものです。v27と同様に、アラビア語テキストのルールと出力形式の指示を維持しています。各モデル呼び出しの後の正規化ステップが、残りのフォーマットの違いを処理します。

v27_PF を使用して、Llama 4 Maverick 17B Instruct は356枚の評価セットで Micro F1 0.80 を獲得し、プロプライエタリモデルAは v22 で 0.56 でした。評価セットには256枚の開発画像が含まれており、両モデルのプロンプトはそれらの画像でチューニングされています。したがって、これらのスコアは楽観的なものです。

プロプライエタリモデルAから Llama 4 Maverick 17B Instruct への切り替え(それぞれ独自にチューニングされたプロンプトを使用)により、開発セットで Micro F1 が 0.55 から 0.81 に向上しました。これは相対的に47パーセントの改善です。Llama 4 Maverick 17B Instruct 上でのプロンプトチューニングだけでも、共通の v21 プロンプトでの 0.75 から v27 での 0.81 に向上しました。

失敗したアプローチからの教訓

すべてが成功したわけではありません。 2-bucket このアプローチでは、ウォーターマーク属性とその他の属性を2つの別々のAPI呼び出しに分けていました。しかし、有意な精度向上はもたらされませんでした。枠付き画像の検出も大幅に低下しました。同じプロンプト内にウォーターマーク属性がないと、モデルはウォーターマークのオーバーレイを画像の枠と誤認してしまったのです。

汎用的なプロンプトも、どのモデルで実行しても失敗しました。不動産の画像は、画一的な指示には対応できないほどドメイン固有性が高すぎます。

結果：コスト、精度、速度

AWS Generative AIイノベーションセンターのチームは、バイアスのない評価フレームワークを用いて、Amazon Bedrock上の複数のモデルを評価しました。すべてのモデルは共有のv21プロンプトから開始し、その後、開発セット上で各モデルファミリー向けにチューニングされました。プロプライエタリモデルAは1回のチューニングラウンドでv22となりました。Llama 4 Maverick 17B Instructは複数回、v24からv27までチューニングされ、さらにProperty Finderのエッジケースルールも加わったため、より多くのチューニング作業が行われました。プロプライエタリモデルAとの最終比較では、356枚画像の評価セットを使用しました。Property Finderは、11属性すべてにおける精度とコスト効率に基づき、本番ワークロードにLlama 4 Maverick 17B Instructを選定しました。リージョンごとのモデル利用可否については、以下を参照してください。 Amazon Bedrock でサポートされる AWS リージョン別モデル.

次の表は、Llama 4 Maverick 17B Instruct (v27_PF) が356枚画像の評価セットでスコアリングされた、各単一ラベル属性で達成した完全一致精度を示しています。9属性中6属性で90パーセント以上を記録し、11属性すべてでプロプライエタリモデルAと同等以上でした。1枚の画像に複数のラベルが付く場合がある写真分類では、両者は同じスコアでした。

1,000枚あたりのコスト

Property Finderは1日に数万枚の画像をスコアリングするため、画像あたりのコストが重要です。Llama 4 Maverick 17B Instructはコスト効率の高いオープンウェイトモデルであり、このパイプラインは1回の呼び出しで画像の全属性を取得します。

これらの数値は、2025年12月時点のUS East (Ohio) リージョンにおける推定値です。Llama 4 Maverick 17B Instructの数値は、元の2回呼び出しのコスト分析に基づき、画像あたり9,000入力トークンおよび200出力トークンを想定しています。本番用プロンプトでの1回の呼び出しには約7,500〜8,000入力トークンが含まれるため、これは上限の推定値です。86パーセントという数値は、v21プロンプトを使用していたProperty Finderの以前のセットアップのコスト分析推定値と比較したものです。精度比較では、v21からチューニングされたv22を使用したため、そのコストは異なる可能性があります。最新の価格については、以下を参照してください。 Amazon Bedrock の料金.

推論速度

Property Finderはこの最適化されたパイプラインを本番環境で運用しており、Amazon Bedrock上のLlama 4 Maverick 17B Instructを使用して1日に数万枚の画像を処理しています。Property Finder自身のモニタリングでは、以前のセットアップと比較して推論レイテンシーが40〜60パーセント削減されたことを確認しました。

このアプローチをあなたのワークロードに適用する

まず、評価ラベルを監査することから始めましょう。それらが人間の専門家ではなくモデルの予測から得られたものである場合、Property Finderが発見したのと同じバイアス問題を抱えています。

数百件の代表的なサンプルに対するドメイン専門家によるグラウンドトゥルースを構築し、チューニングには決して使用しない別のテスト分割を保持しましょう。分類タスクに重なり合う属性が含まれる場合は、マルチラベル指標を採用しましょう。その後、画像エラー分析を用いてプロンプトを反復改善し、各反復を進化的最適化ループにおける1世代として扱いましょう。

このようなパイプラインをデプロイする際は、責任あるAI (Responsible AI) の制御を追加してください。例えば、 Amazon Bedrock Guardrails を使用して、コンテンツポリシーを強制し、不適切なモデル出力をフィルタリングできます。このパイプラインの属性予測には較正された信頼度スコアが付いていないため、人間によるレビューの対象画像を選ぶには実用的なシグナルを使用してください。モデル間の不一致はそのようなシグナルの一つです。2つのモデルが属性について異なる回答をした場合、その画像は多くの場合曖昧です。すべての画像にセカンドモデルを適用するとコストが増加するため、まずはサンプリングから始めることができます。そのシグナルに依存する前に、開発セット上で実際のエラーをどの程度捕捉するかを確認してください。

まとめ

この記事では、Property Finderが評価バイアスを特定し、バイアスのないグラウンドトゥルースを構築し、Amazon Bedrockでのモデル選定を通じて進化的プロンプト最適化を適用することで、より低コストでより高い精度を達成した過程を詳しく見てきました。

この結果を得るには、3つの要素が揃う必要がありました。正直に測定するための偏りのない評価、プラットフォームを組み替えることなく複数のモデルファミリーを評価し切り替えられる柔軟性、そしてドメインに合わせて慎重に進化させたプロンプトです。Amazon Bedrock がその基盤を提供しました。単一の API を通じて複数のモデルファミリーへのアクセスを Property Finder に提供し、AWS のガバナンスおよびセキュリティコントロールを継承させ、インフラストラクチャを変更することなく新規モデルが利用可能になり次第採用できるようにしました。

Amazon Bedrock でのモデル評価と選択を始めるには、以下をご覧ください: Amazon Bedrock ドキュメント。大規模なビジョンワークロードを処理していて、偏りのない評価フレームワークの構築についてサポートが必要な場合は、 AWS Generative AI Innovation Center.

にご連絡ください。モデル評価やプロンプト最適化に関するご経験を、コメント欄でお聞かせください。

謝辞

AWSからの追加の寄稿者は、Yousuf Albannai、Amine Sehili、Thomas Ounnas、Aris Tsakpinis、Rafik Soliman、Nikhil Ulhas Pandit、Sneh Sharmaです。

著者について