Co-Scientist 可靠性模块能把论文结果幻觉率从 46% 降到 4%，这个数据最值得关注的不是“AI 进步了”，而是它第一次把科研场景里的幻觉问题当成一个可量化、可验证、可拦截的工程问题来处理。对于正在做 RAG、智能体、自动报告生成，或者任何用大模型产出严肃内容的人来说，这套思路比“换更大模型”更有参考价值。我准备从问题根源、可靠性模块的设计逻辑、评测方法和可迁移的工程经验四个角度拆开讲。
1. Co-Scientist 可靠性模块到底解决什么问题
1.1 AI 写论文或研究结论时，真正的风险是“看起来合理但结果不存在”
LLM 生成内容时有一个天然特点：它追求的是“文本层面的连贯和自洽”，而不是“事实层面的成立”。在聊天场景里，这种偏差最多让你觉得回答不够准确。但到了科研场景，问题会被放大很多倍：模型可能引用一篇不存在的论文，可能把两个实验的条件记混，可能根据一个统计学上不显著的数据点推出一个看起来很漂亮的结论。
很多时候，这种错误不是模型“没有数据”，而是它在组合已有知识时，把相关性写成了因果性，把推测写成了确定性。普通人阅读一段文字时，很难在看到结论的同时快速核对每一个出处、参数和样本量。于是模型生成的研究结果就会披着“论文格式的外衣”通过人的初筛。
Co-Scientist 这类系统之所以需要一个独立的可靠性模块，核心原因就在这里：生成能力越强，格式越像论文，越需要有一个不相信生成结果的检查环节。
1.2 46% 到 4%，是一个工程化验证层的收益，不是模型能力提升的收益
如果只看标题，容易误以为这是换了更好的大模型，所以幻觉率下降了。但更合理的理解是：Co-Scientist 把“生成”和“验证”分成两个独立阶段。生成模块负责提出假设、组织论证；可靠性模块负责对生成结果进行怀疑、校验和过滤。
换个容易理解的说法：你不能让一个写文章的人同时担任自己的审稿人，因为他在心理上会对自己的行文逻辑有很强的惯性。可靠性模块要做的，就是找另一个视角，专门盯着论文里“结果数据是从哪里来的、能不能复现、参考文献是否真实、推断是否超过数据支持范围”这些问题。
46% 到 4% 的下降说明，绝大多数被生成模块“自信地写出来”的不可靠结果，是可以被一套针对性的验证规则识别出来的。那些剩下 4% 的漏网之鱼，才是真正难处理的硬骨头。
1.3 先建立三个判断标准，再谈相信 AI
看这类系统时，我一般会先问三个问题。
第一，这里的“幻觉率”是怎么定义的。是指生成的整篇论文完全虚构，还是指论文里存在一处不真实的数据引用？这两种定义下，统计结果会差很多。
第二，下降后的 4% 是在什么测试集上得到的。如果测试集里主要是常见实验范式，可靠性模块可以靠检索知识库拦截掉很多错误；到了真正冷门的学科前沿，知识库里没有答案，拦截难度会明显上升。
第三，可靠性模块拦截后，被删掉的内容里有没有包含正确的创新点。如果为了追求低幻觉率，把所有没有依据的新想法都过滤掉，那科研助手就变成了一个复读机，失去了辅助探索的价值。
所以这篇文章里最值得吸收的，不是“Co-Scientist 多厉害”，而是它如何通过模块化设计，在生成结果和最终输出之间加了一道可度量的防线。
2. 可靠性模块背后的工程链路：从生成、自检到证据核验
2.1 为什么要把生成与可靠性拆成两个模块
把生成和验证拆开，是这套设计里最重要的一步。
如果让同一个模型在生成时同时自我检查，效果往往不稳定。原因不难理解：模型在生成后续内容时，已经被前文带入了固定的叙事方向，它很难中途停下来质疑自己刚刚写出的样本量是否正确、结论是否站得住脚。
独立的可靠性模块则不同。它接收到的是一段完整的、已经生成的文本，它的任务只有一个：尝试证伪。证伪这个动作天然需要“外部知识”和“逻辑规则”参与，而不是靠生成时的语言惯性。
在工程落地时，这种拆分还有一个好处：生成模块和可靠性模块可以分别升级。生成模块用更大更新的模型，可靠性模块则可以引入搜索引擎、知识图谱、论文数据库、领域规则，甚至人工审阅。两者耦合度低，迭代和排障都更快。
2.2 常见的可靠性校验方式
虽然原始材料没有给出详细实现，但一个针对科研论文的可靠性模块，通常需要覆盖至少四个层面的验证。
第一层是事实来源核验。模型生成的内容里出现实验数据、论文引用、统计结果时，系统会去检索真实数据库或可信知识源，比较引用是否存在、数字是否一致。很多看起来惊人的结论，在这一层就会被发现是“编造了参考文献”或“张冠李戴”。
第二层是内部一致性核验。模型可能会在一段话里说样本量是 100，在另一段话里又说整个实验由 80 个样本完成。这种矛盾不涉及外部知识，是纯文本层面的逻辑漏洞，也最容易通过规则模型识别。
第三层是统计推断边界核验。即使实验数据是真实的，可靠性模块也要检查结论是否超出了数据能够支持的范围。比如相关数据不能直接写成交互影响，单组实验结果不能直接推广到全体人群。
第四层是领域专家规则核验。科研领域往往有很强的格式和专业规范，比如对照组设置、效应量报告、伦理审查号等。可靠性模块可以把这些规则写成检查器，对生成内容做硬性约束。
2.3 “论文结果幻觉率”怎么定义和评估
幻觉率不是幻觉。评估它的第一步是把概念操作化，也就是明确“什么样的输出算一次幻觉”。
比较常见的定义有两种：一种是按论文粒度统计，生成的论文若包含一个虚构引用或关键数据错误，就算一篇幻觉论文；另一种是按语句粒度统计，评估模型生成的每一个陈述句是否都能被真实资料或合理逻辑支持。按第一种计算，更接近于题目中“论文结果幻觉率”的口径；按第二种计算，能更细致地定位错误类型。
评测时一般先准备一个人工审核的测试集。把模型生成结果交给领域专家，专家对照真实数据和文献来源，逐条标注哪些是可信的、哪些是编造的、哪些是推断过度的。再将标注结果作为金标准，计算模型评价指标与人类判断的一致性，最后算出幻觉率。
2.4 判断可靠性模块是否有效，不能只看下降率
一个可靠性模块如果把 100 条结果全部拦截掉，幻觉率也可以降到 0，但系统就变得没有任何价值。所以评估时必须同时关注两个方向：
- 精确率：被判定为可靠的内容，是不是真的可靠。
- 召回率：真正可靠的创新内容，有没有被错误误杀。
一个成熟的可靠性模块，在报告“幻觉率下降”时，应该同时报告误杀率或保留率。如果幻觉率从 46% 降到 4%，但有效假设的保留率也从 80% 掉到 40%，那就说明验证规则过严，生产环境里没法使用。
| 指标 | 含义 | 关注点 |
|---|---|---|
| 幻觉率 | 不可靠结果占总生成结果比例 | 越低越好，但要与保留率一起看 |
| 可靠结果召回率 | 可靠内容中多少被保留下来 | 防止把创新想法误删 |
| 人工接受率 | 人工审阅后认可的结果比例 | 能反映系统真实可用性 |
| 单条验证耗时 | 每次验证需要多长时间 | 决定能否应用于大规模生成 |
3. 这种可靠性设计能迁移到日常 AI 工作流吗
3.1 不只是科研场景需要可靠性模块
很多人看到 Google 论文，会觉得离自己太远。实际上，任何让 LLM 直接输出“结论型内容”的场景，都存在类似的幻觉风险。
举几个常见例子：
- 开发者在项目里让模型根据代码仓库生成技术方案，模型很可能会虚构不存在的 API 或过时的依赖版本。
- 运营同学让模型根据销售数据写复盘报告，模型可能把一个未经验证的字段当成核心指标来解读。
- 产品经理让模型总结用户访谈，模型可能把不同受访者的表述合并成“用户普遍认为”。
这些场景都没有论文那么严肃，但错误逻辑是一样的：生成结果如果缺少一个外部核查环节，轻则返工，重则误导决策。可靠性模块要解决的不只是论文造假问题，而是“生成式系统如何对现实负责”的问题。
3.2 迁移思路一：给答案加上依据、置信度和限制条件
最容易落地的一步，是强制要求模型在给出结论时列出依据来源和置信程度。
我在实际使用中会这样设置指令：当模型需要回答事实性内容或做出推断时，先输出“依据”，再输出“结论”，最后输出“可能的例外情况”。依据可以来自用户输入的上下文、本地数据库或网络检索结果。如果模型找不到依据，就明确标注“当前资料不足”，而不是强行编一个。
这条规则之所以有效，是因为它把一个隐性问题变成了显性问题。模型如果被迫说清楚“我为什么这么判断”，它自己就会减少很多无依据的编排。
3.3 迁移思路二：用另一种模型或规则做独立的红队复核
Google 把可靠性模块从生成模型里拆出来，思路同样适用于日常工作流。
一个比较直接的做法是：让模型 A 负责生成答案或报告，让模型 B 负责审校。模型 B 接收到的任务是专门找出模型 A 输出里的错误，比如引用不存在、数字与资料不符、结论超出依据范围。两个模型之间没有共享生成链路，相当于做了一次交差验证。
这种方法不需要复现 Google 的完整系统，只需要在代码里串联两次调用。如果为了控制成本，也可以不让模型 B 全部重新分析，而是只用几个规则检查器，比如“正则表达式检查参考文献格式”“调用搜索 API 检查关键名词是否存在”“用语言模型检查前后文是否存在数字矛盾”。
3.4 迁移思路三：把输出拆成可核验的最小单元
可靠性校验最怕的是“整段判断”。因为一段话可能包含六个事实点和两个推断，如果只给整体一个可信度分数，很难判断错误出在哪里。
更合理的做法是把输出内容拆成最小断言单元，逐条核验。举个例子：
- 模型结论：“A 方案的转化率比 B 方案高 12%。”
- 拆开后可核验点包括：是否存在 A 方案和 B 方案？数据来源是否显示 12% 这个差异？统计口径是否相同？结论中的“高”是统计显著还是有误差范围？
在我的经验里，只要把输出拆细，可靠性模块的设计思路就会清晰很多。每个断言对应一个验证器，整体幻觉率自然就会降低。Google 的可靠性模块能产生显著效果，很可能也采用了类似的细粒度拆解方式。
4. 从 46% 降到 4%，有哪些容易踩的坑
4.1 第一个坑：只看下降率，不看测试集有多难
任何评测都要回到测试集本身。如果测试问题都比较简单，比如常见知识、公开论文、成熟领域的标准实验，那么让可靠性模块检索知识库就能解决绝大多数幻觉。这种情况下，20% 到 2% 的下降都算不上了不起。
真正考验系统的，是测试集里包含大量“模型不知道但装作知道”的问题。例如：
- 最新才发表的论文，模型预训练数据里根本没有。
- 小众领域的术语，公开资料很少。
- 研究结论需要综合多篇论文，而不是单一事实可判断。
所以看到“降到 4%”时，我会先去想：测试集里有多少是这种高难度问题？如果不清楚，就不能直接得出“所有场景下都能降到 4%”的结论。
4.2 第二个坑：幻觉率的计算口径不一致
可靠性模块上线之前，必须有人专门定义清楚“幻觉”的归类标准。
不同人评同一段内容，很可能给出不同结论。比如模型把“实验发现温度升高会加速反应”写成了“温度升高会显著加速反应”，增加的“显著”是否算幻觉？模型在一篇综述里引用了领域内一致共识，但没有标注具体文献，这算不算“引用缺失”？如果评测者之间标准不一致，前后两次迭代对比就没有意义。
我的建议是：在项目开始前先做一个标注规范，包含定义、例子、边界情况和投票规则。至少选几名标注者分别标注同一批数据，计算标注一致性。只有标注稳定了，后续计算出来的幻觉率才有参考价值。
4.3 第三个坑：为了降低幻觉，误杀了真正的创新内容
科研场景里，很多有价值的信息并不能直接写在公开论文里，它可能是逻辑推导的结果，是基于已有实验组合产生的新假设。这类内容的可靠性，很难用“检索是否命中”来判断。
如果可靠性模块只会执行“没有外部证据就拒绝”，那么它能防住大部分幻觉，但也把所有没人研究过的新想法挡在门外。一个真正面向科研辅助的系统，要区分三种情况：
- 论据错误：引用不存在、数据算错。这种情况必须拦截。
- 推断脆弱：有一定依据但逻辑链不够完整。这种情况不应该拒绝，而应该降低置信度并提示核查方向。
- 合理创新：依据两个已知领域的理论和实验，推出了新组合。即使没有直接论文支持，也应该保留，但标记为“假设”而非“事实”。
可靠性模块的核心目标是防止系统把假设包装成结论，而不是禁止假设本身。
4.4 第四个坑：验证模块本身的错误没有被检测
可靠性模块也是模型或规则组成的，它同样会出现误判、漏判。尤其当验证器依赖检索时，如果检索结果切题不准、数据源存在错误，就会把真实内容标记为错误，或者把错误内容判定为可信。
所以，凡是引入可靠性模块的项目，都应该单独记录验证模块的“误判案例”。比如模型明明是对的，但验证器因为关键词搜索匹配到了别的领域，把它标记为虚构。这种问题看起来是小概率，一旦在特定领域高频出现，会严重伤害整个系统的可信度。
我在跑这类流程时，会定期抽样查看被拦截的内容，把误杀样本放到一起分析，然后调整验证器的触发条件和提示词。
5. 想在自己的项目里复现这种可靠性模块，怎么落地
5.1 第一步：拆任务，分类别，定义高/低风险场景
先不要急着写代码。先把你的项目里“模型生成了什么、错误会造成什么后果”写清楚。
不同业务场景对幻觉的容忍度完全不一样。搜索结果摘要里有个别错误，用户可能觉得无所谓；医疗建议或金融报告里出现错误，代价就很高。可靠性模块的复杂度和成本，应该按照“生成内容的风险等级”来设计，不能全项目一刀切。
对低风险场景，只做基础提示词要求即可；对高风险场景，至少要有独立检查和人工兜底；对中等风险场景，可以先接入简单的规则校验。
5.2 第二步：给每类输出建立三个层面的验证器
根据我在实际项目里的经验，一套可以工作的可靠性模块通常由三层验证器构成。
第一层是格式验证器。负责检查字段是否完整、数字格式是否正常、引用格式是否统一、是否有重复段落。这类检查成本极低，用规则或正则就能实现，适合放在最前面。
第二层是知识验证器。可以是搜索 API、知识库查询接口或向量检索库。它的任务是找到每一条核心结论的外部依据，并计算依据与结论的匹配度。匹配度低且结论又使用肯定语气时，就把输出标记为“待人工复核”。
第三层是逻辑验证器。用规则或者大模型检查前后一致性。比如前面说要统计 100 个样本，后面却写 90 个，就是逻辑层的问题；如果结论说“显著提升”，而后文数据集里没有对照组，就要标记推断过度。
5.3 第三步：为“幻觉”建立可量化的检查清单
每个项目都应该有一份字段级的检查清单，而不只是一个整体评分。比如一个自动生成的研究摘要，可以拆成以下字段：
| 字段 | 检查项 | 是否通过 |
|---|---|---|
| 研究背景 | 是否包含对现有研究的概括 | 检查概括是否有文献依据 |
| 方法描述 | 是否说清样本量、分组方式 | 检查是否与数据文件一致 |
| 结果数据 | 核心数字是否来自输入数据 | 检查是否被模型改写或扩充 |
| 结论表述 | 结论是否支持真实数据 | 检查是否带有限定语 |
| 参考文献 | 引用是否真实存在 | 检查文献名称、作者、年份 |
这样设计的好处是，即使模型输出整体看起来很通顺，系统也能按字段从某个角度发现具体问题。
5.4 第四步：先跑小范围测试，再做回归对比
可靠性模块上线时可能引入新的误判，最好的方法是先小范围测试。
做法比较简单：选过去一段时间里已经由人工确认过的样本，把它们同时送入“没有可靠性模块”和“有可靠性模块”两套系统。对照两类结果，看可靠性模块是否降低了幻觉率，是否误伤了一些原本正确的内容。这个测试集还可以作为未来的回归测试集，每次改动后都用它跑一遍，防止一个地方的修正引发另一个地方的错误。
常见情况下，第一次接入可靠性模块时，幻觉率确实能明显下降，同时误杀率也会上升。所以需要做一些微调，让错误判断集中在对业务最关键的问题上。
5.5 第五步：记录失败样本并持续更新验证器
我在之前的项目里有一个体会：可靠性模块不是一次性搭完就结束的，它更像一个规则库，需要被持续维护。
每当你发现模型输出的错误没有被验证器拦截下来，都应该做两个动作。第一，判断这个错误能否被一条新的规则覆盖；第二，把出错样本加入回归测试集。重复几次以后，拦截能力会越来越接近你真正希望达到的水准，而不是只解决几个一眼就能看出的典型问题。
6. 如何正确看待 Google 这篇论文带来的价值
6.1 别只盯住 4%，要关注“可靠性能否成为可评测的属性”
Co-Scientist 可靠性模块最大的贡献，是把“减少 AI 幻觉”从一句口号变成了一种可以测量和迭代的系统能力。
过去讨论 AI 幻觉时，常停留在“这个模型容易编数据”“那个模型相对更严谨”这种模糊判断上。有了可计算的幻觉率，团队就可以建立评测基准，把“模型输出是否可信”纳入产品迭代的必需指标。这一点对任何使用 LLM 的团队都有借鉴意义。
与其问“这个系统能达到多低的幻觉率”，不如问一句：“我在发布新版本之前，有没有一份测试集可以证明当前输出比上一个版本更可靠？”
6.2 可靠性模块不是万能盾牌，它只能降低已知类型的错误
要注意的是，“幻觉率降到 4%”并不代表系统已经把真实世界完全纳入掌控。那些剩余 4% 的错误往往更隐蔽，也更难处理。
比如模型可能在多个断言均真实的情况下，把因果顺序弄反；可能在统计结果正确的情况下，选择了一个不适合该数据的统计模型；也可能输出了可靠但不重要、不相关的内容，浪费了研究人员的时间。这些问题都不是简单的“引用核验”或“检索比对”能解决的。
Google 把可靠性模块作为一个公开论文中的设计思路，真正意义在于提醒大家：可靠性不是模型自带的安全属性，而是需要投入资源去构建的一层系统防御。生成结果越重要，这层防御就要越认真。
6.3 对普通研发者，这是我建议的行动项
我没有办法从这个标题里确认 Google 论文具体的代码实现、评测数据集或是否开源。所以以下只从通用实践出发给建议。
如果你也在做 AI 相关工具，可以先从一个小切口开始：找一个你认为“模型常常编造内容”的模块，把输出结果全部记录下来，人工标注其中哪些是幻觉，挑出最典型的十个错误样本。然后再为这十类错误分别设计验证器。
这个动作做完，你大概率会得到一个比现在靠谱得多的系统。原因很简单：可靠性改进并不神秘，它本质上是“知道错误长什么样，然后阻止它发生”。Google 的 46% 到 4% 是系统性的结果，但每一部分落在工程上，都是一个一个验证器和一条一条规则累积起来的。
我个人更建议先把单条生成链路跑稳，再考虑增加模型参数量或复杂 Agent 结构。先把“模型不能随便相信自己的输出”这个机制建起来，后续所有功能都会建立在更扎实的基础上。
