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
250
軌跡検索エンジンT-Torch論文紹介
社内勉強会資料です。
Takatomo Torigoe
February 26, 2021
Tweet
Share
More Decks by Takatomo Torigoe
See All by Takatomo Torigoe
型付きアクターモデルがもたらす分散シミュレーションの未来
piyo7
0
900
AI動画生成ガチャ紹介
piyo7
1
210
AIイラスト生成・編集テクニック紹介
piyo7
2
410
PandasAIにおけるLLMを用いた自然言語クエリの仕組み
piyo7
0
500
HdrHistogram紹介:ストリーミングで統計値を算出するための 高速・省メモリなライブラリ
piyo7
0
370
AI画像生成の紹介スライドをAI画像とAIチャットで作ってみた
piyo7
0
340
将棋AI「dlshogi」紹介
piyo7
1
760
DynamicでScalableな空間分割データ構造Bkd-Tree
piyo7
0
980
アドテクと機械学習
piyo7
0
360
Other Decks in Programming
See All in Programming
学習を成果に繋げるための個人開発の考え方 〜 「学習のための個人開発」のすすめ / personal project for leaning
panda_program
1
110
コンテキストエンジニアリング Cursor編
kinopeee
1
730
デザインシステムが必須の時代に
yosuke_furukawa
PRO
2
130
AIでLINEスタンプを作ってみた
eycjur
1
210
サイトを作ったらNFCタグキーホルダーを爆速で作れ!
yuukis
0
710
The State of Fluid (2025)
s2b
0
200
個人軟體時代
ethanhuang13
0
250
testingを眺める
matumoto
1
130
Google I/O recap web編 大分Web祭り2025
kponda
0
2.9k
旅行プランAIエージェント開発の裏側
ippo012
1
510
自作OSでDOOMを動かしてみた
zakki0925224
1
1.4k
パスタの技術
yusukebe
1
540
Featured
See All Featured
Understanding Cognitive Biases in Performance Measurement
bluesmoon
29
1.9k
Principles of Awesome APIs and How to Build Them.
keavy
126
17k
StorybookのUI Testing Handbookを読んだ
zakiyama
30
6k
Evolution of real-time – Irina Nazarova, EuRuKo, 2024
irinanazarova
8
900
Stop Working from a Prison Cell
hatefulcrawdad
271
21k
Being A Developer After 40
akosma
90
590k
Dealing with People You Can't Stand - Big Design 2015
cassininazir
367
27k
Templates, Plugins, & Blocks: Oh My! Creating the theme that thinks of everything
marktimemedia
31
2.5k
For a Future-Friendly Web
brad_frost
179
9.9k
The Psychology of Web Performance [Beyond Tellerrand 2023]
tammyeverts
49
3k
"I'm Feeling Lucky" - Building Great Search Experiences for Today's Users (#IAC19)
danielanewman
229
22k
Practical Orchestrator
shlominoach
190
11k
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などの検索エンジンがすでに あるため、実用的な軌跡検索を実装するのはそこまで難しくないかも?