Ho costruito un repository con cui lavorare sui dati

Doodle di una cartella trasformata in officina: una persona collega strumenti e controlla documenti, aiutata da un piccolo robot.

In una cartella ho messo degli script, le istruzioni per usarli, dei percorsi di analisi e un posto dove conservare quello che viene trovato. Poi ci ho fatto lavorare un agente IA, insieme a me.

Questa cosa l'ho usata per un'analisi vera. Alla fine sono rimasti le interrogazioni fatte, i risultati, un registro delle evidenze e un documento di analisi. Anche una copia dei dati usati, conservata separatamente, con un'impronta che permette di controllare che sia proprio quella.

È un repository Git. E mentre ci lavoravo mi sono reso conto che lo stavo usando come un software.

Detta così sembra che abbia trovato un uso molto complicato per una cartella 😀

Provo a spiegarmi.

Quando lavori sui dati di un sito puoi avere aperti Google Analytics, Search Console, Tag Manager e il sito stesso. Ognuno ti fa vedere un pezzo. Per capire qualcosa devi decidere quali pezzi prendere, portarli su periodi confrontabili, controllare cosa stai misurando e capire se la spiegazione che ti viene in mente regge anche guardandola da un'altra parte.

Una parte del lavoro è interrogare strumenti. Un'altra è sapere quale domanda fare dopo.

Ho provato a mettere queste due cose nello stesso ambiente.

Gli script permettono all'agente di interrogare le fonti e salvare i risultati. Le istruzioni gli dicono come lavorare: conservare la query, specificare periodo e filtri, distinguere un fatto da un'ipotesi. I percorsi di analisi raccolgono i controlli da fare per famiglie di domande. E il contesto del lavoro resta lì, insieme alle verifiche già fatte e a quello che ancora manca.

Per arrivarci ho dovuto scegliere quali operazioni rendere disponibili, come conservarne i risultati e quali verifiche chiedere prima di usare un'osservazione in una diagnosi. Dentro i percorsi di analisi ho messo anche conoscenza del mestiere: quali fonti confrontare, quali differenze approfondire, quando fermarsi perché manca un pezzo. Poi, usandoli, alcuni passaggi sono diventati codice riutilizzabile e altri sono rimasti valutazioni da fare insieme all'agente.

Io posso continuare la conversazione, chiedere di approfondire un punto o mettere in dubbio una lettura. L'agente ha degli strumenti con cui andare a vedere.

Il passaggio che mi interessa è questo: una domanda nella chat può diventare un'interrogazione eseguita, un file salvato, un controllo successivo. E quei passaggi rimangono disponibili anche dopo la risposta.

Per esempio, nel registro delle evidenze un'osservazione viene collegata alla sua fonte. Se voglio capire da dove arriva, posso tornare ai risultati e alla query che li ha prodotti. Quando ci sono osservazioni fatte direttamente nel browser o informazioni lette da un'interfaccia, si conserva quel tipo di provenienza: non tutto passa dalle API.

Questo obbliga anche a lasciare qualche vuoto.

Ci sono domande per cui i dati disponibili non bastano. Oppure una relazione sembra interessante, ma manca un controllo per poterci appoggiare sopra una spiegazione. Nell'ambiente ho previsto anche questa risposta: prove insufficienti. Almeno sappiamo dove si ferma ciò che possiamo sostenere.

L'IA può comunque leggere male un dato. E anche uno script può produrre un risultato sbagliato. Per questo il percorso comprende verifiche e il mio controllo prima del documento finale. Avere una fonte associata a una frase rende possibile controllarla; il controllo poi va fatto.

Poi c'è il passaggio al documento da consegnare. Il percorso arriva a un report Word, con tabelle e grafici generati dai dati. Per prepararlo bisogna scegliere quali osservazioni rispondono alla domanda iniziale, quali conclusioni possiamo sostenere e quali dubbi lasciare aperti. L'impaginazione segue regole definite e viene controllata prima della consegna. Chi legge può così seguire l'analisi senza dover entrare nella nostra cartella o ricostruire tutta la conversazione.

Anche il codice sta cambiando forma. Gli script costruiti per la prima esecuzione restano conservati con il lavoro che li ha usati; le operazioni riutilizzabili sono confluite in uno strumento comune. Così posso ripartire su un'altra analisi senza perdere il collegamento fra una conclusione precedente e il modo in cui era stata ottenuta.

È qui che il repository comincia a sembrarmi un oggetto diverso.

Il codice esegue le operazioni. Le istruzioni organizzano il lavoro. L'agente sceglie e usa gli strumenti durante la conversazione, con me che porto il contesto e verifico le interpretazioni. Git tiene insieme le versioni di questa struttura. I dati riservati stanno fuori dal versionamento.

Il comportamento viene fuori da come questi pezzi sono collegati.

Questo ambiente ha già prodotto un'analisi e un documento. Alcune parti sono ancora tarate sulla prima esecuzione; il riuso su lavori diversi va verificato, soprattutto dove entrano soglie, ipotesi e conoscenza del sito. È uno strumento interno che sto facendo evolvere mentre lo uso.

Ora mi interessa capire quanto del lavoro successivo potrò portare dentro la stessa struttura, e quali pezzi mi costringeranno a cambiarla.