Snakemaker：通过生成式人工智能将临时分析无缝转化为可持续的Snakemake工作流

Marco Masera ${}^1$, Alessandro Leone ${}^1$, Johannes Köster ${}^2$ 和 Ivan Molineris*,1
${}^1$ 比奥系统生物学与生命科学系，都灵大学，意大利都灵，Via Accademia Albertina 13, 10126.
${}^2$ 可重复生物信息学算法研究组，基因组信息学研究所，人类遗传学研究所，埃森大学医院，杜伊斯堡-埃森大学，德国埃森。

*通讯作者

关键词：可持续数据分析，生成式人工智能，Snakemake，可重复性。

摘要

可重复性和可持续性在生物信息学软件开发中面临重大挑战，快速变化的工具和复杂的流程常常导致生命周期短或难以适应的管道。本文介绍了Snakemaker，一种利用生成式人工智能帮助研究人员构建可持续数据分析管道的工具，它通过将无结构代码转换为定义明确的Snakemake工作流来实现这一目标。Snakemaker非侵入性地跟踪研究人员在终端中的操作，分析执行模式，并生成可以集成到现有管道中的Snakemake工作流。Snakemaker还支持将单一的Ipython笔记本转换为模块化的Snakemake管道，将笔记本的全局状态解析为基于文件的规则间交互。一个集成的聊天助手通过自然语言指令为用户提供精细控制。Snakemaker通过遵循最佳实践（包括Conda环境跟踪、通用规则生成和循环展开）生成高质量的Snakemake工作流。通过降低从原型到生产质量代码之间的障碍，Snakemaker填补了计算可重复性在生物信息学研究中的关键空白。

1 引言

可重复性是科学研究的核心，确保研究成果能够独立验证并进一步发展。在生物信息学中，计算工具和工作流是数据分析不可或缺的一部分，因此可重复性尤为重要。它支撑了科学主张的可靠性，促进了同行评审，并加强了未来发现的基础。然而，由于对短期或快速变化的工具的依赖以及发布的管道的复杂性和低质量，可重复性仍然是一个问题 [1]。这种缺乏可重复性的情况给整个领域带来了负担，因为它限制了在新场景中重用以前的管道的可能性 [2]。
F. Mölder等人强调，除了可重复性之外，透明性和适应性对于已发布软件的持久影响至关重要 [3]。这些特性定义了可持续的数据分析，涉及代码属性，超越了简单的执行能力，与整体代码质量和发布代码的深思熟虑相关。同样，L.P. Coelho描述了科学软件的三个层次 [4]：level-0用于简单的一次性分析脚本；level-1用于随研究论文发布的开源代码；level-2用于可重用、可适应的工具。这与K. Ferenc等人的观点一致，即生物信息学通常忽视了健全的软件实践，受结果优先文化驱动，代码被视为发表的手段而非长期资产 [5]。因此，研究人员通常为实验生成level-0脚本，并认为将其改进为level-1或level-2工具是一项繁琐且不必要的努力。随着时间推移，这些临时工具在团队内重复使用时，技术债务累积，使得未来的改进更加困难。

如果某种“酶”能够分解从level-0跃升至level-1或level-2软件所需的“激活能”，会怎样？本文提出Snakemaker，一种利用生成式人工智能提供半自动转换无结构或特定用例代码为定义明确的Snakemake工作流的工具。

Snakemaker以非侵入方式运行，允许研究人员按常规方式进行原型设计，同时支持向可持续管道的过渡。生成式人工智能分析代码并将其转换为Snakemake工作流，同时检测模式、泛化规则、跟踪和导出Conda环境并生成文档。图形界面和聊天接口使用户能够控制和查看转换过程。

Snakemaker支持两种工作模式：Shell和IPython笔记本。
像Bash这样的Shell语言是生物信息学的核心工具，因为它们提供了对广泛生物信息学工具的访问，并擅长将它们链接起来处理大型基于文本的数据集（例如FASTA、FASTQ、VCF）。通常，shell-based管道是通过在终端中运行命令并最终将它们复制到.sh文件中以实现可重复性而构建的。Snakemaker记录用户的终端活动并将其转换为Snakemake工作流。

IPython Notebook支持功能实现了笔记本到结构化管道的半自动转换。尽管由于其灵活性和方便的代码与可视化集成，笔记本在原型设计中很受欢迎，但它们往往会演变成笨重的单体代码库，难以追踪执行状态。这可能导致对结果的不确定性以及频繁且耗时的完整重新执行。作为经典的level-0软件，笔记本非常适合快速迭代，但在重用、协作或长期维护方面表现不佳。将它们转换为Snakemake工作流可以提高模块化，澄清依赖关系，并确保数据和代码更改的自动跟踪——从而提升可重复性和可持续性。

2 数据和方法

Snakemaker被开发为VSCode扩展，集成到工作区的图形界面中。VSCode API使用户能够对集成终端和工作目录进行精细控制；此外，语言API允许提示GitHub Copilot模型；虽然Snakemaker支持任何兼容OpenAI的LLM API，但对于大多数情况，集成的LLM支持是最简单且即用的解决方案。

本节描述了Bash（2.1）和Notebook（2.2）功能的实现，以及使用LLM生成工作流所面临的挑战和解决方案。

2.1 Shell跟踪和转换

本节介绍了Shell跟踪和转换功能的实现。VSCode API使终端活动得以跟踪：用户命令、返回码和活动的Conda环境。记录的活动由LLM处理，以建议规则名称、识别潜在的输入和输出文件，并确定每个命令是否与工作流相关或是一次性操作。这种相关性标志对于过滤掉无关操作（如目录导航或Git命令）至关重要。命令也可以手动插入历史记录，但不带元数据。转换管道包含多个步骤：

1. 上下文整合。当前工作环境中现有的Snakemake工作流被提供给模型作为上下文。LLM尝试模仿现有的形式主义，以保证代码库的一些风格一致性，并过滤掉冗余规则。
2. 规则起草。历史记录中的命令及其元数据被馈送到LLM以生成Snakemake规则的第一版。模型查找命令和现有规则中的模式，以验证将不同命令合并为单个通用规则的可能性，使用expand指令展开bash循环为规则，避免重复规则。
3. 配置。第二次LLM分析查找可以移动到配置文件中的硬编码参数或路径。现有配置文件被用作示例和参数池，这些参数可以在规则中使用。实验结果表明，将此步骤与前一步分开可以显著提高生成规则和配置的质量。
4. 后处理。后处理步骤使用正则表达式和有限状态自动机修复一些常见的格式错误，然后将新规则与现有工作流合并。
5. 验证。最后一步执行迭代验证和修正。工作流通过Snakemake二进制文件传递以发现问题，然后反馈给LLM进行修正。实验表明，一两次迭代足以修正大多数情况下的所有错误。对于复杂的边缘案例错误，采用回退提示技术[6]。在此过程中，模型被用来编写问题分析和修正计划。该计划随后反馈给LLM并应用。
   

图1：Bash命令转换管道。当前工作流包含在模型的上下文中（a），然后生成新规则（b）。第二次LLM传递提取配置（c），后处理步骤进行一些修复并将规则与之前的流程合并（d）。新的工作流被传递给Snakemake（e.1）；如果出现错误（e.1b），则反馈给LLM直接修正（e.2b）或遵循两步管道（e.2a）。结果规则从后处理返回到管道。

Snakemaker还可以为当前的工作流和记录的bash历史生成文档。虽然模型无法确切知道用户的意图，但它可以通过注释、规则和文件命名以及对工具的内在知识来推断更广泛的范围并生成工作流描述。

2.2 笔记本转换

本节介绍了Ipython Notebook转换功能的实现。该功能旨在将笔记本半自动拆分为模块化的Snakemake工作流，需要将全局Ipython状态复杂地展开为一组基于文件的规则之间的离散依赖关系。这些基于文件的依赖关系通过为单元格添加生成的额外代码来实现。

全局状态被展开为有向无环图（DAG），其中节点对应于单元格，边对应于数据依赖关系。该过程需要确定每个单元格写入和读取的变量集合。从这两个集合以及假设单元格按顺序运行出发，可以通过为每个读取集合中的变量绘制一条边，从读取单元格到最接近的相同变量写入单元格（位于读取单元格上方的单元格之间）来构建DAG。通过静态分析计算读取和写入集合是一个不可判定的问题[7]，但可以通过始终考虑最悲观的情况来放松：如果一个变量可能在写入之前被读取，则它是依赖项。

函数声明需要特殊处理，因为它们的定义和调用可能出现在不同的单元格中。为了避免歧义，函数被隔离在专用单元格中，并通过重命名和添加依赖项作为参数使其独立于全局上下文，确保调用者始终负责提供数据。导入语句类似地被解析，在预处理期间剥离，并在导出时按脚本逐一重新插入。

即使对于高性能模型，识别读取和写入集合也被证明是一个容易出错的过程，偶尔会出现遗漏写入或幻觉读取的情况，导致缺少依赖关系。按照2.1的方法，第二次LLM传递专门查找与缺失依赖关系相关的集合中的错误。

每个单元格被标记为规则、脚本或未决定。规则对应于Snakemake执行的任务，脚本是可以被其他脚本或规则导入的可重用代码片段，未决定的单元格需要手动标记。某些约束适用：脚本可以在任何地方导入，但规则的输出文件只能被其他规则读取。

在完成DAG后，依赖关系通过生成的代码实现。前缀块实现输入依赖关系，读取和解析文件，后缀块写入输出文件供下游依赖关系使用。Snakemake规则定义了单元格之间的连接。类似于2.1，第二次LLM传递构建规则的配置。在导出之前，类似于bash管道2.1，对规则和Python脚本进行迭代验证和修正。

图2：笔记本转换管道。输入笔记本通过正则表达式和LLM（a.1, a.2）解析并转换和注释单元格的读取和写入集合及单元格状态。从注释的单元格构建DAG（b），如果有错误则进行第二次LLM传递（b.1）。用户可以修改单元格的注释（b.2），从而修改DAG。DAG随后被馈送到LLM以生成附加代码块和Snakemake规则（c）；用户可以手动更改它们（c.1），在这种情况下LLM传递会被重复以传播更改。规则和脚本的集合可以从步骤b开始馈送到图1中描述的转换管道。

2.3 聊天助手

上述功能基于某些设计好的、结构化的方式，扩展程序应尽可能减少用户干预。另一方面，聊天助手功能旨在成为Snakemaker的多功能工具，提供完全的灵活性。通过将扩展的状态（设置、记录的历史、打开的屏幕、内部数据结构）和README馈送到LLM，指示其通过输出给定的URI来使用一组命令。这些URI由Snakemaker解析并执行动作。动作允许修改扩展设置、修改记录的历史、打印新规则、修改构建的DAG或生成的代码在笔记本转换期间。

2.4 LLM交互

为了确保广泛的兼容性，与LLM的交互完全基于原始文本。LLM提示动态生成自当前设置和数据。提示围绕《Prompt Engineering白皮书》[8]提供的指南和OpenAI广为人知的指南[9]设计。提示尽可能简洁明了，偏好正面指令；上下文在上部部分提供良好的分段，并在末尾描述期望的输出格式。

提示随后通过迭代微调，测试管道，识别常见问题并防止它们。一些模型，尤其是较小的模型，显然对Snakemake语言的知识有限，倾向于反复产生语法错误，如使用点符号而不是Python字典访问语法。这些常见错误通过使用少量样例提示或简单地包含精确指令来避免。为了保持提示大小有限，一些常见错误在后处理步骤中使用正则表达式或小型有限状态自动机修复。响应格式在大多数情况下为JSON字符串，允许扩展从原始文本响应中解析丰富的数据结构。LLM的随机性质使此过程容易出现解析错误。类似于规则生成，通过特定指令识别和防止常见错误，并使用开源工具Json-Repair[10]作为后处理。如果失败，则采用类似的规则验证和修正的迭代方法。

3 结果

图3：Snakemaker GUI截图。Bash转换功能。
Snakemaker允许从记录的集成bash终端活动和Ipython笔记本构建Snakemake工作流。
bash功能在后台非侵入性地运行，使研究人员免于手动跟踪他们的工作和环境。命令被记录、处理并存储在本地的命令历史中，通过图形界面显示，用户可以在其中编辑、删除或将命令组合成复合条目。使用不同LLM的测试表明，它们能够可靠地区分与工作流相关的命令和偶然的命令（例如目录导航、git交互），通过用户反馈准确性得到提高。

用户可以通过简单的点击追溯和转换整个历史或个别命令。如果已经存在工作流，新规则将合并到其中。生成的Snakefiles遵循最佳实践，使用通配符、conda环境、配置文件以增强适应性，每条规则的日志和文档。

对于不在VSCode集成终端中工作的用户，Snakemaker还支持手动输入先前执行的命令。这可以通过复制shell内置history命令的输出来完成——这是大多数类Unix命令行接口的标准功能。该命令按时间顺序列出所有先前执行的命令，提供用户在shell中的活动的文本记录。虽然这种方法允许在集成环境之外重建工作流，但它缺乏Snakemake在集成终端内运行时能够自动捕获的丰富元数据（如目录上下文或环境信息）。

Ipython笔记本虽然适合原型设计，但往往变得难以管理。Snakemaker将它们拆分为具有清晰依赖关系的模块化脚本，通过Snakemake管道连接，使用正则表达式和LLM解决其全局状态为独立的代码块。

用户可以控制这个过程。第一步计算并图形显示描述笔记本单元格之间依赖关系的有向无环图（DAG），用户可以审查它，发现错误，修改每个块的读写集合，标记需要用通配符解决的依赖关系，合并、拆分或删除单元格。用户还可以决定一个单元格是作为规则还是脚本管理（见第2.2节了解更多细节）。在接下来的步骤中，用户可以手动调整生成的代码，更改会自动传播到DAG中的下游单元格。例如，在Snakemake规则中修改输出文件的格式会导致生成该输出的单元格的后缀代码重写以及所有读取它的单元格的前缀块重写。

此外，Snakemaker提供了一个聊天助手，可以通过自然语言提示执行用户请求的任意操作。它允许在扩展的使用中具有更大的灵活性：在bash功能中，用户可以通过自定义提示请求规则，覆盖用户特定需求，对记录的历史进行批量更改，解释或修改当前设置。聊天助手生成的规则可以直接附加到工作流，或从步骤3开始馈送到2.1中定义的管道进行后处理。由于笔记本转换功能比bash功能需要更多的用户输入，聊天助手提供的灵活性在这种情况下特别有用。助手可以审查正在构建的DAG或生成的代码，发现并修正错误并进行更改。生成的代码不可避免地带有主观性，因为在文件格式和名称上必须做出决策，助手允许轻松修改这些决策。

目前，Snakemaker需要一定规模的LLM才能有效运行。测试表明，使用最先进的模型如OpenAI 4o效果最佳，使用参数少于70B的开源模型效果次之，使用参数为4B-8B的模型几乎无法使用，这使得本地部署具有挑战性。然而，其与GitHub Copilot的集成降低了访问商业高端模型的门槛。对OpenAI兼容API的支持使几乎任何API提供商都能无缝连接。扩展的设置允许用户禁用个别功能，如配置生成、迭代验证或工作流上下文包含，根据不同模型的优势、速度和API成本定制性能。

4 结论

Snakemaker在用户工作流中非侵入性地协助开发可持续的数据分析管道。它减少了将原型代码（level 0）转换为定义明确且组织良好的管道（level 2）所需的努力。它通过采用Snakemake语言及其最佳实践，并利用LLM和传统编程算法使该过程半自动化来实现这一点。

作为VSCode扩展，Snakemaker可以集成到用户的日常工作环境中，并利用VSCode语言API连接到GitHub Copilot，这对于学生和学术界免费，对于大多数使用情况而言是一个经济实惠的选择，促进LLM在个人工作流中的使用。

Snakemaker未来改进的一个潜在领域是优化其对本地LLM部署的有效使用。这可能涉及使用带有专用Snakemake语言规范、教程和精选示例的检索增强生成（RAG）技术，以即使在较小的本地托管模型上也能增强模型性能。

Snakemaker降低了结构化工作流的门槛，鼓励从临时分析转向可持续、可重复的做法——不仅推进了可重复性，而且推动了开放、高质量数据分析的长期文化。

利益冲突

无声明。

资金

本工作得到了Chan Zuckerberg Initiative DAF（硅谷社区基金会的咨询基金）Essential Open Source Software for Science Program项目资助2024-342822（5022）GB-1609971的支持。

数据和软件代码的可用性

我们的软件代码可在以下URL获取：https://github.com/molinerisLab/snkmaker

参考文献

[1] Neha Kulkarni, Luca Alessandri, Riccardo Panero, Maddalena Arigoni, Martina Olivero, Giulio Ferrero, Francesca Cordero, Marco Beccuti, and Raffaele Calogero. 可重复生物信息学项目：可重复生物信息学分析管道的社区。BMC Bioinformatics, 19:211-219, 102018.
[2] Geir Sandve, Anton Nekrutenko, James Taylor, and Eivind Hovig. 可重复计算研究的十条简单规则。PLoS computational biology, 9:e1003285, 102013.
[3] Felix Mölder, Kim Jablonski, Brice Letcher, Michael Hall, Christopher Tomkins-Tinch, Vanessa Sochat, Jan Forster, Soohyun Lee, Sven Twardziok, Alexander Kanitz, Andreas Wilm, Manuel Holtgrewe, Sven Rahmann, Sven Nahnsen, and Johannes Köster. 使用Snakemake进行可持续数据分析。F1000Research, 10:33, 01 2021.
[4] Luis Pedro Coelho. 生物信息学中长期可持续软件。PLOS Computational Biology, 20:e1011920, 032024.
[5] Katalin Ferenc, Ieva Rauluseviciute, Ladislav Hovan, Vipin Kumar, Marieke L Kuijjer, and Anthony Mathelier. 通过团队合作提高生物信息学软件质量。Bioinformatics, 40(11):btae632, 102024.
[6] Huaixiu Steven Zheng, Swaroop Mishra, Xinyun Chen, Heng-Tze Cheng, Ed Huai hsin Chi, Quoc V. Le, and Denny Zhou. 后退一步：通过抽象激发大语言模型中的推理。ArXiv, abs/2310.06117, 2023.
[7] Lane Hemaspaandra and Jörg Rothe. 复杂性理论中Rice定理的第二步。Theoretical Computer Science, 244:205-217, 081999.
[8] Lee Boonstra. Google关于Prompt Engineering的白皮书。Google, 2025.
[9] OpenAI. 文本生成和提示。https://platform.openai.com/docs/guides/text.
[10] Jos De Jong. JSON Repair. https://github.com/josdejong/jsonrepair.

参考论文：https://arxiv.org/pdf/2505.02841