1/7번째 챕터
15분
청구 한 건에서 첫 단서 찾기
시나리오를 가져온 뒤 원본 문서와 접수 메타데이터를 구분합니다.
이번 단계의 질문
청구를 판단하기 전에 이미 알고 있는 정보와 문서에서 읽어야 할 정보는 무엇일까요?
왜 지금 필요한가
한 값이 어디에서 왔는지 모르면 나중에 오류 원인을 찾기 어렵습니다. 먼저 접수 정보와 원본 문서의 경계를 정해 두면 구조화 결과를 검토할 기준이 생깁니다.
직접 해보기
docai.zip 다운로드(43 KB)포털 왼쪽 사이드바의 컬렉션을 선택합니다. 컬렉션 페이지 오른쪽 위 더 보기(⋯) → 가져오기에서 zip 파일을 올립니다.
가져오기를 시작하면 manifest.json에 정의된 자산이 등록됩니다. 아래 깊이 보기에서
자산 종류와 구성을 확인할 수 있습니다.
가져오기가 끝나면 processed 컬렉션에서 claim_documents 데이터셋을 엽니다. claim_id가
CLM-2025-006인 행을 찾으세요.
이 화면이 나오면 성공
컬렉션 트리에 inbox와 processed가 보이고, CLM-2025-006 행에서 다음 접수 정보를
확인할 수 있습니다.
| 확인할 값 | 현재 값 | 이 값이 알려 주는 것 |
|---|---|---|
document_key | claims/inbox/clm_006.pdf | 원본 PDF를 찾을 위치 |
claimant_name | Frank Wilson | 청구인 |
policy_number | POL-60444 | 보험 증권 |
received_at | 2025-03-01 11:15:00 | 접수 시각 |
source_channel | portal | 접수 채널 |
결과를 읽어 봅니다
지금 보고 있는 행은 PDF 본문이 아니라 문서를 접수할 때 이미 알고 있던 메타데이터입니다.
- 원본 문서:
clm_006.pdf에 적힌 청구 금액과 진단 내용입니다. - 접수 메타데이터: 문서 위치, 청구인, 증권 번호, 접수 시각처럼 처리 전에 아는 값입니다.
- 구조화 결과: 다음 챕터에서 파이프라인이 문서와 메타데이터를 한 행으로 정리한 값입니다.
깊이 보기 — 가져온 자산 전체
| 자산 종류 | 수량 | 구성 |
|---|---|---|
| 컬렉션 | 2 | inbox, processed |
| 데이터셋 | 3 | claim_documents, extracted_fields, decision_log |
| 코드 | 3 | 문서 구조화, 청구 판단, 온톨로지 적재 |
| 파이프라인 | 3 | 청구 추출, 결정 흐름, 온톨로지 적재 |
| 온톨로지 | 엔티티 3 / 관계 2 | 문서·청구인·증권 / 접수·보장 관계 |
| 지식 | 1 | claims_handbook |
| 대시보드 | 1 | claims_processing |
inbox는 향후 수신 자산을 분리하기 위한 빈 컬렉션입니다. 실습 자산은 모두
processed에 들어 있습니다. 샘플 전체의 접수 채널은 email 4건, portal 4건,
fax 2건입니다.
다음 판단
접수 정보만으로는 PDF에 적힌 청구 금액과 진단 코드를 판단할 수 없습니다. 다음 챕터에서는 문서를 구조화하고, 만들어진 값을 자동 결정에 사용해도 되는지 확인합니다.