企业官网建设流程全解析

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 上一样能完成这套实验。

这是参数设置（不同平台叫法略有差异，本质是一样的）：

• temperature：0.2（防止输出过于随机，同时保留一点发散）
• top_p：0.9
• max tokens：2048
• system prompt：不设置，用空 system prompt，避免指令偏差
• 每个题跑 3 次：取三次输出的差异性和稳定性，而不是一次定论

注意：很多人在评测模型时忽略了一个关键变量——system prompt 设置。如果你在系统提示里写了“你是一个严谨的历史学家”，模型的回答风格会完全改变，它可能隐藏自己的不确定性。所以评测历史题时，我建议system prompt 保持空白，只把谜题作为用户输入，让模型直接面对问题本身。

3.2 设计统一可复用的测试模板

与其每次临时写提示词，不如固定一套模板，否则不同提示词之间的差异会让测试结果失去可比性。我的模板如下：

请回答以下历史问题。回答要求： 1. 先根据你掌握的历史知识给出直接的答案。 2. 区分“史实”和“推测”，对推测部分明确标注。 3. 如果信息不足或存在多种说法，请直接说“信息不足/证据不充分”，不要编造细节。 4. 回答控制在500字以内。 问题：{在这里填入谜题}

这个模板看起来简单，但每一项都有用意。要求 2 是在逼模型分层输出，要求 3 是给模型留出“认怂”的空间，要求 4 是为了控制输出长度，避免长文本覆盖掉关键推理痕迹。

3.3 实测记录：同一套题跑三个模型

下面是我用 4 道题对三个模型跑出来的代表性结果（使用的模型信息已隐去，重点是你看到这种差异模式就知道怎么判断了）。测试主要集中在推理水平上，得分以 0-10 计。

看完这张表，我第一感受是：你以为大的模型一定全面碾压？其实不一定。模型A虽然是闭源 API，但加了 RAG 之后在跨领域联想上表现最好；模型C虽然大，但某些题落入“稳妥但平庸”；模型B在身份辨析上直接简化得离谱，说明它对历史多因素归因的理解确实差。

3.4 评分标准：怎么区分“真推理”和“背答案”

分数是主观的，关键是盯住三个信号：

第一个信号：是否区分“史实”和“推测”。真推理的模型会在每一步标注“目前史料显示”“据推测”。背答案的模型从头到尾只说“事实是”，没有任何限定词。

第二个信号：是否主动承认信息不足。我测过的足够好的模型在遇到史料冲突的时候会说“此处证据存疑”，而指标“正确”的模型最喜欢硬给一个说法。你要注意，会承认不知道的模型，比自信满满编造的模型靠谱得多。

第三个信号：是否有跨材料引用而不只是复述。以《史记》与《资治通鉴》那道题为例，真正理解的模型会引用两本书各自的写法差异，再说明为什么会有差异；背答案的只会检索出“司马迁写于西汉、司马光写于北宋”这种通识。

4. 常见问题与排查技巧实录

4.1 模型一本正经地编造史料，怎么堵住这个口子

这是所有用历史题测试 AI 的人首先会遇到的问题。我给一个 7B 模型出“请描述尼禄时期罗马城的供水系统建設过程”，它直接编了一个“公元 64 年大火后尼禄立刻任命塞内加监督水道扩建”的说法，这明显是把两个人物的关系搞混了，还加上了错误的细节。

排查思路：用“证据链”提示词压制幻觉，而不是单纯说“不许编”。把第 3.2 节的模板里的要求 3 改得更严：

如果某段历史事件的细节并未被普遍接受或存在争议，请直接说明“存在争议”， 不要以权威叙事的方式陈述。只有在你能指出至少两个不同史料来源时， 才能使用“可以确认”的说法。

加了这一句之后，同一模型的表现明显变差，你不应该说“变差”是坏事——它在告诉你，它确实不具备多源验证能力，这是有用的评测结果。如果你的产品场景必须让它回答这种问题，那你需要换模型或加 RAG，而不是幻想靠提示词一劳永逸。

4.2 模型被历史文本的语言风格“带偏”

我跑历史谜题时有个特别有趣的经历：用文言文问一个问题，模型回答时突然切换到半文半白的风格，还会模仿司马迁的口吻说“太史公曰”这类话。这看着很有“味道”，但对评测没有任何用处，反而掩盖了它实际的推理误差。

原因在于训练语料中古文和历史文本常常以“仿写”的形式出现，模型学习了“生成历史风格文本”这个模式，而你要测的是它“理解历史内容”的能力。建议在提示词里明确加上一句：

用现代汉语口语化回答，不要模仿古代文风。

这能有效过滤掉“风格模仿型输出”，让模型把注意力放回内容本身。

4.3 温度太低模型变复读机，温度太高开始胡编

我的实测记录（三项输出均来自同一个中等规模模型，问的是“中世纪西欧修道院在经济活动中的角色”）：

• temperature=0.1：每次输出的回答几乎一字不差，内容稳定但极端死板，细节缺失。
• temperature=0.5：回答有一定差异，但偶尔有一两句“灵感式内容”，还行。
• temperature=1.0：输出差异极大，有两次直接编了一个修道院的“酒坊专利”细节，完全是幻觉。

建议评测时先固定 temperature=0.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 都拼命展示自信感的时代，能分辨“不确定”和“胡编”的模型，才是真正值得放进生产环境的模型。