숫자가 클수록 의심부터 해야 하는 이유
이번 주 눈에 띈 기사 네 건을 나란히 놓으면 공통 패턴이 보입니다. 모두 구체적인 성능 지표를 전면에 내세우면서도, 실험 설계와 통계적 검증에 대한 기술은 놀라울 정도로 빈약합니다. CRAG(Self-Reflective RAG)는 환각률을 24%에서 6%로 줄였다고 발표했고, 트릴리온랩스의 Tri 21B Think는 '국가대표 AI 모델 평균치를 상회'한다고 주장하며, 한 개인 프로젝트는 PaySim 데이터셋에서 ROC-AUC ~0.999를 달성했다고 공유합니다. 인상적이죠. 하지만 샘플 사이즈가 충분한가요? 베이스라인 대비 비교 조건이 공정한가요? 이 질문에 답하는 기사는 없었습니다.
CRAG: 환각률 6%의 실험 조건이 빠져 있다
dev.to에 게시된 CRAG 가이드는 Basic RAG 대비 Fact Accuracy를 68%→89%, Hallucination Rate를 24%→6%로 개선했다는 테이블을 제시합니다. 문제는 이 수치가 'internal benchmark'라는 한 줄로만 출처가 명시된다는 점입니다. 테스트 쿼리 수, 도메인 분포, Golden Dataset의 라벨링 기준, 그리고 환각을 어떤 rubric으로 판정했는지가 전혀 기술되어 있지 않습니다. Cross-Encoder 임계값을 0.7/0.3으로 설정한 근거도 '경험적(empirical)'이라는 한마디뿐입니다. 이건 재현 불가능한 실험입니다. P99 레이턴시가 850ms→1.4s로 65% 증가한 점은 솔직하게 공개했지만, 이 정도 레이턴시 오버헤드가 정당화되려면 정확도 개선의 신뢰구간(confidence interval)이 먼저 제시되어야 합니다.
Tri 21B Think: '평균값 비교'라는 통계적 함정
트릴리온랩스의 Tri 21B Think 발표(aitimes 보도)는 더 흥미로운 사례입니다. 21B 매개변수로 5~25배 큰 모델의 성능에 '대등하거나 앞선다'는 주장인데, 비교 대상이 2단계 진출 5개 모델의 평균값입니다. 평균은 분포를 숨기는 지표입니다. 5개 모델 중 하위 2개가 특정 벤치마크에서 극단적으로 낮은 점수를 받았다면, 평균은 쉽게 이길 수 있습니다. 중앙값(median)이나 개별 모델 대비 head-to-head 비교가 없으면 이 주장의 강도를 판단할 수 없습니다. 기사도 인정하듯, 수학 추론(AIME), 코딩(AA-LCR), 최고난도 추론(HLE)에서는 한계가 확인됐습니다. 즉, cherry-picking 가능성이 열려 있는 벤치마크 구성입니다. Ablation study 결과 — 백트래킹 구조와 테스트 타임 스케일링 각각의 기여도 — 도 공개되지 않았습니다.
ROC-AUC 0.999의 착시: 클래스 불균형이 만드는 허상
사기 탐지 프로젝트의 ROC-AUC ~0.999는 데이터 분석가에게 가장 익숙한 함정입니다. 0.17% 클래스 불균형에서 ROC-AUC는 거의 항상 높게 나옵니다. TN(True Negative)이 압도적으로 많으니까요. 실제로 의미 있는 지표는 Precision-Recall AUC(PR-AUC), 특히 소수 클래스의 Recall과 Precision의 trade-off입니다. class_weight='balanced'와 scale_pos_weight 적용은 올바른 방향이지만, 최종 Confusion Matrix에서 False Negative(사기를 놓친 건수)가 몇 건인지, 실제 운영 환경의 트랜잭션 볼륨에서 이 FN이 금액 기준 얼마의 손실을 의미하는지가 핵심입니다. 모듈화된 코드 구조와 pytest 테스트는 MLOps 관점에서 바람직하지만, 모델 성능 주장과 엔지니어링 품질은 별개의 축입니다.
GBM 지배력 논쟁이 던지는 메타 질문
dev.to의 GBM 정형 데이터 지배력 분석 글은 직접적인 성능 수치를 주장하지 않지만, 오히려 가장 정직한 프레이밍을 보여줍니다. GBM이 정형 데이터에서 강한 이유를 gradient/Hessian 기반 split gain, histogram 최적화, 정규화 메커니즘으로 설명하면서도 'feature engineering 의존성'이라는 구조적 한계를 명시합니다. 이 글이 위 세 사례의 배경이 되는 이유는 간단합니다. 어떤 모델이든 입력 데이터의 품질과 실험 설계의 엄밀성이 성능 수치보다 중요하다는 메시지를 담고 있기 때문입니다.
시사점: ML 성능 주장을 읽을 때의 체크리스트
정리하면, ML 성능 숫자를 접할 때 최소한 다음을 확인해야 합니다.
- 샘플 사이즈와 테스트셋 구성 — 몇 건의 데이터로 평가했는가? 도메인 분포는?
- 베이스라인의 공정성 — 비교 대상의 하이퍼파라미터 튜닝 수준이 동일한가?
- 지표 선택의 적절성 — 클래스 불균형에서 Accuracy나 ROC-AUC만 보고 있지 않은가?
- 신뢰구간과 반복 실험 — 단일 run 결과인가, 여러 seed의 평균±표준편차인가?
- Ablation study — 각 구성 요소의 독립적 기여도가 검증되었는가?
- 프로덕션 환경과의 격차 — 레이턴시, 비용, 데이터 드리프트를 고려한 결과인가?
이건 correlation이지 causation이 아닙니다 — 벤치마크 점수가 높다는 것과 실제 비즈니스 가치를 만든다는 것은 다른 차원의 이야기입니다. 숫자를 발표하는 쪽보다 숫자를 읽는 쪽의 리터러시가 더 중요한 시대입니다. pd.read_csv()로 데이터를 열기 전에, 먼저 그 데이터가 어떻게 만들어졌는지를 물어야 합니다.