この記事の目次
海洋画像のアノテーションを効率化する方法の一つに、AIの予測を人が確認しながら進めるやり方があります。まず一部の画像にアノテーションを付けてモデルを学習し、そのモデルに未確認の画像を処理させ、対象の場所や輪郭を示すマスクを予測させます。人は予測結果を確認して必要な箇所を修正し、確定したアノテーションを次の学習に加えます。この流れを繰り返すことで、人が1枚ずつ最初から作業するより効率的に、たくさんの画像をアノテーションできます。
このように、AIの予測と人による確認・修正を組み合わせてアノテーションを進める仕組みを、Human-in-the-loop（HITL）と呼びます。ただし、単に人が承認ボタンを押すだけではなく、どの画像を確認し、何を修正し、その結果を次の学習や評価に使うかまでを一連の流れとして管理します。有効に機能させるには、明文化した確認基準、追跡できる識別子、アノテーションの来歴、品質検査、開発に使わない評価データが必要です。
Human-in-the-loopで人が担う役割
HITLでは、AIが作成したマスクを人が確認します。ただし、人の仕事はAIが示した対象の範囲を確認するだけではありません。画像を研究データとしてどう扱うかについて、たとえば次のような判断をします。
- 画像に写る対象を、あらかじめ定めたクラスに分類するか
- 接触している生物を一つの領域としてまとめるか、それぞれ別の個体として分けるか
- 一部しか写っていない対象や、ぼけ・濁り・遮蔽がある対象をどう扱うか
- その画像を研究に使えるデータとみなすか
- モデルが苦手な画像なのか、入力データ自体に問題があるのか
こうした判断を人によってばらつかせないため、あらかじめ基準を文書化しておきます。基準がないままHITLのサイクルを繰り返すと、処理速度は上がっても、判断の違いが蓄積します。
改善の流れ
HITLでは、予測と修正を繰り返すだけでなく、どのデータを確認し、その結果をどう学習に戻し、モデルの改善をどう確かめるかまでを決めておきます。基本的には、次の順で進めます。
- 同じ条件を再現できるようモデルのバージョンを固定し、まだアノテーションしていない画像や一部だけ済んだ画像に適用して予測を作る。
- あらかじめ決めた基準に従い、どの画像を人が確認するかを選ぶ。
- 元画像とモデルの予測をレビュアーに示す。
- レビュアーがレビュー結果を記録し、修正内容を確認したうえで、確定版アノテーションを新しいバージョンとして保存・公開する。
- そのバージョンを明示したマニフェストに基づいて再学習する。
- 学習に使っていない評価専用のデータで、更新前後のモデルを比較する。
このサイクルを回すのは、追加したデータによって、あらかじめ定めた課題の改善が見込めるときです。少量のデータを追加するたびに再学習しても、評価に役立つ新しい情報は増えず、運用上の手間と結果のばらつきだけが増えることがあります。
予測・レビュー・確定版を分けて管理する
HITLのサイクルを後から検証できるようにするには、モデルの予測、人によるレビュー、学習に使う確定版アノテーションを同じデータとして扱わないことが重要です。信頼できるシステムでは、次の三種類を分けて管理します。
モデル予測
モデルのバージョン、出力したマスクやクラス、信頼度、推論時のパラメータを記録します。モデルが何を提案したかを後から確認できるよう、内容は書き換えません。
レビュー操作
誰がいつ、どのバージョンのガイドラインに従って確認したか、承認・修正・却下・保留のどれを選んだかを記録します。レビュー操作によって元の予測を上書きすることはありません。
確定版アノテーション
必要なレビューと検証を経て、特定のバージョンのデータセットに採用されたアノテーションです。以後の学習マニフェストは、このバージョンを参照します。
予測、レビュー履歴、確定版アノテーションをmask.pngのような単一のファイルに上書きしてしまうと、承認率も、人がどこを直したかも、そのアノテーションの元になったモデルも、後から追えなくなります。
人が確認する画像を選ぶ
確認できる件数には限りがあるため、選定規則が重要になります。
不確実性による選定
信頼度が低い予測や、複数のクラスに同程度の確率を付けてモデルが迷っている予測（エントロピーが高い予測）を選びます。対象の範囲やクラスを決めにくい画像を見つけやすい一方で、モデルの信頼度が確率として適切に校正されているとは限りません。信頼度が高いまま誤っている予測は、この方法では拾えません。
不一致による選定
モデルのバージョン違い、異なるデータ拡張、アンサンブルの各モデルで予測が一致しない例を選びます。不安定な予測を見つけられますが、追加の推論処理が必要になり、特定の種類の難しさばかりが集まることもあります。
多様性・新規性による選定
画像のメタデータや、画像の見た目の特徴を数値化した情報を使い、地点、日付、カメラ、深度、見た目の特徴が偏らないように選びます。ほぼ同じフレームを何千枚も確認する事態を避けられます。
既知リスクによる選定
希少種、低視界、小さな対象、画像端、付着物、反射、新しい装置など、運用上重要な条件を意図的に選びます。
ランダム監査
無作為に抽出する枠も残します。これがないと、通常のデータで誤りがどのくらい起きているのかを推定できず、信頼度が高いまま誤っている予測にも気づけません。
実際の運用ではこれらを組み合わせ、確認対象の偏りを抑えながら、見落としも防ぎます。どの規則で選ばれた画像なのかを記録しておくと、確認対象の構成を後から点検できます。
同じ撮影場面の画像ばかりを選ばない
海洋画像には、動画から連続して切り出したフレームが大量に含まれることがあります。モデルの不確実性だけを基準に確認対象を選ぶと、同じ撮影区間のよく似たフレームが何百枚も選ばれかねません。確認作業が重複するだけでなく、次の学習データも一つの場面に偏ります。
そこで、確認対象を選ぶ段階で、撮影単位や画像同士の間隔に制約を設けます。
- 動画、潜航、測線、地点、日ごとに選ぶ枚数を制限する
- フレーム間隔または撮影時間の間隔を一定以上空ける
- ほぼ同じ画像を除く
- 取得条件ごとに偏りなく選ぶ
- 元の撮影単位を示すIDをアノテーション出力に残す
元の撮影単位を記録しておくことは、後で学習用とテスト用のデータを分けるときにも重要です。海洋データの機械学習で起きるデータリーク：空間・時間を考慮したデータ分割では、同じ撮影単位に属する画像を学習側とテスト側にまたがらせてはいけない理由を説明しています。
人が確認・修正しやすい画面にする
画面には、AIの予測を確認し、必要な修正を加え、その判断を記録するための機能を用意します。研究上の判断をしやすく、意図しない変更に気づいて取り消せることが重要です。
たとえば、次のような機能が考えられます。
- 元画像を拡大・調整し、予測結果の表示・非表示を切り替える
- クラスや個体を確認し、対象の範囲を編集する
- 必要に応じて、取得条件や前後のフレームを確認する
- 承認、修正、却下、除外、保留のいずれかを選ぶ
- ガイドラインや判断に迷う例を参照し、必要なら修正理由を残す
信頼度は、アノテーションの正しさを保証する値ではありません。確認対象の優先順位や、候補が選ばれた理由を示すためには使えますが、レビュアーが誤った提案に引きずられる原因にもなります。品質を監査するときは、信頼度を隠して確認する方法や、予測を表示した場合と表示しなかった場合の結果を比べる方法が役立ちます。
海洋画像をAIの学習データにする：Label StudioとSAMで始めるアノテーションでは、モデルの提案を使ってアノテーションする手順を説明しています。この場合も、モデルの提案と最終判断は分けて扱います。SAMが対象の範囲を提案しても、それがプロジェクトのクラス定義と境界基準に合っているかどうかは、アノテーターが判断します。
レビューの進み具合と品質を確認する
レビューが効率化されたかどうかは、作業量だけでなく、判断の品質やデータの偏りも見て確認します。たとえば、次のような指標が使えます。
- 1件あたりの確認時間
- 承認、修正、却下、保留などの判断結果の割合
- 修正したときに対象の範囲がどれだけ変わったか
- 修正や再確認が必要になった割合
- クラスや取得条件ごとの確認状況
承認率や確認時間だけでは、レビュー支援の効果を判断できません。簡単な画像ばかりが集まっただけかもしれませんし、レビュアーがモデルの提案を過信している可能性もあります。確認が速くなった一方で、アノテーションの品質が下がっていることもあります。予測を表示しない監査や二重レビューと組み合わせて評価します。
レビュアー間の不一致率だけで担当者を順位付けしないようにします。担当するクラスや画像の難しさが異なるうえ、不一致が多い原因も作業の丁寧さではなく、ガイドラインの曖昧さにあるかもしれないためです。
アノテーションとレビューの履歴を残す
公開するアノテーションの各バージョンについて、元画像と取得単位、元になったモデルの予測、誰がどのように確認・修正したか、最終的なクラスと形状を追跡できるようにします。使用したガイドラインとクラス対応表のバージョン、検証結果も記録し、必要なら除外や保留の理由も残します。
学習時には、内容を固定したアノテーションのバージョンをマニフェストに明記して参照します。実行途中で内容が変わる「最新版」を直接参照すると、同じ条件で学習を再現できません。
コード、スキーマ、ガイドライン、小さなマニフェストは、研究コードの変更履歴と再現性を残す方法：Git・GitHub入門で説明しているGitで管理できます。大容量の画像やマスクはデータセット管理ツールやオブジェクトストレージで管理し、内容を特定できる識別子をGit側に記録するのが一般的です。
評価データを保護する
「改善の流れ」で示した図のように、評価専用のテストデータは改善ループの外に置きます。このデータをアノテーション候補の選択やクラス定義・境界基準・信頼度閾値の調整、複数のモデルの比較、再学習に使ってはいけません。開発上の判断に使うデモ画像へ転用することも避けます。
テストデータを確認していてアノテーションの誤りが見つかった場合は、あらかじめ定めた方法で修正します。変更を記録し、過去の比較結果をそのまま使えるか説明したうえで、必要なら評価用ベンチマークを新しいバージョンとして扱います。都合の悪いアノテーションだけを記録なしに直すと、それ以降の比較は成り立ちません。
今後取得するデータについては、運用監視用の確認枠を別に設けます。評価用ベンチマークを学習データに転用せずに、データ分布の変化にも気づけます。
追加したアノテーションでモデルが良くなったか確かめる
確認済みのアノテーションを追加したら、更新前のモデルと同じ条件で学習したモデルを比べます。目的は、追加したデータによって、あらかじめ定めた課題が本当に改善したかを評価用データで確かめることです。
- 追加したアノテーションのバージョンを記録し、前回と同じ学習手順で新しいモデルを作る。最初の比較では、学習条件もできるだけそろえる。
- 新旧モデルを、同じ評価用テストデータで評価する。
- 全体の平均だけでなく、クラス別・取得単位別の指標も比べる。
- どの失敗が解消され、どの失敗が新たに生じ、どの失敗が残ったかを確認する。
- 追加データで重点的に集めた条件で改善が見られたかを確認し、更新版を採用する根拠を記録する。
評価指標や取得単位を考慮したテスト、目視によるエラー分析については、海洋画像のアノテーションからセグメンテーションモデルへ：学習と評価で詳しく説明しています。
アノテーションを増やしたからといって、必ず良くなるわけではありません。クラスの偏りや修正基準の不統一、難しい例ばかりを集めたこと、学習条件の変更などによって、通常の画像に対する性能が下がることもあります。
HITLで起こりやすい問題を見つける
AIの提案に引きずられる
レビュアーがモデルの提案を正しいと思い込み、誤りもそのまま受け入れることがあります。予測を表示しない画像を監査用に混ぜたり、必要に応じて予測を隠して確認したりします。
確認対象が偏る
不確実な画像ばかりをアノテーションすると、一般的な条件のデータが不足します。不確実性だけでなく、多様性、既知のリスク、無作為抽出も組み合わせます。
未知の対象を見落とす
モデルは、学習していないクラスを提案できません。レビュアーがモデルの提案だけを確認すると、未知の対象を見落としたままになります。「不明・その他」を選べるようにし、画像単位で問題を報告できるようにします。
古い予測が混ざる
複数のモデルが作った予測を区別せずに扱うと、古い予測が新しい確認対象に混ざります。予測ごとにモデルのバージョンを記録し、モデルを更新したら確認対象を作り直します。
ガイドラインがいつの間にか変わる
時間がたつと、レビュアーの判断基準は少しずつ変わります。ガイドラインにバージョンを付けて変更点を共有し、影響を受けた画像だけを必要に応じて再確認します。
評価用データが開発に入り込む
テスト用の画像が、修正や再学習に使うデータへ混ざることがあります。マニフェストとストレージの権限で用途を分け、分離できているかを実際に確かめます。
まずは小さく試す
最初からすべてのクラスや画像を対象にせず、管理しやすい範囲で一連の流れを試します。たとえば、次のように進めます。
- 対象クラスを一つに絞り、少数の取得単位から始める。
- 承認や修正、却下、除外の扱いを決める。
- 一つのモデルで予測を作り、不確実性や多様性、無作為抽出を組み合わせて確認対象を選ぶ。
- 少数の画像を二重に確認し、内容を固定したアノテーションのバージョンを作る。
- そのデータで一度だけ再学習し、開発に使っていない取得単位のテストデータで、品質と確認作業の負担が改善したかを比べる。
対象クラスやレビュアーを増やしたり、優先順位付けを自動化したりするのは、基本の流れを確認してからで十分です。
この確認ループを自組織だけで構築するのが難しい場合は、下の問い合わせ導線から、設計・実装支援やアノテーション業務の委託についてもご相談いただけます。
お問い合わせ
構築・実装支援とアノテーション業務
環境構築や設計・実装の支援、アノテーション業務の委託について、ご相談いただけます。
よくある質問
Human-in-the-loopとActive Learningは同じですか？
Active Learningは、確認候補を選ぶ方法の一つです。Human-in-the-loopはより広い概念で、レビューでの判断、アノテーション規則、来歴、品質管理、バージョン管理、再学習、評価までを含みます。
レビュアーに信頼度を見せるべきですか？
作業に役立つ場合だけ表示します。ただし、モデルの数値に判断が引きずられるアンカリングに注意が必要です。候補が選ばれた理由の説明には使えますが、正解として扱ってはいけません。
承認済み予測を直接学習に使えますか？
承認の規則、レビュアー、予測のバージョン、検証結果、データセットのバージョンを記録したうえで学習に使います。リスクの高い条件に当てはまる画像は、抜き取り確認か二重レビューを行います。
どのくらいの頻度で再学習すべきですか？
意味のある単位ごとにバージョンを付けてバッチにまとめ、あらかじめ決めた評価基準に照らして判断します。一律の頻度はありません。新たに追加したデータと確認結果が、再学習や比較にかかるコストに見合うときに実施します。
