💻 computer science

Declarative Data Services: Structured Agentic Discovery for Composing Data Systems

Questo articolo introduce i Servizi Dati Dichiarativi (DDS), un'architettura strutturata che supera i fallimenti di convergenza della scoperta agenziale illimitata nei sistemi dati eterogenei decomponendo lo spazio di ricerca in livelli limitati e tipizzati guidati dall'intento dichiarativo dell'utente e dal feedback iterativo di runtime.

Autori originali: Shanshan Ye, Duo Lu

Pubblicato 2026-05-21

📖 6 min di lettura🧠 Approfondimento

CC BY 4.0

Autori originali: Shanshan Ye, Duo Lu

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 Grande Problema: Il "Far West" della Programmazione AI

Immagina di chiedere a un architetto molto intelligente e ben informato (un agente AI) di costruire una casa. Dici: "Voglio una casa con 3 camere da letto, un tetto solare, una piscina e un budget di 300.000 dollari".

In passato, se chiedevi a un'AI di scrivere il codice per una singola applicazione, solitamente faceva un ottimo lavoro. Ma quando le chiedi di costruire un sistema dati complesso (come una piattaforma di trading che deve gestire migliaia di scambi azionari al secondo, conservare anni di cronologia e rimanere veloce), le cose vanno storte.

Perché? Perché l'AI è come un genio che ha letto ogni libro della biblioteca ma non ha mai effettivamente costruito una casa. Sa cosa sono una coda "Kafka" o un database "ClickHouse", ma non sa come si integrano nel mondo reale. Potrebbe scegliere i materiali sbagliati, dimenticare di collegare i tubi o scegliere un progetto che crolla sotto pressione.

Se dici semplicemente all'AI: "Ripristinalo", e le permetti di indovinare ancora e ancora (un processo chiamato "scoperta illimitata"), spesso gira a vuoto. Cerca di riparare l'impianto idraulico cambiando il tetto, o continua a ricostruire l'intera casa da zero ogni volta che commette un piccolo errore. Non converge mai su una soluzione funzionante.

La Soluzione: DDS (L'"Architetto Strutturato")

Gli autori propongono un nuovo sistema chiamato Declarative Data Services (DDS). Invece di lasciare che l'AI vaghi senza meta, DDS agisce come un rigido e organizzato direttore dei lavori che costringe l'AI a seguire una specifica pianta in quattro fasi.

Pensa a DDS come a un edificio di quattro piani dove ogni piano ha un compito specifico e un insieme specifico di regole. L'AI (il "sotto-agente") esegue il lavoro, ma il Framework (il "manager") detiene i progetti e controlla il lavoro ad ogni passaggio.

I Quattro Piani dell'Edificio DDS

Piano 1: Il "Cosa" (Intenzione)

Il Compito: Prima di costruire, devi definire esattamente cosa vuoi.
L'Analogia: Invece di dire "Voglio una casa figa", l'utente dice: "Ho bisogno di 3 camere da letto, 2 bagni, pannelli solari e un budget di 300k".
La Magia: Il sistema costringe l'AI a tradurre il tuo desiderio vago in un elenco di controllo rigoroso e tipizzato (Modello Dati, Velocità, Costo, ecc.). Se la richiesta è impossibile (es. "Voglio una villa per 500 dollari"), il sistema ti ferma prima che venga scritto qualsiasi codice.

Piano 2: Il "Come" (Il Progetto)

Il Compito: Progettare il flusso dei dati senza ancora scegliere marchi specifici.
L'Analogia: L'architetto disegna un diagramma: "L'acqua entra, va al filtro, poi al serbatoio, poi alla doccia". Non dicono ancora "Useremo un filtro Whirlpool". Decidono solo la forma del sistema.
La Magia: Questo separa il progetto dai prodotti. Se il progetto è sbagliato, correggi il disegno, non il marchio specifico dei tubi. Questo impedisce all'AI di cambiare l'intera casa solo perché un tubo ha perso acqua.

Piano 3: Il "Quale" (Le Competenze)

Il Compito: Scegliere i prodotti e le configurazioni effettive.
L'Analogia: Ora l'architetto sceglie gli oggetti specifici: "Useremo un filtro Whirlpool e tubi in PVC". Ma ecco il segreto: il sistema utilizza un "Libro delle Competenze" (una memoria persistente).
La Magia: Questo Libro delle Competenze è come un manuale vivente. Se una casa precedente ha avuto un problema perché il filtro Whirlpool richiedeva un adattatore specifico, quel fatto viene scritto nel Libro delle Competenze. La prossima volta che l'AI costruisce una casa, legge il Libro delle Competenze e sa esattamente quale adattatore usare. Non deve "indovinare" o "ri-imparare" quell'errore.

Piano 4: Il "Controllo" (Attribuzione a Runtime)

Il Compito: Costruiscilo, accendilo e vedi cosa si rompe.
L'Analogia: Accendi l'acqua. Se la doccia perde, il sistema non dice semplicemente "La casa è rotta". Dice: "La perdita è nel collegamento del tubo PVC (Piano 3)".
La Magia: Questa è la parte più importante. Quando il sistema fallisce, traccia l'errore fino al piano esatto in cui è stata presa la decisione.
- Se il budget è troppo basso, torna al Piano 1.
- Se il progetto è impossibile, torna al Piano 2.
- Se la scelta del prodotto specifico era sbagliata, aggiorna il Libro delle Competenze al Piano 3.
- Non fa indovinare all'AI l'intera casa di nuovo. Esegue una piccola correzione mirata.

Perché Funziona (Il Momento "Eureka!")

Il documento ha testato questo approccio contro agenti AI "illimitati" (quelli che semplicemente indovinano e riprovano).

L'Agente Illimitato: Come uno studente che cerca di risolvere un problema matematico scrivendo numeri a caso finché non indovina. Ci vuole molto tempo, costa molto denaro (potenza di calcolo) e spesso si arrende.
L'Agente DDS: Come uno studente che usa un libro di testo e una calcolatrice. Se sbaglia un passaggio, il libro di testo gli dice esattamente quale regola ha violato. Corregge quella singola regola e procede.

I Risultati:
In un test per costruire un backend di trading:

Agenti Illimitati: Non sono riusciti a costruire un sistema funzionante 8 volte su 10, anche dopo molti tentativi. Si sono bloccati in loop.
DDS: Ha costruito un sistema funzionante 10 volte su 10. È stato più veloce, più economico e il sistema ha effettivamente funzionato con dati reali.

L'Analogia del "Libro delle Competenze"

Il documento sottolinea che la conoscenza ha bisogno di una casa.

Nei vecchi metodi AI, se l'AI imparava che "Kafka ha bisogno della porta 9092", potrebbe dimenticarlo domani. Deve reimpararlo ogni volta.
In DDS, quella conoscenza viene salvata in un File delle Competenze (come un file YAML).
Se l'AI commette un errore (es. "Ho dimenticato di aprire la porta 9092"), il sistema corregge il File delle Competenze.
Crucialmente: La prossima volta che l'AI costruisce un sistema, legge il File delle Competenze corretto. L'errore non viene più commesso. La "correzione" è permanente, non solo una patch temporanea.

Riepilogo

Il documento sostiene che per costruire sistemi dati complessi con l'AI, non possiamo semplicemente lasciare che l'AI "improvvisi". Abbiamo bisogno di un framework strutturato che:

Scomponga il problema in passaggi chiari e tipizzati (Intenzione -> Progetto -> Prodotto -> Codice).
Costringa l'AI a controllare il proprio lavoro ad ogni passaggio prima di procedere.
Ricordi gli errori in un permanente "Libro delle Competenze" in modo che non vengano ripetuti.
Individui esattamente gli errori in modo che l'AI non debba indovinare cosa correggere.

Trasforma il processo caotico del "tentativo ed errore dell'AI" in una linea di assemblaggio industriale affidabile per la creazione di software.

Riepilogo Tecnico: Servizi di Dati Dichiarativi (DDS)

Enunciato del Problema

Il documento affronta la sfida della scoperta agenziale per backend di dati multi-sistema. Sebbene gli agenti guidati da Large Language Model (LLM) abbiano dimostrato successo nella scoperta di nuovi algoritmi o nell'ottimizzazione di configurazioni di singoli sistemi (ad esempio, database auto-gestiti), incontrano difficoltà quando si tratta di comporre stack di dati eterogenei (ad esempio, combinando code, archivi OLAP/OLTP, cache e connettori) partendo dall'intento dell'utente espresso in linguaggio naturale.

Le difficoltà principali identificate sono:

Spazio di Ricerca Eterogeneo: Lo spazio delle soluzioni abbraccia sistemi distinti con dialetti, connettori e peculiarità operative differenti.
Complessità di Verifica: Il "verificatore" non è una chiave di risposta di un benchmark, ma il fatto che uno stack distribuito funzioni effettivamente e soddisfi gli Obiettivi di Livello di Servizio (SLO).
Cattura Disomogenea della Conoscenza: La conoscenza sulla composizione (cosa funziona insieme, quali anti-pattern evitare) è scarsa nei dati di pre-addestramento e cambia con ogni ciclo di rilascio.
Fallimento della Scoperta Illimitata: Gli agenti di codifica iterativi che si basano sul feedback dei log di errore (scoperta illimitata) non riescono a convergere in modo coerente. Spesso regrediscono livelli precedenti di successo riscrivendo l'architettura in risposta a errori a valle o rimangono intrappolati in cicli di ipotesi sulle cause radice senza tracciare i segnali a specifici livelli decisionali.

Metodologia: Il Framework DDS

Gli autori propongono i Servizi di Dati Dichiarativi (DDS), un'architettura strutturata di scoperta agenziale che scompone il problema di ricerca globale in quattro sotto-ricerche delimitate e tipizzate. Il framework impone una separazione rigorosa tra Framework (che possiede i contratti e la validazione) e Sub-Agenti (che eseguono la ricerca delimitata all'interno di tali contratti).

L'architettura è composta da quattro livelli (L1–L4), ciascuno con un contratto tipizzato:

L1: Contratto di Intento:
- Obiettivo: Tradurre un linguaggio naturale ambiguo in una dichiarazione tipizzata e validata.
- Meccanismo: Un sub-agente elicita una bozza di intento, che il framework valida contro uno schema a sei dimensioni: modello di dati, pattern di accesso, scala, latenza, consistenza e costo.
- Vincolo: Il framework rifiuta input malformati prima di qualsiasi generazione di codice.
L2: DAG di Operatori Logici:
- Obiettivo: Determinare la topologia (il "cosa" e il "come" del flusso di dati) indipendentemente dai prodotti specifici.
- Meccanismo: Il framework definisce un grafo di operatori tipizzati (ad esempio, INGEST → QUEUE → TRANSFORM → STORE).
- Vincolo: Il framework impone la raggiungibilità (ogni ingestione deve raggiungere ogni servizio) e compone le garanzie degli archi in SLO end-to-end. Se una topologia non può soddisfare il budget o gli SLO di L1, viene rifiutata prima della selezione del prodotto.
L3: Contratto di Competenza Fisica:
- Obiettivo: Selezionare prodotti e configurazioni specifici che si adattino al DAG.
- Meccanismo: Questo livello utilizza Competenze Agente, che sono artefatti strutturati, persistenti e modificabili (YAML) per sistema. Ogni competenza contiene quattro blocchi: capacità, composizioni, anti_pattern e operativi.
- Vincolo: Il framework valida i candidati contro gli anti-pattern definiti dalla competenza (ad esempio, intervalli di versione proibiti, accoppiamenti di operatori incompatibili). Crucialmente, la conoscenza sulla composizione è archiviata qui come un artefatto riutilizzabile e non come contesto transitorio del prompt.
L4: Ciclo di Attribuzione Runtime:
- Obiettivo: Distribuire lo stack e instradare i fallimenti runtime al livello corretto.
- Meccanismo: In caso di fallimento della distribuzione, il framework classifica il segnale (ad esempio, fallimento del pull dell'immagine, conflitto di porta, ritardo del consumatore) e lo instrada al livello che possiede la decisione violata.
- Vincolo:
  - Gli errori L4 (problemi transitori di generazione codice/host) vengono corretti automaticamente dal framework.
  - Gli errori L3 (competenze mancanti/anti-pattern) risultano in patch delle competenze che vengono modificate nell'artefatto della competenza, persistendo per le distribuzioni future.
  - Gli errori L1/L2 (mismatch di intento o topologia) vengono esposti all'utente per revisione, poiché il framework non può rivedere automaticamente questi confini contrattuali.

Contributi Chiave

Architettura Strutturata per la Scoperta Multi-Sistema: Una separazione framework/agente con quattro contratti tipizzati (L1–L4) che scompone la ricerca globale in sotto-ricerche delimitate, governata da regole di proprietà in cui il framework valida i contratti e gli agenti cercano all'interno di essi.
Scoperta Strutturata vs. Illimitata: Due innovazioni architetturali:
- Attribuzione Tipizzata: Instradare ogni segnale runtime al livello specifico che possiede la decisione violata, prevenendo la regressione della ricerca globale.
- Memoria delle Competenze Persistente: Archiviare la conoscenza sulla composizione in artefatti di competenza modificabili e citabili (L3) invece che nei prompt, permettendo alle correzioni di accumularsi e persistere tra le distribuzioni.
Validazione Empirica (Backend di Trading): Uno studio di caso che dimostra come DDS converga verso uno stack funzionante laddove la scoperta illimitata fallisce, con i fallimenti runtime che diventano patch delle competenze migliorando le iterazioni successive.

Risultati

Il documento valuta DDS rispetto a baseline di scoperta agenziale illimitata (Condizioni A, B, C) utilizzando un carico di lavoro di backend di trading (50K tick/sec, ricerche sotto i 10ms, budget di 300$/mese) e lo stesso LLM sottostante (Claude Opus 4.6).

Convergenza:
- Baseline Illimitate: Anche con 5 iterazioni e nomi di sistema espliciti o contenuto di competenze incollati come prosa, gli agenti illimitati non sono riusciti a raggiungere uno stato funzionante (T1/T2) in modo coerente. La Condizione A (solo NL) ha raggiunto T1 in 2/10 esecuzioni; la Condizione C (NL + prosa delle competenze) ha raggiunto T1 in 6/10 esecuzioni.
- DDS: Con lo stesso ciclo di 5 iterazioni, DDS ha raggiunto T1 e T2 in 10/10 esecuzioni.
Efficienza:
- DDS ha richiesto una mediana di 44 turni e 1,94$ per convergere.
- Le baseline illimitate hanno richiesto significativamente più turni (mediana 209–268) e costi (5,06 $–6,23$ ), spesso esaurendo le iterazioni senza convergenza.
Studio di Ablazione: La rimozione dei blocchi operational e anti_patterns dagli artefatti delle competenze ha fatto crollare il tasso di successo a 0/3, dimostrando che la conoscenza operativa specifica (ad esempio, immagini raccomandate, conflitti di porta) è critica e non ridondante con il pre-addestramento.
Accuratezza dell'Attribuzione: In un esperimento controllato di iniezione di guasti (20 istanze), il ciclo di attribuzione L4 ha instradato correttamente i segnali al livello proprietario il 100% delle volte.
Ciclo di Apprendimento: In uno scenario reale di fallimento, quattro distinti fallimenti runtime sono stati attribuiti a lacune nelle competenze L3. Il framework ha applicato patch solo sulle competenze (nessuna modifica al codice), e la seconda distribuzione ha corretto 4/4 fallimenti con citazioni inline dei campi modificati.

Significato e Affermazioni

Il documento posiziona DDS come un prototipo iniziale che riporta lezioni dalla composizione di sistemi di dati nel mondo reale. Il suo significato risiede nel dimostrare che la struttura, non solo l'iterazione o il volume di conoscenza, è la chiave per una scoperta agenziale affidabile per sistemi complessi.

Il "Vittoria" è la Struttura: Gli autori affermano che il "canale tipizzato" (la superficie contrattuale) è ciò che trasforma l'iterazione in una modifica delimitata al livello. Gli agenti illimitati falliscono perché mancano di un meccanismo per tracciare i sintomi alle decisioni della causa radice; DDS risolve questo problema costringendo i fallimenti a ricadere su livelli specifici.
Conoscenza Persistente: Il documento sostiene che la conoscenza sulla composizione deve essere un "artefatto di prima classe e persistente" (la competenza) piuttosto che un contesto transitorio. Ciò permette al sistema di imparare dai fallimenti e applicare queste lezioni alle distribuzioni future senza doverle riscoprire.
Portata Modesta: Gli autori dichiarano esplicitamente che il prototipo gira su Docker Compose locale ed è una "prova di vita", non un sistema di produzione. Riconoscono problemi aperti come la fiducia nell'attribuzione per segnali ambigui (ad esempio, ritardo del consumatore), la deriva dell'intento e la necessità di un livello valutatore L5 per verificare gli SLO sotto carico sostenuto. Il lavoro non afferma di risolvere tutti i problemi di ingegneria dei dati, ma offre un pattern architetturale specifico per colmare il divario tra intento dell'utente e distribuzione multi-sistema.