Multi‑LCB를 통해 드러난 다국어 코드 격차

LLM(Large Language Models)은 Python 코딩 작업에서는 높은 점수를 기록하지만, 해당 스위트 내의 다른 11개 언어에 대한 숙련도는 떨어집니다. Multi‑LCB 저자들은 "Python 과적합 (Python overfitting). Python에서 강력한 성능을 보이는 모델들이 다른 언어에서는 급격히 성능이 저하된다"[[1]]는 점을 관찰했습니다. 이 벤치마크의 12개 언어 범위는 언어에 구애받지 않는 (language-agnostic) 코드 생성이라는 주장에 의문을 제기할 만큼 극명한 대조를 보여줍니다.

Multi‑LCB 이전에는 커뮤니티의 골드 표준인 LiveCodeBench가 단일 언어인 Python만을 평가했으며, 다른 생태계는 비공식적인 일화에 의존해 왔습니다. 이러한 단일 언어 중심의 접근 방식은 개발자들이 Python 결과를 풀스택 워크로드로 확장하여 추론하도록 장려했으며, 이는 실제 코드베이스의 명백한 다양성에도 불구하고 지속되어 온 습관입니다.

이 연구는 12개 언어에 걸쳐 24개의 LLM을 평가하였으며, "Python 과적합, 언어별 오염 (language-specific contamination), 그리고 다국어 성능에서의 상당한 격차에 대한 증거"를 발견했습니다. 그들의 리더보드는 "언어 간에 상당하고 실질적으로 의미 있는 성능 격차"를 보여주며, 최고의 Python 모델들은 강력한 성능을 보이는 반면, 많은 모델이 Rust, JavaScript, Go에서는 뒤처지는 모습을 보입니다. 24개의 모델과 12개의 언어라는 방대한 범위는 이 격차가 일화적인 것이 아니라 체계적이라는 사실에 의심의 여지를 남기지 않습니다.

하지만 Multi‑LCB는 원래의 LCB 문제 세트를 상속받았는데, 이는 Python을 위해 먼저 작성된 후 기계적으로 번역되었습니다. 이러한 파이프라인은 언어별 오염을 유발할 수 있으며, 낮은 점수가 실제 언어 능력의 부족이 아닌 번역의 부산물과 혼동될 수 있습니다. 논문 자체에서도 이러한 한계를 지적하며, "언어별 오염"이 여전히 혼란 변수(confounding factor)로 남아 있다고 언급했습니다. 또한 이러한 결핍이 불충분한 다국어 사전 학습 (multilingual pre-training) 데이터에서 기인한 것인지, 아니면 대상 언어 자체의 내재적인 어려움에서 기인한 것인지는 명확히 구분하지 못하고 있습니다.

만약 이러한 연구 결과가 유효하다면, 엔지니어링 커뮤니티는 일반적인 프로그래밍 능력의 대리 지표(proxies)로서 Python 전용 코드 벤치마크를 폐기해야 합니다. Multi-LCB 또는 엄격한 다국어 제품군(multilingual suite)을 모델 평가 파이프라인에 통합하면, 모델이 이질적인 스택(heterogeneous stacks)에 배포되기 전에 숨겨진 약점을 드러낼 수 있으며, 우리가 구축하는 도구들이 진정으로 단일 언어 그 이상을 이해하도록 보장할 수 있습니다.

References

1. Multi-LCB: Extending LiveCodeBench to Multiple Programming Languages