사람 없이 돌아가는 연구 세션 운영

이것은 사람이 지켜보지 않는 연구 세션, 즉 밤샘 세션이나 낮 동안의 긴 인수인계를 위한 운영 프로그램입니다. 밤마다 쓰던 프롬프트(round-6과 night-3 프로그램, git tag research-archive-2026-09-24의 docs/prompts/ 아래에 보관)를 대체하며, 그 밤들에 잘못된 점을 반영했습니다. 이 세션이 적용하는 연구 규칙은 PLAN.md의 “Standing rules for every round”에 있고, 명령은 AGENTS.md에 있습니다.

세션은 등록된 규칙 아래에서 언덕 오르기(hill-climb)와 확인을 수행하고, Jared가 조치할 수 있는 기록을 남깁니다. 게시하지는 않습니다.

1. 시작

처음 30분은 실행이 아니라 읽는 데 쓰십시오.

AGENTS.md 전부(명령, 고정된 스위트, 표준 위치, Modal 설정).
PLAN.md: 현재 위치, 배운 것, 상시 규칙, 데이터 정책과 Next. 이어서 발전시키고 싶은 발견이 있으면 그 근거를 아카이브에서 읽으십시오: git show research-archive-2026-09-24:PLAN.md.
.agents/skills/의 스킬: kev-modal-study(GPU 작업 실행·감시·가져오기; Gotchas를 읽으십시오), kev-verify(코드 변경에 회귀가 없음을 증명), kev-pr-description(모든 PR 전에), thermonuclear-code-review.
kev/rounds.py(docstring이 spec 스키마입니다), experiments/rounds/에서 가장 가까운 과거 spec, kev/autoresearch.py(session).
인수인계 자체: 권한(Modal 달러, AI Gateway 달러), 범위에 무엇이 있는지, Jared가 필요한 것이 무엇인지.

그다음 준비하십시오:

연구 브랜치의 worktree에서 작업하십시오(git worktree add -b research/<session> /tmp/kev-<session> origin/main). 커밋할 때마다 push해서 기계가 잠들어도 잃는 것이 없게 하십시오. main에 들어갈 코드는 자체 검토된 PR을 거칩니다.
uv run modal billing summary --json을 읽고 metered_cost를 상태 파일(section 6)의 기준선으로 기록하십시오.
이전 세션이 상태 파일을 남겼다면 먼저 읽고 그것에서 재개하십시오. 분리된 Modal 작업은 당신 없이도 계속 실행됩니다.

2. 예산과 지출 규칙

권한은 세션의 총액이며, 아직 실행 중인 모든 것을 포함합니다. 모든 실행 전에 계량 비용을 다시 읽고, (metered_now - baseline) + sum(admission bounds of everything still running) >= authorization이면 실행하지 마십시오.
스터디의 admission bound는 실행 시 출력되고 runs/<study>.spawn.json에 저장됩니다. 벤치마크 호출의 bound는 compute_bound(gpu, timeout, trials)(kev/budget.py)입니다. spec의 스터디 budget은 최소한 그 bound 이상이어야 합니다(kev.rounds validate가 확인하고, modal_app.admit_study는 아무것도 실행되기 전에 예산을 넘는 스터디를 거부하며, 스터디는 $250와 28,800초로 상한이 걸립니다).
어떤 단계도 계획에 넣지 않는 예비분(권한의 약 10 %)을 남기십시오: 청구 읽기는 늦게 도착하고 수정되며, admission bound는 읽기를 크게 과대평가합니다(읽기 배치는 가장 느린 작업의 타임아웃을 물고 갑니다).
모든 읽기를 UTC 시각과 함께 상태 파일에 기록하십시오. AI Gateway 지출(Jev 참조 읽기, 레이블 판정)은 자체 상한이 있고, 지출하는 스크립트가 강제하며, runs/<name>/usage.json에 기록됩니다.
Modal 워크스페이스 지출 한도는 대시보드에서만 올릴 수 있습니다. 한도에 닿으면 학습 중인 컨테이너가 중간에 죽습니다.

3. 라운드 등록

라운드는 PLAN.md 절 하나와 spec 하나이며, 학습이나 읽기 전에 함께 커밋합니다.

PLAN.md 절을 쓰십시오: 이유(측정된 격차와 그 근거), 데이터(먼저 고정, manifest 포함), arm, 규칙(주 기준, 스위트마다 크기를 맞춘 임계값을 가진 가드, 순위), 확인 단계, 예산. 상시 규칙을 쓰고, 한 라운드를 위해 새 통계량을 발명하지 마십시오.
가장 가까운 과거 spec을 복사해 experiments/rounds/r<N>.json을 쓰십시오(공동 델타에는 r15, 27B에는 r17, 스킬 라운드에는 r10, 학습 없는 사후 arm에는 r20: 온도 풀, 보간된 체크포인트; 다른 체크포인트로의 블렌드에는 r23, 그 arm은 양 끝점의 학습을 위해 trained_on을 명시). "archive"는 빼십시오: 그 키는 기록된 라운드 5-18을 표시합니다. spec이 명시하는 모든 plan 파일과 그 규칙이 필요로 하는 모든 부모 읽기는 이 체크아웃에 있어야 합니다. 부모에 읽기가 없으면 launch-reads <spec> --parents가 만듭니다. 제거된 스위트(kev.suite.REMOVED_SUITES, 이유 포함)의 모든 읽기를 버리십시오: evals/external/scienthoon-v1은 2026-09-27에 제거되어 라운드 23부터 scienthoon 읽기·패널·가드가 빠지고, evals/external/wanli-v2와 typesafe-v1은 2026-09-30에 제거되어 라운드 27부터 그 읽기도 빠지며, SemIf가 남은 유일한 외부 읽기입니다(보고 전용). 통합된 외부 스위트는 게이트가 아닙니다: 라운드 23-26이 따르는 라운드 24의 감사된 규칙은 SemIf, WANLI-v2와 TypeSafe를 선택적 패널로 보고했습니다. validate와 launch는 그 스위트를 마지막으로 명시한 라운드 이후의 라운드를 거부합니다.
새 데이터는 manifest.json(파일별 sha256, 입력의 해시)을 가진 evals/ 아래의 새 디렉터리입니다. SFT 데이터 정책(PLAN.md)에 따라 비공개 코퍼스는 manifest만 git에 남기고, "mirror" 항목으로 비공개 데이터셋을 가리킵니다.
필수: 서빙되거나 배포되는 모든 온도는 홀드아웃 데이터셋 풀에서 나와야 하며, 학습 코퍼스의 파티션에서 나오면 안 됩니다. 캘리브레이션(ECE, Brier, 확신 오류, 커버리지)을 읽는 라운드는 그 arm을 위한 temperature 풀을 등록하고(r20 복사: transfer-r3 캘리브레이션 파티션의 홀드아웃 공개 소스 여덟 개 + transfer-v9 MMLU-Pro), 릴리스는 scripts/calibrate_checkpoint.py가 같은 풀에서 적합한 온도를 배포합니다. 학습 소스의 홀드아웃 항목(학습 스위트의 calibration / development 파티션)은 분포 내입니다: 라운드 19는 sft-v1 개발 행에서 적합한 T 0.955로 SFT arm을 서빙했고 모든 캘리브레이션 기준을 실패했습니다(breadth-v1 ECE 0.059). 라운드 20의 홀드아웃 데이터셋 풀은 같은 체크포인트에서 0.0085를 냈습니다. 무엇이 강제하는가:
- 라운드 21부터 kev.rounds validate와 launch는 규칙이나 확인에 온도가 움직이는 기준(ECE, Brier, NLL, 확신 오류, 커버리지; 정확도를 뺀 전부)이 있는데 temperature 풀이 없는 라운드를 거부합니다. 라운드 <= 20은 학습 코퍼스로 학습한 arm마다 !!! warning만 출력하므로, 그 기록된 spec은 여전히 검증됩니다.
- kev.rounds validate는 풀 읽기가 (a) arm의 학습 스위트, 그 구성 요소(sft-v1의 inputs.components) 또는 그 plan의 data 스위트이거나, (b) 어떤 arm이 학습한 소스를 풀에 넣거나, (c) 어느 학습 코퍼스의 calibration 또는 development 파티션을 읽으면 거부합니다. 또한 확인할 수 없는 풀(학습이 알려지지 않은 arm, manifest나 나열된 소스가 없는 스위트)도 거부합니다. 트라이얼 없는 체크포인트 arm은 trained_on을 명시할 수 있습니다.
- read-out은 각 arm의 temperature_source를 기록하고, 표는 학습 코퍼스의 트라이얼 개발 행에서 서빙된 arm에 !!!를 출력합니다(라운드 5-19가 모두 그랬고, 이제 그런 온도는 스크리닝 전용입니다).
- scripts/calibrate_checkpoint.py는 같은 적합 집합을 거부합니다(head.pt의 학습 스위트와 대조해 확인). --allow-in-distribution은 옛 적합을 재현할 때만 쓰고, head.pt["temperature_fit"]에 기록됩니다.
- 트라이얼 내 온도(result.json의 calibration_fit)는 role: in-trial screening ... not a served or shipped temperature라고 밝힙니다.
- 부모는 트라이얼의 개발 행에서 적합한 온도로 서빙됩니다(Kev-27B의 경우 같은 행에서 적합한 배포값 1.38). read-out은 그것과 그들이 배포한 head.pt T를 기록하고(parent_temperature_source), validate는 학습 코퍼스의 행에서 둘이 0.05 넘게 다르면 경고합니다.
- 분리성 검사는 소스 NAME 기준입니다(명목상이며 의미상이 아님): 같은 데이터셋을 다른 이름으로 담은 두 스위트는 통과합니다. 따라서 풀은 Kev에서 구조상 eval 전용인 소스, 예컨대 transfer-r3의 홀드아웃 공개 소스 여덟 개와 transfer-v9의 MMLU-Pro를 써야 합니다. 풀 읽기의 sources 허용 목록은 그 스위트가 나열한 소스를 명시해야 하고(오타는 문제입니다), 검사기가 나열할 수 없는 학습(evals/ 밖의 data 파일, 소스 없는 manifest)은 새 라운드에 문제입니다.
- calibrate_checkpoint.py --temperature T(수동 값, 적합 없음)는 --reason이 필요하고 head.pt["temperature_fit"]에 기록됩니다(예: “copied from the pool fit of runs/r20-readout”).
uv run python -m kev.rounds validate experiments/rounds/r<N>.json(--partitions를 더하면 파티션도 확인)이 ok를 출력할 때까지 반복하십시오. PLAN 절과 spec을 한 커밋으로 커밋하고 push하십시오. 그 커밋 시각이 등록 시각입니다.

4. 처음부터 끝까지 실행

KEV_GPU=H200 uv run modal deploy modal_app.py                     # after any change to kev/*.py or any new file under evals/
uv run python -m kev.rounds launch experiments/rounds/r<N>.json   # one ::study per study, 60 s apart, logs in runs/<study>.log
caffeinate -i nohup uv run python -m kev.rounds watch experiments/rounds/r<N>.json > runs/r<N>.watch.log 2>&1 &

모든 스터디의 처음 5분 안에 modal container logs <id>에서 분당 옵티마이저 스텝을 세고, 타임아웃 대비 벽시계 시간을 투영하십시오(ep0 step N/M: M은 전체 에포크). 타임아웃된 컨테이너는 아무것도 저장하지 않습니다. 취소하고(FunctionCall.from_id(cid).cancel()) 레코드를 줄이거나 타임아웃을 늘린 새 스터디 이름으로 다시 실행하십시오.
watch는 실행된 트라이얼을 폴링하고, 끝난 스터디마다 가져오고(한 번에 스터디당 하나의 pull), 그 arm의 읽기를 한 번 실행하고(arm마다 배치된 ::benchmarks 호출 하나, 60초 간격), 그것들을 기다린 뒤 runs/r<N>-readout/round<N>.json과 표를 씁니다. 재시작할 수 있습니다: 상태는 runs/<study>.watch.json에, 실행 의도는 runs/r<N>-reads-<arm>.json에 있습니다. 수동으로: launch-reads <spec> [--arms a,b] [--parents] [--dry-run], readout <spec>.
read-out을 PLAN 절에 쓰십시오: 모든 arm, 구간이 붙은 모든 기준, 판정과 실패한 것.
확인은 의도적이며, 결코 자동이 아닙니다. read-out이 지목한 후보에 대해 선택을 PLAN.md에 쓰고 커밋한 뒤, 단계별로: launch-reads <spec> --stage <stage> --arm <arm>, 그다음 confirm <spec> --stage <stage> --arm <arm>(→ runs/r<N>-verdict/<size>-<stage>.json). 잠긴 읽기 전에 패널을 테스트하십시오. 각각 한 번, 예외 없음.
상한 아래에서 등록된 여러 라운드를 연속 실행: uv run python -m kev.autoresearch session experiments/rounds/r19.json [...] --spend-start <baseline> --spend-cap <authorization>. 각 라운드를 검증하고 실행하고 read-out까지 감시하며, 예산이 상한을 넘을 라운드 전에 멈추고, runs/autoresearch-sessions.jsonl에 덧붙이며, 확인 명령을 출력합니다. 결코 실행하지는 않습니다. kev.autoresearch leaderboard는 runs/leaderboard.{jsonl,md}(커밋되지 않음)를 갱신하고, compare는 전이 정확도에서 트라이얼을 참조와 짝지으며, release-check --study <name>은 그 스터디의 모든 config를 검사합니다(각 config는 모든 시드가 게이트를 통과해야 통과합니다).

5. 세션이 건드려도 되는 것과 안 되는 것

가능: spec, plan, PLAN.md 절 작성; 새 디렉터리 아래에 새 고정 데이터 구축; modal_app.py를 통한 스터디와 읽기 실행; 스크립트와 modal_app.py 인프라 상수 변경; main에 들어갈 코드를 위한 PR 열기.

Jared의 명시적 승인 없이는 불가능:

Hub에 무엇이든 게시하거나 변경(kev.publish, hf upload, hf repos tag, scripts/publish_space.sh, 배포된 head.pt), 비공개 저장소를 공개로 만들기, 공개 엔드포인트 배포;
main에 커밋, force-push, PR 병합(코드는 CI가 통과한 검토된 스쿼시 병합 PR을 거쳐 main에 들어갑니다);
evals/ 아래에 있는 것(고정됨)이나 평가기를 편집: kev/experiment.py: EVALUATOR_FILES, 게이트, kev/metrics.py, kev/rounds.py의 paired read. 필요한 평가기 변경은 자체 PR이며, 어떤 라운드가 그것에 의존하기 전에 kev-verify와 tests/test_rounds.py로 검증합니다;
등록된 확인 단계 밖에서 --allow-test를 넘기거나 locked_test를 실행;
어떤 Jev 출력이나 폐쇄 모델 생성물을 학습 데이터에 넣기;
로컬에서 학습(32 GB Mac은 이 모델들을 담을 수 없습니다)하거나 한 기계에서 두 학습 프로세스 실행;
runs 볼륨에서 체크포인트나 스냅숏 삭제(modal volume rm, 컨테이너 안의 shutil.rmtree), 또는 등록된 spec에서 전체 가중치 트라이얼의 스냅숏 끄기("snapshot_fractions": "none"). 전체 가중치 트라이얼은 스텝의 0.25, 0.5, 0.75에서 스냅숏을 유지합니다(kev.experiment.SNAPSHOT_FRACTIONS). 그래야 실행이 끝난 뒤 읽기가 그 실행의 최선 지점을 찾을 수 있습니다: 라운드 19는 찾지 못했습니다. 유일한 중간 상태가 재개 지점이었고 실행이 끝날 때 삭제되었으며, AutoJev의 최선 체크포인트는 0.7 에포크에 있었기 때문입니다. 27B의 스냅숏은 트라이얼당 볼륨 약 154 GB입니다; 그 공간은 세션이 아니라 Jared가 결정합니다. 스냅숏은 runs 볼륨(주)에 있습니다; 비공개 Hub 미러(plan의 snapshot_hub_repo, 또는 modal_app.py::mirror_snapshots)는 남겨 둘 가치가 있는 체크포인트를 위한 장기 저장소이지 대체물이 아닙니다: 27B 체크포인트 미러링(각 약 51 GB, jaredpalmer/kev-snapshots 같은 비공개 저장소로)도 Jared의 결정이며, 결코 공개 저장소로 하지 않습니다.

어떤 arm이 막히면(인증, 지출 한도, 30분 안에 되지 않을 배포), 무슨 일이 있었는지 적고 다음 arm으로 넘어가십시오. 사람을 기다리지 마십시오.

6. 복원력

상태 파일 runs/<session>-state.json(runs/는 gitignore됨; 연구 브랜치에서 git add -f): 기준선과 권한, UTC 시각이 붙은 지출 읽기, spawn id·bound·상태가 붙은 모든 스터디, 실행하고 가져온 읽기, 후보, PR, 대기 중인 결정. 실행·가져오기·읽기마다 갱신하고 PLAN 절과 함께 커밋하십시오.
분리된 작업. 스터디는 배포된 앱에서 spawn되고 로컬 클라이언트가 죽어도 살아남습니다. study 이후의 로컬 오류에도 트라이얼이 이미 spawn되었을 수 있으므로, 다시 실행하기 전에 modal container list를 실행하고, 같은 스터디 이름으로 결코 다시 실행하지 마십시오. 프로브와 벤치마크는 --detach로 실행합니다.
감시자는 로컬 프로세스이며 기계나 네트워크와 함께 죽습니다. nohup과 caffeinate 아래에서 실행하고, 중단 후에는 watch를 다시 시작하십시오(상태에서 재개합니다). DNS와 연결 오류는 스스로 재시도합니다; 트라이얼 자체의 예외는 실패이며 보고됩니다.
타임아웃된 전체 가중치 트라이얼은 Modal이 아니라 감시자가 이어갑니다. 트라이얼은 Modal의 재시도를 끄고 spawn됩니다; 전체 가중치 트라이얼의 호출이 타임아웃으로 끝나면 watch가 modal_app.py::resume --trial <label>을 실행해 다음 시도를 spawn하고(마지막으로 커밋된 재개 지점에서 이어감) 스터디가 승인받은 GPU와 타임아웃으로 runs/<study>.spawn.json에 기록합니다(attempts, 트라이얼당 최대 1 + kev.budget.FULL_FT_RETRIES, admission bound가 계산된 횟수; 현재 호출이 아직 실행 중인 트라이얼은 결코 이어가지 않습니다). 감시자가 꺼져 있는 동안에는 이어가지지 않습니다: 다시 시작하면 타임아웃을 이어갑니다. 이유: Modal은 타임아웃된 시도마다 두 번 청구했고(타임아웃, 그리고 30초 뒤 죽인 작업), 그래서 Retries(2)가 라운드 22의 트라이얼에 세 번의 시도 중 두 번을 줬으며, kill의 재시도가 실행 중인 시도 옆에서 시작될 수 있습니다(scripts/modal_retry_probe.py). 원장 이전에 spawn된 스터디에는 횟수가 없습니다: resume --trial <label> --beyond-bound가 어떤 bound 밖에서 수동으로 이어가고, 그렇게 밝힙니다. 두 시도는 결코 트라이얼을 공유하지 않습니다: 각각은 spawn 전에 pending으로 기록되고, 각각 kev-leases 볼륨에 임대를 쥡니다(1분마다 하트비트). 새 시도는 다른 임대가 신선하면 거부하고, 이어가기는 죽은 시도의 마지막 하트비트 후 최대 kev.budget.LEASE_STALE(15분)을 기다린 뒤 spawn합니다.
네트워크 단절은 로컬 클라이언트를 죽일 뿐 원격 작업은 죽이지 않습니다: 클라이언트가 죽은 읽기는 보통 Modal에서 이미 끝났습니다; 다시 실행하는 대신 볼륨에서 그 디렉터리를 가져오십시오(modal volume get kev-runs /<name> runs/<name>).
실패한 벤치마크나 프로브는 볼륨에 그 디렉터리를 남깁니다; 새 이름으로 재시도하십시오.

7. 보고

세션 끝에(그리고 진행되는 동안 상태 파일에):

각 라운드의 PLAN.md 절은 등록, read-out 표, 확인 결과와 판정을 부정적이든 아니든 리포트 경로와 함께 담습니다.
PLAN.md의 “Where we stand”(릴리스·확인된 후보, 실행 중인 작업, 지출)와, 발견이 바뀌었으면 “What we have learned”를 갱신하고, Record 표에 각 라운드를 추가하십시오.
PLAN.md에 세션 요약: 지출(기준선, 최종 읽기, 실행 중 bound), 완료에 필요한 정확한 명령과 함께 Modal에 대기 중인 것, 사건, 그리고 근거가 붙은 최대 세 개의 다음 단계.
모든 수치는 체크포인트, 스위트와 파티션, n, 리포트 경로를 답니다; 수치가 나온 read-out과 verdict를 커밋하십시오(.gitignore는 리포트를 유지하고 예측 덤프는 두지 않습니다; 새 read-out 디렉터리에 규칙을 추가하십시오).
시계 도장: 등록 시각과 결과 시각은 커밋 시각입니다. 일어나기 전에 제목에 시각을 쓰지 마십시오; night 3의 스크래치패드가 그랬고, 그 도장은 쓸 수 없게 되었습니다.

8. 알려진 함정

Modal 앱 생성 레이트 리밋. 1분 안에 분리된 modal run을 대략 세 번 넘게 실행하면 “App create rate limit exceeded”로 실패하고 아무것도 실행되지 않습니다. kev.rounds는 실행을 60초 간격으로 벌리고 arm의 읽기를 한 호출로 묶습니다; 수동으로도 그렇게 하십시오.
벤치마크 작업의 repo@sha 는 예전에 run@suite@name@flags의 모든 필드를 어긋나게 했습니다. modal_app.parse_jobs가 이제 오른쪽에서 파싱하므로 고정한 Hub revision은 안전합니다. 스위트와 이름에는 @나 ,가 들어가면 안 됩니다.
스터디당 하나의 pull. 같은 스터디를 동시에 가져오면 서로의 트라이얼 디렉터리를 지웠습니다; 이제 pull_study가 스터디별 잠금을 쥡니다. 트라이얼이 아직 도는 중의 pull은 안전하고 미완 트라이얼만 갱신합니다.
pull은 볼륨에 전체 가중치를 남깁니다. ::pull(과 watch)은 전체 가중치 샤드(model*.safetensors, 27B 체크포인트나 스냅숏당 약 51 GB)와 재개 지점을 건너뜁니다; 나머지는 전부 내려옵니다(결과, 행, head.pt, config). 볼륨의 체크포인트나 스냅숏을 읽으려면: ::benchmarks --jobs "/runs/<study>/<trial>/snapshots/step-<N>/checkpoint@<suite>@<name>". 로컬에서 정말 샤드가 필요하면 ::pull --weights가 복사합니다.
데이터 후에 배포하십시오. 이미지가 evals/를 복사합니다; 런처는 kev/*.py 해시만 확인하므로, 배포 후에 데이터 파일이 추가된 트라이얼은 컨테이너 안에서 실패합니다. study의 --gpu H200은 KEV_GPU=H200으로 배포된 앱을 필요로 합니다.
27B. H200 전용(bf16 백본, 상주 55 GB); 스터디 타임아웃은 최대 28,800초(lr 2e-5의 1 에포크 스킬 델타는 옵티마이저 스텝당 약 8.8초); fp32 읽기는 9B의 약 세 배(spec read_timeout: {"27b": 14400}); 잠긴 읽기는 H200에서 --timeout 14400 --memory-mb 131072(spec locked_args)가 필요합니다(GPU는 spec의 gpu / 배포된 앱에서, 또는 수동으로 --gpu H200). 모든 bf16 가중치 트라이얼은 트라이얼 내 isolation_and_packing 게이트(fp32 검사)를 실패합니다; 행에서 결과를 읽고, bf16에서의 서빙 격리는 따로 측정하십시오.
locked_test 이름 규칙. 트라이얼 내 스크리닝 게이트가 실패하면 도구는 -ungated 접미사를 요구합니다(kev-4b-r8-ungated); 판정은 여전히 등록된 규칙을 따릅니다.
스위트별 읽기 타임아웃. modal_app.READ_TIMEOUTS는 긴 state 패널 7,200초, 문서 5,400초, transfer-v9 3,600초, 그 외 1,800초로 정합니다. 전역 --timeout 하나가 배치 안 모든 작업의 admission bound를 부풀립니다.
예산 승인. --budget을 넘는 실행은 아무것도 실행되기 전에 종료됩니다; 최소한 출력된 bound 이상의 예산으로 다시 실행하십시오.
외부 서버는 단일 비행입니다. AutoJev의 서버는 한 번에 한 요청만 답했습니다(바쁠 때 HTTP 529); 긴 kev.benchmark --remote 전에 외부 엔드포인트를 프로브하고 --remote-concurrency를 감당할 수 있는 값으로 설정하십시오. 거부한 요청(예: 컨텍스트를 넘겨 422)은 커버리지로 세고, 결코 조용히 버리지 마십시오.
온도: 배포값 vs 트라이얼 내. 트라이얼의 result.json과 그 잠긴 요약은 트라이얼 내 적합으로 채점됩니다; 릴리스는 scripts/calibrate_checkpoint.py가 head.pt에 쓴 T를 배포합니다. 첫 AutoJev 비교는 Kev-27B를 배포값 1.38이 아니라 트라이얼 내 1.19로 서빙했고 수정해야 했습니다. 모든 수치가 어느 T를 쓰는지, 어디서 적합했는지 말하십시오(section 3, 규칙 4: 홀드아웃 데이터셋, 결코 학습 코퍼스 자체의 파티션이 아님).
긴 컨텍스트 캘리브레이션. "by_length": true인 패널은 state 토큰 버킷별로 정확도, ECE, Brier와 확신 오류를 보고합니다(8k 미만부터 64k+, 그리고 8k+/16k+/32k+ 꼬리), 기준은 그중 하나를 게이트할 수 있습니다(long.ece_16k_plus.candidate <= 0.05). 토큰은 읽기 스위트 레코드에서 세므로 양쪽이 같은 버킷을 공유합니다.
새 스위트 버전 없는 스위트 수정. 패널은 양쪽에서 소스, 태스크 또는 (비공개, 해시 등록된) id나 소스 목록을 뺄 수 있고(exclude_sources, exclude_tasks, exclude_file), 보고 전용 패널은 "optional": true로 표시해 빠진 리포트 읽기가 후보를 미완으로 만들지 않게 합니다. 제외는 그 아래에서 어떤 read-out을 하기 전에 레이블 타당성으로 고르고(라운드 24는 2026-09-27 감사에서 가져왔습니다), 비공개 목록을 결코 커밋하지 마십시오.
워크스페이스 용량. 워크스페이스는 한 번에 최대 GPU 컨테이너 약 열 개로 돌았습니다; 대기 중인 컨테이너는 용량 문제이지 버그가 아니므로 다시 실행하지 마십시오.
작은 스위트. 89나 144 질문에 대한 가드는 2-3 pp 바닥을 해소할 수 없습니다; 통합 패널을 통해 게이트하십시오.
Jev 읽기는 도중에 실패합니다 게이트웨이 503에서; 부분 행을 이어 붙이지 말고 새 이름으로 읽기 전체를 다시 실행하십시오.
소프트 타깃 데이터. 빌더를 작성할 때 레코드 몇 개를 눈으로 확인하십시오: target의 합이 1이고, 레코드가 답할 수 없는 경우가 아니면 레이블의 질량이 최소 0.5입니다(kev.data.none_pair가 한때 소프트 타깃에 질량 0을 학습시켰고 #60에서 고쳤습니다).
modal run ...::study 출력을 로그 파일로 리디렉션하십시오; 필터가 아무것도 실행되지 않은 이유를 설명하는 SystemExit을 숨길 수 있습니다.