Iterare come un modello: cosa ho imparato (io) mentre ri‑addestravo AI Builder

La parte più istruttiva di un progetto “con AI” non è quando funziona. È quando quasi funziona: abbastanza da vedere il potenziale, ma non ancora da fidarsi dei dettagli. Nel mio caso, il progetto era molto concreto: prendere PDF di prenotazioni hotel (scaricati da Booking) e trasformarli in righe strutturate in Excel tramite un flusso Power Automate, con un modello AI Builder che estrae campi come nome hotel, costo totale, data di check‑in e data di check‑out.

Il flusso, a un certo punto, faceva già “la magia” che volevo: carico un PDF, e in automatico compaiono valori in tabella. Però c’era un dettaglio che stonava: l’hotel e il costo venivano estratti, mentre le date (check‑in e check‑out) rimanevano vuote o incoerenti. E lì mi è venuta la domanda tipica di chi sta ancora cercando la mappa mentale giusta: “Devo rifare il flusso? Devo sostituire il componente addestrato? Devo ricominciare da capo?”.

La risposta è stata un “no” netto, quasi educativo: guai rifare tutto. Se l’architettura è corretta, non si butta via l’infrastruttura per un errore del componente “apprendente”. Si itera sul componente, lo si aggiusta, lo si ri‑addestra, lo si ritesta. In altre parole: si separa ciò che deve restare stabile da ciò che deve imparare.

Qui sta il parallelismo che mi ha colpito: mentre io attraversavo i miei inciampi (confusione, errori, frustrazione, tentazione di “resettare”), anche AI Builder stava facendo la stessa cosa, ma in modo formale. Io imparavo per iterazioni successive; il modello imparava per retraining.

Per rendere il concetto preciso, vale la pena definire i pezzi in modo esplicito:

• Un flusso Power Automate è una pipeline deterministica: trigger → recupero file → chiamata al modello → scrittura su Excel. Se questa catena è ben impostata, è un asset stabile.

• Un modello AI Builder di Document Processing è un componente statistico addestrato su esempi: sbaglia dove gli esempi sono ambigui, scarsi o “etichettati” male. È per definizione un asset iterativo, non definitivo al primo colpo.

Questa distinzione è una “distinzione forte” perché cambia il modo di lavorare: non è “o funziona o non funziona”. È “funziona il flusso, e migliora il modello”.

Le date di Booking sono un ottimo banco di prova perché non sono solo numeri: spesso sono incastonate in testo, con formati variabili (giorno della settimana, orari, preposizioni). Nei PDF che ho usato, la struttura tipica è esplicita: “ARRIVO …” e “PARTENZA …” con le date subito dopo. In un esempio, si vede chiaramente la coppia ARRIVO/PARTENZA nello stesso blocco informativo. In un altro, ARRIVO e PARTENZA includono anche intervalli orari.

Ed è qui che spesso nasce l’errore “umano” che si trasferisce al modello: quando etichetti un campo in AI Builder, la tentazione è contornare “tutto ciò che sembra rilevante”, inclusa l’etichetta (ARRIVO/PARTENZA) e magari anche l’orario. Ma per un modello di estrazione campi, questo può diventare rumore: il modello non sta imparando “che cos’è una data”, sta imparando un pattern visivo‑testuale. Se quel pattern cambia anche solo un po’ (un giorno della settimana presente in alcuni PDF e assente in altri; l’orario scritto diversamente; spaziatura diversa), la predizione può collassare su null.

Il punto non è “fare più training” in astratto. Il punto è migliorare la qualità del training, cioè la coerenza delle etichette. Nel mio caso, la correzione è stata concettualmente semplice: per check‑in e check‑out, contornare solo il valore, non l’etichetta e non elementi accessori. Nei documenti Booking questo significa: contornare la data (ad esempio “25 MAGGIO”) e lasciare fuori “ARRIVO” e “PARTENZA”.

Questo è il criterio operativo che mi porto via: quando un campo è instabile, riduci l’ambiguità dell’etichetta. In pratica:

1. tieni stabile la pipeline (flusso) e agisci sul modello;

2. rivedi come hai “contornato” i valori;

3. ri‑addestra;

4. ritesta sullo stesso set e poi su un PDF diverso.

È qui che il parallelismo diventa quasi narrativo: anche io, nel percorso, ho avuto momenti di confusione e reazioni “di pancia” (la voglia di buttare via tutto e rifare). Ma la soluzione non è stata l’eroismo tecnico: è stata l’iterazione paziente. Un passo alla volta. Prova e riprova. Con l’idea chiara che gli errori non sono un fallimento del progetto: sono dati di addestramento, per il modello e per chi lo usa.

C’è anche un effetto collaterale interessante: quando capisci che “non devo rifare il flusso”, inizi a progettare meglio fin dall’inizio. Costruisci una base robusta (trigger, recupero contenuto, tabella Excel) e poi accetti che la parte intelligente si perfeziona nel tempo. Questo approccio è più vicino all’ingegneria che alla magia: è manutenzione, miglioramento continuo, osservazione.

Alla fine, la soddisfazione non è solo “ha funzionato”. È “ho capito come farlo funzionare anche la prossima volta, su un altro documento, con un altro campo difficile”. E forse è questa la lezione più utile: l’automazione intelligente non elimina l’apprendimento; lo sposta dentro un processo.

Sintesi dei punti chiave: il flusso va progettato per restare stabile; il modello va progettato per essere iterato; se un campo (come le date) fallisce, non si resetta tutto: si migliora l’etichettatura e si ri‑addestra sullo stesso modello.

Domanda finale: in quale parte dei tuoi processi oggi stai “rifacendo tutto da capo”, quando basterebbe capire quale componente va solo ri‑addestrato?