企业官网建设流程全解析

这次我们来看一项很有意思的开源大模型评测研究，标题是《Cultural Awareness is Represented but Not Decoded: Tracing Mythological Knowledge across 18 Open-Source LLMs》。核心结论一句话就能说清楚：开源 LLM 内部其实“记得”不少神话知识，但到了生成回答的时候，却不一定能稳定、准确地把这些知识说出来。翻译成研究术语，就是“知识被表征了，但没有被解码”。

这个视角最难得的地方，是把大模型的能力拆成了两个独立问题：模型肚子里有没有货，和模型能不能把货倒出来。对于开源模型来说，这个问题尤其值得关注，因为开源模型参数可见、logits 可取、中间层可以访问，我们有机会从内部去观察知识是否存在，然后再和生成结果做对比。这比闭源 API 只能做黑盒测试要深入得多。

这篇文章会按论文阅读加工程落地的思路展开：先讲清楚“表征”和“解码”到底指什么，再拆解为什么选择神话知识作为评测载体，接着聊 18 个开源 LLM 的评测思路，最后落到对模型选型、RAG、微调和本地部署的实际影响，并给出一套可以自己动手搭建的文化知识评测方案。适合做大模型评测、多语言产品落地、开源模型选型和 RAG 应用开发的同学阅读。

1. 研究速览与研究问题

在展开细节之前，先用一张表把这项研究的轮廓列出来。

1.1 一句话理解核心结论

用不太严谨但很好懂的话说：模型像是在课本里读过这些神话故事，知识点进入了参数，但考试做题的时候，它可能写错名字、答错职能、张冠李戴，甚至直接说不知道。

这和我们通常判断一个模型“懂不懂文化”的方式不一样。传统评测往往只看生成准确率：模型回答对了，就认为它懂；回答错了，就认为它不懂。这项研究的价值在于指出中间有一个被忽略的断层：知识有没有，和能不能说出来，不是一回事。

1.2 为什么这个结论值得关注

如果这个结论成立，那常规 benchmark 给出的高分会掩盖文化能力上的短板。

举个例子：一个模型在 MMLU、GSM8K 这些通用评测上得分很高，但在面向东南亚或中东用户的文化知识问答上频繁出错。如果只看总分，你会觉得这个模型能力很强，但真正部署到当地产品里，用户一问到本地神话、节庆、习俗，模型就露馅。这种“假阳性”比“直接不行”更难排查，因为问题出在评测维度缺失，而不是模型整体太弱。

从研究角度看，把“表征”和“解码”分开，等于给文化能力评测增加了一个新的坐标轴。顺着这个坐标轴，我们能看到不同模型的差异化表现，也能更清楚地定位问题到底出在预训练语料覆盖不足，还是出在对齐阶段、生成策略或 tokenizer 上。

2. 文化意识评测为什么难：从通用基准到文化能力

开源大模型的能力评测，过去主要集中在语言建模、数学推理、代码生成、指令跟随和安全对齐这些维度。这些维度有一个共同特点：可以用相对客观的题目来打分，比如代码能不能跑通、数学题答案对不对、安全 prompt 有没有被拒绝。

文化能力不一样。它不是一个单一指标，而是一组能力的集合。至少可以拆成几个层面：

• 事实性文化知识：某个神话人物是干什么的，某个节日在什么时候，某个历史事件发生在哪里。
• 价值观与社交规范：什么话题在不同文化里是敏感的，什么表达在当地语境中算礼貌。
• 语言风格与表达习惯：相同含义在不同语言里的自然说法。
• 本地化常识：地名、人名、机构名、度量衡、货币等高频实际知识。

这项研究选择神话知识作为切入点，属于第一类“事实性文化知识”。这类知识有一个天然优势：它有相对确定的答案，可以被自动评分。比如问“孙悟空在中国神话中的身份是什么”，那是可以对照权威资料打分的。这就比“模型是否足够尊重某种文化”这种主观问题更容易做成量化实验。

神话知识还有一个特性：跨文化分布广。希腊神话、北欧神话、中国神话、印度神话、日本神话、中东神话、非洲和美洲原住民神话，每个文化体系都有自己的神话叙事。这意味着评测天然具备多文化、多语言的覆盖维度，不会只集中在英语世界。

所以，文化意识评测难，难在三点：第一，文化不是一个可计算的概念；第二，文化知识高度依赖语言和语境；第三，缺少可规模化、可自动评分的评测集。而神话知识恰好能绕过部分困难，让文化意识变成一个可以被测量、可复现的研究对象。

3. “表征”和“解码”到底指什么

这次研究的两个关键词是 represented 和 decoded。理解这两个概念，是读懂整篇文章的前提。

3.1 表征：模型内部有没有这个知识

表征指的是模型在预训练过程中，从海量文本里学到了某种知识，并把知识以参数分布、隐藏层状态、注意力模式等形式存储下来。从理论上讲，如果模型在训练语料中见过足够多关于某个神话人物的文本，它应该在内部建立相应的“记忆痕迹”。

开源模型的最大优势，就是我们可以用白盒方法去观察这种内部痕迹。常见手段包括：

• 探针法：训练一个线性分类器，从隐藏层激活值里预测某个知识属性是否成立。
• logits 分析：只让模型预测答案的第一个 token，看正确答案对应的 token 概率是不是显著更高。
• 激活编辑与消融：修改某个方向的特征，观察模型行为是否变化。

需要注意的是：内部表征存在，不等于模型能在对话中说出正确答案。表征更像是一种“潜在知识状态”，它能不能被用户感知，取决于下一步的生成能不能把它激活并正确表达出来。

3.2 解码：模型能不能把知识说出来

解码在这里不是指分词器或采样算法的单一环节，而是指模型从内部状态出发，在给定 prompt 下生成可读文本的整个过程。

这个过程会受到很多因素干扰：

• 指令理解偏差：模型可能没理解“请用中文回答关于中国神话人物的问题”这个要求。
• 语言分布不平衡：训练语料中英文占比过高，导致非英文语境下的生成路径被压制。
• 偏好对齐影响：RLHF 或 DPO 让模型倾向于输出“安全但平庸”的内容，可能回避确定性回答。
• 采样参数波动：温度过高时，模型可能从低概率区域采样，正确答案被随机抖动淹没。
• tokenizer 切分质量：非英文 token 被切碎之后，模型在生成时更难复用完整语义块。

这些因素中的任何一个，都可能导致一个“内部知道答案”的模型，在生成时给出错误回答。

3.3 二者的差距怎么衡量

衡量办法其实不复杂：同一批评测样本，分别走两条路。

第一条路是内部探测。让模型只输出答案 token 或从隐藏层读取信息，看模型“知不知道”正确答案。第二条路是正常生成。让模型在完整对话或问答任务里自由生成答案，再判断回答是否正确。

如果集群结果显示内部探测正确率明显高于生成正确率，就可以说：知识在内部被表征了，但在最终输出阶段没有被成功解码。这就是“Represented but Not Decoded”的操作化定义。

需要说明的是，内部探测本身也有争议。线性探针能否真正反映“知识”，还是只反映统计相关性，学术界还没有完全一致的意见。但即使如此，把表征和解码分开做对比，已经比只看最终生成结果要细致得多。

4. 为什么用神话知识做评测载体

选择神话知识作为评测载体，不是随便挑一个“有文化味”的领域，而是经过权衡的选择。

第一，可验证性强。神话人物、事件、象征物、亲属关系都有比较明确的内容。虽然不同版本存在差异，但核心事实是稳定的。比如天照大神是日本神话中的太阳女神，宙斯是希腊神话中的众神之王，这些是可以对答案评分的。

第二，跨文化可比性高。不同文化体系都有神话，而且结构相似度很高：创造神、太阳神、海神、冥界、英雄传说、创世故事。这意味着我们可以构造一个结构一致、内容文化多元的评测集，而不是针对单一文化的“特供题”。

第三，适合做语言维度的控制实验。同一个问题，可以分别用英文、中文、日语、印地语等语言提问。这样一来，评测就能区分“模型有没有知识”和“模型能否跨语言调用知识”。

第四，知识图谱式结构清晰。神话知识可以用实体-属性-关系三元组来表示。例如：

• 实体：孙悟空
• 属性：身份 / 所在作品
• 关系：是《西游记》中的主要角色，会七十二变

这种结构化表示利于自动生成问题、自动判断答案，也方便后续扩展为知识本体评测集。

第五，迁移价值。神话知识只是文化事实的一类代表。实际产品中，用户会问历史人物、当地节日、传统习俗、旅游景点、地方食物等大量文化事实问题。一个在前面这类问题上表现出“已表征未解码”现象的模型，大概率在后面的文化知识任务中也会出现类似问题。

5. 18 个开源 LLM 的评测范围与设计思路

具体是哪 18 个模型，需要看原文的模型清单。但从标题涉及的开源生态来看，通常会尽量覆盖不同模型族、不同参数量级、不同语言侧重。常见的开源模型家族一般包括 LLaMA 系、Mistral 系、Qwen 系、Gemma 系、DeepSeek 系等，具体名单以原文为准。

5.1 模型选择可能考虑的因素

如果是我来设计这个实验，我会从以下维度挑选模型：

• 参数量级：覆盖 7B 到 70B 以上，观察规模与文化知识容量之间的关系。
• 语言覆盖：需要包含中文、日文等多语言化程度较高的模型，也要包含英文为主的模型。
• 架构差异：Dense 模型和 MoE 模型都要有，观察架构是否影响知识解码。
• 对齐方式：是否经过 RLHF、DPO 或安全对齐，是否对齐损耗了解码准确率。
• 社区使用热度：优先选真实部署场景中常用的开源模型，结论更有工程参考价值。

5.2 评测任务设计思路

从“表征 vs 解码”这个框架出发，评测任务至少应该包含以下几组：

• 事实问答任务。给定神话实体，提问它的身份、职能、象征物、关联人物。这是最核心的评测任务。
• 多语言提问任务。同一实体的问题分别用英文和本地语言提问，观察语言切换带来的性能变化。
• 对抗性提示任务。有些 prompt 会诱导模型用西方神话类比来解释其他文化的神话，例如“孙悟空是不是中国版的赫拉克勒斯”，这种问题能测出模型是否遵循文化边界。
• 内部表征对照任务。在只输出答案 token 的条件下，检查正确 token 的概率，再和完整生成的结果对比，定位解码损失。

5.3 评测实现时需要警惕的坑

• Prompt 语言需要保持一致。如果在评测中，每个问题都先用英文再翻译成中文，翻译误差会影响结果。
• 生成参数要固定。温度、top-p、max_new_tokens 都会影响输出，必须统一设置。
• 评分标准要明确。同义改写、命名变体、文化遗产的多重认定要提前定义。
• 数据授权要规范。神话资料如果有整理者版权，需要取得使用授权，不能直接抓取商业网站内容。

6. 核心发现：知识存在但输出不稳

从标题和研究框架看，这项研究的核心发现应该可以概括成一个稳定的主线：模型在一定程度上具备跨文化神话知识的内部表征，但在生成阶段出现了系统性的解码偏差。

这意味着可能出现三类现象。

第一类，同一模型在不同语言提问下表现不一致。比如用英文问某个日本神的名字，回答正确；用日文或混合语言问同一个问题，回答错误。问题不在知识缺失，而在跨语言激活路径没有被正确触发。

第二类，不同模型之间的表现模式不同。有的模型内部知识覆盖率不低，但生成准确率偏低，说明解码环节是瓶颈；有的模型生成风格相对保守，较少编造，但遇到冷门文化实体时会直接承认不知道。前者适合做检索增强，后者更适合在开放域场景兜底。

第三类，模型存在“文化默认值”倾向。面对不属于英语主流文化的知识，模型可能倾向于用西方神话体系去类比或填充，导致回答在形式上流畅但实质错误。这种错误在自动评测里容易被判定为“有一点相关但不对”，需要人工复核。

从工程视角看，这些现象都指向同一个结论：开源模型的文化能力，不能靠单一 benchmark 分或人工印象来判断。尤其不能因为某模型在英文问答上很强，就默认它在你目标地区的文化知识上也强。

7. 对开源大模型评估的启示

这项研究对评测体系的启示，可以归纳为以下四点。

第一，评测要拆成“知识有没有”和“能不能说出来”两层。只测生成结果，会把解码问题误判成知识缺失，也会把知识充足但解码失败的模型误判成不行。对于开源模型，更合理的做法是同时输出内部探测结果和生成结果，用对比结果定位瓶颈。

第二，评测要文化多元化。目前主流基准测试更多覆盖英语世界的方法论、知识体系和表达方式。对全球用户，需要设计包含亚洲、非洲、拉美、中东等地区文化事实的子集，至少保证评测集覆盖目标用户所在区域。

第三，评测要语言对齐。文化知识评测不能只看英文结果。同一个问题应该至少设计英文版和本地语言版，观察语言切换的影响。这样能暴露文化知识在不同语言上下文中的可用性差异。

第四，评测要尽可能开放可复现。模型版本、decode 参数、prompt 模板、评分代码、数据授权信息都要公开。只有完全可复现，才能成为后续训练和选型可依赖的基准。

从落地角度看，这套评估思路对开源模型选型尤其重要。如果你在评估多个候选模型，不要只看排行榜总分，建议拆出文化子集，用目标用户的语言测试一轮，对比哪些模型是“真知道”，哪些是“看似知道但说不出来”。

8. 对模型选型与落地部署的影响

8.1 模型选型：不要只看通用分数

在开源模型选型时，通用能力分数是起点，不是终点。如果目标产品面向某个特定文化区域，需要额外准备一份“文化知识小样本集”，包含神话、历史、节庆、饮食、地名等常见问题。用这个样本集去测试候选模型，重点关注两个指标：

• 生成准确率：最终回答是不是正确。
• 内部置信度：答案 token 的概率分布是否明显偏向正确答案。

如果出现生成准确率不高但内部置信度给出的正确答案概率不低的情况，说明这个模型有知识解码问题，可以通过 RAG、提示词优化等方式补救。如果内部置信度本身就不指向正确答案，说明预训练语料覆盖不足，补救成本更高。

8.2 提示词工程：减少默认文化假设

在不能快速换模型的前提下，提示词工程是缓解解码问题的低成本手段。可以从三个方向入手：

• 明确限定文化语境。在 prompt 中写清楚“请从中国文化语境回答”，避免模型默认按西方文化视角输出。
• 禁止不当类比。要求模型不要用“相当于西方的某某”来解释本地文化实体。
• 提供 few-shot 示例。给出一个正确格式的问答示例，帮助模型激活正确的生成路径。

示例 prompt：

你是一个文化知识问答助手。请严格按用户指定的文化语境回答问题。 如果不确定，直接说“我不确定”，不要编造。 问题：孙悟空在中国神话中的身份是什么？ 回答：孙悟空是中国古典小说《西游记》中的主要角色，兼具猴精形象和取经护法职能。

8.3 RAG 增强：让模型做阅读者而不是复读机

如果模型内部有知识但解码不稳定，RAG 是性价比最高的工程方案。思路是把神话、历史、文化事实类知识放进外部检索库，回答问题时先检索相关资料，再让模型基于资料做摘要和重组。

这种方式把生成任务从“回忆内部知识”变成了“阅读理解外部文本”，大幅降低对内部知识解码的依赖。只要检索结果准确，模型即使内部“记忆模糊”也能给出正确回答。

典型的 RAG 流程是：

1. 建立文化知识文档库，分实体、地区、主题管理。
2. 用户提问后先向量检索，找 top-k 相关知识片段。
3. 把检索结果拼进完整 prompt。
4. 模型生成回答，并附上来源。

RAG 还有一个额外好处：可以在答案中带上引用来源。对于文化敏感话题，用户能看到出处，信任度更高。

8.4 微调与持续预训练

如果目标地区非常垂直，比如长期做日本或印度市场的产品，更彻底的做法是做本地文化语料的持续预训练或 SFT。通过让模型在高质量文化语料上继续学习，可以同时改善内部知识和解码路径。

不过要注意，微调在文化能力上的收益并不总是显著。如果基础模型本身的生成策略有问题，仅仅增加语料可能不够。需要在下游任务上做验证，而不是以困惑度下降为准。

数据方面，文化语料涉及民族、宗教、历史等敏感内容，整理和标注必须谨慎。尽量使用有明确授权、来源可靠、经过文化背景审核的资料。

9. 如何自己搭建一套文化知识评测

理解研究方法最好的方式，是自己动手做一遍。下面给出一套可以直接落地的文化知识评测设计，不依赖特定模型，可按需求替换。

9.1 定义知识本体

评测集需要有一个结构化本体。建议先定义三类核心元素：

• 实体：神话人物、神、英雄、妖怪、地名。
• 属性：身份、职能、象征物、所在作品、亲属关系。
• 关系：实体之间的关联，例如“是父子”“是敌对关系”“是某个地区的守护神”。

示例数据结构：

[ { "entity": "孙悟空", "region": "中国", "language": "zh", "attributes": { "identity": "《西游记》中的主要角色", "ability": "七十二变、筋斗云、火眼金睛", "relation": "唐僧的大徒弟" } }, { "entity": "Amaterasu", "region": "日本", "language": "ja", "attributes": { "identity": "太阳女神", "relation": "天照大神，日本皇室的祖先神" } } ]

9.2 构造评测集

评测集的建设原则：

• 来源可靠。优先从学术资料、公开知识库、专家审核内容中整理。
• 多语言覆盖。如果目标模型支持中文，至少做中英文双语评测。
• 数量均匀。每个文化地区至少 30 到 50 条，避免样本量太少导致结论不稳定。
• 版本说明。神话在不同传播版本中有差异，要写明依据哪个版本。

9.3 批量生成评测脚本

下面是一个用 Python 调用开源模型的评测框架，只做流程示范，实际模型名和路径需要按环境替换。

import json from transformers import AutoModelForCausalLM, AutoTokenizer import torch model_name = "your-open-source-llm" tokenizer = AutoTokenizer.from_pretrained(model_name) model = AutoModelForCausalLM.from_pretrained( model_name, device_map="auto", torch_dtype=torch.float16 ) def generate_answer(prompt, max_new_tokens=128): inputs = tokenizer(prompt, return_tensors="pt").to(model.device) outputs = model.generate( **inputs, max_new_tokens=max_new_tokens, do_sample=False, temperature=0.1 ) answer = tokenizer.decode( outputs[0][inputs["input_ids"].shape[1]:], skip_special_tokens=True ) return answer.strip() def evaluate_dataset(dataset_path): with open(dataset_path, "r", encoding="utf-8") as f: dataset = json.load(f) results = [] for item in dataset: prompt = f"请回答下面的文化知识问题。\n问题：{item['question']}\n回答：" prediction = generate_answer(prompt) results.append({ "entity": item["entity"], "question": item["question"], "reference": item["reference"], "prediction": prediction }) with open("eval_results.json", "w", encoding="utf-8") as f: json.dump(results, f, ensure_ascii=False, indent=2) return results

注意：批量评测时输出目录、日志、失败重试要提前设计好，避免跑一半出现模型加载失败或生成超时导致数据丢失。

9.4 内部表征探测示例

如果需要复现“表征 vs 解码”的对比思路，可以做一个非常简化的 logits 探测：只让模型预测答案的第一个 token，并比较正确答案 token 的概率。

def probe_answer_probability(prompt, answer): inputs = tokenizer(prompt, return_tensors="pt").to(model.device) with torch.no_grad(): logits = model(**inputs).logits[:, -1, :] probs = torch.nn.functional.softmax(logits, dim=-1) answer_tokens = tokenizer.encode(answer, add_special_tokens=False) score = 1.0 for token_id in answer_tokens: score *= probs[0, token_id].item() return score

这是一个非常简化的版本，不能直接等同于论文中的探针实验，但可以用它来观察“第一个答案 token 的概率”和“完整生成是否正确”之间是否存在明显落差。如果探测概率很高，但生成结果错误，说明问题大概率出在后期的解码生成路径。

9.5 评测时的资源观察

如果你准备批量评测多个开源模型，建议记录每个模型的显存占用、平均生成耗时、一次加载可处理的连续请求数量。尤其在 8G 显存的消费级显卡上，7B 模型加 16 位精度的加载就很紧张，建议优先使用 4bit 量化版本。显存占用需以你本机的实际模型版本和推理参数为准，不同量化方式差异很大。

评测 18 个模型的工作量不小，建议先用 2 到 3 个模型跑通流程，再横向扩展到全部模型。评测日志里保存模型名、版本、加载量化配置、decode 参数、时间戳，方便后续回溯。

10. 常见的评测误区与排查建议

11. 局限与合规边界

任何评测都有边界，这项研究也不例外。

神话知识只是文化意识的一个切片。它代表的是“事实性文化知识”，不包含价值观、社交规范、幽默感、隐喻理解等更复杂的文化能力。不能因为一个模型神话问答得分高，就认为它具备完整的文化意识；也不能因为得分低，就否定它在其他文化维度上的表现。

模型在不同语言下的表现还会受评测 prompt 影响。换一种问法，结果可能完全不同。所以这类评测更适合做相对比较或者定位问题，不适合做绝对排名。

关于合规，有三点必须强调：

• 评测集如果来自公开书籍、数据库、网站，需要确认数据授权。神话资料虽然历史悠久，但整理版本、翻译版本可能受著作权保护。
• 涉及宗教神话、民族神话的内容，表达要尊重文化背景，避免戏说、贬损或冒犯性生成。部署到公众场景时，应当有内容审核机制。
• 如果是用模型生成评测数据，要警惕模型自身的偏见被带入评测集。建议人工审核比例不低于 20%，关键文化条目必须人工确认。

12. 总结与下一步

这项研究最值得关注的点，是它把“模型懂不懂文化知识”重新拆成了两个问题：内部有没有知识，以及生成时能不能把知识准确说出来。对于所有正在做开源模型选型、多语言产品开发和本地化部署的团队来说，这个视角值得直接借鉴。

建议先从自己的业务场景出发，整理一份 30 到 50 条左右的文化知识小样本集，用目标用户的语言去测试候选模型。如果时间有限，至少先做两组测试：一组只问事实性问题，观察生成准确率；另一组把正确答案的首 token 概率和生成结果做对比，观察是否存在“知道但说不出来”的情况。

最容易踩的坑，是直接用英文评测结果推断模型在本土文化场景的表现。语言一换，文化一换，结果经常是天壤之别。

后续更值得关注的方向有三个：一是跨文化评测基准的标准化，二是把“表征-解码”差距作为优化目标的对齐训练，三是面向文化场景的可解释评测工具。这类工作做完之后，开源模型在真实世界里的文化适应能力会更容易衡量，也更可控。