brunch

You can make anything
by writing

C.S.Lewis

by 서진호 Jun 15. 2020

Templatic 문서에서 구조화된 데이터 추출

2020년 6월 12일(금) 구글 AI 리서치 블로그

영수증, 청구서, 보험료 등의 문서는 다양한 비즈니스 워크플로우에서 매우 일반적이며 중요합니다. 현재 이러한 문서를 처리하는 작업은 대부분 수동 작업이며 존재하는 자동화 시스템은 불안정하고 오류가 발생하기 쉬운 휴리스틱을 기반으로 합니다. 청구서(invoice)와 같은 문서 유형을 고려하십시오. 청구서와 같은 수천 가지 방법으로 배치할 수 있습니다. 서로 다른 회사의 청구서 또는 같은 회사 내의 다른 부서의 청구서의 형식이 약간 다를 수 있습니다. 그러나 청구서 번호, 청구서 날짜, 지불 금액, 지불 날짜 및 청구서를 보낸 품목 목록과 같이 청구서에 포함되어야 하는 구조화된 정보에 대한 일반적인 이해가 필요합니다. 이 모든 데이터를 자동으로 추출할 수 있는 시스템은 오류가 발생하기 쉬운 수동 작업을 피함으로써 많은 비즈니스 워크플로우의 효율성을 획기적으로 향상시킬 수 있습니다.


ACL 2020에 승인된 “양식 문서에서 정보 추출을 위한 표현 학습(Representation Learning for Information Extraction from Form-like Doucments)” 논문에서 템플릿 문서에서 구조화된 데이터를 자동으로 추출하는 방법을 제시합니다. 일반 텍스트 문서에서 추출하는 이전 작업과 달리 대상 필드 유형에 대한 지식을 사용하여 후보 필드를 식별하는 방법을 제안합니다. 그런 다음 주변 지역의 단어를 사용하여 각 후보의 밀도가 높은 표현을 학습하는 신경망을 사용하여 점수를 매깁니다. 두 개의 청구서 및 영수증(corpora) 실험에서 보이지 않는 레이아웃에 대해 일반화할 수 있음을 보여줍니다.


왜 이것이 어려운가요?

이 정보 추출 문제는 자연어 처리(NLP)와 컴퓨터 비전 세계에 걸쳐 있기 때문에 문제가 발생합니다. 고전적인 NLP 작업과는 달리, 그러한 문서에는 일반 문장과 단락에서 볼 수 있는 “자연어”가 포함되지 않고 대신 양식과 유사합니다. 데이터는 종종 표들(Tables)로 표시되지만 많은 문서에는 여러 섹션이 있으며 여러 섹션으로 구성되며 정보를 구성하기 위한 다양한 레이아웃 및 서식 표지가 있습니다. 페이지에서 텍스트의 2차원 레이아웃을 이해하는 것이 그러한 문서를 이해하는 데 중요합니다. 다른 한편으로, 이것을 순전히 이미지 분할 문제로 취급하면 텍스트의 의미를 이용하기가 어렵습니다. 


솔루션 개요

이 문제에 대한 우리의 접근 방식을 통해 개발자는 두 가지 입력 - 대상 스키마(예: 추출할 필드 목록 및 해당 유형)와 훈련 세트로 사용하기 위해 근거가 표시된 작은 문서 모음 - 을 사용하여 주어진 도메인 (영수증과 같은)에 대한 추출 시스템을 훈련하고 배포할 수 있습니다. 지원되는 필드 유형에는 날짜, 정수, 영숫자 코드, 통화 금액, 전화번호 및 URL과 같은 기본 사항이 포함됩니다. 또한 Google knowledge graph에서 일반적으로 감지하는 주소, 회사 이름 등과 같은 엔티티 유형을 활용합니다.


입력 문서는 먼저 광학 문자 인식(OCR) 서비스를 통해 텍스트 및 레이아웃 정보를 추출하여 PDF와 같은 기본 디지털 문서 및 문서 이미지(예 : 스캔된 문서)와 함께 작업할 수 있습니다. 그런 다음 주어진 필드의 인스턴스에 해당할 수 있는 OCR 출력에서 텍스트 범위를 식별하는 후보 생성기를 실행합니다. Candidate Generators는 각 필드 유형 (날짜, 번호, 전화번호 등)과 관련된 기존 라이브러리를 사용하므로 각 candidate generator에 새 코드를 작성할 필요가 없습니다. 이 candidates 각각은 훈련된 신경망 (아래에 설명된 “스코어(scorer)”)을 사용하여 채점되어 실제로 해당 분야에 대해 추출할 수 있는 가치가 있는지 추정합니다. 


마지막으로 assigner 모듈은 scored candidates를 대상 필드와 일치시킵니다. 기본적으로 담당자는 해당 필드에 대해 가장 높은 점수를 매기는 candidates를 선택하지만 영수증 날짜 필드가 지불 날짜 필드 이전의 시간순으로 표시되어야 하는 등 추가 도메인별 제약 조건을 통합할 수 있습니다.

[그림 1]

[그림 1] 입력 영수증 문서에 두 개의 필드가 있는 toy schema를 사용하는 추출 시스템의 처리 단계입니다. 파란색 박스는 invoice_date 필드의 candidate와 amount_due 필드의 골드 박스를 표시합니다.


스코어

스코어(Scorer)는 이진 분류기(binary classifier)로 훈련된 신경망 모델입니다. 추출 candidate와 함께 스키마에서 대상 필드를 입력으로 0과 1 사이의 예측 점수를 생성합니다. candidate의 대상 레이블은 candidate가 해당 문서 및 필드에 대한 근거와 일치하는지 여부에 따라 결정됩니다. 모델은 필드와 candidate가 벡터 공간에 더 가까운 벡터 공간에서 각 필드와 각 후보를 나타내는 방법을 학습합니다. candidates가 해당 필드와 문서의 실제 추출 값일 가능성이 높습니다.


Candidate Representation

candidate는 candidate에 대해 식별된 경계 상자의 중심과 관련하여 페이지에서 토큰의 상대적 위치와 함께 해당 지역의 토큰으로 표시됩니다. 예를 들어, invoice_date 필드를 사용하여 “Invoice Date” 또는 “Inv Date” 와 같은 이웃에 있는 문구는 Scorer에게 이것이 candidate일 가능성이 있음을 나타내며 “Delivery Date” 와 같은 문구는 invoice_date 가 아닐 가능성이 있음을 나타냅니다. 우리는 작은 훈련 데이터셋에 존재하는 값에 대해 오버피팅(overfitting)을 피하기 위해 그 자체의 representation에서 candidate 값을 포함시키지 않습니다. 예를 들어, invoice date의 "2019" 값. 만일 훈련 코퍼스에 영수증만 포함된 경우를 말합니다.

[그림 2]

[그림 2] 영수증(invoice)의 작은 스니펫. 녹색 상자에는 invoice_date 필드의 candidate가 표시되고, 빨간색 상자는 상대 위치를 나타내는 화살표와 함께 이웃의 토큰을 표현합니다. 다른 각 토큰 ( 'number', 'date', 'page', 'of' 등은 다른 'invoice'와 함께)는 invoice candidate의 이웃에 속합니다.


모델 아키텍처

아래 그림은 네트워크의 일반적인 구조를 보여줍니다. candidate 인코딩 (i)을 구성하기 위해, 이웃에 있는 각각의 토큰은 word embedding 테이블 (a)을 사용하여 내장됩니다. 각 이웃 (b)의 상대적 위치는 세밀한 비선형성을 포착하는 완전히 연결된 두 개의 ReLU 레이어를 사용하여 임베드됩니다. 각각의 이웃에 대한 텍스트 및 위치 임베딩은 이웃 인코딩 (d)을 형성하기 위해 연결됩니다. self-attention 메커니즘은 각 이웃 (e)에 대한 이웃 컨텍스트를 통합하는 데 사용되며, 이는 max pooling을 사용하여 이웃 인코딩(f)으로 결합됩니다. 페이지 (g)에서 후보의 절대 위치는 neighborhood에 대한 위치 임베딩과 유사한 방식으로 임베딩 되고, candidate 인코딩 (i)에 대한 neighborhood encoding과 연결됩니다. final scoring layer은 필드 임베딩(k)과 candidate 인코딩 (i) 사이의 코사인 유사성(cosine similarity)을 계산한 다음 0과 1 사이로 재설계합니다. 

[그림 3]

결과

훈련 및 검증을 위해 다양한 레이아웃의 영수증 내부 데이터셋을 사용했습니다. 보이지 않는 레이아웃으로 일반화하는 모델의 기능을 검증하기 위해 훈련 및 유효성 검증 셋(Validation Set)와 분리된 레이아웃의 영수증 테스트 셋을 사용했습니다. 아래의 몇 가지 주요 필드에서 이 시스템에서 추출한 F1 score(F1 점수)를 보고합니다 (높을수록 좋음).

 

위의 표에서 볼 수 있듯이 모델은 대부분의 필드에서 잘 작동합니다. 그러나 delivery_date와 같은 필드를 개선할 여지가 있습니다. 추가 조사에 따르면 이 필드는 훈련 데이터의 예제 중 아주 작은 부분에 존재합니다. 추가 훈련 데이터를 수집하면 이를 개선하는 데 도움이 될 것으로 기대합니다.


향후 계획은 무엇인가?

Google Cloud는 최근 Document AI 제품의 일부로 인보이스 파싱 서비스를 발표했습니다. 이 서비스는 BERT와 같은 최근의 다른 혁신적인 연구와 함께 위에서 설명한 방법을 사용하여 송장에서 12 개 이상의 주요 필드를 추출합니다. 데모 페이지에서 송장을 업로드하고이 기술이 실제로 작동하는 것을 볼 수 있습니다!


주어진 문서 유형에 대해 우리는 적당한 크기의 레이블이 있는 전집(corpus)이 주어지면 추출 시스템을 구축할 수 있을 것으로 기대합니다. 데이터 효율성 개선, 중첩 및 반복 필드의 정확한 처리 및 우수한 candidate generator를 정의하기 어려운 필드를 포함하여 현재 추구하고 있는 몇 가지 후속 조치가 있습니다.


감사의 말

이 연구는 Google Research와 Google Cloud의 여러 엔지니어 간의 공동 작업이었습니다. 클라우드 AI 팀의 Naurone Costa, Evan Huang, Will Lu, Lukas Rutishauser, Mu Wang 및 Yang Xu는 물론 Google Research의 Navneet Potti, James Wendt, Marc Najork, Qi Zhao 및 Ivan Kuznetsov에게 감사의 말씀을 전합니다. 그들의 지원에. 마지막으로, 우리 연구 인턴 Bodhisattwa Majumder와 Beliz Gunel은 수십 가지 아이디어에 대한 지칠 줄 모르는 실험을 했습니다.


원본 제목: Templatic 문서에서 구조화된 데이터 추출(Extracting Structured Data from Templatic Documents)
게시자 : Google Research 소프트웨어 엔지니어 Sandeep Tata
원본 링크: https://ai.googleblog.com/2020/06/extracting-structured-data-from.html
Representation Learning for Information Extraction from Form-like Documents 논문: https://research.google/pubs/pub49122/
신경망을 사용하여 표들에서 답 찾기 블로그(한글): https://brunch.co.kr/@synabreu/82
Detect text in files 문서: https://cloud.google.com/vision/docs/pdf
Google Cloud Document AI: https://cloud.google.com/solutions/document-ai
Open Sourcing BERT: State-of-the-Art Pre-training for Natural Language Processing 블로그(영문): https://ai.googleblog.com/2018/11/open-sourcing-bert-state-of-art-pre.html
이 블로그는 2020년 6월 12일(금), Google AI 리서치 블로그 기사를 영한 번역한 것입니다. 또한 이 번역 글은 정보 공유 목적으로만 작성했으므로 어떠한 상업용으로 사용할 수 없으며, 원본 저작물 모두 구글에게 저작권이 있음을 알려 드립니다. (First Draft Version)
매거진의 이전글 신경망을 사용하여 표들에서 답 찾기
브런치는 최신 브라우저에 최적화 되어있습니다. IE chrome safari