Andrej Karpathy의 autoresearch는 잘 쓰인 Markdown 파일이 AI 에이전트를 하룻밤에 실제 과학적 발견을 하도록 지시할 수 있다는 것을 증명했습니다. 하지만 모든 program.md 파일이 동등하게 만들어지지는 않습니다.

Markdown 지침의 품질이 AI 에이전트 출력의 품질을 직접 결정합니다. 모호한 program.md는 무작위적이고 방향 없는 실험을 생성합니다. 정확한 것은 복합되는 집중적인 개선을 생성합니다.

실제로 작동하는 program.md를 작성하는 방법입니다.

좋은 program.md의 구조

ML 연구를 하든 에이전트 지시 다른 작업을 하든, 모든 효과적인 program.md에는 다섯 가지 섹션이 필요합니다.

1. 컨텍스트: 에이전트가 무엇을 알아야 하는가?

에이전트는 프로젝트에 대한 이해가 전혀 없는 상태에서 시작합니다. 첫 번째 임무는 지능적인 결정을 내릴 수 있을 만큼 충분한 컨텍스트를 제공하는 것입니다.

포함할 것:

프로젝트가 무엇을 하는지
코드베이스의 모습
주요 파일과 그 목적
도메인별 용어
현재 상태와 알려진 문제

건너뛸 것:

LLM이 이미 아는 명백한 정보
코드에서 읽을 수 있는 구현 세부 사항
현재 결정에 영향을 미치지 않는 이력

2. 목표: 에이전트가 무엇을 최적화해야 하는가?

이것이 가장 중요한 섹션입니다. 에이전트에게는 명확하고 측정 가능한 목표가 필요합니다.

autoresearch에서 목표는 간단합니다: val_bpb (검증 비트/바이트) 감소. 에이전트는 5분 훈련 실행마다 이것을 측정할 수 있습니다.

자신의 프로젝트에서는 에이전트가 평가할 수 있는 용어로 성공을 정의하세요:

“페이지 로드 시간을 2초 미만으로 줄이기”
“테스트 커버리지를 80% 이상으로 높이기”
“번들 크기를 최소 15% 줄이기”

“코드를 더 좋게 만들기”와 같은 모호한 목표는 모호한 결과를 생성합니다. 측정 가능한 목표는 집중적인 개선을 생성합니다.

3. 제약: 에이전트가 절대 해서는 안 되는 것은?

제약은 목표만큼 중요합니다. 없으면 에이전트가 당신이 원하지 않는 창의적인 솔루션을 찾을 수 있습니다 --- 빌드 속도를 “개선”하기 위해 모든 테스트를 삭제하는 것처럼.

일반적인 제약:

테스트 파일 또는 평가 코드 수정하지 않기
공개 API 변경하지 않기
새 의존성 도입하지 않기
메모리 예산 초과하지 않기
코드를 읽기 쉽고 유지 관리 가능하게 유지

autoresearch에서 핵심 제약은 train.py만 수정할 수 있다는 것입니다. 데이터 파이프라인, 평가 코드, 테스트 세트는 잠겨 있습니다. 이것은 에이전트가 메트릭을 조작하는 것을 방지합니다.

4. 전략: 에이전트가 어떻게 문제에 접근해야 하는가?

여기서 당신의 도메인 전문 지식이 빛납니다. 에이전트가 모르는 것들을 알고 있습니다 --- 어떤 방향이 유망하고 어떤 것이 막다른 길인지.

좋은 전략 지침:

“아키텍처 변경 전에 하이퍼파라미터 튜닝부터 시작”
“어텐션 메커니즘에 집중 --- 현재 구현이 최적화되지 않았을 수 있음”
“먼저 정규화 기술 시도: dropout, weight decay, layer norm”
“훈련 시간을 10% 이상 증가시키는 변경은 피하기”

나쁜 전략 지침:

“모든 것을 시도” (너무 모호함)
“learning rate를 0.001로 변경” (너무 구체적 --- 마이크로 관리 중)

최적점은 에이전트가 생산적인 범위 내에서 탐색할 수 있게 하는 방향적 안내입니다.

5. 평가: 에이전트가 성공을 어떻게 판단해야 하는가?

에이전트는 변경 사항이 도움이 되었는지 측정하는 방법을 알아야 합니다. autoresearch에서 이것은 루프에 내장되어 있습니다: val_bpb가 향상되면 변경 사항 유지. 그렇지 않으면 되돌리기.

다른 컨텍스트에서는 평가 기준을 정의하세요:

어떤 메트릭이 중요한가?
어떤 임계값이 개선으로 간주되는가?
에이전트가 모호한 결과를 어떻게 처리해야 하는가?
에이전트가 언제 멈추고 보고해야 하는가?

일반적인 실수

너무 모호함

“모델을 더 좋게 만들어”는 에이전트에게 아무 방향도 제공하지 않습니다. “더 좋다”가 무엇을 의미하는지, 어떻게 측정하는지, 어떤 접근 방법을 먼저 시도할지 구체적으로 지정하세요.

너무 구체적임

“47번 줄을 3e-4의 learning rate를 사용하도록 변경”은 에이전틱 엔지니어링의 목적을 무너뜨립니다. 구현을 지시하는 것이 아니라 방향을 설정해야 합니다. 에이전트가 탐색하게 하세요.

제약 잊기

제약 없이는 에이전트가 최소 저항 경로를 찾습니다 --- 이것이 원하는 것이 아닐 때가 많습니다. “훈련 시간을 줄여”라고 지시받은 에이전트는 다르게 말하지 않으면 훈련 데이터의 절반을 건너뛸 수 있습니다.

반복하지 않기

첫 번째 program.md는 완벽하지 않을 것입니다. 에이전트가 무엇을 하는지 지켜보고, 어디서 잘못되는지 보고, 지침을 업데이트하세요. 가장 좋은 program.md 파일은 수십 번의 반복을 통해 발전합니다.

반복 루프

program.md 작성은 일회성 프로세스가 아닙니다. 루프입니다:

초기 program.md 작성
에이전트 실행
에이전트가 한 일 검토
효과가 있었던 것과 없었던 것을 바탕으로 지침 업데이트
반복

각 반복은 지침을 더 정확하게 만듭니다. 몇 번의 라운드 후에는 일관되게 좋은 결과를 생성하는 program.md를 갖게 됩니다.

이것이 에이전틱 엔지니어링의 핵심 기술입니다: 코드를 작성하는 것이 아니라, 반복을 통해 점점 더 효과적인 에이전트 지침을 작성하는 것.

참조 라이브러리 구축

최고의 program.md 파일은 갑자기 나오지 않습니다. 도메인에 대한 깊은 지식 위에 구축됩니다 --- 문서, 논문, 모범 사례, 예시.

웹에서 유용한 참조 자료를 발견할 때 Markdown으로 저장하세요. 그런 다음 program.md를 작성할 때 관련 컨텍스트를 가져오고, 특정 기술을 인용하고, 에이전트에게 필요한 배경 지식을 제공할 수 있습니다.

autoresearch에서 최고의 결과를 얻는 연구자들은 단지 좋은 작가들이 아닙니다. 명확한 에이전트 지침으로 합성할 수 있는 잘 정리된 참조 자료를 갖춘 도메인 전문가들입니다.

Save는 어떤 웹페이지든 깨끗한 Markdown으로 변환합니다 --- 효과적인 program.md 파일을 구동하는 참조 라이브러리 구축에 완벽합니다. Save 무료로 사용해보기.