💬 NLP

Making Prompts First-Class Citizens for Adaptive LLM Pipelines

本文提出了 SPEAR 框架，通过将提示词（Prompt）作为执行模型中的“一等公民”，实现了结构化版本管理、基于运行时反馈的动态自适应优化以及策略驱动的自动修正，从而解决了传统提示词与程序逻辑脱节导致的复用性差和灵活性不足问题。

原作者： Ugur Cetintemel, Shu Chen, Alexander W. Lee, Deepti Raghavan, Duo Lu, Andrew Crotty

发布于 2026-04-07

📖 1 分钟阅读☕ 轻松阅读

原作者： Ugur Cetintemel, Shu Chen, Alexander W. Lee, Deepti Raghavan, Duo Lu, Andrew Crotty

原始论文采用 CC BY 4.0 许可（http://creativecommons.org/licenses/by/4.0/）。 ✨ 这是对下方论文的AI生成解释。它不是由作者撰写或认可的。如需技术准确性，请参阅原始论文。阅读完整免责声明

这篇论文提出了一种名为 SPEAR 的新系统，旨在彻底改变我们使用大型语言模型（LLM）的方式。

为了让你轻松理解，我们可以把现在的 LLM 应用比作一家正在装修的餐厅，而 SPEAR 就是给这家餐厅带来的一场管理革命。

1. 现状：混乱的“手写菜单”

目前，大多数 LLM 应用（比如医疗诊断助手、客服机器人）的核心指令——也就是提示词（Prompt），就像是一张张手写的、涂涂改改的便签纸。

问题所在：
- 脆弱且模糊：这些便签纸（提示词）通常只是一串死板的文字。如果医生发现 AI 漏掉了药量信息，开发者只能手动在便签纸上加一行字：“请一定要写清楚药量！”
- 无法复用：每个便签纸都是孤立的。如果你想把“写药量”这个要求用到另一个关于“手术记录”的便签上，你得重新抄一遍，很容易出错。
- 无法适应：如果餐厅突然来了个急客（运行时出现新情况），或者发现某个菜做得太慢（延迟高），这些死板的便签纸无法自动调整。它们完全不知道外面发生了什么。

这就好比厨师（AI）看着一张写死的菜单做菜，不管客人多饿、厨房多乱，厨师都只能按部就班，无法灵活应变。

2. SPEAR 的解决方案：把“提示词”变成“智能食材”

SPEAR 的核心思想是：把提示词（Prompt）从“死板的便签纸”变成“有生命的、可管理的智能食材”。

在 SPEAR 的世界里，提示词不再是简单的字符串，而是像数据库里的数据一样，可以被查看、修改、组合和优化的对象。

三大核心功能（用餐厅做比喻）：

A. 结构化菜单管理（Structured Prompt Management）

比喻：以前，每道菜（任务）的食谱都是单独写在一张纸上。现在，SPEAR 把食谱做成了模块化组件。
怎么做：比如“药量说明”是一个独立的模块，“药物相互作用检查”是另一个模块。开发者可以像搭积木一样，把这些模块组合成不同的菜单（视图）。
好处：如果你想修改“药量说明”，只需要改那个模块，所有用到它的菜单都会自动更新。而且，系统会记录每一次修改的历史版本，就像餐厅的“食谱修订日志”，方便回溯。

B. 自适应的烹饪调整（Adaptive Prompt Refinement）

比喻：以前的厨师不管客人反馈什么，都按原菜单做。现在的 SPEAR 让厨师在烹饪过程中能实时调整。
怎么做：
- 手动模式：开发者像主厨一样，直接指挥：“这道菜太淡了，加点盐（修改提示词）。”
- 辅助模式：开发者只说：“这道菜要更详细点”，系统自动帮你生成更详细的指令。
- 自动模式：这是最酷的！系统会像智能温控器一样，实时监控。如果它发现“这道菜（回答）”太模糊了，或者“客人（用户）”等了太久，它会自动决定：“好吧，我要给厨师加一条指令，让他重新做一遍，或者换个更厉害的厨师（调用更大的模型）。”

C. 策略驱动的控制（Policy-Driven Control）

比喻：这是餐厅的自动管理规则。
怎么做：开发者可以设定规则，比如："当（WHEN）检测到病人是住院状态，就（THEN）自动在菜单里加入‘药物相互作用检查’这一项。”或者"当（WHEN）AI 对答案没把握时，就（THEN）自动把问题转交给更高级的专家模型。”
这些规则本身也是可以优化的，系统会学习哪些规则最有效，自动淘汰没用的规则。

3. 实际效果：更聪明、更省钱

论文通过一个医疗问答的实验证明了 SPEAR 的威力：

对比传统方法：传统的自动优化工具（如 DSPy）像是在离线状态下反复试错，虽然能优化，但一旦上线运行，遇到新情况就没办法了。
SPEAR 的表现：
- 更准：通过结构化地调整提示词，AI 回答的准确率大幅提升。
- 更省：SPEAR 能像精明的管家一样，简单的问题直接让“新手厨师”（小模型）做，复杂的问题再叫“大厨”（大模型）。结果发现，用这种动态策略，成本几乎减半，但准确率却和一直用“大厨”差不多。

总结

简单来说，SPEAR 就是把 LLM 的“提示词”从“一次性便签”升级成了“可编程的智能数据”。

它让开发者不再需要像以前那样，对着黑盒子里的乱码提示词盲目地试错。相反，他们拥有了一个透明的、可控制的、能自我进化的系统。就像是从“手工作坊”升级到了“自动化智能工厂”，让 AI 应用变得更聪明、更灵活，也更省钱。

论文技术总结：Making Prompts First-Class Citizens for Adaptive LLM Pipelines

1. 研究背景与问题 (Problem)

随着大型语言模型（LLM）被广泛集成到现实世界的复杂数据驱动应用中（如检索增强生成、多智能体协作、错误恢复等），提示词（Prompt） 已成为控制整个流程的核心要素。然而，当前的 LLM 流水线存在以下关键痛点：

提示词的“脆弱性”与“黑盒化”：提示词通常被视为静态、不透明的字符串，与周围的程序逻辑完全脱节。
缺乏系统化管理：提示词通常通过试错法手动编写，缺乏版本控制、可追溯性（Provenance）和系统性的演化跟踪。
运行时适应性不足：现有的优化框架（如 DSPy）主要侧重于离线优化，缺乏基于运行时反馈（如延迟、置信度、Token 预算）的动态调整能力。
优化机会受限：由于提示词逻辑对执行引擎不可见，导致难以进行端到端的优化（如缓存、批处理、算子融合）。

2. 核心方法论：SPEAR (Structured Prompt Execution and Adaptive Refinement)

为了解决上述问题，论文提出了 SPEAR 框架，其核心理念是将提示词提升为流水线中的一等公民（First-Class Citizens），即像处理普通数据一样处理提示词。

2.1 结构化提示词管理 (Structured Prompt Management)

提示词视图 (Prompt Views)：SPEAR 将提示词定义为结构化的数据对象，而非简单的字符串。它们被组织成命名视图（Named Views），类似于 SQL 中的视图。
- 模块化与复用：复杂的提示逻辑可以分解为小的、可组合的模块（例如，将“药物相互作用检查”作为一个独立视图）。
- 参数化：支持运行时参数传递（如将药物名称作为参数）。
- 版本控制：视图是版本化的，支持开发者追踪提示词的演化历史并进行内省（Introspection）。
系统状态：系统状态由三部分组成：提示词视图集合 ( $P$ )、上下文存储 ( $C$ ，包含输入/输出/中间结果) 和运行时元数据 ( $M$ ，如 Token 预算、延迟阈值)。

2.2 提示词代数 (Prompt Algebra)

SPEAR 定义了一个可执行的提示词代数，所有操作符都消耗并产生 $(P, C, M)$ 三元组。核心算子包括：

GENERATE (GEN)：调用 LLM 执行提示词。
RETRIEVE (RET)：从外部数据源获取数据。
SWITCH：编码条件逻辑以控制流水线流程。
REFINE (REF)：这是 SPEAR 的关键创新，允许在代数计划中直接修改提示词逻辑。

2.3 自适应提示词优化 (Adaptive Prompt Refinement)

SPEAR 允许提示词在运行时根据反馈动态演化，支持三种优化模式：

手动模式 (Manual)：开发者显式修改提示词文本（如添加具体指令）。
辅助模式 (Assisted)：开发者提供高层意图描述，系统自动编译为新的提示词版本。
自动模式 (Automatic)：系统基于运行时信号自动触发优化，无需人工干预。

2.4 策略驱动控制 (Policy-Driven Control)

引入 When-Then 规则 来管理自动优化：

规则形式：WHEN condition THEN refinement。
触发时机：
- 输入条件 (Before)：基于操作符输入（如患者状态）在运行前决定优化策略。
- 输出条件 (After)：基于操作符输出（如 LLM 判断结果置信度低）在运行后触发重试或降级策略。
自进化控制平面：策略本身也可以作为提示词被优化，形成自我改进的控制平面。

3. 关键贡献 (Key Contributions)

结构化提示词管理：提出了将提示词作为结构化数据对象和版本化视图的抽象，支持模块化、复用性和演化追踪。
运行时自适应优化：打破了离线优化的局限，实现了基于运行时反馈（如延迟、置信度）的动态提示词调整。
策略驱动的控制机制：设计了 When-Then 规则系统，统一了静态规划与运行时自适应，允许开发者细粒度控制优化逻辑。
可组合的优化机会：通过提示词代数，解锁了前缀缓存、输入/提示词批处理、算子融合等传统框架难以实现的优化手段。

4. 实验结果 (Results)

论文在 EHRNoteQA（基于电子健康记录的问答基准）上进行了评估，对比了 Baseline、DSPy、DSPy-CoT 和 SPEAR 的不同策略。

性能提升：
- SPEAR 的优化策略（特别是 R3，即结构化重组提示词组件）在所有模型规模（1B 到 27B）上均显著优于 Baseline 和 DSPy。
- R3 证明了显式的、可解释的提示词结构重组（如将临床证据前置）比黑盒优化更有效。
成本与效率权衡：
- R4 (自动路由)：利用小模型（1B）作为路由器，根据问题难度动态选择模型。在保持与 12B 模型相当准确率（83.5%）的同时，大幅降低了成本。
- R5 (级联优化)：当小模型（12B）不确定时自动升级到大模型（27B）。以接近一半的成本（$0.046 vs $0.087）达到了与 27B 模型相当的准确率（86.7% vs 87.3%）。
可调试性：相比 DSPy 的黑盒优化，SPEAR 的透明结构使得错误诊断和针对性修复更加容易。

5. 意义与未来展望 (Significance)

范式转变：SPEAR 将提示词从“静态字符串”转变为“动态数据对象”，填补了现有 LLM 框架在运行时自适应方面的空白。
互补性：它与现有的离线优化框架（如 DSPy）和语义查询引擎形成互补，专注于解决执行过程中的动态调整问题。
系统级优化潜力：通过暴露提示词逻辑，SPEAR 使得数据库领域的经典优化技术（如缓存、批处理、算子融合）能够应用于 LLM 流水线，显著降低延迟和计算成本。
开发者生产力：通过模块化和策略驱动，降低了构建复杂、鲁棒的 LLM 应用门槛，并提高了系统的可维护性。

总结：SPEAR 提出了一种全新的 LLM 流水线执行模型，通过赋予提示词一等公民的地位，实现了从静态编写到动态自适应的跨越，为构建高效、鲁棒且可解释的 AI 应用系统奠定了坚实基础。