开源 LLM 这两年迭代速度很快但有一个现象特别值得注意模型能说出“夸父追日”“俄耳甫斯下冥府”这类神话名词也能在常识问答里给你一段看似合理的解释可一旦你追问神话背后的文化逻辑、禁忌、象征、伦理它往往就开始混搭、夹层、一本正经地圆场。这种“能说出来但用不对”的状态其实对应一个判断文化意识在开源大模型里可能是被表示出来的却未必能被解码成正确的输出。最近我留意到一个研究式的项目标题Tracing Mythological Knowledge across 18 Open-Source LLMs副标题写的是“Cultural Awareness is Represented but Not Decoded”。这句话很短却点中一个很容易被忽略的问题在我们评估开源大模型时“模型内部有没有文化知识”和“模型能不能把文化知识用对”是两件完全不同的事。1. 一个反直觉的现象模型“知道”神话却不一定能回答好神话问题1.1 从“能说出名字”到“能理解文化逻辑”之间隔着什么当我们在做一个文化知识问答时常见的判断标准是模型能不能给出正确的人名、事件、地点。比如问“洛基是谁”模型如果能说出“北欧神话中的诡计之神”很多评测就会把它记为正确。但文化意识显然不止于此。真正有文化意识的回答需要处理上下文、立场、价值观、叙事方式甚至禁忌。同样一个问题“祝融是火神”可以被任何一个抓取过百科数据的模型说出来但如果问“祝融在楚文化里的地位为什么和北方水火神叙事不完全一样”这就不是简单的知识检索能解决的。它需要模型理解神话在不同文化体系里承担的功能并在生成时选择合适的话语框架。这里最容易被低估的是“话语框架”。一个从英文语料里学到“water deity”说法的模型很容易在中文神话问题上输出西方式的“神系管理”结构谁掌管什么、家庭关系、善恶阵营。中文神话里不一定按这套逻辑组织。于是模型看起来“知道”祝融但回答的文化味不对。更麻烦的是这种错误在短答案评测里往往看不出来。如果你只问“祝融是干什么的”模型答“火神”就能得分。但只要进一步问“为什么在一些民间叙事里祝融和颛顼的关系不是简单的上下级”模型可能就会开始合理化把不同体系里的零碎信息拼成一个表面通顺但内核混乱的解释。这不是记错了一个事实而是没有解码出神话背后的文化逻辑。1.2 “表示”和“解码”是两套能力所以把标题拆开看重点不是“模型是否记住了神话知识”而是“这些知识被存放在模型内部之后能不能被正确调用”。“被表示”的意思是模型在预训练阶段可能已经通过大量文本把神话人物、事件、关联压缩进参数里。你从中间层的隐藏状态里探测往往能找到这些概念的痕迹。甚至可以用简单的线性探针从某一层向量里预测“这是在讲哪个神话体系”准确率可能还不低。“被解码”是另一回事。生成回答时模型要从内部表示出发按词表的概率分布逐词生成。只要分布里的干扰项足够多或者目标语言和文化语境下的表达方式没有被充分对齐内部知识就会被“压住”最终输出一个大概相关但不准确、不连贯、不一致的答案。这就是“represented but not decoded”。我一般不会用“模型没文化”来概括这类现象更准确的说法是它知道得比说出来的多至少内部表示可能保留了更多信息。另一个常见误区是把“答错”等同于“没学过”。很多模型在神话问题上的一本正经胡说是解码环节出了问题而不是知识完全没有进入参数。你可以尝试在提示词里显式写“请从楚文化视角回答”有些模型马上会给出更贴合文化的答案说明相关知识其实是存在的只是默认解码路径没有走到那里。2. 为什么选“18个开源LLM”和“神话知识”作为研究切口2.1 开源模型为什么比闭源API更适合做内部追踪研究没有选择直接调用闭源API而是选择了18个开源LLM这个设计背后有很实际的原因。要追踪知识不能只看最终输出还要看模型内部的隐藏层状态。开源模型允许你导出每一层的向量也允许你去修改推理过程、加探针、看注意力分布。闭源API通常只给你一段文本有些连 logprobs 都不开放更不用说中间层。所以“追踪”这个词本身就要求可解释性。一个模型再强如果只能输入输出就很难回答“知识被存储在哪一层”“为什么某个问题会答错”。开源LLM提供的可访问性让这类研究成为可能。当然这不等于说闭源模型没有文化意识只是它们处于一个“黑盒”状态无法用同样的方式去拆解。因此研究的结论更多是描述开源模型阵营的情况而不应该直接外推到所有大模型。2.2 神话知识为什么适合当文化意识的试金石神话知识几乎是文化意识评测的天然样本。原因有三点。第一它有相对稳定的实体。各国神话的人物、地名、事件是有限的可以建测试集也能对答案进行比对。第二它有深厚的文化语境。同一个“洪水叙事”在不同文化里会指向不同的世界观和伦理比如“诺亚方舟”和“大禹治水”不能用同一套解释模板去讲。这种多元性正好测试模型是不是只会搬运单一模板。第三它跨越了“事实”和“价值观”的边界。神话不同于物理常识不能只靠对错判断还要理解它在特定文化中的位置。比如“灶神”在中国民间的位置与希腊神话里的“炉灶女神赫斯提亚”并不一样虽然功能上有某种相似性。用这些样本去测模型能看到它在多大程度上只是“提取共名”而不是“理解文化差异”。神话还有一个特殊优势它可以设计比较题。比如问“阿喀琉斯和哪吒都有某种反叛性但他们反叛的对象和后果是否相同”这类问题能直接逼着模型在多个文化坐标系之间切换。一个只记住百科条目的模型很难给出有层次的回答。2.3 具体怎么“追踪”神话知识很多人以为“追踪”就是跑一批问答然后算准确率。真正的追踪还要回答三个更细的问题这些知识存在模型的哪些层以什么形式存在激活哪些路径能让它被更好地解码。一个典型流程是让模型回答一组神话问题同时保存每一层的隐藏状态然后训练一个探针分类器判断某一层的向量能否预测出正确答案再对比答对和答错样本的层间差异找到知识被“卡住”的位置。这就是标题里“tracing”的意思。也可以使用 logit lens 或类似方法把每一层隐藏状态映射到词表概率观察模型在哪一层开始“倾向于说出正确答案”。如果这个倾向出现在很深的层但最终输出层被别的模式覆盖就能说明“表示”和“解码”的不一致。3. 为什么内部有知识却常常解不出来3.1 预训练目标是“续写”不是“按需检索”关键原因要从训练目标说起。开源LLM大多基于自回归语言模型预训练的目标是“根据前文预测下一个词”。这意味着模型优化的是文本序列的连贯性而不是“从知识库中检索正确事实”的能力。大量神话知识确实会被压缩进参数但参数在某一层向量里的分布是围绕“文本接续”形成的不是围绕“知识本体”形成的。所以模型内部有某种表示不等于它建立了稳定的“知识-语言-文化”映射。当问题以不同方式提出来时可能激活的是不同的参数路径。于是会出现同一个模型换一种问法答案就从准确变成胡编。3.2 中层存储、表层解码知识可能被“埋”在中间层从已有的可解释性经验和常见观测来看知识通常不会均匀地分布在所有层。有的层偏向语法和局部语义中间或深层承担更抽象的知识整合最后几层则负责把信息映射到输出词汇。当知识被存储在某个中间层而生成层的注意力又被其他高频模式占据时知识就无法顺利传到输出端。你可以做一个简单实验用 logit lens 看第 N 层模型内部已经“想”到正确答案但最终输出的第一个 token 却走了另一个方向后面只能顺着错误方向把整个答案“圆”回来。这种断层就是“represented but not decoded”的直观表现。这里也和模型大小有关。更大的模型通常有更多参数来容纳知识但解码能力并不一定同步增强。某些中等规模模型可能在最终输出上显得“文化感更弱”但中间层表示却已经相当丰富。如果只看输出你会低估它如果结合内部表示看你会发现问题更多出在解码侧。3.3 提示语言、文化语境和轻微扰动都会改变解码路径还有一个容易忽略的变量提示方式。用中文提问和用英文提问模型使用的内部路径可能不同。神话知识往往带有强烈的文化语言背景如果提示词里缺少文化语境标记模型容易激活一个“默认文化框架”通常是训练语料里占比最高的那套文化叙事。所以评估神话知识时不能只写“介绍某某神话人物”。要在问题里明确文化范围例如“在古希腊神话语境中”“按楚地祭祀传统”。否则模型内部可能把北欧、希腊、中国、印度神话混在一起抽取一些跨神话的“最大公约数”。这会让评测出现两种结果表面准确率还行但深度追问时混乱或者表面准确率很低但加一个上下文框架后显著提升。后者恰恰说明知识被表示出来了只是缺少解码线索。一个很实用的判断方法如果模型在“无文化标记的提问”下答得混乱但在“显式文化标记的提问”下明显更准确那大概率不是知识缺失而是解码引导不足。4. 如果你也想复现这类评估可以按这个流程做4.1 第一步界定文化知识边界避免“神话大杂烩”先别急着选模型。第一步是定义测试范围。神话知识不是一个统一体可以从三个维度拆分区域/文化体系中国神话、希腊罗马神话、北欧神话、埃及神话、印度神话、美洲原住民神话等。知识类型人物、事件、象征、禁忌、族谱、地理、仪式、价值观。认知层级直接识别、概念解释、文化比较、场景应用、反事实推理。例如“洛基是谁”是直接识别“洛基和奥丁的关系反映了北欧神话的哪类伦理”是概念解释“把洛基放进希腊神话语境他更接近谁”是文化比较。测试集里应该覆盖这些层级否则只能测到“模型是否记住百科”测不到“文化意识”。另一个建议是给每个问题都标注来源和可能答案的边界。神话在不同典籍里存在不同版本这是正常现象。不要用单一“标准答案”去卡模型而应该记录模型在多个版本之间是否具备区分能力。4.2 第二步建一个能区分“背答案”和“真理解”的测试集很多现成评估集已经把问答做成选择题但选择题容易让模型“蒙对”。要区分背答案和真理解我会加四类题事实一致型连续追问同一神话事件的不同侧面看前后是否一致。反事实型改变一个关键前提例如“如果大禹没有治水成功夏朝可能怎么发展”看模型是否还能围绕该文化的逻辑作答。文化比较型要求模型对两个同功能但不同文化逻辑的神话进行对比。语境切换型同一个问题分别用中文、英文、以及“按该文化内部视角”来问观察答案稳定性。这四类题不需要太多但质量比数量重要。30 到 50 道精心设计的题往往比几百道“百科式问答”更能反映文化意识。4.3 第三步跑通最小评估流程环境准备上常见做法是用 Hugging Face Transformers 加载模型开启 output_hidden_states先用一个提示词做单条验证。下面是一个示例结构具体版本和路径要按你的环境调整。from transformers import AutoModelForCausalLM, AutoTokenizer import torch model_name your-local/open-llm tokenizer AutoTokenizer.from_pretrained(model_name) model AutoModelForCausalLM.from_pretrained( model_name, torch_dtypetorch.float16, device_mapauto, output_hidden_statesTrue, ) prompt 请用中文介绍大禹治水重点说明这个叙事在中国文化里的位置。 inputs tokenizer(prompt, return_tensorspt).to(model.device) with torch.no_grad(): outputs model(**inputs, output_hidden_statesTrue) hidden_states outputs.hidden_states # tuple of tensors print(layer count:, len(hidden_states)) print(last layer shape:, hidden_states[-1].shape)先不要批量跑。确认三件事模型能正常加载tokenizer 不会截断掉关键内容hidden_states 能拿到每一层输出。再跑单条问答观察模型回答和隐藏层状态是否正常。从工程经验看这一步最容易踩的坑是显存不足和版本兼容。可以先从 7B 左右的量化版开始确认流程没问题再去跑更大模型。4.4 第四步用分层探测和激活追踪定位“知识卡点”如果要复现“被表示但未解码”的现象建议做两类分析。第一类是“线性探针”。把每一层最后一个 token 的隐藏状态取出来训练一个分类器来预测“这个问题属于哪个神话体系”或“正确答案是哪一项”。随着层数加深分类准确率通常会先升后降。如果知识点对应的准确率在中间层很高但最后输出时失败说明知识被表示在中间层但没有被解码出来。第二类是“logit lens”。把每一层隐藏状态乘以模型的输出嵌入矩阵映射到词表空间查看模型在这一层“内部最想生成的下一个 token”。逐层看下来你能看到模型是在哪一步偏离正确方向的。这两类分析都很吃资源建议先用小模型跑通再上大模型。如果只是想做粗略验证只保存最后几层的隐藏状态就行不一定要保存完整中间层可以大幅减少显存和磁盘占用。4.5 第五步批量评估、统计口径和常见坑批量评估时要控制好随机性和上下文。参数或环节常见问题建议采样参数temperature 过高导致答案飘第一批用 greedy / temperature0输入长度神话故事太长被截断检查 tokenizer 的 max_length分段提问输出长度答案在关键处被 max_new_tokens 截断优先设置 512 以上后续按需调整随机种子结果不稳定无法复现固定 seed并在记录中写明批量并发显存溢出或 GPU 崩溃从小 batch 开始使用 stream 输出评分方式人工评分和裁判模型可能不一致先抽 20% 做一致性检验再全量评估统计口径建议分成三组直接回答准确率、深度追问一致性、文化比较合理性。这三组不要加权成一个总分分开呈现更能看清楚问题。如果直接准确率不错但深度追问一致性很低那正好说明模型处于“表示但不解码”的状态。常见坑还包括回答里出现了其他文化的神话人物但模型没有意识到同一个神话在不同版本里冲突模型却坚持一个版本提示词里的文化标记一旦移除准确率大幅下降。如果遇到这些不要急着给模型下结论先跑一遍上面说的分层探测看看问题出在知识存储还是解码环节。5. 这项研究真正想提醒我们的事5.1 别把“能生成”当成“能理解”很多评测只关心最终文本。模型能流利生成一段关于神话的解释很容易给人“这个模型有文化素养”的错觉。但内部表示和解码能力的差异提醒我们流畅生成可能只是语言模型学会了“像文化话语”的形式而不是真的在按文化逻辑做推理。这不是说开源模型没有文化能力而是说我们需要更谨慎地选择评估方式。要测文化意识至少要加入跨题一致性、反事实和语境切换不能只靠百科式问答。5.2 文化适配不仅发生在训练端也发生在解码端如果知识已经被表示出来问题出在解码那改进思路就不只有“继续增大训练语料”。常见路径还包括在提示词中显式给出文化框架对关键文化实体做知识增强或外部检索用偏好对齐或风格对齐强化模型在生成时选择正确话语框架在解码时干预高概率分布降低对“默认文化框架”的倾向。这些属于“解码侧”工作。一个模型如果已经在大规模语料里见过海量神话文本它缺少的可能不是知识而是把知识调动出来的条件。这个区别决定了投入方向是重训模型还是做推理时增强。5.3 对普通开发者和研究者三句话建议如果你想基于开源模型做一个文化敏感类产品我的建议可以压缩成三句话。第一先评估再决定是否调模型。不要因为一次问答表现差就重新训练。第二评估时不要只看一个指标要同时看直接准确率、一致性、反事实能力。这三个维度能分开模型是“记住了”还是“理解了”。第三当模型答错时先做内部追踪再做模型替换。用分层探测或 logit lens 快速判断问题出在知识层还是解码层可以省下大量调参时间。当然也要承认边界。围绕 18 个模型的中文语境和神话知识评估并不能代表所有开源模型在所有文化领域的表现。模型版本、评测提示、语言都会影响结论。但这不影响“表示与解码分离”作为一个观察角度因为它能帮助我们理解一次回答背后发生了什么。甚至可以说神话知识只是文化意识的一个探测窗口。真正重要的不是模型能不能背出神话故事而是它能不能在不同的文化坐标系里选择正确的表达方式。这个问题开源模型的“可追踪性”给了我们比闭源系统更好的研究条件。