autoresearch program.md 실습: val_bpb 실험을 keep/discard로 관리하기 | DAKER 커뮤니티
program.md를 연구 운영 규칙으로 보고 train.py 실험 범위를 정리한 NotebookLM 카드.
autoresearch program.md는 에이전트에게 “어떤 파일을 읽고, 무엇을 바꾸고, 어떤 수치로 keep/discard를 판단할지”를 알려 주는 연구 운영 문서입니다. 2026년 7월 1일 기준 공식 program.md는 train.py만 수정하고 prepare.py와 evaluate_bpb는 고정하라는 경계를 분명히 둡니다.
val_bpb 실험 관리란, 5분 실행 뒤 validation bits per byte가 낮아졌는지와 코드 복잡도 비용을 함께 보고 keep, discard, crash를 기록하는 절차를 의미합니다.
오늘 배울 것은 무엇인가요?
한 줄 요약: Karpathy autoresearch 기준선 글에서 첫 baseline을 남겼다면, 이제 program.md 안에 “유지할 실험”과 “버릴 실험”의 기준을 써야 합니다.
run tag, branch, in-scope files, data check, results.tsv 초기화를 순서대로 봅니다.
train.py만 수정하고 prepare.py와 evaluation harness는 고정합니다.
val_bpb, memory_gb, status, description을 tab-separated로 남깁니다.
오늘의 경험/수치: 공식 program.md의 results.tsv는 commit, val_bpb, memory_gb, status, description 5개 열을 요구합니다.
program.md는 왜 단순 프롬프트보다 중요하나요?
자율 실험은 에이전트가 오래 돌수록 작은 실수를 크게 반복할 수 있습니다. program.md는 허용 파일, 금지 파일, metric, timeout, logging format, simplification 기준을 한곳에 적어 실험을 비교 가능한 형태로 묶습니다.
이 관점은 nanochat 전체 파이프라인 글의 실행 체크리스트와 이어집니다. 실험 루프 자체는 nanoGPT 학습 루프 글의 checkpoint 기록 습관과도 닮아 있습니다.
핵심 개념은 keep, discard, crash를 숫자와 복잡도로 나누는 것입니다
상태 | 판단 기준 | 기록 방법 |
|---|---|---|
keep | val_bpb가 낮아지고 복잡도 비용이 납득 가능함 | commit 유지, status keep |
discard | val_bpb가 같거나 나빠짐 또는 복잡도 비용이 큼 | 시작점으로 reset, status discard |
crash | OOM이나 버그로 metric을 얻지 못함 | val_bpb 0.000000, memory 0.0 |
baseline | 첫 실행 비교 기준 | 가장 먼저 results.tsv에 기록 |
val_bpb 개선 여부와 복잡도 비용으로 keep, discard, crash를 나누는 NotebookLM 비교 카드.
따라 해볼 실습은 어떤 순서인가요?
program.md 상단에 오늘 run tag와 branch 이름을 적습니다.
README.md, prepare.py, train.py를 읽는 단계를 체크박스로 둡니다.
“수정 가능: train.py만”과 “수정 금지: prepare.py, dependencies, evaluation harness”를 분리합니다.
results.tsv header를 commit, val_bpb, memory_gb, status, description 순서로 만듭니다.
run.log에서 grep으로 val_bpb와 peak_vram_mb를 뽑는 명령을 적습니다.
개선 폭이 작을 때 complexity cost를 어떻게 볼지 한 문장 규칙으로 남깁니다.
자주 막히는 지점은 무엇인가요?
results.tsv를 comma-separated로 만듭니다. 공식 program.md는 tab-separated를 요구합니다.
0.001 val_bpb 개선만 보고 복잡한 코드를 무조건 keep합니다.
crash를 그냥 지우고 넘어가서 어떤 아이디어가 실패했는지 잃어버립니다.
run이 10분을 넘겨도 계속 기다립니다. 공식 program.md는 timeout 실패 처리를 둡니다.
prepare.py의 evaluate_bpb까지 건드려 metric 자체를 바꿉니다.
다음 학습 연결은 무엇인가요?
GPT Tokenizer 실습에서 입력 단위를, microgpt 200라인 글에서 알고리즘 지도를, nanochat 파이프라인 지도에서 전체 실행 단계를 연결해 보면 program.md에 어떤 context를 더 넣어야 하는지 보입니다.
공식 출처는 어디까지 확인했나요?
2026년 7월 1일 KST 기준 Karpathy autoresearch program.md에서 setup, experimentation, output format, logging results, experiment loop 규칙을 확인했습니다.
README에서 autoresearch가 nanochat 기반 단일 GPU 학습 설정과 5분 고정 예산을 사용한다는 점을 재확인했습니다.
공개 본문 링크는 DAKER 정책에 따라 DAKER 학습 디렉터리와 확인된 DAKER 내부 학습 글만 넣었습니다.
자주 묻는 질문
program.md에는 아이디어 목록만 쓰면 되나요?
아닙니다. 아이디어보다 먼저 수정 가능 파일, 금지 파일, metric, logging, timeout, keep/discard 기준을 써야 합니다.
작은 val_bpb 개선은 항상 keep인가요?
항상 그렇지는 않습니다. 공식 program.md는 단순성 기준을 강조하므로, 작은 개선이 큰 복잡도를 만들면 discard가 더 나을 수 있습니다.
crash는 실패라서 기록하지 않아도 되나요?
기록해야 합니다. crash도 다음 아이디어를 줄이는 증거입니다. 공식 예시는 val_bpb 0.000000과 memory 0.0으로 남깁니다.
왜 prepare.py는 고정해야 하나요?
prepare.py에는 data loading, tokenizer, fixed evaluation이 들어 있습니다. 이것을 바꾸면 실험끼리 공정하게 비교하기 어렵습니다.
여러 에이전트를 바로 붙여도 되나요?
처음에는 한 에이전트와 한 results.tsv로 기준을 잡는 편이 낫습니다. 비교 기준이 안정된 뒤에 더 많은 에이전트를 논의하세요.
오늘 program.md에는 “좋은 아이디어”보다 “버릴 실험을 버리는 규칙”을 먼저 써 보세요.