숫자가 화려할수록, 그것을 폐기하기 전에 원본 출력물을 더 면밀히 살펴보게 된다

자동 측정 결과는 좋은 소식을 전해왔다: 쓰레기 같은 영어(junk English) 97% 감소. 하지만 나는 그 수치를 받아들이지 않았다. 나는 그것을 버렸다.

원본 출력물을 한 페이지씩 검토한 결과, 97%라는 수치는 두 가지 측정 버그가 겹쳐진 결과임이 드러났다. (1) 압축 (compression) 단계에서의 무작위성(Randomness)이 가끔 깨진 인스턴스를 생성하며, (2) 어그리게이터(aggregator)의 파싱 실패(parse-failure) 폴백(fallback)이 전체 원문 텍스트를 카운트하고 있었다. 공정하게 측정했을 때, 세 가지 모두 거의 비슷하게 나타났다 (5 / 7 / 9 단어).

하지만 그 수치와 함께 기술 자체를 묻어버리지는 마라. "지표(metric)는 거부되었지만, 기술이 작동하는지 여부는 여전히 미결 상태이다." 자신이 아는 것과 지식이 멈추는 지점 사이에 선을 긋는 것이, 다음에 그것을 제대로 측정할 수 있는 여지를 남겨준다.

이전 파트들까지, 나는 빠르고 저렴하게 만들기 위해 나만의 작은 모델을 압축(양자화 (quantized))했다. 품질은 거의 떨어지지 않지만, 10%가 채 되지 않는 "경계선(borderline)" 사례에서는 가끔 무너진다. 그 붕괴의 한 형태는 번역에 원문 영어가 유출되는 것(일본어 출력물 안에 영단어가 그대로 남아 있는 현상)이다.

이 "남겨진 영어"를 제거하기 위해, 나는 복구 기술을 시도했다. 자동 측정 결과는 극적인 희소식을 가져왔다. 쓰레기 같은 영어 97% 감소.

나는 그 수치를 있는 그대로 받아들이지 않았다. 이 글은 왜 내가 그 놀라운 97%를 버렸는지에 관한 이야기다.

좋은 소식: 97%

나는 하드 압축(hard-compressed)된 모델에 복구 기술(모델의 내부 가중치를 재배열하여 압축으로 인해 손실된 정확도를 회복하는 후처리 단계; 이후부터는 이를 회전(rotation)이라 부르겠다)을 적용하여 30페이지 분량의 만화를 번역하게 했다. 집계된 결과는 다음과 같았다.

그리고 압축되지 않은 전체 정밀도 (Full-precision, FP16) 버전과 나란히 놓으니, 이야기는 완벽해 보였다.

• 전체 정밀도 버전의 불필요한 단어: 3개 (사실상 깨끗함)
• 강하게 압축된 버전: 968개 (압축으로 인해 불필요한 단어가 +965개 증가)
• 수정된 버전: 33개 (935개 단어 복구, 전체 정밀도 수준으로 거의 회복)

"압축은 불필요한 단어를 재앙적인 수준으로 증폭시키지만, 수정(repair)은 이를 다시 전체 정밀도 수준으로 되돌려 놓는다" — 교과서처럼 깔끔한 스토리라인이다. 이 결과 그대로 받아들인다면, 수정 기술은 출시할 가치가 있다고 결론 내릴 수 있다.

수치가 너무 좋았다

나를 멈춰 세운 것은 −97%라는 수치가 너무나도 깔끔했다는 점이다. 실제 모델의 성능 저하(breakdown)는 한 방향으로 그렇게 고분고분하게 정렬되지 않는다.

또 다른 문제가 있었다: 두 개의 별도 측정값이 서로 일치하지 않았다. 일반 텍스트 지표인 퍼플렉시티 (Perplexity)로 동일한 수정 기술을 측정했을 때, 복구율은 29%에서 멈췄다. 번역 작업에서만 97%의 복구율이 나타났는데, 두 지표가 수십 배(orders of magnitude) 차이가 난다면, 대개 두 측정값 중 하나는 잘못된 것이다.

따라서 집계된 수치를 신뢰하기 전에, 나는 출력물 자체를 직접 확인하기로 결정했다. 세 가지 모델(전체 정밀도, 압축, 수정) 모두에게 30페이지 분량의 만화를 번역하게 한 뒤, 브라우저에 출력물들을 나란히 배치하고 내 눈으로 한 페이지씩 직접 훑어 내려갔다.

공정하게 재측정하기

그것들을 살펴보니 즉시 명확해졌다. 두 가지 수정이 필요했다.

수정 1: 재집계 (recount). 집계 도구가 모델이 "스스로에게 말하는 내용"까지 영어로 카운트하고 있었다. 모델은 번역을 반환하기 전에 내부적으로 추론용 스크래치패드 (reasoning scratchpad, </think>로 닫히는 작업 영역)를 작성한다. 스크래치패드를 제외하고 오직 번역문만 추출하여 다시 집계하자, 전체 정밀도 버전과 수정된 버전의 불필요한 단어 수는 한 자릿수로 떨어졌다.

수정 2: 인스턴스를 다시 생성(re-roll)합니다. 하지만 압축된 버전의 968이라는 수치는 단순히 다시 집계하는 것만으로는 사라지지 않았습니다. 해당 인스턴스는 스크래치패드(scratchpad)가 아니라, 번역문 자체에 가공되지 않은 영어를 내보내고 있었습니다 (아래 구멍 1 참조). 동일한 압축 단계를 다시 실행하여 정상적인 인스턴스를 추출하자, 번역문 전용(translation-only) 단어 수는 7개로 떨어졌습니다.

두 가지 수정 사항을 모두 적용한 결과는 다음과 같습니다 (압축된 열은 다시 생성된 정상적인 인스턴스의 값입니다).

| | 전체 정밀도 (Full-precision) | 압축됨 (Compressed)\

• | 수리됨 (Repaired) |
  | --- | --- | --- | --- |
  | 불필요한 영어 (단어 수) | 5 | 7 | 9 |
  | 불필요한 내용이 남은 페이지 수 | 4 | 5 | 8 |

• 다시 생성된 정상적인 인스턴스. 968을 내뱉었던 불운한 인스턴스가 아님.

세 가지 모두 거의 비슷합니다. 정상적인 인스턴스들을 서로 비교하고 번역문만을 집계하면, 압축이나 수리 모두 불필요한 내용을 거의 변화시키지 못합니다. 968과 33은 오직 이 두 가지 수정 사항이 이루어지기 전까지만 존재했던 환상이었습니다. -97%라는 수치는 흔적도 없이 사라졌습니다.

The automatic metric made it look like a huge gap — 968 for the compressed version against 33 for the repaired one — but recounting the raw output with the same yardstick put all three at 5 to 9 words, with no visible difference

그림 1: 두 가지 척도로 측정된 하나의 현상. 자동 지표(automatic metric)는 압축 버전은 968단어, 수리된 버전은 33단어라는 거대한 격차가 있는 것처럼 보이게 했지만, 가공되지 않은 번역문만을 다시 집계하면 세 가지 모두 5~9단어 사이로 거의 차이가 없습니다. -97%는 척도(yardstick)가 만들어낸 결과물이었습니다.

두 가지 구멍

그렇다면 그 968이라는 숫자는 어디에서 온 것일까요? 두 가지 버그가 결합된 결과였습니다.

구멍 1: 압축 과정에서의 무작위성 (randomness). 모델을 압축하는 과정에는 소수의 샘플을 사용하여 반올림 (rounding)을 조정하는 "교정 (calibration)" 단계가 포함되며, 바로 이 지점에서 무작위성이 개입됩니다. 동일한 절차를 거치더라도 매 실행마다 약간씩 다른 모델이 생성됩니다. 운이 없었던 한 번의 실행에서 "망가진" 압축 버전이 탄생했고, 번역 대신 가공되지 않은 영어 (raw English)를 출력했습니다. 동일한 프로세스를 다시 실행하자 7개의 단어만 쓰레기 값(junk)으로 나타났을 뿐, 나머지 30페이지는 모두 정상적이었습니다. 968이라는 숫자는 단지 운이 없었던 한 번의 추출 결과에 불과했습니다.

구멍 2: 애그리게이터 (aggregator)의 폴백 (fallback). 쓰레기 값을 계산하는 프로그램은 모델의 구조화된 출력 (JSON)을 파싱 (parse)하여 번역 내용만 추출하도록 설계되었습니다. 하지만 파싱에 실패하면, 전체 원문 텍스트 (raw text)에 포함된 영어를 계산하는 폴백 방식으로 전환됩니다. 추론 스크래치패드 (reasoning scratchpad), 프롬프트의 잔상 등 모든 것이 영어로 계산됩니다. 과정은 다음과 같습니다.

망가진 인스턴스 (broken instance) → JSON 파싱 실패 → 폴백 기능이 전체 원문 텍스트의 영어를 계산 → 968로 폭증

운 나쁜 인스턴스 (구멍 1)와 과잉 계산되는 폴백 (구멍 2)이 결합되어 거대한 가짜 차이를 만들어낸 것입니다. 둘 중 하나만 있었다면 이토록 화려하게 망가지지는 않았을 것입니다.

아이러니하게도, 승자로 여겨졌던 — 즉, 수정된 버전 — 모델 자체에도 결함이 있었습니다. 30페이지 중 29페이지에서 추론 스크래치패드의 </think> 태그가 번역 내용보다 앞서 유출되었습니다. 집계 결과 (aggregate)는 이러한 퇴보 (regression)에 대해 단 한 마디도 언급하지 않았습니다.

실제 데이터만 남기기

노이즈가 섞인 수치들을 버리고 나니, 제가 가진 "실제" 데이터는 이것뿐이었습니다.

• 일반 텍스트에 대한 퍼플렉시티 (Perplexity): 10.65 → 10.42
• 참조 모델 (reference model)과의 일치도: 81.6% → 85.8%

작지만 확실한 개선입니다. 대단한 것은 아닙니다.

그리고 한 가지 더: 저는 그 수치를 버리는 방식에 신중을 기했습니다. 저는 "수정 기술이 효과가 없다"라고 결론 내리지 않았습니다. </think> 누출(leakage)과 정크(junk) 감소 실패 모두 **제 측정 절차 자체의 혼란 변수 (confound)**에서 비롯되었을 가능성이 충분하기 때문입니다 (정식 서버가 아닌 임시 평가 경로를 통해 측정했습니다). 그래서 저는 다음과 같이 결론을 맺었습니다 — "-97%라는 자동 지표(automatic metric)는 기각되었습니다. 이 수정이 실제 운영 환경(production)에서 작동하는지는 여전히 미지수이며, 다시 제대로 측정되어야 합니다."

"측정이 틀린 것"과 "기술이 틀린 것"을 혼동하지 마세요. 공정하다는 것은 기술을 부수적 피해(collateral damage)로 삼아 폐기하지 않는 것을 의미하며, 이는 화려한 수치를 버리는 것만큼이나 중요합니다.

교훈 (Lessons)

1. 수치가 화려할수록, 그것을 폐기하기 전에 원시 출력물(raw output)을 더 면밀히 살펴봐야 합니다. -97%처럼 깔끔한 수치나, 수십 배의 차이를 보이는 지표들은 승리가 아니라 경보(alarm)입니다. 집계(aggregate) 단계의 상류(upstream)에 있는 원시 출력물을 한 페이지씩 직접 눈으로 확인하기 전까지는 좋은 소식을 그대로 받아들이지 마세요.

2. 비결정론적(non-deterministic) 단계에는 시드(seed)를 고정하고, 애그리게이터(aggregator)의 폴백(fallback)을 의심하세요. 무작위성(randomness)이 섞여 있다면, 단 한 번의 실행으로는 인스턴스 간 변동(instance-to-instance variation) 외에는 아무것도 알 수 없습니다 (재현되지 않는 개선은 개선이 아닙니다). 또한, 파싱 실패(parse failure) 시 작동하는 폴백은 거대한 가짜 신호(fake signal)를 조용히 만들어낼 수 있습니다 — 오류를 삼킨 후 실제로 무엇을 카운트하고 있는지 확인하세요.

3. 측정 오류와 기술 오류를 분리하여 종결하세요. 거짓된 승리를 버릴 때, 기술까지 함께 묻어버리지 마세요. "지표는 기각되었으나, 기술은 여전히 유효하다"라고 선을 긋는 것이 다음에 이를 제대로 측정할 수 있는 여지를 남겨줍니다.

그리고 이 모든 것의 밑바탕에는 선언문의 첫 번째 원칙, 먼저 측정하라 (Measure First)가 자리 잡고 있습니다. 하지만 제대로 측정해야 합니다. 잘못된 측정은 측정하지 않는 것보다 더 나쁩니다. 잘못된 측정이 가짜 승리를 진짜 승리인 것처럼 실어 나를 수 있기 때문입니다.

부록: 원시 데이터 (raw data)

범위 (Scope): 강력하게 압축된 (INT4) 4B 모델 + 학습된 회전 복구 (learned rotation repair), 30페이지의 만화 번역, A100에서 측정.

1. "참조 모델과의 일치도 (Agreement with the reference model)" = 압축된 버전이 압축되지 않은 전체 정밀도 버전 (FP16)이 생성하는 다음 단어를 얼마나 잘 재현하는지를 나타냅니다 (teacher forcing 하에서의 top-1 일치율). +4.2pt는 "FP16의 동작에 약간 더 가까워졌다"는 것을 의미하며, 번역 자체가 좋아졌다는 뜻은 아닙니다. ↩