はじめに

渋谷中の Web 企業を巻き込んだ Design Scramble が 11 月 24 日（土）に開催されましたが、参加された方はいらっしゃいますか？なんだそれは、という方のために軽くご紹介をしますと、Design Scramble は「渋谷を舞台に、クリエイターと企業が業界を超えて交差する」というモットーの元に開催された、渋谷を舞台としたクリエイター・デザイナーのためのデザインフェスティバルです。お祭りで各企業が屋台を出店し、デザイン力やエンジニアリング力を集結させた催し物をする、といえば伝わりやすいでしょうか。

イベント全体で 1000 人を超える来場者数の中、弊社も例に漏れず、渋谷に拠点をおくいち企業として参加させていただきました。出し物は CONNECTED by AWA P[AR]TY という名前の「AR×自然言語処理」をテーマとしたインスタレーション作品になっております。具体的には、Tweet の内容と事前アンケートから User 特徴を算出し、それを元にした自分の分身が近しい特徴のUser 達と AR 空間上で対話を行う、というものでした。

この作品の自然言語処理部分を担当するに当たって AI Lab から岩崎 (@chck) と張 (@peinan) の二名のリサーチャーが約一ヶ月間仕様を詰めながら検証し、ゴリッゴリにサーバーサイドの開発を担当したのでその軌跡を残したいと思います。ゼロから自然言語処理（以下 NLP）を実サービスに載せる際の喜怒哀楽や、世にあまり出ないような良かったこと苦労したこと悩んだことのすべてを晒していく予定ですので、なにか参考になれば幸いです。
この記事で書かれることは大まかに以下になります。

• 案件の進め方
• Google Cloud Platform (以下 GCP) をフル活用したシステムアーキテクチャ
• NLP の実サービスへの応用思想

先に成果物紹介

https://twitter.com/hiroko_tazume/status/1066244947349712896
https://twitter.com/CONNECTED_AWA/status/1068093050063269891

コトの発端

「ちょっといいかな？身構えないでね」

ある日のこと、こんな相談が。
自分たちは普段アドテクスタジオの AI Lab という研究部署で論文を読んだり書いたり、自分たちがかんがえたさいきょうの手法の実験をしたり、Kaggle に打ち込んだり、サイエンスの力でサービスの問題を解決することに努めたりしています。夏の主要学会シーズンも終え、業務も一旦の落ち着きを取り戻した9月中旬のこと、とある筋から NLP の知見を活かしてメディアのエンジニア・デザイナーと一緒に何かを作らないか？という相談が来ました。それが今回の Design Scramble 企画の始まりでした。

ひと言で表現すると参加者の分身がAR上で勝手に踊る・繋がる・喋るといった内容でした。具体的には以下のようなものでした。

1. クラブをイメージした AR 空間で自分のアバターが他のアバターに混じってダンスして会話する
2. 類似度が高い人同士がよりマッチングし、より会話をしやすくなる
3. ① の会話内容は、当人っぽい言葉遣いや内容を生成したものを使う

ここからなんとなく読み取れる通り、「繋がる」「喋る」に該当する ② と ③ の部分が自分たちの担当になります。

システムアーキテクチャ

主な要件は以下になります。

1. 数百人規模の来場をリアルタイムで捌けるような構成
2. User の Tweet ベースのマッチング
3. User の Tweet と事前アンケートからの対話生成

要件を踏まえて、機能別に細かく定義すると以下のようになります。

• User の Tweet 取得
• User の特徴語抽出
• User のベクトル化
• User の類似度計算
• User の対話生成

これらをそれぞれ順に説明していきます。

1. User の Tweet 取得

AR サーバー側から渡される TwitterAccessToken を基に、1 User あたり API の上限である 3200 Tweets を取得し、形態素解析をかけたのち、Cloud Datastore に保存します。この時点である程度次元（Vocabulary）を減らすために、形態素解析で分けられた単語の助詞・助動詞・非自立語・数字を除去し、原形に変換しておきます。辞書は新語・固有表現に強い mecab-ipadic-neologd を使用しました。
この処理を介して最終的に得られたものがUser 単位の元データとなります。

2. User の特徴語抽出

1 で得られた User 単位の Tweet 単語群から tf-idf という（他の文書（今回の場合他の User）で出現頻度が高い場合ペナルティを課す）単語の重み付け手法を使って特徴語を抽出します。tf-idf の値の大きい単語 top100 をその User の特徴語として、こちらも Cloud Datastore に保存しておきます。トピックモデル（文書群から教師無しでトピック（単語のまとまり）を探索し、その確率分布を返す。指定トピック数に次元を圧縮できる）の利用も考えましたが、計算量の問題で断念しました。以下の図は、得られた特徴語から User を WordCloud として可視化した例です。その User らしい特徴的な単語が抽出できています。

コーパスの定期更新

前述の通り、特徴語の計算には指定 User 以外の大衆 Tweet も利用されます。登録 User が増えるということは、この全体の Tweet 数、つまりコーパス内の単語の分布が変わっていき、結果的に特徴的な単語も都度変化します。例えば、User 数の少ない当初は特徴的だった「今日」という単語も、別の User の Tweet がコーパスに追加され、そこに多く含まれていたら特徴的ではなくなります。この特徴語の変化を取り入れるためには、特徴語の計算の際に、コーパスを常に最新に保つ工夫が必要です。
今回は、メモリにロードされているコーパスが計算に使用され、かつ読込元のコーパスがひとつのバイナリファイルに集約されていたため、スレッドセーフな更新・ロードに注意する必要がありました。毎回 1 User の処理の合間に更新&リロードを差し込むと上記問題が起こり得るため、コーパスを定期的に洗い替えるバッチを用意しました。

（右図．コーパスデータの更新タイミング問題）

3. User のベクトル化

User を表す特徴語を抽出することに成功しましたが、User 間のマッチング、距離を測るためには、特徴語を何らかのベクトル表現にする必要があります。ここでは単語の意味的な近さを考慮したベクトル表現に変換するのによく使われる、Word2Vec を用います。これにより、User あたり 100 特徴語から 100 × 200 次元の行列になりました。日本語 Wikipedia のリンク構造を利用して固有表現に頑健な Suzuki ら [1] の Wikipedia Entity Vector を Word2Vec のモデルとして使わせて頂きました。ここで改めて、Tweet から算出した特徴語群はその User を表す特徴となり得るという仮定を置いています。Amazon の商品レコメンド、Tinder のカップリングよろしく、人やモノ同士を関連度で紐付ける機能の背景には、特徴量（ベクトル）化した人やモノ間の距離を測るという処理が行われています。そのため、はじめに行うべきは登録してくれた各Userのベクトル（User feature）化です。

User Feature の定義

参加者をベクトル化するにあたって、参加者の個性を表す何らかの元ソースが必要です。今回 Twitter 連携を利用した User 登録にした理由の一つとして、参加者の大半を占めるはずのクリエイターから集められる自然言語の特徴として Twitter がリーチすると考えたからです。参加者の Tweet から算出した特徴的な単語群はその User を表す特徴、個性となり得るはずです。前述した tf-idf という技術で、各 User 最大 3200 Tweet から特徴語を 100 単語ずつ抽出した各単語を、意味的な近さを考慮したベクトル変換技術 Word2Vec によって 100 × 200 次元のベクトルに変換し、User feature としました。マッチングで利用されるこの特徴語群は、そのままUser自身を可視化でき、事前登録時に WordCloud として提供しています。

4. User の類似度計算

公式の謳い文句の勝手に「マッチング」の部分です。これまでの工程で、User の Tweet から抽出された 100 個の特徴語を各 200 次元でベクトル化しました。今回マッチングさせたい対象は User 同士なので、依然として単語同士の距離だけではなく、単語群の距離を測る必要がありました。平均等を取って 100 から 1 ベクトルに潰すこともできますが、各特徴語本来の特徴が潰れることを懸念し、今回は「似ている特徴語ペアの類似度の上位 10 語の平均を User 間の類似度」としました。具体的には以下のプロセスによって User 間の類似度を算出しました。

1. 100 特徴語/ 1 User のうち、tf-idf Top30 特徴語 Vector を利用
2. UserX, UserY の Top30 特徴語 Vector それぞれのコサイン類似度を算出
3. 得られた類似度 30×30 ペアのうち、上位 10 ペアの類似度の平均値が User 間の類似度

このやり方の場合、各単語同士の近さは考慮できますが、単語の組み合わせ、単語群としての近さはあまり考慮できていないため、想定通り 30% を越える類似度の User ペアは得られませんでした。今後の課題として上記問題に対応すべく Doc2Vec や Encoder 系の手法も試したいです。

こちらで得られたおもしろ類似特徴語を以下にいくつか載せておきます。
「中野ブロードウェイ」&「恋人」
「港区男子」&「志望動機」
「チョココロネ」&「浜松町」

マッチングの定期更新

1 User が本システムに登録してくれるたびに WordCloud から Matching までの処理が走り、全体の User Feature が増えていきます。ということは、Similarity を計算したタイミングによって母数が違うので異なったマッチングを楽しめます。また、より多い母数でマッチングしたほうがより高い類似度の User が現れる可能性が高いとも言えます。そこで、既に Similarity を計算しおわった User に対しても定期的に再計算を行うバッチを作成しました。

これの難点として、Userの登録が増え、マッチングの候補の母数が増えるということは、類似度計算の総当たり数も増えるということです。ここでも計算時にメモリにロードされている User 候補 Matrix が使われるため、前述したコーパスの定期更新と同じ問題に悩まされたのと、計算時間が線形で増えていくことでした。1day イベントでなければ FAISS のような近似最近傍探索を検討していました。

（右図．類似度計算の総当たり数が増えていく様子）

5. User の対話生成

主に要件に沿ったプロダクトに仕上げるまでに考えたことやったことを書きます。

要件と使用手法の検討

冒頭で書いた全体的な要件のうち、対話生成のタスクに関わるのは ④ の「当人っぽい言葉遣いや内容を生成して、お互いを対話させる」です。
これだけだとかなりふわっとしていましたが、初回から何回か仕様についての議論を重ねていくうちに、なんとなく以下のような方向性になりました。

• データはどこから？
  • Twitter もしくは来場時にアンケートに答えてもらう
• (イベントとして) 当日登録は許容する？
  • yes. むしろ当日登録の方が多くなるかもしれない
• 会話生成にかかる時間は最長でどれくらいまでなら許せる？
  • 当日登録の場合を考えるとせいぜい 5 分から 10 分程度

これに対して取り得るアプローチはざっと思いついたものは以下のようになります。

• でぃ〜ぷら〜にんぐを使った手法
  • ニューラルネットワークで当人の発言となるものを学習し、そのモデルで対話させる
• 用例ベースの手法
  • 当人と他人のやりとりの用例を集め、発話同士の近さで対応する返答をする
• シナリオ・テンプレートを使った手法
  • 予め会話をシナリオ・テンプレートに落とし、それに沿った発話を行う。最終的にはこれを採用。

結果的にこの手法を採用しましたが、時系列的には上から検討・調査しました。それらのメリットやデメリット、今回の要件への適切度をどう判断したかについては、寄せ集めコラムに書きますので興味ある方は読んでみてください。

シナリオ・テンプレートを使った手法

シナリオ型、穴埋め形式から slot-filling などとも呼ばれるこの手法は今まで出てきた中でもっともシンプルで実装がしやすく、それでいて日本語的に破綻することなく動作します。ただし、シナリオ・テンプレートなどを人手で設計する必要があるため、時間と労力をかけて用例を作ったり会話の流れを設定したりしなければなりません。

今回そこは根気でカバーするとして、要件にあった対話を作成する時間は他のいずれの手法よりも速く、参加者を模する内容の方はアンケートでカバーしてテンプレートに埋め込む形式を取ることで、全体的な要求を満たせることができます。よってこの手法でシステムを作っていくことにしました。
シナリオ型の中でも今回は分岐が発生しない固定回数のやりとりをするタイプを取りました。用例やシナリオのおおよその設計は以下の図のようになります。

話者 A と話者 B が交互に発話していく設計で、全部で 13 対の対話が行われるようにしています。赤矢印が示すように各発話には複数パターンが用意されており、そのパターンからランダムに選ぶことで異なる対話セッションで同じ対話内容にならないようにしています。 No は会話の順番、 id は会話内容を示すスロットの prefix になっていてこれと話者情報を組み合わせます。例えば A さんの出身地を示すスロットは birthplace_a になります。このような参加者の情報は以下のような 7 項目使用することにしました。

id	詳細
name	Twitter から取れる screen_name
job	職業（アンケート回答）
together	誰と来たか（アンケート回答）
birthplace	出身地（アンケート回答）
music	好きな音楽ジャンル（アンケート回答）
wordcloud	（少し紛らわしいですが）最近興味を持ってる物事を示す単語を Tweet から解析
tweet	wordcloud の根拠となる Tweet

出身地に関して、相手側の出身地について何かしらの薀蓄を話せたら面白いよねという案が出たので、web から日本の 47 都道府県の観光名所をクロールしてきて knowledge base を作成し、それを元に API を実装して裏側に配置しました。

これの descs （名所の説明文）を品詞情報やらなんやらを見て~~泥臭く~~うまく処理して、日本語的に自然になるように発話に組み込みました。ただ試作段階では、今まで一言二言しかしゃべらなかった自分の分身が、出身地の話になると急に饒舌になってどうなのという議論もありましたが、これはこれで面白いんじゃねということでそのままにしました。すると同じことを来場者の方々も思ったらしく、狙った通りの体験を味わえてもらえたことが製作者冥利に尽きました。

出身地の話で急に饒舌になるの面白い#DesignScramble #CONNECTED_AWA pic.twitter.com/WxbMhp5GYu

— ホトマイ (@hotomymy) November 24, 2018

寄せ集めコラム

対話生成で検討した他手法

でぃ〜ぷら〜にんぐを使った手法

人工知能が流行しはじめて短くない期間が過ぎ去り、なんにでもとりあえず人工知能だと叫ばれる昨今、でぃ〜ぷら〜にんぐを使った手法はやはり目を引くものがあります。自分としてもぜひとも使いたかったのですが、結論から言いますと今回は色々検討の末見送ることにしました。その理由は非常にシンプルで、学習に必要なデータの不足と学習にかかる時間が長すぎるからです。
当然といえば当然ですが、ニューラルネットワークを使って学習させる場合、大量のデータを使ってそれなりの時間をかけて行うことが多いです。今回のケースだと、データは Twitter などの SNS から引っ張ってくることになるので、Tweet (中でも特に mention) が多い人なら良いのですが、それが不足している人のほうが圧倒的に多かったので文法的に破綻していたりと上手く学習させることができませんでした。また、学習に必要な時間も長いので、当日来場者はもちろん事前登録者だけでもちゃんと賄えるかが非常に怪しい状況でした。

ちなみに検討したモデルたちは供養を兼ねて以下に紹介したのでご参考になったら幸いです。

sequence-to-sequence モデル

「seq2seq」や「encoder-decoder」などとも呼ばれていたりします。ニューラルネットワークを使って bot 作成や対話をしたいってなったときに真っ先に思いつくのがこのモデルと言っても過言ではないでしょう。
encoder-decoder という名前の通り、encoder と decoder の役割を担う2つの Recurrent Neural Network (RNN) を使っており、encoder 側で入力となる系列 (sequence) を受け取り内部表現に圧縮し、decoder 側でその圧縮された内部表現を元に系列を出力する、という構造になっています。AutoEncoder ¹ の一種で、初期の全結合ネットワークである Multi-layer Perceptron (MLP) の代わりに RNN を使っている、という風に捉えることもできます。

このアーキテクチャが注目され始めたのは 2014 年で、いくつかの論文 [5, 6] でこの構造を使って機械翻訳タスクにおいて高い精度を達成していました。
同じ意味の文に対して、encoder に元言語の系列を入力し、decoder に翻訳先の言語の系列を出力させるように学習させています。
一見対話処理には関係なさそうですが、元言語を発話、翻訳先の言語をその発話に対する応答と考えれば対話処理にも応用できると気付き、一気に広まりました。どこでなにが応用できるか分からないものですね。

Generative Adversarial Network (GAN) モデル

生成という単語から GAN [7] を連想する方も多いのではないでしょうか。敵対性学習とも呼ばれるこの手法が初めて世界の目にさらされたのは 2014 年の NIPS で、2018 年現在の 4 年間までに数多くの派生が生まれてきました。
敵対性という言葉の通り、GAN の基本的なアイデアは Generator と Discriminator の2つのニューラルネットワークを作り、前者は何かを生成し、後者は生成された結果を分別する役割を持っています。Generator の目標は Discriminator を欺く結果を生成することで、逆に Discriminator は生成された結果を正しく分別することをゴールとしています。

しかし当初から今に至るまで、GAN を使ったタスクの多くが NLP 分野のものではなく画像に関するものでした。理由は諸説ありますが、自分としては画像は密な値を取ることができるが言語ではそれが難しい、というのが主な原因だと思っています。つまり GAN を使って生成された結果の密行列に対して、画像ならば近しい画素を割り当てられるが、言語の表現は画像ほど連続性がないため近しい単語を選ぶのが難しいということです。また、そのため重みの更新が困難で、どこをどうやってアップデートすればより判別されにくい系列にできるのかが Generator には分からない。他にも多くの問題が存在しているのですが、GAN の NLP 適用についてより詳しく知りたい方は [10] のスライドを参考にすると良いかもしれません。
とはいえ技術の進歩は凄まじく、去年や今年からチラホラと GAN を用いた手法が NLP 界隈でも観測されるようになり [8, 9]、対話処理に応用した研究も出てきています [11, 12]。これからの発展に期待したいところですね。

用例ベースの手法

ニューラルネットワークが流行る前の対話処理では用例を使った手法が主流で、その手軽さや解釈容易性から現在でも盛んに使われています。
そのバリエーションはたくさんあるのですが、そのほとんどに共通していることとしては Question (Q) と Answer (A) のペアを大量に用意し、その中からクエリ入力に最も近しい Q に対応する A を返す、という仕組みです。

単純ながらもそれっぽい回答ができるのですが、文脈を見ていないことやそれに起因する整合性の破綻、データ量がないと返答のパターンが少なくなり的はずれなことを発言しがちになるなど問題がいくつかあります。外的なリソースやナレッジベースを上手く活用すればある程度は解決できるのですが、構築やチューニングするのにそれなりの時間と労力が必要とされます。

今回の場合は、やはり対話破綻とデータ量の観点から採用はしませんでしたが、ニューラルな手法とは違って文法的には破綻していなかったので余力があれば余興として対話破綻を楽しんでもらうこともありかなと考えました。結局使いませんでしたが。

（右図．デモ用に作った bot を LINE に載せたもの。高木さんって誰ですか）

高速化の工夫

特徴語抽出やマッチング処理はそれなりに計算時間がかかることが予想できたので、NLP 周りの API は基本非同期で設計し、1 User の処理毎に進捗を返す API を用意しました。STANDBY, PROCESSING, FINISHED, FAILED の 4 status で表現し、各処理を Cloud Pub/Sub 経由で Queueing する際等にstatus を変えていました。具体的には、User 登録時点で TwitterToken が発行されるので Tweet 取得から類似度計算まで裏で走らせておき、登録後に回答してもらうアンケートとスタッフの喋りで 5 分程稼ぎつつ対話生成に繫げていました。また、来場ピーク時に詰まらないように Request 数に応じて Scaleout するよう Kubernetes 側で設計しました。

（右図．処理の進捗を表す json）

豆腐削除プロジェクト

WordCloud 画像を生成するときに苦労したことの一つが豆腐についてです。画像生成にするときに、使用するフォントに含まれていない文字が使われると豆腐となってしまいますが、Twitter ではそのような文字（絵文字、他言語の文字など）がそれなりに散見されます。もちろん人によってその数は変動しますが、人によってはかなりの数の豆腐が生まれてしまうことがありました。

本番でこれが出てしまうことはさすがに見栄えが悪いので、豆腐削除プロジェクトが立ち上がりました。といっても実装の片手間の時間で調べたり検証したりしていた程度なのですが、数多くの試行の末に採用された方法がフォントテーブルの解析でした。具体的な流れは以下のようになります。

1. 使用するフォントファイル（ttf ファイル）を解析して、フォントファイル内の文字コードのリストを作る
2. 事前にそのリストをエクスポート
3. 実際のシステムでは流れてくる文字を 1 文字ずつ舐めて、リストにない文字コードを含む単語を除去

この方法にたどり着くのには少し時間がかかりまして、というのもフォント解析なんて中々縁のないことだった上に文献も少なかったからです。同じことをする方は少ないかもしれませんが、もしいましたらぜひ参考にしてみてください。

After Party

利用者の Tweet 分布

Tweet は Option なので来場者はもっと多く、12:00-19:00 で 400 人程でした。

利用者のTwitterProfile

Design Scramble自体がクリエイター向けのイベントなので、近しい職種の方々に利用して頂けたようです。

反響

UI/UXの観点でわかりやすく解説して頂けたり、実際にこのインスタレーションを通じてマッチングされた方もいました。ユーザーの反応は励みになりますね。本当にありがとうございました。

https://twitter.com/saharu54/status/1066346308972163073
https://twitter.com/sallllly0307/status/1066305617910882304

感想

普段の研究業務では state-of-the-art を追ったりしていることが多く、こういった発案からプロダクトに乗せるところまで全てを自分たちでやることはあまりないです。その分今回の製作体験ではどうやって最高精度を出すかではなく、どうやって要件を満たして最高の体験をしてもらえるか、という軸を据えて製作活動ができたのは非常に新鮮味がありいつもとは違う視点を持つことができて楽しかったです。

他にも多くの反省点や感想があるのですが、全てを文章に書ききれないので下のような箇条書きにまとめてみました。これはどういうことなのか詳しく！、いやそれ違うだろ！等ありましたら適宜連絡いただければ幸いです。

• 妥協が大事
  • 精度と処理速度はトレードオフ
  • SOTA なモデルが良いとは限らない
• 同期/非同期処理を使い分ける
  • 計算量をできれば事前に見積もる
  • 処理時間が線形に増えていくと危険
• NLP 系の本番で動くシステムから多くのノウハウが得られた
  • 本番中に Tweet が 0 件の User 対応含む運用も思い出
  • データが Static でない=ゴミデータが入る可能性を常に頭に入れる
• ベクトルデータをうまく扱う DB 知ってたら教えてください

参考文献

• [1] Suzuki et al., A Joint Neural Model for Fine-Grained Named Entity Classification of Wikipedia Articles, IEICE Transactions on Information and Systems, 2018
• [2] Hinton et al., Reducing the Dimensionality of Data with Neural Networks, Science 2006
• [3] Pascal et al., Extracting and Composing Robust Features with Denoising Autoencoders, ICML 2008
• [4] Diederik et al., Auto-Encoding Variational Bayes, ICML 2014
• [5] Ilya et al., Sequence to Sequence Learning with Neural Networks, NIPS 2014
• [6] Kyunghyun et al., Learning Phrase Representations using RNN Encoder–Decoder for Statistical Machine Translation, EMNLP 2014
• [7] Goodfellow et al., Generative Adversarial Nets, NIPS 2014
• [8] Yu et al., SeqGAN: Sequence Generative Adversarial Nets with Policy Gradient, AAAI 2017
• [9] Fedus et al., MaskGAN: Better Text Generation via Filling in the______, ICLR 2018
• [10] 小町守, 言語処理における GAN の展開 (SlideShare)
• [11] Li et al., Adversarial Learning for Neural Dialogue Generation, ACL 2017
• [12] Zhen et al., Neural Response Generation via GAN with an Approximate Embedding Layer, ACL 2017

---

著者