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
250
PandasAIにおけるLLMを用いた自然言語クエリの仕組み
piyo7
0
350
HdrHistogram紹介:ストリーミングで統計値を算出するための 高速・省メモリなライブラリ
piyo7
0
250
AI画像生成の紹介スライドをAI画像とAIチャットで作ってみた
piyo7
0
300
将棋AI「dlshogi」紹介
piyo7
1
550
DynamicでScalableな空間分割データ構造Bkd-Tree
piyo7
0
730
アドテクと機械学習
piyo7
0
300
Let's Simulate a Quantum Computer with Pretty Scala
piyo7
0
30
量子コンピュータでニューラルネットワークな論文紹介
piyo7
0
35
Other Decks in Programming
See All in Programming
2024/11/8 関西Kaggler会 2024 #3 / Kaggle Kernel で Gemma 2 × vLLM を動かす。
kohecchi
5
920
Kaigi on Rails 2024 〜運営の裏側〜
krpk1900
1
220
Amazon Qを使ってIaCを触ろう!
maruto
0
410
どうして僕の作ったクラスが手続き型と言われなきゃいけないんですか
akikogoto
1
120
見せてあげますよ、「本物のLaravel批判」ってやつを。
77web
7
7.8k
광고 소재 심사 과정에 AI를 도입하여 광고 서비스 생산성 향상시키기
kakao
PRO
0
170
WebフロントエンドにおけるGraphQL(あるいはバックエンドのAPI)との向き合い方 / #241106_plk_frontend
izumin5210
4
1.4k
PHP でアセンブリ言語のように書く技術
memory1994
PRO
1
170
Streams APIとTCPフロー制御 / Web Streams API and TCP flow control
tasshi
2
350
as(型アサーション)を書く前にできること
marokanatani
10
2.7k
とにかくAWS GameDay!AWSは世界の共通言語! / Anyway, AWS GameDay! AWS is the world's lingua franca!
seike460
PRO
1
870
役立つログに取り組もう
irof
28
9.6k
Featured
See All Featured
Intergalactic Javascript Robots from Outer Space
tanoku
269
27k
ReactJS: Keep Simple. Everything can be a component!
pedronauck
665
120k
The Art of Programming - Codeland 2020
erikaheidi
52
13k
Performance Is Good for Brains [We Love Speed 2024]
tammyeverts
6
410
Practical Orchestrator
shlominoach
186
10k
Fashionably flexible responsive web design (full day workshop)
malarkey
405
65k
Git: the NoSQL Database
bkeepers
PRO
427
64k
How to Create Impact in a Changing Tech Landscape [PerfNow 2023]
tammyeverts
47
2.1k
Fight the Zombie Pattern Library - RWD Summit 2016
marcelosomers
232
17k
Unsuck your backbone
ammeep
668
57k
Ruby is Unlike a Banana
tanoku
97
11k
Faster Mobile Websites
deanohume
305
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などの検索エンジンがすでに あるため、実用的な軌跡検索を実装するのはそこまで難しくないかも?