【フォースタテックブログ】タグの自動予測について。STARTUP DBに機械学習を組み込んだ話【前編】

f:id:forStartups:20211025162928p:plain

はじめに

こんにちは。テックラボの松原です。

先日（2021年3月18日）に、「STARTUP DB サービスリニューアル & ENTERPRISE β版リリース」をしました！

「国内スタートアップエコシステムのキャッシュフローの総量を増やす」というプロダクトミッションのもと、国内スタートアップとエコシステムビルダー、それぞれの信頼できるパートナーとの出会いを創出することを目指して、今回のサービスリニューアルを行いました。

サービスリニューアルでは、下記の機能が利用できるようになっています。

フリーワード検索機能
タグ検索機能
ENTERPRISE β版

※「 ENTERPRISE β版」について
スタートアップエコシステムにおける事業会社、投資家を中心としたエコシステムビルダーの方々と、国内スタートアップ、それぞれが信頼のできるパートナーとのマッチング機会の創造をサポートする機能です。

タグについて

上述しているように、リニューアルしたSTARTUP DBでは、「タグ」という概念が加わっています。

リニューアルしたSTARTUP DBをお使いの方はお気づきかと思いますが、タグが企業やサービスの説明文の下に付けられています。

以前のSTARTUP DBを使われていた方は、「あれ？？付いていたような？」と、思われるかもしれませんが、以前のSTARTUP DBに付いていたのは「カテゴリ」です。
リニューアルに伴い、「カテゴリ」を廃止し、今回から「タグ」という分類を行なうようにしました。

STARTUP DBでの「カテゴリ」と「タグ」の定義の違いは、後ほど説明します。

「タグ予測機能」について

エンドユーザーには、今のところ関係のない機能です。

STARTUP DBのデータは、プログラムで自動的に収集している情報もありますが、人の手でこつこつと入力していっている情報が大半です。

完全に自動化してしまわないのは、人的に行う部分を挟むことで、データの品質を保つようにしているからです。

そして、タグ（前カテゴリ）の付与は、そんな人的な作業が大きくかかる作業でした。

企業名、企業の説明、企業の役員、企業への投資、企業が提供するサービス等、企業に関する様々な情報を確認し、これらに適したタグを100以上あるタグの中から選び出すのは、それなりに骨の折れる作業です。

タグ予測機能は、そんな運用の作業を改善するために、実装した機能です。
（今後、この機能をどのように展開していくかは、まだ未定です）

カテゴリ廃止の決断

前STARTUP DBで使っていた「カテゴリ」は、以下の図に示すように、ツリー構造で、企業のサービスに紐付くデータ設計になっていました。

そのため、「医療」カテゴリで「AI」というサブカテゴリを使いたい、でも「農業」カテゴリでも「AI」というサブカテゴリを使いたい、というような要望を満たすためには、同じ名前のサブカテゴリを用意せざるを得ませんでした。

また、検索も「カテゴリ」→「サブカテゴリ」という検索を行うように画面が設計されていたため、横串な検索を素直に行えない状態にありました。

もちろん、力技でもできなくはないですが、リニューアルに伴い、データの構造を見直し、自由度の高い検索を簡潔に行えるようにしましょう、ということで、「カテゴリ」を取っ払い、「タグ」という、多対多の形を取れる仕組みにする、という決断がされたわけです。

タグ予測（機械学習）を実装する決断

タグの実装が決まってすぐは、タグ予測を実装するなんて話はもちろんありませんでした。

タグの実装を進めながら、一方で、どのサービスにどのタグが紐付くのか、それらを一覧にしていく作業の中で、「まだ、あと、8,000件…」と、時間を掛けたにも関わらず、出来高が乏しく…「今の作業だけでなく、今後の運用も考えると、自動でタグが付いてくれる仕組みがいるんじゃないか」という、我らがPMのお言葉により、タグを自動で付ける仕組みをつくってみましょう…！となったわけです。

方針設定

STARTUP DBは、サービスをローンチしてから約3年の月日が経ち、内部のデータも相当のものになっています。

ただ、データがいかに溜まってて、学習をさせる材料があろうと、すべてのタグを、狂いなく、人間が想定するとおりに、完璧に付けることができる程、（少なくとも私は）機械学習での精度を保証できないので、「管理画面でレコメンドが行われるようにする」という方針を立てさせてもらいました。

はじめにのおわりに

長い長いはじめにでしたが、この記事では、そんな「タグ予測」を、どのように実装していったかをお話していこうと思います。

仕組み

現在、この下に記すような構成で、タグ予測を行っています。

タグの予測

現在、タグの予測はこのように行われています。

①運用ユーザーが管理画面で、「タグ予測」ボタンをクリックします。

②企業のサービスの説明文が、アプリケーションサーバー（Flaskで稼働）に送られます。

③アプリケーションサーバーは、タグの一覧をマスタから取得し、タグ一覧と、分かち書きされたサービスの説明文を、SageMakerで作った推論用のエンドポイント（MLホスティングインスタンス）に送ります。

④MLホスティングインスタンスは、学習済みのモデルを用いて、タグと、分かち書きされたサービスの説明文をベクトル化し、それらのリストを、アプリケーションサーバーに返します。

⑤アプリケーションサーバーは、説明文のベクトルをクラスタリングし、各クラスター毎に平均合成したベクトルの算出を行います。その後、コサイン近似を用いて、平均合成したベクトルとタグのベクトルの近似値を求め、近しいベクトルのタグを管理画面に返します。

もっとSageMakerに寄せられる部分もあるんじゃないかと思う構成ですが、検討を行った時は、アルゴリズムの日本語対応の状況や、使いたい種類のアルゴリズムがないなど、いくつかの課題に引っかかり、このような構成になりました。

これも詳しい話は後ほど。

学習モデルの作成

MLホスティングインスタンスで使っているモデルは、以下のようなフローで生成しています。

①Wikipediaから学習を行うための圧縮されたデータを取得し、解凍します。

②解凍されたテキストの分かち書きを行い、ストレージに保存します。

③SageMaker上で分かち書きされたテキストを用いて、学習を行い、ストレージにモデルを保存します。

こちらの具体的な話は、後編にて。

検証開始

「企業で」機械学習を始めるとなった場合、まず、何から行えばいいのでしょうか？

このタグ予測の開発では、以下の優先順位で検証を進めていきました。

1. コグニティブサービス検証
学習済みのモデルが組み込まれており、値を与えると結果が返ってくる、機械学習のサービスを利用できるかどうか検証する。
2. 提供されているアルゴリズム検証
提供されているアルゴリズムを用いて学習を行わせ、モデルを作成し、そのモデルを利用して値を与えると結果が返ってくる仕組みを作り、想定の結果を得ることができるか検証する。
3. 独自でアルゴリズムから開発
目的に合致するアルゴリズム自体を開発し、学習を行わせ、モデルを作り、そのモデルを利用して値を与えると結果が返ってくる仕組みを作り、想定の結果を得ることができるか検証する。

今回の記事のミソになるのは、「企業で」というところだとも思っています。

優秀な機械学習のエンジニアは、やはり単価も安くはありませんし、社内にほいほい生まれてくるわけでもないので、「運用していく」ということを考えると、（インフラもそうだと思いますが）可能な限りマネージドなものを利用していくのが基本的には、是なのではないかなと思います。
（もちろん、会社のビジョンや、サービスの内容にも左右されるとは思います）

そういった理由で、タグ予測の検証を、上記した順に従って進めて行きました。

コグニティブサービス検証

昨今、AWSもGCPもAzureも、その他あらゆるサービスも、ある程度のことは、機械学習の知見がなくても、お手軽にできてしまうような機械学習のサービスを出しており、ゴリゴリ頑張らなくても、目的さえ合致してしまえば、できてしまったりします。

例えば、AWSの場合、以下のようなコグニティブサービスが提供されています。

Amazon CodeGuru（コードレビュー）
Amazon Rekognition（画像解析・動画分析）
Amazon Fraud Detector（偽アカウントオンライン不正の検知）
Amazon Comprehend（テキスト内のインサイトや関係性を検出）
Amazon Comprehend Medica（Amazon Comprehendのサービスを医療向けに特化したもの）
Amazon Textract（画像化された文書からテキストとデータを抽出）
Amazon Translate（テキスト翻訳）
Amazon Transcribe（音声認識）
Amazon Polly（テキストを音声に変換）
Amazon Lex（チャットボット）
Amazon DeepComposer（GANによる作曲）※専用キーボードが必要
AWS DeepLens（動画解析）※専用ハードウェアが必要
Amazon Forecast（トレーニングデータから時系列予測モデルを作成）
Amazon Personalize（トレーニングデータからパーソナライズと推奨のモデルを作成）

タグ予測においては、「単語や文章から、マッチするタグを見つけ出す」という処理を行いたいので、コードレビューや音声変換のサービスを利用する必要はないというのは言うまでもありません。

コグニティブサービスの説明に、さっと目を通した感じでは、「4. Amazon Comprehend」と、100歩譲って「14. Amazon Personalize」が使えそうかな、というアタリを付けて、この2つの検証をまず行いました。

Amazon Comprehend

AWSの説明を引用すると、「機械学習を使用してテキスト内でインサイトや関係性を検出する自然言語処理（NLP）サービスです。機械学習の経験は必要ありません。」というサービスです。

2019年の11月にプレスリリースで日本語が追加された旨が記されており、もしかすると使えるのではという予感のもと検証を開始しました。

結論。目的とは得られる結果が、絶妙に合致しませんでした。

このサービスは、文章内の単語が人名なのか、数量を表すものなのか等の、各フレーズの属性を分析してくれたり（Entity）、文章内の主要なキーワードは何なのかを見つけてくれたり（Key phrases）、文章の感情分析をしてくれたり（Sentiment）するのですが、これらの結果を利用して、タグを導きだす…というのがどうにも難しいなと…

例えば、上の画像は某サイトのHTMLのTEXTに対して、Entitiesを実行した結果ですが、確かに、それぞれのフレーズのTypeは分かります。

ですが、このQuantity、OrganizationのようなTypeが分かったところで、如何にしてタグへと置き換えて行くか、私の頭では繋がらなくて…断念。

Key phraseならば、出てきたKey phraseとタグをマッピングさせて、想定と近しいことができるのではと思ったのですが…

何か、そうじゃない。

与えるデータが悪かったのは、もちろん、そうなのですが、文章の主要なワードがでてきたところで、文章全体を表すワードを出せるとは限らず、結局タグとの紐付けで、もう一段階何かしらロジックが必要になるなと、こちらも…断念。

他にも、Amazon Comprehendの中には、「Custom classification」という機能があり、学習データを用意して、モデルを作成することで、独自の解析を行うことができるようなるのですが、これは日本語の対応がまだできておらず…

上の画像にあるとおり、タグとテキストの学習データさえ用意すれば、うまくできるかなと思ったりもしたのですが、言語の壁はどうしようもないところでした。

できたとしても、フレーズとタグの分類はできるかもしれませんが、文章とタグの分類はできなさそうですし、これも…断念。

Amazon Personalize

AWSの説明を引用すると、「Amazon.com がリアルタイムのパーソナライズされたレコメンデーションに使用するのと同じ機械学習（ML）テクノロジーを使用してアプリケーションを構築できます。ML の専門知識は必要ありません。」というサービスです。

ECサイトの商品のレコメンドと同じようなロジックで、タグ予測もできないかと考え、検証を行ってみたわけです。

結論。インプットさせるデータがうまく合いませんでした。

というのも、レコメンドを作成するために、下の画像のような、データの定義が必要になります。

つまり、文章のような非構造なデータのインプットがそもそもできないので、今回のデータとは合わないということになります。

私自身、レコメンドの開発に関わっていたことがありましたが、商品の購入履歴やユーザーの行動履歴など、構造化されたデータをその時も使っていましたし、非構造なデータでレコメンドを行うためには、全く違うロジックが要りますよねぇと…断念。

検証の結果

GCP、Azureなどのコグニティブサービスも試してはみましたが、同様に、日本語未対応が問題になったり、結果やインプットが合わないなど、タグ予測をコグニティブサービスで行えるようにするのは、現時点では難しいなと判断し、次の検証を進めることになりました。

提供されているアルゴリズム検証

提供されているアルゴリズムと曖昧な書き方をしましたが、今回利用を検討したものは、Amazon SageMakerに組み込みで提供されているアルゴリズムです。

Amazon SageMakerは、AWSの説明を引用すると、「ML 専用に構築された幅広い一連の機能をまとめて提供することにより、データサイエンティストとデベロッパーが高品質の機械学習 (ML) モデルを迅速に準備、構築、トレーニング、およびデプロイするのを支援します。」というサービスです。

つまり、これだけ使えば、機械学習で必要なあれこれがすべてできますよ、というサービスです。

SageMakerは、デフォルトで以下のようなアルゴリズムを提供してくれています。
それ以外にも、AWS Marketplaceから、アルゴリズムを買うこともできるようになっています。

ベクトル化を行う「Object2Vec」もしくは、テキスト分類を行う「BlazingText」が、今回の目的に合致するのではないかと考え、この2つの検証を進めました。

Object2Vec

AWSのブログ（https://aws.amazon.com/jp/blogs/machine-learning/introduction-to-amazon-sagemaker-object2vec/ ）の説明を読むのが正確ですが、簡単に例えると、「リンゴ」と「ミカン」をインプットにして、ラベルを「果物」として学習させれば、2つの情報から分類ができるモデルが作成でき、「ラーメン」と「蕎麦」をインプットしてラベルを「1」、「ラーメン」と「リンゴ」をインプットしてラベルを「0」として学習させると、2つの情報の類似度を推論するモデルが作成できる、というようなアルゴリズムです。

画像引用元: https://aws.amazon.com/jp/blogs/machine-learning/introduction-to-amazon-sagemaker-object2vec/

ラベルと2つのインプットが必要になるので、用意するデータはこのようなフォーマットになります。

{"label": 1, "in0": [774, 14, 21, 206], "in1": [21, 366, 125]}

タグ予測の場合だと、以下のような学習を行うことができるかと思います。

① Skip gram（https://towardsdatascience.com/skip-gram-nlp-context-words-prediction-algorithm-5bbf34f84e0c）のように、「文」と、「その周辺の文」をインプットとして、「タグ」をラベルにする。
（参考: https://hironsan.hatenablog.com/entry/object2vec-training-by-japanese-dataset）
②「タグ」と「文」をインプットとして、ラベルを「0〜1」（類似度）にする。
設定済みのタグと、企業のサービス情報をSTARTUP DBから抽出し、①②の方法で学習させ、検証してみました。

結論。精度が出ませんでした。

Object2Vec自体は汎用性の高い、良いアルゴリズムだと思います。
しかし、単語レベルなら精度も出たかもしれませんが、やはり、文章というのが多様すぎるためか、学習させるデータが圧倒的に足りない、という印象でした。

データをこつこつコツコツ作ってて精度を上げてくことも考えましたが、もっと上手く解ける方法があるのではないかと、他を模索することにしました。

BlazingText

BlazingTextは、word2vecを行う行うアルゴリズムです。

word2vecに関しては特に語る内容もないかなとは思うので、説明はこれだけです。

結論。これを採用してできるようになった、というわけではないですが、最終的にはこのアルゴリズムを全体の仕組みの中に組み込みはしました。

検証の結果

直接的に、企業の情報とタグを紐付けられる都合の良いものはないのだと思い知らされることになりました。
ただ、アルゴリズムが単に合わないということだけではなく、これらの検証をやる中で、目的に対して、データの総量が多いように見えて少ないことも、上手くいかない原因だということが見えてもきました。

STARTUP DB内部のデータだけで学習用のデータを作って推論させるというのは、少し無理があるのだと。

推論を行わせるためにどういうデータを準備すべきか、少ないなら少ないでどういうロジックを組めばいいか、もう少し検討する必要がありそうだ…という知見を得てからの、次の段階、独自での実装の始まりです。

前編のまとめ

運用を考えて可能な限りマネージドに…と最初に書きもしましたが、そうは問屋が卸してはくれず、完全に満足する結果が得られないから、結局、独自に実装しないといけなくなる、というのが、今なんだろうなと思わされました。

後編では、実際に今動いている仕組みの内容を、詳しく説明していこうと思います。

後編に続く

for Startups Tech blog

このブログのデザインを刷新しました。（2023/12/26）