Claude Fable 5 같은 Mythos급 모델은 Anthropic에서 많은 사람이 일하는 방식을 바꾸었습니다. 저는 이 종류의 모델에서 더 많은 것을 얻기 위한 팁 두 가지를 공유하려고 합니다.
자기 수정 루프
최근 루프에 대한 관심이 큽니다. @bcherny는 자신의 일이 "루프를 쓰는 일"이라고 말한 적이 있습니다. 모델이 어떤 평가를 기준으로 더 나아지게 하는 것은 작업 성능을 높이는 흔한 방법입니다. Claude Code의 /goal과 Claude Managed Agent의 Outcomes는 이 일반적인 방법을 특정 작업에 적용하게 해 주는 기본 도구입니다.
저희 프롬프팅 가이드에서 말했듯이, Fable 5는 루프 안에서 스스로 고치는 일을 잘합니다. 잘 설계한 목표나 채점 기준은 Claude가 돌아가는 환경에 피드백을 더합니다. 그러면 Claude는 실행하고, 목표나 채점 기준을 통해 피드백을 모으고, 스스로 고친 뒤, 목표나 채점 기준을 만족할 때까지 계속 나아갈 수 있습니다.
제가 Fable을 테스트할 때 쓴 작은 예를 하나 공유하겠습니다. Parameter Golf는 8xH100에서 10분 안에 16MB 아티팩트에 들어가는 가장 좋은 모델을 학습시키는 오픈 소스 ML 엔지니어링 도전 과제입니다.
이것은 @karpathy의 autoresearch 프로젝트와 조금 비슷합니다. 에이전트가 기본 학습 코드(단일 train_gpt.py 파일)를 고치고, 학습을 시작하고, 로그를 확인하고, 점수를 읽고, 다음에 어떤 실험을 할지 정하는 능력을 테스트합니다.
저는 Claude Managed Agents(CMA)를 사용해 이 도전 과제에서 Fable 5와 Opus 4.7을 비교했습니다. CMA는 에이전트 하네스와 호스팅 샌드박스를 제공하므로 Fable 5로 오래 걸리는 작업을 하기 좋습니다. Parameter Golf에서는 CMA가 자가 호스팅 샌드박스로 8xH100 GPU에 접근할 수 있게 했습니다.
미묘하지만 중요한 점이 하나 있습니다. 무엇이 판단하느냐가 중요합니다. 저희는 모델이 자기 출력물을 스스로 비판할 때 문제가 생긴다는 것을 보았습니다. Prithvi Rajasekaran은 저희 엔지니어링 블로그에서 이 내용을 여기에 썼습니다.
저희는 Fable 5에서 검증기 하위 에이전트가 자기 비판보다 더 나은 경향을 보인다는 것을 발견했습니다. 채점이 독립된 컨텍스트 창에서 이뤄지기 때문입니다. CMA의 Outcomes는 채점기 하위 에이전트를 자동으로 띄워 이 일을 처리합니다.
각 테스트에서 저는 확인 가능한 아홉 가지 기준(예: 기준선 실행, 20개 실험 실행 등)을 담은 채점 기준 파일을 제공했습니다. 그런 다음 Parameter Golf를 최대 8시간 동안 실행했습니다. Outcomes 채점기는 Claude가 작업을 멈추도록 허용하기 전에 모든 실험 기준이 충족됐는지 확인했습니다.
Fable 5는 학습 파이프라인을 Opus 4.7보다 약 6배 더 많이 개선했습니다. 실험을 구조적 실험(예: 아키텍처 변경)과 스칼라 실험(예: 상수 조정)으로 나눠 보면, Fable 5는 더 큰 구조 변경에 베팅했고 회복력을 보였습니다. 예를 들어 양자화 회귀를 지나 가장 큰 승리까지 밀고 갔습니다.
Opus 4.7의 첫 번째 실험은 작은 개선을 만들었고, 그 뒤 거의 모든 실험은 같은 틀을 따랐습니다. 스칼라를 조정하고, 측정하고, 결과가 좋으면 유지하는 방식이었습니다.
메모리
메모리는 Fable이 뛰어난 또 다른 영역입니다. 우리는 이것을 세션을 가로지르는 바깥 루프로 생각할 수 있습니다. Claude는 세션 중에 메모리에 쓰고, 그 메모리는 이후 세션에서 다시 꺼내 쓸 수 있습니다.
@pgasawa와 팀이 최근 Continual Learning Bench 1.0을 공개했기 때문에, 저는 이것으로 Fable 5와 이전 모델들을 비교해 보고 싶었습니다.
저는 이 벤치마크의 한 작업에서 Fable 5, Opus 4.7, Sonnet 4.6을 비교했습니다. 이 작업은 에이전트가 SQL 데이터베이스에 접근해 순서대로 이어지는 질문에 답하게 합니다. 각 질문은 별도의 에이전트 세션이고, 메모리가 제공됩니다.
이를 위해 저는 메모리를 켠 CMA를 사용했습니다. 이 기능은 각 에이전트가 세션 사이에서 공유할 수 있는 마운트된 파일 시스템에 접근하게 해 줍니다.
이 작업에서 메모리를 효과적으로 쓰려면 다음 흐름이 도움이 됩니다. 실패(무언가 틀리고 기록하기), 조사(넘어가기 전에 이유 찾기), 확인(진단을 확인된 사실로 바꾸기), 추출(확인한 내용을 일반 규칙으로 바꾸기), 참고(다시 추론하지 말고 규칙 읽기).
Sonnet 4.6은 대체로 1단계에서 멈춥니다. 저장소에는 실패 기록과 열린 추측 목록이 쌓입니다(예: "prc_usd 대신 prc일 수도?"). 이전 기록을 참고하는 일은 드뭅니다. 성능을 높이려면 작업별 메모리 지시가 필요합니다.
Opus 4.7은 대체로 3단계쯤에서 멈춥니다. 불확실성을 표시한 스키마 참고 자료를 만듭니다(예: "prc가 센트 단위일 수도? 확인 필요."). 하지만 확인 범위는 낮습니다. 질문의 7~33% 수준이고, 중간 실행값은 약 17%입니다.
Fable 5는 이 흐름을 끝까지 완료하는 경향이 있습니다. 가장 강한 실행에서는 확인 범위가 최대 73%(30개 중 22개)에 이르렀고, 배운 내용을 이후 작업에 도움이 되는 일반 규칙으로 추출했습니다.
Fable 5를 직접 프롬프트하고 계속 조종하기보다, 모델이 환경 피드백에 반응해 스스로 고칠 수 있는 루프(예: /goal 또는 Outcomes)를 설계하고, 자기 컨텍스트를 스스로 관리하게 하는 것(예: 메모리)이 더 나은 경우가 많습니다.
제가 실행한 몇 가지 작은 실험만 공유했지만, 어려운 작업에서 Fable 5를 직접 테스트해 볼 만합니다. 특히 자기 수정이나 메모리용 루프를 함께 써 볼 가치가 있습니다.
시작하려면 저희 문서를 보거나 최신 Claude Code에 물어보면 됩니다. Claude Code는 내장 /claude-api 스킬을 써서 Fable 5(예: 프롬프팅 모범 사례), /goal, Claude Managed Agents, 그 밖의 API 기능을 설명할 수 있습니다.