Threading Machine Generated Email http://dl.acm.org/citation.cfm?id=2433447

1. Threading Machine
Generated Email
Nir Ailon, Zohar S. Karnin,
Edo Liberty, Yoelle Maarek
SEXI/WSDM2013 読み会
id: y_benjo

2. 目次
• 10秒まとめ
• 目的
• 手法
• 実験
• まとめ

3. 10秒まとめ
• 機械的なメールを自動的にスレッド化
• Amazonなら商品注文から受取番号入力までひとま
とまりに
• 精度90%，再現率70%

4. 目的
• 機械が吐くメールをスレッドでまとめたい
• スレッド: メールをまとめる形式
• 既存技術: 人とのメールならReやらFwdやらに則って機
械的に処理可能
• サーバから自動的に送られてくるだけのメールもま
とめたい

5. どんなシチュエーションか?
• 例1: パスワード再発行
• 「パスワード再発行のURLはここだから踏んでくれ」
• 「パスワード再発行完了したんで」
• 例2: ECでの注文
• EC: 「注文受け付けたんで」
• EC: 「商品送ったんで」
• USPS: 「商品の追跡番号はxxxなんで」
• EC: 「買ってくれてありがとう，評価してくれ頼む」

6. 何が問題か
• 例1
• 普通のメーラーはスレッドにまとめてくれない
• Reとかでつながってないから
• 例2
• 例2は例1よりもっと厄介
• 例1と違って，例2のメールはタイトルは全然似ていない
• しかも送り主が途中で変わってる
• けれどもこれらをまとめたい

7. 手法
1. メールのテンプレートを抜きだす
2. 因果グラフ(causal graph)を作る
3. 最終的には判別問題に落とす
4. 実際どうやってスレッド化していくのか

8. 1. テンプレートを抜く
• 共通部分と固有の部分に分ける
• 例: e: Your package number 2049862-56 is on
its way
• テンプレート τ(e) = Your package number * is on
its way
• 可変部 var(e) = 2049862-56
• 「ここは色々関連研究あるから参考にしてくれ」と
しか書いてない

9. 2. 因果グラフ(causal graph)を作る
• 基本方針
• ユーザ別にメールのテンプレートを受信時間で昇順ソー
ト
• テンプレートAを受け取ったあと，δ秒以内にテンプ
レートBを受け取っているかを数え上げ
• それを使ってテンプレートをエッジとして持つ因果グラ
hうを作る

10. τがτcausの後に
登場した回数
因果グラフのweight

11. Fig2: causal graph
• 図は本文参照
• 因果の例が出ている
• 同じドメインから「注文受け付けたわ」→「送ったわ」
メールとか
• 「パスワードリセットしたわ」→「注文したわ」って
メールもある
• これはECユーザはパスワードを忘れやすいため，注文前にパス
ワードをリセットする人が多い事を示している

12. 3. 判別問題に落とす
• 二つのメール e_i, e_j に関係があるかどうかを判別
問題で解く

13. 特徴量
• Time Difference Features
• Variable Match Features
• Periodicity Features

14. Time Difference Features
• 2つのメールの時間差と，そのメールのテンプレート
の時間差における平均/分散の差
• ここで，同テンプレート内で上位/下位10%を削除
• 理由: 一週間に2度パスワードを変更したユーザは1度目
の変更完了メールと二度目の変更確認メールがカウント
されるため
e_i, e_j が
持つ
テンプレート

15. Variable Match Features
• テンプレートじゃなくてvarsにも着目
• 重要な例: 注文 #number を受け付けたわ と 注文
#number を発送したわ
• 重要でない例: #city1 から #city2 のチケット取った
わ と #city1 から #city3 のフライト中止になった
• 二つのメールに含まれるvarsをマッチさせる
• メールの送信元ドメインとvarsの類似度も考慮する
• racingbuy.com の注文受付メールと racing buy で
の支払いについて メールの類似性は高い

16. Periodicity Features
• 定期通知メールが重なると関係があるように見えて
しまう
• 毎月の支払い通知メール，日毎のメーリングリスト
• テンプレートごとに届いた間隔(にlogを取ったもの)
の平均と標準偏差を feature に追加

17. 4. 実際どうやってスレッド化していくのか
• すごく大雑把に書く
• 新しいメールeとこれまで届いたメール{e_1, ..., e_j}
• F(e, e_1), ..., F(e, e_j)を計算し，もっともスコアが
高いものに繋げていく
• Fは[0, 1]のスコアを吐く学習器
• スレッドが途中で分岐するけど問題なし

18. 実験
• 人手で正解作り
• 「このメールに一番近いメールを選んでください」
• 「無ければ無し」で良い
• 学習器はAlternating decision tree
• 結果は大体良い感じ

19. まとめ
• 機械的なメールを自動的にスレッド化
• Amazonなら商品注文から受取番号入力までひとま
とまりに
• 精度90%，再現率70%

20. 感想
• 「あー確かにあれば楽だ」という感じがする
• 途中添字が異常になっていて混乱した
• 実際の例とか見たかったけどさすがに載せらないの
だろうか

21. 色々出た突っ込み
• テンプレート抜く部分が一番難しいのでは？
• 精度比較，テンプレートだけのものが欲しい
• 同ドメインのメールをまとめるだけの精度はどれぐ
らいか?
• 例えば注文が入り乱れる場合だと同ドメインを全てまと
めるとよくないけど，実際はどれぐらいあるのか?
• 提案手法で異なるドメインのメールはうまくまとめられ
たのか?