Upgrade to Pro
— share decks privately, control downloads, hide ads and more …
Speaker Deck
Features
Speaker Deck
PRO
Sign in
Sign up for free
Search
Search
軌跡検索エンジンT-Torch論文紹介
Search
Takatomo Torigoe
February 26, 2021
Programming
0
170
軌跡検索エンジンT-Torch論文紹介
社内勉強会資料です。
Takatomo Torigoe
February 26, 2021
Tweet
Share
More Decks by Takatomo Torigoe
See All by Takatomo Torigoe
AIイラスト生成・編集テクニック紹介
piyo7
2
240
PandasAIにおけるLLMを用いた自然言語クエリの仕組み
piyo7
0
340
HdrHistogram紹介:ストリーミングで統計値を算出するための 高速・省メモリなライブラリ
piyo7
0
240
AI画像生成の紹介スライドをAI画像とAIチャットで作ってみた
piyo7
0
290
将棋AI「dlshogi」紹介
piyo7
1
550
DynamicでScalableな空間分割データ構造Bkd-Tree
piyo7
0
720
アドテクと機械学習
piyo7
0
300
Let's Simulate a Quantum Computer with Pretty Scala
piyo7
0
28
量子コンピュータでニューラルネットワークな論文紹介
piyo7
0
35
Other Decks in Programming
See All in Programming
Vue SFCのtemplateでTypeScriptの型を活用しよう
tsukkee
3
1.5k
OpenTelemetryでRailsのパフォーマンス分析を始めてみよう(KoR2024)
ymtdzzz
4
1.5k
デプロイを任されたので、教わった通りにデプロイしたら障害になった件 ~俺のやらかしを越えてゆけ~
techouse
52
32k
Piniaの現状と今後
waka292
5
1.4k
Nuxtベースの「WXT」でChrome拡張を作成する | Vue Fes 2024 ランチセッション
moshi1121
1
500
レガシーな Android アプリのリアーキテクチャ戦略
oidy
1
170
Boost Performance and Developer Productivity with Jakarta EE 11
ivargrimstad
0
810
Snowflake x dbtで作るセキュアでアジャイルなデータ基盤
tsoshiro
2
430
Synchronizationを支える技術
s_shimotori
1
150
Why Spring Matters to Jakarta EE - and Vice Versa
ivargrimstad
0
950
Kaigi on Rails 2024 - Rails APIモードのためのシンプルで効果的なCSRF対策 / kaigionrails-2024-csrf
corocn
5
3.3k
Content Security Policy入門 セキュリティ設定と 違反レポートのはじめ方 / Introduction to Content Security Policy Getting Started with Security Configuration and Violation Reporting
uskey512
1
420
Featured
See All Featured
It's Worth the Effort
3n
183
27k
Building a Modern Day E-commerce SEO Strategy
aleyda
38
6.9k
Navigating Team Friction
lara
183
14k
BBQ
matthewcrist
85
9.3k
Writing Fast Ruby
sferik
626
61k
Embracing the Ebb and Flow
colly
84
4.4k
RailsConf & Balkan Ruby 2019: The Past, Present, and Future of Rails at GitHub
eileencodes
131
33k
Designing on Purpose - Digital PM Summit 2013
jponch
115
6.9k
The Invisible Side of Design
smashingmag
297
50k
Build your cross-platform service in a week with App Engine
jlugia
229
18k
How to Ace a Technical Interview
jacobian
275
23k
Faster Mobile Websites
deanohume
304
30k
Transcript
軌跡検索エンジンT-Torch 論文紹介 鳥越貴智 2021/02/26 データサイエンス共有会 #meetup_ds
T-Torch (Paper) Torch: a Search Engine for Trajectory Data (ACM
SIGIR 2018) 第一著者のSheng Wangは、この後も軌跡系の論文を発表している。 • Fast Large-Scale Trajectory Clustering (PVLDB 14) • A Survey on Trajectory Data Management, Analytics, and Learning (SIGMOD 2021)
T-Torch (Code) tgbnhy/torch-trajectory: The World's First Search Engine for Trajectory
Data Javaで書かれているが、Maven Centralなどでのパッケージ公開はしていない様 子。「git clone」すれば「mvn package」で、jarのビルドはできる。 ライセンスも宣言されていないため、あくまで論文実装という雰囲気。OSSとし て整備すれば需要はありそうだが……。
None
Boolean Search • Range Query: クエリの矩形内を一点でも通過した軌跡を検索。 • Path Query: クエリのパスと一点でも重なる軌跡を検索。
• Strict Path Query: クエリのパスを部分列として含む軌跡を検索。
Similarity Search クエリの軌跡に対して、類似度の高い順にK個の軌跡を取ってきたい。 元論文では、6つの類似度を対象としている。
Similarity Measures(記号列系) • Longest Overlapping Road Segment (LORS): 提案類似度。LCSSの亜種。 •
Longest Common Subsequence (LCSS): 最長共通部分列長。 • Edit Distance on Real sequence (EDR): 近ければ一致とみなす編集距離。 マップマッチング済みの エッジ長を足しこむ つまり重みのあるLCSS いかにも 動的計画法な 再帰式
Similarity Measures(点の距離ベース) • Dynamic Time Warping (DTW): 時系列データの類似度。点の数依存。 • Hausdorff
Distance: 部分空間の距離。 • Frechet Distance: 犬のリードに例えられる距離。
Upper Bounding LORS 軌跡長nと軌跡長mのLORSの計算量はO(nm) Similarity Search時、候補の軌跡ごとにO(nm)は重いので、まず上限を抑える。 軌跡Qと軌跡Tに共通するエッジの長さを合計するだけ。順番は考慮しない。 それぞれソート済みであれば、共通集合取る計算量はO(n + m)
(所感)LORSの使い所 • 同じ道は通ってないけれど並行する道路を走っている軌跡は類似度0になるの で、そういった軌跡も引っ掛けたい場合は適していない。 • 代わりに、記号列系の処理のため、DTWやFreshetよりはいかにも速そう。 • 長距離の軌跡で同じ幹線道路を通ったかどうかが重要な場合は使えそうだが、 マップマッチングでレーン分裂してないかどうかなどは気をつけたい。 •
LORSでいい場合は、LORSのUpper Boundをそのまま類似度として使っても、 実データ上はあまり問題ない気がする。そうそう折り返さないと思うので……
Pruning for LORS クエリ軌跡Qに含まれるマップマッチング済みエッジqごとに エッジ転置インデックスI_eを引いて エッジqを含む軌跡を候補集合canに加える。 候補軌跡ごとにLORS上限値を計算してソートする。 LORS上限値が高い軌跡から順に、実際のLORSを計算して、 Top-kのLORSが、残りのLORS上限値全てを上回ったら停止する。
※ 最悪、全候補軌跡のLORSを計算する可能性はあるはず。
Edge Inverted Index Patched Frame of reference on Deltas (PFor-Delta)
は、差分列をブロックごとに基準値から差分を取る。 Variable Byte (VByte) は、バイトごとに先頭1ビットを使って可変長数値を区切る。 どちらも転置インデックスでよく使われる圧縮方式らしい。 第11回 転置索引の圧縮:検索エンジンはいかにして動くのか?|gihyo.jp trajectory id → edge position → 同じエッジ持つ軌跡 が近くなるように IDを振り直して 圧縮効率を上げる 赤く囲ったところを Edge Inverted Index として最終的に保存 1 2 3 4
Pruning for LCSS/EDR 以下、LORSと同じ。 19行、20行は、 LORSは上限値計算時の共通部分列を覚えていれば、 軌跡の全エッジを覚えてなくてもいいよね、 他の類似度だとそういうことはできないよね、 という主張のようだが、LCSSでも同様のことはできるはず。
クエリ軌跡に含まれるバーテックスqごとに、 半径τ内に含まれるセルq’についてグリッドインデックスI_vを引いて、 セルq’を通る軌跡を候補集合canに加える。 元論文では、 LCSS/EDRはマップマッチングせず、 距離τ内のバーテックスを一致とみなす。 類似度選択とマップマッチングは別軸なので ちょっとズルい比較な気がする。 空間インデックスであれば R木やkd木など グリッドでなくてもよい。
Upper Bounding DTW/Hausdorff/Frechet DTW/Hausdorff/Frechetについても、距離のマイナスを類似度として上限値、 すなわち距離の下限値を抑えていきたい。 クエリ軌跡Qのバーテックスqiごとに半径rの正方形を取り、 その中に入っていない軌跡Tのバーテックスへの距離を下からrで抑える。 DTWの足し合わせる数の上限は |Q| ではなく
|Q| + |T| だと思われる。
Pruning for DTW/Hausdorff/Frechet Top-kの類似度が、残りの上限値全てを上回ったら停止する。 クエリ軌跡に含まれるバーテックスqごとに、 半径r_min + g*i_IRSの正方形に重なるセルq’について グリッドインデックスI_vを引いて、
セルq’を通る軌跡を候補集合canに加える。 停止するまで、セルの大きさを徐々に広げていく。
実験結果:データセット Proto (GeoLink)とT-Drive (Microsoft)はどちらもタクシーの軌跡データセット。 経路探索エンジンGraphHopper (OSS)でOpenStreetMapにマップマッチング。
実験結果:ストレージ使用量 → 類似度によって使うインデックスの使用量のみカウント マップマッチング ↓ PFor/VByteによる圧縮 ↓ 軌跡ID振り直し ↓ ↑
↑ trajectory edge ID position → R木を使うと使用量が膨れる
実験結果:クエリ時間 Map: クエリ軌跡をマップマッチング ? Filter: 類似度の上限値を計算しながら候補洗い出し? Refine: 正確な類似度を計算?
実験結果:ロバスト性 LORSとLCSSの差の主因はマップマッチングっぽいので、ズルい比較な気がする。 P@k: top-k result precision NDCG@k: normalized DCG レコメンドつれづれ ~第3回
レコメンド精度の評価方法を学ぶ~
(所感)まとめ 類似軌跡検索は、類似度に応じて「マップマッチング」「転置インデックス」 「空間インデックス」「上限抑えてフィルタリング」をうまく組み合わせたアル ゴリズムを作ることで、重い類似度計算の対象をできるだけ減らすことが重要。 マップマッチングについてはGraphHopperなどのライブラリ、「転置インデック ス」「空間インデックス」についてはElasticsearchなどの検索エンジンがすでに あるため、実用的な軌跡検索を実装するのはそこまで難しくないかも?