ETL non strutturato: l'approccio all'integrazione richiesto dall'IA aziendale

La maggior parte dei dati aziendali è di tipo non strutturato. La maggior parte delle pipeline ETL li ignora. Ecco come si può colmare questa lacuna.

Quando la maggior parte dei team parla di ETL, in genere pensa ai dati relazionali: tabelle, schemi, chiavi esterne. Un sistema di origine, una fase di trasformazione, una destinazione pulita. Si tratta di un problema ben noto, con soluzioni ben note.

I dati non strutturati rappresentano un problema a sé stante. File PDF, contratti, conversazioni via e-mail, ticket di assistenza, trascrizioni audio, immagini, pagine HTML, registri in formato libero. Questi contenuti costituiscono una parte significativa dei dati effettivamente detenuti dalla maggior parte delle aziende, eppure i classici strumenti ETL non tentano nemmeno di gestirli.

Questa mancanza di visibilità sta diventando un ostacolo. I casi d’uso dell’intelligenza artificiale su cui le organizzazioni stanno investendo oggi richiedono l’accesso alle fonti di dati non strutturati su cui si basa effettivamente l’attività aziendale. Ad esempio, forse:

• Il flusso di lavoro di contract intelligence deve essere in grado di leggere i file PDF
• L'intelligenza artificiale dedicata al servizio clienti deve elaborare i ticket e le registrazioni delle chiamate 
• Il sistema di monitoraggio della conformità deve analizzare i documenti relativi alle politiche e segnalare eventuali scostamenti

Se il tuo livello di integrazione non è in grado di gestire questi input, il livello di IA (che dipende da esso) non può svolgere il proprio compito in modo efficace.

In cosa consiste effettivamente l’ETL non strutturato

L'ETL strutturato è un problema di pipeline. L'ETL non strutturato è qualcosa di diverso: un problema di comprensione con una pipeline alla base.

Già la fase di estrazione non è affatto banale. Un PDF può essere un’immagine scansionata, un documento nativo o una combinazione di entrambi. Un contratto può contenere tabelle, annotazioni scritte a mano e allegati. Una conversazione via e-mail può fare riferimento a un documento archiviato in un sistema separato. Prima che possa avvenire qualsiasi trasformazione, il contenuto grezzo deve essere analizzato, sottoposto a OCR ove necessario e segmentato in unità significative.

Segue poi l’inferenza della struttura. Di cosa tratta questo documento? A quali entità fa riferimento? Quali sono i campi chiave rilevanti per i sistemi a valle? Nel caso dei dati strutturati, è lo schema a fornire le risposte a queste domande. Per i dati non strutturati, invece, il livello di estrazione deve dedurne le risposte, solitamente ricorrendo a una combinazione di regole, riconoscimento delle entità denominate e, sempre più spesso, modelli linguistici di grandi dimensioni.

Infine, l'output deve essere indirizzato verso una destinazione utile. Un archivio vettoriale per la ricerca semantica. Un database relazionale per la reportistica. Un'applicazione a valle che richiede un formato specifico dei dati. Le fasi di trasformazione e caricamento sono ben note, ma l'utilizzabilità dei risultati dipende interamente dalla qualità di ciò che è emerso dal livello di comprensione.

Dove le imprese incontrano difficoltà: le cause di fallimento

Definire una strategia per l'ETL non strutturato è solo metà dell'opera. È proprio nel passaggio alla produzione che la maggior parte delle aziende incontra difficoltà. Ecco le cause di fallimento più comuni che compromettono le pipeline di dati per l'IA.

Espansione delle soluzioni puntuali

La modalità di fallimento più comune è la proliferazione di soluzioni isolate. Un team sviluppa uno script Python per estrarre dati dai PDF. Un altro team utilizza uno strumento diverso per l’elaborazione delle e-mail. Un terzo team gestisce l’acquisizione dei documenti manualmente. Nessuno di questi processi condivide controlli di monitoraggio, gestione degli errori, tracciabilità della provenienza dei dati o governance. Il risultato è un insieme di pipeline fragili e invisibili che si interrompono silenziosamente e sono impossibili da sottoporre a audit. Quando un modello di IA a valle produce un risultato errato, risalire a un problema di qualità dei dati in uno script di estrazione non documentato è un’impresa a sé stante.

Sottostima del volume

La seconda causa di fallimento consiste nel sottovalutare il problema del volume. I dati non strutturati non arrivano in lotti a intervalli prevedibili, ma si accumulano continuamente. Le richieste di assistenza arrivano 24 ore su 24. I contratti vengono conclusi in base alle tempistiche delle trattative, non ai programmi del team di integrazione. Un’architettura di elaborazione che funziona bene con 1.000 documenti al giorno potrebbe non reggere con 100.000.

Ignorare i permessi

La terza causa di errore consiste nel trascurare l’importanza delle autorizzazioni e degli ACL. Tutti questi documenti sono soggetti ad autorizzazioni nel luogo in cui si trovano, sia che si tratti di un archivio di file sia che siano allegati a qualche altro oggetto (un biglietto, un’e-mail o un record in un CRM). Tali autorizzazioni devono essere rispettate e trasferite insieme alle informazioni estratte dal documento, per evitare che l’acquisizione diventi una fonte di fughe di dati che dovrebbero essere soggetti a restrizioni o che potrebbero essere soggetti a normative.

Impostalo e non pensarci più 

L'ultimo errore da evitare è considerare l'ETL non strutturato come un'operazione una tantum. I formati dei documenti cambiano. I sistemi di posta elettronica vengono sostituiti. Compaiono nuove fonti di dati. Una capacità duratura richiede pipeline che siano resistenti a questi cambiamenti e che possano essere aggiornate, testate e sottoposte a controllo delle versioni. Gli script di estrazione una tantum non sono sufficienti nel lungo periodo. 

Come si presenta un approccio pronto per la produzione

Il punto di partenza consiste nel considerare l'estrazione non strutturata come un tipo di pipeline a tutti gli effetti, non come un'eccezione da gestire al di fuori della piattaforma di integrazione principale. Ciò significa che le stesse funzionalità di authoring visivo, monitoraggio, avvisi, logica di riprova e tracciamento della provenienza che si applicano alle pipeline strutturate valgono anche in questo caso.

SnapLogic soddisfa questo requisito grazie a una combinazione di Snap nativi per l’elaborazione dei documenti, pipeline di estrazione collegate a modelli di linguaggio di grandi dimensioni (LLM) e un framework di metadati che trasporta le informazioni di provenienza dalla fonte alla destinazione. Una pipeline che acquisisce i contratti è in grado di estrarre date chiave, parti coinvolte, obblighi e clausole penali, convalidare l’output rispetto a uno schema e instradare il risultato al sistema a valle corretto, il tutto all’interno dello stesso livello di orchestrazione utilizzato per la replica dei database e l’integrazione delle API.

Il vantaggio pratico è la coerenza operativa. Il team che monitora la pipeline di sincronizzazione con Salesforce utilizza la stessa dashboard per monitorare la pipeline di acquisizione dei contratti. Le anomalie vengono segnalate in un unico punto. Le query di tracciabilità funzionano su fonti sia strutturate che non strutturate. I team addetti alla conformità possono verificare i flussi di dati senza dover capire quali script personalizzati vengano eseguiti e dove.

Il ruolo dei modelli di linguaggio di grandi dimensioni (LLM) nel livello di estrazione

I modelli linguistici di grandi dimensioni hanno rivoluzionato le possibilità offerte dall'estrazione di dati non strutturati. Compiti che in precedenza richiedevano un'elaborata progettazione di regole, come l'estrazione di clausole da formati contrattuali non standard o la classificazione dell'intento di messaggi di assistenza in formato libero, possono ora essere gestiti tramite una chiamata al modello, opportunamente guidata da un prompt, all'interno della pipeline.

La chiave sta nel considerare le chiamate agli LLM come componenti di una pipeline, applicando la stessa disciplina operativa di qualsiasi altra fase. Ciò significa definire gli schemi di input, convalidare gli output, gestire gli errori in modo corretto e ricorrere alla cache, ove opportuno, per contenere i costi. Una fase di estrazione tramite LLM che viene eseguita senza una logica di convalida o di riprova rappresenta un rischio. Una fase correttamente strumentata, invece, costituisce una funzionalità affidabile su cui i processi aziendali fondamentali possono fare affidamento.

Il livello di integrazione basato sull'intelligenza artificiale di SnapLogic rende le chiamate agli LLM elementi fondamentali delle pipeline. I modelli dei principali fornitori si collegano tramite gli Snap, con funzionalità configurabili di riprova, analisi dell'output e instradamento a valle. I team possono creare pipeline di estrazione che richiamano un LLM per l'analisi del testo e quindi instradano l'output strutturato verso qualsiasi destinazione, senza bisogno di codice di orchestrazione personalizzato.

Integrazione OEM e embedded: un’opportunità per gli ISV e i produttori di piattaforme

L'ETL non strutturato è una funzionalità altrettanto utile sia per i reparti IT aziendali che per i fornitori di software, che possono integrarla direttamente nei propri prodotti. Si pensi ai settori in cui i flussi di lavoro con un elevato volume di documenti sono la norma. Ad esempio, la tecnologia legale, il settore assicurativo, quello sanitario, i servizi finanziari, le piattaforme di approvvigionamento e la gestione del ciclo di vita dei contratti. 

In ciascuno di questi mercati, i clienti chiedono ai fornitori non solo di archiviare i documenti, ma anche di utilizzarli in modo intelligente: estrarre i termini chiave, segnalare le anomalie, compilare automaticamente i campi ed evidenziare le clausole rilevanti.

I fornitori in grado di rispondere a questa domanda grazie a una funzionalità nativa, anziché richiedere il collegamento a uno strumento di terze parti, godono di un vantaggio competitivo significativo. E il percorso più rapido per ottenere tale funzionalità consiste nell’integrare un livello di integrazione ed estrazione collaudato, anziché svilupparne uno da zero.

Il programma OEM di SnapLogic consente ai fornitori di software di integrare direttamente nelle proprie piattaforme tutte le funzionalità di integrazione ed ETL, compresa l’elaborazione dei dati non strutturati. L’esperienza è offerta in white label e implementata all’interno dell’infrastruttura del fornitore stesso. I clienti interagiscono con una funzionalità nativa, non con uno strumento di integrazione separato. Il fornitore controlla l’interfaccia, mentre SnapLogic garantisce la profondità.

Per i team di prodotto che stanno valutando come integrare funzionalità di analisi dei documenti nella propria piattaforma, la scelta tra “sviluppo in-house” e “integrazione” si riduce solitamente ai costi di manutenzione nel tempo. Sviluppare uno stack di estrazione personalizzato significa assumersi la responsabilità del livello OCR, dell’orchestrazione dei modelli di linguaggio di grandi dimensioni (LLM), dell’ecosistema dei connettori, dell’infrastruttura di monitoraggio e dei controlli di conformità. 

Integrare SnapLogic significa rendere disponibili tali funzionalità fin dal primo giorno e dedicare le risorse ingegneristiche a ciò che contraddistingue il prodotto, anziché alle infrastrutture di base.

Dalla teoria alla pipeline: primi passi

Il punto di partenza concreto per la maggior parte dei team consiste nell’identificare due o tre tipi di documenti ad alto volume che attualmente richiedono una gestione manuale o l’utilizzo di script fragili e disgiunti. Contratti, fatture e ticket di assistenza sono punti di partenza comuni. La creazione di una pipeline di estrazione regolamentata e monitorata per tali fonti genera un modello riutilizzabile che si estende al caso d’uso successivo senza dover ripartire da zero.

Per i team di prodotto, la domanda è: quali funzionalità di IA presenti nella vostra roadmap dipendono dall'accesso a documenti o a dati non strutturati, e se intendete sviluppare o integrare la funzionalità necessaria a supportarle.

In ogni caso, il principio di fondo è lo stesso. L'efficacia dei flussi di lavoro basati sull'intelligenza artificiale dipende interamente dal livello di accesso ai dati su cui si fondano. Realizzare correttamente quel livello, includendo sia fonti strutturate che non strutturate, è il lavoro che rende possibile tutto il resto.

Sei pronto a vederlo in azione? Segui una visita guidata autonoma del prodotto oppure prenota una demo per incontrare un esperto di integrazioni SnapLogic e discutere dell'ETL non strutturato per il tuo ambiente o il tuo prodotto.