Can LLMs Beat Classical Hyperparameter Optimization Algorithms? A Study on autoresearch

이 논문은 LLM 기반 자동화 연구 (autoresearch) 를 통해 전통적인 하이퍼파라미터 최적화 알고리즘과 LLM 에이전트를 비교한 결과, CMA-ES 의 내부 상태를 LLM 과 공유하는 하이브리드 접근법인 'Centaur'가 가장 우수한 성능을 보였으며, 특히 0.8B 모델로도 27B 모델 이상의 효과를 거둘 수 있음을 입증했습니다.

핵심

이 논문은 **"인공지능 (LLM) 이 정말로 기존의 최적화 알고리즘을 이길 수 있을까?"**라는 질문에 답하기 위해 진행된 실험 결과입니다.

비유하자면, 이 연구는 **"새로운 AI 비서 (LLM) 가 숙련된 베테랑 엔지니어 (전통적 알고리즘) 보다 더 똑똑하게 일할 수 있을까?"**를 확인하는 실험이었습니다.

핵심 내용을 일상적인 비유로 설명해 드릴게요.

---

1. 실험 배경: 두 가지 방식의 대결

연구진은 작은 언어 모델을 훈련시키는 과정에서 '최적의 설정값 (하이퍼파라미터)'을 찾는 문제를 풀었습니다. 이때 두 가지 방식이 경쟁했습니다.

• 방식 A (전통적 알고리즘): CMA-ES, TPE 같은 기존 수학 알고리즘들입니다. 이들은 정교한 나침반처럼, 이전 실패와 성공 데이터를 수학적으로 분석하며 가장 좋은 길을 찾아갑니다.
• 방식 B (LLM 에이전트): AI 비서 (Qwen3.5 모델) 가 직접 코드를 수정하거나 설정값을 제안하는 방식입니다. 이는 창의적인 예술가처럼, 인간의 직관과 경험을 바탕으로 "이렇게 해보면 어떨까?"라고 제안합니다.

2. 주요 발견 1: "범위"가 중요했다

실험은 두 가지 시나리오로 나뉘었습니다.

• 시나리오 1: 정해진 범위 안에서만 고르기 (고정된 검색 공간)

  • 결과: 전통적 알고리즘이 압도적으로 이겼습니다.
  • 이유: AI 비서 (LLM) 는 범위가 정해져 있으면 오히려 당황했습니다. 마치 "이 10 가지 메뉴 중에서 고르라"고 했을 때, 창의적인 셰프가 "아니, 저는 이걸로 요리하고 싶어요"라고 말하며 오히려 실패하는 경우와 비슷합니다. LLM 은 과거 실패 데이터를 기억하는 데 약해, 메모리 부족 (OOM) 같은 치명적인 실수를 반복했습니다.
  • 교훈: 창의성보다 '신뢰성'이 더 중요했습니다. 무작위로 많이 시도하는 것보다, 실패하지 않는 안전한 길을 찾는 것이 더 중요했습니다.

• 시나리오 2: 아예 코드를 직접 고쳐라 (제한 없는 검색 공간)

  • 결과: AI 비서가 전통적 알고리즘과 거의 대등한 성적을 냈습니다.
  • 이유: AI 비서가 직접 코드를 수정할 때, 그 창의성이 빛을 발했습니다. 기존에 생각지 못한 새로운 방법을 찾아냈기 때문입니다. 하지만 이 경우, AI 비서의 두뇌 크기 (모델 크기) 가 중요했습니다. 작은 두뇌 (0.8B) 는 코드를 고치는 데 실패했지만, 큰 두뇌 (27B) 는 잘해냈습니다.

3. 해결책: '켄타우로스 (Centaur)'의 등장

연구진은 두 방식의 장점을 합친 혼합형 (Hybrid) 방법을 개발했습니다. 이름은 반은 사람, 반은 말인 신화 속 생물 '켄타우로스'에서 따왔습니다.

• 어떻게 작동할까요?

  • **수학 알고리즘 (나침반)**이 전체적인 방향을 잡고, **AI 비서 (예술가)**가 가끔 "이쪽으로 살짝 틀어보세요"라고 조언을 줍니다.
  • 구체적으로는, 수학 알고리즘이 "지금 우리가 어디에 있고, 어디로 가야 할지"에 대한 모든 내부 데이터 (평균, 단계 크기, 공분산 행렬 등) 를 AI 비서에게 보여줍니다.
  • AI 비서는 이 데이터를 보고 "아, 여기가 위험하구나, 저기로 가자"라고 제안합니다.

• 결과: 이 혼합형이 가장 잘 나왔습니다!

  • 놀라운 점은, 거대한 AI 비서 (27B) 보다 **작은 AI 비서 (0.8B)**를 썼을 때 오히려 더 좋은 결과가 나왔다는 것입니다.
  • 이유: 수학 알고리즘이 이미 길을 잘 찾고 있기 때문에, AI 비서는 거창한 코딩을 할 필요가 없습니다. 그냥 "약간의 조언"만 해주면 되기 때문입니다. 마치 숙련된 운전사 (수학 알고리즘) 가 핸들을 잡고 있을 때, 조수석의 작은 아이 (작은 AI) 가 "저기 빨간불이야!"라고 알려주는 것과 같습니다. 아이의 두뇌가 작아도, 운전사의 실력을 보조하기엔 충분합니다.

4. 결론: 요약하자면

1. 범위가 정해져 있으면: 수학 알고리즘이 AI 비서보다 훨씬 빠르고 정확하게 일을 처리합니다. (AI 는 실패를 잘 피하지 못함)
2. 코드를 직접 고르면: AI 비서가 강력한 무기가 될 수 있습니다. 하지만 그 AI 는 충분히 똑똑해야 합니다.
3. 최고의 방법은: 수학 알고리즘이 주도권을 잡고, AI 비서가 가끔 조언을 해주는 '혼합형'입니다. 이 경우, 값비싼 거대 AI 가 아니라 저렴한 작은 AI 로도 최고의 성과를 낼 수 있습니다.

한 줄 요약:

"혼자서 모든 걸 하려던 AI 비서보다, 숙련된 수학 알고리즘과 손잡고 '조언자' 역할을 한 AI가 가장 똑똑하게 일했습니다."

기술 요약

논문 요약: LLM 기반 자동화 연구 (autoresearch) 를 통한 하이퍼파라미터 최적화 비교 연구

이 논문은 대규모 언어 모델 (LLM) 에이전트가 직접 학습 코드를 수정하며 하이퍼파라미터 (HP) 를 최적화하는 방식이, 기존의 고전적인 하이퍼파라미터 최적화 (HPO) 알고리즘을 능가할 수 있는지 여부를 검증합니다. 저자들은 'autoresearch'를 테스트베드로 활용하여 고정된 검색 공간과 비제약 (Unconstrained) 코드 편집 환경에서 다양한 방법을 비교 분석했습니다.

1. 연구 문제 (Problem)

• 배경: 최근 LLM 에이전트가 학습 코드를 직접 수정하여 소규모 언어 모델의 성능을 향상시킨 사례 (Karpathy, 2025a) 가 등장했습니다. 반면, 전문가가 설계한 하이퍼파라미터를 가진 고전적 AutoML 방법 (TPE 등) 이 동일한 예산 내에서 더 좋은 성능을 보인다는 연구 (Ziv, 2025) 도 존재합니다.
• 핵심 질문:
  1. 다른 고전적 HPO 방법들은 이 작업에서 어떻게 수행되는가?
  2. LLM 기반 HPO 방법이 고전적 방법들을 능가할 수 있는가?
  3. LLM 의 강점 (도메인 지식) 과 약점 (상태 추적 실패) 을 어떻게 극복할 수 있는가?

2. 방법론 (Methodology)

• 벤치마크 환경:
  • 작업: nanochat (약 50M 파라미터의 디코더 전용 트랜스포머) 을 FineWeb 데이터셋으로 학습시키며 검증 비트/바이트 (val_bpb) 를 최적화.
  • 조건: 24 시간 GPU 예산, 3 개의 시드 (seed), 단일 H200 GPU 사용.
  • 검색 공간: 학습 스크립트 (train.py) 에서 AST(추상 구문 트리) 파싱을 통해 자동으로 14 개의 하이퍼파라미터를 추출 (수동 커스터마이징 최소화).
• 비교 대상 (9 가지 방법):
  • 고전적 HPO (4 가지): TPE, CMA-ES, SMAC, Random Search.
  • LLM 기반 (4 가지): LLAMBO (서로 다른 구현), Karpathy Agent (고정 HP), Karpathy Agent (코드 직접 편집).
  • 하이브리드 (1 가지): Centaur (제안된 방법).
• 제안된 방법: Centaur
  • 개념: CMA-ES 와 LLM 을 결합한 하이브리드 접근법.
  • 동작: CMA-ES 의 전체 내부 상태 (평균 벡터 $\mu$, 스텝 크기 $\sigma$, 공분산 행렬 $C$) 를 LLM 에게 공유합니다.
  • 프로세스: 실험의 약 30% 에서 LLM 이 CMA-ES 의 제안과 내부 상태, 최근 20 회 실험 기록을 바탕으로 제안을 수정 (Override) 합니다. 나머지 70% 는 CMA-ES 가 직접 제안하며, 모든 실험 결과는 CMA-ES 의 상태를 업데이트하는 데 사용됩니다.
  • 모델: Qwen3.5 (0.8B 및 27B) 를 자체 호스팅하여 사용.

3. 주요 기여 (Key Contributions)

1. 포괄적인 벤치마크: 고정된 HP 검색 공간과 비제약 코드 편집 환경 모두에서 9 가지 HPO 방법을 동일한 조건 (24 시간, 3 시드) 에서 비교했습니다.
2. 성능 비교 결과 도출: 고정된 검색 공간 내에서는 고전적 HPO 가 LLM 에이전트보다 우세함을 입증했습니다. 반면, LLM 이 직접 코드를 편집하는 비제약 환경에서는 고전적 방법과의 격차가 크게 줄어듦을 확인했습니다.
3. Centaur 도입: CMA-ES 의 내부 상태를 LLM 과 공유하는 하이브리드 방법을 제안하여 실험에서 최고의 성능을 달성했습니다.
4. 심층 분석: 검색 다양성, OOM(메모리 부족) 발생률, 모델 스케일링 효과를 분석하고 실험별 LLM 대화 로그를 공개했습니다.

4. 실험 결과 (Results)

• 고정 검색 공간 (Fixed Search Space):
  • 고전적 방법의 우세: CMA-ES 와 TPE 와 같은 고전적 알고리즘이 LLM 기반 에이전트보다 일관되게 더 빠르고 우수한 성능을 보였습니다.
  • LLM 의 한계: 고정된 HP 공간만 탐색하는 LLM 은 고전적 방법보다 성능이 낮았으며, 일부는 무작위 검색보다도 나빴습니다.
  • OOM(메모리 부족) 의 중요성: 성능이 좋은 방법들은 OOM 발생률이 낮았습니다 (16% 이하). 반면, LLM 기반 방법들은 전체 실험 기록을 보더라도 OOM 이 발생하기 쉬운 영역을 피하는 데 실패하여 (48~61% 발생) 성능이 저하되었습니다. 이는 LLM 이 최적화 상태를 추적하는 데 어려움을 겪음을 시사합니다.
• 비제약 코드 편집 (Unconstrained Code Editing):
  • LLM 의 잠재력: Karpathy Agent(코드 직접 편집) 는 고전적 방법과 경쟁 가능한 수준 (val_bpb ~0.9814) 에 도달했습니다.
  • 모델 스케일링 필요성: 0.8B 모델은 코드 편집에는 부적합했으나, 27B 모델로 확장하면 성능이 크게 향상되었습니다.
• 하이브리드 최적화 (Centaur):
  • 최고의 성능: Centaur(0.8B 및 27B) 가 모든 방법 중 최고의 결과를 기록했습니다.
  • 작은 모델의 효율성: 흥미롭게도 Centaur(0.8B) 가 Centaur(27B) 보다 더 좋은 성능을 보였습니다 (0.9766 vs 0.9763). 이는 강력한 고전적 최적화기 (CMA-ES) 와 결합될 경우, 저렴하고 작은 LLM 만으로도 충분한 보완적 가치를 제공함을 의미합니다.
  • 안정성 향상: Centaur 는 CMA-ES 단독 사용 시의 높은 분산 (std 0.0036) 을 크게 줄여 (std 0.0005) 실험 간 안정성을 높였습니다.

5. 의의 및 결론 (Significance & Conclusion)

• 핵심 통찰:
  • 신뢰성 vs 탐색: LLM 기반 방법에서 '검색의 다양성'보다 'OOM 과 같은 실패를 피하는 신뢰성'이 성능에 더 중요한 요소였습니다.
  • 역할 분담: 작은/중형 LLM 은 최적화 상태 (State) 를 추적하는 데는 부족하지만, 도메인 지식 (학습 인사이트) 을 제공하는 데는 유용합니다. 반면, CMA-ES 는 상태 추적과 수렴에는 탁월하지만 도메인 지식이 부족합니다.
  • 하이브리드의 승리: Centaur 는 CMA-ES 의 수렴 속도와 안정성을 유지하면서, LLM 이 제공하는 도메인 지식을 통해 성능을 극대화했습니다.
• 미래 전망:
  • 현재 연구는 오픈 가중치 모델 (Qwen3.5) 에 기반했으나, 비제약 코드 편집 환경에서 LLM 이 고전적 방법을 능가하기 위해서는 모델 규모와 능력이 더 커져야 할 가능성이 있습니다.
  • 향후 연구에서는 최첨단 (Frontier) 모델을 활용한 비제약 코드 편집 벤치마킹과, 검색 공간 자체가 최적화 과정과 함께 진화하는 방식의 탐구가 필요할 것입니다.

요약하자면, 이 논문은 "LLM 만으로 하이퍼파라미터 최적화를 수행하는 것보다, 고전적 최적화 알고리즘의 상태 관리 능력과 LLM 의 도메인 지식을 결합한 하이브리드 방식 (Centaur) 이 현재로서는 가장 효과적"임을 입증했습니다.