「VALUENEX Radar Fusion」β版開発の裏話≪前編≫
VALUENEXでは、先日、「VALUENEX Radar Fusion」β版のテスターの募集を開始しました。Fusionのアルゴリズム開発までの道のりや、Webアプリケーションとしての実装の体験談など、先進情報学研究所の大﨑敏郎さん、開発部の麻生真吾さん、営業部の中山舞さんにお話を伺いました。
とても濃い内容になっているので、アルゴリズム開発編とWebアプリ開発編の前後編でお送りします。
「VALUENEX Radar Fusion」β版(以下、Fusion)とは？
特許×論文のような異種データの融合マップ解析・大規模データ分類マップ解析を可能にするアルゴリズムで、これまでVALUENEXがコンサルティングサービスのみでお客様に提供していたものを、ユーザー自身でご利用いただけるようにプロトタイプを実装したものです。
Fusionは、もともと大﨑さんがクライアントワークで使用していたプログラムが始まりということですが、これまでの道のりについてお伺いできますか？
大﨑さん クライアントワークでVALUENEX Radar(以下、Radar)を使っていて、いろんな分野の特許や論文の大量の情報を解析していくうちに、俯瞰図でくっきりと領域を分けたり、もっとこれ以上に大量の文献を解析できるようにしたいという風に欲が出てきたんですよね。そんな中でディープラーニング分野の分析を行った際、当時はディープラーニングの領域では画像処理が中心の時代だったんですけど、言語処理の領域がいくつか台頭してきていて、その中の1個にトピックモデルという領域が出てきました。僕はトピックモデル自体その時初めて知ったのですが、「ディープラーニングの中でこんなに領域ができるならきっといい技術に違いない！」と興味を惹かれ、色々なネットの情報とかを調べて作っていったら意外といいものができたという感じです(笑)。
Radarだと自分で調整できるのはインプットのデータか出力のオプションなので、真ん中のプログラムが調整できなくて、自分が思うような結果を得られるようにトピックモデルを使ったプログラムの調整を試していきました。トピックモデルでも、インプットを変えるとか出力加工しなければならないところもありますが、中身も直接変えられるっていう魅力があって、それで意外と楽しくなったんですね。
さらに、以前から論文と特許を混ぜて調査したいという要望を受けることがあってそれにもいろいろと試行錯誤してました。実際、受託調査案件でトピックモデルを使ってどんどんチューンアップしていって、良いものになっていったかなと。
最初は、それまで扱っていたような論文だけ、特許だけのデータだったら、少々トピックモデルのパラメータチューニングを変えても俯瞰図が変わりませんでしたので、それならこれは安定だと思って、同じ気持ちで論文と特許を混ぜてやったら、今まで通じたパラメータでは、ことごとくぐちゃぐちゃの図が出たんですよね。
そこで、これまでの経験と勘を頼りにパラメータのチューニングを繰り返しました。パラメータの数が多すぎるので論理的にやろうとすると、うまくいかなくて、ある程度は論理的に展開して、 行き詰まったら論理的に考えるのはやめて、非論理的に感覚的にトライして、こっち側いじってないから調整してみよう…と試しました。この感覚ができたならば、もうちょっと論理的に考えて展開できるだろうというのを繰り返して、ようやくあるパラメータセット群を見つけました。トピックモデルのパラメータチューニングにここまで熱を上げてしつこくやったのはきっと世の中探しても僕くらいだと思ってます(笑)
このパラメータセットのすごいところは特許と論文を混ぜたテキストデータだけでなく、論文だけ、特許だけのデータベースでもきれいに出すことができるんです。これがFusionとしてASPサービスで提供するものです。
Fusionには他にも利点があって、より大規模な計算ができるんですよね。Radarでは文章に現れる単語1つ1つを計算して細かな違いを表現する分、大量の情報を計算するので計算コストがかかります。1万ワード出てくれば1万次元のベクトルで類似計算をしているんですね。一方でトピックモデルではワードを組み合わせてトピックという上位概念にまとめることによって、Radarで処理するよりも次元を下げて、千次元とか、1/10くらいのベクトルで計算が可能になるんです。計算に使用するメモリが一桁以上、節約できます。
上位概念のトピックを使っているサービスは他でもあまり見かけないのですが、ワードレベルで処理していると大量の計算ができず、計算する文献の量をかなり絞り込むか、抽出する情報を捨てるしかなくなってしまいますが、Fusionは文献数を絞り込まず情報を捨てず処理できるので、大規模データの解析でもかなり細かいところまで結果として出てると 僕は思ってます。
そのような経緯で大﨑さんが改良に改良を重ねていたFusionですが、コンサル案件だけでなく、ASPサービスとして商品化しようということになったのでしょうか？
大﨑さん これは営業部の中山さんのご協力の賜物と思っています。僕から開発の麻生さんに直接コンタクトしたいなと思いつつ、 もごもごしてるうちに、いつの間にか中山さんが手配してくれてた！
中山さん そうですね(笑)麻生さんにASPとして実装を相談する前にもいろいろありまして…。
そもそも以前から大﨑さんはトピックモデルの成果を社内で度々発表されていました。私はデータサイエンスとかド素人なのですが、大﨑さんのチームはデータサイエンスの素養があって、そのチームでの実案件での実績があるのは一定の信頼ができるプログラムなのだろうと思っていました。
私が入社した時にはすでにリモートワークが始まっていたのですが、よく大﨑さんはオンライン会議とか、たまの出社とかでよく話をしてくれて。その雑談の中で、大﨑さんが「トピックモデルを商品化したいけど、難しいかな」とおっしゃっていて。実績もあり、かつ大﨑さんのようなこの会社で長年努力されてきた方がやりたいことができないのはもったいないと思い、「やってみましょうよ！」と動き出しました。
社内で検討した中で、商用化は難しそうという意見もありましたが、まずは社内のコンサルメンバー数人と検証を行いました。受託調査の実績はあるものの、”お客様にとって”使いやすいのか？本当にメリットかあるのか？という検証です。検証方法は、同じ母集団でトピックモデルとRadarのアウトプットのメリット・デメリットを比較するものでした。
検証の結果、トピックモデルは明確な技術分野の分類ができることや領域内文献のカバー率が高いことから、技術を分類しつつ全体像を把握する目的や、技術領域内の情報を集計して分析を行う方には情報の漏れをより少なくできることが分かりましたので、トピックモデルはそのようなニーズに応えられると分かりました。実際、Radarを使い始めのユーザー様からどのように領域を分ければよいか？という質問がよくありました。
さらに、特許と論文を混ぜて1つのマップに落とし込むことはできないか？という問い合わせも。皆さん新しい分析手法を求めているんですよね。
私も社内で検討を進めつつ、大﨑さんが声をかけたお客様にご関心いただけたことで商品化に向けて大きく動きだせるようになったので、 最後のきっかけは大﨑さんが掴んでいただいたのかなと思っています。
大﨑さん 中山さんの社内の方を巻き込む力があってこそだと思ってます。
そしてお客様に使っていただきやすく提供するためには麻生さんのお力が欠かせませんでした。
ある時の社内全体会議で麻生さんがツール共有プラットフォームの構想を話していたのを聞いて、「面白そうだな、僕のトピックモデルもこれでできないかな」という思いはあったのですが、なぜだかもじもじしてしまって(笑)中山さんを通じてお願いしたらあっさり「できます」と言ってもらえて「ああ、助かった」と思いました。
中山さん その話は後編で(笑)
以上、大﨑さんのアルゴリズム開発秘話をメインにお届けしました。
後編では麻生さんによるWebアプリケーション開発のお話をメインに、Fusionの名前の由来についてお伝えしますので、ぜひ、後編もご覧ください。
カジュアル面談も随時受け付けてます！
この記事が気に入ったらサポートをしてみませんか？