EvoOntology: il quaderno che l’agente dei dati consulta, e che si corregge da solo

Il primo giorno in un ufficio amministrativo nessuno ti dà il manuale del database. Ti danno l’accesso, e da lì in avanti scopri da solo che i «ricavi» stanno in una tabella che si chiama fact_rev, che vanno contati senza gli ordini annullati, che i costi del personale sono in euro ma quelli delle spedizioni in dollari. Dopo qualche mese hai un quaderno: dove sta cosa, cosa vuol dire, quali trappole evitare. Il collega che arriva dopo di te, se è fortunato, eredita il quaderno. Se no ricomincia da capo.

Gli agenti che lavorano sui dati sono quasi sempre il collega sfortunato. È il punto di partenza di EvoOntology: A Self-Evolving Ontology Layer for Data Agents, uscito su arXiv il 14 settembre 2026 (2609.15779) e in questi giorni fra i paper in tendenza su Papers with Code. Lo firmano Meiduo Chong, Shaolei Zhang, Ju Fan e Xiaoyong Du, della Renmin University of China; il codice è pubblico su GitHub.

Il divario fra l’agente e i dati

Un data agent riceve una domanda in linguaggio naturale, «perché il mese scorso sono saliti i costi?», e deve rispondere andando a guardare tabelle, file CSV, database, documenti. Ma i dati stanno fuori da lui, e li vede solo attraverso strumenti generici: un’interfaccia SQL, un lettore di file. Non sa in anticipo né come sono strutturati né che cosa contengono. Così esplora alla cieca: lancia query di prova, indovina dove potrebbe stare il concetto richiesto, apre contenuti che non servono. Gli autori chiamano questo scarto l’agent–data gap.

Le soluzioni esistenti sono due, e secondo il paper nessuna delle due scala. La prima lascia l’agente libero di esplorare lo schema grezzo: va bene su un database piccolo, su uno largo e disomogeneo l’agente si impantana in giri ripetitivi. La seconda è il semantic layer, una descrizione di entità, metriche e altre regole di dominio, di solito scritta e mantenuta a mano, il genere di cosa che nelle aziende si fa con strumenti come quello di dbt, da incollare nel prompt. Ma un semantic layer completo non entra nel contesto di un modello quando i dati sono tanti, costa fatica mantenerlo, e soprattutto è statico: non sa niente di come l’agente lo usa davvero. E quello che un agente scopre durante un compito, di solito, va perso alla fine del compito.

Un’ontologia da interrogare, non da leggere

La proposta di EvoOntology è trasformare il quaderno in un servizio. L’ontologia vive dentro un server MCP e ha tre strati. Lo strato dei contenuti è un grafo con quattro tipi di nodi: i termini (i concetti di dominio, come «ricavi» o «canale di vendita»), le mappature che li legano a colonne e percorsi di join concreti, i vincoli che ne regolano l’uso («il profitto è ricavi meno costi», «i ricavi escludono gli ordini annullati») e le evidenze, cioè le osservazioni sui dati che giustificano ogni affermazione. Lo strato dello schema definisce quali campi hanno questi nodi e quali relazioni sono ammesse. Lo strato degli strumenti li espone all’agente con due funzioni: browse, che data una domanda restituisce i termini più pertinenti, e resolve, che dato un termine restituisce mappature, relazioni, vincoli ed evidenze collegati.

Nel prompt entra solo un breve manifesto iniziale con le fonti e le istruzioni d’uso. Tutto il resto l’agente lo chiede quando gli serve, un passo alla volta.

Chi scrive il quaderno, e chi lo corregge

A scriverlo è un agente costruttore. Guarda le domande dell’insieme di addestramento, senza vedere le risposte giuste, e ne estrae i concetti ricorrenti: entità, metriche, operazioni. Per ognuno lancia query di sonda sui dati veri e tiene solo i candidati che la sonda conferma, con tipi, filtri e distribuzioni di valori coerenti con quanto dichiarato. I risultati delle sonde restano nell’ontologia come evidenze. È un dettaglio che, vedremo, pesa.

A correggerlo è un agente di evoluzione, che legge le traiettorie passate dell’agente dei dati. Le esecuzioni riuscite mostrano che cosa funziona, quelle fallite mostrano elementi mancanti, fuorvianti o esposti male. Il ciclo ha quattro passi: raggruppare i fallimenti in schemi ricorrenti, attribuire ognuno a uno solo dei tre strati, proporre una modifica circoscritta a quello strato, e poi farla passare da un cancello. Se $\phi(L, V; m)$ è il punteggio dell’ontologia $L$ sull’insieme di validazione $V$ con il modello $m$, la nuova versione sostituisce la vecchia solo se

$$\phi(L’_t, V; m) – \phi(L_t, V; m) \ge \tau,$$

con stesse impostazioni di decodifica e stesso budget di interazioni per i due confronti. Altrimenti si resta alla versione precedente, e il tentativo scartato viene registrato perché non si ripeta. Ogni modello linguistico fa evolvere la propria copia, partendo dalla stessa ontologia iniziale.

Il caso di studio del paper rende l’idea. In un database di carte da gioco, l’ontologia iniziale sa che esistono le carte e che ognuna ha uno stato di legalità, ma non dice che per trovare le carte bandite serve status = 'Banned' insieme al formato di gioco richiesto. La correzione aggiunge un termine, la sua mappatura, l’evidenza sulla distribuzione dei valori e un vincolo. Nient’altro viene toccato.

I numeri

Il protocollo è pulito: ogni benchmark è diviso in due parti disgiunte; su una si costruisce e si fa evolvere l’ontologia (70% per costruire, 30% per il cancello), sull’altra la si prova congelata, poi si scambiano i ruoli e si fa la media. I confronti sono con un agente ReAct senza ontologia e con lo stesso agente a cui l’ontologia iniziale del costruttore viene incollata nel prompt come semantic layer statico. I modelli sono sei: GPT-5.5, GPT-5.6-sol, Claude-Sonnet-5, Claude-Opus-4.8, DeepSeek-V4-Flash e Qwen3.5-Flash.

Il guadagno cambia molto da un benchmark all’altro. Su DDR-Bench, ricerca aperta su bilanci aziendali 10-K, si misura l’accuratezza sull’intera traiettoria; su BIRD, il classico text-to-SQL, l’accuratezza di esecuzione, nella configurazione ufficiale in cui il benchmark fornisce già la conoscenza di dominio (Oracle Knowledge); su InsightBench si tratta di analisi di business su CSV.

Su DDR-Bench la media tiene insieme una forbice larga, da +4,8 su Qwen3.5-Flash a +26,7 su GPT-5.5, che passa da 64,2 a 90,9. Su InsightBench, su tre dei quattro modelli più forti, il guadagno resta sotto il punto. Gli autori lo attribuiscono alla saturazione di una metrica che premia risposte brevi aderenti al riferimento.

Il confronto più istruttivo è con il semantic layer statico. Incollare l’ontologia nel prompt aiuta poco e in modo incostante, e a volte peggiora: su DDR-Bench Claude-Sonnet-5 perde 15 punti, su BIRD GPT-5.5 ne perde 5,6. Servita invece con gli strumenti, la stessa ontologia iniziale alza già il punteggio prima di qualsiasi evoluzione; il resto lo aggiunge l’evoluzione. Il contenuto di partenza è lo stesso, cambia il modo di accedervi. Una memoria delle traiettorie passate, recuperata e messa nel prompt, fa meno.

Le ablazioni, su DDR-Bench, dicono dove sta il peso. Togliere il cancello costa 11,2 punti: le modifiche non filtrate introducono regressioni che il giro successivo non sempre ripara. Togliere l’attribuzione ne costa 6,3. Fra i componenti dell’ontologia, le mappature valgono 13,4 punti e le evidenze 8,7: sono gli ancoraggi ai dati veri, non le descrizioni in linguaggio naturale. E il 57% del guadagno accumulato dall’evoluzione viene da modifiche allo strato degli strumenti, cioè a come l’ontologia si presenta all’agente, più che a che cosa contiene.

C’è infine il costo, misurato su DDR-Bench. Il manifesto e le risposte degli strumenti portano i token in ingresso per turno da 3.200 a 4.600, ma i turni per compito scendono da 14,6 a 8,4, e il totale per compito cala del 20% circa, da 52.600 a 42.000 token. I termini dell’ontologia, misurati con GPT-5.6-sol, passano da 61 a 80 in cinque giri; dopo il terzo ogni voce cresce meno del 5% a giro.

Che cosa non dice

L’ontologia è cucita addosso a un modello. Gli autori lo presentano come un pregio, e in parte lo è, ma vale la pena dirlo per intero. Servita a un modello diverso da quello su cui è evoluta, l’ontologia rende meno: fra 6,6 e 10,9 punti in media secondo il testo, fra 8,8 e 14,5 se si rifà il conto sulla matrice pubblicata nella stessa figura. Su Claude-Sonnet-5 due delle tre ontologie prese in prestito finiscono sotto l’agente senza ontologia; sugli altri tre modelli restano sopra. L’indice di sovrapposizione (Jaccard) fra i termini accettati da due modelli non supera 0,62. Chi cambia modello, per riavere tutto il guadagno, deve rifare l’evoluzione.

Il costo dell’evoluzione non è riportato. Il paper misura i token spesi dall’agente in servizio, non quelli spesi per costruire l’ontologia, rigiocare le traiettorie e valutare ogni candidato contro la versione precedente sulla validazione. Manca anche il valore della soglia $\tau$, e mancano ripetizioni con semi diversi o intervalli di confidenza: su InsightBench, con guadagni sotto il punto, farebbero la differenza.

Il semantic layer battuto è quello costruito dall’agente, incollato nel prompt, non un semantic layer curato da un team di dati come se ne trovano in azienda. Il confronto dice che interrogare è meglio che incollare; non dice che un’ontologia generata batta una scritta da chi conosce i dati.

Il testo ha qualche incoerenza, oltre a quella sul trasferimento. L’abstract parla di quattro modelli, gli esperimenti ne usano sei; le ablazioni e le analisi di costo e di trasferimento sono condotte su quattro, i più forti, e solo su DDR-Bench, dove i guadagni sono più ampi. E di DDR-Bench viene usato un solo scenario, quello dei bilanci 10-K.

Perché conta adesso

Buona parte del lavoro sugli agenti di questi mesi riguarda il modo di mettere a loro disposizione la conoscenza: skill, memorie, server MCP. EvoOntology porta un risultato semplice, con il codice pubblico, in un dominio dove gli errori si pagano, quello dei numeri aziendali: la stessa conoscenza rende di più se l’agente la chiede quando serve invece di trovarsela tutta davanti, e una correzione dovrebbe entrare solo se si può dimostrare che migliora qualcosa. Il quaderno del collega esperto, in altre parole, serve se lo si può sfogliare, e va aggiornato con giudizio. Resta da vedere quanto regge fuori dai benchmark, su dati che cambiano ogni settimana e con un modello che, prima o poi, si cambia.