TL;DR
- 프런티어 모델이 문서 처리 시장을 대체할 것이라는 예측과 달리, 시장은 2024년 20억 달러 초과 규모에서 매년 약 3분의 1씩 성장하며 정밀하고 검증 가능한 데이터 추출의 중요성이 커지는 추세임.
- 문서 처리는 1990년대 은행 수표 필기 인식 신경망부터 이어진 분야이며, 프런티어 모델은 수요보다 오류가 후속 작업에 미치는 위험을 키움.
- 문서 처리의 난제는 문서 읽기에서 긴 문서의 주의력·환각 문제를 거쳐, 필드마다 정확성을 보장해야 하는 정밀도로 이동함.
OmniDocBench에서 최고 수준 프런티어 모델은 전체 점수 약 90점을 기록하지만 표와 읽기 순서 점수는 더 낮으며, 보험 청구 같은 자동화 결정에는 부족할 수 있음.- 문서 도구는 페이지 요소별 처리, 바운딩 박스 기반 출처 추적, 필요에 따라 조합 가능한 처리 체인을 제공해야 함.
작업은 유행보다 오래됐고, 유행은 중요성을 높임
- 문서 처리의 역사는 GPT-4V보다 오래됐으며, 대표적인 초기 성과로 1990년대 Bell Labs의 Yann LeCun 팀이 신경망으로 은행 수표의 필기체를 읽은 사례가 있음. 당시 모델은 수백 킬로바이트였고, 오늘날 모델은 수백 기가바이트 규모임.
- 현대 문서 모델의 계보는 2020년경
LayoutLM이 문서의 텍스트와 이차원 레이아웃을 함께 학습하면서 이어짐. - 프런티어 모델이 바꾼 것은 문서 처리 수요가 아니라 중요성임. 검색 증강 생성(RAG)과 에이전트가 등장하면서 추출 데이터의 품질이 이후 작업 전체의 품질을 좌우함.
- 잘못 읽힌 표는 잘못된 문맥이 되고, 그 문맥은 문제가 터질 때까지 발견되지 않는 확신에 찬 오답으로 이어질 수 있으며, 이런 문제가 현재 실제 운영 환경에서 발생함.
페이지 읽기는 쉬워졌지만 모든 필드를 신뢰하기는 어려움
- 문서 처리의 난제는 시기별로 이동함.
- 2020~2023년: 모델이 문서 구조와 레이아웃을 파악하고 복잡한 페이지를 쓸 수 있는 형태로 변환하는 문제임.
- 2024~2025년: 긴 문서의 중간 내용을 놓치거나 원문에 없는 값을 만들어내는 주의력과 환각 문제임.
- 2026년: 조금이라도 틀리면 틀린 것과 같은 결과가 되는 정밀도 문제임.
- 원시적인 문서 읽기는 대체로 해결된 상태임. 표준 문서 파싱 벤치마크인
OmniDocBench에서 최고 수준 프런티어 모델은 전체 점수 약 90점을 기록하지만, 표와 읽기 순서 점수는 눈에 띄게 낮음. - 보험 청구에 관한 자동화된 결정을 지원하는 경우에는 이러한 성능만으로 충분하지 않을 수 있음.
- 그래서 분야가 전문 모델 개발을 멈추지 않음. 2025년까지 범용 모델과 함께 특정 용도에 맞춘 문서 모델이 잇따라 등장함.
다음 모델이 문서 처리를 단순히 흡수하지 못하는 이유
- 모델 성능이 계속 향상되더라도 넘어야 할 기준도 함께 높아짐.
- 추출 결과를 신뢰할 수 있게 되면 사람의 개입 없이 데이터에 따라 에이전트가 행동하는 고위험 업무 흐름에 적용되므로, 필요한 정밀도가 원시 모델 성능이 격차를 좁히는 속도보다 빠르게 높아짐.
- 가치가 집중되는 영역은 정밀도가 중요하고 검증 가능한 마지막 단계임.
- 프런티어 모델 자체를 반대하는 주장은 아님. 프런티어 모델은 강력한 구성 요소이며 Unstructured도 이를 사용함. 다만 단독으로는 시연 수준에 그치며, 업무상 핵심적인 작업에서 신뢰하려면 입력되는 모든 파일 형식을 읽고, 처리량을 감당하며, 각 필드를 정확히 추출해야 함. 잘못된 값 하나가 후속 단계 전체에 영향을 미칠 수 있음.
지금 문서 도구에 요구할 사항
- 문서 공급업체에는 다음 세 가지를 확인해야 함.
- 페이지의 각 요소는 서로 다른 문제임. 표, 양식, 차트, 필기, 셀에 연결된 각주에는 저마다 특성이 있으므로 요소에 맞춘 처리가 필요함. 페이지 전체를 하나의 작업으로 다루는 범용 모델과 달리, 적절한 도구는 각 요소가 실패하는 지점을 파악하고 그에 맞게 구축돼야 함.
- 결과의 출처를 추적할 수 있어야 함. 모든 요소에 페이지상 위치의 좌표인 바운딩 박스가 포함되면, 중요한 값이 원문의 어디에서 왔는지 확인하고 대조할 수 있음. Claude는 추출한 텍스트의 좌표를 제공하지 않음.
- 필요에 따라 조합할 수 있는 처리 체인이어야 함. 일부 팀은 문서를 넣으면 구조화된 데이터를 돌려주는 단일 엔드포인트를 원하고, 다른 팀은 데이터가 있는 곳에서 가져와 후속 시스템으로 전달하는 전체 흐름이 필요함. 당장 필요한 부분부터 사용하고 나머지로 확장할 수 있어야 함.
문서 처리에서 작업이 남은 영역
- 문서가 더 이상 문제가 되지 않을 것이라는 예측과 달리, 문서는 더 가치 있는 문제가 됐으며 어려운 부분은 페이지를 읽는 일에서 페이지의 모든 필드를 신뢰하는 일로 이동함.
- 페이지 읽기는 대부분 해결됐지만, 추출된 값을 신뢰하는 일은 여전히 진행 중인 과제임.
댓글 (0)
로그인하면 이 기사에 내 생각을 남길 수 있어요