機械学習では、データセットが重要であることを先に述べた。

機械学習のデータセットの重要性

しかし、そのデータセットとは実は容易に失われてしまいやすいことを述べておきたい。

データ取得と管理を軽んじる傾向

研究者・開発者とも自分の業績として着目される分野の作業に時間を使いたい。
すぐれたアルゴリズムを創りだして論文を書いて自分の業績を世界に認めさせたい。。
よくできた実装を創りだして、そのコードの作者としての業績を作りたい。
そういうものは、時間をかけたからといい結果にたどりつくとは限らない。研究者・開発者としての腕の見せ所だ。

それにくらべると、データの取得と管理は、そこまで業績として評価されることの少ないものだ。
「時間さえかければうまくいくんだろう」とか「他に〇〇のデータがあるんだから十分じゃないか」とか、
「原理的にうまくいくことを示したんだから、あとは現場の人間がデータを増やしてくれれば十分だ。」とか
そういった考えで、データの取得と管理は軽視されてきた傾向がある。

個人任せの学習データ

機械学習の実務の担当者は、既存の公開データベース（もしくは商用データベース）のデータだけで学習を行うことはない。
既存の公開データベースだけを用いて学習をするのは、もっぱらアルゴリズムの開発者だ。既存の公開データベースで、既存のアルゴリズムで学習を行なっても実用的な価値を生み出さないからだ（個人の能力の向上というのはあるが）。
だから、解決したい実際の案件を抱えている人は、その解決したい案件に対して、既存のアルゴリズム・既存の学習済みモデルが有効な結果になっているか、実用上十分な性能になっているかどうかを確認することから始めなくてならない。

そこでまっさきに、発生するのが、検討している案件での実際のデータでどうなるのかという問題だ。

この時点で、実務の担当者は、自分の抱えている案件での実際のデータを収集することから始めることになる。

データ取得のために支援のオペレータがいない状況で始まる。

ディスクが死ぬとなくなるデータ

実務の担当者に与えられ得るのは、なすべき課題の大きさに比べたら貧弱なマシン環境だ。
やむを得ず、外付けのHDDをいくつも接続して使うことになる。

ディスクのバックアップ環境など、実務の担当者が何も考えなくても面倒を見てくれるなんてことはなかった。
データのバックアップをとろうとするなら、自分で別のHDDにデータをコピーしておくしかなかった。
ミラーリングをするが十分ではなかった。

ずぼらな人間が実験データを管理する方法

学習データへの加工処理とデータの選択

収集したデータがそのまま機械学習の有効なデータになることはほとんどない。

収集したデータから学習に有効なデータを取捨選択する。
教師付き機械学習の場合、大量のアノテーション、正解データが必要だ。
- 実はアノテーションのルールをどう決めるかは、学習が成功するかどうかの鍵となる。
効果的な学習をさせるためのデータの加工処理
- 加工処理が加わることで、撮影・収集した直後のデータとは大いに違いを生じてくる。

成果物ができたあとには、関係者の関心が失われる。

次の開発に追われる実務担当者

最終成果物をつくったときのフルセットのデータについての記録が失われる。

NFSやNASで複数人で共有可能にしても解決しない

NFSやNASでファイルを管理すると、チームでのデータの管理ができるように思えるかもしれないが、そんなに話は簡単じゃない。
データは必要十分であって余計なものを残してはいけない。

あるいは、一人の人間がきちんと一貫して作業しても不十分である。
その担当者以外には、そのデータ構造とデータの有効な範囲がわからないかだである。

バージョン管理のしやすさへの支援の欠如

そう背景もあって、機械学習のデータのメンテナンスは、不十分な状況にあって、失われてしまいやすい。

データがバージョン管理されないため、その学習をした時のデータがはっきりしない。

データ処理に使用していたライブラリが、互換性を損なう変更を生じて、エラーを生じるようになる。

そのような状況になった時に、このプロジェクトのコードは壊れていると判断されるようになってしまう。
その結果、ライブラリのバージョンを固定していれば、動作したであろうプロジェクト一式が、壊れたプロジェクトと認識されるにいたって、もはや注意を向けられなくなって、放置され忘れ去られてしまう。

学習に使えるはずのまま、動作検証なしの引き継ぎ

今までの成果物を、だれかに引き渡すことがあるだろう。ただたいがいの場合、引き継ぎの際に、そのデータを用いて実際に学習されることは殆どない。たぶんうまくはずだ。しかし検証していない状況のままに放置されることが多い。そうしてしかも、そのデータの所在さえ忘れ去られていく。RAIDを利用したことはあるだろうか。RAIDでバックアップを復元したことはあるだろうか。私の場合、RAIDでバックアップを復元したことはない。「うまくいくはずだ」は後々に「何か必要な条件が不足して利用できない」と判明する。

組織としての学習データの活用の意識の欠如

ガチガチの管理は、社内で部署を移動しただけで、データの利用を不可能にする。

そのデータベースを作成した主要な開発者本人であっても、部署の移動はそのデータの利用を不可能にする。
そのことで、そのデータは利用者を失い、そのデータがあることさえも忘れられてデータは死滅する。

「同じ会社の中であったら、申請すれば利用を許可してもらえるんじゃない」
- そう思うかもしれないが、がちがちの管理が進んでしまった会社組織は、自分の評価につながらないリスクがあるかもしれないことを許可しようとしないのだ。
- あるいは、部署間ので、あるいは部署の中での相対比較で評価をあげようとする意識が強くなりすぎてしまった組織では、自分の特にならないことを許可してやろうなどとしないのだ。

個人情報保護に対する過度の反応

蔓延する事なかれ主義

顔画像は個人情報だという。ただすべての情報が、公開・部分的開示されることで、誰かしらの不利益を生じさせるものではない。
顔画像が単に顔画像だけでしかなく、名前とのひも付けもなく、撮影された状況に特別な意味もなく、そんな画像が大半だ。
そのようなときに、事なかれ主義で、一切の顔画像を利用できなくなるのは損失が大きすぎる。

"HOIP顔画像データベース" というのは、そのような失われてしまった顔データベースの一つです。

外部に対してあまく、身近な人にあまりにも厳しい態度

外部の組織が作成データにはあまく、身近な人がそれと同様なデータセットを作ることに対しては極端に厳しい人がいることがある。

学習結果だけにしか興味がなく、学習データに関心を持たない経営

（これは成功を継続している会社にはあてはまらない）
成果を上げたあとの開発者が軽視される。
- 開発者が去ったあとのPCのデータは引き継がれない。
- その分野の技術を改良する力を失ってしまう。
開発を再開しようとして、別の技術者を連れて来ても、過去の成果を上げた学習データを見つけることはできない。
- 探し当てる努力をしている暇があったら、自分でデータを取得したほうが早い。

あなたの開発目標を実現するために必要な要素技術はなんですか？

必要な要素技術が何かによって、それを実装・検証するためのデータセットが不可欠。
必要な要素技術の枠組みによって、必要なデータセットの構造が決まってくる。
再現可能な処理をしようとするならば、保存済みのデータへのオフラインでの動作検証は必須。
- それは、データセットを作るということ。

機械学習は、常に新しいプラットフォームを求めている。

より大量のデータを必要とする学習へ
過学習に陥りにくするための工夫が仕込まれているデータセット
既存のデータセットの長所と弱点とを知って新しいデータセットを作ろう。
- 静止画 or 動画
- 検出枠、セグメンテーション
- シーン分類・検出・追跡、などなど
- 隠れのある被写体の取り扱い
- アノテーションをつける対象
あなたの必要なデータセットは何？
- できるならば、標準的なデータの枠組みの方が再利用性が上がるのでうれしい。
- 標準的なデータ形式ならば、それを利用するソフトウェアは既にある場合が多い。

新しい学習の枠組みには、従来からのデータセットも大切

データセットを揃えることが、学習の最大のコスト要因

既存のデータセットの弱点を知っている。

既存データセットの新しい使い方

例：検出枠をつけることから、セグメンテーションのアノテーションへの変更
例：既存のデータ処理のアルゴリズムを利用することで、既存データに新しい属性を付与できる。

対策

学習とデータセットを分離しよう

学習プログラムは陳腐化しやすい。
学習プログラムは、ライブラリの変更で,そのままでは動作できなくなりやすい。
いいデータセットならば、学習プログラムと切り離しても価値をもつ。

可能ならばデータセットを公開しよう

可能ならばkaggle に登録しよう。

Google Driveの個人ドライブにデータ、ドキュメントを置かないようにしよう。

追記

エンジニアが去ったときに起こること

引き継がれないPCとHDD
- 同僚がそのデータを引き継ごうとしない。
PCからHDDが抜き取られ、倉庫に管理（死蔵される）
引き継いだはずのデータは、うまく引き継げてなかった。
- 退職時のデータ削除（ネットワーク上のストレージのデータ削除）で消えてしまう。
- 利用方法の手順がわからなければ、データだけあっても利用ができない。
データはCloud Storage にあるはずなんだけど、どれがそのデータなのかわからない。
- とくに、DVC(Data Version Control) してあるデータのClou Storage側のデータは、DVCを介せずに直接アクセスしても理解不能なデータでしかない。
- 誰が何のために用意したデータであって、どのリポジトリにあるプログラムの側からアクセスするようになっているのかを知ることができない。

エンジニアが立ち去る前にしておくべきこと

その学習用・評価用データセットを使う学習を社内の別のエンジニアに実行してもらう。
データの撮影からアノテーションし、学習用・評価用データセットへの追加を行う。
その再度、学習と評価を行う。
その作業を他のエンジニアに経験をしてもらう。
特にアノテーションルールの部分は、一度説明を聞いただけでは不十分なことがあり、経験者がアノテーションの修正を行い、どのような修正をしたのかを、アノテーションルールの文書に修正例として加えること。
そのような念入りな引き継ぎをしない限り、学習用・評価用データは生きたまま引き継がれることがない。

アノテーションルールも大事

機械学習のシステムへのデータの追加をする際には、アノテーションルールを引き継ぐことが大事だ。
引き継ぎ
- アノテーションルールを記載したドキュメント
- アノテーション済みの画像のアノテーションを見る方法。
- アノテーションを実際にしてもらって、不明点を従来のデータの管理者に聞いて、アノテーションへの不安を減らしていく。

チームそのものがなくなってしまえば、引き継ぎも何もあったもんじゃない。

ある会社のある開発チーム、論文に名前を連ねていた主要なメンバーがことごとく抜けてしまう。
それらの人たちが他の組織に移動していた。
おそらく、その開発チーム自体が崩壊してしまったのだろう。
そういう状況では、引き継ぎも何もあったものじゃない。
データが失われるだけではなく、ソースコードも、アルゴリズムへの理解もすべて失われたのだろう。
画像認識技術の進展に取り残された製品の状況が続いている。

花形の機械学習アルゴリズムと、軽視されるデータエンジニア

機械学習で着目されるのは、最新のアルゴリズムを使いこなしたり、それらの実装を高速化したりする部分だ。
データを構築する側については、軽視されがちである。
データの構築には、対象の学習についての理解や画像認識の特徴量についての洞察があるほど、良質のデータセットが構築できるということを、大多数の人は知らない。
データのアノテーションなんて、アルバイトに任せれば十分だと思っている人が大半だ。

学習を成功させるものは、データそれ自体の品質と量

一般物体認識の学習を成功させようとすれば、アルゴリズムの選択と、データそれ自体の品質と量のどちらだと思いますか。
アルゴリズムが一定以上の状況では、データそれ自体の品質と量　こそが、学習の成否の支配的な要因だ。
そのことがわかっているエンジニアは、データそれ自体の品質と量の充実を重視する。
しかし、そのあたりの事情がわかるはずのない人は、たいしたことができない人と見下すことになる。

学習用プログラムと学習データがあって、あとはデータの追加さえあれば、それだけで十分なのか。
　学習を本当に改善させようと思うなら、それだけでは不十分だと言っておきたい。
理由：

追加できる学習データには限りがある。
追加できる学習データの分布には限りがある。
しかも、ユースケースのデータと学習データにはドメイン間の違いがある。
そのために、対策を実施しなければならない。
https://www.mamezou.com/techinfo/ai_machinelearning_rpa/ai_tech_team/3
ドメイン適応の原理と応用
未検出・誤検出の特徴を探らないと、どう改善すべきかが見つけられれない

ちらばったドキュメントはどれがメンテナンスされているのかわからなくなる。

ドキュメントは、いろんな場所に置かれがちである。
- 例
- リポジトリの中のmarkdown ドキュメント
- Google Drive 上のスライドなど
- markdown で管理しているドキュメントサービス
プログラムを更新していくと、それにともなってドキュメントを更新する必要を生じる。
そのときに、ドキュメントの更新が追いつかないことがおこる。
メンテナンスが追いつかないと、手順をたどれなくなってしまって、利用ができなくなる危険がある。

追記(2021)：

機械学習のデータを失わせにくくする方法を見つけた。

明確な目的を明確にする。
そのデータを使って学習する・評価する方法をもgit で管理する。
学習プログラム自体とデータセットは別のリポジトリで管理する。
１つの明確な目的に対応するデータセットが巨大なデータセットになるときは、それをgit submodule を使って複数のリポジトリに分けて管理する。
アノテーションがなされていないデータは、そのままでは活用できないので、別のリポジトリで管理し、学習に使える状態のリポジトリには余計なファイルを置かない。
以上のgit submodule の活用方法は, 規模の大きな学習用データセットには git submoduleを使うに記載した。

追記(2022.08.23)

言語・ライブラリのバージョンアップに取り残される学習プログラム

自社での開発ライブラリは、絶えず言語・ライブラリのバージョンアップに取り残されないようしておかないと、動作しないライブラリになってしまう。開発ライブラリについては、自社開発の部分に変更がなくても、依存ライブラリのサポート状況によって、メンテナンスをし続けなければならないことを、多くの人が経験している。

しかし、学習プログラムは学習を実施したあとは、コードが放置されメンテナンスされなくなりがちだ。いざ、学習を更新しようと思ったときには、そのコードが想定していた依存ライブラリの仕様は変更になってしまっている。書き換えなければ動作しないのだ。
その書き換えについて、十分理解していないと、データが壊れたのか、アルゴリズムがおかしくなったのか、何がだめなのかわからず、その学習プログラムの使用を断念することも怒るだろう。

言語・ライブラリのバージョンアップに取り残される学習プログラムへの対策

docker環境を使うこと
そうすれば、ライブラリのバージョンの問題を避けることができます。

データの所在にたどり着けるか

設定：数年前に開発された機械学習に対して、学習アルゴリズムを置き換えた版の作成に、あなたが割り振られたとしよう。
その当時に機械学習を担当したエンジニアはもう会社にはいない。
その機能は、販売中の製品のなかで重要な機能を担っている。
しかし、標準的な学習済みモデルには、あなたの望んでいる機能はない。
どうしても、学習をやり遂げなくてはならない。

当時のドキュメントを見つけるところから始める。

報告書など当時のドキュメントには、データの名前とかが書いてあるだろう。
しかし、データセットがPCだけにあるのか、Google Drive やリモートストレージにあるのか、GitやDVCなどにあるのかは書かれていないことがある。
特にデータへのアクセス権限などの問題もあって、データへのアクセス方法までは、報告書に書いていない場合が多い。
学習プログラムのあるリポジトリ名は、書いて置こう。
- リポジトリ名は、ある程度落ち着いたら変更しないこと。
  − リポジトリ名は、データにたどりつくヒント

学習プログラムのリポジトリにたどりつけ

学習プログラムのリポジトリ内には、データの所在が書いてあるはず。
前任者が残してくれたdocを読もう。
そこに書いてあるデータのリポジトリ、もくしは、Google Drive, Cloud Storageを探そう。

機械学習モジュール・サービスには、「式年遷宮」が必要だ。

機械学習モジュールは、常にモジュールが古くなって利用できなくなる危険を含んでいる。
理由：
- 機械学習のためのフレームワーク・deploy用のライブラリが絶えずバージョンが変更になっている。
- そのため、ある時点での機械学習結果の重みファイルをシステムの中で使い続けることができない。
対策：
- 機械学習のデータと、その学習評価のデータをメンテナンスし続けること。
- 機械学習の担当者1名による作業ではなく、別の担当者に作業を実施させること。
- 自動化テストをメンテナンスし続けること
- システム技術の「式年遷宮」を社内でし続けていよう。
- 放置しがちな社内システムこそ式年遷宮していこう

追記：2023.08

学習データは、個々の学習プログラムよりも長生きする。
一般物体検出というタスクは、まだ引き続き改良を必要としている。
そのため、一般物体検出の学習用・評価用のデータは、データ形式を変えてでも長生きする。

機械学習システムにおける「技術的負債」とその回避策

機械学習：技術的負債の高金利クレジットカード