3/7번째 챕터

20분

자동화를 멈추고 사람에게 인계하기

순서가 있는 규칙으로 청구를 판정하고 사람이 확인해야 할 이유를 decision_log에 남깁니다.

이번 단계의 질문

confidence가 기준보다 낮을 때 자동화는 무엇을 남기고 멈춰야 할까요?

단순히 “처리 실패”라고 남기면 다음 담당자는 처음부터 원인을 찾아야 합니다. 자동화가 멈춘 결정과 이유를 함께 기록해야 사람이 판단을 이어받을 수 있습니다.

processed 컬렉션에서 decision_workflow를 엽니다. claim_adjudicator는 각 청구를 순서가 있는 규칙에 대입하고, 처음 일치한 결정에서 멈춥니다.

Run을 선택하기 전에 CLM-2025-006을 예상해 보세요. 첫 번째 규칙은 다음과 같습니다.

confidence < 0.6이면 자동 처리를 멈추고 ESCALATED로 기록합니다.

이제 Run을 선택한 뒤 decision_log를 엽니다.

한 행에서 결정과 이유를 함께 확인할 수 있습니다.

`claim_id`	`decision`	`reason`
`CLM-2025-006`	`ESCALATED`	`confidence 0.52 below threshold 0.6`

이 청구는 금액만 보면 1,000달러 초과 5,000달러 미만의 표준 청구입니다. 하지만 첫 번째 품질 규칙에서 멈췄기 때문에 금액 규칙까지 내려가지 않습니다. 규칙의 순서 자체가 정책인 이유입니다.

ESCALATED는 실패가 아니라 책임 있는 인계입니다. 심사 담당자는 reason을 보고 원본의 금액과 진단 코드를 먼저 대조할 수 있습니다. 차이가 있다면 값을 바로잡고, 차이가 없다면 낮은 신호가 만들어진 경로를 점검합니다.

깊이 보기 — 여섯 규칙과 샘플 전체 분포

순서	확인 질문	조건	결정
1	구조화 결과를 믿을 수 있는가?	`confidence < 0.6`	`ESCALATED`
2	필수 진단 코드가 있는가?	`diagnosis_code`가 비어 있음	`ESCALATED`
3	보장 제외 진단인가?	`diagnosis_code = EXCLUDED`	`REJECTED`
4	소액 신속 승인 대상인가?	`claim_amount <= 1000`	`APPROVED`
5	고액 수동 검토 대상인가?	`claim_amount >= 5000`	`ESCALATED`
6	위 예외에 해당하지 않는가?	그 외	`APPROVED`

샘플 10건 전체 결과는 APPROVED 4건, REJECTED 1건, ESCALATED 5건입니다. 이 분포는 좋고 나쁨의 점수가 아니라 현재 샘플과 규칙을 적용했을 때 어느 처리 경로로 흘렀는지를 보여 줍니다.

결정과 이유는 남았지만, 다른 담당자는 청구인과 증권의 맥락도 확인해야 합니다. 다음 챕터에서는 흩어진 데이터를 관계로 연결해 같은 결정을 다시 추적합니다.