Assistente pendolare: orari veri di metro e tram a Roma (GTFS)
10 domande · scoring agentic · contaminazione none
Cosa misura
Il lavoro di un assistente pendolare su dati veri: 10 richieste in italiano («la prima metro utile per...», «l'ULTIMA corsa che mi fa arrivare entro...») da risolvere con 5 strumenti su uno snapshot congelato del servizio reale di metro e tram di Roma — il GTFS statico di Roma Mobilità, servizio di mercoledì 2026-07-01 (4 linee metro, 4 tram, 2.207 corse, 172 fermate). Nessun tool risolve il problema da solo: per sapere quando si arriva bisogna aprire la corsa e leggere; per un cambio bisogna concatenare due ricerche vincolate dall'orario d'arrivo della prima tratta; due task sono trappole impossibili (linea che non serve la fermata, vincolo d'orario fuori servizio) dove la risposta giusta è l'azione esplicita segnala_impossibile.
Ground truth eseguibile su mondo reale: le gold non sono scritte a mano — i check le ricalcolano eseguendo le stesse query sullo snapshot (stesso principio dello scoring agentic, ma su dati d'esercizio veri invece che su un catalogo sintetico). Itinerari equivalenti sono accettati (MEB e MEB1 condividono il tronco Termini→Laurentina: conta l'orario d'arrivo ottimo, non l'identità della corsa).
Com'è andata (secondo giro: i cloud)
Nove modelli cloud, e finalmente l'eval discrimina: in vetta a 10/10 ci sono Opus 4.8, Sonnet 4.6 e — la sorpresa — Haiku 4.5, perfetto a $0.26 a run. GPT-5.4 si ferma a 9/10 (sbaglia p2, l'«ultima corsa utile»), Qwen3-235B a 7/10, e i piccoli GPT trovano il muro: nano 5/10, mini 4/10 — sì, il mini sotto il nano. Con Gemma locale al 30%, la fotografia è netta: l'agentic multi-turn su orari veri premia la disciplina (leggere il risultato, incatenare la chiamata giusta, fermarsi al momento giusto), non la stazza.
p2 è la domanda killer: «l'ultima metro utile per arrivare entro le X» richiede di aprire le corse a ritroso con orario_corsa e verificare l'arrivo, non la partenza. La sbagliano GPT-5.4, Qwen, mini, nano — e a suo tempo Gemma. Chi la azzecca ha capito davvero la differenza tra partire e arrivare.
Quanto effort serve? Nessuno. Opus 4.8 provato anche a effort low e medium: sempre 10/10, e il costo quasi non scende ($1.15 vs $1.21) — sull'agentic il grosso dei token è il loop coi tool, non il ragionamento. La stessa prova su trap-it invece crolla a effort basso (67-70%): il lavoro da assistente operativo e i quiz-trappola chiedono ai modelli muscoli diversi.
Com'è andata (primo giro: solo il locale)
Apre Gemma-12B sul Jetson: 30% (3/10) — e il come vale più del numero. Nei log c'è un modello che risolve gli orari e sbaglia il modulo: in 7 task su 10 trova la corsa giusta al minuto esatto (la prima MEA delle 07:52, l'ultima MEB delle 23:52, il tram nella finestra giusta), ma quando compila salva_itinerario scrive la fermata di partenza anche nel campo di arrivo — itinerari «da Venezia a Venezia», «da Termini a Termini». Il voto binario sullo stato finale li boccia, giustamente: un assistente che ti salva un itinerario privo di senso ha fallito il compito, anche se sapeva la risposta. È la differenza tra sapere e fare che questo scorer esiste per misurare.
Il rovescio: le trappole sono 3/3 (con p2). Sui due task impossibili Gemma verifica coi tool e poi segnala, senza inventare — la stessa disciplina delle astensioni vista su faq-it. E su p1 l'unico vero fallimento di pianificazione: aveva trovato la corsa giusta e ha continuato a richiamare lo stesso strumento fino a esaurire i turni, senza mai concludere.
Controprova A/B sulla temperatura (due ripetizioni, entrambe in classifica: la media è la loro). Ipotesi: lo scambio di campo è rumore di sampling a temp 1.0? No — a temp 0.6 va peggio (20%): l'errore a_fermata=partenza compare in 7 salvataggi su 7, incluso il task che a 1.0 era riuscito. Abbassare la temperatura rende il modello più deterministico nel pattern sbagliato: compilare lo slot d'arrivo con l'id già maneggiato è il suo comportamento a massima probabilità, non una svista. Il difetto è strutturale — il function calling su schema annidato (l'unico tool con array di oggetti) — e infatti sui 4 tool a parametri piatti non sbaglia un argomento in venti traiettorie.
La barra, come previsto, è più alta che negli agentic sintetici — orari veri, al minuto, con cambi e direzioni.
Note di metodo
- Contaminazione:
noneper costruzione. Query autoriali, gold derivate dagli orari d'esercizio 2026: non esistono in nessun training set. È il primo eval del sito con questa proprietà su task agentici. - Snapshot versionato:
snapshot.json.gz(163 KB) committato nel repo con sha256 del feed sorgente; i check dipendono SOLO da esso, il feed vivo può cambiare o sparire. - Convenzioni dichiarate nel prompt: cambio valido se la seconda corsa parte a orario ≥ dell'arrivo della prima (nessun margine); orari dopo mezzanotte in notazione GTFS 24:xx. Tutto ciò che serve è detto al modello.
- Validazione pre-run: oracolo scriptato 10/10, agente pigro 0/10, 23 itinerari avversari respinti, doppia esecuzione deterministica (
scripts/check_pendolare.py). - Voto binario sullo stato finale: itinerario esatto al minuto (o segnalazione corretta). Niente crediti parziali: o l'assistente ti mette in tasca l'itinerario giusto, o no.