💻 computer science

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

Cet article présente PromptDB, un système de base de données qui traite les prompts comme des types de données de premier niveau au niveau du tuple afin de permettre la gestion, l'optimisation et la réécriture en base de données des interactions avec les grands modèles de langage, améliorant ainsi la validité des sorties et les compromis coût-qualité par rapport au stockage externe et statique des prompts.

Auteurs originaux : Denis Mayr Lima Martins, Gottfried Vossen

Publié 2026-07-27

📖 8 min de lecture🧠 Analyse approfondie

CC BY 4.0

Auteurs originaux : Denis Mayr Lima Martins, Gottfried Vossen

Article original sous licence CC BY 4.0 (http://creativecommons.org/licenses/by/4.0/). ✨ Ceci est une explication générée par l'IA de l'article ci-dessous. Elle n'a pas été rédigée ni approuvée par les auteurs. Pour une précision technique, consultez l'article original. Lire la clause de non-responsabilité complète

Le langage secret des bases de données et des robots

Imaginez que vous possédez une bibliothèque géante et super organisée (une base de données) qui contient des millions de faits, et que vous avez un robot brillant et bavard (un grand modèle de langage, ou LLM) capable de lire et de comprendre presque tout. Habituellement, pour que le robot accomplisse une tâche en utilisant les faits de la bibliothèque, un humain doit agir comme intermédiaire. Il saisit une feuille de papier dans la bibliothèque, écrit un ensemble spécifique d'instructions (un « prompt ») pour le robot, l'envoie, puis attend la réponse. Le problème est que la bibliothèque elle-même ne sait pas quelles instructions le robot suit. C'est comme un chef cuisinier qui sait exactement quels ingrédients se trouvent dans le réfrigérateur mais qui ne peut pas voir la recette que le cuisinier utilise ; le chef ne peut pas aider à corriger une mauvaise recette ou suggérer de meilleurs ingrédients parce que la recette est cachée dans un carnet sur le comptoir.

Ce document entre dans le monde de l'informatique où les bases de données et l'intelligence artificielle se rencontrent. Il s'attaque à un casse-tête spécifique : actuellement, les instructions que nous donnons aux robots d'IA sont souvent stockées en dehors de la base de données, dans du code désordonné ou des carnets de notes. Cela rend difficile pour la base de données de vérifier si les instructions sont bonnes, de les corriger si elles sont confuses, ou de les rendre moins coûteuses à exécuter. Les auteurs proposent une idée radicale : et si nous traitions ces instructions comme n'importe quelle autre donnée, comme un nom ou un nombre, stockée directement à l'intérieur des tables de la base de données ? En rendant les instructions « visibles » pour la base de données, le système pourrait automatiquement les réécrire pour qu'elles soient plus intelligentes, plus rapides et plus précises, en utilisant sa propre connaissance pour aider le robot à mieux faire son travail.

La grande idée du papier : Le prompt comme donnée

Les auteurs, Denis Mayr Lima Martins et Gottfried Vossen, introduisent un nouveau système appelé PromptDB. Voyez cela comme une base de données qui ne stocke pas seulement des faits, mais aussi les instructions sur la manière de parler à une IA. Dans les systèmes traditionnels, si vous vouliez qu'une IA classifie une plainte client (comme « Mon colis n'est jamais arrivé ! »), vous écririez un prompt dans votre code d'application, extrairiez le texte de la base de données, et l'enverriez à l'IA. La base de données ne voit alors qu'une chaîne de texte ; elle ne sait pas que ce texte est un ensemble d'instructions destinées à être exécutées.

Dans PromptDB, le prompt est un citoyen de première classe. C'est un type de donnée spécial appelé PROMPT. Au lieu de cacher les instructions dans un carnet, la base de données les stocke directement à l'intérieur des lignes de la table, aux côtés des données qu'elles décrivent. Une ligne pourrait ressembler à ceci :

ID du ticket : 1001
Message : « Le colis n'est jamais arrivé »
Priorité : Haute
Instruction : PROMPT("Classifie ce ticket : {{body}}", output: [remboursement, livraison, technique, autre])

Ici, l'instruction est un objet structuré. Elle connaît le modèle (le template : « Classifie ce ticket... »), elle sait quelle partie de la ligne elle doit y injecter (le body), et elle connaît les réponses valides (la liste output). Parce que la base de données peut « voir » l'instruction, elle peut agir comme un éditeur intelligent.

L'éditeur magique : PromptOpt

La véritable magie opère avec un composant appelé PromptOpt. Imaginez que vous êtes un enseignant corrigeant la dissertation d'un élève. Si l'élève écrit une réponse longue et confuse, vous pourriez lui dire : « Sois concis ». S'il oublie de lister les étapes requises, vous pourriez lui dire : « Ajoute les étapes manquantes ». PromptOpt fait cela automatiquement pour les prompts d'IA.

Le système utilise la propre connaissance de la base de données pour réécrire les instructions avant de les envoyer à l'IA. Il possède quelques astuces dans sa manche :

Injection de contraintes : Si la base de données sait que les seules réponses valides sont « remboursement » ou « livraison », PromptOpt réécrit le prompt pour dire explicitement à l'IA : « Tu dois choisir l'un de ces mots exacts ». Cela empêche l'IA d'inventer des réponses bizarres comme « Le client est triste ».
Projection de colonnes : Si une ligne possède 50 colonnes de données mais que l'IA n'a besoin de lire que la colonne « message », PromptOpt supprime les 49 autres. Cela permet d'économiser de l'argent (moins de tokens à lire) et de réduire la confusion.
Exemples de type "Few-Shot" : Le système peut regarder d'autres lignes dans la base de données, trouver de bons exemples de réponses correctes, et les insérer dans le prompt pour montrer à l'IA exactement quoi faire.

Le système traite ces réécritures comme un optimiseur de requête. Tout comme un optimiseur de base de données décide du moyen le plus rapide de rechercher des données, PromptOpt décide de la meilleure façon de rédiger le prompt. Il évalue le coût (combien de mots l'IA doit lire/écrire) par rapport à la qualité (quelle est la probabilité que la réponse soit correcte). Il peut décider que pour une tâche simple, un prompt court suffit, mais que pour une tâche complexe, il vaut la peine de payer le coût supplémentaire pour ajouter des exemples.

Ce qu'ils ont découvert

Les auteurs ont testé PromptDB sur trois ensembles de données différents : des faux tickets de support, un ensemble d'évaluation de voitures, et un ensemble de données standard de l'industrie appelé TPC-H. Ils ont comparé trois méthodes de travail :

Statique : L'ancienne méthode, où le prompt est écrit une fois et ne change jamais.
Toutes les règles : Une version qui applique aveuglément chaque règle de réécriture possible.
PromptOpt : La version intelligente qui choisit la meilleure réécriture pour chaque tâche spécifique.

Les résultats suggèrent que traiter les prompts comme des données fonctionne.

Meilleure qualité : Lorsque la tâche exigeait que l'IA choisisse parmi une liste d'options spécifiques (comme classer un ticket), la réécriture guidée par la base de données a rendu l'IA beaucoup plus précise. L'approche « Toutes les règles » donnait souvent les meilleurs résultats, mais elle était coûteuse.
Le compromis : Le système PromptOpt a réussi à trouver un juste milieu. Il ne choisissait pas toujours le prompt le plus complexe et le plus coûteux. Au lieu de cela, il choisissait des prompts plus simples qui étaient « assez bons » pour la tâche, économisant ainsi les coûts de calcul tout en obtenant des résultats de haute qualité. Par exemple, dans certains tests, PromptOpt a obtenu une qualité compétitive avec nettement moins de tokens d'entrée que la méthode statique.
La tâche importe : Le papier note qu'une solution unique ne convient pas à tous. Une réécriture qui aide pour le « filtrage sémantique » (vérifier si une ligne correspond à une règle) peut ne pas aider pour la « normalisation de valeur » (nettoyer un texte désordonné). Le système suggère que les futures versions devront être encore plus intelligentes pour savoir quelle règle utiliser pour quelle tâche.

Ce que cela signifie (et ce que cela ne signifie pas)

Le papier soutient que nous devrions cesser de traiter les instructions d'IA comme du code caché et immuable. En les rendant visibles sous forme de données, nous pouvons utiliser les superpouvoirs de la base de données — sa connaissance des contraintes, sa capacité à filtrer les données et ses compétences d'optimisation — pour rendre les interactions avec l'IA plus fiables et efficaces.

Cependant, les auteurs prennent soin de ne pas prétendre qu'il s'agit d'un problème parfaitement résolu. Ils admettent que leur système actuel utilise des règles « heuristiques » simples (des suppositions éclairées) pour estimer la qualité et le coût, plutôt qu'un modèle d'IA entièrement appris qui saurait exactement quelle sera la qualité d'un prompt. Ils suggèrent que bien que le prototype fonctionne bien dans des simulations et sur des ensembles de données spécifiques, l'« estimateur de qualité » doit devenir plus intelligent pour pouvoir gérer parfaitement chaque tâche possible.

En bref, PromptDB suggère un avenir où votre base de données n'est pas seulement un entrepôt de faits, mais un coach actif pour votre IA, réécrivant ses instructions en temps réel pour s'assurer qu'elle accomplisse sa tâche correctement, rapidement et sans gaspiller de ressources. C'est une étape vers un monde où l'IA semble moins être une boîte noire et davantage une partie naturelle du monde des données.

Résumé Technique : Le Prompt en tant que Type de Données : Gestion et Réécriture de Prompts au sein de la Base de Données

Énoncé du Problème
Les modèles de langage étendus (LLM) sont de plus en plus intégrés dans des applications reposant sur des bases de données pour des tâches telles que la classification de tuples, le filtrage sémantique, l'extraction d'attributs et l'enrichissement de résultats. Cependant, les modèles d'intégration actuels souffrent d'une déconnexion architecturale fondamentale : les prompts qui pilotent ces calculs sont typiquement stockés en dehors du système de gestion de base de données (SGBD) sous des formats non structurés (par exemple, code applicatif, notebooks ou fichiers de configuration). Par conséquent, les prompts sont invisibles pour le SGBD, ce qui empêche le système de les inspecter, de les réécrire, de les expliquer ou de les optimiser. Bien que les fonctions définies par l'utilisateur (UDF) basées sur le SQL permettent l'invocation de LLM, le prompt reste un argument opaque, et la base de données ne peut pas exploiter ses propres métadonnées (schéma, contraintes, statistiques) pour améliorer la validité ou l'efficacité du prompt. Cela entraîne des problèmes tels que la génération par les LLM de sorties qui violent les domaines ou les contraintes de la base de données, ainsi qu'un manque d'optimisation systématique pour le compromis coût-qualité de l'exécution des prompts.

Méthodologie et Conception du Système
Le document présente PromptDB, un système de base de données qui élève les prompts au rang de citoyens de premier rang en les traitant comme des valeurs de base de données au niveau du tuple. S'inspirant du concept de Stonebraker « QUEL en tant que Type de Données » et de la programmation réflexive, le système introduit un type logique PROMPT.

Modèle de Données : Le type PROMPT est un objet structuré auto-descriptif contenant :
- Un Modèle (Template $T$ ) : Une chaîne de caractères avec des variables.
- Des Liaisons (Bindings $B$ ) : Une correspondance reliant les variables du modèle aux attributs des tuples.
- Des Métadonnées de Modèle (Metadata $M$ ) : La spécification du LLM cible.
- Des Métadonnées de Tâche (Task Metadata $D$ ) : Le domaine de sortie ou la spécification (ex: étiquettes valides).
Modèle d'Exécution : Les prompts peuvent résider dans des tables de base ou des vues. Lorsqu'un utilisateur interroge un attribut de type prompt, le système génère en interne le prompt par rapport au tuple, le réécrit en utilisant le contexte de la base de données, et l'exécute via un opérateur EVAL interne.
Réécriture et Optimisation de Prompt : PromptDB traite l'ingénierie de prompt comme un problème d'optimisation de base de données. Il utilise un contexte dérivé de la base de données ( $\Omega$ $Ω$ ) comprenant le schéma, les contraintes, les prédicats de requête et les statistiques pour réécrire les prompts.
- Règles de Réécriture : Le système emploie une approche basée sur des règles incluant :
  - Injection de Contraintes ( $R_{CI}$ ) : Injection de domaines de sortie valides dérivés des contraintes de la base de données.
  - Projection de Colonnes Sensible à la Requête ( $R_{QACP}$ ) : Élagage des attributs de tuples non pertinents pour réduire les coûts de tokens.
  - Minimisation du Format de Sortie ( $R_{OFM}$ ) : Imposition de sorties concises et analysables.
  - Sélection d'Exemples Few-Shot par la DB ( $R_{FSE}$ ) : Sélection d'exemples pertinents à partir de la base de données pour les inclure dans le prompt.
- PromptOpt : Un optimiseur qui sélectionne le meilleur plan de réécriture en estimant un compromis qualité-coût ( $\hat{Q} - \lambda\hat{C}$ ), équilibrant la qualité de sortie estimée et les coûts de tokens.

Implémentation
Les auteurs ont implémenté un prototype de PromptDB sur la base de DuckDB.

Le type PROMPT est défini comme un STRUCT de DuckDB.
Pour gérer l'exécution sans modifications invasives du noyau, le système génère des vues d'évaluation qui exposent les colonnes de prompts. En interne, ces vues se déploient en appels EVAL.
L'opérateur EVAL est une UDF scalaire qui désérialise le prompt, applique la stratégie de réécriture sélectionnée (via PromptOpt), génère le prompt final, appelle un LLM (via LM Studio) et retourne le résultat sous forme de chaîne SQL.
Les métadonnées d'exécution (stratégie, coût, latence, tokens) sont enregistrées pour analyse.

Résultats Expérimentaux
Le système a été évalué sur des jeux de données synthétiques et réels (Tickets de support, Évaluation de voitures, TPC-H) à travers trois tâches : l'Extraction d'Attributs, le Filtrage Sémantique et la Normalisation de Valeurs Sémantiques.

Qualité de la Tâche : La réécriture guidée par la base de données a considérablement amélioré la qualité globale des tâches par rapport aux prompts statiques écrits manuellement, particulièrement pour les tâches nécessitant des sorties contraintes ou structurées (ex: extraction d'attributs).
Sensibilité des Règles : Les études d'ablation ont révélé qu'aucune règle de réécriture unique ne domine toutes les tâches ; l'efficacité est hautement dépendante de la tâche. Par exemple, l'injection de contraintes est critique pour la classification, tandis que la projection aide à la réduction des coûts.
Compromis Coût-Qualité : La stratégie PromptOpt a réussi à sélectionner des plans de réécriture à moindre coût qui maintenaient une qualité compétitive pour certaines tâches, démontant la faisabilité d'une planification de prompt sensible au coût. Cependant, l'estimateur heuristique de qualité a montré des limites, ne parvenant pas toujours à sélectionner des plans suffisamment riches pour les tâches complexes de sortie structurée.

Signification et Revendications
L'article affirme que traiter les prompts comme des valeurs typées et visibles par la base de données crée un nouvel espace d'optimisation analogue à l'optimisation de requêtes traditionnelle. En apportant la pensée de l'optimiseur de requêtes aux prompts, PromptDB permet au SGBD de :

Améliorer la Validité : Utiliser les contraintes de schéma pour empêcher les sorties invalides du LLM.
Réduire les Coûts : Utiliser la projection et l'élagage du contexte pour minimiser l'usage des tokens.
Accroître la Qualité : Utiliser des exemples sélectionnés par la base de données et une réécriture sensible à la tâche pour améliorer les performances, notamment pour les modèles plus petits.

Les auteurs positionnent PromptDB comme une approche complémentaire aux cadres d'ingénierie de prompt existants (comme DSPy) et aux opérateurs sémantiques (comme LOTUS ou EVAPORATE). Alors que d'autres traitent les prompts comme des chaînes éphémères ou des paramètres d'opérateurs, PromptDB se concentre spécifかment sur la manière dont les métadonnées de la base de données (schéma, contraintes, statistiques) peuvent réécrire systématiquement les modèles de prompts. L'article conclut que cette approche déplace l'ingénierie de prompt d'une logique applicative ad hoc vers un processus systématiquement géré par la base de données, ouvrant de nouvelles voies pour la recherche sur les bases de données natives de l'IA.

Le langage secret des bases de données et des robots

La grande idée du papier : Le prompt comme donnée

L'éditeur magique : PromptOpt

Ce qu'ils ont découvert

Ce que cela signifie (et ce que cela ne signifie pas)

Articles similaires