做科研智能体最怕什么最怕它一本正经地给出一个看起来很严谨、实际上回头一查文献根本不存在的结论。我之前在知芽项目里折腾过一阵Notebook Skill当时团队推这个方向的核心诉求很简单科研场景下的大模型输出不能只靠“生成完再说”得有人在出口处把每一段话的底细查清楚。后来我们把方案收敛成一套段落级校验机制把“整篇可信”拆成“每段可证”效果比预想中扎实不少。这篇文章就把这套机制的落地过程掰开揉碎讲一遍包括我们为什么放弃整体打分、段落级校验到底校验什么、工程上怎么实现生成-校验-修正闭环以及基于Notebook形态做Skill封装时踩过的坑。适合正在做科研助手、论文润色、文献综述Agent这类产品的朋友参考也适合对AI输出可信度控制感兴趣的读者。1. 科研智能体为什么绕不开“可信输出”做科研辅助类产品的朋友应该都有同感这类场景对错误零容忍但大模型天然会一本正经地胡说八道。我们刚做知芽的时候内部第一版是个纯RAG问答系统用户问一句系统从文献库里检索几段相关文本再让大模型组织成答案。demo阶段看着挺好一上真实用户就露馅。有用户反馈说“这个结论看着很合理但我找不到原文献支撑”还有更严重的模型把两篇论文的结论拼接在一起得出了一个原文完全没有的推论。1.1 科研场景里幻觉的代价比想象中大论文写作、基金申报、文献综述这些场景引用错误不是小事。一篇综述里引用错了半句话审稿人顺着标记去查原文查不到就是学术不端嫌疑。编造一个不存在的实验数值轻则返工重则影响整个研究方向的判断。我们调研过一批研究生和青年科研人员他们对AI写作工具最大的顾虑不是“写得好不好”而是“哪句话能信、哪句话不能信”。这跟普通办公场景完全不一样。写周报的时候生成错了还能改但是科研写作中用户不会逐字逐句去核对 AI 给的每个引用他们默认“大模型既然给了文献标号那内容应该是可靠的”。这个认知差导致问题被放大了工具越方便用户越容易放松警惕等错误沉淀到正式稿子里返工成本极高。1.2 单纯靠RAG解决不了“出口质检”问题第一代方案依赖RAG我们以为只要检索质量够高生成就不会出错。实际跑下来发现两个漏洞。一个是检索召回本身有噪声。Top-5的召回段落里经常出现部分相关的内容模型在组织回答时可能把段落甲的背景和段落乙的实验结果混在一起看起来逻辑通顺实际上张冠李戴。另一个是生成阶段的推理过度。RAG召回再准大模型在改写时还是会往“更完整”的方向发挥尤其是遇到文献里本来就有争议或没下结论的地方模型会自动补一个“合理的”解释这个补出来的内容恰恰是幻觉重灾区。所以我们内部后来达成了一个一致结论生成链路做得再花哨必须有一个独立于生成器的校验出口。答案不是生成完之后就结束了而是生成完之后还要经过一道质检闸门质检不通过就打回重写。这就是段落级校验机制的起点。2. 段落级校验为什么是“段落”而不是“全文”刚开始设计校验机制的时候团队里其实有个争论是不是应该对整篇生成结果做一个统一的可信度评估类似给论文打个总分我们试着做了个初版效果非常尴尬。2.1 整体打分最大的问题是“定位不到病灶”整篇打分只能输出一个分数比如“整体可信度82%”。用户看了这个分数依然不知道哪段话需要仔细读、哪段话可以直接放心用。更麻烦的是一篇长文里可能有20个段落每个段落的真实性参差不齐——某三段引用扎实某两段纯粹是模型自由发挥。整体分数会被平均值稀释本该被标记的高风险段落反而被“平均”掉了。我们后来把“校验”和“定位”拆开看发现用户真正需要的其实是两件事一是有问题的段落被精确标记出来二是标记的时候给出依据哪篇文献、哪个段落支持或反驳了这句话。这两个需求都指向同一个粒度——段落。2.2 段落是科研写作里天然的论证单元科研论文本身就以段落为基本论证单元。一个段落通常表达一个完整观点内部包含“论点论据来源”这对校验非常有利。拆到段落级之后每个校验单元都有明确的上下文边界既不会因为太短丢失语义也不会因为太长让证据判断变得模糊。对比来看如果拆到句子级很多句子单独抽取出来后会缺少主语或限定条件校验器容易误判如果整篇做又回到定位困难的老路。段落粒度经过我们实际测试是误判率和定位精度平衡最好的方案。2.3 段落级校验让“人机协作”成为可能还有一个容易忽略的好处段落是用户可以介入修改的最小舒适单元。用户看到某个段落被标红之后可以直接在这一段动手修改或删掉不需要在全文上下文里来回折腾。基于Notebook的文档形态更是把这种体验放大了后面我会单独讲。所以最终我们确定的设计原则是校验以段落为单位执行但校验结果可以下钻到句子级——段落只作为状态容器真正做事实判断时按句子拆分再聚合回段落级结论。这样既拿到了段落的边界语义又不丢失判断粒度。3. 校验机制的核心设计到底校验哪些东西定下段落级的方向后接下来要回答一个更麻烦的问题段落级校验到底校验什么是检查“这句话在文献里有没有依据”还是检查“这句话和上下文是否矛盾”我们一开始以为只有一个维度真正做下来发现至少有四层。3.1 校验维度拆解事实、来源、逻辑、术语第一层是事实一致性。段落里每一个关键断言claim都需要在知识库/文献库中找到支持性证据。这是整个校验机制的基础也是我们花精力最多的地方。第二层是来源可溯性。每个段落末尾的引用标记必须真实对应到文献库中存在的条目且内容确实与引用来源相关。这个看起来简单实际做起来bug很多——模型经常给出一个格式正确的引用标号但对应文献的内容跟这段文字毫无关系。第三层是逻辑一致性。放在科研写作里就是段内的因果关系、转折关系、递进关系有没有被曲解。比如原文说的是“A方法在小样本上表现更好”模型可能改写成“A方法整体优于B方法”这就是典型的逻辑放大。第四层是术语准确性。科研场景里很多术语差一个字意思就完全不同比如“相关性”和“因果性”、“显著性”和“有效性”这类错误普通模型很难自查。3.2 判定输出的三级状态通过、存疑、失败我们给每个段落设了三级状态不搞四五六七八种标签因为标签越多用户理解和系统调优都越难。通过绿色段落所有关键断言都找到支持证据引用与来源匹配逻辑未发现曲解。存疑黄色存在没有找到明确支持或反驳证据的断言通常是因为知识库覆盖不足不能直接下错误结论。失败红色至少一个关键断言被证据明确反驳或引用标记与内容明显不匹配。为什么要把“存疑”单独拉出来因为科研语料库永远不可能完整覆盖所有领域知识尤其是新发表的论文。如果要求每个断言都必须检索到支持证据那模型生成稍微前沿一点的内容就会被误杀。把“查不到”和“被反驳”当成两回事是非常关键的设计决策。3.3 从“段落判定”到“可信度评分卡”段落级别只是粗糙的大筛选真正要跑科研流程的话用户还需要一个汇总性的、能反映整篇质量的指标。我们在段落校验基础上做了聚合评价输出类似“本段关键断言支持率86%存在2个未验证断言1个被反驳断言”的评分卡。这个评分卡会出现在Notebook的输出面板里用户扫一眼就知道整体风险分布在哪。我们内部管这个叫“可信输出评分卡”虽然名字有点重但确实解决了“每一段都通过但整篇依然不可用”的问题——因为聚合结果会暴露段落之间的冲突或重复。4. 工程落地校验流程的完整闭环设计思路讲完了接下来是更实际的工程落地。段落级校验听起来不复杂真正搭起来链路非常长。我们最后的流程分为五个环节段落切分、断言抽取、候选证据检索、证据判断、结果聚合与反馈。4.1 段落切分规则优先模型兜底第一步把生成内容切成段落。对于Notebook这种带块结构的文档来说切分比纯文本场景容易得多——每个Notebook Cell天然是一个边界。但Cell里面可能还有多个自然段落需要二次切分。我们用的方案是先按Markdown标题、空白行、列表标记做规则切分规则切不动的大块文本再丢给大模型做语义分段。规则优先的原因是稳定可控模型分段虽然效果好但随机性大同一段文本跑两次可能分段结果就不一样这对校验系统来说是致命的。4.2 断言抽取从段落里提炼“可被验证的硬句子”段落切好之后接下来要把段落转成一组可验证的断言。所谓断言就是一段话里包含事实性判断的最小单元比如“xx方法在xx数据集上取得了xx精度”。这部分我们用了一个单独的抽取模型prompt里明确要求只抽取有客观答案的断言过滤掉主观评价、过渡语句和修辞。这一步特别容易踩坑。如果抽得太细比如把“该研究具有重要意义”这种虚词也抽成断言检索器会找一堆不相关的证据白白增加噪音如果抽得太粗比如把整个段落当成一个断言检索和判断又失去意义。我们调了很多版prompt最后总结出一条经验断言必须包含可检索的名词性实体和可比较的谓词两者缺一不可。4.3 候选证据检索混合检索加一层重排断言抽完之后每个断言要进文献库检索候选证据。我们一开始只用了向量检索结果召回的结果太“语义化”——能召回语义相似但没有直接事实关系的文本导致判断器经常被带偏。后来改成BM25关键词检索和向量检索并行召回各取Top50合并再用一个轻量rerank模型把Top5挑出来。这一步对比单纯向量检索证据相关性提升非常明显。关键点是检索召回的目的是“查全”重排的目的是“精挑”两个阶段目标不同最好不要用同一个模型一把梭。4.4 证据判断三段式分类比打分好用得多候选证据到位之后核心判断环节我们在两种方案之间纠结了很久一是让大模型输出一个0到1的相关性分数二是让大模型做三分类支持/矛盾/无关。最后选了分类。原因是打分模式的分数解释性太差0.6和0.7之间到底差了什么用户看不出来我们也不知道怎么调。分类则清晰得多而且还能在判定结果后附加一句理由比如“该断言与证据矛盾因为证据中样本量仅为50断言声称有500”。判断环节我们用了稍大一点的模型因为判断质量直接决定整个系统的可信度。prompt里附带了检索出来的证据原文要求模型先引用证据原文再下结论这样后续用户可以点击查看判断依据。4.5 结果聚合与反馈修正所有断言判断完之后聚合回段落级状态。聚合时要小心处理多断言冲突的情况如果一个段落里有五个断言四个通过一个矛盾段落状态应该是红色——不能因为多数派通过就掩盖少数派错误科研场景里一个人的错误可能毁掉整段可信度。红色和黄色的段落会触发反馈修正。我们把校验结果连同错误信息一起返回给生成模型让它根据反馈重写该段落。重写不是重新生成而是在原段落基础上只修改被标记的部分不然容易把没问题的地方也改坏。重写后再次进入校验形成一个“生成-校验-修正-再校验”的闭环最多循环三轮超过三轮直接放弃并转人工标注避免死循环消耗算力。4.6 校验流程伪码参考def validate_paragraph(paragraph: str, knowledge_base) - ParagraphVerdict: claims extract_claims(paragraph) # 断言抽取 evidences [] for claim in claims: cands hybrid_search(claim, knowledge_base) # BM25 向量检索 top rerank(cands, claim, top_k5) # 精排 verdict judge(claim, top) # 支持/矛盾/无关 evidences.append((claim, verdict, top)) para_level aggregate(evidences) # 聚合段落状态 if para_level in (RED, YELLOW): revised rewrite_with_feedback(paragraph, evidences) return validate_paragraph(revised, knowledge_base) # 递归修正 return ParagraphVerdict(statuspara_level, evidenceevidences)这里要提醒一下递归重写必须设置深度限制否则遇到模型反复改不好某段时会无限循环。我们踩过一次这个坑某段涉及一篇刚上线、检索库还没收录的论文模型每次重写都被判“证据不足”整整跑了7轮才被熔断。后来我们把上限设为3轮并且给“存疑”状态单独设了一条规则重写3轮后如果问题只是“无证据”而非“被反驳”直接保留黄色状态并放行不再继续烧钱。5. Notebook Skill用笔记形态承载校验逻辑方案在命令行和Web界面上跑通之后我们做了个关键决策把整套校验机制封装成知芽里的Notebook Skill。为什么选Notebook不单独做一个校验界面这是被用户需求推着走的。5.1 科研用户的工作流不是“问完就走”我们观察真实科研用户使用AI的方式发现他们很少像ChatGPT那样问一个问题拿一个答案就走更多是长时间地在文档里来回修改、补充、推敲。一个综述可能要写好几天期间反复增删段落。这个工作流对“会话式聊天”很不友好反而和Notebook的“文档代码块结果输出”形态天然契合。把校验做成Notebook Skill之后每个段落可以被当成一个独立块来处理段落状态直接以颜色标签展示在块旁边。绿色、黄色、红色一眼可辨用户不需要打开某个隐藏面板才能看到校验结果。5.2 校验状态的可视化和可操作化Notebook携带了结构化信息我们因此可以在段落块上叠加更多有用的元数据。比如鼠标悬停在绿色状态上可以看到支持该段落的文献列表悬停在红色状态上可以直接看到被反驳的断言与证据原文的对比。更重要的是用户可以直接在黄色或红色块上点击“重写”按钮触发我们前面说的修正闭环而无需把文本复制到另一个工具里操作。这大大降低了用户与校验系统交互的摩擦成本。实测下来工具的Daily Active Users访问粘性相当高因为用户一旦开始在自己的Notebook里布局段落就离不开状态标签了。5.3 Skill封装的三个原则把校验机制封装成Skill的时候我们给自己定了几条原则第一条Skill对外暴露的必须是“结果”而不是“过程”。用户不需要知道检索召回了多少篇文档、重排分数是多少只需要看到每段的状态和依据。过程细节全部隐藏到配置文件里。第二条Skill必须可以按领域配置。不同学科文献库差异极大生物医学和CS论文的引用习惯完全不同。我们允许用户在Skill配置里指定文献库集合、术语表、校验严格程度等参数避免一套参数打天下。第三条Skill要支持批量模式与交互模式互换。有些用户希望生成完整个文档后一次性校验全部段落有些则希望边写边校验。两种模式我们都做成了开关均使用同一套校验内核只是触发时机不同。6. 实际操作中常踩的坑与排查技巧最后这部分最有实践意义。段落级校验机制原理不复杂但工程落地时到处是小坑。我把我们团队在知芽项目里排队踩过的几个典型问题整理成表格并附上排查思路。问题现象根因分析排查/解决办法校验误杀率过高大量本无问题的段落被标红检索召回不完整导致判断器“因缺证而误判”排查召回环节确认是BM25漏召回还是向量检索召回错位补充关键词同义词扩展断言抽取结果太碎片化一个长段落抽出20断言抽取Prompt约束不足把大量非事实语句也抽了进来加强排除项明确过滤“观点、建议、过渡、修辞”类语句段落被反复重写后质量不升反降重写模型在修正错误时把周边正确内容也改了重写时使用“最小修改”指令并限定修改范围只允许动被标记的部分某段落显示“无证据”但用户确认该结论来自一篇新论文文献库更新不及时知识库覆盖不足提示“存在未验证断言”并区分“知识库未收录”与“知识库中有矛盾证据”两种状态校验耗时过长整篇20段跑下来需要几分钟每段都串行执行检索和判断链路等待时间长段落间无依赖改成并行校验检索候选集结果做进程内缓存排障过程中我们还有一个很深刻的体会别把校验器当成一个“评判官”来训把它当成一个“举证律师”来用。评判官关注对错举证律师负责“支持就说支持、反对就说反对、证据不足就说不足”。这套价值观直接体现在提示词设计里——我们明确要求判断器不许在证据不明确时强行推理只允许返回“无关/不足”的结果。另外一个容易被忽视的坑是领域术语的识别。我们在测试医学文献时模型把“Mortality rate”死亡率和“Morbidity rate”发病率当成了同义词导致大量事实判断失真。后来我们在Pipeline里加了一个术语保护层从领域论文库里自动抽取术语词典在检索和判断前把术语向量预计算好凡是术语级别的匹配必须精确不能靠语义相似度。加了这层之后医学场景的误判率降了大约三分之一。关于测试集建设我们的做法是从实际用户反馈中积累“校验错误case”每隔两周做一次回归测试。凡是被用户跳过的标红段落、被用户手动改回绿色状态的段落都进入分析队列找出系统判断错误的根因后修Prompt或修检索策略。这套机制跑下来后续迭代速度比一开始猛加模型参数要有效得多。再说一个关于性能和成本的优化。校验链路中最贵的是每一步都调用大模型尤其是断言抽取和证据分类。我们的优化方案是第一做两个轻量模型当“守门员”先用小模型判断这个段落是否包含需要校验的断言明显不含的段落直接放行第二真正的证据判断也只对Top3证据做不逐个判断Top5减少请求量第三对所有段落级校验结果做缓存在Notebook里同一段内容没有修改的情况下直接从缓存返回结果不再重复跑链路。这三板斧下来整篇文档的校验成本压到了纯链路方案的15%左右。7. 一点经验总结知芽Notebook Skill的段落级校验机制上线后我们内部复盘过好几次发现可信输出这件事本质上不是让模型不犯错而是让错误无处藏身。大模型幻觉无法根治但可以通过段落级校验把错误限制在可定位、可追溯、可修正的范围内这已经足够让科研用户放心使用了。我个人实际蹭出来的一个体会是做可信输出类功能一定要把校验和生成放在同等重要的位置上设计而不是等生成器做完了再补一道质检。我们早期走弯路就是因为把校验当成了后期加的一个工具导致生成器的输出方式和校验器的输入要求总是对不上——比如生成器喜欢用一大堆模糊措辞而校验器需要明确的断言才能判断。后来我们直接把校验结果作为训练和推理阶段的一部分反馈信号让生成器从一开始就知道“会被查底细”输出才慢慢变得收敛、克制、可验证。最后再分享一个小技巧如果你也在做类似的段落级校验不要一上来就追求100%准确率先把误判率压到用户可接受的范围内更重要。阈值宁可调松一点也要保证标红的内容“十标九准”。用户能容忍漏报但非常反感误报——误报一次他们对整个系统的不信任感会飙升。我们早期为了追求查全率把阈值压得很严结果被用户吐槽“满屏红的没法看”后来放宽阈值并增加“存疑”状态用户反馈反而好了很多。