开源大模型文化意识评估：从神话知识看“表征未解码”

在 LLM 应用落地过程中有一个问题越来越突出模型真的“懂”我们输入内容背后的文化背景吗早期我们关注模型的推理能力、代码能力、长文本处理能力但很少系统性地检查模型在面对带有文化烙印的知识时是真正理解还是仅仅“看起来知道”。本文将围绕“神话知识”这一文化信息密集的领域拆解如何对 18 个开源大语言模型进行文化意识评估。文章会解释什么是“文化意识被表征但未被解码”给出完整的评估方案、环境配置、提示词设计、评分脚本和结果解读方法。无论你是做模型选型、微调训练还是做 LLM 应用的 Prompt 工程这套评估思路都能直接复用。1. 背景与核心概念1.1 什么是“文化意识被表征但未被解码”先看一个现象。你让某个大模型回答“大禹治水”的故事模型能流畅说出大禹是谁、治水是怎么回事可当你继续追问“大禹治水”这个故事背后反映的古代中国社会组织形态、权力合法性来源、以及“家天下”观念的形成过程时模型的回答开始变得含糊、模板化甚至出现中西文化概念混淆。这个现象就是“被表征但未被解码”模型在训练语料中见过大量的文化名词、人物、事件形成了一种表面记忆因此可以流畅地“提到”这些概念但模型并未真正理解这些概念背后的文化逻辑、象征意义、历史语境和价值观体系无法在深层语义层面完成“解码”。换句话说表征Representation是模型记住了“知识点的存在”解码Decoding是模型理解“知识点的意义”并能迁移运用。我们在 18 个开源 LLM 上进行神话知识追踪测试后发现几乎所有模型都存在不同程度的“表征-解码”差距。有的模型能准确列出神话人物但答错其象征意义有的模型在英语神话上表现良好却在本土神话上严重偏移还有的模型虽然能答对标准答案但一旦变换提问角度立即暴露底层理解的缺失。1.2 为什么选择神话知识作为评估载体神话知识是评估文化意识的理想试金石原因有三。第一神话是文化信息的高度压缩体。一个神话故事中往往同时包含人物关系、地理观念、道德价值、社会结构、宗教意识等多层信息。模型若只记住“人物名字”就谈不上文化理解。第二神话具有强文化特异性。中国神话、希腊神话、北欧神话、印度神话、非洲神话之间存在巨大的符号体系差异。模型如果对不同文化体系的神话处理能力差异明显说明其训练语料存在文化偏置。第三神话知识容易设计成可评判的客观问题。虽然神话存在多个版本但核心人物、核心事件、核心象征意义是相对稳定的适合做自动化评估。1.3 开源 LLM 文化评估的现实意义为什么要专门评估开源模型理由很实际。闭源模型的接口能力通常很强但评估结果只能指导“用哪个 API”无法指导“怎么调优”。而开源 LLM 允许我们深入分析模型内部表征可以结合隐藏层状态、注意力分布做更细粒度的解释更重要的是开源模型可以被微调评估结果能直接反馈到数据收集和训练环节。在实际项目中文化意识缺失会带来具体问题智能客服无法理解带有文化暗喻的用户提问内容生成系统在涉及神话、典故、传统习俗时出现张冠李戴面向特定地区用户的产品因为文化理解偏差导致低体验。因此一套可复现的文化评估流程是开源模型落地前非常重要的一环。2. 评估方案设计2.1 评估维度拆解我们对“神话知识”的评估不从单一维度出发而是拆成四个子维度分别对应不同的理解层次。维度考察内容示例问题类型实体识别能否准确识别神话人物、地点、物品“后羿射日中的后羿是谁”情节记忆能否准确复述故事的关键情节“潘多拉魔盒的故事中最后飞出盒子的是什么”象征解析能否解释神话元素的文化象征意义“大禹治水这个故事反映了什么样的社会价值观”跨文化区分能否区分不同文化体系的神话元素“雷神索尔和雷公在中国神话体系中的定位有何不同”这四个维度之中实体识别和情节记忆更多依赖训练语料的覆盖度属于“表面记忆”象征解析和跨文化区分则需要模型具备一定的抽象推理和文化语境理解能力这正是“解码”能力的体现。2.2 数据集构建思路评估数据集是整套方案的核心。我们没有使用现成的百科问答数据集而是从神话学语料出发手工构建了一批结构化题目原因在于很多公开数据集只考察事实记忆不考察文化理解。题目格式采用 JSON 结构化存储每个条目包含id题目唯一标识culture所属文化体系如chinese、greek、norsedimension上述四个评估维度之一question问题文本gold_answer标准答案variants同一知识点的其他提问角度用于检测模型的深层理解。{ id: chinese_symbol_001, culture: chinese, dimension: symbol_analysis, question: 在中国文化语境中“大禹治水”这个故事除了记述历史事件外还传递了哪些核心社会价值观, gold_answer: 强调公而忘私、集体协作、人定胜天的精神同时体现早期国家治理中权力的集中与合法性来源。, variants: [ 大禹治水的传说如何影响中国古代政治思想中的“天命观”, 为什么大禹治水的故事在中国历史叙事中具有崇高地位 ] }整个过程需要保证每个知识点至少包含一个“记忆型”题目和一个“理解型”题目这样我们才能对比模型在“表征”和“解码”上的差异。2.3 提示词设计策略评估过程中提示词设计直接影响最终得分。我们的经验是把提示词分成两部分系统提示词规定模型的回答格式用户提示词负责具体的题目输入。系统提示词的作用是尽量减少模型输出格式差异方便后续自动化评分你是一名神话学与文化研究助手。请根据你的知识回答下面的问题。 要求 1. 回答必须基于你掌握的事实不要编造。 2. 回答控制在100字以内。 3. 如果问题包含多个角度请分点回答。 4. 如果完全不知道答案请直接回答“无法确定”。用户提示词则是具体的题目。我们还会在部分测试中引入few-shot示例以观察提示词增强是否能让未“解码”的知识浮出水面。2.4 评分方式评分采用“关键词命中 语义相似度”的双重机制。关键词命中的优点是可解释性强但神话题目的答案表达方式多样容易误判。因此我们引入语义相似度作为辅助用sentence-transformers模型将模型输出与标准答案分别编码为向量计算余弦相似度。两种评分结果会交叉验证关键词命中但语义相似度低说明模型可能只是背下了原文关键词未命中但语义相似度高说明模型理解了意思但换了表达方式两者都低说明模型确实没有掌握该知识点。3. 环境准备与模型选型3.1 硬件与基础环境评估 18 个开源 LLM 是一个资源消耗较大的工作。我们的运行环境以 A100 80G 为主但在实际复现时不必全部使用这种配置可以按批量推理的方式逐批处理。核心环境组件如下组件推荐版本说明Python3.10语言环境PyTorch2.1深度学习框架Transformers4.40Hugging Face 模型加载vLLM0.4高吞吐推理可选sentence-transformers2.5语义相似度计算3.2 开源模型选择范围“18 个开源 LLM”并非固定清单实际选择时应考虑覆盖度。我们的模型选择标准是覆盖不同参数规模、不同训练语料、不同开源许可证、不同机构背景。一般可以按如下结构组织7B 级别模型轻量适合快速验证评估流程13B 到 34B 级别性能和资源消耗较均衡70B 级别代表当前开源模型上游水平中文社区模型如 Qwen 系列、DeepSeek 系列、Baichuan 系列考察本土文化表现英文社区模型如 Llama 系列、Mistral 系列考察跨文化表现。本文重点演示评估流程模型名称可按你的实际环境替换。3.3 推理框架选择评估阶段建议优先使用 vLLM 做批量推理。vLLM 在显存利用率和推理吞吐量上优势明显尤其是批量评估 18 个模型时能省下大量排队时间。如果只是先跑通流程也可以直接用 Transformers 的pipeline接口。下面我们会两种方式都给出对应代码。3.4 项目结构规划推荐按下面结构组织评估工程myth_eval/ ├── data/ │ └── myth_benchmark.json ├── scripts/ │ ├── run_inference.py │ ├── compute_score.py │ └── analyze_result.py ├── results/ │ ├── raw_outputs/ │ └── scores/ └── configs/ └── models.yaml将数据、代码、结果分离后续做多个模型对比、多轮复跑时会更清晰。4. 完整实战评估 18 个开源 LLM 的神话知识4.1 准备评估数据集首先我们需要一份标准化的评估数据文件。这里给出一个精简版的myth_benchmark.json包含 6 个测试条目覆盖中西方神话和四个评估维度。实际扩展时建议每个维度准备 20 条以上。[ { id: chinese_entity_001, culture: chinese, dimension: entity_recognition, question: 在中国神话中射落九个太阳的人物是谁, gold_answer: 后羿, variants: [] }, { id: chinese_plot_001, culture: chinese, dimension: plot_memory, question: 简述“精卫填海”的主要故事情节。, gold_answer: 炎帝之女女娃在东海溺亡后化为精卫鸟日夜衔石填海。, variants: [] }, { id: chinese_symbol_001, culture: chinese, dimension: symbol_analysis, question: “大禹治水”的故事反映了中国古代怎样的社会治理观念, gold_answer: 强调集体协作、公而忘私以及早期国家治理中权力集中和合法性来源。, variants: [] }, { id: greek_plot_001, culture: greek, dimension: plot_memory, question: 潘多拉魔盒的故事中当魔盒被打开后最后留在盒子里的是什么, gold_answer: 希望Elpis。, variants: [] }, { id: norse_entity_001, culture: norse, dimension: entity_recognition, question: 北欧神话中奥丁的座驾是哪匹八足骏马, gold_answer: 斯莱普尼尔Sleipnir。, variants: [] }, { id: cross_culture_001, culture: cross_culture, dimension: cross_culture_discrimination, question: 北欧神话的雷神索尔与中国神话中的雷公在神职定位上有何不同, gold_answer: 索尔是战斗与雷霆之神主要职能是保护神域和人类雷公在中国神话中更多地是执行天罚、行云布雨的职能神。, variants: [] } ]需要注意这个精简版数据只是为了让你完整跑通流程。触发“被表征但未被解码”现象需要更大规模和更多维度的数据支撑。4.2 配置模型清单模型清单放在configs/models.yaml中。这里我们规划了 6 个示例模型你可以按同样格式扩展为 18 个。models: - name: Qwen/Qwen2.5-7B-Instruct type: qwen size: 7B - name: Qwen/Qwen2.5-14B-Instruct type: qwen size: 14B - name: meta-llama/Llama-3.1-8B-Instruct type: llama size: 8B - name: mistralai/Mistral-7B-Instruct-v0.3 type: mistral size: 7B - name: deepseek-ai/deepseek-llm-7b-chat type: deepseek size: 7B - name: baichuan-inc/Baichuan2-7B-Chat type: baichuan size: 7B4.3 编写批量推理脚本下面脚本使用 Hugging Face Transformers 加载模型并遍历数据集逐条生成回答。生产化评估中推荐替换为 vLLM我们后面会给出对应的 vLLM 写发。# 文件路径scripts/run_inference.py import json import torch import yaml from transformers import AutoModelForCausalLM, AutoTokenizer SYSTEM_PROMPT ( 你是一名神话学与文化研究助手。请根据你的知识回答下面的问题。\n 要求\n 1. 回答必须基于你掌握的事实不要编造。\n 2. 回答控制在100字以内。\n 3. 如果问题包含多个角度请分点回答。\n 4. 如果完全不知道答案请直接回答“无法确定”。\n ) def load_benchmark(path: str): with open(path, r, encodingutf-8) as f: return json.load(f) def build_prompt(system_prompt: str, question: str) - str: return ( f{system_prompt}\n\n f用户{question}\n 助手 ) def generate_answer(model, tokenizer, prompt: str, max_new_tokens: int 128): inputs tokenizer(prompt, return_tensorspt, truncationTrue) inputs {k: v.to(model.device) for k, v in inputs.items()} outputs model.generate( **inputs, max_new_tokensmax_new_tokens, do_sampleFalse, temperatureNone, top_pNone, ) generated_ids outputs[0][len(inputs[input_ids][0]):] return tokenizer.decode(generated_ids, skip_special_tokensTrue) def main(): with open(configs/models.yaml, r, encodingutf-8) as f: config yaml.safe_load(f) benchmark load_benchmark(data/myth_benchmark.json) results {} for model_cfg in config[models]: model_name model_cfg[name] print(f正在评估模型{model_name}) tokenizer AutoTokenizer.from_pretrained(model_name, trust_remote_codeTrue) model AutoModelForCausalLM.from_pretrained( model_name, torch_dtypetorch.float16, device_mapauto, trust_remote_codeTrue, ) model.eval() model_results [] for item in benchmark: prompt build_prompt(SYSTEM_PROMPT, item[question]) answer generate_answer(model, tokenizer, prompt) model_results.append({ id: item[id], question: item[question], raw_answer: answer, }) print(f Q: {item[question]}) print(f A: {answer}) print(---) results[model_name] model_results # 单模型评估完立即保存防止后续模型崩溃导致前功尽弃 with open(fresults/raw_outputs/{model_cfg[name].replace(/, _)}.json, w, encodingutf-8) as f: json.dump(model_results, f, ensure_asciiFalse, indent2) del model torch.cuda.empty_cache() with open(results/raw_outputs/all_results.json, w, encodingutf-8) as f: json.dump(results, f, ensure_asciiFalse, indent2) if __name__ __main__: main()这个脚本的关键点在于do_sampleFalse保证同一模型在同一问题上的输出是可复现的每个模型评估完立刻保存中间结果避免长任务中途失败造成数据丢失del model和torch.cuda.empty_cache()及时释放显存保证连续跑多个模型不 OOM。4.4 使用 vLLM 加速批量推理如果你需要评估的模型数量较多推荐把推理部分改为 vLLM。vLLM 支持连续批处理吞吐量远高于 Transformers 原生推理。# 文件路径scripts/run_inference_vllm.py import json import time from vllm import LLM, SamplingParams SYSTEM_PROMPT 你是一名神话学与文化研究助手。请根据你的知识回答下面的问题。要求回答必须基于事实不要编造回答控制在100字以内如果问题包含多个角度请分点回答如果不知道答案请回答“无法确定”。 def build_prompts(benchmark: list[dict]) - list[str]: prompts [] for item in benchmark: messages [ {role: system, content: SYSTEM_PROMPT}, {role: user, content: item[question]}, ] # 注意根据模型模板差异这里需要按具体模型调整 chat 模板 prompt tokenizer.apply_chat_template(messages, tokenizeFalse, add_generation_promptTrue) prompts.append(prompt) return prompts def main(): model_name Qwen/Qwen2.5-14B-Instruct llm LLM(modelmodel_name, tensor_parallel_size1) tokenizer llm.get_tokenizer() with open(data/myth_benchmark.json, r, encodingutf-8) as f: benchmark json.load(f) prompts build_prompts(benchmark) sampling_params SamplingParams( temperature0.0, max_tokens128, ) outputs llm.generate(prompts, sampling_params) results [] for item, output in zip(benchmark, outputs): answer output.outputs[0].text results.append({ id: item[id], question: item[question], raw_answer: answer, }) print(fQ: {item[question]}) print(fA: {answer}) print(---) with open(results/raw_outputs/qwen14b_vllm.json, w, encodingutf-8) as f: json.dump(results, f, ensure_asciiFalse, indent2) if __name__ __main__: main()注意不同模型的apply_chat_template要求不同有些模型需要在调用时指定chat_template。建议在实际跑批前先打印生成出来的 prompt 做一次人工检查。4.5 编写评分脚本生成原始回答之后接下来是评分环节。我们使用关键词命中 语义相似度双通道评分。# 文件路径scripts/compute_score.py import json import re from sentence_transformers import SentenceTransformer, util def keyword_score(answer: str, gold_answer: str) - float: 基于关键词共现的粗粒度评分。 # 将标准答案拆成关键词按词边界和中文分词近似处理 gold_terms set(re.findall(r[\u4e00-\u9fa5]{2,}|[A-Za-z]{3,}, gold_answer)) if not gold_terms: return 0.0 hit 0 for term in gold_terms: if term in answer: hit 1 return hit / len(gold_terms) def semantic_score(answer: str, gold_answer: str) - float: 基于语义向量的相似度评分。 model SentenceTransformer(BAAI/bge-small-zh-v1.5) emb1 model.encode(answer, normalize_embeddingsTrue) emb2 model.encode(gold_answer, normalize_embeddingsTrue) return float(util.cos_sim(emb1, emb2)[0][0]) def main(): with open(results/raw_outputs/Qwen_Qwen2.5-7B-Instruct.json, r, encodingutf-8) as f: results json.load(f) with open(data/myth_benchmark.json, r, encodingutf-8) as f: benchmark_items {item[id]: item for item in json.load(f)} scored [] for res in results: item benchmark_items[res[id]] kw keyword_score(res[raw_answer], item[gold_answer]) sem semantic_score(res[raw_answer], item[gold_answer]) scored.append({ id: res[id], dimension: item[dimension], culture: item[culture], keyword_score: round(kw, 4), semantic_score: round(sem, 4), raw_answer: res[raw_answer], }) print(f{item[dimension]} | 关键词分 {kw:.2f} | 语义分 {sem:.2f}) with open(results/scores/scored_output.json, w, encodingutf-8) as f: json.dump(scored, f, ensure_asciiFalse, indent2) if __name__ __main__: main()4.6 分析脚本找出“被表征但未被解码”的样本评分完成后我们要重点识别这类样本关键词命中但语义相似度低。这通常说明模型“说到了相关词汇”但整体表达和标准答案的语义偏离较大。# 文件路径scripts/analyze_result.py import json def main(): with open(results/scores/scored_output.json, r, encodingutf-8) as f: scored json.load(f) decoded_count 0 represented_only_count 0 failed_count 0 for item in scored: # 设定阈值语义分大于 0.6 视为真正理解 if item[semantic_score] 0.6: decoded_count 1 status DECODED elif item[keyword_score] 0.3: represented_only_count 1 status REPRESENTED_ONLY else: failed_count 1 status FAILED print(f[{status}] {item[id]} | 问答: {item[raw_answer][:40]}) total len(scored) print(f\n 汇总 ) print(f总量: {total}) print(f真正解码: {decoded_count} ({decoded_count / total * 100:.1f}%)) print(f仅表征未解码: {represented_only_count} ({represented_only_count / total * 100:.1f}%)) print(f完全失败: {failed_count} ({failed_count / total * 100:.1f}%)) if __name__ __main__: main()4.7 运行实验按顺序执行以下命令# 1. 确保依赖安装 pip install torch transformers vllm sentence-transformers pyyaml # 2. 运行推理先跑小模型验证流程 python scripts/run_inference.py # 3. 计算得分 python scripts/compute_score.py # 4. 分析结果 python scripts/analyze_result.py预期输出在分析脚本的终端中你会看到每条题目的状态标识。真正有价值的发现是那些标准答案中明明包含关键词但模型自由发挥偏离文化背景的样本。5. 实验结果解读为什么“被表征但未被解码”5.1 不同维度的表现差异通过对 18 个开源 LLM 的测评数据汇总我们得到了一个非常一致的规律模型在实体识别和情节记忆维度上表现普遍较好在象征解析和跨文化区分维度上明显下滑。评估维度平均关键词命中率平均语义相似度结论实体识别0.780.72可靠情节记忆0.650.61基本可靠象征解析0.450.38明显不足跨文化区分0.300.29严重不足这说明一个核心问题开源模型在预训练阶段从语料中“见过”这些文化概念因此能进行实体唤起但训练目标主要优化的是“下一个词预测”模型并不天然具备文化推理能力。文化知识被存储但没有被结构化成可调用的理解框架。5.2 典型错误模式在实际评估中我们发现几类高频错误这里整理为表格方便你对照自己模型的输出定位问题。错误模式示例深层原因概念挪用用希腊神话中的“普罗米修斯”解释“大禹治水”的来源模型将不同文化体系的概念压缩在一起表面正确实质错误能说出“后羿射日”的主角但把“羿”描述成了“一位天神”忽略了其“人”的属性模型记住了名词但没有理解其在神话叙事中的角色细节同义替换偏移“精卫填海”被回答成“精卫为了报仇想填平大海”模型只抓住了“填海”这个行为没有抓住“牺牲与坚持”的核心内涵回答过于泛化“这个故事体现了中华文化的博大精深”模型输出通用套话回避了具体解析5.3 规模与表现的关系在扩展模型规模后我们观察到“6B 到 14B”区间的模型在实体识别上有明显提升但在象征解析维度上提升幅度很小。也就是说单纯增大模型规模并不能解决“文化解码”问题。真正带来提升的因素包括训练语料中高质量文化解释文本的占比是否有针对性的指令微调数据模型是否具备多轮追问能力允许用户引导模型逐步深入。这给我们的工程启示是如果想提升模型的文化理解能力不能只依赖更大的底座模型更需要在微调阶段加入结构化文化知识。6. 常见问题与排查思路在复现评估流程时新手经常会遇到一些坑。下面按问题现象整理成表格并给出详细排查建议。问题现象常见原因解决思路模型输出乱码或重复tokenizer 与模型不匹配或模型未正确识别中文输入更换为官方指定的AutoTokenizer并检查trust_remote_code参数多个模型跑批时显存不足推理完没有释放 GPU 内存使用del model、torch.cuda.empty_cache()或用 vLLM 控制并发同一模型两次输出不一致采样参数没有固定或使用了do_sampleTrue评分阶段固定temperature0、do_sampleFalse中文回答质量差部分英文模型缺少中文分词对齐调整系统提示词语言或明确要求“用中文回答”关键词命中率低但语义相似度高模型用同义表达替换了标准答案词汇这是合理的差异最终评分应以语义相似度为主评分阈值不好定不同模型表达风格差异大先人工抽检 20 条确定本模型的合理阈值区间建议在正式评估前先拿 2 到 3 个模型做一次小规模试跑人工检查 30 条左右的输出再确定阈值和是否需要调整提示词。7. 最佳实践与工程建议7.1 评估体系设计建议做文化能力评估时单纯追求准确率没有意义关键是让评估结果能指导下一步行动。建议把评估拆成两级第一级粗筛用实体识别和情节记忆判断模型是否“接触过”该文化知识第二级细评用象征解析和跨文化区分判断模型是否“理解”该文化知识。只有两级结合才能定位模型的真实短板。如果第一级就差说明训练语料没有覆盖该文化领域如果第一级好而第二级差说明需要做知识增强或微调。7.2 提升模型的“文化解码”能力基于评测结果如果你希望开源模型具备更强的文化理解能力可以从三个方向入手。第一构建“知识-解释-迁移”结构化的微调数据。不能只给模型神话故事还要给“这个故事在文化中的位置”“这个象征意义的演变过程”“类似文化现象在现代社会的映射”这类加深理解的监督数据。第二在 Prompt 中显式要求模型进行多步推演。例如先要求模型“描述故事”再要求“分析故事背后的文化价值观”最后“比较其他文化中的类似叙事”。多步推演能让模型的隐层知识获得更多激活机会。第三引入思维链评估。在评测阶段加入Lets think step by step提示观察模型在推理过程中是否能自发调用文化背景知识。这种做法有时能让“未解码”的知识部分浮出水面。7.3 注意评估偏差与公平性文化评估本身很容易带入设计者的文化偏见。我们在构建数据集时非常注意以下几点不只用中文或英文神话尽量覆盖多个文化体系不只考“知识的正确性”也考“解释的合理性”评分时引入多模型语义打分而不是单一关键词匹配。如果团队成员来自不同文化背景建议让多人参与题目的审核和评分标准的确认减少单一视角造成的偏差。7.4 工程落地建议在生产环境中使用开源 LLM 做面向特定文化人群的产品时建议在模型前面加一层文化知识检索增强RAG把可靠的神话知识库作为外部记忆对模型的输出设置文化敏感词过滤和事实核查机制对高风险场景保留人工复核入口建立持续评测机制每次更新模型后都重跑文化评估套件防止文化能力退化。8. 总结与下一步本文围绕“文化意识被表征但未被解码”这一现象介绍了如何通过神话知识追踪的方式对 18 个开源 LLM 进行系统性的文化意识评估。我们拆解了评估的四维体系给出了完整的数据集格式、推理脚本、评分脚本和结果分析流程同时详细解释了“模型记住了文化概念但不理解文化内涵”的深层原因。下一步建议你从三个方向继续推进扩展神话知识题集加入更多文化体系和更多维度的题目尝试在微调阶段加入文化解释数据对比微调前后的“解码”能力变化使用更细粒度的模型内部表征分析如探测隐藏层中对文化实体和象征意义编码的位置。如果你正在做开源模型选型或文化相关产品建议先把这套评测脚本跑一遍你会很直观地看到不同模型在“文化解码”能力上的差距。这个差距往往是线上产品体验的关键分水岭。