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
210
軌跡検索エンジンT-Torch論文紹介
社内勉強会資料です。
Takatomo Torigoe
February 26, 2021
Tweet
Share
More Decks by Takatomo Torigoe
See All by Takatomo Torigoe
AIイラスト生成・編集テクニック紹介
piyo7
2
310
PandasAIにおけるLLMを用いた自然言語クエリの仕組み
piyo7
0
400
HdrHistogram紹介:ストリーミングで統計値を算出するための 高速・省メモリなライブラリ
piyo7
0
290
AI画像生成の紹介スライドをAI画像とAIチャットで作ってみた
piyo7
0
310
将棋AI「dlshogi」紹介
piyo7
1
640
DynamicでScalableな空間分割データ構造Bkd-Tree
piyo7
0
830
アドテクと機械学習
piyo7
0
320
Let's Simulate a Quantum Computer with Pretty Scala
piyo7
0
33
量子コンピュータでニューラルネットワークな論文紹介
piyo7
0
47
Other Decks in Programming
See All in Programming
GitHub Actions × RAGでコードレビューの検証の結果
sho_000
0
280
なぜイベント駆動が必要なのか - CQRS/ESで解く複雑系システムの課題 -
j5ik2o
12
4.4k
SpringBoot3.4の構造化ログ #kanjava
irof
3
1k
Visual StudioのGitHub Copilotでいろいろやってみる
tomokusaba
1
180
昭和の職場からアジャイルの世界へ
kumagoro95
1
410
2024年のWebフロントエンドのふりかえりと2025年
sakito
3
260
AIの力でお手軽Chrome拡張機能作り
taiseiue
0
180
第3回関東Kaggler会_AtCoderはKaggleの役に立つ
chettub
3
1.1k
密集、ドキュメントのコロケーション with AWS Lambda
satoshi256kbyte
1
210
Unity Android XR入門
sakutama_11
0
170
苦しいTiDBへの移行を乗り越えて快適な運用を目指す
leveragestech
0
820
もう僕は OpenAPI を書きたくない
sgash708
5
1.8k
Featured
See All Featured
Side Projects
sachag
452
42k
The Power of CSS Pseudo Elements
geoffreycrofte
75
5.5k
[Rails World 2023 - Day 1 Closing Keynote] - The Magic of Rails
eileencodes
33
2.1k
Testing 201, or: Great Expectations
jmmastey
42
7.2k
Learning to Love Humans: Emotional Interface Design
aarron
273
40k
Automating Front-end Workflow
addyosmani
1368
200k
Building Adaptive Systems
keathley
40
2.4k
ピンチをチャンスに:未来をつくるプロダクトロードマップ #pmconf2020
aki_iinuma
114
50k
Producing Creativity
orderedlist
PRO
344
39k
"I'm Feeling Lucky" - Building Great Search Experiences for Today's Users (#IAC19)
danielanewman
226
22k
It's Worth the Effort
3n
184
28k
[RailsConf 2023 Opening Keynote] The Magic of Rails
eileencodes
28
9.3k
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などの検索エンジンがすでに あるため、実用的な軌跡検索を実装するのはそこまで難しくないかも?