Translate

2017年11月15日水曜日

TensorFlow Lite が発表された件

今朝のタイムラインには驚いた。



リンク先のブログ記事をとりあえず勝手に翻訳してみた。
以下、その翻訳文です。
#参照する人は at your own risk でお願いします。


-----

TensorFlow Lite を発表





本日、我々は TensorFlow モバイルと組み込み機器向けの  軽量ソリューションである TensorFlow Lite の開発者向けプレビューを発表します。


TensorFlowは、サーバのラックから小型のIoTデバイスまで、常に多くのプラットフォーム上で動作していますが、機械学習モデルの採用が過去数年間で急激に増加しているため、モバイルデバイスや組み込みデバイスに展開する必要があります。TensorFlow Liteを使用すると、デバイス上の機械学習モデルのレイテンシを低く抑えることができます。

TensorFlow Lite は、次のように設計しています:

  • 軽量 バイナリサイズが小さく、初期化/起動が速いオンデバイスマシン学習モデルの推論を可能にする
  • クロスプラットフォーム AndroidやiOSの複数のプラットフォームで動作 するように設計されたランタイム
  • 高速 モバイルデバイスに最適化され、モデルの読み込み時間が大幅に短縮、ハードウェアアクセラレーションをサポート
今日、ML ワークロードをより効率的に処理するための専用ハードウェアを組み込んだモバイルデバイスが続々と登場しています。TensorFlow Liteは、Android ニューラルネットワークAPI をサポートし、これらの新しいアクセラレータを利用できるようにします。
 

ハードウェアのアクセラレータが利用できない場合、 TensorFlow Lite は最適化された CPU 実行に戻ります。これにより、モデルが大量のデバイスで高速に動作することが保証されます。
 

アーキテクチャ

 次の図は、TensorFlow Lite のアーキテクチャ設計を示しています。


 個々のコンポーネントは次のとおりです:


  • TensorFlow Model:ディスクに保存された訓練された TensorFlow モデル
  • TensorFlow Lite コンバータ:モデルをTensorFlow Liteファイル形式に変換するプログラム
  • TensorFlow Liteモデルファイル:最大速度と最小サイズに最適化された FlatBuffers に基づくモデルファイル形式
TensorFlow Liteモデルファイルは、モバイルアプリケーション内にデプロイされます。モバイル・アプリケーション内では:


  • Java API: Android 上のC++ APIに関する便利なラッパー
  • C++ API:TensorFlow Liteモデルファイルを読み込み、Interpreterを呼び出す。AndroidとiOSの両方で同じライブラリが利用可能
  • Interpreter:Operatorの集合を使ってモデルを実行する。Interpreter は限られたOperatorのみローディングをサポートします:Operatorなしで70KB、すべてのOperatorをロードして300KBです。TensorFlowが必要とする1.5M (通常のOperatorの集合を使用)から大幅に削減
  • 限られたAndroidデバイスでは、InterpreterはAndroid Neural Networks APIを使用してハードウェアアクセラレーションを行い、使用できない場合はCPUの実行をデフォルトにする

開発者は、インタプリタで使用できるC ++ APIを使用してカスタムカーネルを実装することもできます。
 


モデル

TensorFlow Lite は、すでに訓練され、モバイル向けに最適化された多数のモデルをサポートしています。


  • MobileNet:モバイルおよび組み込み機器での効率的な実行のために特別に設計された1000種類のオブジェクトクラスを識別できるビジョンモデルクラス
  • Inception v3:MobileNetと機能的に類似しているが、より高い精度を提供するが、より大きなサイズを有する画像認識モデル
  • Smart Reply:着信した会話型チャットメッセージにワンタッチで返信するオンデバイスの会話モデル。ファーストパーティとサードパーティのメッセージングアプリはAndroid Wearでこの機能を使用する。
Inception v3 と MobileNets は ImageNet データセットで訓練されています。転移学習(Transfer Learning)を行うことで、自分の画像データセットでこれらを簡単に再学習することができます。
 


TensorFlow Mobile はいかが?

ご存じのように、TensorFlowはすでに、 TensorFlow Mobile API を通じてモデルのモバイルおよび組み込み展開をサポートしています。今後、 TensorFlow Lite は TensorFlow Mobile の進化と見なされるべきです。成熟するにつれて、TensorFlow Mobile はモバイルデバイスや組み込みデバイスにモデルを導入するための推奨ソリューションになるでしょう。この発表により、TensorFlow Lite は開発者のプレビューとして利用可能になり、TensorFlow Mobileはまだプロダクションアプリをサポートします。

TensorFlow Liteの範囲は大きく、依然として積極的に開発中です。この開発者プレビューでは、最も重要な共通モデルの一部でパフォーマンスを保証するために、意図的に制約のあるプラットフォームを使用しています。私たちは、ユーザのニーズに基づいて将来の機能拡張を優先させる予定です。継続的な開発の目標は、開発者の経験を簡素化し、モバイルデバイスや組み込みデバイスのモデル展開を可能にすることです。

開発者が TensorFlow Lite に手を差し伸べていることに、私たちは興奮しています。私たちは、TensorFlowプロジェクトの残りの部分と同じ強度で外部コミュニティをサポートし、取り組むことを計画しています。TensorFlow Lite で何ができるのかを待つことはできません。

詳細については、TensorFlow Liteのドキュメントページを参照してください。
より多くのアップデートをお待ちしております。

ハッピー TensorFlow Liteコーディング!

------

実は、転移学習でカスタマイズした学習済みモデルをKeras.js で縮退させたモデル使ってHTML5アプリにしてうごかしてやろうと思っていたら..

そうか..Andoroid系のハードにGPUリソース入れる気なんだ..

..でそれでアクセラレーションした機械学習モデルネイティブアプリ動かして
クラウド上のコグニティブとか抜かしているAPIサービス群をまるっとぶっ飛ばす気だ..




...やられた..コカコーラの記事でなんとなく怪しいとは思ってたんだよな..

 そうなると..Appleは対抗でiPhone/iPadにGPUを入れてくるよな..

..モバイルGPU市場の株式アツくなるかもしれないなあ..

2017年11月10日金曜日

tf.dataを制するものはTensorFlow1.4.0 を制す、な話

前に書いた記事「TensorFlow 1.4.0 rc0 がリリースされていた
にでてきたとおり、

TensorFlow 1.4.0 リリースの核
 Estimator
であるのは明白だ。

いろんな機械学習モデルの実装が
Estimator としてこれから提供されるだけでなく
学習済み機械学習モデルは
缶詰めされた Esatimator (Canned Estimator)としても提供される。


すぐに鎮火すると思っっていた人工知能ブームだったが、
自動運転やチャットボットとかの台頭と
顧客がいまだ何に使えるかわかっていない状態が続き
幻滅期に一気に移行しなかったようで、
そうこうしているうちに
コグニティブ API 流用レベルのいっちょかみSIer
にも
私のように勉強する時間ができ
TensorFlowやChainer、Theano、Kerasなどの
ライブラリを使った機械学習いっちょかみSIer 
へレベルが徐々にあがってきた。

この「機械学習いっちょかみSIer」が最近
いまだ何に使えるかわかっていない顧客」に
学習済み機械学習モデルを流用して類似事例に転用して
高値で売りつけるようになってきた..気がする。

機械学習を少し勉強した人は単なる「転移学習(Tranfer Learning)」の流用に過ぎないが
VGG16やのInseptionV3やらの性能の良い学習済み画像分類器なんかが
ライブラリに入っているものだから..

..と、話がそれていきそうなのでやめにするが...

ようはこれから至近何ヶ月かは
Canned Estimator の時代
が来ていることを個人的に実感している。


転移学習は基本、
少ない学習データで学習済みモデルを追加学習させる方法
なのだけど、
これをやるには
学習済みモデルのお尻の層数層+新規の層数層を加えて
少ない学習データをバッチ実行させて追加学習させ無くてはならない。

Keras の VGG16 とかの既存学習モデルは
はなっからそう使われるだろうなと想定されていて
簡単に転移学習できるようになっているが
TensorFlowのEstimatorは
Estimator に合う入力データ、バッチデータにしてやらないといけない。

でもTensorFlowというライブラリは
バリバリのモデル自体の開発者向けという面をもっているので
入力データを input_fn という一定のルールで書かれた関数にしてやらないと
食わせることができない、いっちょかみできないのだ。


で、いろいろ調べているのだけど 1.4.0 が出たばっかりなので
本家サイト以外にさっぱり情報がない..

で、本家サイトを読んでいたらこのリンクを見つけた。

Introducing tf.data
Derek Murray
https://docs.google.com/presentation/d/16kHNtQslt-yuJ3w8GIx-eEH6t_AvFeQOchqGRFpAD7U/edit?usp=sharing



と、いうことで早速勝手に翻訳してみた。
ちょうどスライドのノート部分にDerek Murray氏の喋った内容も記載されているので
一緒に翻訳してみた。

以下その翻訳文だが、当然間違っていても一切責任はとりません。
参照する際は、at your own riskでお願いします。

-------



 皆さん、私はDerek Murrayです。今日、私は入力パイプラインについてお話します。

このセッションでは、入力データ用の効率的で複雑なパイプラインを簡単に定義できる入力パイプライン用の新しいライブラリについて説明します。

ライブラリでは tf.data と呼ばれ、TensorFlow 1.2がリリースされた 5月に初めて登場しました...

...そして先日の1.4 リリースにて、TensorFlowをコアに無事移行になったことがアナウンスされました。



私はなぜ入力パイプラインについて話しているのしょう?
それは、入力データは機械学習の生命線だからです。
私たちはモデルを高精度に訓練するために巨大なデータセットに効率的にアクセスすることに頼りっきりになっているのです。







 しかし、現在のアクセラレータ(GPU)は非常に枯渇しています。 NVIDIA の Volta や Cloud TPU のようなアーキテクチャは、数年前よりもはるかに高速であり、入力パイプラインから非常に高いスループットを要求して飽和状態を維持します。



 率直に言うと、GPU枯渇はパフォーマンスの問題だけではありません...あなたのデータをTensorFlowに簡単に取り込む方法が必要です。
以前は、基本的に2つのオプションがありました...




 ひとつは、feed_dict メカニズムです。

この方法では、すべての入力処理をTensorFlow 計算グラフ外の Pythonプログラム上に置いています。

これを行うことの良い点は、Pythonのもつ柔軟性を享受でき、任意のデータ形式での作業が容易になることです。

しかし、この方法ではパフォーマンスは悪くなることがあります。利用者はしばしば単一のスレッドで入力データを処理することとなり、それがクリティカルパスとなっています。その間アクセラレータは全くの役立たずとなるのです。







..また、2つめの選択肢として、あなたのプロセスを TensorFlow の C++ オペレーションに移して、それらを TensorFlow の "生産者/消費者" キューを使うために文字列化するという方法もあります。

このスライド上のこのようなAPIは、ちょっとした待ち行列を構築し、パイプラインを与え、並列性を得ることで、データを placeholder へコピーする時間の合計を削減させています。

TensorFlowプログラムで ”キューランナーの開始(start queue runnners)" を聞いたことがありますか?これは、待ち行列の間で要素を移動する小さなグラフを実行するためにPythonスレッドを分岐させる神秘的なライブラリコールのことです。(start queu runnerを)呼び出すことを忘れても、複雑な並列 Python プログラムを実行してキューをいっぱいにしておく必要があります。グローバルインタープリタロックは、1秒あたりに処理できるレコード数を厳しく制限します。

コンセプト上の欠点もあります。--いい意味で--APIがこれらのスレッドの詳細を隠蔽しようとするため、キューベースのパイプラインはすべての入力データに対して単一のグローバルな1回限りのパイプラインになり、実行時に入力ソースを変更することはほとんど不可能になります。

このため、これらよりも高速で、キューよりもはるかに使いやすい代わりになるAPIを設計したいと考えたのです。



 では、なぜ我々が、関数入力パイプラインのための新しいTensorFlow APIである tf.data のために数ヶ月を費やしたのかについて話したいと思います。

ここでは、みなさんに APIのツアーを提供して、あなたが何をすることができるかを示していきたいと思います。

私たちがtf.data を設計していたときは、機能プログラミングの分野からも重要な洞察が得ていました。


入力パイプラインは、関数型言語における"のろまなリスト(遅延リスト:lazy list)"のようなものなのです。

何故我々がそう設計したと思いますか?



 データ要素はほとんど同質であるため、(Pythonの)listのようなものと同じです。フィーチャは異なるshapeを持つこともありますが、一般的には同じタイプのフィーチャを持ちます。


データセット全体が大きすぎてすべてを一度に実現できない場合や、データを自分で生成している場合は無限になる可能性があります。

そこれ、それらをlazy(=のろま)にすることを考えました。


 一旦のろまなリストのようなそれらについて考え始めると、どうして map() filter() のような高次関数を作成するのかがわかるとおもいます。



 これは決して新しい考えではなく、実際にはC# の LINQ 、Scala のコレクション、 Java8 のストリームなどの主流言語の標準ライブラリの一部にもなっています。 そして、まったく正直なところ、斬新さの欠如はここでは良いことです。それが定石としてうまくいくことはわかっていますし、Stream Fusion、Shortcut Deforestation、そしてもしかすると、パフォーマンスを向上させるためのSQLクエリの最適化などで--あなたも書いたことのあるようなプログラム最適化に関する膨大な文献があります。

したがって、入力パイプラインを機能的なプログラムとして記述することができれば、良い形になります...



 ...これが、関数入力パイプライン用の新しいTensorFlow APIであるtf.dataを作成した理由です。


 tf.data には、TensorFlowプログラムへの2つの新しいインターフェイスが導入されています。

1つは、要素のコレクションを表す Dataset インターフェイスです。関数型のアナロジーが好きだった場合-- Dataset はテンソルのタプルののろまなリストと考えることができます。



 それらをどのようにして作成するかについての幾つかのデータセットの例を紹介します。
最初のデータセットの例は "ソース" で、1つ以上のテンソルオブジェクトから作成しています。



 たとえば、最も簡単なソースは Dataset.from_tensors() で、これはテンソルのタプルから単一要素のデータセットを作成しています。



 これらのテンソルを複数の要素に分割したい場合は、 "from_tensor_slices"を使用します。


 もしデータをディスクから取得するのであれば、TextLineDatasetなどのファイルリストを読み取るファイル形式パーサを使用して、これらのファイル内の各行に対して1つの文字列要素を含むデータセットを生成することができます。



 第2の選択肢としては、機能変換を使用して1つのデータセットを別のデータセットに変換することです。 一覧でおみせするにはあまりにも多くの変換があるのですが、より一般的なもののいくつかは以下を含みます...


...map(), ここではデータセットの各要素へ関数を適用します...





... repeat() を使用して、入力データセットを複数回ループすることができます...

...そしてバッチ、ここでは元のデータセットから複数の連続した要素をまとめてバッチを作成します。

 そして、APIには数多くの基本的な変換があります(主に標準的な高次関数のリストに基づいており、それらを組み合わせてより複雑なものにすることができるように設計されています)。


 この良いサンプルとしては、TensorFlow 1.4に追加した py_func opといくつかの標準データセットから作成した新しい Dataset.from_generator() のソースです。

このソースを使用すると、入力処理ロジックをPythonジェネレータとして記述することができます。これをデータセットに変換して、他の変換と一緒に作成することができます。 これはユーザの生産性を変えるものであり、数週間しか利用できないにもかかわらず、 feed に慣れている方がより良い成果を望む場合はより簡単になると思います。





 さあ、それをまとめてみましょう。 ファイル名のリストから始めて、TFRecordDatasetを使ってレコードをバイナリ blob として取得し、構文解析関数をマップしてテンソルに変換し、ランダムシャッフルし、100回のトレーニングを繰り返し、最後に128個の連続要素のバッチを連結し単一の要素に変換します。

多くの人々の最初のデータセットパイプラインはこのように見えます。シャッフルリピートバッチは、ミニバッチSGDを実行するときの共通のモチーフです。

データセットのパイプラインを読んで、 feed やキューベースのプログラムを見ているよりも、何が起こっているのかを簡単に伝えることができていたらうれしいのですが。







パイプラインをデータセットとして定義してきました。

あなたはどの方法でモデルをトレーニングするためにテンソルを取得しましたか?

2つめの補足は Iterator インターフェイスです。Iterator は他のプログラミング言語のイテレータとよく似ています。Iterator はデータセット内の現在の位置を維持し、テンソルのタプルとして次の要素にアクセスする方法を提供します。




iteratorメソッドを呼び出すことによってデータセットからIteratorを作ることができます。ここにはいくつかのオプションがあります。



単純なケースでは、1回のみのイテレータがうまく機能します。自動的に初期化され、データを1回通過させることができます。これは、基本的にキューから取得できる機能を提供します。



より高度なオプションは、初期化可能なイテレータで、複数のデータソース間の切り替えなど、より洗練された使い方を提供しています...


..主な違いは、初期化可能なイテレータは、初期化のために実行できるオペレーションを与えることができます。

・複数回実行可能

・異なるファイルリストや異なるエポック数などのようなパラメータを実行時にfeed可能です。




イテレータを設定したら、 get_next() メソッドを使用してイテレータから次の要素にアクセスできます。 これは古典的な TensorFlow で、遅延実行があるため、session.run に渡して次の要素を生成する必要があります。



実際にどうやって使うのでしょうか?

ここで、画像とラベルのバッチのデータセットがあるとします。
イテレータを作成し、get_nextの結果をあなたのモデルと最適化機能を使って訓練を行い、その訓練をループで実行します。

OutOfRangeErrorは、ファイルの終わりに対する私たちの魅力的な名前です。

この定型文をすべてあなた自身で書く必要はないことに注意してください...




たとえば、Estimator APIを使用している場合は、最初の数行を入力関数にラップするだけで、Estimatorがループ処理を行います。



キューではできないこともあなたに味わっていただきたいと思います。

(1エポックと呼んでいる単位の)データを正確に一通り実行し、次を開始する前に幾つかの エポック終了時の計算(end-of-epoch computation) を実行するとしましょう。

古いキューベースのAPIでは、基本的に単一のグローバルなone-shot(1回だけの) iterator があるため、これをやりたい場合はsessionを解体して再起動する必要があります。これは不器用で処理も遅くなります。

このスライドでは、初期化可能なイテレータがその問題をどのように解決するかを示しています。このように、エポックを越えて外側のループを持つことができます。そのループの始めにイテレータを初期化し、範囲外になるまで訓練し、最後にエポックの計算を行い、パイプラインを再起動します。

エポック終了時の計算では、検証のために別のデータセットを反復処理する必要があるかもしれません。あるいは、イニシャライザをパラメータ化して、各エポックで異なる処理を行うこともできます。





tf.data APIをまとめましょう。
ここでは、学ぶべき2つの新しいクラスがありました。
tf.data.Dataset では、データソースと機能変換の構成としての入力パイプラインを表しました。

また、tf.data.Iteratorを使用すると、データセットから要素にシーケンシャル(順番)にアクセスすることができました。

うまくいけば、既存のAPIよりシンプルであると確信しています。


tf.data の柔軟性は次の2つの点からもたらされます:

・複雑なパイプラインを構築するために一緒に構成された豊富な変換セット



・同じプログラム内に複数のデータセットとイテレータを作成できるため、振る舞いをパラメータ化してさまざまなソース間を切り替えることが可能

なことです。




パフォーマンスについても少し語りたいとおもいます。

ここでの努力に対する全ての目的は、使いやすく高速なものを作ることにあります。




あなたがこれまでずっと feed_dict ベースのプログラミングをしてきているのであれば、かなりのスピードアップを期待できるでしょう。

実装されている内容を詳しく説明する時間はありませんが、主な性能向上ポイントとしては、Pythonのオーバーヘッドを避けるために C++ で tf.data を実装しているところにあります。

tf.data パイプラインを同等のキューベースのパイプラインと比較すると、同様の構造のキューとスレッドが使用されますが、クリティカルパスには Python キューランナースレッドが存在しないため、tf.data パイプラインは グローバルインタープリタロックによって制限され、より高いスループットにエンハンスされます。





ただし、現在の実装は、デフォルトでは決定論的(確定的)、順次および同期的です。 すべてのステージのバッファとスレッドを作成し、要素を生成するために競合するキューベースのAPIとは異なり、並列性と非決定性のオプトインを行うという控えめなアプローチをとってきました。 その理由の1つは、トレーニングモデルのRAM要件が非常に大きくなる可能性があるということです。1つのバッチはマルチGPUイメージモデルでは数百MBから数ギガバイトになる可能性があり、コンピュータのスラッシングを開始するよりも遅く予測可能です。

幸いにも、我々はより高いパフォーマンスの選択を容易にしました...






このデータセットのサンプルを見て、パフォーマンス関連のコードを入れようとしている不審なスペースをつかって再編成してみしましょう!

私は努力順で行くつもりです...




まず、非同期パイプラインを有効にし、dataset.prefetch() でこれを行うことができます。これは本質的に恒等変換ですが、バックグラウンドスレッドとバインドされたバッファを作成して要素をプリフェッチします。

残りのパイプラインのコストが安い場合は、現在のバッチのトレーニングと次のバッチの事前処理を重複させることができます。




事前処理がより大変な場合は、並列化したくなるかもしれません。
これは、 num_parallel_calls を dataset.map() に追加するだけで簡単にできます。

今度は、TensorFlowスレッドプールを使用して一度に64レコードを解析します。




最後の方法は、GCSのような分散ファイルシステムを使ってデータを保存する場合に最も便利です。

ファイルベースのデータセットでは、一度に1つのファイルが読み込まれるため、ほとんどの時間を I/O のブロックに費やす可能性があります。

この小さなインターリーブとプリフェッチガジェットを使用すると、8つのファイルを同時に読み込み、バッファを保持してレイテンシの変動を隠すことができます。




さて、ここまで新しい tf.data API を紹介してきました。

セッションの終盤は、今後何が起こっていくのかを知りたいだけだとおもいます。

私はすでに、TensorFlow 1.4 において API が tf.dataに移動していると述べました。
これのバージョンから、後方互換性の保証をしていきます。みなさんのプロダクトではそれに頼ることをお勧めします。




我々の次の大きな目標は、GPUメモリへの自動ステージングを可能にすることです。 これはパフォーマンスにとって重要です。プログラムの1行の変更でこれを有効にする必要があります。



そして長期的には、自動パフォーマンス最適化のチャンスに興味があります。 私は既に静的最適化に関する豊富な文献があると述べましたが、新しいAPIは、実行時にバッファサイズ、スレッド数、プレースメントを設定する興味深い可能性を与えてくれますし、これらを最適化するLearning2Learnや強化学習のテクニックのような事さえ使うでしょう。



このセッションでは、TensorFlow内へのデータ取得は苦痛を伴うものではないことを示しました。

tf.data はシンプルですが、高速で、柔軟性があり、以前はできなかったあらゆることを行うことができます。

あなたがそれを使って構築することを聞くのが待ちきれません。

ああ。 また、私たちが公開したばかりの基礎を紹介するブログポストもあります...

聞いてくれてありがとう、質問をいただけると嬉しいのですが..




-------


..多分ノート部分は、
Youtubeの自動テロップ機能の出ててきた英語をそのままではなく
直しているのだとおもうのだけど、
ところどころ..ああ、ここ、ドヤ顔してるな..きっと..というのが
よめる英語だった..

実装のスードコードが載っていたので
非常によくわかった。

キューっていうモノがあるのは
本家サイトを翻訳していたときから知ってはいたんだけど、
(もちろん非同期の基本モデルの登場人物だってことも)
これまでは「まずは動作させること」に命を燃やしていたので
feed_dict 経由一本槍だった..


..たしかに feed_dict で投入する段階って、
TensorFlow の C++ の実装との境界レベルだともうので
そこまでずーっとシングルスレッド一本で書いてたら
遅くなるよなあ..



..入力層にデータを入れるところからが
機械学習と思っているほかのライブラリと違って、
TensorFlowは
データ入力するところ(事前処理)も機械学習ですって
いっているわけね。

バッチ毎回の豆乳までにその分のデータを用意すりゃいいでしょ
っていうことで遅延リストを使うあたり
DBアクセスのHibernateっぽい..

やっぱコンピュータは I/O がボトルネックになるのは
基本中の基本ということか..

にしても.. バッチ1回毎に学習データに変化を持たせる..
..域まで機械学習こなしてないなあ..

..最先端の機械学習屋はそんなこともやってるんだ..




p.s.

そうか..

これからしばらくは、
Qiitaとかに出してるTensorFlowサンプルコード
人の書いたコードとかの
session を withしてるなかで
feed_dictをつかっていたら
まだまだ、わかってないね、チミ(シー、シー)
とか言えば、
TensorFlowなんちゃって玄人
にすぐなれるってことか..


..もちろん、
この記事を読んでいる人は
みないい人たちだから
そんなことしませんよね...

2017年10月23日月曜日

Proxy環境下でHubotコンテナが起動しなくなった

前に書いた記事

HuBotを使ってRocketChat用のチャットボットを試しに作ってみる
https://fight-tsk.blogspot.jp/2017/04/hubotrocketchat.html

で書いたスクリプトがProxy環境下で動作しなくなってしまった
どうも

[GitHub] hubot-rocketchat
https://github.com/RocketChat/hubot-rocketchat

をcloneしてちくちくbuildしていくと
npmコマンドへのproxyを設定しないとビルドに失敗してしまうのだ。

Dockerfileの中でスイッチユーザしてたりして厄介だ..

..ということで、Dockerfileを自分で書いてみた。

ベースイメージはnodeの安定版がv6.11らしいので、コッチをつかってみた。


FROM node:6.11
MAINTAINER hara hara development

# change your setting or overwrite with build parameters
ARG HTTP_PROXY=http://proxy.server:8080
ARG HTTPS_PROXY=$HTTP_PROXY

USER root
RUN npm -g config set proxy $HTTP_PROXY && \
    npm -g config set https-proxy $HTTPS_PROXY && \
    npm -g config set registry http://registry.npmjs.org/ && \
    npm install -g yo generator-hubot && \
    npm install  -g hubot-rocketchat@1 && \
    useradd hubot -m
USER hubot
WORKDIR /home/hubot

# change your setting or overwrite command parameter
ENV ROCKETCHAT_URL=change_rocketchat_server:3000
ENV ROCKETCHAT_ROOM=
ENV BOT_OWNER="Change Your Name "
ENV BOT_NAME=bot
ENV BOT_DESC="change bot description"
ENV ROCKETCHAT_USER=bot
ENV ROCKETCHAT_PASSWORD=password
ENV ROCKETCHAT_AUTH=password
ENV LISTEN_ON_ALL_PUBLIC=true
ENV EXTERNAL_SCRIPTS=hubot-diagnostics,hubot-help,hubot-google-images,hubot-google-translate,hubot-pugme,hubot-maps,hubot-redis-brain,hubot-rules,hubot-shipit,hubot-jenkins-notifier,hubot-grafana
ENV TZ=Asia/Tokyo

RUN cd $HOME && \
    yo hubot --owner=$BOT_OWNER --name=$BOT_NAME --description=$BOT_DESC --adapter="rocketchat@1" && \
    node -e "console.log(JSON.stringify('$EXTERNAL_SCRIPTS'.split(',')))" > external-scripts.json && \
    npm install $(node -e "console.log('$EXTERNAL_SCRIPTS'.split(',').join(' '))")

EXPOSE 8080

CMD bin/hubot $BOT_NAME -a rocketchat



DockerfileENVARG指定を、各自の環境に合わせて変更して、

mkdir -p data && chmod a+rwx data && sudo docker build --name myhubot:latest .
sudo docker run -v data:/home/hubot/scripts -p3001:8080 mybot:latest

を実行してもいいし、

mkdir -p data && chmod a+rwx data
sudo docker build --name hara2/myhubot:latest --build-arg HTTP_PROXY=http://my,proxy:8080 --build-arg HTTPS_PROXY=http://my.proxy.8080 .
sudo docker run -e ROCKETCHAT_USER=mybot -e ROCKETCHAT_PASSWORD=mybotpass -v data:/home/hubot/scripts -p 3001:8080 hara2/myhubot:latest


と全部引数指定しても良い。

hubot-scripts.jsonexternal-scripts.jsonの扱いが今後も変わってきそうなので
このあたりまた動かかなくなるかもしれない。

けどDockerfileを見てもらったらわかると思うけど、
インストール手順に従っただけなので、
動かなくなったらちょこちょこ直して動かせるようにするにはそう難しい技術がいるわけでもない。

#ので、今後動かなくなっても、あとは各自でやってください..

2017年10月17日火曜日

TensorFlow 1.4.0 rc0 がリリースされていた

タイムラインにTensorFlow1.4.0 rc0 のリリース案内が流れてきました。
ので、何処が変わったかGitHubのREADMEを翻訳してみました。

以下、参照される場合は、at your own risk でお願いします。

-------

TensorFlow 1.4.0-rc0


リリース 1.4.0


主要な機能および改善点



  • tf.dataはコアTensorFlow APIの一部になりました
  •  APIは現在、下位互換性の保証を受けています。
  •  tf.contrib.data APIから移行する方法については、README参照のこと。
  •  主な新機能には、Dataset.from_generator() (Pythonジェネレータからの入力パイプラインを構築するため)、カスタム変換関数を適用するための Dataset.apply()メソッドがあります。
  •  tf.contrib.data.batch_and_drop_remainder()tf.contrib.data.sloppy_interleave() などいくつかのカスタム変換関数が追加されました。
  • 単純な分散Estimatorトレーニングのための train_and_evaluate を追加しました。
  • DCT-IIを計算するためのtf.spectral.dctを追加しました。
  • Mel-Frequency Cepstral Coefficientのサポートのために tf.contrib.signalを追加しました(GPUおよびグラディエントサポートあり)。
  • Windows DLLの問題のために import tensorflow 処理時セルフチェックを追加しました。
  • GPU上での tf.depth_to_space にNCHWサポートを追加しました。
  • contrib.distributions SinhArcsinh (スカラー)分布を追加しました。
  • GANEstimator オープンソースを構築しました。
  • Estimator.export_savedmodel() にすべての有効なサービスシグネチャが含まれるようになりました。
  • Estimator.export_savedmodel() には、サービング入力レシーバと利用可能なすべての ExportOutputs から構築できるすべての有効なサービングシグネチャが含まれるようになりました。 例えば、分類器は、分類フレーバな出力に加えて、回帰および予測フレーバな出力を提供することができます。これらからシグネチャを構築することで、 TF サービングはさまざまな API(ClassifyRegress、および Predict) を使用してリクエストを尊重することができます。 さらに、 serving_input_receiver_fn() は入力として機能するノードの代替サブセットを指定できるようになりました。 これは、例えば、直列化された tf.Example の代わりに生の Tensors を受け入れる分類子の予測シグネチャを生成することを可能にします。
  • tf.contrib.bayesflow.hmc を追加しました。
  • tf.contrib.distributions.MixtureSameFamily を追加しました。
  • Dataset.shuffle() は、デフォルトで各繰り返しの後に常に再シャッフルされます。
  • tf.contrib.bayesflow.metropolis_hastings を追加しました。
  • tf.contrib.distributions.Poissonlog_rate パラメータを追加しました。
  • tf.contrib.distributions.bijector API を拡張して非注入のものを処理
  • いくつかの非注入変換をハンドル
  • Java:
  •  型安全性を向上させるジェネリックス(Tensor など)(@andrewcmyers の好意より)。
  •  多次元ストリングテンソルのサポート。
  •  Linux および OS X上でカスタム操作(たとえば、tf.contribの多く)の読み込みをサポート。


バグフックスおよびその他変更



  • tf.nn.rnn_cell.DropoutWrapperは、LSTM状態を取り除くことに、今より注意が必要です。 具体的には、LSTMStateTuplec(メモリ)状態を削除することはなくなりました。 新しい動作により、LSTMとスタックされたLSTMの適切なドロップアウト動作が実現します。 このバグ修正は、公開された文献の推奨事項に従いますが、動作上の変更です。 状態のドロップアウト動作は、新しいdropout_state_filter_visitor引数を使用してカスタマイズできます。
  • tf.contrib.training.python_inputを削除しました。 新しいtf.contrib.data.Dataset.from_generatorメソッドを使用すると、より柔軟で再現性の高いパッケージで同じ動作を利用できます。
  • tf.contrib.distributions.Affineを間違ってlog-det-jacobianを修正しました。
  • tf.random_gammaが非バッチ、スカラー描画を誤って処理するのを修正しました。
  • TensorForest TreePredictionsV4Opの競合状態を解決しました。
  • Google Cloud StorageファイルシステムとHadoopファイルシステムのサポートはデフォルトビルドオプションになりました。


APIの変更点



  • tf.contrib.data.rejection_resample() 関数のシグネチャが変更されました。 これで、Dataset.apply() の引数として使用できる関数が返されます。
  • tf.contrib.data.Iterator.from_dataset() メソッドを削除します。 代わりに Dataset.make_initializable_iterator() を使用してください。
  • まれに使用され、不要な tf.contrib.data.Iterator.dispose_op() を削除します。
  • いくつかの TFGAN 損失関数を後方互換性のない方法で並べ替えます。


貢献者への謝辞


このリリースには、Googleの多くの人々からの寄付と次のものが含まれています。


  • 4d55397500, Abdullah Alrasheed, abenmao, Adam Salvail, Aditya Dhulipala, Ag Ramesh,
  • Akimasa Kimura, Alan Du, Alan Yee, Alexander, Amit Kushwaha, Amy, Andrei Costinescu,
  • Andrei Nigmatulin, Andrew Erlichson, Andrew Myers, Andrew Stepanov, Androbin, AngryPowman,
  • Anish Shah, Anton Daitche, Artsiom Chapialiou, asdf2014, Aseem Raj Baranwal, Ash Hall,
  • Bart Kiers, Batchu Venkat Vishal, ben, Ben Barsdell, Bill Piel, Carl Thomé, Catalin Voss,
  • Changming Sun, Chengzhi Chen, Chi Zeng, Chris Antaki, Chris Donahue, Chris Oelmueller,
  • Chris Tava, Clayne Robison, Codrut, Courtial Florian, Dalmo Cirne, Dan J, Darren Garvey,
  • David Kristoffersson, David Norman, David RöThlisberger, DavidNorman, Dhruv, DimanNe,
  • Dorokhov, Duncan Mac-Vicar P, EdwardDixon, EMCP, error.d, FAIJUL, Fan Xia,
  • Francois Xavier, Fred Reiss, Freedom" Koan-Sin Tan, Fritz Obermeyer, Gao, Xiang,
  • Guenther Schmuelling, Guo Yejun (郭叶军), Hans Gaiser, HectorSVC, Hyungsuk Yoon,
  • James Pruegsanusak, Jay Young, Jean Wanka, Jeff Carpenter, Jeremy Rutman, Jeroen BéDorf,
  • Jett Jones, Jimmy Jia, jinghuangintel, jinze1994, JKurland, Joel Hestness, joetoth,
  • John B Nelson, John Impallomeni, John Lawson, Jonas, Jonathan Dekhtiar, joshkyh, Jun Luan,
  • Jun Mei, Kai Sasaki, Karl Lessard, karl@kubx.ca, Kb Sriram, Kenichi Ueno, Kevin Slagle,
  • Kongsea, Lakshay Garg, lhlmgr, Lin Min, liu.guangcong, Loki Der Quaeler, Louie Helm,
  • lucasmoura, Luke Iwanski, Lyndon White, Mahmoud Abuzaina, Marcel Puyat, Mark Aaron Shirley,
  • Michele Colombo, MtDersvan, Namrata-Ibm, Nathan Luehr, Naurril, Nayana Thorat, Nicolas Lopez,
  • Niranjan Hasabnis, Nolan Liu, Nouce, Oliver Hennigh, osdamv, Patrik Erdes,
  • Patryk Chrabaszcz, Pavel Christof, Penghao Cen, postBG, Qingqing Cao, Qingying Chen, qjivy,
  • Raphael, Rasmi, raymondxyang, Renze Yu, resec, Roffel, Ruben Vereecken, Ryohei Kuroki,
  • sandipmgiri, Santiago Castro, Scott Kirkland, Sean Vig, Sebastian Raschka, Sebastian Weiss,
  • Sergey Kolesnikov, Sergii Khomenko, Shahid, Shivam Kotwalia, Stuart Berg, Sumit Gouthaman,
  • superzerg, Sven Mayer, tetris, Ti Zhou, Tiago Freitas Pereira, Tian Jin, Tomoaki Oiki,
  • Vaibhav Sood, vfdev, Vivek Rane, Vladimir Moskva, wangqr, Weber Xie, Will Frey,
  • Yan Facai (颜发才), yanivbl6, Yaroslav Bulatov, Yixing Lao, Yong Tang, youkaichao,
  • Yuan (Terry) Tang, Yue Zhang, Yuxin Wu, Ziming Dong, ZxYuan, 黄璞

問題を提起した人、解決を助けた人、、質問した人、質問に答えてくれた人に感謝しています。


ダウンロード



-----

ざっとながめると、新機能というより Contrib の組み入れが中心なかんじか。

新しいモデルなどはまだついていけてないのでよくわからないし..


ちなみにDocker Hubのほうも既に更新されていて tensorflow/tensorflow のlatestはすでに1.4.0-rc0になっていた。


追記2017/11/7

今朝TwitterタイムラインにGoogle中の人が1.4.0の紹介したい機能に関する記事をながしていたので、ここに勝手翻訳文を載せておきます。
------

TensorFlow 1.4.0 の発表

2017年11月7日火曜日
TensorFlowチームによる投稿
TensorFlowリリース1.4が公開されました - これは大きなものです!私たちは誰もが楽しむことを願って、新しくてエキサイティングな機能をいくつか紹介します。

Keras

1.4では Keras が tf.contrib.keras からコアパッケージ tf.keras に移行しました。Keras は非常に一般的な機械学習フレームワークであり、ハイレベルのAPIで構成され、アイデアと実装の間の時間を 最小限に抑えます。Keras は Estimator API を含む他のコアTensorFlow 機能とスムーズに統合します。実際には、tf.keras.estimator.model_to_estimator 関数を呼び出すことによって任意のKerasモデルから直接Estimatorを構築することができます。 Keras が TensorFlow コアに組み込まれているので、実際の業務で稼動するワークフローのために使用することができます。

Keras を始めたい方は、次のドキュメントを読んで下さい:
Estimator を始めたい方は、この記事を読んで下さい。

Datasets

私たちは、Dataset API の ( tf.contrib.data から) コアパッケージ tf.data 移行を発表できることを喜んでいます。1.4 版の Dataset API では、Python ジェネレータのサポートも追加されています。TensorFlow モデルの入力パイプラインを作成するには、 Dataset API を使用することを強く推奨します。


  • Dataset API は過去のAPIより機能的( feed_dict もしくはキューベースパイプライン)
  • Dataset API のパフォーマンスが向上
  • Dataset API がクリーンで使いやすく
今後は過去のAPIの更新ではなく、Dataset API の開発にフォーカスしていく予定です。

Dataset API を開始するには、次のドキュメントを読んでください。


Estimator による分散トレーニングおよび評価

1.4 ではユーティリティ機能 tf.estimator.train_and_evaluate が導入されており、Estimator モデルのトレーニング、評価、およびエクスポートが簡単になりました。この機能は、ローカル実行をサポートしながら、トレーニングと評価のための分散実行を可能にします。

その他の機能拡張

これまで紹介してきた機能以外にも、1.4 ではいくつかの追加機能が導入されています。詳細はリリースノートを参照してください。

TensorFlow 1.4 のインストール

pip install を使用して TensorFlow リリース 1.4 をインストールできるようになりました。
# 注意:次のコマンドは既存の TensorFlow を上書きインストールします
$ pip install --ignore-installed --upgrade tensorflow
# Python 2.7 の場合は pip
# Python 3.x の場合は pip3

tensorflow.org のドキュメントを 1.4 に更新しました。

TensorFlow のそれぞれの拡張は異なる寄稿者によってなされています。 TensorFlow の開発を手伝ってくださったみなさん、本当にありがとうございました! GitHub のソースコードを開発したり、 Stack Overflow に関する質問に答えるのを手伝ったりして、コミュニティに参加して貢献者になることを躊躇しないでください。

このリリースのすべての機能を楽しんでください。

Happy TensorFlow Coding!
-----

どうも1.4.0のポイントはEstimatorらしい。

この日本語記事を読んでも、これからモデルを作る人はこのEstimator のAPIにしたがって作ってね、ということなのだとおもうが..

サンプルが全然ない..

既存のモデルもパーセプトロンぐらいしか無い..

(この文書を書いている時点の)T2Tすら、Estimator実装してないし..

やっぱ Keras API をナカ実装に使って、外見APIはEstimator習って書けってのは
いっちょかみ機械学習開発者にはまだまだハードルが高い..

Keras ベースにJavaライブラリを標準化して、
中の人をAbstractFactoryでTensorFlowやChsainer、CNTK、Theanoにかえられるようにして、
Estimator はGenericServletみたいにJava API化して
あ、もちろんDataset API( input_fn )もいいかんじにTemplateMethodにして
くれないと日本のサラリーマンSEには厳しいのよ..

たのむ、頑張ってくれ Google Brainチーム..

2017年10月12日木曜日

コカコーラのTensorFlow活用紹介ブログ記事を翻訳してみた


これもタイムラインに流れてきたのだけど、
コカコーラ社でTensorflowを活用した事例が書かれた記事のリンク

How Machine Learning with TensorFlow Enabled Mobile Proof-Of-Purchase at Coca-Cola
https://developers.googleblog.com/2017/09/how-machine-learning-with-tensorflow.html



が私のところにながれついた。


ので翻訳してみた。
..というか、最近はほぼGoogle翻訳のままでイケてるので、ブラウザで翻訳させたほうが良いかもしれないけど..

以下の日本語訳を読む方は at your own risk でお願いします。

----------

いかにして Coca-Cola社が購入証跡を TensorFlow エンベデッドモバイルを使って機械学習させたか

木曜日、9月21日、2017



コカ・コーラ社のパトリック・ブランデ氏は、AIとTensorFlowを使って、摩擦のない購入証明をどのように利用しているのかを説明しています。
2006年にMyCokeRewards.comとして開始されたコカ・コーラのコアロイヤルティプログラム。「MCR.com」プラットフォームには、20オンスボトルで販売されるコカコーラ、スプライト、ファンタ、パワー・ド・プロダクト、および食料品店やその他の小売店で購入可能な段ボール「冷蔵庫パック」用のユニークな製品コードの作成が含まれていました。ユーザーは、MyCokeRewards.comでこれらの製品コードを入力して、プロモーションキャンペーンに参加することができます。



2016年の振り返り:コークスのロイヤルティプログラムは、プロモーションや懸賞のために数百万の製品コードが登録され、依然として非常に人気があります。しかし、モバイルブラウジングは、2006年に存在しなかったものから2016年末までに50%以上のシェアになりました。 (「MCR.com」の代わりに)「 Coke.com 」を立ち上げたのは、ブラウジング行動の変化に対する応答でした。モバイルデバイスに14文字のコードを大文字で入力すると、プログラムの成功に影響を及ぼすのに十分なユーザーエクスペリエンスが得られません。私たちはモバイルユーザーに最高の体験を提供したいと考えています。最近の人工知能の進歩は新しい機会をもたらしました。

摩擦のない証拠の探求



何年もの間、Coke は既製の光学式文字認識(OCR)ライブラリとサービスを使用しても、製品コードをほとんど読み取れませんでした。当社の印刷プロセスでは、通常、低解像度のドットマトリックスフォントを使用し、プリントヘッドの下で実行されるキャップまたは冷蔵庫の媒体を非常に高速で使用します。これはすべて、既製のOCR製品を凌駕する忠実度の低い文字列に変換されます(人間の目でも読みにくいことがあります)。OCRは、モバイルユーザーのコード入力プロセスを単純化する上で非常に重要です。コードの写真を撮って、自動的にプロモーションエントリ用に購入を登録する必要があります。私たちは、製品コードを認識するための専用のOCRシステムが必要でした。


ボトルキャップと冷蔵庫パッケージの例

私たちの研究により、有望なソリューション、Convolutional Neural Networksが実現しました。CNNは、近代的な人工知能製品の中心にある「ディープラーニング」ニューラルネットワークのファミリーの1つです。GoogleはCNNを使用してStreetView画像から住所番を抽出しています。CNNは、手書き数字の認識においても非常によく機能します。これらの数字認識ユースケースは、私たちが解決しようとしていた問題のタイプの完璧な代替となります。小さな文字セットを含むイメージから文字列を抽出し、文字の外観に大きなばらつきがあります。


TensorFlowのCNN


過去には、利用可能な訓練および推論ライブラリの複雑さのために、CNNのようなディープニューラルネットワークの開発が課題でした。2015年11月にGoogleがオープンソースとした機械学習フレームワークであるTensorFlowは、深いニューラルネットワークの開発を簡素化するように設計されています。

TensorFlowは、さまざまな種類のニューロン層と一般的な損失関数に高レベルのインターフェイスを提供します。これにより、異なるCNNモデルアーキテクチャを実装するのが容易になります。さまざまなモデルアーキテクチャを素早く反復する能力は、CokeカスタムOCRソリューションを構築するために必要な時間を劇的に短縮しました。数日間で異なるモデルを開発し、訓練し、テストすることができるからです。TensorFlowモデルも移植可能です。フレームワークは、モバイルデバイス(「エッジ上のAI」)またはクラウド内でリモートでホストされているサーバー上でモデルの実行をネイティブにサポートします。これにより、Webベースやモバイルなど、さまざまなプラットフォーム間でモデルを実行できる「一度作成、どこでも実行(create once, run anywhere)」アプローチが可能になります。


機械学習:訓練が完璧を作る(practice makes perfect)


どのニューラルネットワークも、それを訓練するために使用されたデータと同じくらい重要です。私たちは、パフォーマンス目標を達成するCNNを育成するために、大量の製品コードイメージを必要としていることを知っていました。私たちのトレーニングセットは3つのフェーズで構築されます:

  1. 事前起動シミュレーション画像
  2. 実際の画像をプレランチ
  3. でユーザによってラベル付けされた製品の画像

launch前のトレーニング段階は、プログラムされた数百万のシミュレートされた製品コード画像を生成することから始まりました。これらのシミュレートされた画像には、傾斜、照明、陰影、およびぼやけの変化が含まれていました。シミュレーションの画像のみを使用してモデルを訓練した場合、予測精度(すなわち、上位10の予測内で14文字すべてが正確に予測された頻度)は、実世界の画像に対して50%でした。これは転送学習のベースラインを提供しました。シミュレーションされた画像で最初に訓練されたモデルは、実際の画像に対して訓練されるより正確なモデルの基礎でした。

現在の課題は、実績のある目標を達成するのに十分な現実世界の画像でシミュレートされた画像を豊かにすることに変わっています。私たちは iOS と Android デバイス用の専用のトレーニングアプリを作成し、「トレーナ」がコードの写真を撮りラベルを貼ることができるようにしました。これらのラベル付けされた画像は、訓練のためにクラウドストレージに転送されます。ボトルキャップと冷蔵庫パッケージで数千の製品コードを生産し、アプリを使って最初の実世界のトレーニングセットを作成した複数のサプライヤに配布しました。

強化された豊富なトレーニングセットがあっても、さまざまな環境条件でエンドユーザーによって作成されたイメージを代替することはできません。スキャンでコードの予測が不正確になることがあるため、ユーザーがこれらの予測を迅速に修正できるユーザーエクスペリエンスを提供する必要がありました。この経験を提供するためには、2006年にオリジナルのロイヤルティ・プラットフォーム(予測コードが実際のコードであることを検証するため)の開始以来使用されてきた製品コード検証サービスと、回帰を実行する予測アルゴリズムが14文字の位置のそれぞれで文字当たりの信頼度を決定します。予測されたコードが無効である場合、各文字の最上位予測および信頼レベルがユーザインターフェースに戻されます。


エラー訂正UIにより、ユーザは無効な予測を訂正し、有用な訓練データを生成できる


このユーザインターフェイスの革新により、積極的な学習プロセスが可能になりました。フィードバックループを使用すると、補正された予測をトレーニングパイプラインに戻すことでモデルを徐々に改善することができます。このようにして、ユーザは時間の経過とともに文字認識モデルの精度を有機的に改善することができるのです。



最大限のパフォーマンスを得るための最適化


パフォーマンスに関するユーザーの期待に応えるために、製品コードOCRパイプラインのいくつかの野心的な要件を確立しました。

  • より速く:製品コードイメージがOCRパイプラインに送られた後、平均処理時間が1秒とすることが必要。
  • より正確に:私たちの目標は、積極的な学習により、起動時に95%の文字列認識の精度を達成すること。
  • より小さく:OCRパイプラインは、モバイルアプリケーションに直接配布され、時間の経過とともにモデルが改善されると、無線アップデートを収容するのに十分小さい必要がある。
  • よりおおくの製品コードデバイスをハンドルできるように:フォント・タイプ、ボトル・キャップ、厚紙のフライディ・パック・メディアなど、数多くの異なる組み合わせの製品コード・メディアを扱う必要がある。

最初に、すべての製品コードメディアに単一のCNNを使用したアーキテクチャを検討しました。このアプローチでは、モバイルアプリに配布するには大きすぎるモデルが作成され、実行時間が必要以上に長くなっていました。  Quantiphi Inc. の我々の適用されたAIパートナは、 異なるモデルアーキテクチャで反復を開始し、最終的に複数のCNNを使用したものに到達しました。



この新しいアーキテクチャは、精度を犠牲にすることなくモデルサイズを劇的に縮小しましたが、モバイルアプリケーションへの無線アップデートをサポートするために必要なものの最高水準でした。次に、接続されたニューロン間の重みの忠実度を減らすことによってモデルのサイズを縮小するために、TensorFlowの事前構築された量子化モジュールを使用しました。量子化は、モデルサイズを4倍に縮小しましたが、Quantiphiが SqueezeNet という新しいアプローチを使用して画期的な進歩を遂げたときに、モデルサイズが大幅に縮小されました。

SqueezeNet モデルは、2016年の11月にUC Berkeleyとスタンフォードの研究者チームによって発表されました。このモデルは、 Imageet などの一般的なベンチマークに対して、より大きなモデルと同等の精度レベルを達成するために、小さく複雑です。 SqueezeNet CNN を使用するために文字認識モデルを再構築した後、 Quantiphi は特定のメディアタイプのモデルサイズを100倍に減らすことができました。 SqueezeNet モデルは本質的に小さく、豊富な特徴量検出アーキテクチャを構築できました。 SqueezeNet なしで訓練された最初のバッチモデルと比較して、はるかに小さなサイズではるかに高い精度を実現しました。現在、リモートデバイスで簡単に更新できる高精度なモデルが用意されています。能動的学習前の最終モデルの認識成功率は96%に近く、これは99.7%の文字認識精度(1000文字の予測ごとにわずか3回のミス)に相当します。


さまざまなタイプのオクルージョン(隠れ領域)、翻訳、およびカメラフォーカスの問題を伴う有効な製品コード認識の例


AIとの境界を越えて


人工知能の進歩と TensorFlow の成熟により、私たちは長期にわたって求められていた購入証明機能を最終的に達成することができました。2017年2月下旬より発売されて以来、当社の製品コード認識プラットフォームは、十数以上のプロモーションを促進し、18万件以上のスキャンコードをもたらしました。現在、コカ・コーラ北米のウェブベースのプロモーションのすべてのコアコンポーネントとなっています。

AI対応の製品コード認識プラットフォームへの移行は、2つの重要な理由から価値があります。

  • モバイルファーストマーケティングプラットフォームへの全般的な移行に対応して、摩擦のない購入証明がタイムリーに使用可能になりました。
  • Coke は、既存の既製のOCRソフトウェアで動作するより忠実なフォントをサポートするために、生産ラインのプリンタを更新する必要性を避けることによって、何百万ドルも節約できました。

当社の製品コード認識プラットフォームは、コカコーラ内でスケールアップされた新しいAI対応機能の最初の実行です。現在、新製品開発から電子商取引小売の最適化まで、複数の事業部門にわたってAIアプリケーションを検討しています。

----------

上記記事を読む際の、参考リンクとしては、以下のあたり。


TensorFlowサイトを探っていた頃は "量子化" のあたりなんで突然現実的な話がでてきたんだろうか、と不思議に思っていたがおそらく米国でコカ・コーラ社との事案が実際に動いていたのだと思う。技術的にではなく、論理的に繋がった。


で、なんでこの記事を紹介したのかというと...

前の記事で紹介したkeras.js のサンプルにたしか SqueezeNet のやつあったよなあ..
じゃあそれをつなげれば、TensorFlow Mobileを使わないでAndroidのWebPanelだけで
似たようなアプリできるんじゃないのかなあ..と。


TensorFlow Lite が発表された件

今朝のタイムラインには驚いた。 We are so excited to announce the Developer Preview of #TensorFlowLite ! Read all about it in our blogpost → https://...