摘要
近年来，基础模型在自主工具使用和推理方面取得了显著进展，但其在基于地图的推理能力尚未被充分探索。为此，我们提出了MapEval，一个旨在评估基础模型在文本、API交互和视觉推理三项任务中的表现的基准测试。该测试涵盖了跨越180个城市和54个国家的700道多项选择题，涉及空间关系、导航、旅行规划以及真实世界的地图交互。与之前仅关注简单位置查询的基准测试不同，MapEval要求模型处理长上下文推理、API交互和地图视觉分析，使其成为地理空间人工智能最全面的评估框架。在对包括Claude-3.5-Sonnet、GPT-4o、Gemini-1.5-Pro在内的30种基础模型进行评估时，无一模型的准确率超过67%，开源模型表现尤为不佳，且所有模型较人类表现均落后20%以上。这些结果揭示了模型在空间推理方面的关键短板，例如在距离、方向、路线规划和具体地点推理等方面的困难，凸显了需要更强大的地理空间人工智能以缩短基础模型与真实世界导航之间的差距。所有资源均可在项目网站上获取。
1. 引言
近年来，基础模型的快速发展，特别是大型语言模型（LLMs）和视觉-语言模型（VLMs），显著提升了人工智能系统在自主工具使用（Qin等；Yao等，2023）和推理（Lu等；Wei等，2022）方面的能力。这些进展通过自然语言指令促进了日常任务的自动化，尤其是在需要与地图服务等专门工具交互的领域。 随着Google地图或Apple地图等平台在获取多种基于位置的服务（即工具/API，例如寻找附近的餐馆或确定从起点到目的地的最快路线）中变得无处不在，越来越多的研究兴趣集中于将地图与基础模型整合（Xie等；Zheng等，2024）。最近的一些尝试，例如WebArena（Zhou等）和VisualWebArena（Koh等，2024），提出了在实际场景中涉及地图使用的新任务。 然而，尽管地图服务的广泛应用以及基础模型（如LLMs和VLMs）与这些服务交互的潜在前景，尚没有研究严格测试基础模型在位置或地理空间推理方面的能力。这一研究空白至关重要，因为高效的基于地图的推理可以优化导航、促进资源发现以及简化日常生活中的物流工作。弥补这一空白对于推动人工智能在现实世界应用中的实际效用至关重要。 我们提出了MapEval，一个新颖的基准，用于评估基础模型和人工智能代理在复杂地图场景中的地理空间推理能力。MapEval通过评估模型处理异构地理空间上下文、执行组合作业推理以及与真实世界地图工具交互的能力，填补了现有基准中的关键空白。它包括三种任务类型——API、视觉和文本，要求模型通过地图工具收集世界信息、深度视觉理解，并对多样的地理空间数据（例如命名实体、坐标、营业时间、距离、路线、用户评论/评分、地图图像）进行推理，这些仍然是挑战性的任务。 针对最先进的基础模型来说，这是一项挑战。MapEval包含分布于180个城市和54个国家的700道独特的多选题，反映了真实世界用户与地图服务的交互，同时推动最先进的模型理解空间关系、地图信息图、旅行规划、兴趣点搜索和导航。MapEval确保了地理多样性、现实的查询模式以及跨多种模态的评估。通过整合长文本上下文、视觉复杂性、API交互以及需要常识推理或识别信息不足（即无解性）的问题，它为提升地理空间人工智能能力提供了严格的框架。在图1中，我们展示了MapEval的概览。借助MapEval，我们评估了30个知名的基础模型，其中Claude-3.5-Sonnet、GPT-4o和Gemini-1.5-Pro整体表现具有竞争力。然而，在MapEval-API中出现了显著差距，其中Claude-3.5-Sonnet代理的表现超出GPT-4o和Gemini-1.5-Pro分别16%和21%，与开源模型相比差距甚至更大。我们详细的分析揭示了模型的优势和弱点。尽管这些有所进步，所有模型在处理复杂地图图像和严格推理方面距离人类表现仍然相差超过20%，这凸显了MapEval在推动地理空间理解中的重要作用。
图 1. MapEval 概览。左侧展示了标注过程，专家通过从 Google 地图收集视觉快照或文本数据来创建带有真实标签的多项选择题。右侧描述了 MapEval 中三个基准任务的评估过程及其输入/输出。
（1）Step 1：地理数据采集（Expert + Google Maps）。由地理领域专家（Expert Annotator）从 Google Maps（谷歌地图）中采集两类关键数据，为后续问题构建提供真实场景支撑：
第一类，视觉上下文（Visual Context）：截取 Google Maps 的数字地图快照（如包含街道、POI 地标、路线的地图视图），覆盖不同缩放级别（如世界地图→城市街道级）、不同地理场景（如 urban 城区、natural 自然景观）；
第二类，文本上下文（Textual Context）：通过 Google Maps 获取 POI（兴趣点）的结构化文本信息（如地址、评分、营业时间、周边设施），例如图中示例 “迪拜购物中心周边餐厅信息”（包含麦当劳、Nando's 等餐厅的评分、价格等级）。
（2）Step 2：问题构建与标注（MCQ 生成 + 真值标注）。专家基于采集的 “视觉 / 文本上下文”，设计多选择题（MCQ） 及对应的 “真值标签（ground truth）”：
问题设计：问题需紧密关联地理空间推理需求，例如文本任务的 “迪拜购物中心周边哪家餐厅评分最高”、视觉任务的 “罗马旅游地图上是否有星级标记的医院”、API 任务的 “查询巴黎铁塔到卢浮宫的步行路线”；
选项与真值：每个问题配套 4 个左右选项（包含 1 个正确答案 + 3 个干扰项），真值标签需明确对应 “正确选项 + 推理依据”（如 “答案为 The GrillShack，依据是其评分 4.6 为所有餐厅最高”）。
（3）Step 3：数据格式标准化（适配三大任务）
核心操作：将标注好的 “上下文 + 问题 + 真值” 按 MapEval 三大任务类型拆分，形成标准化输入格式：
文本任务（Textual）：输入 “文本上下文 + 问题 + 选项”（如图中 “迪拜购物中心餐厅文本信息”+“最高评分餐厅查询”+4 个餐厅选项）；
API 任务（API）：输入 “问题 + 选项 + API 调用文档”（无预提供上下文，需模型主动调用地图 API 获取数据）；
视觉任务（Visual）：输入 “地图快照（视觉上下文）+ 问题 + 选项”（如图中包含街道与 POI 的地图图像 +“识别地标位置” 类问题）。
2. 右侧：评估流程（Evaluation Process）。这是 MapEval 基准的 “核心功能”，通过 “适配不同模型类型→输出结构化结果→对比真值评分”，量化评估模型的地理空间推理能力，具体分为 3 个关键环节：
（1）Step 1：模型类型适配（LLM/VLM/Agent 对应三大任务）
MapEval 根据任务特性，为不同基础模型分配专属评估链路，确保评估的 “针对性” 与 “公平性”：
Textual 任务→LLM（大语言模型）：如 GPT-3.5-Turbo、Llama-3.1-70B 等纯文本模型，输入 “文本上下文 + 问题 + 选项”，输出包含推理过程的答案（如 “通过文本中餐厅评分对比，The GrillShack 4.6 分最高”）；
API 任务→Agent（智能体模型）：如基于 Claude-3.5-Sonnet 构建的 ReAct Agent，输入 “问题 + 选项 + API 文档”，需主动调用地图 API（如 Nearby Search、Directions API）获取数据，再推理答案（如 “调用 Nearby Search API 查询迪拜购物中心周边餐厅，对比评分后选择 The GrillShack”）；
Visual 任务→VLM（视觉语言模型）：如 GPT-4o、Qwen2.5-VL-72B 等多模态模型，输入 “地图快照 + 问题 + 选项”，需解析地图中的视觉元素（如 POI 图标、路线标识、文字标注），再推理答案（如 “从地图中识别星级医院标记，判断是否存在”）。
2. 相关工作
地理空间问答对基础模型提出了显著挑战（Mai 等人，2024）。早期关于 GeoQA 的研究（Mai 等人，2021）集中于基于模板的方法（Zelle 和 Mooney，1996；Chen 等人，2013；Chen，2014；Punjani 等人，2018；Kefalidis 等人，2023），其中预定义模板用于对查询进行分类，并从结构化数据库（如 OpenStreetMap 或 DBpedia（Auer 等人，2007））中检索信息。这些方法在某些场景中表现有效，但由于数据库的静态性质和预定义模板的限制，在处理复杂或动态查询方面缺乏灵活性。在评估（Roberts 等人）和提高大型语言模型（LLM）地理空间推理能力方面的努力较少（Balsebre 等人，2024）。最近的基准测试，例如 Travel Planner（Xie 等人）、ToolBench（Qin 等人）和 API-Bank（Li 等人，2023），整合了地图工具和 API 用于基于位置的查询。这些基准测试处理现实任务，如行程规划或查询地图数据，但地图 API 的使用仅限于较简单的应用场景，例如计算距离或识别附近兴趣点。此外，遥感研究（Bastani 等人，2023；Yuan 等人，2024；Zhang 等人，2024；Lobry 等人，2020）主要集中于从卫星图像中提取物理特征。尽管这对环境监测和城市规划非常有价值，但这种方法与在交互式数字地图视图上推理的任务有显著不同。涉及在动态、用户交互的环境中理解空间关系、地图符号和导航元素。关于基于模板的方法、涉及地图API的基准测试以及与遥感方法的比较的详细讨论，请参见附录A。
3 MapEval 数据集
3.1 设计原则
推理。地图任务中的地理空间推理对基础模型提出了独特的挑战，包括：(a)理解自然语言中复杂的问题描述，(b)使用地图工具或 API 收集相关的世界信息，(c)执行组合和时空推理，(d)解释地图图像，(e)从异构地理空间背景中综合信息（例如，命名实体、距离和时间值）。这些任务测试了最先进模型的极限，这些模型难以全面理解地理空间关系、导航复杂性以及兴趣点（POIs）。
真实性。MapEval通过捕捉用户在使用地图服务中的典型交互，反映了真实世界地图使用场景，例如：(a)定位搜索和旅行规划等多样化的使用模式，以及(b)非正式、不完整的查询，无需严格遵循语法或结构。
多样性。MapEval确保地理上的多样性以及模型和任务覆盖的广泛评估：(a)捕捉全球范围内各城市和国家的地理位置，(b)提供各种问题类型和背景，测试基础模型的空间、时间、数据检索和视觉推理能力。
长文本、多模态、API交互。MapEval对模型提出挑战：(a)长篇地理空间描述，包括兴趣点和导航数据，(b)复杂的地图特定图像，如位置标记，(c)API交互，测试模型作为语言代理处理真实地图任务的能力。
无法回答性与常识。MapEval包含情境不足以提供答案的问题，测试模型识别信息缺失或不完整的能力，而不是作出错误的猜测。它也评估常识推理和处理不确定性的能力，这对于在真实世界中可靠决策至关重要。
选择题（MCQs）。我们在MapEval中使用多项选择题（MCQs），类似于MMLU（Hendrycks等），而非开放式问题。这种方法避免了与生成型响应评估相关的挑战（如Sai等，2022），提供了更直接且可靠的基于准确性评估地图推理能力的方法。如附录G.2所讨论，我们也评估了MapEval的开放式问题变体，以考察其超越选择题形式的灵活性。
成本效益与集中特性。为保持成本效益高且全面的评估框架，MapEval包含700个实例，旨在覆盖多样化的地理空间推理任务、问题类型和全球位置。这个集中的方法确保了可管理的测试环境，同时提供足够的多样性以进行稳健可靠的评估，避免冗余而不牺牲深度或广度。
3.2 任务
文本任务。MapEval-Textual的目标是通过解析复杂查询并从长期的文本上下文中提取相关信息来回答选择题。这些上下文描述地图位置、兴趣点（POIs）、路线、导航细节和旅行距离/时间，通常包括用户评级或评论。与典型的阅读理解任务不同，这些文本结合结构化数据（例如坐标、距离）与非结构化叙述及主观内容。模型必须解析这些异构信息以选择正确答案。该任务评估模型分析文本中呈现的细致地图相关信息的能力。
API任务。在MapEval-API任务中，一个AI代理与基于地图的API交互以检索数据（例如附近的兴趣点、距离计算）。任务涉及根据用户问题生成API查询，解释返回的结构化数据，并将其整合到推理过程中以回答选择题。该任务评估模型在处理数据检索、API交互以及合成结构化信息时的能力，考察其在真实地图驱动场景中的表现。
视觉任务。MapEval-Visual任务要求模型解释并分析地图快照，主要是来自谷歌地图等服务的数字地图视图。这些快照呈现复杂的空间关系、路线、地标、光学字符识别（OCR）的文本（例如评价），以及符号元素（例如标志或交通标志），与典型图像识别任务不同。模型必须从视觉中提取相关信息，将其与空间推理结合，并用于回答选择题。该任务评估模型处理地图特定视觉内容以及执行空间推理的能力。
3.3 数据集构建
数据标注。为了创建高质量的MapEval基准数据集，我们采用了广泛应用的地图服务——谷歌地图。构建文本上下文的过程中存在显著的挑战，特别是在确保数据的准确性和效率方面。例如问题“哪些是开放要回答“英国博物馆的开放时间？”这一问题，需要精准的数据以提供有效的选项和正确答案。手动在Google地图上搜索“英国博物馆”并寻找其开放时间既耗时又容易出错，使得这种方法效率低下。为了解决这些问题，我们使用了MapQaTor（Dihan等, 2024），这是一个基于Google Maps API开发的网页界面，旨在简化文本地图数据的收集。MapQaTor通过自动化从地图API中检索数据，收集了诸如开放时间和位置信息等关键数据，以构建文本数据集（详情见附录B.1）。对于每个用户查询，我们首先使用MapQaTor提取必要的上下文数据。然后，将问题与相应的上下文配对，并根据这些信息精心设计多项选择题选项。答案的标准参考则基于相同的上下文数据。 在MapEval-API中，使用的提问和MapEval-Textual一致，但未提供文本上下文，要求语言代理直接与工具交互。为了解决实时数据更新带来的不一致性问题，我们创建了一个受控评估环境，包括缓存地点信息并模拟API交互。关于伪Google地图设置的细节见附录C。 针对视觉上下文，我们从Google地图中截取地图快照，覆盖世界各地不同城市和国家的随机位置。根据每张快照，我们设计了相关的问题并配以多项选择题，正确答案直接来源于地图信息。为保持可追溯性，我们保存了每张快照对应的Google地图URL。此外，为了研究模型在不同缩放级别下的能力，我们截取了不同缩放深度的快照。 我们为MapEval创建了以下问题类型：(a)地点信息：检测兴趣点并询问与某地相关的具体细节（如位置、评分、评论）；(b)附近检索：识别附近的地点或兴趣点；(c)路径规划：在地点之间导航，考虑路线和地标；(d)无法回答：当地图信息（如来自Google地图）或文本及视觉上下文不足以回答问题时。需要注意的是，在每一类别中，我们设计了一些需要通识知识或关于位置和导航推理的问题（例如，在MapEval-Visual中有52个常识问答）。 此外，MapEval-Textual和MapEval-API独有旅行类问题，这类问题涉及规划跨越多个兴趣点的多站点旅程。由于旅行规划的复杂性和细节，这类问题难以用单一的视觉快照表现。相反，计数任务是MapEval-Visual独有的，要求模型在地图上计数特定项目或地点——这是专为视觉上下文设计的挑战。 质量控制与人工表现 为了确保质量，每一组问答对都由多个团队成员进行标注。
团队初步达成了76%的互相一致性。随后，至少有两名团队成员手动验证并解决剩余对中的争议；如果无法达成共识（即存在歧义），则剔除该对。为了计算人工得分，由两名未参与标注过程的团队成员尝试回答问题，并将其得分最高的尝试作为人工性能基准报告。对于MapEval-API，由于问题与MapEval-Textual相同，我们报告两者相同的人工性能。
3.4. 数据集统计与分析
MapEval的主要统计数据见表2和图2。每种问题类型的例子及数量见表15。我们使用坐标可视化数据集中位置的全球分布（附录图7）。表12（附录）列出了所有国家及其在MapEval中的频率。我们使用OpenStreetMap的Nominatim API进行反向地理编码以从坐标中确定国家。文本上下文包括其中的地点坐标。对于视觉上下文，可以从每个快照关联的地图URL中找到坐标。例如，一个示例URL的坐标是35.7048455,139.763263。我们在附录中可视化了问题和文本上下文长度的分布（图5和图6）。总体而言，除了在类型上的多样性之外，问题和上下文在长度上也显著变化，反映了不同水平的复杂性和详细程度。此外，在附录F.1中，我们展示了MapEval-Visual中的缩放级别分布，为数据集的多样性和评估挑战增添了另一个维度。
表1. 不同问题类别的示例。MapEval-Textual 和 MapEval-Visual 问题同时包含文本和视觉上下文（完整的示例查询、上下文以及评估模型输出请参见附录I）。
4. 实验
4.1. 实验协议和设置
我们使用准确率指标评估所有任务，准确率定义为模型选择正确选项的百分比。我们通过提供相关的上下文、问题、工具使用文档（仅适用于 MapEval-API）、答案格式指南以及选项来提示模型。我们评估用于 MapEval-Textual 的大型语言模型 (LLMs)、用于 MapEval-Visual 的视觉语言模型 (VLMs)，以及基于各种 LLM 构建的 MapEval-API 的 ReACT agents（Yao 等, 2023）（以其在工具交互中的有效性而闻名 (Zhuang 等, 2023)），将每项任务与适合的模型类型对齐。附录 I 提供了所有任务的示例提示。我们的 LLMs 和 VLMs 包括开源和闭源模型。闭源模型包括 Claude-3.5-Sonnet、GPT4o、GPT-4-Turbo、GPT-3.5-Turbo、Gemini-1.5（Pro, Flash）；除了 GPT-3.5-Turbo 之外，这些模型均为用于所有任务的多模态基础模型，而 GPT-3.5-Turbo 仅能处理文本，因此仅用于 MapEval-Textual 和 MapEval-API 任务。开源 LLMs 包括 Gemma-2.0（9B, 27B）、Llama-3.2（3B, 90B）、Llama-3.1（8B, 70B）的 instruct 版本、Mistral-Nemo-7B、Mixtral-8x7B。
Qwen2.5（7B、14B、72B）、Phi-3.5-mini。在MapEvalVisual任务中，我们考虑了以下开源视觉语言模型（VLMs）：Qwen2.5VL-72B-Instruct、Qwen2-VL-7B-Instruct、Llama-3.2-90BVision、MiniCPM-Llama3-V-2 5、Llama-3-VILA1.5-8B、glm-4v-9b、InternLm-xcomposer2、paligemma-3b-mix-224、DocOwl1.5、llava-v1.6-mistral-7b-hf，以及llava-1.5-7b-hf。在MapEval-API任务中，我们重点研究了高容量的开源大型语言模型（LLMs），具体包括Llama-3.290B、Llama-3.1-70B、Mixtral-8x7B和Gemma-2.0-9B。由于任务的复杂性和资源需求、小型模型的性能不佳，以及对LLMs和地图API的调用次数过多，我们对开源模型在AI代理中的评估范围有所限制。
4.2. 结果与分析
4.2.1. MAPEVAL-TEXTUAL
我们在表3中展示了MapEval-Textual的摘要结果，提供了关于语言模型中地理空间推理的当前状态的洞察。闭源模型通常表现优于开源模型，其中Claude-3.5Sonnet达到66.33%的准确率，而表现最好的开源模型Llama-3.1-70B达到61.00%。然而，顶级模型与人类准确率（86.67%）之间的显著差距突显了地理空间推理任务的挑战。模型在“位置信息”“附近”和“路线”任务中表现较好（最佳表现约75%），这得益于MapEvalTextual提取的全面上下文，例如文字描述、开放时间和距离。相比之下，“行程”规划场景的表现仍较差（最佳约49%），反映出在处理多步推理和汇总时空约束方面的困难。在“无答案”查询中的表现差异较大，Gemini-1.5-Pro达到85%的准确率，而大多数模型介于0-45%之间。这种差异突出了在实际应用中识别信息不足的重要性。“行程”任务的一贯低表现以及“无答案”查询中的差异化准确率反映了各种结构在地理空间推理中的根本局限性。结果还表明，大型模型通常表现优于小型模型。然而，开源模型与闭源模型之间的差距则显示了开源系统仍有进步空间。此外，图17揭示了开源模型在处理更长上下文时所面临的挑战。
4.2.2. MAPEVAL-API
我们在表4中展示了MapEval-API的结果，突出了关于地理空间推理能力的关键洞察。语言模型结合地图 API。与 MapEval-Textual 相比，MapEval-API 在总体表现上较差，特别是在“附近”任务（从 74.70% 降至 55.42%）和“路线规划”任务（从 75.76% 降至 65.15%）中的表现有显著下降。图 3 展示了这些差异。虽然 Claude-3.5-Sonnet 的表现较为稳定，但其他模型由于缺乏上下文和工具复杂性而出现下降，这突显了超越 ReAct 能力的高级代理的必要性。在“行程”类别中，MapEval-API 相比 MapEval-Textual 提升了约 22%，表明其在逐步推理处理复杂问题方面的有效性。Claude-3.5-Sonnet 以 64.00% 的总体准确率领先，其工具代理角色和通用图推理表现都十分优秀。然而，闭源模型与开源模型之间仍存在显著差距，性能最佳的开源模型 Llama-3.2 90B 仅达到 39.67%。在“无法回答”的查询中，表现差异较大（5% 到 65%），这凸显了更好处理信息不足问题的需求。
4.2.3. MAPEVAL-VISUAL
我们在表5中对模型在MapEval-Visual任务上的表现进行了评估。闭源模型的表现优于开源模型，其中Claude-3.5-Sonnet以61.65%领先，紧随其后的是GPT4o（58.90%）和Gemini-1.5-Pro（56.14%）。在开源模型中，Qwen2.5-VL-72B取得了最高的准确率（60.35%）。尽管模型在地点信息任务上表现出色（82.64%），但在计数、邻近查询和路径规划等复杂任务上表现不佳，凸显了改善的需求。在普通图像上训练的模型在地图特定任务上的表现不佳，这可能是由于缺乏对详细地图数据的充分接触所致。附录中的图21显示，在更高的缩放级别（如街道、符号、边界标记）超出14级时，模型的准确率显著下降，这与地图复杂性增加相关。我们的基准测试揭示了AI与人类在微妙任务上的显著差距。例如，人类在路径规划任务上达到85.18%的准确率，而最佳模型仅为50%；在人口统计任务上，人类达到78.41%，而最佳模型仅为47.73%。尽管闭源模型如Claude-3.5-Sonnet和Gemini-1.5-Pro在识别无法回答的问题方面表现出色（分别达到90%和80%），但开源模型的表现却显著落后。
4.3. 质性错误分析
在基于位置的查询中，LLMs在空间、时间和常识推理方面存在困难。在空间推理中，它们往往在直线距离（列表1）、方位（例如东、西、南、北；列表2）和逐步路径规划（包括涉及数学计算或计数的任务，如附近餐馆的数量；列表3）上失败。在时间推理方面，挑战包括低效的行程规划以及旅行时间或访问持续时间的错误（列表4）。常识推理的失败则表现在模型可能产生幻觉或忽略简单的情境信息。
推导（列表5）。基于LLM的代理同样在地图工具和API的使用中表现不佳，尤其是在附近查询和路线查询中。不正确的参数使用会导致失败，例如遗漏关键参数、使用不兼容的值，或者在没有有效结果时进入无限请求循环。视觉任务暴露出进一步的问题，例如VLMs难以保持空间意识，错误识别位置接近的兴趣点（POIs），或者在地图图像中错误计算POIs的数量（例如，商场/商店）。这些限制突显了更好的空间意识、时间推理以及鲁棒工具使用的必要性（详见附录E）。
5. 解决失败问题并增强LLMs的地理空间推理能力
MapEval-Textual中的失败：为了进一步分析LLMs在MapEval-Textual中的表现，我们检查了一部分需要以下能力的问题子集：（i）直线距离计算（47道问题），（ii）确定基本方位（24道问题），以及（iii）与计数相关的查询（23道问题）。结果显示模型在这些任务中的表现存在显著差异（图11、图12、图13）：（i）Claude-3.5Sonnet在识别基本方位中获得最高准确率（91%），而Gemma-2.0-27B得分最低（16.67%）。 （ii）直线距离计算对所有模型而言都构成挑战，最高准确率仅为51.06%。（iii）计数任务也证明较为困难，表现依然不佳。即使Claude-3.5-Sonnet的表现也不如开源的Gemma-2.0-27B（准确率为60.87%）。复杂空间计算的计算器集成：这些结果表明，大型语言模型在涉及精确数值计算的空间推理任务中表现不佳。为减轻这些限制，我们通过整合外部工具（例如计算器）来扩展模型功能，用于计算距离和确定心脏相关任务。
有关方向细节的说明（见附录G）。这导致了显著的性能提升（表6）：（i）Claude-3.5-Sonnet在计算直线距离的准确率从51.06%提高到85.11%；（ii）GPT-4o-mini最初在方位识别方面存在困难，其准确率从29.17%提升至91.67%；（iii）即使是像Gemma-2.0-9B这样的开源模型，在直线距离任务中的准确率也从29.79%提高到了68.90%。这些结果强调了在没有外部支持的情况下，大型语言模型（LLMs）在空间推理方面面临的挑战。整合工具可以让模型将计算密集型任务卸载出去，从而产生更精准且可靠的结果。然而，空间推理仅是基于位置任务中模型表现不足的一个方面。时间推理任务（例如计算旅行时间或确定最佳访问时间）同样可能从工具整合中受益。扩展工具支持可以提高多个领域的表现，但同时也会增加架构复杂性，需有效管理多样化的工具。
MapEval-API中的失败：在基于ReAct的系统中，一个显著的挑战是将提取问题相关参数、调用带有这些参数的API、并基于API响应提供最终答案的重任归于单一智能体。这一复杂流程通常导致如参数提取错误、不正确的API调用或死循环问题（例如，GPT-3.5-Turbo出现16次无限循环；见图19）。当智能体在任务推理上面临困难时，这些问题会更加显著，从而降低任务完成率。此外，即便是以纯文本形式处理大批量的API数据（即MapEvalTextual任务中的长上下文处理），对于大型语言模型来说仍是一个重大挑战，如第4.2.1节中讨论的那样，这在表3的低性能表现中得以体现。
工具与模型的自适应路由：为了解决这些限制，Chameleon框架（Lu et al., 2024）通过自适应地将任务分解为多个工具使用模块（例如，多智能体系统）提供了一个强大的解决方案。
将Chameleon集成到MapEval-API中已经显著提升了GPT-3.5-Turbo的性能（表7）。此外，Chameleon在分解任务和更高效地处理错误方面的能力减少了参数提取错误的发生，并避免了死循环，从而显著提高了准确性。另一个具有潜力的替代方案是开发一个集成系统，该系统将查询分类器与特定类型的LLM部署结合起来。该系统首先对传入的查询进行分类，然后将其路由到表现最佳的针对特定查询类型的LLM，从而可能实现更优的性能。
6. 结论
本文介绍了MapEval，这是一套用于通过文本、基于API和视觉评估模式来衡量基础模型在地理空间推理能力上的基准数据集。MapEval整合了多样化的真实场景，以评估模型在地理空间推理任务中的能力。我们的研究发现，虽然诸如Claude-3.5-Sonnet、GPT-4o和Gemini-1.5-Pro等主流模型在某些领域表现出色，但与人类的准确度相比仍存在差距，尤其是在使用开源基础模型时。这凸显了在处理复杂的基于地图的查询中需要改进的关键领域，这类查询要求多步骤时空推理、高效的工具利用以及领域特定知识的管理。未来的工作可以专注于开发专门的地理空间模型，将LLM与诸如地图API等外部工具集成，以及增强VLM对地图图像的视觉理解能力。我们期望MapEval能够催化地理空间推理以及更广泛的问答领域的后续研究。
影响声明
我们通过提供实验中使用的完整数据集和评估代码，确保结果的可重复性。这些资源包括LLM推理过程的详细信息，例如温度、top-k和top-p等参数。为了保持长期可用性，任何更新或错误修复将会在仓库中提供。
尽管如此，我们的研究仍存在一些局限性。数据集主要关注了谷歌地图API中的五个类别（“地点”和“路线”分类下的文本搜索、地点详情、附近搜索、路线规划和距离矩阵），未包含其他类别，例如地图和环境。这限制了查询的多样性和地理空间洞察的评估。此外，这些API的更新可能会导致数据集在实时应用中相关性降低，更适合档案研究目的。
我们的结果在其他领域或工具中的通用性尚未得到验证，而提示形式的变化（可能影响结果）也未进行探索。
研究可以通过整合更广泛的API范围、考察提示设计的影响以及在不同领域中测试方法来弥补这些空白。通过承认这些局限性并共享我们的资源，我们旨在支持正在进行的研究并鼓励进一步探索使用LLMs进行地理空间推理任务。
致谢
我们诚挚感谢卡塔尔计算研究院（QCRI）提供API访问权限和计算资源支持，包括GPU支持，这对本研究的进行起到了重要作用。
A. 详细相关工作
A.1. MapEval-Textual
基于模板的地理问答模型（Zelle & Mooney, 1996；Chen et al., 2013；Chen, 2014；Punjani et al., 2018；Kefalidis et al., 2023）主要采用两步策略回答地理问题：（1）将自然语言查询分类到预定义模板中，（2）利用这些模板查询结构化地理知识来源，例如 PostGIS、DBpedia（Auer et al., 2007）、YAGO（Suchanek et al., 2007）、Freebase（Bollacker et al., 2007）和 OpenStreetMap。这些方法对结构化查询非常有效，但受限于预定义问题模板及其对静态数据库的依赖。它们通常将自然语言问题转换成结构化查询语言脚本。例如，GeoQuestions1089（Kefalidis et al., 2023）包含1089个问题及其对应的 GeoSPARQL（开放地理信息联盟，2011）查询，这些查询基于 YAGO2geo（Karalis et al., 2019）空间知识图。
相比之下，我们的 MapEval-Textual 方法将重点从数据库查询转移到评估大型语言模型（LLMs）的地理空间推理能力。标注员利用 MapQaTor 收集事实地图服务数据，然后将其作为上下文提供给 LLMs。这一设置隔离并评估模型在复杂动态环境中进行地图相关自由形式问题推理的能力。这种方法能够更全面地评估 LLMs，反映用户在真实场景中通过自然语言与地图工具交互的方式。因此，在 MapEval 中，回答问题的责任归于 LLMs，而在之前的工作中，模型的任务是生成查询（例如 Geoquery、GeoSPARQL），这些查询被用于访问外部知识库。
GPT4GEO（Roberts et al.）探索了 GPT-4 的地理事实知识，通过研究其在没有插件或互联网访问的情况下对世界知识的“了解”。他们的评估着重于通过模板化查询分析单一模型对常见地点和方向事实的理解，例如关于知名城市和地点的路线规划和导航。然而，这种方法本质上受限于 GPT-4 的训练数据，使其无法回答涉及较不知名地点的问题。虽然研究结果表明 GPT-4 展现了令人鼓舞的地理空间知识，这种方法既未建立地理空间推理的基准，也未包含真实用户查询或地图服务（如 Google Maps）作为地理信息库。
我们的方法采用了根本不同的评估和设计原则。我们通过真实用户查询而非模板建立跨多个基础模型的深层地理-时空推理能力基准测试。另外，我们的评估独特地涵盖了多模态理解、工具交互以及可回答性评估。此外，我们通过上下文和 API 访问为基础模型提供细粒度的地图服务数据，从而对其地理问答能力进行更全面的基准测试。
A.2. MapEval-API
MapEval-API 任务采用了一种实用的方式，通过利用地图 API 直接回答位置相关问题，为评估大型语言模型（LLMs）在地图推理上的能力提供了更贴近现实的场景。最近在 LLMs 方面的进展引发了对规划任务（Xie et al.；Balsebre et al., 2024；Zheng et al., 2024；Fang et al., 2024）的兴趣，这些任务涉及地图数据。例如，Travel Planner（Xie et al.）基准评测利用 Google Maps API 评估多天行程规划，包括距离、旅行时间以及附近景点的详情。该任务展示了地图数据在现实规划场景中的用途，突出了 LLMs 将实时地理信息整合到决策中的潜力。
此外，诸如 ToolBench（Qin et al.）和 API-Bank（Li et al., 2023）等工具调用基准测试已将位置相关查询作为子任务，测试 LLMs 结构化与 API 交互的能力。这些基准测试通常专注于更简单的查询类型，例如检索距离或附近兴趣点（POIs），但它们未充分回应现实世界中地图相关问题的复杂性和多样性。
相比之下，MapEval-API 通过评估 LLMs 在各种复杂地理空间任务中的表现推动了边界。这些任务不仅需要查询地图 API，还需整合包括旅行计划、附近服务以及时空推理在内的多种信息。这种更全面的基于 API 的推理评估挑战模型处理复杂多样化问题的能力，突出了其有效应对精细地图交互的能力。
从API检索数据并进行合成。
A.3. MapEval-Visual
针对地理空间分析和基于地图的问题回答的以往研究主要集中在遥感图像（Bastani等，2023；Yuan等，2024；Zhang等，2024），这些图像涉及卫星或航拍影像。这些图像通常包含关于地球表面的复杂数据，包括土地覆盖、植被、城市基础设施以及其他环境特征。用于解释遥感图像的模型（Lobry等，2020）通常依赖卷积神经网络（CNNs）及其他计算机视觉技术进行目标检测、分割和分类任务。这些方法常常着眼于从高分辨率图像中识别道路、建筑物和自然特征等物理实体。
相比之下，我们的MapEval-Visual方法侧重于数字地图视图快照，这些快照是地图服务（如Google Maps）的二维表示形式。不同于遥感图像，它们通过顶视角捕捉物理现实，而数字地图则以结构化、互动的格式展示地理空间信息。MapEval-Visual专注于评估模型对这些结构化地图视图的解释和推理能力，这些地图不仅包含物理特征，还包括符号和导航信息，例如交通标志、路线、地标以及地图界面本身提供的视觉线索。
遥感图像分析通常涉及从原始图像像素中提取物理数据，而MapEval-Visual任务需要模型参与到空间推理和基于地图符号的理解，要求完全不同的计算技能。在此任务中，模型不仅需要理解地图特征之间的空间关系，还需要对数字地图接口提供的上下文进行推理，这些接口包括额外的元素，如缩放级别、图标和导航标记。这一区别使MapEval-Visual在传统的遥感任务之外独树一帜，并为地理空间推理和基于地图的问题回答领域带来了新的挑战。
B. 数据收集细节
B.1. MapQaTor：标注界面
为了创建文本上下文并基于此设计多项选择问题，我们使用了一个名为MapQaTor的定制化网页界面。如图4所示，该界面是数据集开发过程的核心部分，提供了一个直观、用户友好的环境，使复杂任务（如API交互和上下文生成）得以简化。
标注界面的设计目标是降低用户的技术复杂性，使其能够专注于数据集标注的核心任务，例如选择相关位置，提供关于地点间距离、持续时间和方向的信息，以及识别附近的兴趣点。其简化的工作流程通过自动化重复性任务显著提高了数据集创建效率，不仅减少了错误，还大幅加速了标注过程。
MapQaTor使用了五种关键的Google Maps API：文本搜索、地点详情、距离矩阵、路线规划以及附近搜索，基于它们与常见地图任务的相关性以及提供全面位置数据的能力。
MapQaTor会将所有API调用响应缓存，从而为评估创建静态数据库。这确保了在评估MapEval-API时可以返回一致的响应而不是实时查询，从而保持一个可控且静态的评估环境。
数据集生成后，可以轻松导出为JSON格式，使其能够用于进一步的分析和下游任务的评估，例如模型训练和基准测试。
B.2. 通过LLM过滤
为了确保数据集的挑战性和质量，我们评估了多种LLMs，并过滤掉了大多数LLMs可以轻易正确回答的问题样本，认为这些样本“过于简单”，因此从数据集中移除。此外，我们还识别了多数LLMs无法基于给定上下文回答的问题样本。在这些情况下，我们重新检查问题，纠正可能存在的不一致性，以提高问题的清晰度和相关性。
C. 评估细节
C.1. 伪Google Maps环境
为了确保标注与评估的一致性，开发了一个具有以下功能的伪Google Maps环境：
• 缓存：在标注和评估阶段，通过Google Maps地点ID缓存了13,000多个位置的信息，以确保更新过程中的一致性。表8显示了数据库中每个API工具的数据条目数量。
• API模拟：通过代理接口模拟实际的API交互，允许在控制测试的同时保持动态的地图属性（例如旅行时间和地点列表）。
• 关键词-查询映射：用户查询和数据库键之间的差异通过使用通过真实API调用获取的标准化地点ID存储所有数据来处理。
该方法通过控制诸如旅行时间、地点属性和附近位置列表等动态变量，模拟了真实场景的API交互，同时保持静态评估环境，以确保答案的有效性。
C.2. MapEval-文本评估
在此评估设置中，我们为LLM提供了一个预先获取的上下文，其中包含关于特定位置的详细信息，例如开放时间、兴趣点之间的距离以及附近设施。上下文的设计旨在模拟一个真实的场景。
E. 精细化定性错误分析
E.1. MapEval-文本
常识推理：
(i) 考虑一个情境，其中上下文说明：“{地点 A}提供晚餐、午餐、素食餐。”当被问到“{地点 A}是否提供早餐？”时，许多大型语言模型（LLM）回答为：“上下文中没有足够的信息进行回答”，而不是直接说“没有”。而人类会推断，由于早餐未被列出，{地点 A}不提供早餐。
(ii) 另一个挑战出现在规划问题中。即使上下文中包含营业时间的相关信息，大型语言模型在设计计划时可能会忽略约束条件，例如在满足其他条件的同时安排闭店时间段的访问。例如，虽然{地点 A}的营业时间为早上9:00至下午3:00，模型可能会安排在下午5:00访问，表明在此场景中训练的不充分。
空间推理：
(i) 大型语言模型在涉及计算空间关系的查询中表现尤为困难，例如方位、直线距离、最近兴趣点（POIs）或逐步路线规划。例如，在“地点信息”、“附近区域”和“路线规划”的问题中，随机抽取了50个问题，这些问题需要空间计算，发现其准确率比其他问题降低了10%。这一下降突显了即使像Gemini这样的主流模型也难以从地理空间数据中计算直线距离和方向。
(ii) 大型语言模型在领域特定问题中涉及数学计算时也表现困难，甚至在简单计数时表现不佳，特别是当计数规模较大时。例如，对于一个查询“附近有至少4.5分评级的餐厅有多少家？”，大型语言模型通常未能提供准确计数。
时间推理：
大型语言模型在时间推理方面表现不佳，这影响了其在需要时间处理的任务（如行程规划）中的表现。例如，当被问到“我想访问A、B和C。按什么顺序访问最有效率？”时，模型需要计算旅行时间并决定最佳访问顺序，但通常失败。同样，对于“我想访问A一小时。我最晚什么时候能离开家？”的提问，模型需要从A的闭店时间中减去访问时长和往返时间，但在这些简单的时间计算中经常出错。
暂无评论内容