这次我们来看一篇大语言模型评测方向的研究。标题有点长先翻译过来Cultural Awareness is Represented but Not Decoded意思是“文化意识在模型里存在但模型不一定能把它解码出来”。副标题是 Tracking Mythological Knowledge across 18 Open-Source LLMs即在 18 个开源大语言模型里追踪它们对神话知识的掌握程度。为什么选神话知识因为神话是文化底层的浓缩体里面有人物、事件、因果关系、器物、禁忌和象征比普通百科问答更能暴露模型训练语料的偏差。这篇论文的核心问题不是“模型知不知道某个国家的神话”而是更深一层知识明明已经在权重里了为什么提问方式一变、语言一换、上下文一改模型就答不出来。这个问题的研究价值很高尤其对三类人非常有用做多语言产品的人、做本地化功能的人、负责模型选型和 RAG 方案设计的工程师。看完这篇文章你会理解“知识表示”和“知识解码”之间的差距也能拿到一套自建神话知识评测集的思路以及用 OpenAI 兼容接口批量跑多个开源模型的方法。1. 研究核心信息速览先把这篇研究的规格信息放在前面方便快速判断它讨论了什么、需要什么环境、能得出什么结论。项目内容研究类型大语言模型知识评测与文化意识分析评测对象18 个开源大语言模型评测内容跨文化神话知识核心命题文化知识在模型权重中已经存在但不一定能被正确解码评测方式用统一提示模板跑全部模型汇总答案并对比正确率硬件要求需要 GPU支持 CPU 小规模测试按实际评测规模决定接口要求更推荐使用 OpenAI 兼容接口便于批量调用是否支持批量支持同一测试集可跑多个模型适用读者LLM 研究者、多语言产品开发者、模型选型工程师需要说明的是输入材料中没有给出 18 个模型的具体名单所以本文不会猜测具体模型。常见的开源系列包括 Qwen、Llama、Mistral、DeepSeek 等实际选型以论文原文为准。拿同一套测试集在本地跑这些模型就能复现类似的评测流程。2. 为什么要拿“神话知识”来评测模型2.1 神话知识的评测难度高于普通常识先看一个问题模型 A 知道“希腊神话的主神是宙斯”模型 B 也知道这能说明什么什么也说明不了。因为这类知识点在互联网语料里出现频率很高模型相当于背过答案。真正的难点在于神话知识的多层结构。以“大禹治水”为例单问“大禹是谁”和“大禹为什么能治水”是两个难度。更进一步如果问“大禹治水与诺亚方舟中‘洪水叙事’有什么异同”模型不仅要回忆两个文明的神话事实还要理解其中不同的自然环境、神人关系和伦理逻辑。这种问题无法靠关键词匹配解决。所以神话知识是一个很好的评测载体。它能测试出模型是否真的理解了文化内部的逻辑而不只是记住了几个名字。2.2 神话知识能区分“语言能力”和“文化能力”很多开源模型在中文、英文等语言任务上分数很高但这只能说明它们的语言能力强。语言能力强不代表文化能力强。一个模型可能能流利地用中文解释“龙”这个词但当你问“中国的龙和西方的 dragon 在象征意义上有什么本质区别”时它很容易输出一套混杂的、甚至自相矛盾的答案。这正是“文化意识”需要被单独评测的原因。日常对话里文化差异是隐藏的模型就算搞混了也能用通用词掩盖过去。但神话知识是具体且强相关的文化搞错了答案就是错的。研究标题里强调“神话知识”本质上是在用高密度的文化信息测试模型的文化边界。3. “表示”与“解码”的差距在哪里3.1 什么是“表示”在神经网络模型中知识并不是像数据库那样存储的而是以参数和分布式向量的形式存在。模型读了很多关于神话的语料之后与神话相关的实体、关系和语义特征会被压缩到一组高维向量里。“表示”这个层面的意思是如果你去探测模型的内部向量或者用一种特殊的提示方式去引导它它是能表现出知道某些神话知识的。例如用靠近训练语料的提问方式模型很可能给出正确答案。这个时候我们认为知识存在于模型的表示空间里。3.2 什么是“解码”“解码”指的是模型在推理时把存储在权重里的知识转换成自然语言输出的过程。模型通过注意力机制和生成头一步步预测下一个 token最终把你要的答案写出来。解码并不是一个直接查表的过程。同样的知识只要提问的语言变了、选项的顺序变了、上下文加了额外信息模型可能就走不到正确的输出路径上。这就是“表示但解码失败”的直观表现。3.3 为什么会出现“表示但解码失败”主要原因可以拆成三层。第一层是训练目标和解码目标的错位。语言模型训练的核心任务是预测下一个 token它并不专门优化“从知识库中精确检索某个事实”这个目标。训练阶段形成了“下一词概率高”的路径但推理阶段用户追问的是“某条知识的精确答案”这两个目标经常不一致。第二层是分布式存储导致的路径依赖。知识不是存在一个独立的单元里而是分散在很多参数中。模型需要正确的上下文激活某些路径才能把分散的信息拼接起来。如果用户给出的上下文结构偏离训练分布模型就很难完成内部的路径激活最后只能输出一个模糊的、通用的答案。第三层是提示语言与知识语言的错配。如果知识来自中文语料但用户用英文提问模型需要先完成一次内部翻译再检索知识再翻译回来。这个过程中每多一次转换就多一分信息损失。跨语言评测下“表示但解码失败”会更普遍。4. 评测方法设计建议如果你想参考这篇论文的思路自建一套神话知识评测方案可以把评估拆成三步测试集、提示模板、评分方式。4.1 测试集结构设计不要只做单一题型建议用四类任务覆盖不同层面的文化知识选择题给定四个选项判断人物、事件、物品归属适合批量统计准确率。开放题只给问题不提供选项考察模型从表示空间里自由提取知识的能力。连线题给出两组神话元素要求模型判断是否匹配考察关系记忆。对比题要求模型比较两个不同文化神话中的同类概念考察深层推理。同时测试集要有明确的类别划分。例如神话人物类、事件因果类、神物与象征类、仪式与禁忌类、跨文化比较类。每一类最好单独统计得分这样能看出模型是在哪类知识上存在解码失败。4.2 提示模板设计提示模板不要只用一种建议至少测试三种模板A直接提问 请回答下面关于神话知识的题目只输出答案不要解释。 问题XXX 答案 模板B带选项提问 请回答下面关于神话知识的题目从给出的选项中选择最合适的一项只输出选项字母。 问题XXX 选项A. XXX B. XXX C. XXX D. XXX 答案 模板C限定角色提问 你是一位比较文化学研究者请根据你掌握的神话知识回答下面的问题。 问题XXX 答案不同模板的得分差异本身就是一个很有价值的观察维度。如果模型在模板 A 下得 30 分在模板 C 下得 60 分说明知识表示是存在的但解码路径对提示结构非常敏感。这就是“表示但未解码”的直接证据。4.3 评分方式评分不要只看最终答案是否精确匹配建议使用三级评分分数标准2 分答案准确信息无遗漏1 分答案方向正确但存在部分错误或遗漏0 分答案错误或输出“我不知道”等无效内容对于开放题和对比题建议用语义相似度辅助评分但一定要加入人工抽检。大模型输出的文本经常结构完整但内容虚假纯自动评分很容易给“看似合理但实际错误”的答案打高分。5. 在 18 个开源 LLM 上跑评测的脚本下面给出一套完整示例采用 OpenAI 兼容接口大多数本地推理框架都支持包括 vLLM、Ollama 等。如果你的推理服务不是 OpenAI 兼容协议需要按实际接口调整。5.1 准备测试集文件建议使用 JSONL 格式一行一个题目{id: greek_001, question: 宙斯的兄弟波塞冬掌管哪个领域, options: [天空, 海洋, 冥界, 大地], answer: B, category: 人物关系} {id: chinese_001, question: 在“大禹治水”的传说中禹主要通过哪种方式治理洪水, options: [筑堤堵水, 疏浚河道, 建塔镇水, 求神赐雨], answer: B, category: 事件因果} {id: norse_001, question: 北欧神话中奥丁为了获取智慧付出了一只眼睛他换取的是什么, options: [命运之力, 智慧之泉的智慧, 雷神之锤, 世界树的果实], answer: B, category: 事件因果}5.2 编写评测脚本保存为eval_cultural_knowledge.py核心逻辑是读取 JSONL逐题请求模型拿到答案后与正确答案对比。import json import argparse from openai import OpenAI def run_question(client, model, q, temperature0.1): options_text .join( f{chr(ord(A) i)}. {opt} for i, opt in enumerate(q[options]) ) prompt ( 请回答下面关于神话知识的题目只输出选项字母不要解释。\n f问题{q[question]}\n f选项{options_text}\n 答案 ) resp client.chat.completions.create( modelmodel, messages[{role: user, content: prompt}], temperaturetemperature, max_tokens16, ) return resp.choices[0].message.content.strip() def evaluate(data, base_url, api_key, model, output_path): client OpenAI(base_urlbase_url, api_keyapi_key) results [] total 0 correct 0 for q in data: pred run_question(client, model, q) answer_letter pred[0].upper() if pred else exact answer_letter q[answer] total 1 correct int(exact) results.append({ id: q[id], category: q[category], pred: pred, expected: q[answer], correct: exact, }) print(f{q[id]} | pred{pred} | expected{q[answer]} | {OK if exact else FAIL}) accuracy correct / total if total else 0 print(f\n模型 {model} 准确率: {accuracy:.2%} ({correct}/{total})) with open(output_path, w, encodingutf-8) as f: json.dump({ model: model, total: total, correct: correct, accuracy: accuracy, details: results, }, f, ensure_asciiFalse, indent2) if __name__ __main__: parser argparse.ArgumentParser() parser.add_argument(--model, requiredTrue, help模型名称) parser.add_argument(--base-url, defaulthttp://127.0.0.1:8000/v1, help推理服务地址) parser.add_argument(--api-key, defaultEMPTY, helpAPI Key) parser.add_argument(--questions, defaultquestions.jsonl, help测试集路径) parser.add_argument(--output, defaulteval_result.json, help结果输出路径) args parser.parse_args() with open(args.questions, encodingutf-8) as f: data [json.loads(line) for line in f if line.strip()] evaluate(data, args.base_url, args.api_key, args.model, args.output)这个脚本会逐题输出预测结果最后统计准确率并把完整结果写入 JSON。这样不仅能看总分还能按category字段分析每个知识类别的得分情况。5.3 批量执行多个模型有了单个模型的评测脚本批量跑 18 个模型就很容易了。写一个 for 循环把模型名换成你要测的列表for model_name in qwen2.5:7b llama3.1:8b mistral:7b deepseek-r1:7b; do echo echo Evaluating: $model_name echo python eval_cultural_knowledge.py \ --model $model_name \ --output result_${model_name//:/_}.json done注意如果你的推理服务使用的是自定义模型名请把$model_name替换成你在服务端配置的名称。另外18 个模型并行跑会占用大量显存建议根据 GPU 总量分批处理一次跑 3 到 4 个模型结果会更稳定。6. 资源占用与性能观察评测 18 个开源 LLM 不是一件轻松的事资源占用量取决于模型尺寸、输入长度和并发数。理论上有两条路线本地 GPU 推理和云端 API 推理。如果是本地 GPU 推理重点观察两个指标显存占用和推理吞吐。显存直接决定单卡能跑多大的模型。7B 级别模型在 FP16 下大约需要 14GB 显存如果量化到 4bit 能压到 6GB 左右。更简单的方式是直接看推理服务启动时的提示信息不同负载框架会打印显存占用。运行过程中用下面的命令动态观察显存nvidia-smi --query-gpuname,memory.total,memory.used,memory.free,utilization.gpu --formatcsv -l 5每 5 秒刷新一次重点关注memory.used和utilization.gpu。如果显存占用稳定在 95% 以上且利用率很高说明模型正在满负荷推理如果利用率低于 20%可能是批处理逻辑有问题或者输入输出长度过短。批量评测场景下温度的设置也会影响性能测试的稳定性。建议把温度固定在 0.1关闭随机性这样同一个模型在相同题目上输出可复现也更容易定位推理框架的问题。如果对生成长度没有特殊需求max_tokens设置得越短越好这样能有效降低单请求延迟。如果本地 GPU 资源紧张可以用 CPU 推理跑小型模型。但要注意CPU 上跑 7B 模型的延迟可能是 GPU 的几十倍评测集如果很大耗时非常夸张。如果模型名以“8B”“14B”结尾而显存不足优先考虑量化版本或换云 GPU不要直接硬撑。7. 评测结果能指导什么“表示但解码失败”这个现象如果被充分验证对实际工程有四个直接启发。第一个启发是提示词工程不是玄学。模型在模板 A 下答错在模板 C 下答对这种现象用同一个模型也能复现。这说明“提示词对结果影响巨大”不是偶然而是模型知识检索路径对上下文结构的依赖。面向用户的产品里设计提示词时不要只考虑“能不能答”还要考虑“换一种问法之后是否依然稳定”。第二个启发是模型选型要多看文化维度。很多企业选模型只看通用 benchmark这会导致产品里出现奇怪的文化错位。用一套小规模的神话知识测试集哪怕是 50 道题就能快速筛选出哪些模型在你的目标文化场景里表现稳定。这个做法比看通用分数更有指导意义。第三个启发是 RAG 系统不能完全替代模型的文化知识。RAG 能召回文档片段但如果模型本身无法把召回内容与文化背景结合答出来的内容依然可能是生硬的拼接。在做知识库问答时不要假设“召回对了就万事大吉”还需要对生成结果做文化校验。第四个启发是做人机协同接口时要预留人工复核机制。如果模型被评测为“知识存在但解码不稳定”那在实际产品里就必须加入兜底逻辑。当模型答案不确定时不要强行给一个看似合理的答案而是返回“建议人工确认”或触发二次检索。8. 常见问题与排查方法自己跑文化知识评测时很容易遇到下面几个问题。问题现象可能原因排查方式解决方案所有模型全部得 0 分测试集格式错误或提示模板无法触发模型回答打印一条原始请求和响应人工检查调整提示模板加入“请直接选择”等约束模型答案总是无效文本max_tokens太小答案被截断查看完整输出确认是否包含完整选项字母调大max_tokens或改用输出解析逻辑同一模型不同时间结果不一致温度设置过高检查温度参数和随机种子把温度降到 0.1必要时设置 seed显存不足导致推理中断并行模型过多或单模型过大用nvidia-smi查看显存占用减少并发模型数使用量化版本请求超时模型推理速度慢或并发过高查看服务端日志观察平均延迟增大超时时间降低请求并发数输出结果全是“A”或固定项模型未真正解析题目输出发生了坍缩查看不同模板下的输出差异更换模板加入思考要求或拆分子问题测试集本身包含错误答案评测集未经过人工校验随机抽 20 条人工复核重新校对测试集避免错误标签污染结论不同模型之间分数差异极小题目太难或太简单没有区分度统计每道题的正确率筛选正确率在 30%-80% 之间的题目作为有效评测项如果你在跑大规模评测时发现分数忽高忽低优先检查提示模板和输出解析逻辑。这两个环节出问题的概率远高于模型本身。9. 合规与安全边界评测神话知识时要注意几个边界问题。第一神话知识不等于宗教评价。很多神话体系与某些地区的历史文化、民间信仰强关联评测中应保持学术中性和文化尊重不要把神话人物或典故用于贬低、戏谑某个民族或宗教群体。第二测试集不能包含过度敏感的内容。本地部署评测时如果测试集涉及特定民族、传统习俗、神话传说不要使用带有诋毁性、歧视性表述的题目也不要将虚构神话与现实政治建立映射。第三如果评测的是从网络收集的文本需要注意数据来源的版权要求。神话故事本身很多属于公共领域但现代改写版本、翻译文本可能受版权保护。自建评测集时建议优先使用公共领域的经典文本不直接批量下载商业电子书或受限数据库中的全文。第四调用外部模型 API 进行评测时不要把未脱敏的内部业务数据放进测试集。神话知识测试本身通常不涉及隐私但如果你把用户生成内容混入测试集就必须遵循数据最小化原则提前做匿名化处理。第五标注“模型存在文化知识但解码失败”不等于“模型具备某种文化立场”。评测结果只能说明模型在特定提示下能否输出特定知识点不适合据此下结论说某个模型“天然偏向某种文化”更不能用这种结论去制造对特定模型或地区的刻板印象。10. 最佳实践与后续方向如果你打算把神话知识评测纳入模型评估体系推荐按下面的顺序落地。第一先建一个 50 到 100 题的迷你测试集。覆盖人物、事件、物品、跨文化比较四个类别每类不少于 10 题先拿两三个模型试跑一遍确认题目的区分度和提示模板的稳定性。第一轮不要追求 18 个模型先把流程跑通。第二记录每个模型在不同提示模板下的表现差异。这个差异本身就是评估报告的重要部分。如果某个模型直接提问得分低、限定角色后得分高说明它的解码路径比较窄需要靠强提示词才能激活知识区域。第三把评测脚本接入 CI 或定期评估流程。每次升级模型版本、切换推理框架、调整量化参数时都跑一遍同一套测试集。这样能及时发现“模型变强了但文化知识反倒没法解出来了”的回归问题。后面如果想继续深入可以往三个方向扩展跨语言评测用同一道题的多种语言版本测试模型文化纠偏训练在模型输出后进行文化合规校验以及解码策略优化比如用多轮追问或思维链方式提升知识检索成功率。这套方法论不只能用于神话知识中医概念、地域民俗、历史典故都可以按同样思路做成评测集。评测的目的不是给模型排名而是搞清楚模型的知识边界在哪里哪些场景需要提示词强行拉回哪些场景必须交给 RAG 或人工兜底。先把“表示但解码失败”这个问题测量出来后续的优化才有依据。 模型“知道”神话却答不出？18个开源LLM评测揭示知识解码困境
这次我们来看一篇大语言模型评测方向的研究。标题有点长先翻译过来Cultural Awareness is Represented but Not Decoded意思是“文化意识在模型里存在但模型不一定能把它解码出来”。副标题是 Tracking Mythological Knowledge across 18 Open-Source LLMs即在 18 个开源大语言模型里追踪它们对神话知识的掌握程度。为什么选神话知识因为神话是文化底层的浓缩体里面有人物、事件、因果关系、器物、禁忌和象征比普通百科问答更能暴露模型训练语料的偏差。这篇论文的核心问题不是“模型知不知道某个国家的神话”而是更深一层知识明明已经在权重里了为什么提问方式一变、语言一换、上下文一改模型就答不出来。这个问题的研究价值很高尤其对三类人非常有用做多语言产品的人、做本地化功能的人、负责模型选型和 RAG 方案设计的工程师。看完这篇文章你会理解“知识表示”和“知识解码”之间的差距也能拿到一套自建神话知识评测集的思路以及用 OpenAI 兼容接口批量跑多个开源模型的方法。1. 研究核心信息速览先把这篇研究的规格信息放在前面方便快速判断它讨论了什么、需要什么环境、能得出什么结论。项目内容研究类型大语言模型知识评测与文化意识分析评测对象18 个开源大语言模型评测内容跨文化神话知识核心命题文化知识在模型权重中已经存在但不一定能被正确解码评测方式用统一提示模板跑全部模型汇总答案并对比正确率硬件要求需要 GPU支持 CPU 小规模测试按实际评测规模决定接口要求更推荐使用 OpenAI 兼容接口便于批量调用是否支持批量支持同一测试集可跑多个模型适用读者LLM 研究者、多语言产品开发者、模型选型工程师需要说明的是输入材料中没有给出 18 个模型的具体名单所以本文不会猜测具体模型。常见的开源系列包括 Qwen、Llama、Mistral、DeepSeek 等实际选型以论文原文为准。拿同一套测试集在本地跑这些模型就能复现类似的评测流程。2. 为什么要拿“神话知识”来评测模型2.1 神话知识的评测难度高于普通常识先看一个问题模型 A 知道“希腊神话的主神是宙斯”模型 B 也知道这能说明什么什么也说明不了。因为这类知识点在互联网语料里出现频率很高模型相当于背过答案。真正的难点在于神话知识的多层结构。以“大禹治水”为例单问“大禹是谁”和“大禹为什么能治水”是两个难度。更进一步如果问“大禹治水与诺亚方舟中‘洪水叙事’有什么异同”模型不仅要回忆两个文明的神话事实还要理解其中不同的自然环境、神人关系和伦理逻辑。这种问题无法靠关键词匹配解决。所以神话知识是一个很好的评测载体。它能测试出模型是否真的理解了文化内部的逻辑而不只是记住了几个名字。2.2 神话知识能区分“语言能力”和“文化能力”很多开源模型在中文、英文等语言任务上分数很高但这只能说明它们的语言能力强。语言能力强不代表文化能力强。一个模型可能能流利地用中文解释“龙”这个词但当你问“中国的龙和西方的 dragon 在象征意义上有什么本质区别”时它很容易输出一套混杂的、甚至自相矛盾的答案。这正是“文化意识”需要被单独评测的原因。日常对话里文化差异是隐藏的模型就算搞混了也能用通用词掩盖过去。但神话知识是具体且强相关的文化搞错了答案就是错的。研究标题里强调“神话知识”本质上是在用高密度的文化信息测试模型的文化边界。3. “表示”与“解码”的差距在哪里3.1 什么是“表示”在神经网络模型中知识并不是像数据库那样存储的而是以参数和分布式向量的形式存在。模型读了很多关于神话的语料之后与神话相关的实体、关系和语义特征会被压缩到一组高维向量里。“表示”这个层面的意思是如果你去探测模型的内部向量或者用一种特殊的提示方式去引导它它是能表现出知道某些神话知识的。例如用靠近训练语料的提问方式模型很可能给出正确答案。这个时候我们认为知识存在于模型的表示空间里。3.2 什么是“解码”“解码”指的是模型在推理时把存储在权重里的知识转换成自然语言输出的过程。模型通过注意力机制和生成头一步步预测下一个 token最终把你要的答案写出来。解码并不是一个直接查表的过程。同样的知识只要提问的语言变了、选项的顺序变了、上下文加了额外信息模型可能就走不到正确的输出路径上。这就是“表示但解码失败”的直观表现。3.3 为什么会出现“表示但解码失败”主要原因可以拆成三层。第一层是训练目标和解码目标的错位。语言模型训练的核心任务是预测下一个 token它并不专门优化“从知识库中精确检索某个事实”这个目标。训练阶段形成了“下一词概率高”的路径但推理阶段用户追问的是“某条知识的精确答案”这两个目标经常不一致。第二层是分布式存储导致的路径依赖。知识不是存在一个独立的单元里而是分散在很多参数中。模型需要正确的上下文激活某些路径才能把分散的信息拼接起来。如果用户给出的上下文结构偏离训练分布模型就很难完成内部的路径激活最后只能输出一个模糊的、通用的答案。第三层是提示语言与知识语言的错配。如果知识来自中文语料但用户用英文提问模型需要先完成一次内部翻译再检索知识再翻译回来。这个过程中每多一次转换就多一分信息损失。跨语言评测下“表示但解码失败”会更普遍。4. 评测方法设计建议如果你想参考这篇论文的思路自建一套神话知识评测方案可以把评估拆成三步测试集、提示模板、评分方式。4.1 测试集结构设计不要只做单一题型建议用四类任务覆盖不同层面的文化知识选择题给定四个选项判断人物、事件、物品归属适合批量统计准确率。开放题只给问题不提供选项考察模型从表示空间里自由提取知识的能力。连线题给出两组神话元素要求模型判断是否匹配考察关系记忆。对比题要求模型比较两个不同文化神话中的同类概念考察深层推理。同时测试集要有明确的类别划分。例如神话人物类、事件因果类、神物与象征类、仪式与禁忌类、跨文化比较类。每一类最好单独统计得分这样能看出模型是在哪类知识上存在解码失败。4.2 提示模板设计提示模板不要只用一种建议至少测试三种模板A直接提问 请回答下面关于神话知识的题目只输出答案不要解释。 问题XXX 答案 模板B带选项提问 请回答下面关于神话知识的题目从给出的选项中选择最合适的一项只输出选项字母。 问题XXX 选项A. XXX B. XXX C. XXX D. XXX 答案 模板C限定角色提问 你是一位比较文化学研究者请根据你掌握的神话知识回答下面的问题。 问题XXX 答案不同模板的得分差异本身就是一个很有价值的观察维度。如果模型在模板 A 下得 30 分在模板 C 下得 60 分说明知识表示是存在的但解码路径对提示结构非常敏感。这就是“表示但未解码”的直接证据。4.3 评分方式评分不要只看最终答案是否精确匹配建议使用三级评分分数标准2 分答案准确信息无遗漏1 分答案方向正确但存在部分错误或遗漏0 分答案错误或输出“我不知道”等无效内容对于开放题和对比题建议用语义相似度辅助评分但一定要加入人工抽检。大模型输出的文本经常结构完整但内容虚假纯自动评分很容易给“看似合理但实际错误”的答案打高分。5. 在 18 个开源 LLM 上跑评测的脚本下面给出一套完整示例采用 OpenAI 兼容接口大多数本地推理框架都支持包括 vLLM、Ollama 等。如果你的推理服务不是 OpenAI 兼容协议需要按实际接口调整。5.1 准备测试集文件建议使用 JSONL 格式一行一个题目{id: greek_001, question: 宙斯的兄弟波塞冬掌管哪个领域, options: [天空, 海洋, 冥界, 大地], answer: B, category: 人物关系} {id: chinese_001, question: 在“大禹治水”的传说中禹主要通过哪种方式治理洪水, options: [筑堤堵水, 疏浚河道, 建塔镇水, 求神赐雨], answer: B, category: 事件因果} {id: norse_001, question: 北欧神话中奥丁为了获取智慧付出了一只眼睛他换取的是什么, options: [命运之力, 智慧之泉的智慧, 雷神之锤, 世界树的果实], answer: B, category: 事件因果}5.2 编写评测脚本保存为eval_cultural_knowledge.py核心逻辑是读取 JSONL逐题请求模型拿到答案后与正确答案对比。import json import argparse from openai import OpenAI def run_question(client, model, q, temperature0.1): options_text .join( f{chr(ord(A) i)}. {opt} for i, opt in enumerate(q[options]) ) prompt ( 请回答下面关于神话知识的题目只输出选项字母不要解释。\n f问题{q[question]}\n f选项{options_text}\n 答案 ) resp client.chat.completions.create( modelmodel, messages[{role: user, content: prompt}], temperaturetemperature, max_tokens16, ) return resp.choices[0].message.content.strip() def evaluate(data, base_url, api_key, model, output_path): client OpenAI(base_urlbase_url, api_keyapi_key) results [] total 0 correct 0 for q in data: pred run_question(client, model, q) answer_letter pred[0].upper() if pred else exact answer_letter q[answer] total 1 correct int(exact) results.append({ id: q[id], category: q[category], pred: pred, expected: q[answer], correct: exact, }) print(f{q[id]} | pred{pred} | expected{q[answer]} | {OK if exact else FAIL}) accuracy correct / total if total else 0 print(f\n模型 {model} 准确率: {accuracy:.2%} ({correct}/{total})) with open(output_path, w, encodingutf-8) as f: json.dump({ model: model, total: total, correct: correct, accuracy: accuracy, details: results, }, f, ensure_asciiFalse, indent2) if __name__ __main__: parser argparse.ArgumentParser() parser.add_argument(--model, requiredTrue, help模型名称) parser.add_argument(--base-url, defaulthttp://127.0.0.1:8000/v1, help推理服务地址) parser.add_argument(--api-key, defaultEMPTY, helpAPI Key) parser.add_argument(--questions, defaultquestions.jsonl, help测试集路径) parser.add_argument(--output, defaulteval_result.json, help结果输出路径) args parser.parse_args() with open(args.questions, encodingutf-8) as f: data [json.loads(line) for line in f if line.strip()] evaluate(data, args.base_url, args.api_key, args.model, args.output)这个脚本会逐题输出预测结果最后统计准确率并把完整结果写入 JSON。这样不仅能看总分还能按category字段分析每个知识类别的得分情况。5.3 批量执行多个模型有了单个模型的评测脚本批量跑 18 个模型就很容易了。写一个 for 循环把模型名换成你要测的列表for model_name in qwen2.5:7b llama3.1:8b mistral:7b deepseek-r1:7b; do echo echo Evaluating: $model_name echo python eval_cultural_knowledge.py \ --model $model_name \ --output result_${model_name//:/_}.json done注意如果你的推理服务使用的是自定义模型名请把$model_name替换成你在服务端配置的名称。另外18 个模型并行跑会占用大量显存建议根据 GPU 总量分批处理一次跑 3 到 4 个模型结果会更稳定。6. 资源占用与性能观察评测 18 个开源 LLM 不是一件轻松的事资源占用量取决于模型尺寸、输入长度和并发数。理论上有两条路线本地 GPU 推理和云端 API 推理。如果是本地 GPU 推理重点观察两个指标显存占用和推理吞吐。显存直接决定单卡能跑多大的模型。7B 级别模型在 FP16 下大约需要 14GB 显存如果量化到 4bit 能压到 6GB 左右。更简单的方式是直接看推理服务启动时的提示信息不同负载框架会打印显存占用。运行过程中用下面的命令动态观察显存nvidia-smi --query-gpuname,memory.total,memory.used,memory.free,utilization.gpu --formatcsv -l 5每 5 秒刷新一次重点关注memory.used和utilization.gpu。如果显存占用稳定在 95% 以上且利用率很高说明模型正在满负荷推理如果利用率低于 20%可能是批处理逻辑有问题或者输入输出长度过短。批量评测场景下温度的设置也会影响性能测试的稳定性。建议把温度固定在 0.1关闭随机性这样同一个模型在相同题目上输出可复现也更容易定位推理框架的问题。如果对生成长度没有特殊需求max_tokens设置得越短越好这样能有效降低单请求延迟。如果本地 GPU 资源紧张可以用 CPU 推理跑小型模型。但要注意CPU 上跑 7B 模型的延迟可能是 GPU 的几十倍评测集如果很大耗时非常夸张。如果模型名以“8B”“14B”结尾而显存不足优先考虑量化版本或换云 GPU不要直接硬撑。7. 评测结果能指导什么“表示但解码失败”这个现象如果被充分验证对实际工程有四个直接启发。第一个启发是提示词工程不是玄学。模型在模板 A 下答错在模板 C 下答对这种现象用同一个模型也能复现。这说明“提示词对结果影响巨大”不是偶然而是模型知识检索路径对上下文结构的依赖。面向用户的产品里设计提示词时不要只考虑“能不能答”还要考虑“换一种问法之后是否依然稳定”。第二个启发是模型选型要多看文化维度。很多企业选模型只看通用 benchmark这会导致产品里出现奇怪的文化错位。用一套小规模的神话知识测试集哪怕是 50 道题就能快速筛选出哪些模型在你的目标文化场景里表现稳定。这个做法比看通用分数更有指导意义。第三个启发是 RAG 系统不能完全替代模型的文化知识。RAG 能召回文档片段但如果模型本身无法把召回内容与文化背景结合答出来的内容依然可能是生硬的拼接。在做知识库问答时不要假设“召回对了就万事大吉”还需要对生成结果做文化校验。第四个启发是做人机协同接口时要预留人工复核机制。如果模型被评测为“知识存在但解码不稳定”那在实际产品里就必须加入兜底逻辑。当模型答案不确定时不要强行给一个看似合理的答案而是返回“建议人工确认”或触发二次检索。8. 常见问题与排查方法自己跑文化知识评测时很容易遇到下面几个问题。问题现象可能原因排查方式解决方案所有模型全部得 0 分测试集格式错误或提示模板无法触发模型回答打印一条原始请求和响应人工检查调整提示模板加入“请直接选择”等约束模型答案总是无效文本max_tokens太小答案被截断查看完整输出确认是否包含完整选项字母调大max_tokens或改用输出解析逻辑同一模型不同时间结果不一致温度设置过高检查温度参数和随机种子把温度降到 0.1必要时设置 seed显存不足导致推理中断并行模型过多或单模型过大用nvidia-smi查看显存占用减少并发模型数使用量化版本请求超时模型推理速度慢或并发过高查看服务端日志观察平均延迟增大超时时间降低请求并发数输出结果全是“A”或固定项模型未真正解析题目输出发生了坍缩查看不同模板下的输出差异更换模板加入思考要求或拆分子问题测试集本身包含错误答案评测集未经过人工校验随机抽 20 条人工复核重新校对测试集避免错误标签污染结论不同模型之间分数差异极小题目太难或太简单没有区分度统计每道题的正确率筛选正确率在 30%-80% 之间的题目作为有效评测项如果你在跑大规模评测时发现分数忽高忽低优先检查提示模板和输出解析逻辑。这两个环节出问题的概率远高于模型本身。9. 合规与安全边界评测神话知识时要注意几个边界问题。第一神话知识不等于宗教评价。很多神话体系与某些地区的历史文化、民间信仰强关联评测中应保持学术中性和文化尊重不要把神话人物或典故用于贬低、戏谑某个民族或宗教群体。第二测试集不能包含过度敏感的内容。本地部署评测时如果测试集涉及特定民族、传统习俗、神话传说不要使用带有诋毁性、歧视性表述的题目也不要将虚构神话与现实政治建立映射。第三如果评测的是从网络收集的文本需要注意数据来源的版权要求。神话故事本身很多属于公共领域但现代改写版本、翻译文本可能受版权保护。自建评测集时建议优先使用公共领域的经典文本不直接批量下载商业电子书或受限数据库中的全文。第四调用外部模型 API 进行评测时不要把未脱敏的内部业务数据放进测试集。神话知识测试本身通常不涉及隐私但如果你把用户生成内容混入测试集就必须遵循数据最小化原则提前做匿名化处理。第五标注“模型存在文化知识但解码失败”不等于“模型具备某种文化立场”。评测结果只能说明模型在特定提示下能否输出特定知识点不适合据此下结论说某个模型“天然偏向某种文化”更不能用这种结论去制造对特定模型或地区的刻板印象。10. 最佳实践与后续方向如果你打算把神话知识评测纳入模型评估体系推荐按下面的顺序落地。第一先建一个 50 到 100 题的迷你测试集。覆盖人物、事件、物品、跨文化比较四个类别每类不少于 10 题先拿两三个模型试跑一遍确认题目的区分度和提示模板的稳定性。第一轮不要追求 18 个模型先把流程跑通。第二记录每个模型在不同提示模板下的表现差异。这个差异本身就是评估报告的重要部分。如果某个模型直接提问得分低、限定角色后得分高说明它的解码路径比较窄需要靠强提示词才能激活知识区域。第三把评测脚本接入 CI 或定期评估流程。每次升级模型版本、切换推理框架、调整量化参数时都跑一遍同一套测试集。这样能及时发现“模型变强了但文化知识反倒没法解出来了”的回归问题。后面如果想继续深入可以往三个方向扩展跨语言评测用同一道题的多种语言版本测试模型文化纠偏训练在模型输出后进行文化合规校验以及解码策略优化比如用多轮追问或思维链方式提升知识检索成功率。这套方法论不只能用于神话知识中医概念、地域民俗、历史典故都可以按同样思路做成评测集。评测的目的不是给模型排名而是搞清楚模型的知识边界在哪里哪些场景需要提示词强行拉回哪些场景必须交给 RAG 或人工兜底。先把“表示但解码失败”这个问题测量出来后续的优化才有依据。