이미지 출처: Nanonets 블로그

서론

이 리포트에서, 정형적 또는 비정형적 문서에서 정보를 추출하는 바에 대해서 살펴보겠습니다. 특히 Google의 Representation Learning for Information Extraction from Form-like Documents 논문에 대해 논의하겠습니다. 이 논문은 ACL 2020에서도 수록되었습니다.

명함을 직접 스캔하여 연락처, 이메일 ID, 주소와 같은 모든 연락처 정보를 있으면 어떨까요? 흥미롭지 않으신가요? 이 작은 기능을 통해 많은 시간을 절약할 수 있습니다.

문서에서 정보를 추출하는 것은 우리 인간에게 있어 번거로운 작업이며, 물론, 비용도 많이 듭니다.

이제 정보를 추출하는 법에 대한 몇 가지 딥러닝 접근법에 대해서 논의하겠습니다.

GitHub에서 코드 확인하기 →

참고: 코드 구현(code implementation)이 예상만큼 제대로 작동하지 않습니다. 그러나. 이 부분은 이 논문을 구현하기 위한 좋은 출발점이 될 것입니다.

다양한 접근법

1. 템플릿 기반 정보 추출

2. Deep Visual Template-Free Form Parsing

3. Attend, Copy, Parse

4. Graph Convolutional Networks

5. Representation Learning for Information Extraction from Form-like Documents

   

이미지 출처 : ACL Demo Slides

기존의 접근법은 템플릿 기반의 방법을 사용하며 OCR 처리된 텍스트와 매칭시키고 정보를 추출합니다. 그러나 송장마다 큰 차이가 있기 때문에 이 접근 방식의 경우 대규모로 적용하는 것은 불가능합니다.

그림1

출처 : 논문

여러 판매자의 서로 다른 레이아웃을 사용하여 정보를 제공합니다. 템플릿 기반 접근 방식을 사용하는 것은 확장성이 떨어지며 오류가 발생하기 쉽습니다.

이 블로그 게시물에서는 Representation Learning for Information Extraction from Form-like Documents 논문에 대한 높은 차원의 관점에서 논의하겠습니다. 다른 테크닉에 대해 자세히 살펴보시려면 Nanonets의 블로그 게시물 을 살펴보시기 바랍니다.

데이터세트 세부사항

이 논문에서 저자들은 두 가지 다른 데이터세트를 사용했습니다.

1. 송장: 2개의 송장 코퍼스(corpus)가 있습니다. 첫 번째 코퍼스는 14,237개의 송장을 포함하고 있으며, 두 번째 코퍼스에는 595개의 송장이 있습니다. 송장은 공통된 템플릿을 갖고 있지 않으며, 각 송장의 템플릿은 다른 송장과 다릅니다.

송장 코퍼스는 비공개 데이터세트입니다.

2. 영수증: 이 데이터세트는 Scanned Receipts OCR and Information Extraction(SROIE)에 대한 ICDAR 2019 Robust Reading Challenge의 부분으로 발표된 스캔된 영수증의 공개적으로 사용 가능한 코퍼스입니다.

이 데이터세트는 4개의 필드 주소, 회사명, 총량, 날짜에 대한 참값(ground truths)와 함께 626개의 이미지를 포함하고 있습니다. 저희는 총량 및 날짜 필드만을 대상으로써 사용하겠습니다. 또한 이 데이터세트는 좌표 및 연관된 해당 텍스트와 함께 OCR 처리된 CSV 파일을 포함하고 있습니다.

샘플 이미지 샘플 참값(GroundTruth)

{
    "company": "BOOK TA .K (TAMAN DAYA) SDN BHD",
    "date": "25/12/2018",
    "address": "NO.53 55,57 & 59, JALAN SAGU 18, TAMAN DAYA, 81100 JOHOR BAHRU, JOHOR.",
    "total": "9.00"
}

관측 결과

모델 파트에 들어가기 앞서, 몇 가지 관측 결과에 대해 논의하겠습니다.

1. 각 필드는 일반적으로 잘 알려진 유형에 해당합니다. 예를 들어, 총량에 대한 후보는 숫자 값 인스턴스가 됩니다. 총량 필드에 대하여 “Weights and Biases”와 같은 텍스트는 분명하게 맞지 않습니다.

이미지 출처 : ACL Demo Slides

검색 공간을 유형별로 제한하게 되면 문제의 복잡성을 크게 줄일 수 있습니다. 따라서 저희는 각 필드에 대한 후보를 생성하기 위해 몇몇 라이브러리를 사용하겠습니다. 예를 들어, 날짜 영역에 대한 잠재적 후보 생성기(potential candidate generator)는 날짜 분석기 라이브러리(date parser library)가 됩니다. 또한 Google NLP와 같은 클라우드 서비스를 사용하여 후보를 보다 효과적으로 생성할 수 있습니다.

2. 각 필드 인스턴스는 핵심 문구(key phrase)와 연관되어 있습니다. 예를 들어 그림 1에서 날짜 인스턴스는 항상 핵심 문구 Date(날짜) or Dated에 둘러싸여 있음을 추론할 수 있습니다. 또한 핵심 문구가 항상 같은 줄에 있는 것은 아닙니다. 효과적인 해결책은 텍스트 정보와 함께 공간 정보를 포함하는 것입니다.

I이미지 출처 : ACL Demo Slides

어떻게 공간 정보를 포함시키나요?

공간 정보는 각 단어의 주변 이웃을 고려하여 포함됩니다. 이웃(neighbors) 선택을 위해서 이 논문의 저자들은 인접 영역(neighborhood zone)을 정의했습니다.

인접 영역(Neighborhood Zone): 각 후보의 경우, 인접 영역은 페이지의 왼쪽 및 후보 위로 페이지의 10퍼센트까지 확장됩니다.

바운딩 박스가 인접 영역과 50퍼센트 이상 겹치는 모든 텍스트 토큰은 이웃으로 간주됩니다.

3. 필드의 핵심 문구는 주로 제한된 어휘에서 가져옵니다. 송장에 있는 데이터 인스턴스의 약 93%는 “date” 또는 “dated”(논문상에서의)와 같은 핵심 문구와 연관되어 있습니다. 이는 적당한 양의 훈련 데이터로 이 문제를 해결할 수 있음을 시사합니다.

이미지 출처: ACL Demo Slides

All the above observations are applicable to many fields across various documents.

In this problem, data pre-processing is crucial and important than the model part. Let's look at the data processing pipeline using the above observations.

이미지 출처 : ACL Demo Slides

1. OCR: 이미지에서 텍스트를 추출하기 위해 저희는 OCR을 적용할 필요가 있습니다. EasyOCR, PyTesseract와 같은 오픈 소스 툴 또는 Google OCR과 같은 클라우드 서비스를 사용할 수 있습니다. 저희의 예제에서는, ICDAR는 이미 OCR 처리된 텍스트를 제공하고 있습니다

2. 후보 생성기(개체(entity) 태그 지정): 위의 관측 결과에서 논의된 바와 같이, 우리는 여러 후보 생성기를 사용하여 후보를 생성하겠습니다. 전반적 시스템의 리콜은 후보 생성기의 리콜을 초과할 수 없으므로, 이들의 리콜이 높은 것은 중요합니다.

3. 스코어링 및 할당 모듈(Scoring and Assignment Module): 이 모듈은 신경 모듈(neural module)을 사용하여 각 후보에 대하여 독립적으로 0과 1사이의 점수를 계산하며, 그다음 우리는 각 필드에 대한 참 추출 값일 가능성이 높은 점수가 매겨진 후보를 각 영역에 할당합니다.

이러한 스코어링 및 할당의 구분을 통해 다른 후보 및 영역과는 별개로 오직 인접 지역만을 기준으로 각 후보에 대한 표현을 학습할 수 있습니다. 또한 필요시 임의적으로 복잡한 비즈니스 규칙을 할당자(assigner)로 인코딩 할 수 있습니다. 예를 들어, 송장의 만기일이 (연대순으로) 송장 날짜보다 이전일 수 없습니다. (논문에서)

간결성을 위해, 저자들은 다른 필드와 독립적으로 각 영역에 대하여 최고 점수의 후보를 선택하는 간단한 할당을 사용하여 다른 할당 모듈의 디테일 및 리포트 결과를 생략했습니다.

신경 스코어링 모델

모델이 다양한 문서의 템플릿에서 일반화되는지 확인하기 위해 모델은 후보와 해당 필드에 대한 개별 임베딩을 학습하고 여기서 후보와 필드 임베딩 간의 유사성이 점수를 결정합니다.

저자들이 선택한 또 다른 중요한 설계 사항은 후보 텍스트를 모델에 통합하는 것이 아니라 돌발적인 오버피팅(overfitting)을 방지하는 것입니다. 예를 들어, 데이터세트에 2020년 이전의 모든 송장을 포함될 수 있으며, 모델은 송장 날짜가 2020년 이전이 되어야 함을 학습할 수 있습니다.

인접지역 인코딩(Neighborhood Encoding): 모든 인접지역 임베딩은 서로 독립적입니다. 이웃 간의 관계를 포착하기 위해 셀프 어텐션(self-attention) 메커니즘이 사용됩니다. 이를 통해 예측과 관계없는 이웃의 가중치는 줄어들고 이웃에 대한 맥락화된 표현을 생성할 수 있습니다.

후보 위치 임베딩(Candidate Position Embedding): 후보 위치는 간단한 선형 레이어를 사용하여 임베딩됩니다.

후보에 대한 이웃의 상대적 위치에 관한 정보는 이미 임베딩 자체에 캡처되어 있으므로, 인접 영역 인코딩이 특징에 포함되는 (임의의) 순서에 불변하도록 하기 위해 최대 풀링(max-pooling) 메커니즘이 사용됩니다.

후보 인코딩: 후보 인코딩은 인접지역 인코딩과 후보 위치 임베딩을 연결하여 획득됩니다.

필드 임베딩: 필드 임베딩 레이어를 사용하여 필드 ID 표현을 생성하기 위해, 필드 ID 또한 임베딩됩니다.

후보 점수: 후보 인코딩은 인접지역 세부사항과 함께 후보 위치에 대한 모든 정보가 포함되어 있어야 합니다. 이는 후보가 속한 필드에서 독립적입니다.

이제 후보 인코딩 및 필드 임베딩 간의 코사인 유사성(CosineSimilarity)을 계산하겠습니다. 유사성 값은 -1에서 1의 범위에 있으므로, 0에서 1사이의 값을 다시 조정하고 가장 높은 점수의 후보를 선택합니다.

결과

모델의 장점을 보여주기 위해 이 논문의 저자들은 두 가지 기준(baselines)를 제안하고 그 결과를 비교했습니다.

Bag-of-words(BoW) 기준은 후보의 인접 토큰만을 통합하며, 위치는 통합하지 않습니다. MLP 기준은 우리가 제안한 모델과 동일한 입력 특징을 사용하며, 후보 이웃의 상대적 위치를 포함합니다. 또한 3개의 숨겨진 레이어를 사용하여 후보를 인코딩합니다.

이 두 기준 모두 동일한 접근법을 따르며, 후보와 필드를 별개로 인코딩합니다.

이 모델이 두 기준보다 성능이 뛰어나다는 것은 분명합니다. 이웃 위치를 사용하여 MLP 기준은 BoW 기준보다 더 나은 결과를 냅니다.

특징 중요도(feature importance)의 상대적 순서는 다음과 같습니다:

neighbor text > candidate position > neighbor position

셀프 어텐션(self-attention) 레이어를 제거하면 채점자(scorer) ROC AUC에서 1 포인트 감소되며, 엔드-투-엔드 최대 f1에서 1.7 포인트 감소로 이어짐이 관측되었습니다.

모델 표현

저자들이 모델의 내부 표현(internal representations)을 조사하고 t-SNE(Dimensionality Reduction Technique, 차원 축소 테크닉)을 사용하여 시각화했다는 점은 이 논문에서 아주 흥미로운 부분 중 하나입니다.

이러한 표현이 어떤 모습일지 흥미롭지 않으신가요? 그럼 한번 살펴봅시다.

참고점:

1. 그림 4(b)를 살펴보면, 포지티브 포인트가 서로 잘 모여있음이 분명한 반면, 네거티브 포인트는 드문드문한 공간적 분포를 나타냅니다.

2. 필드 임베딩은 클러스터의 중앙이 아니라 포인트에서 멀리 떨어진 클러스터의 가장자리에 있다는 점이 특히 주목할만합니다. 이 패턴은 손실 함수(loss function)가 본질적으로 필드 임베딩과 필드 임베딩의 포지티브 사이의 코사인 거리 최소화하면서 네거티브와의 거리, 특히 다른 필드에 대한 포지티브를 최대화한다는 사실을 통해 예측됩니다.

3. 그림 4(c)에서 invoice date 예시는 송장 날짜 클러스터에서 멀리 떨어져 있습니다. invoice date로 purchase date를 표시한 것은 주석자(annotator)의 잘못임이 분명합니다.

4. 그림 4(d)에서 샘플의 후보 인코딩은 invoice date와 due date 사이에 있습니다. 이는 이 후보가 만기일 및 송장 날짜라는 용어 모두에 둘러싸여 있다는 사실로 설명할 수 있습니다.

5. 그림 4(e)에서 샘플의 후보 인코딩은 invoice date 클러스터와 멀리 떨어져 있습니다. 자세한 검사 후, 이것은 스캐닝 노이즈(scanning noise)로 인한 OCR 오류 때문인 것으로 확인되었습니다.

모델 표현을 시각화하는 것은 모든 모델에 전반적으로 많은 도움이 된다고 생각합니다.

결론

이 블로그 게시물을 재미있게 읽으셨기를 바랍니다. 문서에서 정보를 추출하는 것은 까다롭고 힘든 작업입니다. 후보 생성기의 정확성을 높이는 것은 여전히 연구 중이며 여러 분야의 전문 지식을 필요로 합니다. 댓글이나