大语言模型的地理空间推理能力不能只靠英文问答题来验证。MultiGlobeQA 是一个面向多语言、全球地理多样性的地理空间推理基准核心设计目标是评估模型在理解不同语言题面、不同地区地理关系和空间方位时的真实水平。这类基准的出现是因为地理空间推理与其他常识推理不同它既依赖地名知识也依赖方向、距离、邻接、行政区划等空间关系还依赖训练语料对相关语言和地区的覆盖程度。本文从设计思路、数据结构、评测脚本、结果分析和排查路径几个层面展开适合自然语言处理研究者、大模型评测工程师以及需要在地图、搜索、客服等业务场景中验证地理能力的研发人员参考。要实际使用一个多语言地理空间推理基准并不是把测试题发给模型、统计正确率这么简单。题面字段、语言编码、区域归属、答案规范化、指标口径、错误分析方式都会影响最终结论。真正有价值的做法是先把基准的数据组织方式理解清楚再搭建一条可复现的评测流水线最后用拆解后的分数定位模型在哪些语言、哪些区域、哪些题型上存在短板。1. 为什么地理空间推理需要专门的多语言基准1.1 地理空间推理到底是什么地理空间推理是指一个人或模型根据地名、位置、地理实体之间的空间关系完成推断的能力。它与“记忆地理事实”不同。记住“埃及的首都是开罗”更多是知识记忆而判断“苏丹位于埃及以南”需要知道两个国家的大致位置再结合方向关系得出结论。前者属于百科问答后者才更接近推理。常见的地理空间推理任务包括方向判断某个城市在另一个城市的北面、南面、东面还是西面。邻国关系哪些国家和指定国家接壤哪些不接壤。相对距离三个城市中哪两个距离更近。行政区划某个城市属于哪一个州、省、邦或大区。地标位置某个著名地标位于哪个国家或城市。气候与地理带某地区属于热带、温带还是寒带或位于哪个自然地理区。这些任务有一个共同点只靠文本记忆不够。模型必须把地名映射到空间位置并完成多实体之间的比较或方位换算。在自然语言处理中这类能力往往不在基础预训练任务中显式出现因此需要通过专门的 benchmark 来评测。MultiGlobeQA 正是围绕这些任务设计的。它不希望模型只会回答“某国首都在哪里”这类高频填空题而是希望评测模型能否在真实、多样的地理场景中完成推理。也就是说它关注的是地理空间推理能力而不是单纯的事实检索能力。1.2 已有评测为什么容易忽略多语言和全球多样性大多数常识问答或地理问答基准默认使用英文题面而且题目中的地名、行政单位和地理事件多集中在欧美或高资源地区。这种设计有两个明显问题。第一英文题面本身会干扰地理能力评估。一个模型如果英语能力强即使对目标区域地理知识有限也可能通过上下文线索或选项名称猜测答案。反过来一个模型如果地理知识充分但多语言能力较弱在非英语题面上也可能出现错误。如果不把语言变量单独控制就分不清是地理推理能力不足还是语言理解能力不足。第二训练语料中的地理知识分布极不均匀。互联网上关于北京、纽约、伦敦、巴黎的文本数量远大于关于一些低资源语言所在地区的文本数量。模型对地名的熟悉程度往往等同于该地名在训练语料中出现的频率。这样一来用欧美中心和英文题面的基准测试会高估模型整体的地理空间推理能力也会掩盖模型对某些地区的系统性盲区。MultiGlobeQA 想解决的是评估口径问题用多语言题面覆盖全球不同区域让模型在地理实体的本地名称、本地语言表达和不同区域的空间逻辑上进行推理。这样得到的准确率才更接近模型在真实多语言用户场景中的表现。1.3 MultiGlobeQA 的评测目标MultiGlobeQA 的评测目标可以拆成三层。第一层是“多语言”。题面不是把英文题翻成几十种语言那么机械而是要按目标语言的使用习惯重新编写。因为同一个地理实体的称呼可能有本地名、官方名、历史名和历史遗留名直接翻译容易引入歧义。比如一些非洲国家在英语和法语中名称不同一些城市在不同语言里拼写不同。多语言题面应尽量贴近该语言使用者的真实表达。第二层是“全球多样性”。题目样本需要覆盖非洲、亚洲、欧洲、北美洲、南美洲、大洋洲等多个区域并保证各区域样本不至于严重失衡。只有区域分布足够多元才能发现模型是真的具备通用地理推理能力还是只熟悉高资源地区。第三层是“可归因”。评测结果必须能够按语言、区域、题型、难度等维度拆分。否则一个总体准确率无法告诉我们模型为什么失败也无法指导后续通过训练数据还是推理策略来改进。所以 MultiGlobeQA 不只是一个题库更是一套评测框架。使用者的目标不是追求单一的分数而是要回答三个问题模型在哪些语言上表现差模型在哪些地理区域上表现差模型在哪些推理类型上系统性失误2. 理解 MultiGlobeQA 的题面结构和数据格式2.1 一道题包含哪些字段要搭建评测流程首先要理解 benchmark 的数据格式。虽然 MultiGlobeQA 的具体官方文件可能在不同版本中调整但多语言地理推理题通常会包含下面这些字段。这里给出的是一种常见设计便于说明评测脚本如何处理数据。字段类型说明question_idstring题目唯一编号建议同时编码语言、区域和序号languagestringISO 639-1 语言代码例如 en、zh、es、swregionstring地理区域代码例如 af、as、eu、na、sa、occategorystring题型例如 direction、adjacency、distance、admin、landmarkdifficultystring难度标签例如 easy、medium、hardquestionstring题面文本使用指定语言表达choicesarray选项列表一般 4 到 6 个answerstring正确选项字母例如 Acontextstring可选上下文例如地图片段或地理背景source_notestring可选说明数据来源或编写方式便于审计一个 JSON Lines 文件中的最小示例可以是{ question_id: MQA-EN-AF-0123, language: en, region: af, category: direction, difficulty: easy, question: Which country is directly south of Egypt?, choices: [Sudan, Libya, Israel, Chad], answer: A }question_id的设计不能随意。建议包含语言、区域和类别例如MQA-ZH-AS-0042这样在结果分析时可以直接从编号中提取信息也可以避免把不同来源的题目混在一起。choices中的选项顺序也需要稳定。如果一个基准在多次评测中随机打乱选项顺序那么答案字段也要同步更新。固定顺序有助于做可复现实验也便于人工复核。2.2 多语言题面的设计思路多语言题面不是简单的翻译流水线。同一个地理题目在不同语言中可能有不同的表达习惯。以“哪个国家位于埃及以南”为例{ question_id: MQA-ZH-AF-0124, language: zh, region: af, category: direction, question: 以下哪个国家位于埃及以南, choices: [苏丹, 利比亚, 以色列, 乍得], answer: A }{ question_id: MQA-ES-AF-0125, language: es, region: af, category: direction, question: ¿Qué país está al sur de Egipto?, choices: [Sudán, Libia, Israel, Chad], answer: A }这里的关键是地名也要采用目标语言中通用的写法而不是一律使用英文地名。例如中文题面中的“苏丹”“乍得”与英文拼写不同。如果评测脚本只按英文地名做实体匹配就会遇到问题。使用多语言题面时prompt 的指令语言也最好与题面语言对齐。不能在中文题面后加英语指令。一个稳妥做法是在数据集中增加一个instruction_language字段或者按language字段从映射表中读取对应的“只输出选项字母”指令。这样能减少指令语言与题面语言不一致造成的干扰。2.3 全球多样性如何体现在答案分布中全球多样性不能只靠“题目里包含多个国家”来体现。它体现在样本的区域分布、语言分布和题型分布三个层面。区域分布层面题目应该覆盖非洲、亚洲、欧洲、北美洲、南美洲和大洋洲。北极和南极区域可以作为专项题集补充但数量不宜过多。每个区域的题量要尽量均衡否则总体准确率会被高频区域主导。语言分布层面高资源语言和低资源语言需要混合。英文、中文、西班牙语、法语等可以占一部分同时也要纳入非洲、南亚、东南亚等区域使用的语言。不能因为某种语言用户少就不加题因为“全球多样性”的本意正是要测试模型对少资源地理区域的覆盖能力。题型分布层面一个合格的地理空间推理基准不可能只考方向题。建议至少包含题型能力点direction判断方位关系adjacency判断邻国或相邻行政区域distance比较相对距离administrative判断城市与行政区划的归属关系landmark判断地标所在位置natural region判断气候带、植被区、地形区答案分布也需要校准。不能出现某一题中 A 选项永远正确或者某个区域题目的答案集中在同一个字母。这可以通过构建脚本或人工抽检来控制。在复杂地理题中可能存在“边界模糊”的情况。例如“哪个国家位于埃及以南”中乍得也在埃及西南方向可能造成争议。基准设计者在制作题目时应通过“directly south”或“最合适”这样的限定词消除歧义。注意如果读者拿到的 MultiGlobeQA 数据版本字段有所不同应以实际数据文件为准。上面的字段设计用于建立一个可运行的评测逻辑而不是替代官方规范。3. 搭建一个可复现的 MultiGlobeQA 评测流程3.1 环境准备与依赖评测脚本的依赖不多。推荐 Python 3.10 或更高版本使用一个独立的虚拟环境。python -m venv .venv source .venv/bin/activate pip install openai1.0 pandas这里使用openaiPython 包是因为很多自部署模型服务、云端模型 API 都提供了 OpenAI 兼容接口。这样评测脚本可以做到模型无关只要服务地址和模型名可配就能评测不同模型。不强制依赖pandas但如果要做按语言、区域、题型的聚合统计pandas会方便很多。如果希望保持轻量也可以用标准库collections.defaultdict替代。依赖清单参考软件或库作用建议Python运行评测脚本 3.10openai调用 OpenAI 兼容接口 1.0pandas结果聚合与透视表 2.0json/jsonlines读写数据Python 标准库3.2 数据加载与标准化数据文件使用 JSON Lines 格式读取一行一条题目。加载之后先做 schema 校验避免后续因为字段缺失或选项错误导致评测中断。import json from typing import List, Dict def load_instances(path: str) - List[Dict]: instances [] with open(path, r, encodingutf-8) as f: for line in f: line line.strip() if not line: continue instances.append(json.loads(line)) return instances def validate_instance(inst: Dict) - bool: required_fields [ question_id, language, region, category, question, choices, answer, ] if not all(field in inst for field in required_fields): return False if len(inst[choices]) 2: return False if inst[answer] not in ABCDEFGHIJ: return False return True这里的选择题选项数量限制在 2 到 10 个因此答案字母范围是A-J。如果题目设计固定为 4 个选项可以把校验范围改成ABCD。数据加载后建议做一次批量校验def filter_valid_instances(instances: List[Dict]) - List[Dict]: valid [] for inst in instances: if validate_instance(inst): valid.append(inst) else: print(fInvalid instance: {inst.get(question_id, unknown)}) return valid这样做的目的是把“数据问题”和“模型问题”分开。如果某道题字段不全模型答错了也不是模型能力问题而是评测数据问题。3.3 调用大模型生成答案模型调用层建议定义一个抽象类或通用类。这里给出一个基于 OpenAI 兼容接口的实现方便替换成自部署模型。from openai import OpenAI class OpenAICompatibleModel: def __init__(self, model_name: str, api_base: str, api_key: str): self.client OpenAI(base_urlapi_base, api_keyapi_key) self.model_name model_name def predict(self, prompt: str) - str: resp self.client.chat.completions.create( modelself.model_name, messages[ {role: user, content: prompt} ], temperature0, max_tokens32, ) return resp.choices[0].message.content.strip()temperature0是为了让评测结果尽量稳定。max_tokens32是因为选择题只需要一个字母或很短文本不需要让模型生成大段解释。如果模型支持输出 logits 或 JSON 结构也可以通过 constrained decoding 限制输出只能是选项字母但这里为了通用性先不做。构造 prompt 时需要把题面和选项拼接起来。指令语言要尽量与题面语言一致。给出一个简单映射INSTRUCTIONS { en: Output only the letter of the correct answer., zh: 请只输出正确选项的字母。, es: Responde solo con la letra de la opción correcta., } def build_prompt(instance: Dict) - str: labels ABCDEFGHIJ lines [instance[question]] for idx, choice in enumerate(instance[choices]): lines.append(f{labels[idx]}. {choice}) lang instance.get(language, en) instruction INSTRUCTIONS.get(lang, INSTRUCTIONS[en]) lines.append(instruction) return \n.join(lines)language字段如果缺失默认使用英语指令。实际项目中这个映射表应该覆盖数据集中的所有语言。3.4 评测指标与结果输出评测主循环需要记录每一次模型输出、正确答案、是否匹配以及题目的语言、区域、题型等元信息。这样后续分析才不会丢失原因。import re def normalize_answer(text: str) - str: text text.strip().upper() m re.search(r\b([A-J])\b, text) if m: return m.group(1) return text def run_evaluation(instances, model, max_samplesNone): results [] if max_samples is not None: instances instances[:max_samples] for inst in instances: prompt build_prompt(inst) raw_pred model.predict(prompt) pred normalize_answer(raw_pred) gold inst[answer].strip().upper() results.append({ question_id: inst[question_id], language: inst.get(language, ), region: inst.get(region, ), category: inst.get(category, ), difficulty: inst.get(difficulty, ), gold: gold, prediction: pred, raw_prediction: raw_pred, correct: pred gold, }) return results结果计算可以写成一个聚合函数。这里使用标准库实现按字段拆分from collections import defaultdict def compute_accuracy(results): if not results: return 0.0 return sum(r[correct] for r in results) / len(results) def accuracy_by_field(results, field): groups defaultdict(lambda: {correct: 0, total: 0}) for r in results: key r.get(field, unknown) groups[key][total] 1 groups[key][correct] int(r[correct]) report {} for key, stat in groups.items(): report[key] { accuracy: stat[correct] / stat[total], correct: stat[correct], total: stat[total], } return report输出结果时推荐同时保存两份文件一份是原始结果包含每个请求的完整输出一份是聚合报告方便直接查看。import csv def save_results(results, output_path): with open(output_path, w, encodingutf-8, newline) as f: writer csv.DictWriter(f, fieldnames[ question_id, language, region, category, difficulty, gold, prediction, raw_prediction, correct ]) writer.writeheader() writer.writerows(results) def print_report(results): print(fOverall accuracy: {compute_accuracy(results):.4f}) print(By language:) for lang, stat in accuracy_by_field(results, language).items(): print(f {lang}: {stat[accuracy]:.4f} ({stat[correct]}/{stat[total]})) print(By region:) for region, stat in accuracy_by_field(results, region).items(): print(f {region}: {stat[accuracy]:.4f} ({stat[correct]}/{stat[total]}))运行评测的入口可以写成一个命令行脚本import argparse def main(): parser argparse.ArgumentParser() parser.add_argument(--data, requiredTrue, helpPath to JSONL data file) parser.add_argument(--model, requiredTrue, helpModel name) parser.add_argument(--api_base, requiredTrue, helpAPI base URL) parser.add_argument(--api_key, defaultEMPTY, helpAPI key) parser.add_argument(--max_samples, typeint, defaultNone) parser.add_argument(--output, defaultresults.csv) args parser.parse_args() instances load_instances(args.data) instances filter_valid_instances(instances) model OpenAICompatibleModel(args.model, args.api_base, args.api_key) results run_evaluation(instances, model, args.max_samples) save_results(results, args.output) print_report(results) if __name__ __main__: main()命令行执行示例python run_multiglobeqa.py \ --data data/qa.jsonl \ --model llama3.1-8b \ --api_base https://your-endpoint/v1 \ --api_key EMPTY \ --max_samples 200 \ --output results.csv在正式评测时api_key不应写在命令行中建议从环境变量读取。上面的命令行写法是为了快速演示。4. 用数据分析模型在地理空间推理中的薄弱点4.1 按语言维度拆解分数总体准确率只能告诉我们模型大概行不行不能告诉我们在哪里不行。按语言维度拆解是最直接的分析方式。假设评测结果保存在results.csv用 pandas 可以快速得到透视表import pandas as pd df pd.read_csv(results.csv) lang_report df.groupby(language).agg( total(correct, count), correct(correct, sum) ) lang_report[accuracy] lang_report[correct] / lang_report[total]输出表头类似languagetotalcorrectaccuracyen100780.780zh80700.875es70520.743sw50210.420实际数字仅为示意。分析时重点不是看哪种语言分数最高而是要观察“语言覆盖不够导致分数骤降”的模式。如果一个模型在英文上准确率 78%在某种低资源语言上只有 42%那么它的地理知识很可能来自英文语料而不是真正的空间推理能力。4.2 按区域维度拆解分数按区域拆解可以定位地理覆盖盲区region_report df.groupby(region).agg( total(correct, count), correct(correct, sum) ) region_report[accuracy] region_report[correct] / region_report[total]同样可以按category拆解比较方向题、邻国题、距离题、行政区划题的差异。如果模型在邻国题上表现好但在行政区划题上表现差说明它对“点状地名”和“面状行政层级”的表达理解不够。4.3 错误类型与典型失败模式只看准确率还不够还要看错误样本长什么样。通过原始预测结果可以归纳出几种典型失败模式模型输出了非选项字母或完整句子导致归一化失败。模型选择了与正确答案地理上邻近的选项说明空间定位不够精确。模型无法识别某语言的本地地名导致随机乱猜。模型对行政层级概念混乱混淆国家、省、城市。写一个简单的错误抽样脚本可以快速观察失败原因def sample_errors(results, fieldraw_prediction, n10): errors [r for r in results if not r[correct]] for r in errors[:n]: print(r[question_id], r[language], r[region]) print(Question:, r.get(raw_prediction, )) print(Gold:, r[gold], Pred:, r[prediction]) print(---)注意在这个简化的结果字典中我们保存了raw_prediction。如果只保存了归一化后的prediction就无法判断是格式问题还是知识问题。因此评测脚本中保留原始输出非常重要。注意分析错误时不要只看前几条。建议从不同语言和区域分别抽样否则容易只看到高资源语言的失败模式。5. 常见问题与排查路径5.1 多语言文本编码和文件读写问题现象读取 JSONL 文件时中文、阿拉伯语或斯瓦希里语文本变成乱码或者运行脚本时出现UnicodeEncodeError。原因很多脚本默认使用系统编码在 Windows 控制台上可能无法输出非 ASCII 字符。也可能是文件写入时没有指定encodingutf-8。检查方式python -c import sys; print(sys.stdout.encoding)如果输出不是utf-8运行评测时先设置环境变量export PYTHONIOENCODINGutf-8处理建议所有文件读写都显式传入encodingutf-8不要依赖系统默认编码。保存结果时同样指定 UTF-8。这能避免在本地复现时出现“评测脚本本身把答案搞乱”的情况。5.2 模型输出格式不规范现象模型经常输出“答案是 A”“正确答案是 A”或者一段解释导致归一化后取不到字母。原因模型没有严格遵循 prompt 的“只输出选项字母”指令也可能是max_tokens设置过大让模型觉得应该给出详细回答。处理方式先改进normalize_answer从输出中用正则提取第一个大写字母。更好的方式是限制max_tokens为 8 到 16并尝试在 prompt 中给出一个示例Please output only the letter of the correct answer. Example output: A如果模型支持 logprobs 或 JSON 结构化输出可以进一步限制输出必须匹配A-J中的某一个字母。这是最稳定的方案。5.3 地理答案边界模糊导致空判现象一道题中存在多个从字面上看都正确的选项模型选择了其中一个但数据集给出的标准答案不同于是被判错。原因地理关系天然存在边界模糊。例如“位于埃及以南”在英文中如果写成 “south of Egypt”乍得在西南方向也能被某些人理解为“在南部区域”。这种题如果不加限定词就不适合作为单选题。检查方式把错误样本拿出来查看题目原文和选项判断是否存在歧义。如果存在应修正题目或删除该题而不是怀疑模型能力。处理建议在编写题目时加入“directly south”“最合适”等限定词。在评测报告中如果这类歧义题数量较多应对精度造成的影响单独说明。5.4 API 请求不稳定或限流现象评测跑到一半某个请求返回超时或限流错误。脚本中断后已经跑过的结果丢失。原因评测脚本没有做重试也没有断点续跑。大批量请求云端 API 时限流是常见问题。处理方式在模型调用层加入重试和指数退避。更稳妥的做法是每跑完一道题就把当前记录追加写入 CSV这样中断后可以从已有的question_id集合中恢复。import time def predict_with_retry(model, prompt, retries3, delay2.0): for attempt in range(retries): try: return model.predict(prompt) except Exception as e: print(fRequest failed: {e}; retry {attempt 1}/{retries}) time.sleep(delay * (attempt 1)) raise RuntimeError(Predict failed after retries)这个处理在生产环境评测中尤其重要。学习环境小样本可以忽略但全量评测必须把重试、日志和断点保存加进去。6. 从评测基准走向工程实践最佳实践与扩展方向6.1 复现 MultiGlobeQA 的过程清单使用一个评测基准建议按下面的清单执行。这份清单同时适用于 MultiGlobeQA 和其他类似的多语言地理推理数据集。确认数据集版本和数据格式阅读样例文件弄清必填字段和可选字段。建立独立虚拟环境安装评测依赖。先运行校验脚本统计无效题目的占比。配置模型 API 地址、模型名和密钥。密钥从环境变量读取不能写死在代码中。小样本试跑例如--max_samples 20确认输出文件不是乱码、字段完整。全量评测时开启断点续写、请求重试和日志记录。同时保存归一化预测和原始输出便于后续错误分析。生成总体准确率、语言维度、区域维度、题型维度报告。根据错误样本修正数据歧义或 prompt 设计再复跑对照。小样本试跑是很容易被跳过的一步。直接全量跑容易出现跑完后才发现 prompt 没拼对、答案无法归一化的问题。6.2 学习环境与生产环境的差异学习环境的目标是快速理解评测流程生产环境的目标是稳定复现并支撑模型迭代决策。两者差异明显。维度学习环境生产环境样本量几十道题全量数据集请求重试可有可无必须配置断点续跑不需要强烈建议API 密钥可以写常量环境变量或密钥管理输出记录打印即可保存原始响应和日志指标解释看总体准确率按语言、区域、题型拆解模型采样temperature0temperature0必要时多次采样数据校验简单过滤全量校验并统计质量如果企业需要把地理空间推理能力接入客服、搜索或地图产品建议在生产评测中增加多次采样和人工复核。只跑一次可能因为模型随机性造成误判。6.3 扩展方向MultiGlobeQA 这类基准解决的是纯文本地理空间推理问题。实际业务中还可以从三个方向扩展。第一加入视觉输入。许多地理问题需要看地图、街区图、卫星图才能回答。未来评测可以引入“文本题面 地图图像”的多模态题型评估视觉语言模型在空间布局理解上的能力。第二加入多跳和时空推理。当前的方向、邻国题大多是一跳关系。实际场景中用户可能问“从 A 出发向南经过 B再向东到 C 有多少公里”这类多步问题。这类问题需要模型组合多个空间关系难度更高。第三加入更细粒度的本地化表达。同一个地点的地名可能在不同语言中差异很大例如许多东南亚和非洲城市的拼音写法与英文写法不同。评测基准可以针对这些差异设置“本地名称识别”和“跨语言地名对齐”专项题。从工程角度来看引入 MultiGlobeQA 最重要的一点是让“地理空间推理能力”不再是模糊感觉而是一组可复现、可拆解、可对比的指标。模型升级后是否真的有进步不能只看几条示例而要回到统一数据、统一脚本、统一指标上做对照。判断一个模型的地理空间能力也不应该只看总体准确率。多语言、全球多样性的基准真正价值在于帮助开发者把能力缺口定位到语言、区域和题型维度。最值得实践的一点是从数据格式、评测逻辑到错误分析都保持可复现这样模型迭代或多语言扩展后才能看到可比较的变化。 MultiGlobeQA：多语言地理空间推理基准，量化大模型空间智能
大语言模型的地理空间推理能力不能只靠英文问答题来验证。MultiGlobeQA 是一个面向多语言、全球地理多样性的地理空间推理基准核心设计目标是评估模型在理解不同语言题面、不同地区地理关系和空间方位时的真实水平。这类基准的出现是因为地理空间推理与其他常识推理不同它既依赖地名知识也依赖方向、距离、邻接、行政区划等空间关系还依赖训练语料对相关语言和地区的覆盖程度。本文从设计思路、数据结构、评测脚本、结果分析和排查路径几个层面展开适合自然语言处理研究者、大模型评测工程师以及需要在地图、搜索、客服等业务场景中验证地理能力的研发人员参考。要实际使用一个多语言地理空间推理基准并不是把测试题发给模型、统计正确率这么简单。题面字段、语言编码、区域归属、答案规范化、指标口径、错误分析方式都会影响最终结论。真正有价值的做法是先把基准的数据组织方式理解清楚再搭建一条可复现的评测流水线最后用拆解后的分数定位模型在哪些语言、哪些区域、哪些题型上存在短板。1. 为什么地理空间推理需要专门的多语言基准1.1 地理空间推理到底是什么地理空间推理是指一个人或模型根据地名、位置、地理实体之间的空间关系完成推断的能力。它与“记忆地理事实”不同。记住“埃及的首都是开罗”更多是知识记忆而判断“苏丹位于埃及以南”需要知道两个国家的大致位置再结合方向关系得出结论。前者属于百科问答后者才更接近推理。常见的地理空间推理任务包括方向判断某个城市在另一个城市的北面、南面、东面还是西面。邻国关系哪些国家和指定国家接壤哪些不接壤。相对距离三个城市中哪两个距离更近。行政区划某个城市属于哪一个州、省、邦或大区。地标位置某个著名地标位于哪个国家或城市。气候与地理带某地区属于热带、温带还是寒带或位于哪个自然地理区。这些任务有一个共同点只靠文本记忆不够。模型必须把地名映射到空间位置并完成多实体之间的比较或方位换算。在自然语言处理中这类能力往往不在基础预训练任务中显式出现因此需要通过专门的 benchmark 来评测。MultiGlobeQA 正是围绕这些任务设计的。它不希望模型只会回答“某国首都在哪里”这类高频填空题而是希望评测模型能否在真实、多样的地理场景中完成推理。也就是说它关注的是地理空间推理能力而不是单纯的事实检索能力。1.2 已有评测为什么容易忽略多语言和全球多样性大多数常识问答或地理问答基准默认使用英文题面而且题目中的地名、行政单位和地理事件多集中在欧美或高资源地区。这种设计有两个明显问题。第一英文题面本身会干扰地理能力评估。一个模型如果英语能力强即使对目标区域地理知识有限也可能通过上下文线索或选项名称猜测答案。反过来一个模型如果地理知识充分但多语言能力较弱在非英语题面上也可能出现错误。如果不把语言变量单独控制就分不清是地理推理能力不足还是语言理解能力不足。第二训练语料中的地理知识分布极不均匀。互联网上关于北京、纽约、伦敦、巴黎的文本数量远大于关于一些低资源语言所在地区的文本数量。模型对地名的熟悉程度往往等同于该地名在训练语料中出现的频率。这样一来用欧美中心和英文题面的基准测试会高估模型整体的地理空间推理能力也会掩盖模型对某些地区的系统性盲区。MultiGlobeQA 想解决的是评估口径问题用多语言题面覆盖全球不同区域让模型在地理实体的本地名称、本地语言表达和不同区域的空间逻辑上进行推理。这样得到的准确率才更接近模型在真实多语言用户场景中的表现。1.3 MultiGlobeQA 的评测目标MultiGlobeQA 的评测目标可以拆成三层。第一层是“多语言”。题面不是把英文题翻成几十种语言那么机械而是要按目标语言的使用习惯重新编写。因为同一个地理实体的称呼可能有本地名、官方名、历史名和历史遗留名直接翻译容易引入歧义。比如一些非洲国家在英语和法语中名称不同一些城市在不同语言里拼写不同。多语言题面应尽量贴近该语言使用者的真实表达。第二层是“全球多样性”。题目样本需要覆盖非洲、亚洲、欧洲、北美洲、南美洲、大洋洲等多个区域并保证各区域样本不至于严重失衡。只有区域分布足够多元才能发现模型是真的具备通用地理推理能力还是只熟悉高资源地区。第三层是“可归因”。评测结果必须能够按语言、区域、题型、难度等维度拆分。否则一个总体准确率无法告诉我们模型为什么失败也无法指导后续通过训练数据还是推理策略来改进。所以 MultiGlobeQA 不只是一个题库更是一套评测框架。使用者的目标不是追求单一的分数而是要回答三个问题模型在哪些语言上表现差模型在哪些地理区域上表现差模型在哪些推理类型上系统性失误2. 理解 MultiGlobeQA 的题面结构和数据格式2.1 一道题包含哪些字段要搭建评测流程首先要理解 benchmark 的数据格式。虽然 MultiGlobeQA 的具体官方文件可能在不同版本中调整但多语言地理推理题通常会包含下面这些字段。这里给出的是一种常见设计便于说明评测脚本如何处理数据。字段类型说明question_idstring题目唯一编号建议同时编码语言、区域和序号languagestringISO 639-1 语言代码例如 en、zh、es、swregionstring地理区域代码例如 af、as、eu、na、sa、occategorystring题型例如 direction、adjacency、distance、admin、landmarkdifficultystring难度标签例如 easy、medium、hardquestionstring题面文本使用指定语言表达choicesarray选项列表一般 4 到 6 个answerstring正确选项字母例如 Acontextstring可选上下文例如地图片段或地理背景source_notestring可选说明数据来源或编写方式便于审计一个 JSON Lines 文件中的最小示例可以是{ question_id: MQA-EN-AF-0123, language: en, region: af, category: direction, difficulty: easy, question: Which country is directly south of Egypt?, choices: [Sudan, Libya, Israel, Chad], answer: A }question_id的设计不能随意。建议包含语言、区域和类别例如MQA-ZH-AS-0042这样在结果分析时可以直接从编号中提取信息也可以避免把不同来源的题目混在一起。choices中的选项顺序也需要稳定。如果一个基准在多次评测中随机打乱选项顺序那么答案字段也要同步更新。固定顺序有助于做可复现实验也便于人工复核。2.2 多语言题面的设计思路多语言题面不是简单的翻译流水线。同一个地理题目在不同语言中可能有不同的表达习惯。以“哪个国家位于埃及以南”为例{ question_id: MQA-ZH-AF-0124, language: zh, region: af, category: direction, question: 以下哪个国家位于埃及以南, choices: [苏丹, 利比亚, 以色列, 乍得], answer: A }{ question_id: MQA-ES-AF-0125, language: es, region: af, category: direction, question: ¿Qué país está al sur de Egipto?, choices: [Sudán, Libia, Israel, Chad], answer: A }这里的关键是地名也要采用目标语言中通用的写法而不是一律使用英文地名。例如中文题面中的“苏丹”“乍得”与英文拼写不同。如果评测脚本只按英文地名做实体匹配就会遇到问题。使用多语言题面时prompt 的指令语言也最好与题面语言对齐。不能在中文题面后加英语指令。一个稳妥做法是在数据集中增加一个instruction_language字段或者按language字段从映射表中读取对应的“只输出选项字母”指令。这样能减少指令语言与题面语言不一致造成的干扰。2.3 全球多样性如何体现在答案分布中全球多样性不能只靠“题目里包含多个国家”来体现。它体现在样本的区域分布、语言分布和题型分布三个层面。区域分布层面题目应该覆盖非洲、亚洲、欧洲、北美洲、南美洲和大洋洲。北极和南极区域可以作为专项题集补充但数量不宜过多。每个区域的题量要尽量均衡否则总体准确率会被高频区域主导。语言分布层面高资源语言和低资源语言需要混合。英文、中文、西班牙语、法语等可以占一部分同时也要纳入非洲、南亚、东南亚等区域使用的语言。不能因为某种语言用户少就不加题因为“全球多样性”的本意正是要测试模型对少资源地理区域的覆盖能力。题型分布层面一个合格的地理空间推理基准不可能只考方向题。建议至少包含题型能力点direction判断方位关系adjacency判断邻国或相邻行政区域distance比较相对距离administrative判断城市与行政区划的归属关系landmark判断地标所在位置natural region判断气候带、植被区、地形区答案分布也需要校准。不能出现某一题中 A 选项永远正确或者某个区域题目的答案集中在同一个字母。这可以通过构建脚本或人工抽检来控制。在复杂地理题中可能存在“边界模糊”的情况。例如“哪个国家位于埃及以南”中乍得也在埃及西南方向可能造成争议。基准设计者在制作题目时应通过“directly south”或“最合适”这样的限定词消除歧义。注意如果读者拿到的 MultiGlobeQA 数据版本字段有所不同应以实际数据文件为准。上面的字段设计用于建立一个可运行的评测逻辑而不是替代官方规范。3. 搭建一个可复现的 MultiGlobeQA 评测流程3.1 环境准备与依赖评测脚本的依赖不多。推荐 Python 3.10 或更高版本使用一个独立的虚拟环境。python -m venv .venv source .venv/bin/activate pip install openai1.0 pandas这里使用openaiPython 包是因为很多自部署模型服务、云端模型 API 都提供了 OpenAI 兼容接口。这样评测脚本可以做到模型无关只要服务地址和模型名可配就能评测不同模型。不强制依赖pandas但如果要做按语言、区域、题型的聚合统计pandas会方便很多。如果希望保持轻量也可以用标准库collections.defaultdict替代。依赖清单参考软件或库作用建议Python运行评测脚本 3.10openai调用 OpenAI 兼容接口 1.0pandas结果聚合与透视表 2.0json/jsonlines读写数据Python 标准库3.2 数据加载与标准化数据文件使用 JSON Lines 格式读取一行一条题目。加载之后先做 schema 校验避免后续因为字段缺失或选项错误导致评测中断。import json from typing import List, Dict def load_instances(path: str) - List[Dict]: instances [] with open(path, r, encodingutf-8) as f: for line in f: line line.strip() if not line: continue instances.append(json.loads(line)) return instances def validate_instance(inst: Dict) - bool: required_fields [ question_id, language, region, category, question, choices, answer, ] if not all(field in inst for field in required_fields): return False if len(inst[choices]) 2: return False if inst[answer] not in ABCDEFGHIJ: return False return True这里的选择题选项数量限制在 2 到 10 个因此答案字母范围是A-J。如果题目设计固定为 4 个选项可以把校验范围改成ABCD。数据加载后建议做一次批量校验def filter_valid_instances(instances: List[Dict]) - List[Dict]: valid [] for inst in instances: if validate_instance(inst): valid.append(inst) else: print(fInvalid instance: {inst.get(question_id, unknown)}) return valid这样做的目的是把“数据问题”和“模型问题”分开。如果某道题字段不全模型答错了也不是模型能力问题而是评测数据问题。3.3 调用大模型生成答案模型调用层建议定义一个抽象类或通用类。这里给出一个基于 OpenAI 兼容接口的实现方便替换成自部署模型。from openai import OpenAI class OpenAICompatibleModel: def __init__(self, model_name: str, api_base: str, api_key: str): self.client OpenAI(base_urlapi_base, api_keyapi_key) self.model_name model_name def predict(self, prompt: str) - str: resp self.client.chat.completions.create( modelself.model_name, messages[ {role: user, content: prompt} ], temperature0, max_tokens32, ) return resp.choices[0].message.content.strip()temperature0是为了让评测结果尽量稳定。max_tokens32是因为选择题只需要一个字母或很短文本不需要让模型生成大段解释。如果模型支持输出 logits 或 JSON 结构也可以通过 constrained decoding 限制输出只能是选项字母但这里为了通用性先不做。构造 prompt 时需要把题面和选项拼接起来。指令语言要尽量与题面语言一致。给出一个简单映射INSTRUCTIONS { en: Output only the letter of the correct answer., zh: 请只输出正确选项的字母。, es: Responde solo con la letra de la opción correcta., } def build_prompt(instance: Dict) - str: labels ABCDEFGHIJ lines [instance[question]] for idx, choice in enumerate(instance[choices]): lines.append(f{labels[idx]}. {choice}) lang instance.get(language, en) instruction INSTRUCTIONS.get(lang, INSTRUCTIONS[en]) lines.append(instruction) return \n.join(lines)language字段如果缺失默认使用英语指令。实际项目中这个映射表应该覆盖数据集中的所有语言。3.4 评测指标与结果输出评测主循环需要记录每一次模型输出、正确答案、是否匹配以及题目的语言、区域、题型等元信息。这样后续分析才不会丢失原因。import re def normalize_answer(text: str) - str: text text.strip().upper() m re.search(r\b([A-J])\b, text) if m: return m.group(1) return text def run_evaluation(instances, model, max_samplesNone): results [] if max_samples is not None: instances instances[:max_samples] for inst in instances: prompt build_prompt(inst) raw_pred model.predict(prompt) pred normalize_answer(raw_pred) gold inst[answer].strip().upper() results.append({ question_id: inst[question_id], language: inst.get(language, ), region: inst.get(region, ), category: inst.get(category, ), difficulty: inst.get(difficulty, ), gold: gold, prediction: pred, raw_prediction: raw_pred, correct: pred gold, }) return results结果计算可以写成一个聚合函数。这里使用标准库实现按字段拆分from collections import defaultdict def compute_accuracy(results): if not results: return 0.0 return sum(r[correct] for r in results) / len(results) def accuracy_by_field(results, field): groups defaultdict(lambda: {correct: 0, total: 0}) for r in results: key r.get(field, unknown) groups[key][total] 1 groups[key][correct] int(r[correct]) report {} for key, stat in groups.items(): report[key] { accuracy: stat[correct] / stat[total], correct: stat[correct], total: stat[total], } return report输出结果时推荐同时保存两份文件一份是原始结果包含每个请求的完整输出一份是聚合报告方便直接查看。import csv def save_results(results, output_path): with open(output_path, w, encodingutf-8, newline) as f: writer csv.DictWriter(f, fieldnames[ question_id, language, region, category, difficulty, gold, prediction, raw_prediction, correct ]) writer.writeheader() writer.writerows(results) def print_report(results): print(fOverall accuracy: {compute_accuracy(results):.4f}) print(By language:) for lang, stat in accuracy_by_field(results, language).items(): print(f {lang}: {stat[accuracy]:.4f} ({stat[correct]}/{stat[total]})) print(By region:) for region, stat in accuracy_by_field(results, region).items(): print(f {region}: {stat[accuracy]:.4f} ({stat[correct]}/{stat[total]}))运行评测的入口可以写成一个命令行脚本import argparse def main(): parser argparse.ArgumentParser() parser.add_argument(--data, requiredTrue, helpPath to JSONL data file) parser.add_argument(--model, requiredTrue, helpModel name) parser.add_argument(--api_base, requiredTrue, helpAPI base URL) parser.add_argument(--api_key, defaultEMPTY, helpAPI key) parser.add_argument(--max_samples, typeint, defaultNone) parser.add_argument(--output, defaultresults.csv) args parser.parse_args() instances load_instances(args.data) instances filter_valid_instances(instances) model OpenAICompatibleModel(args.model, args.api_base, args.api_key) results run_evaluation(instances, model, args.max_samples) save_results(results, args.output) print_report(results) if __name__ __main__: main()命令行执行示例python run_multiglobeqa.py \ --data data/qa.jsonl \ --model llama3.1-8b \ --api_base https://your-endpoint/v1 \ --api_key EMPTY \ --max_samples 200 \ --output results.csv在正式评测时api_key不应写在命令行中建议从环境变量读取。上面的命令行写法是为了快速演示。4. 用数据分析模型在地理空间推理中的薄弱点4.1 按语言维度拆解分数总体准确率只能告诉我们模型大概行不行不能告诉我们在哪里不行。按语言维度拆解是最直接的分析方式。假设评测结果保存在results.csv用 pandas 可以快速得到透视表import pandas as pd df pd.read_csv(results.csv) lang_report df.groupby(language).agg( total(correct, count), correct(correct, sum) ) lang_report[accuracy] lang_report[correct] / lang_report[total]输出表头类似languagetotalcorrectaccuracyen100780.780zh80700.875es70520.743sw50210.420实际数字仅为示意。分析时重点不是看哪种语言分数最高而是要观察“语言覆盖不够导致分数骤降”的模式。如果一个模型在英文上准确率 78%在某种低资源语言上只有 42%那么它的地理知识很可能来自英文语料而不是真正的空间推理能力。4.2 按区域维度拆解分数按区域拆解可以定位地理覆盖盲区region_report df.groupby(region).agg( total(correct, count), correct(correct, sum) ) region_report[accuracy] region_report[correct] / region_report[total]同样可以按category拆解比较方向题、邻国题、距离题、行政区划题的差异。如果模型在邻国题上表现好但在行政区划题上表现差说明它对“点状地名”和“面状行政层级”的表达理解不够。4.3 错误类型与典型失败模式只看准确率还不够还要看错误样本长什么样。通过原始预测结果可以归纳出几种典型失败模式模型输出了非选项字母或完整句子导致归一化失败。模型选择了与正确答案地理上邻近的选项说明空间定位不够精确。模型无法识别某语言的本地地名导致随机乱猜。模型对行政层级概念混乱混淆国家、省、城市。写一个简单的错误抽样脚本可以快速观察失败原因def sample_errors(results, fieldraw_prediction, n10): errors [r for r in results if not r[correct]] for r in errors[:n]: print(r[question_id], r[language], r[region]) print(Question:, r.get(raw_prediction, )) print(Gold:, r[gold], Pred:, r[prediction]) print(---)注意在这个简化的结果字典中我们保存了raw_prediction。如果只保存了归一化后的prediction就无法判断是格式问题还是知识问题。因此评测脚本中保留原始输出非常重要。注意分析错误时不要只看前几条。建议从不同语言和区域分别抽样否则容易只看到高资源语言的失败模式。5. 常见问题与排查路径5.1 多语言文本编码和文件读写问题现象读取 JSONL 文件时中文、阿拉伯语或斯瓦希里语文本变成乱码或者运行脚本时出现UnicodeEncodeError。原因很多脚本默认使用系统编码在 Windows 控制台上可能无法输出非 ASCII 字符。也可能是文件写入时没有指定encodingutf-8。检查方式python -c import sys; print(sys.stdout.encoding)如果输出不是utf-8运行评测时先设置环境变量export PYTHONIOENCODINGutf-8处理建议所有文件读写都显式传入encodingutf-8不要依赖系统默认编码。保存结果时同样指定 UTF-8。这能避免在本地复现时出现“评测脚本本身把答案搞乱”的情况。5.2 模型输出格式不规范现象模型经常输出“答案是 A”“正确答案是 A”或者一段解释导致归一化后取不到字母。原因模型没有严格遵循 prompt 的“只输出选项字母”指令也可能是max_tokens设置过大让模型觉得应该给出详细回答。处理方式先改进normalize_answer从输出中用正则提取第一个大写字母。更好的方式是限制max_tokens为 8 到 16并尝试在 prompt 中给出一个示例Please output only the letter of the correct answer. Example output: A如果模型支持 logprobs 或 JSON 结构化输出可以进一步限制输出必须匹配A-J中的某一个字母。这是最稳定的方案。5.3 地理答案边界模糊导致空判现象一道题中存在多个从字面上看都正确的选项模型选择了其中一个但数据集给出的标准答案不同于是被判错。原因地理关系天然存在边界模糊。例如“位于埃及以南”在英文中如果写成 “south of Egypt”乍得在西南方向也能被某些人理解为“在南部区域”。这种题如果不加限定词就不适合作为单选题。检查方式把错误样本拿出来查看题目原文和选项判断是否存在歧义。如果存在应修正题目或删除该题而不是怀疑模型能力。处理建议在编写题目时加入“directly south”“最合适”等限定词。在评测报告中如果这类歧义题数量较多应对精度造成的影响单独说明。5.4 API 请求不稳定或限流现象评测跑到一半某个请求返回超时或限流错误。脚本中断后已经跑过的结果丢失。原因评测脚本没有做重试也没有断点续跑。大批量请求云端 API 时限流是常见问题。处理方式在模型调用层加入重试和指数退避。更稳妥的做法是每跑完一道题就把当前记录追加写入 CSV这样中断后可以从已有的question_id集合中恢复。import time def predict_with_retry(model, prompt, retries3, delay2.0): for attempt in range(retries): try: return model.predict(prompt) except Exception as e: print(fRequest failed: {e}; retry {attempt 1}/{retries}) time.sleep(delay * (attempt 1)) raise RuntimeError(Predict failed after retries)这个处理在生产环境评测中尤其重要。学习环境小样本可以忽略但全量评测必须把重试、日志和断点保存加进去。6. 从评测基准走向工程实践最佳实践与扩展方向6.1 复现 MultiGlobeQA 的过程清单使用一个评测基准建议按下面的清单执行。这份清单同时适用于 MultiGlobeQA 和其他类似的多语言地理推理数据集。确认数据集版本和数据格式阅读样例文件弄清必填字段和可选字段。建立独立虚拟环境安装评测依赖。先运行校验脚本统计无效题目的占比。配置模型 API 地址、模型名和密钥。密钥从环境变量读取不能写死在代码中。小样本试跑例如--max_samples 20确认输出文件不是乱码、字段完整。全量评测时开启断点续写、请求重试和日志记录。同时保存归一化预测和原始输出便于后续错误分析。生成总体准确率、语言维度、区域维度、题型维度报告。根据错误样本修正数据歧义或 prompt 设计再复跑对照。小样本试跑是很容易被跳过的一步。直接全量跑容易出现跑完后才发现 prompt 没拼对、答案无法归一化的问题。6.2 学习环境与生产环境的差异学习环境的目标是快速理解评测流程生产环境的目标是稳定复现并支撑模型迭代决策。两者差异明显。维度学习环境生产环境样本量几十道题全量数据集请求重试可有可无必须配置断点续跑不需要强烈建议API 密钥可以写常量环境变量或密钥管理输出记录打印即可保存原始响应和日志指标解释看总体准确率按语言、区域、题型拆解模型采样temperature0temperature0必要时多次采样数据校验简单过滤全量校验并统计质量如果企业需要把地理空间推理能力接入客服、搜索或地图产品建议在生产评测中增加多次采样和人工复核。只跑一次可能因为模型随机性造成误判。6.3 扩展方向MultiGlobeQA 这类基准解决的是纯文本地理空间推理问题。实际业务中还可以从三个方向扩展。第一加入视觉输入。许多地理问题需要看地图、街区图、卫星图才能回答。未来评测可以引入“文本题面 地图图像”的多模态题型评估视觉语言模型在空间布局理解上的能力。第二加入多跳和时空推理。当前的方向、邻国题大多是一跳关系。实际场景中用户可能问“从 A 出发向南经过 B再向东到 C 有多少公里”这类多步问题。这类问题需要模型组合多个空间关系难度更高。第三加入更细粒度的本地化表达。同一个地点的地名可能在不同语言中差异很大例如许多东南亚和非洲城市的拼音写法与英文写法不同。评测基准可以针对这些差异设置“本地名称识别”和“跨语言地名对齐”专项题。从工程角度来看引入 MultiGlobeQA 最重要的一点是让“地理空间推理能力”不再是模糊感觉而是一组可复现、可拆解、可对比的指标。模型升级后是否真的有进步不能只看几条示例而要回到统一数据、统一脚本、统一指标上做对照。判断一个模型的地理空间能力也不应该只看总体准确率。多语言、全球多样性的基准真正价值在于帮助开发者把能力缺口定位到语言、区域和题型维度。最值得实践的一点是从数据格式、评测逻辑到错误分析都保持可复现这样模型迭代或多语言扩展后才能看到可比较的变化。