Replies: 1 comment 5 replies
|
Ho testato Constraints del dataflow
La distinzione tra Sul problema di discoveryIl gap che descrivi (il nome ufficiale non contiene "stradali") e' strutturale e difficile da risolvere solo con semantic search, perche' il naming ISTAT e' spesso interno e non orientato all'utente. Una via alternativa - o complementare - e' un registry curato di dataflow testati, indicizzati per tema e granularita' territoriale. Qualcosa tipo: - id: 41_983_DF_DCIS_INCIDMORFER_COM_1
tema: incidenti stradali
granularita: comune
dimensioni: 4 filtrabili
performance: stabile
note: unico dataflow con dati comunali; 41_269 e 41_270 sono regionali e lentiNon sostituisce la discovery semantica, ma per i casi d'uso piu' comuni (i dataflow "giusti" per una categoria) riduce il rischio di surfacciare dataflow sbagliati o inutilizzabili. E puo' anche alimentare una blacklist per i dataflow noti come lenti. |
|
@Gabrymi93 Peccato, che costruiate strumenti nuovi, e non si lavori insieme su questo :) Grazie per gli spunti |
|
@aborruso Hai ragione sullo spirito, ma per onesta': il nostro MCP ISTAT lo avevamo costruito prima di scoprire il tuo - lo abbiamo visto solo ieri sera. Quindi non e' stata una scelta di non collaborare, e' che non sapevamo che esistesse. Detto questo, ora che ci siamo incrociati, la domanda e' valida. Dove potremmo contribuire concretamente:
Se c'e' un punto di partenza concreto, siamo disponibili. |
|
@Gabrymi93 hai scritto "un MCP ISTAT locale che abbiamo costruito ispirandoci proprio a questo progetto", non "anche noi abbiamo creato un MCP simile a questo" Detto questo, mi pare che sia tutto già concreto. O sbaglio? La #35 è già pronta, ma prima di fare il merge la vogliamo testare un altro po'. Perché non fai il pull e poi E mi piace l'idea di dataflow testati, e quando vuoi/puoi, puoi fare una PR. Rimango in ascolto tuo e di @patrunomeister, che è l'autore di questo server e esperto di dati Istat e SDMX. Grazie |
|
Hai nuovamente ragione :) Sul resto: concreto, si. Facciamo il pull di feat/compact-constraints-search e testiamo. Per il registry apriremo una PR quando abbiamo qualcosa di solido. E su #1 aggiungiamo la nostra prospettiva. |
|
Devo iniziare a parlare anche io al plurale 🤪 |
Uh oh!
There was an error while loading. Please reload this page.
La query originale
Query dell'utente: "Quanti incidenti stradali mortali nei comuni di Palermo e Matera"
Sembra una domanda semplice. Ma il percorso per risponderla ha rivelato una serie di problemi a cascata che vale la pena analizzare e discutere.
Il dataflow selezionato (sbagliato)
Il tool
discover_dataflowscon keywordincidenti stradaliha restituito:41_269_DF_DCIS_INCIDENTISTR1_1— Incidenti stradali con lesioni alle persone41_270_DF_DCIS_MORTIFERITISTR1_1— Morti e feriti in incidenti stradaliSembrano quelli giusti. Ma non lo sono, per due motivi:
I problemi a cascata
1.
get_constraints→ timeout dopo 180sLa chiamata
get_constraints(41_269_DF_DCIS_INCIDENTISTR1_1)non ha mai risposto. Stessa cosa per41_270. Il server ISTAT sembra non reggere la query sui constraint per questi dataflow specifici.2.
get_data→ timeout anche con curl direttoTentando di bypassare l'MCP con
curldiretto:curl "https://esploradati.istat.it/SDMXWS/rest/data/IT1,41_269_DF_DCIS_INCIDENTISTR1_1,1.0/A.IT.ROADACC.9.9.9.1.99.9.99/"Timeout a 30s, poi a 60s, poi a 180s. Il dataflow è inutilizzabile via REST API, probabilmente per problemi infrastrutturali lato ISTAT.
3. Impossibile verificare i codici validi
Senza
get_constraintsfunzionante, non si sapevano i codici esatti da usare per le 10 dimensioni. Alcune query con valori errati restituivanoError executing generated SQL and populating SDMX model— errore server-side.4. Il dataflow corretto non emergeva dalla ricerca
Il dataflow giusto è
41_983_DF_DCIS_INCIDMORFER_COM_1— "Incidenti, morti e feriti - comuni".Perché non veniva trovato? Il nome non contiene la parola "stradali". La ricerca per similarità testuale con
incidenti stradalinon lo intercettava.Il dataflow corretto
41_983_DF_DCIS_INCIDMORFER_COM_1— Incidenti, morti e feriti - comuniQuery funzionante:
{ "id_dataflow": "41_983_DF_DCIS_INCIDMORFER_COM_1", "dimension_filters": { "FREQ": ["A"], "REF_AREA": ["082053", "077014"], "DATA_TYPE": ["KILLINJ"], "RESULT": ["M"] } }Risultato — morti in incidenti stradali:
La causa principale: assenza di ricerca semantica
Il meccanismo attuale di
discover_dataflowsusa corrispondenza testuale/vettoriale sui nomi dei dataflow. Il problema è che:Una ricerca semantica più robusta potrebbe risolvere il problema, ad esempio:
Un'occasione per approfondire
Questo caso è un ottimo banco di prova per discutere:
discover_dataflowsper gestire il gap tra linguaggio naturale dell'utente e nomenclatura ISTATget_constraintsva in timeout, provare con una chiave parziale suget_dataIl tutto con l'obiettivo di rendere il server MCP affidabile anche per domande geograficamente specifiche, che sono probabilmente le più frequenti tra gli utenti.
Aperto a idee, test, contributi.
All reactions