이번 주 초에 저는 기이한 발견을 발표했습니다. GPT의 저해상도 이미지 모드는 볼 수 없는 문서를 잘못 읽는 것이 아니라, 합계 금액을 맞추면서 유창하게 문서를 _발명(invent)_해 버립니다. 그것은 하나의 모델 제품군에서, 하나의 판독성 수준에서 나타난 하나의 실패 모드였습니다.

이는 불편한 질문을 남겼습니다. 각각의 모델은 정확히 어디에서 읽기를 멈추며, 그 이후에는 무엇을 할까요? 필드를 빈칸으로 남겨둘까요, 아니면 그럴듯한 무언가를 꾸며낼까요?

스크롤을 내리는 동안 기억해야 할 결과 하나는, 문서를 더 이상 읽을 수 없는 모델이라도 대개 그것이 어떤 종류의 문서인지는 여전히 말할 수 있다는 것입니다. 이는 거의 모든 사례에서 일관되게 나타났습니다.

그래서 저는 사다리를 만들었습니다.

그런 다음 27개의 비전 모델 (vision model) 변형들을 그 사다리 아래로 실행했습니다. 4,158개의 작업, 정가 기준 약 141달러, 단 한 번의 오후였습니다. 이 포스트는 그 지도입니다.

설정 (The setup), 한 단락 요약

고정된 2480×3508 캔버스(300 dpi 기준 A4)에 렌더링된 하나의 일본어 인보이스(invoice)를 준비한 뒤, 7단계의 시뮬레이션된 스캔 해상도를 통해 품질을 저하시켰습니다: 300 → 150 → 100 → 70 → 50 → 35 → 25 dpi (L0–L6). 품질 저하는 리샘플링(resampling)으로만 이루어졌으며 — 노이즈, 블러(blur), 회전은 포함되지 않았습니다 — 따라서 판독성(legibility)이 유일한 변수입니다. 인보이스는 네 가지 폰트 계층에 걸쳐 12개의 필드를 포함합니다: 28 pt 제목, 16–14 pt

행(Rows)은 모델 변체(model variants)를, 열(columns)은 사다리 단계(ladder steps)를 나타내며, 색상은 **10.5 pt 본문 계층(body tier)에서의 조작률 (fabrication rate)**을 의미합니다. 이 계층은 인보이스의 거래 상대방과 금액이 위치하는 계층입니다. 흰색은 모델이 올바르게 읽었거나 침묵(데이터를 채우지 않음)했음을 의미합니다. 빨간색은 읽을 수 없는 필드를 조작된 값(invented values)으로 채웠음을 의미합니다.

아래의 보조 표는 각 변체의 **경계선 (frontier)**을 제공합니다. 이는 각 계층별로 필드 정확도가 90% 이상을 유지하는 가장 깊은 사다리 단계를 나타냅니다 (× = 선명한 300 dpi 원본에서 이미 90% 미만인 경우).

지도(map)를 통해 여섯 가지 관찰 결과가 도출되었습니다.

1. "@low"는 제공자마다 의미가 다르다

google/gemini-3.5-flash@low — 보드에서 두 번째로 저렴한 변체 — 는 25 dpi까지 내려가는 모든 단계에서 본문 계층을 조작 없이 정확하게 읽어냈습니다. 정확히 동일한 조건에서, 모든 OpenAI 및 Azure @low 변체들은 깨끗한 원본인 L0 단계에서 무너졌습니다. 접미사는 같지만, 동작은 정반대입니다. 이 차이는 모델의 시력 때문이 아니라, 각 제공자의 저해상도 파이프라인(low-detail pipeline)이 모델이 이미지를 보기 전에 이미지에 어떤 처리를 하는가에 달려 있습니다.

2. GPT @low의 경우, 스캔 품질이 나쁠수록 스캔 품질이 더 좋다

@low 정확도 곡선은 단조롭지 않습니다. 대부분의 GPT @low 변체들은 300 dpi 원본보다 70 dpi 스캔본을 더 잘 읽습니다. 본문 정확도가 L0에서의 약 40%에서 L3–L4에서는 70–80%까지 상승했다가 다시 떨어집니다. 저의 리샘플링 (resampling)은 제공업체의 공격적인 다운스케일링 (downscale)에 대한 안티앨리어싱 (anti-alias) 필터 역할을 합니다. 여기서 도출되는 실질적인 결론은 정말 기이합니다. 만약 @low 파이프라인을 사용할 수밖에 없는 상황이라면, 문서를 미리 블러 (pre-blurring) 처리하는 것이 추출 성능을 향상시킬 수 있습니다.

3. 붕괴 이후, 모델은 조작자(fabricators)와 공백 생성자(blankers)로 나뉜다

모델이 자신의 한계점(frontier)을 넘어선 이후에 무엇을 하는가는 하나의 성격 특성(personality trait)이며, 이는 측정 가능합니다. 25 dpi에서 대부분의 GPT @high 변체들은 더 이상 읽을 수 없는 본문 필드의 75–100%를 지어낸 값(invented values)으로 채웁니다. openai/gpt-5.6-terra@high는 전체 판도에서 벗어난 예외적인 사례입니다. 이 모델의 실패 사례 중 96%는 공백(blanks)입니다. Anthropic과 Google 모델은 애초에 실패율이 더 낮으며, 실패하더라도 조작하는 비율이 낮습니다 (0–26%). 만약 귀하의 파이프라인이 결제 시스템으로 연결된다면, 허세를 부리는 강력한 판독기보다 패배를 인정하는 공백 생성자(blanker)가 더 가치 있습니다.

4. 동일한 모델, 다른 게이트웨이, 다른 눈

gpt-5.6-sol@high는 OpenAI를 통해 호출될 때 100 dpi까지 7.5 pt의 미세 계층을 100% 읽어내지만, 동일한 모델을 Azure를 통해 호출하면 92%에서 시작하여 즉시 성능이 저하됩니다. 실패의 스타일 또한 변합니다. terra의 공백 비율은 96%(OpenAI)에서 39%(Azure)로 떨어집니다. 이는 모델이 문서를 보기 전에 Azure 파이프라인이 더 낮은 유효 해상도 상한선 (effective-resolution ceiling)을 적용한다는 이전의 측정 결과와 일치합니다. 귀하의 게이트웨이 선택은 모델 선택의 조용한 일부입니다.

5. 조작은 성능 저하를 필요로 하지 않는다 (티저)

작은 글씨(fine-print) 필드 중 하나에는 실제 메가뱅크(megabank)의 이름과 단 한 글자 차이인 가상의 은행 이름이 포함되어 있었습니다. 300 dpi 환경에서 — 5회 실행 중 5회 모두 완전히 판독 가능한 상태였음에도 — 일부 모델은 이를 실제 은행 이름으로 "교정"했습니다. Gemini 변체(variants) 전반에 걸쳐 48건의 치환이 발생한 반면, 실제 세계에 유사한 이름이 없는 가상의 신용조합(credit union)은 동일한 조건에서 완벽하게 읽혔습니다. 트리거는 판독 가능성(legibility)이 아니라, 근처에 실제 엔티티(entity)가 존재하는지 여부입니다. 이 사례는 증거 자료와 함께 별도의 글로 다룰 가치가 있습니다. 조만간 따로 공개하겠습니다.

6. 분류(Classification)는 판독 능력 상실 속에서도 살아남는다

27개의 변체 중 25개는 추출(extraction) 능력이 완전히 붕괴된 변체를 포함하여, 모든 성능 저하 단계에서 84개의 문서(송장(invoice) / 영수증(receipt) / 명함(business card) / 회의록(meeting minutes))를 모두 정확하게 분류했습니다. 문서를 읽을 수 없는 모델이라도 그것이 어떤 종류의 문서인지는 여전히 말할 수 있습니다. 두 가지 예외 사례는 시사하는 바가 큽니다. 테스트 대상 중 가장 저렴한 모델은 영수증을 송장으로 혼동했으며(21번 중 21번 모두 — 무작위가 아닌 일관되게), 하나의 @low 변체는 성능 계층의 최하단에서 세 번의 분류에 실패했습니다.

실제 프로덕션에 적용한다면

• 문서가 아닌 티어(tier)별로 라우팅하십시오. 제목(Titles)은 거의 무엇이든 견뎌내지만, 작은 글씨(fine print)는 가장 먼저 소멸합니다. 특정 필드가 중요하다면, 해당 필드가 속한 티어의 한계점(frontier)을 측정하십시오.
• 결제 필드에는 "빈칸을 만드는 모델(blankers)"을 선택하십시오. 조작된 은행 이름은 모든 시각적 개연성 검사를 통과합니다. 그럴듯한 내용을 반환하는 모델보다 ""(빈 문자열)을 반환하는 모델을 선호하십시오.
• @low가 단일한 특성을 가졌다고 가정하지 마십시오. 실제로 호출할 변체를, 실제로 사용할 게이트웨이에서 벤치마크하십시오.

재현하기 (무료 키로도 충분합니다)

결정론적 자료 생성기(deterministic material generator), 실행기(runner), 점수 측정기(scorer), 4,158개 작업의 모든 원시 출력(raw outputs)을 포함한 모든 것이 공개되어 있습니다:

github.com/ldxhub-io/examples → analyzedoc/legibility-benchmark/

해당 자료들은 어떤 플랫폼에서도 바이트 단위로 동일합니다 (생성기가 체크섬 검증이 완료된 고정된 폰트를 다운로드합니다). 3가지 변형의 재현 서브셋(reproduction subset)을 실행하는 데 147개의 작업(jobs)이 소요되며, 이는 약 17,600 크레딧(credits)에 해당합니다. 이는 LDX hub의 무료 티어(월 25,000 크레딧, 카드 등록 불필요) 범위 내에 들어옵니다:

python3 gen_materials.py
export LDXHUB_API_KEY=...   # 무료 키: gw.portal.ldxhub.io
python3 run_benchmark.py --models ume --t1-instances A --t1-reps 3 --t2-reps 1 --yes
...

모델의 원시 출력값(raw model outputs)이 결과와 함께 제공되므로, 저의 채점 규칙에 동의하지 않더라도 단 하나의 작업도 다시 실행할 필요 없이 모든 것을 재채점할 수 있습니다.

솔직히 말씀드리면, 저는 LDX hub를 운영하고 있습니다. LDX hub는 모델을 구축하는 곳이 아니라, 여기서는 실험을 위한 하네스(harness) 역할을 수행하며 연구 대상이 아닙니다. OpenAI, Azure, Google, Anthropic 그리고 AWS를 아우르는 단 하나의 API 키 덕분에 27가지 변형의 매트릭스(matrix)를 단 한 오후 만에 처리할 수 있었으며, 바로 그 편의성이 제가 제공하는 가치입니다. 측정 결과는 어떤 경우에도 공개된 원시 데이터(raw data)를 바탕으로 합니다.

주의 사항 (Caveats)

성능 저하는 실제 스캐너 노이즈가 아닌 합성 재샘플링(synthetic resampling)에 의한 것이므로, 주장은 시뮬레이션된 가독성(legibility)에 국한됩니다. 문서 유형은 한 가지이며, 언어 또한 한 가지(일본어; 라틴 문자보다 더 어려운 테스트임)입니다. 엄격한 채점기(scorer)는 문자 수준의 오독을 허구(fabrications)로 간주하며, 이는 누구에게도 유리하게 작용하지 않습니다. 결과는 2026년 7월의 스냅샷입니다. 새로운 모델이 추가될 때마다 래더(ladder)가 다시 실행되므로, 지도는 최신 상태를 유지할 것입니다.

다음에 제공업체가 새로운 비전 모델(vision model)을 출시하면, 하루 이내에 해당 모델의 행(row)이 추가됩니다. 이것이 리뷰를 쓰는 대신 래더(ladder)를 구축하는 이유입니다.