💻 computer science

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

Questo articolo introduce PromptDB, un sistema di database che tratta i prompt come tipi di dati a livello di tupla di prima classe per consentire la gestione, l'ottimizzazione e la riscrittura in-database delle interazioni con i Large Language Model, migliorando così la validità dell'output e i compromessi tra costo e qualità rispetto allo storage statico ed esterno dei prompt.

Autori originali: Denis Mayr Lima Martins, Gottfried Vossen

Pubblicato 2026-07-27

📖 7 min di lettura🧠 Approfondimento

CC BY 4.0

Autori originali: Denis Mayr Lima Martins, Gottfried Vossen

Articolo originale sotto licenza CC BY 4.0 (http://creativecommons.org/licenses/by/4.0/). ✨ Questa è una spiegazione generata dall'IA dell'articolo qui sotto. Non è stata scritta né approvata dagli autori. Per precisione tecnica, consulta l'articolo originale. Leggi il disclaimer completo

Il linguaggio segreto dei database e dei robot

Immaginate di avere una biblioteca gigantesca e super organizzata (un database) che contiene milioni di fatti, e di avere un robot brillante e chiacchierone (un Large Language Model, o LLM) capace di leggere e comprendere quasi tutto. Di solito, per far sì che il robot svolga un lavoro utilizzando i fatti della biblioteca, un essere umano deve agire da intermediario. Prende un foglio di carta dalla biblioteca, scrive un insieme specifico di istruzioni (un "prompt"), lo invia al robot e attende la risposta. Il problema è che la biblioteca stessa non sa quali istruzioni il robot stia seguendo. È come uno chef che sa esattamente quali ingredienti ci sono in frigorifero, ma non può vedere la ricetta che il cuoco sta usando; lo chef non può aiutare a correggere una cattiva ricetta o suggerire ingredienti migliori perché la ricetta è nascosta in un taccuino sul bancone.

Questo articolo entra nel mondo dell'informatica dove i database e l'intelligenza artificiale si incontrano. Affronta un mal di testa specifico: attualmente, le istruzioni che diamo ai robot AI sono spesso conservate al di fuori del database, in codice disordinato o in taccuini. Questo rende difficile per il database verificare se le istruzioni siano buone, correggerle se sono confuse o renderle più economiche da eseguire. Gli autori propongono un'idea radicale: e se trattassimo queste istruzioni proprio come qualsiasi altro dato, come un nome o un numero, conservato direttamente all'interno delle tabelle del database? Rendendo le istruzioni "visibili" al database, il sistema potrebbe riscriverle automaticamente per renderle più intelligenti, veloci e accurate, usando la propria conoscenza del database per aiutare il robot a svolgere il suo lavoro meglio.

La grande idea del saggio: I prompt come dati

Gli autori, Denis Mayr Lima Martins e Gottfried Vossen, introducono un nuovo sistema chiamato PromptDB. Pensatelo come un database che non si limita a memorizzare fatti, ma memorizza anche le istruzioni su come parlare a un'IA. Nei sistemi tradizionali, se volete che un'IA classifichi un reclamo di un cliente (come "Il mio pacco non è mai arrivato!"), scrivereste un prompt nel codice della vostra applicazione, recuperereste il testo dal database e lo inviereste all'IA. Il database vede solo una stringa di testo; non sa che quel testo è un insieme di istruzioni destinate a essere eseguite.

In PromptDB, il prompt è un cittadino di prima classe. È un tipo di dato speciale chiamato PROMPT. Inve al di là di nascondere le istruzioni in un taccuino, il database le conserva proprio dentro le righe della tabella, insieme ai dati che esse descrivono. Una riga potrebbe apparire così:

ID Ticket: 1001
Messaggio: "Il pacco non è mai arrivato"
Priorità: Alta
Istruzione: PROMPT("Classifica questo ticket: {{body}}", output: [rimborso, consegna, tecnico, altro])

Qui, l'istruzione è un oggetto strutturato. Conosce il template ("Classifica questo ticket..."), sa quale parte della riga inserire (il body) e conosce le risposte valide (la lista output). Poiché il database può "vedere" l'istruzione, può agire come un editor intelligente.

Il Magic Editor: PromptOpt

La vera magia avviene con un componente chiamato PromptOpt. Immaginate di essere un insegnante che valuta il saggio di uno studente. Se lo studente scrive una risposta lunga e confusa, potreste dirgli: "Sii conciso". Se dimentica di elencare i passaggi richiesti, potreste dire: "Aggiungi i passaggi mancanti". PromptOpt fa questo automaticamente per i prompt dell'IA.

Il sistema usa la conoscenza del database stesso per riscrivere le istruzioni prima di inviarle all'IA. Ha alcuni trucchi nel mirino:

Iniezione di Vincoli (Constraint Injection): Se il database sa che le uniche risposte valide sono "rimborso" o "consegna", PromptOpt riscrive il prompt per dire esplicitamente all'IA: "Devi scegliere esattamente una di queste parole". Questo impedisce all'IA di inventare risposte strane come "Il cliente è triste".
Proiezione di Colonne (Column Projection): Se una riga ha 50 colonne di dati ma l'IA ha bisogno di leggere solo la colonna "messaggio", PromptOpt taglia le altre 49. Questo risparmia denaro (meno token da leggere) e riduce la confusione.
Esempi Few-Shot: Il sistema può guardare altre righe nel database, trovare buoni esempi di risposte corrette e inserirli nel prompt per mostrare all'IA esattamente cosa fare.

Il sistema tratta queste riscritture come un ottimizzatore di query. Proprio come un ottimizzatore di database decide il modo più veloce per cercare i dati, PromptOpt decide il modo migliore per scrivere il prompt. Valuta il costo (quante parole l'IA deve leggere/scrivere) rispetto alla qualità (quanto è probabile che la risposta sia corretta). Potrebbe decidere che per un compito semplice un prompt breve è sufficiente, ma per uno complicato vale la pena sostenere il costo extra per aggiungere esempi.

Cosa hanno scoperto

Gli autori hanno testato PromptDB su tre diversi dataset: ticket di supporto finti, un dataset di valutazione automobilistica e un dataset standard del settore chiamato TPC-H. Hanno confrontato tre modi di procedere:

Statico: Il vecchio metodo, in cui il prompt è scritto una volta sola e non viene mai cambiato.
Tutte le Regole (All Rules): Una versione che applica ciecamente ogni possibile regola di riscrittura.
PromptOpt: La versione intelligente che sceglie la migliore riscrittura per ogni specifico compito.

I risultati suggeriscono che trattare i prompt come dati funziona.

Qualità Migliore: Quando il compito richiedeva all'IA di scegliere da una lista specifica di opzioni (come classificare un ticket), la riscrittura guidata dal database rendeva l'IA molto più accurata. L'approccio "All Rules" dava spesso i risultati migliori, ma era costoso.
Il Compromesso: Il sistema PromptOpt è riuscito a trovare un punto di equilibrio. Non sceglieva sempre il prompt più costoso e complesso. Al contrario, sceglieva prompt più semplici che erano "abbastanza buoni" per il compito, risparmiando sui costi computazionali pur ottenendo risultati di alta qualità. Ad esempio, in alcuni test, PromptOpt ha ottenuto una qualità competitiva con significativamente meno token di input rispetto al metodo statico.
Il Compito Conta: Il saggio nota che un modello unico non va bene per tutti. Una riscrittura che aiuta con il "filtraggio semantico" (controllare se una riga corrisponde a una regola) potrebbe non aiutare con la "normalizzazione del valore" (pulire il testo disordinato). Il sistema suggerisce che le versioni future dovranno essere ancora più intelligenti nel sapere quale regola usare per quale compito.

Cosa significa questo (e cosa non significa)

L'articolo sostiene che dovremmo smettere di trattare le istruzioni dell'IA come codice nascosto e immutabile. Rendendole dati visibili, possiamo usare i superpoteri del database — la sua conoscenza dei vincoli, la sua capacità di filtrare i dati e le sue abilità di ottimizzazione — per rendere le interazioni con l'IA più affidabili ed efficienti.

Tuttano, gli autori sono cauti nel non affermare che questo sia un problema perfetto e risolto. Ammettono che il loro attuale sistema utilizza semplici regole "euristiche" (ipotesi educate) per stimare qualità e costo, piuttosto che un modello di IA completamente appreso che sappia esattamente quanto sarà buona una prompt. Suggeriscono che, sebbene il prototipo funzioni bene in simulazioni e su dataset specifici, il "stimatore di qualità" deve diventare più intelligente per gestire perfettamente ogni possibile compito.

In breve, PromptDB suggerisce un futuro in cui il vostro database non è solo un magazzino per i fatti, ma un coach attivo per la vostra IA, riscrivendo le sue istruzioni in tempo reale per garantire che svolga il lavoro nel modo giusto, veloce e senza sprecare risorse. È un passo verso rendere l'IA meno simile a una scatola nera e più una parte naturale del mondo dei dati.

Sintesi Tecnica: Il Prompt come Tipo di Dato: Gestione e Riscrittura dei Prompt In-Database

Problematica
I Large Language Models (LLM) sono sempre più integrati in applicazioni basate su database per compiti quali la classificazione di tuple, il filtraggio semantico, l'estrazione di attributi e l'arricchimento dei risultati. Tuttavia, gli attuali pattern di integrazione soffrono di un fondamentale disconnessione architettonica: i prompt che guidano tali computazioni sono tipicamente conservati al di fuori del Database Management System (DBMS) in formati non strutturati (ad esempio, codice applicativo, notebook o file di configurazione). Di conseguenza, i prompt sono invisibili al DBMS, impedendo al sistema di ispezionarli, riscriverli, spiegarli o ottimizzarli. Sebbene le User-Defined Functions (UDF) basate su SQL permettano l'invocazione di LLM, il prompt rimane un argomento opaco, e il database non può sfruttare i propri metadati (schema, vincoli, statistiche) per migliorare la validità o l'efficienza del prompt. Ciò porta a problemi quali la generazione da parte degli LLM di output che violano i domini o i vincoli del database, e una mancanza di ottimizzazione sistematica per il compromesso costo-qualità dell'esecuzione del prompt.

Metodologia e Design del Sistema
Il documento introduce PromptDB, un sistema di database che eleva i prompt a cittadini di prima classe trattandoli come valori di database a livello di tupla. Ispirandosi al concetto di Stonebraker di "QUEL come Tipo di Dato" e alla programmazione riflessiva, il sistema introduce un tipo di dato logico PROMPT.

Modello dei Dati: Il tipo PROMPT è un oggetto strutturato auto-descrittivo contenente:
- Template ( $T$ ): Una stringa con variabili.
- Binding ( $B$ ): Una mappa che collega le variabili del template agli attributi della tupla.
- Metadati del Modello ( $M$ ): Specifiche del target LLM.
- Metadati del Task ( $D$ ): Il dominio di output o la specifica (ad esempio, etichette valide).
Modello di Esecuzione: I prompt possono risiedere in tabelle base o viste. Quando un utente interroga un attributo con valore PROMPT, il sistema internamente renderizza il prompt rispetto alla tupla, lo riscrive utilizzando il contesto del database ed esegue l'operazione tramite un operatore interno EVAL.
Riscrittura e Ottimizzazione del Prompt: PromptDB tratta l'ingegneria dei prompt come un problema di ottimizzazione del database. Utilizza un contesto derivato dal database ( $\Omega$ $Ω$ ) composto da schema, vincoli, predicati di query e statistiche per riscrivere i prompt.
- Regole di Riscrittura: Il sistema impiega un approccio basato su regole che include:
  - Iniezione di Vincoli ( $R_{CI}$ ): Iniezione di domini di output validi derivati dai vincoli del database.
  - Proiezione di Colonne Consapevole della Query ( $R_{QACP}$ ): Potatura degli attributi della tuola irrilevanti per ridurre i costi di token.
  - Minimizzazione del Formato di Output ( $R_{OFM}$ ): Imposizione di output concisi e facilmente analizzabili.
  - Esempi Few-Shot Selezionati dal DB ( $R_{FSE}$ ): Selezione di esempi rilevanti dal database da includere nel prompt.
- PromptOpt: Un ottimizzatore che seleziona il miglior piano di riscrittura stimando un compromesso costo-qualità ( $\hat{Q} - \lambda\hat{C}$ ), bilanciando la qualità dell'output stimata rispetto ai costi dei token.

Implementazione
Gli autori hanno implementato un prototipo di PromptDB sopra DuckDB.

Il tipo PROMPT è definito come uno STRUCT di DuckDB.
Per gestire l'esecuzione senza modifiche invasive al kernel, il sistema genera viste di valutazione che espongono le colonne dei prompt. Internamente, queste viste si espandono in chiamate EVAL.
L'operatore EVAL è una UDF scalare che deserializza il prompt, applica la strategia di riscrittura selezionata (tramite PromptOpt), renderizza il prompt finale, chiama un LLM (tramite LM Studio) e restituisce il risultato come stringa SQL.
I metadati di esecuzione (strategia, costo, latenza, token) vengono registrati per l'analisi.

Risultati Sperimentali
Il sistema è stato valutato su dataset sintetici e reali (Support Tickets, Car Evaluation, TPC-H) attraverso tre task: Estrazione di Attributi, Filtraggio Semantico e Normalizzazione del Valore Semantico.

Qualità del Task: La riscrittura guidata dal database ha migliorato significativamente la qualità end-to-end rispetto a prompt statici scritti manualmente, particolarmente per i task che richiedono output strutturati o vincolati (ad esempio, l'estrazione di attributi).
Sensibilità delle Regole: Gli studi di ablazione hanno rivelato che nessuna singola regola di riscrittura domina tutti i task; l'efficacia è altamente dipendente dal task. Ad esempio, l'iniezione di vincoli è critica per la classificazione, mentre la proiezione aiuta nella riduzione dei costi.
Compromesso Costo-Qualità: La strategia PromptOpt ha selezionato con successo piani di riscrittura a minor costo che mantenevano una qualità competitiva per certi task, dimostrando la fattibilità di una pianificazione dei prompt consapevole dei costi. Tuttavia, lo stimatore euristico della qualità ha mostrato limitazioni nel selezionare sempre piani sufficientemente ricchi per task complessi con output strutturati.

Significatività e Claim
Il paper sostiene che trattare i prompt come valori tipizzati e visibili al database crei un nuovo spazio di ottimizzazione analogo alla tradizionale ottimizzazione delle query. Portando il pensiero dell'ottimizzatore delle query nei prompt, PromptDB consente al DBMS di:

Migliorare la Validità: Utilizzare i vincoli dello schema per prevenire output LLM non validi.
Ridurre i Costi: Utilizzare la proiezione e la potatura del contesto per minimizzare l'uso dei token.
Aumentare la Qualità: Utilizzare esempi selezionati dal database e riscritture consapevoli del task per migliorare le prestazioni, specialmente per modelli più piccoli.

Gli autori posizionano PromptDB come un approccio complementare agli attuali framework di prompt engineering (come DSPy) e agli operatori semantici (come LOTUS o EVAPORATE). Mentre altri trattano i prompt come stringhe effimere o parametri di operatore, PromptDB si concentra specificamente su come i metadati del database (schema, vincoli, statistiche) possano riscrivere sistematicamente i template dei prompt. Il paper conclude che questo approccio sposta l'ingegneria dei prompt dalla logica applicativa ad hoc a un processo sistematico gestito dal database, aprendo nuove strade per la ricerca sui database AI-native.

Il linguaggio segreto dei database e dei robot

La grande idea del saggio: I prompt come dati

Il Magic Editor: PromptOpt

Cosa hanno scoperto

Cosa significa questo (e cosa non significa)

Articoli simili