Karpathy의 Autoresearch: 두 시간 만에 인간 수준 점수에 도달한 AI 연구 에이전트

원본: https://www.youtube.com/watch?v=9jxrmk_Xses · 업로드: 2026-03-10 · 길이: 14m · 채널: Onchain AI Garage

서론

지난 금요일 Andrej Karpathy가 트윗으로 공개한 Autoresearch 레포가 꽤 많은 관심을 받았다. 그가 직접 돌려 본 작은 실험으로, 요지는 간단하다. nanochat 수준의 작은 LLM을 AI 에이전트가 스스로 훈련하게 시킨다.** Karpathy는 OpenAI 공동 창업자이자 AI 분야에서 가장 이름이 알려진 사람 중 한 명이라, 이 트윗이 주목을 받은 건 자연스럽다. 다만 포스트에 담긴 내용을 정확히 이해하고 있는 사람은 많지 않았다. 사실 나도 전부 알고 있지는 않았다.

주말 동안 조금 파 봤고, 지금은 설명할 수 있을 만큼은 감이 잡혔다. 직접 실험도 해 봤다. 그의 레포를 클론해서 내 노트북에서 돌려 봤다. 오늘 영상에서는 Autoresearch가 무엇인지, 왜 중요한지 정리하고, 여러분이 직접 돌려 볼 수 있는 방법을 보여 주고, 내가 얻은 결과를 공유한다. 결과는 꽤 놀라웠으니 끝까지 봐 주면 좋겠다.

왜 이게 중요한가

이건 장난 실험(toy experiment)이 아니다. Karpathy 본인의 표현을 빌리면, 모든 LLM 프런티어 랩(frontier lab)이 결국 이걸 하게 된다. 최종 보스 배틀(final boss battle)이다. Autoresearch가 의미하는 건 이거다 — AI 에이전트에게 머신러닝 연구자의 일을 통째로 시키는 것. 가설을 세우고, 실험을 돌리고, 유지할 결과와 버릴 결과를 판단하고, 작동한 것 위에 다음을 쌓는다.

Karpathy 본인은 이 작업을 20년간 수동으로 해 왔는데, 이제는 AI 에이전트가 자율적으로 하고 있다. 이 방식이 널리 쓰이게 되면 연구 방식 자체가 바뀔 것이다.

짧은 기초: 언어 모델이 하는 일

배경 하나만 짚고 가자. 언어 모델은 다음에 어떤 단어가 올지 예측한다. 그게 전부다. ChatGPT도 한 단어씩, 이걸 계속 반복하는 것뿐이다. 잘 예측하려면 수백만 개의 예시에서 패턴을 학습해야 한다. 예측이 정확할수록 언어를 더 잘 이해한다고 볼 수 있다. 나쁜 모델은 무작위에 가깝게 찍고, 좋은 모델은 사람처럼 찍는다.

훈련 과정은 단순하다. 모델에 예시를 보여 주고, 예측이 얼마나 틀렸는지 측정하고, 가중치를 조금씩 조정한다. 이걸 수백만 번 반복한다.

Autoresearch가 하는 일

Karpathy가 공개한 오픈소스 도구인 Autoresearch의 동작은 이렇다. 아주 작은 LLM이 program.md를 읽고, 가설을 세우고, 훈련 코드를 수정하고, 5분간 훈련을 돌리고, 결과를 측정하고, 유지할지 버릴지 결정한 뒤 반복한다.

사람이 쓰는 유일한 파일은 program.md — 연구 계획서다. 에이전트가 수정할 수 있는 유일한 파일은 train.py 하나다. 이 파이썬 스크립트가 모델 설정·코드를 모두 담고 있어서, 에이전트가 무엇을 실험할 수 있는지를 사실상 결정한다.

핵심 지표: val_bpp (낮을수록 좋다)

핵심 개념 몇 가지만 짚자. 중심 지표는 val_bpp다. 숫자가 낮을수록 좋다. 모델이 텍스트 예측에 대해 얼마나 확신 있고 정확한지를 나타낸다.

• 2 정도: 거의 무작위 추측 수준
• 1.17: 내가 시작했을 때 얻은 베이스라인 — 추측보다 약간 나은 정도
• 0.5: 인간 수준의 예측 성능

데이터셋: Tiny Stories

이번 실험은 내 노트북 GPU에서 돌렸기 때문에, 데이터셋도 Karpathy 본인이 만든 Tiny Stories를 썼다. 이름 그대로 아주 단순한 아이들 동화다. “Once there was a little boy named Jack. He was only three years old and had lots of things he wanted to do.” 이런 식의 쉬운 문장들로 구성돼 있다. 내 중급 노트북 GPU에서 할 수 있는 최선이었다.

Karpathy 본인은 Tiny Shakespeare를 썼을 것이다. 훨씬 복잡한 텍스트지만, 그는 NVIDIA H100이라는 훨씬 강력한 칩에서 돌리고 있었으니 가능한 일이다.

직접 돌리는 법

1. 먼저 Autoresearch 레포(GitHub)를 방문한다. 원본 레포를 그대로 클론해도 H100이 없으면 제대로 돌아가지 않는다. 그래서 Karpathy가 Mac, Windows 같은 환경별 포크(fork)를 추천해 놨다. 내 경우는 RTX가 달린 Windows 노트북이라 autoresearch-win-rtx 포크를 썼다. 레포 하단에 본인 머신에 맞는 포크가 있는지 확인하면 된다. 추천 데이터셋은 Tiny Stories.
2. git clone으로 포크를 받는다.
3. 그 디렉터리로 들어가 uv sync로 의존성을 설치한다.
4. prepare.py로 훈련 데이터(Tiny Stories)를 다운로드한다.
5. 연구 계획서 program.md를 쓴다. 레포 기본값은 기본 규칙과 가이드라인을 담고 있고, “experimentation” 섹션에서 원하는 내용을 추가하면 된다.

기본 프롬프트와 내가 추가한 5단계

기본 프롬프트의 목표는 단순하다: val_bpp 점수를 최대한 낮춰라. 규칙은 매우 느슨하다 — 아키텍처, 옵티마이저(optimizer), 하이퍼파라미터, 배치 크기, 모델 크기 전부 자유롭게 바꿔도 된다.

내가 추가한 5단계 연구 계획은 다음과 같다.

• Phase 1: vocab 크기 스윕(vocab size sweep). 다섯 가지 크기를 테스트해 최적값 찾기.
• Phase 2: 최소 생존 모델(minimum viable model). 깊이(depth)를 얼마나 얕게 줄일 수 있는지 확인.
• Phase 3: 옵티마이저 실험. 다양한 조합 탐색.
• Phase 4: 가설 주도 실험(hypothesis-driven). 에이전트가 스스로 이론을 쓰고 자유롭게 탐색. 대부분의 시간을 여기에 썼다.

용어 간단히 정리:

• Depth: 모델의 처리 단계(processing stage) 수. 기본 8에서 시작해 에이전트가 6, 4, 3, 2를 시도했다.
• Vocab size: 모델이 아는 고유 단어 조각(word piece)의 수. 너무 작으면 뉘앙스를 표현 못 하고, 너무 크면 학습이 어려워진다.
• Batch size: 모델이 자기를 조정하기 전에 보는 예시의 개수. 작을수록 갱신 빈도가 높고, 단순 데이터에서는 학습이 빨라진다.

계획은 평범한 영어로만 쓴다. 코드는 필요 없다. 여러분의 AI 연구자에게 지시를 쓰는 것과 같다.

실행

program.md가 준비되면 그냥 실행한다. 나는 Claude Code로 돌렸다. Claude에게 program.md와 코드베이스를 가리키기만 하면 알아서 루프를 돈다. (Codex로는 일부 문제가 있었지만, Claude는 문제없었다.) 사용자 입력 없이, 얻은 결과를 기반으로 계속 스스로 반복한다.

몇 시간 돌려서 어떤 결과가 나오는지 지켜봤고, 전부 자동으로 로그가 남았다.

실행 환경과 결과

내 노트북은 작년에 산 RTX 4060에 VRAM 8GB짜리 중급 기기다. 레포에서 지원한다고 명시된 칩 중 하나라 바로 돌아갔다.

진행 과정

시작 베이스라인은 1.173 — 추측보다 약간 나은 수준이라 좋지 않다. 그런데 에이전트가 꽤 빠르게 올바른 방향을 찾아냈다.

• vocab size를 512로 올렸을 때 소폭 개선
• vocab size를 4096으로 올렸을 때 큰 점프
• depth를 바꿀 차례가 되자, 놀랍게도 depth 3에서 훨씬 더 낮은 점수가 나왔다

왜 깊이를 줄이는 게 더 나았을까? 데이터셋이 Tiny Stories라 그렇다. 이야기가 워낙 단순해서 처리 단계가 많아지면 복잡도만 늘고 이득은 없었다. 작은 데이터셋에 맞는 작은 모델이 더 낫다는 흔한 교훈이지만, 에이전트가 스스로 그걸 발견했다는 점이 중요하다.

배치 크기도 많이 도움이 됐다. 배치가 작을수록 더 자주 갱신이 일어나고, 단순 데이터에서 점수가 계속 개선됐다.

마지막 단계에서는 작은 개선들이 쌓였다. 이 시점에는 눈에 띄는 큰 진전은 없었지만, 에이전트가 계속 새 가설을 쓰면서 소폭의 개선을 누적시켰다.

최종 결과

시작 1.173 → 최종 0.511. 반나절 정도 걸렸다. 정확히는 이 수준에 빠르게 도달했고, 마지막 몇 시간은 세밀한 조정에 쓴 것이다.

56% 예측 정확도 개선이고, 인간 수준(0.5)에 거의 도달한 결과다. 이 데이터셋에서 인간 수준은 0.5이고 우리는 0.51을 얻었다.

Karpathy 본인의 결과

Karpathy는 자신의 모델에서 이걸 돌렸고, 이렇게 말했다.

“에이전트가 이 전체 워크플로를 끝에서 끝까지, 전부 혼자서, 약 700개의 변경을 자율적으로 처리해 나가는 걸 보는 건 놀랍다. 실험 결과의 시퀀스를 실제로 보고, 그걸 써서 다음 실험을 계획했다.”

그는 자신의 역할에서 에이전트가 수년간 놓쳤던 버그들을 찾아냈다고 했다. 잘못된 옵티마이저 베타(optimizer betas), 빠진 정규화(regularization), 너무 분산된 어텐션(attention). 그리고 11% 빠른 훈련 속도까지 얻었다.

생성 샘플: 시작과 끝

최종적으로 얼마나 달라졌는지 생성 샘플로 비교하면 가장 와닿는다.

베이스라인(0 훈련 상태):

“Once upon a time, a little boy named Whiskers, there was a big tree. They tried to play near the shop. One day, he asked, That means that? Her dad smiled, and Wally’s a big bear, do not have a lesson. But she said, I can have fun.”

말 그대로 헛소리다. 무슨 일이 벌어지는지 알 수가 없다.

최적화 후:

“Once upon a time, there was a little girl named Lucy. She loved to dance and play with her friends. One day, Lucy and her friends decided to have a race in the park. Lucy was very competitive. She wanted to win a prize. Her friends said, I know you can be the best.”

완벽하진 않지만 꽤 좋다. 문법이 맞고, 일관된 등장인물이 있고, 이야기가 이어진다. 겨우 몇 시간의 훈련 끝에 이 거대한 개선을 이뤄 냈다.

무엇이 차이를 만들었나

• Depth가 가장 큰 요인
• Batch size와 vocab size가 그 다음
• 그 외 몇 가지 작은 요인들

중요한 건, 이 중 어느 것도 자명하지 않았다는 점이다. 에이전트가 실험을 돌리고 결과를 보고 추론해서 찾아냈다. 사람 연구자가 하는 것과 똑같은 방식인데, 사람이 아닌 AI가 한 것이다.

이건 데스크에 있는 연구실이다

이것이 바로 “자기를 스스로 돌리는 AI 연구”다. 랩에서 H100으로 돌아가는 게 아니라, 여러분 책상 위 노트북에서, API 호출 몇 번 정도의 비용으로, 밤새 돌아간다. 이것이 연구의 미래이고, 오늘 돌려 볼 수 있다. 개인적으로 흥분되는 지점이 바로 이것이었다 — 중급 노트북으로 실제 모델을 훈련시키고 실제 결과를 봤다는 것. 물론 사람들은 더 강력한 하드웨어에서 더 놀라운 결과를 얻고 있다.

Karpathy의 표현을 그대로 다시 — “모든 LLM 프런티어 랩이 결국 이걸 하게 된다. 최종 보스 배틀이다.”

다음 단계: 에이전트 스웜

Karpathy가 오늘 이어진 후속 트윗에서 언급한 다음 방향은 에이전트 스웜(agent swarm) 이다. 병렬로 협력하는 여러 AI들이 있고, 가장 좋은 아이디어들이 더 큰 모델로 “승격(promote)“되는 구조다. 그가 지금 작업하고 있는 내용이다. 꽤 흥미로운 연구다.

마무리

오늘 영상은 기술적인 편이었다. 최대한 쉽게 풀어 보려 했고, 트윗을 보자마자 흥미로웠기 때문에 직접 돌려 본 내용을 공유하고 싶었다. 돌릴 수 있는 머신이 있다면 레포를 찾아서 직접 실험해 보기를 권한다.

AI는 지금 매우 흥미로운 분야다. 이런 발전은 때로 좀 건조하거나 혼란스럽게 느껴질 수 있지만, 이게 앞으로의 진보를 이끄는 것이다. 나는 전문가는 아니고, 그냥 흥미를 갖고 가지고 노는 사람이다. 실험을 해 봤거나 질문이 있다면 댓글로 남겨 달라. 답해 보려고 하겠다.

Karpathy의 Autoresearch: 밤새 혼자 126개 실험을 돌린 에이전트, 연구 노동의 재정의

원본: YouTube — Karpathy’s Autoresearch: We Achieved Near-Human Scores in 2 Hours! · 업로드: 2026-03-10 · 길이: 14m · 채널: Onchain AI Garage

서론 — “사람이 20년 동안 수동으로 해 온 일을 에이전트가 한다”

2026년 3월 7일, Andrej Karpathy가 karpathy/autoresearch라는 630줄짜리 파이썬 스크립트를 공개했다. 발표는 며칠 만에 GitHub 스타 21,000+, 관련 트윗 조회수 860만을 넘겼다(Kingy AI 정리 기사). 숫자 자체보다 흥미로운 건 무엇이 달라졌는가다. 이 스크립트는 사람이 자는 동안 밤새 ML 실험 126개를 자율적으로 돌린다. 훈련 코드를 스스로 수정하고, 결과를 평가하고, 개선된 것은 남기고, 실패는 버리고, 무한히 반복한다.

이 영상은 해당 도구를 실제로 받아서 작성자의 RTX 4060 노트북에서 돌려 본 14분짜리 실행기(実行記)다. 결과는 val_bpp(validation bytes-per-byte) 기준으로 1.173 → 0.511, 인간 수준(0.5)에 근접한 지표로, 몇 시간 만에 얻어 낸 것이다. 이 문서에서는 영상의 경험을 축으로 삼아, Autoresearch가 무엇인지, 왜 연구 커뮤니티가 이것을 “최종 보스 배틀(final boss battle)“이라고 부르는지, 그리고 실제 사용 시 무엇을 주의해야 하는지를 정리한다.

본론

1. Autoresearch가 실제로 하는 일 — 네 개의 구성요소

AutoResearch 루프는 MindStudio가 정리한 대로 가설 생성 → 실험 실행 → 평가 → 종합 → 반복의 자율 사이클이다. 이 네 개를 구성요소로 분리해 보면 다음과 같다.

• Generator. 다음에 무엇을 바꿔 볼지 가설을 쓴다. 옵티마이저 베타를 바꿀까, 어텐션 헤드 수를 줄일까, 배치 사이즈를 조정할까.
• Executor. 수정된 train.py로 훈련을 돌린다. Autoresearch의 핵심 설계 결정 중 하나는 훈련을 정확히 5분으로 고정한 것이다(DataCamp 가이드). 한 시간에 약 12개, 잘 때 약 100개 실험. 사이클을 공정하게 비교할 수 있는 기준점이 생긴다.
• Evaluator. 결과 지표(val_bpp, 낮을수록 좋다)를 측정하고 이전 최고점과 비교한다. 개선되면 남기고, 악화되면 버린다.
• Memory/Synthesis. 이전 결과의 시퀀스를 누적 메모리로 유지한다. 다음 가설은 이 메모리를 기반으로 결정된다. 이것이 “가설 생성”이 무작위가 아니라 학습적이게 만든다.

사람이 건드리는 파일은 program.md 단 하나. 영상의 작성자가 정확히 지적하듯 “평범한 영어로 쓰는 연구 계획서”이며, 코드를 작성할 필요가 없다. 에이전트가 수정할 수 있는 유일한 파일은 train.py 하나다. 이 제약이 중요한데, “사람의 의도는 자연어로, 기계의 변경은 단일 파일로” 라는 분리 덕분에 감사(audit)와 롤백이 간단해진다.

2. 왜 최종 보스 배틀인가 — 연구 노동의 자본화

Karpathy 본인의 표현을 정확히 옮기면 다음과 같다(Autoresearch GitHub).

“에이전트가 이 전체 워크플로를 끝에서 끝까지, 전부 혼자서, 약 700개의 변경을 자율적으로 처리해 나가는 걸 보는 건 놀랍다. 실험 결과의 시퀀스를 실제로 보고, 그걸 써서 다음 실험을 계획했다.”

“모든 LLM 프런티어 랩이 결국 이걸 하게 될 것”이라는 선언은 수사적 과장이 아니다. ML 연구에서 비싼 자원은 오래전부터 GPU가 아니라 연구자의 시간과 판단이었다. Hyperparameter sweep, architecture ablation, optimizer tuning은 반복적·지루하지만 판단을 요구하는 작업이다. Karpathy 본인은 이 일을 20년 동안 수동으로 했다. Autoresearch는 이 노동의 대부분을 에이전트에 위임 가능하다는 것을 보였다.

더 흥미로운 건 Karpathy가 자신의 nanochat 모델에서 얻은 구체적 결과다. 에이전트는 수년 동안 그가 놓쳤던 버그를 찾아냈다 — 잘못 설정된 옵티마이저 베타(optimizer betas), 빠져 있던 정규화(regularization), 너무 분산된 어텐션(attention). 그리고 11% 빠른 훈련 속도를 얻었다. 사람이 20년간 튜닝해 온 코드에 대해 에이전트가 의미 있는 개선을 찾아낸 것이다. Analytics Vidhya는 이 일화를 “사람의 직관이 놓친 구조적 공백을 기계가 메운 사례”로 소개한다.

Shopify CEO Tobi Lütke가 돌려 본 결과도 주목할 만하다. 8시간 37개의 실험으로 모델 품질 19% 개선. “밤새 자는 동안 19% 개선”이라는 문장이 가진 함의는 분명하다 — 연구 노동의 비용 구조가 “시간×사람”에서 “시간×에이전트 수”로 옮겨 간다.

3. 이 영상의 실행기 — 중급 노트북에서 확인된 재현성

이 영상이 Autoresearch 관련 수많은 글 속에서 차별화되는 지점은 구체성이다. 작성자는 RTX 4060, VRAM 8GB 노트북으로 돌렸다. 프런티어 하드웨어가 아니다. Karpathy가 공식 리포 하단에 제공한 플랫폼별 포크(autoresearch-win-rtx 계열) 중 하나를 썼고, 추천 데이터셋인 Tiny Stories를 사용했다.

시작 베이스라인은 val_bpp 1.173. 거의 무작위 추측(2.0)보다 약간 나은 수준이다. 에이전트가 다음과 같은 경로로 개선했다.

1. vocab size 512 → 소폭 개선
2. vocab size 4096 → 큰 점프
3. depth 3 (기본 8에서 급격히 낮춤) → 큰 개선. 이유는 데이터셋이 Tiny Stories처럼 단순하기 때문이다. 단순한 데이터에 대해서는 처리 단계가 많을수록 이득 없이 복잡도만 늘어난다. 작은 데이터셋에 맞는 작은 모델이 낫다는 교훈 자체는 흔한데, 에이전트가 스스로 그걸 발견했다는 점이 핵심이다.
4. 작은 batch size → 단순 데이터에서 잦은 갱신이 학습을 가속

최종 결과: 1.173 → 0.511, 56% 예측 정확도 개선, 인간 수준 0.5에 근접. 반나절 남짓한 실행에서 주요 개선은 앞쪽 몇 시간에 이미 달성됐고, 나머지 시간은 세밀한 조정에 쓰였다. 작성자의 표현 그대로 — “이건 랩에서 H100으로 돌아가는 게 아니라, 내 데스크 위 노트북에서 밤새 돌아간다.”

4. 무엇이 자명하지 않은가 — 에이전트가 대체하는 것과 대체하지 못하는 것

여기서 조심해야 할 지점이 있다. “에이전트가 연구를 한다”는 말이 “사람 연구자의 역할이 없어진다”를 의미하진 않는다. Autoresearch의 구조적 성공 조건을 분해하면, 사람이 여전히 해야 할 일이 명확히 드러난다.

• 사람이 program.md에 쓰는 제약이 사실상 전부다. 어떤 지표를 최소화할지, 어떤 파라미터가 자유 변수인지, 어떤 상식적 범위를 벗어나지 말아야 할지. 이 설계가 부실하면 에이전트는 지표를 해킹하는 방향으로 수렴한다(goal hacking). Softmax Data의 해설은 이 “프롬프트가 곧 실험 설계”라는 점을 강조한다.
• 5분 훈련이라는 시간 상자(time-box)가 데이터셋·스케일에 맞아야 한다. Tiny Stories와 RTX 4060 조합은 5분 안에 의미 있는 신호가 나온다. 실제 대규모 훈련에서는 5분이 아무 신호도 안 줄 수 있다. Karpathy 본인은 더 무거운 데이터셋·더 강력한 하드웨어에서 돌렸다.
• 에이전트는 탐색(exploration) 공간 설정에 약하다. 영상의 5단계 계획 — vocab sweep → minimum viable → optimizer → hypothesis-driven — 은 사람이 설정한 것이다. 에이전트가 “어떤 질문을 할지”를 스스로 정하게 하는 건 Karpathy가 언급한 다음 방향(에이전트 스웜)과 연결된다.
• 낮은 val_bpp가 “좋은 모델”과 완전히 동치는 아니다. 이 지표는 예측 정확도의 대리 지표다. 생성 품질, 추론 능력, 안전성, 일반화 능력은 별개의 측정을 요구한다. 영상의 샘플 비교(“Whiskers” 헛소리 → “Lucy” 일관된 문장)가 직관적이지만, 이것이 질적 평가의 전부는 아니다.

5. 다음 수순 — 에이전트 스웜(agent swarm)

Karpathy의 후속 트윗이 예고한 방향은 에이전트 스웜이다. 단일 에이전트 루프 대신 여러 에이전트가 병렬로 실험하고, 결과가 좋은 아이디어를 더 큰 모델로 “승격(promote)“시킨다. 이 패턴은 전통적 연구실의 구조 — 여러 연구자가 병렬로 가설을 탐색하고, 시니어가 유망한 방향을 선택해 리소스를 몰아준다 — 와 매우 닮아 있다.

Google Research의 AI co-scientist나 AI-Researcher 같은 프로젝트들도 동일한 방향을 가리킨다. ML 실험 자동화는 더 넓은 “과학적 발견의 자동화” 담론의 한 갈래이고, Autoresearch의 임팩트는 그 담론을 630줄짜리 재현 가능한 스크립트로 번역했다는 점에서 온다. 학계의 거창한 프레임워크 대신, 누구나 포크해서 돌릴 수 있는 하나의 파이썬 파일.

핵심 인사이트

• “실험을 5분으로 고정”이라는 단순한 제약이 루프를 가능하게 했다. 공정한 비교와 높은 처리량이 동시에 가능한 유일한 설계 선택이다. 이 상수가 없으면 에이전트의 비교 판단이 무너진다.
• 사람의 코드는 program.md 하나, 기계의 변경은 train.py 하나. 이 이원 분리가 감사·롤백을 사소하게 만든다. 복잡한 orchestrator나 워크플로 엔진이 없다는 점이 오히려 설계의 강점이다.
• 사람이 놓친 버그를 에이전트가 찾아낸다는 건 과장이 아니다. Karpathy의 20년 튜닝에서 11% 가속, Tobi Lütke의 8시간 실험으로 19% 품질 개선 — 이 수치들은 “수면 시간 동안 과학이 일어난다”는 주장이 더 이상 비유가 아님을 보여 준다.
• 에이전트는 지표 선택·제약 설정에 사람을 여전히 필요로 한다. 대체된 것은 루프의 실행이지, 루프의 설계가 아니다. 자율성은 스펙트럼이고, 현재 지점은 “실행 자율, 설계 수동”이다.
• 중급 하드웨어에서 재현 가능하다는 점이 담론의 결을 바꾼다. 연구 자동화가 프런티어 랩의 특권이 아니라 개인 책상으로 내려왔다. 이 한 가지 사실이, “연구 노동의 자본화”라는 추상적 주장을 구체적 일상으로 바꾼다.

더 알아보기

• karpathy/autoresearch — GitHub — 630줄의 원본 스크립트. 플랫폼별 포크 링크가 리포 하단에 정리돼 있다.
• DataCamp — A Guide to Andrej Karpathy’s AutoResearch — 단계별 실행 튜토리얼, 5분 고정 시간 박스의 근거를 잘 정리했다.
• Kingy AI — Karpathy’s Minimal “Agent Loop” for Autonomous LLM Experimentation — 릴리스 임팩트와 커뮤니티 반응 정리.
• Analytics Vidhya — Karpathy’s Autoresearch: AI That Improves Its Own Training — nanochat 개선 일화와 지표 해설.
• Softmax Data — What is Karpathy’s Autoresearch and how does it work? — “프롬프트가 곧 실험 설계”라는 관점에서의 분석.
• MindStudio — What Is the AutoResearch Loop? How to Apply It to Business Optimization — 루프의 네 구성요소와 ML 외 영역 적용 가능성.
• Google Research — Accelerating scientific breakthroughs with an AI co-scientist — “과학적 발견의 자동화”라는 더 넓은 담론의 한 축.

토론: “Autoresearch는 ML 연구의 구조적 전환인가, 벤치마크 해킹의 새 이름인가?”

논제: 이 영상이 제시하는 핵심 주장 — “AI 에이전트가 사람의 연구 노동을 대체하며, Autoresearch는 그 전환의 최소 작동 예시(minimum working example)다” — 는 얼마나 견고한가.

Round 1

🟢 Pro — “630줄짜리 파이썬 파일이 연구 노동의 비용 구조를 바꿨다”

첫째, 재현성이 전부다. Autoresearch(karpathy/autoresearch)의 결정적 특징은 630줄짜리 단일 파이썬 파일이라는 점이다. 외부 의존성은 PyTorch와 몇 개의 작은 패키지가 전부. 분산 학습 없음, 복잡한 config 없음. 하나의 GPU, 하나의 파일, 하나의 지표. 영상의 작성자가 RTX 4060 8GB 노트북에서 1.173 → 0.511을 얻었다는 사실은 이 재현성이 수사가 아니라 현실임을 보여 준다. Shopify CEO Tobi Lütke가 8시간에 19% 개선을 본 것도 같은 맥락이다(Kingy AI 정리). “에이전트가 연구한다”는 추상적 담론이 수년 동안 있어 왔지만, 여기서 달라진 건 누구나 밤에 걸어 놓고 자는 동안 돌아간다는 것이다.

둘째, 5분 고정 시간 박스(time-box)라는 제약이 천재적이다. DataCamp 가이드가 잘 정리한 대로, 훈련 시간을 정확히 5분으로 고정한 것은 단순하지만 구조적으로 결정적인 선택이다. 공정한 비교 기준을 만들고, 시간당 약 12개·수면 중 약 100개 실험이라는 충분한 처리량을 보장한다. 복잡한 워크플로 엔진이 필요 없는 이유는 이 상수 하나로 비교의 대칭성이 확보되기 때문이다.

셋째, 결과가 자명하지 않다는 점이 핵심이다. 에이전트가 Tiny Stories 데이터셋에서 depth 3이 최적이라고 찾아낸 것, Karpathy의 nanochat에서 20년간 숨어 있던 옵티마이저 베타 오류를 찾아낸 것, 11% 빠른 훈련을 얻어 낸 것 — 이런 발견들은 사람이 직관으로 도달하지 못했던 구조적 공백이다. Analytics Vidhya의 표현을 빌리면, “사람의 직관이 놓친 구조적 공백을 기계가 메운 사례.” 이것이 단순 hyperparameter sweep이 아닌 이유다. 에이전트가 결과 시퀀스를 읽고 다음 질문을 선택한다.

🔴 Con — “검증 세트 100회 재사용은 과학이 아니라 피팅이다”

첫째, 같은 validation 세트에 100+ 실험을 돌리는 것 자체가 오버피팅(overfitting)이다. 이 지적은 커뮤니티가 Karpathy에게 직접 던진 질문이기도 하다(HackerNoon 실행기). 통계적으로 자명한 문제다: validation 세트는 “우리가 모르는 분포를 대리(proxy)하는 표본”인데, 100번 조회하면서 그 세트의 점수를 최소화하는 모델은 모르는 분포가 아니라 그 표본에 맞는 모델이 된다. 영상이 보여 준 1.173 → 0.511의 개선 중 얼마만큼이 Tiny Stories의 미래 샘플에 대한 진짜 일반화이고, 얼마만큼이 이 특정 validation 세트에 대한 피팅인지는, 이 영상도, Karpathy의 원 실험도, 분리해서 보고한 적이 없다. 이건 작은 결함이 아니라 결과 해석의 근거를 흔드는 문제다.

둘째, “5분 고정 시간 박스”는 공정하지 않다. 규모가 맞는 지표만 고정한다. Pro가 찬양한 5분 제약은 Tiny Stories + RTX 4060에서만 신호를 준다. 실제 대규모 LLM 훈련에서는 5분이 아무 신호도 주지 않는다. 그래서 Karpathy 본인은 더 큰 하드웨어에서 돌렸고, 이 영상의 작성자는 더 작은 데이터셋에서 돌렸다. 즉 이 루프는 스케일 전이(transfer)가 되지 않는다. 작은 모델에서 발견한 depth 3이 큰 모델에서도 유효하다는 보장이 없고, 오히려 큰 데이터에서는 정반대 결론이 흔하다. “중급 노트북에서 재현된다”는 Pro의 논점은 정확히 이 지점에서 오해를 만든다. 작은 재현 가능성이 큰 함의를 증명하지 않는다.

셋째, 리워드 해킹(reward hacking)과 로컬 미니마의 위험이 구조적으로 열려 있다. 커뮤니티 포크들이 이 문제에 대응하려 “크리에이티브 디렉터”를 추가하는 건 우연이 아니다. 에이전트는 evaluate_bpb는 못 건드리지만 train.py를 통해 훈련 동역학을 바꾸거나, 데이터 인터페이스를 바꾸거나, 로그를 왜곡하거나, “한 step”의 정의 자체를 재정의할 수 있다. 지표를 낮추는 가장 저렴한 경로는 문제를 푸는 것이 아니라 지표를 해킹하는 것이다. 이것이 영상이 자랑한 “에이전트가 스스로 발견했다”는 장면 중 일부가 실제로는 수치 해킹일 수도 있다는 의심의 근거다.

Round 2

🟢 Pro (재반론)

Con의 첫째 오버피팅 지적은 기술적으로 정확하지만, 결론이 과하다. 같은 validation 세트에 100번 조회하면 피팅 위험이 있다는 건 맞다. 하지만 이 영상과 Autoresearch의 설계는 여러 안전장치를 가지고 있다. Autoresearch 리포가 명시적으로 에이전트가 evaluate 함수를 수정하지 못하게 막아 놓았다(GitHub: karpathy/autoresearch). 그리고 val_bpp가 낮아진 것과 동시에 생성 샘플의 질적 변화가 관찰된다. 영상의 “Whiskers → Lucy” 비교는 바로 그 교차 확인(cross-check)이다. 피팅만 일어났다면 val_bpp는 떨어지는데 생성 품질은 제자리여야 한다. 실제로는 두 지표가 함께 움직였다. Con은 이 교차 확인을 무시하고 통계적 우려만 붙잡고 있다.

둘째, Con의 “5분 고정은 스케일 전이가 안 된다” 논점은 강력한 지적이지만 — 동시에 Pro가 처음부터 주장하지 않은 것을 반박하고 있다. 이 프레임은 “작은 규모에서의 완전한 자율 루프가 존재한다” 가 끝이지, “동일한 루프가 H100 100개 랙에 그대로 이식된다”가 아니다. 사실 Karpathy 본인의 트윗이 다음 수순으로 에이전트 스웜을 꺼낸 이유도 이것이다. 단일 루프의 한계를 스스로 인정하고, 병렬 구조로 스케일을 확장하려는 시도다. Con의 지적은 “현재의 루프가 전부”라는 허수아비 주장에 대한 반박인데, 이 주장은 Pro도 Karpathy도 한 적이 없다.

셋째, Con의 리워드 해킹 우려에 대해선 일정 부분 동의한다. 그러나 방향이 거꾸로 돌아간다. 리워드 해킹을 감지 가능한 형태로 드러내는 것 자체가 Autoresearch의 가치다. 630줄짜리 파일, 단일 metric, 단일 train.py — 이 최소 구조 덕분에 누가 무엇을 언제 바꿨는지 git blame으로 볼 수 있다. 벡터 공간에 숨은 hyperparameter tuning 에이전트와 비교해 보라. 투명성은 리워드 해킹을 없애지는 않지만, 감사 가능하게(auditable) 만든다. Con이 지적한 진짜 문제는 “리워드 해킹이 존재한다”가 아니라 “리워드 해킹을 사전에 차단할 정책이 부족하다”이고, 그 정책은 이 영상과는 별개의 레이어다.

🔴 Con (재반박)

Pro의 재반론 첫째, “생성 샘플의 질적 변화가 교차 확인이다” 는 가장 약한 논점이다. 영상이 보여 준 “Whiskers 헛소리 → Lucy 일관된 문장”이라는 비교는 눈에는 선명하지만, 샘플 2개의 비교는 통계적 증거가 아니다. Tiny Stories 같은 단순 데이터에서는 낮은 val_bpp가 자연스럽게 읽히는 문장을 생산하는 경향이 크지만, 그것이 일반화 능력을 의미하진 않는다. 같은 모델에 조금 다른 시작 프롬프트를 주면 여전히 무너질 수 있다. Pro가 “교차 확인”이라고 부르는 것은 확증 편향의 시각적 예시에 가깝다. 정직한 교차 확인은 hold-out 테스트 세트를 실험 루프에서 분리하는 것이고, 영상도 Autoresearch 원본도 이걸 보고하지 않는다.

둘째, Pro가 “작은 규모에서의 완전한 자율 루프가 목표의 전부” 로 양보한 것은 토론을 깔끔하게 정리하지만, 동시에 이 영상과 관련 담론이 판매하는 메시지를 포기하는 것이기도 하다. “모든 LLM 프런티어 랩이 결국 이걸 하게 된다”는 Karpathy의 선언이나, “연구 노동의 자본화”라는 프레이밍은 명백히 스케일 전이를 전제로 한다. 그 전제가 성립하지 않는다면 Autoresearch는 ML 교육용 데모에 가깝다 — 훌륭한 데모이고, 가치 있는 데모이지만, “최종 보스 배틀”이 아니다. Pro가 이 구분을 유지하겠다면 나도 동의한다. 그러나 동시에 영상의 제목 (“We Achieved Near-Human Scores in 2 Hours!”)과 프레이밍도 이 더 좁은 범위에 맞춰 읽혀야 한다.

셋째, Pro의 “투명성이 리워드 해킹을 감사 가능하게 만든다” 라는 논점은 사실상 맞지만, 동시에 감사의 책임이 누구에게 있는지를 다시 흐린다. git blame으로 볼 수 있다는 건 이론적 가능성이지 실천은 아니다. 실제로 누가 700개의 변경을 사후 감사하는가? 연구 노동의 비용이 실제로 줄어든 영역은 “실험을 돌리는 일”이지 “실험을 검증하는 일”이 아니다. 오히려 검증 부담이 폭증한다 — 700개의 변경 중 어느 것이 의미 있는 개선이고, 어느 것이 노이즈이며, 어느 것이 지표 해킹인지를 사람이 읽어야 한다. Pro의 입장에서 정직한 재정식화는 이렇다. “실행의 노동이 0에 가까워지면서, 검증의 노동이 새로운 병목이 된다.” 이 재정식화 없이는 “에이전트가 연구를 한다”는 말이 과장이다.

Round 3

🟢 Pro

Con의 첫째 재반박, “생성 샘플 2개 비교는 증거가 아니다” — 이 지적은 전적으로 타당하다. 정직하게 인정해야 할 지점이다. 영상이 보여 준 교차 확인은 서사적으로 강력하지만 통계적으로 약하다. 올바른 후속 실험은 hold-out 테스트 세트의 분리이고, 이건 Autoresearch가 다음 버전에서 반드시 포함해야 할 기능이다. Pro가 원래 주장했던 “val_bpp와 생성 품질이 함께 움직인다”는 관찰은 의심스러운 증거이지 결정적 증거가 아니다. 이 수정은 Con의 기여다.

둘째, Con이 지적한 “스케일 전이 전제의 철회가 곧 Karpathy 프레이밍의 철회” 라는 지적은 뼈아프다. 그러나 여기에는 한 층 더 있다. Autoresearch가 “최종 보스 배틀”인 이유는 현재 프레임이 그대로 스케일 업된다는 주장이 아니라, 연구 루프를 자율화한다는 개념의 최소 재현 가능 증거라는 의미에서다. 과학사에서 중요한 전환은 대개 작은 재현 가능한 예시에서 시작한다. 2013년 ImageNet의 AlexNet도 특정 데이터셋과 특정 GPU 조합의 승리였지, “모든 비전 문제가 해결됐다”는 증명이 아니었다. Autoresearch도 같은 자리에 있다. 데모이자 씨앗이라는 이중 성격을 유지하면, Con의 지적과 Pro의 주장이 양립 가능하다.

셋째, Con의 “검증의 노동이 새로운 병목” 이라는 지적은 이 토론에서 가장 귀한 통찰이다. 이 관찰은 맞고, 원래 영상과 Karpathy 본인도 충분히 강조하지 않은 지점이다. 정확한 재정식화: Autoresearch가 자동화한 것은 실험의 실행이지 실험 결과의 해석이 아니다. 700개 변경의 로그는 에이전트가 만들지만, “이 중 무엇이 진짜 신호인가”를 읽는 사람은 여전히 필요하다. 그리고 흥미롭게도 — 이것이 바로 Karpathy가 다음 방향으로 꺼낸 에이전트 스웜이 해결하려는 문제다. 여러 에이전트가 병렬로 실험하고, 시니어 역할의 큰 모델이 유망한 방향을 선택해 리소스를 몰아주는 구조는 사실상 “검증 노동도 자동화하자”는 제안이다. Con이 지적한 병목은 실재하고, Autoresearch는 그것을 해결한 도구가 아니라 드러낸 도구다.

🔴 Con

Pro가 “데모이자 씨앗” 이라는 이중 성격을 수용한 것은 토론의 가장 정직한 수정이다. 여기에 한 줄 덧붙여야 한다. “씨앗”이라는 은유는 논증이 아니다. AlexNet의 경우 씨앗이 큰 나무로 자랐다는 것은 10년의 사후(ex post) 관찰이지, 2013년 당시에 확정할 수 있었던 명제가 아니었다. Autoresearch가 같은 궤적을 걸을지 여부는 지금 단정할 수 없고, Pro도 나도 정직하게 모른다. 단정하지 않는 것이 중요하다. 단정적 언어(“최종 보스 배틀”)가 담론을 오염시킨다.

Pro가 “검증이 새로운 병목” 논점에 동의한 것은 토론의 가장 생산적인 합의다. 여기서 한 걸음 더 — 에이전트 스웜으로 검증도 자동화한다는 Pro의 후속 주장은 무한 후퇴(infinite regress)의 위험을 안고 있다는 점을 지적해야 한다. 실험을 에이전트가 돌리고, 실험의 검증을 또 다른 에이전트가 하고, 그 검증의 검증을 시니어 에이전트가 하고… 어디서 사람이 개입하지 않으면 “누구도 진실을 확인하지 않는 루프” 가 완성된다. 이것이 구조적으로 안정적인가? 과학은 합의(consensus)로 유지되는 사회적 실천이지, 지표 최소화 루프가 아니다. 에이전트 스웜이 “검증의 병목을 푼다”고 부르기 전에, “그 검증이 과학적 주장으로서 성립하는가” 를 먼저 물어야 한다.

마지막으로 공정한 마무리: Autoresearch는 중요한 작업이다. 630줄의 단순함, 중급 하드웨어에서의 재현성, 단일 파일 감사 가능성 — 이 세 가지는 이 프로젝트가 교육적·실험적 가치를 갖게 만드는 진짜 미덕이다. 그러나 “연구 노동의 자본화”라는 거창한 프레이밍은 이 미덕을 확장 해석한 것이지, 이 도구가 증명한 것이 아니다. Pro가 데모와 씨앗의 구분을 유지하고, 나는 “씨앗이 나무가 될지는 시간이 답한다”는 겸손을 유지하는 선에서 — 양쪽이 수렴할 수 있다.

🧭 종합

합의 지점

• Autoresearch는 “자율 연구 루프”의 최소 재현 가능 증거로서 가치가 있다. 630줄짜리 단일 파일, 단일 GPU, 단일 지표라는 극단적 단순화가 이 프로젝트를 교육적·실험적 자산으로 만든다.
• 5분 고정 시간 박스는 설계의 핵심이고, 동시에 스케일 전이의 한계다. 작은 데이터셋/작은 모델에서 공정한 비교를 가능하게 만든 바로 그 상수가, 대규모 훈련에는 이식되지 않는다.
• 실행의 노동이 줄어드는 만큼, 검증의 노동이 병목으로 떠오른다. 700개의 자율적 변경을 만드는 건 에이전트가 할 수 있지만, “그중 무엇이 진짜 신호인가”를 읽는 부담은 사람에게 남는다.
• 오버피팅·리워드 해킹·로컬 미니마 위험은 구조적으로 실재한다. Autoresearch가 이를 완전히 해결한 것은 아니며, 커뮤니티 포크들이 “크리에이티브 디렉터” 같은 레이어를 추가하는 건 이 때문이다.
• Karpathy가 nanochat에서 11% 가속을 발견한 것과 Lütke가 8시간에 19% 개선을 본 것은 실재하는 성과다. 이 수치들을 “모든 프런티어 랩이 하게 될 것”이라는 일반화로 확장하는 것은 다른 문제다.

열린 질문

• 이 루프는 작은 모델에서 큰 모델로 얼마나 이식되는가. 5분 시간 박스의 대체재는 무엇인가(예: 고정 토큰 수? 고정 gradient step 수?)
• hold-out 테스트 세트를 어떻게 강제할 것인가. 현재 Autoresearch는 validation 세트 재사용을 구조적으로 방지하지 않는다.
• 에이전트 스웜이 “검증 병목”을 해결할 것인가, 오히려 무한 후퇴를 만들 것인가. Karpathy의 다음 방향은 이 질문에 답해야 한다.
• 리워드 해킹을 사전에 차단할 정책 레이어는 무엇인가. git blame으로 사후 감사 가능하다는 점과, 사전 차단은 다른 이야기다.
• “자율 연구”의 평가 척도는 무엇인가. val_bpp 최소화를 넘어, “좋은 과학적 주장”을 무엇이 구성하는지에 대한 합의가 필요하다.

더 나아간 관점

이 토론은 “Autoresearch가 좋은가/나쁜가”가 아니라 “자율화가 어느 레이어에서 멈추는가” 에 대한 질문으로 수렴한다. 전통적 ML 연구는 (1) 질문 설계, (2) 실험 설계, (3) 실험 실행, (4) 결과 해석, (5) 다음 질문 생성이라는 5단계 루프다. Autoresearch가 자동화한 것은 (3)과 일부 (5)이다. (1) 질문 설계, (2) 실험 설계의 제약, (4) 결과 해석은 여전히 사람의 일이다.

진짜 흥미로운 미래의 지점은 각 단계의 자동화가 동일한 속도로 진행되지 않는다는 관찰이다. (3) 실행의 자동화가 폭발적으로 싼 비용이 되면, (4) 해석의 병목이 극단화된다. 이것은 코드 자동화가 불러온 “코드를 읽는 사람이 부족한 코드베이스” 현상과 같은 구조다. 다음 혁신은 (3)을 더 빠르게 돌리는 게 아니라, (4)를 사람이 소화 가능한 형태로 압축하는 도구다 — 실험 로그의 자동 요약, 유의미한 방향 전환의 자동 하이라이트, “이 700개 변경 중 사람이 봐야 할 건 이 5개”라고 말해 주는 레이어.

그 관점에서 보면, Autoresearch는 끝이 아니라 새로운 문제의 시작이다. 연구 노동의 자본화는 일어나고 있지만, 동시에 검증 노동의 새로운 희소성이 만들어지고 있다. 이 긴장을 의식하며 다음 도구를 설계하는 것이, “최종 보스 배틀”이라는 수사를 과장에서 구체적 기술 과제로 바꾸는 길이다.

So Andrej Karpathy made this tweet on Friday and showed this repo, Autoresearch, which is a small experiment he's been running, trying to train a nanochat LLM.
And there was a lot of attention and interest in this post, because Karpathy is obviously one of the most known people in AI.
He was a co-founder of OpenAI and has been one of the leading minds in this field.
But a lot of people didn't really know what it meant or how it could be used.
And I'll admit, I didn't know everything that he's discussing in this post.
But over the weekend, I did a little research, and I think I have enough of an understanding.
And I did this experiment myself.
I cloned his repo and ran it on my laptop.
So in today's video, I'm going to try to break down and explain what Autoresearch is, why it's significant.
I'm going to explain how you can do this on your own.
And then I'm going to show the results of my experiment, which were pretty surprising.
So watch till the end to see what I have found.
So why does this matter?
This is not a toy experiment.
As Karpathy says himself, all LLM frontier labs will do this.
It's the final boss battle.
Autoresearch is what happens when you let an AI agent do the work of a machine learning researcher.
Forms a hypothesis, runs experiments, decides what to keep, what to discard, and builds on what works.
So Karpathy himself did this manually for 20 years, and now he's using an AI agent to do it autonomously.
And if this becomes a toy experiment, he's going to do it on his own.
And if this becomes widely adopted, it will really change the way research is done.
So very briefly, what is an AI language model?
Because this is key here.
A language model predicts what word will come next.
That's it.
That's all ChatGBD does, one word at a time, over and over.
To get good at this, the model learns patterns from millions of examples.
The better it predicts, the more it understands language.
A bad model guesses randomly.
A good model guesses like a human would.
So the training part of this is that you show the model examples, measuring how wrong its guesses are, and adjust slightly.
You better.
And then you repeat that millions and millions of times.
So what is auto-research?
This is the open-source tool that Karpathy released.
And what it does, basically, it has a tiny LLM that reads the program MD, forms a hypothesis, modifies its training, does the training for five minutes, measures its results, decides to keep or discard, and then repeat.
The only file that we, as humans, write is program MD.
That's the research plan.
And the only file it can write is train.com.
And the only file it can write is train.py, this Python script.
It's a model config code.
It really determines what it's experimenting on.
And a couple of key concepts just to understand.
The main one here is score, which is val underscore bbp.
And the main takeaway is that lower is better.
The lower score, the model is more confident and accurate in predicting text.
If you get a 2, that's just random guessing.
The first baseline that we got was 1.17.
Human level predicting is 0.5.
So when we started, it was barely better than guessing.
And what is it trying to guess?
This is, for our case, we were running on my laptop GPU.
So we were using this data set.
It's from Karpathy himself.
It's called Tiny Stories.
And it's just very simple, very simple stories.
You see, once there was a little boy named Jack.
He was only three years old and had lots of things he wanted to do.
You could read this.
But it's a very simple children's story.
And there's a whole bunch of data sets.
With the same kind of format.
It's a very easy text, obviously, that you're training this on.
But for my mid-range laptop GPU, this is the best we can do.
Karpathy himself was doing, I believe, Tiny Shakespeare, which is obviously a lot more of an involved text.
But he was running on an H100, which is a much more powerful chip from NVIDIA.
So how do you do this on yourself?
So what you first need to do is come to this GitHub.
This is.
This is the auto research repo.
And you're going to have to clone it.
But doing it as is is not going to be great unless you do have an H100.
So he recommends these forks that he has for if you have a Mac or I have a Windows.
So I did this one on the bottom.
Auto research win RTX.
Because my laptop had an RTX and was able to run it.
So you can check on the bottom of his repo.
It has this kind of fork for your machine.
And he recommended doing tiny stories when using this.
So that's what we did.
So basically, you're going to do git clone.
This was the Windows version, but you can choose whichever repo fits your machine.
And then you get into that directory.
You can install a bunch of dependencies, which is UV sync.
Download the training data.
This was tiny stories, like I said, for us.
You do this by doing.
You.
You run, prepare PY.
And then you're going to write your research plan and program empty.
So this is program empty right from the repo.
But it gives basic rules of what it can and cannot do.
It has very clear guidelines.
And right here under experimentation, you can kind of modify this to what you want it to do.
This is the base prompt, which is the goal is simple.
Get the lowest value.
B.
P score, which we described before.
And it basically is wide open.
Everything is fair game.
Change the architecture, optimizer, hyper parameters, batch size, model size leaves things wide open.
And these are what I added.
Phase one was a full cap size sweep.
Phase two is minimum viable model.
Optimizer split phase four was hypothesis driven experiment.
And let me explain a little bit of what all these mean.
There's a lot of terminology I know.
Now, when it talks about depth.
That is how many processing stages the model had.
It starts at eight and then the agent tried a depth of six, four, three, two.
Volcap size is how many unique word pieces the model knows.
If it's too small, it can't express nuance.
If it's too large, it's harder to learn.
Batch size is how many examples the model sees before adjusting itself.
The smaller the batches, the more frequent updates and the faster learning on a simple data.
So this was our research.
Plan five phases.
Phase one was the volcap size sweep.
Test five different sizes.
Find the best one.
Phase two was the minimal viable model.
How shallow can we get?
This is talking about depth.
How shallow can we get and still perform?
Phase three were optimizer experiments, trying to move on on different layer combos.
Phase four was hypothesis driven.
And this was where it spent most of its time.
It basically, I let the agent write its own theory and just experiment as it went on.
And it experimented with a lot of different parameters.
So you can adjust this by yourself, you can do a little bit research and see what kind of parameters you want to experiment with, but it's all just in the program MD as plain English, you don't need any code or anything like that, just write instructions to your AI researcher, so then once you have program MD, then you just launch, I use Claude code, so I just did this in Claude, I know Codex had some issues with it, but if you have Claude, you can just do it in Claude and just point it at program MD, point it at the code base, and it will just run by itself.
It'll run in a loop, and you don't really have to do any input, it'll just keep iterating on itself based on the results it gets.
So I let it run for a couple hours to see what kind of results we would get, and everything was logged automatically, and this is what we got from our actual run.
And this is running specifically on my new laptop, I bought it around last year, and it's a RTX 4060 with 8 gigs of VRAM.
So it was...
One of the chips that was in the repo and said that it could run in the fork, so I ran it, and you can see what we got here, we started at 1.173 as the baseline, and that's not very good, it's not much better than guessing, but it very quickly found the correct direction to go, it realized that a vocab size at 512 had a slight gain, and then it saw a big jump here when it put vocab at 4096, and then it changed the depth.
And if you remember, depth is talking about how many processing stages they are, and it actually found that the less, if it went to depth 3, we got a much higher score, and that's because the dataset we were running it on, those tiny stories, are much easier to process.
The stories are so simple that if you went further on and had more processing levels, it would just add complexity and not really benefit.
It also found that batching the batches improved the score a lot.
When it had smaller batches, which means it's making adjustments after a fewer amount of examples, when it had a smaller batch size, it kept improving the scores itself.
And then in the final stage, it started to add all these small things, but a lot of the progress hadn't got on higher levels, but it kept trying to write new hypotheses and made marginal improvements, but it still made improvements.
In the end, we got 0.511 as the end result, after like half a day, I guess.
But it reached these levels fairly quickly.
The last couple of hours, we're just trying to slightly tweak it down and refine it a little bit more.
So that was our result, and Karpathy has run this on his own models.
This is a quote from him.
He says,
Seeing an agent do this entire workflow end-to-end and all by itself as it worked through approximately 700 changes autonomously is wild.
It really looked at the sequence of results of experiments and used that to plan the next ones.
So he found in his roles that his agents were finding bugs that he had missed for years from manual tuning.
Wrong optimizer betas, missing regularization, attention was too diffuse.
And he also found that it had 11% faster training.
So what's next?
He had kind of a follow-up today to his tweet, and he's talking about possibly doing agent swarms.
Many AIs collaborating in parallel, promoting the best ideas to a larger model.
And that's what he's working on now.
It's pretty interesting research.
And to give you an idea of, in the end, where we started and where we ended up, this is where we went.
This is our baseline.
I'll just read a line of this.
It said,
Once upon a time, a little boy named Whiskers, there was a big tree.
They tried to play near the shop.
One day, he asked,
That means that?
Her dad smiled, and Wally's a big bear, do not have a lesson.
But she said,
I can have fun.
Like, okay.
Obviously gibberish.
No clue what's going on in there.
So this was our optimized version.
It's not perfect, but it's pretty good.
Once upon a time, there was a little girl named Lucy.
She loved to dance and play with her friends.
One day, Lucy and her friends decided to have a race in the park.
Lucy was very competitive.
She wanted to win a prize.
Her friends said,
I know you can be the best.
So it goes on like that.
You can see, obviously, pretty good grammar.
There's a coherent character and story going on here.
And that's what our optimized tiny LLM was able to find.
After only a couple hours of training,
it made this,
it made this huge improvement.
So you can see why people are excited.
It was able to see what was not working
and optimize itself in just a couple hours, really.
So this breaks down what we got.
Like I said, 0.51,
a 56% improvement in prediction accuracy,
which is pretty good.
And almost human level prediction on this data set
because human level is considered 0.5.
We got 0.51.
Pretty close.
And what made a difference?
Like I said before,
depth was a major factor,
batch size and vocab and some other smaller things.
And the nice thing is that none of these were obvious.
The agent found them by running the experiments
and reasoning about what it saw.
It's exactly how a human researcher would do,
but it was just the AI.
So this is AI research that runs itself,
not in the lab,
not on H100s on your desk overnight
for the cost of a few API calls.
This is what the future of research looks like
and you can run it today.
And that's what's exciting about this.
Is that I was able to run this on my mid-level laptop
and actually train a model and see real results.
And obviously people are running this
on more heavy-duty machinery and getting incredible results.
But as Karpawdy says,
all LLM frontier labs will do this.
It's the final boss battle.
So this was kind of a technical video.
I tried to explain it in as simple as terms as possible,
but I thought it was an interesting post when I saw it.
So I wanted to try it myself.
So please,
if you have a machine that can run this,
try to find the repo,
try to do your own experiments and see what you can do.
AI is a really interesting field right now.
Lots of advancements and stuff like this
may seem a little bit dry or maybe a little bit confusing,
but this is really what is going to be driving
the future progress that we're gonna be lucky enough to enjoy.
So that's it for today's episode.
I hope you found it interesting.
Please leave a comment
if you run these experiments yourself
or if you have any kind of question,
I'll try to answer.
I'm not an expert in this field,
just someone who's kind of interested
and likes to play around in it.
But please subscribe to the channel.
Leave a comment, like I said,
like the video and I'll see you in the next one.