電笑戦 ~ AI は人を笑わせられるのか 3 新たな挑戦者

針原:
おっ、職人さん登場ですね、やはりこれまでのボケて投稿経験を生かしたアプローチをされているのでしょうか。

武藤氏:
はい。この連載の第 1 回目で紹介されていた石川さんのシンプルなモデルを見ながら戦略を練っていて、手元で試したところデータが少なかったせいかもしれませんが、画像の内容があまりボケに反映されていない印象を受けました。そこで、もう少し画像の中にどういう物がどういう位置関係で写ってるかを取得できるモデルの方が面白くなる気がして、やってみたのが今回紹介する手法です。

針原:
それはモデル作りを結構工夫したということでしょうか。石川さんも、この連載 2 回目で登場された森長さんも、基本は CNN (VGG or ResNet) + Bi-LSTM の Encoder-Decoder モデルだったかと思います。このあたりも工夫されましたか ?

武藤氏: 僕たちが使ったモデルは NeurIPS 2019 で発表された Object Relation Transformer というモデル (参考: S. Herdade, et al., “Image Captioning: Transforming Objects into Words”) です。物体の相対的な位置関係を取り出すことができるものとして提案されています。例えば論文中にあるように、「馬に乗る少女」と「馬の横に立つ少女」の画像を区別することができます。

針原:
なるほど、それは新しいですね。そしたら前処理も結構変わってくるんでしょうか ?

武藤氏:
データは、ボケ缶の中からボケに対する ★ の数が多いものとして、★ を付けた人が 4 人以上いるものを選びました。これで大体 20 万ボケぐらいだったかと思います。画像は、それぞれに対して Detectron2 を用いて物体検出と特徴抽出を行いました。これが案外時間が必要で、6 ~ 7 時間ほどかかりました。文章は MeCab と NEologd で分かち書きを行いました。
 

針原:
なるほど。もう少しモデルの詳細を伺ってもいいでしょうか ?

武藤氏:
このモデルは物体の相対的な位置関係を取得できる Transformer ベースの Encoder-Decoder モデルです。画像の特徴を捉えて、ボケに翻訳します。物体検出・特徴抽出では Faster R-CNN with ResNet-101 が使われています。バウンディングボックスは 36 個以下になるようにし、それぞれから 2048 次元の特徴を抽出しています。
 

針原:
なるほど、Encoder がオブジェクトのバウンディングボックスと空間的な位置関係を読み込んで、Decoder で Transformer を使って文章に直しているということですか。トレーニングについても伺っていいですか ?

武藤氏:
モデルのトレーニングは Softmax cross-entropy loss を用いて、Adam で最適化しました。難しかったのは面白いボケを評価する関数がない点で、そのため沢山のモデルを保存して挙動を確認しました。具体的には 1000 イテレーションごとにモデルを保存し、22 万イテレーションぐらい回しました。キャプション生成でよく使われる MSCOCO に比べてテキストのばらつきが大きい分、学習が難しかったと思います。学習率は 5 * 10^-5 (論文中は 10^-4) と、かなり小さくしました。

針原:
ちなみに環境はどういうものを使われましたか ?

武藤氏:
Amazon EC2 p3.2xlarge インスタンスを使いました。Deep Learning AMI には GPU (NVIDIA Tesla V100) ドライバーとソフトウェア、Python 環境の Anaconda が用意されているため、環境構築も容易でした。ちなみにフレームワークは PyTorch です。
 

針原:
それでは、本連載最後に登場するのは吉本興業 田中さんです。笑いを本業にしている企業の参加ということで期待が高まります。これまでは皆さん Encoder-Decoder モデルでのキャプション生成を行われていましたが、同様のアプローチをされましたか ?

田中氏:
私達も最初は画像キャプションのモデルを作っていました。どこまでできるか試してみたくて石川さんのモデルをベースに試していたのですが同じような壁にぶつかり、我々は Deep Learning を本業にしてきたわけではないので方針転換しました。

針原:
壁、というと ?

田中氏:
キャプション生成のモデルはどこかで見たような単語を繋げてそれっぽいボケを出力してくるんですが、それで本当に面白いボケになるのかいまいちしっくりこずでして・・・。皆さん指摘されているように、笑いの評価関数を作って学習させているわけではないので、モデルが面白さを理解しているわけではないと思っています。

針原:
はい、面白さをどう定量的に評価するか、そして真に新しいボケを生成できるか、という点はたしかにこれまでのインタビューでも課題として話題に上がりました。もちろん、そこに切り込めると電笑戦としてもとても意義深いのですが、結構難しいのではという印象を持っているんですよね、正直。

田中氏:
吉本興業はお笑いのイメージを皆さんにお持ちいただいているので、どうしても「大喜利としての面白さ」というところに正面から挑戦しないとな・・・と考えました。そもそも「写真で一言」の「面白さ」て何なのかな・・・と。

針原:
そうですねえ、改めて考えると・・・。

田中氏:
構成作家さんに聞いたのですが、お客さんから見て写真から考えつくことから、回答が「ズレ」た時に笑いが起こりやすいそうです。なので、画像を正しく認識・解釈して抽出した特徴から適度にずらした回答を行うのが良いアプローチだと考えています。

針原:
ズレ、というのは仰るとおりですね。

田中氏:
今回、大喜利などお笑いに長けた構成作家さんやディレクターさんがボケての回答データにタグを付けて、どういう軸に沿ってズレると笑いが生まれているのかを分析しようと試みました。

針原:
それは面白い、まさに笑いの専門家によるアノテーションを行ったわけですね。実際は、お笑い構成作家さん・ディレクターさんってどんな感じでラベル付けされたんでしょうか ?

山本氏:
初めは SageMaker Ground Truth の利用も検討したんですが、画像とテキストのペアを評価するというタスクだったため使うことができず、元々作っていたツールをベースに AWS Lambda + Amazon DynamoDB + Amazon API Gateway で構築しまた。タグは初めに決めずにアノテータ (構成作家さん) が自由に付与できるようにしました。データは、 評価の高い Red (1001 ≦ ★ の数 ≦ 10000) と、少ない Yellow (★ の数 ≦ 100) 、両方で試しました。

針原:
「あるある」よりも「ないない」の方がお題からズレてるから笑いが起きやすいということですか。

田中氏:
そのようです。評価の高いボケにはそういう傾向がありました。また、ボケてでは長文・説明調の回答が高評価なことがありますが、これは Web の媒体と相性がいいためだと思われます。普段から大喜利イベントをされている構成作家さんに言わせると、実際のイベント会場での笑いは簡潔なものがウケやすいそうです。ボケての長文ボケをそのまま大喜利イベントに持ち込むと瞬発力に欠けるという話もありました。

針原:
なるほど、電笑戦の本戦も時機を見て会場に集っての開催を予定しているので、笑いの相性は考慮する必要があるということですね。ありがとうございます。今回の知見をまとめると、人の表情をよく捉えた、簡潔な、「ないない」ボケは傾向として人気が高い、ということですね。

田中氏:
はじめ生成モデルで上手くいかなかった原因は、このズレを正しく表現できていなかったためだと考えています。写真から連想するものとのズレを表現するためには、そもそも写真に写っているものが人間から見て常識的にどうなのかという基準が必要だからです。そのため学習データとして、説明系の回答には日本語画像キャプションデータセット STAIR Captions を、セリフ系の回答としては青空文庫のセリフを取り入れることもしてみました。

本記事では、前半でカラクリ株式会社 武藤さん・吉田さんによる物体の位置関係を考慮した画像キャプションのモデルによるボケ生成、後半では吉本興業 田中さんより笑いの分析と複数モデルのアンサンブルによるボケ選択について紹介いただきました。どちらも、手法の着想において笑いのドメイン知識を生かしている点が重要かなと感じました。

本連載をお読み頂いた読者の皆様、最後までお付き合い頂きありがとうございました。電笑戦の試みは、AWS Summit Online での技術セッション「電笑戦 ~ AI は人を笑わせられるのか ?」および、その後開催予定 (日時未定) の電笑戦本戦へと継続します。引き続きお楽しみ頂けると幸いです。