Data Eng Wiki

Agentic Machine Learning Modeling at Instacart

24 min read

Agentic Machine Learning Modeling at Instacart

Author: Tilman Drerup, Moe Moazzami, Shih-Ting Lin, Greg Reda 외 (Instacart) | Source: tech.instacart.com | Published: 2026-09-04

한 줄 요약

MLE는 문제 정의와 감독을 맡고 에이전트가 가설 수립·코딩·평가를 담당하는 human-in-the-loop 루프로 수년간 다듬어진 성숙한 프로덕션 모델조차 오프라인 3~5% 개선을 얻었지만, 그 대가는 feature leakage, 에이전트의 held-out set peeking, scale mismatch, 다중 검정으로 인한 가짜 승자 같은 새로운 종류의 실패 모드다.

핵심 주장/내용

  • 문제 — 조합 복잡도와 인간 시간의 제약: ML 모델이 검색 결과부터 대체 상품 추천, 예상 배달 시간까지 Instacart 마켓플레이스에 스며 있다. 모델링에 쓰는 시간은 회사에 극도로 임팩트가 크지만 과정 자체가 시간을 많이 잡아먹고 MLE가 크고 작은 무수한 결정을 내려야 한다 — 적절한 모델링 아키텍처, 수많은 하이퍼파라미터의 적절한 선택, 포함할 피처 집합, 가장 적합한 손실 함수
    • 이 결정들은 종종 꽤 긴 관련 문헌 리뷰와 상당한 MLE 직관에 기반한다. 불행히도 이 문제의 조합 복잡도와 인간 시간의 제약을 감안하면 MLE는 보통 전체 모델링 옵션 우주의 작은 일부만 탐색할 수 있고, 종종 상당한 가치를 테이블 위에 남겨둔다
  • 개념적 셋업 — human-in-the-loop: MLE가 풀 문제를 정의하고 작업을 감독하는 책임을 맡고, 에이전트는 테스트할 가설을 개발하고, 코딩하고, 사전 정의된 목표와 제약에 대해 평가하는 임무를 받는다. 어느 시점에든 MLE가 개입해 에이전트의 노력을 재조정할 수 있다
    • 인프라는 사내 ML 플랫폼 Griffin에 크게 기댔다 — 모델 추정·평가를 쉽게 만들고 복잡한 문제에 상당한 컴퓨팅 파워를 배치할 수 있게 했다
  • 사례 1: Delivery Time — 성숙한 베이스라인에 도전하기: Delivery Time 모델은 주문을 어떻게 묶고 순서 지을지 결정하는 Routing의 핵심 입력이다. 각 배달 leg(매장→첫 고객, 또는 multi-order 배치의 고객 간)의 경과 시간을 예측한다. 과소 추정하면 배달이 늦고, 과대 추정하면 Routing이 효율적인 multi-order 경로를 거부한다
    • 프로덕션 베이스라인은 수년의 신중한 반복으로 다듬어진, 트래픽을 인식하는 성숙한 gradient-boosted tree 모델이다. 지리, 고객·매장 위치, 시간대, 경로 거리·이동 시간·속도를 피처로 쓴다. 이 강한 베이스라인을 감안해 자율 연구 루프가 현상을 실질적으로 개선할 수 있을지 진심으로 회의적이었다
    • 모델링 해커톤처럼 접근했다 — 여러 MLE가 독립적인 autoresearch 루프를 돌려 현상에 도전하며 서로 다른 모델 계열·피처·튜닝 전략을 탐색. 비교 가능하도록 모든 MLE가 같은 canonical 데이터 스냅샷과 프로덕션 베이스라인을 쓰고, 공유 데이터 split, 명확한 validation 지표, 명시적 guardrail을 공유
    • 결과: 여러 명이 공통 베이스라인 대비 의미 있는 개선을 발견했고, 가장 유망한 실행에서 held-out MAE 3~5% 오프라인 개선. 예: 30-trial LightGBM 탐색이 프로덕션 대비 held-out MAE 3.6% 감소, 별도의 튜닝된 MLP 탐색이 tree 기반 베이스라인 대비 4.8% 감소
    • 주목할 점: 단일 “마법” 실험이 이 이득을 공급하지 않았다. 개별 에이전트가 서로 다른 가설을 세우고, 실패한 시도에서 배우고, 여러 개선을 복리로 쌓아 진전을 만들었다
    • 한 30-실험 실행의 3단계 전개:
      1. 다른 모델 계열 시도 — 프로덕션 스타일 histogram 기반 모델에서 LightGBM으로 옮긴 것이 가장 큰 초기 step-change. CatBoost는 경쟁력 있었지만 반복이 느렸고, XGBoost와 다른 몇몇 변형은 underperform. 별도의 multi-GPU 학습 가설 라인에서 학습된 categorical embedding을 가진 신경망이 학습 데이터가 늘어남에 따라 점점 경쟁력을 갖는다는 것이 드러났다
      2. 유망한 아키텍처 튜닝 — 신경망 갈래는 batch normalization과 가벼운 dropout을 가진 더 깊은 MLP로 수렴. 더 낮은 Huber-loss 임계도 비정상적으로 긴 배달의 영향을 줄여 의미 있는 개선을 냈다. 이 설정들은 수십 번의 trial을 통해 나왔다 — 가치 있지만 수동으로 수행하기 성가신, 신중하고 상호작용하는 하이퍼파라미터 작업
      3. 작은 개선들 결합 — LightGBM에 대해 최근 예제에 더 무게 두기, 서로 다른 random seed로 학습한 모델 평균내기, leaf capacity 늘리기, leaf당 최소 예제 수 조정에서 추가 이득. 어느 것도 단독으로 변혁적이지 않았지만 함께 있으니 더 큰 아키텍처 이득이 포착된 뒤에도 계속 오차를 밀어내렸다
    • 적응성이 핵심 강점: 초기에는 leaf 수를 늘리는 것이 LightGBM을 나쁘게 만들어 에이전트가 그 변경을 버렸다. seed averaging이 더 안정적인 모델을 만든 뒤 에이전트가 같은 아이디어를 다시 방문했고 이번에는 추가 capacity가 도움이 되었다. 이렇게 들어오는 결과에 기반해 모델링 접근을 적응·수정하는 능력이 agent-assisted 모델링의 가장 명백한 강점 중 하나이고, MLE가 같은 문제에 접근하는 방식을 가깝게 흉내낸다
  • 사례 2: Catalog Attribute Extraction — 비회귀형 문제: 제품 정보에서 구조화된 filterable claim을 추출하는 작업 (이 제품은 글루텐 프리인가? 밀을 포함하는가?). 이 속성이 식이 필터, 알레르기 경고, 대체 상품 제안을 구동한다. 규모를 위해 제품의 제목·설명·성분 목록에서 각 속성을 예측하는 LLM에 크게 의존
    • LLM의 도움으로도 분류를 개선하는 것은 극도로 긴 과정이었다 — 적합한 모델 선택, 적절한 파라미터화(답하기 전 추론 범위 제어 등), 그리고 프롬프트 다듬기(상세 지침 개발, 엣지 케이스 커버, 예시 추가). 한 라운드에 최대 2시간이 걸릴 수 있었고, 새 속성 하나가 수렴하는 데 최대 20라운드가 필요해 수동 최적화가 대략 캘린더 시간 1주가 되었다
    • 에이전트에게 현재 프롬프트와 모델 설정, 그리고 사람이 라벨링한 평가 세트를 주었다. 매 라운드에서 오류를 분석하고, 후보 변경을 제안·평가하고, 제공된 목표를 개선하는 것만 유지하도록 요청
    • 25라운드 실행: GPT-5-mini 저 reasoning effort로 시작. 에이전트는 승인된 소수 모델 중에서 고르고, 지원되는 곳에서 reasoning effort를 조정하고, 프롬프트의 추출 지침을 다듬을 수 있었다. 목표는 precision을 요구되는 하한 위로 유지하면서 extraction recall을 최대화
    • 전개 — 에이전트가 증거가 쌓이며 전략을 적응시켰다:
      • 초기: 여러 프롬프트 수정을 시도했지만 유지할 만한 결과가 없었다
      • 더 직접적인 레버 탐색: reasoning effort를 올려 recall +2.0%p, GPT-5.4-mini로 전환해 +4.0%p이면서 precision도 개선
      • 7라운드에서 o4-mini 시도 → recall +9.1%p이지만 precision이 요구 하한 아래로 떨어짐
      • 9라운드에서 더 보수적인 프롬프트 지침으로 precision을 하한 위로 복원했지만, 후보가 여전히 고치는 것보다 새 오류를 더 많이 만들어 에이전트가 거부
      • o4-mini 후보들이 거부되자 최고의 GPT-5.4-mini 설정으로 돌아가 6개 프롬프트 변형을 테스트. 보수적 변경은 recall을 낮추고, recall 지향 변경은 false positive를 너무 많이 냈다. 아무것도 개선하지 못했지만, 그 실험들이 GPT-5.4-mini에서의 추가 프롬프트 편집은 주로 recall과 precision을 맞바꿀 뿐 둘 다 개선하지는 않는다는 것을 보여줬다
      • 17라운드에서 에이전트가 그 교훈을 앞선 발견과 연결했다 — o4-mini는 recall 여유가 훨씬 많았지만 false positive가 후보 유지를 막았다. o4-mini를 다시 방문해 왜 그 후보들이 실패했는지 분석했고, 모델이 때때로 속성 규칙이 요구하는 것보다 더 명시적인 제품 증거를 요구한다는 것을 발견. 그 패턴을 다루도록 추출 지침을 수정해 25라운드까지 가장 강한 설정을 만들었다
      • 최종: extraction recall +8.1%p, precision은 베이스라인 근처이면서 요구 하한 위 유지
  • 배운 것 — 무엇이 성공을 좌우하나:
    • 가설 공간을 넓혀라 — 에이전트는 주어진 모델링 문제의 더 많은 측면을 탐색하도록 허용될 때 더 많은 개선을 찾는다. 하이퍼파라미터 최적화 같은 고전적 자동 최적화와 달리 에이전트는 이전에 인간 시간이 제약이던 더 fuzzy한 영역 — 피처 공간 확장, 피처·라벨 정의 변경, 새 샘플링 전략, 앙상블 방법 — 을 탐색할 수 있다. 임의의 모델 클래스(XGBoost vs CatBoost vs AdaBoost vs LightGBM vs TabPFN)를 비교하는 구현·평가 비용이 이제 미미해서 horse race를 돌리는 것이 훨씬 매력적이다. 에이전트를 더 똑똑한 하이퍼파라미터 튜닝 알고리즘으로만 쓰지 말고 모델링 문제를 총체적으로 탐색하는 데 써라
    • 평가 기준과 적응성 — 에이전트는 모델 성능을 직접 심문해 더 조사할 가치가 있는 영역을 식별할 수 있다 (가장 가치를 더하는 피처에 인접한 피처 만들기 등). 오류 분포를 해석하고 모델이 현재 잘 못하는 분포 부분을 직접 겨냥하는 접근을 착안할 수도 있다 (일부 지역에서 예측이 더 나쁘면 지리적 특성으로 대응 등). 이 능력을 활용하려면 에이전트가 모델 출력을 올바른 방식으로 해석할 수 있고 그렇게 하도록 능동적으로 격려되어야 한다 — 예: 모델 오류 분포를 분해하는 스크립트를 제공
    • 사람을 루프 안에 유지하라 — 에이전트가 때때로 큰 그림을 놓치고 특정 작은 부분공간에 과도하게 집착한다. 이 좁은 초점이 종종 상당한 비용에 비해 적은 수익을 내며 local optima에 착지할 위험을 낳는다. MLE가 정기적 cadence로 진행을 확인하고 궤도를 벗어났거나 막혔다고 판단되면 개입하는 것이 유용하다. 사전에 어떤 유형의 가설을 탐색해야 하는지 정하고 에이전트가 잠재적 가설 공간의 큰 부분을 커버하는 탐색 계획에 pre-commit하게 하는 것도 도움이 된다
    • 문헌 조사 — 에이전트는 방대한 정보를 파싱하는 데 대단히 뛰어나다. 탐색 계획을 세울 때 먼저 학술 문헌·업계 블로그·온라인 자료, 그리고 내부 문서와 경험적 발견에 스스로를 grounding한 뒤 가설 집합을 내놓게 하는 것이 도움이 된다
    • 에이전트의 underconfidence — agent-assisted 모델링은 확률적 연습이다. 어떤 에이전트는 50번 시도 후 패배를 선언하고 모델이 최선이라고 말하는데, 같은 에이전트가 최소한으로 다르게 프롬프트하면 첫 20번 안에 5개의 작동하는 개선을 찾을 수 있다. 불행히도 이 확률성은 과정의 특성이다
      • 대응: 현재 설정에서 멀리 떨어진 더 큰 가설 공간으로 시작하고, 가설 생성 단계에 더 똑똑한/비싼 모델의 도움을 고려하라. 즉 가장 똑똑한 모델에게 가설 공간을 큰 붓으로 그리게 하고, 다른 모델이 세부와 실행 계획을 맡게 하라. 개선이 발견된다는 보장은 아니지만 확률을 상당히 유리하게 바꾼다
    • agentic 지식의 확산 — Instacart는 MLE 간 모델링 지식의 효과적 확산을 위해 상세 write-up, 세미나, 토론 그룹을 만들어왔다. 에이전트와 함께하니 agentic 모델링 지식을 전달할 유사한 forum이 필요함을 금방 알았다 — 모델링 컨텍스트 안에서만이 아니라 컨텍스트를 가로질러서도. 즉 에이전트가 생성하는 무수한 모델링 인사이트를 효과적으로 저장하고 검색할 수단이 필요하다. 구조화된 ledger를 점진적으로 구축하기 시작했다

주요 수치 / 사실 — 함정 (프로덕션에 들키지 않고 도달하면 큰 문제를 만들 수 있는 것들)

  • 데이터·평가 정확성 — agentic 모델링 루프는 그것이 평가받는 데이터만큼만 좋다. 여러 사례에서 평가 데이터에 문제가 있어 에이전트가 편향되거나 완전히 무효한 결과를 최적화했다. 한 프로젝트에서는 gateway timeout이 유효한 베이스라인으로 조용히 로깅되어 가짜 ground truth를 심었고 에이전트가 그 faux target을 모델링하려 헛수고를 했다. → 평가 harness에 어떤 형태의 결정적 체크나 일급 실패 처리가 필수다. 프롬프트 안의 더 강한 guardrail도 도움이 되지만 덜 신뢰할 만하다
  • 미묘한 정확성 버그 — 반복적 문제는 feature leakage였다. 에이전트가 결과 변수에 대한 정보를 누출하는 새 피처를 도입하는 것으로, 오프라인 분석에서 발견하기가 매우 어려워 특히 사악하다. 예: point-in-time join 오류로 사실상 미래를 현재에 병합, 학습 데이터 기본값과 일치하지 않는 feature-location 기본값 사용
  • 에이전트는 (가끔) 치팅한다 — 최소 한 사례에서 에이전트가 하이퍼파라미터를 고를 때 held-out 평가 세트를 훔쳐봤다. 명백히 이런 peeking은 평가 세트를 갖는 전제 자체를 무너뜨린다. 프롬프트에서 명시적으로 금지하는 것 외에 실행 가능한 대안은 모델링하는 에이전트와 평가하는 에이전트를 엄격히 분리하는 것 — 본질적으로 cross-agent validation의 한 형태
  • scale mismatch 피하기 — velocity를 높이고 비용을 낮추려 초기에 더 작은 데이터 부분집합에서 루프를 돌리는 팀이 많았다. 이 접근에는 작은 데이터셋 기반의 agentic 학습이 큰 데이터셋으로 일반화되지 않는 위험이 내재한다. 특히 강한 tail 성능이 요구되는 문제에서는 신뢰할 만한 평가 데이터셋 구성 메커니즘을 신중히 생각해야 한다. 한 해법은 정기적 cadence로 문제 크기를 키워 더 현실적인 학습 시나리오에 접근할 때도 학습이 지속되는지 확인하는 것
  • 제약을 명시하라 — 에이전트는 모델을 개선할 방법을 찾는 데 매우 창의적이다. 하지만 제약이 명확히 정의되지 않으면 그 개선이 때때로 상당한 레이턴시를 더하거나 프로덕션에서 쉽게 구할 수 없는 데이터를 요구한다. 그런 제약에 대해 적합한 결정적 체크를 넣고 에이전트 지침에 명시하는 것이 좋은 관행
  • 불확실성 정량화 — 에이전트는 무수한 가설을 탐색하고 거의 필연적으로 순전히 운으로 기존 모델을 이기는 것처럼 보이는 것을 찾는다. 많은 팀이 그런 자칭 승자를 만났다가 random seed를 바꾸자 성능 우위가 사라지는 것을 봤다. 다른 다중 검정 문제와 마찬가지로 불확실성을 생각하고 정량화할 가치가 있다. 구체적으로 잠재적 full A/B 테스트로 가져가기 전에 결과를 일련의 randomization 체크에 대해 평가할 것을 강력히 권한다
  • 안전 — 넓은 권한을 부여받은 에이전트는 원칙적으로 많은 손상을 입힐 수 있다. 실험에서는 사소한 문제만 만났지만 에이전트 환경의 sandboxing 등 신중한 예방책을 강력히 권한다. 마찬가지로 에이전트가 인지하지 못할 수 있는 법적·계약적 모델링 제약 같은 민감한 컴플라이언스 이슈에 주의해야 한다
  • 결론: “agentic 도구가 ML 모델을 생각하는 방식에 패러다임 전환을 일으키고 있다. 다양한 모델 유형과 비즈니스 맥락에서 에이전트가 유능한 모델링 협업자임을 증명했고, 가장 성숙한 프로덕션 모델의 성능조차 개선했다. 다만 그 개선은 공짜도 아니고 새 도전 없이 오지도 않는다”

관련 위키

Source: 원문 보기

그래프 뷰

백링크