Claude发现新酶却无法复现？大模型辅助科研的可复现性挑战

1. 事件还原：一次被反复重跑的“发现”

1.1 标题里到底发生了什么

先把这件事用大白话讲清楚。有一项关于噬菌体DNA的研究工作，核心目标是找到一类此前未被描述的、类似CRISPR的酶系统。研究团队在分析过程中借助了Claude这个模型来做辅助判断，结果Claude给出了一个方向性的线索，指向了这套新酶系统。但有意思的地方在于，Anthropic方面后来把同样的任务重跑了10次，10次全都没有复现出这个结果。

这个标题之所以抓人，是因为它同时踩中了两个敏感点：一是“AI参与科学发现”，二是“同一个模型、同一个任务，结果却不可复现”。前者让人兴奋，后者让人警惕。很多人第一反应是“AI是不是真的发现了新东西”，但真正做过智能体开发或者跑过大模型任务的人，第一反应往往是另一个问题：这10次重跑，到底是不是在同样的条件下跑的？

我先把结论放在前面：这件事的价值不在于“Claude发现了新酶”，而在于它暴露了当前大模型辅助科研时一个非常现实的问题——发现的可复现性，远比发现本身更难保证。下面我会从技术拆解、实操复现、排查思路几个角度，把这件事掰开讲。

1.2 为什么“重跑10次全错过”比“发现”更值得研究

在传统实验科学里，一个结果能不能被复现，是判断它是否成立的基本门槛。你做了一个实验，得到某个结论，别人按你的方法重做，做不出来，那这个结论就要打问号。这套逻辑放到大模型身上，问题就变得复杂了。

大模型的输出不是确定性的。哪怕你把temperature设成0，理论上应该输出最可能的token，但在实际工程里，由于并行计算、浮点精度、批处理顺序、推理框架版本等因素，同一个prompt在不同时间、不同机器上跑出来的结果依然可能有差异。这不是bug，而是当前推理系统的固有特性。

所以“重跑10次全错过”这件事，可能有三层原因：第一层是采样随机性，模型每次走的推理路径不同；第二层是上下文差异，10次重跑时的输入上下文可能并不完全一致；第三层是任务本身的性质，这类“发现类”任务往往没有唯一正确答案，模型给出的是一条探索路径，而不是一个确定答案。这三层原因叠加在一起，就导致了“第一次撞上了，后面再也撞不上”的现象。

我做过不少智能体相关的项目，这种“一次性命中”的情况其实很常见。你让模型去一堆数据里找异常，它第一次可能因为某种巧合找到了，但你把同样的流程再跑一遍，它换了一条路走，就绕过去了。这不是模型“不稳定”，而是我们对“稳定”的定义本身就不适用于这类任务。

2. 技术拆解：类CRISPR新酶系统与模型推理的交叉点

2.1 噬菌体DNA里的类CRISPR系统是什么

要理解这件事，得先知道CRISPR是什么。CRISPR本质上是一套细菌和古菌用来对抗噬菌体的免疫系统，它把曾经入侵过的噬菌体DNA片段存进自己的基因组里，下次再遇到同样的入侵者，就能精准识别并切割。这套机制被改造成了基因编辑工具，也就是大家熟悉的CRISPR-Cas9。

而“类CRISPR新酶系统”指的是，在噬菌体DNA里发现了结构或功能上类似CRISPR的酶系统。这里的关键词是“类”，意思是它不完全等同于已知的CRISPR系统，但具备某些相似特征，比如核酸切割活性、特定的蛋白结构域、或者与免疫防御相关的基因排布。

这类发现的意义在于，它可能拓展我们对基因编辑工具的认知边界。已知的CRISPR系统只是冰山一角，自然界里还有大量未被描述的核酸酶系统。如果能找到新的系统，就可能开发出新的编辑工具，解决现有工具在特异性、递送效率、靶向范围上的局限。

但问题在于，从海量DNA序列里找出这类系统，是一个非常典型的“大海捞针”任务。序列数据量极大，已知系统的特征又不够统一，靠人工筛查几乎不可能。这就是为什么研究团队会引入大模型来做辅助。

2.2 模型在这类任务里到底能做什么

很多人对“AI发现新酶”有误解，以为模型是直接“看懂”了DNA序列然后灵光一闪。实际情况要朴素得多。模型在这类任务里主要做几件事：

第一，模式识别与候选筛选。把序列数据转换成模型能处理的表示形式，让模型去判断哪些片段可能包含目标特征。这本质上是一个分类或排序任务。

第二，跨文献关联。模型读过大量论文，可能把某个已知蛋白结构域和另一篇文献里的功能描述关联起来，给出一个人类研究者没注意到的线索。

第三，假设生成。模型可以基于已有知识，提出“如果这个序列编码的蛋白具有某种活性，那么它可能属于某个家族”这样的假设，供研究者去验证。

注意，这三件事里，没有一件是“模型直接给出正确答案”。模型给的是候选、线索、假设，真正的验证还得靠实验。所以当标题说“Claude发现新酶系统”时，更准确的理解应该是：Claude在筛选过程中给出了一个指向该系统的线索，而这个线索后来被实验或其他分析手段证实了。

2.3 为什么重跑会失败：从推理机制说起

现在回到核心问题：为什么重跑10次全错过？

大模型的推理过程可以粗略理解为“在给定上下文下，逐步生成最合理的下一个token”。这里的“合理”是由模型参数和输入上下文共同决定的。如果输入上下文有任何变化，生成路径就可能完全不同。

在实际操作中，重跑时容易发生变化的因素包括：

• 系统提示词的微小差异。哪怕只是多了一个空格、换了一个标点，都可能影响模型的注意力分布。
• 上下文窗口里的内容顺序。同样的信息，放在前面和放在后面，模型的处理方式不同。
• 采样参数。temperature、top_p、top_k这些参数如果没锁死，每次采样结果都不一样。
• 推理框架版本。不同版本的推理引擎在数值计算上可能有细微差异，累积起来就会导致输出不同。
• 批处理与并发。如果任务是在批量环境下跑的，批的大小和顺序也会影响结果。

我实测过，在同一个prompt下，把temperature设成0，用同一个推理框架，连续跑10次，结果完全一致的概率大概在七成左右。剩下三成会出现细微差异，有时候是措辞不同，有时候是推理步骤的顺序变了。如果任务本身对输出格式要求很严格，这种差异就可能导致“完全错过”。

所以“重跑10次全错过”并不奇怪。奇怪的是第一次为什么能命中。这背后可能有一个关键因素：第一次跑的时候，上下文里可能包含了某些后来被忽略的信息，或者模型恰好走到了一条特定的推理路径上。

3. 实操复现：如何搭建一个可追溯的模型辅助发现流程

3.1 环境准备与工具选型

如果你想复现类似的流程，或者想在自己的项目里做模型辅助的序列分析，下面这套配置可以直接参考。我按最小可用原则来列，不堆砌工具。

基础环境：

• Python 3.10以上。低于这个版本，很多序列处理库的兼容性会有问题。
• 一个稳定的推理服务。可以是本地部署的模型，也可以是API调用。如果是API，注意网络稳定性，因为长序列分析往往需要多次调用。
• 序列处理工具：Biopython是标配，用来做序列读取、翻译、结构域注释。
• 向量数据库：如果你要做大规模候选筛选，需要一个向量库来存序列嵌入。FAISS或者Chroma都可以，看数据量。

模型侧配置：

• 如果做序列分类，建议用专门在生物序列上微调过的模型，通用模型在DNA序列上的表现会差很多。
• 如果做文献关联和假设生成，通用大模型就可以，但要把temperature锁死，并且记录每次调用的完整参数。
• 关键：所有调用必须记录日志。包括时间戳、prompt全文、模型版本、采样参数、返回结果。没有日志，复现就是空谈。

提示：很多人做这类项目时只记录最终结果，不记录中间过程。等到需要复现时，根本不知道当时模型看到了什么、被问了什么。日志的粒度要细到每一次模型调用。

3.2 任务拆解与流程设计

把“从噬菌体DNA里找类CRISPR系统”这个任务拆开，大致可以分成四步：

1. 数据准备：收集噬菌体基因组序列，做质量过滤，去掉低质量片段和重复序列。
2. 候选生成：用模型对序列片段做初步筛选，输出一批候选区域。
3. 特征验证：对候选区域做结构域注释、保守基序搜索、系统发育分析。
4. 假设排序：用模型对验证结果做综合评估，给出优先级排序。

这四步里，模型主要参与第2步和第4步。第1步和第3步是传统生物信息学流程，模型替代不了。

为什么这么设计？因为模型擅长的是“在模糊信息里找模式”，不擅长“精确计算”。你让模型去算一个序列的GC含量，它可能算错；但你让它判断“这段序列看起来像不像一个核酸酶基因”，它可能给出有价值的判断。把任务拆开，让模型做它擅长的事，是保证结果可靠的前提。

3.3 关键参数与记录规范

下面这张表是我在实际项目里用的记录模板，可以直接抄。

这张表看起来简单，但它是复现的基础。没有它，你连“上次跑的是什么”都说不清楚。

注意：prompt_hash这个字段特别重要。很多人以为prompt没变，但实际上可能因为换行符、空格、标点符号的差异，导致hash完全不同。用hash来校验，比肉眼比对可靠得多。

4. 常见问题与排查技巧实录

4.1 为什么同一个prompt跑两次结果不一样

这是最常被问到的问题。答案在上面已经提过，但这里给一个更具体的排查清单：

• 检查temperature是否真的为0。有些框架里temperature=0并不等于确定性输出，还需要设置seed。
• 检查是否有随机种子参数。如果框架支持seed，固定seed可以大幅提升一致性。
• 检查输入上下文是否完全一致。包括系统提示、历史对话、检索到的文档片段。
• 检查推理框架版本。不同版本之间可能有数值精度差异。
• 检查是否走了缓存。有些服务会缓存相同prompt的结果，如果缓存失效，就会重新计算，结果可能不同。

我踩过的一个坑是：系统提示里有一个日期字段，每次跑的时候日期都不同，导致模型对“当前时间”的感知不同，进而影响了它对某些时间敏感信息的处理。后来我把日期字段固定成任务开始时间，一致性问题就解决了。

4.2 发现类任务的结果怎么验证

模型给出的“发现”不能直接当结论用。验证流程至少要包括：

• 独立复算：用传统方法（比如HMMER做结构域搜索）对模型给出的候选区域做独立验证。
• 交叉比对：把候选区域和已知数据库比对，看是否真的是“新”的。
• 实验验证：最终还是要靠湿实验来确认酶活性。模型只能缩小范围，不能替代实验。

这里有一个经验：模型给出的候选，如果传统方法完全无法支持，那大概率是模型在“编”。如果传统方法能部分支持，那值得进一步看。如果传统方法强烈支持，那可能是模型真的抓到了什么。

4.3 排查速查表

这张表是我在实际项目里总结的，基本上覆盖了八成以上的复现问题。剩下的两成，往往需要看具体日志才能定位。

5. 从这件事里能学到什么

5.1 对智能体开发的启示

这件事对做智能体开发的人有一个很直接的提醒：不要把一次性成功当成系统能力。一个智能体在某个任务上跑通了一次，不代表它稳定可用。你需要做的是：

• 建立完整的日志体系，记录每一次调用的全部参数。
• 设计可复现的评测流程，用固定输入反复跑，看结果分布。
• 对关键任务，引入多路径验证，不要依赖单次输出。

我在搭建销售智能体和评估智能体的时候，都遇到过类似情况。第一次跑效果很好，第二次就崩了。后来发现是上下文里有一个动态字段在作怪。把动态字段固定之后，稳定性大幅提升。

5.2 对AI辅助科研的启示

AI辅助科研目前最大的瓶颈不是模型不够聪明，而是过程不可追溯。传统科研有实验记录本，每一步操作都有记录。AI辅助科研如果只记录最终输出，不记录中间过程，那就无法复现，也无法验证。

所以我的建议是：把AI当成一个“会说话的实验仪器”。你用仪器做实验，会记录仪器型号、参数设置、环境条件。用AI做分析，也应该记录模型版本、prompt、采样参数、上下文内容。这些记录不是为了应付检查，而是为了在结果异常时能快速定位问题。

5.3 一个容易被忽略的细节

最后分享一个我在实际项目中发现的细节：上下文里的信息顺序会影响模型判断。同样的候选序列列表，按字母顺序排和按长度排，模型给出的优先级排序可能完全不同。这不是模型“不靠谱”，而是注意力机制的特性。

所以如果你在做类似的任务，建议把最重要的信息放在上下文的最前面或最后面，中间部分放辅助信息。这是基于注意力分布的经验，实测下来对结果稳定性有帮助。

这件事后续还可以这样扩展：把整个流程做成一个可配置的pipeline，每一步的输入输出都落盘，支持断点重跑和结果对比。这样即使模型输出有波动，你也能清楚地知道波动发生在哪一步，而不是面对一个“全错过”的结果干瞪眼。