CNTKをC#で、ふたたび ― 2019年12月02日 18:10
CNTKを用い、機械学習のうち、CNNを学んでみようとして、データを用意しては、学習しない、を繰り返し、途中、サイクリングや読書に逃避しつつ、ずいぶんと時間を費やす。結局、敷かれた道を歩むのが最短だったか、と今さら気づく。
最初は、木や土、といった漢字の構成要素を識別できないか、と試みる。ラベリングしたデータは4000ほど。さっぱり学習が進まない。
漢字の構成要素は、画面のあちこちに現れる。これは、場所を特定してから識別しなければいけないか、と、もう少し簡単なデータを探す。手元に、Webで公開されている、もっとらぶらぶ作戦です、のPDFがあったので、顔の部分を切り出して、ラベリング。1500ほど。こちらも、学習が進まない状況は変わらず。
うまくいかないのは、データの不備か、学習プログラムのせいか、アルゴリズムを追えばよいわけではないので、切り分けが難しい。基本に戻って、MSのTutorialにある手書き数字の識別の例題を実装。ところが、ここでも学習は進まず。
C#のAPIの方は、巷の情報も少ない。さらに戻って、Pythonの例題を実装。Visual StudioにPythonの環境も実装されたので、あわせて試す。文法解析などはしてくれるが、C#ほど親切ではない。データを変換する処理を動かして、出力ファイルを比較して、問題の所在が判明。自前のデータ生成処理に不具合があった。
処理を修正して、データを出力し直し、C#の例題にあるコンソールアプリを動かす。MLP(Multi Layer Perceptron)の方は、誤識別率5%程度を達成。
CNN(Convolutional Neural Network)の方は、誤識別率2%程度と、もう少し優秀。
自前の学習プログラムで改めて確認。同じように学習が進むことを確認。
漢字の構成要素やらぶらぶ作戦の顔データで試してみると、誤識別率は、実用に耐えるほどではないが、改善する傾向を見ることができた(50%を切るくらいまで)。この2例では、MLPの方が、学習の進みが早い。手書き文字の例題の傾向とあわせてみると、MLPでデータの有効性(学習性向)を把握して、CNNに進む方がよさそう。
総括すると、CNTKを学ぶ道筋は、素直にPythonの環境で、既知のデータを用いて、データと処理ロジックを確認した上、C#のアプリ実装に進み、自前のデータに進む、という段取りが確実。そうすれば、学習アルゴリズムの選択や、Neural Networkの試行錯誤に集中できる。今回は、今さら新言語をと、Pythonを迂回しようとしたのが誤り。
新調したGPU。MLPでHidden Layerが200層、CNNで最大フィルタ数が16、画像は64x64ピクセル。これで、GPUのメモリ使用量が1.5GB弱(ブラウザが使う分を含む)。以前の0.5GBのQuadroでは不足だったはず。今度は、4GBあるので、もう少し試せそう。
問題はこの先。十分な学習に必要なデータ数は、かなり多め。個人の関心の向く中で用意するには、どうしたものか。大きな組織に属するもの以外には、お呼びではないのか。
興味の向くようなデータを公開してくれる組織が増えないと、例題のその先に進む学習者は増えない。逆にゲームやコンテストのノリで募れば、面白くもなりそう。くずし字のプロジェクトは、そのいい例かも。
上野東照宮、秋葉原アトレ、神田クリスティ ― 2019年12月06日 13:18
上野から、東京駅に抜ける。
動物園のそばを北側に抜けると上野東照宮。お膝元を忘れていた。
参道から五重塔。紅葉、黄葉を写真に収める人が多数。
金色殿。
来た道を戻ると脇に伊豆栄。雰囲気のある建物。
動物園脇には咲き誇るつわぶき。
PCショップで買い物の後、秋葉原のアトレ。まちカドまぞくとコラボ中。2階にグッズショップ。
万世橋を越えて神田。駅前の郵便局を目印に、クリスティ。早川書房の一階。
店内は、ホームズフェアの余韻を残す。許可をいただいて壁の展示を何枚か。
ポートレートは、ジェレミー・ブレット。
夕食時間帯の少し前。カレーといきたいところ、この後の予定を考えてパンケーキ。ホームズに囲まれて、ホームズを読む。しばらくすると、関係者らしきお客さんが裏口から入ってきて、打ち合わせのようす。編集者や翻訳者になった気分を少々。
秋葉原アトレで買ったピンバッジは、シャミ子。ポンコツとのご託宣。
東京駅。いつもながら見事な夜景。植え込みにはここにもつわぶき。
印旛沼、八千代 ― 2019年12月10日 19:52
印旛沼から、道の駅やちよ。いつものコース。
佐倉のふるさと広場は、花壇の入れ替え中。
花の少ないこの時期の楽しみは、野鳥。新川沿いには、この時期になるとオオバンが集う土手がある。陽が差すと、集団ひなたぼっこが微笑ましい。
道の駅やちよのリニューアルした食堂。今回の目当てはここだったが、火曜日定休。間が悪い。
川向かいの農業交流センターに向かうが、こちらの食堂も火曜日定休。向かいのお弁当屋さんで大根の葉を炒めたおかずのごはんと、キャベツメンチで昼ご飯。キャベツメンチは、野菜たっぷりの餃子の具を丸めてフライにした感じ。メンチとは名付けられているが、酢醤油が合いそう。
AzureでVisualStudio ― 2019年12月20日 14:33
VisualStudio Onlineの提供も近々ということだが、AzureのVMで動かせば、今の時点でもフルの開発環境を用意できる。出先で使うのもいいし、自宅のPCを軽めにしてこちらを使うことも考えていい。MSDN Professionalの契約があれば、月に6000円分使用できる。使い勝手と費用はどんなものか。
AzureのポータルからMarket Placeを探すと、VS2019設定済みの環境がある。インストール中も費用はかかるので、手間は少ない方がいい。対象は、Community Editionを選ぶ。Enterprise Editionは、MSDN Professionalの契約には含まれないので注意。ここを間違えて、作り直し。
Market Placeで選んだ環境をもとに、仮想マシンを作成。自前の環境では、メモリ6GBくらいを消費するので、7GBの設定を選択。費用を考えて、CPU少なめ、米国中部を選ぶ。
セキュリティのため、自宅の固定IPからのみの接続を許可する設定を追加。追加の費用が必要な設定を推奨されるが、パス。自宅外から接続するときは、少々まどろっこしいが、一度、VPNで自宅の環境に入ってからつなぐことにする。
仮想マシンを起動。CPUは、Xeon E5-2673v4。Intel ARKには掲載がない。大口顧客向けの製品か。2016年頃の20CoreのCPUらしい。場所と環境により、この辺りは変わる。
VS2019を起動。実際は、日本語環境のための追加インストールを行った後。Azure DevOpsのリポジトリに接続し、作業中の環境をそのまま再現。IMEの設定をさぼったので、日本語は入力できない。Market Placeの環境は英語なので、使い勝手をよくするには、色々追加の設定は必要。
一時間ほど、コーディングをして、最後に、Buildして動作確認。CPU使用率が前半高いのは、OSのIndex作成が走っていたもよう。米国西部と遠いが、操作感はふつう。大きなウインドウを掴んで動かすときに、少々もっさりするくらい。作業を終えたら、仮想マシンを停止して、ストレージ以外の資源を解放。止めないと課金がつづく。ディスク上に領域を確保する分の費用にとどめる。
日をまたいで、作業当日の費用。1時間ほどの作業でCPUは、20円から30円くらい。ストレージは、使っていない日は一日100円くらいだが、なぜかこの日は少なくなっている。
コスト分析で1ヶ月分の費用予測。未作業の月の実績は3000円くらいなので、上述の軽作業なら、一時間あたり20~30円くらい増える計算。日に4時間30日で、3000円くらいか。MSDNの6000円のクレジットがあれば、まかなえそう。
開発用途の高スペックのPCなら、20~30万円。5年以上使うと、月額5000円を大きく下るので、自由度を考えても、自前のPCの方がお得。とはいえ、この先、Azureの性能が上がり、費用が下がれば、自由度以外は、クラウド環境の方が便利になるのかも。既存のアプリのメンテや、ちょこっとプログラミングだけなら、いまでも十分。ちょうど分岐点の時期。
VisualStudio Onlineすこしだけ ― 2019年12月21日 09:57
Azure上のVisualStudioで作業した日の課金。Storageの金額が少なくなっていると書いたが、翌々日に確認すると、100円ほどとこれまでと同水準に。VMとStorageと集計のタイミングが少しずれるよう。
さて、VisualStudio Online。まだ、GUIのエディタはなし。接続できるリポジトリもGitのみ。環境をつ作って、ひととおりできることを確認して、削除した後の画面。Azure DevOpsとつなげられなかったので、コードを持って来れず。こちらはブラウザだけでも利用できる。
Azureに戻って、課金状況を確認すると、ちゃっかり、VisualStudio Onlineも課金。環境をつくって、メニューをひととおり確認して6円強。説明を見る限り、一日4~5時間ほど開発作業をして100円くらいになりそう。価格水準は、AzureでVisualStudio環境を用意するのと同じくらいか。
CNTKで生成したモデルをWindows MLで使用したいが ― 2019年12月23日 09:08
自前のデータによる学習も少し進捗してきたところで、できあがったモデルが使い物になるか試そうと、Windows MLでアプリを用意しようと試みる。
Windows MLで取り込めるのは、ONNXフォーマットのモデル。CNTKのSaveのAPIによると、ONNXフォーマットの出力もできそうだが、C#のライブラリは非対応。簡単なPythonプログラムで変換。
変換したONNXをプロジェクトに取り込むと、Windows Machine Learning Code Generatorがコードを自動生成してくれる。
自動生成されたクラスを用い、アプリを書いてみるが、読み込みで例外発生。Opsetのバージョンの未対応。CNTK2.7で出力したもののバージョンは9。Windows MLが対応しているのは7と8。これも、簡単なPythonプログラムを書いて変換。この機械学習の世界、発展中ということもあって、ツールやフォーマットの不整合があちこちに。
もう一度、アプリを動かすと、読み込みは通るが、LearningModelSessionのEvaluateAsyncで例外。XとWの配列数が不一致、というが。
ONNXモデルの中身をみる必要が生じ、WinMLDashboardをインストールして確認。
DashboardのEdit/Viewボタンを押し、最初のConvのNODE PROPERTIESのInputsをみる。
Xの型は float32[Sequence, 1, 1, 64, 64]。
Wの型は、float32[4, 1, 3, 3]。
Xは5つ、Wは4つ。例外のメッセージはこれのことか。
WinMLはConv非対応かと思ったが、例題に出てくるMNISTのモデルをダウンロードして、確認してみると、Convを使っている。ただし、InputsのXとWの配列の数は4つで合っている。CNTKのSaveでこの辺りを制御するパラメータはない。
Dashboardの画面の最初に戻って、MNISTのモデルを生成したCNTKのバージョンをみると、2.5.1。少し古い。
自前のアプリで使用するCNTKの最新版2.7では、ONNXの拡張されたデータ型 (Sequence) に対応しており、それに準じた出力をしている。他方、Windows MLでは、そこまでの対応に至っていない、そんな事情と推察する。
今さら、古いバージョンのCNTKを使うのも?なので、Windows MLによるアプリは保留。WPFなら、CNTKのC#のAPIが使えるので、そちらで検証を進める。
坂田ヶ池、竜ヶ崎、小貝川、印旛沼 ― 2019年12月24日 18:42
しばらくぶりにすっきりした天気。竜ヶ崎方面に出掛ける。
房総のむらの少し手前、坂田ヶ池。水面に突き出た枝にたわわになる鴨。慣れていて近づいても慌てない。
安食を抜けて利根川サイクリングロード。筑波山を望む。
通りがかりの人に声をかけられて振り向くと富士山。冬の澄んだ空気ならでは。
若草大橋を渡って竜ヶ崎市内。中央の通りを一本越えて般若院。
そのまま進んで中学校の手前に愛宕神社。正宗の子の代に建てられたもの。
階段を登ると社殿。社殿は柵で覆われており、よく見えない。それよりも裏手の大木が見事。
そのまま足をのばして、龍ケ崎市歴史民俗資料館。仙台領の石柱が立派。
表には、竜ヶ崎線をかつて走った4号蒸機。
こちらが今の竜ヶ崎線。佐貫と龍ケ崎の間を、一両が往復する。
入地駅までは、ほぼ線路と併走できる。合格祈願の黒板。ここで先ほどの車両が戻ってきた。
駅から南に抜けて小貝川。整備されたサイクリングロード。
利根川との合流地点。流れがよどむ辺りに水鳥が集う。
利根川を戻り、長門川に沿って南下。途中、豊年橋の架け替え工事。盛り土がされ、バイパスの準備。将来、栄と印旛日本医大の辺りを結ぶらしい。
長門川を抜け、印旛沼の北岸。見渡す限りの鴨。
市街に戻って、今日の猫。まだ、子猫。見渡すと3匹ほど視界を横切る。
プログラムで生成したデータで学習してみると ― 2019年12月26日 07:39
個人レベルでは、機械学習のデータが用意できないなら、作ってしまおう、とプログラムで生成するとして、それは、使い物になるのか。
漢字を構成する要素を、乱数をふんだんに配置して、プログラムで生成。これなら万単位のデータも用意できる。Win2DのCanvasPathBuilderで書いていく。
試しということで、CNTKで生成したラベル数が5のCNNのモデルを読み込み、検証。Windows MLが使えなかったので、アプリは、WPFで作成。C++のWrapperを用意してUWPにする手もあるのだけど。
ゴシックフォントの「木」を認識。評価関数は、学習した内容から、それである確率を数値化する。これを、右の一覧に表示。最大値のものを正答とする。
ゴシックフォントの「土」を認識。そこそこ。
明朝フォントの「土」を認識。「土」と「木」の判定数値が接近している。学習データがゴシック様のものであることが影響するか。
他、「口」、「氵」などは、正しく認識。ただし、「亻」は、誤認識。形状が単純で不十分な学習に終わったか。
まだ、なんともいえないが、漢字フォントのようなかっちりしたものには、プログラムで生成したデータでもそこそこいけそうな感触。もう少し、先に進めてみる。
最近のコメント