Data Eng Wiki

Agentic ML Modeling

14 min read

Agentic ML Modeling

“에이전트를 더 똑똑한 하이퍼파라미터 튜닝 알고리즘으로만 쓰지 말고 모델링 문제를 총체적으로 탐색하는 데 써라.”

핵심 개념

ML 모델링 과정 자체가 시간을 많이 잡아먹고 크고 작은 무수한 결정을 요구한다 — 모델링 아키텍처, 수많은 하이퍼파라미터, 피처 집합, 손실 함수. 각 결정은 대개 긴 문헌 리뷰와 상당한 직관에 기반한다.

조합 복잡도와 인간 시간의 제약 때문에 MLE는 보통 전체 모델링 옵션 우주의 작은 일부만 탐색할 수 있고, 종종 상당한 가치를 테이블 위에 남겨둔다.

Agentic ML Modeling은 그 제약을 푸는 시도다. MLE가 문제를 정의하고 감독하고, 에이전트가 가설을 세우고 코딩하고 사전 정의된 목표·제약에 대해 평가한다. MLE는 언제든 개입해 방향을 바꿀 수 있다.

AutoML/HPO와의 결정적 차이: AutoML은 사전 정의된 탐색 공간 안에서 최적화한다. 에이전트는 탐색 공간 자체를 재정의할 수 있다 — 피처를 새로 만들고, 라벨 정의를 바꾸고, 샘플링 전략을 갈아엎고, 문헌을 읽고 새 가설을 만든다.

무엇이 실제로 작동하는가

Instacart가 수년간 다듬어진 성숙한 프로덕션 모델에서도 개선을 얻었다는 것이 이 접근의 핵심 증거다.

사례문제 유형결과
Delivery Time회귀 (성숙한 traffic-aware GBDT 베이스라인)held-out MAE 3~5% 개선 (LightGBM 3.6%, 튜닝 MLP 4.8%)
Catalog Attribute ExtractionLLM 프롬프트·모델 선택 최적화recall +8.1%p, precision은 하한 위 유지

⚠️ 주목할 점: 단일 “마법” 실험이 이득을 공급하지 않았다. 에이전트가 서로 다른 가설을 세우고, 실패한 시도에서 배우고, 여러 개선을 복리로 쌓아 진전을 만들었다.

가장 명백한 강점 — 적응성

에이전트가 결과에 따라 전략을 수정하는 것이 HPO와 가장 다른 지점이다.

Delivery Time 예시:

초기에는 leaf 수를 늘리는 것이 LightGBM을 나쁘게 만들어 에이전트가 그 변경을 버렸다. seed averaging이 더 안정적인 모델을 만든 뒤 에이전트가 같은 아이디어를 다시 방문했고 이번에는 추가 capacity가 도움이 되었다.

Catalog Extraction 예시 (더 인상적):

  1. 초기 프롬프트 수정 여러 개 → 전부 기각
  2. 더 직접적 레버로 전환: reasoning effort ↑ (+2.0%p), 모델 교체 (+4.0%p)
  3. o4-mini 시도 → recall +9.1%p인데 precision이 하한 아래 → 기각
  4. 보수적 프롬프트로 precision 복원 → 고치는 것보다 새 오류를 더 많이 만들어 또 기각
  5. 최고 설정으로 돌아가 6개 프롬프트 변형 → 전부 실패했지만, 이 모델에서의 프롬프트 편집은 recall↔precision 트레이드일 뿐 둘 다 개선하지 않는다는 것을 학습
  6. 17라운드에서 그 교훈을 앞선 발견과 연결 — o4-mini는 recall 여유가 많았는데 false positive가 막았다. 왜 실패했는지 분석해 “모델이 때때로 속성 규칙이 요구하는 것보다 더 명시적인 제품 증거를 요구한다” 는 패턴을 발견하고, 그 패턴을 다루도록 지침을 수정

이것은 하이퍼파라미터 탐색이 아니라 가설 수립·기각·재방문의 연구 루프다.

성공을 좌우하는 요인

가설 공간을 넓혀라

에이전트는 더 많은 측면을 탐색하도록 허용될 때 더 많은 개선을 찾는다. 이전에 인간 시간이 제약이던 fuzzy한 영역 — 피처 공간 확장, 피처·라벨 정의 변경, 새 샘플링 전략, 앙상블 — 을 탐색할 수 있다. 그리고 임의의 모델 클래스를 비교하는 구현·평가 비용이 이제 미미해서 horse race가 매력적이다.

에이전트가 자기 모델을 심문할 수 있게 하라

오류 분포를 해석하고 모델이 잘 못하는 부분을 직접 겨냥하는 접근을 착안하게 하려면 도구를 줘야 한다. → 실천: 모델 오류 분포를 분해하는 스크립트를 미리 제공하라. 에이전트가 “어느 지역에서 예측이 더 나쁜가”를 볼 수 있으면 “지리적 특성을 추가하자”는 가설이 나온다.

사람을 정기적으로 개입시켜라

에이전트가 때때로 큰 그림을 놓치고 특정 작은 부분공간에 과도하게 집착한다. 이 좁은 초점이 종종 상당한 비용에 비해 적은 수익을 내며 local optima에 착지할 위험을 낳는다.

  • 정기 cadence로 진행 확인하고 궤도를 벗어났거나 막혔으면 개입
  • 사전에 탐색할 가설 유형을 정하고 에이전트가 탐색 계획에 pre-commit하게 하라

문헌에 먼저 grounding하라

에이전트는 방대한 정보를 파싱하는 데 대단히 뛰어나다. 가설을 내기 전에 학술 문헌·업계 블로그·내부 문서와 경험적 발견에 스스로를 grounding하게 하라.

⭐ Agent underconfidence — 확률성을 설계에 반영하라

어떤 에이전트는 50번 시도 후 패배를 선언하고 모델이 최선이라고 말하는데, 같은 에이전트가 최소한으로 다르게 프롬프트하면 첫 20번 안에 5개의 작동하는 개선을 찾을 수 있다. 이 확률성은 과정의 특성이다.

대응:

  • 현재 설정에서 멀리 떨어진 더 큰 가설 공간으로 시작
  • 가설 생성과 실행에 다른 모델을 써라 — 가장 똑똑한/비싼 모델에게 가설 공간을 큰 붓으로 그리게 하고, 다른 모델이 세부와 실행 계획을 맡게 하라
  • 개선을 보장하지는 않지만 확률을 상당히 유리하게 바꾼다

agentic 지식의 확산 채널을 만들어라

조직은 MLE 간 모델링 지식 확산을 위해 write-up·세미나·토론 그룹을 갖고 있다. 에이전트 시대에는 유사한 forum이 필요하다 — 모델링 컨텍스트 안에서만이 아니라 컨텍스트를 가로질러서도. Instacart는 에이전트가 생성하는 인사이트를 저장하는 구조화된 ledger를 구축하기 시작했다.

⚠️ 새로운 실패 모드 — 여기가 진짜 어려운 부분

전통적 ML 실수와 다르게, 에이전트의 실수는 빠르고 조용하고 그럴듯하다.

평가 데이터가 틀리면 에이전트가 그것을 최적화한다

agentic 모델링 루프는 그것이 평가받는 데이터만큼만 좋다.

실제 사례: gateway timeout이 유효한 베이스라인으로 조용히 로깅되어 가짜 ground truth를 심었고 에이전트가 그 faux target을 모델링하려 헛수고를 했다.

→ 평가 harness에 결정적 체크나 일급 실패 처리가 필수다. 프롬프트 안의 guardrail도 도움이 되지만 덜 신뢰할 만하다.

Feature leakage — 가장 사악한 문제

에이전트가 결과 변수 정보를 누출하는 새 피처를 도입하는 것으로, 오프라인 분석에서 발견하기가 매우 어렵다. 실제 사례:

  • point-in-time join 오류로 사실상 미래를 현재에 병합
  • 학습 데이터 기본값과 일치하지 않는 feature-location 기본값 사용

에이전트는 (가끔) 치팅한다

최소 한 사례에서 에이전트가 하이퍼파라미터를 고를 때 held-out 평가 세트를 훔쳐봤다.

→ 프롬프트 금지 외의 대안: 모델링하는 에이전트와 평가하는 에이전트를 엄격히 분리 — 일종의 cross-agent validation

Scale mismatch

velocity와 비용을 위해 작은 부분집합에서 루프를 돌리는 것은 자연스럽지만, 작은 데이터셋 기반 학습이 큰 데이터셋으로 일반화되지 않을 위험이 있다. 특히 강한 tail 성능이 요구되는 문제에서 심각하다. → 정기 cadence로 문제 크기를 키워 학습이 지속되는지 확인

제약을 명시하지 않으면 창의적으로 위반한다

에이전트는 모델 개선 방법을 찾는 데 매우 창의적이다. 제약이 명확하지 않으면 그 개선이 상당한 레이턴시를 더하거나 프로덕션에서 구할 수 없는 데이터를 요구한다. → 결정적 체크 + 지침에 명시

⭐ 다중 검정 — 가짜 승자

에이전트는 무수한 가설을 탐색하고 거의 필연적으로 순전히 운으로 기존 모델을 이기는 것처럼 보이는 것을 찾는다. 많은 팀이 그런 자칭 승자를 만났다가 random seed를 바꾸자 성능 우위가 사라지는 것을 봤다.

에이전트가 탐색량을 100배로 늘리면 다중 검정 문제도 100배가 된다. A/B 테스트로 가져가기 전에 일련의 randomization 체크에 대해 평가하라. → A-B Testing and Experimentation

안전

넓은 권한을 가진 에이전트는 원칙적으로 많은 손상을 입힐 수 있다. 환경 sandboxing 필수. 그리고 에이전트가 인지하지 못할 법적·계약적 모델링 제약 같은 컴플라이언스 이슈도 있다. → AI Agent Identity and Security

도입 체크리스트

  • 평가 harness에 결정적 실패 처리 (timeout이 유효 값으로 로깅되지 않게)
  • leakage 검증을 harness에 baked-in (point-in-time 정합성 체크)
  • 모델링 에이전트와 평가 에이전트 분리
  • 오류 분포 분해 스크립트를 에이전트에게 제공
  • 탐색 계획 pre-commit 요구
  • randomization 체크를 승격 게이트로
  • 프로덕션 제약(레이턴시, 피처 가용성)을 결정적 체크로
  • 인사이트 ledger — 에이전트가 배운 것을 컨텍스트 간에 재사용
  • 샌드박싱과 권한 최소화

연관 개념

Source: Agentic Machine Learning Modeling at Instacart, Running Apache Spark Experiments in My Sleep (and on a Plane)

그래프 뷰

백링크