MultiGlobeQA：多语言地理空间推理评测基准实战指南

这次我们来看一个比较硬核的评测基准项目：MultiGlobeQA。它面向的是地理空间推理（Geospatial Reasoning），并且强调多语言和全球多样性。如果你正在做多模态大模型、地理信息相关模型，或者想验证自己的检索模型、推理模型在空间理解上到底什么水平，这篇文章可以直接收藏。

先回答几个大家最关心的问题：MultiGlobeQA 是什么、能测什么、多语言分布怎么样、需要什么环境、怎么跑评测脚本、怎么算指标、怎么批量跑，以及最容易踩的坑在哪里。

1. 核心能力速览

MultiGlobeQA 本身不是一个需要跑在 4090 上的推理模型，它是一个评测集加一套评测流程。真正的资源消耗取决于你评测的模型规模和推理方式。如果你只是先看数据集结构，普通 CPU 机器完全够用。

2. 适用场景与使用边界

先说要解决的问题。地理空间推理是很多大模型比较薄弱的环节。普通的常识问答模型能回答“法国首都是哪里”，但面对“从北京到乌鲁木齐，如果不经过兰州，最合理的替代路线要穿过哪些山脉”这类复杂的空间约束问题，很多模型会直接崩。MultiGlobeQA 的定位就是把这类问题系统化，并且拉入不同语言和文化背景下的地理文本，防止模型的评测结果只盯着英语数据。

从材料来看，这个项目有下面几个比较清晰的用途：

• 多语言地理 QA 评测：评估模型在非英语地理问题上的表现，比如阿拉伯语、印地语、中文、斯瓦希里语、西班牙语等。
• 空间关系推理评估：考察模型理解方向、距离、邻接关系、国界线、河流走向等空间事实的能力。
• 跨区域泛化测试：检验模型在非欧美中心化数据上的表现，验证训练数据是否存在地域偏差。
• 基准对比：报道自己的模型在 MultiGlobeQA 上的跑分，可以作为论文的实验部分。

不适合什么场景？MultiGlobeQA 不是训练数据集，不要拿它去微调模型，否则会造成评测集污染。它也不是实时地理信息系统，不能用来做路径规划或地图渲染。它更适合做评测打分、能力对比和诊断分析。

合规和安全边界方面，涉及地理空间数据时要注意：不要传播未经授权的高精度测绘数据，不要用评测数据去推导敏感设施位置。做多语言评测时，尽量使用项目公开发布的评测集，避免自行抓取网络地理数据造成版权问题。

3. 环境准备与前置条件

先给一套通用的环境检查清单，按这个顺序确认基本不会出问题。

3.1 操作系统与 Python 版本

• 操作系统：Ubuntu 20.04/22.04、macOS、Windows WSL2 均可。
• Python 版本：推荐 3.9 到 3.11。要注意，部分评测框架在 3.12 下可能存在依赖兼容问题。
• 包管理建议：使用conda创建独立环境，避免污染系统 Python。

conda create -n multiglobe python=3.10 -y conda activate multiglobe pip install --upgrade pip

3.2 Python 依赖

评测脚本通常会用到以下依赖，具体版本需要以项目requirements.txt为准：

如果你的模型是纯 API 模式，比如调用 DashScope、OpenAI 兼容接口或自建 vLLM 服务，就不需要transformers也能完成评测，只需要保留requests和pandas。

3.3 显卡与显存

这里需要分两种情况说明。

第一种，只用官方评测集，不加载模型，只检查数据内容。这种情况完全不需要 GPU，普通办公电脑就能跑。

第二种，评测一个本地大模型。显存占用完全取决于模型大小。例如一个 7B 模型就算用 4bit 量化，推理时也需要至少 6GB 到 8GB 显存；一个 70B 模型至少需要 48GB 以上。多语言评测如果启用批量推理，显存占用还会成倍增长。具体显存需求必须以模型实际部署情况为准，评测脚本本身不会吃掉太多显存。

稳妥建议：先用 API 模式跑通整个评测流程，再决定是否有必要在本地部署大模型。

3.4 磁盘空间

• 数据集本身：通常几十 MB 到几百 MB，占用非常小。
• 评测结果缓存：按评测轮次生成 JSON/CSV，单次结果通常不超过几百 KB。
• 如果本地部署模型：7B 模型 4bit 量化约 4GB，FP16 约 14GB；下载前先确认磁盘空间。

4. 安装部署与启动方式

由于目前材料中没有给出 MultiGlobeQA 官方仓库的具体命令，下面给出一套通用评测项目流程。实际操作时，以官方 README 为准，替换仓库地址和脚本路径即可。

4.1 克隆仓库

git clone https://github.com/your-org/MultiGlobeQA.git cd MultiGlobeQA

如果你的网络环境无法直接访问 GitHub，可以将仓库手动下载后上传到服务器。

4.2 安装依赖

pip install -r requirements.txt

如果requirements.txt不存在，先安装最小依赖集：

pip install datasets pandas scikit-learn tqdm

4.3 检查数据集结构

评测项目通常会提供一个data/目录或通过 Hugging Face Datasets 分发。先看目录结构：

tree -L 2 data/

一个常见的结构可能是：

data/ ├── train/ ├── dev/ ├── test/ └── metadata.json

如果数据集通过 Hugging Face Datasets 分发，可以用下面这个通用脚本加载：

from datasets import load_dataset dataset = load_dataset("path/to/MultiGlobeQA") print(dataset)

4.4 启动评测

通用评测命令格式如下：

python run_eval.py \ --model_name_or_path Qwen/Qwen2.5-7B-Instruct \ --dataset_path data/test \ --output_dir outputs/test_run \ --batch_size 4

如果是 API 模型评测，参数会变成--api_base和--api_key形式：

python run_eval.py \ --api_base "http://127.0.0.1:8000/v1" \ --api_key "EMPTY" \ --model_name "custom-llm" \ --dataset_path data/test

注意，这些命令是通用示例，实际参数名称可能不同，必须按项目 README 调整。

5. 功能测试与效果验证

拿到 MultiGlobeQA 之后，不要急着全量跑。先做小批量测试，确认数据加载、模型推理、指标计算三个环节都能跑通，再全量评测。

5.1 检查数据加载是否正常

先用 Python 直接查看数据样本：

from datasets import load_dataset dataset = load_dataset("json", data_files="data/test/test.jsonl") sample = dataset["train"][0] print(sample.keys()) print(sample)

预期可以看到类似下面的字段：

{ "question": "Which country lies between Namibia and Mozambique?", "options": ["Botswana", "Zambia", "Zimbabwe", "South Africa"], "answer": "Botswana", "language": "en", "region": "Africa", "source": "geo-benchmark" }

如果字段名不一致，说明数据集 schema 与你的评测脚本不匹配，需要先调整。

5.2 单条样例推理测试

先跑 5 到 10 条题目，验证模型输出格式和评测脚本解析逻辑是否兼容。这里给一个通用推理测试脚本：

import json from transformers import AutoModelForCausalLM, AutoTokenizer model_name = "Qwen/Qwen2.5-7B-Instruct" tokenizer = AutoTokenizer.from_pretrained(model_name) model = AutoModelForCausalLM.from_pretrained(model_name, device_map="auto") def predict(sample): prompt = f"Question: {sample['question']}\nOptions: {sample['options']}\nAnswer:" inputs = tokenizer(prompt, return_tensors="pt").to(model.device) outputs = model.generate(**inputs, max_new_tokens=64) result = tokenizer.decode(outputs[0], skip_special_tokens=True) return result.split("Answer:")[-1].strip() sample = dataset["train"][0] print("Ground truth:", sample["answer"]) print("Prediction:", predict(sample))

这个环节重点看两件事：

• 模型能不能输出有效答案。
• 评测脚本能不能从输出中提取出选项A/B/C/D或答案文本。

5.3 多语言题目抽查

MultiGlobeQA 的核心卖点之一是多语言。建议从测试集中筛选三种不同语言的题目各抽 20 条，单独跑一遍，观察模型在不同语言上的表现差异。

from datasets import load_dataset dataset = load_dataset("json", data_files="data/test/test.jsonl") languages = dataset["train"].unique("language") print("Languages in the test set:", languages) sample_subset = dataset["train"].filter(lambda x: x["language"] in ["en", "zh", "hi"])

跑完记录下每类语言的准确率。这一步的意义不只是看分数，还能判断模型是否存在严重的语言偏科问题。

5.4 小批量全流程验证

用 50 条数据跑完整评测流程，确认输出报告格式和指标计算逻辑正常。

python run_eval.py \ --model_name_or_path Qwen/Qwen2.5-7B-Instruct \ --dataset_path data/test \ --max_samples 50 \ --output_dir outputs/smoke_test

评测完成后，检查输出目录：

ls -la outputs/smoke_test/

预期看到：

predictions.jsonl metrics.json summary.csv

如果三个文件都存在，且metrics.json能在打开时不报错，说明全流程已经跑通。

5.5 全量测试

小批量跑通后，再放开全量测试。这里建议分批跑，方便定位失败任务。

python run_eval.py \ --model_name_or_path Qwen/Qwen2.5-7B-Instruct \ --dataset_path data/test \ --output_dir outputs/full_run \ --batch_size 8

5.6 效果判断标准

不同模型在同一评测集上的分数可以从模型底座能力差异来解释，但判断一次评测是否有效，主要不是看分数高低，而是看：

• 数据集加载是否完整，没有重复或缺失。
• 预测结果是否可解析，未解析率不能过高。
• 指标计算逻辑是否正确，多语言子集有独立的指标报告。
• 评测日志中是否出现异常样本，比如空输出、截断输出。

未解析率是重点中的重点。如果大量模型的输出无法提取出有效答案，那评测基准本身没问题，是你的生产提示词和解析逻辑不匹配。先调整提示词，再调整解析函数，最后才考虑换模型。

6. 接口 API 与批量任务

评测类项目最常见的集成方式不是本地加载模型，而是通过 API 调用模型服务。这样做的优势很明显：评测脚本只负责发请求，模型推理由 vLLM、Ollama 等独立服务处理，评测失败重启时不会连模型一起重启。

6.1 启动 OpenAI 兼容服务

如果你的评测脚本支持 OpenAI 兼容接口，先启动一个本地模型服务：

python -m vllm.entrypoints.openai.api_server \ --model Qwen/Qwen2.5-7B-Instruct \ --port 8000 \ --gpu-memory-utilization 0.9

这一步是模型服务启动，不是 MultiGlobeQA 评测启动，实际命令以你自己的模型服务为准。

服务启动后，用 curl 验证接口可用：

curl http://127.0.0.1:8000/v1/models

看到模型列表返回后，再启动评测脚本。

6.2 评测脚本中调用 API

通用 Python 调用模板如下：

import requests url = "http://127.0.0.1:8000/v1/chat/completions" payload = { "model": "Qwen/Qwen2.5-7B-Instruct", "messages": [ { "role": "user", "content": "Question: Which country lies between Namibia and Mozambique?" } ], "temperature": 0.0, "max_tokens": 64 } response = requests.post(url, json=payload, timeout=60) print(response.json())

注意，评测任务要把temperature设为 0 或接近 0，尽量保证可复现性。真实评测脚本里，通常会连续发送多个样本，因此要给请求加上超时控制和重试逻辑。

6.3 批量评测设计

多语言评测经常要同时评估多个模型，或者同一模型跑多个 subset。推荐目录结构如下：

outputs/ ├── modelA/ │ ├── en/ │ ├── zh/ │ └── hi/ ├── modelB/ │ ├── en/ │ ├── zh/ │ └── hi/ └── aggregate_report.csv

批量提交时，写一个简单的 Shell 循环：

for lang in en zh hi ar sw do python run_eval.py \ --model_name_or_path Qwen/Qwen2.5-7B-Instruct \ --dataset_path data/test \ --language $lang \ --output_dir outputs/modelA/$lang done

如果评测集本身没有按语言拆分的启动参数，也可以先用 Python 过滤数据，生成临时评测文件。

import pandas as pd df = pd.read_json("data/test/test.jsonl", lines=True) for lang in df["language"].unique(): subset = df[df["language"] == lang] subset.to_json(f"data/test_{lang}.jsonl", orient="records", lines=True)

6.4 失败重试与日志

批量评测最怕中途挂掉。除了加超时和重试，还要在评测脚本里记录每一条样本的推理状态。推荐在预测结果中增加status字段：

{ "question_id": "test_0042", "language": "zh", "status": "success", "prediction": "B", "ground_truth": "B" }

对于失败样本，单独输出到一个failed_samples.jsonl，方便续跑：

python run_eval.py \ --model_name_or_path Qwen/Qwen2.5-7B-Instruct \ --dataset_path data/test \ --resume_from outputs/full_run/failed_samples.jsonl

这里强调一点：评测类脚本的续跑功能如果不确定是否存在，不要硬用，先看项目有没有--resume参数。如果没有，就自己把失败样本过滤出来重跑，然后把结果 merge 回去。

7. 资源占用与性能观察

MultiGlobeQA 本身就是一串文本题目，评测过程的主要资源消耗来自模型推理。下面分几个维度说明如何观察和定位瓶颈。

7.1 显存占用观察方法

如果模型运行在本地 GPU 上，用nvidia-smi实时观察显存：

nvidia-smi --query-gpu=index,memory.used,memory.total,utilization.gpu --format=csv -l 2

-l 2表示每 2 秒刷新一次。批量推理时，memory.used会随着 batch_size 增大而升高。

7.2 CPU 与 GPU 推理差异

如果只是想在数据集层面调试脚本，CPU 模式完全够用。但如果你要评测 7B 以上模型，CPU 推理一次生成 64 token 可能需要几秒到几十秒，几百条样本累积下来会非常慢。

建议策略：

• 开发调试阶段：采样 20 条数据，CPU 模式，验证流程。
• 正式评测阶段：GPU 模式，或者用 vLLM 起 API 服务，再通过 API 跑评测。

7.3 影响推理速度的主要参数

多语言评测里还有一个容易被忽视的问题：不同语言的 tokenizer 编码效率差异很大。比如同一个地理问题，英语可能消耗 40 个 token，中文可能只要 25 个 token，而越南语或者阿拉伯语可能消耗 80 个 token。这会导致不同语言的推理速度有明显差异，不是模型变慢了，而是 token 数变了。

7.4 降低资源占用的方式

如果本地显存实在紧张，推荐按这个顺序调整：

• batch_size降到 1，看是否稳定。
• 用 4bit 量化加载模型。
• 使用FlashAttention-2（如果模型支持）。
• 改用 API 模式评测，模型加载到远程服务。
• 淘汰掉生成多余文本的提示词，让模型只输出选项字母。

7.5 防止进程残留

评测过程中 Ctrl+C 中断后，显存可能不会立刻释放。排查方法：

nvidia-smi

如果看到残留的 Python 进程占用显存：

ps aux | grep run_eval kill -9 <PID>

也可以直接用pkill清理，但要小心别误杀其他进程。

8. 常见问题与排查方法

地理解析类评测看起来简单，实际跑起来会遇到很多细碎问题。这里列一个排查表，按出现的可能性排序。

这里说一个比较容易忽略的问题：选项顺序偏置。很多模型在选择题评测中倾向于输出某个固定位置的选项，比如选 A 或选 C。如果你发现某个模型在 MultiGlobeQA 上全选了一个字母，准确率居然还能到 25% 甚至更高，说明评测集中选项顺序固定，存在偏置风险。缓解方式有两种：

• 如果项目原始数据支持，多次随机打乱选项顺序取平均。
• 查看官方 README 是否已做选项随机化处理。

如果没有选项随机化，你自己在评测时也可以做一次数据的“选项重排”，得到更真实的准确率。

9. 最佳实践与使用建议

跑 MultiGlobeQA 这类评测基准，有几点工程经验值得提前记下来。

9.1 数据与代码分离

数据集、评测脚本、模型输出尽可能分开。目录结构推荐：

MultiGlobeQA/ ├── data/ # 原始评测集，文件只读 ├── scripts/ # 评测脚本 ├── outputs/ # 模型输出和指标报告 ├── logs/ # 运行日志 └── README.md

数据文件设置为只读，防止评测脚本误写污染原始数据。

chmod -w data/test/test.jsonl

9.2 先跑金标样本

在正式评测前，手动挑选 10 条不同语言、不同难度梯度的样本，人工验证模型能答对大部分题目。如果这些样本都答不对，说明 prompt 写法或者模型本身不适合这个任务，不要急着全量跑。

9.3 固定推理参数和随机种子

评测报告里一定要写明temperature、top_p、max_tokens、模型版本和量化配置。不写推理参数的评测分数没有参考价值。

model: Qwen2.5-7B-Instruct quantization: 4bit temperature: 0.0 top_p: 1.0 max_tokens: 64 batch_size: 8

9.4 记录每个模型的评测环境

建议用 JSON 文件记录评测元信息，方便复现。

{ "model_name": "Qwen2.5-7B-Instruct", "inference_server": "vllm", "cuda_version": "12.1", "dataset_version": "v1.2", "date": "2026-01-15", "notes": "temperature=0, no system prompt" }

9.5 多语言代码切换提示词

如果你用的是中文、日文、韩文等模型，直接让它用英文回答地理问题时效果不一定好，更适合的做法是指定输出语言。给一个相对比较稳的 prompt 模板：

You are a geography expert. Answer the following multiple-choice question by choosing one option (A/B/C/D). Question: {question} Options: A. {option_a} B. {option_b} C. {option_c} D. {option_d} Answer:

9.6 合规和数据边界

评测地理空间数据时，注意几个原则：

• 只使用项目分发或明确授权的评测集。
• 不要将评测集用于模型微调。
• 如果涉及地名推导，不得结合任何高精度坐标数据。
• 发布评测分数时，注明数据集版本和评测配置。

9.7 对比结果发布建议

如果后续要发论文或博客，建议对每个语言子集单独报告准确率，不要只报一个总分数。比如：

只报总分很容易掩盖模型在低资源语言上的真实短板，这恰恰与 MultiGlobeQA 的初衷背道而驰。

10. 总结与下一步

MultiGlobeQA 最值得尝试的点在于它把地理空间推理和多语言两个维度绑在了一起。过去我们看模型的地理能力，经常只测英语；看多语言能力，又经常只测通用文本。MultiGlobeQA 把这两个维度交叉起来，能够快速暴露一个模型是否在非英语地理知识上有系统性短板。

先建议验证的流程是：克隆仓库，加载 50 条样本，用一个小模型或 API 跑通评测环境，确认指标计算脚本输出正常。跑通之后，再决定要不要上大模型全量评测。

最容易踩的坑有三个：一是数据集字段映射不正确导致加载时报错；二是模型输出的答案文本无法被解析函数提取；三是多语言子集的 prompt 没有做语言适配，导致非英语准确率失真。这三个坑都提前规避，后面就比较顺利。

后续可以继续扩展的方向包括：把 MultiGlobeQA 接入现有的 LLM 评测平台，比如 lm-evaluation-harness 自定义任务；将评测结果按地理区域做可视化，生成模型跨区域能力热力图；或者结合检索增强生成（RAG）对比测试，让模型在给定地理知识库的情况下重新评测，看检索是否能补上空间推理的短板。

如果你的研究方向是地理空间大模型或多语言评测，建议收藏备用。等官方仓库放出完整评测代码后，按本文第 4 节和第 5 节的流程跑一遍，十分钟左右就能看到第一份评测报告。