테디노트 - Upstage Document Parse

테디노트 - Upstage Document Parse

 

본 게시글은, 테디노트의 Upstage Document Parse 관련 라이브를 보고 내용을 이해하기 위해

기록 및 정리한 게시글 입니다.

 

 

 

 

https://www.upstage.ai/products/document-parse

 

Document Tasks

• Document OCR
  • 단어들에 대해 BBOX를 잡고, 추출해오는 테스크
• Key Information Extraction
  • 키 밸류 페어로, 원하는 텍스트 정보만 가져오는 테스크
• Document Parse
  • 문서 안에 여러 레이아웃 항목들을 잘 구분해서 찾아주는 테스크가 바로 오늘 소개할 DP 입니다.

 

Document Parser 주요 기능

1. 레이아웃 분석 (Element Detection)

• 12 레이아웃 클래스를 현재 지원하고 있습니다.
• 각 레이아웃 요소는 HTML 태그로 변환되어 제공됩니다. 예를 들어, 표는 `<table>` 태그로, 이미지는 `<figure>` 태그로 변환됩니다. 특별한 HTML 태그가 없는 요소들은 `data-category` 속성을 가진 `<p>` 태그로 표현됩니다.

• 단락 (Paragraph) 
• 표 (Table) 
• 이미지 (Figure) 
• 제목 (Heading) 
• 헤더/푸터 (Header/Footer) 
• 캡션 (Caption) 
• 수식 (Equation) 
• 리스트 (List) 
• 목차 (Index) 
• 차트 (Chart) 
• 각주 (Footnote)

각종 태그를 가지고, 자유롭게 후처리 등을 진행할 수 있다는게 업스테이지 DP의 가장 큰 장점 중 하나가 아닐까 싶습니다.

 

2. 요소 순서화 (Element Serialization)

단순히 레이아웃 요소를 감지하는 것을 넘어, DP는 문서 내 요소들을 사람이 읽는 순서대로 정렬합니다. 이는 특히 PPT나 포스터와 같이 복잡한 레이아웃을 가진 문서에서 중요합니다.

 

예를 들어, 가운데에 줄이 있고 좌측과 우측에 글이 나뉘어져 있는 경우 (논문에 흔히 나오는 형태인)

단순 OCR은 좌상단에서 우하단으로 텍스트를 나열하지만, DP는 사람이 읽는 형태로 올바른 순서로 구조화할 수 있습니다.

 

Question) 순서정하는게 되게 어려운 테스크 같은데 어떤식으로 처리하셨을까요?

ANS) 순서 정보를 명확하게 어노테이터들이 가이드라인 잘 작성해야했어요

일반적인 문서 같은경우에는 읽는 순서 명확한데, 포스터, PPT의 경우, 순서가 사람마다 달라져버려서..

이러면 어려우니깐 가이드라인에 최대한 룰을 명확하게 잘 정해서 구축했습니다.

어노테이션 준비하는 사람 자체가 헷깔리면 모델도 헷깔리니깐 그걸 방지하고자 일관성있게 준비를 잘 했던 것 같아요

 

3. 테이블 구조 인식 (Table Structure Recognition)

표는 문서에서 가장 중요한 정보를 담고 있는 경우가 많습니다. DP는 복잡한 표 구조(병합된 셀 포함)도 정확하게 인식하여 처리할 수 있습니다.

 

DP만의 장점

• Q. 문서 내 있는 표 등에 대해 일관적으로 마크다운으로 정리하여 변환하는 것과, DP로 작성하는 것에는 어떤 차이가 있나요?
  • A. 대부분 마크다운에는 텍스트 베이스여도 Paragraph 캡션, 헤딩 후터 그걸 구별할 수 없습니다. Table로 나타내냐 마냐만 보여주게 됩니다. 반면 DP를 사용하게되면 그러한 클래스들이 구별 가능하게 되면서, 가령 헤더와 푸터에 항상 들어가는 라이센스 내용 등에 대해 간편하게 제거할 수 있게 됩니다.
  • A. 이미지가 포함되어 있으면 마크다운에서는 변환이 되지 않는데, DP에서는 이미지 좌표를 따주기 때문에 크롭핑해서 멀티 모달에 넣을 수 있게 됩니다.
    
    • 특정 영역에 도장이 반복되는데, 이걸 빼버린다던가 무시한다던가 하는데 요긴하게 사용 됩니다.
• 좌표 정보 이용해서, 시각화 하여 정성평가 및 수정 가능해서 매우 편리하게 사용 가능 합니다.
• 세로 글을 정리할 때도, 좌표를 사용합니다.

 

기술 측면

 

OCR

REcog Swin-Transformer

 

• 문서 도메인에서 글자 찾는 일을 진행합니다.
• 위치 찾는 검출기 디텍터 - 박스 안의 글자를 읽는 인식기 (두 가지 파이프라인)
• 내부적으로 End to End 시도해보긴했지만, 기능 측면에서 이게 더 좋아서 일단 사용 중 입니다.

 

Layout Element Detector

 

• Layout Box들의 순서 입니다.
• H Tag Classifier -> Heading : 타이틀을 걸러내는 모델
  • RAG에서 제목, 소제목에 대해서 처리하는 것도 중요한데, H tag Classifier 가 바로 해당 태그를 걸러내는 역할을 하게 됩니다.
• Equation Recog : 수식 인식 모델 ( LayText )
  • 표 안에 수식은 참고로 지원하고 있지 않다고 합니다.
  • 표 안의 다른 레이아웃 (표 안에 표, 표 안에 이미지, 표 안에 수식 등) 지원 x

 

Detector

• 학습 데이터셋으로 public하게 공개되어있는 8만장 사용하고
• 내부 데이터 셋을 2천장정도 다양한 도메인에서 모아서 파인튜닝 용도로 사용
• 11개의 최종적으로 내보내고 있어요
• 그리고 레이아웃 하나가 H Tag 에서 추가가 됩니다.
• MaskRCNN로는 BBOX 정보만 사용하고 있습니다.

Order Extractor

 

 

• 박스 정보 임베딩화해서, 디코더 결과 내보낼때 참고합니다.
• 오더헤드 거쳐서 나오는거는 순서정보를 이용해 각 박스 순서를 찾아주게 됩니다.
• 이미지 입력만 보고서 아니면 박스 입력만 보고서 순서 찾는 과정이 있는데,
  이때 정보가 많으면 많을수록 모델이 구분이 편해진다고 합니다.
• 최종적으로 나오는결과 후처리해서 순서를 찾고, 2천장 정도 학습에 사용합니다.

 

Question. 데이터 증강은 어느 정도 하십니까?
Answer. Crop Aug 성능 떨어진 경험이 있어서, 웬만하면 전체 페이지를 보게 하면서 학습을 진행했었습니다.
이미지를 단순 리사이즈 하는지, Ratio를 고려해서 패딩을 넣는지에 따라 다르기는한데, OCR 했을 때 리사이즈 차이로 인해서 텍스트 너무 구겨지거나 하지 않는 이상 큰 차이는 없었습니다.
텍스트가 살아있는 이미지를 선정해서 사용했다. 정도로 답할 수 있을 것 같습니다.

 

Question. 파인튜닝용 2K의 데이터를 직접 검수해서 다 만드셨을까요?
Answer. 모델 만드는 사람 입장에서 타겟으로 하는 문서 도메인 선정하고,
모든 도메인을 다 커버하기 어렵기 때문에, 중점적으로 볼 문서로만 제한합니다.
문서별 특징이 무엇이 있는지 파악하고, 수량 얼마나 모을 것인지 의사결정합니다.
2K가 처음부터 만들어진게 아니고, 처음에 실험용으로 데이터셋을 어느정도 만들어서 진행하고. 잘 되는 것 같으면 증가시키면서 하다가 2K가 된 것입니다.

 

Question. 국가별로 문서의 성향, 특징들이 다 다를 것 같은데 어떻게 이를 진행하셨을까요?
Answer. 롱테일은 제외하고, 범용에 집중해서 보고 있습니다.
너무 어려운 문서는 보통 데이터 어노테이션도 어렵기 때문에, 그런 문서들을 범용으로 같이 처리할지 아니면 특화모델로 갈지는 고민해봐야할 것 같습니다.

 

H Tag Classifier

• 별도의 Classifer 박스정보가 입력으로 들어갑니다. OCR 박스가 얼마나있는지 Ratio 참고해서
  최종적으로 뽑는 거는 마크다운에서의 우물 정자 개수 다를 때마다 크기가 다른데 그걸 구별해주기 위해 사용됩니다.
• 현재는 H1 과 일반만을 구별합니다.
  • 처음에는 룰 베이스로 폰트 사이즈 구별했습니다. 그러나 결과가 좋지 않았습니다.
    사람이 보기엔 같은데 픽셀레벨로 나타내다보니깐 폰트사이즈가 다 달라서 그렇습니다.
  • 텍스트 의미 보다는 위치, 크기, 폰트 스타일를 봐가면서 구별하고 있는데 이또한 쉽지 않은 Task 입니다.

 

Question. RAG가 잘 되기 위해, 앞으로 기업들이 문서 양식을 만들 때 있어서 사용할만한 팁이 있다면?

Answer. Heading도 이왕이면 크게 써주면 좋을 것 같습니다. 그러면 Que 역할을 해줄 수 있는 Heading이 더 잘 구분될 것 같습니다. 

 

Question. 벡터이미지에 대해 효율적으로 OCR 하는 방법론?

Answer. PNG와 같은 이미지 타입으로 데이터를 변환할 수 있다면 처리가능할 것 같습니다. 벡터이미지는 많이 다뤄보지 않았습니다.

 

Question. 기업에서 흔히 쓰는 다이어그램은 어떻게 처리해야할까요?

Answer. Figure로 처리하고 있습니다. 나중에 멀티모달에 넣어서 파싱하거나 할 수 있겠습니다.
글자 같은 경우에는 OCR로 강제로 뽑을 수 있는데, 이때 이미지의 ALT 텍스트로 나오기 때문에 이미지 안의 텍스트라는 것을 인지할 수 있습니다.

 

Equation Recognizer

 

• 수식 보면 윗첨자 아랫첨자 텍스트 많은데
• 기존에는 OCR 결과 였는데 OCR 에서는 인식 어려워서 별도의 모델 사용해서 수식 처리한다.
• 참고로, 블럭 형태로 나온 수식만 현재 처리 가능하고, 줄글에 나온 수식은 처리 불가능 합니다.

 

Layout Table Recognizer

 

• 이미지 입력
• OCR 박스 피쳐 뽑고
• 트렌스포머 디코더에서 HTML 토큰을 뽑습니다.
• OCR 박스가 어떤 셀에 들어가는게 옛날에는 어려운 테스크였는데, 이제는 하나의 모델로 해당 문제를 풀게 되었습니다.
• 트랜스포머 모델 베이스로 들어가고 있고, Merged Cell 다 처리 가능합니다.

 

 

데이터 어노테이션

• 리스트를 설명하기 위해 사용한 가이드라인이 9장

• 리스트는 파라그래프와 유사하지만 나열 되어 있고, 글머리 기호 세로로 두 번 이상 나열되어야 한다.
  한번만 있으면 파라그래프이다.
• 간격있거나 들여쓰기는 별개의 박스
• 숫자 구분자 글자 구분자 리스트 타입에 따라
• 순서정보 리스트
• 블랙타입 간단한 리스트
• 문서에서 가. 나. 이런식으로 되어있는건 Ordered 리스트로 구분
• 리스트의 글자가 매우 길어지면 이것도 리스트로 봐야할 것인가...
• 가-1. 가-2 -> 뒤에 텍스트 어떻게 붙어있냐에 따라 갈리는 리스트
• 인덴테이션 있는지 없는지
• L, I, II, III 로 된 리스트

Question. DP의 엄청난 성능으로, 문서에 첨부된 참고화면의 뿌연 글씨들까지 비교적 정확하게 추출해주는데요. 인식 수준을 조절도 가능할까요?
Answer. dp로 뿌연 부분을 figure로 잡아주는지 봐야할 것 같고, OCR에서 Confidence Score가 나오는데 이를 활용해 걸러낼 수도 있을 것 같습니다.

 

Evaluation

기존 평가메트릭

 

 

 

단순히 박스 유사만 찾는건데, 
제품 A는 파라그래프 박스 두 개, 제품 B는 띄어쓰기 기준으로 잡아냈다고 하면 두 제품 다 못찾았다고 보기 어렵기 때문에

이런거는 쓸 수 없겠다 라고 판단했습니다.

 

 

NID, TEDS

• TEXT 위주로 평가하겠다
• 얼마나 사람들이 읽는 순서대로 문서 안 텍스트를 잘 찾는지
• GT를 문서 안 텍스트를 읽는 순서대로 나열
• Prediction을 텍스트 위주로만 쫙 나열, 그러고 나서 얼마나 얼마나 많은 Insertion/Deletion 을 잘 수행해야 원본 텍스트가 동일하게 만드는가.

• TEDS -> 테이블 안 구조, 텍스트정보까지
• TEDS-S -> OCR, 텍스트 정보 제외하고 구조 정보 얼마나 잘 찾았는지

 

DP-Bench

• 애매한 샘플은 제외
• 순서 애매하다, 노이즈 너무 많다 등 제외하고 명확한 애들만 선정.

 

 

경쟁사 제품과 비교 결과