kntn02

https://github.com/hikalium/kntn02

Transcript

2. 目次 ・手法の検討 ・実装の詳細 ・結果 ・まとめ
3. 手法の検討
4. 元のデータは一体…？ ・ある「モデル」で生成されている → 誰かのDNA配列？ 画像データ？ → モデルを推定できるだろうか？
5. 正解データrefの視覚化
6. 法則はなさそうに見える ・目で見るのは限界がある ・周期性を見つけたい → フーリエ変換！
7. ランダム 正解データ 視覚化したデータのフーリエ変換像 ランダムなデータと正解データは異なる！
8. 統計的解析 xとなっていた文字の分布 a b c
9. 統計的解析 正解文字列中の3-gram 分布 同じ文字が連続しない場合 (12パターン) 同じ文字が2連続する場合 (12パターン) 同じ文字が3連続する場合(3パターン)
10. 統計的解析からわかること 同じ文字が連続して出現する可能性は低い 連続しない: 79.0% 2文字連続: 19.8% 3文字連続: 1.2%
11. セグメントの解析 セグメントの長さと個数の分布
12. セグメントの解析 長さで重み付けたセグメントの長さの分布
13. そもそも精度100%は可能か 不可能 1文字のセグメント：1700個ほどある 生成モデルも不明 （実は機械学習も試したがダメだった）
14. 2種類の手法の組み合わせ 1. 確実に修復 → 修復した箇所は100%正解 2. 確率的に修復 → 誤った修復をする可能性あり
15. 実装の詳細 〜確実に修復〜
16. 確実に修復 利用可能な情報：2種類 T' = 虫食いデータ Segment = 切れ端 → 全部つなげると元の文書になる
17. セグメントの配置決定 T'とセグメント情報を利用 → 挿入可能offsetをリストアップ xを無視した完全一致をとる 挿入可能offsetが一つしかないSegment → そこに配置するしかない = 決定！
18. セグメントの配置決定 セグメントを配置 → 配置可能箇所が減少する可能性 セグメントは重複しないため → 他のセグメントが決定可能になるかも → これ以上決定できなくなるまで反復
19. セグメントの解析結果 25文字以下のセグメント → ほぼ確定不可能 35文字以上のセグメント → ほぼ確定できる
20. セグメント配置の高速化 毎回検索していては遅すぎる！ → 配置可能ofsのテーブルを 最初に生成 そのテーブル生成も遅い！ → prefixツリーをその前に生成 → テーブル生成を10秒に短縮
21. 実装の詳細 〜確率的修復〜
22. 1: もっともらしいoffsetに配置 セグメントの配置先範囲に含まれる… ・多くのa,b,cで一致しているoffset かつ ・a,b,cの数が一定以上のoffset に優先的に配置する
23. 2: 長いセグメントから配置 長いセグメントほど置ける場所は少ない → 正解の可能性が高い と考える →長いセグメントで上書きしていく (確定的に配置された部分は上書きしない)
24. 結果
26. 入力データT'の視覚化
27. 確実に修復されたセグメント 全体の14.5%程度
28. さらに確率的修復をした結果
29. 正解データと比較
30. テストデータにおける実績 test1 83.46% test2 83.50% test3 83.32% test4 83.68% test5 83.42%
31. テストデータにおける実績 だいたい30秒以下 on 1.3 GHz Intel Core i5 (きっと計測環境はもっと速いはず…！)
32. まとめ
33. まとめ 速度と精度のトレードオフはよくとれた しかし 精度はそこまで上がらなかった → 決定的なモデルではなくて 確率的モデル？
34. Contributors
35. Source Code https://github.com/hikalium/kntn02