문서 자동화는 오랫동안 OCR과 규칙 기반 파서, 그리고 클로즈드 비전-언어 모델(VLM) API의 조합으로 운영되어 왔습니다. Datalab가 공개한 lift는 9B 파라미터의 오픈 웨이트 비전 모델로, 스키마만 던져주면 PDF와 이미지에서 유효한 JSON을 추출해 주는 방향성을 제시합니다. 본 글은 lift가 어떤 구조적 선택을 통해 환각(hallucination) 문제를 억제하는지, 그리고 엔터프라이즈 파이프라인에서 어떤 위치를 점할 수 있을지 기술적 관점에서 정리합니다.
핵심 요약
- 9B 오픈 웨이트 비전 모델 lift: PDF와 이미지 입력을 받아 사용자가 정의한 JSON 스키마로 변환하는 데 특화된 비전-언어 모델
- 스키마 제약 디코딩과 학습된 abstention: 유효하지 않은 JSON을 구조적으로 차단하고, 정보가 없는 필드는 null로 반환해 환각을 억제
- 자체 225문서 벤치마크 필드 정확도 90.2%: 소형 오픈 모델임에도 문서 파싱 실용 영역에서 경쟁력 있는 수치를 제시
lift의 가치는 모델 크기 자체보다 스키마라는 인터페이스로 출력을 강제하는 설계와 모르는 정보를 모른다고 반환하는 abstention 능력에서 나온다고 볼 수 있습니다.
Datalab lift의 등장 배경과 오픈소스 의의
문서 파싱 시장의 한계와 오픈 웨이트의 필요성
기존 문서 파싱은 크게 두 갈래로 나뉘어 왔습니다. 하나는 템플릿과 좌표 규칙에 의존하는 전통적 OCR/파서이고, 다른 하나는 GPT-4o 같은 대형 클로즈드 모델에 스키마를 함께 전달하는 방식입니다. 전자는 레이아웃 변동에 취약하고, 후자는 비용과 데이터 유출 우려, 그리고 출력의 비결정성 문제가 남아 있습니다.
lift는 9B 규모의 비전-언어 모델을 오픈 웨이트로 공개함으로써, 온프레미스 배포와 학습 데이터 통제라는 두 가지 요구를 동시에 만족시키려 한 것으로 분석됩니다. 90억 파라미터라는 크기는 단일 GPU 또는 소규모 클러스터에서 운용 가능한 범위로, 기존 오픈소스 에이전트 프레임워크와 결합하기에도 적절한 스위트 스팟으로 보입니다(참고: 오픈소스 AI 에이전트 맥락).
Datalab의 오픈 모델 전략
Datalab는 lift를 통해 “문서 → JSON”이라는 좁은 인터페이스에 모델을 집중시키는 전략을 취했습니다. 범용 VLM이 챗봇과 캡셔닝 등 여러 태스크에 분산되는 반면, lift는 스키마 기반 추출이라는 단일 태스크에 최적화된 가중치를 학습한 것으로 파악됩니다. 이는 오픈 웨이트 모델이 대형 클로즈드 모델을 정면으로 대체하기보다, 특정 도메인에서 비용 대비 성능 우위를 확보하는 방식으로 생태계를 확장해 왔던 흐름과 맞닿아 있습니다.
lift 모델 아키텍처와 핵심 기술
9B 비전-언어 모델 구조 개요
lift는 9B 파라미터 규모의 비전 인코더와 디코더 구조를 결합한 VLM으로 소개됩니다. PDF 페이지를 이미지 시퀀스로 렌더링한 뒤, 비전 인코더가 페이지 레이아웃과 텍스트를 통합적으로 토큰화하고, 디코더는 사용자가 함께 전달한 JSON 스키마를 조건으로 받아 토큰을 생성하는 것으로 이해할 수 있습니다. 9B라는 크기는 문서 파싱 태스크에서 충분한 표현력을 가지면서도, 추론 비용이 폭증하지 않는 지점에 위치한 것으로 보입니다.
스키마 제약 디코딩의 작동 원리
lift의 핵심 차별점 중 하나는 schema-constrained decoding(스키마 제약 디코딩)입니다. 일반적인 VLM은 자유 텍스트를 생성하는 경향이 있어, 사후에 JSON으로 파싱하더라도 누락된 필드, 잘못된 타입, 추가 문장 출력 등 정합성 문제가 발생할 수 있습니다. lift는 디코딩 단계에서 스키마에 명시된 키와 타입에 해당하는 토큰만 후보로 남기는 마스킹을 적용해, 출력 자체가 항상 유효한 JSON이 되도록 강제합니다. 이는 환각을 사후 필터링으로 다루는 기존 접근과 본질적으로 다른, 구조적 해결책이라 할 수 있습니다.
학습된 abstention으로 환각 억제
스키마 제약 디코딩이 “형식의 환각”을 차단한다면, 학습된 abstention은 “내용의 환각”을 다룹니다. 모델은 학습 과정에서 “정보가 충분하지 않을 때는 추측하지 않고 null을 반환하라”는 신호를 받습니다. 결과적으로 lift는 청구서에 없는 할인 필드를 상상으로 채우지 않고 null로 비워두며, 이 동작은 후속 파이프라인에서 결측치 처리 로직과 자연스럽게 결합됩니다.
벤치마크 성능과 한계
225문서 평가에서의 90.2% 필드 정확도
Datalab는 자체적으로 구성한 225개 문서 벤치마크에서 lift의 필드 정확도(field accuracy)가 90.2%에 달한다고 보고했습니다. 필드 정확도는 추출된 JSON의 각 필드가 정답과 일치하는 비율을 의미하며, 문서 파싱 태스크에서 자주 사용되는 지표입니다. 9B 오픈 모델이 이 수준을 보고했다는 점은, 동일 클래스 태스크에서 전통적 OCR+규칙 파서 대비 더 단순한 파이프라인으로 유사한 결과를 낼 수 있음을 시사합니다(MarkTechPost 원문 보기).
스키마 다양성, 언어, 레이아웃 복잡도에 따른 격차
다만 90.2%라는 수치는 평균적인 지표이며, 도메인별로 상당한 편차가 존재할 것으로 보입니다. 다음 표는 실무에서 자주 마주치는 변수와 lift 적용 시 예상되는 영향 방향을 정리한 것입니다.
| 변수 | 예시 | lift 정확도에 미치는 영향(추정) |
|---|---|---|
| 스키마 복잡도 | 중첩 객체, 배열, 조건부 필드 | 중첩이 깊을수록 추론 비용 증가, 정확도 하락 가능 |
| 언어/문자 | 한글, 일본어, 아랍어 등 비라틴 문자 | 학습 분포에 따라 정확도 편차 발생 가능 |
| 레이아웃 | 다단 편집, 표/이미지 혼재, 손글씨 | 시각적 복잡도가 높을수록 인식 난이도 상승 |
| 문서 품질 | 저해상도 스캔, 회전/기울어짐 | 사전 보정 단계가 없으면 정확도 급락 가능 |
따라서 lift를 실제 운영 환경에 투입하기 전에는 자사 문서 샘플로 별도의 정확도 측정을 수행하는 것이 안전합니다. 90.2%는 매력적인 출발점이지만, 그것이 곧 전 도메인 일반화로 이어진다고 단정하기는 이른 것으로 판단됩니다.
실무 적용 시나리오와 통합 가이드
청구서, 계약서, 연구논문 JSON 추출 파이프라인
lift의 적용처로 자주 거론되는 것은 반복적이고 정형화된 추출이 필요한 문서군입니다. 예를 들어 월 수백 건의 청구서에서 공급사, 품목, 금액, 부가세 정보를 JSON으로 추출하거나, 계약서에서 당사자, 효력 발생일, 해지 조건을 구조화하는 작업이 대표적입니다. 연구논문이라면 저자 목록, 초록, 참고문헌 분리 같은 태스크에 활용할 수 있습니다. 스키마만 교체하면 동일 모델로 여러 문서 유형에 재사용할 수 있다는 점이 lift의 구조적 강점으로 분석됩니다.
Hugging Face 로컬 배포와 API 서빙 옵션
오픈 웨이트이므로 Hugging Face Transformers 기반의 로컬 서빙이 가장 자연스러운 진입점입니다. PDF를 페이지 단위 이미지로 변환해 lift에 전달하고, 반환된 JSON을 스키마 검증 라이브러리(예: pydantic, jsonschema)로 한 번 더 검증하는 구성을 권장합니다. 운영 부하가 커지면 vLLM이나 TGI 같은 추론 서버로 감싸고, 워커 풀과 메시 큐를 붙여 수평 확장하는 패턴이 일반적입니다. 클로즈드 API 대비 첫 응답(latency) 면에서는 불리할 수 있으나, 토큰당 비용과 데이터 주권(data sovereignty) 측면에서 우위를 가질 것으로 보입니다.
기존 OCR, GPT-4V, DocParser 계열 대비 트레이드오프
최적의 도구는 없다는 점이 핵심입니다. 다음은 실무 도입 검토 시 자주 비교되는 세 가지 대안과 lift의 상대적 위치를 정리한 것입니다.
- 전통적 OCR + 규칙 파서: 단순하고 결정적이지만, 레이아웃 변동에 취약하며 유지보수 비용이 누적됩니다. lift는 동일 비용대에서 레이아웃 적응력이 높을 것으로 보입니다.
- GPT-4V 등 클로즈드 VLM: 정확도와 다국어 능력은 강력하지만, 문서 단위 비용이 발생하고 민감 문서의 외부 전송이 발생합니다. lift는 온프레미스 운용으로 프라이버시와 단가를 모두 개선할 수 있습니다.
- DocParser 같은 상용 문서 API: 손쉬운 통합이 강점이지만, 벤더 종속과 스키마 유연성 제약이 따릅니다. lift는 스키마를 코드로 완전히 통제할 수 있다는 점에서 차별화됩니다.
전망과 과제
오픈 웨이트 비전 모델 생태계 확장 가능성
lift는 “특정 태스크에 깊게 특화된 오픈 웨이트 VLM”이 실용 수준에 진입했음을 보여주는 사례로 읽힙니다. 향후에는 표 추론, 영수증 분류, 양식 자동 채움과 같은 더 좁은 태스크용 오픈 모델이 잇따라 등장할 가능성이 있으며, 이러한 모델들이 결합되어 오픈소스 기반 문서 자동화 스택을 구성하는 그림이 점현해질 것으로 보입니다. 에이전트 프레임워크와의 결합 측면에서도, lift 같은 도구형 모델이 플래너 LLM의 손이 되는 구성이 자연스러운 확장으로 분석됩니다.
신뢰성 평가와 책임 있는 도입을 위한 체크리스트
마지막으로 운영 환경 도입 전 검토할 항목을 정리합니다. 이는 의견에 가까운 운영 가이드이며, 조직별 상황에 따라 가중치가 달라질 수 있습니다.
- 자사 문서 샘플 100건 이상으로 필드 정확도를 직접 측정했는가
- abstention 비율과 null 반환 패턴이 후속 비즈니스 로직과 호환되는가
- PII, 계약서 등 민감 문서에 대한 온프레미스 운용 정책이 수립되어 있는가
- 스키마 변경 시 모델 재평가와 회귀 테스트 절차가 정의되어 있는가
- 출력 JSON을 pydantic/jsonschema로 사후 검증하는 단계가 포함되어 있는가
- 장애 시 폴백(fallback) 경로, 예: 전통 파서 또는 휴먼 인 루프가 준비되어 있는가
정리 포인트
- lift는 9B 오픈 웨이트 비전 모델로, 스키마 기반 JSON 추출에 구조적으로 특화되어 있습니다.
- 스키마 제약 디코딩과 학습된 abstention의 조합이 형식과 내용 양쪽의 환각 억제 핵심입니다.
- 자체 225문서 벤치마크에서 필드 정확도 90.2%는 강력한 출발점이지만, 도메인별 재평가가 필수입니다.
- 온프레미스 운용과 스키마 통제 측면에서 클로즈드 VLM과 차별화되는 위치를 점합니다.
- 도입 시 사후 스키마 검증, abstention 처리 정책, 폴백 경로 설계가 함께 검토되어야 합니다.