지난주에 표를 Markdown으로 바꾸는 이야기를 했는데, 오늘은 그 표가 얼마나 잘 뽑혔는지 재는 방법이에요. 이게 생각보다 어려워서 저희도 지표를 몇 번 바꿨어요.
처음엔 TEDS를 썼어요
표 인식 분야에서 제일 많이 쓰는 지표는 TEDS(Tree-Edit-Distance-based Similarity)예요. 표를 HTML 트리로 보고, 정답 트리와 예측 트리 사이의 편집 거리를 재서 0~1 점수로 만들어요. 구조(행·열·병합)와 내용(셀 텍스트)을 한 번에 평가할 수 있어서 논문 벤치마크에서는 거의 표준이에요.
저희도 처음엔 TEDS로 시작했어요. 공개 데이터셋에서 0.9 넘는 점수가 나오니까 꽤 괜찮아 보였죠.
그런데 현장 피드백이랑 안 맞았어요
실제 고객 문서(라고 해도 저희 테스트셋이에요)로 돌려 보니, TEDS가 0.92인 표를 담당자분이 "못 쓰겠다"고 하시는 경우가 있었어요. 반대로 0.85짜리를 "이 정도면 된다"고 하시기도 했고요. 뜯어보니 이유가 있었어요.
- TEDS는 모든 셀을 똑같이 봐요. 제목 셀 하나 틀린 거랑 금액 셀 하나 틀린 게 같은 비용이에요. 업무에선 전혀 안 같죠.
- "한 칸 밀림"에 관대해요. 열이 하나 밀리면 트리 편집으로는 몇 번 안 되는 수정인데, 업무에선 모든 숫자가 다른 항목에 들어간 거예요. 최악의 오류인데 점수는 살짝만 떨어져요.
- 긴 텍스트 셀이 점수를 먹어요. 비고 열에 긴 문장이 있으면 그 셀의 글자 오류가 전체 점수를 좌우해요. 정작 중요한 숫자 칸은 묻히고요.
그래서 셀 단위 지표를 추가했어요
TEDS는 그대로 두고(구조 평가엔 여전히 좋아요), 업무 관점의 지표를 세 개 더 만들었어요.
1. 셀 정합률(Cell Match Rate). 정답 표와 예측 표를 (행, 열) 주소로 정렬한 뒤, 같은 주소의 셀 값이 정확히 같은 비율이에요. 숫자 셀은 공백·쉼표·단위를 정규화한 뒤 비교해요. "1,234원"과 "1234 원"은 같은 걸로 봐요.
2. 숫자 셀 정합률. 1번을 숫자 셀만 따로 계산해요. 저희 고객 업무에서 틀리면 안 되는 건 대부분 숫자라서, 이 지표를 대시보드 맨 위에 둬요.
3. 행 밀림 탐지율. 한 행 전체가 좌우로 밀린 경우를 따로 세요. 셀 정합률로도 잡히긴 하는데, 이건 원인이 다르거든요(보통 병합 셀이나 빈 셀 처리 문제). 별도로 세어야 고칠 수 있어요.
정답: 예측:
| 구분 | 수량 | 금액 | | 구분 | 수량 | 금액 |
| A | 10 | 500 | | A | 10 | 500 |
| B | 20 | 800 | | B | | 20 | ← 행 밀림: 빈 셀 때문에 전부 왼쪽으로
위 예시에서 TEDS는 0.85쯤 나오는데, 숫자 셀 정합률은 50%, 행 밀림은 1건이에요. 담당자가 느끼는 심각도에 훨씬 가까워요.
정답 데이터는 어떻게 만들었냐면요
지표보다 더 어려웠던 게 정답(ground truth) 만들기였어요. 공개 데이터셋은 영어 논문 표가 대부분이라 한국 공공·금융 문서 표랑 모양이 많이 달라요.
저희는 HWP 원본에서 표 구조를 프로그램으로 뽑아서 정답으로 썼어요. 1월 13일 글에서 설명한 네이티브 파서로 HWP의 표 구조를 읽으면 병합·행·열이 정확히 나오잖아요. 그걸 정답으로 두고, 같은 문서를 PDF로 인쇄한 뒤 이미지 기반 파서에 넣어서 비교하는 식이에요. 사람이 라벨링 안 해도 돼서 수천 장을 만들 수 있었어요. 다만 이 방법은 "원본 HWP가 있는 문서"에서만 쓸 수 있고, 스캔 문서에는 적용이 안 돼요. 스캔 문서는 결국 사람이 라벨링했어요.
지금 저희 기준
새 모델이나 후처리 규칙을 올릴 때 보는 순서예요.
- 숫자 셀 정합률이 떨어지면 무조건 반려
- 행 밀림 건수가 늘면 반려
- 셀 정합률, TEDS는 참고
이렇게 바꾸고 나서 "점수는 올랐는데 현장에선 나빠진" 일이 거의 없어졌어요. 지표를 고를 때는 논문에서 쓰는 걸 가져오되, 틀렸을 때 업무에서 얼마나 아픈지를 반영하는 지표를 하나는 꼭 더 두시길 권해요.
다음 주부터는 몇 주 동안 도면 이야기를 할게요. 문서랑은 또 완전히 다른 세계예요.