🤖 machine learning

iML: Executable, Problem-Grounded, and Broadly Exploratory Code-Driven AutoML

본 논문은 구조화된 청사진과 반복적인 디버깅을 통해 실행 가능하고, 문제에 근거하며, 폭넓게 탐색적인 솔루션을 보장하는 멀티 에이전트 코드 기반 AutoML 프레임워크인 iML을 소개하며, 이를 통해 다양한 머신러닝 벤치마크에서 최첨단 성능과 높은 신뢰성을 달성한다.

원저자: Dat Le, Duc-Cuong Le, Anh-Son Nguyen, Tuan-Dung Bui, Thu-Trang Nguyen, Son Nguyen, Hieu Dinh Vo

게시일 2026-06-02

📖 4 분 읽기☕ 가벼운 읽기

CC0 1.0

원저자: Dat Le, Duc-Cuong Le, Anh-Son Nguyen, Tuan-Dung Bui, Thu-Trang Nguyen, Son Nguyen, Hieu Dinh Vo

원본 논문은 CC0 1.0 (http://creativecommons.org/publicdomain/zero/1.0/)에 따라 공공 도메인에 제공됩니다. ✨ 이것은 아래 논문에 대한 AI 생성 설명입니다. 저자가 작성하거나 승인한 것이 아닙니다. 기술적 정확성을 위해서는 원본 논문을 참조하세요. 전체 면책 조항 읽기

당신이 복잡한 기계, 예를 들어 고성능 레이스 카를 만들고 싶지만 정비사가 되는 법은 모른다고 상상해 보십시오. 당신은 매우 똑똑하고 박식하지만 때로는 자만하기도 하는 조수(AI)에게 설계도를 작성하고 차를 만들어 달라고 요청합니다.

과거의 이러한 조수들은 종纸 위에서는 완벽해 보이지만, 막상 엔진을 켜는 순간 무너져 내리는 계획을 세우곤 했습니다. 그들은 당신이 V6 엔진만 가지고 있는데도 V8 엔진이 있다고 가정하거나, 속도에 관한 아름다운 연설을 늘어놓느라 바빠서 바퀴를 볼트로 조이는 것을 잊어버리기도 했습니다.

이 논문은 이러한 문제들을 해결하기 위해 설계된 새로운 AI 조수 팀인 𝑖ML을 소개합니다. 𝑖ML는 모든 것을 한꺼번에 처리하려는 단일 조수 대신, 고도로 조직화된 건설 현장 팀처럼 작동하는 **멀티 에이전트 팀(multi-agent team)**을 사용합니다. 이들의 목표는 실제로 작동하며, 당신이 가진 실제 재료를 바탕으로 구축되고, 경주에서 승리하기 위한 다양한 방법을 탐색하는 머신러닝 모델(즉, "자동차")을 만드는 것입니다.

𝑖ML이 어떻게 작동하는지 세 가지 간단한 원칙으로 나누어 설명하겠습니다.

1. "실제로 돌아가는가?" 규칙 (실행 가능성, Executability)

대부분의 AI 조수들은 실행하려고 하면 충돌이 발생하는 코드를 작성합니다. 𝑖ML은 코드를 실행하는 것을 가장 중요한 테스트로 간주합니다.

비유: 요리 레시피를 쓰기만 하는 것이 아니라, 실제로 요리를 하고 맛을 본 뒤, 너무 짜면 손님에게 내놓기 전에 미리 수정하는 요리사를 상상해 보십시오.
𝑖ML의 방식: 팀은 작업을 작은 부분들(데이터 준비, 모델 구축)로 나눕니다. 이들은 각 부분을 별도로 구축한 다음, 이를 조립해 봅니다. 만약 부품이 맞지 않으면(예: 둥근 구멍에 사각형 말뚝을 끼우는 경우), 시스템은 즉시 중단하고 정확한 오류를 찾아내어 그 부분만을 수정합니다. 전체 기계가 매끄럽게 작동할 때까지 계속해서 시도하고 수정합니다. 이를 통해 최종 결과물이 실제로 작동하는 비율을 90%까지 보장합니다.

2. "가진 것을 보라" 규칙 (문제 접지, Problem Grounding)

때때로 AI 조수들은 사실을 지어내곤 합니다. 데이터가 깨끗하다고 추측하지만 실제로는 지저도 난장판일 수 있고, 당신이 날씨를 예측하고 싶은데 판매량을 예측하고 싶어 한다고 가정할 수도 있습니다.

비유: 당신이 준 설계도와 실제 부지의 상태를 무시하고, 당신이 원할 것이라고 '생각'하여 수영장을 짓기로 결정하는 건설업자를 상상해 보십시오.
𝑖ML의 방식: 코드를 한 줄도 쓰기 전에, 𝑖ML은 실제 데이터를 조사하기 위해 "정찰병"을 보냅니다. 누락된 데이터가 얼마나 되는지 세고, 정보의 유형을 확인하며, 유사한 데이터에 대해 다른 전문가들이 무엇을 했는지 조사합니다. 그런 다음 추측이 아닌 현실에 기반한 엄격한 계획(즉, "설계도")을 만듭니다. 이는 팀이 논리적으로는 타당하지만 당신의 특정 문제에는 쓸모없는 모델을 만드는 것을 방지합니다.

3. "모든 것을 시도하라" 규칙 (광범위한 탐색, Broad Exploration)

기존의 AutoML 시스템은 고속도로만 달릴 줄 아는 운전자처럼, 하나의 경로를 선택하면 그것만 고집하는 경우가 많습니다. 도로가 비포장도로로 바뀌면 그들은 길을 잃습니다.

비유: 한 명의 용의자만 조사하는 형사를 상상해 보십시오. 𝑖ML은 세 명의 서로 다른 용의자를 인터뷰하는 형사와 같습니다. 한 명은 전통적인 방식을 사용하고, 한 명은 첨단 장비를 사용하며, 다른 한 명은 맞춤형 도구를 사용합니다.
𝑖ML의 방식: 팀은 문제를 해결하기 위해 단 하나의 방법만을 선택하지 않습니다. 이들은 세 가지 전략을 병렬로 실행합니다:
1. 전통적인 방법 (견고한 세단처럼 신뢰할 수 있는 방식).
2. 사전 학습된 모델 (스포츠카처럼 기존의 스마트한 도구를 사용하는 방식).
3. 커스텀 신경망 (독특하고 맞춤화된 엔진을 처음부터 직접 만드는 방식).
  그들은 이 세 가지를 모두 테스트하여 어떤 것이 경주에서 승리하는지 확인하고 승자를 선택합니다. 만약 하나가 실패하더라도 포기하지 않고 다음으로 좋은 옵션으로 전환합니다.

팀 구조

이를 실현하기 위해 𝑖ML은 AI 에이전트들을 다음과 같은 특정 역할로 조직합니다:

전략가 (The Strategist): 문제를 읽고 데이터를 조사하여 마스터 설계도를 작성합니다.
전문가 (The Specialists): 서로 혼동되지 않도록 서로 다른 에이전트들이 특정 부분(데이터 클리닝 담당, 모델 구축 담당 등)에 대한 코드를 작성합니다.
조립자 및 디버거 (The Assembler & Debugger): 이들은 조각들을 모아 조립하고 테스트합니다. 만약 무언가 고장 나면, 전체 자동차를 다시 만드는 대신 진단 도구를 가진 정비사처럼 정확히 고장 난 볼트를 찾아내어 수정합니다.

결과

저자들은 이 시스템을 두 가지 어려운 과제(유명한 Kaggle 데이터 과학 경진대회와 같은)에 적용하여 테스트했습니다.

신뢰성: 다른 시스템들이 절반 정도의 확률로 작동하는 결과를 내는 데 실패한 반면, 𝑖ML은 90%의 시간 동안 성공했습니다.
성능: 𝑖ML은 단순히 작동하는 것에 그치지 않고 승리했습니다. 𝑖ML은 기존의 자동화 도구와 다른 AI 에이전트들을 제치고 **45%**의 경진대회에서 "메달"(상위 순위)을 획득했습니다.
강건성: 지침이 모호하거나 "이 데이터를 수정하라"는 식의 최소한의 정보만 주어진 상황에서도, 텍스트 지침 대신 실제 데이터 조사를 바탕으로 의존함으로써 𝑖ML은 여전히 70%의 시간 동안 성공을 거두었습니다.

요약하자면, 𝑖ML은 추측을 멈추고, 테스트를 시작하며, 전문적인 팀을 구성하여 최종 머신러닝 모델이 단순한 멋진 아이디어가 아니라 실제로 작동하는 고성능의 현실이 되도록 보장하는 시스템입니다.

기술 요약: $i$ ML – 실행 가능하고, 문제에 기반하며, 폭넓게 탐색하는 코드 기반 AutoML

1. 문제 정의

자동화된 머신러닝(AutoML)이 머신러닝에 대한 접근성을 민주화했지만, 기존 시스템들은 유연성, 투명성 및 실행 신뢰성 측면에서 상당한 한계에 직면해 있습니다. 전통적인 AutoML 도구들은 종មាន 정해진 탐색 공간(예: 정형 데이터)에 국한된 경직된 "블랙박스"로 작동하며, 복잡하거나 멀티모달인 문제를 위해 파이프라인을 커스텀할 수 있는 능력이 부족합니다.

최 recent LLM(대규모 언어 모델) 기반 에이전트들은 전처리, 훈련 및 평가를 위한 실행 가능한 코드를 합성하는 **코드 기반 AutoML(Code-driven AutoML)**로 패러다임을 전환했습니다. 그러나 현재의 접근 방식들은 세 가지 결정적인 결함을 가지고 있습니다:

실행 가능성의 결여: 생성된 코드가 텍스트상으로는 그럴듯해 보일 수 있으나, 런타임 오류, 타입 불일치 또는 검증되지 않은 가정으로 인해 실행 시 실패합니다.
불충분한 문제 기반(Problem Grounding): 계획 결정이 실제 데이터셋에 대한 경험적 분석보다는 검증되지 않은 텍스트적 가정이나 "환각(hallucination)"된 데이터 속성에 의존합니다.
좁은 탐색 범위: 많은 시스템이 단일 모델링 경로(예: 단일 스크립트의 미세 조정 또는 AutoGluon과 같은 고정된 백엔드 래핑)에 조기에 안주하여, 전통적인 ML, 사전 학습된 모델 적응, 그리고 커스텀 신경망 구조를 아우르는 최신의 다양한 솔루션 전략을 탐색하는 데 실패합니다.

2. 방법론: $i$ ML 프레임워크

저자들은 실행 가능성(Executability), 문제 기반(Problem Grounding), 그리고 **폭넓은 탐색(Broad Exploration)**이라는 세 가지 핵심 요구 사항을 충족하도록 설계된 멀티 에이전트 코드 기반 AutoML 프레임워크인 $i$ ML을 소개합니다. 이 프레임워크는 세 가지 조정된 단계로 작동합니다:

1단계: 코드 가이드 전략적 계획 (Code-Guided Strategic Planning)

직접적인 코드 생성 프롬프팅 대신, $i$ ML은 먼저 문제에 기반한 전략적 청사진( $B$ )을 구축합니다.

태스크 분석 및 프로파일링: *태스크 분석가(Task Analyzer)*는 의미론적 제약 조건을 추출하고, *프로파일링 에이전트(Profiling Agent)*는 원시 데이터셋( $\mathcal{D}$ )을 경험적으로 분석하여 스키마, 결측 패턴, 데이터 품질을 포함한 메타 특징( $F_{meta}$ )을 생성합니다.
지식 검색: *지식 검색기(Knowledge Retriever)*는 외부 소스로부터 도메인 제약 조건과 전처리 전략을 습득합니다.
청사진 합성: *가이드라인 에이전트(Guideline Agent)*는 전처리 지침, 모델 선택 로직(전통적 ML, 사전 학습된 모델 적응 또는 커스텀 신경망 구조 중 선택), 훈련 프로토콜 및 평가 지표를 명시하는 구조화된 청사을 합성합니다. 이 청사진은 탐색 공간을 제한하는 일련의 아키텍처 불변량(architectural invariants) 역할을 합니다.

2단계: 코드 모듈형 구현 (Code-Modular Implementation)

특화된 코딩 에이전트들이 명시적인 인터페이스 계약(Interface Contracts, $IC_{\mathcal{T}}$ ) 하에 각 구성 요소를 별도로 구현합니다.

전처리 코더(Preprocessing Coder): 원시 데이터를 검증된 표현 형태( $\mathcal{D}'$ )로 변환하는 스크립트( $S_{prep}$ )를 생성하며, 이는 모델링 단계에서 요구되는 스키마를 엄격히 준수해야 합니다.
모델링 코더(Modeling Coder): 훈련 및 추론을 위한 스크립트( $S_{model}$ )를 생성하며, 검증된 $\mathcal{D}'$ 와 수학적 호환성을 보장합니다.
계약 기반 설계: 이러한 모듈성은 로직의 엉킴을 방지하고 구성 요소의 독립적인 개발 및 수리를 가능하게 합니다.

3단계: 코드 검증 통합 (Code-Verifiable Integration)

*어셈블러 에이전트(Assembler Agent)*는 $S_{prep}$ 와 $S_{model}$ 을 하나의 통합된 파이프라인( $S$ )으로 통합합니다.

동적 실행 및 검증: 시스템은 모델링 단계로 진행하기 전, 인터페이스 계약에 따라 데이터에 대해 $S_{prep}$ 를 실행하여 런타임 속성(형태, 타입)을 검증합니다.
반복적 디버깅: 실행에 실패할 경우, *에러 분석기(Error Analyzer)*는 런타임 트레이스백을 사용하여 오류(예: API 불일치, 텐서 형상 오류)를 국소화합니다. 이후 *디버깅 에이전트(Debugging Agent)*는 필요한 경우 웹 검색을 활용하여 최신 구문을 참조하며, 유효한 파이프라인을 얻을 때까지 특정 구성 요소를 반복적으로 수정합니다.

3. 주요 기여

새로운 설계 원칙: 본 논문은 이상적인 코드 기반 AutoML을 위한 세 가지 기준인 실행 가능성(신뢰할 수 있는 엔드 투 엔드 합성), 문제 기반(경험적 데이터 및 검색된 지식에 기반한 결정), 다양한/최신 탐색(이질적인 솔루션 트랙 간의 탐색)을 확립합니다.
$i$ ML 프레임워크: 경험적 프로파일링, 검색 기반 계획, 모듈형 코드 합성 및 동적 검증을 통해 이러한 원칙을 실행하는 멀티 에이전트 아키텍처를 제공합니다.
광범위한 실험적 검증: MLE-BENCH 및 새롭게 도입된 $i$ ML-BENCH(2021~2025년 사이의 16개 다양한 Kaggle 경진대회 포함)에 대한 포괄적인 평가를 통해 우수한 운영 신뢰성과 경쟁력 있는 성능을 입증했습니다.

4. 실험 결과

저자들은 $i$ ML을 전통적인 AutoML(AutoGluon) 및 코드 기반 에이전트(MLZERO, MLE-STAR, AutoML-Agent)를 포함한 최첨단 베이스라인들과 비교 평가했습니다.

MLE-BENCH (Lite)에서의 성능

신뢰성: $i$ ML은 90%의 유효 제출률을 달 기록하며, MLE-STAR(55%)와 AutoML-Agent(40%)를 크게 앞질렀습니다.
경쟁적 품질: 45%의 태스크에서 메달(Gold/Silver/Bronze)을 획득했으며, 80%의 "중앙값 이상(Above Median)" 달성률을 보였습니다.
성능 점수: 평균 성능 점수(APS)는 0.82로, LLM 기반 베이스라인 대비 52%~273%의 향상을 나타냈습니다

$i$ ML-BENCH에서의 성능

강건성: $i$ ML은 가장 높은 APS(0.54)를 기록하며, MLZERO(0.19)의 성능을 거의 3배 상회했습니다.
복잡한 태스크: AutoGluon 및 MLZERO와 같은 베이스라인이 복잡한 멀티모달 태스크(예: PetFinder, Multilabel Classification)에서 실패(0.00점)한 반면, $i$ ML은 높은 점수(각각 0.67 및 0.69)를 유지했습니다.
설명이 생략된 경우: 태스크 설명이 일반적인 프롬프트로 대폭 축소되었음에도 불구하고, $i$ ML은 70%의 성공률과 0.63의 APS를 유지하며 모호한 사용자 의도에 대한 회복력을 보여주었습니다.

절제 연구 (Ablation Studies)

실행 가능성: 동적 검증 또는 모듈형 통합을 제거하면 유효 제출률과 APS가 크게 하락하여, 정적 체크만으로는 불충분함을 확인했습니다.
그라운딩(Grounding): 경험적 데이터 프로파일링을 제거하면 APS가 0.82에서 0.66으로 감소하여, 데이터 그라운딩이 경쟁력 있는 품질의 주요 동력임을 입증했습니다.
탐색: $i$ ML을 단일 모델링 트랙(예: 전통적 ML만 사용)으로 제한하면 비정형 태스크에서 성능이 붕괴되었으며, 이는 다중 트랙 탐색의 필요성을 입증합니다.

5. 의의 및 주장

본 논문은 $i$ ML이 고수준의 전략적 추론과 경험적으로 검증 가능한 구현 사이의 간극을 메움으로써 강력한 AutoML 패러다임을 구축한다고 주장합니다.

그럴싸함보다 신뢰성: 텍스트적으로는 그럴싸하지만 취약한 코드를 생성하는 이전의 에이전트들과 달리, $i$ ML은 조립, 실행, 진단 및 수정의 폐쇄 루프 프로세스를 통해 실행 가능성을 강제합니다.
경험적 기반: 관찰된 데이터 속성과 검색된 지식에 계획의 근거를 둠으로써, 시스템은 런타임 실패를 초래하는 환각된 가정을 피합니다.
인간 수준의 경쟁력 있는 성능: $i$ ML은 커스텀 태스크별 파이프라인을 설계함으로써, 코드 기반 AutoML가 "블랙박스" 최적화 도구(AutoGluon 등)의 성능 천장을 초월할 수 있음을 보여줍니다.

저자들은 $i$ ML이 **신뢰할 수 있는, 인간과 경쟁 가능한 자율 공학(autonomous engineering)**을 향한 변혁적인 단계임을 결론지으며, 차세대 ML 시스템을 위한 검증 가능한 토대를 제공합니다. 또한 멀티모달 태스크에서의 성능은 향후 최적화를 위한 과제로 남아있으나, 본 프레임워크가 현재의 AutoML 에이전트들이 가진 로직 엉킴과 실행 신뢰성 문제를 성공적으로 해결했음을 밝히고 있습니다.