こんにちは、DSOC 研究開発部の奥田です。以前の私のブログ記事ではコーギーの動画を見ていると書きましたが、とうとうコーギーを家族として迎え入れ、現在生後6ヶ月の子犬と暮らしております。
さて私たちDSOCでは、SansanやEightの価値を高めるために様々な自然言語処理のタスクに取り組んでおります。例えばニュース記事からの固有表現抽出では、私たちのサービスに特化した固有表現を対象に研究開発しています。その他にも様々あるなかで、特に重要かつ困難とされているものの一つに「名寄せ」というタスクがあります。AIや人工知能と呼ばれるものが発達した現代においても、人間には当たり前にできるタスクが機械には難しいことがまだまだ存在します。
今回は、その「名寄せ」というタスクにおける日本語でのデータセットを作成してみました。これをきっかけに、日本語での名寄せというタスクの研究が進み分野が活性化することを期待しています。
名寄せとは？
まず「名寄せ」というタスクについて紹介します。この記事では、
異なる言葉が同じ事象を表現しているかを判定するタスク
と定義します。例えばいま私が現実に飲んでいる「カフェラテ」は、「ラテ」と省略して表現されることもありますし、「カフェ・ラテ」と中黒を入れて表記されることもあります。Wikipediaの記事だと「カフェ・ラッテ」とあります。一方で「カフェ」とは違いますし、「カフェ・オレ」とも違いますよね*1。こうしたように、人や状況によって異なる言葉の表現をされるものを同一かどうか判定するのが「名寄せ」というタスクです。なおここで言う言葉というのは、一般にはいくつかの単語から成り立つ短い文字列で、文書のような長いものではないものとします。
ちなみに、この「名寄せ」ですが、上記のような定義以外にも様々な考え方があり、あまり統一した定義は無い認識です。データベースのレコード同士を紐付ける行為を指す場合もあれば、Wikipediaの記事を対象に紐付けるもの、文字列を正規化するという場合もあります。また、英語ではEntity Matching、Record Linking、Disambiguation、Deduplicationなど様々な呼ばれ方をしており、タスクによって細かな違いがあるようです。
Sansanでの名寄せ
Sansanでは、この名寄せを人や企業の名前に対して行っています。名刺をデータ化する際には様々な表記ゆれが含まれることがあり、それを解消することが目的です。詳しくは過去に私が発表した資料や講演内容を参照ください。
Sansanでの名寄せは、これまでに培ってきた知見や創意工夫あふれるシステムを通して高い精度を維持しておりますが、それでも解決できない難しいケースや取り組むべき問題も数多く残されています。私たちの規模のサービスでは全ての処理を人間が行うのは到底不可能なため、人間並みの知覚と知識を持ったシステムの構築が不可欠です。
研究のための名寄せデータセット
名寄せはこのようにビジネスにおいて普遍的かつ魅力的なタスクなのですが、現在のところ名寄せの研究はそれほど盛んに行われておりません。その要因は色々考えられますが、その一つに大規模な日本語のデータセットが存在しないことが挙げられます。多くの研究者が研究に参入するためには、タスクとしての魅力さ以上に、そこに良質なデータセットと統一した評価基準が必要であると思います。
そこで、今回は日本語を対象とした名寄せのデータセットを作成しました。
データセット作成方法
本データセットを作成するにあたり、ACL2019で発表された下記の論文の方法を参考にしました。
本論文でTamらは、Wikipediaの記事と文中でのリンク文字列から、同一事象に対する複数の呼び方を取得しています。以降では、Wikipeidaの記事のことをエンティティ、リンクの文字列をメンションと呼びます。先の例で言えばWikipediaの記事 カフェ・ラッテがエンティティ、文字列「カフェラテ」がメンションになります。このメンションが名寄せの対象となる文字列で、その文字列が同一の事象をあらわすかどうかをエンティティとの紐付けで判断します。
以下は大まかに解説します。詳細はデータセットのリポジトリを参照ください。
1. Wikipediaのテキストからリンクを抜き出す
まずWikipedia (ja)の全記事から、他のエンティティに貼られたリンクとそのときのメンションを取得します。そこからマークアップのタグやその他ノイズを除去した上で、全Wikipedia内で5件以上存在するメンションを対象としました。
Wikipediaのデータは、2020/02/24にダンプされたjawiki-20200224-cirrussearch-content.json.gzを使用しました。全体で4,775,681件のエンティティと5,543,323件のメンションを取得し、フィルタリングの結果、1,054,856件のエンティティと2,213,547件のメンションを抽出しました。
2. エンティティごとに 学習/開発/テスト データを分割する
一つのエンティティからは、同じエンティティを指す正例のメンションペアとそれ以外の負例のメンションペアからなる、複数のデータセットが作成されます。そのためデータセットを作成した後に学習やテストデータに分割すると互いに似た事例が含まれてしまうことから、まずエンティティ自体を学習:開発:テストが6:2:2になるように分割し、それらの各エンティティで正例と負例を作成しました。
2. 正例と負例の作成
ここから、各エンティティに対する正例と負例を作成します。ここからは、以下の概念図を元に具体事例を解説していきます。
Wikipeidaから抽出したエンティティとメンションをもとに、まずは正例を作成します。同一エンティティの異なるメンションの組み合わせでかつ、両者に1つ以上の重複する文字が含まれているものを正例とします。
Entity_コーヒーでは「コーヒー 」「ブラックコーヒー」「珈琲」がメンションにありますので、これらのペアを正例とします。この場合は(コーヒー, ブラックコーヒー)は正例として採用できますが、(コーヒー, 珈琲)はメンション間に共通する文字が含まれていないため正例としません。この場合は名寄せのデータセットとしては相応しいのですが、多くの場合共通する文字が含まれていないペアは単語の翻訳やノイズであることが多く、今回の場合は日本語の名寄せデータセットの構築を意図していることから、こうした文字が重複していないメンションは除外しました。
次に負例を作成します。メンションと関係ない文字列なら何を持ってきても良いのですが、現実に即した課題にするためになるべく判別が難しい”似た”メンションを用意する必要があります。そこで下記の4つの方法で負例をサンプリングします。
- 編集距離：編集距離が1か2のメンション
- オーバーラップ：先頭か末尾4文字が重複しているメンション
- 4ホップ：あるメンションが指す別のエンティティのメンション
- ランダム：全メンションの中からランダムに選択したメンション
編集距離は、対象のメンションとの編集距離が1または2のメンションの中からランダムに選択します。オーバーラップは、先頭か末尾の4文字が重複しているメンションを選択します。4ホップは一つ先の違うエンティティのメンションを負例として採用します。ここでは「 コーヒー -> Entity_コーヒー -> 珈琲 -> Entity_カトウハルアキ -> カトウハルアキ」で4ホップ先にある(コーヒー,カトウハルアキ)が負例です。そして最後にランダムは、全メンションの中からランダムに選択されます。
これら4つの方法で作成した候補の中から不適切な候補をフィルタリングします。抽出確率はそれぞれ同率とします(0.25ずつ)。正例と負例のバランスを均一にするため、エンティティごとに負例は正例と同じ数だけサンプリングします。
データセット
- Github: yagays/nayose-wikipedia-ja
データセットは、以下のような形式となっております。lhsとrhsがメンションのペアを表し、labelが名寄せできる(1)かできない(0)か、typeがメンションペアを抽出した方法、commentが抽出Entityを表しています。
| lhs | rhs | label | type | comment |
|---|---|---|---|---|
| けいおん!! | けいおん! | 1 | positive | Entity_けいおん! |
| けいおん! | けいおん！ | 1 | positive | Entity_けいおん! |
| けいおん! | らじおん! | 0 | levenstein | Entity_けいおん! |
| 放課後ティータイム | 天使にふれたよ! | 0 | alias_of_tp | Entity_けいおん!_Entity_放課後ティータイムII |
| 放課後ティータイム | SUPERヒーロータイム | 0 | overlap | Entity_けいおん! |
人間のパフォーマンス
名寄せの難しい点として、人によって解釈が異なる場合があることが挙げられます。最初に例で示したカフェラテとカフェオレは、知らない人からすれば同じものだと判定して名寄せしてしまうかもしれません。また、ルールを元にデータセットを自動で作成したため、中には明らかに間違ってアノテーションされているものも存在します。
そのため、人間による評価を行いました。今回はテストセットの中から500件をランダムに抽出し、2名の人間による名寄せ作業を独立して行いました。その結果、正解率(Accuracy)は、アノテーター1（私）は85%なのに対し、アノテーター2は66%でした。評価者の一致度合いを表すCohen's kappa係数は0.382でした。正解率にかなり乖離がある結果になりましたが、私はデータセット作成者なのに対し、アノテーター2には基本的なガイドラインのみを理解して作業してもらったという違いがあります。もう少しガイドラインを整備すれば正解率は向上するのではないかと思います。
名寄せの課題
さて、ここからは名寄せのデータセットにおける課題と展望を少し述べたいと思います。
概念の粒度が異なる
そもそも名寄せをこの記事では「異なる言葉が同じ事象を表現しているかを判定するタスク」と定義しましたが、ここで言う「同じ」とは何でしょうか？みかんとりんごは異なりますが、りんごの中にも品種やサイズが異なるものがありますし、極論を言ってしまえば物体として存在するりんごは、一つとして同じものはありません。一方で、果物というカテゴリならばみかんとりんごは同じです。結局、見る方向によって「同じ」という認識は変わりうることがあります。これは人間の抽象化という知的な能力の一つの側面だと思います。また、人間は一見無関係なものに対しても共通点を見つけ出すことがあります。
私の以前のプレゼンテーションでは、この名寄せという行為を生物学の種の同定と関連付けてお話しました。生物学においては種の概念はかなり正確に定められており、階級という階層構造で表現することにより、「同じ種」ということをある程度客観的な視点で議論することができます。一方で、一般的な自然言語処理の名寄せタスクのような場合ですと統一した定義は（おそらく）存在せず、したがって人によって意見が異なる事例が大量に出てくることになります。今回はWikipediaの記事を基本単位とすることでその課題に対して統一した基準を設けましたが、それでもそれぞれのエンティティの粒度はまちまちで、曖昧さが残ります。
この問題に対しては、カテゴリなどの階層構造をWikipediaでも活用できれば、同じ階層のエンティティのみに対象を絞ることができると思われます。ただし、それも人間が階層分けしているに過ぎないので、人によって解釈が異なったり粒度が揃わない場合があります。
事前知識が要求される
今回データセットを作るにあたり私もアノテーション作業を行ってみましたが、はっきり言って難しいです。百科事典の全項目を対象にしているのだから当たり前ですが、かなり多くの単語はそもそも見たことがないし内容を理解できません。名寄せというタスクの性質上はメンションが指す内容を理解している必要は必ずしもないのですが、それでも文字列だけから判定するのには情報が足りないケースが多いと思いました。文書の中にで出てくれば周りの文脈から理解できる場合がありますが、今回は単語だけが提示されるので、知らなければもうお手上げです。これは自然言語処理で一般的な文書を対象とするタスクと大きく異る点で、タスクを難しくしている要因でもあると思います。
この問題に対しては、事前知識をあまり要求しないような、人間が安定して解けるものだけを対象にするなどの工夫ができると思われます。最終的に人間のパフォーマンスに近づけるのであれば、人間に解けない問題を学習させる必要性はありません。そうした項目を除外していけば、データセットとしての質は高まると思いますが、一方で当たり前な名寄せしか学習できないようになるなどモデルの汎化性能が落ちる可能性も否めません。
他には、複数の人間の回答を保持しておくという方法もあります。SNLI (Standord Natural Language Inference) Corpus*2という推論タスクのデータセットでは、個々のデータに対して5名がそれぞれアノテーションを行っており、場合によっては意見が割れることもあります。このアノテーションデータを用いれば、先のように人間が安定して解けるものだけをフィルタリングすることもできますし、単一の正解率やF1スコアといった指標以外の曖昧さを許容した評価方法も可能です。
まとめ
この記事では「名寄せ」というタスクに対する日本語のデータセットを作成しました。前から着想はあったものの、今回初めて実際にデータセットを構築する中でいろんな発見があり課題が見つかりました。結論としては、やっぱりかなり難しいタスクですし、対象とするドメイン依存だなというのが正直な感想です。ディープラーニングの成功事例でよく見かけるような、大規模なデータがあれば解決する問題ではないのは確かです。ここ数年の自然言語処理の研究分野では、人間の知識を記述した知識ベース (Knowledge Base) が流行りだしていますが、そうした様々な知識も入れつつ取り組む必要がありそうです。
この名寄せデータセットにより、そうした研究の一つの事例として名寄せを活かすことができるのではないかと思いますし、ビジネスの現場で直面する名寄せがちょっとでも解決できればと期待しております。今回は時間の都合上間に合いませんでしたが、次回は実際にこのデータセットに対して機械学習で名寄せしたときの結果をご報告できればと思います。
参考
- 名寄せの概要
- Wikipediaにおける名寄せについて
- 日本語における名寄せ
*1:淹れるコーヒーの種類が違います
