论文结果里一个数字比“又强了多少个点”更值得被记住把 AI 科研智能体输出的幻觉率从约 46% 打到约 4%。这次我们不聊 GPU 部署也不聊某个本地一键包而是一个发生在科研智能体身上的工程问题模型生成的结论看起来很专业但没有文献或实验证据支撑该怎么办。Google 团队在 AI Co-Scientist 这条线上更新的可靠性模块就是把“生成结论”和“验证结论”拆开让一个独立验证环节去拦截没有证据支持的结果最终把论文结果幻觉率压到了个位数。这篇文章会把几件事讲清楚这个 46% 到 4% 是怎么测出来的可靠性模块在 Co-Scientist 架构里放在什么位置如果要在自己的 Agent 管线里复现“生成 验证 过滤”这套降幻觉方案需要准备什么数据、怎么写评测脚本、怎么判断效果是真是假。1. 核心信息速览先把材料里信息密度最高的部分列出来。下面的口径来自 Google 公开论文和技术说明具体实验环境、测试集范围、模型版本不同数值会有浮动但趋势是一致的验证模块能显著压低胡编乱造成分。项目主体Google AI Co-Scientist一个面向科学假设发现的多智能体系统技术方向将科学方法流程化生成、反思、排序、进化、复核、验证底层模型Gemini 系列实际版本要按官方论文和发布说明为准核心改进点增加可靠性/验证模块在结果呈现前先做证据链核对关键效果论文结果幻觉率从约 46% 降至约 4%公开测试口径非通用绝对值可靠性判断方式基于给定文献/实验证据判断结论是否被支持、被反驳或证据不足系统入口官方云端科研协作入口与 API 为主需按 Google 最新发布渠道接入本地部署未见官方开放完整权重与一键部署包一般用户适合复用自己的评测方案典型适用者科研假设探索、证据综述、实验方案设计、Agent 可靠性治理相关的开发团队有几个点必须说清楚。第一这个 46% 到底是谁的幻觉率是基线系统输出里存在无证据支撑结论的比例而不是说每个回答都错一半。第二4% 也不是“答案完全正确率 96%”而是“结论有据可查”的比例提高。两者含义差别很大评测时要特别注意口径。2. 先理解这个数字46% 到 4% 到底意味着什么幻觉率在科研智能体场景里是致命的。日常对话场景里模型给出一个错误日期用户顶多觉得不靠谱但科研智能体输出的是一套可以被人拿去做实验、写论文、推进课题的半成品结论。如果其中一半左右的内容无法被证据支撑这个系统就不能作为科研辅助工具进工作流。Google 给出的差值说明的是一个基础事实没有显式验证机制的大模型科研工作流会稳定地产出一批“形式上专业、证据上悬空”的结果。这个问题光靠换更大的模型、写更强的提示词很难根治因为生成式模型的本质就是逐词预测它并不天然知道自己在生成一个结论之前是否曾经见过支持这个结论的文献。可靠性模块要解决的是在模型的自信息里架一道外部检查不管生成器本身多自信只要最终结论无法在给定证据集里找到支撑就不应该被当作可交付结果。这就是为什么论文里这个改善程度值得信任——它不是把模型变聪明了而是把系统从“生成器”改成了“生成器 法官”的两段式结构。判断标准也要展开看。一篇论文里幻觉可能出现在摘要、方法、结果、讨论任何一个位置。Google 这套验证器不是逐句做语法检查而是对“研究结论 / 实验发现 / 机制判断”这类命题性内容做证据核对看它们与文献和实验数据是否存在一致性。从工程角度可以简化成一句话结论要有出处出处要能支撑结论。3. Co-Scientist 多智能体架构里可靠性模块放在哪里AI Co-Scientist 并不只是一个带对话界面的 Gemini 封装。从公开资料看它内部是按科研工作的子任务拆分的多智能体工作流。材料中反复提到的角色大致可以归成两类生成与演化类智能体负责提出候选假设根据已有文献做变异、组合、进化模拟科学家的头脑风暴过程。评估与筛选类智能体负责给候选结果打分、找弱点、检查与现有证据是否冲突。可靠性模块最合理的插入位置是“生成结束”到“结果进入用户侧”之间。它更像论文投稿前的最后一道审稿而不是跟随生成过程同步打分的软约束。为什么放在最后更合理如果验证器在每一步生成过程里都介入会拖慢整条探索链路而如果完全不介入又会让大量无效假设污染排序结果。所以常见做法是先生成一批候选再用验证器做高精度过滤让通过率作为一层数据输入反馈给排序模块。这种“先广后严”的流程在工程上非常像推荐系统的召回加精排。生成器是召回负责扩大可能的假设空间验证器是精排负责把没有证据基础的结论剔除。两个模块目标不同不能混成一个。这给所有开发 Agent 应用的人一个直接启发当输出质量不够稳定时第一步不是重写生成 prompt而是检查你是否在生成链路之外单独设了一个验证节点。4. 可靠性模块的工作逻辑不是“检查错别字”是“证据链核对”综合 Google 论文中验证器相关描述可以把可靠性模块的核心判断模式理解为给定一个候选结论验证智能体先去权威语料、文献库或实验数据中定位与它相关的证据片段然后对两者关系做分类。分类体系在具体实现里可能有差异但最常见的是三种类别支持证据直接支撑结论的全部或关键部分。反驳证据与结论存在冲突结论可能被推翻。证据不足或无关联现有资料不足以判断结论真伪。更粗粒度的工程实现还可以加一个“部分支持但不完整”的类别用于映射科研结果中常见的灰色地带。比如一篇论文的机制假设只有间接证据验证器如果只会判断支持和反驳就会表现得很绝对反而不科学。验证器的工作效果依赖三个条件检索质量它能不能在证据库中命中与结论真正相关的页面。如果检索结果本身是零散或错误的后续判断自然失真。判断 prompt 的稳定度同一个结论用不同表达方式输入验证器是否仍然给出相似判断。判断口径不稳定幻觉率下降就只是偶然。结论切分方式把一个包含多个命题的复杂论断整段丢给验证器和拆成单一命题分别验证结果差异很大。应优先对单一命题做验证。一个可以借鉴的判断原则是验证器输出的不是“这段话是对的还是错的”而是“这段话是否可以由证据集合推导出来”。两者在实践中有本质区别。前者要求验证器掌握世界知识后者只要求它建立逻辑映射关系复杂度小得多可靠性也容易控制。5. 想复现这种“幻觉率下降”评测环境怎么搭Google 没有公开让人一键复现的完整训练包但有公开论文和数据集里的评估思路。想在自有场景里复现一次“加 verifier 前后幻觉率变化”实验并不需要拥有 Google 的完整系统只需要构造一套最小可用的评测闭环。这里给出一套通用评测方案可以直接迁移到论文综述、行业报告生成、医疗文献解析等场景。5.1 评测数据构造准备三部分内容问题集从目标场景中选 50 到 200 个真实研究问题覆盖不同子方向。问题不宜太宏大否则验证器难以定位局部证据。语料库每个问题配套一批候选文献、临床指南或内部研究报告。语料库必须包含与问题直接相关的“正证据”也要包含部分无关文档用于测试验证器是否会把不相关内容误判为支持。答案生成基准让同一个生成器在关闭验证器和开启验证器两种模式下对相同问题集分别输出最终结论。5.2 幻觉率标注口径幻觉率需要先定义再计算。推荐一套简单可执行的标准标注项定义幻觉结论中的关键命题无法在给定语料库中找到证据支撑或与证据矛盾完整关键命题可以被语料库中的至少一条证据直接支撑部分结论只有部分子命题有证据其余无证据但也没有被反驳幻觉率计算公式幻觉率 幻觉样本数 / 总样本数如果想更严格还可以统计“部分支撑”类样本中无证据子命题的占比。Google 报告里的口径大概率比这个严格这里给出的是一个本地可执行的近似版。实际使用时测试集越大、人工复核比例越高数值越可靠。5.3 评测脚本参考用 Python 写一个幻觉率归因脚本。它读取一个包含“结论文本”的 JSONL每条调用验证器返回 label最后统计比例。import json from collections import Counter LABELS {supported, unsupported, partial, contradicted} def load_samples(path): with open(path, r, encodingutf-8) as f: return [json.loads(line) for line in f if line.strip()] def compute_metrics(samples): counter Counter() for s in samples: label s.get(verifier_label, unsupported) counter[label] 1 total len(samples) hallucination_ratio (counter[unsupported] counter[contradicted]) / total return { total: total, label_distribution: dict(counter), hallucination_ratio: round(hallucination_ratio, 4), } def main(): samples load_samples(samples.jsonl) metrics compute_metrics(samples) print(json.dumps(metrics, ensure_asciiFalse, indent2)) if __name__ __main__: main()运行前要把 samples.jsonl 里每条数据的 verifier_label 补全补全方式可以是人工标注也可以是另一个 LLM 判断后人工抽检。5.4 对比流程设计要证明“可靠性模块降低了幻觉率”不是跑一遍得出 4% 就行必须做双系统对照。推荐流程如下同一组问题分别用 Baseline 系统和带验证器的系统生成结果。对两组结果混洗打乱标注者或评分模型不知道哪条来自哪个系统。分别统计两组的幻觉率。两组差异做简单显著性检验后再下结论。这样可以避免一个常见陷阱用户在验证器开启后为了减少最终输出悄悄把答案改短了导致“幻觉率下降”只是因为表达更长更容易出错而不是可靠性模块起效。6. 把“验证器”接到自己的 Agent 管线里Co-Scientist 的可靠性模块逻辑完全可以抽出来接到其他科研、知识生产类 Agent 流程里。核心思路是增加一道验证过滤循环生成器给出候选答案 - 验证器检查每个关键命题 - 通过则交付不通过则打回重写或丢弃。6.1 验证器 Prompt 参考这里给出一个通用的验证 prompt 模板。它不绑定具体厂商可在调用 Gemini、GPT、Claude 或其他国产长文本模型时使用按自家模型能力调整即可。你是一个严谨的证据验证员。你的任务不是判断“观点是否有趣” 而是判断“给定结论能否被用户提供的证据支持”。 待验证结论 {conclusion} 可参考证据 {evidence_chunks} 请按以下规则回答 1. 如果证据直接支持结论的关键命题输出 supported。 2. 如果证据与结论矛盾输出 contradicted。 3. 如果证据存在但不足以证明结论输出 partial。 4. 如果证据无法定位到相关命题输出 unsupported。 只输出一个单词supported受支持这个 prompt 的重点是把“观点是否专业”从判断标准里拿掉强制模型只做命题与证据的映射。如果你发现验证器输出有系统性偏松或偏严可以在结尾追加一小段“判定阈值说明”加以校准。6.2 带过滤的科研 Agent 伪代码实际工程里验证器与主流程是异步调用关系。下面提供一个生成—验证—过滤的最小实现骨架供后续改造import asyncio from dataclasses import dataclass dataclass class Candidate: content: str verifier_label: str pending async def generate_candidates(problem: str) - list[str]: # 对接生成模型返回多个假设或结论草稿 ... async def verify_conclusion(candidate: Candidate, evidence: list[str]) - str: # 调用验证 prompt返回 supported/partial/unsupported/contradicted ... async def research_pipeline(problem: str, evidence: list[str]): raw_candidates await generate_candidates(problem) tasks [verify_conclusion(Candidate(c), evidence) for c in raw_candidates] labels await asyncio.gather(*tasks) verified [] for cand, label in zip(raw_candidates, labels): if label in {supported, partial}: verified.append(Candidate(cand, label)) return verified async def main(): problem ... evidence [......] outputs await research_pipeline(problem, evidence) for item in outputs: print(item.label, item.content)这段代码体现的核心工程要点生成候选和验证候选解耦验证过程允许多个候选并行通过“supported”和“partial”两种标签进入最终交付集合。6.3 重试与降级策略验证器的输出未必一步到位。推荐配置两层策略若结论被评判unsupported系统可以重新生成一次结论并自动补充更显式的证据来源描述再进行二次验证。若反复出现unsupported更稳妥的决定是丢弃该候选不让它进入最终交付因为这大概率是生成侧本身没有可依托的素材。重新生成行为最多建议重试一到两轮避免形成无意义循环让推理成本成倍上升。7. 资源开销与性能观察给 Agent 增加验证环节不是免费的。最直观的成本来自三处额外模型调用 token、证据检索的索引查询时间、多轮重试带来的并发压力。在 Google 的论文级场景里算力由云端 TPU 集群承担用户不太会关心显存但一旦把这种方案搬到自有服务里就要把这些成本计入。以下按本地或云端 API 两种形态给出可观测维度具体情况需要以本机测试为准。环节主要开销优化手段证据检索向量库查询耗时与语料库规模相关预切片、分层索引、限制每个结论检索的 chunk 数量验证判断token 消耗一次结论一次大模型调用同批候选并行调用、复用缓存结果重试循环失败轮次会产生额外生成和验证调用设置最大重试次数如 1 到 2 次数据准备语料入库前的清洗和 embed 向量化离线执行不与在线检索路径耦合另一个值得关注的是端到端时延。验证器开启后单条结论交付从“纯生成”变成“生成 检索 验证”一般会增加数倍耗时。批量场景下可以通过加大并发来摊薄时延但如果接口有并发限制就需要在队列中增加流控。如果观察发现验证后的结果中partial比例长期偏高建议优先排查证据语料是否覆盖不足其次再调验证 prompt。不要一上来就把阈值放宽松那样只会掩盖证据缺口。8. 常见问题与排查方法把幻觉率从 46% 压到 4%听起来很理想但本地复现时往往没这么顺利。问题现象可能原因排查方式解决方案加了验证器后幻觉率没有明显下降验证器判断口径过松大量 unsupported 被误判为 supported抽 30 条人工复核验证器原始输出收紧 prompt增加“证据直接支持”判定条件结论被大量误杀验证通过率过低生成模型习惯输出无出处长文或验证器把部分支撑当不支持查看被拒结论是否真的没有相关证据优化检索召回改判 partial 为允许交付指标波动较大两次评测结果不一致评测集样本太少或问题集中在小众方向看每轮结果的分布而非只看平均值扩充到 50 个以上问题分层覆盖验证器对同一结论在不同表达下判断不一致模型随机性或 prompt 表达缺乏稳定性同一结论换 3 种表达分别调用 3 次调整 temperature在 prompt 中增加格式约束引入验证后成本超预算每个候选都调用验证模型且存在高频重试在日志中统计每次验证消耗的 token 与调用次数验证结果做缓存、减少重试次数、增加批量并发遇到幻觉率没降下来的情况先不要怀疑验证器原理而是先检查评测集里“被判定为 supported 的样本真的都有证据吗”。实践中八成以上的幻觉率复现失败来自标注口径不统一而不是模型能力问题。9. 从论文到工程科研 Agent 的可靠性实践建议Google 这篇工作的价值不在“做了个 app”而在于它给出了一套可以复用的可靠性治理范式。按重要程度排序下面几条最有借鉴意义。第一必须把结论生成和结论验证拆成两个独立角色。如果同一个模型既当运动员又当裁判它的“自我一致性偏好”会掩盖幻觉。即使使用同一基座模型也要通过不同的上下文角色、检索策略和判断 prompt 把两条链路隔离。第二证据颗粒度要够细。验证时不是让模型看整篇论文 PDF而是把结论拆成“一个个可被证明或证伪的命题”再给它配对应的局部证据段落。命题拆分让验证器不需要处理大段混沌信息判断质量和稳定性都会提高。第三建立可回查记录。每条交付结论都要保留支持它的证据 ID 和验证结果。这样做有两个好处一是使用者可以直接点开原始文献确认二是当最终报告出错时可以追溯到是证据库缺失、检索失败还是验证判断失误而不是对着整条输出干瞪眼。第四设计灰度标准。不要追求所有输出都达到“100% 可验证”。科研领域大量结论本来就处于假说状态把 partial 类结果单独标记为“需实验验证”比直接拦掉更符合科研工作流习惯。Google 那 4%大概率也不是零风险而是残余风险被明确标记出来。第五人工抽检不能省。LLM 验证器和人工验证互为补充。建议每个验证批次中人工抽检 5% 到 10% 的supported样本确认验证器没有在证据不充分的情况下给出过宽判断。抽检结果既用于质量审计也可以周期性回流调整验证 prompt。第六版权与隐私合规同样适用于科研智能体。涉及患者数据、商业实验数据或未公开论文进行系统综述与假设发现时在把语料投入检索和验证前必须先确认数据使用边界和授权。不要因为验证器是系统内部模块就忽略了数据隐私合规。10. 这件事对做 Agent 的人意味着什么换个视角看这个“46% 到 4%”对普通技术选型有一个非常实用的反向启发如果你正在做一个面向专业领域的 Agent 系统第一优先级的开发任务不一定是把生成模型换到更大的参数版本而是尽快加一层能对输出结果进行证据审计的验证模块。它告诉你的信息是即使在 Agent 协作任务中决定质量上限的不再只是单模型智商而是系统的自我纠错控制回路。生成器负责拓宽可能性验证器负责守住可信度两套机制彼此制约时最终面向用户的输出才会更接近“可交差”状态。顺着这个方向往下走项目团队可以安排下一步工作扩充领域实验证据库打造更细粒度的论文命题级评测集在验证器判断逻辑中加入“反事实检验”——结论若为因果性判断使用反事实样本做对抗测试再把验证器的中间结果以结构化 JSON 输出接入报告生成链路使最终论文稿自带证据地图。对大多数开发团队而言短期内要完整复现 Google 的多智能体科研系统并不现实但把“生成后再验证、验证后留证据”这套思路用到自己的知识库问答、报告生成或数据处理流程里门槛并不高。一个 prompt 模板、一份标注规范、一段并行调用代码就能把可靠性意识做成 Agent 基础设施的一部分。
科研智能体幻觉率直降46%至4%：生成+验证+过滤可靠性架构解析
论文结果里一个数字比“又强了多少个点”更值得被记住把 AI 科研智能体输出的幻觉率从约 46% 打到约 4%。这次我们不聊 GPU 部署也不聊某个本地一键包而是一个发生在科研智能体身上的工程问题模型生成的结论看起来很专业但没有文献或实验证据支撑该怎么办。Google 团队在 AI Co-Scientist 这条线上更新的可靠性模块就是把“生成结论”和“验证结论”拆开让一个独立验证环节去拦截没有证据支持的结果最终把论文结果幻觉率压到了个位数。这篇文章会把几件事讲清楚这个 46% 到 4% 是怎么测出来的可靠性模块在 Co-Scientist 架构里放在什么位置如果要在自己的 Agent 管线里复现“生成 验证 过滤”这套降幻觉方案需要准备什么数据、怎么写评测脚本、怎么判断效果是真是假。1. 核心信息速览先把材料里信息密度最高的部分列出来。下面的口径来自 Google 公开论文和技术说明具体实验环境、测试集范围、模型版本不同数值会有浮动但趋势是一致的验证模块能显著压低胡编乱造成分。项目主体Google AI Co-Scientist一个面向科学假设发现的多智能体系统技术方向将科学方法流程化生成、反思、排序、进化、复核、验证底层模型Gemini 系列实际版本要按官方论文和发布说明为准核心改进点增加可靠性/验证模块在结果呈现前先做证据链核对关键效果论文结果幻觉率从约 46% 降至约 4%公开测试口径非通用绝对值可靠性判断方式基于给定文献/实验证据判断结论是否被支持、被反驳或证据不足系统入口官方云端科研协作入口与 API 为主需按 Google 最新发布渠道接入本地部署未见官方开放完整权重与一键部署包一般用户适合复用自己的评测方案典型适用者科研假设探索、证据综述、实验方案设计、Agent 可靠性治理相关的开发团队有几个点必须说清楚。第一这个 46% 到底是谁的幻觉率是基线系统输出里存在无证据支撑结论的比例而不是说每个回答都错一半。第二4% 也不是“答案完全正确率 96%”而是“结论有据可查”的比例提高。两者含义差别很大评测时要特别注意口径。2. 先理解这个数字46% 到 4% 到底意味着什么幻觉率在科研智能体场景里是致命的。日常对话场景里模型给出一个错误日期用户顶多觉得不靠谱但科研智能体输出的是一套可以被人拿去做实验、写论文、推进课题的半成品结论。如果其中一半左右的内容无法被证据支撑这个系统就不能作为科研辅助工具进工作流。Google 给出的差值说明的是一个基础事实没有显式验证机制的大模型科研工作流会稳定地产出一批“形式上专业、证据上悬空”的结果。这个问题光靠换更大的模型、写更强的提示词很难根治因为生成式模型的本质就是逐词预测它并不天然知道自己在生成一个结论之前是否曾经见过支持这个结论的文献。可靠性模块要解决的是在模型的自信息里架一道外部检查不管生成器本身多自信只要最终结论无法在给定证据集里找到支撑就不应该被当作可交付结果。这就是为什么论文里这个改善程度值得信任——它不是把模型变聪明了而是把系统从“生成器”改成了“生成器 法官”的两段式结构。判断标准也要展开看。一篇论文里幻觉可能出现在摘要、方法、结果、讨论任何一个位置。Google 这套验证器不是逐句做语法检查而是对“研究结论 / 实验发现 / 机制判断”这类命题性内容做证据核对看它们与文献和实验数据是否存在一致性。从工程角度可以简化成一句话结论要有出处出处要能支撑结论。3. Co-Scientist 多智能体架构里可靠性模块放在哪里AI Co-Scientist 并不只是一个带对话界面的 Gemini 封装。从公开资料看它内部是按科研工作的子任务拆分的多智能体工作流。材料中反复提到的角色大致可以归成两类生成与演化类智能体负责提出候选假设根据已有文献做变异、组合、进化模拟科学家的头脑风暴过程。评估与筛选类智能体负责给候选结果打分、找弱点、检查与现有证据是否冲突。可靠性模块最合理的插入位置是“生成结束”到“结果进入用户侧”之间。它更像论文投稿前的最后一道审稿而不是跟随生成过程同步打分的软约束。为什么放在最后更合理如果验证器在每一步生成过程里都介入会拖慢整条探索链路而如果完全不介入又会让大量无效假设污染排序结果。所以常见做法是先生成一批候选再用验证器做高精度过滤让通过率作为一层数据输入反馈给排序模块。这种“先广后严”的流程在工程上非常像推荐系统的召回加精排。生成器是召回负责扩大可能的假设空间验证器是精排负责把没有证据基础的结论剔除。两个模块目标不同不能混成一个。这给所有开发 Agent 应用的人一个直接启发当输出质量不够稳定时第一步不是重写生成 prompt而是检查你是否在生成链路之外单独设了一个验证节点。4. 可靠性模块的工作逻辑不是“检查错别字”是“证据链核对”综合 Google 论文中验证器相关描述可以把可靠性模块的核心判断模式理解为给定一个候选结论验证智能体先去权威语料、文献库或实验数据中定位与它相关的证据片段然后对两者关系做分类。分类体系在具体实现里可能有差异但最常见的是三种类别支持证据直接支撑结论的全部或关键部分。反驳证据与结论存在冲突结论可能被推翻。证据不足或无关联现有资料不足以判断结论真伪。更粗粒度的工程实现还可以加一个“部分支持但不完整”的类别用于映射科研结果中常见的灰色地带。比如一篇论文的机制假设只有间接证据验证器如果只会判断支持和反驳就会表现得很绝对反而不科学。验证器的工作效果依赖三个条件检索质量它能不能在证据库中命中与结论真正相关的页面。如果检索结果本身是零散或错误的后续判断自然失真。判断 prompt 的稳定度同一个结论用不同表达方式输入验证器是否仍然给出相似判断。判断口径不稳定幻觉率下降就只是偶然。结论切分方式把一个包含多个命题的复杂论断整段丢给验证器和拆成单一命题分别验证结果差异很大。应优先对单一命题做验证。一个可以借鉴的判断原则是验证器输出的不是“这段话是对的还是错的”而是“这段话是否可以由证据集合推导出来”。两者在实践中有本质区别。前者要求验证器掌握世界知识后者只要求它建立逻辑映射关系复杂度小得多可靠性也容易控制。5. 想复现这种“幻觉率下降”评测环境怎么搭Google 没有公开让人一键复现的完整训练包但有公开论文和数据集里的评估思路。想在自有场景里复现一次“加 verifier 前后幻觉率变化”实验并不需要拥有 Google 的完整系统只需要构造一套最小可用的评测闭环。这里给出一套通用评测方案可以直接迁移到论文综述、行业报告生成、医疗文献解析等场景。5.1 评测数据构造准备三部分内容问题集从目标场景中选 50 到 200 个真实研究问题覆盖不同子方向。问题不宜太宏大否则验证器难以定位局部证据。语料库每个问题配套一批候选文献、临床指南或内部研究报告。语料库必须包含与问题直接相关的“正证据”也要包含部分无关文档用于测试验证器是否会把不相关内容误判为支持。答案生成基准让同一个生成器在关闭验证器和开启验证器两种模式下对相同问题集分别输出最终结论。5.2 幻觉率标注口径幻觉率需要先定义再计算。推荐一套简单可执行的标准标注项定义幻觉结论中的关键命题无法在给定语料库中找到证据支撑或与证据矛盾完整关键命题可以被语料库中的至少一条证据直接支撑部分结论只有部分子命题有证据其余无证据但也没有被反驳幻觉率计算公式幻觉率 幻觉样本数 / 总样本数如果想更严格还可以统计“部分支撑”类样本中无证据子命题的占比。Google 报告里的口径大概率比这个严格这里给出的是一个本地可执行的近似版。实际使用时测试集越大、人工复核比例越高数值越可靠。5.3 评测脚本参考用 Python 写一个幻觉率归因脚本。它读取一个包含“结论文本”的 JSONL每条调用验证器返回 label最后统计比例。import json from collections import Counter LABELS {supported, unsupported, partial, contradicted} def load_samples(path): with open(path, r, encodingutf-8) as f: return [json.loads(line) for line in f if line.strip()] def compute_metrics(samples): counter Counter() for s in samples: label s.get(verifier_label, unsupported) counter[label] 1 total len(samples) hallucination_ratio (counter[unsupported] counter[contradicted]) / total return { total: total, label_distribution: dict(counter), hallucination_ratio: round(hallucination_ratio, 4), } def main(): samples load_samples(samples.jsonl) metrics compute_metrics(samples) print(json.dumps(metrics, ensure_asciiFalse, indent2)) if __name__ __main__: main()运行前要把 samples.jsonl 里每条数据的 verifier_label 补全补全方式可以是人工标注也可以是另一个 LLM 判断后人工抽检。5.4 对比流程设计要证明“可靠性模块降低了幻觉率”不是跑一遍得出 4% 就行必须做双系统对照。推荐流程如下同一组问题分别用 Baseline 系统和带验证器的系统生成结果。对两组结果混洗打乱标注者或评分模型不知道哪条来自哪个系统。分别统计两组的幻觉率。两组差异做简单显著性检验后再下结论。这样可以避免一个常见陷阱用户在验证器开启后为了减少最终输出悄悄把答案改短了导致“幻觉率下降”只是因为表达更长更容易出错而不是可靠性模块起效。6. 把“验证器”接到自己的 Agent 管线里Co-Scientist 的可靠性模块逻辑完全可以抽出来接到其他科研、知识生产类 Agent 流程里。核心思路是增加一道验证过滤循环生成器给出候选答案 - 验证器检查每个关键命题 - 通过则交付不通过则打回重写或丢弃。6.1 验证器 Prompt 参考这里给出一个通用的验证 prompt 模板。它不绑定具体厂商可在调用 Gemini、GPT、Claude 或其他国产长文本模型时使用按自家模型能力调整即可。你是一个严谨的证据验证员。你的任务不是判断“观点是否有趣” 而是判断“给定结论能否被用户提供的证据支持”。 待验证结论 {conclusion} 可参考证据 {evidence_chunks} 请按以下规则回答 1. 如果证据直接支持结论的关键命题输出 supported。 2. 如果证据与结论矛盾输出 contradicted。 3. 如果证据存在但不足以证明结论输出 partial。 4. 如果证据无法定位到相关命题输出 unsupported。 只输出一个单词supported受支持这个 prompt 的重点是把“观点是否专业”从判断标准里拿掉强制模型只做命题与证据的映射。如果你发现验证器输出有系统性偏松或偏严可以在结尾追加一小段“判定阈值说明”加以校准。6.2 带过滤的科研 Agent 伪代码实际工程里验证器与主流程是异步调用关系。下面提供一个生成—验证—过滤的最小实现骨架供后续改造import asyncio from dataclasses import dataclass dataclass class Candidate: content: str verifier_label: str pending async def generate_candidates(problem: str) - list[str]: # 对接生成模型返回多个假设或结论草稿 ... async def verify_conclusion(candidate: Candidate, evidence: list[str]) - str: # 调用验证 prompt返回 supported/partial/unsupported/contradicted ... async def research_pipeline(problem: str, evidence: list[str]): raw_candidates await generate_candidates(problem) tasks [verify_conclusion(Candidate(c), evidence) for c in raw_candidates] labels await asyncio.gather(*tasks) verified [] for cand, label in zip(raw_candidates, labels): if label in {supported, partial}: verified.append(Candidate(cand, label)) return verified async def main(): problem ... evidence [......] outputs await research_pipeline(problem, evidence) for item in outputs: print(item.label, item.content)这段代码体现的核心工程要点生成候选和验证候选解耦验证过程允许多个候选并行通过“supported”和“partial”两种标签进入最终交付集合。6.3 重试与降级策略验证器的输出未必一步到位。推荐配置两层策略若结论被评判unsupported系统可以重新生成一次结论并自动补充更显式的证据来源描述再进行二次验证。若反复出现unsupported更稳妥的决定是丢弃该候选不让它进入最终交付因为这大概率是生成侧本身没有可依托的素材。重新生成行为最多建议重试一到两轮避免形成无意义循环让推理成本成倍上升。7. 资源开销与性能观察给 Agent 增加验证环节不是免费的。最直观的成本来自三处额外模型调用 token、证据检索的索引查询时间、多轮重试带来的并发压力。在 Google 的论文级场景里算力由云端 TPU 集群承担用户不太会关心显存但一旦把这种方案搬到自有服务里就要把这些成本计入。以下按本地或云端 API 两种形态给出可观测维度具体情况需要以本机测试为准。环节主要开销优化手段证据检索向量库查询耗时与语料库规模相关预切片、分层索引、限制每个结论检索的 chunk 数量验证判断token 消耗一次结论一次大模型调用同批候选并行调用、复用缓存结果重试循环失败轮次会产生额外生成和验证调用设置最大重试次数如 1 到 2 次数据准备语料入库前的清洗和 embed 向量化离线执行不与在线检索路径耦合另一个值得关注的是端到端时延。验证器开启后单条结论交付从“纯生成”变成“生成 检索 验证”一般会增加数倍耗时。批量场景下可以通过加大并发来摊薄时延但如果接口有并发限制就需要在队列中增加流控。如果观察发现验证后的结果中partial比例长期偏高建议优先排查证据语料是否覆盖不足其次再调验证 prompt。不要一上来就把阈值放宽松那样只会掩盖证据缺口。8. 常见问题与排查方法把幻觉率从 46% 压到 4%听起来很理想但本地复现时往往没这么顺利。问题现象可能原因排查方式解决方案加了验证器后幻觉率没有明显下降验证器判断口径过松大量 unsupported 被误判为 supported抽 30 条人工复核验证器原始输出收紧 prompt增加“证据直接支持”判定条件结论被大量误杀验证通过率过低生成模型习惯输出无出处长文或验证器把部分支撑当不支持查看被拒结论是否真的没有相关证据优化检索召回改判 partial 为允许交付指标波动较大两次评测结果不一致评测集样本太少或问题集中在小众方向看每轮结果的分布而非只看平均值扩充到 50 个以上问题分层覆盖验证器对同一结论在不同表达下判断不一致模型随机性或 prompt 表达缺乏稳定性同一结论换 3 种表达分别调用 3 次调整 temperature在 prompt 中增加格式约束引入验证后成本超预算每个候选都调用验证模型且存在高频重试在日志中统计每次验证消耗的 token 与调用次数验证结果做缓存、减少重试次数、增加批量并发遇到幻觉率没降下来的情况先不要怀疑验证器原理而是先检查评测集里“被判定为 supported 的样本真的都有证据吗”。实践中八成以上的幻觉率复现失败来自标注口径不统一而不是模型能力问题。9. 从论文到工程科研 Agent 的可靠性实践建议Google 这篇工作的价值不在“做了个 app”而在于它给出了一套可以复用的可靠性治理范式。按重要程度排序下面几条最有借鉴意义。第一必须把结论生成和结论验证拆成两个独立角色。如果同一个模型既当运动员又当裁判它的“自我一致性偏好”会掩盖幻觉。即使使用同一基座模型也要通过不同的上下文角色、检索策略和判断 prompt 把两条链路隔离。第二证据颗粒度要够细。验证时不是让模型看整篇论文 PDF而是把结论拆成“一个个可被证明或证伪的命题”再给它配对应的局部证据段落。命题拆分让验证器不需要处理大段混沌信息判断质量和稳定性都会提高。第三建立可回查记录。每条交付结论都要保留支持它的证据 ID 和验证结果。这样做有两个好处一是使用者可以直接点开原始文献确认二是当最终报告出错时可以追溯到是证据库缺失、检索失败还是验证判断失误而不是对着整条输出干瞪眼。第四设计灰度标准。不要追求所有输出都达到“100% 可验证”。科研领域大量结论本来就处于假说状态把 partial 类结果单独标记为“需实验验证”比直接拦掉更符合科研工作流习惯。Google 那 4%大概率也不是零风险而是残余风险被明确标记出来。第五人工抽检不能省。LLM 验证器和人工验证互为补充。建议每个验证批次中人工抽检 5% 到 10% 的supported样本确认验证器没有在证据不充分的情况下给出过宽判断。抽检结果既用于质量审计也可以周期性回流调整验证 prompt。第六版权与隐私合规同样适用于科研智能体。涉及患者数据、商业实验数据或未公开论文进行系统综述与假设发现时在把语料投入检索和验证前必须先确认数据使用边界和授权。不要因为验证器是系统内部模块就忽略了数据隐私合规。10. 这件事对做 Agent 的人意味着什么换个视角看这个“46% 到 4%”对普通技术选型有一个非常实用的反向启发如果你正在做一个面向专业领域的 Agent 系统第一优先级的开发任务不一定是把生成模型换到更大的参数版本而是尽快加一层能对输出结果进行证据审计的验证模块。它告诉你的信息是即使在 Agent 协作任务中决定质量上限的不再只是单模型智商而是系统的自我纠错控制回路。生成器负责拓宽可能性验证器负责守住可信度两套机制彼此制约时最终面向用户的输出才会更接近“可交差”状态。顺着这个方向往下走项目团队可以安排下一步工作扩充领域实验证据库打造更细粒度的论文命题级评测集在验证器判断逻辑中加入“反事实检验”——结论若为因果性判断使用反事实样本做对抗测试再把验证器的中间结果以结构化 JSON 输出接入报告生成链路使最终论文稿自带证据地图。对大多数开发团队而言短期内要完整复现 Google 的多智能体科研系统并不现实但把“生成后再验证、验证后留证据”这套思路用到自己的知识库问答、报告生成或数据处理流程里门槛并不高。一个 prompt 模板、一份标注规范、一段并行调用代码就能把可靠性意识做成 Agent 基础设施的一部分。