Google Research、主観的なAI分類器に人間の熟考を取り入れる

Google Researchは2026年11月4日、Agile Deliberationを発表した。これは、主観的なカテゴリーに基づく画像分類器を構築するための対話型フレームワークで、オープンソースのコードとノートブック形式のデモも公開された。18回のセッションからなるユーザー調査では、手動でプロンプトを調整する場合に比べ、分類器の性能が向上し、作業負担も軽減したと研究者らは報告している。

このフレームワークが対象とするのは、個人の判断や文化的背景、運用方針によって境界が変わるカテゴリーだ。たとえば、健康的な食べ物、心を動かす芸術作品、誤解を招く報酬を約束するクリックベイト画像などがある。中心となる考え方は、判断の難しい事例を検討するなかで、ユーザー自身が判断基準を見いだすことが多いというものだ。従来のラベリング作業では、アノテーションを始める前に判断基準が確定しているものとして扱われる。そのため、意図の変化が一貫性のないラベルや恣意的なモデル判断として表面化することがある。

Agile Deliberationは、変化していく定義を、人が読める仕様書と、視覚言語モデルの分類器を動かすプロンプトの両方に反映する。この設計は、コンテンツモデレーションの専門家5人へのインタビューと、各人の業務で使われていた20件の定義の定性分析に基づいている。分析からは、専門家がまず概念の範囲を定め、その後、境界事例の画像を通じて定義を調整することが分かった。

概念を熟考する2つの段階

概念の範囲設定では、最初のアイデアを、肯定的・否定的な下位概念の候補に分ける。たとえば、健康的な食べ物を分類する器を作るユーザーは、サラダや穀物を使ったボウル料理を含める一方、加工食品や、生のまま調理されていない食材を除外できる。それぞれの選択を代表する画像を用意し、意味のある視覚的パターンを表さない下位概念は、最初の分類器を作成する前に取り除くことができる。

次の概念の反復では、モデルの信頼度が0.5に近づく事例を単純に選ぶのではなく、意味的に境界が曖昧な画像を探す。研究者らは、視覚言語モデルの信頼度は人間が感じる曖昧さに対して適切に調整されていない場合があると指摘する。モデルが確信を示していても、人には判断が難しい画像があり得る。検索された事例は重複を除去したうえでクラスタリングされ、過去に誤りを修正したり、有用なフィードバックを生み出したりしたクラスタを優先する、マルチアームド・バンディット方式のルールが適用される。

曖昧さを抽出する段階では、クリーミーなソース、糖分量、分量といった解釈可能な論点のいずれかを軸に画像をひとまとまりにし、各画像が曖昧である理由を簡潔に説明する。ユーザーは画像を対象範囲に含めるかどうかを指定し、自然言語で理由を追加することもできる。システムは複数の定義案を生成し、それまでに集めたすべてのラベルを使って検証したうえで、F1スコアが最も高い案を選ぶ。また、ユーザーは手動で編集することもできる。

プロトタイプでは、概念の分解にGemini 2.5 Proを使い、分類、境界事例のクエリ生成、曖昧さの抽出にはGemini 2.5 Flashを使う。これらのモデルには追加学習やファインチューニングを行わず、インターフェースは対話型のColabノートブック上で動作する。

実ユーザー調査で分かったこと

コンテンツモデレーションの実務経験がない参加者9人が、それぞれ約90分のセッションを2回行った。1回はAgile Deliberationを使い、もう1回は手動で熟考する方法を使い、使用するシステムの順序はランダムに割り当てられた。検証対象となった概念は、健康的な食べ物と、課金を促すクリックベイトのモデレーションの2つだった。各セッションでは、定義の作成に約45分をかけ、保留されたテスト画像200枚をアノテーションし、アンケートに回答した後、15分間のインタビューを受けた。比較には、ゼロショット分類と、自動で概念を分解するベースライン手法であるModeling Collaboratorも含まれた。手動で作業した参加者は、同システムが生成した詳細なプロンプトを参照できた。

論文によると、課金を促すクリックベイトでは、Agile DeliberationのF1スコアはゼロショットのベースラインと比べて11%向上した一方、手動での熟考では、独自のベースラインに対して8%向上した。健康的な食べ物では、Agile Deliberationで10%向上し、手動での熟考では3%低下した。向上の主な要因は適合率の改善で、再現率の低下はそれより小さかった。参加者ごとに定義が異なり、テストラベルの分布が不均衡になったため、正解率は評価に使われなかった。

参加者全員が、手動での熟考よりAgile Deliberationを好んだ。作業負担の平均値は、Agile Deliberationでは3.11、手動作業では4.67だった。不安やストレス、苛立ちを感じた度合いの平均評価は、それぞれ1.67と3.00だった。いずれの差も統計的に有意で、p<.05とされた。インタビューからは、実務上の理由も明らかになった。手動で作業した参加者は、反例を探す検索方法を自分で考える必要があり、ある誤りを修正するプロンプトの編集によって、別の場面での動作が損なわれるのではないかと懸念する人もいた。

調査の限界とコードの公開状況

この評価には明確な限界もある。著者らは、参加者が9人に限られるため、統計的検出力と一般化可能性が制約されると注意を促している。また、2回目のセッションに既に確立した定義を持ち込まないよう、各参加者は2つのシステムをそれぞれ異なる概念に使用した。そのため、主観的な体験は参加者内で比較できたが、分類器の性能は参加者グループ間でしか比較できなかった。個々の構成要素の効果は切り分けられておらず、他の生成モデルを用いたパイプライン全体の評価も行われていない。

オープンソースのリポジトリには、関連するコードベースとデータセットに加え、JupyterまたはGoogle Colabで使える、手順を詳しく説明したDemo.ipynbノートブックが含まれています。デモでは、LAION400Mを対象とする最近傍検索用のインデックスを構築します。既定のセットアップでは、パイプラインを検証するために合計約260 MBの2つのシャードをダウンロードします。ドキュメントに記載された100シャードのセットアップでは、合計約13 GBになります。検索、外部画像のダウンロード、モデルの呼び出しには数秒から数分かかることがあり、APIキー1つあたりの利用がレート制限される場合もあります。また、いくつかの段階ではディスクキャッシュが利用できます。リポジトリの免責事項には、これはGoogleが公式にサポートする製品ではないと記されています。

Agile Deliberationの実用面での貢献は、主観的な意図を、明示的に定義し、見直し可能なものとして分類器の開発に組み込むことです。ユーザーは、肯定的ルールと否定的ルールを確認し、見落としが明らかになった境界事例を調べ、修正の根拠を示すことができます。モデレーションやキュレーションを担うチームにとって、これにより、カテゴリの定義と、それを形づくる人間の判断が、分類器の開発過程のうち検証可能な部分になります。