💻 computer science

Prompt as a Data Type: In-Database LLM Prompt Management and Rewriting

本文介绍了 PromptDB，这是一个将提示词（prompt）视为一等元组级数据类型的数据库系统，旨在实现对大语言模型交互的数据库内管理、优化与重写，从而与静态的外部提示词存储相比，提高输出有效性并改善成本与质量之间的权衡。

原作者： Denis Mayr Lima Martins, Gottfried Vossen

发布于 2026-07-27

📖 1 分钟阅读☕ 轻松阅读

原作者： Denis Mayr Lima Martins, Gottfried Vossen

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

数据库与机器人的秘密语言

想象一下，你拥有一个巨大且超级有序的图书馆（一个数据库），里面存放着数百万条事实；而你还有一个聪明且健谈的机器人（一个大语言模型，或称 LLM），它几乎可以阅读并理解任何事物。通常情况下，为了让机器人利用图书馆里的事实来完成一项工作，必须由人类充当中间人。他们从图书馆里取出一张纸，为机器人写下一套特定的指令（一个“提示词”/prompt），然后将其发送出去，并等待答案。问题在于，图书馆本身并不知道机器人正在遵循什么样的指令。这就像一位厨师非常清楚冰箱里有哪些食材，却看不见厨师正在使用的食谱；因为食谱被藏在柜台上的笔记本里，所以厨师无法帮助改进糟糕的食谱，也无法建议更好的食材。

本文步入了计算机科学中数据库与人工智能交汇的世界。它解决了一个特定的头疼问题：目前，我们给 AI 机器人的指令通常存储在数据库之外，存在于杂乱的代码或笔记本中。这使得数据库很难检查这些指令是否优秀，或者在它们产生歧义时进行修正，亦或是让它们的运行成本更低。作者提出了一个激进的想法：如果我们把这些指令视为任何其他数据（比如一个名字或一个数字），直接存储在数据库的表内部，会怎么样呢？通过让指令对数据库“可见”，系统就可以自动重写这些指令，使其变得更聪明、更快速、更准确，利用数据库自身的知识来帮助机器人更好地完成工作。

论文的核心思想：提示词即数据

作者 Denis Mayr Lima Martins 和 Gottfried Vossen 引入了一个名为 PromptDB 的新系统。可以把它想象成一个不仅存储事实，还存储如何与 AI 交谈的“指令”的数据库。在传统系统中，如果你想让 AI 对客户投诉（例如“我的包裹从未送达！”）进行分类，你会在应用程序代码中编写一个提示词，从数据库中获取文本，然后将其发送给 AI。数据库仅仅将此视为一段字符串文本；它并不知道这段文本是一套旨在执行的指令。

在 PromptDB 中，提示词是一个一等公民。它是一种被称为 PROMPT 的特殊数据类型。与其将指令隐藏在笔记本中，不如将它们直接存储在表行内，与它们所描述的数据并列。一行数据可能看起来像这样：

工单 ID： 1001
消息： “包裹从未送达”
优先级： 高
指令： PROMPT("对该工单进行分类：{{body}}", output: [退款, 递送, 技术, 其他])

在这里，指令是一个结构化对象。它知道模板（“对该工单进行分类……”），知道要将哪部分行数据填入其中（body），也知道有效的答案范围（output 列表）。因为数据库可以“看到”这条指令，它可以扮演一名智能编辑的角色。

魔法编辑器：PromptOpt

真正的魔力发生在一个名为 PromptOpt 的组件中。想象一下你正在给学生的作文评分。如果学生写了一段冗长且散漫的回答，你可能会告诉他们，“请简洁明了”。如果他们忘记列出要求的步骤，你可能会说，“添加缺失的步骤”。PromptOpt 会自动为 AI 提示词执行此类操作。

该系统利用数据库自身的知识，在将提示词发送给 AI 之前对其进行重写。它有几个拿手好戏：

约束注入（Constraint Injection）： 如果数据库知道唯一的有效答案是“退款”或“递送”，PromptOpt 会重写提示词，明确告诉 AI：“你必须从这些精确的词汇中选择其一。”这能防止 AI 编造出奇怪的答案，比如“客户很伤心”。
列投影（Column Projection）： 如果一行数据有 50 列，但 AI 只需要读取“消息”这一列，PromptOpt 就会切掉其余 49 列。这节省了成本（减少了需要阅读的 token 数量）并减少了困惑。
少样本示例（Few-Shot Examples）： 系统可以查看数据库中的其他行，找到正确答案的良好范例，并将它们插入到提示词中，向 AI 展示具体该怎么做。

系统将这些重写行为视为一种查询优化器。正如数据库优化器决定搜索数据的最快方式一样，PromptOpt 决定编写提示词的最佳方式。它在成本（AI 需要阅读/写入多少个词）与质量（答案正确的可能性）之间进行权衡。它可能会决定，对于简单的任务，短小的提示词就足够了；但对于棘手的任务，值得支付额外的成本来增加示例。

研究发现

作者在三个数据集上测试了 PromptDB：虚构的支持工单、汽车评估数据集以及一个标准的行业数据集 TPC-H。他们对比了三种处理方式：

静态（Static）： 旧的方法，提示词被编写一次后便不再更改。
全规则（All Rules）： 一个盲目应用所有可能重写规则的版本。
PromptOpt： 能够为每个特定任务选择最佳重写的智能版本。

结果表明，将提示词视为数据是行之有效的。

更好的质量： 当任务要求 AI 从特定选项列表中进行选择（如对工单进行分类）时，由数据库引导的重写使 AI 的准确性大大提高。“全规则”方法通常能提供最好的结果，但成本很高。
权衡之道： PromptOpt 系统成功找到了一个平衡点。它并不总是选择最昂贵、最复杂的提示词。相反，它会选择对于该任务而言“足够好”的简单提示词，在保持高质量结果的同时节省了计算成本。例如，在某些测试中，PromptOpt 以显著减少的输入 token 数量达到了与静态方法竞争性的质量水平。
任务决定一切： 论文指出，并非一种方案适用于所有场景。一种有助于“语义过滤”（检查某一行是否符合规则）的重写方式，可能对“数值规范化”（清理混乱的文本）没有帮助。该系统表明，未来的版本需要变得更加聪明，以便知道针对哪种任务使用哪种规则。

这意味着什么（以及它不意味着什么）

论文认为，我们应该停止将 AI 指令视为隐藏且不可更改的代码。通过使它们成为可见的数据，我们可以利用数据库的超能力——它的知识约束、过滤数据的能力以及优化技能——来使 AI 的交互更加可靠和高效。

然而，作者也谨慎地指出，这并不是一个完美且已解决的问题。他们承认目前的系统使用的是简单的“启发式”规则（凭经验的猜测）来估算质量和成本，而不是一个完全学习过的、能够精准预知提示词好坏的 AI 模型。他们建议，虽然原型系统在模拟和特定数据集上表现良好，但“质量评估器”需要变得更加聪明，才能完美处理每一种可能的任务。

简而言之，PromptDB 描绘了一个未来的愿景：你的数据库不仅仅是一个存放事实的仓库，还是你 AI 的积极教练，能够实时重写指令，以确保 AI 能够正确、快速且不浪费资源地完成任务。这是让 AI 感觉不再像一个黑盒，而是成为数据世界自然组成部分的一步。

技术摘要：将提示词作为一种数据类型：数据库内 LLM 提示词管理与重写

问题陈述
大语言模型（LLM）正越来越多地集成到以数据库为支撑的应用中，用于执行诸如元组分类、语义过滤、属性提取和结果增强等任务。然而，当前的集成模式存在一个根本性的架构脱节：驱动这些计算的提示词（Prompts）通常存储在数据库管理系统（DBMS）之外的非结构化格式中（例如应用程序代码、Notebook 或配置文件）。因此，提示词对 DBMS 是不可见的，导致系统无法对其进行检查、重写、解释或优化。虽然基于 SQL 的用户自定义函数（UDF）允许调用 LLM，但提示词仍然是一个不透明的参数，数据库无法利用自身的元数据（模式、约束、统计信息）来提高提示词的有效性或效率。这导致了诸如 LLM 生成的输出违反数据库领域或约束，以及缺乏针对提示词执行的成本-质量权衡的系统性优化等问题。

方法论与系统设计
本文介绍了 PromptDB，这是一个通过将提示词提升为第一类公民（即视为元组级数据库值）来构建的数据库系统。受 Stonebraker 的“将 QUEL 作为一种数据类型”概念及反射式编程的启发，该系统引入了一个逻辑 PROMPT 数据类型。

数据模型： PROMPT 类型是一个自描述的结构化对象，包含：
- 模板 ( $T$ )： 带有变量的字符串。
- 绑定 ( $B$ )： 将模板变量映射到元组属性的映射表。
- 模型元数据 ( $M$ )： 目标 LLM 的规范。
- 任务元数据 ( $D$ )： 输出领域或规范（例如，有效标签）。
执行模型： 提示词可以驻留在基础表或视图中。当用户查询一个具有提示词值的属性时，系统会在内部根据元组渲染提示词，利用数据库上下文对其进行重写，并通过内部的 EVAL 算子执行。
提示词重写与优化： PromptDB 将提示词工程视为一个数据库优化问题。它利用由数据库衍生的上下文 ( $\Omega$ $Ω$ )——包括模式、约束、查询谓词和统计信息——来重写提示词。
- 重写规则： 系统采用了一种基于规则的方法，包括：
  - 约束注入 ( $R_{CI}$ )： 注入源自数据库约束的有效输出领域。
  - 查询感知列投影 ( $R_{QACP}$ )： 裁剪无关的元组属性以减少 Token 成本。
  - 输出格式最小化 ( $R_{OFM}$ )： 强制执行简洁、可解析的输出。
  - 数据库选择的少样本示例 ( $R_{FSE}$ )： 从数据库中选择相关的示例并包含在提示词中。
- PromptOpt： 该优化器通过估计成本-质量权衡 ( $\hat{Q} - \lambda\hat{C}$ ) 来选择最佳重写计划，平衡估计的输出质量与 Token 成本。

实现
作者在 DuckDB 之上实现了 PromptDB 的原型。

PROMPT 类型被定义为 DuckDB 的 STRUCT。
为了在不进行侵入性内核修改的情况下处理执行，系统生成**评估视图（evaluation views）**来暴露提示词列。在内部，这些视图会展开为 EVAL 调用。
EVAL 算子是一个标量 UDF，负责反序列化提示词、应用选定的重写策略（通过 PromptOpt）、渲染最终提示词、调用 LLM（通过 LM Studio），并将结果作为 SQL 字符串返回。
执行元数据（策略、成本、延迟、Token 数）会被记录以供分析。

实验结果
该系统在合成数据集和真实世界数据集（支持工单、汽车评估、TPC-H）上针对三项任务进行了评估：属性提取、语义过滤和语义值归一化。

任务质量： 与静态、手动编写的提示词相比，数据库引导的重写显著提高了端到端的任务质量，尤其是在需要受限或结构化输出的任务（如属性提取）中。
规则敏感性： 消融研究表明，没有单一的重写规则在所有任务中都占据主导地位；有效性具有高度的任务依赖性。例如，约束注入对于分类任务至关重要，而投影则有助于降低成本。
成本-质量权衡： PromptOpt 策略成功地选择了在保持竞争性质量的同时具有较低成本的重写计划，这证明了成本感知型提示词规划的可行性。然而，启发式质量估计器显示出其局限性，在某些复杂结构化输出任务中，无法始终选择足够丰富的计划。

意义与主张
本文主张，将提示词视为数据库可见的、类型化的值，创造了一个类似于传统查询优化的新优化空间。通过将查询优化器的思维引入提示词，PromptDB 使数据库能够：

提高有效性： 利用模式约束来防止无效的 LLM 输出。
降低成本： 通过投影和上下文裁剪来最小化 Token 使用量。
提升质量： 通过数据库选择的示例和任务感知重写来提高性能，尤其是对于较小的模型。

作者将 PromptDB 定位为现有提示词工程框架（如 DSPy）和语义算子（如 LOTUS 或 EVAPORATE）的补充。其他方法将提示词视为瞬态字符串或算子参数，而 PromptDB 则专注于如何系统地使用数据库元数据（模式、约束、统计信息）来重写提示词模板。本文结论指出，这种方法将提示词工程从琐碎的应用逻辑转变为一种系统的、由数据库管理的流程，为 AI 原生数据库研究开辟了新的途径。