CLOSE

リクルート式『AI』の生かし方(全2記事)

2017.03.16

Brand Topics

PR

「最終的に人は必要です」リクルートの開発・施策接続メンバーらが感じたAIの正体

提供:株式会社リクルートテクノロジーズ

注目ワードでもある「AI」。その華やかなイメージの裏側にあるリアルとは? 2017年2月10日、リクルートテクノロジーズによる「RECRUIT Technologies NIGHT vol.4〜リクルートにおけるAI活用のリアル〜」が開催されました。現在、リクルートでは、グループ内での利用を目的に開発されたA3RT(Analytics & Artificial Intelligence API Via RECRUIT Technologies)で、大量のデータを日々解析し、事業の発展や改善へつなげています。そんなテクノロジーの現場メンバーだからこそわかる本音や課題について語られています。

マッチングモデルを展開し、情報を価値にする

石川信行氏(以下、石川):みなさん、こんばんは。実は私、今週月曜日からインフルエンザでぶっ倒れてまして。今週初めて出社してしゃべっています。ということなんで、ちょっと言っていることがおかしいかもしれないですけど、それは熱でやられたんだと思っていただければと思います。

今回は「リクルート式『AI』の活かし方」ということで、事例を交えて、リクルートのなかでAIと呼ばれる技術がどう使われているかをお話ししていきたいと思います。詳しい話はメンバーからあるのですが、その前に、リクルートグループやリクルートテクノロジーズがどういう考え方でAIを使っているのか、開発しているのかについて、概要をお話しできればと思っております。

はじめに、私の自己紹介をさせていただきます。

私は今、ビッグデータ部のプロダクト開発グループというところでマネジャーをやっております。兼業で会社も起業していまして、こちらではアプリ開発もやっていたりします。

実は私、大学時代にコンピュータ・サイエンスや情報工学といった専攻ではなく、農学部でした。そこで虫の研究をずっとしていました。なので、畑違いのところからリクルートに入り、今は縁あってデータ解析、AIの推進をやっています。

パソコンや機械はあまり好きではなくて、本当はもっぱら生き物をずっといじっていたいというのが僕の趣味です。データ解析をやって給料をいただいて、その大半を虫に費やすという感じですね。

みなさんが本当にひくくらい(虫にお金を)使っているので。例えば、10万円ぐらいするカブトムシ……というのを何匹も買っちゃうんですよね。だから、お金ないんです。という話は置いておいてですね(笑)。

まず初めに、リクルートという会社について、簡単にビジネスモデルをご説明させていただきたいと思います。我々、リクルートグループではいろんな事業を展開していますが、その多くがこのマッチングモデルに基づいたビジネス活用を行っています。

すなわち、情報を探したいカスタマーのみなさんと情報を提供したいクライアントのみなさんを、Webやスマートフォン上、あるいは雑誌でマッチングをする。こういったビジネスをさまざまな事業で展開しています。

実際に、みなさんも見たことがあるメディアもあると思います。大きく分けると、ライフイベントとライフスタイルの領域に関わるメディアを展開しています。

ライフイベントは、ある人が人生に1〜2回ぐらい経験するかしないかという、わりと大きな決断を要するものに対するメディアを提供しています。例えば、結婚の「ゼクシィ」、住宅を買う「SUUMO」、中古車を買う「カーセンサー」、そういったものです。

もう1つは、ライフスタイルエリア……日常消費領域ですね。これは日常で使うようなものです。例えば、じゃらんでホテルを予約する、ホットペッパービューティーで美容室を探すといったサービスが含まれます。

こういった多岐にわたるエリアで、先ほどのマッチングモデルを展開し、情報を価値にしているところが、リクルートグループの特徴でございます。

技術は使ってもらわないと意味がない

我々リクルートテクノロジーズは、事業会社各社に対してITのソリューションを展開、提供していく会社になっております。

ITのソリューションといっても、多岐にわたります。我々が所属しているビッグデータ周りの解析技術・インフラを扱うグループもあれば、昨今流行りのセキュリティグループもあります。その他インフラそのものを専門で扱うグループもありますし、ユーザーエクスペリエンスのノウハウ、知見を提供するものもあります。こういったものをリクルートグループ内の各サービスへ展開しているのが、リクルートテクノロジーズの特徴です。

このリクルートテクノロジーズの中に、ビッグデータ部があります。どんなグループがあるのかを表したのが、この図です。

今、ビッグデータ部は7つのグループに分かれています。簡単にいいますと、まずはインフラ提供ですね。ビッグデータにまつわるインフラ。Hadoopやアプライアンス製品、……GCP、AWSのようなクラウドとかですね。こういったものの運用をしているのが、右下の2つのグループになっています。

次に左下の3つですね。この3つは、事業会社やユーザーが抱える課題をデータ解析でどう解決するかを、並走しながら展開していく。レコメンドやコンテンツの最適化など、そういったものを開発していくのがこの3つになっています。このように、事業ごとにグループが分かれているんですね。

最後に、上2つがソリューション軸のグループです。どちらかというと、左のコンサルティンググループが課題解決型で動いているグループ。それと比較して、ソリューションドリブン、つまり、「リクルート全体でこういう課題があって、これを解決するためにはこういうソリューションが必要だ」まで見据えて、実際にソリューションを作って、フィットさせていくのが、私が所属するプロダクト開発グループです。課題から入るのか、ソリューションから入るのか。ちょっと違いがあるんですけど、主にソリューション軸で2つのグループがあります。

今回、我々がメインでお話しするのは、私がグループマネジャーをしているビッグデータプロダクト開発グループです。こちらでやっていることを簡単にいうと、R&Dですね。最先端の技術やアルゴリズムを探してきて、実用化して世に出していく。こういったところをメインミッションとしています。

勘違いしていただきたくないのは、研究所ではまったくなくて、必ずビジネスに活かすところが最大の命題です。そういったグループになっております。

簡略化して話してしまいましたが、このプロダクト開発グループのミッション・ポリシーを言葉にすると、こんな感じです。

最新技術をいち早く検証し、誰でも早く簡単に利用できるようにソリューション軸まで実装を深める。リクルートグループすべての人に内容を展開していく。最近は、必然的にAIと言われるような領域の技術が多いです。今お話ししたとおり、基本的に技術を使ってもらわないとまったく意味がないので、施策出口のアイデアは常に持っておくことが我々のグループのミッションです。

さらに、この辺は内部の話なので興味ない方もいるかもしれませんが、我々は今、プロダクトオーナー制をグループの配下につけています。例えば自然言語解析の技術には、プロダクトオーナーを1人、ドーンと立てて、その下に開発メンバーや分析メンバーがぶら下がっている仕組みになっています。今日お話しする2人は、まさにプロダクトオーナーです。

プロダクトオーナーの方に、基本的に権限委譲がなされています。「どういう事業にどういう製品をあてていくのか」「出口はこうしたほうがいいんじゃないか」も全部考える。責任も報酬もすべて乗ってきます。

基本的に最終目的の設定後は切り取り方次第、と僕らは言っています。例えば、リクルートゼクシィの人たちと一緒に、ゼクシィになにか施策を展開しました。そのあと「カーセンサーに持っていきましょう」「HR領域に持っていきましょう」といった、目標設定みたいなところは基本的にはプロダクトオーナーにやってもらう。「どんどん進めてください」と、権限委譲しているのが、このプロダクト開発グループの特徴になっております。

こういったなかで、AIという技術を取り扱い、施策を展開していこうという背景でございます。

特徴抽出を機械で代替させることにフォーカス

では、我々のグループがAIをどう捉えているかについて、本題に入りたいと思います。

どうですかね。みなさんは「AI」という言葉が好きかどうかわからないですが、私は正直、大嫌いですね。あまり好きじゃないんです。というのも、僕が思うAIとは、もうかなりぶっ飛んでいるものです。例えば『アイアンマン』でいうJarvisみたいな話ですね。

あるいは、2000年くらいに僕が見た『A.I.』というスティーブン・スピルバーグ監督の映画があるんですけれど、みなさん、見たことありますか?

(会場挙手)

いますね。あんな感じのAIを、僕はイメージしているんです。我々が今やっているものは、そこに比べるとまだまだ程遠いイメージがあります。なので、なるべくなら「AI」という言葉を、僕は使いたくない。

ですが、それでも使っています。なぜかというと、キラーワードだからですね。基本的に、上司を説得する時や外で発表する時には、この言葉を使ったほうが余計なストレスがなくていいんです。なので、葛藤しながら、だましだまし使っているところが正直あります。

なので、ここに来たみなさんは「ああ、この人はAIって言葉を苦しみながら使っているんだな」と思っていただければと考えています。

僕は「AIとは?」を語りません。Googleという素敵なサービスがあるので、そこで調べてもらえれば死ぬほど出てくると思います。なので、こういったワードはぜひ、調べてみてもらえればと思っています。

こちらは、我々リクルート内部がAIをどう捉えているかをまとめたスライドです。

AIというと、ロボットや画像認識、あるいは感情分析もその中に入る場合がありまして、捉え方が広いんですね。なので、リクルート内部ではあえてAIのスコープをぎゅっと絞っています。とくに深層学習……いわゆるディープラーニングが得意とするような特徴量抽出の自動化にフォーカスさせています。

この特徴量抽出とはなにか。この画像の説明を見てもらえたらと思います。上が人間です。人間は、こういったカブトムシの画像をパッと見ると、脳の中で無意識に「角がある」「足が6本ある」「茶色である」「木の樹液を吸っているな」と勝手に捉えて、過去の経験から「カブトムシ」と理解します。つまり、画像を見てなにかしらの特徴を無意識に見つけてジャッジしています。それが、人間の脳みその中身です。

これはケンタウルスオオカブトというやつです。アフリカのカブトムシなんですけど、15万円くらいするんです(笑)。これを与えると、名前すらわからなくても「カブトムシに近いな」とは理解できる。なぜかというと、カブトムシの画像をずっと見ていて、特徴を覚えているからです。

逆に、クワガタの画像を入れると「カブトムシとちょっと似ているけど、ちょっと違うな」と思うわけです。これは無意識にカブトムシの特徴を脳の中に記憶していて、それと一致しているかどうか判断しているからです。

「これを機械に代替できないか?」が、まさに画像認識だったりするわけです。こういったカブトムシの画像を500枚くらいバーっと用意して、ディープラーニングをかけると、一定の特徴がベクトルとして出てきます。これを元に、目の前の画像に写っているものを分類したり、予測したりするわけです。

こういった、いわゆる特徴抽出を機械で代替させる。リクルート内部では、AIのスコープをここに絞っています。

特徴抽出を機械化=人の簡単な行動を機械で代替

今、ちょっと難しい話をしたんですけど。この特徴抽出の作業は、社内を見渡せばけっこうあります。例えば、高橋がお話しすると思いますが、クチコミの分類とかです。文章の校閲、作成、あるいはチャット。

みなさんの会社に、スーパー庶務さんみたいな人もいると思います。要するに「この費用負担構造はなんですか?」と聞いた時、「それ、こうですよ」と返してくれるような「生き字引みたいな人」がいると思うんです。これ、まさに特徴抽出の一貫です。

過去、ずっと「こういう作業の時は、こういった作業をしています」「こういうテキストは、こう分類します」ということをやってきて、脳で記憶しているんですね。それを元に予測することができている。

こういった単純作業は、見渡すといっぱいあります。なので、特徴抽出を機械化できれば、簡単にいうと、人の簡単な行動を機械で代替できるんじゃないかと思うわけです。

今回、僕らは人の単純作業のリプレイスを、施策の出口として多く行っています。AIの出口として必然的に多いですよ、という状況になっているわけです。

では、AIの案件を進めるにはどういったノウハウが必要なのか。図にまとめてみました。この他にもいっぱい……開発やインフラの要件などいろいろありますが、いったん簡単にまとめています。

実際に教師データを元にアルゴリズムを作って、モデリングして、施策に適用する流れのなかで、必要な要素がいろいろあります。例えば、自社内のデータを使えばいいのか、あるいはクラウドソーシングで作ればいいのか。買ってくるのもそうですよね。または、そのあたりに転がっているデータを整形すればいいのか、データを作るのかという概念にもつながります。

さらに、モデリングやアルゴリズムのノウハウも、自社内で開発するのはもちろん、他社の製品を使う、オープンソースを使う。いろんな手段があるわけですね。

問題は、一番上の部分なんです。これまでお伝えしてきた部分までは、どの会社さんでもできますし、我々でもたぶんできるんです。しかし、今回我々が一時的にAIの案件を増やしてきたのは、まさに一番上の部分にこだわったからです。我々のようなプロダクト開発グループがいることによって、きちんとAIの技術を施策レベルまで落とし込める。ここを考えられる人間は今、圧倒的に少ないですね。だから、ここを我々のグループが担いますよ、と。

さらにもっというと、このデータを用意するところに関しても、僕らが手伝います。もっともっというと、あとで紹介しますが、アルゴリズムの部分も僕らが用意します。「このAI推進に必要な要素すべて、僕らのグループでカバーします」というのが売りであり、メリットだったりします。

機械学習ソリューション群「A3RT(アート)」

今回は次の「A3RT」と呼ばれるものに関して、簡単にご説明したいと思います。

今、リクルートの中では「A3RT(アート)」と呼ばれる、機械学習やディープラーニングなどを同一ブランドで整備して、社内で展開しています。API群だと思っていただければと思います。

最初、それこそオープンソースを使ってフルスクラッチで開発したり、あるいは外部の製品をそのまま使って開発していたんですが、手間もコストもけっこうかかってしまう。もっというと、実際にサービスに適用しようとして、現場に寄れば寄るほど、要件が絞られるので、カスタマイズしたくなっちゃう。そうすると、案外、汎用的な製品を使うことに対してハードルが高くなってきてしまいます。

だから、「こんな仕組みを自分たちで用意できないか」という、僕らの経験から始まったプロジェクトにもなっています。リクルートに適したAPIをどんどん作っていけば、いろんな事業で横展開していけます。そこを狙って、A3RTを作っています。

くわしい話は、後ほどメンバーからあると思いますが、今のラインナップはこんな感じです。レコメンドのAPIもあれば、画像認識や文章分類、原稿のサジェスト、校閲など。チャットなどは新しいもので、最近やったものです。

(スライドを見て)ちなみに「このロゴはなんなのか」は、僕は知りません(笑)。懇親会にはほかのメンバーもいますのでそこで聞いてください。僕はわかりません。ログ作成もプロダクトオーナーにすべて任せているので、意味も知らない感じです。

このように最新の技術をAPIに落とし込んで、各事業に展開し、ラインナップをどんどん追加している状況でございます。

実際に、リクルートテクノロジーズという会社であることを最大限に活かせるのが、この領域です。例えば、ホットペッパービューティーで画像解析APIを作った場合。そのノウハウを僕らがハブになることで、カーセンサーに持っていくこともできるんです。そうすると、カーセンサーという事業は少ない工数で、かつ少ない費用で、ホットペッパービューティーが培ったノウハウをそのまま活かして、次の施策ができます。これが、いろんな事業間で起こるんですね。

A3RTを使って、いろんな事業のみなさんと施策展開をしていますが、そのなかでメンバーがいろんな課題に直面すると思っています。今日は、そういった課題をどう解決したかをメンバーに話してもらおうと思っています。

どうでしょう? 少しだけ焦らしますと、僕がAI案件を2〜3年やってきた中でも特によく出くわした場面があります。どうですかね? みなさんにも、いくつか心当たりあるんじゃないかと思うんですけど。

最も多いのは一番上です、「精度を100パーセントにしたい」。でも、100パーセントにはならないんですよね。なぜかというと、教師データ……教師有り学習が今主流だと思いますけど、その教師にするデータが間違っていたりするんですよね。「それで覚えさせても100パーセントにはならないでしょ」というのはあります。

2番目に多いのは、「データあります」。……ないんです。あるんですけど、使える状態じゃないんですよ。けっこう、あるあるだと思います。

あとは、「AIやりたい」「AIやりたいんですけど……」みたいな。とはいえ、「なにに使うんでしょう? これは」というあれですね。どうですかね、みなさん心当たりはありますかね。

外からパッと製品を持ってきて「すぐできます」と思っている方がいらっしゃるんですけれども、まあ(それができれば)苦労はしないですよね。そういう方に限って、カスタマイズした要件を持っていたりします。そうすると、ますます一筋縄ではいかなくなってくるんですけど。

そのほか、「なにかの魔法の類だと思っています」という話。僕ら、黒魔道士でもなんでもないので、無理ですね。こんなの。

AIという言葉がバズっていて、有象無象の捉え方があります。それぞれ捉え方に勘違いあったりするので、そこをうまく僕らが是正をしながら、どうAIという案件を事業のみなさんと一緒に続けてきたのかを、高橋と白井のほうからお話しさせていただきます。

テキストデータはマッチングビジネスの要

ということで、バトンタッチしたい思います。まずは高橋から、お話しさせていただきます。

高橋諒氏(以下、高橋):ただいま紹介に与りました、高橋といいます。僕からは、リクルートにおける業務効率化のための自然言語処理というところで、主に自然言語処理系、テキストデータに対してソリューションを作ってきた経験から発表させていただきたいと思っています。

まず自己紹介です。先ほど石川からA3RTというプロダクト群が紹介されましたが、それを開発しているプロダクト開発グループを兼務しています。主務は販促バイト領域Gで、主にゼクシィのアドホックな分析や開発業務を担当しております。

A3RTでは文章分類と文章校閲のAPI開発を担当しています。

これは、これまでリクルートのビジネスにおいてビッグデータ部がどういうところにフォーカスしてきたかという話です。よくリクルートは「カスタマーとクライアントをつなぐマッチングモデル」とよく言われています。これまで、データ活用の文脈ではカスタマーに対しての接点で活用してきました。要するに、レコメンドだったり、モニタリングだったり、予測モデル作成をやってきていました。

今回の私が担当しているプロダクトでいうと、このど真ん中をやるのだ、と。リクルート自体が払っている人のコスト削減、業務効率化を目指して、今回はRecurrent Neural NetとConvolutional Neural Netの2つを使ったお話をします。

まず、「自然言語処理、NLPとはなんぞや?」という話です。ご存知の方もおられると思うのですが、ウィキペディアによると「自然言語処理は、人間が日常的に使っている自然言語をコンピュータに処理させる一連の技術であり、人工知能と言語学の一分野である」とあります。実際に様々な書籍が出ていたり、Word2vecだったり、トピックモデルではポピュラーで耳にしたことがある方も多いと思います。

個人的に、自然言語は大きく4つに分けられると思っています。1つはTranslation。翻訳ですね。次にSummarization。長い文章を1つの短いセンテンスにギュッと要約するようなものです。あとはClassification。分類ですね。それとAnomaly Detection。要するに、「この文章、なにかがおかしいぞ」というのを見つける異常検知といったところかなと思っております。

「なんで自然言語処理にこんなに力を入れているか?」というお話をすると、リクルートにおいてテキストデータはマッチングビジネスの要なんです。例えば、リクナビなどを想像していただければと思います。

クライアント(企業)が「こうゆう人材が欲しい!」と求人原稿を作成するわけです。それをサイトに掲載することで、カスタマー……要するに会社を探している学生さんとかがその求人を見て応募したりしています。

サイトに載せてはいけない文章と、誤字脱字を発見

ただ、その原稿に不備があったらなにが起きるのか。「おっ、いい求人だな」と思って見ていて、原稿中に……例えば「2017年2月10日(木)に説明会を開催します」と書いてあったとします。そうすると、「2月10日って金曜日だよね」「あれ? 結局10日なのか、9日なのか、どっちなのかわからない……」となっちゃう。こういうのが起きると、単純にマッチングの機会損失が起きます。

他にも例えば、「いい求人ないかな?」と探している人が「やっといい求人見つけた!」って思ったら、「弊社は“操業”以来、新しい価値“が”“想像”してきました」みたいな感じで、誤字脱字が多いと読む気が失せちゃいますよね。そういうところの品質を担保したい。

さらに、「業界ナンバー1の実績を誇ります」というのがよくあるんですけど、「なにをもって業界ナンバー1なのか?」「ナンバー1の定義ってなんなのか」がよくわからない。判断しづらい文章が出回ると疑問点が生まれて、なかなかマッチングしませんよね。

先ほど4つ挙げた自然言語処理の主な使い道のうちの右2つを僕は担当しています。Classificationでいうと、掲載NGになる文章を見つけにいく。要するに、サイトに載せてはいけない文章を見つけるものと、もう1つは誤字脱字を発見するものの2つを担当しております。

まずは、「載せてはいけない文章発見機」からお話をしていきます。

Classificationというと、結構シンプルなタスクで、人の手で行っている文章のタグ付けや審査を機械学習によって自動化しましょう、という話です。

ニュース記事とかで、これがスポーツのジャンルなのか、政治のジャンルなのか、芸能のジャンルなのかを人間が判断して、人の手でタグを付けることがよくやられていますよね。

でも、それでは効率が良くない。API側の裏側で機械学習モデルを作っておいて、記事が入力として入ってきたら、その記事のトピックがスポーツの確率何パーセント、政治の確率何パーセントと返してあげれば人の負担がかなり減るわけです。

例えば、クチコミの審査の効率化を例にして考えてみましょう。リクルートのサービスでいうと、クチコミが大量に入ってきます。ただ、そのなかでもサクラや荒らしなど投稿規定にそぐわないクチコミが実はあったりします。それらを審査者の人が一件一件チェックをするのですが、かなり負担が大きいというのは想像に難くないですよね。

そこで、今回僕が作っている「Linne」というサービスを活用して、「これ、何パーセントの確率で掲載NG」「何パーセントで掲載OK」といったサジェストを返してあげる。審査者はそれを参考に気になる部分だけを見る。そうすると業務の効率化につながっていくわけです。

ここからちょっと技術的な話です。中身はConvolutional Neural Networkを使っています。主に画像認識で使われるモデルで、画像認識系の技術は後ほど白井から話があるとは思うので詳しくはそちらで。

例えば、「こういう感じの猫の画像が入ってきました」というときに、「これは猫!」という風に、画像とラベルの対を大量に学習させて覚えさせていく。これを使うと、まったく新しい画像が来ても、「なんなんだっけ?」の答えがだいたいわかるモデルになっています。

最終的に、人は必要

今回の学習データは、画像とラベルではなくて、テキストとラベルの対になっていく。例えば、「私はタコです」はOK。でも、「あなたが嫌いです」はNGというデータをあらかじめ持っておくんですよね。これを大量に教え込んでいきます。そうすると、学習していけばしていくほど、APIというか機械学習、Convolutional Neural Netが賢くなっていく。

ConvNetは、基本的には画像のためのモデルです。インプットとしては、32×32とかなんらかの行列とかテンソルが入ってくる。でも、文章だと「私はこの景色が好きだ」といったものが入ってくるわけです。ここで重要なのは、この文章をどう特徴量にするか、数値化するかというところです。

よくあるのはBag-of-Wordsみたいに、「『私』が1回出てる」「『は』が1回出てる」というのを抽出してベクトル化するんですけど、今回はそうではなくEmbeddingをします。

Embeddingってなにかというと、要するにWord2vecみたいに、それぞれの単語がどういう意味を持っているのか、意味空間に落とすイメージですね。この文章をそれぞれ単語ごとに区切っていって、それぞれ1個のベクトルとして扱うイメージです。これをがんがん並べていくと、1個の行列になりますよね。その話をここではしております。

ただ、固定長という制約があります。今回のように文章だと、入ってくる文章の長さ=単語数がそれぞれ違うわけです。それに対応するためにパディングを行っています。

パディングは、別にすごいことではなくて学習に関係ないような、end of sequenceを適当に入れて穴埋めしていくことを指しています。全体でみて一番長い単語列プラスアルファでパディングしてやれば、全部画像として扱うことができます。

学習の手順は、さっき言ったように、こういう感じの流れになります。まずインプットとなる文章を形態素解析して単語ごとに分ける。それをEmbeddingして、ベクトル化する。それを順に並べていって、パディングを入れてサイズを整えた後にConvolutional Neural Netに入れると、OKの確率がいくら、NGの確率がいくらのアウトプットが出てくる。これを実際のラベルと比較する。今回だったら審査はOKなので、ここが高くなるように重みを学習していくことをやっております。

実際にどういう環境で動かしているかというと、AWSなどのクラウド上に環境を構築しています。そこにAPIの受け口を作成して、クチコミのテキストが入ってきたら、それに対して確率を返すということをやっています。

ここからが今回の趣旨で大事なところなんですが、よくAIを使う場合に、完全自動化を目指される方が多いんです。もう、APIが結果を返したらそれを100%信頼してしまうということです。掲載OKの確率が高いんだから「これを掲載OKだと判断して、自動的に載せちゃいましょうよ」という話になるんです。

そうするともう、審査する人間がいらないわけですよ。コストリダクションには絶大な効果があるんですが、「いやいや待てよ」と。先ほど石川が言ったように、どれだけ高性能なAIでも精度100パーセントはありません。しかも、掲載NGの文章が出ると、どれくらいの影響力があるのかを1回考えないといけないですよね。

僕が強調したいのは、最終的に人は必要ということです。なんだよ、それじゃあコスト減らないじゃん、と思われる方もいるかと思いますが、人がどこまで見るのかという点で考えるとAIのサポートによって見る箇所が減っているので結果的に人ひとりあたりの作業効率が上がります。例えば、「掲載OKの確率が95パーセントだったら、そうは間違えていないだろう」というラインを引いておいて、「95パーセント以上だったら人が見ない」というような運用を目指しています。

シンプルに、条件付き確率を出していく

ここからは異常検知の話です。文章データにおける異常検知として誤字脱字にフォーカスしていてProofreading APIとして展開しています。先ほども話しましたが、誤字脱字や不備と呼ばれるものは結構重要で、求人原稿に間違いがあると説明会の日付が分からなかったり、読む気が失せちゃってマッチングの機会損失につながります。なので、そこを解決しようという意図になります。

今回は求人原稿にフォーカスしていますが、原稿自体の不備はけっこういろいろあります。「説明会の日付が過去の日付になっていないか?」「日付と曜日がズレていないか?」「電話番号正しいんだっけ?」「差別表現含まれていないか?」とか。

あと、住所もですね。「この住所は本当にあるんだっけ?」もあるんです。この大半がルールベースでできるものが多かったりします。先ほどの差別表現でいうと、分類のAPIが使えたりします。しかし、誤字脱字でいうと、「なかなかルールベースだけでは難しいよね」という面があったので、今回、機械学習を使ってやっています。

「なぜルールベースでは難しいのか?Deep Learningを使うのか?」という話をもう少し深掘りしていきます。例えば「私は妄奏する」といった文章が来た場合、そもそも「妄奏」という単語は存在しないので辞書と突き合わせて、存在する・しないを見つけられそうです。これはルールでクリアできる可能性があります。

でも一方で、「税金を“収める”」という文章の場合。よく間違える人多いと思うんですけど、本当は「納める」ですよね。ただ、間違えの「収める」も辞書には存在している。この場合、先ほどと同じルールで対処するのは無理そうです。

「税金・を・納める」というような3つの単語のペアにして、ルールとして登録しておく方法も考えられそうです。ただそうすると、組み合わせがすごく増えてしまったりします。あとは「税金が納める」という、文章として不自然な“てにをは”の間違いの話ですね。その間違いにルールで対処しようとすると、「ルールを作れなくはないけど、効率悪いですよね」となります。

じゃあ、どうするかというと、インプットとして「水は私たちは生活は欠かせない」みたいなちょっと変な文章が入ってきたら、「文章としておかしくしている単語ってどれだっけ」という形で異常検知をします。今回は、「間違いはここだよね」と見つけて、代わりをサジェストまでできたらいいよねという話をしています。

シンプルにいうと、ただの条件付き確率を出していくんです。「水」が入ってきたあとに「は」が入ってくる確率はどのくらいか。これを続けていって、確率が低くなるものを検知して、代わりをサジェストすればいい。

ただ、普通の条件付き確率を求めていても面白くないし、時系列を考慮できていないので精度もよくない。なので、今回はRecurrent Neural Netを使ってやってみました。

Recurrent Neural Netは、系列データに対してのNeural Netと呼ばれるものです。例えば、音声データや、今回の文章データ、映像データ、画像の系列になったりしている映像データでよく使われています。

文章データに対してよくやられるのが、特定の文字列のあとに来る単語の予測です。例えば、「He always 〇〇 English.」となった時の、「この〇〇ってなんだ」を当てに行くタスクです。そしたら、「ここには動詞が来るはず」「主語はheなので三人称単数系だ」を考えて候補を埋めていくわけです。これを自動的に学習するのが、Recurrent Neural Netの得意分野だと考えています。

この特質を利用すれば、逆に“ここに来ないであろう単語”も求められるわけですよね。それを使って誤字脱字の発見をやっていきます。

続きを読むには会員登録
(無料)が必要です。

会員登録していただくと、すべての記事が制限なく閲覧でき、
著者フォローや記事の保存機能など、便利な機能がご利用いただけます。

無料会員登録

会員の方はこちら

株式会社リクルートテクノロジーズ

関連タグ:

この記事のスピーカー

同じログの記事

コミュニティ情報

Brand Topics

Brand Topics

  • ランサムウェア攻撃後、わずか2日半でシステム復旧 名古屋港コンテナターミナルが早期復旧できた理由 

人気の記事

人気の記事

新着イベント

ログミーBusinessに
記事掲載しませんか?

イベント・インタビュー・対談 etc.

“編集しない編集”で、
スピーカーの「意図をそのまま」お届け!