论文笔记：MGeo: Multi-Modal Geographic Language Model Pre-Training-EW帮帮网

2023 sigir

1 intro

在导航地图（如 Google Maps）、打车应用（如 Uber）和外卖平台（如 Uber Eats）等位置服务（LBS）中，查询与兴趣点（POI）匹配是一项核心功能
- 其目标是根据用户的显式或隐式意图找到一组候选兴趣点
一个典型的查询-POI 匹配流程采用“两阶段检索-排序”的管线架构
- 轻量级的检索器首先从海量数据库中检索初步候选POI集合
- 排序器对这些候选项按相关性进行排序

一个查询通常会在目标 POI 的背景中提到多个地理对象
- 要实现准确匹配，完整地理解情境地理上下文（Geographic Context, GC）是必要的
- 例如，给定查询“地下通道上的学校门口”，虽然多个相关 POI 被检索出来，但只有“南开中学”的侧门 (c) 位于“地下通道”上，才是最匹配的目标。
——>提出了一种利用 GC 进行查询-POI 匹配的新方法，称为多模态地理语言模型 MGeo
- 包含一个地理编码器与一个多模态交互模块
  - 地理编码器将 GC 视作一种新模态进行建模
  - 多模态交互模块则融合了地理特征与语义特征，实现查询与 POI 之间的文本、地理及跨模态交互
受隐私限制，当前尚无公开的用于查询-POI 匹配的加密解除数据集可供研究使用
- 论文提出了GeoTES（Geographic Textual Similarity）数据集
  - 一个面向 GC 的查询-POI 匹配大规模开源基准数据集
  - POI 来源于开放 GIS 平台 OpenStreetMap（OSM），查询则由标注人员手工撰写，从而避免了隐私问题

传统的大规模语料检索方法通常采用精确的词项匹配
- 这类启发式检索器借助倒排列表结构具有低延迟的优点
- 但它们的相似度计算仅依赖文档统计特征
近年来，深度神经网络（DNN）被引入到信息检索（IR）中
- 考虑到效率与效果的权衡，PLM 相关的 IR 模型大致分为两种架构：bi-encoder 和 cross-encoder
  - 前者支持高效的索引，常用于检索阶段
  - 后者将查询与文档拼接后进行全面交互，虽能提供更精确的相关性估计，但计算成本更高，通常只用于排序阶段

设 P为兴趣点（POIs）的集合。
- P 可以是一个包含数十个候选 POI 的小集合，也可以是一个包含海量 POI 的大数据库
- 每个 POI p 包括文本描述 tp 和地理位置 lp
  - POI 的文本描述tp 包含其正式地址和名称
设 q 表示用户发起的查询
- 查询的文本描述 tq可分为三种类型：
  - 普通地址描述
  - 正式街道门牌号描述
  - 口语化描述
- 查询的地理位置 lq可以是用户当前位置，也可以是用户在地图上浏览某区域时所查看地图中心点的位置
  - lq 可能存在，也可能未被提供
将 POI 或查询的地理位置统一记作 lpq

给定 POI 集合 P 和用户的查询 q，目标是估计最符合用户意图的 POI p∈P
定义了两个子任务
- 排序任务
  - 对于排序任务，P是一个有限长度的候选 POI 列表，并且包含最匹配的 POI
- 检索任务
  - 在检索任务中，P 是包含所有 POI 的海量数据库，其总量非常大

给定 POI 或查询的位置 $l^{pq}$ ，其中l^{pq}以地理坐标（经度、纬度）表示，GC 由 $l^{pq}$ 与其邻近地理对象 $\{o_1, o_2, \ldots, o_n\}$ 之间的关系决定
形式上，关系类型 $r^t \in \{\text{NEAR}, \text{COVERED}\}$ 表示 $l^{pq}$ 是否在 oi内部，或与之存在某种距离。相对位置 $r^p$ 则描绘 $l^{pq}$ 与 oi 之间更详细的位置信息关系。

第一个用于 Query-POI 匹配 的开源基准数据集
- POI 数据来自开源的 OpenStreetMap (OSM)
- 查询由标注员手动生成，以避免隐私问题
在当前版本的 GeoTES 中，所有 POI 均位于 中国杭州，并使用 中文文本
每条查询都配有一个 正样本 POI，并在排序任务中提供数量有限的 负样本 POI

招募了 20 名标注员 和 4 名有经验的专家 来根据第3节定义的 POI 对三种类型的查询进行标注
- 为了模拟现实场景中查询的位置，标注员被要求对于 50% 的查询，在对应 POI 周围 1 公里范围内随机选取一个地理位置；其余查询则在全城市范围内随机选择一个位置