Idea principale

L'articolo che descrive il motore di contesto portato su ChatGPT è stato preparato dentro quel motore: idee persistite, fonti ingerite, angoli ciechi individuati, attività create e poi chiuse, prima versione prodotta, riletta, poi ripresa in V2 dallo stesso contesto. Il sistema non è stato testato da uno scenario costruito per lui; gli è stato affidato il lavoro per cui esisteva.

La differenza non è di rigore ma di natura della prova. Una dimostrazione sceglie i propri dati e il proprio percorso — verifica che il cammino previsto funzioni. Un lavoro reale porta quello che nessuno aveva previsto: un'idea che arriva in disordine, una contraddizione tra due note, una ripresa diversi giorni dopo, un volume non anticipato. Sono queste situazioni a decidere se un sistema regge.

Perché è importante

Cambia quello che si può affermare alla fine. Dopo una dimostrazione si sa che il sistema fa quello che gli si è chiesto di mostrare. Dopo un lavoro reale portato fino al deliverable, la domanda «funziona?» è chiusa, e la domanda successiva diventa quella della crescita di carico — il che è un progresso, perché riguarda un uso e non una capacità.

E fornisce una disciplina pratica: scegliere come primo uso di un sistema quello che si deve comunque produrre, invece di un caso di scuola che non costa nulla abbandonare.

Sfumature e limiti

Un solo lavoro reale non esaurisce i regimi d'uso. Produrre un articolo in qualche giorno non dice nulla del comportamento di un contesto alimentato per diverse settimane, né di una settimana di campo intensa — e l'articolo lo riconosce esplicitamente.

E la prova è viziata dal suo operatore: chi ha costruito il sistema aggira senza pensarci quello che sa fragile. Il lavoro è reale, l'utente non del tutto.

Domande aperte

• Come distinguere, in un sistema messo alla prova dal suo autore, ciò che dipende dal sistema e ciò che dipende dagli aggiramenti che lui fa senza vederli?