十年匠心定制 · 商业建站与技术教学双线并行 咨询热线:400-886-1026 service@lmnt.cn
ARTICLE DETAIL

资讯详情

深耕网站建设与运营推广的一线实战洞察。

从46%到4%:谷歌Co-Scientist如何用验证流程击穿AI幻觉

从46%到4%:谷歌Co-Scientist如何用验证流程击穿AI幻觉 最近让我停下手头 prompt 调试的不是某个新模型发布而是一组来自 Google 论文的数字Co-Scientist 加入可靠性模块后在论文结果类任务上的幻觉率从 46% 降到了 4%。先说明一下背景。Co-Scientist 是 Google 面向科研场景推出的多智能体系统目标不是让 AI 直接写一篇论文给你而是帮助研究者生成假说、设计实验、筛选文献、评估新研究方向。它从一开始就不是“一个问答机器人”而是把生成、质疑、排序、演化、评审这些动作拆给不同角色去做想模拟的其实是科研协作里的讨论和交锋过程。那这组数字为什么要单独拿出来说因为论文结果幻觉率 46%基本等于系统生成的内容里有接近一半的结论和相关结果表述与真实证据不符。可能来自模型自己对文献的“记忆缝合”可能在原始文献里根本查不到出处也可能把一篇文献的结论理解成了相反的意思。降到 4% 之后输出的可信度才算真正从“不能直接用”进入“可以辅助判断、需要抽查复核”的区间。这里我想先亮一个判断46% 到 4%核心并不是模型底层能力突然变强而是系统里增加了一条“验证链路”。这件事对普通开发者、研究者、内容生产者都有借鉴意义。本文就围绕这个判断展开。1. 先从一组数字说起46% 到 4%差的不是“智能”是验证流程1.1 论文里的“幻觉”和聊天时的幻觉不是一回事机器翻译、营销文案、剧情生成里的幻觉往往只是“语句通顺但事实有误”用户判断成本低看两眼基本能发现。但论文结果场景里幻觉的危害会被放大很多倍它的输出通常带有严肃的学术外壳有结论、有因果、有引用、有统计分析读者很难第一眼判断哪一层出了问题。常见的论文结果幻觉包括几种典型形态引用了不存在的文献或者把一篇真实文献的结论张冠李戴对实验数据做了模型自己脑补的“解读”但解读方向违反统计常识生成了看似合理的对照实验但该实验在原始材料里根本没有出现把两条文献结论强行拼在一起表达出一个从未被研究支持的因果断言。这些错误比“多了一个错别字”严重得多因为它直接污染研究过程中的判断依据。研究者拿着这样的结果去做下一步推导就等于在软地基上盖楼。所以也不难理解为什么论文类 AI 系统最需要的不是“更会说”而是“先证明你说的话有出处”。1.2 46% 的基线到底意味着什么单看 46% 这个数字容易误判成“这个模型太差了”。但如果你拿真实科研场景来对照会发现这个比例并不反常。原因在于科研任务里的“结果”通常不是一句事实而是一整套需要多步推导的结论。模型可能在中途某一步检索到一篇不相关的文献也可能在判断因果关系时偷换概念。任何一个环节出错最终输出都会被算进“幻觉结果”。所以基线偏高往往不是模型在胡编而是任务本身的验证链条比普通问答长很多。正因如此把幻觉率压到 4% 是一个很典型的“工程胜利”。它回答了一个长期被讨论的问题与其反复换更大的模型、加更长的 prompt不如给系统装一个显式的质量闸门。一个我在实践里反复验证的判断降低幻觉率最有效的不是“让它更自信”而是“让它先过一道证据关”。2. 可靠性模块到底“可靠”在哪里2.1 Co-Scientist 这类多智能体系统本来是怎么组织科研工作的从公开的架构介绍来看Co-Scientist 这类系统的核心特征是“多智能体多阶段评审”。它通常包含负责提出想法的生成型智能体负责挑刺和反思的评审型智能体负责对假设排序的评估型智能体还会安排一些智能体负责模拟历史文献、逼近真实研究者的思维过程。外部还有一个主持人式的模块负责汇总和分发任务。这种形态很像一个科研小组的开会流程有人先提出草案其他人负责质疑、补证据、找反例最后大家投票决定哪些想法值得继续往下做。但只有这一步还不够。因为智能体之间的辩论解决的是“想法是否新颖”“是否符合已有逻辑”的问题并不能自动保证“每个结论都被真实证据支持”。一个模型如果想说服另一个模型它依然可以编造一个不存在的实验作为支撑而对方的批判能力也存在同样的盲区。于是就有了这次讨论的关键设计可靠性模块。它相当于在“生成—评审—演化”这条主流程之外再增加专门面向真实证据的校验层。2.2 可靠性模块要完成的四件事拆解、检索、比对、裁决我没有拿到论文里模块的源码级细节但从这类验证框架的通用思路来看把幻觉率从 46% 压到 4%通常需要完成下面四个步骤第一拆解。系统不能直接对一个长段落做“是/否”判断而是要把模型的生成结果拆成最小的事实断言。一个段落可能包含三五个论断其中可能有真有假。只有把论断拆到足够细后续的检索和比对才有意义。第二检索。每个断言都要送去外部证据源做检索。这里的检索不是为了找“看起来像相关”的内容而是为了建立“这条断言到底对应了哪一条原始文献、哪个实验、哪组数据”的映射。第三比对。检索到结果只是第一步更关键的是把模型生成的断言和检索到的证据放在一起做理解级对照。它不是简单的关键词匹配而是要看证据是否真正支持这个断言是否存在上下文被截断导致的误读。第四裁决。基于比对结果给每条断言打一个可信度标签。常见的做法分为三档完全支持、部分支持/证据不足、明确矛盾。对证据不足和明确矛盾的输出系统会退回生成模块要求重写或者直接阻止它进入最终结果。一个可参考的验证流程示意不是论文原文实现 输入模型生成的一段结论 - 拆解成 N 个独立事实断言 - 逐个断言调用检索 - 检索结果与断言做证据比对 - 输出裁决支持 / 不支持 / 证据不足 - 低于阈值的结论进入“待重写”队列这个流程的关键不是某一个模型变强了而是把“被验证”变成输出必须经过的关卡。只要最终结果里出现的每条论断都经过外部证据比对幻觉率自然会大幅下降——因为模型没有机会带着一条空口无凭的结论走出系统。2.3 为什么“验证路径”比“更大模型”更能压低幻觉过去两年很多人对“降低幻觉”的默认解法是等下一代更聪明的模型。下一代模型确实在事实性上有所提升但只依赖模型自身知识去判断自己是否正确本质上是在做“自己给自己监考”。有一个很容易被忽视的细节幻觉率的瓶颈不一定来自生成能力而是来自“模型对自己不确定的内容缺乏暴露机制”。一个模型可能知道某篇文献不存在但它在生成时为了让行文更顺畅依然倾向于把模糊记忆包装成确定结论。这种情况下再大的模型也只能降低概率无法消除路径依赖。可靠性模块的做法不同。它把“事实是否正确”这个判断依据从模型内部记忆转移到了外部证据。生成模型可以先“不管对错”地提出假设校验模块再去把它和真实世界对接。从工程角度看这属于用算法结构去约束模型输出比在同一个模型里同时做生成和反思更可靠。这也解释了一个常见疑问为什么有了可靠性模块之后不是直接把模型换成一个更强的模型因为目标不是“生成更流畅”而是“能被核验”。流畅度是生成层的目标可核验性是流程层的目标两者不应该混为一谈。3. 这个思路可以借鉴到普通工作流如果你不做科研也没准备搭一套多智能体系统上面这些东西看起来可能有点远。但 Co-Scientist 的可靠性模块代表的方法完全可以迁移到普通内容生产、调研报告、代码注释、产品需求文档等任何“需要输出可验证结论”的任务里。3.1 一个可复用的三阶段管线拆解、取证、终审我不建议普通用户一开始就去实现复杂的多智能体架构。更务实的路径是把可靠性模块拆成一个轻量工作流。第一阶段拆解。拿到模型输出后不要直接通读修改而是先把内容拆成独立句子。尤其在报告、方案、技术说明这类文体里每一句都可能在陈述一个事实。把这些句子单独列出来你才能看清楚哪些地方其实没有证据支撑。第二阶段取证。对每个关键论断做一次“证据标注”。标注可以是人工执行也可以结合检索工具半自动执行。你需要为每个论断找出至少一条支撑材料。如果找不到出现两个选择删掉这句话或者把它改成有明确来源的表述。第三阶段终审。标准很简单一段内容里如果核心结论缺少支撑标记就不允许进入交付版本。这个阶段最忌讳“整体感觉还行”它要求你把质量控制落到每一句而不是给整段内容打一个印象分。对大多数写作和调研类任务来说这一套流程就能复现可靠性模块 60% 以上的效果。它真正改变的不是模型而是交付习惯把“看起来对”变成“有据可查才叫对”。3.2 成本与体验之间需要做分层有人可能会问如果每个输出都要拆解、取证、终审那效率和成本都会成问题。这个担心是对的。现实中也不应该对每类输出都无差别启用完整验证。更合理的方式是做分层输出类型验证必要性建议做法会议速记、脑暴草稿、待办整理低直接使用无需完整验证内部技术方案、架构评审文档中对关键论断抽查文献和版本对外发布的技术博客、产品说明高每个事实断言单独标注来源科研成果、临床摘要、投资分析很高强制完整验证流程工程上通常把幻觉治理当作一个有成本的质量动作。你可以先在小范围、高价值场景里启用跑通后再逐步扩大适用范围。千万不要一上来就写一个巨复杂的校验框架结果两周之后因为维护成本太高放弃。3.3 实际落地最容易踩的三个坑参考我在这条路上踩过的坑给你三个提醒。坑一把“检索到内容”当成“内容支持结论”。很多人在验证环节只做到“我搜到了相关页面”就认为这条论断通过。但检索相关性不等于证据一致性。搜到一篇论文摘要不代表这篇论文支持你的表述有时候恰恰相反。正确的做法是强制进行理解级比对模型生成的这句话和检索到的原文在逻辑上到底是不是一个意思坑二用同一个模型既做生成又做校验。如果生成和校验用的是同一套模型你只是在让同一个盲区自己检查自己。可靠性模块之所以有效一定程度是因为校验层使用了独立于生成过程的机制。普通场景里可以让不同模型分工或者至少引入外部检索工具让校验不完全依赖内部记忆。坑三只做“结果拦截”不做“过程修复”。裁决出“这句话有问题”之后如果只是把它标红删掉其实没有发挥验证的复利价值。更好的做法是把失败样本收集起来分析哪一类论断最容易出错、哪类源文本最容易被误读然后把这些总结写进下一轮的 prompt 或校验规则里。我的经验是把“一次拦截”变成“规则沉淀”才能真正拉开和普通 AI 协作方式的差距。4. 别把 4% 当成“可以放心用”的安全线4.1 这组数据能说明什么又不能说明什么需要先明确一个边界46% 到 4% 是论文实验里报告的结果不是所有场景、所有模型、所有数据集上都必然复现的数字。幻觉率的定义方式、测试任务难度、外部知识库覆盖程度、评测时使用的判定标准都会对最终数字产生明显影响。所以正确的理解方式有两个第一这组数据证明了“验证链路”这套方法论有效而且效果显著。即便在不同任务上数字会有浮动方向是有参考价值的。第二不要看到 4% 就觉得“AI 论文结果已经可靠到不用审了”。4% 意味着平均 100 条结果里还有 4 条需要发现和处理。如果这 4 条恰好命中了你最在意的研究环节没有人工复核流程损失仍然可能很大。更合理的预期是可靠性模块把幻觉率从“高到不可用”降到了“低到需要抽查”。它不是替代人的判断而是把人的精力和注意力集中到少部分高风险内容上。4.2 从结果拦截到过程校验再到组织约束放到更大视野里幻觉治理不应该只停留在单次模型调用层面。我一般把它分成三个层级。第一层是结果拦截。就像可靠性模块做的那样在输出端检查每一个论断不合格就拦截或退回。这一层最直接见效也最快。第二层是过程校验。在生成阶段就使用检索增强、结构化证据、显式引用这类手段让模型在生成过程中就开始接触真实资料而不是全靠内部记忆。过程校验能降低后续拦截的压力因为它从源头减少了胡编材料进入表达的概率。第三层是组织约束。当一个团队或项目开始长期使用 AI 生成的研究性内容时需要建立质量规范哪些输出必须经过人工复核哪些领域要强制引用来源验证流程的日志要不要保留历史版本如何回溯。这些都不是模型层能解决的却是“长期可信任”的必要条件。一个只做第一层的系统适合实验和短期任务想长期依赖它做判断就一定要把第二层和第三层补齐。4.3 下一步最值得关注的三个方向基于可靠性模块这个方向我觉得有三个问题值得持续关注。一是评测标准。目前不同论文、不同团队对“幻觉率”的定义并不统一。未来如果出现一个被广泛接受的科研事实校验基准不同系统的能力才真正可比较。二是证据可追溯性。现在很多系统能告诉你“结论有支撑”但未必能告诉你“证据链是怎么走完的”。如果验证过程本身不可审计那校验结果的可信度依然有限。证据版本、检索时间、匹配逻辑都需要归档。三是效率和成本。可靠性模块不出意外会增加大量检索、比对、多模型判断的开销。如果未来能把验证模块压缩到更小的模型上普通开发者才能在真实工作流里广泛使用它。5. 从“会生成”到“敢交付”评判标准变了Co-Scientist 这组数据真正有启发的地方不是“Google 又做了一个厉害系统”而是它改变了一个基础评判标准我们评判一个 AI 助手不再只看它能不能生成像样的结果还要看它能不能证明自己的结果经得起查证。过去很长一段时间大家对 AI 工具的期待是“你负责快点出活我负责把关”。这种模式里AI 更像一个低成本的初稿生成器人的价值主要体现在后续修改。可靠性模块出现后这个分工开始变化AI 不仅要出活还要在流程里主动标记哪些内容可信、哪些内容存疑、哪些内容需要人确认。人的角色从“从头审一遍”变成“抽查高风险点”。对普通用户来说最值得做的不是等待厂商把“可靠性”做成默认功能而是先把这套思路内化成自己的工作流。无论是写技术文章、做调研报告还是让 AI 辅助设计实验你都可以问同一个问题我敢不敢给这句话标注一个真实的来源如果答案是不敢那这句话就不应该出现在最终交付物里。这个朴素的习惯可能比任何模型参数都更能决定 AI 工作流的可信度。
返回列表