はじめに
機械学習という表現は、人々の間に大きな誤解を引き起こしている。「コンピュータが勝手に機械学習をしてくれる」というものだ。大規模言語モデルを利用したデモンストレーションは、実に見事だ。だから、勘違いをしてしまう。
「あとは、人が学習用のデータさえ与えれば十分だ」というものだ。
しかし、実際には、そんな具合に単純ではない。
本当に起きていることは「機械学習という道具を使って」人が問題を解いているということだ。
ちょうど、多変量解析が勝手に問題を解くことはなく、「多変量解析という道具を使って」人が問題と解いているということだ。
深層学習から大規模言語モデルへと利用可能な道具が拡大していても、結局は「機械学習という道具を使って」人が問題を解いているということだ。(注１)
本文
ルールベースの時代
1980年代までのAIの開発は、多くがルールベースの実装だった。
数式処理システムなどは、人がルールを与えて実装を作っていた。そこには、機械が学習を行う要素は少なかった。
統計的な処理によってしきい調整を行うことはあったが、基本はルールベースの実装の時代だった。
線形のデータ解析については、統計的な手法が他変量解析の延長として実装が進んでいる。
時系列データ処理も進展を遂げている。
ニューラルネットワークへの期待と、当時の限界
- バックプロパゲーションなどの状況により、ニューラルネットワークへの期待があった。
- 当時は、それをものにすることができなかった。
- 理由：
- ハードウェアのリソースが限られていたこと
- 並列計算を高速に行うハードウェアがなかったこと
- 最適化が極小値に落ち込んでしまう問題や、初期値依存性の問題を解決できていなかった。
画像認識が本格化する以前
- 人が可能なことは、機械でも可能なはずだという信念
- しかし、人が自然にできることでも学習できなかった日々
Viola Jonesの顔検出の衝撃
- 特徴量デザインと統計的学習の勝利
Viola Jonesの顔検出は、機械学習による画像認識技術を、人々の生活を変える力となった。
Viola Jonesの顔検出にヒントを得たさまざまな変種は、ハードウェアのロジックにもなった。
- OpenCVでの実装の解説
Viola Jones の顔検出の優れている点は、
・時間がかかる判定処理を、早めに判定を打ち切れること重視したこと。
・一つでは、十分な判定ができないこと内容でも複数集めて判定すると、十分に尤もらしい判断で
対象の真の条件を満たしていないものを減らしていけるということ。
・そのように偽の条件を繰り返していけば顔と非顔を区別できる。
この時代の特徴としては、限られたCPUのリソースで実装であるという点だ。
見るべき候補の数を絞り込むことが目的ならば、
その他のタスクでも、似たような考え方は使えるはずだ。
GPUというリソースが使える状況になると、Cacscade型の識別器は使われなくなる。
理由：if文による分岐が多数あり、ループの回数も一定しないという仕組みが、
GPUによる並列処理の枠組みとなじまないため。
サポートベクターマシン（SVM）という強力な助っ人
- 統計的な処理による分類というアプローチに立ちはだかっていたのは、世の中を線形なモデルだけでは扱いきれないということだった。
- 線形に分離できない問題に対して、人々が臆病になり、行き詰まっていた時代があった。
- それを打ち破って希望の星となったものは、サポートベクターマシンだった。
- カーネルトリックという手法が、線形には分離できない問題に対して、変換後のより多次元の空間において、線形に分離できるという、魔法なような手法が登場した。
- その結果次のような手法が一般化した。
- 限られた領域の画像が、人であるのか否かを判定することを、学習用データとして準備する。
- 入力画像から、特徴量という数値を多数得る手法を人が作る（特徴量デザイン）
- その結果、歩行者検出が大幅に進歩した。
- その代表的な結果はHOG特徴量とSVMが使われている。
サポートベクターマシンは、機械学習タスクのいろんなものに応用が効く極めて汎用性の高いロジックだ。
しかも、誰にでも使えるようにインタフェースが洗練されたライブラリが例題付きで紹介されている。
機械学習を目指す人の最初に学ぶべき手法の一つとなった。
サポートベクターマシンは2GBの壁を超えて使いやすくなった。
サポートベクターマシンだと、学習用のデータをメモリに置いて計算する必要があった。
1990年代だと2GBのメモリの壁があった。
2000年代だと、2GBのメモリの壁はなくなり、もっと大量のメモリを使えるようになった。
そのこともサポートベクターマシンの利用を後押ししていた。
深層学習・YOLOの登場
- アノテーションさえ自力で頑張れば、カスタムデータで学習できる時代がやってきた。
深層学習は、それ以前の機械学習と違って、特徴量設計が不要になった。
また深層学習が普及したタイミングではGithubの利用も当たり前になっていた。
これらのことが、深層学習を誰にでもトレース可能な状況を作ってくれた。
物体検出タスクという枠組みの中では、しょせん同じタスク
機械学習は、同じタスクの範囲の中では、ある段階に達するとかなりうまくいきやすくなる。
データの準備とアノテーションが一番の重要な部分になる。
それは、物体検出という解決方法が見つかったタスクになっているからです。
（実は、細かいところをつつくといろいろあるのだが）
深層学習の物体検出タスクでは、まずネットワーク構造をいじるタイミングではない。
深層学習の物体検出タスクでは、ネットワーク構造の試行錯誤する時代は、数年で終わりを告げた。
学習をする際のデータの品質と量とが、学習結果の品質につながっていることに、多くの開発者が気がついていった。
自前のデータ拡張（data augmentation) をしていって、学習データの品質と量を高めていった。
それらの個人ベースの工夫は、OSSの学習プログラムの側へ取り入れられていった。
それが、YOLOのシリーズでは、どうやって、データのカバレージを増やすのかという方向に進化していった。
OSSで配布される中にそれらの工夫が入っていくことで、比較的少ない数でも学習がうまくいくようになっていった。
既知の問題を、異なるデータセットに対してドメイン適応するならば
それらの状況の結果、
- すでに学習が上手くいくことがわかっている問題で、ドメイン適応するだけの問題ならば、機械学習で失敗することも少なくなってきた。
そのため、既存のフレームワークを使って、解決するには、一定水準以上の機械学習エンジニアならば大丈夫だという状況になってきた。
学習データを減らすための試み
目的とするターゲットドメインにおけるデータの数を増やすのが難しいということは起こりがちです。
そのために、次のようなアプローチが取り組まれています。
それらを用いたうえでターゲットドメインのデータで学習を行うのがいいのでしょう。
Vision Transformer
画像認識タスクの土俵は、深層学習からVisionTransformer に移行した。
データが十分にそろっていて、アルゴリズムで勝負したいのならば、Vision Transformerが勝負どころだろう。
Vision Transformerは大規模言語モデルの一つなので、凄まじいほどのデータと学習用のマシンパワーがいる。
まずは、 Vision Transformer系の実装をhuggingfaceで調べてみることだろう。
Masked Auto Encoderの効果
物体検出タスクは、データ拡張や、Masked Auto Encoderの技術によって、
検出性能が全般に上昇している。特にMasked Auto Encoderを用いたTransfomer系の技術は
対象物の一部に隠れが生じているときでの検出性能の低下が改善された。
ほんの少し見えている画像から、元画像に近い画像が復元されているんだって、信じられるかい。
Masked Autoencoders Are Scalable Vision Learners
(Masked Autoencoders がうまくいくのは、並大抵じゃない規模のデータを使って学習しているからだ。
データ数が少ない分野では、fine tuningに留めるべきなのだろう。)
ロングテールの現象（出現頻度の低い現象）
しかし、出現頻度が少ないデータでは、性能が確保されていない状況も残る。
いわゆるSOTAの実装では、公開データセットになっている範囲においては、よい値を持っています。
しかし、ロングテールに属するような事例を集中的に解析してみると、精度がでていないことが露見する。
ロングテールの現象での学習の性能を引き出すには、工夫が必要だ。
機械学習のフレームワークが、勝手に解決してくれるわけじゃない。
機械学習が簡単に思えるのは、簡単に解ける実績がある範囲を使っているから
数万の機械学習のエンジニアは、簡単に解ける範囲を広げるように、努力を重ねている。
その結果がOSSとして実装されているから、Githubからcloneして自分の環境で利用できる。
簡単に解ける実績がある範囲から、少しでも逸脱したら、
自分の頭を使って、工夫を重ねていく。
論文発表の実装が、ほんとうに性能がでますか
- 論文発表の実装の多くは、その時点で共有されているデータセットの中での評価です。
- そのため、とても品質のよいテストデータになっていることが多い。
- 実際の利用の状況では、何らかの理由により性能がでないことが多い。
- 論文で評価しているデータセットでの僅かな性能の評価よりも、多様なデータセットでの安定性を気にすべきです。(注２)
その機械学習は適切に定式化できてますか
Q:運用において使えるはずのない入力を想定していませんか？
ターゲット漏えいを回避するには、ターゲットの成果の時点で不明なデータを除外します。以下のタイムラインは、患者が心臓疾患と診断されるかどうかなど（「ターゲット確認（target observed）」として記載）、診療結果を予測するときにターゲット漏えいを回避するプロセスを示しています。トレーニングデータセットを構築するとき、「ターゲット確認」の時点よりも前のタイムラインで発生するデータ（外来データ、検査法データ、診断テストデータなど）を含める必要があります。ただし、最初の心臓疾患診断よりも後に発生したテストや外来診療からのデータを含めてはいけません。これらのデータは、診断を考慮したうえで収集されたものであり、将来のデータにモデルを適用して予測を行うときには不明なものだからです。
推論の結果の品質を保証できるようにしようとした時点で、未知の新規タスク
- その推論が間違えたときの影響がどれくらいあるのか、その利用のされ方を考えましょう。
- 推論した結果が、ビデオの推薦ならば、間違えても影響は少ないでしょう。
- これが、手術が必要かどうかの判定ならば、判定の信頼度をあげるために、何をできるのか工夫の限りを尽くさなければならないことがわかるでしょう。
- もはや、既知のタスクの既知の解決方法だけではすまない領域になっているのです。
未知の問題に対して機械学習を使って挑む
上手くいくかがまだわかっていない未知の問題では、取り組む人の素質・力量が特に重要になる。
けして、既存のフレームワークを適応して、「うまくいきました。めでたしめでたし」にはならない。
そのままでは、うまくいかない部分がある。
どのように、何を工夫しなくちゃならないのかを、開発者が考えなくちゃならない。
アルゴリズムの改良は、どこから着手するか？
最小化問題としての定式化は適切だろうか
- 損失関数の中にある束縛条件由来の項は妥当だろうか
機械学習の多くは、損失関数の最小化問題として扱われる。
与えられる束縛条件によって、学習結果にどのような傾向があるのか、違いが生じるはずである。
さらなる改良のための知見は得られただろうか
もっと改良するためには、ネットワーク構造をどう改変したらいいというのがわかったら
いまこそネットワーク構造を改変するタイミングだ。
大規模言語モデルは、新規の問題を解決してくれますか？
大規模言語モデルは、「既にだれかが解決して結果をweb上に公開してある」から、それを見つけ出して返答をつくってくれます。かなりの日常のタスクは、「既にだれかが解決して結果をweb上に公開してある」のを参照すれば十分なことも多いから、大規模言語モデルは有用な結果を返してくれています。
「どういうコミュニケーションロボットを作れば、人によろこんでもらえるのか」などということに対して、大規模言語モデルに聞くなんて馬鹿げています。アンケート調査するのも違います。まだ存在していない未来に対して、マーケット・リサーチがあてにならないものです。
それは、開発者が、ユーザーのみなさんと一緒に見つけ出していくしかないものです。
大規模言語モデルは、ヒントにはなる。
「以下の書いたpythonスクリプトと同等な使い方ができるC++のコードをC++14以降の規格を使って書き換えてください。」
がかなり有用なコードを吐き出すのはすごいことだ。
しかし、実際に問題を解くのはあなただ。
その課題を解ける人になりましょう
- 依頼主が何を求めているのかを理解しましょう。
- 関係者と良好な関係を作りましょう。
- それぞれの分野のプロに尊敬を持ちましょう。
- その問題を解くのは、依頼主・関係者とあなたのチームです。
- どうやったら、その課題を解けるかチームで取り組んでいくことです。
- 何が課題なのか、どうやったら解決できるか対話し、チームづくりをすることです。
その課題を解ける人になるには、何が必要なのかを聞きます。
- 新しい問題を解くというのは、未踏破の山を登るようなものだろう。
- いままでも、多くの挑戦者が手がけ、ある程度の結果をだしてきたはずだ。
- その結果、どこまでたどり着けているのか、論文や現場での状況を見てみましょう。
- あなたの持っている装備で解決できるのはなんでしょうか
- あなたが今持っている装備では、どうにも解決できないものはなんでしょうか
- どうやって一緒に解けるようになっていったらいいのか、依頼者と一緒に考えましょう。
- 新規の問題を解くためには、あなた自身が変わっていく必要があります。
- 変わっていく自分を楽しみましょう。
目的は何
- 社会的に意義がある目的になっているか。
- 競合がよりよい実装を普及させてしまうと、その意義が変わってくる。
- 例：それでも開発を続けなければ、他所から買うのにしても言いなりになる未来しか残っていない。
- 実現可能性があるように、目的を十分に絞り込んでいるか
しかも、その成果の横展開の可能性がありますか。
そういった部分を確認しながら、その案件を確認します。 - いま一番の課題はなんですか
- 自分が期待される領域での一番の課題はなんですか
その案件を選ぶ、選ばないという選択肢がある状況ならば、その案件には意義がある、目的がしっかりしていることが大事です。
社会実装として成功するためのアプローチは適切ですか
- その開発が社会実装として成功するためには、以下の内容が必要でしょう。
- うまく機能することがわかっている範囲が十分にあること
- その範囲での需要が十分にあること
- 過大な期待による失望を生じさせないこと
既にわかっていること、できていること
- 作業を分析するための大前提です。
- 特許情報プラットフォームでその会社名で特許検索をしてみましょう。
- 官報決算データベースに会社名を入力すると、決算状況がわかる。非上場でも決算公告がある。
チーム内で既に足りている部分
- 既にどういうエンジニアがいて、どういう実績をあげているのか
- どういうデータ・セットができているのか
- ドメイン分野についての理解を高めていって、そのデータが十分に価値があるかどうかを身につける必要があります。
- どういう具合にデータ管理のフレームワークができているか
- 例：AWS
- どういうソフトウェアのフレームワークを使っているのか
- 例：PyTorch
いま一番の課題にどう取り組むことが求められているのか
新しく加わるあなたに期待されていること
この内容を確認しましょう。
- アルゴリズムに専念できるのか、データ取得・データ管理も担当範囲なのか
- その業務範囲では、どういった人と協力していくのが期待されているのか
- コードの開発だけでいいのか、マネジメントももとめられているのか
開発者であるあなたがしなきゃいけないこと
その開発が成功するための仕組みづくり
- その開発に関係する人々との良好な関係の構築
- 情報の共有のしくみ
- 開発成果の共有のしくみ
- チームとしての開発のしくみ
困った時に、他のメンバーの協力が期待できる仕組みづくりは大事。
いろんなアプローチを考えてみよう
- 最初に思いついたアイディアが一番いいとは限りません。
- いろんなアプローチを考えてみましょう。
- クラスタリング一つとっても、多数のアルゴリズムがあります。
- データ拡張にしてもいろんな手法があります。
- その技術分野でのコミュニティでヒントを探して見ましょう。
あまり早い段階で絞り込みすぎないことが大切だったりします。
勝手に進んでいく部分に上手にのっかろう
数万、数十万人の機械学習エンジニアがいる時代です。
技術分野によっては、あなたが開発しなくても勝手に改良が進んでいく領域もあります。
そういう部分については、OSSとして利用できるのならば、それに乗っかるのも手です。
あなたは、あなたにしかできない部分の領域の開発に重心をおくことができます。
注１： 最近では、大規模言語モデルを使って、大規模言語モデルの学習を人手を介することを少なくてして、結果を評価してまとめ上げさせることもされだしてきている。それでも、そのためのプロンプトを与えるのは人間である。
注２：いわゆるSOTAの実装が、実際のユースケースにおいてボロボロになることがある。それよりも、質の良いアノテーションデータを増やすことが、改善に寄与することがある。それを検出と属性推定の分野で示しているのが、以下の実装である。