TRIDENT GeoAI v2 解説
これは何
TRIDENT GeoAI v2のデモ
yuiseki.icon
code:prompt
Show UN facilities in New York City.
TRIDENT.icon
yuiseki.icon
code:prompt
Add hotels, police stations and train stations to this map.
TRIDENT.icon
yuiseki.icon
code:prompt
Show military installations in South Sudan.
TRIDENT.icon
yuiseki.icon
code:prompt
Add hospitals and shelters to this map.
TRIDENT.icon
yuiseki.icon
code:prompt
Show only military installations, after all.
TRIDENT.icon
yuiseki.icon
code:prompt
表示領域を首都に限定して
TRIDENT.icon
yuiseki.icon
code:prompt
スーダンと南スーダンの軍事施設を表示して
TRIDENT.icon
yuiseki.icon
code:prompt
台東区のお寺と神社を表示して
TRIDENT.icon
yuiseki.icon
code:prompt
やっぱり神社だけにして
TRIDENT.icon
yuiseki.icon
code:prompt
表示範囲に文京区と墨田区も加えて
TRIDENT.icon
yuiseki.icon
code:prompt
台東区のラーメン屋と蕎麦屋と寿司屋とピザ屋とハンバーガー屋を表示して
TRIDENT.icon
yuiseki.icon
code:prompt
やっぱりラーメン屋だけにして
TRIDENT.icon
yuiseki.icon
code:prompt
ウチの近所の最高に美味いラーメン屋が表示されてないじゃないか！どういうことだ！
TRIDENT.icon
うまくいく例だけを紹介しています
うまくいかないことも山ほどあります
自己紹介yuiseki.icon
仕事
OSS活動
モチベーション
災害の時にはやっぱり地図を紙で印刷して配れないと困る！！
モチベーション
OpenStreetMapの建物の住所情報を楽に楽しく充実させたい！！
モチベーション
タダでベクトルタイル地図をホスティングしたい！！
モチベーション
ベクトルタイル地図のスタイル定義をもっと柔軟に簡単にやりたい！
モチベーション
災害の時に通信環境が不安定でもデジタル地図を活用して災害対応したい！
モチベーション
国連平和維持活動や国連開発の最新状況をデジタル地図にしたい！
私とGeo&Lang
学士時の論文
グラフィティコミュニティのためのマップのデザイン
コミュニティ形成のためのマルチレイヤーマップのデザイン -ライブハウスコミュニティを事例として-
修士論文
街に着目した Twitter 上のメッセージ分析について
全体を通じた話の前提
私は人間並みに賢いGeoAIをいますぐ作ろう、作れる、とは思っていません OpenStreetMapには多くの改善の余地があるんだということに気づいて、積極的に貢献したくなるような、キッカケを作りたいと考えています
また、たとえ完璧なGeoAIではなくても、私の想像を超えた使い方をする人が現れて、それが誰かの役に立つかもしれないという、人の持つ可能性を俺は信じたいです ところでGeoAIって何？
私もよくわかっていません！！yuiseki.icon
https://gyazo.com/59603af0188a004ab5a37da01feeaf36
https://gyazo.com/da7282d5bfd13fecb2f2f5036557d02f
GeoAIでは、対話システムよりも、人工衛星画像の分析、地理空間情報データ分析、などのほうが主流かもしれないです 技術的な前提知識
今回の話で最も重要
使ってない
使ってない
今回の話で最も重要
PromptTemplate, Chain
Agent, Tool
ReAct
インタラクティブなWeb地図のUI開発に必要
今回は割愛
WikipediaとOpenStreetMap
NLP系の方々はWikipediaに馴染みが深いはず
同様に、OpenStreetMapにもAPIがある
そのうち最も強力なもののひとつが、Overpass API
Overpass APIとは読み出し専用のAPIであり、OSM地図データの中から個別に選択された部分を取り出します。Webを介したデータベースとして動作します。利用者はAPIに対してクエリを送り、クエリに対応したデータ セットを受け取ります。
編集に最適化されている標準のAPIとは異なり、OverPass APIはデータ利用者向けに最適化されています。利用者は数個の要素を即座に得たり、最大約1千万個の要素を数分かかって得ることができ、例えば位置、オブジェクトのタイプ、タグの内容、近接度やその組合せによる検索条件によって選び出すことができます。様々なサービスのデータベースのバックエンドとして動いています。
台東区の
病院を探す
code:overpass
(
);
out geom;
警察署を探す
居酒屋を探す
公園を探す
"leisure"="park"
ホテルを探す
"tourism"="hotel"
台東区と墨田区の病院を探す
code:overpass
(
);
out geom;
ポイント
エリアとタグがわかっていればOverpass APIのクエリを組み立てられる
便利ページ
TRIDENT GeoAI v2に至るまでの経緯
背景
https://gyazo.com/0b67931b29be63ee9ed63c90a7c78165
https://gyazo.com/18f0232cf9f6308b349a5a44ec97ba5c
Key findings
インタラクティブなデジタル地図における、Concernsという概念をここで考えて実装した
MUNDOにおけるConcernsとは
地図においてどの地物を強調して表示するのか、という興味関心、懸念事項
地図のThemeあるいはSubjectと呼んでも良いが、RailsをリスペクトしてConcernsと呼んでいる
MUNDOはConcernsをどう扱うか
YAMLファイルでOverpass APIクエリを簡易的に記述
YAMLファイルの記述を元にOverpass APIクエリを生成する
というアプローチ
MUNDOの特徴：Temporary Concerns（一時的な懸念事項）を扱える
OpenStreetMap は、「一時的な情報は取り扱わない」というポリシーがある
例えば、事件、事故、災害、紛争、通行止め、etc
MUNDOは、YAMLファイルでOpenStreetMapの地物のIDを指定して、地物のタグを追加する機能を持っている
https://www.youtube.com/watch?v=XEM5qz__HOU
AIが拠点への襲撃を検知、敵戦力を分析、戦場の地形と部隊配置を分析し最短ルート探索、味方戦力を確認、最適な撃退プランを立案、「実行準備完了。命令を送信しますか？」
https://pbs.twimg.com/media/FursbiMacAAF1y8.jpghttps://pbs.twimg.com/media/FurslB_aEAEfu0m.jpghttps://pbs.twimg.com/media/Furso3PaIAAexjL.jpghttps://pbs.twimg.com/media/Furst-AakAAsjWs.jpg
質問応答した結果に地名が含まれていた場合に、地図を表示する、限定的なGeoAIとしての機能がある
ChatGeoPTを参考に、一発のプロンプトでOverpass APIクエリを生成している TRIDENTの限定的GeoAI機能の問題点
レスポンスが遅い
デジタル地図としての柔軟性に欠けている
LangChain.jsのソースコードを読みまくった
LLMsにうまく出力させるための、プロンプトのテクニックのパターンが学べる
プロンプトは英語で書いたほうがいい
一発のプロンプトで全部解決するのではなくて、複数のプロンプトをうまく連携させるという考え方が重要
LangChain.jsのAgentとしてGeoAIを実装
Agentに以下の3つのToolを与えた
Overpass APIクエリのためのAreaを出力するツール
Overpass APIクエリのためのTagsを出力するツール
最終的なOverpass APIクエリを出力するツール
v1の問題点
レスポンスが遅い
複数のAreaや複数のConcernを扱えない
対話型にできない
リリースしてから3日間くらいでv2を思いついて実装・リリースしたので短命
v2の改善点
レスポンスが高速
複数のAreaや複数のConcernを扱える
対話型である
v1からの変更点
複雑な地図を表現するためのデータ構造を考え直した
Areas, Concerns, Stylesをセットで持つデータ構造にした
LangChain.jsのAgentを使うのをやめた
Agentを使わない三層のアーキテクチャになっている
表層、内層、深層の3つのLLMsがいる
TRIDENT GeoAI v2 データ構造
背景
Web地図の描画には以下が必要
地物の位置と形状
それをどのような見た目で表示するか
近年のWeb地図は、これらを分離したことで、柔軟な見た目の地図を作れるようになった
逆に、描画する際には、これらを結びつけてやる必要がある
データ構造の概要
地図は、複数の対象地域（areas）を持てる
対象地域は、複数の関心事（concerns）を持てる
関心事（concerns）は、それぞれstyleを持てる
具体例
code:geoai
対象地域A: 台東区
関心A: 駅
見た目: グレー
関心B: 病院
見た目: ピンク
対象地域B: 文京区
関心A: 駅
見た目: グレー
関心B: 病院
見た目: ピンク
TRIDENT GeoAI v2 三層アーキテクチャ
以下の3つの層になっている
表層
表層は、ユーザーと自然に対話して、どんな地図を作りたいのかという要望を聞き出すことに特化している
内層
内層は、表層とユーザーの対話履歴全体を分析して、複雑な地図を作るために必要な情報を、中間言語として出力することに特化している
深層
深層は、内層が出力した中間言語を元にOverpass APIクエリを生成することに特化している
なぜこんなややこしいことをしているのか？
非同期処理したいから
対話の応答も非同期でやりたい
対話の分析も非同期でやりたい
Overpass APIクエリを考えさせるのも非同期でやりたい
Overpass APIにリクエストするのも非同期でやりたい
TRIDENT GeoAI v1が遅かったのは、
LLMsに、複雑かつ巨大なOverpass APIクエリを出力させていたのが遅かった
Overpass APIに、複雑かつ巨大なOverpass APIクエリをリクエストしていて、レスポンスが遅かった
表層
表層は、「対話型オンライン地図構築アシスタント」である
平凡な対話プロンプトになっている
内層
内層は、「デジタル地図構築専用対話履歴分析アシスタント」である
内層は、ユーザーと表層の対話履歴を分析する
対話履歴から地理空間情報を特定できなければ、適切に諦める
内層は、Overpass APIクエリを直接出力はしない
内層は、Overpass APIクエリを構築し、結果を描画するのに必要な情報を、中間言語で出力する
中間言語は、JSONではなく、接頭辞＋改行区切りにしている
内層の出力する中間言語のフォーマット
code:geoai
ConfirmHelpful: text that meanings "Mapping has been completed. Do you have any other requests? Have we been helpful to you?", MUST be the last language written by the human
EmojiForConcern: emoji best suited to expressing specific concern, MUST be unique for each concern
ColorForConcern: color name best suited to expressing specific concern, MUST be unique for each concern, should be one of the name of Web Safe Color
Area: geospatial area mentioned by human
AreaWithConcern: pair of geospatial area and concern mentioned by human
... (You MUST ALWAYS output only one ConfirmHelpful)
... (this Area/AreaWithConcern/EmojiForConcern/ColorForConcern can repeat N times)
これはReActを強く参考にしている
ReActのプロンプトの一部：
code:react
Thought: you should always think about what to do
Action Input: the input to the action
Observation: the result of the action
... (this Thought/Action/Action Input/Observation can repeat N times)
中間言語の具体例
「スーダンと南スーダンの軍事施設の地図を作って」
code:geoai
EmojiForConcern: 軍事施設, 🪖
ColorForConcern: 軍事施設, pink
Area: スーダン
Area: 南スーダン
AreaWithConcern: スーダン, 軍事施設
AreaWithConcern: 南スーダン, 軍事施設
「台東区と文京区の駅と病院の地図を作って」
または「台東区の駅と病院の地図を作って」「そこに文京区も追加して」
code:geoai
EmojiForConcern: 駅, 🚉
EmojiForConcern: 病院, 🏥
ColorForConcern: 駅, gray
ColorForConcern: 病院, coral
Area: 台東区
Area: 文京区
AreaWithConcern: 台東区, 駅
AreaWithConcern: 台東区, 病院
AreaWithConcern: 文京区, 駅
AreaWithConcern: 文京区, 病院
深層
AreaWithConcern: 台東区, 駅
深層は、「OpenStreetMapとOverpass APIの専門家で、中間言語に基づいて、正確にOverpass APIクエリを出力する」
TRIDENT GeoAI v2 既知の課題と限界、今後の展望
MUNDOで実現できていた、Temporary Concerns（一時的な懸念事項）が扱えない
建物名を厳密に指定するとほぼ確実に地図描画に失敗する
中間言語にAreasとConcernsという概念しかないので、Pointsを表現できない
Overpass APIで特定の建物を正確に取得するのはかなり難しい
人間でも難しい
統計的な地理空間情報の可視化がしたい
いまはOpenStreetMapにある地物の可視化しかできない
Overpass API以外のAPIとも連携して、例えばコロプレス図を表示できれば、さらに多様な地理空間情報の可視化に使えるハズ PostGISのクエリを書かせたい
LLMsは、SQLも生成できる
ユーザーとの対話履歴を元に、PostGISのクエリを書かせたい
Palantir AIPのような、さらに高度で精密な地理空間情報の分析が可能になるはず
質疑応答コーナー
Ouchiさん
内層と深層
可能な限り非同期にするために中間言語は一行ずつにしている
TRIDENT失敗例まとめ：
「日本で"Sony"の名前を持つ会社・工場などを表示して」
→候補が多い／聞き方がファジー？特定社名が問題
以下のクエリでいけたので対応したyuiseki.icon
code:overpass
(
);
out geom;
name:enが適切に設定されていない建物が多いため表示件数が少ないのはOpenStreetMapを改善するしか無いですyuiseki.icon
「東京大学のすべてのキャンパスを表示して」
→場所ではなく範囲？
これは2023/5/24 14:23時点では正しくいけてそうですyuiseki.icon
2023/5/24 19:41 プロンプトをいじってたら不安定になってしまったので調整して強化しましたyuiseki.icon
「今Twitterで話題になっている場所を表示して」
→SNSのリアルタイム情報を拾っていない？
これはTwitterの最新の情報を収集してリアルタイムに分析しなければならないため、当面対応不可能ですyuiseki.icon
私にメチャクチャな大金を注ぎ込むパトロンになっていただければ、技術的には対応する自信があります
→しました
https://gyazo.com/d74d93314f9e29d9786e8597f3b0cad4
「これまでTwitterで最も話題になった場所を表示して」
→そもそもSNS情報を拾わない？
これはTwitterの過去全ての情報を収集して分析しなければならないため、当面対応不可能ですyuiseki.icon
私にメチャクチャな大金を注ぎ込むパトロンになっていただければ、技術的には対応する自信があります
→答えられませんと答えさせたい
→しました
https://gyazo.com/b5140744b89f4c5f1464fe16c0bc269c
「最近Twitterで話題になっている場所を表示して」
https://gyazo.com/eb4af421952cef208576a098df5b9cbb
「最近YouTuberがよく行ってる焼肉屋を教えて」
https://gyazo.com/3a16f0666cb751e156060e31f0d2cb93
「日本で開催されているG7サミットの場所を表示して」
https://gyazo.com/9ce70cd149c13b4adcdf524c3bdde85e
「台東区で一番評価の高いラーメン屋を教えて」
https://gyazo.com/cfb2e3d624197ce2ceb92f5bacae1947
「上野で一番人気の居酒屋を表示して」
https://gyazo.com/b7750b75e6dd16822a617468f3c05c07
「東京の品川区にある兵器開発をしている会社を表示して」
→業務内容（しかも特殊）まで聞くのは無茶？
こうした曖昧な要求を補完して正確なOverpass APIクエリを構築するのは非常に難しいですねyuiseki.icon
そもそも私もわからない……yuiseki.icon
GPT-4に聞いてみた
https://gyazo.com/721bc371c9172ea24f4c4881da0de3db
「東京の港区にある小児科の病院を表示して」
→港区の表示はできた→小児科は絞りすぎ？
小児科はOpenStreetMapでタグの定義はあるけど、日本では全く使われていないyuiseki.icon
code:overpass
(
);
out geom;
こういうアプローチのほうがいいかもしれない…yuiseki.icon
code:overpass
(
);
out geom;
Few-shotのExamplesを与えまくっているyuiseki.icon
SimilarityでExampleを選ぶExampleSelectorが有用なので採用したい
Sorami Hisamoto (MIERUNE)
OSMの地物を全てベクトル化してとかで、Overpassではない類似度APIが開発できると良いのですかね
なので、名前や説明文からとかはあるにせよ、より直接的に座標をベクトルの世界へ持っていける方法が求められるような
その他のGeo&Langな話題提供
モチベーション
OpenStreetMapのタグを元に自然言語で地物の説明文を書き起こす
それをEmbeddingにする
そうすれば、ユーザーの入力した自然言語の文章に意味的に近い地物をベクトル検索することができるはず
https://gyazo.com/efec0d29233d5bf02cebc414dc3ed911
https://gyazo.com/7599d7ac213ae267b7051d1165de22d1
ベクトルタイル地図の画像キャプション生成
OpenStreetMap標準スタイル
https://gyazo.com/8326800078a1420491ae266129e4be8a
意図的に単純化したスタイル
https://gyazo.com/264fef8837e24a25095e980ba575ebd4
https://gyazo.com/a32b169ece3be59dc8bacbd69124e8b7
https://gyazo.com/8447f104027d774b7a8bbbbb9aa8bb06