JP7281427B2 - 情報処理システム - Google Patents

Description

本発明は、情報処理システムに関する。

従来より、様々な分野で機械学習が利用されている。機械学習とは、具体的に、複数のデータを用いて反復的に学習し、そこに潜むパターンをコンピュータが見つけ出すことができる。そして、機械学習を利用した技術が提案されている（例えば特許文献１参照）。

特開２０１６－１９２００７号公報

しかしながら、上述の特許文献１に記載の技術を含む従来技術のみでは、データの収集状況に応じてモデルを更新したり、様々な実行環境で動かすという運用が困難であった。

本発明は、このような状況に鑑みてなされたものであり、機械学習のモデル管理を容易にすることを目的とする。

上記目的を達成するため、本発明の一態様の情報処理システムは、
学習データを入力するデータ入力手段と、
学習方法を入力する学習方法入力手段と、
前記データ入力手段により入力された所定の前記学習データと、前記学習方法入力手段により入力された所定の前記学習方法の組を選択する学習条件選択手段と、
前記学習条件選択手段により選択された前記学習データを含むデータ又は学習方法の少なくともいずれか一方を用いて学習を実行する学習手段と、
前記学習手段により実行された学習の結果の採用又は不採用を決定する採用決定手段と、
推論方法を入力する推論入力手段と、
前記採用決定手段により採用が決定された前記学習の結果と、前記推論入力手段により入力された前記推論方法とを組にしてモデルバージョンとし、前記モデルバージョンを１つ又はそれ以上を、管理するタスク毎に用意するモデル管理手段と、
前記モデル管理手段に紐づいた実行選択手段であって、当該モデル管理手段の管理するモデルバージョンと実行環境を選択する実行選択手段と、
前記実行選択手段により選択された前記実行環境において、前記実行選択手段により選択された前記モデルバージョンを実行させる実行選択手段と、
を備える。

本発明によれば、機械学習のモデル管理を容易にすることができる。

本発明の情報処理システムの一実施形態としての機械学習管理運用システムのハードウェア構成を示すブロック図である。 図１の機能的構成の一例を示す機能ブロック図である。 学習ジョブ進行状況確認画面の一例を示す図である。 学習ジョブ進行状況確認画面の図３とは異なる例を示す図である。 学習ジョブ進行状況確認画面の図３及び図４とは異なる例を示す図である。 モデルのバージョン管理画面の一例を示す図である。 モデルのバージョン管理画面の図６とは異なる例を示す図である。 モデルのバージョン管理画面の図６及び図７とは異なる例を示す図である。 モデルのバージョン管理画面の図６乃至図８とは異なる例を示す図である。

以下、本発明の実施形態について、図面を用いて説明する。

図１は、本発明の情報処理システムの一実施形態としての機械学習管理運用システムのハードウェア構成例を示すブロック図である。
機械学習管理運用システムは、サーバとクライアント等ネットワークを介する複数台の情報装置により構成される実施形態等、各種各様な実施形態を取ることができる。ただし、以下説明の便宜上、本実施形態では、機械学習管理運用システムは、図１に示す情報処理装置で構成されるものとして説明する。

情報処理装置１は、ＣＰＵ（Ｃｅｎｔｒａｌ Ｐｒｏｃｅｓｓｉｎｇ Ｕｎｉｔ）１１と、ＲＯＭ（Ｒｅａｄ Ｏｎｌｙ Ｍｅｍｏｒｙ）１２と、ＲＡＭ（Ｒａｎｄｏｍ Ａｃｃｅｓｓ Ｍｅｍｏｒｙ）１３と、ＧＰＵ（Ｇｒａｐｈｉｃｓ Ｐｒｏｃｅｓｓｉｎｇ Ｕｎｉｔ）１４と、バス１５と、入出力インターフェース１６と、出力部１７と、入力部１８と、記憶部１９と、通信部２０と、ドライブ２１とを備えている。

ＣＰＵ１１及びＧＰＵ１４は、ＲＯＭ１２に記録されているプログラム、又は、記憶部１９からＲＡＭ１３にロードされたプログラムに従って各種の処理を実行する。
ＲＡＭ１３には、ＣＰＵ１１又はＧＰＵ１４が各種の処理を実行する上において必要なデータ等も適宜記憶される。

ＣＰＵ１１、ＲＯＭ１２、ＲＡＭ１３、及びＧＰＵ１４は、バス１５を介して相互に接続されている。このバス１５にはまた、入出力インターフェース１６も接続されている。入出力インターフェース１６には、出力部１７、入力部１８、記憶部１９、通信部２０、及びドライブ２１が接続されている。

出力部１７は液晶ディスプレイ等で構成され、各種情報を出力する。
入力部１８は、各種ハードウェア鉛等で構成され、各種情報を入力する。
記憶部１９は、ＤＲＡＭ（Ｄｙｎａｍｉｃ Ｒａｎｄｏｍ Ａｃｃｅｓｓ Ｍｅｍｏｒｙ）等で構成され、各種データを記憶する。
通信部２０は、インターネットを含むネットワークＮを介して他の装置との間で行う通信を制御する。

ドライブ２１は、必要に応じて設けられる。ドライブ２１には磁気ディスク、光ディスク、光磁気ディスク、或いは半導体メモリ等よりなる、リムーバブルメディア３１が適宜装着される。ドライブ２１によってリムーバブルメディア３１から読み出されたプログラムは、必要に応じて記憶部１９にインストールされる。またリムーバブルメディア３１は、記憶部１９に記憶されている各種データも、記憶部１９と同様に記憶することができる。

図２は、機械学習管理運用システム（図１の情報処理装置１）の機能的構成の一例を示す機能ブロック図である。

図２の情報処理装置１のＣＰＵ１１やＧＰＵ１４においては、学習データ入力部１０１と、学習方法入力部１０２と、学習条件選択部１０３と、学習部１０４と、採用決定部１０５と、推論入力部１０６と、モデル管理部１０７と、実行選択部１０８と、実行実施部１０９とが機能する。
また、図１の学習処理装置の記憶部１９においては、学習データが記憶される学習データＤＢ２００と、モデルの各バージョンが記憶されるモデルＤＢ３００及びモデルＤＢ４００と、実行環境データが記憶される実行環境データＤＢ５００とが設けられる。

学習データ入力部１０１は、例えば学習対象を被写体に含む画像及びその学習対象に関する情報を含むデータ等学習に用いるデータ（以下、「学習データ」と呼ぶ）を入力する。学習データは、学習データＤＢ２００に記憶される。

学習方法入力部１０２は、学習方法を入力する。

学習条件選択部１０３は、所定のデータ（学習データＤＢ２００に記憶された１以上の学習データのうち、ユーザにより選択されたデータを含む）と学習方法の組を選択する。

学習部１０４は、学習条件選択部１０３により選択されたデータ又は学習方法の少なくともいずれか一方を用いて学習を実行する。

採用決定部１０５は、学習部１０４により出力された学習結果の採用又は不採用を決定する。

推論入力部１０６は、推論方法を入力する。

モデル管理部１０７は、採用決定部１０５により決定された学習結果と、推論入力部１０６により入力された推論方法を組にしてモデルバージョンとし、前記モデルバージョンを１つ又はそれ以上を管理するタスク毎に用意する。
即ち、図２の例では、モデルＤＢ３００やモデルＤＢ４００の夫々は、所定の１つのタスクについて、１つ又はそれ以上のモデルバージョン（図２の例ではいずれも３つのモデルバージョン）を記憶する。そこで、モデル管理部１０７は、このようなモデルＤＢ３００やモデルＤＢ４００等のタスク毎のモデルＤＢを用いて、各モデルバージョンをタスク毎に管理することもできる。

モデル管理部１０７に紐づいた実行選択部１０８は、当該モデル管理部１０７の管理するモデルバージョンと実行環境を選択する。

実行実施部１０９は、実行環境において前記モデルバージョンを実行させる。

このように、本発明が適用される機械学習管理運用システムは、次に示す課題を解決することができ、その結果として、次に示す効果を奏することができる。
即ち、データの収集状況に応じてモデルを更新したり、様々な実行環境で動かすという運用が従来大変であったという課題が存在した。
本発明が適用される機械学習管理運用システムは、モデル管理の容易化を図ることができるため、このような課題を解決可能である、という効果を奏することができる。

換言すると、本発明が適用される機械学習管理運用システムは、タスク毎の学習結果のバージョンと、実行環境の両方をクラウド上で一元的に管理することができるので、このような課題を解決可能である、という効果を奏することができる。

機械学習はそれ自体が利益を生み出すものではなく、導入現場で施策を打ったりして効果検証をすることが重要である。即ち、機械学習自体の精度は参考程度の情報である。ここで、バージョンと実行環境を対にして管理しておくことで、機械学習のどのモデルが、実際にどのように顧客の価値につながったかが紐付けられる。前記参考程度の情報しか分からないバージョン管理機構と、実行環境を選択する機構の夫々が有している個別の効果からは、直接的には上記効果は類推できるものではなく、これらが有機的に結びつくことによってはじめて、上記効果は実感できるものである。

図３は、学習ジョブ進行状況確認画面の一例を示す図である。
図３の例の学習ジョブ進行状況確認画面は、図１の出力部１７に表示される。なお、この点は、後述する図４の例及び図５の例でも同様である。
ユーザは、図３の例の学習ジョブ進行状況確認画面を用いることで、学習部１４（図２）で実行される学習についてのひとつの学習定義（Ｊｏｂ Ｄｅｆｉｎｉｔｉｏｎ）にたいして、複数の学習ジョブの夫々を相互に独立して個別に実行することができる。
ここで、学習定義は、例えばＶｅｒ.１１やＶｅｒ．１２等の複数のバージョンで管理されており、所定のバージョンの学習定義が上述の「ひとつの学習定義」に相当する。
学習ジョブには、学習部１０４で学習が実行される際に用いられるもの、即ち、学習条件選択部１０３により選択されたデータ又は学習方法の少なくともいずれか一方が含まれている。
ユーザは、図３の例の学習ジョブ進行状況確認画面を用いることで、複数のジョブの夫々について、「ステータス」、「コメント」、「実行ユーザ」、「進行状況」、「対応する学習定義のバージョン」、「任意で定義した項目と数値」、「経過時間」、「実行開始日時」、「ジョブ実行時のログ」、「学習状況詳細確認」の確認、及び「学習結果のダウンロード」をすることができる。

図４は、学習ジョブ進行状況確認画面の図３とは異なる例を示す図である。
図４の例の学習ジョブ進行状況確認画面は、図３の例の学習ジョブ進行状況確認画面のうち下側の「Ｍａｉｎ」に相当するものであるが、図３の例とは異なる状況（実行ユーザがコメントを記載している状況）のものである。
例えば実行ユーザは、図４の例の学習ジョブ進行状況確認画面を用いることで、各学習ジョブの夫々にコメントを残すことができる。その結果、機械学習管理運用システム（図１の情報処理装置１）は、当該学習ジョブを実行した経緯や結果へのコメントを記録することができる。一定期間をおいてからの確認、又は実行ユーザ以外のユーザが学習ジョブを調査するときに有用である。

図５は、学習ジョブ進行状況確認画面の図３及び図４とは異なる例を示す図である。
図５の例の学習ジョブ進行状況確認画面は、図３の例の学習ジョブ進行状況確認画面のうち下側の「Ｍａｉｎ」に相当するものであるが、図３及び図４の各例とは異なる状況（実行ユーザがコメントを記載している状況）のものである。
ユーザは、図５の例の学習ジョブ進行状況確認画面を用いること（特に同図の太線枠で囲まれている箇所を視認すること）で、「任意で定義した項目と数値」、「ステータス」、及び「進行状況」の指標により、複数ある学習ジョブのうちからもっとも効果が高いと思われる学習ジョブを選択し、又は順序づけをして、それらを図１の出力部１７に表示する機能を機械学習管理運用システム（図１の情報処理装置１）に発揮させることができる。

図６は、モデルのバージョン管理画面の一例を示す図である。
図６の例のモデルのバージョン管理画面は、図１の出力部１７に表示される。なお、この点は、後述する図７の例及び図８の例でも同様である。
ユーザは、図６の例のモデルのバージョン管理画面を用いることで、モデル管理部１０７により管理されている（モデルＤＢ３００やモデルＤＢ４００等に記憶されている）モデルバージョンの更新履歴及び更新毎に使用したソースコードを管理できる。ユーザは、モデルバージョンの夫々の更新において、そのバージョン番号（Ｖｅｒｓｉｏｎ）及び、更新時のコメントを記録させることができる。ユーザは、コメントに、更新の経緯や、デプロイした結果のメモ等記録させることができる。

図７は、モデルのバージョン管理画面の図６とは異なる例を示す図である。
図７の例のモデルのバージョン確認画面は、図６の例のモデルのバージョン管理画面のうち右上の領域に相当するものであるが、図６の例とは異なる状況（ユーザが新たなモデルバージョンの作成を所望している状況）のものである。
ユーザは、図７の例のモデルのバージョン管理画面において、“Ｃｒｅａｔｅ Ｖｅｒｓｉｏｎ“のソフトウェアボタンを押下操作することにより、新たなモデルバージョン（モデルの新規バージョン）を作成することができる。

図８は、モデルのバージョン管理画面の図６及び図７とは異なる例を示す図である。
上述の図７の例のモデルのバージョン管理画面において、“Ｃｒｅａｔｅ Ｖｅｒｓｉｏｎ“のソフトウェアボタンの押下操作がなされると、図１の出力部１７に表示される画面が、図８の例のモデルのバージョン管理画面に遷移する。
ユーザは、図８の例のモデルのバージョン管理画面を用いることで、新たなモデルバージョン（モデルの新規バージョン）の作成（その指示操作）ができると共に、「バージョン番号（Ｖｅｒｓｉｏｎ）」や「利用する実行環境」の設定その他の設定を指定できる。

図９は、モデルのバージョン管理画面の図６乃至図８とは異なる例を示す図である。
図９の例のモデルバージョン管理画面は、図８の例のモデルのバージョン管理画面のうち下側の領域に相当するものである。換言すると、ユーザは、新たなモデルバージョン（モデルの新規バージョン）の作成（その指示操作）をしている際に、スクロール操作等をすることで、図１の出力部１７に表示される画面を、図８の例のモデルのバージョン管理画面から図９の例のモデルのバージョン管理画面に遷移させることができる。
ユーザは、図９の例のモデルのバージョン管理画面において、“Ｓｏｕｒｃｅ Ｃｏｄｅ”の下方の灰色の領域に対して、ソースコード（アイコン）をドラッグ＆ドロップさせる操作をするか、又は、選択ダイアログから該当ファイル（ソースコード）を選択する操作をすることができる。

以上、本発明の情報処理システムの一実施形態としての機械学習管理運用システムについて説明した。機械学習管理運用システムは、次の（１）のような情報処理システムに適用されたり、又は次の（２）乃至（１１）の夫々のような各種機能を有するようにすることもできる。
（１）クラウドでのモデル学習のデータを利用したＡＩコンサルティング推薦システム。
（２）学習結果と共にモデルのソースコードを独立して管理する機能。
（３）Ｓｕｐｅｒ Ａｗｅｓｏｍｅ Ｍｏｄｅｌ Ｐｌａｔｆｏｒｍ（ｓａｍｐ）の機能。
（４）モデル学習の達成度に応じた課金プランの機能。
（５）精度改善を保証したＢｌｕｅ／Ｇｒｅｅｎデプロイメントの機能。
（６）Ｗｅｂ ＡＰＩ（Ａｐｐｌｉｃａｔｉｏｎ Ｐｒｏｇｒａｍｍｉｎｇ Ｉｎｔｅｒｆａｃｅ）の確認用インターフェースを有する機能。
（７）同じモデルをデプロイメントという概念を用いて、用途毎に管理する機能。
（８）推論のリクエスト（生データ）と推論のレスポンス（推論結果）を自動保存的に保存する機能。
（９）推論結果に関しての可視化（モニタリング、グラフ化）、及びアラートの機能。
（１０）推論結果の可視化の機能。
（１１）推論結果の真値チェックの機能。

（１）クラウドでのモデル学習のデータを利用したＡＩコンサルティング推薦システム（以下、単に「推薦システム」と略記する）の特徴について、以下に記載する。
推薦システムは、クラウドのみで完結しているので、ユーザの行動履歴を把握できている。
例えば、これくらいのデータとこれくらいのカテゴリに対して、これくらいの精度しか出てないのはおかしい、となった場合に、推薦システムは、コンサルタントに相談しよう、とユーザに推薦することができる。
ユーザは、推薦システムを利用することで、ソースコードを解析して利用しているネットワーク等がわかる。
推薦システムは、チャットボットと比較しての独創性があるものである。
推薦システムは、そこから適切なコンサルティングを推薦できる。
推薦システムは、行動履歴に応じて、困ったポイントをあらかじめ理解した状態でコンサルタントに依頼を出すことができる。
推薦システムは、日本、インド、ＵＳ、世界各国に対応できる。

推薦システムは、機械学習／深層学習のノウハウがないと、学習を実行しても思ったように精度を達成できない、という課題を解決することができる。
その結果、推薦システムは、ユーザの行動履歴及びモデルの学習に用いるソースコードを解析することにより、適切なタイミングで適切なＡＩコンサルティングを推薦することが可能になる、という効果を奏することができる。

ここで、従来において、コンサルティングとのチャンネルを提供するチャットボットのようなソリューションがあったに過ぎない。これに対して、推薦システムは、クラウド上に保管された行動履歴やソースコードを解析した結果から推薦する仕組みを有するものである。

推薦システムは、機械学習／深層学習の需要にたいして、ノウハウをもつ企業は少ないため、効率的なコンサルティングの必要性は非常に高い、という基本性を有している。

また、推薦システムにおいて、コンサルティングとのコンタクトをとるためになんらかのチャンネル（Ｗｅｂインターフェースやメール等）は顕在化しているはずである。

次に、（２）学習結果と共にモデルのソースコードを独立して管理する機能（以下、「機能（２）」と呼ぶ）について説明する。

機能（２）の特徴について、以下に記載する。
従来において、ローカルでの開発だとディレクトリによる管理等、手運用になってしまう。
これに対して、機能（２）により、学習に使用したデータセット、コード、パラメータ、ログがバージョン管理されたモデルのソースコードがクラウド上で紐づけられている。
その結果、学習結果とソースコードを別管理できるので、ライセンスの問題を解決できる。
さらに、機能（２）は、ソフトウェア著作権とモデルの権利を分けて管理できる。

機能（２）は、モデル学習の結果として生成される成果物（ネットワークの重み等）と推論を実行するソースコードの権利関係は異なる可能性がある、という課題を解決することができる。
その結果、機能（２）は、モデル学習の結果として生成される成果物と推論を実行するソースコードを別々のコンポーネントとして管理することで、夫々に異なる権利／ランセンスを適用できる、という効果を奏することができる。

機能（２）は、利用者（ユーザ）である開発者の作成したソースコードと、クラウド上で生成された学習結果の権利関係を明確にすることはプラットフォームにとって重要である、という基本性を有する。

機能（２）は、ソースコードと学習結果の取り扱いを見れば分かる、という顕現性を有している。

次に、（３）Ｓｕｐｅｒ Ａｗｅｓｏｍｅ Ｍｏｄｅｌ Ｐｌａｔｆｏｒｍ（ｓａｍｐ）の機能（以下、「機能（３）」と呼ぶ）について説明する。

機能（３）の特徴について、以下に記載する。
機能（３）は、入出力データの前処理を利用者（ユーザ）から隠蔽して提供している。
機能（３）は、ユーザのプログラムと実行環境を独立にするための仕組みである。
機能（３）は、ＨＴＴＰ（Ｈｙｐｅｒｔｅｘｔ Ｔｒａｎｓｆｅｒ Ｐｒｏｔｏｃｏｌ）である。
機能（３）は、クラウド上でのイベント駆動できる。
機能（３）は、エッジデバイス上での実行できる。
機能（３）は、一ユーザとしての開発者の作業工数の削減ができる。

次に、（４）モデル学習の達成度に応じた課金プランの機能（以下、「機能（４）」と呼ぶ）について説明する。

機能（４）の特徴について、以下に記載する。
機能（４）は、機械学習クラウドオンリーの新しい効果を有する。
機能（４）は、学習結果に満足できない場合はコミットをしないことでコスト削減できる。
機能（４）は、学習に時間がかかる場合は延長できる。
機能（４）は、最終的にキャンセルすることもできる。

機能（４）は、機械学習／深層学習におけるモデルの学習については「どれくらいの時間」で「どれくらいの精度」が達成できるかが事前に予測困難であり、十分な精度が出ないうちはできるだけコストを抑えたい、という課題を解決することができる。

その結果、機能（４）は、次のような効果を奏することができる。
即ち、クラウドでのモデル学習において「オープン」と「コミット」という操作を以下のように定義するものとする。
「オープン」は、学習の開始を表すものとする。「コミット」は、学習を完了し、学習結果からモデルを作成することを表すものとする。
この場合、機能（４）は、モデル学習の課金を「オープン」時と「コミット」時に課金されるようにし、「オープン」時の価格を「コミット」時の価格よりも低く抑えることで、顧客（ユーザ）は学習が完了するまでのコストを削減することができる、という効果を奏することができる。

ここで、従来において、モデルの学習においては、インフラストラクチャーとして使用するＧＰＵの性能／利用時間によって課金するのが一般的であった。これに対して、機能（４）は、モデル学習の達成度を定義し、それに応じて課金する方式という新しいものである。

機能（４）は、機械学習／深層学習のモデル学習がクラウドにシフトする過程においては、ＧＰＵ１４を利用者が意識すること自体が陳腐化すると考えられ、ＧＰＵ１４に応じた課金体系は利用されなくなってくるはずである。

機能（４）は、課金プランを確認するという顕現性を有している。

次に、（５）精度改善を保証したＢｌｕｅ／Ｇｒｅｅｎデプロイメントの機能（以下、「機能（５）」と呼ぶ）について説明する。

機能（５）の特徴について、以下に記載する。
機能（５）は、ＵＩ（Ｕｓｅｒ Ｉｎｔｅｒｆａｃｅ）上で瞬時に切り替えることができる。
機能（５）は、ひとつ或いは複数のテストデータセットを各エンドポイントにリクエストとして送ることで、異なるバージョン間の精度比較ができる。
機能（５）は、精度比較は可視化されており、ベストなものをプライマリーとして選択できる。

機能（５）は、新しいバージョンのＡＰＩにアップデートするときは、以前のバージョンのＡＰＩよりも精度が改善されていることを確認した上で瞬時にアップデート（Ｂｌｕｅ／Ｇｒｅｅｎデプロイメントによるゼロダウンタイムリリース）したい、という課題を解決することができる。
その結果、機能（５）は、ＡＰＩのアップデート時に、同一のデータセットを用いて、現行バージョンと新バージョンの精度の比較をすることができる。比較結果を確認しながら、新バージョンに切り替えるかどうかを決定できる、という効果を奏することができる。

ここで、一般的なＷｅｂサービスとは異なり、機械学習／深層学習のＡＰＩにおいてはモデルの精度が指標として重要である。
機能（５）は、同一条件下における複数バージョンの精度比較結果をＢｌｕｅ／Ｇｒｅｅｎデプロイメントに用いることができる。

機能（５）は、上で述べたとおり、機械学習／深層学習のＡＰＩにおいてはモデルの精度が重要であり、一般的なＢｌｕｅ／Ｇｒｅｅｎデプロイメントだけでは十分ではない、という基本性を有する。

機能（５）は、ＷｅｂＡＰＩのデプロイ方法で確認できる、という顕現性を有する。

次に、（６）Ｗｅｂ ＡＰＩの確認用インターフェースを有する機能（以下、「機能（６）」と呼ぶ）について説明する。

機能（６）の特徴について、以下に記載する。
機能（６）のインターフェースは、入力画像と出力の比較のしやすさを維持しつつ、視認性を上げるために夫々の描画領域を独立させている。
機能（６）は、入力画像の加工ができる。
機能（６）は、アノテーションサービスと紐づいているデータレイクのファイルを入力等に使える。
機能（６）は、結果と比較もできる。
機能（６）は、出力結果を解析してｂｏｕｎｄｉｎｇ ｂｏｘを入力画像に重ねたり、出力を工夫できる。

機能（６）は、機械学習／深層学習モデルの教師データを含む入力と出力の結果が整合していることを、教師データと推論の結果の非構造化テキストデータを照合するのではなく、視覚的に確認したい、という課題を解決することができる。

その結果、機能（６）は、次のような効果を奏することができる。
機能（６）により、Ｗｅｂブラウザで利用可能な確認用のインターフェースが用意できる。
このインターフェースは、入力データ描画エリアと出力データ描画エリアの分かれており、夫々を独立してスクロール可能である。これによって、入力画像と出力の比較のしやすさを維持しつつ、視認性を上げている。
入力データとしては以下のデータ（ａ）乃至（ｃ）が利用可能である。
（ａ）プラットフォームに組み込まれたサンプル画像。
（ｂ）アップロードした画像。
（ｃ）データレイクに保存された画像と教師データ（非構造化テキストデータ）。
ここで、データ（ｃ）の教師データがある場合は、非構造化テキストデータを解析して、色分けされた矩形として画像に重ね合わせることで視認性を向上させる。
出力データとしては非構造化テキストデータ又は画像を推論結果として取得することができる。
その場合、画像の場合はそのまま描画する。また、非構造化テキストデータを解析し、色分けされた矩形として画像に重ね合わせる。
機能（６）は、これらのインターフェースを提供することができるので、入力と出力の比較が容易になるという効果を奏することができる。

機能（６）は、入力の教師データ／画像及びＡＰＩの出力の非構造化テキストデータを自動で解析して画像データとして描画するインターフェースは他に類を見ないものである。

機能（６）は、デプロイしたＷｅｂ ＡＰＩの確認を容易にすることは重要という基本性を有する。

機能（６）は、インターフェースなので確認可能という顕現性を有する。

次に、（７）同じモデルをデプロイメントという概念を用いて、用途毎に管理する機能（以下、「機能（７）」と呼ぶ）について説明する。

機能（７）は、店舗ごと、エッジ毎に分けられるという特徴を有している。

機能（７）は、同一のモデルを異なる用途に使い回したいが、用途毎に異なる設定やキャパシティを管理するのは困難である、という課題を解決することができる。
その結果、機能（７）は、あるモデルを複数のインフラストラクチャー上で実行でき、実行に必要なインフラストラクチャーの規模やプログラムの設定を「デプロイメント」という単位で管理できる、という効果を奏することができる。

機能（７）は、ＳａａＳサービス等では異なる要求に応じて、同一のモデルの性能や設定を変更する必要があるため重要である、という基本性を有する。

機能（７）は、開発者が設定するものなので分かる、という顕現性を有する。

次に、（８）推論のリクエスト（生データ）と推論のレスポンス（推論結果）を自動保存的に保存する機能（以下、「機能（８）」と呼ぶ）について説明する。

機能（８）は、推論して終了ではなく、後ほど推論結果が正しいのか確認するため、精度を向上させるための学習用データとして、その他精度向上させる用途として推論のリクエスト（生データ）と推論のレスポンス（推論結果）を自動保存的に保存する、という特徴を有する。

機能（８）は、次のような課題を解決することができる。
即ち、推論は、１００％の精度が出るわけでも、１００％正しいわけでもない。そのため、推論したデータと結果を確認しないと正しい精度を測ることができない。さらに精度を向上させるアクションも難しい。あとから精度をチェックするための仕組みが必要となる。
機能（８）は、このような課題を解決することができるので、推論した結果を自動的に保存することで、あとから簡単に精度のチェックができる、という効果を奏することができる。

次に、（９）推論結果に関しての可視化（モニタリング、グラフ化）、及びアラートの機能（以下、「機能（９）」と呼ぶ）について説明する。

機能（９）は、推論した結果の精度が意図した基準を満たしているのかグラフ化し、満たしていない場合はアラートを送信する、という特徴を有している。

機能（９）は、次のような課題を解決することができる。
即ち、推論を行う外部環境で一定水準を満たさないケースが起こりうる。例えばカメラで人数カウントを行う場合、カメラ設置環境の証明を変えるだけでも精度に大きく関わり精度が下がる場合がある。その場合は異常検知して対処する必要がある。
機能（９）は、このような課題を解決することができるので、異常にいち早く検知し、対処することができる、という効果を奏することができる。

次に、（１０）推論結果の可視化の機能（以下、「機能（１０）」と呼ぶ）について説明する。

機能（１０）は、画像を推論した結果、この画像は何と分類したのかというラベルと画像をサムネイル表示できる。分類以外に、セグメンテーションやバウンディングボックス等も対応する、という特徴を有している。

機能（１０）は、次のような課題を解決することができる。
即ち、推論した結果が正しいのかを数値では測れないケースにおいて、人の目で確認し精度をチェックする必要になる。確認しやすいようにデータの保存とデータのチェックが必要になる。
機能（１０）は、データのチェックを行うための開発やワークフローが不要になる、という効果を奏することができる。

次に、（１１）推論結果の真値チェックの機能（以下、機能（１１）と呼ぶ）について説明する。

機能（１１）の特徴について、以下に記載する。
即ち、推論した結果が正しいのかを数値では測れないケースにおいて、人の目で確認し精度をチェックする必要がある。推論した結果をサンプリングした一部のデータに対して人手のアノテーション代行を行い、真値をチェックする。

機能（１１）は、推論した結果が正しいのかを数値では測れないケースにおいて、どのように精度を確認するのか、という課題を解決することができる。
その結果、機能（１１）は、真値チェックするための人のアサイン、管理コストを下げることができる、という効果を奏することができる。

以上本発明の一実施形態について説明したが、本発明は、上述の実施形態に限定されるものではなく、本発明の目的を達成できる範囲での変形、改良等は本発明に含まれるものである。

例えば、上述した一連の処理は、ハードウェアにより実行させることもできるし、ソフトウェアにより実行させることもできる。
換言すると、図２の機能的構成は例示に過ぎず、特に限定されない。
即ち、上述した一連の処理を全体として実行できる機能が機械学習管理運用システムに備えられていれば足り、機械学習管理運用システムの構成は特に図１の例に限定されず、かつ、この機能を実現するためにどのような機能ブロックを用いるのかは特に図２の例に限定されない。また、機能ブロックの存在場所も、図２に特に限定されず、任意でよい。例えば、機械学習管理運用システムはサーバとクライアントとを含む構成としてもよく、この場合、図１の情報処理装置１の各機能ブロックをサーバ又はクライアントに分散させて移譲させてもよい。
また、１つの機能ブロックは、ハードウェア単体で構成してもよいし、ソフトウェア単体で構成してもよいし、それらの組み合わせで構成してもよい。

また例えば、一連の処理をソフトウェアにより実行させる場合には、そのソフトウェアを構成するプログラムが、コンピュータ等にネットワークや記録媒体からインストールされる。
コンピュータは、専用のハードウェアに組み込まれているコンピュータであってもよい。
また、コンピュータは、各種のプログラムをインストールすることで、各種の機能を実行することが可能なコンピュータ、例えばサーバの他汎用のスマートフォンやパーソナルコンピュータであってもよい。

また例えば、このようなプログラムを含む記録媒体は、ユーザにプログラムを提供するために装置本体とは別に配布される図示せぬリムーバブルメディアにより構成されるだけでなく、装置本体にあらかじめ組み込まれた状態でユーザに提供される記録媒体等で構成される。

なお、本明細書において、記録媒体に記録されるプログラムを記述するステップは、その順序に沿って時系列的に行われる処理はもちろん、必ずしも時系列的に処理されなくとも、並列的或いは個別に実行される処理をも含むものである。
また、本明細書において、システムの用語は、複数の装置や複数の手段等より構成される全体的な装置を意味するものとする。

以上を換言すると、本発明が適用される情報処理システムは、次のような構成を有していれば足り、各種各様な実施の形態を取ることができる。
即ち、本発明が適用される情報処理システムは、
学習データを入力するデータ入力手段（例えば図２の学習データ入力部１０１）と、
学習方法を入力する学習方法入力手段（例えば図２の学習方法入力部１０２）と、
前記データ入力手段により入力された所定の前記学習データと、前記学習方法入力手段により入力された所定の前記学習方法の組を選択する学習条件選択手段（例えば図２の学習条件選択部１０３）と、
前記学習条件選択手段により選択された前記学習データを含むデータ又は学習方法の少なくともいずれか一方を用いて学習を実行する学習手段（例えば図２の学習部１０４）と、
前記学習手段により実行された学習の結果の採用又は不採用を決定する採用決定手段（例えば図２の採用決定部１０５）と、
推論方法を入力する推論入力手段（例えば図２の推論入力部１０６）と、
前記採用決定手段により採用が決定された前記学習の結果と、前記推論入力手段により入力された前記推論方法とを組にしてモデルバージョンとし、前記モデルバージョンを１つ又はそれ以上を、管理するタスク毎に用意するモデル管理手段（例えば図２のモデル管理部１０７）と、
前記モデル管理手段に紐づいた実行選択手段であって、当該モデル管理手段の管理するモデルバージョンと実行環境を選択する実行選択手段（例えば図２の実行選択部１０８）と、
前記実行選択手段により選択された前記実行環境において、前記実行選択手段により選択された前記モデルバージョンを実行させる実行選択手段（例えば図２の実行実施部１０９）と、
を備える。

１・・・情報処理装置、１１・・・ＣＰＵ、１４・・・ＧＰＵ、１０１・・・学習データ入力部、１０２・・・学習方法入力部、１０３・・・学習条件選択部、１０４・・・学習部、１０５・・・採用決定部、１０６・・・推論入力部、１０７・・・モデル管理部、１０８・・・実行選択部、１０９・・・実行実施部、２００・・・学習データＤＢ、３００,４００・・・モデルＤＢ、５００・・・実行環境データＤＢ

Claims (1)

1. 学習データを入力するデータ入力手段と、
   学習方法を入力する学習方法入力手段と、
   前記データ入力手段により入力された所定の前記学習データと、前記学習方法入力手段により入力された所定の前記学習方法の組を選択する学習条件選択手段と、
   前記学習条件選択手段により選択された前記学習データを含むデータ又は学習方法の少なくともいずれか一方を用いて学習を実行する学習手段と、
   前記学習手段により実行された学習の結果の採用又は不採用を決定する採用決定手段と、
   前記採用決定手段により採用が決定された前記学習の結果を含む情報をモデルバージョンとし、前記モデルバージョンを１つ又はそれ以上を、管理するタスク毎に用意するモデル管理手段と、
   を備える情報処理システム。

Images