4/7번째 챕터

20분

결정의 맥락을 관계로 추적하기

청구 문서와 청구인·증권을 연결해 에스컬레이션된 결정의 맥락을 다시 찾습니다.

이번 단계의 질문

결정 로그 한 행만으로 다음 담당자가 청구의 전체 맥락을 찾을 수 있을까요?

왜 지금 필요한가

decision_log는 무엇을 결정했고 왜 멈췄는지 알려 줍니다. 하지만 누가 제출했고 어느 증권과 연결되는지는 다른 데이터셋에 있습니다. 이 관계를 함께 볼 수 있어야 원본과 결정의 맥락을 빠르게 되짚을 수 있습니다.

직접 해보기

ontology_materialization 파이프라인을 열고 Run을 선택합니다. 실행이 끝나면 그래프 탐색기에서 다음 쿼리를 실행합니다.

MATCH (c:da_claimant)<-[:da_filed_by]-(d:da_document)-[:da_covered_by]->(p:da_policy)
WHERE d.claim_id = 'CLM-2025-006'
RETURN c, d, p
LIMIT 25

이 화면이 나오면 성공

그래프에서 CLM-2025-006 문서가 Frank Wilson과 POL-60444 사이에 연결됩니다.

flowchart LR
    accTitle: 에스컬레이션된 청구의 관계
    accDescr: Frank Wilson 청구인이 CLM-2025-006 문서를 제출했고, 그 문서가 POL-60444 보험 증권의 보장 대상이며 결정 로그에는 사람 검토가 필요한 이유가 남아 있습니다.
    claimant["청구인<br/>Frank Wilson"] -->|"da_filed_by"| document["청구 문서<br/>CLM-2025-006"]
    document -->|"da_covered_by"| policy["보험 증권<br/>POL-60444"]
    document -. "reason" .-> decision["사람 검토<br/>confidence 0.52"]

이 관계는 claim_documents, decision_log, 증권 정보를 한 청구 식별자로 다시 연결한 결과입니다.

결과를 읽어 봅니다

사람에게 인계할 때는 결정만 전달해서는 부족합니다. 결정, 이유, 원본 위치, 청구인과 증권의 맥락이 함께 있어야 다음 담당자가 같은 근거를 재구성할 수 있습니다.

현재 샘플에서는 청구인 10명과 증권 10개가 모두 한 번씩만 등장합니다. 따라서 여러 청구가 모인 반복 청구 클러스터를 이 데이터로 확인할 수는 없습니다. 여기서는 한 문서의 맥락을 정확히 연결하는 데 집중합니다.

깊이 보기 — 현재 사람 인계의 범위

decision_log의 adjuster_id는 모두 비어 있습니다. 기본 Portal 실행도 원본 PDF를 객체 저장소에서 내려받지 않습니다. 합성 원본은 시나리오의 docai/data/pdf/clm_006.pdf에 있습니다.

이 시나리오는 사람이 검토해야 한다는 결정과 이유까지 만듭니다. 원본 열람, 담당자 배정, 최종 승인 화면, 검토 완료 상태는 별도 업무 절차가 필요합니다.

다음 판단

한 청구의 맥락을 추적했습니다. 다음 챕터에서는 시선을 샘플 10건 전체로 넓혀, 운영팀이 같은 결론을 대시보드에서 어떻게 확인하는지 살펴봅니다.