Ethan Mollick 建议用历史谜题测试 AI一个让我少走半年弯路的评测思路如果你正在做 AI 应用开发、模型选型或者只是被某款号称“逻辑能力超强”的大模型忽悠过那么 Ethan Mollick 的这个思路你应该听听——用历史谜题来测试 AI。先说清楚 Ethan Mollick 是谁。他是沃顿商学院研究 AI 与工作、教育交叉领域的教授长期公开评测各类大模型的实际表现。他的核心观点不是“哪家模型更强”而是模型在与你对话时表现出的能力可能是一套精心编排的表演而不是真实的推理能力。而历史谜题恰好能撕破这层表演。我最早听到这个建议的时候第一反应是怀疑历史题那不是考记忆吗模型背了那么多训练数据历史百科全书级别的知识拿历史题考它哪里难得到但真正动手跑了一轮测试之后我发现自己完全想反了——越是不起眼的历史细节题越能暴露模型的推理和溯源能力。这不是“考背诵”这是一套能让你看清 AI 底裤的评测方法论。这篇内容就是把我的实践过程、踩坑经历、测试设计思路完整复盘一遍。不管你是做 AI 产品规划、提示词工程还是单纯想验证“手上这个模型到底是聪明还是爱吹牛”这篇文章都值得你花十分钟读完。1. 整体设计思路拆解为什么偏偏是历史谜题1.1 历史文本是一套天然“防背诵”测试集先想一个问题常规的大模型能力测试为什么越来越不可信数学题今年以来的新模型在 MATH 和 GSM8K 上的分数已经高得离谱但其中相当一部分提升来源于训练集里混入了同类题目的变体。编程题LeetCode 级别的题本身就是公开题库模型只要在训练阶段见过相似解法就能“默写”出正确答案。逻辑判断题市面上的逻辑题已经被人反复整理成公开语料模型连推理过程都能照着标准答案背。问题是这些都是“开卷题”。模型经历过海量数据的洗礼已经见过太多同类的题。你在测试它本质上是在测试它有没有背过这道题的亲戚。但历史谜题不一样。历史事件本身是唯一的、不可重复的。亚历山大大帝不会在 2024 年再打一次高加米拉战役凯撒也不会换个时间再跨一次卢比孔河。任何一道高质量的历史谜题都不可能在训练数据中高频出现完全相同的题干和标准答案。它既考事实调用又考推理能力还专门戳那些“看似知道、细想却不确定”的知识盲区。把这种题抛给 AI你得到的是一个未经“模拟考试”的原始反应。1.2 历史谜题和其他测试方式的本质区别我需要强调一个区分测试 AI 有很多方式但不同类型测出来的能力维度完全不同。测试类型测的是什么模型容易在哪些地方作弊数学/编程题符号运算、逻辑链训练集覆盖同类题背解法百科问答知识存储直接背诵语料通用对话语言组织和意图匹配模板化回复绕开不确定问题历史谜题事实追溯、因果推理、证据权衡最难作弊事件唯一、推理链长历史谜题最大的特点是“结构性封闭”。它不是开放式脑洞给定史料有限答案有据可查但这个“据”藏在尘封文本里需要模型真正理解语义、辨别文献、推断因果而不是从段落之间找词频相关性。我在实践中发现模型面对历史题的反应远比面对编程题更能说明它是否具备深度推理能力。数学题错了可能就是计算误但历史题错了很多时候是它根本不知道自己不知道然后一本正经给你编一段“史料”。1.3 这个方法适合谁来用很多人一听“历史谜题”第一反应是“我又不是历史老师这跟我有什么关系”。恰恰相反这个评测思路的适用场景比想象中广得多AI 产品经理需要对比哪个大模型适合做知识库问答场景历史题能帮你挑出“乱编身世”最少的那个。开发者每次升级模型或换供应商之前用同一套历史题跑一遍回归测试代替拍脑袋选模型。提示词工程师通过分析模型的错误模式你的提示词结构调整会更有方向。普通 AI 用户判断某款宣称“超越 GPT”的国产模型或开源模型的真实水平。我自己的实践体会是历史谜题不是一个“专业的测试工具”而是一套低成本、可复制、高区分度的模型评估方法。只要你会上网搜史料就能搭出一套测试集而且效果比一堆玄学 Prompt 靠谱得多。2. 核心细节解析与实操要点搭一套能测出毛病的题库2.1 第一类事件还原题——测事实提取能力这是最基础的一类。你给出一段关于历史事件的陈述要求模型判断其真实性并给出依据来源或者让模型在混杂的史料中提取关键时间线。好题例子自测用中世纪欧洲的“黑死病”爆发于 1347 年左右但意大利的某些城市如米兰在疫情中死亡率异常低。米兰采取了哪些措施这在当时医学水平下是“卫生防疫”还是纯属地理运气模型需要做到列出米兰早期封锁措施、提到当时医生对“空气传播”和“接触传染”的不同看法、指出统治者采取的隔离决策。这题藏着“解释真实历史中的复杂归因”这个坑模型如果直接说“米兰运气好”说明它完全没进入推理状态。我用这类题测过两个主流大模型回答里都出现了同一个问题把 1348 年佛罗伦萨的瘟疫描述挪用给米兰这明显是训练语料里混杂了不同城市的描述。有价值的不是纠错而是意识到它在“调用相似事件”而不是“查询精确史实”。2.2 第二类身份辨析题——测推理能力和证据权重这是我最喜欢的一类也是水分最大的领域。你给模型两个或多个历史人物它们身份高度相似但事迹和影响力完全不同。实操时我会这么问同样是古希腊时代的“大帝”亚历山大三世和皮洛士的军事策略区别在哪里为什么皮洛士在意大利南部打了胜仗却落得“皮洛士式胜利”的名声这类题你真正考的不是模型会不会背维基百科而是它是否懂得区分证据权重——胜利的结果赢了但战略目标没有达成军事能力很强但政治条件不允许。我在同一模型上跑不同温度参数发现一个规律温度越低趋近 0模型倾向于给出单一“标准答案”把皮洛士的解释简化成“赢得惨烈的胜利”完全忽略他在文化和体制层面的局限温度越高超过 0.7模型开始编造细节比如给出一个不存在的“罗马使者谈话记录”。这类题的真实用法是你可以让模型以某一方的立场写一段简报看它是否能在约束条件下保持逻辑一致。比如让模型扮演“公元前 279 年皮洛士的军事顾问”解释要不要继续打罗马它如果只讲战争不讲政治决策就是不合格。2.3 第三类口供判断与自洽性——测逻辑一致性现在进入真正左右互搏的领域。这种题给的不是直接信息而是同一事件的不同史料版本让模型判断哪个版本可信、哪个版本是后来的修饰。我实际用过的题《史记》与《资治通鉴》对“赵高杀李斯”的记载在时间顺序上有出入。请你列举两处细节差异并判断这种差异对理解秦朝官僚体系意味着什么。这道题很损因为现代模型的训练数据里《史记》原文和《资治通鉴》原文都有但几乎没有专门讨论“两书在这个细节上的差异”的语料。模型必须真正读原文、比对事件先后、推断作者意图。结果如何呢我用 3 个模型跑这题有两个都出现了“记忆的缝合”——它们能把两段材料各自复述出来但要在“同一时间线上比对”就卡壳了。这不是巧合而是模型本质上是预测下一个 token它擅长在文本空间内保持风格一致但跨文本的锚定推理往往是不擅长的。这种题型特别适合检测 RAG 系统的路由能力把两段不同来源的史料分别做成文档块看模型能不能检索到并交叉比对。如果它只取第一段就开始回答你的 RAG 检索策略就欠优化。2.4 第四类跨领域联想题——测知识迁移这是高阶玩法。给的信息横跨多个领域但最终落在历史谜题上。这类题考验的是模型能不能把不同领域的事实“缝合”起来而不是在单一领域内死记硬背。实例启发我让模型做的题秦始皇统一度量衡涉及大量标准化工作。如果让你从现代供应链管理的角度分析秦朝“车同轨、书同文”政策在执行层面可能遇到的最大障碍是什么这里有意思的点是模型如果把“车同轨”理解成简单的“统一轮距”回答就停留在表层如果它能把“标准化”和“信息传递成本”连接起来提到地方工匠的培训、旧贵族利益抵抗、监察系统人手不足这才是真正从语义层面理解了这个事件。测过一轮之后发现即使中小模型也能对这类题说出一部分跨界概念但它们在事实连接处容易乱编——比如有人会凭空给出一个“秦朝推广代码”的错误细节。这不是模型的故意撒谎而是在知识迁移过程中“幻觉合成了”最相似的上下文字。3. 实操过程与核心环节实现从零跑通一套历史谜题测试3.1 准备环境与确定评测框架我实际操作时是在本地部署的 Ollama 环境下跑的操作系统是 Ubuntu显卡是一张 4090模型分别在 7B、14B、72B 三个量级各选了一个开源模型。不过不部署本地模型也没关系你在云端 API 上一样能完成这套实验。这是参数设置不同平台叫法略有差异本质是一样的temperature0.2防止输出过于随机同时保留一点发散top_p0.9max tokens2048system prompt不设置用空 system prompt避免指令偏差每个题跑 3 次取三次输出的差异性和稳定性而不是一次定论注意很多人在评测模型时忽略了一个关键变量——system prompt 设置。如果你在系统提示里写了“你是一个严谨的历史学家”模型的回答风格会完全改变它可能隐藏自己的不确定性。所以评测历史题时我建议system prompt 保持空白只把谜题作为用户输入让模型直接面对问题本身。3.2 设计统一可复用的测试模板与其每次临时写提示词不如固定一套模板否则不同提示词之间的差异会让测试结果失去可比性。我的模板如下请回答以下历史问题。回答要求 1. 先根据你掌握的历史知识给出直接的答案。 2. 区分“史实”和“推测”对推测部分明确标注。 3. 如果信息不足或存在多种说法请直接说“信息不足/证据不充分”不要编造细节。 4. 回答控制在500字以内。 问题{在这里填入谜题}这个模板看起来简单但每一项都有用意。要求 2 是在逼模型分层输出要求 3 是给模型留出“认怂”的空间要求 4 是为了控制输出长度避免长文本覆盖掉关键推理痕迹。3.3 实测记录同一套题跑三个模型下面是我用 4 道题对三个模型跑出来的代表性结果使用的模型信息已隐去重点是你看到这种差异模式就知道怎么判断了。测试主要集中在推理水平上得分以 0-10 计。题目类型模型A带RAG联动的API模型模型B开源14B模型C开源72B事件还原黑死病米兰封锁措施7分准确提到隔离船队但未区分同时期“空气瘴气说”6分把佛罗伦萨情况与米兰混在一起8分区分了两种医学解释身份辨析亚历山大与皮洛士8分叙述清楚策略差异4分直接简化成“胜率差异”7分缺少政治环境影响但基础史实准确口供判断《史记》与《资治通鉴》比对5分复述了内容但没比对时间线3分两书混为一谈6分指出了大部分差异但“缝合”细节明显跨领域联想秦朝标准化与供应链管理8分能用现代管理体系类比但细节有夸张5分概念堆砌7分说得稳妥但没有独特视角看完这张表我第一感受是你以为大的模型一定全面碾压其实不一定。模型A虽然是闭源 API但加了 RAG 之后在跨领域联想上表现最好模型C虽然大但某些题落入“稳妥但平庸”模型B在身份辨析上直接简化得离谱说明它对历史多因素归因的理解确实差。3.4 评分标准怎么区分“真推理”和“背答案”分数是主观的关键是盯住三个信号第一个信号是否区分“史实”和“推测”。真推理的模型会在每一步标注“目前史料显示”“据推测”。背答案的模型从头到尾只说“事实是”没有任何限定词。第二个信号是否主动承认信息不足。我测过的足够好的模型在遇到史料冲突的时候会说“此处证据存疑”而指标“正确”的模型最喜欢硬给一个说法。你要注意会承认不知道的模型比自信满满编造的模型靠谱得多。第三个信号是否有跨材料引用而不只是复述。以《史记》与《资治通鉴》那道题为例真正理解的模型会引用两本书各自的写法差异再说明为什么会有差异背答案的只会检索出“司马迁写于西汉、司马光写于北宋”这种通识。4. 常见问题与排查技巧实录4.1 模型一本正经地编造史料怎么堵住这个口子这是所有用历史题测试 AI 的人首先会遇到的问题。我给一个 7B 模型出“请描述尼禄时期罗马城的供水系统建設过程”它直接编了一个“公元 64 年大火后尼禄立刻任命塞内加监督水道扩建”的说法这明显是把两个人物的关系搞混了还加上了错误的细节。排查思路用“证据链”提示词压制幻觉而不是单纯说“不许编”。把第 3.2 节的模板里的要求 3 改得更严如果某段历史事件的细节并未被普遍接受或存在争议请直接说明“存在争议” 不要以权威叙事的方式陈述。只有在你能指出至少两个不同史料来源时 才能使用“可以确认”的说法。加了这一句之后同一模型的表现明显变差你不应该说“变差”是坏事——它在告诉你它确实不具备多源验证能力这是有用的评测结果。如果你的产品场景必须让它回答这种问题那你需要换模型或加 RAG而不是幻想靠提示词一劳永逸。4.2 模型被历史文本的语言风格“带偏”我跑历史谜题时有个特别有趣的经历用文言文问一个问题模型回答时突然切换到半文半白的风格还会模仿司马迁的口吻说“太史公曰”这类话。这看着很有“味道”但对评测没有任何用处反而掩盖了它实际的推理误差。原因在于训练语料中古文和历史文本常常以“仿写”的形式出现模型学习了“生成历史风格文本”这个模式而你要测的是它“理解历史内容”的能力。建议在提示词里明确加上一句用现代汉语口语化回答不要模仿古代文风。这能有效过滤掉“风格模仿型输出”让模型把注意力放回内容本身。4.3 温度太低模型变复读机温度太高开始胡编我的实测记录三项输出均来自同一个中等规模模型问的是“中世纪西欧修道院在经济活动中的角色”temperature0.1每次输出的回答几乎一字不差内容稳定但极端死板细节缺失。temperature0.5回答有一定差异但偶尔有一两句“灵感式内容”还行。temperature1.0输出差异极大有两次直接编了一个修道院的“酒坊专利”细节完全是幻觉。建议评测时先固定 temperature0.3-0.4每个问题跑 3 次。如果三次输出的核心事实高度稳定再考虑调高温度测试发散性。如果三次输出在关键史实上有不一致说明模型对这个知识点掌握不牢固。4.4 测试样本太少一次好回答让你误判这是最容易犯的错。我以前测试一个模型只用了 2 个认知难度较高的谜题结果它答得很好我差点就以为这个模型的历史推理能力碾压其他模型。换了一批题之后才发现那两道题在训练数据里出现过相似版本说白了它见过答案而不是会推理。所以我强烈建议第一次测试至少准备 8-10 道历史谜题涵盖前面说的四种类型每种至少 2 题。只有样本量上来你才能判断成绩到底是真实能力还是“撞上了熟悉题”。4.5 历史谜题评测速查表坑表现排查方式术语幻觉编造人名、制度名、数字换题重测检查是否出现同一实体在不同题中的张冠李戴风格模仿回答用古文或历史腔提示词明确要求“现代口语化”过度自信不确定的地方仍给出确切答复加“证据链”提示词观察是否主动承认不确定跨文本缝合两个史料混在一个语境里做两两比对型题目如《史记》与《资治通鉴》答案稳定但错三次输出一致但全是错的调整温度再跑或换一个模型交叉验证5. 从测试结论到产品决策这套方法如何落地到实际项目5.1 用评测结果反推模型选型我最终把历史谜题测试作为团队内部“模型能力回归”的一个固定环节。每次接到一个新的 API 模型或部署一个新开源的模型我第一时间不是跑 benchmark而是先丢给它 10 道历史谜题。为什么这么做因为历史谜题覆盖的能力维度非常均衡事实提取、逻辑推理、证据权衡、跨领域联想这几项恰恰是知识库问答、客服助手、文档分析等真实业务场景通用的能力。在通用能力没验证好的情况下指标刷得再好看都是空中楼阁。5.2 把历史谜题融入 RAG 评测如果你在做 RAG 应用历史谜题还有一个特殊价值它能有效检验检索质量。我在一个知识问答产品里做过实验把一批历史文本切成不同 chunk size然后用“口供判断题”去测检索效果。你会发现chunk size 太短时单段材料只能覆盖一半事实模型找不到足够证据来比对chunk size 太长时模型容易被干扰信息带偏。历史题的答案往往散落在多个段落中这恰恰是检索增强系统的压力测试。更实用的做法是故意把“出处信息”切成单独的 metadata 字段如果模型的回答能够指向具体出处说明 RAG 的引用链路是健康的。5.3 建立你自己的“历史谜题回归集”每季度更新一次你的测试集。为什么因为新模型训练时可能混入越来越多的网络讨论你今天设计的“防背诵题”半年后可能已经出现在别人的博客里被新的训练数据学会了。我的做法是保留 5 道基准题长期不变另外 5 道题每季度替换。基准题用于跨时间对比模型能力变化新题用于防止数据污染。建立回归集时注意题目来源最好是你自己从原始史料中整理的而不是直接抄维基百科的“历史疑难解析”页面。来源越偏门评测的可信度越高。6. 一些实测后的经验补充最后说几条心得体会。第一评测时要让模型“说过程”不要只说答案。历史题的推理链比结论重要得多。我实测发现有些模型虽然最终结论正确但它的推理过程里有明显的逻辑跳步——这在严格的历史研究中是不能接受的。第二同一模型不同版本之间的变化非常大。我之前测过一个 8B 模型它在 4 月版本里的推理能力明显弱于 9 月版本这提醒我在发布基于 AI 的产品时要特别关注模型升级带来的行为迁移好的要迁移错的也可能被迁移进来。第三这套测试方法的价值会随“大模型历史题题库”的公开而逐渐衰减。现在已经有开源社区尝试收集“AI 测不出来的历史题”一旦这些谜题被大规模引入训练语料它的测试价值就会降低。所以趁现在这套方法还有新鲜度赶紧建立起你自己的测试集和评测流程这比任何人推荐的“十大提问技巧”都更长效。我个人在实际操作中最深的体会是历史谜题测试不会告诉你哪个模型“更聪明”但它能很清楚地告诉你哪个模型在“装懂”。在如今这个各家 AI 都拼命展示自信感的时代能分辨“不确定”和“胡编”的模型才是真正值得放进生产环境的模型。