💻 computer science

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

Este artículo presenta PromptDB, un sistema de base de datos que trata los prompts como tipos de datos de nivel de tupla de primera clase para permitir la gestión, optimización y reescritura en la base de datos de las interacciones con Modelos de Lenguaje Grande, mejorando así la validez de la salida y las compensaciones entre costo y calidad en comparación con el almacenamiento de prompts estáticos y externos.

Autores originales: Denis Mayr Lima Martins, Gottfried Vossen

Publicado 2026-07-27

📖 7 min de lectura🧠 Análisis profundo

CC BY 4.0

Autores originales: Denis Mayr Lima Martins, Gottfried Vossen

Artículo original bajo licencia CC BY 4.0 (http://creativecommons.org/licenses/by/4.0/). ✨ Esta es una explicación generada por IA del artículo a continuación. No ha sido escrita ni avalada por los autores. Para mayor precisión técnica, consulte el artículo original. Leer descargo de responsabilidad completo

El lenguaje secreto de las bases de datos y los robots

Imagina que tienes una biblioteca gigante y súper organizada (una base de datos) que contiene millones de hechos, y tienes un robot brillante y parlanchín (un Modelo de Lenguaje Grande, o LLM) que puede leer y entender casi cualquier cosa. Normalmente, para lograr que el robot realice un trabajo utilizando los hechos de la biblioteca, un humano tiene que actuar como intermediario. El humano toma un trozo de papel de la biblioteca, escribe un conjunto específico de instrucciones (un "prompt") para el robot, lo envía y espera la respuesta. El problema es que la biblioteca en sí misma no sabe qué instrucciones está siguiendo el robot. Es como un chef que sabe exactamente qué ingredientes hay en la nevera pero no puede ver la receta que el cocinero está usando; el chef no puede ayudar a arreglar una mala receta o sugerir mejores ingredientes porque la receta está escondida en un cuaderno sobre la encimera.

Este artículo se adentra en el mundo de la informática donde las bases de datos y la inteligencia artificial se encuentran. Aborda un dolor de cabeza específico: actualmente, las instrucciones que damos a los robots de IA suelen estar almacenadas fuera de la base de datos, en código desordenado o cuadernos. Esto dificulta que la base de datos compruebe si las instrucciones son buenas, las corrija si son confusas o las haga más baratas de ejecutar. Los autores proponen una idea radical: ¿qué pasaría si tratáramos estas instrucciones como cualquier otro dato, como un nombre o un número, almacenado directamente dentro de las tablas de la base de datos? Al hacer que las instrucciones sean "visibles" para la base de datos, el sistema podría reescribirlas automáticamente para que sean más inteligentes, rápidas y precisas, utilizando el propio conocimiento de la base de datos para ayudar al robot a realizar mejor su trabajo.

La gran idea del artículo: Los prompts como datos

Los autores, Denis Mayr Lima Martins y Gottfried Vossen, presentan un nuevo sistema llamado PromptDB. Piensa en él como una base de datos que no solo almacena hechos, sino que también almacena las instrucciones sobre cómo hablar con una IA. En los sistemas tradicionales, si quisieras que una IA clasificara una queja de un cliente (como "¡Mi paquete nunca llegó!"), escribirías un prompt en el código de tu aplicación, extraerías el texto de la base de datos y lo enviarías a la IA. La base de datos solo ve una cadena de texto; no sabe que este texto es un conjunto de instrucciones destinadas a ser ejecutadas.

En PromptDB, el prompt es un ciudadano de primera clase. Es un tipo de dato especial llamado PROMPT. En lugar de esconder las instrucciones en un cuaderno, la base de datos las almacena directamente dentro de las filas de la tabla, junto con los datos que describen. Una fila podría verse así:

ID de Ticket: 1001
Mensaje: "El paquete nunca llegó"
Prioridad: Alta
Instrucción: PROMPT("Clasifica este ticket: {{body}}", output: [reembolso, entrega, técnico, otro])

Aquí, la instrucción es un objeto estructurado. Conoce la plantilla ("Clasifica este ticket...") , sabe qué parte de la fila debe insertar (el body) y conoce las respuestas válidas (la lista output). Debido a que la base de datos puede "ver" la instrucción, puede actuar como un editor inteligente.

El editor mágico: PromptOpt

La verdadera magia ocurre con un componente llamado PromptOpt. Imagina que eres un profesor calificando el ensayo de un estudiante. Si el estudiante escribe una respuesta larga y divagante, podrías decirle: "Sé conciso". Si olvida enumerar los pasos requeridos, podrías decirle: "Añade los pasos que faltan". PromptOpt hace esto automáticamente para los prompts de IA.

El sistema utiliza el propio conocimiento de la base de datos para reescribir las instrucciones antes de enviarlas a la IA. Tiene algunos trucos bajo la manga:

Inyección de restricciones: Si la base de datos sabe que las únicas respuestas válidas son "reembolso" o "entrega", PromptOpt reescribe el prompt para decirle explícitamente a la IA: "Debes elegir una de estas palabras exactas". Esto evita que la IA invente respuestas extrañas como "El cliente está triste".
Proyección de columnas: Si una fila tiene 50 columnas de datos pero la IA solo necesita leer la columna "mensaje", PromptOpt recorta las otras 49. Esto ahorra dinero (menos tokens para leer) y reduce la confusión.
Ejemplos de pocos disparos (Few-Shot Examples): El sistema puede observar otras filas en la base de datos, encontrar buenos ejemplos de respuestas correctas e insertarlos en el prompt para mostrarle a la IA exactamente qué hacer.

El sistema trata estas reescrituras como un optimizador de consultas. Del mismo modo que un optimizador de base de datos decide la forma más rápida de buscar datos, PromptOpt decide la mejor forma de escribir el prompt. Sopesa el costo (cuántas palabras tiene que leer/escribir la IA) frente a la calidad (qué tan probable es que la respuesta sea correcta). Puede decidir que para una tarea sencilla, un prompt corto es suficiente, pero para una difícil, vale la pena pagar el costo adicional de añadir ejemplos.

Lo que encontraron

Los autores probaron PromptDB en tres conjuntos de datos diferentes: tickets de soporte falsos, un conjunto de datos de evaluación de coches y un conjunto de datos estándar de la industria llamado TPC-H. Compararon tres formas de hacer las cosas:

Estático: La forma antigua, donde el prompt se escribe una vez y nunca se cambia.
Todas las reglas: Una versión que aplica ciegamente todas las posibles reglas de reescritura.
PromptOpt: La versión inteligente que elige la mejor reescritura para cada trabajo específico.

Los resultados sugieren que tratar los prompts como datos funciona.

Mejor calidad: Cuando la tarea requería que la IA eligiera de una lista específica de opciones (como clasificar un ticket), la reescritura guiada por la base de datos hizo que la IA fuera mucho más precisa. El enfoque de "Todas las reglas" a menudo daba los mejores resultados, pero era costoso.
El equilibrio: El sistema PromptOpt logró encontrar un punto ideal. No siempre elegía el prompt más complejo y costoso. En su lugar, elegía prompts más simples que eran "suficientemente buenos" para el trabajo, ahorrando costos de computación mientras mantenía resultados de alta calidad. Por ejemplo, en algunas pruebas, PromptOpt logró una calidad competitiva con significativamente menos tokens de entrada que el método estático.
La tarea importa: El artículo señala que una solución no sirve para todos. Una reescritura que ayuda con el "filtrado semántico" (comprobar si una fila coincide con una regla) puede no ayudar con la "normalización de valores" (limpiar texto desordenado). El sistema sugiere que las versiones futuras necesitan ser aún más inteligentes para saber qué regla usar para cada tarea.

Lo que esto significa (y lo que no es)

El artículo argumenta que debemos dejar de tratar las instrucciones de la IA como código oculto e inalterable. Al hacerlas visibles como datos, podemos utilizar los superpoderes de la base de datos —su conocimiento de las restricciones, su capacidad para filtrar datos y sus habilidades de optimización— para que las interacciones con la IA sean más fiables y eficientes.

Sin embargo, los autores tienen cuidado de no afirmar que este es un problema perfecto y resuelto. Admiten que su sistema actual utiliza reglas "heurísticas" simples (conjeturas educadas) para estimar la calidad y el costo, en lugar de un modelo de IA totalmente aprendido que sepa exactamente qué tan bueno será un prompt. Sugieren que, si bien el prototipo funciona bien en simulaciones y en conjuntos de datos específicos, el "estimador de calidad" debe volverse más inteligente para manejar cada tarea perfectamente.

En resumen, PromptDB sugiere un futuro donde tu base de datos no es solo un almacén de hechos, sino un entrenador activo para tu IA, reescribiendo sus instrucciones en tiempo real para asegurar que haga su trabajo correctamente, rápido y sin desperdiciar recursos. Es un paso para que la IA se sienta menos como una caja negra y más como una parte natural del mundo de los datos.

Resumen Técnico: El Prompt como un Tipo de Dato: Gestión y Reescritura de Prompts en la Base de Datos

Declaración del Problema
Los Modelos de Lenguaje Grande (LLM) se están integrando cada vez más en aplicaciones respaldadas por bases de datos para tareas como la clasificación de tuplas, el filtrado semántico, la extracción de atributos y el enriquecimiento de resultados. Sin embargo, los patrones de integración actuales sufren un desencuentro arquitectónico fundamental: los prompts que impulsan estas computaciones suelen almacenarse fuera del Sistema de Gestión de Bases de Datos (DBMS) en formatos no estructurados (por ejemplo, código de aplicación, notebooks o archivos de configuración). En consecuencia, los prompts son invisibles para el DBMS, lo que impide que el sistema los inspeccione, reescriba, explique u optimice. Si bien las Funciones Definidas por el Usuario (UDF) basadas en SQL permiten la invocación de LLMs, el prompt permanece como un argumento opaco, y la base de datos no puede aprovechar su propia metadata (esquema, restricciones, estadísticas) para mejorar la validez o la eficiencia del prompt. Esto genera problemas tales como que los LLM generen salidas que violen los dominios o restricciones de la base de datos, y una falta de optimización sistemática para el equilibrio entre costo y calidad de la ejecución del prompt.

Metodología y Diseño del Sistema
El artículo presenta PromptDB, un sistema de base de datos que eleva los prompts a ciudadanos de primera clase al tratarlos como valores de tupla de la base de datos. Inspirándose en el concepto de Stonebraker de "QUEL como un Tipo de Dato" y la programación reflexiva, el sistema introduce un tipo de dato lógico PROMPT.

Modelo de Datos: El tipo PROMPT es un objeto estructurado autodescrito que contiene:
- Plantilla ( $T$ ): Una cadena con variables.
- Vinculaciones ( $B$ ): Un mapa que vincula las variables de la plantilla con los atributos de la tupla.
- Metadata del Modelo ( $M$ ): Especificación del LLM objetivo.
- Metadata de la Tarea ( $D$ ): El dominio de salida o especificación (por ejemplo, etiquetas válidas).
Modelo de Ejecución: Los prompts pueden residir en tablas base o vistas. Cuando un usuario consulta un atributo con valor de prompt, el sistema renderiza internamente el prompt contra la tupla, lo reescribe utilizando el contexto de la base de datos y lo ejecuta mediante un operador EVAL interno.
Reescritura y Optimización de Prompts: PromptDB trata la ingeniería de prompts como un problema de optimización de bases de datos. Utiliza un contexto derivado de la base de datos ( $\Omega$ $Ω$ ) que comprende el esquema, las restricciones, los predicados de consulta y las estadísticas para reescribir los prompts.
- Reglas de Reescritura: El sistema emplea un enfoque basado en reglas que incluye:
  - Inyección de Restricciones ( $R_{CI}$ ): Inyección de dominios de salida válidos derivados de las restricciones de la base de datos.
  - Proyección de Columnas Consciente de la Consulta ( $R_{QACP}$ ): Poda de atributos de tupla irrelevantes para reducir los costos de tokens.
  - Minimización del Formato de Salida ( $R_{OFM}$ ): Imposición de salidas concisas y analizables.
  - Ejemplos de Pocos Disparos Seleccionados por la DB ( $R_{FSE}$ ): Selección de ejemplos relevantes de la base de datos para incluirlos en el prompt.
- PromptOpt: Un optimizador que selecciona el mejor plan de reescritura estimando un equilibrio costo-calidad ( $\hat{Q} - \lambda\hat{C}$ ), equilibrando la calidad de salida estimada frente a los costos de tokens.

Implementación
Los autores implementaron un prototipo de PromptDB sobre DuckDB.

El tipo PROMPT se define como un STRUCT de DuckDB.
Para manejar la ejecución sin modificaciones invasivas del kernel, el sistema genera vistas de evaluación que exponen las columnas de los prompts. Internamente, estas vistas se expanden en llamadas EVAL.
El operador EVAL es una UDF escalar que deserializa el prompt, aplica la estrategia de reescritura seleccionada (vía PromptOpt), renderiza el prompt final, llama a un LLM (vía LM Studio) y devuelve el resultado como una cadena SQL.
La metadata de ejecución (estrategia, costo, latencia, tokens) se registra para su análisis.

Resultados Experimentales
El sistema fue evaluado en conjuntos de datos sintéticos y del mundo real (Tickets de Soporte, Evaluación de Autos, TPC-H) a través de tres tareas: Extracción de Atributos, Filtrado Semántico y Normalización de Valores Semánticos.

Calidad de la Tarea: La reescritura guiada por la base de datos mejoró significamente la calidad de extremo a extremo de las tareas en comparación con los prompts estáticos escritos manualmente, particularmente para tareas que requieren salidas restringidas o estructuradas (por ejemplo, extracción de atributos).
Sensibilidad de las Reglas: Los estudios de ablación revelaron que ninguna regla de reescritura única domina todas las tareas; la efectividad depende altamente de la tarea. Por ejemplo, la inyección de restricciones es crítica para la clasificación, mientras que la proyección ayuda en la reducción de costos.
Compromiso Costo-Calidad: La estrategia PromptOpt seleccionó con éxito planes de reescritura de menor costo que mantuvieron una calidad competitiva para ciertas tareas, demostrando la viabilidad de la planificación de prompts consciente del costo. Sin embargo, el estimador de calidad heurístico mostró limitaciones al no poder seleccionar siempre planes suficientemente ricos para tareas de salida estructurada complejas.

Significancia y Reivindicaciones
El artículo sostiene que tratar los prompts como valores tipados y visibles para la base de datos crea un nuevo espacio de optimización análogo a la optimización de consultas tradicional. Al llevar el pensamiento del optimizador de consultas a los prompts, PromptDB permite que el DBMS:

Mejore la Validez: Utilizar las restricciones del esquema para prevenir salidas inválidas del LLM.
Reduzca los Costos: Utilizar la proyección y la poda de contexto para minimizar el uso de tokens.
Mejore la Calidad: Utilizar ejemplos seleccionados de la base de datos y reescritura consciente de la tarea para mejorar el rendimiento, especialmente para modelos más pequeños.

Los autores posicionan a PromptDB como un enfoque complementario a los marcos de ingeniería de prompts existentes (como DSPy) y operadores semánticos (como LOTUS o EVAPORATE). Mientras otros tratan los prompts como cadenas efímeras o parámetros de operadores, PromptDB se enfoca específicamente en cómo la metadata de la base de datos (esquema, restricciones, estadísticas) puede reescribir sistemáticamente las plantillas de los prompts. El artículo concluye que este enfoque mueve la ingeniería de prompts de la lógica de aplicación ad-hoc a un proceso gestionado sistemáticamente por la base de datos, abriendo nuevas vías para la investigación de bases de datos nativas de IA.

El lenguaje secreto de las bases de datos y los robots

La gran idea del artículo: Los prompts como datos

El editor mágico: PromptOpt

Lo que encontraron

Lo que esto significa (y lo que no es)

Más como este