Mistral OCR vs space-ocr 2라운드 — 아무도 벤치마크하지 않는 사진들

이달 초에 Mistral Document AI와의 통제 벤치마크를 공개했습니다. 모든 엔진에 같은 사진, 같은 항목 정의, 같은 채점 스크립트를 주고 8케이스·463필드를 3번씩 돌리는 내용이었습니다.

그 글에는 약점이 하나 있었습니다. 골라 놓은 게 읽기 어려운 '문서'였다는 점입니다. 실제 현장에서 오는 건 어려운 '사진'입니다. 납품서는 창고 바닥에서 옆으로 누운 채 찍히고, 영수증은 주머니 속에서 구겨집니다. 복사 전표는 묶음째 찍히고 그 위에 도장이 눌려 있습니다. 밤 백야드에서, 한 손으로, CCTV 모니터 불빛에 의지해 찍히기도 합니다.

그래서 딱 그런 사진 7케이스를 추가해 전부 다시 쟀습니다. 합계 15케이스·14문서·769필드, 엔진마다 3번씩. 조건은 전과 같습니다 — 전 엔진 동일 사진, 동일 항목 정의, 동일 채점. 하나 바꾼 건 space-ocr를 부르는 경로인데, 이번에는 내부 경로가 아니라 공개 API — 어느 계정이나 쓰는 그 POST /ocr/fields — 로 쟀습니다. 즉 지금 가입하면 누구든 같은 경로로 재현할 수 있는 숫자입니다.

표 읽는 법을 두 가지 덧붙입니다.

첫째, 절대값은 보수적으로 봐 주세요. 정답 데이터는 표기를 하나로 고정해 두었습니다. 종이에 「¥711」이라고 찍혀 있으면 정답도 「¥711」이고, 엔진이 「711」로 돌려주면 오답으로 셉니다. 이런 표기 어긋남은 어느 엔진에나 생기기 때문에 89.2%든 69.3%든 절대값은 전부 실력의 하한이고, 의미가 있는 건 격차 쪽입니다.

둘째, 두 번째 행의 '흔들린 폭'입니다. 같은 사진 묶음을 아무것도 바꾸지 않고 3번 읽혔을 때 총점이 몇 필드나 움직였는가 하는 숫자입니다. space-ocr는 3번 동안 6필드 움직였습니다. Mistral OCR은 106필드 움직였습니다 — 어떤 판에서는 읽히고 어떤 판에서는 안 읽히는 값이 106개 분량 있었다는 뜻입니다. 매일 밤 배치로 서류를 흘리는 사용을 생각하면 이 차이는 정확도만큼 중요합니다. 어제와 오늘 출력의 diff가 '리뷰할 수 있는 차이'가 되느냐 '그냥 소음'이 되느냐가 여기서 갈리기 때문입니다.

격차는 어디서 벌어지나

아래 표가 이 글의 본체입니다. 조건이 가장 좋은 문서 — 깨끗하게 인쇄된 조밀한 표 — 에서는 사실 세 엔진이 거의 만점으로 나란히 섭니다. '글자를 알아보는 힘' 자체에는 큰 차이가 없다는 얘기입니다. 격차는 문서 구조가 복잡해질 때, 그리고 촬영 조건이 나빠질 때 벌어집니다:

이 표에서 가장 놀란 행은 옆으로 누운 두 문서입니다. 비전 LLM — 사진을 통째로 대규모 언어모델에 넣고 "이 항목들을 뽑아 줘"라고 부탁하는 방식 — 이 회전된 문서에서 무너집니다. 점수는 0.217과 0.130. 같은 사진을 OCR을 앞단에 둔 두 엔진은 0.611~0.872로 읽었습니다.

이유는 구조를 생각하면 수긍이 갑니다. OCR 엔진은 글자를 읽기 전에 페이지 방향을 감지해서 똑바로 세우는 공정을 갖고 있습니다. 비전 LLM에는 그 공정이 없어서 옆으로 누운 픽셀이 그대로 들어갑니다. 사람이라면 고개를 기울이면 그만이지만, 모델은 페이지 대부분을 흘렸습니다. 문서 두 장으로 일반 법칙을 선언할 생각은 없으니 정확하게 말해 두겠습니다: 이 코퍼스의 이 두 장에서는, 3번 돌려 3번 다 그랬습니다.

영수증 한 장에 ¥711이 넷

마지막 신규 케이스는 결이 조금 다릅니다. 정확도가 아니라 "좌표가 왜 필요한가"를 실물로 보여 주는 케이스입니다.

세븐일레븐 영수증인데, 711이라는 숫자 배열이 여덟 군데에 나옵니다. 합계가 ¥711. iD 결제도 ¥711. 신용 전표 구역의 금액도 ¥711. 세액 내역 줄에도 ¥711. 게다가 가게 전화번호 끝자리가 0711, 계산한 시각이 07:11, 날짜가 7월 11일(두 군데), 전표번호는 240-711-292-8686. 우연이 전부 이 한 장에 모였습니다.

이 영수증에 '합계', 'iD 결제액', '청구 금액' 세 항목을 요청하면, 올바르게 읽은 엔진은 같은 「¥711」을 세 번 돌려줍니다. 값만 봐서는 어느 것이 어느 줄에서 왔는지 절대 알 수 없습니다. 구별할 수 있는 정보는 좌표뿐입니다. space-ocr의 3번 실행에서 세 항목은 매번 각자 올바른 줄 위의 박스를 달고 돌아왔고, 박스 좌표는 3번 모두 동일했습니다. 값만 돌려주는 API에는 애초에 "어느 줄을 읽었는지" 밝힐 자리가 없습니다. 맞았든 틀렸든, 돌아오는 JSON의 겉모습이 같습니다.

코퍼스 갤러리

이번 측정에 쓴 새 사진 전부입니다. 목록에서 골라 보세요 — 초록 박스는 전부 엔진이 실제로 돌려준 좌표이고, 거래처 정보는 저희가 모자이크했습니다.

그래도 빠져나가는 오류

마지막으로, 잘 안 된 이야기도 적어 둡니다.

space-ocr의 검증 레이어는 모델이 돌려준 값과, OCR이 페이지에서 실제로 본 글자를 독립된 두 개의 눈으로 맞대 보는 장치입니다. 두 눈이 일치하지 않으면 플래그가 붙습니다. 그런데 이번 같은 악조건 사진에서는 남은 오류의 대부분이 두 눈이 같은 오독으로 일치해 버리는 경우였습니다. 글레어에 하얗게 날아간 글자, 블러에 뭉개진 글자는 어느 쪽 눈에도 똑같이 잘못 보입니다. 맞대 보기라는 장치의 성질상 '합의된 오류'는 잡을 수 없습니다.

이건 예전부터 적용 범위 밖이라고 문서에 명시해 온 한계인데, 이번에 실측으로 확인됐습니다. 그래서 리뷰 플래그는 "사람이 어디를 봐야 하는지"를 좁혀 주는 신호이지, 사람 확인을 대신해 주는 보증이 아닙니다. 금액 자릿수 체크나 합계 검산 같은 업무 규칙의 층을 이 위에 겹쳐 쓰시길 권합니다.

1라운드 글에 방법 전문과 공개 세트의 원시 출력, 채점 로직이 있습니다. 검증 레이어 자체를 어떻게 쟀는지는 별도 글로 정리해 두었습니다. 갖고 계신 최악의 사진이 어떻게 읽히는지 궁금하시면, 랜딩 페이지의 데모가 계정 없이 한 장 읽어 드립니다.