在给大模型做地理空间能力评测时我遇到一个很典型的困惑模型能答对“东京在首尔哪个方向”但你没法确定它是真的做了空间推算还是仅仅在背诵语料里的地理表述。要区分这两种能力仅靠普通的百科问答式 benchmark 完全不够。最近我梳理了 MultiGlobeQA 这类多语言、全球多样化地理空间推理基准的设计思路顺便把一套可以本地运行的评测流程整理了出来。本文会先讲清楚地理空间推理评测为什么难再给出一套完整的可运行评测工作流希望能帮到正在做大模型能力评估、Agent 评测或者地理相关应用的朋友。1. 背景与核心概念1.1 什么是地理空间推理先看一个生活场景。你站在陌生城市的地铁站出口手机地图显示目的地在你当前位置的东南方向 500 米你在心里快速判断“先往右走到路口再左转”这个过程中大脑完成的方位判断、距离比较、路径规划就是空间推理。地理空间推理Geospatial Reasoning就是把这种能力模型化、自动化。在 NLP 领域它通常被定义为模型从地理实体、方位、距离、边界、拓扑关系等非结构化信息中推导出新的空间结论。举几个简单例子方向判断东京位于首尔的哪个方向。边界邻接埃及的南边是哪个国家。距离比较德里和孟买哪个纬度更靠北。路径连通从昆明到仰光是否必须经过某个特定区域。空间排序把一组城市按照从北到南的顺序排列。这些题目看起来只是“地理常识”但背后涉及的信息处理方式并不一样。有些是回忆有些是推导。真正的地理空间推理更关注“推导”这一部分给你若干位置信息你能不能推算出新的空间关系。这也是为什么地理空间推理评测和普通百科问答评测要区分开。普通 QA 考的是“知不知道”地理空间推理考的是“能不能通过已知位置关系推出结论”。1.2 为什么评测地理空间推理如此困难地理空间推理评测的难点首先在于题目类型不统一。同样是“东京在首尔哪个方向”如果模型在过去训练语料里见过大量类似表述它可能直接“记住”了答案并没有真正做过经度纬度的比较。这种情况下准确率再高也不能说明模型具备空间推理能力。其次是语言和地区差异。一个英文语料训练出来的模型处理英文地名时得心应手但同样的空间问题换成印地语、阿拉伯语、东南亚小语种表达效果可能断崖式下降。到底是因为模型“不会推理”还是“听不动题”需要一个能拆解问题的评测维度。最后是评测结果的可解释性。很多 benchmark 最终只给一个总准确率把不同语言、不同区域、不同题型全部混在一起。这就像用一张“全班平均分”去判断一个学生是否偏科信息损失非常严重。MultiGlobeQA 这类基准的出现本质上就是对上述难点的一个回应用多语言、全球多样化的题面把评测结果拆细让研究者知道模型在哪个维度上强、在哪个维度上弱。1.3 MultiGlobeQA 的定位从名字来看MultiGlobeQA 由三部分组成Multi多语言。题目覆盖多种语言而不是只有英文。Globe全球范围。地理样本不局限于欧美而是尽量覆盖各大洲、各个国家和地区。QA问答形式。以问答题作为评测载体便于自动评分。合在一起MultiGlobeQA 的目标可以概括为一个多语言、全球多样化的地理空间推理问答基准。它试图回答的问题是当一个模型面对不同语言、不同区域的地理空间问题时它的推理能力是否稳定可靠。关于该基准的具体数据集规模、语言数量、题型比例建议以官方发布信息为准不建议在二次转述时使用未经确认的具体数字。对开发者来说更值得关注的是它背后体现的评测思路——多语言分组、区域分组、题型分组这三层拆分方式本身就可以复用到自己的评测项目中。2. 评测盲区单语、单区域真的够了吗2.1 英文中心基准的偏差早期很多地理空间 QA 基准主要以英文构建问题与答案也围绕英文地理知识展开。这样做的好处是容易收集数据但问题在于最终测到的是“模型在英文场景下的地理空间推理能力”而不是普适能力。如果你把一个部署在印度、中东或东南亚市场的智能助手拿过来用英文 benchmark 测出来的分数可能虚高因为真实用户不会用标准英文提问他们可能会用本地语言夹杂着本地地名、本地人对方位的描述习惯。单语基准的评测结论很难直接推导到多语言生产环境。2.2 语言如何影响空间认知不同语言表达空间关系的方式存在明显差异。中文习惯说“东边、西边、南边、北边”也经常用“左边、右边”来描述相对位置英语里 north / south / east / west 使用频率很高同时也会用 left / right还有一些语言会使用“上坡 / 下坡”“内陆 / 沿海”这类与地理环境相关的参考系。同一个空间关系在不同语言中可能被编码成完全不同的表达结构。当模型接到一道日文跳转的中文空间题它需要先理解语言再理解地理实体最后还要完成空间推断。任何一个环节失误都会导致最终答错。因此在多语言基准中语言本身就是评测对象的一部分而不只是“翻译后的载体”。2.3 全球多样性的评测价值全球多样化不是为了“看起来覆盖广”而是为了暴露模型的系统性偏差。大模型的训练语料分布天然不均衡英文、中文、部分欧洲语言含量高非洲、中亚、东南亚等地区的语料相对少。这种情况下模型对欧美地理的答案准确率高对其他区域的准确率低几乎是可以预见的。如果评测集只包含欧美地区模型得分高可能只是样本偏差的产物。加入全球多样化的样本之后我们就可以量化这种偏差模型在欧洲样本上准确率 90%在东南亚样本上只有 50%这就说明它的地理空间能力分布不均衡。对于做全球化产品的人来说这个信息比总平均分更有价值。3. 基准测试通常考察哪些能力3.1 六类空间推理任务MultiGlobeQA 这类基准在设计题目时往往会把地理空间推理拆成多个能力维度。以通用评测经验来看至少包含以下六类能力维度问题形式示例方向判断判断两个地物的相对方位东京在首尔的哪个方向边界邻接判断行政区或国家是否接壤埃及的南方邻国是哪个距离比较比较两个地物的距离或纬度新德里和孟买哪个更靠北路径连通判断从一地到另一地的可达路径从 X 到 Y 是否必须经过 Z空间排序按经度、纬度、面积等排序将以下城市按纬度从北到南排列。坐标推理根据给定坐标推算方位或距离给定两点坐标判断第三点的方位。不同能力维度的难度差异很大。坐标推理最依赖计算路径连通最依赖拓扑理解距离比较则需要同时调动地理知识和数量比较能力。一个合理的评测基准通常会按这些维度分别统计准确率方便定位模型的薄弱环节。3.2 多语言样组与评测边界多语言样组的设计难点在于“公平”。同样是考“方向判断”中文题和英文题难易度如果不同最后比较中文准确率和英文准确率就没有意义。因此研究者通常要保证同一道逻辑题在翻译成不同语言后知识难度、选项设置尽量一致。从工程实践角度看我们在自己搭建评测集时可以用“翻译 回译”的方式检查题面是否偏移先把中文题翻译成英文再把英文直译回中文如果意思基本没变说明题面语言一致性较好。反过来如果回译后和原题差异很大就说明翻译过程中可能引入了额外歧义。3.3 推理与记忆的分离这是 MultiGlobeQA 这类评测最值得学习的一点尽量把“记忆”和“推理”分开。如果一道题是“埃及的首都是什么”模型答对只能说明它记住了埃及首都如果一道题是“已知 A 点在北纬 30 度、东经 90 度B 点在北纬 35 度、东经 80 度请你告诉我 B 在 A 的哪个方向”模型能答对说明它确实做了坐标比较与方位推理。在实际样本设计上可以给每条样本增加一个字段比如requires_coordinates: true或reasoning_type: pure_reasoning方便在结果分析时把“知识型题目”和“推理型题目”分开统计。我自己在做评测时经常发现模型在纯记忆题上得分高、在推理题上得分低这种差异单纯看总准确率完全发现不了。4. 环境准备4.1 运行环境说明要进行多语言地理空间推理评测我们需要准备一个可运行的脚本环境。推荐配置如下操作系统不限Windows / macOS / Linux 均可。Python 版本3.10 及以上。Python 依赖openai库用于调用 OpenAI 兼容接口。模型服务任意支持 OpenAI 兼容 Chat Completion API 的模型包括云端 API 和本地 vLLM 部署的模型。pip install openai如果你本地部署了 vLLM可以用下面的命令启动一个 OpenAI 兼容服务python -m vllm.entrypoints.openai.api_server \ --model Qwen/Qwen2.5-7B-Instruct \ --served-model-name qwen2.5-7b-instruct \ --port 8000启动后本地服务会监听http://localhost:8000/v1评测脚本只需把api_base指向该地址即可。不同版本的openai库在初始化参数上略有差异新版推荐使用OpenAI(base_url..., api_key...)这种写法老版本如果报错可以检查库版本并升级到最新。4.2 模型接入方式评测脚本不限定具体模型只要该模型提供 OpenAI 兼容的 Chat Completion 接口就能直接接入。云端模型可以直接使用 API Key本地模型通常可以忽略 Key 校验填EMPTY或者其他任意字符串即可。需要特别注意的是不同模型的指令遵循能力不同同一个 prompt 在强模型上的输出是单字母在弱模型上可能是一大段解释。后面代码里提供了一个答案解析函数可以兼容“答案B”这类带说明的输出格式但依然建议在评测前先做一轮小样本试跑确认输出格式符合预期。5. 从零搭建一个多语言地理空间推理评测流程下面这套评测流程是通用的任何类似 MultiGlobeQA 的 QA 基准都可以复用。我会从数据格式、评测脚本、运行命令、结果聚合四个步骤依次展开。5.1 数据集格式设计为了方便扩展评测数据使用 JSONL 格式每一行是一条完整的题目。字段设计如下language题目语言例如zh、en、hi。region题目对应的地理区域例如East Asia、Africa、South Asia。spatial_type空间推理类型例如direction、border、distance、coordinates。question题目文本。options选项列表。answer正确答案字母。示例文件geospatial_sample.jsonl{language: zh, region: East Asia, spatial_type: direction, question: 日本东京位于韩国首尔的哪个方向, options: [东北, 东南, 西南, 西北], answer: B} {language: en, region: Africa, spatial_type: border, question: Which country lies directly south of Egypt?, options: [Sudan, Libya, Chad, Saudi Arabia], answer: A} {language: hi, region: South Asia, spatial_type: distance, question: Which city is farther north, New Delhi or Mumbai?, options: [New Delhi, Mumbai, They are at the same latitude, Impossible to determine], answer: A} {language: en, region: Global, spatial_type: coordinates, question: Point A is at (35.7N, 139.7E), point B is at (37.5N, 127.0E). From B to A, which direction is correct?, options: [northeast, southeast, southwest, northwest], answer: B, requires_coordinates: true}这里需要说明以上样例只是为了演示数据格式不是 MultiGlobeQA 官方题目。在实际使用时你可以按照同样结构准备自己的评测样本也可以从官方基准中抽取一份子集。5.2 评测脚本核心实现创建evaluate_geospatial_qa.py完整代码如下# 文件路径evaluate_geospatial_qa.py import argparse import json import re from collections import defaultdict from openai import OpenAI SYSTEM_PROMPT ( 你是一个严谨的地理空间推理助手。 请阅读问题与选项选择正确的答案。 只输出选项字母A、B、C 或 D不要输出多余解释。 ) def load_items(data_path): items [] with open(data_path, encodingutf-8) as f: for line in f: line line.strip() if line: items.append(json.loads(line)) return items def build_prompt(item): parts [item[question], ] for idx, opt in enumerate(item[options]): letter chr(ord(A) idx) parts.append(f{letter}. {opt}) parts.append() parts.append(答案) return \n.join(parts) def extract_answer(response_text): text response_text.strip().upper() # 优先匹配独立的选项字母 m re.search(r\b([A-D])\b, text) if m: return m.group(1) # 兼容中文场景答案B m re.search(r答案[:]\s*([A-D]), text) if m: return m.group(1) return None def run_eval(client, items, model_name, temperature0): predictions [] for idx, item in enumerate(items): messages [ {role: system, content: SYSTEM_PROMPT}, {role: user, content: build_prompt(item)}, ] response client.chat.completions.create( modelmodel_name, messagesmessages, temperaturetemperature, ) pred extract_answer(response.choices[0].message.content or ) predictions.append(pred) print(f进度 [{idx 1}/{len(items)}] gold{item[answer]} pred{pred}) return predictions def aggregate(items, predictions, group_key): grouped defaultdict(lambda: [0, 0]) for item, pred in zip(items, predictions): g item.get(group_key, unknown) grouped[g][0] 1 if pred item[answer]: grouped[g][1] 1 result {} for g, (total, correct) in sorted(grouped.items()): result[g] { total: total, correct: correct, acc: round(correct / total, 4) if total else 0.0, } return result if __name__ __main__: parser argparse.ArgumentParser(descriptionGeospatial QA evaluator) parser.add_argument(--data, requiredTrue, helpJSONL 评测文件路径) parser.add_argument(--model, requiredTrue, help模型名称) parser.add_argument(--api_base, defaultNone, helpOpenAI 兼容 API 地址) parser.add_argument(--api_key, defaultNone, helpAPI Key) parser.add_argument( --group_key, defaultlanguage, help聚合维度language / region / spatial_type, ) args parser.parse_args() kwargs {} if args.api_base: kwargs[base_url] args.api_base if args.api_key: kwargs[api_key] args.api_key client OpenAI(**kwargs) items load_items(args.data) print(fLoaded {len(items)} items) preds run_eval(client, items, args.model) result aggregate(items, preds, args.group_key) print(json.dumps(result, ensure_asciiFalse, indent2))脚本逻辑分四层每一层都很直观load_items按行读取 JSONL 文件把每一条题目转成字典。build_prompt把题目和选项拼成一段适合模型阅读的文本。run_eval循环调用模型接口并把模型的输出解析成选项字母。aggregate按language、region或spatial_type分组统计正确率。这里的关键设计是extract_answer函数。它先找独立字母 A 到 D再兼容“答案B”这种中文输出格式能够减少因为模型多输出了几个字而导致的解析失败。5.3 运行与验证使用云端 OpenAI 兼容接口时运行命令如下python evaluate_geospatial_qa.py \ --data geospatial_sample.jsonl \ --model gpt-4o-mini \ --api_key $OPENAI_API_KEY \ --group_key language如果使用本地 vLLM运行命令如下python evaluate_geospatial_qa.py \ --data geospatial_sample.jsonl \ --model qwen2.5-7b-instruct \ --api_base http://localhost:8000/v1 \ --api_key EMPTY \ --group_key region预期会在控制台看到逐条进度信息最后输出一个 JSON 格式的分组准确率。例如Loaded 4 items 进度 [1/4] goldB predB 进度 [2/4] goldA predA 进度 [3/4] goldA predA 进度 [4/4] goldB predB { Africa: { total: 1, correct: 1, acc: 1.0 }, East Asia: { total: 1, correct: 1, acc: 1.0 }, Global: { total: 1, correct: 1, acc: 1.0 }, South Asia: { total: 1, correct: 1, acc: 1.0 } }5.4 分组聚合与结果解读脚本支持三个常用聚合维度--group_key language看多语言能力判断模型在中文、英文、印地语等不同语言上的表现差异。--group_key region看区域覆盖能力判断模型是否在欧美以外地区出现准确率滑坡。--group_key spatial_type看推理能力结构判断模型具体是方向判断弱还是坐标推理弱。实际操作时可以跑三次命令分别导出三份 JSON。然后把这些 JSON 汇总到分析表里就能比较全面地了解模型的地理空间推理画像。6. 常见问题与排查思路在运行这类多语言地理空间评测时我整理了一份常见问题清单基本覆盖了多数踩坑场景。问题现象常见原因解决思路模型输出一段解释而不是字母指令遵循能力较弱或 prompt 约束不足在 prompt 中加入 few-shot 示例extract_answer 兼容“答案X”格式模型始终选同一个选项位置偏见或对题目理解不足解析时只取字母必要时对选项做随机排列多次测量取均值不同语言准确率差异极大模型多语能力不均或样本难度不一致按语言维度拆开报告检查翻译后题目是否存在语义偏移同一批题目结果忽高忽低采样温度过高或并发请求乱序将 temperature 设置为 0固定请求顺序多次运行取均值模型不认识本地地名训练语料覆盖不足在 prompt 中补充地名词表优先评测模型对常见地名的能力题目被模型直接“背出答案”评测集与训练集存在数据泄露使用动态生成题目或未公开子集记录评测集版本和日期API 调用报认证错误本地 vLLM 不校验 Key 但客户端要求传入设置任意非空api_key例如EMPTY最需要警惕的是“数据泄露”问题。公开的 benchmark 题目可能在训练语料里出现过几轮评测之后模型分数会越调越高但这个提升可能来自记忆而不是推理能力提升。一个折中方案是把官方拆分子集和自建动态样本结合在报告中注明哪些题目来自公开集、哪些题目来自内部集。7. 最佳实践与工程建议7.1 Prompt 一致性与输出解析不同语言、不同题型应尽量使用同一套 prompt 模板。我在实际评测中经常看到一种做法先写英文 prompt再翻译成中文、日文、阿拉伯文各一份。这样虽然提升了模型的语言理解友好度但也带来了变量导致最终无法确认差异来自模型推理能力还是 prompt 语言。建议默认所有语言都用同一套系统提示词如果要单独验证多语言 prompt 的影响再单独跑一组实验对比。7.2 关注结构化的分组结果只报一个总准确率对地理空间推理评测来说信息量太少。至少要同时报告按语言分组准确率。按区域分组准确率。按空间推理类型分组准确率。三张表合在一起才能形成完整的模型能力画像。如果发现某个特定区域准确率明显偏低可以先检查样本难度、地名翻译、数据量这三项是否均衡再判断模型是否存在区域偏差。7.3 区分记忆型与推理型题目在数据字段中增加requires_coordinates或reasoning_type这样的标记然后在结果分析时把“纯记忆题”和“纯推理题”分开统计。这样一个模型如果总准确率 80%但推理题只有 50%说明它的真实空间推理能力远没有表面数据那么乐观。下面是一个坐标推理题样例可以直接加入评测集{language: en, region: Global, spatial_type: coordinates, question: Point A is at (10N, 100E), point B is at (20N, 110E). Which direction from A would you travel to reach B?, options: [northwest, northeast, southwest, southeast], answer: B}A 点纬度 10N经度 100EB 点纬度 20N经度 110E。B 在 A 的东北方向答案 B也是“东北”对应的英文东北方向。这类题不依赖训练语料中是否出现过这两个点而是考察坐标比较能力适合用来衡量模型的空间运算能力。7.4 防污染与版本管理在工程化评测流程中建议给评测集增加版本号记录每个版本的题目哈希。每次评测前把当前模型名称、评测集版本、prompt 版本、运行时间一起写入结果文件。这样即使后续发现某个模型在某月份的分数突增也能回溯到是哪一批数据造成的。7.5 低资源语言人工抽检多语言评测中低资源语言的自动解析错误率会高于英文和中文。建议对解析失败样本尤其是准确率异常低的语言分组做一次人工抽检判断到底是模型真的不会还是答案解析环节误判。这一步虽然耗时但对结论可靠性至关重要。8. 结语关于多语言地理空间推理评测我的整体感受是真正的难点不在“出题”而在“拆解”。把评测结果按语言、区域、推理类型层层切开才能看清模型能力的真实边界。MultiGlobeQA 这个方向提供了一个很有价值的评测视角值得每一位关注大模型空间能力的人认真研究。如果你也想验证自己的模型在地理空间推理上的表现我的建议很直接先不要急着找完整的大规模评测集而是准备一小份包含多语言、多区域、多种推理类型的 JSONL 样本用本文的脚本跑通流程再逐步扩展到更大规模的数据集。等你能清晰回答“模型在中文方向题上表现如何、在英文坐标题上表现如何”时你对模型能力的理解会比单纯知道一个准确率数字要准确得多。