▲

오래된 연구 아이디어에 Autoresearch 수행하기

 (ykumar.me)
2P by GN⁺ 2시간전 | ★ favorite | 댓글 1개
  • Autoresearch 시스템은 LLM 에이전트가 train.py를 반복 수정하며 성능을 개선하는 제약 최적화 루프 구조로, 가설 설정부터 평가까지 자동 순환을 수행함
  • 실험은 컨테이너 기반 샌드박스 환경에서 실행되어 네트워크 접근과 임의 코드 실행을 차단함
  • Ukiyo-eVG 데이터셋을 사용해 약 11,000장의 일본 목판화 이미지와 주석 정보를 학습에 활용, CLIP 기반 모델로 Mean Rank 34.30, R@5 약 53% 성능을 달성함
  • 주요 개선은 temperature 파라미터 완화(-113 Mean Rank) 와 하이퍼파라미터 튜닝(-30 Mean Rank) 으로, 하루 42회 실험 중 13회 커밋을 통해 54% 성능 향상을 기록함
  • LLM 에이전트는 명확히 정의된 탐색 공간에서는 효과적이지만, 구조 변경 단계 이후에는 불안정성이 커져 완전한 자율 연구에는 한계가 드러남

핵심 아이디어

  • Autoresearch는 LLM 에이전트를 중심으로 한 제약 최적화 루프 구조로, 에이전트가 train.py를 수정하며 평가 지표를 반복적으로 개선함
    • 에이전트는 program.md의 지침을 읽고, scratchpad.md를 작업 메모로 사용해 실험 과정을 기록함
  • 탐색은 여러 단계(phase) 로 구성되며, 초기에는 하이퍼파라미터 튜닝에서 시작해 소규모 구조 변경, 이후에는 제약을 최소화한 자유 탐색으로 확장됨
  • 전체 루프는 가설 설정 → 코드 수정 → 학습 → 평가 → 커밋 또는 되돌리기 → 반복의 순환 구조로 설계됨
  • 각 실험은 약 5분 내에 완료되도록 제한해 빠른 반복과 과적합 방지를 유도함
  • 에이전트는 시간 제한 내에서 train.py를 자유롭게 수정할 수 있음

  • 샌드박싱

    • 임의 코드 실행 위험을 방지하기 위해 컨테이너 환경에서 학습 루프를 실행하고 네트워크 접근을 차단함
    • run.sh가 전체 실험 흐름을 관리하며, Claude Code는 train.py와 program.md만 수정 가능
    • Python 직접 실행, pip 설치, 네트워크 접근, git push 등은 모두 제한됨
    • 관련 구현은 GitHub 저장소에서 공개됨

데이터셋

  • 원래 연구에서 사용된 의료 X-ray 데이터셋에 접근할 수 없어, Ukiyo-eVG 데이터셋을 새로 사용함
    • 약 11,000개의 일본 목판화 이미지와 문구-바운딩박스 주석을 포함
    • 바운딩박스를 가우시안 히트맵으로 변환해 모델 입력에 추가, 원래 eCLIP 논문의 전문가 주의(attention) 메커니즘과 유사한 방식 적용
  • 히트맵은 모델이 특정 영역에 집중하도록 유도함

Claude Code와의 실험 설정

  • Claude Code가 기존 연구 코드를 최신 Python 환경으로 업그레이드하고, 새 데이터셋 로딩 및 실험 루프 스캐폴딩을 작성함
  • 교차 검증 분할, 평가 로직, program.md의 초기 아이디어를 설정함
  • 평가 지표로 Mean Rank를 사용했으며, 최종 보고에는 Recall@K를 병행함
    • Mean Rank는 직관적 판단용으로 사용되었으나, 이상치에 덜 민감한 Median Rank가 더 적절했을 것으로 언급됨
  • 모델 구성: CLIP 백본은 ViT-Small(22M) + DistilBERT(66M) + HeatmapProcessor로 총 약 90M 파라미터
    • 학습: 800 스텝(약 3분/실험, RTX 4090 기준)
    • 평가: 1,000장 테스트 세트에서 Mean Rank 및 Recall@K 측정
    • 기준 성능: Val Mean Rank 344.68, img→txt R@1 17.2%, txt→img R@1 16.5%

실험 결과

  • 하루 동안 총 42회 실험, 그중 13회 커밋, 29회 되돌림 수행
    • Mean Rank가 344.68에서 157.43으로 54% 감소
  • 전체 데이터셋으로 최종 학습 시, 테스트 점수가 검증 점수보다 더 높게 나타남
    • 이는 짧은 800스텝 실험이 언더피팅 상태였음을 시사
  • 최종 테스트 성능: Mean Rank 34.30, img→txt R@5 53.0%, txt→img R@5 51.4%

주요 개선 포인트

  • Temperature clamp 수정 (-113 Mean Rank)

    • 코드 내 학습 가능한 temperature 파라미터가 2로 고정되어 있었는데, 에이전트가 이를 완화해 성능이 크게 향상됨
    • 전체 개선 중 가장 큰 단일 효과를 보임

  • Optuna++ (-30 Mean Rank)

    • 이후 개선은 주로 하이퍼파라미터 튜닝에서 발생
    • 투영 차원 증가 및 학습률 재조정으로 추가 30포인트 개선
    • 인간이 반복적으로 수행하는 지루한 작업을 에이전트가 더 빠르고 체계적으로 수행함

  • 수익 감소 구간

    • 4단계(구조 변경) 이후부터는 LLM의 가설 성공률이 급감
    • 주의 메커니즘 변경이나 대담한 아이디어(moonshot) 시도는 대부분 실패
    • 탐색 후반부에서는 무작위적 시도가 많았음

  • 샌드박스의 중요성

    • Claude Code가 가끔 권한을 잊고 잘못된 bash 호출을 시도하거나, 학습 대기 중 루프를 중단하는 등 불안정한 행동을 보임
    • 완전한 자율 실행에는 아직 한계가 있음

마무리 관찰

  • 전체 과정에서 초기 90%는 매끄럽게 진행, 마지막 10%는 많은 개입이 필요함
  • LLM 에이전트가 명확히 정의된 탐색 공간 내에서는 효과적으로 ML 연구를 수행할 수 있음
  • Autoresearch의 커밋-되돌리기 루프는 구조화된 탐색 전략으로 유용함
  • 그러나 미지의 영역으로 확장되면 최적화 루프가 불안정해짐
  • 실험당 한 번의 변경만 허용하는 제약이 대규모 아이디어 탐색에는 지나치게 엄격했을 가능성 있음
    • 향후에는 계획 단계 추가나 하위 에이전트(subagent) 도입이 개선 방향으로 제시됨
  • 실험 종료 후, Claude Code와의 협업은 일상으로 돌아가며 마무리됨

감사 표시

  • Ukiyo-eVG 데이터셋: 약 11K 일본 목판화 이미지와 문구-바운딩박스 주석 포함
  • Autoresearch: Andrej Karpathy의 원래 아이디어 기반
▲
GN⁺ 2시간전  [-]
Hacker News 의견들

  • 메인 링크가 느리면 archive.is 버전을 시도해볼 것을 제안함

  • 나는 종종 LLM을 이용해 기존 연구를 탐색하거나 문제를 다른 방식으로 생각해보는 데 사용함
    결과의 90%는 내 도메인에 맞지 않지만, 나머지 10%는 꽤 유용했음
    하지만 LLM이 추천한 모든 걸 실제로 시도하게 하는 에이전트를 두는 건 비용($$$)이 너무 큼
    추천 목록에는 종종 유지보수가 안 되는 니치 라이브러리가 많음
    반면, 회사의 “전문 컨설턴트”들도 비슷하게 터무니없는 제안을 하곤 해서, 차라리 에이전트가 그들을 대신 상대해줬으면 함

    • 에이전트의 가치는 사용자가 쉬는 동안 자동으로 실험을 반복할 수 있다는 점에 있음
      단, 한 번의 테스트가 빠를 때만 의미가 있음. 내 일에서는 테스트 하나에 반나절이 걸려서 밤새 돌리긴 어려움
    • 어떤 도메인에서 일하는지 궁금함
    • 나는 LLM이 기억하기 귀찮은 짧은 문장이나 틀려도 상관없는 부분에서 유용하다고 느낌
      MCP 서버나 AGENTS.md 같은 걸 세팅하는 사람들을 보면, 결국 LLM이 광고된 대로 작동하지 않는다는 증거 같음
      특정 워크플로우에 맞게 잘 튜닝하면 훌륭하지만, 그게 스케일할 수 있을지는 의문임
      막대한 자금이 훈련과 인프라를 떠받치지 않는다면 지속 가능한 비즈니스 모델이 될 수 있을까?
    • 비용이 문제일 수도 있음. 나는 Claude Code를 가볍게 쓰는데, Max 플랜에서도 토큰이 거의 안 떨어짐

  • “에이전트가 하이퍼파라미터 최적화 알고리즘처럼 행동했다”는 표현이 인상적이었음
    핵심은 program.md라는 시스템 프롬프트 파일 하나로, “train.py 개선 → 학습 실행 → 평가 → 결과 기록”을 반복하는 구조임
    나머지는 임의의 ML 모델일 뿐임

  • 작동 중인 코드를 LLM에 주고 버그 수정, 성능 측정, 테스트 커버리지 평가를 반복하는 방식이 우리 팀의 표준 접근법임
    반복마다 다른 모델을 쓰면 새로운 시각을 얻는 느낌이라 좋았음

    • 이 방식을 특정 언어나 프레임워크에 특화된 로컬 LLM 학습에 적용할 수 있을지 궁금함

  • “Autoresearch”가 왜 이렇게 화제가 됐는지 의문이었음
    AI/ML의 병목은 항상 데이터 품질이나 컴퓨팅 자원이라 생각했는데, 이게 그걸 개선하는지 모르겠음

    • 사실 이런 시도는 예전부터 있었음. AutoML 분야가 그 예인데, 실제로는 잘 안 됐음
      Bayesian 최적화나 Gaussian Process 같은 접근도 있었지만, 결국 랜덤 서치가 더 나았음
      LLM은 문헌을 보고 상식적인 추론을 할 수 있다는 점이 다름
      완벽하진 않지만, 기존 방법보다 나을 가능성은 있음
    • 단순한 하이퍼파라미터 튜닝을 넘어 비파라메트릭 구조 변경도 가능하다는 점이 다름
      완전히 새로운 개념은 아니지만, 덜 brute-force하길 기대하는 듯함
    • “Swarm optimization” 같은 기존 기법도 있지만, LLM은 과거 연구를 학습해 중요한 축에 집중할 수 있다는 점이 다름
      즉, 이미 누군가 한 연구를 LLM이 활용할 수 있음
    • “데이터나 컴퓨트가 병목”이라는 말엔 동의하지 않음
      ML의 핵심은 같은 입력 X로 더 나은 함수 매핑을 찾는 것임
      단순히 컴퓨트를 늘린다고 해결되지 않음
    • 결국 Autoresearch는 생각 자체를 LLM에 위임하는 방식임

  • 결과적으로는 작동했음. LLM이 버그를 찾고 최적화도 수행했음

    • 하지만 실제로는 대부분의 개선이 버그 수정 + Optuna 튜닝 덕분이었음
      이런 건 Claude Code로도 금방 할 수 있음
      Autoresearch의 진짜 가치는 아키텍처 탐색에 있을 듯함
      누가 탐색적 모델링에 써본 경험이 있는지 궁금함

  • 커밋 로그(GitHub 링크)를 보니 대부분이 하이퍼파라미터 튜닝이었음
    그 정도면 토큰 비용($$$)이 아깝다고 느낌

    • Autoresearch에 비용 추정 및 정렬 단계를 추가해 사람이 검토 후 실행하도록 하면 효율적일 듯함
      LoRa 어댑터로 비용 피드백을 주는 식으로 개선 가능함
    • 사실 Optuna나 skopt 같은 오픈소스 툴로 GPU 없이도 가능함

  • 원 논문에서는 의료 X-ray 데이터를 썼지만, 접근 권한이 없어 Ukiyo-eVG(일본 목판화 11K장)로 대체했다고 함
    이상한 전환처럼 보였음. 무료 의료 이미지 데이터는 Cancer Imaging Archive에도 많음

    • 맞는 말임. 다만 의료 데이터를 에이전트에 맡기기엔 부담스러웠고, 도메인 전이를 실험해보고 싶었음

  • 누군가 이런 실험을 하길 바랐는데, 실제로 해줘서 반가웠음
    “훈련이 끝나길 기다리다 지쳐 대화를 종료했다”는 부분이 웃겼음
    결과 공유에 감사함

    • 고마움, 즐겁게 읽었다는 답변을 남김

  • 이건 자동화된 연구라기보다 구조화된 시행착오에 가까움
    결국 핵심은 평가 지표의 품질임. 그게 약하면 잘못된 방향으로 더 빨리 최적화할 뿐임

    • 좋은 피트니스 함수 설계는 예나 지금이나 어려운 일임
    • 결국 그게 바로 과학적 방법론 아닌가 하는 의견도 있음
답변달기