문서 비중이 높은 도메인에서 데이터 파이프라인을 구축하는 사람이라면 누구나 불편하게 느낄 만한 추정치가 있습니다. 기업이 알고 있는 지식의 60%에서 80% 사이는 데이터베이스에 전혀 들어있지 않습니다. 그것은 PDF, 스캔본, 이미지로 변환된 팩스, 그리고 이메일 첨부 파일 형태로 존재합니다.

이러한 도메인의 모든 ML (머신러닝) 프로젝트는 동일한 흐름을 따릅니다. 자신만만하게 시작했다가, 문서라는 벽에 부딪히고, 결국 이미 구조화되어 있는 데이터로 범위를 조용히 축소합니다. 그런데 그 데이터는 조직이 알고 있는 지식 중 가장 흥미롭지 않은 부분입니다.

이 포스트는 그 문제를 해결하는 파이프라인을 구축하는 방법과, 그 파이프라인의 작동 여부를 결정짓는 설계 결정에 관한 것입니다.

2015년 방식이 실패한 이유 (그리고 왜 더 이상 적용되지 않는가)

대부분의 조직은 이전에 템플릿 기반 OCR (광학 문자 인식) 방식을 시도했다가 실망했습니다. 똑같은 것을 다시 만들지 않으려면 왜 실패했는지 이해할 가치가 있습니다.

템플릿 OCR은 페이지의 _어느 위치_에 값이 있는지 파악하여 작동합니다. 예를 들어 좌표 (420, 310)에 있는 텍스트를 추출하는 방식입니다. 이 방식은 공급업체가 송장 레이아웃을 변경하거나, 양식을 비스듬한 각도에서 촬영하거나, 새로운 문서 유형이 나타나는 순간 무용지물이 될 정도로 취약합니다. 팀들은 상위 5개 형식에 대한 템플릿을 만들어서 전체 물량의 약 40%를 커버했지만, 나머지 롱테일 (long tail) 부분은 포기했습니다.

현대의 문서 AI (Document AI)는 좌표로 값을 찾는 것이 아닙니다. 문서를 읽고 _그것이 무엇인지_를 이해합니다.

추출하기 전에, 해당 문서가 _무엇인지_를 먼저 결정하십시오: 의료 보고서, 수리 견적서, 경찰 보고서, 계약서 등입니다. 이것은 생각보다 훨씬 중요합니다. 추출 스키마 (extraction schemas)는 문서 유형별로 다르며, 분류를 잘못하면 이후의 모든 과정이 쓸모없는 데이터 (garbage)가 됩니다. 분류 오류는 소리 없이 발생하지만, 잘못 분류된 문서에서 발생하는 추출 오류는 마치 유효한 데이터처럼 보이기 때문입니다.

이 단계에 실질적인 노력을 투입하십시오. 이곳은 비용이 많이 드는 무의미한 오류를 방지할 수 있는 가장 저렴한 지점입니다.

3. 신뢰도 점수 (confidence scores)와 함께 스키마로 추출하기

"여기 텍스트가 있습니다"라고 던져주는 방식은 안 됩니다. 그것은 그저 형태가 다른 비정형 데이터 덩어리 (unstructured blob)일 뿐입니다. 각 항목에 **신뢰도 값 (confidence value)**을 포함하여 **정의된 필드 (defined fields)**로 추출하십시오:

{
  "doc_type": "repair_estimate",
  "fields": {
...

신뢰도 점수는 다음 단계를 가능하게 만드는 핵심 요소입니다.

4. 신뢰도에 따른 라우팅 (Route by confidence) — 시스템을 작동하게 만드는 결정

이것은 실제로 작동하는 파이프라인과 단순한 데모를 구분 짓는 설계상의 선택입니다. 완벽한 자동화를 목표로 하지 마십시오. 조정 가능한 임계값 (tunable threshold)을 목표로 하십시오.

• 임계값 초과 → 사람의 개입 없이 즉시 처리
• 임계값 미만 → 사람이 수정할 수 있는 검토 대기열 (human review queue)로 전송

이렇게 하면 자동화율은 비즈니스의 위험 감수 성향 (risk appetite)에 따라 조절할 수 있는 다이얼이 됩니다. 아무도 신뢰하지 않는 상황에서 100% 자동화를 달성해야만 하는 이진법적 문제가 아닙니다. 처음에는 보수적으로 시작하고, 근거가 쌓임에 따라 임계값을 높여 나가십시오.

5. 수정 사항을 다시 피드백하기

4단계에서 이루어진 사람의 수정 사항은 **이미 수행하고 있던 업무를 통해 무료로 생성된 라벨링된 학습 데이터 (labelled training data)**입니다. 이러한 수정 사항을 캡처하지 않는 파이프라인은 가장 강력한 개선 신호를 스스로 버리는 것과 같습니다. 모든 수정 사항을 원래의 추출 결과 및 소스 문서와 함께 기록하십시오.

6. 출처 (provenance) 유지하기

추출된 모든 필드는 반드시 해당 소스 문서와 페이지를 가리켜야 합니다. 누군가가 roof_age: 18이 어디서 나왔는지 물었을 때 — 규제 대상 도메인(regulated domain)에서는 반드시 물어보게 될 것입니다 — "모델이 그렇게 말했습니다"는 정답이 될 수 없습니다. 문서 ID, 페이지, 그리고 이상적으로는 경계 영역 (bounding region)을 저장하십시오.

함정: 모든 것을 추출하려 하지 마십시오

본능적으로는 40년 치의 모든 유형과 모든 필드를 디지털화하려 할 것입니다. 하지만 그런 프로그램은 3년이 걸리며, 18개월 만에 취소되기 마련입니다.

관점을 뒤집으십시오. 질문하십시오: 지금 당장 의사결정을 가로막고 있는 구체적인 필드(field)는 무엇인가? 보통은 비용, 날짜, 분류, 몇 가지 속성 등 소수의 필드에 불과합니다. 현재 활발히 처리 중인 문서들 중에서, 해당 정보를 담고 있는 문서 유형으로부터 그 필드들만 추출하십시오.

결코 이루지 못할 일 대신, 6주 안에 결과물을 내놓으십시오. 아카이브(archive)는 기다릴 수 있습니다. 아무도 1998년도 계약서를 검색할 수 있게 해달라고 요청하지 않습니다. 그들은 왜 의사결정에 여전히 3일이나 걸리는지를 묻고 있는 것입니다.

이것이 기능(feature)이 아닌 기반 인프라(enabling infrastructure)인 이유

문서 인텔리전스(Document intelligence)는 화려하지 않으며, 누구도 데모로 보여주지 않는 유스케이스(use case)입니다. 하지만 로드맵의 절반이 실현되기 위해서는 반드시 작동해야 하는 요소입니다. 왜냐하면 모델들이 필요로 하는 데이터가 스캔된 팩스 안에 들어있기 때문입니다.

이를 하나의 프로젝트가 아닌 인프라로 취급하는 팀은, 정체되어 있던 여러 이니셔티브(initiative)가 조용히 동시에 움직이기 시작하는 것을 경험하게 됩니다.

우리는 AI가 의존하는 문서 파이프라인(document pipelines)과 구조화된 데이터 기반(structured data foundations)을 구축합니다. 자세한 내용은 IntelliBooks에서 확인하세요.