Prompt as a Data Type: In-Database LLM Prompt Management and Rewriting
作者: Denis Mayr Lima Martins, Gottfried Vossen
分类: cs.DB, cs.LG
发布日期: 2026-07-23
💡 一句话要点
提出PromptDB以解决数据库中提示管理与重写问题
🎯 匹配领域: 支柱九:具身大模型 (Embodied Foundation Models)
关键词: 大型语言模型 数据库管理 提示管理 查询优化 元数据利用
📋 核心要点
- 现有方法中,提示通常存储在DBMS之外,导致其在查询执行和优化中不可见,影响了应用的有效性。
- 论文提出PromptDB,将提示视为数据库元组的值,利用数据库元数据对提示进行重写和优化。
- 实验结果表明,PromptDB在合成和真实数据工作负载下,数据库引导的重写显著提高了输出有效性,并实现了成本与质量的良好平衡。
📝 摘要(中文)
大型语言模型(LLMs)在数据库驱动的应用中越来越普遍,但提示通常存储在数据库管理系统(DBMS)之外的非结构化格式中,导致其在查询执行、元数据管理和优化中不可见。本文提出PromptDB,一个将提示视为元组级数据库值的数据库系统。PromptDB提供逻辑PROMPT数据类型,存储模板、元组属性绑定、模型元数据和任务元数据。通过生成的评估视图,用户可以查询提示值属性,而系统内部则通过EVAL操作符渲染、重写、优化和执行提示。将提示数据库可见性引入了新的优化空间,PromptDB通过利用数据库元数据重写提示,从而提高输出有效性并实现成本与质量的良好平衡。
🔬 方法详解
问题定义:论文要解决的问题是如何将提示有效地集成到数据库管理系统中,以便在查询执行和优化过程中能够利用这些提示。现有方法的痛点在于提示的非结构化存储使其无法被数据库系统有效利用。
核心思路:论文的核心解决思路是将提示视为数据库的元组级值,通过引入PROMPT数据类型,使得提示可以直接在数据库中存储和管理,从而实现更高效的查询和优化。
技术框架:PromptDB的整体架构包括PROMPT数据类型的定义、EVAL操作符的实现,以及生成评估视图的机制。用户通过这些视图查询提示值属性,系统则负责内部的提示渲染与优化。
关键创新:最重要的技术创新点在于将提示的管理与优化引入数据库的思维方式,类似于查询优化器如何利用数据库元数据重写SQL计划,PromptDB则利用元数据重写提示。
关键设计:在设计中,PromptDB定义了PROMPT数据类型,包含模板、属性绑定、模型和任务元数据等关键参数,确保提示的灵活性和可重用性。
🖼️ 关键图片
📊 实验亮点
实验结果显示,PromptDB在合成和真实数据工作负载下,相较于静态手动编写的提示,数据库引导的重写提高了输出有效性,并在成本与质量之间实现了良好的平衡,具体提升幅度未知。
🎯 应用场景
该研究的潜在应用领域包括数据库驱动的智能应用、数据分析和自然语言处理等。PromptDB的设计可以显著提高这些应用中提示的管理效率和执行效果,未来可能推动更多基于LLM的数据库应用的发展。
📄 摘要(原文)
Large Language Models (LLMs) are increasingly used in database-backed applications to classify tuples, filter records using semantic predicates, extract structured attributes, and enrich query results. Yet the prompt that start these computations are typically stored outside the DBMS in unstructured formats, making them invisible to query execution, metadata management, and optimization. Drawing on Stonebraker's QUEL as a Data Type and the principles of reflective programming, this paper introduces PromptDB, a database system that treats prompts as tuple-level database values. PromptDB provides a logical PROMPT datatype whose values store a template, bindings to tuple attributes, model metadata, and task metadata. Relations may contain PROMPT attributes directly in base tables, or expose them through views over joined tuples. Users query prompt-valued attributes through generated evaluation views, while the system internally renders, rewrites, optimizes, and executes prompts through an EVAL operator. Making prompts database-visible creates a new optimization space. The key idea is to bring query-optimizer thinking to prompts: just as query optimizers exploit database metadata to rewrite SQL plans, PromptDB exploits database metadata to rewrite prompts. We evaluate PromptDB on synthetic and real-world data workloads across different tasks. The results show how database-guided rewriting improves output validity and yields favorable cost-quality trade-offs compared with static, manually written prompts.