오토리서치 실험: 지표는 완벽해 보였지만, 코드를 보니…

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

이번 실험의 배경

며칠 전에 안드레이 카파시(Andrej Karpathy)의 오토리서치(Autoresearch)를 가지고 실험한 영상을 올렸습니다. 그때는 소형 GPU에서도 돌아가는 타이니 스토리즈(Tiny Stories) 레포를 그대로 사용했고, 불과 두 시간 만에 성능이 56% 향상되는 꽤 인상적인 결과를 얻었습니다. 베이스라인은 문법도 엉망인 알아볼 수 없는 문자열에 가까웠는데, 학습이 끝난 뒤에는 문법도 맞고 흐름도 매끄러운 짧은 이야기를 생성할 수 있었죠.

이게 단순한 재미 이상의 가능성을 보여준다고 느꼈고, 저는 “그럼 이 도구로 또 뭘 해볼 수 있을까?” 하는 질문에 꽂혀 버렸습니다. 나만의 작은 모델을 처음부터 학습시키는 일에 살짝 중독된 상태라, 앞으로 몇 주 동안 여러 가지 변형 실험을 차례로 진행할 계획입니다. 오늘은 그 첫 번째 후속편으로, 데이터셋을 코드로 바꿔 보기로 했습니다.

데이터셋 준비: CodeParrot Clean

이번에 쓴 데이터셋은 코드패럿 클린(CodeParrot Clean)입니다. 깃허브(GitHub)에서 수집한 파이썬 스크립트 모음을 정제한 것으로, 전체를 다 쓰진 않고 샘플만 사용했습니다. 저도 파이썬을 쓸 줄 알기 때문에, 모델이 뱉은 결과물이 말이 되는지 아닌지 직접 눈으로 판단할 수 있다는 점이 큰 장점이었죠.

1단계는 클로드(Claude)에게 데이터셋을 검토시키고, 다운로드한 뒤 prepare.py를 타이니 스토리즈용에서 파이썬 코드용으로 재구성하도록 지시하는 것이었습니다. 그 과정에서 pip install uv가 필요했는데 이 머신에는 설치돼 있지 않아서 추가로 깔아야 했습니다. program.md 파일에는 거의 손을 대지 않았고, 단지 “이번 데이터셋은 파이썬 소스 코드라서 타이니 스토리즈보다 훨씬 복잡하고 다양하며, 베이스라인이 더 높고 수렴도 느릴 것으로 예상한다”는 메모만 덧붙였습니다. 실제로 타이니 스토리즈만큼 극적인 성능 점프는 어렵겠다고 처음부터 예상했습니다.

베이스라인과 핵심 지표

2단계에서 코드 데이터로 토크나이저 학습이 끝났고, 곧바로 메인 학습 루프가 시작됐습니다. 핵심 지표는 검증 세트 BPB(Val BPB, bits per byte)이며, 베이스라인은 1.84~1.85 수준이었습니다. 이 숫자가 학습 이후에 얼마나 떨어지는지가 실험의 성패를 가릅니다.

베이스라인 모델이 생성한 샘플을 보면, import torch로 시작한 뒤 이어지는 줄들은 대부분 의미 없는 문자열입니다. 클로드도 스스로 “5분 학습된 베이스라인 결과물은 예상대로 거의 비문 수준이며, import·주석·라이선스 헤더 같은 구조적 패턴만 흉내 낼 뿐 실제로 돌아가는 코드는 아니다”라고 인정했습니다. 여기서부터 오토리서치가 얼마나 끌어올릴 수 있는지가 관전 포인트였죠.

에이전트가 돌린 하이퍼파라미터 탐색

이번에는 가설을 제가 미리 정해 주지 않고, 에이전트가 알아서 탐색하도록 풀어 놨습니다. 이전 타이니 스토리즈 편과 시트 뮤직(sheet music) 편에서 이미 확인된 바로는, 모델 깊이(depth) 와 배치 사이즈(batch size) 가 점수에 가장 큰 영향을 주는 레버였습니다.

에이전트가 가장 먼저 건드린 것은 깊이였습니다. 레이어를 8층에서 12층으로 늘렸는데, 코드의 구조적 복잡성을 고려하면 더 깊은 모델이 유리할 것이라는 논리였죠. VRAM에도 여유가 있었습니다. 그러나 결과는 오히려 1.87로 나빠졌습니다. 시간 예산이 고정된 상태에서 깊은 모델은 그만큼 학습 스텝 수가 줄어들기 때문에 손해를 본 것이라고 에이전트는 분석했습니다.

다음은 매트릭스 학습률(matrix learning rate)이었습니다. 이 값은 모델이 내부 변환 테이블을 업데이트할 때 한 번에 얼마나 큰 보폭으로 움직이는지를 정합니다. 너무 크면 최적점을 지나쳐 버리고(overshoot), 너무 작으면 학습이 한없이 느려지죠. 학습률을 살짝 올리자 1.83까지 떨어졌고, 더 올려 0.10으로 맞췄을 때 최고점이 나왔습니다. 다만 0.14까지 밀어붙이자 다시 오버슈팅이 일어났습니다.

그 다음으로는 워밍업 비율(warmup ratio)을 10%로 올려 초반 학습을 안정화했고, 결정적으로 배치 사이즈를 낮추기 시작하면서 점수가 급격히 떨어졌습니다. 2의 19승에서 출발해 1.619 → 1.67 → 1.03 → 0.88까지 계속 내려갔고, 결국 2의 14승 지점이 스위트 스팟이었습니다. “작은 배치로 더 많은 스텝을 밟는다”는 전략이 코드 데이터에서도 통한 셈입니다.

한계에 부딪힌 뒤의 탐색과 최종 점수

배치 사이즈로 짜낼 수 있는 이득이 바닥나자 에이전트는 다른 축을 건드려 봤습니다. 임베딩 학습률(embedding learning rate)을 0.6에서 1.6으로 올려 보고, 웜다운 비율(warm down ratio), 가중치 감쇠(weight decay), 슬라이딩 윈도우(sliding window) 길이, 헤드 차원(head dim), 종횡비 등을 차례로 시도했지만 대부분 의미 있는 개선은 없었습니다.

흥미로운 것은 마지막 반전이었습니다. 초반에 실패했던 깊이 조절을 다시 꺼내 이번에는 반대로 깊이를 낮춰 본 것입니다. 그리고 이것이 먹혔습니다. 최종적으로 Val BPB는 베이스라인 1.85에서 0.82까지 떨어졌습니다. 불과 스무 번 정도의 실험으로 절반 이상 개선한 것이죠. 핵심 교훈은 “배치 사이즈가 가장 큰 레버였고, 주어진 시간 예산 안에서는 모델 용량보다 더 많은 스텝 수가 중요하다”는 점이었습니다.

그런데 생성 결과는 왜 엉망이었을까

문제는 여기서부터였습니다. 점수가 가장 좋았던 0.82 모델로 코드를 생성해 봤더니, import torch 다음에 ch ch ch ch…가 끝없이 반복되는 기괴한 루프가 나왔습니다. 또 다른 샘플은 w만 수없이 찍어 내고 있었죠. 클로드는 이 현상을 “탐욕적 저온도 샘플링에서 흔히 보이는 과적합 루프”라고 설명했습니다.

그래서 저희는 지표는 조금 나쁘지만 생성 결과의 다양성은 더 나은 중간 지점을 찾아봤습니다. 최종적으로 BPB 1.66짜리 모델이 그나마 파이썬 코드다운 모양새를 갖춘 출력을 내놓았습니다. max_length 같은 변수 정의를 시도하는 수준까지는 올라왔고, 실제로 돌아가진 않지만 베이스라인과 비교하면 분명히 개선된 모습이었죠.

핵심 교훈: BPB 평가와 생성은 다른 시험이다

왜 가장 좋은 점수의 모델이 가장 나쁜 생성 결과를 냈는가? 클로드의 설명이 명쾌했습니다. 평가와 생성은 서로 다른 게임이라는 것입니다.

BPB 평가는 티처 포싱(teacher forcing) 으로 이루어집니다. 매 위치마다 모델에게 “정답 이전 토큰”을 그대로 쥐여 주고, 단 한 단계만 예측하게 하죠. 즉 “완벽한 문맥이 주어졌을 때 다음 바이트에 얼마나 덜 놀라는가”를 재는 시험입니다. 반면 실제 생성은 자기회귀(auto-regressive) 방식이라서, 모델은 자기가 방금 뱉어낸 토큰을 다시 입력으로 받습니다. 작은 오류라도 이어지는 단계에서 눈덩이처럼 불어나죠.

클로드는 이를 객관식 시험과 에세이 쓰기에 비유했습니다. BPB 평가는 객관식입니다. 진짜 코드가 주어진 상태에서 “다음 토큰은?” 하고 묻는 거라, 공백이나 self, def처럼 자주 등장하는 토큰을 찍기만 해도 평균 점수가 잘 나옵니다. 반면 생성은 빈 종이에서 에세이를 쓰는 것과 같습니다. 작은 모델이 배운 것이 “이 토큰은 자주 나온다”뿐이라면, 그 인기 토큰만 끝없이 반복해 쓰게 되고, 그게 바로 우리가 본 ch ch ch… 루프의 정체입니다.

마무리: 실패에서 배우는 실험

솔직히 말해 이번 실험은 지표 면에서는 성공, 실질 면에서는 절반의 실패였습니다. 어린이 동화나 악보(sheet music) 데이터는 반복적이고 단순해서 작은 모델도 진짜 패턴을 학습할 수 있지만, 파이썬 코드는 문법과 의미, 변수 이름의 지역 규칙까지 모두 얽혀 있어서 소비자용 GPU에서 돌리는 초소형 모델로는 벽이 있었습니다.

저는 결과를 조작하지 않습니다. 잘 안 된 실험도 있는 그대로 보여 드리는 게 이 채널의 원칙입니다. 이번 실험이 실패였다면, 그 실패에서 얻은 교훈이 다음 오토리서치 실험의 설계를 더 날카롭게 만들어 줄 것입니다. 다음 편에서 또 다른 데이터셋과 가설로 찾아뵙겠습니다. 구독과 좋아요, 그리고 여러분이 오토리서치를 어떻게 활용하고 있는지 댓글로 알려 주세요.

지표는 내려갔는데 코드는 더 엉망이 된 이유: 오토리서치로 들여다본 작은 언어모델의 한계

원본: YouTube · 업로드: 2026-03-20 · 채널: Onchain AI Garage (@OnchainAIGarage) · 길이: 17분

서론: “숫자가 좋아졌는데 결과는 왜 더 나빠졌을까”

안드레이 카파시(Andrej Karpathy)가 2026년 3월에 공개한 오토리서치(Autoresearch)는, 단 630줄짜리 파이썬 스크립트로 AI 에이전트가 스스로 가설을 세우고 학습 코드를 수정하고 실험을 돌리고 결과를 분석하는 “1GPU짜리 자율 연구실”입니다. 실험 하나가 대략 5분 안에 끝나기 때문에 밤사이 100번 가까운 반복이 가능합니다(Abhishek Gautam — 630-Line Script That Does AI Research Itself, softmaxdata — What is Autoresearch).

Onchain AI Garage 채널의 이번 영상은 바로 이 도구를 “타이니 스토리즈(Tiny Stories)“에서 한 단계 더 밀어붙여, 깃허브(GitHub)에서 긁어온 실제 파이썬 코드(CodeParrot Clean)를 학습시키는 후속 실험입니다. 결과는 묘했습니다. 지표상으로는 검증 BPB(bits per byte)가 베이스라인 1.85에서 0.82로 반토막 이상 떨어졌지만, 정작 그 “최고 점수 모델”이 생성한 파이썬 코드는 import torch 뒤로 ch ch ch…만 끝없이 반복되는 괴물이었습니다. 이 글에서는 왜 그런 일이 벌어졌는지, 그리고 그것이 오늘날 작은 언어 모델(small language model)에 시사하는 바가 무엇인지를 정리합니다.

본론 1. 오토리서치라는 아이디어: “잠든 사이 모델이 스스로 실험한다”

오토리서치의 발상은 단순하고 도발적입니다. 보통 머신러닝 연구자는 “이 하이퍼파라미터를 올려 볼까, 저 층을 깊게 해 볼까”를 손으로 바꾸며 반복합니다. 카파시는 이 루프 자체를 LLM 에이전트에게 넘겨 버렸습니다. 에이전트는 program.md에 적힌 연구 목표를 읽고, train.py를 수정하고, 학습을 돌리고, 검증 지표를 읽고, 다음 가설을 스스로 결정합니다. 본체는 nanochat 기반 GPT를 단일 GPU에서 학습 가능하도록 만든 미니멀 리그로, 한 실험이 약 5분이라 하룻밤이면 100회 순환이 가능합니다(Medium — One GPU Into an Autonomous Research Lab).

이 영상의 실험자는 그 첫 적용 대상을 카파시가 준 기본 타이니 스토리즈 데이터셋으로 잡았고, 2시간 만에 56% 성능 향상이라는 체감 가능한 결과를 얻었습니다. 그래서 이번에는 같은 프레임워크를 파이썬 코드라는 훨씬 거친 도메인으로 확장한 것입니다. 프레임워크 자체는 거의 손대지 않고, 단지 program.md에 “이 데이터셋은 타이니 스토리즈보다 훨씬 복잡하고 다양하니, 더 높은 베이스라인과 느린 수렴을 예상하라”는 한 줄의 안내만 추가했습니다.

본론 2. 에이전트가 찾아낸 레버: 배치 사이즈, 학습률, 그리고 깊이의 반전

오토리서치가 자동으로 수행한 하이퍼파라미터 탐색은 그 자체로 흥미로운 기록입니다. 에이전트가 가장 먼저 건드린 것은 모델 깊이였습니다. “코드는 구조가 복잡하니 층을 더 쌓자”는 직관으로 8층에서 12층으로 확장했지만, 주어진 시간 예산 안에서는 학습 스텝이 부족해져 오히려 BPB가 1.87로 올라갔습니다. 에이전트는 곧바로 깊이 축을 접고 매트릭스 학습률(matrix learning rate)로 전환했습니다. 0.10 근방에서 최적점을 찾았고, 0.14에서는 다시 오버슈팅이 발생했습니다.

진짜 돌파구는 배치 사이즈 축소에서 나왔습니다. 2의 19승에서 시작해 꾸준히 줄이며 1.619 → 1.03 → 0.88까지 BPB를 끌어내렸고, 결국 2의 14승 지점에서 스위트 스팟을 찾았습니다. 고정된 시간 예산 안에서는 “큰 배치로 적은 스텝을 밟는 것”보다 “작은 배치로 더 많이 업데이트하는 것”이 유리하다는, 어떻게 보면 교과서적이지만 실제 데이터에서 재확인하기 쉽지 않은 결론을 에이전트가 스스로 도달한 셈입니다.

그 뒤에 에이전트는 임베딩 학습률, 웜다운 비율, 가중치 감쇠, 슬라이딩 윈도우 길이, 헤드 차원 등을 하나씩 시도했지만 의미 있는 이득은 없었습니다. 재미있는 건 마지막 반전입니다. 처음에 실패했던 깊이 축을 다시 꺼내, 이번엔 반대로 줄여 본 것. 그리고 이것이 먹혀 최종 BPB 0.82에 도달했습니다. 같은 축이라도 다른 맥락에서는 정답이 뒤집힐 수 있다는, 자동화된 탐색의 묘미가 드러나는 장면입니다.

본론 3. 반전: 지표는 이겼지만 생성은 졌다

문제는 최종 모델이 실제로 코드를 생성했을 때 벌어졌습니다. Val BPB 0.82 — 숫자상으로는 최고점 — 의 모델은 import torch 뒤로 ch가 끝없이 반복되거나, 변수 w만 수백 번 찍어 내는 퇴행적인 출력을 내놓았습니다. 클로드(Claude)는 이를 “탐욕적(greedy) 저온도 샘플링에서 나타나는 전형적인 반복 붕괴”라고 진단했습니다.

실험자는 결국 점수는 조금 나쁘지만 생성 결과의 다양성이 살아 있는 중간 지점으로 되돌아갔습니다. BPB 1.66짜리 모델이 그나마 파이썬 코드다운 형태 — 클래스 정의 시도, max_length 같은 변수 선언 — 를 내놓았고, 실제로 실행되지는 않지만 베이스라인에 비하면 눈에 띄는 개선이었습니다. 요컨대 가장 좋은 지표가 가장 좋은 모델은 아니었습니다.

본론 4. 왜 그런가: 티처 포싱과 노출 편향(exposure bias)

이 괴리는 오토리서치의 버그가 아니라 언어 모델 평가의 구조적 한계에서 비롯됩니다. BPB(혹은 퍼플렉서티, perplexity)는 티처 포싱(teacher forcing) 환경에서 측정됩니다. 매 토큰 위치마다 모델은 “진짜 이전 토큰”을 입력으로 받고, 바로 다음 한 토큰만 맞히면 됩니다. 이건 객관식 시험에 가깝습니다 — 완벽한 지문이 주어진 상태에서 정답 하나만 고르면 되죠.

반면 실제 생성은 자기회귀(auto-regressive) 방식입니다. 모델은 자기가 방금 내뱉은 토큰을 다시 입력으로 받습니다. 이때 훈련과 테스트의 입력 분포가 달라지면서 작은 오차가 눈덩이처럼 불어나는 현상, 즉 노출 편향(exposure bias) 이 발생합니다. 연구 커뮤니티에서는 이 문제가 이미 오래전부터 지적돼 왔고, 퍼플렉서티만으로는 이 누적 오차를 잡아낼 수 없다는 사실이 정량적으로도 보고돼 있습니다(Why Exposure Bias Matters — arXiv, Language Model Evaluation Beyond Perplexity — ACL Anthology).

클로드가 영상에서 든 비유가 이를 잘 요약합니다. 티처 포싱 평가는 객관식 시험이고, 생성은 빈 종이에 에세이를 쓰는 시험입니다. 아주 작은 모델이 학습 시간이 부족한 상태에서 배울 수 있는 것은 “어떤 토큰이 자주 등장하는가”뿐입니다. 그 모델은 객관식 시험에서는 self, 공백, def 같은 인기 토큰을 잘 찍기 때문에 평균 점수가 좋지만, 에세이에서는 그 인기 토큰만 무한히 반복하는 괴물이 됩니다. 퍼플렉서티가 낮다고 생성 품질이 좋은 것은 결코 아니라는 교훈이 이번 실험으로 다시 한 번 체감 가능한 형태로 드러난 것입니다.

본론 5. 도메인이 결정한다: 동화는 되고 코드는 안 되는 이유

같은 오토리서치, 같은 하드웨어, 같은 실험자인데 왜 타이니 스토리즈는 성공하고 파이썬 코드는 실패했을까요? 답은 “데이터의 구조적 단순성”에 있습니다. 어린이 동화는 문장 구조가 반복적이고 어휘가 좁으며 장기 의존성이 약합니다. 시트 뮤직 데이터도 비슷한 특성이 있죠. 작은 모델이라도 진짜 패턴을 학습할 여지가 충분합니다.

반면 파이썬 코드는 문법과 의미, 지역 변수의 스코프, 들여쓰기로 표현되는 블록 구조, 길게 이어지는 함수 간 의존 등 서로 다른 차원의 규칙이 동시에 얽혀 있습니다. 이런 다차원 규칙을 학습하려면 일정 수준 이상의 모델 용량과 훨씬 긴 학습 시간이 필수적입니다. 시간 예산이 5분 단위인 nanochat 규모에서는 애초에 “다음 토큰 예측 확률”만 빠르게 외우는 쪽이 점수에 유리하고, 그 결과가 바로 반복 붕괴입니다.

핵심 인사이트

• 지표는 시험지일 뿐, 실력이 아니다. 퍼플렉서티/BPB는 티처 포싱 기반 객관식 시험이며, 자기회귀 생성이라는 에세이 시험과는 다른 능력을 측정한다. 두 시험의 점수가 어긋나는 것은 버그가 아니라 구조다.
• 오토리서치는 하이퍼파라미터 탐색을 놀랄 만큼 잘한다, 단 평가 지표가 올바를 때만. 에이전트는 “정의된 지표”를 무자비하게 최적화한다. 지표가 실제 쓸모와 어긋나 있으면, 자동화는 그 어긋남을 가속할 뿐이다.
• 작은 모델은 단순한 도메인에서만 인상적인 결과를 낸다. 동화·악보는 되지만 일반 코드는 안 된다. 이건 실험자의 실력 문제가 아니라 정보 이론적 한계에 가깝다.
• 탐색 경로는 비단조적이다. 초반에 “깊이를 올리면 나빠진다”가 나왔다고 해서 깊이 축을 버려선 안 된다. 같은 축이라도 반대 방향에서 최적이 나올 수 있다 — 이번 실험에서 최종 개선은 바로 그 반전에서 나왔다.
• 실패를 공개하는 실험이 더 많은 것을 가르친다. 잘 된 자동화 결과만 모아 보여 주는 데모는 이 산업의 고질병이다. 이번 영상이 보여 준 “지표는 이겼는데 생성은 졌다”는 실패는, 같은 프레임워크를 쓰는 다른 연구자들이 같은 함정에 빠지지 않도록 돕는다.

더 알아보기

• Andrej Karpathy’s 630-Line Python Script That Does AI Research Itself — Abhishek Gautam
• What is Karpathy’s Autoresearch and how does it work? — softmaxdata
• Karpathy Just Turned One GPU Into an Autonomous Research Lab — Medium
• Why Exposure Bias Matters: An Imitation Learning Perspective of Error Accumulation — arXiv
• Language Model Evaluation Beyond Perplexity — ACL Anthology
• Perplexity for LLM Evaluation — Comet

토론: “오토리서치가 낮춘 BPB 점수는 코드 생성 모델의 진짜 개선으로 볼 수 있는가”

논제: 시간 예산이 고정된 소형 LLM 실험에서, 자동 에이전트가 달성한 Val BPB 개선을 “모델이 정말 좋아졌다”고 해석해도 되는가, 아니면 지표 최적화의 허상일 뿐인가?

Round 1

🟢 Pro — “BPB 개선은 분명한 학습 신호이고, 오토리서치는 그것을 정직하게 낮췄다”

BPB(bits per byte)는 검증 세트 위에서 모델이 실제 데이터를 얼마나 압축해 낼 수 있는지를 측정하는, 정보 이론적으로 근거가 튼튼한 지표입니다. 베이스라인 1.85에서 0.82까지 절반 이하로 줄었다는 건 모델이 공백·키워드·구조 패턴 수준에서라도 진짜 분포를 학습했음을 뜻합니다. 지표가 거짓말을 한 게 아니라, 그 지표가 측정하는 능력이 실제로 향상된 것이죠.

특히 주목할 점은 오토리서치 에이전트가 그 과정을 재현 가능한 기록으로 남겼다는 것입니다. 어떤 가설을 세웠고, 어떤 축을 움직였고, 어떤 결과가 돌아왔는지가 전부 로그에 찍혔습니다. 수작업 튜닝이라면 실험자가 결과를 선별해서 공개하기 쉽지만, 자동화된 로그는 그 편향을 줄입니다. 배치 사이즈가 가장 큰 레버였다는 결론은 이후 같은 프레임워크를 쓰는 모든 연구자에게 전이되는 지식이고, 이는 “허상”이라 부르기엔 너무 유용한 결과입니다.

또한 이번 실험의 목적은 “배포 가능한 코드 생성기 제작”이 아니라 “오토리서치로 하이퍼파라미터 탐색이 어디까지 가능한가”였습니다. 지표 단위의 개선을 증명한 것만으로 실험 목적은 이미 달성된 것이며, 생성 품질은 별개의 다음 문제입니다.

🔴 Con — “낮아진 BPB가 의미 없는 반복 붕괴로 이어졌다면, 그건 개선이 아니라 오버피팅의 다른 이름이다”

점수가 반토막 났다는 건 분명 인상적인 그래프입니다. 그런데 그 “최고 점수 모델”이 실제로 생성한 것은 ch ch ch…의 무한 반복이었습니다. 이건 그냥 구린 모델이 아니라, 지표가 측정하는 방향으로만 최적화된 모델이 정확히 어떤 모습인지를 보여 주는 병리적 사례입니다. 점수가 내려갔다는 사실 자체는 맞지만, “모델이 정말 좋아졌다”는 해석은 객관식 시험 점수를 보고 “이 학생 에세이도 잘 쓸 것”이라고 추정하는 것과 같습니다.

오토리서치는 정의된 목적 함수를 무자비하게 최적화합니다. 그 목적 함수가 잘못 정의돼 있으면, 자동화는 그 오류를 가속할 뿐입니다. 이번 경우 BPB는 티처 포싱 환경에서 측정되기 때문에 자주 나오는 토큰을 잘 찍는 모델이 과도하게 보상받습니다. 그 결과가 “공백과 self만 반복하는 모델이 BPB 0.82”라는 기괴한 결론입니다.

그래서 이번 실험의 진짜 교훈은 “오토리서치는 강력하다”가 아니라 “지표를 잘못 고르면 자동화가 그 함정을 더 빠르고 깊게 파 준다”입니다. BPB 개선을 코드 생성 모델의 개선으로 해석하는 것은 방법론적으로 부적절합니다.

Round 2

🟢 Pro (재반론) — Con의 반복 붕괴 공격에 답한다

Con의 첫째 논점인 “반복 붕괴는 개선이 아니다”에 대해 먼저 반박하겠습니다. 반복 붕괴는 BPB가 거짓말을 한 결과가 아니라, 모델 용량과 학습 시간이 부족한 상태에서 디코딩 전략(탐욕적 저온도 샘플링)이 노출 편향을 증폭시킨 결과입니다. 이건 학습 측면의 문제가 아니라 추론 시점 결정의 문제이고, 같은 가중치에 누클리어스 샘플링(nucleus sampling)이나 높은 온도를 적용하면 전혀 다른 출력이 나옵니다. 즉 “지표는 거짓말, 모델은 쓰레기”라는 프레임 자체가 과도하게 단순합니다.

Con의 둘째 논점인 “오토리서치는 잘못된 목적 함수를 가속할 뿐”에 대해서도 과장이 있습니다. 오토리서치는 지표 최적화 루프일 뿐만 아니라, 그 과정에서 탐색 축 자체에 대한 메타 지식을 쌓아 줍니다. 이번 실험에서 “배치 사이즈가 가장 큰 레버이고 깊이는 양방향으로 테스트해야 한다”는 교훈은 어떤 지표를 쓰든 다음 실험에 재사용됩니다. 이건 목적 함수와 독립된 구조적 지식이고, 지표가 불완전해도 값진 산출물입니다.

마지막으로 실험자 본인이 BPB 0.82 모델의 출력 실패를 있는 그대로 공개했다는 점을 기억해야 합니다. 그건 오토리서치의 실패가 아니라 사람–에이전트 협업의 정직한 실패 공개입니다. 그 투명성 덕분에 우리가 지금 이 토론을 할 수 있는 것이죠.

🔴 Con (재반박) — Pro의 낙관을 하나씩 해체한다

Pro의 첫째 주장인 “BPB는 정보 이론적으로 튼튼한 지표”에 대해 반박합니다. 정보 이론적으로 튼튼하다는 것과 “지금 이 소형 모델·짧은 학습·고정 시간 예산이라는 조건에서 유효한 신호다”라는 것은 완전히 다른 명제입니다. 퍼플렉서티/BPB가 생성 품질을 반영하지 못하고 오차 누적을 포착하지 못한다는 것은 이미 머신러닝 문헌에서 정량적으로 보고돼 있습니다. Pro는 “근거가 튼튼한 지표”라는 수사로 그 한계를 가려 버렸습니다.

Pro의 둘째 주장인 “오토리서치 로그가 재현 가능하니 편향이 적다”에도 동의할 수 없습니다. 기록이 많다고 해석이 옳아지는 것은 아닙니다. 중요한 건 어떤 지표로 “좋다”를 판정했느냐이고, 여기서 판정 기준은 BPB 단 하나였습니다. 자동화된 20번의 실험 내내 단 한 번도 생성 품질 평가는 루프에 들어가지 않았습니다. 이 편향은 로그의 양으로 해결되지 않습니다.

Pro의 셋째 주장인 “이번 실험의 목적은 하이퍼파라미터 탐색 가능성 증명일 뿐”이라는 것도 이동 골대(moving goalpost)에 가깝습니다. 영상의 서사는 “코드를 학습시켜 보자”였고, 비교 대상은 타이니 스토리즈에서의 성공이었습니다. 실험자 스스로 마지막에 “이번 건 절반의 실패”라고 인정했습니다. 나중에 와서 “탐색 실험일 뿐이었다”고 범위를 축소하는 것은 사후 합리화입니다.

Round 3

🟢 Pro — Con의 Round 2 재반박을 다시 반박한다

Con이 Round 2에서 제기한 첫째 반박, “BPB가 소형 모델에서는 유효하지 않다”에 대해 답합니다. Con의 지적은 학계 문헌을 근거로 들지만, 바로 그 문헌들 역시 “퍼플렉서티는 다른 지표와 함께 써야 한다”고 말할 뿐 “단독으로 쓰면 무의미하다”고 선언하지는 않습니다. 즉 BPB는 필요조건이고, 그것이 내려간 것 자체는 학습이 일어났다는 증거입니다. 이번 실험이 부족했던 것은 “BPB 지표 자체”가 아니라 BPB 옆에 함께 봤어야 할 보조 지표였습니다. 그건 오토리서치의 실패가 아니라 프로토콜 설계의 개선 여지입니다.

Con이 Round 2에서 제기한 둘째 반박, “루프에 생성 평가가 없었다는 편향은 로그 양으로 해결되지 않는다”에 대해서도 부분적으로만 동의합니다. Con 말대로 이번 루프에는 생성 품질 평가가 없었죠. 하지만 오토리서치는 에이전트가 새 지표를 추가하도록 지시할 수 있는 열린 프레임워크입니다. 다음 라운드에서 “매 실험마다 10개 프롬프트로 생성하고, 반복률과 문법 유효성을 함께 측정하라”는 지시를 program.md에 한 줄 추가하면 끝납니다. 이번 실패는 프레임워크의 본질적 결함이 아니라 첫 시도의 구성 미비이고, 그건 오토리서치가 해결 가능한 방식으로 드러났다는 뜻입니다.

Con이 Round 2에서 제기한 셋째 반박, “이동 골대”라는 비판도 뒤집어 볼 수 있습니다. 영상의 마지막 메시지는 “실패에서 더 배운다”였고, 이건 과학적 태도 그 자체입니다. 실험의 목적은 결과가 나오고 나서야 비로소 재해석될 수 있는 것이고, 그 재해석의 결과가 “BPB만으론 부족하다”는 것이라면 이 실험은 성공적으로 실패한 것입니다.

🔴 Con — Pro의 Round 2 재반론을 마지막으로 해체한다

Pro가 Round 2에서 제기한 첫째 방어, “반복 붕괴는 디코딩 전략 탓이지 학습 탓이 아니다”에 대해 반박합니다. 이건 책임 전가입니다. 누클리어스 샘플링이나 높은 온도로 바꿨을 때 “무의미한 반복 대신 무의미한 랜덤”이 나왔다면, 그건 구제가 아니라 증상 변화일 뿐입니다. 근본 문제는 모델이 조건부 분포의 꼬리 부분을 학습하지 못했다는 것이고, 디코딩 트릭은 그 빈 공간을 메우지 못합니다. BPB가 낮다는 사실과 생성이 무너지는 사실이 공존한다는 점 자체가, 학습된 표현이 생성에 필요한 종류의 지식을 담지 못했다는 강력한 증거입니다.

Pro가 Round 2에서 제기한 둘째 방어, “오토리서치는 축 자체에 대한 메타 지식을 준다”에 대해서도 의심이 있습니다. 이번에 얻은 “배치 사이즈가 가장 큰 레버”라는 지식은 타이니 스토리즈에서도 이미 나왔던 결론과 거의 같습니다. 즉 자동화가 발견한 메타 지식이라기보다는 “소규모 예산·소형 모델 체제에서 일관되게 관찰되는 상식”에 가깝습니다. 오토리서치가 대체한 건 창의적 가설 생성이 아니라 그리드 서치 수준의 반복 작업이고, 이는 “AI가 스스로 연구한다”는 서사가 주장하는 것만큼 급진적인 기여가 아닙니다.

Pro가 Round 2에서 제기한 셋째 방어, “실패의 투명한 공개 자체가 가치”라는 것에는 부분적으로 동의합니다. 그러나 투명성은 해석의 올바름을 대체하지 못합니다. 이 영상의 투명성은 칭찬할 일이지만, 그것이 “BPB 개선 = 모델 개선”이라는 해석을 정당화해 주지는 않습니다. 투명성과 방법론은 별개의 미덕입니다.

🧭 종합

합의 지점

• BPB가 내려간 것 자체는 학습이 일어났다는 객관적 신호다. 모델이 공백·키워드·구조 패턴 같은 지역 통계를 학습했다는 점은 양쪽 모두 인정한다.
• BPB 단독 평가로는 생성 품질을 보증할 수 없다. 자기회귀 생성의 노출 편향 문제는 이론적·경험적으로 잘 알려져 있으며, 이번 실험은 그 교과서 사례다.
• 오토리서치는 “정의된 목적 함수”에 대해 매우 효율적인 탐색기이다. 문제는 목적 함수 설계에 있다.

열린 질문

• 이번 실험에 생성 품질 평가(예: 반복률, AST 파싱 성공률, 간단한 단위 테스트 통과율)를 루프에 포함시켰다면, 에이전트는 0.82가 아닌 1.66 근처의 모델을 스스로 최적해로 찾아냈을까? 즉 목적 함수 교체만으로 해결되는 문제인가, 아니면 모델 용량이 본질적 제약인가?
• 소형 모델의 시간 예산 최적화 관점에서, 타이니 스토리즈 같은 단순 도메인과 코드 같은 복잡 도메인 사이에 존재하는 “학습 가능성의 상전이선” 은 어디쯤에 있는가?
• 오토리서치가 앞으로 “자동화된 지표 설계”까지 수행할 수 있을까? 즉 에이전트 스스로 “BPB만으로는 부족하다”고 판단해 새 평가 지표를 추가하는 메타 루프는 가능한가?

더 나아간 관점

이 토론의 진짜 교훈은 Pro도 Con도 아닌 제3의 지점에 있습니다. 오토리서치의 가치는 “지표를 낮춰 주는 도구”라는 1차적 정의에 있지 않고, 사람이 지표 설계를 얼마나 잘했는지를 빠르게 드러내 주는 거울이라는 2차적 정의에 있습니다. 잘못된 지표를 주면 20번의 실험 만에 그 지표의 결함이 병리적인 형태로 드러나고, 좋은 지표를 주면 빠른 순환 속에서 진짜 개선이 쌓입니다.

그렇다면 연구자의 역할은 “하이퍼파라미터를 손으로 돌리는 사람”에서 “평가 프로토콜을 설계하는 사람”으로 이동합니다. 이는 소프트웨어 엔지니어링에서 “테스트 코드의 품질이 제품의 품질을 결정한다”는 오래된 격언의 기계학습 버전이기도 합니다. 이번 영상의 실패는 그 격언을 가장 비싼 방식으로 재확인시켜 준 셈이고, 그것이 바로 실패를 공개하는 실험이 주는 선물입니다.

또 하나 짚어야 할 지점은 도메인별 “평가–생성 일치도”가 지표 자체만큼 중요한 속성이라는 것입니다. 타이니 스토리즈처럼 문법이 단순하고 어휘 분포가 좁은 도메인에서는 티처 포싱 기반 BPB와 자기회귀 생성 품질이 거의 일치합니다. 다음 토큰을 잘 맞히는 능력이 곧 다음 문장을 잘 쓰는 능력이죠. 반면 파이썬 코드처럼 장기 의존성과 복잡한 지역 규칙이 얽힌 도메인에서는 두 능력 사이에 틈이 벌어집니다. 이 틈의 크기는 데이터셋의 고유 속성이며, 새로운 도메인에 오토리서치를 적용할 때 가장 먼저 측정해야 할 값입니다. “이 데이터셋에서 BPB는 얼마나 믿을 만한 프록시인가”를 몇 번의 사람 평가로 확인하지 않고 자동 루프를 돌리는 것은, 교정되지 않은 체중계로 다이어트 결과를 판정하는 것과 같습니다.

마지막으로 이번 토론은 “소형 모델 연구의 정직함”이라는 메타 윤리 문제와도 닿아 있습니다. 거대 연구소가 공개하는 벤치마크는 대부분 성공 사례 위주이고, 실패한 실험은 로그 깊숙이 묻힙니다. 반면 이번 영상처럼 개인 연구자가 실패를 공개할 때, 그 데이터는 분야 전체의 학습률을 끌어올립니다. Pro와 Con이 끝내 완전히 합의하지 못한 지점 — “BPB 개선을 어디까지 개선으로 볼 것인가” — 은 사실 한 사람이 결정할 문제가 아니라, 이런 공개된 실패 사례가 누적되면서 커뮤니티 차원에서 천천히 좁혀 가야 할 질문입니다. 다음 오토리서치 라운드는 “모델을 더 크게”가 아니라 “평가를 더 똑똑하게”로 가야 한다는 것이, 이 토론이 합의할 수 있는 가장 멀리 간 결론입니다.

So a couple days ago, I did a video about my experiment with auto research from Andrej Karpathy.
And I just used the Tiny Stories repo that he had presented for smaller GPUs.
And I got a pretty good result.
I got 56% improvement in performance in just like two hours.
And this was a fun little experiment, but it got me really thinking, what else can I do with this?
I was able to train my model to go from this baseline, which is pretty much gibberish, into this very coherent grammatical story.
So I was able to train it using these stories, but I wanted to see what else I could do.
So I think we're going to run a couple different experiments over the next couple weeks,
because I kind of got addicted to this whole training my own little mini models.
So today what we're going to do is we're going to do with code.
So for the data set for this, we're going to be using...
CodeParrot Clean, which is a small code base or data set of Python scripts or Python code.
It's a data set of Python files from GitHub.
And this should hopefully work out well.
We're going to use a sample of this.
So I know Python myself, so I'll be able to tell at least if something looks wrong or looks right.
So I had to...
Step one was I had to get Claude to review this data set, download the data set,
check everything over, and then kind of reconfigure the prepare.py file
so that it could fit this data set, the Python code, instead of the tiny stories.
But it's done that.
It's completed step one, downloading the Python files.
And then it's going to do the prepare script.
So I just confirmed that it's ready.
And now it's going to run prepare.py to prepare the training.
You need this pip install uv, which I didn't have on this machine.
So in the program.md file, I'm not changing anything, really.
The only thing I'm adding is a note about the data set, that it's a Python source code.
And it's more complex and varied than tiny stories.
Expect a higher baseline and slower convergence, which is to be expected here.
I don't think we're going to get as quickly as...
a huge jump in performance that we got with the tiny stories.
But that's basically it.
I'm going to let the agent just kind of run with it and try different hypotheses.
Okay, so step two is done.
The tokenizer trained on the code data.
So next is we're going to kick off the training.
Go ahead.
Let me know the baseline.
And once again, just to give you an idea of what it's training on,
these are the Python scripts.
That it's using, or the code snippets, you can see here, stuff like this.
Okay, so it's training.
The way this is going to run, I'm going to kind of just let it run, try different hypotheses.
I'll let you know.
I'll check back in and let you know which ones they decide to keep.
Which ones show significant improvement.
And we'll see how much we can prove on our baseline.
We're going to find out what our baseline is right now.
So the baseline completed.
And these are the results.
Okay.
The key metric is this Val B P B, which our baseline is going to be 1.84.
So it's writing a sample script so that it can output what the current version of the model would produce in terms of code.
And then once we finish the training and the Val P P P goes down, we'll be able to compare it with what we have after the training.
So let's see what we have.
So you could see.
The snippets here based on these prompts import torch.
I mean, I'm not a Python expert, but I don't think that's going to work.
It's mostly incoherent.
Yeah.
I mean, some of this class is it tries to define, but yeah, this is not going to be workable code.
So yeah.
And Claude says it himself.
Here are the samples from the baseline model as expected with only five minutes of training.
The output is mostly incoherent.
It picked up some structural patterns, imports, comments, license headers, but it can't produce any meaningful code yet.
So this is the baseline and we're going to see if we can actually improve upon this with the auto research and to produce something that is actual looks actually like code.
So we're going to run the training loop.
It's going to read the program MD file, which it's going to retrain P Y fully set up the branch and then begin the training.
So I pretty much let it develop its own hypothesis.
If you remember in the previous episodes, some of the key factors, key metrics that we saw were depth and batch size when we were doing the tiny stories and the music, the sheet music one, those were two key factors that really impacted the score.
Okay.
So there was the first run, the baseline that's going to be logged 1.85.
This is taking a bit longer than each one is taking more than five minutes.
Um, not too long, around eight minutes.
This is certainly the code is more complex than what we were doing with tiny stories or with the sheet music.
So the first thing is going to try to do is mess around with the depth from eight to 12 layers.
More layers should help with the code structural complexity, and we have a VRAM headroom, so they're going to try to do more depth, which as I've described before means more processing stages.
And we found that with the tiny stories, at least less depth, actually.
You had a better result because the stories were so simple, but because the code is complicated and our data set is a lot more diverse, perhaps having more depth in this case will actually have a better result, but we'll see.
The result was actually worse.
It went up to one, eight, seven by increasing in depth.
Oh, the deeper model heard it due to fewer training steps, steps in the time budget.
Now it's going to try increasing the learning rate.
Um, the, for the matrix learning rate, it's going to try it.
Okay.
Bump that up a little bit.
So let's see what it gets from there.
And this matrix learning rate, I think I've discussed it before, but it's basically how big of a step the model takes when it's updating its internal transformation tables during training.
So basically if the number is too high, the nudges are too big and the model overshoots and never really settles.
If it's too low, it's the, the nudges are tiny.
And the training just takes forever.
So what you want is just like a steady improvement with each step though.
It's adjusting.
The, the matrix learning rate here to try to find that just right amount with the learning rate, we dropped down to 1.83 versus the baseline.
So that's a good drop.
So now it's going to push it even further with a higher learning rate.
Okay.
We saw another decent improvement, so it's going to try even higher learning rate.
Okay.
So it found that increasing matrix learning rate to 0.10 at a better score, but when it went to 14, it overshot it.
So now it's going to try to test the warmup ratio to add a 10% warmup, warmup ratio to stabilize the early training.
We're going to, we had a big improvement by reducing batch size down to 1.619.
So more steps with a smaller batch size is much better.
So that's good.
Once again, batch size is a creep is a key metric here.
So we're down.
And we're going to try to reduce.
Batch size even more, see if that helps.
So it's just continued to kind of lower the batch size and we've been really getting good results from a point 1.61 down to 1.67 kept lowering it 1.03.
And then the last one was 0.88.
So really great progress.
So now it's trying to lower it again and see if we can get an even better score, but this has been the big winner from where we started to basically all the way down to 0.88.
The main factor was the batch size, decreasing it.
And like I've explained before, batch size is how many samples or segments the model will see before making adjustments.
So seeing fewer, fewer samples before making an adjustment here has paid off really well.
Another slight improvement, but you could see the gains are starting to so diminishing returns on the batch size reduction.
So diminishing returns on the batch size reduction.
So diminishing returns on the batch size reduction.
But it did go down from 0.88 to 0.87.
So it's going to try to go another level 2 to the 13th and see if we can squeeze out a little bit more, but it seems like we might be at the end of the batch size optimization.
Okay.
So we finally hit the wall with the batch size.
The last one went up.
So 2 to the 14th was the sweet spot for that.
So now it's going to try a different axis, increasing embedding learning rate from 0.6 to 1.6.
So now it's going to try a different axis, increasing embedding learning rate from 0.6 to 1.6.
Embeddings may need faster learning for code tokens.
So the embedding didn't work that well.
Increasing it didn't give us a slightly worse result.
So now it's going to try warm, warm down ratio.
It's probably going to try a bunch of random stuff.
We might be at the end of like major gains, but I'm going to let it try out a couple of things and see if we can get this number down a little bit more.
It's already pretty good.
It's down over a 50% from where we from the baseline.
But let's try to squeeze out a little bit more here.
now it's going to do a warm down ratio decrease the warm down ratio at the end so let it running
at full learning rate for longer okay so it tried a couple other things from there it didn't after
the warm down it did weight decay tried that didn't work try changing the window the sliding
windows to make it more long range didn't work tried to adjust the head dim didn't work aspect
ratio didn't work it finally found a good parameter in depth it lowered the depth you
remember at the beginning it actually tried to increase the depth and it didn't work so it kind
of abandoned the depth approach from there but then it came back at the end and tried to lower
the depth and it actually increased or rather decreased improve the results by decreasing the
valve bvp and we ended up getting uh 0.82
and that's down from the baseline of 1.85 so that's a pretty impressive improvement in only
20 20 experiments the key findings were that the batch size was the biggest lever
we went from 2 to 19th to 2 to 14th to cut the valve bbp in half depth 4 beats 8 because more
steps matter more than the model capacity in the current time budget
and the other tweaks didn't really move the lever one way so we did have a pretty good result
in terms of improving on the original baseline okay so the optimized output was this you can
see import torch and that's then a bunch of ch it got stuck in this weird loop and as claude
explains it's a heavy repetition this is a classic issue with greedy low temperature sampling on
models so basically it's just been way over fit and you can see this was another attempt at an
import torch and then just a bunch of w's the model is too small and under trained for a coherent
generation but the bigger issue was the batch size was just too small it just created these
these kind of loops so we tried to find one that was a little bit better that had diversity in the
output but that was actually even if it had a higher
value then we could get a better output so that was the reason we came up with this one
the final thing that we did was we found a very interesting value which is being able to
use a more well known word to call it the value of the output so this is our output
this is what we came up with so this was trying to find like a good balance so this one the the
bpp was 1.66 which is better than our baseline and you could see the output here import torch and this is not perfect either but it more closely resembles what a python script would look like than what our our first baseline was here you could see that we have a nice nice
and we have a nice nice
see it's trying to define terms max length it's not perfect obviously if you ran the syscode it
wouldn't work but it is an improvement on what we had in the baseline so this is kind of a good
example i asked claude about this about why our optimized valve bpp1 created such loops so it
comes down to the difference between evaluation and generation bpp evaluation uses teacher forcing
at every position the model gets the real previous tokens and just predicts the next one so it's
measuring given perfect context how surprised you by the next byte so generation is auto-regressive
the model feeds on its own inputs so any small error compounds because the next production is
based on wrong contacts so even though the evaluation was fine when you're actually trying
to generate code or generate something it doesn't it may not necessarily have the best output so
low bbp does not necessarily mean good generation bbb rewards predicting common patterns generation
requires learning the full conditional distribution which needs model capacity and
stable training so in simple terms think of it like a student taking a multiple choice test
versus writing an essay the bpp evaluation is like a multiple choice you're shown real code and asked
what comes next
the tiny model got really good at always guessing the most popular answer
and since common tokens like spaces self-death appear everywhere
always guessing popular stuff scored very well on average but generation
is like writing an essay from scratch now the model has to build on what it just wrote
if all of it learned was these tokens are popular it just writes the same popular token over and
over and that's why we saw the chchch and just running into those loops bigger models actually
learn full patterns but this tiny model this these coding snippets were just not suitable so this was
a learning process certainly for me um i didn't know going into this whether or not it would be
successful and even though we got the evaluation score down a lot lower the actual output was
obviously not not better in the fully optimized version so not every experiment's going to be
successful fully successful the music one worked out great but i think it's going to be a lot better
but this one uh didn't have the same great great output at the end but like i say this shows i'm not
faking results i'll show something even if it doesn't work and even though this one failed
we kind of learned a lot here about why you need different kind of processes for different data sets
and what works best so i asked claude why did this process work better for children's stories
the children's stories are simple and repetitive and so is the sheet music so even a small fast
train model can learn the actual patterns something like um this auto research that
i'm running just on my consumer computer not any major chips or anything no huge gpus
um trying to trying to train a coding agent in this environment just didn't work out whereas
something like children's stories was much simpler but i hope you learned something i learned
something certainly about in this experiment sometimes learn more when you fail at the end
but thank you
for watching we're going to keep trying these experiments see what works see what doesn't work
and learn across the way i have a couple other kind of auto research concepts planned now i can
use that what we learned here in the coding experiment to try to guide those next experiments
so they could be more successful but thank you for watching please subscribe leave a like leave
a comment how have you been using auto research and i'll see you in the next video