LLM을 이용한 부동산 계약서 파싱이 튜토리얼에서 주장하는 것보다 열 배나 어려운 이유

저희가 NovAsia (동남아시아의 부동산 카탈로그 및 시장 도구)를 위한 데이터 파이프라인을 구축하기 시작했을 때, 계획은 종이 위에서는 창피할 정도로 단순해 보였습니다:

부동산 PDF와 개발자 계약서(SPA)를 가져옵니다.

이를 최신 비전 LLM에 통과시킵니다.

구조화된 JSON을 PostgreSQL에 덤프합니다.

끝입니다.

2주가 지나자, 파이프라인은 완전히 망가졌습니다. 표준적인 튜토리얼 조언이 실제 환경에서 왜 무너졌는지, 그리고 스캔 문서에서 신뢰할 수 있는 데이터를 얻기 위해 무엇을 변경해야 했는지 알려드립니다.

튜토리얼이 경고하지 않는 것들
대부분의 LLM 문서 파싱 데모는 깨끗하고 태어날 때부터 디지털화된 PDF와 깔끔한 타이포그래피를 사용합니다. 캄보디아나 태국 같은 신흥 시장에서는 현실이 매우 다릅니다:

폰 스캔: 문서 절반은 여러 세대에 걸친 스캔본이거나, 고르지 않은 조명 아래 휴대폰 카메라로 찍은 사진입니다.

듀얼 언어 레이아웃: 크메르어나 태국어가 영어와 섞여 있으며, 종종 라인 베이스라인이 맞지 않는 인접한 테이블 열에 배치되어 있습니다.

실물 스탬프: 빨간색 고무 스탬프, 서명, 공증 도장이 중요한 숫자(지불 마일스톤 날짜, 침식 기금 비용, 양도세 등) 위에 직접 찍혀 있습니다.

40페이지 프롬프트 함정: 35페이지 분량의 PDF를 긴 컨텍스트 모델에 넣고

우리는 모델에게 전체 문서를 한 번에 파싱하도록 요청하는 것을 멈췄습니다. 대신 특정 섹션(예: "지불 일정 (Schedule of Payments)", "유지보수 의무 (Maintenance Obligations)")별로 청킹하고 엄격한 Pydantic 스키마를 적용합니다. 만약 필드가 유효성 검사에 실패하거나 예상 범위를 벗어나면, 파이프라인은 추측하는 대신 수동 확인을 위해 플래그를 지정합니다.

1. 테이블과 서술형 텍스트를 별개의 문제로 취급하기

비전 모델(Vision models)은 정성적인 질문("어떤 조건에서 보증금이 환불되는가?")에 답하는 데는 뛰어나지만, 재무 테이블의 열(column) 처리에는 악명이 높을 정도로 부정확합니다. 우리는 테이블 추출을 전용 패스(dedicated passes)로 분리하고 명시적인 행별 검사(row-by-row checks)를 수행합니다.

핵심 요약 (The takeaway)

만약 지저분한 실제 세계의 서류(messy, physical-world paperwork)로 LLM을 사용하여 구축한다면, 단순히 컨텍스트 창 크기(context window size)가 해결책이 될 수 없습니다. 대부분의 신뢰성은 이미지 위생(image hygiene)과 엄격한 스키마 경계에서 나옵니다.

노이즈가 많은 스캔본과 테이블 추출에 어려움을 겪고 있는 분이 있다면 언제든지 의견을 교환할 준비가 되어 있습니다.