La demo funziona perché qualcuno ha scelto l'esempio
Chi prepara una dimostrazione sceglie un caso. Lo sceglie in buona fede, prendendo un esempio rappresentativo. Ma nel provarlo aggiusta le parole, riformula la richiesta, ripete finché non esce bene, e alla fine mostra il risultato migliore su un caso che si è dimostrato collaborativo.
In produzione l'input non lo scegliete voi. Arriva come arriva: un documento scansionato storto, un messaggio scritto male, una domanda che contiene due domande, un caso che nessuno aveva previsto perché succede tre volte l'anno. I casi difficili non sono una piccola percentuale sfortunata: sono la ragione per cui quel lavoro lo faceva una persona.
Le sette cose che stanno fra la demo e il prodotto
- Il recupero delle informazioni. In chat le informazioni le incollate voi. In produzione qualcosa deve decidere, per ogni richiesta, quali documenti servono, e recuperarli, e capire cosa fare se non ne trova. È spesso la parte più grande del sistema, e determina la qualità più del modello.
- Il formato. Una risposta in prosa va bene a un umano. A un altro sistema serve una struttura, sempre la stessa, valida al primo colpo. Serve una verifica del formato e una strategia per quando non è rispettato.
- La gestione degli errori. Il servizio non risponde, risponde tardi, risponde male, risponde di non poter rispondere. Quattro casi, quattro comportamenti da decidere. In chat li gestisce l'utente riprovando. In produzione li gestisce il vostro codice, o non li gestisce nessuno.
- I limiti di quello che entra. I documenti reali sono più lunghi degli esempi. Serve una strategia per il troppo lungo che non sia troncare in silenzio.
- Il costo a regime. Il costo per richiesta moltiplicato per il traffico vero, con le richieste vere, che sono più lunghe di quelle di prova. È il calcolo che ribalta la fattibilità di molti progetti, e va fatto prima.
- L'osservabilità. Cosa ha chiesto il sistema, cosa ha risposto, quanto ci ha messo, quanto è costato. Senza questi dati, il giorno in cui qualcosa peggiora non avete modo di sapere cosa è cambiato.
- La responsabilità. Chi risponde di un output sbagliato che è arrivato a un cliente. È una domanda organizzativa e va risposta prima del lancio, non dopo il primo incidente.
Perché la trappola è così comune
Perché la prima parte è diventata rapidissima e la seconda no.
Fino a qualche anno fa, arrivare a una dimostrazione funzionante richiedeva settimane. Quel tempo lungo faceva da filtro: chi ci arrivava aveva già affrontato i problemi veri. Oggi si arriva a una demo convincente in un pomeriggio, e il pomeriggio non insegna niente su cosa succede dopo.
Il risultato è una distorsione nelle aspettative: se quasi tutto il risultato è arrivato in un giorno, quel che manca sembra questione di qualche giorno in più. In realtà quel che manca è il grosso del lavoro. Chi ha esperienza di software lo sa da sempre, e vale qui esattamente come valeva prima: l'ultima parte visibile del risultato consuma la maggior parte del tempo.
Cosa cambia nel modo di lavorare
Tre conseguenze pratiche che applichiamo sui nostri progetti.
- La demo si fa sui casi peggiori, non sui migliori. Se funziona sui tre casi che nessuno vuole guardare, funziona. Se funziona solo sull'esempio bello, non sapete ancora niente.
- La valutazione viene prima dell'ottimizzazione. Senza un modo di misurare, ogni modifica alle istruzioni è una scommessa: sembra meglio su tre esempi e nessuno sa cosa ha rotto altrove.
- Il prompt è la parte meno stabile del sistema. Cambia versione del modello, cambia il comportamento. Per questo va trattato come un componente sotto controllo, con una sua storia e una sua batteria di verifiche, e non come una stringa incollata in mezzo al codice.
La posizione
C'è un mestiere che si è diffuso attorno alla scrittura delle richieste, e ha una sua utilità: saper formulare bene un problema è una competenza vera. Ma è una competenza, non un prodotto, e la distanza fra le due cose è esattamente la distanza fra saper cucinare e aprire un ristorante.
Quando qualcuno vi mostra una demo, la domanda utile non è come hai fatto il prompt. È: cosa succede quando l'input è brutto, e chi se ne accorge.
