[논문리뷰] All-in-One Multilingual Scene Text Recognition with Script-aware Mixture-of-Experts (ScriptMoE)
논문리뷰
(출처: arXiv:2609.24058, Figure 3)
All-in-One Multilingual Scene Text Recognition with Script-aware Mixture-of-Experts
Xingsong Ye, Yongkun Du, Jiaxin Zhang, Zhixian Li, Chong Sun, Chen Li, Jing Lyu, Lianwen Jin, Zhineng Chen
Fudan University (Institute of Trustworthy Embodied AI) · Shanghai Key Laboratory of Multimodal Embodied AI · WeChat Vision, Tencent Inc. · South China University of Technology
공개일: 2026년 9월 21일 (v1)
arXiv: https://arxiv.org/abs/2609.24058
코드: https://github.com/YesianRohn/ScriptMoE · https://github.com/Topdu/OpenOCR
분류: cs.CV / Scene Text Recognition · Multilingual OCR · Mixture-of-Experts
🔖 TL;DR (한눈에)
- 언어마다 인식기를 따로 두지도, 거대한 VLM을 쓰지도 않는 단일 다국어 장면 텍스트 인식기를 제안한다.
- 핵심 관찰은 "장면 텍스트 이미지 한 장에는 보통 하나의 문자체계(script)만 들어 있다"는 점이다. 그래서 토큰마다가 아니라 이미지당 한 번만 라우팅한다.
- 디코더의 FFN을 Top-2 script 전문가 + 항상 켜져 있는 공유 전문가로 이루어진 sparse MoE 블록으로 교체했다.
- 10개 문자체계 · 229개 언어를 덮는 합성 데이터 TextMuSS-10M(1,000만 장) 과 평가셋 TextMuSS-Bench(10,899장) 를 함께 공개한다.
- TextMuSS-Bench 평균 정확도 82.06% 로, 가장 강한 STR 베이스라인(SVTRv2-AR, 80.75%)을 1.31%p 앞선다.
- PP-OCRv5의 인식기만 교체했을 때 CC-OCR 다국어 F1이 65.71% → 80.89% 로 뛰며, 최고 성능 VLM(80.73%)을 파라미터 수십 분의 일로 따라잡는다.
한 줄 요약: 문자체계 단위로 전문가를 나눈 4개짜리 MoE 디코더 하나로, 229개 언어를 45.85M 파라미터 모델 한 개가 감당하게 만든 연구.
📄 초록(Abstract) 완역
다국어 장면 텍스트 인식(STR)은 대부분의 언어에서 학습 데이터가 부족하고, 다양한 문자체계를 단일 모델 안에서 처리하기 어렵다는 점 때문에 여전히 까다로운 과제로 남아 있다. 기존 해법은 언어마다 인식기를 하나씩 배치해 비용을 부풀리고 오류 누적을 불러오거나, 비싸면서도 여전히 많은 문자체계에서 부정확한 거대 비전-언어 모델(VLM)에 의존한다. 본 연구에서 우리는 언어별 전문가보다 단순하고, VLM보다 가벼우며, 둘 모두보다 정확한 올인원 다국어 인식기를 추구한다. 첫째, 우리는 10개 문자체계와 229개 언어에 걸친 대규모 합성 장면 텍스트 데이터셋 TextMuSS-10M을 구축한다. 이 데이터셋은 실제 데이터를 구할 수 없는 곳에 균형 잡히고 충분한 지도 신호를 제공한다. 둘째, 우리는 문자체계 인지형 Mixture-of-Experts(MoE) 구조인 ScriptMoE를 제안한다. 이 구조는 단일 시각 인코더를 공유하면서 밀집(dense) 디코더를 sparse MoE 블록으로 대체하는데, 이 블록은 각 이미지를 상위 2개의 문자체계 정렬 전문가로 보내는 이미지 수준 라우터와, 문자체계를 가로지르는 지식을 흡수하는 공유 전문가로 구성된다. 우리가 구성한 TextMuSS-Bench(10개 문자체계, 10,899장)에서의 광범위한 실험은 ScriptMoE가 82.06%라는 최고 정확도를 달성하여 가장 강력한 STR 베이스라인을 1.31% 앞선다는 것을 보여준다. CC-OCR 종단간 다국어 과제에서는 PP-OCRv5의 인식기만을 ScriptMoE로 교체하는 것만으로 F1 점수가 65.71%에서 80.89%로 상승하여, 파라미터 수의 일부만으로 최고 성능 VLM(80.73%)을 근소하게 앞선다.
초록을 요약하면 이렇다. 다국어 OCR의 병목은 모델 구조보다 데이터 불균형과 용량 배분 쪽에 있다. 저자들은 전자를 1,000만 장 규모 합성 데이터로, 후자를 문자체계별로 쪼갠 MoE 디코더로 각각 푼다. 결과적으로 45.85M짜리 모델 하나가 229개 언어를 담당하면서도, 수십억 파라미터 VLM과 대등하거나 그 이상의 인식 정확도를 낸다.
🧩 왜 이 문제가 중요한가
(출처: arXiv:2609.24058, Figure 1)
장면 텍스트 인식 연구는 사실상 영어와 중국어에서 포화됐다. 그런데 실제 서비스가 마주하는 간판·표지판·영수증에는 일본어, 한국어, 아랍어, 힌디어, 키릴 문자가 뒤섞여 들어온다. 현재 업계가 쓰는 방법은 크게 둘이다.
첫째, 전문가 OCR 시스템. PP-OCRv5처럼 검출기 하나에 언어별 인식기를 여러 개 달아두고, 앞단에 언어 분류기를 세우는 방식이다. 문제는 오류 누적이다. 언어 분류기가 한 번 틀리면 뒤에 어떤 인식기가 붙어 있어도 복구할 방법이 없다. 언어가 늘어날수록 유지해야 할 모델 수와 비용도 함께 늘어난다.
둘째, VLM 기반 시스템. 하나의 모델로 모든 언어를 다루니 구조는 깔끔하지만, 파라미터와 추론 비용이 크고 — 논문 표를 보면 — 정작 저자원 문자체계에서는 정확도가 처참하다. 예컨대 GOT-OCR 2.0은 아랍어·벵골어·티베트어에서 단어 정확도 0.00%를 기록한다.
여기서 저자들이 잡은 지점이 문자체계(script) 단위의 통합이다. 수백 개 언어는 결국 10개 문자체계로 수렴한다. 라틴, 키릴, 한자, 일본어, 한국어, 아랍, 힌디 계열, 태국어, 벵골어, 티베트어. 이 10개가 229개 언어를 덮는다. 언어별로 모델을 두는 대신 문자체계별로 용량을 나누면, 모델 수를 언어 수가 아니라 상수에 묶어둘 수 있다.
다만 단일 밀집 디코더로 10개 문자체계를 한꺼번에 처리하려 하면 용량 배분이 어그러진다. 문자체계마다 획 구조(힌디·티베트어의 쌓아 올리는 자음, 아랍어의 필기체 연결), 읽기 방향(아랍어는 우→좌), 문자 집합 크기(한자 16,147자 vs 티베트어 64자)가 전부 다르기 때문이다. 태국어·티베트어 같은 저자원 문자체계는 용량을 충분히 못 받고, 라틴어 같은 고자원 문자체계는 끝까지 특화되지 못한다.
🔬 방법론
이미지 한 장에는 문자체계 하나 — 라우팅 단위를 바꾸다
ScriptMoE 설계의 출발점은 단순한 관찰이다. LLM의 MoE는 토큰마다 라우팅한다. 문장 안에서 주제와 문체가 계속 바뀌니 그럴 수밖에 없다. 그런데 장면 텍스트 이미지는 다르다. 간판 한 장에 아랍어와 한글이 섞여 있는 경우는 드물다. 이미지 한 장은 거의 항상 하나의 문자체계다.
그래서 저자들은 라우팅을 이미지 단위로 내린다. 시각 인코더가 뽑은 토큰 F ∈ R^(L×d)를 평균 풀링해 이미지 대표 벡터 F̄ ∈ R^d를 만들고, 이 벡터 하나로 전문가를 고른다. 그 이미지에서 나오는 T개 출력 토큰은 전부 같은 전문가를 쓴다. 이렇게 하면 세 가지가 따라온다. 라우팅 연산이 줄고, 토큰마다 전문가가 왔다 갔다 하며 학습이 불안정해지는 현상이 사라지고, 무엇보다 각 전문가를 "이 전문가는 아랍 문자 담당"이라고 그대로 읽을 수 있게 된다.
MoE-FFN의 구성
인코더는 SVTRv2를 모든 문자체계가 공유한다. 디코더는 표준 Transformer 블록이되 FFN 자리에 MoE 블록이 들어간다. n개의 라우팅 전문가와 1개의 공유 전문가가 있을 때, 디코더 은닉 상태 h_t에 대해:
MoE(h_t) = α_t · FFN_share(h_t) + (1 − α_t) · Σ_i g_i · FFN_i(h_t) ... (1)
g_i = [p_i · 1{i ∈ TopK(p)}] / [Σ_j p_j · 1{j ∈ TopK(p)}] ... (2)
p = softmax(W_g (F̄ ⊙ (1 + σ·ε))) ... (3)식 (3)에서 ε ~ N(0, I)는 학습 중에만 걸리는 곱셈형 라우터 지터로, 라우터가 초기에 특정 전문가에 눌러앉는 것을 막는다(기본 σ = 0.05). 식 (2)는 Top-K(여기서는 Top-2)만 남기고 게이트를 다시 정규화한다.
눈여겨볼 부분은 α_t다. 공유 전문가와 라우팅 전문가의 비율을 고정값으로 두지 않고, 토큰마다 학습되는 게이트 α_t = sigmoid(w_s^T h_t)로 조절한다. 숫자나 구두점처럼 어떤 문자체계에도 공통인 부분은 공유 전문가 쪽으로, 문자체계 고유의 획 구조는 라우팅 전문가 쪽으로 자연스럽게 흘러가도록 모델이 스스로 비율을 정한다.
10개 문자체계 → 4개 전문가 그룹
전문가를 문자체계 수만큼 10개 두지 않았다는 점이 중요하다. 저자들은 자형(字形) 유사성을 기준으로 4개 그룹으로 묶었다.
| 그룹 | 포함 문자체계 |
|---|---|
| Alphabet | 라틴, 키릴 |
| CJK | 중국어, 일본어, 한국어 |
| Arabic | 아랍 문자 계열 |
| Others | 힌디, 벵골, 티베트, 태국 |
미지원 언어가 들어와도 확장 규칙이 있다. 알파벳 형태면 1번, 한자 형태면 2번, 우→좌로 읽으면 3번, 그 외는 4번 그룹으로 보낸다.
공유 전문가와 문자체계 지도 신호
공유 전문가는 라우팅 결과와 무관하게 항상 켜져 있다. 모든 이미지의 그래디언트가 통과하는 유일한 경로다. 문자체계에 상관없이 반복되는 요소 — 숫자, 구두점, 곡선·원근 왜곡된 텍스트의 기하학적 특성, 중국어와 일본어처럼 가까운 계열이 공유하는 어휘 — 를 여기서 흡수한다. 뒤에서 보겠지만 이 모듈을 빼면 저자원 문자체계가 가장 크게 무너진다.
문자체계 분류 손실은 라우터와 같은 입력 F̄를 받는 4-way 분류 헤드로 구현된다. 정답 레이블은 사람이 달지 않는다. 전사(transcription) 문자열의 유니코드 범위를 보고 4개 그룹 중 하나로 자동 매핑한다.
L = L_ar + λ_scls · L_scls, λ_scls = 0.1 ... (5)여기서 결정적인 설계는 분류 헤드가 라우터의 입력은 공유하되 가중치는 공유하지 않는다는 점이다. 라우터를 직접 감독해버리면 라우터는 문자체계 분류기의 복제본이 되어버린다. 입력만 공유하게 두면, 문자체계를 구분하라는 압력은 받으면서도 라우터는 문자체계 안에서 다시 하위 집단을 스스로 나눌 자유를 갖는다.
TextMuSS-10M: 데이터부터 만들다
용량 문제만큼이나 근본적인 것이 데이터 문제다. 티베트어 장면 텍스트 학습 데이터는 세상에 사실상 없다. 저자들은 UnionST 합성 엔진을 개조해 문자체계당 100만 장, 총 1,000만 장을 만들었다.
문자열을 만드는 비율이 흥미롭다. 실제 단어 사전에서 40%, 문자를 무작위로 뒤섞은 비언어적 시퀀스 20%, 희귀 문자를 일부러 과대표집한 어휘 확장 문자열 20%, News Crawl 신문 코퍼스 문장 20%. 실제 단어만 쓰면 문자 분포가 치우치고 희귀 문자를 영영 못 배우기 때문에, 의미 없는 문자열을 일부러 섞은 것이다.
렌더링 효과는 곡선 배치 20%, 다방향(수직 포함) 배치 20%, 원근 왜곡 20%가 독립적으로 중첩된다. CJK는 수직 텍스트 비중을 20%로 높였고(나머지 문자체계는 5%), 아랍 계열은 우→좌로 렌더링하되 논리 순서로 저장한다. 배경은 SynthText가 공개한 8,000장을 쓴다. 10개 문자표를 합쳐 중복을 제거하면 19,684자, 특수 토큰 3개를 더해 디코더 어휘는 19,687개가 된다.
평가셋 TextMuSS-Bench는 MLT2019 테스트 분할(7개 문자체계)에 러시아어·태국어·티베트어를 직접 수집·주석해 붙였다. 검출 박스는 PP-OCRv5로 뽑은 뒤 전량 수작업 검수했고, 전사는 해당 문자체계 전문가가 맡았다. 다만 저자원 언어 전문가가 귀해 문자체계당 전문가 1명이 작업했고, 별도 검수자가 형태 수준에서 교차 확인했다. 총 10,899장이다.
📊 실험 결과
TextMuSS-Bench: 단어 정확도
15개 STR 모델과 9개 범용 OCR 시스템을 동일한 데이터·스케줄·하드웨어에서 재학습해 비교했다. 주요 결과만 추리면 다음과 같다(단어 정확도 %).
| 방법 | 아랍 | 벵골 | 중국 | 힌디 | 일본 | 한국 | 라틴 | 러시아 | 태국 | 티베트 | 평균 |
|---|---|---|---|---|---|---|---|---|---|---|---|
| InternVL3.5-8B | 0.00 | 0.00 | 72.31 | 0.25 | 32.32 | 38.88 | 74.34 | 30.93 | 0.40 | 0.00 | 24.94 |
| GOT-OCR 2.0 | 0.00 | 0.00 | 76.92 | 0.25 | 21.72 | 0.59 | 84.71 | 0.47 | 0.00 | 0.00 | 18.47 |
| GLM-OCR | 1.49 | 3.31 | 90.46 | 9.14 | 56.40 | 40.06 | 89.62 | 50.95 | 0.13 | 0.00 | 34.16 |
| HunyuanOCR | 36.17 | 62.34 | 92.31 | 52.67 | 57.07 | 64.06 | 86.85 | 50.19 | 35.33 | 29.78 | 56.68 |
| Qwen3.5-9B | 62.13 | 63.36 | 92.31 | 62.85 | 63.97 | 80.27 | 88.04 | 69.17 | 38.76 | 16.85 | 63.77 |
| PP-OCRv5 MLT | 68.30 | / | 80.00 | 60.05 | 57.41 | 75.85 | 83.43 | 47.82 | 35.87 | / | 63.59 |
| SVTRv2 | 70.85 | 83.46 | 93.23 | 84.73 | 66.67 | 85.86 | 91.52 | 47.91 | 66.27 | 85.39 | 77.59 |
| MAERec | 76.17 | 80.15 | 92.92 | 86.01 | 68.35 | 86.16 | 92.13 | 52.66 | 63.73 | 86.80 | 78.51 |
| SVTRv2-AR | 75.11 | 87.79 | 94.15 | 87.28 | 69.36 | 85.86 | 92.27 | 59.30 | 69.60 | 86.80 | 80.75 |
| ScriptMoE (ours) | 78.09 | 88.30 | 95.38 | 86.77 | 71.21 | 87.19 | 91.67 | 61.20 | 72.00 | 88.76 | 82.06 |
평균 82.06%로 1위, 가장 강한 베이스라인 SVTRv2-AR 대비 +1.31%p다. 숫자 자체보다 어디서 벌었는지가 중요하다. 이득은 아랍어 +2.98%p, 태국어 +2.40%p, 티베트어 +1.96%p — 정확히 저자원 문자체계에 몰려 있다. 문자체계별로 용량을 떼어주자는 설계 의도와 결과가 맞아떨어진다.
정직하게 짚을 부분도 있다. ScriptMoE가 모든 칸에서 1등은 아니다. 힌디어(86.77 vs 87.28)와 라틴어(91.67 vs 92.27)는 SVTRv2-AR이 앞서고, 러시아어는 Qwen3.5-9B(69.17)가 훨씬 높다. 논문도 이를 감추지 않고 "전체 정확도를 최적화하면 문자체계별 최고점은 불가피하게 희생된다"고 적는다.
범용 VLM들과의 격차는 다른 차원이다. InternVL3.5-8B와 GOT-OCR 2.0은 아랍어·벵골어·티베트어에서 0.00%, 즉 아예 읽지 못한다. 평균으로 보면 일반 시스템들은 18~70%p 뒤처진다. 반면 ScriptMoE는 이미지당 45.85M 중 41.13M 파라미터만 활성화한다. VLM 대비 1~2 자릿수 적은 규모다.
CC-OCR 종단간 다국어 (F1 %)
더 설득력 있는 실험은 이쪽이다. PP-OCRv5 파이프라인에서 검출기는 그대로 두고 인식기만 ScriptMoE로 갈아끼웠다. 성능 변화는 온전히 인식 쪽 기여로 귀속된다.
| 방법 | 한국어 | 일본어 | 베트남어 | 프랑스어 | 독일어 | 러시아어 | 아랍어 | Total |
|---|---|---|---|---|---|---|---|---|
| GPT-4o | 74.20 | 66.96 | 70.11 | 81.17 | 73.60 | 67.22 | 72.31 | 73.44 |
| Gemini-1.5-Pro | 80.01 | 73.52 | 78.49 | 83.33 | 78.11 | 69.99 | 85.70 | 78.97 |
| Qwen2.5-VL-72B | 85.36 | 76.27 | 78.16 | 83.56 | 79.27 | 71.09 | 79.44 | 79.68 |
| Gemini-3.5-Flash | 89.15 | 85.89 | 73.17 | 84.84 | 81.43 | 67.21 | 88.05 | 80.52 |
| Qwen3.5-9B | 79.03 | 75.17 | 81.43 | 82.83 | 76.82 | 78.97 | 82.01 | 80.73 |
| Qianfan-OCR | - | - | - | - | - | - | - | 76.70 |
| GoogleOCR | 85.32 | 77.46 | 63.15 | 73.40 | 64.80 | 57.69 | 90.62 | 71.78 |
| PP-OCRv5 MLT | 78.58 | 76.13 | 33.67 | 64.86 | 62.30 | 49.67 | 81.93 | 65.71 |
| PP-OCRv5 Det + ScriptMoE | 92.33 | 89.43 | 75.93 | 80.77 | 81.00 | 79.22 | 87.45 | 80.89 |
65.71% → 80.89%, 절대 15.18%p 상승이다. 제로샷 범용 VLM 최고인 Qwen3.5-9B(80.73%), OCR 특화 VLM 최고인 Qianfan-OCR(76.70%), 상용 GoogleOCR(71.78%)을 모두 넘어선다. 한국어 92.33%, 일본어 89.43%는 표 전체에서 최고치다.
다만 베트남어(75.93)와 스페인어(72.58) 등 라틴 계열 일부는 Qwen3.5-9B에 밀린다. 저자들은 그 원인을 상류 검출기로 돌린다. CC-OCR은 라틴 계열을 단어 단위로 엄격하게 채점하기 때문에, PP-OCRv5 검출기의 누락·오검출이 그대로 점수 상한이 된다.
데이터 구성의 효과
| 학습 데이터 | MLT2019 7개 평균 | 러시아 | 태국 | 티베트 |
|---|---|---|---|---|
| SynthMLT | 47.94 | 0.00 | 0.00 | 0.00 |
| Real only | 77.12 | 0.00 | 0.00 | 0.00 |
| Synth only | 79.61 | 68.13 | 70.30 | 87.08 |
| Synth + Real | 85.52 | 61.20 | 72.00 | 88.76 |
합성 데이터만 써도 실제 데이터만 쓴 경우보다 MLT2019 평균이 2.49%p 높다. 둘을 합치면 실제 데이터 단독 대비 +8.40%p. 데이터가 없는 언어에서는 합성이 "차선책"이 아니라 그냥 정답에 가깝다는 뜻이다.
흥미로운 역효과도 보인다. 합성을 더하면 라틴어가 내려가고, 실제 데이터를 더하면 러시아어가 68.13 → 61.20으로 떨어진다. 저자들은 라틴-키릴 동형문자(homoglyph) 충돌을 원인으로 지목한다. 키릴 'а', 'о', 'р'은 라틴 'a', 'o', 'p'와 픽셀 수준에서 구분되지 않는다.
절제 실험: 무엇이 실제로 기여했나
(출처: arXiv:2609.24058, Figure 5)
| 설정 | 평균 |
|---|---|
| MoE 없음 (순수 AR) | 80.75 |
| 전문가 2개 | 81.52 |
| 전문가 4개 (기본) | 82.06 |
| 전문가 10개 (문자체계당 1개) | 81.32 |
| Top-1 라우팅 | 81.60 |
| Top-4 라우팅 | 81.94 |
| 토큰 단위 라우팅 | 81.69 |
| L_scls 제거 | 81.63 |
| 공유 전문가 제거 | 81.35 |
읽을 만한 대목이 몇 가지 있다.
전문가를 문자체계 수만큼 늘리면 오히려 손해다. 10개(문자체계당 1개)로 늘리면 81.32%로 떨어진다. 각 전문가가 보는 샘플이 너무 적어 특화가 안 되고, 일부 문자체계는 구조적으로 가까운 이웃과 전문가를 공유하는 편이 낫기 때문이다. 4개 그룹이라는 선택이 임의적이지 않다는 근거다.
Top-2가 적정선이다. Top-1은 MoE 없는 쪽보다는 낫지만 관련 문자체계 간 공유 패턴을 못 잡아 태국어·중국어에서 가장 크게 떨어진다. Top-4는 평균이 Top-2와 거의 같은데 활성 파라미터만 늘고, 일본어·한국어는 오히려 나빠진다.
라우팅 단위는 사실상 무승부다. 토큰 단위가 힌디어에서는 조금 벌고 러시아어에서는 비슷하게 잃는다. 노이즈 범위 안이다. 저자들은 라우터 비용이 싼 이미지 단위를 택했다.
공유 전문가가 제일 중요하다. 제거 시 평균 0.71%p 하락인데, 이 손실이 저자원 쪽에 집중된다. 아랍어 −3.62%p, 티베트어 −3.65%p. 데이터가 적은 문자체계일수록 다른 문자체계에서 흘러들어오는 공유 지식에 의존한다는 뜻이다. 문자체계 분류 손실 제거는 −0.43%p로 상대적으로 완만하다.
비용과 단일 언어 성능
| 방법 | 파라미터(M) | 지연(ms) | 처리량(img/s) | 메모리(MB) |
|---|---|---|---|---|
| CRNN | 26.25 | 57.40 | 4459.9 | 1368.4 |
| SVTRv2 | 27.30 | 210.32 | 1217.2 | 1560.8 |
| SVTRv2-AR | 37.50 | 395.92 | 646.6 | 2057.3 |
| MAERec | 50.73 | 1297.63 | 197.3 | 2411.3 |
| ScriptMoE | 45.85 | 541.07 | 473.1 | 2091.0 |
V100 한 장, 배치 256 기준이다. SVTRv2-AR보다 파라미터가 8.35M, 지연이 145ms 늘었다. 공짜는 아니지만 MAERec보다는 훨씬 빠르다. 학습 비용은 V100 8장으로 2 에폭, 약 92.7 GPU-시간(실시간 11.8시간)이다.
다국어에 특화하느라 단일 언어를 희생했는지도 확인했다. 중국어 BCTR 평균 86.85%(SVTRv2-AR 대비 +0.92%p), 영어 Union14M-Benchmark 평균 88.95%(+0.28%p)로 오히려 둘 다 올랐다.
🚧 한계
논문이 부록에서 스스로 밝힌 한계는 세 가지다.
합성-실제 도메인 격차. 아무리 정교하게 만들어도 TextMuSS-10M과 실제 촬영 이미지 사이에는 간극이 남는다. 저자들은 대규모 실제 다국어 장면 이미지를 모아 준지도 학습으로 메우는 방향을 제시한다.
라틴-키릴 동형문자 혼동이 완전히 해결되지 않았다. 키릴 문자가 시각적으로 동일한 라틴 문자로 잘못 인식되면, 철자로는 그럴듯하지만 문자체계가 잘못된 전사가 나온다. 균형 잡힌 데이터 분포가 완화는 해주지만 없애지는 못한다. 러시아어가 61.20%로 다른 문자체계보다 낮은 이유도 여기에 있다.
여전히 상류 검출기에 종속된다. 종단간 파이프라인은 PP-OCRv5 검출기를 그대로 쓰는데, 이 검출기의 다국어 검출 품질이 모든 문자체계에서 보장되지 않아 전체 성능의 상한으로 작용한다.
여기에 리뷰어 입장에서 덧붙일 점이 하나 더 있다. TextMuSS-Bench의 러시아어·태국어·티베트어 전사는 문자체계당 전문가 1명이 작업했다. 논문도 이를 명시하고 별도 검수자를 뒀다고 밝히지만, 교차 주석자 일치도를 잴 수 없는 구조인 만큼 이 세 문자체계의 절대 수치는 다소 여유를 두고 읽는 편이 안전하다. 향후 연구로는 전체 재학습 없이 새 문자체계를 추가하는 지속 학습, 그리고 더 강한 검출기와의 결합을 꼽는다.
🎯 마무리
ScriptMoE가 보여준 것은 "MoE를 OCR에 붙였다"가 아니다. 문제의 구조에 맞춰 MoE의 라우팅 단위를 바꾸면 무엇이 달라지는가에 가깝다.
LLM에서 토큰 단위 라우팅이 표준이 된 건 문장 안에서 필요한 전문성이 계속 변하기 때문이다. 장면 텍스트는 그렇지 않다. 이미지 한 장은 거의 항상 하나의 문자체계다. 이 도메인 사전지식을 라우팅 단위에 그대로 반영하자, 연산이 줄어드는 동시에 각 전문가가 해석 가능한 역할을 갖게 됐다. 절제 실험에서 토큰 단위가 이미지 단위를 이기지 못한 것은 우연이 아니다.
두 번째로 눈여겨볼 것은 전문가 수를 문자체계 수에 맞추지 않은 판단이다. 10개로 늘리면 오히려 성능이 떨어진다. 전문가는 "구분 가능한 범주"가 아니라 "충분한 데이터가 모이는 단위"로 잘라야 한다는 교훈이고, 이는 OCR 바깥의 MoE 설계에도 그대로 옮겨갈 만한 이야기다.
실용적 함의는 CC-OCR 결과에 압축되어 있다. 기존 파이프라인에서 인식기 모듈 하나만 교체해 F1을 15%p 올렸다. 검출기, 후처리, 서빙 인프라를 그대로 둔 채 얻은 결과다. 다국어 문서·간판 처리 파이프라인을 운영하면서 언어별 모델 관리에 지쳐 있거나, VLM 전환의 비용이 부담스러운 팀이라면 검토해볼 만한 선택지다. 45.85M 모델 하나로 229개 언어를 덮는다는 조건은, 지금 시점의 다국어 OCR 논의에서 흔치 않다.
📚 출처 / 인용
- 논문: Ye, X., Du, Y., Zhang, J., Li, Z., Sun, C., Li, C., Lyu, J., Jin, L., Chen, Z. All-in-One Multilingual Scene Text Recognition with Script-aware Mixture-of-Experts. arXiv:2609.24058 (2026). https://arxiv.org/abs/2609.24058
- 코드: https://github.com/YesianRohn/ScriptMoE
- OpenOCR: https://github.com/Topdu/OpenOCR
본문에 사용한 이미지는 모두 원논문에서 인용한 것이며, 저작권은 원저자에게 있습니다.
본 글은 개인 학습 목적의 리뷰이며, 해석이나 요약 과정에서 원문의 의도와 다른 부분이 있을 수 있습니다. 정확한 내용은 반드시 원논문을 확인해 주세요.
