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 结构。先把“模型不能随便相信自己的输出”这个机制建起来后续所有功能都会建立在更扎实的基础上。