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
240
軌跡検索エンジンT-Torch論文紹介
社内勉強会資料です。
Takatomo Torigoe
February 26, 2021
Tweet
Share
More Decks by Takatomo Torigoe
See All by Takatomo Torigoe
型付きアクターモデルがもたらす分散シミュレーションの未来
piyo7
0
850
AI動画生成ガチャ紹介
piyo7
1
140
AIイラスト生成・編集テクニック紹介
piyo7
2
380
PandasAIにおけるLLMを用いた自然言語クエリの仕組み
piyo7
0
480
HdrHistogram紹介:ストリーミングで統計値を算出するための 高速・省メモリなライブラリ
piyo7
0
350
AI画像生成の紹介スライドをAI画像とAIチャットで作ってみた
piyo7
0
330
将棋AI「dlshogi」紹介
piyo7
1
740
DynamicでScalableな空間分割データ構造Bkd-Tree
piyo7
0
940
アドテクと機械学習
piyo7
0
350
Other Decks in Programming
See All in Programming
チームで開発し事業を加速するための"良い"設計の考え方 @ サポーターズCoLab 2025-07-08
agatan
1
480
SQLアンチパターン第2版 データベースプログラミングで陥りがちな失敗とその対策 / Intro to SQL Antipatterns 2nd
twada
PRO
26
7.5k
Vibe Codingの幻想を超えて-生成AIを現場で使えるようにするまでの泥臭い話.ai
fumiyakume
18
8.6k
RailsGirls IZUMO スポンサーLT
16bitidol
0
200
React は次の10年を生き残れるか:3つのトレンドから考える
oukayuka
37
13k
GPUを計算資源として使おう!
primenumber
1
280
構文解析器入門
ydah
7
1.7k
PipeCDのプラグイン化で目指すところ
warashi
1
310
AI時代の『改訂新版 良いコード/悪いコードで学ぶ設計入門』 / ai-good-code-bad-code
minodriven
24
9.9k
スタートアップの急成長を支えるプラットフォームエンジニアリングと組織戦略
sutochin26
1
7.5k
コーディングエージェント概観(2025/07)
itsuki_t88
0
100
AWS Summit Japan 2024と2025の比較/はじめてのKiro、今あなたは岐路に立つ
satoshi256kbyte
1
200
Featured
See All Featured
Stop Working from a Prison Cell
hatefulcrawdad
271
21k
Building Flexible Design Systems
yeseniaperezcruz
328
39k
Build The Right Thing And Hit Your Dates
maggiecrowley
37
2.8k
The Cult of Friendly URLs
andyhume
79
6.5k
Statistics for Hackers
jakevdp
799
220k
Mobile First: as difficult as doing things right
swwweet
223
9.7k
A designer walks into a library…
pauljervisheath
207
24k
Helping Users Find Their Own Way: Creating Modern Search Experiences
danielanewman
29
2.7k
A better future with KSS
kneath
238
17k
The Illustrated Children's Guide to Kubernetes
chrisshort
48
50k
Docker and Python
trallard
45
3.5k
Refactoring Trust on Your Teams (GOTO; Chicago 2020)
rmw
34
3.1k
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などの検索エンジンがすでに あるため、実用的な軌跡検索を実装するのはそこまで難しくないかも?