概要
AWS Machine Learning Blogによると、デジタル不動産アプリケーションを手がけるProperty Finderの事例をもとに、Amazon Bedrock上でのAIモデル評価におけるバイアスを解消し、適切なモデル選定を行う手法が公開された。
従来の評価方法では、既存モデルの出力をそのまま正解データとして扱っていたため、新しいモデルを公平に比較できない構造的な問題があった。
本記事では、この評価バイアスをいかにして発見し、人間の専門家による正しい正解データの構築とプロンプトの最適化によって高精度なモデル選定に至ったのかを解説する。
何が発表された？
AWS Generative AI Innovation CenterのチームとProperty Finderのエンジニアリングチームが共同で取り組んだ、Amazon BedrockにおけるビジョンAIワークロードの評価手法の改善とプロンプト最適化のプロセスが発表された。
Property Finderは、中東および北アフリカ地域において毎日数万枚の物件画像を処理し、ウォーターマークの検出や部屋の分類、家具の有無など11個の品質属性を評価している。
しかし、移行先のよりコスト効率の高いモデルを検討する際、従来の評価用ラベルが既存モデルの予測を直接引き継いだものであったため、どのような代替モデルも不利になるという課題に直面していた。
発表では、この評価バイアスを取り除くための独立した人手注釈による正解データの構築と、強化学習の枠組みを取り入れたプロンプトの反復的最適化手法が示されている。
あわせて読みたいAWS週刊アップデート：BedrockとTrainiumの最新情報→評価の歪みはなぜ起きたのか？
多くのチームがビジョンモデルを比較するために評価用データセットを構築する際、最も一般的に行われるのは、現在稼働中のモデルの出力を正解データとして扱うことである。
Property Finderの評価用サンプルのうち96.8パーセントは、独立した人間の検証を経たものではなく、既存のビジョン言語モデルの予測から直接引き継がれたものであった。
これにより、代替モデルは実際の正確さではなく、既存モデルの挙動にどれだけ似ているかによって評価されるという循環的な構造に陥っていた。
さらに、ウォーターマークのテキスト抽出における文字レベルの間違いや、複数の部屋タイプが写る画像への単一ラベルの強制など、隠れたエラーも確認された。
残りの3.2パーセントの人手によるラベルについても、元の仕様にないカテゴリが混入するなどしており、回答の基準となる正解データ自体を見直す必要があった。
信頼できる正解データの構築方法はどう行われたか？
循環的な評価のサイクルを断ち切るため、過去のモデル出力を一切参照しない、ドメイン知識を持った専門家による独立した新しい注釈作業が実施された。
データセットの範囲として、UAEの画像356枚とエジプトの画像が選ばれ、今回の結果はUAEの画像をもとに報告されている。
そのうち最初の256枚の開発セットでチューニングを行い、最後の100枚を追加した356枚の評価セットで最終的なモデル比較を行った。
戦略・アナリティクス専門家がすべての画像を注釈し、AWS Generative AI Innovation Centerチームが体系的な品質レビューを実施して一貫性を保った。
また、リアルタイムの不動産画像で複数の部屋や特徴が重なる実態に合わせて、単一ラベルからマルチラベルへの移行が行われ、モデルが二次的な予測に対して不当にペナルティを受けない仕組みに改められた。
プロンプト最適化はどのように進められたのか？
バイアスのない評価が整ったことで、評価指標を報酬信号、エラー分析を改善のための勾配と見なす、強化学習に似たプロンプトの反復的最適化が可能になった。
初期のプロンプトであるv0から、エラー分析を繰り返しながらバージョンが重ねられ、最終的なv27_PFへと進化していった。
初期のバージョンではドア越しに見える別の部屋のタイプを誤認識する課題があったが、大部分を占める部屋を基準とする指示の追加や、マルチラベル出力への切り替えによって精度が改善された。
さらに、地域ごとの装飾的なテキスト（ウォーターマークではないアラビア語のテキスト）に対するルールを追加することで、誤検知のカテゴリが削減された。
自動プロンプト最適化フレームワークであるMIPROv2なども活用され、写真分類タスクの構造化がさらに洗練された。
結果としてコストと精度はどう変わったのか？
最終的な評価プロンプトを用いた検証において、Llama 4 Maverick 17B Instructは356枚の評価セットでMicro F1スコア0.80を記録した。
比較対象であるプロプライエタリモデルAはv22プロンプトで0.56となっており、スコアの向上が確認された。
単一ラベルの9つの属性のうち6つで90パーセント以上の正確致（Exact-match accuracy）を記録し、すべての11属性において従来モデルと同等以上の結果を示した。
Property Finderはこの結果に基づき、すべての属性における精度とコスト効率を考慮して、プロダクション環境のワークロードにLlama 4 Maverick 17B Instructを選択した。
料金は？
Amazon Bedrockの標準料金および利用するモデルの従量課金に準拠する。記事内では具体的な料金額の提示はなく、コスト効率の優れた選択肢として導入されたことが言及されている。
日本で使える？
使える。Amazon Bedrockが提供されているAWSリージョンにおいて、対応するモデルを利用することが可能である。
- Amazon Bedrockのマネジメントコンソールにアクセスする。
- 対象のモデル（Llamaシリーズなど）の利用有効化を行う。
- リージョンごとのモデル提供状況を確認の上、APIやコンソールから実装する。
自分にはどう関係する？
エンジニアなら
自社でAIモデルの評価環境やベンチマークを構築する際、既存モデルの出力をそのまま正解データにすることの危険性と、独立した人間によるアノテーションの重要性を設計に組み込むことができる。
企画・マーケティングなら
ビジョンAIなどの導入時に、モデルの性能比較が本当に公平な基準で行われているかを検証し、コストと精度のバランスを見極める判断材料として活用できる。
経営者・管理者なら
AI導入における評価プロセスの見直しが、精度の向上だけでなく、よりコスト効率の高いモデルへの移行による全体的なコスト削減に直結することを把握できる。
まとめ
AIモデルの評価において、既存の出力に依存したバイアスを見落とすと、公平なモデル比較や適切なコスト削減の機会を逃してしまう。
読者が次に取るべきアクションとしては、現在社内で利用しているAIの評価データセットが過去のモデルの出力に依存していないかを確認し、必要に応じて独立した評価基準とプロンプト最適化のループを構築することである。
