SPL: Orchestrating Workflows with Declarative Deterministic-Probabilistic Composition
本文介绍了 SPL（结构化提示语言），一种将确定性计算与概率性计算统一在单一规范内的声明式框架，旨在实现模型无关的工作流编排，并通过广泛的实验证明，其基于求解器的方法比未经验证的仅由大语言模型生成的输出实现了显著更高的机器验证正确性。
原始论文采用 CC BY 4.0 许可（http://creativecommons.org/licenses/by/4.0/）。 这是对下方论文的AI生成解释。它不是由作者撰写或认可的。如需技术准确性，请参阅原始论文。 阅读完整免责声明
想象一下，你正试图构建一个超级聪明的机器人助手来帮你做作业。目前，构建这些助手就像是在造一辆汽车，但引擎、方向盘和 GPS 是由不同的公司制造的，它们说着不同的语言，并且需要用杂乱的定制胶带粘在一起。你必须成为一名编程奇才才能让它们互相沟通。
这篇论文介绍了 SPL（结构化提示语言），它就像是一个通用的遥控器，终于让机器人的“创意”部分和“数学”部分能够在同一份简洁的说明书中协同工作。
两个大脑：梦想家与计算器
论文指出，目前的 AI 工具要么处于一种模式。它们要么是梦想家（LLM），擅长写故事、猜答案和聊天，但有时会编造事实或算错数学题；或者它们是计算器（如 SymPy 或 SageMath），它们精于数学和逻辑，但无法理解笑话或写故事。
作者说：“为什么不两者兼得呢？”他们提出了一个系统：由梦想家（系统 1）将问题拆解并进行解释，而由计算器（系统 2）进行实际的繁重计算并检查结果。
大反转： 论文明确反对认为 AI 需要通过“快”或“慢”来区分其中之一的观点。这关乎的不是速度，而是它们如何思考。计算器在处理极其复杂的证明时可以很慢，而梦想家在仅仅进行猜测时可以很快。关键在于知道何时使用哪种大脑。
“一次设计，到处部署”的魔力
这是最酷的部分：通过 SPL，你只需在特殊的 .spl 文件中编写一次指令。即使你想在笔记本电脑、云端或大型超级计算机集群上运行，也不需要重写代码。
把它想象成一份食谱。你写好一份食谱，无论是在小小的露营炉灶（你的笔记本电脑）、高级厨房（云端）还是大规模工业工厂（分布式集群）中烹饪，食谱都保持不变。你只需在开始时告诉系统在哪里“烹饪”即可。论文称之为 DODA（一次设计，到处部署）。
“验证阶梯”
我们如何知道数学是对的？论文引入了一个带有三个层级的“验证阶梯”：
- 第一级（SymPy）： 擅长基础代数和微积分。它快速且简单。
- 第二级（SageMath）： 用于更难的数论和几何学。
- 第三级（Lean 4）： 终极 Boss 级。这是用于由计算机检查以确保 100% 数学正确的形式化证明，就像数学界的法律合同。
论文展示了你可以编写一个工作流，先尝试第一级。如果失败，系统会自动攀登到第二级；如果第二级也失败了，则攀登到第三级。你不需要编写“如果这个失败了，就尝试那个”的代码；这种语言会自动为你处理。
实验：实际发生了什么？
作者并没有仅仅靠猜测；他们进行了一次大规模实验。他们测试了 10 种不同的 AI 模型，针对 20 个不同的数学问题（从简单到专家级），并且每个测试运行了 3 次。总计共有 1,200 次运行。
他们比较了两种解决问题的方法：
- “仅限 LLM”分支： AI 直接猜测并写出答案。
- “求解器”分支： AI 将问题拆解，将数学部分发送给计算器，获取经过验证的答案，然后写出解释。
结果：
- 好消息： “求解器”分支的准确率极高。对于表现最好的模型，如
gemma4:e2b，在经过计算器验证后，其正确率达到了 93%。即使是sonnet-4-6也达到了 85% 的正确率。 - 陷阱： “仅限 LLM”分支几乎总能生成一个答案（接近 100% 的时间），但它是未经验证的。“求解器”分支证明了，仅仅因为 AI 说了某件事，并不代表那是事实。
- 瓶颈： “求解器”分支失败的主要原因并不是 AI 不会做数学（计算器做了那部分工作！），而是 AI 无法正确格式化它的答案。AI 必须以一种非常特定的代码格式（
expr|op）来编写数学内容，以便计算器理解。如果 AI 搞错了格式，计算器就会拒绝它。 - 惊喜： 一个名为
gemma4:e2b的小型开源模型（比那些庞大、昂贵的模型要小得多）在遵循规则方面实际上表现得比一些巨型模型更好。这表明，对于这项特定任务，做一个优秀的“格式翻译官”比拥有一个巨大的、超级聪明的脑子更重要。
论文明确表示它“不是”什么
论文非常清楚地说明了它没有做的事情：
- 它并不声称 AI 模型现在能独立完美地处理数学。事实上，实验显示，如果没有计算器，模型仅仅是在猜测。
- 它并不说“思考型”模型（即在回答前会花费很长时间“思考”的模型）更好。事实上，论文排除了一些“思考型”模型，因为它们花了太多时间思考，在能够写出计算器所需的特定代码格式之前就耗尽了空间。
- 它并不声称这解决了所有问题。实验专门针对符号数学。作者建议它可能适用于其他领域，如检查代码或验证数据，但尚未对此进行证实。
总结
论文证明了，通过将 AI 的“创意”部分与“数学”部分分离，并让计算机检查数学结果，我们可以获得更加可靠的结果。最棒的是？你不需要成为编程天才。你只需制定计划，系统就会处理余下的工作，无论你是在笔记本电脑上运行还是在超级计算机上运行。
作者通过 1,200 次运行 衡量了这一点，并发现虽然“求解器”分支稍慢一些（需要额外几秒钟来检查工作），但它将一个“可能正确”的答案变成了一个“机器验证”的答案。对于最好的模型来说，这种验证在速度上几乎没有任何成本，证明了这种双模式方法是构建更聪明、更安全的 AI 助手的切实可行的方式。
您所在领域的论文太多了？
获取与您研究关键词匹配的最新论文每日摘要——附技术摘要，使用您的语言。