Document intelligence

Il primo step della soluzione prevede una standardizzazione dei dati non strutturati in input, potenzialmente presenti in varie forme e risultato di processi più o meno complessi. Essi possono corrispondere a documenti di testo, immagini o, in contesti più moderni, essere il risultato di attività di web scraping, e non vanno tuttavia escluse situazioni peculiari in cui il dato sia contenuto in documenti cartacei.

Questa eterogeneità dei dati, sebbene debba essere tenuta in considerazione, non deve essere vista come un ostacolo o implicare onerose attività di pre-processing. Queste ultime, infatti, si concretizzeranno esclusivamente in una conversione in formato PDF del dato di partenza, attività che è possibile eseguire in maniera programmatica e con effort estremamente ridotto per qualsiasi tipologia di dato tra quelli precedentemente descritti.

La conversione del documento in PDF diviene condizione abilitante per la successiva applicazione di processi di OCR che, in maniera trasparente, permetteranno di estrarre informazioni testuali da documenti cartacei, immagini o pagine web, rendendo il testo accessibile ed interpretabile dai modelli di Artificial Intelligence ed, in particolare, LLM.

La soluzione finora descritta, dal punto di vista tecnologico, presenta molteplici modalità di implementazione, sfruttando ad esempio i servizi forniti dai principali Cloud Provider quali Textract per AWS o Azure Document Intelligence, dimostrando elasticità e potendosi quindi adattare agli stack tecnologici delle diverse realtà aziendali.

Estratto il contenuto testuale, è ora possibile spostarsi verso la sfera degli LLM per comprenderne il significato ed estrarre la porzione di interesse, potenzialmente rielaborata ed in un formato facilmente fruibile da sistemi a valle.  Controllare il formato dell’output restituito dall’LLM è un problema da non sottovalutare. Nella nostra architettura, suggeriamo di strutturare l’output e riversarlo all’interno di soluzioni di storage che abilitino successive analisi e ne consentano la fruizione da parte di più consumatori terzi in parallelo all’archiviazione del documento originario per riutilizzi futuri.

I modelli LLM possiedono la capacità di rispondere in modo linguistico preciso e accurato alle domande che vengono loro fornite, adottando la vasta conoscenza acquisita in fase di training. Questa abilità non solo consente loro di fornire risposte linguisticamente corrette, ma anche di presentare informazioni pertinenti e rilevanti per la persona con cui stanno interagendo e le domande che vengono poste.

Questo approccio, tuttavia, non è esente da problematiche e, tra queste, figura il knowledge cutoff.

Il problema del Knowledge CutOff è associato alla limitazione dei modelli nel processo di aggiornamento della propria base di conoscenze al di là delle fasi di addestramento, assumendo un ruolo critico quando si intende impiegare modelli di LLM internamente all’ambito aziendale, essendo incapaci di incorporare nuove informazioni in modo dinamico ed esteso.

Allenare un modello da zero è un processo complesso ed estremamente costoso. Allo stesso tempo estendere un modello esistente per ampliarne il campo di conoscenza a un dominio specifico, attraverso la somministrazione di documenti pertinenti, è più agevole ma comunque caratterizzato da complessità non trascurabili. A tal proposito, corrono in nostro supporto le tecniche di Prompt Engineering.

Il prompt engineering si fonda sul processo di organizzazione della conversazione con il modello per guidarlo verso risposte accurate e pertinenti. In quanto modelli probabilistici, la strutturazione del contesto, e conseguentemente della conversazione, influisce direttamente sulla qualità e correttezza delle risposte.

I moderni modelli di LLM sono tuttavia vincolati dalla capacità di considerare solo una quantità limitata di testo per generare una risposta (context windows), pertanto non è fattibile riversare l’intero corpus di dati aziendali nel prompt e formulare domande all’LLM su una potenzialmente vasta gamma di informazioni.

Le tecniche di prompt engineering utilizzate per guidare gli LLM a ragionare e fornire risposte su dati non presenti nel loro training set devono quindi lottare con questo limite, trovando il metodo di selezionare solo le informazioni rilevanti da passare al prompt in funzione della domanda che si vuole porre.

Spesso, non è tuttavia possibile passare all’LLM l’intera ontologia e determinare dinamicamente la porzione più rilevante richiede la comparazione tra i suoi concetti e il contesto del prompt, un’operazione di per sè non banale.

Per svolgere questa attività è possibile dotarsi di un VectorDB, una tecnologia appositamente progettata per archiviare, interrogare ed estrarre dati vettoriali e che eccelle quindi nell’eseguire ricerche di similarità basate su embeddings, spesso definita con il termine Semantic Search. Nella pratica, vettori semanticamente simili vengono mappati in prossimità gli uni agli altri nello spazio degli embeddings, la ricerca per vicinanza tra vettori si traduce quindi in una ricerca semantica.

Il popolamento di un VectorDB avviene tramite processing dei dati operativi ed eterogenei, spesso non strutturati, del contesto aziendale, che vengono elaborati e convertiti in embeddings tramite modelli dedicati. Gli embeddings risultanti possono ora essere indicizzati all’interno di un VectorDB per facilitarne la successiva ricerca.

Ad oggi, è possibile scegliere il modello dedito alla produzione degli embedding in un panorama sempre più ampio di librerie o servizi offerti dai principali cloud provider. È tuttavia importante sottolineare come modelli differenti producono embeddings in spazi distinti e non generalmente comparabili: il cambio di un modello implica solitamente dover ripopolare l’intero VectorDB.