13.9.2 필드별(Field-level) 정확도 vs 문서별(Document-level) 처리 성공률

엔터프라이즈 MLOps 대시보드 회의체에서 가장 흔하게 발생하며, 데이터 과학자(Data Scientist)들이 현업 비즈니스 부서를 상대로 저지르는 가장 질 나쁜 착시 현상이자 자기 기만(Self-deception)이 하나 있다. 바로, 거대 언어 모델(LLM)의 비정형 추출 성능을 달콤한 **‘필드(Field) 레벨 단위’**의 평균치로 은근슬쩍 뭉뚱그려 포장하여 경영진에게 보고하는 행위다.

리얼 월드의 비정형 데이터 추출 파이프라인에서 가장 중요한 아키텍처적 본질은 질문의 단위를 바꾸는 데 있다. 본질은 결코 *“모델이 수많은 개별 단어 조각(Token/Field)들을 얼마나 잘 맞혔는가?”*가 아니다.
엔터프라이즈 시스템이 우리에게 던지는 유일하고도 가혹한 질문은 **“저 종이 문서 덩어리(Document) 1장이, 오라클에게 한 번도 거부당하지 않고 완벽하게 무결점 상태로 원패스(One-pass) 직행 통과를 이루어 냈는가?”**이다.

1. 필드 레벨 정확도(Field-level Accuracy)의 함정과 착시

우리가 13장에서 애써 구축한 Pydantic InvoiceMaster 클래스 안에서, 영수증 1장당 추출해야 할 필수 타겟 필드가 무려 20개(벤더명, 인보이스 날짜, 서브토탈, 세금, 라인 아이템 등)의 복잡한 계층 구조를 띠고 있다고 가정해 보자.

비전 LLM이 오늘 하루 100장의 영수증 이미지를 텍스트로 처리하면서 총 2,000개의 필드를 추출했다. 그런데 모델이 100장의 영수증에서 모두 공통적으로 영수증 맨 밑 귀퉁이에 적힌 ’세금 율(Tax Rate)’이라는 단 1개의 필드에서만 반복적으로 스캔 환각을 일으켜 추출에 실패(또는 오답)했다고 치자.
이때 어리석은 개발팀의 대시보드에는 **필드 레벨 정확도(Field-level Accuracy)**가 \frac{1900}{2000} = 95\% 라는 매우 훌륭하고 이상적인 A급 수치로 찬란하게 찍힌다. 모델 리서치 팀은 이 95%라는 달콤한 숫자에 취해 모델이 완성되었다며 파이프라인 라이브 오픈(Go-Live)을 강행한다.

하지만 이는 시스템의 아키텍처를 전혀 이해하지 못한 거대하고 끔찍한 착시다. 세금(Tax) 필드의 숫자 하나가 환각으로 틀어지면 어떻게 될까? 우리 파이프라인의 무자비한 ’2단계 산술 오라클’은 즉시 단가 합계와 토탈이 맞지 않는 연산 모순을 찾아내고 여지없이 ValidationError 예외(Exception)를 격발시킨다. 그리고 그 영수증 객체 전체의 데이터베이스 INSERT를 기각(Reject)시키고 트랜잭션 덩어리 채로 인간에게 던져버린다.

2. 진정한 MLOps 북극성 지표: 문서 레벨 STP 직행 처리율 (Document-level STP Rate)

기업의 비즈니스 오퍼레이션(결제, 재무, 물류) 관점에서 모든 트랜잭션 데이터베이스는 불변의 **원자성(Atomicity)**을 가진다. 즉, All or Nothing이다.
20개 필드 중 부분 점수로 19개를 맞혔든, 아니면 참담하게 1개밖에 못 맞혔든 시스템 입장에서는 전혀 중요하지 않다. 오라클의 3단계 검증망 중 단 하나라도 통과하지 못해 에러가 격발되면, 그 잘 맞힌 19개의 필드 값들조차 모두 폐기 처분되고 전체 영수증 덩어리(Document)가 통째로 묶여 인간의 수동 확인 대기열(HITL Review Queue)로 압송되어 인간의 비싼 인건비 노동을 빨아먹게 된다.

따라서 우리가 설계한 파이프라인의 진정한 투자수익률(ROI)을 측정하고 유지보수할 때, 벽에 걸어두고 추적해야 하는 가장 가혹한 진실의 거울이자 진정한 **북극성 지표(North Star Metric)**는 바로 **‘문서 레벨 직행 처리율(Document-level Straight-Through Processing Rate, STP Rate)’**이다.

• 수식: STP\_Rate = \frac{HITL(인간)의 개입 없이 원패스로 코어 오라클을 모두 무사 통과한 총 문서 수}{전체 시스템에 인입된 원본 요청 문서 수}

앞선 95% 필드 정확도의 예시로 다시 돌아가 보자. 100장의 영수증이 모두 미세한 ’세금 에러 1개’씩을 개별 품고 있었다면, 결국 오라클의 철퇴를 맞고 인간 통제관의 큐(Queue)로 비참하게 튕겨져 나간 영수증의 개수는 10장이나 5장이 아니라 100장 전부(All)가 된다. 즉, 개발팀이 자랑하던 95% 시스템의 진실 앞에서는, **문서 레벨 STP Rate가 0%**라는 아무짝에도 쓸모없는 참담한 쓰레기 모델의 실체가 드러나게 된다.

결국 진성 MLOps 아키텍트이자 오라클 설계자는, 논문에서 쓰기 좋고 숫자도 예쁘게 나오는 교과서적인 ‘필드 단위 평가 평균치’ 뒤에 비겁하게 숨어선 안 된다. 오히려 스스로를 가장 냉혹하고 가혹한 잣대인 **‘문서 단위 완전 패스율(Document-level Pass Rate)’**에 묶어두고 메인 핵심 성과 지표(KPI)로 선언해야만 한다. 시스템 설계자는 전체 트랜잭션의 원자성 관점에서 작은 결함 1개가 거대한 덩어리의 실패로 전파(Propagation)되는 경로를 악착같이 틀어막아 인간의 개입을 줄이는 생존 철학으로 유지보수 전략을 짜야만 한다.