Named Entity Disambiguation in Streaming Data (ACL 2012)
Alexandre Davis, Adriano Veloso, Algigran S. da Silva, Wagner Meira Jr., Alberto H. F. Laender
proceeding: pdf
解いている問題
名詞nを含む短いテキストが、あるエンティティeのことを指しているか、指していないかを当てる二値分類問題。
課題
- Twitterのようなmicro-blogのテキストは単語の数が少なく、暗号のように書かれていることもあるため、固有表現を認識することが難しい
- テキストの単語の数の少なさから、エンティティの周辺に共通して現れる文脈から特徴を学習することが難しい
- テキストが次々と流れてくるため、テキストを処理するために外部知識を参照していると処理が間に合わない
- テキストが次々とやってきて、テキストの傾向も変わるのでモデルがすぐにデータに合わなくなってしまう
提案手法のモチベーション
- 外部知識を参照している余裕がないなら、ストリーム中の（ラベルなしの）大量のテキストから得られる情報を使う。
- ラベルなしのテキストを負例として学習すると、負例の多さからモデルが過学習をおこし、大量のfalse-negativeが出てしまうおそれがある。
-
+ 正例を作ることは比較的簡単だが、負例を作るのはコストがかかる。
曖昧性解消のアプローチ
（良くない）シンプルな正例の作り方の例
- Twitter中である会社と関連したアカウントあり、このアカウントのプロフィールに書かれたメッセージは、その会社名を含むメッセージである可能性がある。
- こんな感じで正例を集める方法が考えられるが、このやり方はfalse-positiveがないことを保証していない。
-
+ つまり、本当はその会社のことを言及したメッセージではないのに、そのアカウントのメッセージなので正例とみなされていまう可能性がある。
ラベルなしの事例の信頼性を上げて、訓練データとして扱うことでモデルの性能を上げる
- ラベルなしの事例を扱うコストは、人手のアノテーションでラベル付きの事例を作成するコストより低い。
- 具体的には、EMアルゴリズムを使う
訓練データの初期状態としてありうる二つのパターン
- 訓練データは真に正例の事例と、大量のラベルなしの事例からなる
-
+ ラベルなしのデータは最初、負例とみなされるのでfalse-negativeな事例を含む可能性がある
-
+ 正例は真に正例という保証はないので、false-positiveな事例を含む可能性がある
+ ラベルなしのデータは最初、負例とみなされるのでfalse-negativeな事例を含む可能性がある
E-step
- 訓練データ中のすべての事例に、{正例、負例}のそれぞれの場合で閾値以上、あるいは以下であった場合に正例あるいは負例を割り当てる
- 具体的には事例xが負例である確率α(x, -)が閾値α^x_{min}と等しいかそれより小さければ、xは正例となり、大きければ負例となる
-
+ α^x_{min}は、事例ごとに決定されるパラメータ
M-step
- 分類器Rを更新、訓練データのすべての事例に負例である確率α(x, -)を割り当てる
分類器R
- ある単語の集合が正例に現れやすいか、負例に現れやすいかを学習する。
- このルール（単語の集合）の信頼性を、頻度をもとに計算して、事例が負である確率を、集めたルールの集合の重み付きの投票のような感じで計算する。
- ラベルのtransitでは、ラベル付きデータから、ランダムに正例をいくつか抜き出して、残りをラベルなしのデータとみなしている。
- 分類器の更新は、すべての事例のlabel transitionを終えてから行うよりも、各事例のlabel transitionを終えるごとに行うほうがいい結果だった。
- また、label transition operationは負例を正例にする操作に加え、正例を負例にする操作もできるようにしたほうがいい結果だった。
- SVMの代わりにLazy Associative Classifiersの変種を使うことで、速度がかなり早くなった。
疑問点
- 最初に選ぶ少数の正例によって精度がどれくらい変わるのだろうと思った (できあがるモデルがどれくらい初期値に依存するのか)
- α^x_{min}は、正例と負例のバランスがよくなるように決定しているが、正例と負例のバランスはちょうどいいという仮定は直感にあっているのか （ある単語のパターンでは負例になりやすいとかそういうことではない？）
