레이아웃 풍부 문서 정보 추출을 위한 LLM 설계 공간 탐색

초록

본 논문은 레이아웃이 풍부한 문서(LRD)에서 대형 언어 모델(LLM)을 활용한 정보 추출(IE) 파이프라인의 설계 공간을 정의하고, 데이터 구조화·모델 활용·출력 정제라는 세 핵심 과제를 체계적으로 분석한다. 새롭게 제안한 오픈소스 테스트 스위트 LayIE‑LLM을 통해 OCR·마크다운 입력, 청크 크기, 프롬프트 방식, 모델 선택, 디코딩·스키마 매핑·데이터 정제 등 12가지 변수를 실험하고, OFAT(One‑Factor‑At‑Time) 탐색이 전체 조합 탐색에 비해 97% 이상의 성능을 2.8%의 계산 비용으로 달성함을 보인다. 최적화된 설정에서는 GPT‑4o 등 일반 LLM이 LayoutLMv3·ERNIE‑Layout과 동등하거나 우수한 F1 점수를 기록한다.

상세 분석

이 연구는 레이아웃‑리치 문서(LRD)에서 정보 추출(IE)을 수행할 때 직면하는 세 가지 근본적인 도전을 ‘데이터 구조화(Data Structuring)’, ‘모델 활용(Model Engagement)’, ‘출력 정제(Output Refinement)’로 정의한다. 데이터 구조화 단계에서는 순수 텍스트 기반 LLM에 OCR 결과를 그대로 제공하느냐, 혹은 마크다운과 같은 구조화된 포맷으로 변환하느냐가 핵심 변수이며, OCR 품질과 레이아웃 좌표 정규화가 성능에 미치는 영향을 실험적으로 확인한다. 모델 활용 단계에서는 프롬프트 설계가 가장 큰 변동성을 만든다. 저자는 Few‑Shot과 Chain‑of‑Thought(CoT) 프롬프트를 각각 0, 1, 3, 5개의 예시와 결합해 실험했으며, 모델 규모와 멀티모달 여부에 따라 최적의 ICL 전략이 달라짐을 보고한다. 특히 GPT‑4o와 Qwen‑2.5‑vision 같은 비전‑통합 LLM은 텍스트‑전용 LLM보다 높은 F1을 기록했지만, 토큰 사용량·API 비용·디버깅 난이도가 크게 증가한다는 트레이드오프를 제시한다. 출력 정제 단계에서는 세부적인 후처리 기법이 전체 파이프라인 성능을 크게 끌어올린다. JSON 디코딩 오류를 제거하고, 스키마 매핑을 통해 키 이름 정규화(예: “file date”→“file_date”)를 수행하며, 정규표현식 기반 데이터 클리닝으로 날짜·이름 형식을 일관되게 맞춘다. 이러한 단계별 정제는 특히 다중 청크에서 중복·분산된 예측을 하나의 문서‑레벨 결과로 통합할 때 필수적이다.

실험 설계는 432가지 조합(2 × 3 × 2 × 4 × 3 × 3)으로 이루어진 전수 탐색과, 각 변수를 하나씩만 바꾸는 OFAT 방식을 비교한다. OFAT는 전체 탐색 대비 0.8~1.8 F1 포인트만 손실하면서 전체 실험 비용의 2.8%만 사용해 거의 최적에 근접한 설정을 찾는다. 두 데이터셋(VRDU와 FUNSD)에서 최적화된 파이프라인은 일반‑프랙티스 베이스라인 대비 각각 13.3 점, 37.5 점의 F1 향상을 보였으며, 이는 기존의 레이아웃‑전용 모델(LayoutLMv3, ERNIE‑Layout)과 동등하거나 상회한다.

핵심 인사이트는 다음과 같다. ① LLM을 IE에 바로 적용하려면 파이프라인 전반에 걸친 세밀한 튜닝이 필수이며, 단순히 ‘대형 모델만 쓰면 된다’는 인식은 잘못되었다. ② 텍스트‑전용 LLM도 적절히 청크·프롬프트·후처리를 구성하면 멀티모달 모델에 근접한 성능을 낼 수 있다. ③ OFAT와 같은 경량 탐색 기법은 실무에서 비용 효율적으로 최적 구성을 찾는 실용적인 방법이다. ④ 멀티모달 LLM은 성능 면에서 우수하지만, 토큰 비용·투명성·디버깅 난이도가 높아 실제 서비스 적용 시 비용‑효율성을 면밀히 검토해야 한다.

이 논문은 레이아웃‑리치 문서 IE를 위한 설계 공간을 체계화하고, 오픈소스 테스트 스위트와 경량 탐색 방법을 제공함으로써 연구자와 엔지니어가 LLM 기반 파이프라인을 빠르게 프로토타이핑하고 최적화할 수 있는 기반을 마련한다.