Document AI — PDF 청구 LLM 추출부터 규칙 결정, 감사 추적까지

워크숍 목표

다 끝내고 나면 D.Hub 안에서 다음 흐름을 한 사이클 손으로 통과한 셈이 됩니다.

• 시나리오 1개를 포털로 적재해 inbox 와 processed 두 sub-collection, 데이터셋 3종, 코드 노드 3종, 파이프라인 3종, 온톨로지 3엔티티/2관계, 대시보드, 지식 1종을 한꺼번에 등록합니다.
• PDF 청구 서류의 메타데이터를 담은 claim_documents (object type) 데이터셋을 살펴봅니다.
• claim_extraction 파이프라인으로 OCR + LLM 추출을 돌려 PDF 한 장에서 날짜·금액·진단 코드·정책 번호 등의 구조화 필드를 뽑고, 필드별 confidence_score 를 함께 받습니다.
• decision_workflow 파이프라인의 6 규칙 결정 엔진으로 APPROVED / REJECTED / ESCALATED 셋 중 하나를 부여하고, 왜 그 결정인지 의 근거 텍스트를 decision_log 에 남깁니다.
• Document / Claimant / Policy 그래프에서 한 보험계약자의 청구 클러스터 를 펼쳐 봅니다.
• 처리 throughput, 결정 분포, SLA 준수율을 한 화면에 묶은 claims_processing 대시보드를 봅니다.

LLM 기반 자동 추출 + 규칙 기반 결정의 결합 패턴 이 핵심 학습 주제입니다. 권장 소요 시간은 90분.

사전 준비

• D.Hub 포털 접근 가능한 분석가 또는 엔지니어 계정 (Editor 권한 이상)
• 약 42KB 의 zip 한 개를 받을 다운로드 여유

터미널·Python·dhub2-examples 클론은 필요 없습니다.

1. 시나리오 적재 (10분)

포털 좌측 사이드바의 컬렉션 → 더보기(⋯) → 가져오기 로 zip 을 올립니다.

manifest.json 순서대로 다음 자산이 올라갑니다.

1. 컬렉션 2종 — inbox (alias: 수신 청구 서류), processed (alias: 처리 완료)
2. 데이터셋 3종 — claim_documents (inbox, object type), extracted_fields (processed), decision_log (processed)
3. 코드 3종 (Python) — document_parser, claim_adjudicator, build_docai_ontology
4. 파이프라인 3종 — claim_extraction, decision_workflow, ontology_materialization
5. 온톨로지 — 엔티티 3종(Document, Claimant, Policy), 관계 2종(filed_by, covered_by)
6. 지식 1종 — claims_handbook (청구 처리 규정)
7. 대시보드 — claims_processing

적재가 끝나면 좌측 트리에 inbox 와 processed 두 컬렉션이 보입니다. 수신 → 처리 의 시간 흐름을 컬렉션 구조로 표현한 패턴입니다.

2. 청구 서류 둘러보기 (10분)

inbox 컬렉션의 claim_documents 는 object type 데이터셋입니다. 행 하나가 PDF 한 파일에 대응하고, 컬럼은 PDF 자체가 아니라 메타데이터 입니다.

• claim_id — 청구 고유 식별자
• document_key — S3 / 객체 저장소의 PDF 키
• claimant_name — 청구인 이름
• policy_number — 보험 증권 번호
• received_at — 수신 일시
• page_count — 페이지 수
• source_channel — email / web_portal / mobile_app

PDF 본문 자체는 다음 단계에서 document_parser 가 문서 키로 가져와 처리합니다. 이 분리 — 메타데이터 데이터셋 + 객체 저장소 — 는 대용량 비정형 데이터 패턴의 표준입니다.

processed 컬렉션을 열어 보면 extracted_fields 와 decision_log 두 데이터셋이 행 0 으로 비어 있습니다. 다음 단계 파이프라인이 첫 행을 채워 넣습니다.

3. LLM 기반 필드 추출 (20분)

processed 컬렉션의 파이프라인 섹션에서 claim_extraction 을 엽니다. 노드 하나, document_parser 가 claim_documents 의 각 행을 읽어 PDF 한 장씩 처리합니다.

document_parser 스크립트의 처리 흐름은 두 단계입니다.

1. OCR (pdfplumber) — PDF 페이지에서 텍스트 레이아웃을 추출. 스캔 이미지면 OCR fallback.
2. LLM 추출 — 추출된 텍스트를 LLM 에 구조화 추출 프롬프트 와 함께 보내, 다음 필드를 JSON 으로 받습니다:
   • incident_date — 사고/사건 일자
   • claim_amount — 청구 금액
   • diagnosis_code — ICD 진단 코드 (의료 청구의 경우)
   • policy_number — 증권 번호
   • provider_name — 의료기관 이름 (해당 시)
   • confidence_score — 0~1, LLM 의 이 추출에 대한 자신감

핵심은 confidence_score 입니다. LLM 이 불확실한 필드를 솔직히 표시하도록 프롬프트가 설계돼 있고, 다음 단계의 결정 엔진이 confidence < 0.6 인 청구를 자동 에스컬레이션 합니다.

Run 을 눌러 실행합니다. 끝나면 extracted_fields 미리 보기에서 행 수가 claim_documents 와 같은지, confidence_score 컬럼이 0~1 사이로 분포돼 있는지 봅니다.

4. 6 규칙 결정 엔진 (15분)

processed 의 decision_workflow 파이프라인을 엽니다. 노드 하나, claim_adjudicator 가 extracted_fields 를 읽어 decision_log 를 만듭니다.

claim_adjudicator 스크립트의 6 규칙은 우선순위 순서로 평가됩니다.

핵심은 기본값이 ESCALATED 라는 점 입니다. 자동 승인은 충분히 자신 있고 충분히 작은 청구만 받고, 나머지는 모두 사람에게 넘어갑니다. 보험 도메인의 위양성 비용 ≫ 위음성 비용 비대칭을 반영한 설계입니다.

Run 을 눌러 실행합니다. 끝나면 decision_log 미리 보기에서 결정 분포가 대략 APPROVED : REJECTED : ESCALATED ≈ 4 : 2 : 4 비율로 잡힙니다. reason 컬럼이 왜 그 결정인지 한 줄로 설명합니다 — 감사·규제 대응의 핵심 컬럼입니다.

5. 온톨로지 + 그래프 탐색 (10분)

ontology_materialization 을 한 번 돌립니다. build_docai_ontology 가 세 데이터셋을 batch 모드로 읽어 다음 5개 산출물을 upsert 모드로 적재합니다.

그래프 탐색기 에서 한 청구인의 과거 청구 클러스터 를 한 번 펼쳐 봅니다.

MATCH (c:Claimant)<-[:filed_by]-(d:Document)-[:covered_by]->(p:Policy)
WHERE c.claim_count >= 3
RETURN c, d, p
LIMIT 25

3건 이상 청구한 사람의 청구 패턴이 그래프 한 화면에 들어옵니다. 같은 Policy 노드로 여러 Document 가 연결되는 군집이 잡히면, 반복 청구 패턴의 첫 시각화입니다.

6. 대시보드 + 감사 추적 (15분)

claims_processing (alias: 청구 처리 대시보드) 을 열면 위젯 8종이 한 화면에 묶여 있습니다.

• Claims Received (statistic) — claim_documents 의 COUNT(*)
• Decisions Made (statistic) — decision_log 의 COUNT(*)
• Avg Extraction Confidence (statistic) — extracted_fields 의 AVG(confidence) (소수 둘째 자리)
• SLA Met Rate (statistic) — decision_log 의 sla_met 플래그 충족 비율 (%)
• Decision Distribution (도넛) — decision_log 의 decision 별 건수 (APPROVED / REJECTED / ESCALATED 분포)
• Escalations by Reason (막대) — decision_log 의 reason 별 건수, 내림차순
• Claims by Channel (막대) — claim_documents 의 source_channel 별 건수 (email / web_portal / mobile_app)
• Recent Claims (데이터 테이블) — claim_documents 의 received_at 내림차순 최근 100건

운영 시점의 핵심 시그널은 두 statistic + 두 분포 위젯입니다. Avg Extraction Confidence 가 0.7 아래로 떨어지면 LLM 프롬프트나 OCR 품질을 점검해야 하고, SLA Met Rate 가 낮으면 §4 의 결정 엔진이 ESCALATED 로 너무 자주 떨어진다는 신호입니다. Escalations by Reason 막대의 첫 라벨은 어떤 규칙이 가장 자주 ESCALATED 를 만드는지를 한 줄로 보여 줍니다.

7. 다음 단계 + 회고 (10분)

여기까지 왔다면 한 시나리오 위에서 다음 다섯 흐름을 한 번씩 통과한 셈입니다.

• 메타데이터 데이터셋(object type) + 객체 저장소의 분리 패턴
• OCR + LLM 의 구조화 추출 + confidence_score 시그널
• 규칙 엔진의 기본값 ESCALATED 비대칭 설계
• 그래프로 본 반복 청구 클러스터
• reason 컬럼 기반 감사 추적

끌리는 방향으로 한 발 더:

• refund_approval 워크숍 에서 같은 시나리오의 HITL 에이전트 변종을 손으로 짚어 봅니다. 기본 ESCALATED → 사람 검토 → 자동 실행 의 흐름이 보험에도 그대로 옮겨집니다.
• 분석가 코스 의 위젯 관리 레슨에서 에스컬레이션 사유 Top 5 위젯의 SQL 모드를 재구성합니다.
• 자기 도메인 의 문서 → 구조화 → 결정 흐름 (계약 검토·인보이스 처리·이력서 스크리닝) 으로 본 형판을 옮겨 씁니다.

검증 체크리스트

• 컬렉션 트리에 inbox 와 processed 두 컬렉션이 다 보이고, claim_documents 가 object type 으로 잡혀 있는지
• claim_extraction 실행 뒤 extracted_fields 의 confidence_score 가 01 사이로 분포돼 있는지 (0.40.55 인 행이 한두 개 있어야 함)
• decision_workflow 실행 뒤 decision_log 의 결정이 APPROVED / REJECTED / ESCALATED 세 라벨로 분포돼 있고, 각 행에 reason 텍스트가 채워졌는지
• 그래프 탐색기에서 Claimant 한 노드를 시작점으로 filed_by → Document → covered_by → Policy 3-홉 경로를 펼칠 수 있는지
• claims_processing 대시보드의 결정 분포 위젯에서 ESCALATED 비중이 가장 크게 잡히는지 (기본값 ESCALATED 설계의 직접적 결과)