NLP4L - 情報検索における性能改善のためのコーパスの活用とランキング学習

Editor's Notes

• #2: 情報検索システムを改善するために、ビッグデータをどのように活用できるか、というお話をしたい。
• #3: Big Data 関連では、大学院で自然言語処理を学び、ロンウイットで機械学習のトレーニングコースの講師を勤めている。
• #4: 設立当初より情報検索を専門に行ってきた。具体的にはOSSの検索エンジンライブラリであるApache Luceneベースの検索エンジンSolrやElasticsearchなどの導入コンサルティング、製品開発、サポートサービス、トレーニングコースを提供している。トレーニングコース受講者はのべ800名に達する。 Solrをかついでいる日本企業は無数にあるが、情報検索専業であるのでどこよりも検索システムを真剣に考えている自負がある。「より良い検索システムを提供する」をモットーに活動している。 ところで、「良い検索システム」とはなんだろうか。それは「欲しいものがすぐ見つかる」システムであるといえる。 しかしその前に、情報検索システムとはなにか、考えてみよう。
• #5: 情報検索システムの目的は、大量の情報の中からユーザの要求を満たす情報を見つけ出すことである。検索対象となる情報は自然言語で書かれた文書とする。ユーザからの情報要求はキーワードで表現されたクエリ。 ECサイト：商品検索。 企業内検索：ファイルサーバやDBなどに保存されている文書を横断的に検索。 書誌検索：図書館などで、タイトル、著者名だけではなく、文献の概要や本文も含めた検索。 情報検索システムの特徴を、システムを運用する側から考えてみたい。それは導入後に継続的なメンテナンスが必要、ということである。なぜかというと、事業の発展に伴い文書量が増えたり、ユーザニーズが変化したり多様化したりすることでマーケットが変化するため。 もちろんこれは情報検索システムに限った話ではなく、他の業務システムにもあてはまることではある。しかし情報検索システムではこのことが多分に顕著に現れると情報検索業界に10年間携わってきた経験から感じている。利用時にユーザのemotionalな部分が入り込むから・・・かもしれない。 継続的なメンテナンスが必要なのはちょっと面倒そう？なくても業務は回せるが、あると大変便利なシステム。Googleのように検索できる。業務効率が大幅にアップ（企業内検索）。ユーザ利便性の向上（ECサイト）。
• #6: 我々は「よい検索システム」とは「ユーザが欲しいと思った情報をすばやく見つけられるシステム」と考えている。なお、探す対象が「情報」だと漠然としているのでこれ以降は「文書」と呼ぶことにする。「文書」は、Webページ検索であれば「Webページ」、ECサイトであれば「商品」に相当する。 「ユーザが欲しいと思った文書をすばやく見つけられる」というところをもう少しかみ砕いて言うと「網羅的かつ必要な文書のみ提供する」ということになる。「網羅的」というのは「ユーザが欲しいと思った文書はもれなく返す」ということであり、「素早く見つける」ためには「ユーザが欲しい文書のみ返す」、つまり「ユーザが欲しくない文書は返さない」ということになる。 この「必要かつ十分」な文書を返す検索システムを提供する、というのは実は結構実現が難しい。なぜなら「網羅性」の達成と必要なものだけを返すという「正確性」は、トレードオフの関係にあるため。 これは上のような「ベン図」を描くと理解しやすい。上の図で、右の円が「ユーザが欲しいと考えている文書集合」であり、左の円は「検索システムが返す文書集合」を表す。このように描くと領域A、B、Cができ、この領域の大きさを使って検索エンジンの性能指標である「再現率（recall）」と「精度（precision）」を計算できるが、今日は平易な言葉で説明したいので、この話はしない。詳しく知りたい方は、YouTubeで私の過去の講演を検索していただきたい。 ここで左の円の大きさは「網羅性」を表す。このとき、左の円がカバーしきれない領域Cができてしまうが、これを検索漏れと呼ぶ。領域Cは「ユーザが欲しいと思っているが検索システムが返せなかった文書集合」ということである。ユーザとしてはこの領域は当然のことながら小さくなくては困る。一方で、領域Aを検索誤りと呼ぶ。領域Aは「ユーザが欲しくないのに検索システムが返してしまう文書集合」ということである。この領域Aが大きいと、ユーザはたくさんの検索ヒットの中から自分が探したい文書を見つけるのが大変になるので、やはりユーザとしてはこの領域も小さくして欲しい。 したがって、領域AもCも小さくしたいのであるが、そのためには左の円がこの大きさを保ったまま、右に移動してくれるとよい。しかし、検索システムをこのようにチューニングすることは不可能である。可能なチューニングは、左の円を大きくしたり、小さくしたりすることである。
• #7: たとえば、「網羅性」を高めるために、左の円を大きくなるようにチューニングすると、ユーザが欲しい文書はほぼ返せるようになる。しかし、領域Aが増えてしまうので、探しにくくなってしまう。 逆に「正確性」を高めるために、左の円を小さくなるようにチューニングすると、ユーザが欲しくない文書はほぼ返さなくなり探しやすさは高まるが、領域Cが増えてしまうので、ユーザが欲しい文書を十分返せなくなる。 これが検索システムでよく知られている「網羅性」と「正確性」のトレードオフ問題である。（正確には、再現率（recall）と精度（precision）と呼ばれるが、ここではこの言葉を用いない） ユーザとしては両方とも欲しいが、両方同時に実現するのは不可能である。しかし我々は「より良い検索システムを提供する」をモットーに活動しているので、この問題を解決する必要がある。
• #8: 我々はこのトレードオフ問題を解決するには、このような解決手順を踏むことにしている。 まずは、何はともあれ、「網羅性」を高める方向で検索システムをチューニングする。ユーザが欲しい文書を返せないと話にならないからである。 すると、先ほどのロジックから、「正確性」が低下する、つまり、多くの検索ヒットの中から目当ての文書を探すのが難しい状態となる。 これを解決するのに、2つの方法がある。1つは、漸次的に不要な文書を取り除く方法、もう一つは、ランキングが適切になるようにチューニングすることである。ここで「ランキング」とは、検索結果表示ページにおける、文書の表示順のことを指す。 このプロセスを一つずつ説明しよう。
• #9: 検索の網羅性を高める具体的な方法の例を示す。 この表のうち、いくつかは日本語独特なものだが、英語など、日本語以外の言語でも類似の網羅性を高める方法が考えられる。 （以下、それぞれを簡単に説明） 以上のように、「網羅性」を高めると、「正確性」が低下するので、次に低下してしまった「正確性」を高めるプロセスを説明する。一つ目のプロセスは、漸次的に不要文書を取り除く、である。
• #10: 「漸次的な不要文書の除去」の方法について、具体的なWebサイトでの検索を想定して説明しよう。パッケージツアーの販売サイトを考える。 ハワイに行きたいと考えているユーザがパッケージツアーの販売サイトで「ハワイ」と入力する。そのとき、ユーザはこの円で示されるような文書集合が返ってくることを期待している。 しかし、網羅性が高められた検索システムはもっとたくさんのパッケージツアー（文書）を返してくる。そこで画面の右側などを見ると、「予算で絞り込む」というリンクがあるので、自分の予算に照らし合わせてリンクをクリックすると絞り込み検索が実施され、返ってくるツアーの数を絞り込むことができる。さらに別のリンクである「出発地で絞り込む」という絞り込みリンクもあるので、自分の条件に合った出発空港をクリックすると、さらにシステムから返ってくるツアーの数が小さくなる。 このように漸次的に不要文書を取り除くことで、高い網羅性を担保しつつ、正確性も高めることができ、ユーザは望む文書をすばやく探し当てることができるようになる。
• #11: ただし、「漸次的な不要文書の除去」の方策をとるには、検索対象文書がこのように「構造」を持っている必要がある。 このような構造を持っていない、「非構造化文書」に対しては、「漸次的な不要文書の除去」の方法を適用することはできない。
• #12: 「網羅性」を高めることで低下してしまった「正確性」を高める二つ目のプロセスは、「ランキングチューニング」である。ここで「ランキング」とは、検索結果表示ページにおける、文書の表示順のことを指す。 こちらの図は「ランキングチューニング」を行う前である。数字は各文書の表示順（ランキング）を示す。ユーザが最初に目にする文書は、ユーザが望まない文書となってしまっている。ユーザが欲しい文書は、50位、100位、500位など、下位に押しやられている。
• #13: 一方、ランキングが適切にチューニングされた場合、このようになる。ユーザが最初に目にする文書が、まさにユーザが望んでいる文書となっている。 この状態は、「網羅性」が高く、「正確性」は相変わらず低いままだが、ユーザ視点で見れば非常に優秀な検索エンジンと言える。つまり、ランキングが適切にチューニングできれば、低い正確性をカバーできることがわかる。
• #14: 以上、検索システムにまつわる網羅性と正確性のトレードオフの問題を解決する手順を示した。次に、それぞれの項目に対応するSolrのツールを具体的に見ていこう。 「網羅性を高めるようにチューニング」するには、SolrのSynonymFilterを適用する。 「漸次的に不要な文書を取り除く」には、Solrのファセットを使った絞り込み検索を行う。 「ランキングチューニング」するには、Solrの検索において、検索時やインデクシング時にフィールドの重みを適切に調整したり、関数クエリを用いたりすることに相当する。 このように、それぞれの問題解決項目には、Solrにてそれぞれツールが用意されている。しかしながら、いざ実際に使おうとすると、それはそれで問題が出てくる。
• #15: Solrのツールを使おうとしたときに生じる問題。 「SynonymFilter」を使うには、シノニムが定義された辞書ファイル（テキストファイル）が必要である。これを人手で設定するのは大変だ。 「ファセットを使った絞り込み検索」を行うには、検索対象文書が構造化されていないといけない。しかし、世の中の全ての文書が構造化されているわけではない。非構造化文書には適用できない。 「フィールドの重みを適切に調整」するには、Solrに詳しい技術者が、デバッグ情報を見ながら重みを微調整したりしないといけないので大変。またランキングのチューニングを重み調整だけでやるのは実質的に不可能。「あちらを立てるとこちらが立たず」という状態に陥り、全体的に最適なランキングにすることは経験上できない。仮にその時点で最適と考えられるチューニングをやったとしても、検索システムが扱う文書は増え続けるのが通常であり、何かしら自律的にチューニングされるしくみが必要である。
• #16: そこで、これらの人手作業を軽減し、より良い検索システムを手に入れるためのOSSのツールであるNLP4Lを紹介する。 NLP4Lは弊社を含むベンダー数社でGithub上で共同開発しているオープンソースソフトウェアである。 機械学習や自然言語処理のテクニックを用い、Luceneベースの検索システムの使い勝手をより良くするためのものである。 充実した英語と日本語のマニュアルがある。 NLP4L-DICTとNLP4L-LTRの2大モジュールが統合されたGUIベースのプラットフォームである。 NLP4L-DICTでは特に、コーパス、すなわち企業が保有する文書データベースを入力として受け取り、シノニム辞書や専門用語辞書などの各種辞書を自動生成する。NLP4Lでは「機械学習や自然言語処理は完璧ではない」という前提に立っているので、自動生成された辞書はSolrなどの検索システムにデプロイされる前に、Validateプログラムや人手で確認・編集され、最後にデプロイボタンクリックで、Solrにデプロイされるしくみになっている。人手による編集の際、過去に行った同じ編集をもう一度行わなくてもすむように、編集内容はデータベースに記憶され、次回の辞書生成時に編集は自動適用される（リプレイ機能と呼ばれる）。 Wikipediaのような、一般的で誰でも入手可能なコーパスを処理対象にすることもできるが、それぞれの企業が保有するコーパスを用いることで、より業務ドメインに特化した辞書構築が可能となる。
• #17: 前述の各問題点について、NLP4Lがどのようなツールを提供して問題解決をしているか、見てみよう。 （各項目を簡単に紹介） 最初に情報検索システムの特徴として導入後に継続的なメンテナンスが必要である旨述べた。したがって、「自律的」であることがここでのポイント。 AIがもてはやされる昨今、AIの一技術である機械学習は「完璧」ではないので１００％自律的であることを保証するものではないが、かなりの省力化に貢献できる。
• #18: ここでLTRの一般的なフレームワークを示す。 （各コンポーネントについて簡単に紹介） モデルの学習アルゴリズムには、Pointwise、Pairwise、Listwiseのアプローチがあることが知られているが、NLP4L-LTRはこれらのアプローチに依存しないフレームワークとなっている。
• #19: NLP4LはLTRのフレームワークのうち、必要な全てのコンポーネントをカバーしている。 （NLP4LによるLTRコンポーネントのサポートについて簡単に説明） LTRは教師あり学習なので、教師データがなければいけない。NLP4LはLTR用の教師データを作成するのに、2つの方法をサポートしている。（次ページ）
• #20: LTR用の教師データを作成する方法の1つめは、アノテーションGUIである。「どのクエリはどの文書がどの程度関連度があるか」について、ユーザが人手で星をつける作業を行う。そのためのGUIが提供される。このGUIは「どのクエリについてどの文書がどの程度関連度があるか」という星印をつけていくのでPointwiseのデータを作成していることになるが、NLP4L-LTRにて擬似的にPairwiseデータに変換してRankingSVMなどのPairwiseアプローチを取るランキング学習アルゴリズムを実行できる。 2つめは、アクセスログ（NLP4Lでは特別にインプレッションログと呼んでいる）から関連度（上述と同じ「どのクエリはどの文書がどの程度関連度があるか」ということ）情報を自動生成する「クリックモデル」である。 NLP4Lでは独立クリックモデル（Independent Click Model）と非独立クリックモデル（Dependent Click Model）をサポートしている。
• #21: こちらは、NLP4L-LTRがサポートする、インプレッションログのサンプルである。 データは2件ある。1つめは「iphone」というクエリが発行されたクエリセッションで、インプレッション（表示された文書）がdocAからdocEの5件あり、そのうちのdocAとdocCがクリックされたことを示す。 2つめは同じく「iphone」というクエリが発行されたクエリセッションで、インプレッションがdocAからdocEの5件あり、その中でクリックされた文書がなかったことを示す。
• #22: （時間があれば、NLP4L-DICTとNLP4L-LTRのデモを実施。）
• #23: SolrにNLP4Lを組み合わせたシステムはこのようになる。 （おおまかな流れ、参照関係について説明） 「自律的」というのがここでもキーワードになる。 １００％メンテナンスフリーを保証するものではないが、かなりの省力化を達成できる。
• #24: NLP4Lプロジェクトの今後の計画を示す。 評価プログラム NLP4L-LTRにおいて、MAP（Mean Average Precision）、DCG（Discounted Cumulative Gain）、NDCG（Normalized DCG）などによる評価プログラムを追加したい。
• #25: 問題解決の方法 まず網羅性を高めて、低下した正確性を改善するのに2つの方法があることを示した。また、これらの問題解決のために、Solrには対応するツールがあることを示した。ただし、Solrの各ツールはメンテするのに手間がかかることもわかった。 そこで問題解決を自動化するために、（Solrに加えて）NLP4Lを導入し、企業に眠っている資産であるコーパスとクリックログ（NLP4Lではインプレッションログと呼び区別している）を活用しよう、という提案を行った。