-----------------------------------

Acquista i software ArcGIS tramite Studio A&T srl, rivenditore autorizzato dei prodotti Esri.

I migliori software GIS, il miglior supporto tecnico!

I migliori software GIS, il miglior supporto tecnico!
Azienda operante nel settore GIS dal 2001, specializzata nell’utilizzo della tecnologia ArcGIS e aderente ai programmi Esri Italia Business Network ed Esri Partner Network

-----------------------------------



Visualizzazione post con etichetta ArcGIS Pro. Mostra tutti i post
Visualizzazione post con etichetta ArcGIS Pro. Mostra tutti i post

mercoledì 7 ottobre 2026

From Embedding Space to Explanation Space: capire come ragiona la GeoAI con AutoML e SHAP in ArcGIS Pro

Un embedding geospaziale può rappresentare un luogo con centinaia di numeri. Ma se quel vettore entra in un modello predittivo, come possiamo capire quali aspetti del territorio stanno realmente guidando la previsione?

È una delle domande più interessanti della GeoAI moderna, perché riguarda un punto di tensione fondamentale tra representation learning e interpretabilità: più lasciamo che sia il modello a costruire autonomamente rappresentazioni compatte e sofisticate del territorio, più perdiamo la semantica immediata delle tradizionali variabili GIS.

Un recente articolo del team Esri GeoAI, Interpret embeddings using AutoML and SHAP in ArcGIS Pro, pubblicato il 6 ottobre 2026, affronta proprio questo problema combinando quattro tecnologie:

  • USA Geodemographic Embeddings
  • Geodemographic Foundation Model (GDFM)
  • AutoML di ArcGIS Pro
  • SHAP – SHapley Additive exPlanations

Il workflow Esri utilizza come caso di studio la previsione della food insecurity negli Stati Uniti, ma il concetto è molto più generale.

Dietro l'esempio applicativo c'è infatti qualcosa di più importante: un possibile passaggio da un GIS costruito principalmente su feature progettate dall'uomo a un GIS nel quale parte della conoscenza geografica viene rappresentata attraverso latent spaces appresi da foundation model.

Ed è qui che nasce una nuova domanda:

come interpretiamo non soltanto ciò che il modello predice, ma il modo in cui utilizza una rappresentazione appresa del territorio?

1. Dal feature engineering al representation learning geografico

Nel machine learning GIS tradizionale, il processo parte normalmente da variabili esplicite:

Population density
Median household income
Age
Education
Land cover
Distance from roads
Distance from hospitals
House value
Employment rate
Slope
Elevation
...

Ogni feature ha un significato noto.

Possiamo quindi costruire una matrice:

X = [x1, x2, x3, ... xn]

e addestrare un modello:

ŷ = f(X)

Il problema è che un territorio reale può essere descritto da migliaia di variabili correlate tra loro.

La selezione manuale delle feature diventa allora costosa, fragile e fortemente dipendente dal dominio.

Il paradigma degli embedding cambia radicalmente il problema.

Thousands of geographic variables
                |
                v
       Foundation Model
                |
                v
        Latent Embedding
                |
                v
        256 dimensions

Non chiediamo più direttamente:

quali dieci variabili devo scegliere?

Chiediamo invece a un modello di apprendere una rappresentazione compatta capace di preservare strutture, correlazioni e similarità presenti nei dati.

In termini matematici:

z = E(x)

x ∈ R^n
z ∈ R^256

dove E è l'encoder e z è la rappresentazione latente del luogo.

Questo z diventa una sorta di fingerprint geografico.

2. USA Geodemographic Embeddings: circa 5.300 variabili diventano 256 numeri

Gli USA Geodemographic Embeddings di Esri rappresentano ogni area geografica attraverso un vettore denso di 256 dimensioni.

La sorgente non è un singolo dataset ma quattro differenti “view” del territorio.

View Numero di variabili Informazione principale
Housing & Household Characteristics 1.521 Housing units, occupancy, tenure, household composition
Environment 113 Climate, precipitation, land cover e contesto ambientale
American Community Survey 1.617 Income, employment, education, commuting, household structure
Age & Race Census 2.049 Population, age, race e struttura demografica

Complessivamente siamo quindi nell'ordine delle:

1,521
+ 113
+ 1,617
+ 2,049
----------------
≈ 5,300 variables

che vengono compresse in:

256 latent dimensions

È un rapporto di compressione concettualmente molto significativo.

Ma non dobbiamo interpretarlo come una semplice PCA.

Dietro gli embedding si trova il Geodemographic Foundation Model di Esri.

3. Dentro GDFM: un multiview autoencoder geografico

La caratteristica particolarmente interessante del GDFM è l'uso di una architettura multiview autoencoder.

Le quattro sorgenti non vengono semplicemente concatenate in un gigantesco vettore da dare a un singolo encoder.

Concettualmente abbiamo:

Housing & Household
       |
       v
   Encoder H
       |
       +----------> zH ∈ R^64


Environment
       |
       v
   Encoder E
       |
       +----------> zE ∈ R^64


American Community Survey
       |
       v
   Encoder A
       |
       +----------> zA ∈ R^64


Age & Race Census
       |
       v
   Encoder D
       |
       +----------> zD ∈ R^64


z = [zH | zE | zA | zD]

z ∈ R^256

Questa architettura produce una proprietà estremamente utile ai fini dell'interpretabilità:

dimensions   1 -  64 → Housing / Household
dimensions  65 - 128 → Environment
dimensions 129 - 192 → ACS / Socioeconomic
dimensions 193 - 256 → Age / Race / Demographic

Non conosciamo necessariamente il significato semantico della singola dimensione, ma conosciamo la view dalla quale quella parte dello spazio latente è stata appresa.

È una distinzione fondamentale.

4. Perché embedding_137 non significa “income”

Supponiamo che il modello identifichi:

embedding_137

come feature molto importante.

Sarebbe sbagliato concludere:

embedding_137 = income

Una dimensione latente generalmente rappresenta una combinazione non lineare di molte feature originarie.

Potrebbe catturare qualcosa che emerge dall'interazione tra:

income
education
employment
commuting
household composition
urban structure
...

La rappresentazione è distributed.

L'informazione non deve necessariamente trovarsi in una singola coordinata.

Quello che invece possiamo affermare è che la dimensione 137 appartiene al blocco:

129 - 192

e quindi deriva dalla rappresentazione latente costruita dalla view American Community Survey.

È già un'informazione molto potente.

5. Il downstream model: dall'Embedding Space al Prediction Space

Dopo aver costruito il vettore geografico:

z = [z1, z2, ..., z256]

possiamo utilizzarlo come input di un modello supervisionato:

ŷ = f(z)

Nel caso discusso da Esri:

USA Geodemographic Embedding
            |
            v
      256 predictors
            |
            v
        ArcGIS AutoML
            |
            v
     Food insecurity %

Qui avviene una separazione concettuale molto importante.

Il foundation model non sta prevedendo direttamente la food insecurity.

Sta producendo una rappresentazione generale del territorio.

Un secondo modello utilizza successivamente quella rappresentazione per un task specifico.

Abbiamo quindi:

REAL WORLD
    |
    v
Geographic data
    |
    v
GDFM
    |
    v
EMBEDDING SPACE
    |
    v
Downstream ML model
    |
    v
PREDICTION SPACE

6. ArcGIS Pro AutoML

ArcGIS Pro permette di utilizzare queste dimensioni direttamente tramite Train Using AutoML.

AutoML automatizza diverse fasi del processo di modellazione, tra cui, a seconda della modalità utilizzata:

  • exploratory data analysis;
  • model selection;
  • feature selection;
  • feature engineering;
  • cross validation;
  • hyperparameter tuning;
  • model training;
  • evaluation;
  • model packaging.

Il risultato può essere salvato come modello ArcGIS:

.dlpk

e successivamente utilizzato attraverso Predict Using AutoML.

Nel workflow illustrato da Esri viene utilizzato Basic Mode, perché è orientato soprattutto alla comprensione delle variabili e consente di produrre gli output necessari all'analisi dell'importanza.

Tra gli algoritmi utilizzabili troviamo anche modelli tree-based come LightGBM, particolarmente interessanti quando si lavora con embedding tabellari densi.

7. Perché LightGBM è interessante con un embedding

Un embedding a 256 dimensioni produce una matrice:

X ∈ R^(N × 256)

Le relazioni tra coordinate latenti e target possono essere fortemente non lineari.

Una regressione lineare assumerebbe essenzialmente:

ŷ = β0 + β1z1 + β2z2 + ... + β256z256

Un modello gradient boosting può invece apprendere:

  • threshold effects;
  • nonlinearità;
  • interazioni tra dimensioni;
  • relazioni condizionali;
  • combinazioni di feature latenti.

Per esempio:

IF z137 > thresholdA
AND z151 < thresholdB
AND z42 > thresholdC
THEN ...

può identificare configurazioni dello spazio latente difficili da rappresentare con un modello lineare.

Il prezzo da pagare è naturalmente una minore interpretabilità diretta.

Ed è qui che entra SHAP.

8. SHAP: spiegare il comportamento del modello

SHAP significa SHapley Additive exPlanations.

La teoria deriva dai valori di Shapley della teoria dei giochi cooperativi.

L'idea fondamentale consiste nell'assegnare a ogni feature un contributo alla previsione.

In forma semplificata:

f(x) = E[f(X)] + Σ φi

dove:

  • E[f(X)] rappresenta il valore di baseline del modello;
  • φi rappresenta il contributo attribuito alla feature i.

Per una specifica location potremmo avere qualcosa come:

Model baseline                       10.7

embedding_137                        +2.1
embedding_041                        +0.8
embedding_208                        -0.6
embedding_152                        +0.4
other dimensions                    +0.0

-----------------------------------------
Prediction                           13.4

Questo è il concetto di local explanation.

9. Il segno del valore SHAP conta

Un valore:

φi > 0

indica che quella feature spinge la previsione rispetto alla baseline in una direzione positiva.

Viceversa:

φi < 0

la spinge nella direzione opposta.

Questa informazione diventa però importante quando passiamo dall'explainability locale alla feature importance globale utilizzata nel workflow Esri.

10. Mean Absolute SHAP: cosa misura davvero ArcGIS

L'importance table prodotta da AutoML contiene sostanzialmente:

VARIABLE
IMPORTANCE

L'IMPORTANCE è una misura globale basata sul mean absolute SHAP.

Concettualmente:

Ii = E(|φi|)

Ovvero:

quanto, mediamente, quella feature modifica le previsioni del modello in termini di magnitudine.

Supponiamo di ottenere:

embedding_137   0.32
embedding_144   0.27
embedding_201   0.18
embedding_041   0.14

Possiamo concludere che embedding_137 riceve una forte attribuzione dal modello.

Ma attenzione:

|+0.32| = |-0.32|

L'importance globale non ci dice se quella dimensione tende ad aumentare o diminuire il target.

La direzione è stata eliminata dal valore assoluto.

11. Il trucco elegante di Esri: aggregare SHAP per segmento

A questo punto entra in gioco la struttura 4 × 64 dell'embedding.

Possiamo calcolare:

Housing importance
    = Σ IMPORTANCE dimensions 1..64

Environment importance
    = Σ IMPORTANCE dimensions 65..128

ACS importance
    = Σ IMPORTANCE dimensions 129..192

Demographic importance
    = Σ IMPORTANCE dimensions 193..256

Formalmente:

S1 = Σ Ii       i = 1...64
S2 = Σ Ii       i = 65...128
S3 = Σ Ii       i = 129...192
S4 = Σ Ii       i = 193...256

Trasformiamo quindi:

256 opaque latent dimensions

in quattro macro-dimensioni interpretabili:

Housing
Environment
Socioeconomic
Demographic

Nel caso food insecurity discusso da Esri, è il Segment 3, derivato dall'American Community Survey, a mostrare la maggiore aggregate mean absolute SHAP importance.

Il modello sta quindi facendo largo uso delle strutture socioeconomiche apprese dal GDFM.

Ma questa frase deve essere letta con molta precisione.

12. La sottigliezza matematica: non è Group SHAP

Questo è probabilmente uno dei punti tecnicamente più importanti dell'intero workflow.

Esri precisa correttamente che sommare le mean absolute SHAP importance delle singole dimensioni:

Σ E(|φi|)

non equivale a calcolare:

E(|Σ φi|)

Le due quantità sono matematicamente differenti.

Consideriamo due feature appartenenti allo stesso segmento:

φ129 = +0.8
φ130 = -0.7

Sommando le magnitudini otteniamo:

|0.8| + |-0.7| = 1.5

Ma il contributo netto combinato è:

|0.8 - 0.7| = 0.1

Quindi la segment importance utilizzata in questo workflow misura meglio:

la quantità complessiva di attività attributiva presente nelle dimensioni del segmento

che non:

il contributo netto del segmento alla previsione.

Non è una distinzione accademica: cambia radicalmente il significato del risultato.

13. Feature importance non significa predictive value

C'è un secondo errore interpretativo molto comune.

Supponiamo di ottenere:

Housing          20%
Environment      11%
ACS              47%
Demographics     22%

Non possiamo concludere:

senza ACS il modello perderebbe il 47% della propria accuratezza.

SHAP non misura questo.

Misura come il modello già addestrato distribuisce le proprie attribuzioni.

Per misurare il predictive value incrementale di un segmento servirebbe invece una vera ablation study.

14. Ablation study: il test che farei in un progetto reale

Addestriamo inizialmente il modello completo:

Model FULL

Housing
Environment
ACS
Demographic

R² = 0.82

Poi rimuoviamo sistematicamente interi segmenti.

FULL                         R² = 0.82

without Housing              R² = 0.80
without Environment          R² = 0.81
without ACS                  R² = 0.67
without Demographics         R² = 0.78

Ora possiamo osservare:

ΔR² ACS = 0.82 - 0.67
        = 0.15

Questa misura risponde a una domanda differente:

quanto valore predittivo perde il modello quando elimino l'informazione contenuta in quella rappresentazione?

Esiste poi un'altra possibilità: effettuare una joint permutation di tutte le 64 dimensioni del segmento e misurare la degradazione delle performance.

SHAP, ablation e permutation importance diventano quindi strumenti complementari.

SHAP
    → attribution

Ablation
    → incremental predictive value

Permutation
    → dependence of performance on information

Causal analysis
    → entirely different question

15. Il problema nascosto: le latent feature sono correlate

Gli aspetti che descrivono un territorio non sono indipendenti.

Consideriamo:

income
   ↕
education
   ↕
employment
   ↕
house value
   ↕
urban form
   ↕
mobility
   ↕
accessibility

Queste strutture sono fortemente correlate nel mondo reale.

Il representation learning trasferisce parte di queste dipendenze anche nello spazio latente.

Quindi le dimensioni:

z1 ... z256

non devono essere considerate automaticamente indipendenti.

Questo crea una delle classiche difficoltà dei metodi di feature attribution.

Se due variabili contengono informazione ridondante, il modello può distribuirne il “credito” in modi differenti.

Perciò:

SHAP importance of latent dimension

non deve essere trasformata impropriamente in:

importance of a real-world phenomenon

Il secondo concetto è molto più forte del primo.

16. SHAP non decodifica l'embedding

Questa distinzione merita di essere evidenziata.

SHAP non sta facendo:

embedding_137
      |
      v
"this dimension means income"

Sta facendo:

embedding_137
      |
      v
downstream model
      |
      v
"the fitted predictor relies strongly
 on this latent coordinate"

In altre parole:

SHAP non spiega necessariamente ciò che il foundation model ha imparato. Spiega come il downstream model utilizza ciò che il foundation model ha rappresentato.

È probabilmente la distinzione concettuale più importante da portarsi a casa.

17. Tre differenti livelli di interpretabilità

Possiamo formalizzare il problema distinguendo tre livelli.

LEVEL 1
REPRESENTATION INTERPRETATION

What information is encoded in z?


LEVEL 2
MODEL ATTRIBUTION

Which parts of z does f(z) use?


LEVEL 3
CAUSAL INTERPRETATION

Which real-world mechanisms cause Y?

Il workflow AutoML + SHAP opera principalmente al livello 2.

La conoscenza della struttura 4 × 64 consente parzialmente di risalire verso il livello 1.

Ma non arriviamo automaticamente al livello 3.

18. SHAP non implica causalità

Se il segmento ACS ha la maggiore importance nella previsione della food insecurity, possiamo affermare:

il modello utilizza fortemente pattern latenti appresi dal contesto socioeconomico.

Non possiamo automaticamente affermare:

il contesto socioeconomico causa la food insecurity nella misura indicata da SHAP.

Il modello rappresenta una relazione:

P(Y | X)

non necessariamente un intervento causale:

P(Y | do(X))

Questa distinzione tra predictive ML e causal inference diventa ancora più importante con gli embedding, perché la semantica delle feature non è esplicita.

19. Nel GIS compare un problema ancora più serio: spatial autocorrelation

Finora abbiamo ragionato come se le osservazioni fossero indipendenti.

Ma nel mondo geografico questo spesso non è vero.

La prima legge della geografia di Tobler rimane estremamente pertinente:

Everything is related to everything else, but near things are more related than distant things.

Due aree vicine possono condividere:

  • struttura demografica;
  • mercato immobiliare;
  • infrastrutture;
  • clima;
  • mobilità;
  • servizi;
  • accessibilità;
  • politiche locali;
  • storia economica.

Di conseguenza possono avere embedding molto simili.

20. Random train/test split e spatial leakage

Consideriamo un classico split casuale:

TRAIN

County A
County B
County C


TEST

County D

Se D confina con A, B e C e appartiene allo stesso regime geografico, il test potrebbe essere meno indipendente di quanto sembri.

Il modello potrebbe ottenere ottime performance semplicemente interpolando nello stesso contesto spaziale.

Non abbiamo necessariamente dimostrato:

generalization to unseen geography

ma magari soltanto:

interpolation inside a known spatial regime

Per un workflow GeoAI rigoroso affiancherei quindi al normale test una spatial cross-validation.

21. Spatial cross-validation

Una strategia migliore può essere:

Geography
    |
    v
Spatial blocks
    |
    +---- Fold A
    +---- Fold B
    +---- Fold C
    +---- Fold D
    +---- Fold E

I blocchi possono essere costruiti utilizzando:

  • H3;
  • grid regolari;
  • macroregioni amministrative;
  • clustering spaziale;
  • buffered holdout;
  • spatial blocking.

L'obiettivo è verificare se:

Model trained here
        |
        | geographic separation
        v
Predicts there

mantiene davvero performance elevate.

È una distinzione fondamentale quando vogliamo utilizzare foundation model geospaziali in produzione.

22. Performance globale e performance geografica non sono la stessa cosa

In un problema spaziale non mi fermerei quindi a:

R²
RMSE
MAE
F1
Accuracy

Analizzerei anche:

metric by region
metric by urban/rural context
metric by density
metric by embedding cluster
metric by distance from training data
metric by spatial regime

Per esempio un modello può avere:

Overall R² = 0.84

ma:

Urban areas      R² = 0.90
Suburban areas   R² = 0.87
Rural areas      R² = 0.58

Il singolo valore aggregato nasconde completamente il problema.

23. H3 Resolution 7 e il problema della scala

Gli USA Geodemographic Embeddings vengono distribuiti a livello di Uber H3 resolution 7.

Questa scelta crea una tessellazione geografica regolare e molto utile per la costruzione di rappresentazioni spatially consistent.

Ma spesso il nostro problema lavora a un'altra scala:

H3 cells
   |
   v
County

oppure

H3 cells
   |
   v
Municipality

oppure

H3 cells
   |
   v
Custom catchment area

Serve quindi aggregare gli embedding.

24. Non basta necessariamente fare la media dei 256 numeri

Qui incontriamo un punto matematicamente sottile.

Per un encoder non lineare E, generalmente:

Aggregate(E(x))
        ≠
E(Aggregate(x))

Il significato è importante.

L'embedding medio di dieci territori non equivale necessariamente all'embedding che avremmo ottenuto addestrando o applicando l'encoder sulla descrizione aggregata di quei territori.

Per questo ArcGIS introduce strumenti embedding-aware come:

Merge Embeddings

anziché ridurre il problema a una semplice operazione arbitraria sulle colonne.

25. MAUP non scompare con gli embedding

Il Modifiable Areal Unit Problem, uno dei problemi classici della spatial analysis, continua quindi ad esistere.

Gli embedding non lo eliminano.

Cambiando:

  • scala;
  • aggregazione;
  • confini;
  • unità geografica;

possono cambiare le strutture statistiche osservate.

In futuro dovremo probabilmente parlare molto di più di:

representation stability across geographic scales.

È un problema molto interessante per la ricerca GeoAI.

26. Il workflow concreto in ArcGIS Pro

La pipeline pratica diventa approssimativamente:

USA Geodemographic Embeddings
            |
            | H3 resolution 7
            v
      Merge Embeddings
            |
            v
        BLOB field
            |
            v
Extract Embedding To Fields
            |
            +--- emb_1
            +--- emb_2
            +--- ...
            +--- emb_256
            |
            v
      Train Using AutoML
            |
            +--- model selection
            +--- training
            +--- evaluation
            +--- importance
            |
            v
           DLPK
            |
            v
      Predict Using AutoML

ArcGIS può memorizzare gli embedding in un campo BLOB, mantenendoli come singolo oggetto vettoriale per gli strumenti embedding-aware.

Quando occorre utilizzare algoritmi tabellari tradizionali, Extract Embedding To Fields deserializza il vettore nelle singole colonne.

27. Embedding come predictor oppure come augmentation?

Ci sono due strategie differenti.

Prima strategia:

Embeddings
    |
    v
Model
    |
    v
Prediction

Gli embedding costituiscono l'intero set di predictor.

Seconda strategia:

Domain variables
       +
Geodemographic embeddings
       |
       v
      Model
       |
       v
   Prediction

La seconda è probabilmente quella più interessante per molti problemi reali.

28. Un esempio: flood vulnerability

Immaginiamo di voler prevedere vulnerabilità o impatto potenziale di un evento alluvionale.

Potremmo costruire feature fisiche:

DEM
Slope
Flow accumulation
Distance from river
Terrain roughness
Soil permeability
Building elevation
Rainfall
Hydraulic variables

e aggiungere:

Geodemographic Embedding

Housing context
Environmental context
Socioeconomic context
Demographic context

Otteniamo:

PHYSICAL SYSTEM
      +
HUMAN CONTEXT
      |
      v
 GeoAI MODEL

Questa combinazione può essere estremamente potente perché distingue due categorie di informazione.

Explicit domain features

        +

Learned contextual representation

Il modello può così utilizzare contemporaneamente conoscenza fisica progettata dall'esperto e rappresentazioni apprese dal foundation model.

29. SHAP può dirci se l'embedding aggiunge contesto realmente usato dal modello

Supponiamo che il modello abbia:

Elevation
Slope
DistanceRiver
FlowAccumulation

+

emb_1 ... emb_256

SHAP può mostrarci che:

physical variables               62%

geodemographic embedding         38%

e all'interno dell'embedding:

Housing            8%
Environment        13%
Socioeconomic      12%
Demographics        5%

Questo crea una sorta di osservabilità del modello che sarebbe impossibile limitandosi alle sole metriche predittive.

30. Global SHAP è solo l'inizio: il GIS vuole Local SHAP

Il vero salto concettuale arriva quando smettiamo di pensare a SHAP soltanto come a un grafico.

Nel GIS ogni osservazione possiede una geometria.

Questo significa che le spiegazioni possono essere riportate nello spazio.

Per ogni feature geografica possiamo immaginare:

ID = 10382

Prediction            0.74

Housing SHAP          +0.08
Environment SHAP      +0.05
Socioeconomic SHAP    +0.21
Demographic SHAP      -0.03

Ora questi valori possono diventare attributi geografici.

31. Da Explainable AI a Spatial Explainable AI

Possiamo costruire quattro mappe:

Housing Attribution Map

Environment Attribution Map

Socioeconomic Attribution Map

Demographic Attribution Map

A questo punto non stiamo più chiedendo soltanto:

quali feature sono importanti?

Possiamo chiedere:

dove determinate famiglie di feature sono importanti?

Questo piccolo cambiamento introduce una dimensione analitica completamente nuova.

Feature attribution
       +
Geography
       =
Spatial attribution

32. Cercare autocorrelazione nelle spiegazioni

Una volta ottenuto uno SHAP value geografico, possiamo addirittura applicare strumenti spatial statistics alle spiegazioni del modello.

Per esempio:

Local Moran's I(SHAP_ACS)

Getis-Ord Gi*(SHAP_ENV)

Spatial clustering(SHAP_HOUSING)

La domanda diventa:

esistono cluster geografici nei quali il modello utilizza sistematicamente lo stesso tipo di informazione?

Questo è molto più interessante della tradizionale feature importance globale.

33. Possiamo costruire un vero Explanation Space

Facciamo un ulteriore passo.

Per ogni location definiamo:

S(x) = [

  SHAP_Housing,
  SHAP_Environment,
  SHAP_Socioeconomic,
  SHAP_Demographics

]

Ora ogni luogo non è descritto da ciò che è, ma da come il modello ragiona su quel luogo.

Abbiamo creato un nuovo spazio vettoriale:

Explanation Space.

34. Clusterizzare il modo in cui il modello ragiona

Possiamo applicare clustering agli explanation vector.

                    EXPLANATION SPACE

                          |
          +---------------+---------------+
          |               |               |
          v               v               v

      Cluster A        Cluster B       Cluster C

 socioeconomic         environmental      housing
    driven                driven          driven

Questi cluster non significano:

questi territori sono geograficamente simili.

Significano qualcosa di diverso:

il modello utilizza pattern simili per formulare una previsione su questi territori.

È una distinzione sottile ma potentissima.

35. Embedding Space, Prediction Space, Explanation Space

Possiamo quindi descrivere l'intero sistema attraverso tre spazi.

                 REAL WORLD
                     |
                     v
            Raw geographic data
                     |
                     v
             Foundation Model
                     |
                     v

             EMBEDDING SPACE
        "What is this place like?"
                     |
                     v
            Downstream model
                     |
                     v

             PREDICTION SPACE
       "What may happen here?"
                     |
                     v
                   SHAP
                     |
                     v

             EXPLANATION SPACE
       "Why did the model think so?"

Questa, a mio avviso, è una delle chiavi concettuali più interessanti dell'evoluzione futura della GeoAI.

36. E potremmo aggiungere un quarto spazio: Uncertainty Space

Per un sistema realmente maturo manca però ancora qualcosa.

Embedding
    |
    v
Prediction
    |
    v
Explanation
    |
    v
Uncertainty

Non basta sapere:

Prediction = 0.83

Vorremmo sapere anche:

How uncertain is 0.83?

How far is this location
from training distribution?

Is this geography represented
inside the training set?

How stable is the SHAP explanation?

Questo porta verso temi come:

  • out-of-distribution detection;
  • epistemic uncertainty;
  • prediction intervals;
  • embedding distance;
  • explanation stability;
  • model calibration.

37. Embedding distance come possibile segnale di OOD

Consideriamo una nuova location x*.

Otteniamo:

z* = E(x*)

Possiamo misurare la distanza da regioni note del training embedding space.

d(z*, TrainingEmbeddingSpace)

Se la distanza è molto elevata, potremmo trovarci davanti a una geografia che il downstream model non ha mai realmente incontrato.

A quel punto un valore:

Prediction = 0.91

non dovrebbe avere lo stesso significato operativo di un'altra previsione 0.91 effettuata nel cuore della distribuzione di training.

Un GIS realmente AI-native dovrebbe probabilmente mostrare entrambe.

Prediction     0.91
Confidence     LOW
OOD distance   HIGH

38. Explainability stability: un altro problema poco discusso

Anche la spiegazione dovrebbe essere sottoposta a test di stabilità.

Se piccolissime variazioni dell'input producono:

Location A

ACS importance = 60%


Almost identical Location A'

ACS importance = 12%
Environment    = 55%

potremmo avere una spiegazione fragile.

In futuro potrebbe quindi essere utile introdurre metriche del tipo:

Explanation Stability Score

ottenute perturbando ragionevolmente gli input e osservando la varianza delle attribuzioni.

39. Foundation models stanno cambiando il concetto stesso di GIS feature

Storicamente una GIS feature è stata qualcosa come:

Geometry
+
Attributes

Per esempio:

Polygon

POPULATION = 12450
INCOME     = 38200
AREA       = 18.3
...

Con i foundation model possiamo iniziare a immaginare:

Geometry

+

Explicit Attributes

+

Embedding

+

Prediction

+

Explanation

+

Uncertainty

Questa potrebbe diventare una forma molto più ricca di AI-enabled geographic feature.

40. Dal Semantic GIS al Latent GIS

Tradizionalmente attribuiamo significato al territorio mediante uno schema progettato dall'uomo.

FIELD_NAME
FIELD_TYPE
DOMAIN
VALUE

Gli embedding introducono invece una seconda forma di conoscenza:

human-defined semantic attributes

             +

machine-learned latent attributes

Potremmo pensare a questo come a un passaggio da:

Semantic GIS

verso un sistema ibrido:

Semantic + Latent GIS.

Il primo rimane interpretabile dall'uomo.

Il secondo può catturare strutture troppo complesse per essere progettate manualmente.

41. E qui arriva il collegamento con GeoAI e GeoAgents

Questo tipo di rappresentazione diventa ancora più interessante se pensiamo ai futuri agenti geospaziali.

Un GeoAgent potrebbe interrogare contemporaneamente:

Feature attributes
Spatial relationships
Raster data
Vector embeddings
Geodemographic embeddings
Satellite embeddings
Document embeddings
Model predictions
SHAP explanations

La query:

trova aree simili a questa, ma nelle quali il rischio previsto è più elevato e spiegami quale differenza socioeconomica sta guidando il modello

potrebbe essere trasformata in una pipeline:

User question
      |
      v
GeoAgent
      |
      +------ Spatial Query
      |
      +------ Embedding Similarity
      |
      +------ ML Prediction
      |
      +------ SHAP Explanation
      |
      +------ Spatial Statistics
      |
      v
Natural-language answer
+
Map
+
Evidence

Questa è una prospettiva decisamente più interessante del semplice chatbot sopra una mappa.

42. Non soltanto geodemographic embeddings

Lo stesso paradigma può essere esteso ad altri foundation model geospaziali.

Satellite imagery
      |
      v
Vision Foundation Model
      |
      v
Image embedding


Demographic/environmental data
      |
      v
GDFM
      |
      v
Geodemographic embedding


Documents / reports
      |
      v
Language model
      |
      v
Text embedding


Mobility graph
      |
      v
Graph model
      |
      v
Network embedding

Una location potrebbe quindi essere descritta attraverso una rappresentazione multimodale:

Zlocation = [

  Zgeo,
  Zsatellite,
  Ztext,
  Znetwork,
  Ztemporal

]

A quel punto l'explainability non dovrà più rispondere solamente:

quale feature è importante?

ma anche:

quale modalità informativa sta guidando la decisione?

43. Una possibile architettura GeoAI di nuova generazione

                 ┌─────────────────────┐
                 │   GEOGRAPHIC WORLD  │
                 └──────────┬──────────┘
                            │
           ┌────────────────┼────────────────┐
           │                │                │
           v                v                v
      Tabular Data      Imagery          Documents
           │                │                │
           v                v                v
         GDFM          Vision FM            LLM
           │                │                │
           v                v                v
      Geo Embedding    Image Embedding   Text Embedding
           │                │                │
           └────────────────┼────────────────┘
                            │
                            v
                    MULTIMODAL SPACE
                            │
                            v
                    Downstream Model
                            │
                 ┌──────────┴──────────┐
                 │                     │
                 v                     v
             Prediction            Retrieval
                 │                     │
                 └──────────┬──────────┘
                            │
                            v
                       Explainability
                            │
                            v
                  Spatial Explainability
                            │
                            v
                         GeoAgent

Se questa direzione continuerà, la GeoAI non sarà semplicemente “AI applicata ai dati GIS”.

Diventerà un sistema nel quale il territorio stesso possiede rappresentazioni vettoriali riutilizzabili da molteplici modelli e task.

44. Il punto più importante: prediction non basta più

Per anni abbiamo valutato un modello quasi esclusivamente attraverso metriche come:

Accuracy
Precision
Recall
F1
RMSE
MAE
R²

Nella GeoAI moderna questo non è sufficiente.

Dovremmo iniziare a valutare contemporaneamente:

Predictive performance

Spatial generalization

Representation quality

Explanation quality

Explanation stability

Out-of-distribution behavior

Uncertainty calibration

Geographic fairness

Scale sensitivity

Il modello migliore non è necessariamente quello che guadagna l'ultimo 0,01 di R².

Potrebbe essere quello che mantiene:

  • buone performance;
  • buona generalizzazione geografica;
  • spiegazioni stabili;
  • incertezza calibrata;
  • comportamento prevedibile fuori distribuzione.

45. La vera rivoluzione: rappresentazioni geografiche riutilizzabili

Il passaggio fondamentale introdotto dai geodemographic embeddings non è quindi semplicemente:

5300 variables
      ↓
256 variables

È qualcosa di più profondo:

task-specific geographic variables

              ↓

reusable geographic representation

Una volta costruita la rappresentazione, possiamo riutilizzarla per:

  • regression;
  • classification;
  • clustering;
  • segmentation;
  • similarity search;
  • feature enrichment;
  • anomaly detection;
  • retrieval;
  • spatial reasoning.

Questo è esattamente ciò che i foundation model hanno fatto in altri domini.

Ora stiamo iniziando a vedere lo stesso paradigma entrare seriamente nel GIS.

46. From Embedding Space to Explanation Space

Il workflow mostrato da Esri sembra inizialmente molto semplice:

Embeddings
    +
AutoML
    +
SHAP

ma dietro questi tre elementi c'è un cambiamento architetturale importante.

RAW GEOGRAPHY
      |
      v
REPRESENTATION LEARNING
      |
      v
EMBEDDING SPACE
      |
      v
MACHINE LEARNING
      |
      v
PREDICTION SPACE
      |
      v
EXPLAINABLE AI
      |
      v
EXPLANATION SPACE
      |
      v
SPATIAL ANALYSIS
      |
      v
GEOGRAPHIC UNDERSTANDING

Il passaggio veramente interessante è l'ultimo.

Non vogliamo soltanto modelli capaci di fare previsioni sul territorio.

Vogliamo poter analizzare geograficamente come e perché quei modelli arrivano alle proprie conclusioni.

Conclusioni

L'approccio mostrato da Esri rappresenta un passo importante verso una GeoAI più interpretabile.

La struttura del Geodemographic Foundation Model permette di trasformare 256 dimensioni latenti apparentemente opache in quattro grandi domini semantici:

Housing
Environment
Socioeconomic
Demographic

SHAP permette poi di osservare come un downstream model utilizza quelle rappresentazioni.

Ma bisogna evitare scorciatoie interpretative.

Mean absolute SHAP non rappresenta causalità.

Segment SHAP non equivale a Group SHAP.

Feature attribution non equivale a predictive value.

Una latent dimension non corrisponde automaticamente a una variabile originaria.

Un'ottima cross-validation casuale non garantisce generalizzazione geografica.

Gli embedding non eliminano problemi classici del GIS come autocorrelazione spaziale e MAUP.

Ma, utilizzati correttamente, introducono qualcosa di estremamente potente: la possibilità di lavorare con rappresentazioni geografiche apprese, riutilizzabili e interrogabili.

Il prossimo salto potrebbe essere quello di trasformare SHAP da semplice strumento di interpretazione ML in un vero oggetto geografico:

Prediction Map
      +
Explanation Map
      +
Uncertainty Map

e quindi passare definitivamente:

from Embedding Space to Explanation Space.

Quando arriveremo a questo punto, explainability e spatial analysis non saranno più due discipline separate.

Potremo utilizzare gli strumenti GIS non soltanto per studiare il fenomeno geografico, ma anche per studiare geograficamente il comportamento dell'intelligenza artificiale che lo sta interpretando.

E questa potrebbe diventare una delle aree più interessanti della prossima generazione di GeoAI.


Riferimenti

martedì 6 ottobre 2026

ArcGIS Crime Analysis 6.0: dalla mappa dei reati alla Spatio-Temporal Intelligence

Una mappa dei reati non è Crime Analysis.

Visualizzare migliaia di incidenti come punti su una mappa può essere utile, ma il vero problema analitico è molto più profondo: capire se ciò che osserviamo rappresenta un pattern statisticamente significativo, come evolve nel tempo, quanto rapidamente decade il rischio attorno a un evento, se un intervento ha realmente modificato il fenomeno e, soprattutto, quanta incertezza esiste nei dati che stiamo analizzando.

Con Crime Analysis 6.0, rilasciato a settembre 2026, Esri ha aggiornato in modo significativo la propria soluzione per ArcGIS Pro. La nuova release supporta ArcGIS Pro 3.7, introduce un nuovo add-in e due strumenti particolarmente interessanti: Aoristic Analysis e Weighted Displacement Difference.

Ma questi strumenti diventano ancora più interessanti se li inseriamo in un quadro più ampio:

Crime Mapping
      ↓
Spatial Statistics
      ↓
Spatio-Temporal Analysis
      ↓
Crime Pattern Detection
      ↓
Uncertainty Modelling
      ↓
Vector + Graph Representation
      ↓
GeoAI / Agentic Spatial Intelligence

In questo deep dive vediamo quindi Crime Analysis non semplicemente come una toolbar di ArcGIS Pro, ma come il punto di ingresso verso una moderna architettura di spatial intelligence.

1. Il dato criminale è un evento spazio-temporale

Il modello più semplice rappresenta un incidente come:

CrimeEvent = (x, y, t)

dove x,y identificano la posizione e t il tempo.

Nella realtà un evento è molto più ricco:

CrimeEvent =
{
    Geometry,
    OccurFrom,
    OccurTo,
    CrimeType,
    ModusOperandi,
    Target,
    Context,
    Relationships
}

Già qui emerge un problema fondamentale: spesso t non è conosciuto.

Un furto in abitazione può essere scoperto alle 18:00, mentre il proprietario ha lasciato casa alle 08:00. L'unica informazione corretta è quindi:

08:00 ≤ t ≤ 18:00

Attribuire arbitrariamente il crimine alle 08:00, alle 13:00 o alle 18:00 introduce informazione che il dato originale non contiene.

Ed è esattamente qui che entra in gioco una delle novità più interessanti di Crime Analysis 6.0.

2. Aoristic Analysis: modellare il tempo che non conosciamo

L'Aoristic Analysis affronta gli eventi per i quali conosciamo un intervallo temporale ma non l'istante esatto.

Supponiamo che un evento possa essere avvenuto in quattro intervalli temporali:

10:00
11:00
12:00
13:00

In assenza di altra informazione, ciascun intervallo riceve peso:

P(t) = 1 / 4 = 0.25

Più generalmente, per un evento i compatibile con n intervalli:

w(i,t) = 1 / n

quando il time bucket t appartiene alla finestra temporale dell'evento, e zero altrimenti.

Aggregando molti eventi otteniamo:

A(t) = Σ w(i,t)

che rappresenta il peso aoristico complessivo associato a quel periodo.

La differenza concettuale è importante: non stiamo inventando l'orario più probabile del singolo evento. Stiamo propagando esplicitamente la sua incertezza temporale.

3. Implementarlo in C#

Il principio può essere riprodotto facilmente in .NET. Immaginiamo un modello minimale:

public sealed record CrimeIncident(
    long Id,
    DateTime OccurFrom,
    DateTime OccurTo,
    string CrimeType);

Possiamo calcolare quanto un evento contribuisce a un determinato bucket temporale:

static double AoristicWeight(
    DateTime occurFrom,
    DateTime occurTo,
    DateTime bucketFrom,
    DateTime bucketTo)
{
    if (occurTo <= occurFrom)
        return 0;

    var from = occurFrom > bucketFrom
        ? occurFrom
        : bucketFrom;

    var to = occurTo < bucketTo
        ? occurTo
        : bucketTo;

    if (to <= from)
        return 0;

    return (to - from).TotalSeconds /
           (occurTo - occurFrom).TotalSeconds;
}

Questa variante utilizza la frazione effettiva di sovrapposizione dell'intervallo, rendendo esplicito ciò che normalmente viene nascosto dietro una semplice classificazione temporale.

In un add-in ArcGIS Pro potremmo quindi leggere le feature con ArcGIS Pro SDK, estrarre OccurFrom e OccurTo, costruire i bucket e produrre una tabella o una feature class derivata.

Il punto interessante non è riscrivere uno strumento che ArcGIS possiede già. È capire il modello matematico per poterlo integrare in pipeline analitiche più complesse.

4. Kernel Density non significa Hot Spot Analysis

Una delle confusioni più comuni nella spatial analysis è interpretare qualsiasi superficie con zone rosse come un hot spot statisticamente significativo.

Kernel Density Estimation (KDE) costruisce una superficie continua distribuendo attorno agli eventi una funzione kernel. In forma semplificata:

f̂(x) = 1/(nh²) Σ K((x-Xᵢ)/h)

dove h è il bandwidth.

Aumentando il search radius si ottiene una superficie più liscia e generalizzata; riducendolo emergono strutture locali più dettagliate.

Il risultato rimane però una stima di densità, non automaticamente una prova di significatività statistica.

high density ≠ statistically significant hot spot

5. Getis-Ord Gi*: quando il clustering diventa statistico

Per individuare cluster statisticamente significativi ArcGIS Pro mette a disposizione, tra gli altri strumenti, Optimized Hot Spot Analysis, basato sulla statistica Getis-Ord Gi*.

Concettualmente non ci interessa soltanto sapere se una feature ha un valore elevato. Vogliamo sapere se essa è circondata da valori elevati in misura difficilmente compatibile con una distribuzione casuale.

Il risultato comprende:

Gi* z-score
p-value
confidence bin

Questa distinzione dovrebbe essere alla base di qualsiasi sistema serio di crime intelligence:

Visualization
    ≠
Density estimation
    ≠
Spatial clustering
    ≠
Statistical evidence

6. DBSCAN, HDBSCAN e clustering spazio-temporale

Non tutti i pattern hanno forma regolare.

Density-based Clustering in ArcGIS Pro consente di identificare cluster immersi nel rumore utilizzando algoritmi come DBSCAN, HDBSCAN e OPTICS.

Questa proprietà è particolarmente interessante nel crime analysis perché un pattern può essere molto evidente per tre settimane e scomparire completamente nel mese successivo.

Una distanza puramente spaziale:

d(i,j) = √((xᵢ-xⱼ)² + (yᵢ-yⱼ)²)

non cattura questa dinamica.

Possiamo concettualmente introdurre una distanza spazio-temporale:

D(i,j) = αDspace(i,j) + βDtime(i,j)

con scale opportunamente normalizzate.

7. Repeat e Near-Repeat: il rischio non è statico

Uno dei concetti più potenti della crime geography è la repeat/near-repeat victimization.

Dopo un evento, il luogo colpito e le aree vicine possono presentare per un periodo limitato un rischio maggiore di eventi analoghi. Tale influenza tende a diminuire sia con la distanza sia con il tempo.

Crime Analysis contiene strumenti dedicati per classificare eventi come originator, repeat e near-repeat utilizzando bande spaziali e temporali.

Possiamo rappresentare concettualmente il decadimento come:

R(d,t) = R₀ · e-λd · e-μt

dove:

d = distanza dall'incidente
t = tempo trascorso
λ = decadimento spaziale
μ = decadimento temporale

Non è quindi una superficie di rischio permanente.

È una superficie che decade continuamente nello spazio e nel tempo.

8. Prediction Zones: attenzione alla parola "prediction"

Crime Analysis può generare Prediction Zones a partire dai pattern repeat/near-repeat.

È però importante capire cosa significa "prediction".

Non significa:

qui avverrà il prossimo crimine

Significa piuttosto:

date le regolarità spazio-temporali
osservate nel dataset,
quest'area presenta un rischio relativo
più elevato nel breve periodo.

È una differenza enorme, sia statisticamente sia eticamente.

9. Space-Time Cube: quando la mappa 2D non basta più

Un altro salto concettuale consiste nel trattare lo spazio e il tempo come un'unica struttura analitica.

Lo Space-Time Cube suddivide i dati in bin spaziali e temporali:

             TIME
              ↑
              │  ▢
              │  ▢ ▢
              │  ▢ ▢
              │  ▢ ▢ ▢
              │
              └────────────→ SPACE

Emerging Hot Spot Analysis permette di osservare non solo dove sono presenti cluster, ma come essi evolvono nel tempo.

La domanda non è più:

Dove sono gli hot spot?

ma:

Dove stanno nascendo?
Quali persistono?
Quali si stanno intensificando?
Quali stanno scomparendo?

Questa è già spatio-temporal intelligence.

10. Crime series e comportamento spaziale

Crime Analysis include workflow per ordinare cronologicamente gli eventi appartenenti a una serie e rappresentarne le connessioni.

Questo consente di studiare concetti classici del geographic profiling, come la distinzione tra comportamento marauder e commuter.

La sequenza:

P1 → P2 → P3 → P4 → P5

diventa quindi molto più di una polilinea.

Possiamo analizzare:

distance(Pn, Pn+1)
bearing(Pn, Pn+1)
Δt(Pn, Pn+1)
velocity
dispersion
directional persistence

e cercare cambiamenti nella struttura della serie.

11. Weighted Displacement Difference: l'intervento ha funzionato?

Crime Analysis 6.0 introduce anche Weighted Displacement Difference.

Qui la domanda cambia completamente.

Non vogliamo più soltanto descrivere il fenomeno. Vogliamo valutare un intervento.

Response Area
      +
Response Displacement Zone

Control Area
      +
Control Displacement Zone

        ↓

Before vs After
        ↓
Weighted Displacement Difference

La statistica confronta il cambiamento degli incidenti nell'area interessata dall'intervento con quello osservato in un'area di controllo e considera anche le aree circostanti per verificare se il fenomeno sia stato semplicemente spostato.

Questo è un passaggio metodologico importantissimo:

Crime ↓ nell'area A

non implica necessariamente:

Intervento efficace

perché potrebbe essersi verificato:

A ↓
B ↑

ovvero displacement.

12. Da Crime Analysis a un Crime Graph

Fin qui abbiamo considerato principalmente geometrie, attributi e tempo.

Ma un'indagine contiene naturalmente anche relazioni.

Person ── called ── Person
   │                   │
 visited             owns
   │                   │
   ▼                   ▼
Place ── near ── CrimeEvent
                       │
                    similar
                       │
                       ▼
                  CrimeEvent

Crime Analysis contiene già strumenti investigativi per lavorare con call links, settori delle celle telefoniche e corrispondenze spazio-temporali.

La naturale evoluzione architetturale è quindi rappresentare parte del dominio come un spatio-temporal knowledge graph.

13. Il passo successivo: Crime Event Embeddings

Ed è qui che possiamo andare oltre gli strumenti standard.

Un incidente non deve necessariamente essere confrontato con un altro soltanto attraverso la distanza geografica.

Possiamo costruire una rappresentazione multidimensionale:

E = [
    spatial features,
    temporal features,
    modus operandi,
    target characteristics,
    environmental context,
    semantic description,
    graph relationships
]

e trasformarla in un vettore:

z = f(E) ∈ Rⁿ

A quel punto due incidenti possono essere confrontati attraverso una funzione di similarità che combina più domini:

D(i,j) = αDspace + βDtime + γDsemantic + δDMO + εDgraph

La query investigativa cambia radicalmente.

Da:

Find incidents within 500 meters.

a:

Find incidents that are:

geographically compatible
AND temporally compatible
AND behaviorally similar
AND semantically similar
AND connected through relevant entities.

Questo è il punto d'incontro tra GIS, vector search e graph analytics.

14. Un'architettura GeoAI

Una possibile architettura enterprise potrebbe diventare:

                ArcGIS Pro
                    │
             Crime Analysis
                    │
          Spatial Statistics
                    │
             ArcGIS Enterprise
                    │
        ┌───────────┴───────────┐
        │                       │
 Spatial Features         Operational Data
        │                       │
        └───────────┬───────────┘
                    │
               Azure SQL
                    │
       ┌────────────┼────────────┐
       │            │            │
   relational     vector       graph
     data         index      relationships
       │            │            │
       └────────────┼────────────┘
                    │
             Retrieval Layer
                    │
                 GeoAgent
                    │
             ArcGIS Pro / Web

Il GeoAgent potrebbe ricevere una richiesta come:

Analyze residential burglaries from the last six weeks.

Identify statistically significant spatial clusters,
test for repeat/near-repeat behavior,
compare modus-operandi similarity,
and explain which evidence supports each candidate series.

15. L'LLM non deve fare statistica al posto del GIS

Questo è forse il punto architetturale più importante.

Non costruirei un sistema nel quale chiediamo direttamente a un Large Language Model:

Where will the next crime occur?

Un LLM non dovrebbe sostituire Getis-Ord Gi*, KDE, DBSCAN, Space-Time Cube o un modello statistico validato.

Dovrebbe invece funzionare come orchestratore analitico:

User
  │
  ▼
GeoAgent
  │
  ├──► ArcGIS Spatial Statistics
  │
  ├──► Space-Time Analysis
  │
  ├──► Vector Search
  │
  ├──► Graph Query
  │
  └──► Operational Database
          │
          ▼
      Evidence
          │
          ▼
   LLM explanation

In altre parole:

LLM ≠ analytical truth

LLM = reasoning + orchestration + explanation

mentre il risultato quantitativo deve continuare a provenire da strumenti deterministici, modelli statistici o algoritmi esplicitamente validati.

16. Explainability prima della prediction

Un sistema di crime intelligence dovrebbe poter rispondere non soltanto:

Risk = HIGH

ma anche:

WHY?

• 7 recent related incidents
• statistically significant Gi* cluster
• 5 incidents inside the near-repeat temporal window
• high spatial proximity
• strong modus-operandi similarity
• pattern intensifying over the last 3 weeks

La spiegabilità non è un accessorio dell'AI.

In domini ad alto impatto è parte dell'architettura.

17. Il problema più difficile: i dati non sono la realtà

Esiste infine un limite che nessun algoritmo può eliminare automaticamente.

Un database criminale non rappresenta necessariamente:

all crimes that happened

ma più precisamente qualcosa di simile a:

events reported
+
events detected
+
events recorded
+
events classified
+
effects of enforcement activity

Questa distinzione è fondamentale.

Una maggiore concentrazione di osservazioni in una zona può derivare da un maggior numero di eventi, ma può anche essere influenzata da maggiore presenza operativa, differenti livelli di denuncia, procedure amministrative o qualità diversa del dato.

Se utilizziamo questi dati senza comprenderne il processo generativo, rischiamo di creare un feedback loop:

more observations
      ↓
higher estimated risk
      ↓
more attention
      ↓
more detected events
      ↓
even higher estimated risk

La precisione matematica del modello non elimina il bias del processo che ha prodotto i dati.

18. Dal GIS descrittivo alla Spatial Intelligence

Crime Analysis 6.0 mostra bene quanto il GIS moderno si stia allontanando dalla semplice rappresentazione cartografica.

Il percorso ormai è:

Where did it happen?
        ↓
Where is it concentrated?
        ↓
Is the concentration statistically significant?
        ↓
How is the pattern evolving?
        ↓
How does risk decay in space and time?
        ↓
Are apparently separate events related?
        ↓
Did an intervention change the pattern?
        ↓
What evidence supports the conclusion?

E il prossimo passo potrebbe essere:

Can an intelligent spatial agent
autonomously assemble the right analyses,
test competing hypotheses,
retrieve supporting evidence
and explain its conclusions?

Conclusione

Crime Analysis 6.0 è interessante non tanto perché aggiunge nuovi pulsanti ad ArcGIS Pro, ma perché rende evidente una trasformazione più ampia.

La geografia del crimine sta diventando sempre più una disciplina spazio-temporale, probabilistica e relazionale.

Aoristic Analysis ci ricorda che anche il tempo può essere incerto. Repeat/Near-Repeat Analysis introduce il decadimento spazio-temporale del rischio. Space-Time Cube permette di osservare l'evoluzione dei cluster. Weighted Displacement Difference porta l'analisi verso la valutazione degli interventi.

Embeddings, vector search, graph analytics e GeoAI possono costituire il livello successivo, purché non sostituiscano la statistica con un modello linguistico.

Il GIS del futuro non dovrà semplicemente mostrare dove si trova qualcosa.

Dovrà essere in grado di spiegare:

what happened
where
when
how it is connected
how certain we are
how the pattern is changing
and which evidence supports the hypothesis.

È in quel momento che una mappa smette di essere soltanto una rappresentazione dello spazio e diventa un vero sistema di Spatial Intelligence.

lunedì 5 ottobre 2026

NicoGIS Tech Weekly — Runtime Async, Spatial-Semantic GIS e Multi-Agent

Il tema della settimana: spostare complessità nel posto giusto

Questa settimana il filo conduttore non è una singola release, ma uno spostamento architetturale che si vede in ecosistemi apparentemente lontani. In .NET 11 una parte del lavoro di async/await può spostarsi dal compilatore C# al runtime e al JIT. In ArcGIS gli embedding stanno diventando dati GIS operativi, non semplicemente output intermedi di un modello. In Experience Builder le convenzioni di sviluppo vengono impacchettate in un Agent Skill consumabile da coding agent diversi. E nella Responses API di OpenAI il modello può delegare lavoro a subagent con contesti separati e coordinamento interno.

Il pattern comune è interessante: invece di aggiungere altra logica applicativa esplicita, una parte crescente della complessità viene trasferita verso runtime, rappresentazioni apprese e layer di orchestrazione.

Source code / GIS data / user intent
                |
                v
   richer runtime representation
                |
       +--------+--------+
       |        |        |
      JIT   embeddings  agents
       |        |        |
       +--------+--------+
                |
                v
      optimized execution

Analisi. La domanda da software architect non è più soltanto “quale API uso?”, ma dove deve vivere la complessità? Se può essere assorbita da un runtime che conosce meglio l'esecuzione, da una rappresentazione che conserva semantica o da un layer dichiarativo che codifica le regole del framework, il codice applicativo può diventare più semplice senza necessariamente diventare meno efficiente.


.NET 11: la performance interessante è quella che sparisce sotto il codice

Microsoft ha pubblicato il 15 settembre il consueto approfondimento di Stephen Toub sulle performance di .NET 11. Il contesto è importante: .NET 11 RC1 è disponibile dall'8 settembre con licenza go-live, quindi non stiamo parlando soltanto di esperimenti su una branch futura del runtime. Le fonti principali sono Performance Improvements in .NET 11 e Announcing .NET 11 Release Candidate 1.

Il post contiene centinaia di ottimizzazioni. Più che inseguire ogni microbenchmark, conviene cercare quelle che modificano il modello mentale con cui progettiamo applicazioni.

Runtime async: async diventa anche un problema del JIT

Tradizionalmente il compilatore C# effettua il lowering di un metodo async: genera state machine, campi per lo stato catturato, MoveNext, builder e tutto ciò che serve a trasformare il codice sorgente in IL eseguibile. Con runtime async, .NET 11 introduce un percorso diverso: per i metodi eleggibili il compilatore produce un contratto IL più compatto e il runtime/JIT assume una parte del lavoro di trasformazione.

L'opt-in applicativo documentato da Microsoft è:

<PropertyGroup>
  <TargetFramework>net11.0</TargetFramework>
  <Features>$(Features);runtime-async=on</Features>
</PropertyGroup>

Non serve una nuova sintassi C#. L'obiettivo dichiarato è la compatibilità comportamentale: la strategia di lowering deve restare un dettaglio implementativo. Microsoft precisa anche che l'implementazione non è ancora ottimale in tutti i casi e invita a misurare prima di abilitarla in produzione. L'obiettivo per .NET 11 è almeno la parità con il lowering tradizionale, mentre l'abilitazione predefinita è indicata come possibile direzione per .NET 12.

Il passaggio architetturalmente più interessante è la possibilità di evitare di materializzare alcuni Task<T> intermedi quando una catena di metodi runtime-async si limita a chiamare e attendere direttamente il livello successivo. Il runtime mantiene due modalità correlate dello stesso metodo: il contratto pubblico che restituisce Task<T> e una variante interna utilizzabile nelle catene runtime-async. Se una chiamata completa sincronicamente, il valore può fluire verso il chiamante senza creare un Task<T> intermedio; se sospende, il runtime collega lo stato delle continuation.

A() awaits B()
       |
       v
B() awaits C()
       |
       v
C()

Classic lowering:
Task C -> state machine B -> Task B -> state machine A -> Task A

Runtime async, when the pattern is eligible:
C result / continuation
        -> B
        -> A
        -> materialize Task only where observable

Il punto non è che “Task sparisce”. Se il task viene osservato come oggetto, memorizzato o usato da API che ne richiedono l'identità, deve esistere. L'ottimizzazione elimina soprattutto i confini che sono un dettaglio di composizione e non un requisito semantico.

Nel piccolo esempio pubblicato da Microsoft con dieci livelli di metodi async, l'assembly passa da 10.752 a 5.632 byte. È un micro-esempio, non un benchmark applicativo, ma rende visibile un effetto reale: meno state machine generate significa anche meno metadata e meno IL da trasportare. La stessa documentazione indica supporto per Task, Task<T>, ValueTask e ValueTask<T>; async void, async iterator e task-like custom con builder personalizzati restano invece sul percorso tradizionale.

Analisi. Runtime async rende meno costosa una buona decomposizione del codice. In passato, in hot path estremi, si poteva essere tentati di fondere helper async per ridurre state machine e allocazioni. Se il runtime può riconoscere e ottimizzare la catena, la leggibilità del sorgente e la qualità del codice generato smettono di essere necessariamente in conflitto.

Escape analysis: meno oggetti sul GC heap senza cambiare il sorgente

Un'altra linea di lavoro riguarda l'escape analysis. Se il JIT riesce a dimostrare che un oggetto non può sopravvivere al metodo corrente, può evitare l'allocazione sul GC heap e trattarlo in modo più efficiente. .NET 11 estende i casi riconosciuti, per esempio rendendo visibili al JIT temporanei che prima erano nascosti dietro helper runtime.

Un esempio del post riguarda il boxing temporaneo di un Nullable<T>: in uno scenario di formattazione, una precedente allocazione heap da 24 byte viene completamente eliminata. Anche qui il numero non va generalizzato al proprio workload; ciò che conta è il pattern: più informazione il JIT riesce a recuperare, più ottimizzazioni diventano possibili senza introdurre API specialistiche nel codice applicativo.

PGO, devirtualizzazione e loop: il runtime osserva il programma reale

Il JIT continua inoltre a sfruttare tiered compilation e Profile-Guided Optimization. Il Tier 0 può raccogliere informazioni sui rami realmente percorsi e sui tipi concreti che arrivano ai call site virtuali; una successiva compilazione Tier 1 usa quei dati per specializzare il codice. La guarded devirtualization può trasformare un dispatch virtuale o di interfaccia nel percorso veloce verso un tipo probabile, lasciando un fallback corretto per gli altri casi.

.NET 11 estende anche loop cloning e range analysis. In un loop su array o Span<T>, se il JIT riesce a provare una relazione fra indice e lunghezza, può pagare un controllo una sola volta e utilizzare un percorso clonato senza bounds check a ogni iterazione.

guard once
   |
   +--> fast loop: no per-iteration bounds check
   |
   +--> safe fallback: normal checked loop

È un esempio classico di ottimizzazione che difficilmente conviene replicare manualmente: il runtime può mantenerla insieme alle garanzie di sicurezza del linguaggio.

GC e write barrier: la performance non è solo “quante allocazioni faccio”

.NET 11 migliora anche il confine tra codice generato e garbage collector. Microsoft descrive ottimizzazioni alle GC write barrier e ai controlli di covarianza degli array: quando il JIT conosce con precisione il tipo della destinazione, può esporre e semplificare operazioni che in precedenza rimanevano nascoste dietro helper runtime.

Un altro cambiamento riguarda i ConditionalWeakTable e i dependent handle. I metadata dei handle ora possono “invecchiare” insieme agli oggetti a cui sono associati, permettendo alle collection giovani di evitare scansioni inutili di stato ormai long-lived. I microbenchmark pubblicati mostrano differenze molto grandi in scenari costruiti con centinaia di migliaia o milioni di handle, ma il dato realmente importante è l'effetto sistemico: ridurre il lavoro ripetuto durante le collection ephemeral riduce il costo pagato dall'intero processo.

Startup, Native AOT e una convergenza importante per MAUI

Sul fronte startup, .NET 11 riduce allocazioni e lavoro durante la costruzione della Trusted Platform Assembly list, sposta parte dei metadata di EventSource a build time e migliora alcuni percorsi ReadyToRun. Per Native AOT su Windows viene ridotto anche uno spreco di virtual memory nei piccoli blocchi di metadata runtime.

Un cambiamento particolarmente significativo è la convergenza mobile: a partire da .NET 11, Android, iOS e Mac Catalyst in .NET MAUI passano a CoreCLR, completando il superamento del runtime Mono per queste piattaforme. Questo porta la stessa base runtime usata da server e desktop, con JIT, GC, diagnostics, ReadyToRun e PGO dove applicabili, e una base comune per Native AOT.

Valutazione. Il tema di .NET 11 non è “un'altra release con qualche percentuale in più”. È la progressiva trasformazione del runtime in un ottimizzatore più informato: osserva i tipi reali, le hot path, la lifetime degli oggetti, le relazioni fra indici, le catene async e sempre più spesso elimina costi che il sorgente non dovrebbe essere costretto a conoscere.


ArcGIS embeddings: dalla distanza geografica alla distanza semantica

ArcGIS Pro tratta ormai gli embedding come una struttura dati utilizzabile direttamente nei workflow GIS. La documentazione ufficiale descrive un embedding come un vettore numerico ad alta dimensionalità in cui elementi semanticamente simili sono vicini nello spazio vettoriale. Gli embedding possono supportare similarity search, clustering, change detection e analisi su larga scala. Fonti: Embeddings in ArcGIS Pro e Including Embeddings in Your Spatial Analysis Workflows.

Un dettaglio implementativo è importante: ArcGIS riconosce come embedding dataset una feature class con un campo Embedding di tipo Blob. La documentazione indica supporto per file geodatabase, enterprise geodatabase con feature class registrate e mobile geodatabase; shapefile e GeoPackage non sono formati supportati per memorizzare questi embedding dataset.

Una volta calcolato il vettore, molte operazioni non richiedono più di rieseguire il foundation model. Il confronto può diventare un'operazione relativamente leggera sui vettori precomputati, per esempio attraverso cosine similarity. È questa separazione tra costo di representation learning e costo di retrieval che rende gli embedding interessanti anche come building block architetturale.

Non confondiamo due tipi di prossimità

Nel GIS tradizionale, “vicino” significa quasi sempre una relazione nello spazio geografico: distanza euclidea o geodetica, rete stradale, topologia, contiguità. Con gli embedding compare un secondo spazio:

Geographic space                Embedding space
---------------                 ---------------
meters / degrees                cosine / vector distance

near on the map                 similar in meaning/context
far on the map                  semantically similar
near on the map                 semantically different

Due quartieri a centinaia di chilometri di distanza possono risultare molto vicini nello spazio degli embedding perché condividono struttura demografica, economica o ambientale. Al contrario, due poligoni adiacenti possono avere firme semantiche molto differenti.

Esri sottolinea anche un aspetto che nei progetti reali diventa subito critico: la scala dell'embedding deve essere coerente con la scala dell'analisi. Aggregare embedding H3 più fini verso poligoni più grandi tramite media, mediana o altre statistiche è possibile, ma Esri lo descrive come un'area ancora aperta di ricerca perché l'aggregazione può diluire informazione significativa. Usare embedding a scala più grossolana su osservazioni molto fini può invece introdurre valori ripetuti e problemi assimilabili all'ecological fallacy.

Spatial-semantic retrieval: un pattern che vale la pena formalizzare

Analisi. Da qui emerge un pattern che chiamerei spatial-semantic retrieval. Non è necessario trasformare ogni problema GIS in una ricerca puramente vettoriale. In molti casi conviene separare i due segnali.

Query location / feature
        |
        v
Spatial filter
(buffer / intersects / network / extent)
        |
        v
Candidate set
        |
        v
Embedding similarity
(cosine / nearest neighbors)
        |
        v
Semantic ranking
        |
        v
GIS result

Oppure si può invertire l'ordine: partire dai nearest neighbor semantici e successivamente applicare vincoli geografici.

Questa separazione evita un errore concettuale importante. Nel post sulle best practice Esri sconsiglia di mescolare direttamente embedding e variabili tradizionali dentro la stessa metrica di similarità. Se vogliamo combinare distanza geografica e similarità semantica, è più pulito calcolare i due segnali separatamente e fonderli a valle, con una strategia di late fusion validata sul caso d'uso.

Per esempio, una funzione di ranking custom potrebbe essere:

score = alpha * semanticScore
      + (1 - alpha) * spatialScore

Attenzione: questa formula è una proposta architetturale, non una funzione ArcGIS documentata. semanticScore e spatialScore devono essere normalizzati e calibrati; alpha non va scelto “a sensazione” ma su un dataset di validazione coerente con il problema.

Dal pixel al LiDAR: cross-modal geospatial inference

Il 2 ottobre Esri ha pubblicato un caso ancora più interessante: Classify Point Clouds Using Embedding Based Image Analysis. Il workflow parte da imagery e point cloud sovrapposte. Se un oggetto è visivamente riconoscibile nell'immagine ma difficile da separare usando soltanto geometria, quota o return information della point cloud, la semantica può essere estratta dall'immagine e poi trasferita al LiDAR.

Nel caso dimostrato da Esri il target sono i binari ferroviari del Dangermond Preserve. Il flusso è:

True orthophoto
      |
      v
Generate imagery embeddings
      |
      v
Select a few clean rail examples
      |
      v
Find Similar in embedding space
      |
      v
Semantic mask / feature
      |
      v
Review + optional dissolve
      |
      v
Set LAS Class Codes Using Features
      |
      v
Rail class in point cloud

Esri suggerisce questo approccio soprattutto per elementi con pattern visivo netto come rail line, strade, pannelli solari o specifici tipi di copertura. Nel workflow pubblicato, il risultato vettoriale ottenuto dall'analisi degli embedding viene usato da Set LAS Class Codes Using Features per assegnare alla point cloud la classe ASPRS 10 per il rail.

Analisi. Questo è più interessante di una semplice “classificazione AI”. Il modello non deve necessariamente essere ottimizzato per la modalità finale. Possiamo estrarre semantica dalla modalità dove il segnale è più leggibile — l'immagine — e trasferire il risultato verso la rappresentazione 3D.

semantics from imagery
        +
spatial registration
        =
knowledge transferred to 3D geometry

È un esempio concreto di cross-modal geospatial inference.

Il lato delicato è l'incertezza. Una pipeline del genere non eredita soltanto l'errore del modello: accumula errore di classificazione, soglia di similarità, georeferenziazione, differenze di risoluzione e soprattutto eventuale disallineamento temporale tra imagery e LiDAR. Esri raccomanda infatti particolare attenzione quando i due dataset non sono acquisiti nello stesso periodo e insiste sulla verifica visuale del risultato.


Experience Builder Agent Skill: quando la documentazione diventa comportamento dell'agente

Il 14 settembre Esri ha pubblicato un Agent Skill per lo sviluppo di custom widget ArcGIS Experience Builder. Il contenuto è open source nel repository arcgis-experience-builder-sdk-resources, cartella skills/arcgis-exb-widget-dev.

Il punto tecnico non è “ora l'AI scrive i widget”. Quello era già possibile. Il punto è che Esri sta trasformando parte della propria conoscenza procedurale in un artefatto direttamente consumabile dagli agenti.

Lo skill copre, tra le altre cose, struttura dei file, manifest.json, config.json, separazione runtime/settings, data source, map e layer view, message/data actions, theming, state, ArcGIS web components, accessibilità e convenzioni del framework. La documentazione ufficiale di Experience Builder conferma che i custom widget sono componenti React/TypeScript integrati tramite il framework Jimu e che lavorano con data source, Map widget, JimuMapViewComponent, message e data actions. Riferimento: Getting started with widget development.

Skill non significa fine-tuning

Analisi. Uno skill di questo tipo è più vicino a una procedural knowledge package che a un modello specializzato. Non cambia i pesi del modello. Cambia il contesto operativo con cui l'agente decide come procedere.

General coding model
        |
        +--> generic TypeScript / React knowledge
        |
        +--> Esri Agent Skill
                |
                +--> ExB conventions
                +--> file anatomy
                +--> framework APIs
                +--> references
                +--> skeletons

Il vantaggio è importante: invece di sperare che il modello ricostruisca la convenzione corretta da memoria, search o esempi casuali, gli forniamo un pacchetto progettato per quel dominio.

La parte che manca a un vendor skill: il contratto del repository

Un vendor skill può sapere come funziona Experience Builder. Non può conoscere automaticamente le decisioni architetturali di una specifica codebase: versioni supportate, convenzioni di naming, pattern di comunicazione fra widget, servizi autorizzati, policy di logging, regole di packaging, test obbligatori, compatibilità con release Enterprise precedenti.

Per un progetto reale vedo quindi tre livelli distinti:

1. Vendor Skill
   "How Experience Builder works"

2. Repository Skill
   "How THIS project is engineered"

3. CI / tests / linters
   "What is actually allowed to ship"

Valutazione. Questa stratificazione è molto più robusta del semplice prompt engineering. Il prompt descrive il task; lo skill descrive il dominio; il repository skill descrive le decisioni locali; la CI rende alcune regole eseguibili. È un percorso verso una forma di architecture-as-context.

Il limite resta fondamentale: un agente può produrre codice sintatticamente valido ma architetturalmente sbagliato. Per esempio, un widget che usa l'API corretta può comunque gestire male ownership dello stato, lifecycle della map view, concorrenza fra strumenti interattivi o compatibilità con un'altra estensione. Lo skill riduce il problema del “non conosco il framework”; non elimina il problema del “non conosco il sistema”.


GPT-6.1 Sol e Multi-Agent: l'orchestrazione entra nella request

Il 29 settembre OpenAI ha aggiunto GPT-6.1 Sol e la modalità Multi-agent in beta alla Responses API. Nello stesso giorno è arrivato anche computer use nell'Agents API con browser ospitato da OpenAI. Le fonti primarie sono il changelog ufficiale, la documentazione Multi-agent, la pagina del modello GPT-6.1 Sol e la guida Computer use.

Per GPT-6.1 Sol la documentazione corrente indica una context window da 1.050.000 token, output massimo di 128.000 token e, nel tier Standard per prompt fino a 272K token di input, prezzi per milione di token di 2 dollari input, 0,10 dollari cached input, 2,50 dollari cache write e 10 dollari output. I prezzi e i limiti sono dati operativi e vanno sempre verificati di nuovo prima di prendere decisioni di capacità o budget.

Il vero cambiamento non è il modello: è il grafo di esecuzione

Con Multi-agent un root agent può creare subagent con contesti separati, inviare loro task, attendere risultati e sintetizzare la risposta finale. La documentazione indica come casi adatti codebase exploration, confronto di documenti o ipotesi, ricerca parallela e implementazione di componenti indipendenti.

                 /root
                   |
        +----------+----------+
        |          |          |
        v          v          v
 /researcher   /reviewer   /tester
        |          |          |
        +----------+----------+
                   |
                   v
               synthesis

OpenAI documenta sei primitive di collaborazione ospitate: creazione di subagent, messaging, follow-up, attesa, interrupt e listing dell'albero. Non c'è un limite fisso documentato al numero totale di subagent o alla profondità dell'albero; il controllo operativo è la concorrenza, con valore predefinito di tre subagent attivi contemporaneamente nella modalità Responses Multi-agent.

La documentazione è anche esplicita su quando non usare Multi-agent: catene strettamente sequenziali, task piccoli, workload dominati da una singola operazione esterna lenta, necessità di un execution graph deterministico o agenti che competono sulla stessa risorsa mutabile.

Una Amdahl's Law per gli agenti

Analisi. Aggiungere agenti non moltiplica automaticamente l'intelligenza né divide linearmente il tempo. Una stima concettuale può essere:

Ttotal ~= Torchestration
        + max(Tsubagents)
        + Ttools
        + Tmerge
        + Treconciliation

La parte parallelizzabile beneficia dei subagent. Tutto ciò che resta seriale — pianificazione, condivisione di contesto, merge, validazione, side effect — continua a porre un limite superiore al guadagno.

Il costo segue una logica ancora più evidente:

Ctotal ~= Croot
        + SUM(Csubagent)
        + Ctools
        + Cretries
        + Cescalations

OpenAI stessa avverte che i subagent possono aumentare l'uso di token. Per questo la metrica utile non è il prezzo per milione di token ma il cost-per-successful-task, idealmente insieme a latency percentile, tool failure rate, numero di retry e percentuale di escalation verso un modello più costoso.

Security boundary: tutti i subagent vedono gli stessi tool

Un dettaglio della documentazione Multi-agent merita attenzione: tutti gli agenti dell'albero hanno accesso ai tool configurati nella request. Questo semplifica l'orchestrazione ma ha una conseguenza di sicurezza.

Analisi. Se la policy richiede least privilege diverso per ruolo — per esempio un subagent può leggere dati ma non modificarli — un unico albero Multi-agent con lo stesso tool set non costituisce da solo quella separazione. Il controllo va spostato nel tool proxy, nel layer di authorization oppure in orchestrazioni separate con capability differenti.

Bad assumption:
subagent role == security boundary

Safer design:
agent intent
   |
   v
authorization / policy
   |
   v
tool capability
   |
   v
side effect

La stessa cautela vale per computer use. Nell'Agents API il browser OpenAI-hosted richiede approvazione per accedere a nuove origin e l'applicazione gestisce i passaggi di autenticazione. La documentazione specifica però che l'approvazione di un origin non equivale alla conferma di ogni singola azione. Se un'operazione consequenziale deve richiedere approvazione — acquisto, modifica o cancellazione — il sistema deve introdurre una barriera specifica oppure usare un ambiente dove tali azioni non siano possibili senza un ulteriore controllo.


Il trend: runtime, representation e orchestration stanno convergendo

È interessante mettere insieme i quattro temi.

.NET 11
source decomposition
      -> runtime/JIT optimization

ArcGIS embeddings
raw spatial data
      -> learned representation

Experience Builder Skills
framework documentation
      -> agent procedural context

Multi-Agent
single model call
      -> dynamic execution graph

VISIONE. Il salto architetturale dei prossimi anni potrebbe non derivare solo da linguaggi o modelli più potenti. Potrebbe derivare dal fatto che sistemi di esecuzione, framework e toolchain iniziano a conservare intenzione e semantica più a lungo.

Il compilatore non distrugge subito tutta la semantica di async: una parte arriva al runtime. Il GIS non riduce il luogo a un insieme di colonne: conserva una rappresentazione appresa del contesto. La documentazione non resta soltanto testo per umani: diventa un artefatto operativo per il coding agent. Il modello non restituisce soltanto testo: costruisce un grafo di subtask e tool call.

Quando più informazione sopravvive fino al layer che prende decisioni, quel layer può ottimizzare meglio. Ma cresce anche la responsabilità di definire confini, authorization, observability e validazione.


Technical Takeaways

  • .NET 11 Runtime Async: il passaggio del lowering verso runtime/JIT apre ottimizzazioni che il compilatore C# non poteva fare attraverso più confini async. È opt-in e va misurato, non attivato per fede.
  • JIT e GC: escape analysis, guarded devirtualization, PGO, loop analysis e write-barrier optimization mostrano che molta performance futura dipenderà da quanto il runtime riesce a dedurre, non da micro-ottimizzazioni manuali nel sorgente.
  • Embeddings GIS: distanza geografica e distanza semantica sono segnali diversi. I workflow più interessanti probabilmente li useranno insieme, ma senza confonderli nello stesso spazio matematico.
  • Cross-modal GeoAI: imagery -> semantic mask -> point cloud classification dimostra che il modello può operare nella modalità con segnale migliore e trasferire il risultato verso un'altra rappresentazione geospaziale.
  • Agent Skills: il valore non è generare boilerplate; è rendere esplicita la conoscenza procedurale del framework. Il passo successivo è affiancare al vendor skill un repository skill e controlli CI eseguibili.
  • Multi-Agent: parallelizzare subtask indipendenti può ridurre il wall-clock time, ma aumenta token, coordinamento e failure mode. Misurare cost-per-successful-task, non soltanto cost-per-token.
  • Security: un subagent non è automaticamente un security principal. La capacità reale è determinata dai tool e dalle authorization policy che proteggono i side effect.

Lab della settimana

Lab 1 — Runtime async: misurare prima di credere

Creare un piccolo servizio o benchmark con una catena di 5-10 helper async che alternano completion sincrona e reale sospensione I/O. Compilarlo in tre configurazioni: .NET 10, .NET 11 con lowering classico, .NET 11 con runtime-async=on.

Misurare almeno:

  • mean e p95/p99 latency;
  • allocated bytes/op con BenchmarkDotNet;
  • dimensione assembly;
  • GC collections;
  • profilo async.

Riferimenti: Performance Improvements in .NET 11 e .NET 11 RC1.

Lab 2 — Spatial vs semantic proximity

Prendere un embedding dataset ArcGIS e scegliere una feature di riferimento. Costruire tre ranking:

  1. solo distanza geografica;
  2. solo similarity in embedding space;
  3. spatial candidate filter + semantic ranking.

Confrontare la top-10 e osservare quali feature sono geograficamente vicine ma semanticamente lontane e quali sono lontane sulla mappa ma vicine nello spazio degli embedding. Ripetere a due scale diverse per verificare l'effetto della risoluzione.

Riferimenti: Embeddings in ArcGIS Pro e best practice Esri sugli embedding.

Lab 3 — Agent Skill A/B test su Experience Builder

Dare lo stesso task a un coding agent in tre condizioni:

  1. senza skill;
  2. con arcgis-exb-widget-dev di Esri;
  3. con skill Esri + un piccolo repository skill locale che descriva convenzioni, versioni supportate e criteri di accettazione.

Non valutare il risultato a occhio. Registrare:

  • build riuscita al primo tentativo;
  • uso corretto delle API Experience Builder;
  • numero di correzioni manuali;
  • warning TypeScript/ESLint;
  • compatibilità con widget e map interaction già presenti;
  • token e tool call;
  • tempo fino a un test end-to-end superato.

Riferimenti: Esri Agent Skill, SDK resources repository e Experience Builder widget development.


Fonti primarie