機械学習ではないAIから始まった
みなさんは日頃AIと言えば、やれ深層学習だとか、やれ機械学習だとかのキーワードが飛び交っていて、AI＝ビッグデータ解析＆ニューラルネットワークが当然だと思っているかもしれません。
しかし、私はそれにあえてアンチテーゼを唱えたいと思っており、イベントや取材などでも度々言っていますが、スモールデータをAPIを使って検証するところから始めれば良いでしょ？と考えて今回の実装形態に至りました。
グローバル企業やゲーム企業など膨大なトラフィックを持っている企業ならいざしらず、殆どGoogleの定義するビッグデータを持っておらず、深層学習効果はありません。
そこで、既にアルゴリズム化され、最終的な戻り値のみとなったAPIにアクセスすることで、もっとライトに作れるのではないかと考えたのです。
改めてAWS Lambdaとは？
AWS Lambda（以下、Lambdaと呼称）とは2年ほど前に流行った、サーバレスアーキテクチャと呼ばれる、利用時間課金のソリューションです。使える言語は現在Node.js（JavaScript）、JAVA、Python、C#、Go Langの5種となり、日本人に人気の言語Rubyは現在のところSDKが準備されていません。
Lambdaはサーバレスコンピューティングを実現するために、EC2やLightsailに代表されるように空っぽのサーバに独自のAMIを用意しデプロイする必要はありません。最初から用意されている基盤に従い、SDKを使って「呼び出し」で動かします。
これは私が推奨するAPIエコシステムにも通じる概念です。サーバ自体をAPI化しているので、ごく少量のコードを書くだけで動きますが、メモリに限度があるためプログラムの同時実行数に限りがあり重すぎる処理には向いていません。
あくまで簡易的なバッチ処理などを行う事に向いています。
なぜ、AWS Lambdaを選んだのか
なぜ、私はAWS Lambdaを選択したのかというと、EC2に実装していたWebサービスから他社のAIソリューションが持っているAPIを呼び出す必要がありましたが、EC2が既に稼働しており、あまり実装上環境をいじりたくなかったためです。
そこで、EC2インスタンスを新たに立ち上げるとコストが掛かるというのもあって、前から興味があったLambdaでコストを安く実装できないかと思案しました。また、今回の実装はIBMとGoogleのAI APIを同時に呼び出す必要があったので、そのSDKを本番に仕込ませるのも影響を考えると嫌だったというのもあります。
影響範囲の検証という、事前調査の時間を取りたくなかったからです。一秒でも早く、AIで解析した結果を見て使えるのかどうかを確認したいと思いました。
そういう今までならばサンクコストになっていた余剰時間をカットすることで、設計から実装までに1週間も掛からず内部ローンチすることが出来ました。実際に動かすだけなら数時間でしょう。
まとめ
ここまでが、AWS Lambdaを使ったAIソリューションのあらましでした。深層学習を行う理由は、可視化出来ていない何かを見つけるための、アルゴリズムを探すための探求です。しかし、私たちのような既に業務で動いている人間からすれば、ある程度の粒度を持って答えが出ているのであれば、そのパラメータを引き出し、独自の「アルゴリズム」で答えを求める方が理にかなっているはずです。
また、今回行っている処理は自然言語解析と形態素解析であり、ある程度ライブラリがものを言う世界ですし、論文などの演算結果でもそのベクトルや積分の数式からして、すでにあるアセットを使うべきだと私は思っていますし、十分これまでの他の研究と引けを取らない結果が出ていると思います。
結局、道具なのですから使う側はもっと知恵を絞り効率的に答えを導き出していけばいいのです。では、後編ではもう少し具体的な実装について話をしたいと思います。