AWS Startup ブログ

【開催報告&資料公開】ML@Loft #6 × MLPP #4 – 自然言語・レコメンド・時系列解析

ML@Loft #6 × MLPP #4 「自然言語・レコメンド・時系列解析 」

AWS 機械学習ソリューションアーキテクトの宇都宮 ( Twitter: @shokout ) です。本ブログでは ML@Loft 第6回 x MLPP 第４回「NLP/レコメンド/時系列解析」の開催概要を報告いたします。

ML@Loft は、 機械学習を AWS 上でプロダクション運用しているデベロッパー・データサイエンティストのためのコミュニティイベントです。毎月テーマを設定し、前半は各分野のエキスパートの方々からの LT、後半は機械学習のサービス導入のノウハウや様々なツラミについて、LT のご講演者の方々を交えて参加者全員参加型のお悩み相談ラウンドテーブルという構成で AWS Loft Tokyo にて実施しています。次回の ML@Loft #8 は「量子コンピュータ x 機械学習」をテーマに 11月20日 (水)開催予定です。

今回は Machine Learning Production Pitch とのコラボレーション企画として、前半は4名の方の LT 登壇、後半は slido で集めた参加者の皆様からのフィードバックを元に、パネルディスカッション形式でのお悩み相談会を行いました（第4回 #MLPP × 第6回 #MLLoft まとめ: Togetter）。企業研究所で基礎研究からビジネス応用へアプローチされている富士通研究所の梅田さん、NLP・レコメンドといった機械学習を用いて to B のサービスを研究開発されているエムスリー株式会社の河合さん、ストックマーク株式会社の押条さん、TIS株式会社の久保さんに、 研究開発現場での機械学習活用におけるリアルな課題とその解決方法をお話しいただきました。

1.LT ライトニングトーク

梅田 裕平 氏 (株式会社富士通研究所) 富士通研の時系列データ解析技術

https://drive.google.com/file/d/1_lquq3VhYL0XWlzTP3H7zbozgiU1WIKn/view?usp=sharing

株式会社富士通研究所の梅田さんより、富士通研の人工知能研究所での研究について、企業で研究を行う際のプロセスや課題などを交え、時系列データ解析技術の研究のご紹介をいただきました。研究を３つのレイヤーに分けると、ごく稀に誰も見たことがない新しいものが生まれる Theoretical な研究、そこそこ定期的に改良・発展的なものが生まれる Methodological な研究、サービスやお客様の要望を元に、様々な手法をとにかく組み合わせて 、個別のすごいものが気がつけば生まれるExperimental な研究といった分類ができます。梅田さんの理論的な研究は、Experimental な世界での成果を保証できるよう理論を作ることが重要なミッションですが、なかなかうまくいかないのが現状で、 やっていることはかなり黒魔術的だけれど，理論的には明確なのでうまくハマれば白くなることもあるそうです。研究所では色々な人と話をする機会も多く、ちょっとした会話のきっかけが研究テーマを実応用へ繋げる黒魔術を産むことがあるとのことで、梅田さんが取り組まれていた TDA（Topological Data Analysis）を例に理論研究の話をご説明いただきました。

TDA はデータ解析の手法です。データ解析では統計を用いるのが一般的ですが、 データの分布が事前にわからない場合や分布が仮定に合わない場合では、統計手法がうまく適用できないという課題があります。TDA は、データの分布自体をそのまま捉えてしまおうという幾何学的なアプローチです。梅田さんのバックグラウンドが幾何だったこともあり、趣味で始めたこの TDA でしたが、天の声（会社の方針）で画像以外の DL の研究をやる指示が与えられた際、たまたま思いついたのが、複雑な時系列データの特徴量を、TDA を用いることで機械学習などの処理がしやすくなるという手法だったそうです。時系列データをアトラクタという形で図形化し、アトラクタの情報をベクトル化するという二段階で変換します。TDA の強みとしては、IoT データなど個人差が多いデータに汎化性能があり、ノイズにも強い、といった特徴があります。

実際に適用を試みた例として、橋梁の内部損傷の推定と、不整脈分類をご紹介いただきました。橋梁の損傷推定のために、表面に取り付けた加速度センサーからデータを取得し、内部の損傷や劣化状態を推定します。アトラクタに変換し、TDA で特徴量を解析、機械学習で分析すると、故障の時系列データが分類できたそうです。また、パッチをあてて診断する不整脈の検知についても、TDA の特徴量と従来の特徴量を組み合わせ CNN で学習することで、謝判定率を７割低減できたそうです。実際は TDA を使いこなすには梅田さんのような専門知識が必要で、 この技術をビジネスに移行するために、どのように誰でも使える技術へ展開していくのかが難しい課題だそうで、どうやって継続して黒魔術を生み出すのかと合わせて、研究所の技術をどのように事業会社や本体に引き渡していくかという企業研究所に共通する重要な課題を、TDA の事例から分かりやすくお話しいただきました。

河合 俊典 氏 (エムスリー株式会社) ゼロベースからの論文レコメンドシステムの構築

【ML@Loft #6】ゼロベースからの論文レコメンドシステムの構築

株式会社では日本最大級の医療専門サイト m3.com で、製薬企業のプロモーションや医療ニュース、医療従事者向けの転職サービスなどを提供されています。アルファツイッタラーばんくし（Twitter: @vaaaaanquish）さんこと、エムスリー河合さんからは、医療従事者向けの論文レコメンドシステム 「CIWorks」 についてご紹介いただきました。オンコロジー領域（がん領域）に絞り、レコメンドを用いたフィードやメルマガの提供により、 医師をはじめ、製薬企業の MR、MSL 向けの医療情報勉強用に使われています。レコメンド要素としては、最新の論文、研究分野、実験や被験、症例報告、患者ベースでのサーベイ、学会やカンファレンスとの結びつきなどがあり、レコメンドエンジンの要件としては、ユーザーの興味や技術レベルにパーソナライズできること、年間数万件の最新論文に対応する必要があります。

医療論文のレコメンドの課題としては、分野の重なりの大小、希少疾患、ワードの揺れ、略語の重複などがあり、その課題に対するエムスリーで提供するレコメンドシステムの詳細をご紹介いただきました。 レコメンドエンジンとしては、医師の興味ワード群を抽出し、Content-Based Citation モデルを作成、Rerank 処理をしてから TOP k を返す、という構成です。特に糖尿病や癌などは複数の合併症を持つこともあり多くの論文にその単語が使われているため、Content-Based のレコメンデーションを使っています。まず、医師の興味ワードの生成については、医師と論文の名寄せを2値分類でモデル化し、 Label Propagationを用いて興味ワードの作成を行います（詳しくはこちら）。興味ワードをもとに、検索エンジンとしてはelasticsearchのWAND検索を用いて、過去論文をもとに500万件超から条件を設定して検索して1000~10万件に絞り込みます。1000件程度なら10μs程度で検索できるため、フィードや検索ランキングでの動的レコメンドに対応させています。Content-Based Citation Recommendation では、Phase1 では citation 情報を元に、query 論文と近い candidate 論文を、 triplet loss を使って embedding から検索し、Phase2 ではそれらの reranking として title, abstract, author, journal keyword, text intersection を追加し、query 論文と近い論文をランキングして Top N を出します。これにより、elasticsearchとは別に、クリック情報など外部のメタデータなしでquery に近い論文を出す仕組みを作っています。ElasticsearchとContent-Based Citation の二つの結果から、ユーザーの興味に近い論文が上がっていると仮定し、最後に更に Rerank 処理を行います。Cold start を考慮して論文から取得できる title, author などを用いてスコア化し、ユーザーの興味のある単語に紐づく論文+過去に医師が書いた・クリックした論文を、PageRank とクリックによる Co-occurrence matrix でランキングして Top k を出力します。

評価については、編集部にアドバイスをもらうほか、SNS やニュースなどでの話題をスコア化した論文評価の指標である Altmetric も使っています。引用数の遷移を時系列として評価できるように、エムスリー OSSの「gokart」を用いてパイプライン化なども行なっています。様々な ML アルゴリズムを用いており、今後は溜まってきたユーザーの PageView データも用いて CTR、MRR、MAP などを算出し、各モデルのオンライン学習化など改善に努められればとのことです。

押条 祐哉 氏 (ストックマーク株式会社) 社内の XX に詳しい人を知りたい

Mlpp #4 & mlloft #6

ストックマーク株式会社は自然言語処理に特化した AI スタートアップで、to B向けのニュースやナレッジ共有のプラットフォームサービス Anews など３プロダクトを提供しています。Anews はビジネスニュースの配信を行っており 、チームの人が読んだ・関心がある記事を、メンバーがつけたコメント付きで読むことでチームの共通地をアップデートするサービスです。かえるるるさん (Twitter: @kaeru_nantoka) 改め、ストックマーク押条さんより、Anews の刷新にあたり、特定のキーワードやニュースで検索した際にその分野に詳しい社内人物を推薦するエンジンを実装したお話ご紹介いただきました。大企業では社員数が特に多く、誰が何に詳しいかなどが体系化されておらず、わからないことを誰に聞けば良いかわからない課題がよくあります。Anews では、解決したいビジネス課題として、「Who Knows What? の可視化」に取り組まれています。

Anews で利用できるデータは、Raw data として Text（記事の本文、記事のタイトル文、記事の URL ）と、Table（記事のメタデータ、ユーザー情報データ、ユーザーのアクションログデータ）、Preprocessed data として記事ベクトル（fastText）とユーザーの嗜好ベクトルデータがあります。Anews に使う推薦アルゴリズムは、大きく分けるとユーザー集団のアイテムに対する評価を元にレコメンドする（Amazon や Netflix など）協調フィルタリングと、アイテムの特徴ベクトルを類似度計算してレコメンドに利用するコンテンツベースがありますが、今回はユーザーの推薦に向いている、コンテンツベースを採用しました。コンテンツベースではドメイン知識に基づくユーザーのベクトル化が課題になりますが、今回は、記事レコメンドで既に使用していたユーザーベクトルを用いて、ユーザーベクトルと記事ベクトルの cos 類似度ベースのスコアを元にコンテンツベースを用いました。ユーザーベクトルとしては、過去 N 日間に読んだ記事を球面 k-means でクラスタリングして、記事数が最も多いクラスタのセントロイドをユーザーベクトルと定義します。これをオフラインのバッチ処理で行い、DynamoDB に格納します。一方記事ベクトルは、各記事のタイトルの最初の導入の名詞数単語をビジネスニュースで学習したストックマーク社独自の fastText でベクトル化し、オフライン処理として Elasticsearch DB に格納します。

機械学習インフラとしては、上記のバッチ処理とオンライン処理の二つのプロセスに分かれてレコメンド処理を行っています。時間のかかるユーザーベクトルの生成や記事ベクトルの生成はオフラインで実行し、Elasticsearch や DynamoDB に格納します。ユーザーが Anews を利用する際には、機械学習 API で用いるクエリのベクトル化と、 類似度計算、スコア化のところはリアルタイム処理を行っています。

これらの手法の中で、ユーザーベクトルをどうすべきか、というところは、まだまだ課題が多いそうです。初版は記事配信に使用していたものを流用しており、ある程度ワークするものも、記事を読んでいないユーザーへの適用や、未使用だが使えるデータの検討、といった課題があります。また、評価については A/B テストやオンラインテストなどをも検討中で、指標の定義もまだ改善の余地があるとのことで、後半のディスカッションでも是非議論されたいと、お悩み相談のテーマの提言をしていただきました。

久保 隆宏 氏 (TIS株式会社) ESG評価を支える自然言語処理基盤の構築

ESG評価を支える自然言語処理基盤の構築

次の LT は「老後の2000万円心配してません、って方どのくらいいらっしゃいますか？」という piqcy さん（Twitter: @icoxfog417）こと久保さんの問いかけから始まりました。TIS株式会社にて、久保さんは現在、自然言語処理を会計/投資の現場で役立てるべく、主に ESG 投資への活用をテーマに研究をされています。今回の発表では、年金の運用でも考慮されているESG評価を支援するための自然言語処理基盤について解説いただきました。ESG は環境 (Environment)・社会 (Social)・ガバナンス (Governance) の頭文字で、単に売上や利益だけでなく、これらの３要素に関する取り組みを評価する投資のことを指し、現在は人が文書を読んで評価を行うことが多いそうです。2019年現在、80兆ドルを超える資産がESGを加味して運用されており、日本の年金（厚生年金・国民年金）の運用を担う GPIF（年金積立金管理運用独立法人）でも ESG を考慮しています。

ESG 投資を考慮する方法として、ESG 評価が低い企業を除外するネガティブ・スクリーニングや、評価が高い企業を組み入れたり比率を上げたりするポジティブスクリーニング、通常の投資基準（経営方針や財務など）に ESG を考慮するインテグレーションなど、全部で７つの手法があります。MSCI ESG Ratings、FTSE Russels ESG ratings、Thomson Reuters Asset など、様々な評価機関がスコアを算出・公開しており、これらのスコアをベースに ESG 投資が行われています。しかし、評価機関ごとのスコアに相関がないこと、評価を人手に頼っており属人的であることなどが課題になっています。大規模な資金の運用に使われている評価の課題を解決したいという思いが、本取り組みの背景にあります。

自然言語処理による支援として1. 文書データの収集（CSR・統合報告書・有価証券報告書など）、2. 評価対象となる文・段落の絞り込み（評価対象となるテキストデータ項目の抽出、 文書データの整形・整理、PDF のテキスト化など）、3. 自動評価（自然言語処理モデルによる文章データの学習・フィードバック、抽出された対象データの自動評価）３つのアプローチに取り組まれています。

文書データの収集については、AWS を使って、Lambda で一覧を取得、各文書は SQS と Lambda を使い並列で取得、一連の処理を Step Function で実装しています。収集した決算書・CSR 報告書・統合報告書のデータは決算数値・株価などと合わせて Athena のビューで見られるようにしています。作成された過去５年分のデータは近日無償公開！とのこと。これまでの企業文書の分析は、キーワードの分析や文章のポジネガ判定などしかできておらず、その傾向がどう売上や株価に結びつけるかまでは分析できていなかったため、これがあれば、企業がどのような報告書を書くと売上の傾向や株価の変動に影響するのか、など分析に利用できるとのことで、乞うご期待です。

上記のケースをもとに、AWS 上でのデータ収集基盤構築のTipsを共有いただきました。

  1. データを集める場合は SQS + Lambdaが 、データを見る場合は Athena が便利。
  2. Lambda を呼び出せる Step Functions か 公式 ETL である Glue を使うべきか？→ 基本は Step Functions で構築し、Glue Crawer を呼ぶ方法が便利。
  3. 処理の軽重や使用ライブラリの重さで Lambda か ECS を使い分ける。

最後に、自然言語処理による文書解析の課題として、ESG 評価のメイン～のレイアウトが各社各様で解析しづらいという点があります。今後、適切なデータの収集、専門知識に基づくアノテーションデータの生成、プロトタイプ開発、提案モデルの営業など、プロダクトに NLP が登場するまで、長いプロセスが見込まれることをお話しいただきました。

2. お悩み相談パネルディスカッション

今回は、参加者が多かったこともあり、お悩み相談会は、会場からの質問、ディスカッションしたい項目を slido で募りながら、パネルディスカッション形式で行いました。多くの質問を寄せていただき、その中でいくつかをピックアップしながら LTer の方々にお答えいただく形式で、後半の時間も大変盛り上がりました。

Q.    業務で時系列解析をするときに手法の選択をどうしていますか？ TDA for time-series  興味深いです。 SARIMA などの古典的手法、LSTM などの深層系列モデルなどと比較したときの利点・欠点などをお伺いしたいです。

（梅田：回答者、以下敬称略）予測モデルに使う SARIMA とか LSTM とは、設計モデルや自然言語とか、利用用途が異なっている。TDA は、分類や異常検知とかについては、いろんな特徴を含んでいるからやってみないとわからない。単純な特徴から複雑な特徴まで、どれが用途にハマるかはやってみないとわからない。

Q. 機械学習チームの開発方法論って確立してきていますか？実際どうやってますか？

（押条）３つのプロダクトに分かれてエンジニアがアサインされていて、方法論は個々人に依存している。

（河合）会社によるし、開発の部分にもよる。ML やる場合のベストプラクティスは、再現性の部分を担保する考え含め、徐々に確立してきていると思う。他社事例だと Jupyter で開発してプロダクションに入れたりとか。エムスリーではパイプライン OSS をつくっていて、ML 環境としては、出揃ってきている。

（梅田）研究所の場合は、ML 研究環境については現状個々人に依存するところが強い。ただ、大きな会社なので、環境の統一化は大事だという声は出てきており、環境構築の情報共有含めまさに議論しているところ。

（久保）ML 開発手法の文脈によって揃い方が違うのでは。

  1. BI など、ML を分析ツールに使いたい場合
  2. プロダクトに価値を与えるための文脈（プロダクトマネージメント）
  3. すでに運用されている機械学習モデルの開発/デプロイプロセスを高速化したい場合

などがあり、例えばこの３つのケースだと、３の MLOps については比較的情報が充実してきていると思う。

Q. 会社の ML 研究開発チームにいて、モデル作成を含む ML エンジニアデータサイエンティスト的な仕事を期待されています。フロントエンドやバックエンドも含めてプロダクトの作り上げまでやりたいが、会社としてはプロダクト開発は別部署の仕事と切り離され、言われて歯がゆい場面があります。どこまで ML リサーチャやエンジニアが関わるべきでしょうか？

（久保） 自分自身はフロント開発、インフラと ML エンジニア、営業も含めて担当している立場。そもそも何を作るべきかかなど、わかっていないと難しいので、基本的に全部に携わっていた方がいいと考えています。

ビジネス KPI の計算式の中に、機械学習モデルの精度がどう組み込まれるのか意識して開発を行うためにも、ある程度広く知っておくことは非常に重要。その齟齬があると、思っていたものが違うプロダクトができてしまうリスクがある。

（梅田）研究やっている身としては、難しいなと思う。頭から最後まで一人でやれるに越したことはないが、企業体が大きくなるとそれをやっていたら回らないというジレンマもある。

（河合）前職時代は大きな企業体で、確かに完全分業制だった。今のエムスリーでは80人くらいの規模で、全員が頭から最後まで見てプロダクトに携わることができる。ただ、一人で関わることが多く属人的になってしまうと、サービスが止まってしまうリスクもある。

（押条） ストックマークでは、エンジニアは20人ほど、なので分業しすぎたら回らないため、一人の担当範囲が広くならざるを得ない。会社の規模感やプロダクトのステージとかの話もあったが、会社の規模や事情で役割が決められているとすると、ある程度は仕方ないのでは。

Q. 研究所出身なので、自分自身も同じ悩みを持っていると思います。研究所の事業貢献ってどう思いますか？

（梅田）事業化する為には、ものすごくたくさんステップがある。富士通本体に、使える技術であることをわかってもらえる必要がある。また、富士通本体からさらにお客様へ PoC など通して使えることを伝えていくプロセスがあり、事業化にする為にもっと効率良くするには今のやり方をどう変えるべきか？という課題もある。

Q. ML 系のアルゴリズムを AB テストに載せるかどうかの判断をどのようにしていますか？

（河合）最近はABテストの評価について考える機会が多いです。オンラインで AB テストの際は目的を一つに絞り、それを最適化するためのオフライン評価の指標はたくさん持つこと、というのを大事にしている。RecSys 2019 という国際学会で、とてもいい評価指標というのは、そこが目的になってしまうと良い評価指標でなくなるということを言っていた方がいて、その通りだと思った。評価が決まっていると AB テストに載せやすい。

（久保）うちではまだ研究要素が多く産みの苦しみの段階で、AB テストまで行けたら万々歳というところ。強化学習（多腕バンディットなど）などでの AB テストの話を聞くことも多いが、1%からレートをどんどん上げていくことが多いと聞いている。オフライン評価が悪いからオンライン評価も悪いわけではないので、適用ユーザーを徐々に増やしていく方法は効果的なのでは。

（河合）1%を徐々に増やしていくのって難しくないですか？実際実装していて感じるのは、1%のサンプリングが悪いと、本来的に精度が出るはずのものを精度が悪いと判断してしまって取り下げることになりかねないと感じている。

（久保）自分も見ていてそれは実感する。評価の仕方というより、評価のバリエーションがそろっていた方がいいと思う。単一では評価が難しい。

Q. 上記の議論はモデルの精度自体が目的になるとその時点でダメで、ビジネス KPI に紐づいていないとダメ、という話だと思うが、そもそもビジネス KPI が定量化されている前提ですよね。結構難しいことだと思うのですが、ビジネス KPI ってみなさん当たり前のように定量的に決められているんでしょうか。

（河合）自分自身はビジネス KPI に定量的に落としていくの結構好きですね。ただそれはすごく難しいことで、その為に、現場に行ってアンケートをとったり、ユーザーが何を求めているかを知るための工夫をしている。

（久保）私も定量化が好きです（笑）。機械学習に限らずだと思うが、目標とする数字がないと何を目指して頑張ったら良いかわからない。Uber のマッチングなど、ML で成功しているシリコンバレーの Startup などは、機械学習の KPI とビジネス KPI が綺麗に比例関係になっていて、お金を出して良い ML エンジニアを雇うことがビジネスの成功につながるという良いフィードバックを産んでいるため、機械学習では非常に重要なポイントだと思う。

Q. オフラインとオンラインのメトリクス評価に相関がない場合、 例えばオフラインの評価では精度が良かったのに AB テストでビジネス KPI が下がった場合にオフラインでの評価手法にフィードバックする、といったことは考えられていたりしないでしょうか？

（河合） エムスリーではそのフィードバックを考えるのが好きな人が多い。 そこがおそらく機械学習でとても重要なのではと考えていて、チームや役員にもその重要性は伝えて評価の分析に AB テストの結果の分析にはとても力を入れている。

（久保）広告の場合は、広告の種類によって、オフライン評価が効く効かないという問題があり、オフラインの評価メトリクスのバリエーションだけでなく、評価データそのものを増やして評価するシチュエーションを様々に用意しておくことも重要になってくると考える。

（押条） 大企業さんを相手にする場合、ビジネスチームと話をすると、システム導入部署の決済を上げる為には、自社のサービスを導入するとどうメリットがあるという営業ストーリーをわかりやすく伝える必要があり、ビジネス KPI と連動したモデル開発は重要になる。

（河合）営業ストーリーって難しくないですか？営業ストーリーとユーザーにとってのメリットは必ずしも一致していないというのは、自分はユーザの意見を実際聞く事もある立場なんですが、その際に難しさを感じます。そのバランスを取ることが重要だと思う。

Q. 研究所の KPI は？

（梅田）研究所の KPI についても基本的には同じ考え方。研究所でもお客様向けの PoC に関わっていると、オフラインでうまくいっても入力データや評価指標が変わったりすると結果が全然違ったりすることもある。お客様の要望を最初からうまく聞いてシステムを作ることは意外と難しく、そのヒアリングや評価指標の定義も含めてサイクルを効率よく回すことも、エンジニアの仕事なのかなと思う。

そのほか、多くの質問が会場から寄せられました。皆さんからの「いいね！」が多かった質問を、いくつかご紹介します。

  • ML プロジェクトは不確定なことが多いので、進捗管理や目標設定のスパンを決めるのが難しいのですが、どうされてますか
  • 推薦の評価指標をどうやって決めていくか知りたい
  • pdf からテキストを抜き出す部分はどのようにされたのでしょうか
  • k-means の k はどう決めているのか
  • 推薦の評価指標をどうやって決めていくか知りたい
  • AWS（に限らずクラウドサービス）を、特にデータ解析の文脈でどの程度活用されていますか？
  • モデル管理、データ管理には何か工夫されていますか？
  • ユニークID降った時に同じ人に別 ID を振ってしまったりしませんか
  • AWS（に限らずクラウドサービス）を、特にデータ解析の文脈でどの程度活用されていますか？

今回は、MLPP とのコラボレーションという試みで、SNS でも情報発信力の多い方々が集まっていただいたこともあり、多くの参加者にお越しいただきました。後半のパネルディスカッションは、お悩み相談会としてははじめての試みでしたが、みなさんから非常に多くの質問を slido に寄せていただき、LT登壇者の皆様からは実際の研究開発〜運用でのリアルな課題を交えながら、会場からのお悩みに親身に答えていただき、非常に濃い話で勉強になる話ばかりでした。

参加者の方がblogを書いてくださいました！

次回の ML@Loft #8 は 「量子コンピュータ x 機械学習」 をテーマに 11月20日 (水)開催予定です。皆様のご参加をお待ちしております！

このブログの著者

宇都宮 聖子 (Shoko Utsunomiya)

AWS 機械学習ソリューションアーキテクト。自動運転・AI ヘルスケアライフサイエンス・ゲーム・スタートアップのお客様を中心にサポートさせていただいています。好きなサービスは Amazon SageMaker 。

( Twitter: @shokout )