Categories
Uncategorized

Estrazione Dati strutturati da Templatic Documenti

TheMummichogblog è un partecipante al Amazon Services LLC Associates programma, un programma di affiliazione pubblicitario progettato per fornire un mezzo per siti per guadagnare tariffe pubblicitarie con la pubblicità e il link al amazon.com. Amazon, il logo di Amazon, AmazonSupply, e il logo AmazonSupply sono marchi di Amazon.com, Inc. o delle sue affiliate.

Estrazione Dati strutturati da Templatic Documenti
Venerdì 12 Giugno 2020
Pubblicato da Sandeep Tata, Software Engineer, Google Ricerca

documenti Templatic, come ad esempio le ricevute, le fatture, le citazioni di assicurazione, e altri, sono estremamente comuni e critico in una vasta gamma di flussi di lavoro aziendali. Attualmente, l’elaborazione di questi documenti è in gran parte uno sforzo manuale e sistemi automatizzati che esistono sono basati su euristiche fragili e soggetti a errori. Si consideri un tipo di documento, come le fatture, che possono essere disposti in migliaia di modi diversi – fatture da diverse società, o anche diversi dipartimenti all’interno della stessa azienda, può avere la formattazione leggermente diverso. Tuttavia, v’è una comprensione comune delle informazioni strutturate che una fattura deve contenere, come ad esempio un numero di fattura, un data della fattura, l’importo dovuto, il pay-per data, e l’elenco delle voci per le quali è stata inviata la fattura. Un sistema in grado di estrarre automaticamente tutti questi dati ha il potenziale per migliorare notevolmente l’efficienza dei diversi flussi di lavoro aziendali, evitando soggetta a errori, il lavoro manuale.

--------------------------------------------------------------------------------------------------



Beato l'uomo che sopporta la tentazione, perché una volta superata la prova riceverà la corona della vita che il Signore ha promesso a quelli che lo amano.


Subscribe By E-mail:

Enter your email address:

Delivered by FeedBurner



----------------------------------------------------------------------------------------------

In “Rappresentanza di apprendimento per l’Information Extraction dal Modulo simile Documenti”, ha accettato di ACL 2020, presentiamo un approccio per estrarre automaticamente i dati strutturati da documenti Templatic. A differenza di precedenti lavori sull’estrazione da documenti di testo normale, proponiamo un approccio che utilizza la conoscenza dei tipi di campo di destinazione per identificare i campi candidati. Questi sono poi valutato con una rete neurale che apprende una rappresentazione densa di ciascun candidato con le parole nelle sue vicinanze. Esperimenti su due corpora (fatture e ricevute) dimostrano che siamo in grado di generalizzare bene ai layout invisibili.

Perché è così difficile?
La sfida in questo problema estrazione di informazioni nasce dal fatto che a cavallo della elaborazione del linguaggio naturale (NLP) e mondi computer vision. A differenza di compiti NLP classici, tali documenti non contengono “linguaggio naturale”, come potrebbe essere trovato nelle frasi e paragrafi normali, ma invece assomigliano forme. I dati vengono spesso presentati in tabelle, ma in aggiunta molti documenti avere più pagine, spesso con un numero variabile di sezioni, e hanno una varietà di layout e formattazione indizi per organizzare le informazioni. La comprensione del layout bidimensionale del testo sulla pagina è la chiave per la comprensione di tali documenti. D’altra parte, il trattamento di questa puramente come un problema di immagine segmentazione rende difficile sfruttare la semantica del testo.

Panoramica della soluzione
Il nostro approccio a questo problema consente agli sviluppatori di formare e implementare un sistema di estrazione per un dato dominio (come fatture) con due ingressi – uno schema di destinazione (ad esempio, un elenco di campi da estrarre e loro tipi corrispondenti) e una piccola raccolta di documenti etichettati con la verità a terra per l’uso come un insieme di addestramento. tipi di campi supportati includono nozioni di base, come ad esempio le date, numeri interi, codici alfanumerici, gli importi in valuta, telefono con i numeri e URL. Abbiamo anche prendere vantaggio di tipi di entità comunemente rilevati dal Google Knowledge Graph, come gli indirizzi, nomi di aziende, ecc

Il documento di input viene prima eseguito attraverso un servizio di riconoscimento ottico dei caratteri (OCR) per estrarre le informazioni di testo e il layout, che permette a questo di lavoro con documenti nativi digitali, come PDF e immagini dei documenti (ad esempio, documenti scansionati). Abbiamo poi eseguito un generatore candidato che individua campate del testo nell’output OCR che potrebbe corrispondere a un’istanza di un dato campo. I UTILIZZA generatore candidato preesistenti librerie associate a ogni tipo di campo (data, numero, telefono numero, ecc), che evita la necessità di scrivere nuovo codice per ogni generatore candidato. Ognuno di questi candidati viene poi valutato con una rete addestrata neurale (il “marcatore”, descritto di seguito) per stimare la probabilità che è davvero un valore si potrebbe estrarre per quel campo. Infine, un modulo assigner corrisponde ai candidati goal: i campi di destinazione. Per impostazione predefinita, l’assigner sceglie semplicemente il più alto punteggio candidato per il campo, ma ulteriori vincoli di dominio-specifici può essere incorporato, come la richiesta che il campo data della fattura è cronologicamente prima del campo data di pagamento.

L’elaborazione interviene il sistema di estrazione utilizzando uno schema giocattolo con due campi in un documento di fatturazione ingresso. scatole blu mostrano i candidati per le caselle di campo e oro invoice_date per il campo AMOUNT_DUE.
marcatore
Il marcatore è un modello neurale che è addestrato come un classificatore binario. Prende in ingresso il campo obiettivo dallo schema insieme con il candidato estrazione e produce un punteggio previsione tra 0 e 1. L’etichetta di destinazione per un candidato è determinato dal fatto che il candidato corrisponde al vero motivo di tale documento e campo. I impara modello modo di rappresentare ogni campo e ogni candidato in uno spazio vettoriale in cui il più vicino un campo e candidato sono nello spazio vettoriale, il più è probabile che il candidato è il valore vero di estrazione per il campo e il documento.

Rappresentanza Candidate
Un candidato è rappresentato dai token nel suo vicinato insieme con la posizione relativa del token sulla pagina rispetto al baricentro del riquadro identificato per il candidato. Utilizzando il campo invoice_date come esempio, frasi nel quartiere come “data della fattura ‘” o ‘Inv Date’ potrebbero indicare al segnapunti che questo è un probabile candidato, mentre frasi come ‘Data di consegna’ indica che questo è probabilmente non la data fattura. Noi non includere il valore del candidato nella sua rappresentazione al fine di evitare overfitting ai valori che capita di essere presenti in un insieme di dati piccolo training – ad esempio, “2019” per la data della fattura, se il corpus di formazione è successo a includere solo le fatture da quell’anno.

Un piccolo frammento di una fattura. Area spettacoli verdi un candidato per il campo invoice_date, e la scatola rossa è un token nel quartiere lungo con la freccia che rappresenta la posizione relativa. Ciascuno degli altri gettoni ( ‘numero’, ‘data’, ‘pagina’, ‘di’, ecc insieme con le altre occorrenze di ‘fattura’) sono parte del quartiere per il candidato fattura.
Modello Architettura
La figura seguente mostra la struttura generale della rete. Per costruire la codifica candidato (i), ogni token vicino è incorporato usando una parola incorporamento tavolo (a). La posizione relativa di ciascun vicino (b) è incorporato utilizzando due strati Relu completamente collegati che cattura grana fine non-linearità. Gli incastri testo e di posizione per ogni vicino sono concatenati per formare una codifica prossimo (d). Un meccanismo di auto attenzione viene utilizzato per incorporare il contesto quartiere per ciascun vicino (e), che è combinato in una codifica zona (f) usando max-pool. La posizione assoluta del candidato sulla pagina (g) è incorporato in un modo simile al incorporamento posizionale per un vicino, e concatenato con la codifica zona per la codifica candidato (i). Lo strato punteggio finale calcola la somiglianza coseno tra l’incorporamento campo (k) e la codifica candidato (i) e poi ridimensiona per essere tra 0 e 1.

risultati
Per la formazione e la validazione, abbiamo usato un set di dati interna di fatture con una grande varietà di layout. Al fine di testare la capacità del modello di generalizzare ai layout invisibili, abbiamo usato un test-set di fatture con layout che erano disgiunto da training set e validazione. Riportiamo il punteggio di F1 delle estrazioni di questo sistema su alcuni settori chiave qui sotto (maggiore è meglio):

Campo F1 Score
AMOUNT_DUE 0,801
delivery_date 0.667
DUE_DATE 0,861
invoice_date 0.940
invoice_id 0,949
PURCHASE_ORDER 0.896
TOTAL_AMOUNT 0,858
total_tax_amount 0,839

Come si può vedere dalla tabella qui sopra, il modello fa bene sulla maggior parte dei campi. Tuttavia, c’è un margine di miglioramento per i campi come delivery_date. Ulteriori indagini hanno rivelato che questo campo era presente in un piccolo sottoinsieme degli esempi attualmente in formazione. Ci aspettiamo che la raccolta di dati aggiuntivi di formazione ci aiuterà a migliorare su di esso.

Qual è il prossimo?
Google Cloud ha recentemente annunciato una fattura parsing servizio come parte del prodotto Documento AI. Il servizio utilizza i metodi descritti sopra, insieme ad altre scoperte di ricerca recenti come BERT, per estrarre più di una dozzina di campi chiave da fatture. È possibile caricare una fattura alla pagina di prova e vedere questa tecnologia in azione!

Per un determinato tipo di documento ci aspettiamo di essere in grado di costruire un sistema di estrazione di dimensioni dato un corpus etichettato modesto. Ci sono diversi follow-ons che stiamo portando avanti, tra cui il miglioramento dell’efficienza dei dati e la manipolazione con precisione i campi nidificati e ripetuti, e campi per i quali è difficile definire un generatore buon candidato.

Ringraziamenti
Questo lavoro è stato una collaborazione tra Google Ricerca e diversi ingegneri in Google Cloud. Vorrei ringraziare Navneet Potti, James Wendt, Marc Najork, Qi Zhao, e Ivan Kuznetsov in Ricerca Google e Lauro Costa, Evan Huang, Will Lu, Lukas Rutishauser, Mu Wang e Yang Xu sulla squadra cloud AI per il loro sostegno. E, infine, i nostri stagisti ricerca Bodhisattwa Majumder e Beliz Gunel per il loro instancabile sperimentazione su decine di idee.

ai.googleblog.com/2020/06/extracting-structured-data-from.html?m=1

Amazon e il logo di Amazon sono marchi di Amazon.com, Inc., o delle sue affiliate.