まだプログラマーですが何か?

プログラマーネタとアスリートネタ中心。たまに作成したウェブサービス関連の話も http://twitter.com/dotnsf

タグ:watson

IBM ワトソンなどの各種コグニティブエンジンを使う際に、重要なのは学習データだと思っています。

要はコグニティブエンジンを使って問い合わせを行うわけですが、その問い合わせする前に何らかの学習をする必要があり、そこで何をどれだけ学習させたかによって問い合わせの精度が変わってくるからです。

で、先日こんなツイートをしました:
2017022601

https://twitter.com/dotnsf/status/834959690803007488


↑は、その学習データを何らかの方法で集める際に、(非同期処理で集めるのではなく)マルチスレッド処理がいいのではないか、と思ってつぶやいたのでした。このことをもう少し詳しく紹介しようと思います。なお、あくまで特定条件下での個人見解なので他の人の意見も聞いてみたいと思ってます。

やろうと思っているのは、大まかにはこんな内容です:
  1. あらかじめ用意したインターネット上の URL のリストから、その HTML を取得して学習データにしたい
  2. この「リスト」が大量にあるケースを想定する
  3. なお、リストの中には実在しない URL が存在している可能性がある(つまりリストそのものが間違っている可能性がある)
  4. また URL は実在しているのだが、ネットワーク障害や DNS の設定ミスなど何らかの原因でアクセスする際に非常に長い時間がかかる(長い時間がかかった結果、タイムアウトになったり成功したりする)場合もある

1と2はごく普通の条件ですよね。ここではインターネット上の URL のリストは配列変数で用意されているものとしましょう。配列から1つずつ URL を取り出して、その URL の HTML を取得する、という処理を施すことになります。

問題は3と4の条件です(でも現実的に想定すべき条件だと思ってます)。3は用意されたリストそのものが間違っているというケース、つまり与えられた URL は "Unknown Host" になったり、404 などのエラーが返ってくることを想定しないといけない、ということです。

また4は更にややこしい条件です。成功するかしないかではなく、こちらからは手が出せない箇所のなんらかの障害によって目的の URL へのアクセスに非常に時間がかかってしまうケースです。時間がかかった結果、目的の HTML が取得できればいいのですが、最終的にタイムアウトエラーが発生することもあり得る、というケースを想定する必要があります。


要するにこれらを想定したエラー対策が必要になるのですが、まずは3と4を無視して(エラーが発生しない前提で)普通にアルゴリズムを考えるとこんな感じになるでしょうか:
//. URL の配列
urls = [
  "http://xxx.com/a1.html",
  "https://xxx.com/a2.html",
  "https://yyy.net/",
  "http://abc.com/xyz.html",
     :
     :
];

//. URL を1つずつ取り出して HTML を取り出す
forall( url in urls ){
  html = getHTML( url );
      :
      :
  (取り出した HTML を使って学習処理を行う)
      :
      :
}


↑の例ですと、getHTML 関数の中で実際に指定した URL にアクセスして HTML を取り出す、という処理をするものとします。そしてこの関数の中で3や4を原因とするエラーや時間がかかるといった現象が発生することを想定してみます。

3のケースは実は単純で、実在しない URL が指定された場合はこの関数の返り値を null などにして、null でなかった場合のみ処理を続ける、という判断を加えることで解決します:
//. URL の配列
urls = [
  "http://xxx.com/a1.html",
  "https://xxx.com/a2.html",
  "https://yyy.net/",
  "http://abc.com/xyz.html",
     :
     :
];

//. URL を1つずつ取り出して HTML を取り出す
forall( url in urls ){
  html = getHTML( url );
  if( html != null ){ //. 3の対策
      :
      :
  (取り出した HTML を使って学習処理を行う)
      :
      :
  }
}


さて問題は 4 のケースです。3 のアルゴリズムを単純に(シーケンシャルに)実行した場合、特定の URL から HTML を取り出す処理に時間がかかってしまうような事態が発生すると、リストの途中で処理が先に進まなくなってしまう、ということになります。このようなケースを想定した上で効率よく処理を実行するにはどう改良すべきでしょうか?

1つの方法として考えたのが非同期処理です。上記のループ部分を非同期に処理して、リスト内の各 URL へのアクセスを非同期に行う、という方法です。アルゴリズムにするとこのような感じになるでしょうか:
//. URL の配列
urls = [
  "http://xxx.com/a1.html",
  "https://xxx.com/a2.html",
  "https://yyy.net/",
  "http://abc.com/xyz.html",
     :
     :
];

//. URL を1つずつ取り出して HTML を取り出す
forall( url in urls ){
  html = getHTML( url, function( err, html ){  //. getHTML を非同期に実行する
    if( err ){
      //. 3. のエラー処理
    }else{
//. 成功した場合
: : (取り出した HTML を使って学習処理を行う) : : } }); }
↑非同期ということで JavaScript っぽくしてみました

このように非同期に処理を行うことで、「各 URL の HTML を取得する」という命令を全て先に実行しておき、(成功にせよエラーにせよ)取得の処理が終わったらそれぞれの続きを行う、というロジックです。こうすることで 4 のような事態が発生しても、正常な URL に対する処理は邪魔されることなく先に終了し、時間のかかる処理だけが後から実行される、という一見きれいな形になります。

しかし、この方法にも問題点がありました。それは URL のリストが膨大だった場合です。上記のコードが非同期に実行されるとまず全て URL に対する HTML 取得のリクエストが発行されます。そしてその処理はシステムのメモリ量や TCP ソケット数上限を超えて実行されてしまう可能性があります。この部分はコーディングというよりもシステムのメモリ管理やソケット数管理などの厄介そうな処理を行う必要がでてきてしまいます。

で、冒頭のマルチスレッドです。上記の非同期で行っていた部分をマルチスレッドに書き換えることで、(スレッド生成間のスリープ時間を調整するなどの)ある程度のスケジュール調整をした上で同時に HTML を取得する処理を行うことができるようになります。例えばこんな感じです(ここは言語依存がありそうなので、Java 丸出しで記述しています):
//. URL の配列
urls = [
  "http://xxx.com/a1.html",
  "https://xxx.com/a2.html",
  "https://yyy.net/",
  "http://abc.com/xyz.html",
     :
     :
];

//. URL を1つずつ取り出して HTML を取り出す
forall( url in urls ){
  //. 子スレッドを生成して、スレッドの中で取得処理を実行
  Download dl = new Download( url );
  Thread t = new Thread( t );
  t.start();

  try{
    Thread.sleep( 1000 ); //. 1秒待ってから次の URL を処理
  }catch( Exception e ){
  }
}


//. マルチスレッドで動くインスタンス
public class Download implements Runnable{
  private String url = "";
  public Download( String url ){
    this.url = url;
  }

  public void run(){
    html = getHTML( url );
    if( html != null ){
      :
      :
  (取り出した HTML を使って学習処理を行う)
      :
      :
    }
  }
}

↑マルチスレッドなので Java 全開の記述法で

この方法であれば、各 URL に対する HTML の取得は別々のスレッドで行われるため、特定の URL で 4 のような遅延現象が発生しても、他の URL に対する処理がその遅延に巻き込まれることはありません。また、この例では1秒(1000ミリ秒)おきにスレッドを生成するようにしています。例えば1スレッドの処理が2秒程度かかるようなケースであっても、3つ目のスレッドが生成されたタイミングで最初のスレッドの処理は終了している可能性が高くなり、同時に実行されるスレッドの数がさほどは増えないようなアルゴリズムになっています。仮に 4 のようなケースが発生したとしても、そのスレッドだけはしばらくの間生き続けることになりますが、他のスレッドは生成しては処理されて消えてゆくという流れになるので、やはりシステムの限界を意識するような処理にはなりにくいアルゴリズムになっているのでした。


という所まで作っての「マルチスレッド処理が効率よい」という冒頭の結論に至ったわけでした。要するにこれなら深く考えずに作って動かしてもややこしい対応が必要になる心配が少ないかな、と。またマルチスレッド処理となると Java が得意とする処理ロジックであり、オッサン脳の出番が増えるかもしれないなあ、と感じたのでした。

普段は IBM Bluemix の関連で IBM Watson の API を紹介する機会があります(このブログでも何度か扱っています)。これらの多くは Watson Cognitive と呼ばれる言語や画像などを対象にした認識/分類を行うタイプのエンジンです。

一方で、Cognitive 以外の Watson もあります。その1つが Watson Analytics と呼ばれるもので、これは「データ分析」を目的としたエンジンです。現在では API というよりも、クラウド上のツールとしてその機能が提供されています:

http://www.ibm.com/software/jp/cmp/watsonanalytics/
2017020100


この Watson Analytics ツールは、誰でも申し込みから 30 日間は無料で使うことができます。というわけで自分も申し込んで、どんなものなのかを試しに使ってみました。

まず上記ページの「無料トライアルを試す」から申し込みを行います。しばらくすると以下のようなメールが送られてくるので、「ログインする」をクリックして、申込み時に指定したメールアドレスとパスワードで Watson Analytics サービスにログインしてください:
2017020201


Watson Analytics サービスにログインした直後はこのような画面になります:
2017020201



さて、今回このサービスを試用するにあたって、どんなデータで何を試すかを考えました。そこまでアナリティクスに詳しいわけでもなく、そこまで詳しい人を対象に紹介するつもりもないので、自分の守備範囲の中で試すことにします。 というわけで、以前にこのブログで紹介したことと同様のことを Watson Analytics サービスで挑戦してみることにします:

dashDB の R Studio を使ってデータの相関関係を調べる
http://dotnsf.blog.jp/archives/1047597688.html


ここで紹介しているのはセンサーとみなしたラズベリーパイから3種類(CPU 温度、CPU 負荷率、サインカーブを描く値)のデータを1秒おきに取り出したものです(取得済み)。そしてこの3つのデータの相関関係有無を調べてみることにします。同ブログエントリ内でも紹介されていますが、取得済みのデータは CSV で公開しているので、同じものをそのまま使うことにします。ここからダウンロードしておいてください:
https://raw.githubusercontent.com/dotnsf/RPDATA/master/RPDATA.csv


なお、この CSV ファイルをそのままエクセルで開くと、最初の方はこんな感じになります。1行目はヘッダでデータは2行目以降。B列が CPUTEMP(CPU温度)、C列がCPULOAD(CPU負荷率)、そしてD列がSINE(サインカーブを描く値)になっています。A列のIDはユニーク文字列ですが、今回は使いません:

2017020211


ちなみに CPUTEMP と CPULOAD を折れ線グラフにするとこんな感じ。途中でわざと負荷をかけたので、山が1つ出来ていることが見てとれます:

2017020212


一方、同じ期間中の CPULOAD と SINE とを比較したのがこちら。SINE は CPU の負荷とは無関係に、一定のリズムでサインカーブを描いていることがわかると思います:
2017020213


ここまで見た上で意識していただきたいのは以下のことです:
・ CPUTEMP が上がると CPULOAD も上がり、CPUTEMP が下がると CPULOAD も下がる
・ SINE にはそういった相関関係が CPUTEMP にも CPULOAD にもない
・ いまグラフの形を見たからそういうことに気付くことができた
・ また CPUTEMP は CPU 温度で CPULOAD は CPU 負荷率だった。つまりどちらも CPU に関連するセンサー値だった。そこまで理解した上でこの数値やグラフを見ているから、これらには関係があるように推測できた


つまり、人間の目でグラフの形を見比べた上で、なんとなく「形が似ている」と気づけたわけです。また「同じ CPU に関する値だったと分かっていたから、それらには関係があるだろう、と推測できた、ということです。

では同じことを目で判断せずに、加えて事前に同じ CPU の情報であることを知らない Watson が、数値データの羅列を与えただけで気付くことができるでしょうか? ということを今回の調査テーマとしてみることにします。


改めて、この CSV ファイルを Watson Analytics にロードします。新規データとして追加するので "+ New data" と書かれた箇所をクリックします:
2017020201


Watson Analytics には標準でサンプルデータが用意されているのでそれを使うことも出来る上、Box や OneDrive、Twitter などのソーシャルサービスから条件を指定してデータを取り出すことも可能になっています。今回は手元にある CSV ファイルを元にデータを生成したいので、"Local file" タブを選択します:
2017020202


このような画面になったら「Browse」をクリックして、先程ダウンロードした RPDATA.csv ファイルを指定します:
2017020203


こんな感じの画面になって RPDATA.csv ファイルがアップロード候補に加えられている状態になりました。このまま「Import」をクリックしてアップロードします:
2017020204


元の画面に戻りますが、いまアップロードした RPDATA.csv が分析データとして追加されていることが分かります。この画面では "Processing..." と表示されています。これはアップロードは完了しているのですが、分析するための処理を行っている途中であることを意味しています。このままもうしばらく待ちます:
2017020205


下図のような状態になると分析処理も完了したことになります。このアイコンをクリックして、実際の分析結果を確認してみます:
2017020206


(RPDATA に対して)どんな分析をするのか、という選択画面が表示されます。上述したように、今回は値の相関関係を調べたいので、"What drives SINE?"(何が SINE に影響しているのか?)を選びます。SINE との影響だけを調べたいわけではないのですが、この "SINE" の部分を切り替えて調べることができるので、今回はこの観点で各種データの影響要素を調べることにします:
2017020207


"What drives SINE?" をクリックすると、しばらく画面構成の処理で時間がかかるのですが、ロードが完了するとこのような画面になるはずです。結論として、"SINE" に関しては "No key drivers were found."(特に影響要素は存在しない)と表示されています。まあ答をわかっている立場からすると当然の結果なのですが、解析結果としても同じ結論になっていることが分かります:
2017020208


もともとの目的にもよるのですが、例えばこのセンサーモジュールの故障やエラー、利用不可になる予防保全をしたい場合などは CPU 利用率があまり高くない状態をキープしていてほしいものです。センサーが PC などと直結していれば、その PC からセンサーの CPU 状態を把握できることもありますが、そうでないケースも珍しくありません。そうなると「センサーの CPU 状態を直接モニタリングする」ことは簡単ではないことになります。これをどうにかできないでしょうか?

では今度はこの "SINE" を "CPULOAD(CPU 負荷率)" に変更して、CPULOAD に影響を与えている要素があるかどうかを調べてみましょう。画面左下の "SINE" と書かれた箇所をクリックし、"CPULOAD" を選択します:
2017020209


同様にして少し処理時間で待つことになりますが、画面のロードが完了するとこんな結果になりました。"CPULOAD" は "CPUTEMP" の影響を受けている、という解析結果が表示されています!
2017020210


もともとは CPU 負荷率の状態をなんとか調べることができないか、という課題があったわけですが、今回の結果によって、このセンサーモジュールでは CPU 温度と CPU 負荷率との間に相関関係があることが統計的にもわかったことになります。そして CPU の温度は直接外部から測定することもできるものなので、CPU の温度を測定していれば、CPU の負荷が高くなっているのかどうかを判断することができる、という可能性がでてきたことになるわけです!


くどいようですが、我々のように事前にグラフの形を見比べたわけではなく、またこれらがどちらも CPU に関する値である、という情報が事前に与えられたわけでもない中での自動解析結果であることを考慮すると、「ここまで簡単に分かっちゃうのか・・」という印象でした。

今回のデータは ID を除けば3種類しかなく、人間の目や脳でもわかりやすいものでした。ただこれが数10種類ものデータを含むもので、その中から存在するかどうかもわからない相関関係を見つけ出すというのはなかなか大変なんだろうなあ・・・と思うのですが、このツールはその作業負担を大幅に軽減できるものだと思います。


というわけで、このような IBM Watson Analytics サービスが無料で試せるというのはなかなかすごいのではないかと思っています。皆様も興味があれば是非試していただいて、手元にある数値データを使って簡単に解析できるという体験をしていただきたいです。



IBM Watson の画像認識 API である Visual Recognition を使った類似画像検索サービスを作り、そのソースコードを公開しました:
https://github.com/dotnsf/imageSearchDemo


コードは Node.js で作りました。プロジェクト自体に(著作権フリーな)サンプル画像もいくつか含まれていますが、サンプル画像を置き換えて使うことでご自身が所有している画像を使った類似画像検索サービスにすることも可能です。

また基本的に Watson API は使いやすいものばかりだと思ってますが、このサンプルアプリもその特徴を最大限に活かして、単純に「学習させたい画像を用意すれば動く」ようにしました。細かな実装内容はソースコードを参照ください。


上記 github 上のリポジトリの README.md の中に使い方も(英語で)記載していますが、このブログでは日本語での簡単な使い方とカスタマイズについて紹介します。前提としてログインできる CentOS/RHEL のインスタンスに git と Node.js がインストールされている環境をご用意ください。また最終的なウェブアプリケーションは IBM Bluemix 上で動かすことにします(この場合は cf コマンドもインストールしておいてください)。異なるプラットフォームでも動くと思いますが、適宜読み替えてください。


準備

何はともあれ、IBM Watson の API を利用するためには IBM Bluemix のアカウントが必要です。まだアカウントをお持ちでない場合はトップページの「フリーアカウントを作成」ボタンから 30 日間無料で使えるトライアルアカウントを作成できます:
2017012601


Bluemix のアカウントでログインし、カタログ内 "Watson" カテゴリの "Visual Recognition" を選択して、この API を追加してください:
2017012602


なお作成時に "Free" プランを選択すると1日に 250 API call まで無料で利用できるプランになります。本格的に利用する場合はその下の "Standard" プランを検討ください:
2017012603


Visual Recognition API を作成後に、ダッシュボードから作成した同サービスを選択して、サービス資格情報から資格情報を確認します(なければ追加します)。そして "api_key" の値(下図ではモザイクにしています)がこの後必要になるのでメモしておきます:
2017012604


改めて github からソースコードを用意します。いくつかの方法がありますが、git が使える場合は git clone してください(または zip をダウンロードして展開してください):
$ git clone https://github.com/dotnsf/imageSearchDemo
$ cd imageSearchDemo

ソースコードを展開したディレクトリの直下に settings.js というファイルがあります。この中の exports.vr_apikey の値を先程メモした Visual Recognition API の API Key の値に書き換えて保存してください:
2017012605


他はそのままでも動きます。なお、exports.limit の値(デフォルトだと 5)はウェブアプリケーションで類似画像を検索した結果として、上位いくつまでの結果を表示対象とするかの数値です。学習させる画像の数などにもよりますが、必要に応じて書き換えて使ってください。

最後に、この後の学習時に必要な Node.js のミドルウェア: watson-developer-cloud を npm でインストールしておきます:
$ npm install watson-developer-cloud

この結果、プロジェクトのホームディレクトリ(imageSearchDemo)に node_modules というフォルダが作られていれば watson-developer-cloud の導入に成功したことになり、学習処理が行えるようになります。


画像の学習

最終的には類似画像を検索する仕組みを作りますが、そのためにはあらかじめ検索結果となる画像を学習させておく必要があります(学習させた画像の中から類似画像を探します)。そして学習のためにはある程度の枚数の画像が必要です。

上記ソースコードの public/images/ の中にはサンプルとして著作権フリーな画像が含まれています。これらをそのまま使って学習させることもできますし、手元にある画像で類似画像検索システムを作りたい場合はそれらを使うこともできます(その場合は public/images/ 以下のサンプル画像を全て削除した上で、ご自身の画像をこのフォルダ内に格納してください):
2017012606


そして、以下のコマンドを実行すると public/images/ フォルダ以下にある画像を Watson に学習させます(上記の settings.js ファイルの編集を忘れずに行っておいてください):
$ node learnImages.js
imagelearn_xxxxxx

学習が正しく行われた結果、画面には imagelearn_xxxxxx という文字列が表示されます。これが collection_id と呼ばれるもので、後述の Watson API Explorer などでこの API を実行する際には必要になります。またこのコマンドの実行後に setting.js の最終行に以下のような1行が追加されているはずです:
exports.vr_collection_id = 'imagelearn_xxxxxx';


ウェブアプリケーションとして利用

では学習した内容を使った類似画像検索ウェブアプリケーションを作成します。今回は IBM Bluemix 上のランタイムとして作成するので、SDK for Node.js ランタイムを1インスタンス作成します:
2017012607


アプリケーション名は適当にユニークなものを指定します。この例では dotnsf-imagesearch という名前のランタイムを作っています:
2017012608



合わせてソースコードの manifest.yml ファイルを更新します。具体的には name と host 両方の値を、実際に作成するアプリケーション名と同じものにします:
2017012609


ここまで準備できたらアプリケーションをデプロイします。cf コマンドを使ってログインし、プッシュします:
$ cf login -a http://api.ng.bluemix.net/
   :
   :

$ cf push

しばらくするとアプリケーションの転送とステージングが完了して、ランタイムが起動した旨のメッセージが表示されます:
2017012601


この段階でアプリケーションにアクセス可能です。PCかスマホのブラウザでアプリケーションの URL (上記の例だと http://dotnsf-imagesearch.mybluemix.net/)を指定して開くと、このような画面が表示されます:
2017012601


「参照」ボタンをクリックして、類似画像の対象となる画像を選択します。今回は学習データの中に野球ボールがあったので、それが検索できるかどうかを調べる目的で、学習データとは異なる野球ボール画像を指定してみることにします:
野球ボール


画像を指定すると画面が暗転して、類似画像検索が行われます:
2017012602


しばらくすると結果が得られて画面の暗転が戻ります。画面を下にスクロールすると学習データの中の類似画像候補が指定数(デフォルトでは5)表示されます。一番左に野球ボールが検索できているのがわかります。まあこんな感じのウェブアプリケーションサンプルです:
2017012603


画像を学習する部分は learnImages.js で実装しています。学習時に与えるメタデータ(画像検索の結果と一緒に取得できるテキスト情報)の内容を変更する場合はこのファイルをカスタマイズしてください。またウェブアプリケーション部分は app.js で、そしてウェブアプリケーションの見栄え部分は public/ フォルダ内の index.html に依存しています。見栄えを含めたウェブアプリケーションの挙動の変更はこれらのファイルを自由にカスタマイズしてお使いください(ソースコードは MIT ライセンスで配布しています)。



なお、API Key や collection_id を利用して実際に Visual Recognition API を実行する場合は、こちらの Watson API Explorer をお使いいただくのが便利です。仮に作成した collection_id を一度削除するような場合はこの画面から DELETE を実行いただくことができます:
https://watson-api-explorer.mybluemix.net/apis/visual-recognition-v3

また、Watson Visual Recognition API の関数リファレンスはこちらを参照ください:
https://www.ibm.com/watson/developercloud/visual-recognition/api/v3/



ゆるキャラを画像で検索するサービスを作って公開してみました:
http://yuru.mybluemix.net/

まず最初に、自分はある程度ゆるキャラに詳しいと思っています。積極的な興味というよりは、マンホールに詳しくなっていると、最近はそのマンホールのデザインにゆるキャラが使われることが珍しくなくなってきたので、自然と(?)ゆるキャラにも詳しくなってしまうのでした。。
2017011500
 

さて、ゆるキャラに限らないのですが、イマドキ何かを調べようとした時にはまず『ググる』のが定番です。ただ、それは調べるためのキーワードが分かっている場合です。ゆるキャラの場合、名前が分かっていれば名前でググれば確実ですし、名前が分からなくても出身地とかが分かれば「ゆるキャラ 東京都」などで検索すればいくつか候補が見つかるのでそこから調べる方法もあります。

しかし問題は名前も出身地も分からず、検索するためのキーワードがない場合です。例えば目の前に着ぐるみそのゆるキャラ本体がいて、写真は撮れるんだけど、そのゆるキャラがなんという名前で、どこのゆるキャラで、どんな特徴を持っているのか、、、といった情報を調べる具体的な方法がなかったように感じていました。

といった背景もあり、「画像からゆるキャラを調べる」ことができるようなウェブサービスを作ってみた、という経緯です。いわゆる「類似画像検索」を行うため、コグニティブエンジンである IBM WatsonVisual Recognition API を使って実装してみました:
http://yuru.mybluemix.net/


使い方はシンプルで、ウェブサイトをPCかスマホのブラウザで開き、ファイル選択ボタンを押して、ローカルシステムやフォトライブラリ等から目的の画像を選択するだけです:
2017011501


PC の場合に限り、目的の画像ファイルを画面上部のこの辺りにドラッグ&ドロップしても構いません:
2017011502


例えばこの画像のゆるキャラを調べてみることにしました。まあ有名なヒトなので答はわかっているのですが、ちょっとトリッキーなアイテムも写っていて普段と違う画像になっているので、いいサンプルかな、と:
く


この画像を選択するか、画面内にドラッグ&ドロップすると画面が暗転して検索が始まります:
2017011503


暗転から戻ると、検索結果として候補キャラが画面下部に表示されているはずです。最大で100件表示されます:
2017011504


今回の画像の場合、下の方にそれっぽいのが見つかりました:
2017011505


該当する結果の画像をクリックすると、そのゆるキャラの情報がポップアップします。ご存知「くまモン」でした。なお PC であればマウスオーバーでも表示されます:
2017011506


まだまだ学習量が充分ではなく、第一候補となることはまだ珍しいとか、(着ぐるみの写真ではなく)絵の場合には精度が落ちるとか、横から写した画像に弱いとか、背景画像に左右されることが多いとか、まだまだ問題はありますが、一応動くものが作れたと思ってます。

実際の用途としてはある程度いけるかな、と思ってます。もちろん精度高く検索できることが理想ですが、上記で書いたように「名前が分かれば色々調べる方法はあるんだけど、肝心の名前が出てこない」のを解決するツールとして考えると、検索結果の候補の中に含まれていれば、それはそれでオッケーかな、と。


なお、今回のサービスは Visual Recognition の中では現時点でベータ版の /v3/collections/ で始まる API を使って開発しています。今後の仕様変更などがあった場合にサービスがどうなるか何とも言えませんが、なるべく対応させていく予定です。合わせてもう少し学習データの量を増やして検索精度を上げられないか、がんばってみます。


先日、IBM Bluemix から提供されている IBM Watson の翻訳 API である "Language Translator" サービスが待望の日本語対応を果たしました。現在、日本語翻訳機能としては英語→日本語、および日本語→英語のテキスト翻訳が可能になっています:
2016122808


この翻訳 API は文章の翻訳に加え、入力されたテキストが何語のテキストなのかを識別する機能も備えています。実際にどんな言語翻訳ができるのか、そのサンプル的なアプリケーションが以下で公開されているので、興味ある方は試してみてください:
https://language-translator-demo.mybluemix.net/

2016122809



さて、この IBM Watson 翻訳 API の特徴の1つが「カスタマイズ機能」です。デフォルトで提供される翻訳機能をベースに、自分なりのカスタマイズを加えることができるようになっています。これは日本語翻訳機能においても有効な機能です。

というわけで、早速カスタマイズを試してみましょう。ただし、このカスタマイズを使うには、Language Translator サービスは標準プランではなく、拡張プランを選択する必要があります。標準プランには無料枠が用意されていますが、拡張プランにはありません。サインアップから 30 日間の無料期間を過ぎていたり、既に有償プランに移行済みの場合は、サービスインスタンスを作成した段階でインスタンス料金が発生しますので、ご注意ください:
2016122801


では「拡張プラン」を選択していることを確認した上でインスタンスを「作成」します:
2016122802


こうして拡張プランの Language Translator サービスインスタンスを作りました。この後、実際に API を使うことになるので「サービス資格情報」の「資格情報の表示」からクレデンシャル情報を調べてメモしておいてください(繰り返しですが、拡張プランの資格情報です。流出すると勝手に使われて課金額がどんどん増えていくことになるので、取扱いに注意してください):
2016122803


次に実際にカスタマイズする内容を TMX(Transaction Memory eXchange) という翻訳メモリデータの標準フォーマットである XML ファイルで用意します。今回は以下の内容の osaka.tmx ファイルを手元で作って用意しました:
<tmx version="1.4">
  <header
    creationtool="MyTool" creationtoolversion="1.00"
    datatype="PlainText" segtype="sentence"
    adminlang="en-ja" srclang="en"
    o-tmf="MyTransMem"/>
  <body>
    <tu>
      <tuv xml:lang="en">
        <seg>Hello</seg>
      </tuv>
      <tuv xml:lang="ja">
        <seg>もうかりまっか</seg>
      </tuv>
    </tu>
    <tu>
      <tuv xml:lang="en">
        <seg>I am fine</seg>
      </tuv>
      <tuv xml:lang="ja">
        <seg>ぼちぼちでんな</seg>
      </tuv>
    </tu>
  </body>
</tmx>

(かなり偏見入ってますが・・)大阪弁のカスタマイズをするためのファイルです。英語の "Hello" を「もうかりまっか」に、"I am fine" を「ぼちぼちでんな」に変換する、という内容です。これを元々の英→日翻訳機能に上書きする形でカスタマイズする、という意味です。なお日→英の翻訳カスタマイズは今回の説明には含めませんが、同様にして(同様の TMX ファイルを別途用意する形で)カスタマイズすることは可能です。


これでカスタマイズの準備はできました。 が、カスタマイズの前に、カスタマイズ前の挙動を確認しておきます(後でカスタマイズ後の挙動と比較するためです)。ここからは curl コマンドを使って実際に API を使ってみるので、必要に応じてここなどから curl コマンドをインストールしておいてください。

まず最初に、Language Translator がデフォルトで用意しているモデル(日英とか、英日とか、英仏とか、・・)の一覧を取得してみます(username と password には上記の資格情報で取得したものを指定します。また黒字が入力コマンド、青字が出力結果です):
$ curl -u "username:password" "https://gateway.watsonplatform.net/language-translator/api/v2/models"

{
  "models":[
    {
      "model_id":"ar-en",
      "source":"ar",
      "target":"en",
      "base_model_id":"",
      "domain":"news",
      "customizable":true,
      "default_model":true,
      "owner":"",
      "status":"available",
      "name":"",
      "train_log":null
    },
      :
    {
      "model_id":"en-ja",
      "source":"en",
      "target":"ja",
      "base_model_id":"",
      "domain":"news",
      "customizable":true,
      "default_model":true,
      "owner":"",
      "status":"available",
      "name":"",
      "train_log":null
    },
      :
    {
      "model_id":"ja-en",
      "source":"ja",
      "target":"en",
      "base_model_id":"",
      "domain":"news",
      "customizable":true,
      "default_model":true,
      "owner":"",
      "status":"available",
      "name":"",
      "train_log":null
    },
      :
  ]
}

モデルの一覧が JSON 配列形式で出力されます。"model_id" の値が実際に翻訳する時やこの後のカスタマイズ時に翻訳の種類を指定する値になります。英日であれば "en-ja" 、日英であれば "ja-en" という値になります。

また各モデルの中に "customizable" という値があります。これは「このモデルをカスタマイズ可能か」を示した値であり、true になっているとカスタマイズ可能であることを示しており、このモデルに上書きする形でのカスタマイズが可能です(英日、日英ともに true です)。また "status" の値は現時点で利用可能な状態になっているかどうかを示しています(これも英日、日英ともに "available" となっているので使える状態になっています)。

ではカスタマイズ前の翻訳機能を試してみましょう。英語の "Hello" を日本語に翻訳してみます:
$ curl -u "username:password" "https://gateway.watsonplatform.net/language-translator/api/v2/translate?model_id=en-ja&text=Hello"

こんにちは

カスタマイズ前(model_id に既存の en-ja を指定)なので、期待通りの結果になりました。

ではここからはカスタマイズを加えてみましょう。上記で用意した osaka.tmx を指定して、以下のコマンドを実行します:
$ curl -u "username:password" -X POST -F base_model_id="en-ja" -F forced_glossary=@osaka.tmx "https://gateway.watsonplatform.net/language-translator/api/v2/models"

{
  "model_id":"be81b082-1292-47ac-badf-0beb83846f66",
  "source":"en",
  "target":"ja",
  "base_model_id":"en-ja",
  "domain":"news",
  "customizable":false,
  "default_model":false,
  "owner":"da0dc7f3-87c6-4d82-b965-79b463266291",
  "status":"dispatching",
  "name":null,
  "train_log":null
}

基本モデル(base_model_id)を英日(en-ja)にして、そこに osaka.tmx で指定した内容を上書きでカスタマイズする、という内容のコマンドです。実行結果には新しい model_id (be81b082-1292-47ac-badf-0beb83846f66)が付与されて返っています。また customizable 値は false になっているので、このモデルをベースに更にカスタマイズ、ということはできません。status は "dispatching" となっているので、この時点ではまだ内部処理中です。

少し待ってから再度ステータスを確認し、"available" となっていることを確認できたら翻訳も可能になります。
$ curl -u "username:password" "https://gateway.watsonplatform.net/language-translator/api/v2/models/be81b082-1292-47ac-badf-0beb83846f66"

{
  "model_id":"be81b082-1292-47ac-badf-0beb83846f66",
  "source":"en",
  "target":"ja",
  "base_model_id":"en-ja",
  "domain":"news",
  "customizable":false,
  "default_model":false,
  "owner":"da0dc7f3-87c6-4d82-b965-79b463266291",
  "status":"available",
  "name":null,
  "train_log":null
}

また、この段階でモデル一覧を再確認すると、カスタマイズしたこのモデルも一覧の先頭に含まれて表示されることがわかります:
$ curl -u "username:password" "https://gateway.watsonplatform.net/language-translator/api/v2/models"

{
  "models":[
    {
      "model_id":"be81b082-1292-47ac-badf-0beb83846f66",
      "source":"en",
      "target":"ja",
      "base_model_id":"en-ja",
      "domain":"news",
      "customizable":false,
      "default_model":false,
      "owner":"da0dc7f3-87c6-4d82-b965-79b463266291",
      "status":"available",
      "name":null,
      "train_log":null
    },
    {
      "model_id":"ar-en",
      "source":"ar",
      "target":"en",
      "base_model_id":"",
      "domain":"news",
      "customizable":true,
      "default_model":true,
      "owner":"",
      "status":"available",
      "name":"",
      "train_log":null
    },
      :
    {
      "model_id":"en-ja",
      "source":"en",
      "target":"ja",
      "base_model_id":"",
      "domain":"news",
      "customizable":true,
      "default_model":true,
      "owner":"",
      "status":"available",
      "name":"",
      "train_log":null
    },
      :
    {
      "model_id":"ja-en",
      "source":"ja",
      "target":"en",
      "base_model_id":"",
      "domain":"news",
      "customizable":true,
      "default_model":true,
      "owner":"",
      "status":"available",
      "name":"",
      "train_log":null
    },
      :
  ]
}

ではこのカスタマイズモデルを model_id に指定して、先程と同じ英語を翻訳してみます:
$ curl -u "username:password" "https://gateway.watsonplatform.net/language-translator/api/v2/translate?model_id=be81b082-1292-47ac-badf-0beb83846f66&text=Hello"

もうかりまっか

期待通りのカスタマイズが有効な変換結果になりました。なお "I am fine" でもカスタマイズした結果が翻訳されますが、それ以外の(カスタマイズしていない)テキストについてはベースとなっている英日翻訳が有効になって実行されます:
$ curl -u "username:password" "https://gateway.watsonplatform.net/language-translator/api/v2/translate?model_id=be81b082-1292-47ac-badf-0beb83846f66&text=I%20am%20fine"

ぼちぼちでんな

$ curl -u "username:password" "https://gateway.watsonplatform.net/language-translator/api/v2/translate?model_id=be81b082-1292-47ac-badf-0beb83846f66&text=Good%20evening"

こんばんは

カスタマイズモデルが不要になった場合は以下のコマンドで削除することができます:
$ curl -u "username:password" -X DELETE "https://gateway.watsonplatform.net/language-translator/api/v2/models/be81b082-1292-47ac-badf-0beb83846f66"

{"status":"OK"}

今回紹介したのはごくシンプルなカスタマイズでしたが、より多くの語彙を用意できれば方言や、或いは全く新しい言語の翻訳機能まで実現することができるかもしれません。そんなカスタマイズ機能が IBM Watson の Language Translator API には提供されている、という紹介でした。


なお、Language Translator API の詳しい関数リファレンスはこちらを参照ください:
https://www.ibm.com/watson/developercloud/language-translator/api/v2/

実際に挙動をためせる Watson API Explorer はこちら:
https://watson-api-explorer.mybluemix.net/apis/language-translator-v2#/


#TMX をもう少し楽に作れるツールとかないかな・・・


このページのトップヘ