利用目的にそって学習後の性能を疑うこと

趣旨：機械学習の性能が100%になることはありえない。利用目的にとって重要な性能と評価は何か。

学習後の性能の問題がないかを疑うことだ。そして、最小限の利用価値を満たしていることを示すことだ。
そのことについてこの記事では述べようと思う。

序文

• 機械学習のフレームワークはだいぶ便利になっている。
• カスタムモデルでの学習のしかたもリポジトリに含まれている。
• 最近は、機械学習のためのデータの集め方や、アノテーションのしかたについて実際的な情報が入手できる例が増えてきている。
• 例：「Interface」2023年4月号
• 「仕事ではじめる機械学習 第2版」
• 【自動運転】信号機認識に挑む / 走行画像15,000枚のアノテーションとYOLOXモデルによる深層学習実践
• このような例を読むこと・例題をたどることで、機械学習を要件の定義から、学習データの収集・アノテーション、学習、アプリケーションの構築までが理解を深めることができるようになってきています。
• 最近の記事では、アノテーションを複数名で実施する際に問題になることなど、実際の業務での経験に基づいた記事が増えてきています。
• そのようなおかげで、機械学習を業務として着手する際のバリアが減ってきています。

機械学習結果のデプロイの手順も情報が増えてきた。

• 処理の流れはだいたいこんなだろうか。

1. 学習結果を登録する。
2. 機械学習結果を評価する。
3. 機械学習結果をターゲット環境用に変換する。
4. ターゲット環境変換したモデルを登録する。
5. ターゲット環境に機械学習を含んだシステムを提供する。

ターゲット環境へのモデルの変換例

• TensorRTへの変換(NVIDIA　GPU環境)
• OpenVinoへの変換（Intel　deviceの環境）
• ONNX Runtime への変換

こういった情報が、機械学習の枠組みに含まれていることもあるし、
各ターゲット環境の開発者によって、各学習モデルを変換する方法が公開されている。
そのため、ターゲット環境へのモデルの変換作業も格段と簡単になってきている。

学習データの収集、アノテーション、学習からデプロイまでサポートする環境ができてきている。

例：VettexAI
例：Amazon SageMaker

アノテーションツール　例　CVAT

web 上の jupyter notebook 環境 Google Colaboratory

このため、機械学習をデータの収集からアノテーション・学習の遂行までがやりやすくなってきている。

ここからが本題

機械学習の成果を引き出せる問題のサブセットを見つけること

• 業務としての機械学習の本や雑誌の記事が増えている。そのなかで、述べられていることは、達成すべき目標の設定の重要性である。機械学習で100%の精度がでることはないから、次のように書かれている。（前述のInterfaceの記事）

• 「プロジェクトの成否を決める問題設定」
• 「用途を限定すれば機械化の可能性が高まる」
• 「まずは価値の高い9割に対応する」
• 「残り1割についてどうするのか考える」
• 「対象範囲を見極めることが重要」
• 「ただし外せないものがある」
• 「1歩ずつ適用範囲を拡大がお勧め」

機械学習の書籍・記事などで不足してると私が考える内容：それは性能評価

• webの記事の大半は、推論が動いたで良しとするもの。
• しかしながら、業務として機械学習結果をサービスを提供するには、それでは不十分。
• 結果の品質を検証していくことが求められる。
• 単一の再現率・適合率・ｆ１スコアだけでは表現しきれない部分がある。

以下、そのような性能評価の項目を示してみようと思う。

検出問題の場合の疑うべき項目

• 検出性能が背景によって著しく変わること。

  • 人検出を単純な背景でだけ学習させると、複雑な背景では人検出ができない。
  • 人の背後に人がいるような混雑シーンでの人検出は、そのようなデータを学習させることで検出可能になる。

• カメラの視線の高さ、カメラの設置角度によって検出性能が保たれているか。

  • 乗用車の車載カメラが見る人の画像と、ショッピングモールの監視カメラでは人の見え方が変わってくる。そのため、学習済みの人検出のmodel zoo でも、異なるモデルが提供されているくらいだ。
  • 例：　Object Detection Models

• 画像を面内回転したときの検出率がどの程度保たれているか。

• 検出対象の一部を遮蔽するものが写ったときにどの程度対象物を検出することができるか。

  • 傘で頭部が隠れていると人検出できない車載カメラの人検出 なんてのがあったら嫌ですよね。

• 利用環境での照度で、検出性能が確保できるかどうか。

  • 夜間の歩道での防犯カメラの場合だったら、照度が不足しがちです。
  • 夜間の歩行者画像のデータセット
    NightOwls dataset Pedestrians at night
    NightOwls: A Pedestrians at Night Dataset pdf

• 順光での対象物と逆光での対象物

  • 検出性能に差が出がちです。

• 被写体の属性によって性能が確保できるかどうか？

  • 顔検出の性能が、高齢者の場合下がるということはありうるのかどうか

• 被写体の姿勢によって検出率が変わることはよくあることです。

  • 想定するユースケースでは、どういう状況で検出する必要があるのですか

• シーンによって検出率が悪いということはありませんか。

  • 再現率・適合率の指標で、検出性能を評価しているでしょう。
  • シーンを一つにまとめて評価するのではなくて、シーンを分類ごとに再現率・適合率を評価してみてください。
  • シーンによっては、いずれかの値が低かったりしませんか。
  • 全ての評価データをひとまとめにして評価すると、弱点となるシーンがあっても見逃してしまうでしょう。
  • どういうシーンで、どういう対象物で性能が出ていないことがわかれば、どのようにして改善すればいいのかが見えてきます。

• どのような状況で誤検出が頻発するか。

  • 想定する入力は、どうしても学習データの範囲を超えがちです。
  • そのため、当初想定したデータセットのtrain用val用にとっておいた部分では、誤検出を少なく抑えられていたとしても、それ以外のデータセットを入力したときには誤検出が、無視できない頻度で発生するということが起こります。
  • 例：洋服売り場での人の検出
  • 起こりうること：マネキンに対する検出は、どう判断すべきなのか？
    • 方策1：マネキンを人として検出しまうのはしかたないと考え、それ以外の方法で、マネキンの問題を除外する。
    • 人の動線の範囲が視野に入るようにカメラを設置し、人検出・顔検出で、人の客層分類をする。（マネキンが視界に入らないし、入っても顔検出されないから大丈夫。）
    • 方策２：追加のマネキン判定を加える
    • 人とマネキンを含む検出器をまず作る。その検出結果に対して、マネキン判定の有無を作る。
    • マネキンの場合、頭部がない、頭部が単純化されているなどの特徴がある場合が多いです。そのため、顔検出したときには、通常の顔検出がかからない場合が増えます。
    • 方策３：マネキン画像をネガティブサンプルとして学習させる。
    • 今の時点の機械学習のアルゴリズムの中では、学習できると限りませんし、通常の人検出の性能の劣化につながることでしょう。
  • 推奨すること、システムの全体の使い方の中で、解決することです。

検出問題と最小検出サイズ

その検出器では、対象物の大きさをどこまで検出することを期待していますか。
アノテーションルール：　どの大きさまでアノテーションするのかをルールとして明確化しましょう。
学習の設定：　機械学習の入力サイズ・学習モデルの種類によって、検出可能な物体のサイズ（画素数）が決まってきます。
性能の評価：　再現率の評価：　再現率が低いときに、その低い値の理由になっている未検出が、小さな対象物によるものかどうか疑ってみましょう。
　アノテーションで正解データを与えているのにもかかわらず、検出性能が追いつかないために未検出になっていないかどうかです。
適合率の評価：　学習条件の見直しなどで、再現率が向上したときに、適合率が下がっている場合があります。　この場合、誤検出と判定された検出の検出の大きさを確認してみましょう。その大きさの分布を見たときに、小さな検出枠の誤検出が多くないか。もし小さな検出枠が頻出しているとしたら、小さな対象物へのアノテーション漏れの可能性があります。本当にそうかどうかは、個別に検出結果を目視で確認することです。

カメラの設置条件を利用すると、誤検出を減らせる。

・ビルの壁面に大きく書かれたポスターの人の写真に対する検出は、誤検出判定を追加することで改善できる。
　縦横比（＝アスペクト比）が保たれている画像と、極度に縦横比がずれている画像の区別をする追加学習。また、その中には、極度に透視変換した画像も加える。そうすると、誤検出を減らせるだろう。
　人の全身画像を仮定すると、足元のｙ座標と検出枠の高さには相関関係のある分布を生じる。その分布から極端にずれているものは、壁面にある人の巨大なポスターだろう。

分類問題の場合疑うこと

• 解決すべき課題と、そのデータは妥当ですか？

• 解決すべき問題は、無理のない問題設定になっていますか？

  • 例：「顔画像の年齢判定だけで、タバコ判定の可否を判定する」顔で成人を識別するタバコの自動販売機があった!
  • 例：顔部分の画像だけで、10歳未満の子どもの性別を判定する。髪型や服装のヒントなしに性別判定すると人でも判定に惑う状況があります。そもそも性別を判定する必要があるのかどうかという問いかけもあります。

• 解決すべき分類問題を理解していますか。

  • 例：医療画像の分類・検出問題
  • 何がその医療画像の分類のキーなのかを、全く理解しないままに機械学習システムを構築するのは危険です。
  • 医療画像は、色自体が重要な情報です。
  • data argmentation で色を加工することには慎重に。

• その分類は、本当に正しいかか確認できていますか。

  • 医療画像の分類問題の正解のアノテーションは、医療画像の専門家に判定をもらう必要があります。
  • しかも、紛らわしい医療では、複数の医療画像の専門家の判定を仰ぐことです。
  • 特に医療画像の場合には、その判断の説明責任がともないます。
  • 「説明可能なAI」 の構築を心がけてください。

• 顔の表情分類の場合

  • 表情の分類方法は、あなたの想定するユースケースにそったものですか。
  • 顔の表情分類は、どの程度の顔向きの範囲でする必要がありますか。
  • 顔の表情分類のデータセットは、どのようにして作られてますか？
    • 笑顔・笑顔ではないの判定をしようとしたときに、分類の基準を作ったのが一人だけで信用することができますか？
    • 複数名の判断で共通する判定をできるようなデータになってますか？
  • 性能が出にくい状況：
    • 学習・評価用の典型的な顔の表情とは異なる状況で撮影した一連の動画シーンでの表情分類。
    • 出現頻度の少ない表情の再現率は十分ですか？
    • 学習していることと、学習の結果精度がでていることとは同じではない。
  • ありがちなこと
    • 口が開いていると、「笑顔」や「驚き」になりやすい。
    • 出現頻度の少ない表情・学習評価データを集めにくい表情「嫌悪」は精度がでない。
    • 学習・評価データがまったくの正面顔に偏っていて、そのために、顔を少し下向きにするとか、顔を30度横向きにするだけと 表情分類の精度がでない。
    • 学習している地域・人種的な変動が少ないので、そのような変動に対しては表情分類がでないことがあるかもしれない。
  • 顔の表情分類については、顔検出ほどデータセットが充実していません。
    • 顔表情のデータセット自体が少ない。
    • 開発に使えるライセンス条件のデータセットが少ない。
    • 商用ライブラリの開発にはつかえないものが大半。

• 典型例が分類できることと、連続的な現象を分類することは別物。

  • アヤメの分類問題では、異なる種類のアヤメであって、その中間種のアヤメは存在しない。
  • 一方、顔の表情は連続的に変化する。
  • そのため、表情の典型例をデータベースを元に学習・判定できたとしても、日常の連続的な表情の入力のときに、どこまでを笑顔とするのか、どこからを笑顔ではないと判断するかをあなたの期待するものになっているかどうかは疑わしい。

分類問題の学習を全て、事前の学習で対応する必要がありますか。

既にある程度学習ができていれば、新規のデータのうち半分程度以上は、
かなりの確信をもって正解データに追加できる可能性があります。
それらを加えて学習を更新すれば、分類器が判定できる範囲が増える可能性があります。
確信が持てない新規のサンプルに対する分類は、人に入力を要請していくというアプローチがあります。
そうすると、分類問題を処理できる性能を繰り返しによって改善していくというアプローチもあるでしょう。

こういった部分に問題がないかを検証していくことです。そのため、プロジェクトの成否を決める問題設定 との関連が重要になってきます。

• 何ががまんできるのか

• 何はがまんできないのか
  製品・サービスとして根幹をなすもの（＝外せないもの）についての性能の確認は極めて重要になります。

• さきほどの表情分類でも、必要なのは、笑顔・非笑顔判定である場合もあります。

• 笑顔判定は、利用シーンが多いために、表情の分類の中では精度がでやすい傾向があります。

• ですから、あなたが開発するアプリケーションの中で必要十分な条件を見つけ出して、その範囲でテストすることです。

検出問題での撮影画像レベルで疑うべきもの

• 「そのドライブレコーダーでは、信号のLEDの点灯状況はどう見えますか？」
  • LEDは交流電源を整流して使っている関係で、実は点灯しています。ビデオカメラの撮影周期によっては、人には点灯して見えるLEDランプが撮影したタイミングでは消灯している画像が撮影されることがあります。
• 「そのカメラのシャッターで見た列車の画像は歪んでませんか？」
• 「カメラで見たドアの開閉状況は、実際よりどれくらい遅れてますか？」
  • ビデオ信号のエンコード・送信・ビデオ信号のデコードをしているシステムでは、画像信号の遅延が従来のアナログ信号（例NTSC信号)に比べて遅延が大きくなります。
• 「飽和を起こすほど輝度が高い赤い光源は、白く見えていることはないですか？」

撮影する時点で工夫しないと、性能がでない。

• カメラの種類・レンズ・イメージセンサの組み合わせが重要。
• どれくらいの視野になるのか？
• 解像度？
• 撮影の画像のSN比
  機械学習に着手する前に考えるだけではなく、機械学習の進展とともに再度、撮影系の設計を見直すことも必要でしょう。

マシンビジョンの知見を利用して、撮影条件に工夫をする。

• 「特集2認識率UP!マシンビジョンの撮影術」

  • このインターフェースの記事は参考になります。
  • 照明のあて方一つで、500円硬貨の見え方が変わってくるのを示しています。
  • 周辺から光を当てると、それ自体がエッジ検出の効果をもっている例があります。
  • また、特定の向きから光を500円の文字が見えるものもあります。

• 反射光が無視できない環境での画像認識

  • 偏光フィルタを使って反射光を減らして撮影することで、視認性を向上させることができる場合があります。
  • 偏光フィルタを使うとガラス越しの対象物を撮影するのが、視認するのが容易になります。

マシンビジョンの知見・初期の機械学習結果の成果を元に、システム設計を考え直してみよう。

• 解像度とフレームレート：機械学習で推論する際に入力の解像度が限られている場合には、あるいは、システム設計の中で用いる画像の解像度に限界があるなら、カメラの撮像系での解像度を高くしてもしかたありません。解像度を高くするとフレームレートをあげにくいと部分があります。解像度を下げるとフレームレートを上げやすくなります。フレームレートをあげたほうが、レイテンシー（＝遅延）を少なくしやすい部分もあります。
• 視野の選択：同じ解像度であっても、視野の広がりをどするのかは、レンズの選択につながる大事な設計要因です。 システム全体の設計の中で視野がどれくらい価値を持つかで考えることです。
• そういった変更を加えることで、性能を出しやすくすることができるかもしれません。

市場投入の判断と性能評価をどうするのか

• 機械学習の場合に実環境において100%の再現率と100%の適合率を同時に満たすことはありません。
• 100% を実現するまで待っているといつになっても市場に投入できなとくなります。
• かといって、不十分な製品・サービスを投入すると、その不満足な点が製品・サービスを台無しにしてしまいます。
• 他の方が書いているように「用途を限定すれば機械化の可能性が高まる」のですから、限定したユースケースでの使用を満たすようにすことです。
• つまり、限定的なユースケースを満たすをことを確認するためのテストが実行することです。
• そのために、市場投入の判断と性能の確認が連動してきます。

後処理を含めたシステム設計の重要性

• 先にマネキンのある環境での人検出の話をしましたが、機械学習で何かを推論したあとの動作をどう設計するのかがとても重要です。
• その後処理の仕組みによっては、機械学習の間違いの許容できる範囲が増えます。
• 当初想定した画像認識結果が全体のシステムの中で役に立つと思っていて開発していますが、システムが組み上がった後になって、期待したほどの効果をもたないということが判明することもあります。

機械学習の良し悪しは、F1スコアだけでは評価しきれない。

• 機械学習後の学習結果の良し悪しを、mAPや再現率や、F1スコアなどの評価している事例が多い。
• だから、それらの指標の性能が向上しているかをどうかで、機械学習の良し悪しを判断すればいいと思っている人が多いだろう。
• しかし、機械学習を改善しようと思うなら、それらの指標が全てではないことを意識してほしい。
• 系統的な弱点は、わずかな値の中に隠れている。
• 人検出の学習・評価用のデータの中で、うずくまっている人物の画像は0.1%もありはしないだろう。だから、そのような状況での検出が全滅であっても、再現率の0.1%に影響しない。
• ユースケースの中で、そのような「うずくまっている人物」が検出できない場合に、どのような課題を生じるのかを考えてみよう。
• 駅のホームの監視カメラの場合だと、泥酔者を見つけることは、事故を未然に防ぐうえで重要な要因のはずだ。
• 一方、ビルのエントランスでの人検出の場合には、さほど問題にならないかもしれない。
  − ユースケースの中で、どのような未検出が問題になるかに対して想像力を働かせることだ。

まとめ

• 検出問題・分類問題には疑うべき定石がある。
• 想定する利用シーンでの評価を重視すること。
• 後処理によって問題を簡単にして、実現する機械学習の中身を単純なものにしよう。
• マシンビジョンの知見は有用です。
• 初期の実装結果をもとに、撮像系と機械学習系の設計を再検討するとバランスのとれたシステム設計につながる。
• 限定的なユースケースから少しづつ利用できるシーンを増やしていこう。

---

学習後の性能評価の詳細についての記事が書かれにくい理由

理由1：守秘義務

• 学習結果の性能評価の詳細を記載すると、実際の製品やサービスでの性能が出ていない部分がどこにあるかを公にすることになりかねません。
• また、自社の製品・サービスの性能を競合他社と比較可能にすることにもつながります。
• 被写体の画像によってはプライバシー・肖像権などの問題を生じます。
• それらの理由によって、性能評価の詳細について記事が書かれることはほとんどありません。
• 10年前に開発した製品・サービスで今の時点では、利用が停止している場合であっても守秘義務があります。
• また、他社の製品のライブラリを利用して評価した場合でも、NDAにともなう守秘義務があります。
• ですから、性能評価の具体例が書かれることはほとんどありません。

理由２：性能評価とは開発ポリシーである

• また、性能評価の詳細は、何を優先的に実現しようかと考えているのかの詳細を物語るものになります。
• ですから、近い時点でリリースされるであろう製品・サービスの機能がどのような部分にフォーカスしたものになるのかを語るものになります。
• そういう意味でも性能評価についての開発の詳細を語ることは難しくなります。

理由３：アルゴリズム開発者にとっては、評価セットは固定でなくては困る。

• ある検出アルゴリズム（正確には、検出の機械学習アルゴリズム）が、先行するアルゴリズムよりもよいものであるという示すためのものです。
• ですから、アルゴリズム開発者は、機械学習の評価用の学習・検証データを吟味し直すことは多くありません。
• 評価用のデータセットにアノテーションの間違いがあったとしても、複数のアルゴリズムの性能の比較をする際には、勝手に変えるわけにはいかないという事情があります。

理由４：データベース構築の莫大なコストは、なかなか公開できるキャリアにならない。

• 現実のアルゴリズムの課題について論文を書こうとすると、その課題を示す論文にデータを示さねばなりません。
• 課題を示すための社内で構築したデータセットは、とても社外に公開できるものとはなりにくいのです。
• そのため、性能評価のために構築し、検討した内容を論文に書くということが極めてしにくいのです。
• また、評価作業というものが、アルゴリズムの構築やシステム構築よりも簡単なものと誤解されているきらいがあります。
  そういった事情にために、実環境の問題の詳細について論文が書かれるのが少ないという状況があります。

このような理由もあって、性能評価の詳細についての記事が書かれることは少ないものです。しかしながら、機械学習の開発者、機械学習結果を含むライブラリの使用者は、学習後の性能に課題がないか疑ってかかる必要があります。トータルな視点で製品・サービスの中で外せないものをきちんと満たしているのかどうかの確認が必要になります。

機械学習の経験者は、機会学習の結果にどのような弱点を含みがちであるのかを知っている場合が多いです。

---

追記

機械学習の結果の品質への要求水準は高くなっている.

• 公平性

採用する技術の特性に照らし可能な範囲で、AIシステムの学習データに含まれる偏見などに起因して不当な差別が生じないよう所要の措置を講ずるよう努めることが望ましい。

総務省 AI開発ガイドライン及びAI利活用ガイドラインに関するレビュー②

それらをふまえた性能評価を開発していかなくてはならない。

ほしいのは検出ではない、検出後のactionがもたらす価値だ

一般物体検出は、既存のフレームワークを動作させるのは簡単だ。大学生でもできるだろう。
ここで大事なことは、ビジネスとして考えるときは、検出自体は価値をもたないということだ。
価値を持つのは、その後のactionがもたらす価値だ。

そのもたらす価値を担保することこそが、評価しなければならないことだ。

車両検出・歩行者検出

• ある条件の範囲では、ドライバーに対して適切なアドバイスをすることで、事故を未然に防げるといった価値だ。それにしたがって評価を構築していくことだ。

evidence please! (うまくいくことの証拠をください)

• 画像認識を多様なユースケースの中で性能が確保できていることの証拠を示すことは難しい。

  • そのため、マシンビジョンの中では、ユースケースの多様性を制御することになる。
  • 被写体とカメラの条件、照明条件を固定し、その限定された範囲では性能がでていることを確保しようとするアプローチだ。

• 検出が背景の影響を受けていないこと
  特に検出枠を求める物体検出は、背景の影響を受けやすいことが知られている。

• カメラの設置高さの範囲に十分な許容性があること。
  歩行車検出での人検出と天井に設置されたカメラからの人検出では、対象とするドメインが違うために、一方でドメインで学習した結果が他方のドメインでは性能が不十分なことが珍しくない。
  車載カメラでの人検出の場合でも、乗用車での人検出とトラックからの人検出では、カメラの設置高さが違うために、一方で性能が出ても他方で性能が出ないことが予想される。

• 特殊ケースとしてどれだけ考慮していますか？
  レインコートを着て、バックパックを背負って、キャリーバッグを引きずり、傘をさしているので、頭部が見えない人で、
  夜間で雨の中で、他の自動車による照明のために、見えにくくなっている人物の検出。

  通常の道路での人検出をしようとすれば、上記のような「特殊ケース」は、無視できない「特殊ケース」になる。

利用目的にそってバックアッププランを考えること

• 機械学習には、どうしても性能が出ないときがある。
• 制御された環境で工業製品をに対する分類・計測をするマシンビジョンとは違い、一般の環境で多様な被写体を入力とする機械学習では、性能がでないことがある。
• そのときに、生じる問題に対してシステム設計をしておくことが必要になる。

利用目的を達成するために他に使えるヒントはないか

• 例： 再現率は高く適合率は低いシステムの場合
  • ある判定が陽性であるか陰性であるかを、今までは全数を人が判定しなければならなかったとしよう。
  • それの検査で再現率は高く適合率は低いシステムがある場合には、陽性の判定のために人が判定しなければならない数を絞り込むことができる。
  • この場合には、前段の機械学習による判定に対するバップアップとして人がより精度の高い判定をしていることになる。
• 例： 前記のシステムの陰性判定が妥当であるのかの定期的な検査
  • 機械学習が陰性として判定した結果が間違えていると、それによって何らかの不利益を被る人が出てくる。
  • そのため、陰性と判定された結果を人が定期的に検証する必要がある。
  • そのような人によるバックアップであって、全体のシステムが信頼できるものになるだろう。
    　

例：　車線検出のアルゴリズムは、車線検出だけで十分だろうか。

• 利用目的を自動車専用道路に限ったとしても、それで十分だろうか。
• 道路に荷物が散乱していることを知るのは、どのセンサの責任だろうか。
• 路上の走行可能性を判断するのは、車線検出の機械学習の中で同時にするのは自然なことである。
• 割れたガラスが散乱しているかもしれない。
• そういった判定を同時に実現するアルゴリズムを構築する可能性も考えよう。

---

利用目的に応じて、評価基準自体をも疑うこと。

• 画像認識タスクの現状の評価基準が本当に適切なのか。
• 検出のタスクだと、小さすぎる対象を検出しようと検出しまいと、使い方によってはどうでもいい場合があるだろう。
• にもかかわらず、現状の大半の評価の場合には、「検出しなければならない」と「検出してはいけない」との間がない基準になっている。
  提案したい手法としては、小さすぎる検出枠は、検出しても検出しなくてもどちらでもよい条件にしたい。

顔照合ライブラリでの顔自動登録の性能評価

一定数の人数の人物(N人)が登場している動画での評価方法案

• 正解データのラベリングが不要であること。