Caso di studio: descrizioni non strutturate della posizione degli incidenti automobilistici
Raccolta e preparazione dei dati
Per testare e quantificare le capacità di geocodifica degli LLM, un elenco di 100 descrizioni di luoghi non strutturati di incidenti automobilistici in Minnesota è stato selezionato casualmente da un set di dati prelevato dal database. ragnatela. Le coordinate della verità a terra per tutti i 100 incidenti sono state create manualmente attraverso l’uso di varie applicazioni di mappatura come Google Maps e il Dipartimento dei trasporti del Minnesota Applicazione di mappatura del traffico (TMA).
Di seguito sono riportate alcune descrizioni di località di esempio.
US Hwy 71 a MN Hwy 60, WINDOM, contea di Cottonwood
EB Highway 10 vicino a Joplin St NW, ELK RIVER, contea di Sherburne
EB I 90 / HWY 22, FOSTER TWP, contea di Faribault
Autostrada 75 miglia, punto 403, SAINT VINCENT TWP, contea di Kittson
65 Highway / King Road, BRUNSWICK TWP, contea di Kanabec
Come visto negli esempi sopra, esiste un’ampia varietà di possibilità su come strutturare la descrizione, nonché su cosa definisce la posizione. Un esempio di ciò è la quarta descrizione, che presenta un numero di riferimento del miglio, che è molto meno probabile che venga trovato in qualsiasi tipo di processo di geocodifica, poiché tale informazione in genere non è inclusa in alcun tipo di dati di riferimento. La ricerca delle coordinate reali per descrizioni come questa si è basata in gran parte sull’uso del sistema di riferimento lineare (LRS) del Dipartimento dei trasporti del Minnesota, che fornisce un approccio standardizzato su come vengono misurate le strade in tutto lo Stato, con il quale gli indicatori di miglio svolgono un ruolo vitale in. È possibile accedere a questi dati tramite l’applicazione TMA menzionata in precedenza.
Metodologia e strategie di geocodificazione
Dopo aver preparato i dati, sono stati impostati cinque notebook separati per testare diversi processi di geocodifica. Le loro configurazioni sono le seguenti.
1. API di geocodificazione di Google, utilizzata nella descrizione grezza della posizione
2. API Esri Geocoding, utilizzata nella descrizione grezza della posizione
3. API di geocodificazione di Google, utilizzata su una descrizione di posizione standardizzata OpenAI GPT 3.5
4. API Esri Geocoding, utilizzata su una descrizione della posizione standardizzata OpenAI GPT 3.5
5. OpenAI GPT 3.5, utilizzato come geocodificatore stesso
Per riassumere, le API di geocodificazione di Google ed Esri sono state utilizzate sia sulle descrizioni grezze sia sulle descrizioni standardizzate utilizzando un breve prompt passato al modello OpenAI GPT 3.5. Il codice Python per questo processo di standardizzazione può essere visto di seguito.
def standardize_location(df, description_series):
df("ai_location_description") = df(description_series).apply(_gpt_chat)return df
def _gpt_chat(input_text):
prompt = """Standardize the following location description into text
that could be fed into a Geocoding API. When responding, only
return the output text."""
response = openai.ChatCompletion.create(
model="gpt-3.5-turbo",
messages=(
{"role": "system", "content": prompt},
{"role": "user", "content": input_text},
),
temperature=0.7,
n=1,
max_tokens=150,
stop=None,
)
return response.choices(0).message.content.strip().split("\n")(-1)
I quattro casi di test che utilizzano API di geocodifica hanno utilizzato il codice seguente per effettuare richieste API ai rispettivi geocodificatori e restituire le coordinate risultanti per tutte le 100 descrizioni.
# Esri Geocoder
def geocode_esri(df, description_series):
df("xy") = df(description_series).apply(
_single_esri_geocode
)df("x") = df("xy").apply(
lambda row: row.split(",")(0).strip()
)
df("y") = df("xy").apply(
lambda row: row.split(",")(1).strip()
)
df("x") = pd.to_numeric(df("x"), errors="coerce")
df("y") = pd.to_numeric(df("y"), errors="coerce")
df = df(df("x").notna())
df = df(df("y").notna())
return df
def _single_esri_geocode(input_text):
base_url = "https://geocode-api.arcgis.com/arcgis/rest/services/World/GeocodeServer/findAddressCandidates"
params = {
"f": "json",
"singleLine": input_text,
"maxLocations": "1",
"token": os.environ("GEOCODE_TOKEN"),
}
response = requests.get(base_url, params=params)
data = response.json()
try:
x = data("candidates")(0)("location")("x")
y = data("candidates")(0)("location")("y")
except:
x = None
y = None
return f"{x}, {y}"
# Google Geocoder
def geocode_google(df, description_series):
df("xy") = df(description_series).apply(
_single_google_geocode
)df("x") = df("xy").apply(
lambda row: row.split(",")(0).strip()
)
df("y") = df("xy").apply(
lambda row: row.split(",")(1).strip()
)
df("x") = pd.to_numeric(df("x"), errors="coerce")
df("y") = pd.to_numeric(df("y"), errors="coerce")
df = df(df("x").notna())
df = df(df("y").notna())
return df
def _single_google_geocode(input_text):
base_url = "https://maps.googleapis.com/maps/api/geocode/json"
params = {
"address": input_text,
"key": os.environ("GOOGLE_MAPS_KEY"),
"bounds": "43.00,-97.50 49.5,-89.00",
}
response = requests.get(base_url, params=params)
data = response.json()
try:
x = data("results")(0)("geometry")("location")("lng")
y = data("results")(0)("geometry")("location")("lat")
except:
x = None
y = None
return f"{x}, {y}"
Inoltre, un processo finale testato prevedeva l’utilizzo di GPT 3.5 come geocodificatore stesso, senza l’ausilio di alcuna API di geocodifica. Il codice per questo processo sembrava quasi identico al codice di standardizzazione utilizzato sopra, ma presentava un prompt diverso, mostrato di seguito.
Geocodifica il seguente indirizzo. Restituisci la latitudine (Y) e la longitudine (X) nel modo più accurato possibile. Quando rispondi, restituisci solo il testo di output nel seguente formato: X, Y
Metriche e approfondimenti sulle prestazioni
Dopo aver sviluppato i vari processi, ciascun processo è stato eseguito e sono stati calcolati diversi parametri prestazionali, sia in termini di tempo di esecuzione che di precisione della geocodifica. Queste metriche sono elencate di seguito.
| Geocoding Process | Mean | StdDev | MAE | RMSE |
| ------------------- | ------ | ------ | ------ | ------ |
| Google with GPT 3.5 | 0.1012 | 1.8537 | 0.3698 | 1.8565 |
| Google with Raw | 0.1047 | 1.1383 | 0.2643 | 1.1431 |
| Esri with GPT 3.5 | 0.0116 | 0.5748 | 0.0736 | 0.5749 |
| Esri with Raw | 0.0001 | 0.0396 | 0.0174 | 0.0396 |
| GPT 3.5 Geocoding | 2.1261 | 80.022 | 45.416 | 80.050 |
| Geocoding Process | 75% ET | 90% ET | 95% ET | Run Time |
| ------------------- | ------ | ------ | ------ | -------- |
| Google with GPT 3.5 | 0.0683 | 0.3593 | 3.3496 | 1m 59.9s |
| Google with Raw | 0.0849 | 0.4171 | 3.3496 | 0m 23.2s |
| Esri with GPT 3.5 | 0.0364 | 0.0641 | 0.1171 | 2m 22.7s |
| Esri with Raw | 0.0362 | 0.0586 | 0.1171 | 0m 51.0s |
| GPT 3.5 Geocoding | 195.54 | 197.86 | 199.13 | 1m 11.9s |
Le metriche sono spiegate più dettagliatamente qui. La media rappresenta l’errore medio (in termini di distanza di Manhattan, o la differenza totale di X e Y dalla verità fondamentale, in gradi decimali). StdDev rappresenta la deviazione standard dell’errore (in termini di distanza di Manhattan, in gradi decimali). MAE rappresenta l’errore medio assoluto (in termini di distanza di Manhattan, in gradi decimali). RMSE rappresenta l’errore quadratico medio (in termini di distanza di Manhattan, in gradi decimali). 75%, 90%, 95% ET rappresenta la soglia di errore per quella data percentuale (in termini di distanza euclidea, in gradi decimali), il che significa che per una data percentuale, quella percentuale di record rientra nella distanza del valore risultante dalla verità fondamentale . Infine, il tempo di esecuzione rappresenta semplicemente il tempo totale impiegato per eseguire il processo di geocodifica su 100 record.
Chiaramente, GPT 3.5 ha prestazioni molto peggiori da solo. Tuttavia, se si eliminano dal quadro un paio di valori anomali (che sono stati etichettati dal modello come situati in altri continenti), per la maggior parte i risultati di quel processo non sembrano troppo fuori posto, almeno visivamente.
È anche interessante vedere che il processo di standardizzazione LLM in realtà ha ridotto la precisione, cosa che personalmente ho trovato un po’ sorprendente, dal momento che la mia intenzione di introdurre quel componente era, si spera, di migliorare leggermente la precisione complessiva del processo di geocodificazione. Vale la pena notare che i prompt stessi avrebbero potuto essere una parte del problema in questo caso, e vale la pena esplorare ulteriormente il ruolo del “prompt engineering” nei contesti geospaziali.
L’ultimo aspetto importante di questa analisi sono le differenze nei tempi di esecuzione, per cui qualsiasi processo che include l’uso di GPT 3.5 viene eseguito in modo significativamente più lento. Anche l’API di geocodifica di Esri è più lenta di quella di Google anche in questa impostazione. Tuttavia, non sono stati eseguiti test rigorosi, quindi questi risultati dovrebbero essere presi in considerazione.
Fonte: towardsdatascience.com
