这次我们不看工具看一篇论文。Google 在 Co-Scientist 里加了一个“可靠性模块”给出的结果非常直接论文结果幻觉率从 46% 落到 4%。这个数字不只是少了 9 倍的问题它说明了另一件事——大模型不是不能做科研辅助而是缺一套把“生成”和“可信”绑在一起的工程机制。很多人做大模型应用最头疼的就是模型一本正经地编造。普通聊天场景里幻觉顶多让你尴尬科研场景里幻觉会让人做出错误判断编参考文献、编实验数据、给出看似严谨但站不住脚的机制解释这些风险完全不可接受。Co-Scientist 的这条路本质上是把所有生成内容都放到“可验证性”框架里去约束。这篇论文里的可靠性设计对做 AI Agent、RAG、知识库问答、自动报告生成的人都值得拆开来看。下面我会按这个顺序展开Co-Scientist 是什么、科研场景为什么是幻觉重灾区、可靠性模块可能由哪些机制组成、46% 到 4% 靠什么拉下来、这套思路如何迁移到自己的 Agent 里、以及评估幻觉率和工程落地的常见坑。文章会给出可执行的管道伪代码、评估配置和排查清单你可以直接拿去对照自己的方案。1. Co-Scientist 是什么先搞清楚这篇论文的对象Co-Scientist 是 Google 在 AI 辅助科学研究方向上的一个多智能体系统底层使用 Gemini 系列大模型。从公开资料和论文标题来看它不是一个简单的对话机器人而是一个面向科研任务的 Agent 系统能接收研究问题组织多个模型智能体分别完成假设生成、方案设计、结果分析、批判审阅等工作最终输出带论证材料的研究建议。它最值得关注的不是“又有一个 AI 能聊天”而是它系统性地把“科学可靠性”做成了产品级流程。普通软件写错了可以改 bug论文结果写错了会浪费科研人员几周甚至几个月时间。Co-Scientist 的可靠性模块针对的就是这类错误模型生成的每一个所谓结果都要有可以被验证、被溯源、被质疑的通道。能力项说明系统定位AI 驱动的科研合作系统辅助提出假设、设计方案、批判分析结果底层技术Gemini 系列大模型多智能体协作核心成果引入可靠性模块后论文结果幻觉率从 46% 降至 4%关键设计生成与验证分离、结果可溯源、不确定性主动暴露适用对象科研人员、AI Agent 开发者、知识密集型应用团队部署门槛具体以论文版本和发布渠道为准普通开发者更应关注机制可迁移性开源状态需查阅论文对应版本说明不影响方案学习这段要提醒一句论文的 4% 是一个评估集内的结果不是“所有场景绝对只有 4%”。我们关注的重点不是这个数字被复制到所有领域而是它背后那套降低幻觉的机制能不能迁移到我们的 Agent 上。2. 科研场景为什么是幻觉重灾区先给幻觉一个可操作的判定神经网络生成了一段与可验证事实不一致、或没有任何证据支撑的内容并且在表达上没有暴露不确定性。科研内容的特殊性在于它天然使用“确定性语言”结论要明确、引用要精准、公式要能推导、实验数据要能被复现。这就导致模型在科研场景里会过度自信地表达本应带概率判断的内容。科研 Agent 里的幻觉通常表现为以下几类。幻觉类型示例危害虚假参考文献生成一篇看起来像真的论文标题、作者、期刊但实际不存在误导文献调研方向编造实验数值声称某个方法在某数据集上准确率提升 12%但没有任何实验过程影响方案取舍决策错误机制解释用因果关系解释两个变量但实际只是相关性形成错误的科研假设多跳推理断裂结合 A 文献与 B 文献推出 C 结论但 A 和 B 的关联是模型自己脑补的污染整个逻辑链46% 这个基线的存在并不意外。如果没有外部知识校验和判定机制大模型面对开放式科研问题很容易在“不存在的文献”和“想当然的结论”上翻车。科研任务越开放、候选答案空间越大幻觉率就会越高。关键结论是一个模型自己生成的答案不能只靠它自己来判断是否可靠。必须有独立于生成路径的验证通道。3. Co-Scientist 里 Agent 流程与可靠性模块的位置结合 Google 公开的多智能体科研系统介绍Co-Scientist 大体遵循一个“产生想法 - 内部批判 - 筛选排序 - 进化迭代”的流程。这里需要注意不同论文版本对 Agent 的命名和分工可能不一样以下是基于公开机制的工程化理解。阶段典型智能体角色在做什么可靠性问题在哪发散阶段生成 Agent根据研究问题提出多个候选假设、研究框架候选越多幻觉越多审阅阶段批判 Agent对候选方案挑毛病找逻辑漏洞和证据缺口批判不严格会放过错误排序阶段评估 Agent对多个方案进行可验证性和价值排序单点打分容易被表面严谨误导进化阶段迭代 Agent基于批评意见优化方案组合出新想法优化过程可能进一步放大原幻觉出稿阶段输出 Agent把最终研究建议整理成论文结果形式结果需要逐条附带证据链可靠性模块不是某个单独 Agent 的名字而是一套横跨各个环节的约束机制。它的关键动作是让“批判”和“验证”不再是流程里可有可无的调味品而是结果是否能进入下一轮的唯一门槛。更简单地说没有可靠性模块之前一个错误结论被识别出来的概率很低有了可靠性模块之后错误结论在多个交叉校验节点都会暴露。这种“错误在过程中被拦截”的设计远好过最后让用户自己人工识别幻觉。4. 可靠性模块的机制拆解46% 到 4% 靠什么拉下来这是全文最核心的部分。可靠性模块的机制可以拆成几种工程粒度来理解。需要先声明论文内部具体实现权重和模块组合需要去看原文下面的机制拆分更接近“能解释 46% 到 4% 这个量级变化的通用可靠 Agent 设计路径”也是迁移价值最高的部分。4.1 事实核查 Agent每一个关键断言都要过验证闸门首先模型生成的论文结果不能直接进入输出流程。系统会把生成内容拆解成一句一句的“可验证断言”也就是 claim-level splitting。每一句包含事实性的内容——例如“XX 算法在 XX 数据集上 F1 达到 XX”——都会进入事实核查流程。事实核查 Agent 的任务不是再写一段类似的文本而是对一个断言做三件事该断言是否有明确出处出处是否真实存在该断言从出处推导过来是否成立。如果三件事里任何一件不通过断言就需要被标记为“未验证”不得以肯定语气输出。这一层是幻觉率大幅下降的直接原因大量模型想象的“论文结果”在出稿前就被拦截。这里有一个工程细节值得强调。可靠性模块里的“事实核查”不是简单做一次向量相似度检索而是把每一个断言转化为可判定的查询任务。检索到的内容要能覆盖该断言的证据缺口而不是说“从文本风格上看起来像”。否则核查就变成了一种变相的续写。4.2 检索交叉验证打破模型单点生成的盲区降低幻觉的第二个设计是让模型的结果与外部知识源做交叉验证。单靠生成模型的内部参数本质上是在用训练数据里的分布“猜”答案。当某个问题超出模型训练分布或者模型记忆模糊时它依然会输出一个“看起来合理”的回答。交叉验证把这一步从内部判断迁移到外部比较生成的断言去检索真实文献库、知识图谱、技术文档看是否存在内容能支撑。如果外部知识源完全找不到支撑这个断言的默认状态是存疑而不是相信模型的自信表达。这也是科研 Agent 与普通聊天助手的关键差异。普通助手里 RAG 的主要作用是补充知识Co-Scientist 的可靠性模块里检索的作用更像“审计接口”——模型自己说了不算必须拿出外部证据。4.3 置信度评分与不确定性路由拿不准就承认拿不准很多幻觉问题不是模型没有意识到不确定性而是没有一条路径允许它表达不确定性。可靠性模块里工程价值最高的部分很可能是引入了明确的置信度路由高置信度 证据充分 - 正常输出中置信度 证据不足 - 输出时额外标注“需要人工复核”低置信度 - 不输出具体结论而是返回“证据不足给你生成可验证的实验方案”。这个逻辑的目标不是让系统永远正确而是保证系统不会用错误的确定性口吻误导研究者。科研场景里“我不确定”本身就是一个合法答案。真正不可接受的是“明明不确定却把话说死了”。4.4 生成与批判分离用多智能体对抗消除同源偏置可靠性模块的另一层设计是让“写方案”的 Agent 和“批方案”的 Agent 尽可能独立。如果生成模型和批判模型是同一个模型、同一套上下文就会出现很明显的同源偏置模型更倾向于维护自己刚刚生成的内容批判 Agent 很难发现真正的问题。多智能体对抗的价值就是制造“制度化的怀疑”。一个 Agent 负责构造乐观方案另一个 Agent 被指令要求寻找方案里最薄弱的证据链。两个角色目标不一致反而更容易暴露错误。对于科研场景这种对抗还应该引入外部信号——真实论文的审稿意见、实验日志、基准数据集指标——而不是只靠两个 LLM 之间互相辩论。纯 LLM 互辩可以提升逻辑自洽性但解决不了事实性错误。Co-Scientist 的可靠性模块之所以能把幻觉率压到 4% 量级应该不只是智能体互怼而是对每一条结果都做了证据回填。4.5 自洽性与多路采样同一问题多次独立生成科研结论要具备可复现性Agent 的生成结果也一样。可靠性模块很容易引入 self-consistency 机制对同一个研究问题做多次采样观察模型是否稳定输出同一个结论。如果多次生成结果在关键论点上互相矛盾那么该结论的可靠性就要被下调。这个机制本质上是在利用随机采样做置信度校验。模型如果只是“偶尔一次”说出某个结果可信度低如果多次独立生成都指向同一个方向和结论可信度显著增加。这个方法在推理任务里已经很成熟迁移到科研 Agent 后能有效压制“碰运气式”的幻觉。4.6 人类反馈闭环科学家把错误喂回系统最后一部分是人工反馈回路。科学家在使用 Co-Scientist 时如果发现某条输出是幻觉这个反馈不会止于一次人工修正而是进入可靠性模块的评价集成为后续校验的负面样本。这正是很多 Agent 项目容易忽略的部分。幻觉率指标要可持续下降必须有一个“错误样本库”在持续扩容。否则系统只会在一开始优化几次很快进入瓶颈。5. 从论文到工程把可靠性模块拆成分层设计上面那些机制很多做过 Agent 的同学都听过但落地时会发现很难全部做到。一个更工程化的拆法是把可靠性模块当成 4 层管道来设计。层级核心目标典型实现出错后果Generation 生成层在尽量大的假设空间内产生候选结果多路采样、不同 prompt 策略、生成不同角度的方案覆盖率不足错过正确方向Verification 验证层判断每一条断言是否有证据支撑检索交叉验证、事实核查 Agent、主张拆分幻觉漏网错误结果流入决策层Decision 决策层衡量置信度后决定输出、拒绝或转人工置信度评分、不确定性路由、自洽性投票正确结果被误杀或错误结果以高置信度发出Feedback 反馈层将人工纠错纳入系统记忆错误样本库、评估集更新、规则回填幻觉率下降空间有限错误重复出现四层当中验证层是决定幻觉率上限的关卡。如果验证层只是摆设后面的决策层再精细也拦不住错误内容。实际开发中你可以先只做两层claims 拆分 置信度阈值路由。把这两层跑通再逐步加入检索验证和对抗评审。一张图式理解就是生成结果不是答案只是“候选证据包”系统真正输出的内容是“候选证据包经过验证和过滤后的剩余结论”。6. 在自己的 Agent 中做一个简化版可靠性模块如果你想在本地项目或 API 接入的场景里复刻这套思路不需要完整复现 Co-Scientist。直接在一套 Agent 管道的生成结果之后接入一个 verify-and-route 模块就能让幻觉率明显下降。下面给出一套可用于流程验证的 Python 示例。注意这只是工程演示骨架模型名、接口路径和提示词模板需要替换为你实际接入的服务。# 简化版可靠性管道生成 - 断言拆分 - 核查 - 路由 # 依赖openai 或 google-generativeai 等 SDK按实际项目接入 import json from typing import List, Dict def split_claims(text: str) - List[str]: 把模型生成文本拆成一句句可验证断言。 实际项目里可以用 LLM 完成也可以用规则先做粗拆。 # 示例规则按句号拆并丢弃过短和疑问句 sentences [s.strip() for s in text.replace(\n, ).split(。) if len(s.strip()) 10] return sentences def check_claim_with_source(claim: str) - Dict[str, object]: 对单条断言做证据核查。 这里应该调用外部检索接口、知识库或可信语料库。 # 伪代码检索接口结果具体需要换成自己的 Search/Retrieval API # evidence retrieval_api.query(claim) evidence_score 0.7 # 示例值必须按你的检索链路计算 # 判定逻辑检索不到证据时默认标记为未验证 if evidence_score 0.5: return { claim: claim, status: unverified, evidence_score: evidence_score, action: low_confidence_route } return { claim: claim, status: verified, evidence_score: evidence_score, action: allow_output } def route_by_confidence(claims: List[Dict[str, object]]) - Dict[str, object]: 根据断言核查结果决定最终输出策略。 verified [c for c in claims if c[status] verified] unverified [c for c in claims if c[status] unverified] if not verified and unverified: return { final_status: not_confident, message: 证据不足建议仅输出实验验证方案不直接给出结论。 } return { final_status: confident, output_claims: verified, needs_review: unverified } def generate_candidate_research_result(question: str) - str: 示例函数调用 LLM 生成候选结果。 具体调用方式取决于你使用的模型服务。 # client OpenAI(api_key..., base_url...) # resp client.chat.completions.create(...) # 这里返回模拟结果 return (根据迁移学习理论在生物医学文本摘要任务中使用领域自适应预训练 可以将 ROUGE-L 分数提升 4.2 个百分点。该结果在 PubMed 测试集上验证。) def reliability_pipeline(question: str) - Dict[str, object]: # 1. 生成候选结果 raw_text generate_candidate_research_result(question) # 2. 断言拆分 claims split_claims(raw_text) print(拆分段数:, len(claims)) # 3. 逐条核查 checked_claims [check_claim_with_source(c) for c in claims] # 4. 路由 result route_by_confidence(checked_claims) # 5. 保留人工复核标记 return { question: question, raw_text: raw_text, claims: checked_claims, routing_result: result } if __name__ __main__: demo reliability_pipeline(领域自适应预训练是否提升生物医学文本摘要质量) print(json.dumps(demo, ensure_asciiFalse, indent2))上面的代码体现了三个最核心的工程模板不是直接输出大模型原文而是先拆成断言每条断言都有状态字段系统可以根据断言的状态确定能否以肯定语气输出。字段可以按实际项目改造成数据库记录。下面再给一个“最少验证规则”的 JSON 配置示例。它把核查 Agent 的关键参数单独抽出来方便做 AB 测试。{ claim_split_config: { min_length: 10, split_by_punctuation: true, drop_question_sentence: true, drop_subjective_sentence: true }, evidence_checker: { retrieval_top_k: 5, min_evidence_score: 0.6, require_source_id: true, search_timeout_seconds: 10 }, routing: { high_confidence_threshold: 0.8, low_confidence_threshold: 0.5, unverified_action: human_review_or_refuse, allow_low_confidence_with_warning: true } }最后是一个通用外部检索调用的 curl 示意。具体接口、鉴权、参数需要按你实际接入的知识库或搜索 API 调整不要把下面的 URL 当真实接口使用。# 示意把 claim 发给检索服务返回可验证记录 # 实际使用时需要替换为项目自己的检索 API 地址和鉴权 curl -X POST http://127.0.0.1:8000/evidence_check \ -H Content-Type: application/json \ -d { claim: 领域自适应预训练在 PubMed 摘要任务上将 ROUGE-L 提升 4.2 个百分点, top_k: 5, need_source: true }整套简化版管道的核心不是代码多复杂而是流程上强制“结果必须经过验证”。一旦一个 Agent 的输出默认不是答案而只是候选方案幻觉率自然会下降。7. 评估幻觉率怎么得到 46% 到 4% 的可信对比如果你在自己的 Agent 里做了可靠性模块接下来一定是灵魂问题幻觉率降到多少了这需要先定义评估口径。幻觉率不是“模型偶尔胡说八道”而是在一定的测试任务样本中模型输出中被判定为“与可验证事实不一致或缺乏证据支撑”的比例。一个可落地的评估设计包括三个层面。评估层面检查内容判定标准引用层面参考文献、来源链接、代码仓库是否存在捏造即算幻觉事实层面数值、指标、时间、机构名是否与真实资料一致与检索结果不一致即算幻觉推理层面结论是否能由上文证据推出是否存在逻辑跳跃多步推理无法回推即算幻觉用公式表示就是幻觉率 幻觉断言数 / 总断言数 或 样本级幻觉率 出现至少一个幻觉断言的样本数 / 总样本数更重要的一点Co-Scientier 论文里的 46% 到 4%是在它自己的测试任务分布上得到的。不同任务、不同领域、不同证据库覆盖程度下绝对数字会差非常多。比如在长尾科学问题上检索库覆盖不足幻觉率起点可能就低不了。因此更合理的做法是在自己的测试集上先测基线再测加模块后的效果比较相对下降幅度。除了绝对幻觉率还需要记录一个反向指标——覆盖率。很多过滤方法会把正确结果一起误杀。如果为了把幻觉率从 40% 压到 4%导致 60% 的正确结果被系统判定为“未验证”那这个系统在真实场景不可用。8. 工程落地时的常见误区和排查方法很多团队看完这套方案后会直接抄作业但实际跑起来会发现效果不稳定。下面按出现频率列出几类常见问题。问题现象可能原因排查方式解决方案加了核查 Agent 后幻觉率仍然高核查 Agent 与生成 Agent 同源标准过松查看核查 Agent 对已确认幻觉样本的判定结果更换不同模型做验证引入更强的外部检索约束可信结果被大量误杀置信度阈值过高或证据缺失被当成假内容统计被拦截内容的正确率区分“无证据”和“有反证”无证据可以转人工而非直接拒绝检索结果查不到模型仍坚持输出prompt 里给了模型过高的自由裁量权检查 system prompt 是否允许“编造来源”强制要求输出必须附带证据 ID无 ID 不输出幻觉率在测试集 A 降了测试集 B 又上升评估集与模型训练数据分布接近构建更新、更冷门的评估子集按领域拆分报告不只看整体均值多智能体互辩后错误反而增加对抗评审缺少外部事实约束复盘被批评意见“说服”的样本让批评意见必须给出检索证据不能只说观点多路采样结果一致但依然错误多条采样共享了同一个错误先验分析错误模式是否来自 prompt 或检索库更换提示词模板、引入外部反例检索输出变保守很多问题不敢回答不确定性路由把太多问题转给人工查看路由决策日志中的置信度分布降低转人工阈值允许带警告输出低置信度结果最容易踩的坑是第一行验证模块和生成模块用同一个模型、同一套温控参数。同源模型会共享系统性能只是“自己查自己”很难发现错误。建议至少在验证环节换一个不同规模的模型或同模型不同角色提示词来减弱自我一致性偏置。9. 对 Agent 开发者的建议与合规边界可靠性模块的价值不只属于科研 Agent。做知识库问答、法律文书辅助、技术报告生成、金融分析摘要的开发者其实都面对同一个问题模型输出不能直接作为决策依据。给 Agent 开发者的落地建议包括把“输出控制”改为“结果认证”不要只调 prompt 让模型别胡说而是让结果必须携带来源与置信度。优先处理“低置信度通道”当系统不确定时应输出可执行的验证流程而不是继续写一个看似确定的答案。建立错误样本库每次用户纠错都应该进入回归测试成为幻觉率指标体系的一部分。分领域报告效果不要在整体均值上自欺科研、法律、金融等子域需要单独的幻觉率数据。所有输出都要可溯源尤其是涉及结论判断、结果引用、实验推荐的内容API 层应返回证据 ID 列表或置信度标识。合规边界也必须强调。AI 生成的科研假设或论文结果可以作为“辅助材料”但不得直接替代研究者对数据和结论的最终判断。涉及文献引用时要注意版权和学术规范处理内部研究数据、临床数据、个人隐私信息时要遵守数据安全与隐私保护要求。任何自动化工具生成的内容要在发布或商用前做人工复核并明确标注 AI 参与范围。10. 总结与下一步Co-Scientist 这篇论文最有价值的不是 Gemini 模型本身而是它证明了当生成能力已经足够强时系统可靠性更多来自“流程治理”而不是模型继续变大。拆断言、做检索交叉验证、分置信度路由、引入对抗批判这些方法哪怕只做一半也能明显改善 Agent 的输出可信度。如果你现在正准备做一个科研辅助工具或知识密集型 Agent我的建议是不要急着复现完整多智能体架构先把你现有输出的断言拆分和证据校验补上跑一轮基线。这一步做扎实幻觉率下降带来的产品体验提升会比换更大参数模型更明显。后面值得继续研究的方向包括可靠性模块对多跳推理长链错误的抑制能力、不同检索库覆盖度对幻觉率上限的影响、以及如何用多智能体辩论降低错误先验带来的系统性幻觉。把这几个问题做清楚AI Agent 在专业场景里的可用性会上一个大台阶。 从46%到4%：Co-Scientist可靠性模块如何驯服大模型幻觉
这次我们不看工具看一篇论文。Google 在 Co-Scientist 里加了一个“可靠性模块”给出的结果非常直接论文结果幻觉率从 46% 落到 4%。这个数字不只是少了 9 倍的问题它说明了另一件事——大模型不是不能做科研辅助而是缺一套把“生成”和“可信”绑在一起的工程机制。很多人做大模型应用最头疼的就是模型一本正经地编造。普通聊天场景里幻觉顶多让你尴尬科研场景里幻觉会让人做出错误判断编参考文献、编实验数据、给出看似严谨但站不住脚的机制解释这些风险完全不可接受。Co-Scientist 的这条路本质上是把所有生成内容都放到“可验证性”框架里去约束。这篇论文里的可靠性设计对做 AI Agent、RAG、知识库问答、自动报告生成的人都值得拆开来看。下面我会按这个顺序展开Co-Scientist 是什么、科研场景为什么是幻觉重灾区、可靠性模块可能由哪些机制组成、46% 到 4% 靠什么拉下来、这套思路如何迁移到自己的 Agent 里、以及评估幻觉率和工程落地的常见坑。文章会给出可执行的管道伪代码、评估配置和排查清单你可以直接拿去对照自己的方案。1. Co-Scientist 是什么先搞清楚这篇论文的对象Co-Scientist 是 Google 在 AI 辅助科学研究方向上的一个多智能体系统底层使用 Gemini 系列大模型。从公开资料和论文标题来看它不是一个简单的对话机器人而是一个面向科研任务的 Agent 系统能接收研究问题组织多个模型智能体分别完成假设生成、方案设计、结果分析、批判审阅等工作最终输出带论证材料的研究建议。它最值得关注的不是“又有一个 AI 能聊天”而是它系统性地把“科学可靠性”做成了产品级流程。普通软件写错了可以改 bug论文结果写错了会浪费科研人员几周甚至几个月时间。Co-Scientist 的可靠性模块针对的就是这类错误模型生成的每一个所谓结果都要有可以被验证、被溯源、被质疑的通道。能力项说明系统定位AI 驱动的科研合作系统辅助提出假设、设计方案、批判分析结果底层技术Gemini 系列大模型多智能体协作核心成果引入可靠性模块后论文结果幻觉率从 46% 降至 4%关键设计生成与验证分离、结果可溯源、不确定性主动暴露适用对象科研人员、AI Agent 开发者、知识密集型应用团队部署门槛具体以论文版本和发布渠道为准普通开发者更应关注机制可迁移性开源状态需查阅论文对应版本说明不影响方案学习这段要提醒一句论文的 4% 是一个评估集内的结果不是“所有场景绝对只有 4%”。我们关注的重点不是这个数字被复制到所有领域而是它背后那套降低幻觉的机制能不能迁移到我们的 Agent 上。2. 科研场景为什么是幻觉重灾区先给幻觉一个可操作的判定神经网络生成了一段与可验证事实不一致、或没有任何证据支撑的内容并且在表达上没有暴露不确定性。科研内容的特殊性在于它天然使用“确定性语言”结论要明确、引用要精准、公式要能推导、实验数据要能被复现。这就导致模型在科研场景里会过度自信地表达本应带概率判断的内容。科研 Agent 里的幻觉通常表现为以下几类。幻觉类型示例危害虚假参考文献生成一篇看起来像真的论文标题、作者、期刊但实际不存在误导文献调研方向编造实验数值声称某个方法在某数据集上准确率提升 12%但没有任何实验过程影响方案取舍决策错误机制解释用因果关系解释两个变量但实际只是相关性形成错误的科研假设多跳推理断裂结合 A 文献与 B 文献推出 C 结论但 A 和 B 的关联是模型自己脑补的污染整个逻辑链46% 这个基线的存在并不意外。如果没有外部知识校验和判定机制大模型面对开放式科研问题很容易在“不存在的文献”和“想当然的结论”上翻车。科研任务越开放、候选答案空间越大幻觉率就会越高。关键结论是一个模型自己生成的答案不能只靠它自己来判断是否可靠。必须有独立于生成路径的验证通道。3. Co-Scientist 里 Agent 流程与可靠性模块的位置结合 Google 公开的多智能体科研系统介绍Co-Scientist 大体遵循一个“产生想法 - 内部批判 - 筛选排序 - 进化迭代”的流程。这里需要注意不同论文版本对 Agent 的命名和分工可能不一样以下是基于公开机制的工程化理解。阶段典型智能体角色在做什么可靠性问题在哪发散阶段生成 Agent根据研究问题提出多个候选假设、研究框架候选越多幻觉越多审阅阶段批判 Agent对候选方案挑毛病找逻辑漏洞和证据缺口批判不严格会放过错误排序阶段评估 Agent对多个方案进行可验证性和价值排序单点打分容易被表面严谨误导进化阶段迭代 Agent基于批评意见优化方案组合出新想法优化过程可能进一步放大原幻觉出稿阶段输出 Agent把最终研究建议整理成论文结果形式结果需要逐条附带证据链可靠性模块不是某个单独 Agent 的名字而是一套横跨各个环节的约束机制。它的关键动作是让“批判”和“验证”不再是流程里可有可无的调味品而是结果是否能进入下一轮的唯一门槛。更简单地说没有可靠性模块之前一个错误结论被识别出来的概率很低有了可靠性模块之后错误结论在多个交叉校验节点都会暴露。这种“错误在过程中被拦截”的设计远好过最后让用户自己人工识别幻觉。4. 可靠性模块的机制拆解46% 到 4% 靠什么拉下来这是全文最核心的部分。可靠性模块的机制可以拆成几种工程粒度来理解。需要先声明论文内部具体实现权重和模块组合需要去看原文下面的机制拆分更接近“能解释 46% 到 4% 这个量级变化的通用可靠 Agent 设计路径”也是迁移价值最高的部分。4.1 事实核查 Agent每一个关键断言都要过验证闸门首先模型生成的论文结果不能直接进入输出流程。系统会把生成内容拆解成一句一句的“可验证断言”也就是 claim-level splitting。每一句包含事实性的内容——例如“XX 算法在 XX 数据集上 F1 达到 XX”——都会进入事实核查流程。事实核查 Agent 的任务不是再写一段类似的文本而是对一个断言做三件事该断言是否有明确出处出处是否真实存在该断言从出处推导过来是否成立。如果三件事里任何一件不通过断言就需要被标记为“未验证”不得以肯定语气输出。这一层是幻觉率大幅下降的直接原因大量模型想象的“论文结果”在出稿前就被拦截。这里有一个工程细节值得强调。可靠性模块里的“事实核查”不是简单做一次向量相似度检索而是把每一个断言转化为可判定的查询任务。检索到的内容要能覆盖该断言的证据缺口而不是说“从文本风格上看起来像”。否则核查就变成了一种变相的续写。4.2 检索交叉验证打破模型单点生成的盲区降低幻觉的第二个设计是让模型的结果与外部知识源做交叉验证。单靠生成模型的内部参数本质上是在用训练数据里的分布“猜”答案。当某个问题超出模型训练分布或者模型记忆模糊时它依然会输出一个“看起来合理”的回答。交叉验证把这一步从内部判断迁移到外部比较生成的断言去检索真实文献库、知识图谱、技术文档看是否存在内容能支撑。如果外部知识源完全找不到支撑这个断言的默认状态是存疑而不是相信模型的自信表达。这也是科研 Agent 与普通聊天助手的关键差异。普通助手里 RAG 的主要作用是补充知识Co-Scientist 的可靠性模块里检索的作用更像“审计接口”——模型自己说了不算必须拿出外部证据。4.3 置信度评分与不确定性路由拿不准就承认拿不准很多幻觉问题不是模型没有意识到不确定性而是没有一条路径允许它表达不确定性。可靠性模块里工程价值最高的部分很可能是引入了明确的置信度路由高置信度 证据充分 - 正常输出中置信度 证据不足 - 输出时额外标注“需要人工复核”低置信度 - 不输出具体结论而是返回“证据不足给你生成可验证的实验方案”。这个逻辑的目标不是让系统永远正确而是保证系统不会用错误的确定性口吻误导研究者。科研场景里“我不确定”本身就是一个合法答案。真正不可接受的是“明明不确定却把话说死了”。4.4 生成与批判分离用多智能体对抗消除同源偏置可靠性模块的另一层设计是让“写方案”的 Agent 和“批方案”的 Agent 尽可能独立。如果生成模型和批判模型是同一个模型、同一套上下文就会出现很明显的同源偏置模型更倾向于维护自己刚刚生成的内容批判 Agent 很难发现真正的问题。多智能体对抗的价值就是制造“制度化的怀疑”。一个 Agent 负责构造乐观方案另一个 Agent 被指令要求寻找方案里最薄弱的证据链。两个角色目标不一致反而更容易暴露错误。对于科研场景这种对抗还应该引入外部信号——真实论文的审稿意见、实验日志、基准数据集指标——而不是只靠两个 LLM 之间互相辩论。纯 LLM 互辩可以提升逻辑自洽性但解决不了事实性错误。Co-Scientist 的可靠性模块之所以能把幻觉率压到 4% 量级应该不只是智能体互怼而是对每一条结果都做了证据回填。4.5 自洽性与多路采样同一问题多次独立生成科研结论要具备可复现性Agent 的生成结果也一样。可靠性模块很容易引入 self-consistency 机制对同一个研究问题做多次采样观察模型是否稳定输出同一个结论。如果多次生成结果在关键论点上互相矛盾那么该结论的可靠性就要被下调。这个机制本质上是在利用随机采样做置信度校验。模型如果只是“偶尔一次”说出某个结果可信度低如果多次独立生成都指向同一个方向和结论可信度显著增加。这个方法在推理任务里已经很成熟迁移到科研 Agent 后能有效压制“碰运气式”的幻觉。4.6 人类反馈闭环科学家把错误喂回系统最后一部分是人工反馈回路。科学家在使用 Co-Scientist 时如果发现某条输出是幻觉这个反馈不会止于一次人工修正而是进入可靠性模块的评价集成为后续校验的负面样本。这正是很多 Agent 项目容易忽略的部分。幻觉率指标要可持续下降必须有一个“错误样本库”在持续扩容。否则系统只会在一开始优化几次很快进入瓶颈。5. 从论文到工程把可靠性模块拆成分层设计上面那些机制很多做过 Agent 的同学都听过但落地时会发现很难全部做到。一个更工程化的拆法是把可靠性模块当成 4 层管道来设计。层级核心目标典型实现出错后果Generation 生成层在尽量大的假设空间内产生候选结果多路采样、不同 prompt 策略、生成不同角度的方案覆盖率不足错过正确方向Verification 验证层判断每一条断言是否有证据支撑检索交叉验证、事实核查 Agent、主张拆分幻觉漏网错误结果流入决策层Decision 决策层衡量置信度后决定输出、拒绝或转人工置信度评分、不确定性路由、自洽性投票正确结果被误杀或错误结果以高置信度发出Feedback 反馈层将人工纠错纳入系统记忆错误样本库、评估集更新、规则回填幻觉率下降空间有限错误重复出现四层当中验证层是决定幻觉率上限的关卡。如果验证层只是摆设后面的决策层再精细也拦不住错误内容。实际开发中你可以先只做两层claims 拆分 置信度阈值路由。把这两层跑通再逐步加入检索验证和对抗评审。一张图式理解就是生成结果不是答案只是“候选证据包”系统真正输出的内容是“候选证据包经过验证和过滤后的剩余结论”。6. 在自己的 Agent 中做一个简化版可靠性模块如果你想在本地项目或 API 接入的场景里复刻这套思路不需要完整复现 Co-Scientist。直接在一套 Agent 管道的生成结果之后接入一个 verify-and-route 模块就能让幻觉率明显下降。下面给出一套可用于流程验证的 Python 示例。注意这只是工程演示骨架模型名、接口路径和提示词模板需要替换为你实际接入的服务。# 简化版可靠性管道生成 - 断言拆分 - 核查 - 路由 # 依赖openai 或 google-generativeai 等 SDK按实际项目接入 import json from typing import List, Dict def split_claims(text: str) - List[str]: 把模型生成文本拆成一句句可验证断言。 实际项目里可以用 LLM 完成也可以用规则先做粗拆。 # 示例规则按句号拆并丢弃过短和疑问句 sentences [s.strip() for s in text.replace(\n, ).split(。) if len(s.strip()) 10] return sentences def check_claim_with_source(claim: str) - Dict[str, object]: 对单条断言做证据核查。 这里应该调用外部检索接口、知识库或可信语料库。 # 伪代码检索接口结果具体需要换成自己的 Search/Retrieval API # evidence retrieval_api.query(claim) evidence_score 0.7 # 示例值必须按你的检索链路计算 # 判定逻辑检索不到证据时默认标记为未验证 if evidence_score 0.5: return { claim: claim, status: unverified, evidence_score: evidence_score, action: low_confidence_route } return { claim: claim, status: verified, evidence_score: evidence_score, action: allow_output } def route_by_confidence(claims: List[Dict[str, object]]) - Dict[str, object]: 根据断言核查结果决定最终输出策略。 verified [c for c in claims if c[status] verified] unverified [c for c in claims if c[status] unverified] if not verified and unverified: return { final_status: not_confident, message: 证据不足建议仅输出实验验证方案不直接给出结论。 } return { final_status: confident, output_claims: verified, needs_review: unverified } def generate_candidate_research_result(question: str) - str: 示例函数调用 LLM 生成候选结果。 具体调用方式取决于你使用的模型服务。 # client OpenAI(api_key..., base_url...) # resp client.chat.completions.create(...) # 这里返回模拟结果 return (根据迁移学习理论在生物医学文本摘要任务中使用领域自适应预训练 可以将 ROUGE-L 分数提升 4.2 个百分点。该结果在 PubMed 测试集上验证。) def reliability_pipeline(question: str) - Dict[str, object]: # 1. 生成候选结果 raw_text generate_candidate_research_result(question) # 2. 断言拆分 claims split_claims(raw_text) print(拆分段数:, len(claims)) # 3. 逐条核查 checked_claims [check_claim_with_source(c) for c in claims] # 4. 路由 result route_by_confidence(checked_claims) # 5. 保留人工复核标记 return { question: question, raw_text: raw_text, claims: checked_claims, routing_result: result } if __name__ __main__: demo reliability_pipeline(领域自适应预训练是否提升生物医学文本摘要质量) print(json.dumps(demo, ensure_asciiFalse, indent2))上面的代码体现了三个最核心的工程模板不是直接输出大模型原文而是先拆成断言每条断言都有状态字段系统可以根据断言的状态确定能否以肯定语气输出。字段可以按实际项目改造成数据库记录。下面再给一个“最少验证规则”的 JSON 配置示例。它把核查 Agent 的关键参数单独抽出来方便做 AB 测试。{ claim_split_config: { min_length: 10, split_by_punctuation: true, drop_question_sentence: true, drop_subjective_sentence: true }, evidence_checker: { retrieval_top_k: 5, min_evidence_score: 0.6, require_source_id: true, search_timeout_seconds: 10 }, routing: { high_confidence_threshold: 0.8, low_confidence_threshold: 0.5, unverified_action: human_review_or_refuse, allow_low_confidence_with_warning: true } }最后是一个通用外部检索调用的 curl 示意。具体接口、鉴权、参数需要按你实际接入的知识库或搜索 API 调整不要把下面的 URL 当真实接口使用。# 示意把 claim 发给检索服务返回可验证记录 # 实际使用时需要替换为项目自己的检索 API 地址和鉴权 curl -X POST http://127.0.0.1:8000/evidence_check \ -H Content-Type: application/json \ -d { claim: 领域自适应预训练在 PubMed 摘要任务上将 ROUGE-L 提升 4.2 个百分点, top_k: 5, need_source: true }整套简化版管道的核心不是代码多复杂而是流程上强制“结果必须经过验证”。一旦一个 Agent 的输出默认不是答案而只是候选方案幻觉率自然会下降。7. 评估幻觉率怎么得到 46% 到 4% 的可信对比如果你在自己的 Agent 里做了可靠性模块接下来一定是灵魂问题幻觉率降到多少了这需要先定义评估口径。幻觉率不是“模型偶尔胡说八道”而是在一定的测试任务样本中模型输出中被判定为“与可验证事实不一致或缺乏证据支撑”的比例。一个可落地的评估设计包括三个层面。评估层面检查内容判定标准引用层面参考文献、来源链接、代码仓库是否存在捏造即算幻觉事实层面数值、指标、时间、机构名是否与真实资料一致与检索结果不一致即算幻觉推理层面结论是否能由上文证据推出是否存在逻辑跳跃多步推理无法回推即算幻觉用公式表示就是幻觉率 幻觉断言数 / 总断言数 或 样本级幻觉率 出现至少一个幻觉断言的样本数 / 总样本数更重要的一点Co-Scientier 论文里的 46% 到 4%是在它自己的测试任务分布上得到的。不同任务、不同领域、不同证据库覆盖程度下绝对数字会差非常多。比如在长尾科学问题上检索库覆盖不足幻觉率起点可能就低不了。因此更合理的做法是在自己的测试集上先测基线再测加模块后的效果比较相对下降幅度。除了绝对幻觉率还需要记录一个反向指标——覆盖率。很多过滤方法会把正确结果一起误杀。如果为了把幻觉率从 40% 压到 4%导致 60% 的正确结果被系统判定为“未验证”那这个系统在真实场景不可用。8. 工程落地时的常见误区和排查方法很多团队看完这套方案后会直接抄作业但实际跑起来会发现效果不稳定。下面按出现频率列出几类常见问题。问题现象可能原因排查方式解决方案加了核查 Agent 后幻觉率仍然高核查 Agent 与生成 Agent 同源标准过松查看核查 Agent 对已确认幻觉样本的判定结果更换不同模型做验证引入更强的外部检索约束可信结果被大量误杀置信度阈值过高或证据缺失被当成假内容统计被拦截内容的正确率区分“无证据”和“有反证”无证据可以转人工而非直接拒绝检索结果查不到模型仍坚持输出prompt 里给了模型过高的自由裁量权检查 system prompt 是否允许“编造来源”强制要求输出必须附带证据 ID无 ID 不输出幻觉率在测试集 A 降了测试集 B 又上升评估集与模型训练数据分布接近构建更新、更冷门的评估子集按领域拆分报告不只看整体均值多智能体互辩后错误反而增加对抗评审缺少外部事实约束复盘被批评意见“说服”的样本让批评意见必须给出检索证据不能只说观点多路采样结果一致但依然错误多条采样共享了同一个错误先验分析错误模式是否来自 prompt 或检索库更换提示词模板、引入外部反例检索输出变保守很多问题不敢回答不确定性路由把太多问题转给人工查看路由决策日志中的置信度分布降低转人工阈值允许带警告输出低置信度结果最容易踩的坑是第一行验证模块和生成模块用同一个模型、同一套温控参数。同源模型会共享系统性能只是“自己查自己”很难发现错误。建议至少在验证环节换一个不同规模的模型或同模型不同角色提示词来减弱自我一致性偏置。9. 对 Agent 开发者的建议与合规边界可靠性模块的价值不只属于科研 Agent。做知识库问答、法律文书辅助、技术报告生成、金融分析摘要的开发者其实都面对同一个问题模型输出不能直接作为决策依据。给 Agent 开发者的落地建议包括把“输出控制”改为“结果认证”不要只调 prompt 让模型别胡说而是让结果必须携带来源与置信度。优先处理“低置信度通道”当系统不确定时应输出可执行的验证流程而不是继续写一个看似确定的答案。建立错误样本库每次用户纠错都应该进入回归测试成为幻觉率指标体系的一部分。分领域报告效果不要在整体均值上自欺科研、法律、金融等子域需要单独的幻觉率数据。所有输出都要可溯源尤其是涉及结论判断、结果引用、实验推荐的内容API 层应返回证据 ID 列表或置信度标识。合规边界也必须强调。AI 生成的科研假设或论文结果可以作为“辅助材料”但不得直接替代研究者对数据和结论的最终判断。涉及文献引用时要注意版权和学术规范处理内部研究数据、临床数据、个人隐私信息时要遵守数据安全与隐私保护要求。任何自动化工具生成的内容要在发布或商用前做人工复核并明确标注 AI 参与范围。10. 总结与下一步Co-Scientist 这篇论文最有价值的不是 Gemini 模型本身而是它证明了当生成能力已经足够强时系统可靠性更多来自“流程治理”而不是模型继续变大。拆断言、做检索交叉验证、分置信度路由、引入对抗批判这些方法哪怕只做一半也能明显改善 Agent 的输出可信度。如果你现在正准备做一个科研辅助工具或知识密集型 Agent我的建议是不要急着复现完整多智能体架构先把你现有输出的断言拆分和证据校验补上跑一轮基线。这一步做扎实幻觉率下降带来的产品体验提升会比换更大参数模型更明显。后面值得继续研究的方向包括可靠性模块对多跳推理长链错误的抑制能力、不同检索库覆盖度对幻觉率上限的影响、以及如何用多智能体辩论降低错误先验带来的系统性幻觉。把这几个问题做清楚AI Agent 在专业场景里的可用性会上一个大台阶。