开源大模型文化意识评测：知识被表示但未被解码，如何动手验证-编程实验室

这两年评测开源大模型，大家最常盯着代码、数学和通用推理。但有一个维度越测越让人困惑：文化意识。最近有一项覆盖 18 个开源 LLM 的评测研究，标题直接抛出了一个非常尖锐的判断：Cultural Awareness is Represented but Not Decoded。翻译过来就是：模型表现出了文化意识，但这些知识并没有被真正解码。

这个判断很容易被误读。大多数人拿到一份评测报告，看到模型能答出“女娲补天是阻止天柱倒塌”“普罗米修斯盗火是给人类带来了火种”，就会认为模型“懂文化”。但这项研究的核心提醒是：“记得住”和“用得上”是两回事。模型在参数里存储了大量文化符号，这只能说明文化知识被“表征”了；当需要把这些知识迁移到新的语境、完成类比推理、解释象征意义时，模型可能迅速崩盘。

这篇文章不打算逐条复述论文的测试结果，因为脱离实验环境硬搬数据没有意义。更重要的是理解三个问题：为什么文化意识评测越来越重要？“被表示但未被解码”在技术上到底指什么？以及作为普通开发者，我们能不能用一套通用方法，亲手验证自己部署的开源模型到底停留在哪个层次。

读完这篇文章，你将掌握一套最小可用的文化评测框架，包括评测数据设计思路、本地模型调用脚本、结果解读方法和避坑清单。结论先行：文化评测的关键，不是看模型知不知道某个神话人物的名字，而是看它在换问法、加推理、换场景之后还能不能答对。

1. 为什么文化意识评测会成为衡量开源 LLM 的重要维度

先看一个客观变化：开源大模型的能力竞争，已经从前两年的“能不能跑起来”进入到“能不能用得上”的阶段。代码生成、数学推理、多语言支持这些维度，头部开源模型和闭源模型的差距正在肉眼可见地缩小。这时，文化意识就成了一个容易被忽视、但其实非常影响真实使用体验的能力。

什么叫真实使用体验？假设你做一个面向中国用户的客服机器人，用户说“真是女娲补天一般的工程”，模型能不能理解这里不是说有人在补天，而是在说“这个工程需要修复巨大漏洞，难度极高”；假设你做一个跨文化内容推荐系统，用户提到“普罗米修斯式的牺牲”，模型能不能判断出这里强调的是“为大众承担风险”。这些都不是边缘场景，而是真实产品里天天会遇到的语言理解问题。

更现实的问题是：文化意识缺失，往往会被错误归因成“理解能力不行”或“提示词写得不好”。开发者反复调整 prompt，结果发现模型只是不认识某个文化隐喻。这类问题在开源模型里尤其明显，因为开源模型的训练语料分布往往更偏科，有的模型英文语料占大头，有的模型中文语料集中，对非英语、非中文的文化符号覆盖就更弱。

这也解释了为什么研究者选择开源模型而不是闭源模型做文化评测。闭源模型是黑盒，你无法确定它内部到底加载了什么语料、哪个版本的知识库、更新到哪一天。即使测出了结果，也很难复现和审计。开源模型权重固定、本地可部署，评测过程可以被任何人复核，这才是文化评测能形成可靠结论的基础。评测开源模型，本质上是在评测“这个可复现权重”的知识边界，而不是评测一个随时可能变化的在线服务。

第三个原因更偏工程：开源模型可以直接微调。如果你要构建一个面向特定文化区域的应用，文化评测能告诉你“继续预训练该补什么语料”还是“用 LoRA 微调该强化哪类推理”。评测不是学术玩家的游戏，它是模型选型和定制化改造的输入条件。

2. “被表示但没有被解码”到底是什么意思

这个短语是整个研究的核心，也是最初可能让人困惑的地方。我们用最简单的类比来解释。

想象一个学生背下了整本《希腊神话辞典》。考试如果是填空题——“普罗米修斯为什么被惩罚”，他能写出来：因为他盗火给人类。但如果问：“把普罗米修斯盗火类比成当代开源社区的‘逆向工程’，这个类比成立吗？为什么？”他可能就说不清楚了。**他拥有知识，但没有把知识组织成可迁移的推理结构。**在语言模型的语境下，这类知识就是“被表示”的。

“被表示”在技术上指的是：经过预训练，模型参数中积累了大量的文化符号共现关系。它知道“女娲”这个词经常和“补天”“造人”“创世神”一起出现，所以当你输入“女娲”时，解码器有很高概率生成“补天”。这是一种统计层面的知识存储，可以被看作“表征”。

“没有被解码”则指的是：模型不能稳定地把这些知识应用到新的、需要推理的上下文中。比如用一段不包含“女娲”专名的描述，改问“天柱倾塌、洪水滔天，谁炼五色石以补苍天”，有些模型可能答不出来；或者问“补天在今天被用来比喻什么”，模型可能只会复述神话情节，给不出隐喻层面的答案。

**从技术机制看，这个现象背后是“记忆型能力”和“推理型能力”的分离。**自回归语言模型的核心是预测下一个 token，这种架构擅长生成符合上下文分布的文本。如果训练语料里“女娲补天”出现的频率足够高，模型自然能输出高度类似神话叙事的内容。但要完成跨语境解码，模型需要把“补天”这个故事抽象成一个语义结构——“大的灾难被一种创造性的力量修复”——然后映射到一个现代场景。这个映射过程依赖的不是单纯的字面共现，而是更深层的关系推理。

这里必须强调一种常见误读：**“没有被解码”不代表模型没有文化知识，更不代表模型有意识。**它只是告诉我们：从评测者的角度看，知识没有转化为可验证的推理能力。很多人在本地跑模型时，随手问一个神话人物是谁，模型答得不错，就以为文化评测很简单。恰恰是因为这种“假阳性”太容易出现了，所以才需要把问题分成“表征层”和“解码层”来分别测试。

研究标题的另一层精妙在于，它用“represented”而不是“memorized”。为什么？因为“记忆”听起来像一种低级的背诵，而“被表示”意味着知识确实进入了模型的表征空间，只不过没有被充分激活和利用。这为后续微调提供了方向：模型不是完全没有文化知识，而是在训练过程中，缺少把知识“用起来”的任务。这比从头补知识要乐观得多。

3. 为什么偏偏选择神话知识来做文化评测

要评测文化意识，可选的素材很多，比如节日习俗、饮食文化、历史事件、社会规范。但这项研究选择神话知识，不是一个随意的决定，而是因为神话知识有一套非常适合做评测的特性。

第一，**神话知识天然跨文化存在，且结构可对比。**几乎所有文明都有自己的创世神话、英雄传说、灾难叙事。希腊神话有盗火者，中国神话有补天者，北欧神话有诸神黄昏，印度神话有创世与毁灭的循环。这种结构相似性让跨文化对比成为可能：你可以用同一套题型，去测模型对多个文化区域的掌握程度，而不是只测某一个国家的题库。

第二，神话知识有明确的“标准答案”，但又不只是死记硬背。“女娲补天”的基本事实是固定的，这非常适合做 recall 类题目，判断模型是否记住了基础信息。同时，神话本身带有强烈的象征意义和隐喻价值，又可以设计 decode 类题目，判断模型能否完成从具象故事到抽象语义的跳跃。这种两级结构，天然适合验证“Represented but not Decoded”的假设。

第三，**神话知识不容易被模型“蒙混过关”。**常识性题目有一个问题：模型可能通过语感或概率分布猜对。比如你问“鲸鱼是鱼吗”，模型见过很多相关讨论，靠上下文都能答对。但神话知识相对小众，尤其是非主流文化区域的神话知识，训练语料覆盖不足时，模型很难靠语言流畅度猜出正确答案。它要么真的知道，要么只能瞎猜，这给了评测更高的区分度。

第四，**神话知识受到数据污染影响的形式更可控。**你问模型“杜甫是哪朝诗人”，它可能在闲聊数据里见过无数次。但如果你编一个新问题，或者对同一实体换一种指代方式，比如“工部员外郎在流落成都时写下的《茅屋为秋风所破歌》，表达的是什么”，模型可能就不知道了。神话知识的实体和命名方式相对固定，方便做各种扰动实验，也方便研究者发现模型到底是“记住了文本”还是“理解了解释结构”。

当然，神话评测也有一个需要警惕的局限：神话知识只是文化意识的一个切片。一个人懂神话，不等于他懂日常社交礼仪、商业沟通惯例、现代文化梗。**神话评测更准确的定位是“文化意识的可操作代理指标”，而不是文化能力的全部。**但它有一个优势：客观、可打分、可复现。作为一次评测的起步点，神话知识是非常合理的选择。

4. 18 个开源 LLM 评测的方法论拆解

虽然我们拿不到论文的完整数据表，但从这类评测常见的框架设计，可以还原出一套可靠的文化评测方法论。理解这套方法论，比记住几个模型排名更重要。

4.1 模型采样：开源生态的横截面

评测 18 个开源模型，核心目的是覆盖不同系列、不同规模、不同训练策略的模型。常见的选择维度包括：

模型系列：既要有通用大厂系列，比如 Llama、Qwen、Mistral、DeepSeek、Gemma 等，也要有社区微调模型。
参数规模：从 7B 到 70B 以上都应有样本，因为规模会影响知识容量和推理能力。
开源许可：不同许可下模型的训练数据披露程度不同。选择完全可复现、权重可下载的权重版本，才能保证评测过程公开可审计。
训练语言占比：要特别纳入中文占比高和英文占比高的模型，这样才能看出文化覆盖差异是来自于架构，还是来自于语料。

这里的难点在于，开源模型版本迭代很快，同一个系列可能有多个 checkpoint。评测时，必须明确记录模型全名和版本号，比如 qwen2.5-7b-instruct 与 deepseek-v2.5，不能只写“Qwen”或“DeepSeek”，否则结果无法复现。

4.2 数据集设计：按文化区域和题型双重分层

一套合格的文化评测数据集，通常需要两个维度的分层。

第一个维度是文化区域。神话知识不能只测希腊和中国，还要加入北欧、埃及、印度、拉美、日本等多个文化区。如果只测几个热门文化区域，测评结果会对主流语料覆盖充分的大模型更有利，无法体现文化多样性差异。每个文化区域至少需要足够数量的题目，避免一两个特例影响整体判断。

第二个维度是题型。我在前文反复强调的两级结构在这里落地：

表征题（Recall）：考查模型是否“知道”文化事实。
解码题（Decode）：考查模型是否能“使用”文化知识完成理解、比较、隐喻迁移和推理。

这两种题型的比例要接近，最好是 1:1，否则最终准确率会被某一类题型主导。一种常见的错误是数据集里 90% 都是事实问答题，最后得出的结论只是“模型记住了多少文化名词”，而不是“模型有没有文化理解力”。

4.3 Prompt 与评估策略：对抗提示敏感性

一个必须正视的问题：大模型对 prompt 极敏感。同一个问题，换个措辞，答案可能就变了。为此，评测设计通常采用多模板策略：每个题目准备 3 到 5 个等价问法，让模型都回答一遍，只有多数模板都答对才算对。这样能降低随机波动。

同时，题目本身要避免给模型提供过多线索。例如单选题选项出现“女娲”时，模型可能因为“看到女娲就联想到补天”而直接蒙对，这属于表面匹配，不是真正的文化知识激活。因此在 dcode 题中，最好把真正的文化知识隐藏在推理链条里，让模型不做出这一步推理就无法选对。

评分方式通常有两种：一是人工打分，适合开放题；二是自动比对选项，适合选择题。自动比对快速，但容易受格式问题干扰；人工打分准确，但成本高。两者结合的方案是：先用自动方式过滤肯定正确和肯定错误的，再让人工判断有争议的样本。

4.4 统计口径：别让几个百分点骗了你

最后是统计问题。文化评测的样本量不可能是几十万，通常每个文化区域几十到上百题，整体几百题。这时两个模型之间差 3% 到 5%，可能根本没有统计显著性。一个负责任的结果输出，至少要包含三样东西：

分文化区域、分题型的准确率，而不是一个总平均分。
样本量。
如果可能，给出置信区间或显著性检验信息。

很多人在论文里看到“A 模型比 B 模型高 2%”，就认为 A 模型文化能力更强，这是过度解读。正确的做法是看统计误差范围，以及高分成是否集中在某一类题型上。如果 A 比 B 高出的部分几乎全部来自 recall 题，而 decode 题两者打平，那说明 A 的优势只是“文化记忆更多”，不是“文化理解更强”。

5. 自己动手：搭建一个最小文化评测集

理解了上面的方法论，就可以自己做一个最小验证。目标不是复刻论文，而是用二三十道题，快速判断一个本地开源模型是否存在“表征强、解码弱”的问题。

首先设计评测数据。我建议用 JSON 文件管理题目，每个字段清晰标注文化区域、题型、选项和答案。

[ { "id": "cn_nvwa_decode_001", "culture": "chinese", "type": "decode", "question": "今天有人用“女娲补天”来形容某个团队修复了一个严重事故。这种说法强调的是团队的什么特点？", "options": [ "A. 善于制造新问题", "B. 能处理重大危机并恢复秩序", "C. 喜欢发明新工具", "D. 严格遵循传统流程" ], "answer": "B" }, { "id": "gr_prometheus_recall_001", "culture": "greek", "type": "recall", "question": "在希腊神话中，普罗米修斯因什么原因被宙斯惩罚？", "options": [ "A. 偷走火种送给人类", "B. 建造了方舟", "C. 杀死了美杜莎", "D. 打开了潘多拉魔盒" ], "answer": "A" }, { "id": "gr_prometheus_decode_001", "culture": "greek", "type": "decode", "question": "在当代语境中，“普罗米修斯式的盗火者”最适合用来形容下面哪一类人？", "options": [ "A. 为大众引入新知识而承担风险的人", "B. 在暗处偷窃财物的小偷", "C. 为君主保守秘密的谋士", "D. 掌管火种的消防人员" ], "answer": "A" }, { "id": "jp_izanagi_recall_001", "culture": "japanese", "type": "recall", "question": "在日本神话中，伊邪那岐从黄泉返回后，为了清除污秽，进行了什么行为？", "options": [ "A. 沐浴净身", "B. 献上祭品", "C. 建造神殿", "D. 饮酒祈福" ], "answer": "A" } ]

这个示例只有四道题，实际使用时要扩成几十道。题目类型要覆盖至少三个文化区域，每个文化区域同时有 recall 和 decode 两种题型，比例保持均衡。

思考题目的设计原则时，要特别注意：**decode 题的答案不能直接从题面文本中抄出来，必须经过一步语义转换。**例如“女娲补天”这题，如果选项直接出现“补天”两个字，模型可能靠字面匹配就答对了，这不是真正测试“解码”。上面的示例已经规避了这个问题：答案“能处理重大危机并恢复秩序”是对神话故事的抽象转述，需要模型理解隐喻关系。

如果你不确定某道题的答案是否可靠，最有效的验证方法是请至少两位熟悉该文化的人独立作答。不能只拿“网上常见的解释”当标准答案，因为神话存在多版本，不同地域的解读可能有差异。

6. 评测脚本实现：调用本地模型并计算双层准确率

题目准备好之后，需要写一个评测脚本。这里我采用 OpenAI 兼容接口来调用本地部署的开源模型。现在主流的本地推理框架，比如 vLLM、Ollama、LM Studio，绝大多数都支持 OpenAI 兼容的/v1/chat/completions接口，所以这套脚本可以直接复用。

先安装必要的依赖：

pip install openai

然后创建评测脚本evaluate_culture.py。脚本的逻辑分为三步：读取 JSON 题目，逐题调用模型接口，按题型统计准确率。

import json import re from openai import OpenAI # 根据本地推理框架修改 base_url # vLLM 默认：http://localhost:8000/v1 # Ollama OpenAI 兼容端点：http://localhost:11434/v1 client = OpenAI( api_key="EMPTY", # 本地服务通常不需要真实密钥 base_url="http://localhost:8000/v1" ) SYSTEM_PROMPT = ( "你正在参与一个文化知识测试。请从 A、B、C、D 中选择唯一正确的答案。" "只输出选项字母，例如：A。不要输出多余解释。" ) def build_prompt(item): options_text = "\n".join(item["options"]) return f"{item['question']}\n{options_text}" def ask_model(prompt, model, temperature=0.0, max_tokens=32): resp = client.chat.completions.create( model=model, messages=[ {"role": "system", "content": SYSTEM_PROMPT}, {"role": "user", "content": prompt} ], temperature=temperature, max_tokens=max_tokens, ) return resp.choices[0].message.content.strip() def extract_choice(text): match = re.search(r"([A-D])", text) if match: return match.group(1) return None def evaluate(dataset_path, model): with open(dataset_path, "r", encoding="utf-8") as f: dataset = json.load(f) stats = { "recall_right": 0, "recall_total": 0, "decode_right": 0, "decode_total": 0, } for item in dataset: prompt = build_prompt(item) output = ask_model(prompt, model) pred = extract_choice(output) is_correct = pred == item["answer"] if item["type"] == "recall": stats["recall_total"] += 1 if is_correct: stats["recall_right"] += 1 elif item["type"] == "decode": stats["decode_total"] += 1 if is_correct: stats["decode_right"] += 1 print(f"{item['id']} | {item['type']:6s} | pred={pred} | answer={item['answer']} | ok={is_correct}") recall_acc = stats["recall_right"] / stats["recall_total"] if stats["recall_total"] else 0 decode_acc = stats["decode_right"] / stats["decode_total"] if stats["decode_total"] else 0 return { "model": model, "recall_acc": round(recall_acc, 4), "decode_acc": round(decode_acc, 4), "gap": round(recall_acc - decode_acc, 4), } if __name__ == "__main__": # 示例：python evaluate_culture.py myth_dataset.json qwen2.5-7b-instruct import sys dataset_path = sys.argv[1] model = sys.argv[2] result = evaluate(dataset_path, model) print() print(json.dumps(result, ensure_ascii=False, indent=2))

脚本有几个关键设计，值得说明。

第一，系统提示词明确要求只输出选项字母。这大幅降低了回答解析的难度。如果不加这一句，模型经常会输出“我的答案是：A，因为普罗米修斯……”，解析逻辑就会变得复杂。

第二，temperature固定为 0。文化评测只要标准答案，不需要创造性输出。温度越高，模型的输出越随机，评测结果会受随机采样影响。必须固定为 0，才能保证结果可复现。

第三，max_tokens设置为 32。既然要求只输出选项字母，就不需要模型生成大段解释，限制长度可以节省推理时间。这里需要注意，某些模型即使提示要求只输出字母，仍然会输出几句话，所以后面的extract_choice用正则提取第一个 A-D 字母作为预测结果。

如果你用的是 Ollama，启动一个模型的 OpenAI 兼容接口并不复杂。先在本地启动服务：

ollama serve

然后拉取一个模型，例如：

ollama pull qwen2.5:7b

接着把脚本中的base_url改为http://localhost:11434/v1，并把模型名改成你已经拉取的模型名，比如qwen2.5:7b。Ollama 的 OpenAI 兼容端点也是/v1，但需要注意，不同版本 Ollama 的接口参数解析略有差异。如果遇到模型名不识别，可以显式在create参数中增加extra_body={"raw": False}，不过大多数场景不需要。

如果你使用的是 vLLM，启动服务的命令大致如下：

python -m vllm.entrypoints.openai.api_server \ --model /path/to/your/model \ --served-model-name qwen2.5-7b-instruct \ --port 8000

这种方式的稳定性更高，OpenAI 兼容接口的完整度高，适合一次评测多个模型时使用。

7. 运行结果与效果验证

运行脚本前，建议准备两个模型：一个偏向英文语料的模型和一个偏向中文语料的模型。没有偏向也可以，用同一个模型跑多个不同文化区域的题目，观察不同文化区之间的准确率差异。

运行命令：

python evaluate_culture.py myth_dataset.json qwen2.5:7b

预期会看到类似下面的逐题输出，以及最终的统计结果。这里标注一下，下面的结果是用于说明输出格式的示意数据，不代表任何模型的真实得分。

cn_nvwa_decode_001 | decode | pred=B | answer=B | ok=True gr_prometheus_recall_001 | recall | pred=A | answer=A | ok=True gr_prometheus_decode_001 | decode | pred=A | answer=A | ok=True jp_izanagi_recall_001 | recall | pred=C | answer=A | ok=False { "model": "qwen2.5:7b", "recall_acc": 0.75, "decode_acc": 0.5, "gap": 0.25 }

如何判断评测是否成功？从三个层面看。

**第一层是脚本本身是否正常。**只要所有题目都输出了ok=True或ok=False，没有中途报错，脚本就基本正常。如果大量题目输出pred=None，说明模型没有按提示输出 A-D 字母，需要检查系统提示词是否生效，或者max_tokens是否太短。

**第二层是结果是否符合“代表性知识”预期。**一般来说，模型对主流文化区域的 recall 题正确率会明显高于 decode 题正确率。如果某个模型连 recall 题都非常低，说明该模型的训练语料对这个文化区域覆盖严重不足，这可能影响实际产品中处理相关文本的能力。

第三层是关键：看 gap 值。gap = recall_acc - decode_acc。这个差值衡量的是“文化记忆”和“文化使用”之间的断层。

recall_acc高、decode_acc低、gap大：这是研究标题所说的典型现象。模型记住了文化知识，但无法把它们用起来。
两者都低：模型对这些文化知识整体覆盖不足。
两者都高：模型的文化能力比较扎实。
gap为负（decode 反而比 recall 高）：这在小样本下往往只是波动，不必过度解读；如果样本充足仍然如此，则说明模型可能在推理任务上碰巧见过相似题目，需要重新审视题目设计。

关于准确率的置信度，必须提醒一句：**只有几十道题的评测结果，不适合用来做严格的模型排名。**它更适合做快速诊断。如果你想得到可发布的结论，每个文化区域至少要准备 50 到 100 道题，并且用多套 prompt 模板重复测试。一个更严谨的评判口径是：每道题换 3 种问法，3 次里答对 2 次以上才算该题通过。脚本当前实现是单次测试，适合快速摸底；如果你要做正式评测，建议在循环里加入多模板逻辑。

8. 常见问题与排查思路

实际跑评测时，遇到问题最多的往往不是模型能力本身，而是脚本和服务配置。下面是我觉得最值得关注的几个问题。

问题现象	可能原因	排查方式	解决方案
脚本报错`Connection error`	`base_url`写错，或本地推理服务未启动	用 curl 检查接口是否可访问	确认服务端口，修正`base_url`后再运行
大量题目的`pred=None`	模型没有按提示只输出选项字母，输出了整句解释	查看原始输出日志	在系统提示中加入“只输出字母”，或把`extract_choice`改为双字母检查
模型答错但输出看起来有道理	模型用不同文化版本作答，与标准答案存在版本偏差	检查答案是否符合该文化主流说法	请母语者或文化专家复核题目答案，必要时删除争议题
同一模型不同次运行结果不同	采样温度不是 0，或推理框架做随机采样	检查请求参数	固定`temperature=0`，关闭`top_p`随机
换一种问法结果差别很大	模型对 prompt 敏感，或题目本身有语意歧义	对比多个模板的输出	采用多模板投票机制，多数一致才计入正确
中文模型英文文化题答得很好，中文文化题一般	模型训练时中文神话语料不足，或评测题目偏文言/生僻	检查题目难度，确认是否为常见文化知识	先降低题目难度，再逐步增加难题，分析能力边界
准确率波动很大，几十题都不稳定	样本量太少	按题型单独统计，观察置信度	扩充题目数量，至少每个文化区域 50 题以上

这里我想额外展开一个容易踩的坑：模型“答对了”不代表它理解了。如果你的单选题选项里有比较强的关键词提示，模型的正确率会虚高。比如你问“谁补天”，选项里有“女娲”，模型可能只是在选项之间做词向量关联，而不是通过文化知识推理。要识别这种虚假正确，有效方法是做消融测试：把正确答案从选项中移除，看模型是否还能答对。如果移除后模型选择出现明显偏移，说明它是靠选项提示作答，不是真正掌握知识。

另一个常见问题隐藏在解码题里：解码题本身可能变成记忆题。如果网络上已经有大量“女娲补天比喻修复严重问题”的讨论文本，模型不需要真正理解隐喻，也能从表面共现关系猜出答案。要降低这种风险，可以自己构造一些不常见的全新类比，让模型把神话结构迁移到新场景。比如：“如果一个创业者说自己的公司正在经历‘精卫填海式的推进’，他想表达什么？”这类问题在网上很少出现，模型无法靠背题库回答，只能靠真正的文化解码能力。

9. 最佳实践与工程建议

有了脚本和评测集，最后要谈的是怎么把它用在真实工程里，并保证结果可信。

9.1 评测集要与训练集隔离

如果你准备用这份评测集来做模型选型，或者作为微调前的基线测试，那么最重要的原则是：评测集永远不要进入训练集。很多人会顺手把评测数据加入微调数据，最后微调完再拿同一份数据评测，得到“效果大幅提升”的虚假结论。这就是典型的数据污染。评测集应当像考卷一样被保护起来，只在打分期打开。

9.2 固定评测配置并记录环境

一次可复现的评测，至少要记录以下信息：模型完整名称和版本、推理框架名称和版本、base_url、temperature和top_p、prompt 模板版本、评测日期。如果评测隔了一个月，模型更新了一个小版本，结果就不能直接和旧结果对比。记录环境不是形式主义，而是为了以后能回答“这个结论是在什么条件下得出的”。

9.3 分文化区域报告，不要只看总平均分

一个模型可能对中文文化 decode 能力很强，但对拉美文化完全陌生。这时如果只报一个总平均分，信息会被掩盖。报告建议拆成两部分：

分文化区域的 recall 和 decode 准确率表格。
所有模型的“gap”排序。

这样既能看出模型覆盖面，也能看出模型的“知识使用效率”。对选型来说，面向哪个市场的产品，就要重点看对应文化区域的表现。

9.4 多视角人工审核题目

文化评测最大的安全隐患，是评测设计者本身的文化盲区。设计题目时容易用自己熟悉的文化作为标准，从而把模型对另一种文化合理解释判为错误。因此，扩展评测集时，至少请一位熟悉该文化的人参与出题和审题。如果项目预算有限，可以用语言区和文化区双重校验：同一个文化区域至少两个人独立审核。

9.5 文化评测不等于政治立场评测

这也是一个需要特别强调的边界。文化知识评测关注的是模型是否理解文化符号、神话典故、历史记忆、社会习俗，用来判断训练语料覆盖和语义理解能力。它不应该被扩展到政治立场或意识形态的判断。在实际工程中，这两类评测要严格分开：前者是能力评估，后者涉及价值观和安全策略，评测目标、方法和衡量标准完全不同。混在一份报告里，不仅学术上不严谨，还可能带来误导。

9.6 把评测嵌入选型流程

最后，文化评测不应该是一次性的“表演”，而应该成为模型选型的固定环节。当团队准备引入一个新的开源模型时，可以把它加入自动化评测流水线，和代码能力、数学能力、指令跟随能力一起跑。这样一来，任何一次版本升级如果导致文化理解能力下降，都能在 CI 阶段被发现。对于面向真实用户的产品而言，文化能力的回退和代码能力的回退一样严重，甚至更隐蔽。