"테스트 점수"와 "실제 세계의 기술"이 어긋나게 된 단 하나의 이유

미세 조정(Fine-tuned)된 8B 모델은 벤치마크(Benchmark)에서 우수한 성적을 거둔 우등생이었으나, 실제 운영 환경과 유사한 설정에서는 더 작은 4B 모델에게 패배했습니다 (21 대 11). 이는 모델 용량의 한계처럼 보였습니다.

원인은 모델도, 학습(Training)도 아니었습니다. 그것은 바로 내가 학습시킨 정밀도(Precision)와 운영 환경에서 실행되는 정밀도가 달랐기 때문이었습니다. 두 베이스 모델에 동일한 어댑터(Adapter)를 적용하고 비교한 결과, 23 대 2라는 결과가 나왔습니다. 즉, 환경 불일치(Environment mismatch)가 문제였습니다.

운영 환경의 압축(Compression)을 고려하여 다시 학습시키자, 8B 모델이 4B 모델보다 앞서 나갔습니다. 기술을 학습시키는 조건과 기술을 서비스하는 조건을 동일하게 유지하십시오. 그것만으로도 사라졌던 기술이 온전하게 나타나기에 충분했습니다.

나는 승리할 수 있는 패를 쥐고 있었습니다.

나는 더 나은 번역 품질을 원했습니다. 이는 더 큰 모델인 8B(80억 개의 파라미터)가 더 작은 4B보다 더 많은 것을 기억하고 미묘한 문맥을 읽을 수 있음을 의미합니다. 실제로 지난번 미세 조정(Fine-tuning)을 통해 학습시킨 8B 모델은 내가 만든 벤치마크에서 결점 없는 수치를 기록하고 있었습니다. 이제 남은 것은 운영 환경에 적용하는 것뿐이었습니다. 나는 그렇게 생각했습니다.

하지만 운영 환경과 유사한 설정에 모델을 로드하고 품질을 다시 측정했을 때, 그 8B 모델은 더 작아야 할 4B 모델에게 패배했습니다. 한 평가에서는 21 대 11이었습니다. 순서가 뒤바뀐 것입니다. 더 큰 모델이 더 똑똑해야 하는데, 실제 운영 환경에서는 더 작은 모델이 이기고 있었습니다.

잠시 동안 나는 다음과 같은 결론을 내릴 뻔했습니다. 그냥 단순하게 4B 모델에 실시간 번역을 적용하자. 더 큰 모델은 이 유스케이스(Use case)에 적합하지 않다고 말이죠.

그것이 실수였습니다. 8B 모델이 약해진 것이 아니었습니다. 내가 측정하던 8B와 내가 운영 환경에 넣은 8B는 서로 다른 것이었습니다.

벤치마크와 운영 환경에서 모델의 "정밀도(Precision)"가 달랐다

본격적인 폭로에 앞서, 용어 하나를 짚고 넘어가겠습니다. **양자화 (Quantization)**는 모델이라는 '거대한 숫자의 산'을 더 적은 비트(bits)로 다시 저장하여 가볍게 만드는 압축 기술입니다. Part 1에서 자세히 다루었지만, 핵심은 이렇습니다. 프로덕션 GPU에서 모델을 빠르고 저렴하게 실행하려면, 모델을 로드하기 전에 압축해야 합니다.

그 지점이 바로 함정이었습니다. 의도한 적은 없었지만, 저의 워크플로우는 다음과 같은 상태가 되어 있었습니다.

• 미세 조정 (Fine-tuning, 학습)은 전체 정밀도 (Full precision)로 진행됩니다. 숫자를 정밀하게 담는 포맷인 BF16에서 모델에 번역 기술을 학습시킵니다.
• 프로덕션 (Production, 배포)은 압축된 상태로 실행됩니다. 크기를 4분의 1로 줄인 포맷인 INT4로 모델을 로드하여 속도와 비용 측면에서 이득을 얻습니다.

다시 말해, 기술이 학습된 형태와 고객이 받는 형태가 서로 달랐던 것입니다. 벤치마크는 전체 정밀도 형태를 측정하지만, 프로덕션은 압축된 형태를 실행합니다. 이는 마치 두 명의 서로 다른 사람이 시험 문제지와 실제 시험지를 작성한 것과 같습니다.

동일한 어댑터, 다른 베이스 — 그리고 뒤바뀐 결과

의구심을 확인하는 과정은 허무할 정도로 쉬웠습니다. **정확히 동일한 미세 조정 (Fine-tuning, 어댑터)**을 가져와서 두 개의 베이스 모델에 적용한 뒤, 동일한 40개 항목을 두고 대결하게 했습니다.

• 베이스 A = 전체 정밀도 (BF16). 학습할 때와 동일한 형태입니다.
• 베이스 B = 압축됨 (INT4). 프로덕션에 배포되는 형태입니다.

(어댑터는 베이스 모델에 사후에 결합하는 '기술 교정 부품'입니다. 베이스는 바뀌었지만, 그 위에 결합된 교정 부품은 마지막 1비트까지 동일하게 유지되었습니다.)

결과는 냉혹했습니다. 저는 opus에게 판정을 맡겼습니다 (두 번역문을 제3자의 고성능 AI 앞에 나란히 두고, 어느 쪽이 더 나은지 결정하게 했습니다).

두 모델 모두 동일한 기술이 학습되었다고 가정했을 때, 베이스 모델을 압축하는 것만으로 승리 횟수가 23회에서 2회로 급감했습니다. 그리고 결함들을 하나씩 읽어보니, 주어 혼동 (subject mix-ups) (누구의 대사인지 틀리는 것) 및 극성 반전 (polarity flips) (

비유를 들어보겠습니다. 기술을 학습시킬 때, 저는 눈금이 아주 세밀한 고정밀 자를 사용하여 선을 그렸습니다. 그런데 실제 운영 환경(production)에서는 이를 눈금이 거친 자로 바꾸어 그 선들을 복사하려고 시도한 것입니다. 선이 더 가늘수록, 거친 자는 그 선을 제대로 포착할 수 없습니다.

해결책: 운영 환경의 형태로 학습시키기

만약 이것이 원인이라면, 해결책은 명확합니다. 실제 운영 환경에 배포하는 것과 동일한 압축된 베이스(compressed base)를 사용하여 미세 조정 (fine-tuning)을 다시 수행하십시오. 처음부터 거친 자를 사용하여 선을 그리는 것입니다. 반올림 오차(rounding error)가 이미 반영된 상태로 기술을 구축하면, 그 기술은 운영 환경에서도 온전하게 나타납니다. 이렇게 "학습과 운영을 동일한 정밀도로 유지하는" 방식을 양자화 인식 학습 (quant-aware training, 운영 환경의 정밀도를 반영하여 학습하는 방식)이라고 부릅니다.

저는 동일한 40개 항목에 대해 다시 측정했습니다.

가장 명확한 효과는 기존의 불일치하는 8B와의 일대일 대결에서 나타났습니다. 결과는 20 대 8로 앞섰으며, 판정이 명확한 항목만 집계했을 때는 10 대 0이었습니다. 모든 주어 혼동 (subject mix-ups) 및 극성 반전 (polarity flips) 오류는 기존 모델 측에 머물렀고, 재학습된 모델 측은 깨끗했습니다. 대상을 "운영 환경 형태의 4B"로 바꾸었을 때도 8B는 퇴보(regression)를 보이지 않았습니다 (16승 / 15무 / 9패, n=40. 15번의 무승부 때문에 승률이 높다고 선언하기에는 부족하지만, 적어도 패배하지는 않았습니다). "4B에게 진다"는 가정은 바로 이 지점에서 무너졌습니다. 만화 번역에서도 434개 항목 전체에서 에코 (echo, 원문을 그대로 복사하는 현상)가 0을 유지했습니다.

저는 "실시간 번역은 4B가 담당한다"는 결정을 철회했습니다. 8B는 결코 약한 모델이 아니었습니다.

모델을 의심하기 전에, 측정 방식을 의심하십시오

가장 뼈아팠던 점은 제가 모델의 용량 (capacity)을 탓할 뻔했다는 사실입니다. "8B는 이 유스케이스 (use case)에 적합하지 않다." 이는 그럴듯한 가설이었고, 그렇게 결론을 내렸다면 문제가 빠르게 해결되었을 것입니다. 하지만 진짜 범인은 모델 내부에 있지 않았습니다. 그것은 바로 **모델을 측정하는 데 사용한 절차 (procedure)**에 있었습니다. 학습 환경과 운영 (production) 환경이 일치하지 않았던 것입니다. 이는 모델의 문제가 아니라 시스템의 문제였습니다.

"똑똑해야 할 AI가 운영 환경에서 갑자기 멍청해진다." 이런 현상을 목격했을 때, 가장 먼저 의심해야 할 것은 모델의 능력이 아닙니다. 벤치마크 (bench)와 운영 환경이 정말로 동일한 조건에서 실행되고 있는지를 의심해야 합니다.

교훈 (Lessons)

1. 모델을 의심하기 전에 측정 방식을 의심하십시오. 똑똑해야 할 AI가 운영 환경에서 실수를 하기 시작할 때, 의심해야 할 것은 모델의 용량이 아니라 측정 절차입니다. 학습 환경과 운영 환경 모두에 동일한 어댑터 (adapter)를 적용해 보면, 범인이 모델인지 환경인지 구분할 수 있습니다 (결과는 후자였습니다, 23 대 2).

2. 기술을 학습시키는 조건과 이를 서비스하는 조건을 동일하게 유지하십시오. 미세 조정 (Fine-tuning)과 압축 (compression)은 별개의 단계이지만, 이들 사이의 상호작용을 잘못 설정하면 학습시킨 기술이 운영 환경에서 사라져 버립니다. 학습부터 서빙 (serving)까지 모든 과정을 하나의 연속된 시스템으로서 일정하게 유지해야만 비로소 실제 품질이 확보됩니다.

3. 설계 결정의 규모가 클수록, 경기장이 평평한지(조건이 공정한지) 더 엄격하게 확인해야 합니다. 8B에서 4B로의 전환은 단 한 번의 측정 불일치로 인해 결정될 뻔했습니다. "적합하지 않다"라고 결론 내리기 전에, 비교하고 있는 조건들이 진정으로 공정한지 반드시 확인하십시오.

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

조건: 모두 Live, 40개 항목, opus 쌍별 판정 (승리 / 무승부 / 패배).