近年来AI 辅助科研已经成为大模型落地的重要方向之一。从文献调研到实验设计再到代码生成大模型正逐步进入科研工作流。但一个始终绕不开的问题也随之浮出水面AI 生成的内容到底可不可信尤其在论文复现、结果验证这类对准确性要求极高的场景里模型输出的“一本正经胡说八道”会让研究者付出巨大的时间代价。Google 近期公开的 Co-Scientist 系统相关论文中有一个数据引起了广泛关注加入可靠性模块后论文结果的幻觉率从 46% 降到了 4%。这个降幅非常惊人也让人好奇它背后的实现思路到底是什么。本文不打算只做新闻式转述而是结合论文的关键设计拆解 Co-Scientist 的工作方式、可靠性模块的定位以及这套方案对普通开发者在构建 AI Agent 时的可借鉴之处。1. 背景AI 科研助手为什么总在“编结果”1.1 什么是 Co-ScientistCo-Scientist 是 Google 提出的一个面向科研场景的多智能体 AI 系统目标是辅助科学家完成从假说提出、实验设计到结果分析的完整研究流程。它不是在单个提示词里完成所有工作而是通过多个具有不同职责的智能体协作围绕一个研究问题不断提出方案、评价方案、完善方案。这套系统的基本工作方式是这样的输入层研究者提供一个开放性的科学问题例如“某种疾病是否存在新的靶点”“某类材料的合成路径是否可以优化”。生成层系统会生成多个候选假说或研究思路。评价层通过模拟对抗、评审等机制对候选思路进行打分和排序。迭代层系统会基于上一轮结果继续进化、合并、优化最终输出较高质量的研究建议。这种结构和传统的“问答式大模型”有明显区别。传统模型是“你问我答”而 Co-Scientist 更像是一个自动运行的科研小组不同角色各自负责一部分任务再由综合机制收敛结果。1.2 论文结果幻觉率为什么值得关注科研场景不同于日常问答。如果模型告诉你“巴黎是法国首都”说错了影响不大。但如果模型告诉你“某个基因序列与疾病显著相关”而这个结论其实并未被真实实验验证那么研究者一旦基于错误结论设计后续实验浪费的可能是几个月甚至更长时间。论文中提到的“论文结果幻觉率”指的并不是模型在闲聊中编造事实而是指系统在报告研究成果、描述实验数据、解释研究发现时生成了与真实实验结果不一致的内容。46% 这个比例说明在没有额外约束的情况下模型生成的科研结论里有接近一半是不可靠的。这个数字其实并不意外因为大模型本质上是“根据概率预测下一个 token”它并没有真正做过实验也不具备判断自己输出是否真实的能力。1.3 可靠性模块解决什么问题Co-Scientist 论文中展示的可靠性模块核心目标是对系统输出的结论增加一层“验证机制”。简单理解就是在 AI 给出研究结论之后不直接把这个结论交给用户而是先进入一个自动化的验证流程。这个流程会模拟真实的科研验证逻辑包括结果复现、统计检验、文献对比等只有通过验证的内容才会被标记为“可靠结果”。从工程角度来看这个模块的核心思想可以概括为一句话不要相信模型的自我报告用额外流程去约束它。这也是 46% 降到 4% 的关键所在。2. 可靠性模块的定位与架构拆解2.1 多智能体系统中的“验证者”角色Co-Scientist 不是单一模型而是一个由多个智能体组成的系统。可靠性模块在其中承担的角色类似“验证者”或“审查员”。它并不直接参与研究假说的生成而是在生成完成后介入检查每一条结果的可信度。可以这样理解整个流水线研究者提出问题 ↓ 生成智能体提出候选假说 ↓ 评审智能体打分排序 ↓ 进化智能体优化方案 ↓ 可靠性模块自动验证 ↓ 输出标记为“已通过/未通过”的结果在未加入可靠性模块时流程到“优化方案”就直接输出结果了。模型给出的结论可能看起来逻辑严密但并没有真正经过验证。加入可靠性模块后输出端多了一道闸门大大降低了错误结论直接暴露给用户的风险。2.2 可靠性模块的验证方式从论文展示的思路来看可靠性模块的工作方式并非单一手段而是结合了多种验证策略第一类是代码执行验证。科研结果中往往包含数据分析、统计计算、图表生成等环节。模型可能会描述“我们使用某种方法对数据进行分析得到 p 值小于 0.05”这句话即使是编造的语法上也完全通顺。可靠性模块的做法是让这段分析真正跑一遍代码用实际执行结果去对比模型声称的结果。第二类是结果交叉验证。系统会尝试用不同的方法或参数重现相同结论。如果结论只在特定参数下成立换个参数就不成立那么这条结果的可靠性就要打折扣。第三类是文献一致性检查。系统会把结论与已有文献进行比对寻找支持或矛盾的信息。这不能完全证明结论正确但能识别出明显与学界共识冲突的输出。第四类是统计合理性检查。包括样本量是否充足、效应量是否合理、置信区间是否过宽等。这些检查不需要重新做实验但能过滤掉明显不合常理的结论。这几种方法叠加在一起就构成了可靠性模块的验证屏障。2.3 从 46% 到 4% 意味着什么假设系统每生成 100 条论文结果原先有 46 条是幻觉结果。加入可靠性模块后这个数字降到了 4 条。降幅超过 90%说明大部分幻觉结果都能被验证机制识别出来并拦截掉。这带来的实际价值很明显。研究者在使用 AI 辅助工具时最大的成本并不在于等待生成而在于人工判断结果是否可靠。如果系统能提前过滤掉大部分不可靠结论并且给可靠的结论附上验证证据那么研究者的信任成本会大幅降低。不过也要看到4% 仍然不是零。可靠性模块降低的是风险而不是彻底消灭风险。这也提醒我们即便有了验证机制AI 生成的科研结论仍然需要人类专家进行最终判断不能盲目信任。3. 核心机制拆解为什么验证模块能显著降低幻觉3.1 幻觉产生的根源与验证的必要性要理解可靠性模块为什么有效先要理解幻觉是怎么产生的。大模型的训练目标决定了它的运行方式。给定前文模型在词表上计算下一个词的概率分布然后从中采样或取最高概率词。它优化的指标是“文本连贯性”而不是“事实准确性”。所以模型说出一段话本质上只是这段话在统计上更接近训练数据中的常见表达并不代表它对应真实世界的事件。这种机制在科研场景有一个严重后果模型会根据训练数据中的常见科研语料自动生成一段符合“论文风格”的描述其中每个句子在语法上都没有问题但整段内容可能完全没有对应的真实实验支撑。如果只靠提示词约束例如告诉模型“不要编造结果”效果是有限的。因为模型并没有判断“我是否在编造”的能力。它不知道自己哪句话是事实、哪句话是推测、哪句话是生成范围内的合理猜测。可靠性模块的底层逻辑就是不再依赖模型自己判断“对不对”而是引入外部工具和流程去检验结果。模型说“代码运行后得到 R² 0.93”系统不是去问模型“你确定吗”而是真的执行一遍代码看得到的 R² 是否真的是 0.93。这种思路在 AI 工程中有一个朴素的名字外部验证。它把模型从“唯一的信息源”变成了“假设提出者”再由独立流程完成验证。Co-Scientist 的可靠性模块只是把这一思路系统化地应用到了科研场景。3.2 验证流程从假说生成到结果验真结合论文展示的信息可靠性模块的工作流程大致可以划分为几个阶段首先是假说生成与初步筛选。系统针对用户问题生成多个候选方向评审智能体对这些方向进行打分和排序剔除明显不合理的内容。其次是验证方案自动构建。对于进入候选列表的结果可靠性模块需要自动生成可执行的验证方案。如果研究结论是“某药物对某靶点有抑制作用”验证方案可能是“查询公开数据库中的相关记录”“运行分子对接模拟”“检查已有文献中的剂量反应数据”。然后是自动执行与结果比对。系统执行验证方案将验证结果与模型声称的结果进行比对判断是否一致。最后是置信度标注。系统根据验证通过程度为结果标记置信度明确区分“已验证”“部分验证”“未验证”。这套流程的最大意义在于它把“模型的自我陈述”从唯一依据变成了待验证的假设。系统不再以模型输出的置信度作为判断标准而是以验证结果为准。3.3 可靠性模块在系统层面的约束方式在具体实现层面可靠性模块还需要解决一个重要问题如何确保系统的每一步都能进入验证流程而不是像传统对话那样“想到哪说到哪”。从 Co-Scientist 的设计来看科研流程被拆解成了若干标准化的步骤。每个步骤的输出格式是有约束的。例如在描述研究结果时系统可能需要额外提供以下字段数据来源结果基于哪些数据得出是否来自公开数据集或真实实验记录。方法论采取了哪种分析方法版本是什么。可复现性检查代码是否可运行运行环境是什么是否会生成日志。统计指标关键统计指标是什么样本量多大置信区间是多少。这些字段本质上是在引导模型“先把过程说清楚”然后可靠性模块才有可能针对过程去验证。如果模型东一句西一句没有结构化输出验证模块就无法自动化运行。所以在实际工程中可靠性模块并不只是一个“附加的模型”而是一整套输出约束、验证工具、数据处理机制的组合。它要求整个系统从生成端开始就为验证做准备。4. 从论文到工程AI Agent 可靠性设计的通用思路4.1 大模型应用的可靠性分层Co-Scientist 的可靠性模块虽然面向科研场景但它的设计思路可以迁移到很多其他 AI Agent 应用中。我们可以把大模型应用的可靠性划分为几个层次第一层是输入约束层。在提示词中限制输出范围、明确禁止编造、要求提供依据。这一层成本最低但效果也最有限它只能减少幻觉的发生概率不能保证结果正确。第二层是结构化输出层。通过 JSON Schema 等方式限制模型的输出格式要求模型必须在指定字段中返回内容。这一层主要解决“可解析性”问题并不直接解决内容真实性问题。第三层是工具验证层。调用外部 API、数据库、计算引擎对模型输出进行验证。例如模型说“当前北京天气 25 度”系统可以调用天气 API 验证。这一层能显著提高可靠性但前提是存在可用的验证工具。第四层是多智能体交叉评审层。让多个模型从不同角度对同一结果进行评审模拟人类团队的背对背审查。这一层能在没有外部验证工具的情况下从文本内部发现逻辑矛盾和事实冲突。第五层是人工审核层。关键决策仍然由人类完成。AI 系统负责提供候选结果和验证证据人类负责最终确认。Co-Scientist 的可靠性模块属于第三层和第四层的结合既引入了外部验证手段也利用了多智能体的交叉评审机制。4.2 从模型置信度到证据链可靠性判断的转变传统大模型应用中系统判断输出好坏通常依赖模型自带的置信度分数。但置信度分数有天然局限模型对自己编造的内容也可能给出很高的置信度因为它只是基于概率分布计算出来的并不代表任何“真实感”的判断。可靠性模块带来的一个关键转变是判断基准从“模型置信度”变成了“证据链完整度”。系统不再问“模型认为这个结果多可信”而是问“这个结果有没有被外部证据支持”。证据链可以包含的内容有数据来源是否可靠是公开数据还是本地私有数据。分析代码是否实际运行通过日志是否完整。统计检验是否在合理范围有没有显著违反常识。与已有知识的冲突程度如何是边际分歧还是根本矛盾。这套证据链机制的好处是即使模型最终输出仍然有幻觉用户在查看结果时也可以依据证据链判断哪些部分可信、哪些部分需要质疑。可靠性模块的任务不是消灭幻觉而是把幻觉变得可识别、可追溯。4.3 结构化设计在可靠性中的作用可靠性模块还有一个值得借鉴的设计把科研任务拆成标准化子任务并为每个子任务定义清晰的数据结构。这本质上是把“一个巨大的开放式任务”变成“多个有边界的子任务”前者容易失控后者更容易验证。对应到普通开发中如果我们要构建一个“AI 行业调研助手”不应当直接让 AI 输出一份完整调研报告然后寄希望于整体报告可信。更合理的做法是先让 AI 输出几个子模块行业背景、市场规模、头部玩家、技术趋势、风险点。每个子模块分别独立验证。市场规模接数据库查询头部玩家比对权威榜单技术趋势检索最新论文和专利。给每个结论字段单独留出“证据来源”的位置。如果一个结论没有来源那这个结论在呈现时就应当被标记为“待验证”。如果来源是个无效链接验证模块可以直接报告“来源不可用”。前端的呈现层也应当按照不同的可靠性等级展示不同样式“已验证”和“未验证”信息不要混在一起。这种结构化落地的思想正是 Co-Scientist 可靠性模块从论文到工程实践之间的桥梁。5. 可靠性模块的局限与仍然存在的挑战5.1 验证本身也可能出错可靠性模块虽然显著降低了幻觉率但它并不能做到 100% 准确。验证结果出现错误的原因有很多。验证工具本身可能存在问题。比如代码执行环境缺少依赖导致一段本应运行成功的代码报错系统可能误判为“结果不可复现”。或者某些代码带有随机性每次运行结果本身就有波动系统难以基于单次运行得出结论。交叉验证也可能遇到困难。在开放性的科研问题中不同研究路径得到不同结论是正常现象。系统在判断“两条结果是否一致”时本身就需要一个复杂的判定逻辑而判定逻辑又可能引入新的误差。这也是为什么 4% 的幻觉率不可能下降到零数据的复杂性决定了验证过程也会存在边界。5.2 新知识场景的验证缺口可靠性模块的验证方式比较依赖已有知识库和已有数据。如果研究问题本身是全新的例如某个近年来才出现的技术方向或者学界尚未形成共识的问题那么可靠性模块可能找不到足够的对照依据。在这种情况下系统可以做的验证主要包括逻辑自洽性检查结论内部是否存在矛盾。代码复现分析过程是否能重复执行。统计合理性结果是否存在明显的统计误区。类比推理与相似领域的已有结论是否存在冲突。这些检查能让结论更可信但无法完全替代真实实验的验证。所以在真正的前沿科研场景中可靠性模块更适合作为初筛工具而不是最终判断工具。5.3 幻觉率指标的统计口径论文中 46% 到 4% 的数据需要结合评测方式来看。这里的幻觉率是针对“论文结果”类输出的评测结果评测集、评分标准、幻觉的定义方式都会直接影响这个数字。不同团队在报告幻觉率时可能采取不同的口径。有的把“与标准答案不一致”定义为幻觉有的把“没有证据支持的陈述”定义为幻觉这两种统计方式会得到不同的数据。因此在参考这个数字时我们需要关注论文的具体评测方法而不是简单地将 46% 和 4% 理解为所有场景下的通用指标。但这并不削弱可靠性模块的价值。无论是哪种统计方式验证机制的加入能大幅降低不可靠内容的输出比例这一点在逻辑上是成立的并且也有多个独立研究支持这一方向。6. 给开发者的实践建议提升 AI 输出的可信度6.1 构建可靠的 Agent 验证框架如果你正在构建一个面向生产环境的 AI Agent可以参考下面的 Python 风格伪代码来设计一个简单的结果验证框架。这个示例不代表 Google Co-Scientist 的内部实现而是基于可靠性模块设计思路的工程化示意。from dataclasses import dataclass, field from typing import Any, Callable, Dict, List dataclass class VerificationResult: 一条验证记录记录某个结论是否通过了检查。 item_name: str passed: bool evidence: str details: Dict[str, Any] field(default_factorydict) class Validator: 验证器对 Agent 输出的某个结论执行一组检查规则。 每个检查规则接收结论文本返回是否通过以及理由。 def __init__(self, name: str): self.name name self._checks: List[Callable[[str], VerificationResult]] [] def add_check(self, check_func: Callable[[str], VerificationResult]): self._checks.append(check_func) def validate(self, conclusion_text: str) - List[VerificationResult]: results [] for check in self._checks: result check(conclusion_text) results.append(result) return results class ReliabilityModule: 可靠性模块对 Agent 的最终输出做整体验证 并通过“置信度标签”告知使用者当前结论的可靠程度。 def __init__(self): # 这里为不同结论类型维护不同的验证器 self._validators: Dict[str, Validator] {} def register_validator(self, result_type: str, validator: Validator): self._validators[result_type] validator def verify(self, result_type: str, content: str) - Dict[str, Any]: if result_type not in self._validators: return { status: unverified, message: No validator registered for this result type., } validator self._validators[result_type] results validator.validate(content) passed_count sum(1 for r in results if r.passed) total_count len(results) if total_count 0: return {status: unverified} if passed_count total_count: status verified elif passed_count / total_count 0.6: status partially_verified else: status failed return { status: status, passed: passed_count, total: total_count, details: results, } # 使用示例 if __name__ __main__: def check_contains_source(text: str) - VerificationResult: 检查结论中是否包含数据来源信息。 if source: in text.lower(): return VerificationResult( item_namesource_check, passedTrue, evidenceFound source field., ) return VerificationResult( item_namesource_check, passedFalse, evidenceMissing source field., ) def check_code_run(text: str) - VerificationResult: 模拟代码运行检查真实场景中应调用外部执行环境。 if code_log in text: return VerificationResult( item_namecode_run_check, passedTrue, evidenceCode executed., ) return VerificationResult( item_namecode_run_check, passedFalse, evidenceNo execution log found., ) # 创建论文结果验证器 paper_validator Validator(namepaper_result_validator) paper_validator.add_check(check_contains_source) paper_validator.add_check(check_code_run) reliability ReliabilityModule() reliability.register_validator(paper_result, paper_validator) sample_output The new model achieves 92% accuracy on the test set. source: internal benchmark, 2024. code_log: execution succeeded. final_status reliability.verify(paper_result, sample_output) print(final_status[status]) print(fPassed {final_status[passed]} / {final_status[total]})这段示意代码展示了可靠性模块的核心实现模式针对不同类型的 Agent 输出注册不同的验证规则任何输出在放行前都必须执行验证流程。即使在真实项目里验证规则要复杂得多这种可插拔架构也值得保留。6.2 多智能体系统的交叉评审除了代码执行和数据来源检查多智能体之间的交叉评审也是降低幻觉的有效手段。你可以让两个大模型分别独立完成任务再由第三个模型对比两者的输出。def cross_review( result_a: str, result_b: str, reviewer_prompt: str ) - str: 将两轮结果交给评审模型返回评审意见。 # 这里应替换为实际模型调用代码 combined_input f Result A: {result_a} Result B: {result_b} Review instructions: {reviewer_prompt} # 示意返回 return fReview of combined input (length{len(combined_input)}) review_prompt Compare Result A and Result B. Identify factual conflicts. If A and B disagree on numeric conclusions, mark outcome as conflicting. If they agree, mark outcome as consistent. Also list any claims that lack external evidence. # 模拟两次独立生成 result_one Model accuracy: 91.5%, p0.05 result_two Model accuracy: 92.0%, p0.05 review_comment cross_review(result_one, result_two, review_prompt) print(review_comment)交叉评审的核心价值在于两个模型的独立错误同时发生的概率通常会低于单个模型的错误概率。这种机制不需要额外训练模型只需调用多个模型实例即可工程成本相对可控。6.3 输出风险评估与用户提示在真实产品中可靠性信息必须透传给用户。一个有效的做法是在 UI 层区分不同置信度等级已验证绿色标签结果已经通过至少一种外部验证方式。部分验证黄色标签部分结论通过验证部分结论缺少关联证据。未验证灰色标签系统无法对结果进行有效的自动验证需要人工复核。验证失败红色标签结果与已有证据冲突不建议直接采纳。让用户意识到哪些内容可信、哪些内容需要复核比一味追求“回答正确率”更能提升产品体验。论文中 Co-Scientist 的做法本质上也是在向用户透明地传递验证结果而不是简单把所有输出混在一起展示。7. 对 AI 辅助科研工具的未来展望7.1 验证自动化的技术方向Co-Scientist 可靠性模块带来的最大启示是科研工具需要把“生成”和“验证”当作同等重要的组成部分。未来的 AI 辅助科研工具很可能从“生成工具”演化为“自动验证研究平台”。在这个平台上假说生成只是起点。系统将围绕每个假说自动构建实验方案、检索相关文献、匹配数据源、运行代码、分析结果形成完整的验证闭环。研究者看到的不再是一堆模型答案而是一条条带证据链的研究记录。要实现这样的愿景以下领域会有持续的技术投入更高效的代码解释器自动运行数据分析代码记录运行日志。更完善的数据库对接连接公开数据集、论文数据库、临床试验数据。更智能的统计审查自动发现方法选择、样本量、显著性检验中的问题。更好的评估基准在更多科研子领域建立幻觉率评测标准。7.2 可靠性评估的标准化当前幻觉率的评测方法还没有形成行业统一标准。如果你要在自己的系统里报告“幻觉率下降幅度”应当先明确以下问题幻觉类型怎么分类区分“结果幻觉”“引用幻觉”“推理幻觉”了吗评测集是怎么构建的是真实实验记录还是人工标注的模拟问答用什么语义相似度阈值判断“一致”人工复核环节占多大比例只有先定义清楚这些边界讨论 A 系统和 B 系统谁的幻觉率更低才是有意义的。这也是 Co-Scientist 论文令人关注的原因之一它不仅展示了一个工程方案也推动了对“AI 科研结果可靠性如何评测”的讨论。7.3 与现有科研工作流的融合可靠性模块的落地还需要考虑科研人员的实际工作习惯。如果验证流程过于繁琐研究者可能不愿意使用如果验证结果展示不够清晰研究者又可能产生误解。工程化落地时可以按以下原则设计把验证过程自动化不要要求研究者手动提交验证材料。系统自动关联数据源、自动运行代码、自动生成验证报告研究者只负责最终确认。给验证模块保留“人工反馈”入口。当研究者指出某条结论判断有误时系统应该将这个反馈纳入后续验证逻辑形成动态改进。遵循最小权限与合规要求。尤其是在医疗、金融等敏感科研领域系统访问数据库和外部 API 时应严格遵循授权范围确保数据安全与科研伦理合规。对研究数据执行变更性操作前必须有备份和回滚方案。可靠性模块可能自动调用外部计算资源或修改配置要确保所有操作都有审计日志权限最小化。8. 写在最后的实践提醒如果只记住一条信息那就是大模型的可靠性不能靠“提示词优化”解决必须依赖外部的验证流程。Co-Scientist 的可靠性模块用 46% 到 4% 的数字说明了一个已经被多个工程团队验证过的规律——系统性地增加验证环节是降低 AI 输出幻觉最有效的手段。无论你是在构建科研辅助工具、行业调研助手、代码生成 Agent还是面向垂直领域的问答系统都值得在设计早期就把验证模块纳入架构考虑。不要等到用户投诉“AI 又在胡说”之后再做补救。具体动手时可以从下面这些最小步骤开始先把最核心的一类 Agent 输出格式结构化定义好字段和约束。再针对该输出里的关键结论设计验证规则优先选择能用代码和数据源自动验证的部分。然后把验证结果以“证据链”形式展示给使用者并明确标记验证状态。最后建立幻觉率评测集持续统计模块上线前后的效果变化。这套做法不需要一步到位但方向比速度更重要。今天的 AI 应用竞争已经不只是模型能力的比拼而是“谁能把不可控的模型输出变成可验证的业务结果”的比拼。可靠性模块不是可选项而是未来 AI 工程的基础设施。
AI科研助手如何降幻觉率？Co-Scientist可靠性模块与Agent实践启示
近年来AI 辅助科研已经成为大模型落地的重要方向之一。从文献调研到实验设计再到代码生成大模型正逐步进入科研工作流。但一个始终绕不开的问题也随之浮出水面AI 生成的内容到底可不可信尤其在论文复现、结果验证这类对准确性要求极高的场景里模型输出的“一本正经胡说八道”会让研究者付出巨大的时间代价。Google 近期公开的 Co-Scientist 系统相关论文中有一个数据引起了广泛关注加入可靠性模块后论文结果的幻觉率从 46% 降到了 4%。这个降幅非常惊人也让人好奇它背后的实现思路到底是什么。本文不打算只做新闻式转述而是结合论文的关键设计拆解 Co-Scientist 的工作方式、可靠性模块的定位以及这套方案对普通开发者在构建 AI Agent 时的可借鉴之处。1. 背景AI 科研助手为什么总在“编结果”1.1 什么是 Co-ScientistCo-Scientist 是 Google 提出的一个面向科研场景的多智能体 AI 系统目标是辅助科学家完成从假说提出、实验设计到结果分析的完整研究流程。它不是在单个提示词里完成所有工作而是通过多个具有不同职责的智能体协作围绕一个研究问题不断提出方案、评价方案、完善方案。这套系统的基本工作方式是这样的输入层研究者提供一个开放性的科学问题例如“某种疾病是否存在新的靶点”“某类材料的合成路径是否可以优化”。生成层系统会生成多个候选假说或研究思路。评价层通过模拟对抗、评审等机制对候选思路进行打分和排序。迭代层系统会基于上一轮结果继续进化、合并、优化最终输出较高质量的研究建议。这种结构和传统的“问答式大模型”有明显区别。传统模型是“你问我答”而 Co-Scientist 更像是一个自动运行的科研小组不同角色各自负责一部分任务再由综合机制收敛结果。1.2 论文结果幻觉率为什么值得关注科研场景不同于日常问答。如果模型告诉你“巴黎是法国首都”说错了影响不大。但如果模型告诉你“某个基因序列与疾病显著相关”而这个结论其实并未被真实实验验证那么研究者一旦基于错误结论设计后续实验浪费的可能是几个月甚至更长时间。论文中提到的“论文结果幻觉率”指的并不是模型在闲聊中编造事实而是指系统在报告研究成果、描述实验数据、解释研究发现时生成了与真实实验结果不一致的内容。46% 这个比例说明在没有额外约束的情况下模型生成的科研结论里有接近一半是不可靠的。这个数字其实并不意外因为大模型本质上是“根据概率预测下一个 token”它并没有真正做过实验也不具备判断自己输出是否真实的能力。1.3 可靠性模块解决什么问题Co-Scientist 论文中展示的可靠性模块核心目标是对系统输出的结论增加一层“验证机制”。简单理解就是在 AI 给出研究结论之后不直接把这个结论交给用户而是先进入一个自动化的验证流程。这个流程会模拟真实的科研验证逻辑包括结果复现、统计检验、文献对比等只有通过验证的内容才会被标记为“可靠结果”。从工程角度来看这个模块的核心思想可以概括为一句话不要相信模型的自我报告用额外流程去约束它。这也是 46% 降到 4% 的关键所在。2. 可靠性模块的定位与架构拆解2.1 多智能体系统中的“验证者”角色Co-Scientist 不是单一模型而是一个由多个智能体组成的系统。可靠性模块在其中承担的角色类似“验证者”或“审查员”。它并不直接参与研究假说的生成而是在生成完成后介入检查每一条结果的可信度。可以这样理解整个流水线研究者提出问题 ↓ 生成智能体提出候选假说 ↓ 评审智能体打分排序 ↓ 进化智能体优化方案 ↓ 可靠性模块自动验证 ↓ 输出标记为“已通过/未通过”的结果在未加入可靠性模块时流程到“优化方案”就直接输出结果了。模型给出的结论可能看起来逻辑严密但并没有真正经过验证。加入可靠性模块后输出端多了一道闸门大大降低了错误结论直接暴露给用户的风险。2.2 可靠性模块的验证方式从论文展示的思路来看可靠性模块的工作方式并非单一手段而是结合了多种验证策略第一类是代码执行验证。科研结果中往往包含数据分析、统计计算、图表生成等环节。模型可能会描述“我们使用某种方法对数据进行分析得到 p 值小于 0.05”这句话即使是编造的语法上也完全通顺。可靠性模块的做法是让这段分析真正跑一遍代码用实际执行结果去对比模型声称的结果。第二类是结果交叉验证。系统会尝试用不同的方法或参数重现相同结论。如果结论只在特定参数下成立换个参数就不成立那么这条结果的可靠性就要打折扣。第三类是文献一致性检查。系统会把结论与已有文献进行比对寻找支持或矛盾的信息。这不能完全证明结论正确但能识别出明显与学界共识冲突的输出。第四类是统计合理性检查。包括样本量是否充足、效应量是否合理、置信区间是否过宽等。这些检查不需要重新做实验但能过滤掉明显不合常理的结论。这几种方法叠加在一起就构成了可靠性模块的验证屏障。2.3 从 46% 到 4% 意味着什么假设系统每生成 100 条论文结果原先有 46 条是幻觉结果。加入可靠性模块后这个数字降到了 4 条。降幅超过 90%说明大部分幻觉结果都能被验证机制识别出来并拦截掉。这带来的实际价值很明显。研究者在使用 AI 辅助工具时最大的成本并不在于等待生成而在于人工判断结果是否可靠。如果系统能提前过滤掉大部分不可靠结论并且给可靠的结论附上验证证据那么研究者的信任成本会大幅降低。不过也要看到4% 仍然不是零。可靠性模块降低的是风险而不是彻底消灭风险。这也提醒我们即便有了验证机制AI 生成的科研结论仍然需要人类专家进行最终判断不能盲目信任。3. 核心机制拆解为什么验证模块能显著降低幻觉3.1 幻觉产生的根源与验证的必要性要理解可靠性模块为什么有效先要理解幻觉是怎么产生的。大模型的训练目标决定了它的运行方式。给定前文模型在词表上计算下一个词的概率分布然后从中采样或取最高概率词。它优化的指标是“文本连贯性”而不是“事实准确性”。所以模型说出一段话本质上只是这段话在统计上更接近训练数据中的常见表达并不代表它对应真实世界的事件。这种机制在科研场景有一个严重后果模型会根据训练数据中的常见科研语料自动生成一段符合“论文风格”的描述其中每个句子在语法上都没有问题但整段内容可能完全没有对应的真实实验支撑。如果只靠提示词约束例如告诉模型“不要编造结果”效果是有限的。因为模型并没有判断“我是否在编造”的能力。它不知道自己哪句话是事实、哪句话是推测、哪句话是生成范围内的合理猜测。可靠性模块的底层逻辑就是不再依赖模型自己判断“对不对”而是引入外部工具和流程去检验结果。模型说“代码运行后得到 R² 0.93”系统不是去问模型“你确定吗”而是真的执行一遍代码看得到的 R² 是否真的是 0.93。这种思路在 AI 工程中有一个朴素的名字外部验证。它把模型从“唯一的信息源”变成了“假设提出者”再由独立流程完成验证。Co-Scientist 的可靠性模块只是把这一思路系统化地应用到了科研场景。3.2 验证流程从假说生成到结果验真结合论文展示的信息可靠性模块的工作流程大致可以划分为几个阶段首先是假说生成与初步筛选。系统针对用户问题生成多个候选方向评审智能体对这些方向进行打分和排序剔除明显不合理的内容。其次是验证方案自动构建。对于进入候选列表的结果可靠性模块需要自动生成可执行的验证方案。如果研究结论是“某药物对某靶点有抑制作用”验证方案可能是“查询公开数据库中的相关记录”“运行分子对接模拟”“检查已有文献中的剂量反应数据”。然后是自动执行与结果比对。系统执行验证方案将验证结果与模型声称的结果进行比对判断是否一致。最后是置信度标注。系统根据验证通过程度为结果标记置信度明确区分“已验证”“部分验证”“未验证”。这套流程的最大意义在于它把“模型的自我陈述”从唯一依据变成了待验证的假设。系统不再以模型输出的置信度作为判断标准而是以验证结果为准。3.3 可靠性模块在系统层面的约束方式在具体实现层面可靠性模块还需要解决一个重要问题如何确保系统的每一步都能进入验证流程而不是像传统对话那样“想到哪说到哪”。从 Co-Scientist 的设计来看科研流程被拆解成了若干标准化的步骤。每个步骤的输出格式是有约束的。例如在描述研究结果时系统可能需要额外提供以下字段数据来源结果基于哪些数据得出是否来自公开数据集或真实实验记录。方法论采取了哪种分析方法版本是什么。可复现性检查代码是否可运行运行环境是什么是否会生成日志。统计指标关键统计指标是什么样本量多大置信区间是多少。这些字段本质上是在引导模型“先把过程说清楚”然后可靠性模块才有可能针对过程去验证。如果模型东一句西一句没有结构化输出验证模块就无法自动化运行。所以在实际工程中可靠性模块并不只是一个“附加的模型”而是一整套输出约束、验证工具、数据处理机制的组合。它要求整个系统从生成端开始就为验证做准备。4. 从论文到工程AI Agent 可靠性设计的通用思路4.1 大模型应用的可靠性分层Co-Scientist 的可靠性模块虽然面向科研场景但它的设计思路可以迁移到很多其他 AI Agent 应用中。我们可以把大模型应用的可靠性划分为几个层次第一层是输入约束层。在提示词中限制输出范围、明确禁止编造、要求提供依据。这一层成本最低但效果也最有限它只能减少幻觉的发生概率不能保证结果正确。第二层是结构化输出层。通过 JSON Schema 等方式限制模型的输出格式要求模型必须在指定字段中返回内容。这一层主要解决“可解析性”问题并不直接解决内容真实性问题。第三层是工具验证层。调用外部 API、数据库、计算引擎对模型输出进行验证。例如模型说“当前北京天气 25 度”系统可以调用天气 API 验证。这一层能显著提高可靠性但前提是存在可用的验证工具。第四层是多智能体交叉评审层。让多个模型从不同角度对同一结果进行评审模拟人类团队的背对背审查。这一层能在没有外部验证工具的情况下从文本内部发现逻辑矛盾和事实冲突。第五层是人工审核层。关键决策仍然由人类完成。AI 系统负责提供候选结果和验证证据人类负责最终确认。Co-Scientist 的可靠性模块属于第三层和第四层的结合既引入了外部验证手段也利用了多智能体的交叉评审机制。4.2 从模型置信度到证据链可靠性判断的转变传统大模型应用中系统判断输出好坏通常依赖模型自带的置信度分数。但置信度分数有天然局限模型对自己编造的内容也可能给出很高的置信度因为它只是基于概率分布计算出来的并不代表任何“真实感”的判断。可靠性模块带来的一个关键转变是判断基准从“模型置信度”变成了“证据链完整度”。系统不再问“模型认为这个结果多可信”而是问“这个结果有没有被外部证据支持”。证据链可以包含的内容有数据来源是否可靠是公开数据还是本地私有数据。分析代码是否实际运行通过日志是否完整。统计检验是否在合理范围有没有显著违反常识。与已有知识的冲突程度如何是边际分歧还是根本矛盾。这套证据链机制的好处是即使模型最终输出仍然有幻觉用户在查看结果时也可以依据证据链判断哪些部分可信、哪些部分需要质疑。可靠性模块的任务不是消灭幻觉而是把幻觉变得可识别、可追溯。4.3 结构化设计在可靠性中的作用可靠性模块还有一个值得借鉴的设计把科研任务拆成标准化子任务并为每个子任务定义清晰的数据结构。这本质上是把“一个巨大的开放式任务”变成“多个有边界的子任务”前者容易失控后者更容易验证。对应到普通开发中如果我们要构建一个“AI 行业调研助手”不应当直接让 AI 输出一份完整调研报告然后寄希望于整体报告可信。更合理的做法是先让 AI 输出几个子模块行业背景、市场规模、头部玩家、技术趋势、风险点。每个子模块分别独立验证。市场规模接数据库查询头部玩家比对权威榜单技术趋势检索最新论文和专利。给每个结论字段单独留出“证据来源”的位置。如果一个结论没有来源那这个结论在呈现时就应当被标记为“待验证”。如果来源是个无效链接验证模块可以直接报告“来源不可用”。前端的呈现层也应当按照不同的可靠性等级展示不同样式“已验证”和“未验证”信息不要混在一起。这种结构化落地的思想正是 Co-Scientist 可靠性模块从论文到工程实践之间的桥梁。5. 可靠性模块的局限与仍然存在的挑战5.1 验证本身也可能出错可靠性模块虽然显著降低了幻觉率但它并不能做到 100% 准确。验证结果出现错误的原因有很多。验证工具本身可能存在问题。比如代码执行环境缺少依赖导致一段本应运行成功的代码报错系统可能误判为“结果不可复现”。或者某些代码带有随机性每次运行结果本身就有波动系统难以基于单次运行得出结论。交叉验证也可能遇到困难。在开放性的科研问题中不同研究路径得到不同结论是正常现象。系统在判断“两条结果是否一致”时本身就需要一个复杂的判定逻辑而判定逻辑又可能引入新的误差。这也是为什么 4% 的幻觉率不可能下降到零数据的复杂性决定了验证过程也会存在边界。5.2 新知识场景的验证缺口可靠性模块的验证方式比较依赖已有知识库和已有数据。如果研究问题本身是全新的例如某个近年来才出现的技术方向或者学界尚未形成共识的问题那么可靠性模块可能找不到足够的对照依据。在这种情况下系统可以做的验证主要包括逻辑自洽性检查结论内部是否存在矛盾。代码复现分析过程是否能重复执行。统计合理性结果是否存在明显的统计误区。类比推理与相似领域的已有结论是否存在冲突。这些检查能让结论更可信但无法完全替代真实实验的验证。所以在真正的前沿科研场景中可靠性模块更适合作为初筛工具而不是最终判断工具。5.3 幻觉率指标的统计口径论文中 46% 到 4% 的数据需要结合评测方式来看。这里的幻觉率是针对“论文结果”类输出的评测结果评测集、评分标准、幻觉的定义方式都会直接影响这个数字。不同团队在报告幻觉率时可能采取不同的口径。有的把“与标准答案不一致”定义为幻觉有的把“没有证据支持的陈述”定义为幻觉这两种统计方式会得到不同的数据。因此在参考这个数字时我们需要关注论文的具体评测方法而不是简单地将 46% 和 4% 理解为所有场景下的通用指标。但这并不削弱可靠性模块的价值。无论是哪种统计方式验证机制的加入能大幅降低不可靠内容的输出比例这一点在逻辑上是成立的并且也有多个独立研究支持这一方向。6. 给开发者的实践建议提升 AI 输出的可信度6.1 构建可靠的 Agent 验证框架如果你正在构建一个面向生产环境的 AI Agent可以参考下面的 Python 风格伪代码来设计一个简单的结果验证框架。这个示例不代表 Google Co-Scientist 的内部实现而是基于可靠性模块设计思路的工程化示意。from dataclasses import dataclass, field from typing import Any, Callable, Dict, List dataclass class VerificationResult: 一条验证记录记录某个结论是否通过了检查。 item_name: str passed: bool evidence: str details: Dict[str, Any] field(default_factorydict) class Validator: 验证器对 Agent 输出的某个结论执行一组检查规则。 每个检查规则接收结论文本返回是否通过以及理由。 def __init__(self, name: str): self.name name self._checks: List[Callable[[str], VerificationResult]] [] def add_check(self, check_func: Callable[[str], VerificationResult]): self._checks.append(check_func) def validate(self, conclusion_text: str) - List[VerificationResult]: results [] for check in self._checks: result check(conclusion_text) results.append(result) return results class ReliabilityModule: 可靠性模块对 Agent 的最终输出做整体验证 并通过“置信度标签”告知使用者当前结论的可靠程度。 def __init__(self): # 这里为不同结论类型维护不同的验证器 self._validators: Dict[str, Validator] {} def register_validator(self, result_type: str, validator: Validator): self._validators[result_type] validator def verify(self, result_type: str, content: str) - Dict[str, Any]: if result_type not in self._validators: return { status: unverified, message: No validator registered for this result type., } validator self._validators[result_type] results validator.validate(content) passed_count sum(1 for r in results if r.passed) total_count len(results) if total_count 0: return {status: unverified} if passed_count total_count: status verified elif passed_count / total_count 0.6: status partially_verified else: status failed return { status: status, passed: passed_count, total: total_count, details: results, } # 使用示例 if __name__ __main__: def check_contains_source(text: str) - VerificationResult: 检查结论中是否包含数据来源信息。 if source: in text.lower(): return VerificationResult( item_namesource_check, passedTrue, evidenceFound source field., ) return VerificationResult( item_namesource_check, passedFalse, evidenceMissing source field., ) def check_code_run(text: str) - VerificationResult: 模拟代码运行检查真实场景中应调用外部执行环境。 if code_log in text: return VerificationResult( item_namecode_run_check, passedTrue, evidenceCode executed., ) return VerificationResult( item_namecode_run_check, passedFalse, evidenceNo execution log found., ) # 创建论文结果验证器 paper_validator Validator(namepaper_result_validator) paper_validator.add_check(check_contains_source) paper_validator.add_check(check_code_run) reliability ReliabilityModule() reliability.register_validator(paper_result, paper_validator) sample_output The new model achieves 92% accuracy on the test set. source: internal benchmark, 2024. code_log: execution succeeded. final_status reliability.verify(paper_result, sample_output) print(final_status[status]) print(fPassed {final_status[passed]} / {final_status[total]})这段示意代码展示了可靠性模块的核心实现模式针对不同类型的 Agent 输出注册不同的验证规则任何输出在放行前都必须执行验证流程。即使在真实项目里验证规则要复杂得多这种可插拔架构也值得保留。6.2 多智能体系统的交叉评审除了代码执行和数据来源检查多智能体之间的交叉评审也是降低幻觉的有效手段。你可以让两个大模型分别独立完成任务再由第三个模型对比两者的输出。def cross_review( result_a: str, result_b: str, reviewer_prompt: str ) - str: 将两轮结果交给评审模型返回评审意见。 # 这里应替换为实际模型调用代码 combined_input f Result A: {result_a} Result B: {result_b} Review instructions: {reviewer_prompt} # 示意返回 return fReview of combined input (length{len(combined_input)}) review_prompt Compare Result A and Result B. Identify factual conflicts. If A and B disagree on numeric conclusions, mark outcome as conflicting. If they agree, mark outcome as consistent. Also list any claims that lack external evidence. # 模拟两次独立生成 result_one Model accuracy: 91.5%, p0.05 result_two Model accuracy: 92.0%, p0.05 review_comment cross_review(result_one, result_two, review_prompt) print(review_comment)交叉评审的核心价值在于两个模型的独立错误同时发生的概率通常会低于单个模型的错误概率。这种机制不需要额外训练模型只需调用多个模型实例即可工程成本相对可控。6.3 输出风险评估与用户提示在真实产品中可靠性信息必须透传给用户。一个有效的做法是在 UI 层区分不同置信度等级已验证绿色标签结果已经通过至少一种外部验证方式。部分验证黄色标签部分结论通过验证部分结论缺少关联证据。未验证灰色标签系统无法对结果进行有效的自动验证需要人工复核。验证失败红色标签结果与已有证据冲突不建议直接采纳。让用户意识到哪些内容可信、哪些内容需要复核比一味追求“回答正确率”更能提升产品体验。论文中 Co-Scientist 的做法本质上也是在向用户透明地传递验证结果而不是简单把所有输出混在一起展示。7. 对 AI 辅助科研工具的未来展望7.1 验证自动化的技术方向Co-Scientist 可靠性模块带来的最大启示是科研工具需要把“生成”和“验证”当作同等重要的组成部分。未来的 AI 辅助科研工具很可能从“生成工具”演化为“自动验证研究平台”。在这个平台上假说生成只是起点。系统将围绕每个假说自动构建实验方案、检索相关文献、匹配数据源、运行代码、分析结果形成完整的验证闭环。研究者看到的不再是一堆模型答案而是一条条带证据链的研究记录。要实现这样的愿景以下领域会有持续的技术投入更高效的代码解释器自动运行数据分析代码记录运行日志。更完善的数据库对接连接公开数据集、论文数据库、临床试验数据。更智能的统计审查自动发现方法选择、样本量、显著性检验中的问题。更好的评估基准在更多科研子领域建立幻觉率评测标准。7.2 可靠性评估的标准化当前幻觉率的评测方法还没有形成行业统一标准。如果你要在自己的系统里报告“幻觉率下降幅度”应当先明确以下问题幻觉类型怎么分类区分“结果幻觉”“引用幻觉”“推理幻觉”了吗评测集是怎么构建的是真实实验记录还是人工标注的模拟问答用什么语义相似度阈值判断“一致”人工复核环节占多大比例只有先定义清楚这些边界讨论 A 系统和 B 系统谁的幻觉率更低才是有意义的。这也是 Co-Scientist 论文令人关注的原因之一它不仅展示了一个工程方案也推动了对“AI 科研结果可靠性如何评测”的讨论。7.3 与现有科研工作流的融合可靠性模块的落地还需要考虑科研人员的实际工作习惯。如果验证流程过于繁琐研究者可能不愿意使用如果验证结果展示不够清晰研究者又可能产生误解。工程化落地时可以按以下原则设计把验证过程自动化不要要求研究者手动提交验证材料。系统自动关联数据源、自动运行代码、自动生成验证报告研究者只负责最终确认。给验证模块保留“人工反馈”入口。当研究者指出某条结论判断有误时系统应该将这个反馈纳入后续验证逻辑形成动态改进。遵循最小权限与合规要求。尤其是在医疗、金融等敏感科研领域系统访问数据库和外部 API 时应严格遵循授权范围确保数据安全与科研伦理合规。对研究数据执行变更性操作前必须有备份和回滚方案。可靠性模块可能自动调用外部计算资源或修改配置要确保所有操作都有审计日志权限最小化。8. 写在最后的实践提醒如果只记住一条信息那就是大模型的可靠性不能靠“提示词优化”解决必须依赖外部的验证流程。Co-Scientist 的可靠性模块用 46% 到 4% 的数字说明了一个已经被多个工程团队验证过的规律——系统性地增加验证环节是降低 AI 输出幻觉最有效的手段。无论你是在构建科研辅助工具、行业调研助手、代码生成 Agent还是面向垂直领域的问答系统都值得在设计早期就把验证模块纳入架构考虑。不要等到用户投诉“AI 又在胡说”之后再做补救。具体动手时可以从下面这些最小步骤开始先把最核心的一类 Agent 输出格式结构化定义好字段和约束。再针对该输出里的关键结论设计验证规则优先选择能用代码和数据源自动验证的部分。然后把验证结果以“证据链”形式展示给使用者并明确标记验证状态。最后建立幻觉率评测集持续统计模块上线前后的效果变化。这套做法不需要一步到位但方向比速度更重要。今天的 AI 应用竞争已经不只是模型能力的比拼而是“谁能把不可控的模型输出变成可验证的业务结果”的比拼。可靠性模块不是可选项而是未来 AI 工程的基础设施。
