jevlaya
Deutsch
Dokumentation

Eine unbeaufsichtigte Forschungssitzung ausführen

Dies ist das Betriebsprogramm für eine Forschungssitzung, die ohne menschliche Aufsicht läuft: eine Nachtsitzung oder eine lange Übergabe während des Tages. Es ersetzt die Pro-Nacht-Prompts (die Runde-6- und Nacht-3-Programme, am Git-Tag research-archive-2026-09-24 unter docs/prompts/ erhalten) und fasst zusammen, was in jenen Nächten schiefging. Die Forschungsregeln, die es anwendet, stehen in PLAN.md, „Standing rules for every round”; die Befehle stehen in AGENTS.md.

Eine Sitzung betreibt Hill-Climbing und bestätigt unter registrierten Regeln und hinterlässt einen Datensatz, auf den Jared reagieren kann. Sie veröffentlicht nicht.

1. Start

Verbringe die ersten 30 Minuten mit Lesen, nicht mit Starten.

  1. AGENTS.md, vollständig (Befehle, eingefrorene Suites, kanonische Speicherorte, Modal-Einstellungen).
  2. PLAN.md: wo wir stehen, was wir gelernt haben, die stehenden Regeln, die Datenpolitik und Next. Für einen Befund, auf dem du aufbauen willst, lies seine Belege im Archiv: git show research-archive-2026-09-24:PLAN.md.
  3. Die Skills in .agents/skills/: kev-modal-study (GPU-Arbeit starten, beobachten und abholen; lies seine Gotchas), kev-verify (beweisen, dass eine Codeänderung keine Regression hat), kev-pr-description (vor jedem PR), thermonuclear-code-review.
  4. kev/rounds.py (sein Docstring ist das Spec-Schema), die nächstliegende frühere Spec in experiments/rounds/ und kev/autoresearch.py (session).
  5. Die Übergabe selbst: Autorisierung (Modal-Dollars, AI Gateway-Dollars), was im Umfang liegt, was Jared braucht.

Richte dann ein:

  • Arbeite in einem Worktree auf einem Forschungsbranch (git worktree add -b research/<session> /tmp/kev-<session> origin/main). Pushe nach jedem Commit, damit nichts verloren geht, wenn die Maschine schläft. Code, der für main bestimmt ist, geht durch einen eigenen reviewten PR.
  • Lies uv run modal billing summary --json und erfasse metered_cost als Basis in der State-Datei (Abschnitt 6).
  • Wenn eine vorherige Sitzung eine State-Datei hinterlassen hat, lies sie zuerst und fahre von ihr fort; abgekoppelte Modal-Jobs laufen ohne dich weiter.

2. Budgets und die Ausgabenregel

  • Die Autorisierung ist die Gesamtsumme der Sitzung und zählt alles, was noch läuft. Lies vor jedem Start die gemessenen Kosten erneut und starte nicht, wenn (metered_now - baseline) + sum(admission bounds of everything still running) >= authorization.
  • Die Admission Bound einer Studie wird beim Start ausgegeben und in runs/<study>.spawn.json gespeichert; die Bound eines Benchmark-Aufrufs ist compute_bound(gpu, timeout, trials) (kev/budget.py). Das Study-budget einer Spec muss mindestens seine Bound sein (kev.rounds validate prüft es; modal_app.admit_study lehnt eine Studie über ihrem Budget ab, bevor irgendetwas läuft, und eine Studie ist auf $250 und 28,800 s begrenzt).
  • Halte eine Reserve zurück (etwa 10 % der Autorisierung), die keine Phase einplant: Abrechnungswerte hinken nach und werden revidiert, und Admission Bounds überschätzen Reads stark (ein Read-Batch trägt das Timeout seines langsamsten Jobs).
  • Erfasse jeden Messwert mit seiner UTC-Zeit in der State-Datei. Die AI-Gateway-Ausgaben (Jev-Referenz-Reads, Label-Judges) haben ihre eigene Obergrenze, durchgesetzt vom Skript, das sie ausgibt, und werden in runs/<name>/usage.json protokolliert.
  • Das Ausgabenlimit des Modal-Workspace kann nur vom Dashboard aus erhöht werden; wird es erreicht, werden laufende Container mitten im Training beendet.

3. Eine Runde registrieren

Eine Runde ist ein PLAN.md-Abschnitt plus eine Spec, gemeinsam committet vor jedem Training oder Read.

  1. Schreibe den PLAN.md-Abschnitt: warum (die gemessene Lücke und ihre Belege), die Daten (zuerst eingefroren, mit Manifesten), die Arme, die Regel (primär, Guards mit auf jede Suite zugeschnittenen Schwellenwerten, Rang), die Bestätigungsstufen und das Budget. Verwende die stehenden Regeln; erfinde keine neue Statistik für eine einzelne Runde.
  2. Schreibe experiments/rounds/r<N>.json, indem du die nächstliegende frühere Spec kopierst (r15 für ein Joint-Delta, r17 für ein 27B, r10 für eine Skill-Runde, r20 für Post-hoc-Arme ohne Training: ein Temperatur-Pool, interpolierte Checkpoints; r23 für Blends in Richtung eines anderen Checkpoints, deren Arme trained_on für das Training beider Endpunkte nennen). Lass "archive" weg: Dieser Schlüssel markiert die aufgezeichneten Runden 5-18. Jede Plandatei, die die Spec nennt, und jeder Parent-Read, den ihre Regel braucht, muss in diesem Checkout existieren; wenn einem Parent ein Read fehlt, erzeugt ihn launch-reads <spec> --parents. Streiche jeden Read einer entfernten Suite (kev.suite.REMOVED_SUITES, mit dem Grund): evals/external/scienthoon-v1 wurde am 2026-09-27 entfernt, daher entfallen ab Runde 23 der Scienthoon-Read, -Panel und -Guard; evals/external/wanli-v2 und typesafe-v1 wurden am 2026-09-30 entfernt, daher entfallen ab Runde 27 auch ihre Reads, und SemIf ist der einzige verbleibende externe Read (nur Bericht). Die gepoolten Externals sind kein Gate: Die auditierte Regel von Runde 24, der die Runden 23-26 folgen, meldete SemIf, WANLI-v2 und TypeSafe als optionale Panels. validate und launch lehnen eine Runde nach der letzten Runde der Suite ab, die sie noch nennt.
  3. Neue Daten sind ein neues Verzeichnis unter evals/ mit einer manifest.json (sha256 pro Datei, Hashes der Eingaben). Gemäß der SFT-Datenpolitik (PLAN.md) behalten private Korpora nur das Manifest in Git, mit einem "mirror"-Eintrag, der auf den privaten Datensatz zeigt.
  4. MUSS: Jede bediente oder ausgelieferte Temperatur stammt aus einem Pool zurückgehaltener Datensätze, niemals aus einer Partition des Trainingskorpus. Eine Runde, die Kalibrierung liest (ECE, Brier, sichere Fehler, Abdeckung), registriert einen temperature-Pool für ihre Arme (kopiere r20: die acht zurückgehaltenen öffentlichen Quellen der Kalibrierungspartition von transfer-r3 + transfer-v9 MMLU-Pro), und ein Release liefert die Temperatur aus, die scripts/calibrate_checkpoint.py auf demselben Pool fittet. Die zurückgehaltenen Items der Trainingsquellen (die calibration- / development-Partitionen einer Trainings-Suite) liegen in der Verteilung: Runde 19 bediente ihre SFT-Arme bei T 0.955, gefittet auf sft-v1-Development-Zeilen, und scheiterte an jedem Kalibrierungskriterium (breadth-v1 ECE 0.059); der Pool zurückgehaltener Datensätze von Runde 20 ergab 0.0085 auf demselben Checkpoint. Was das durchsetzt:
    • Ab Runde 21 lehnen kev.rounds validate und launch eine Runde ab, deren Regel oder Bestätigung ein Kriterium hat, das die Temperatur bewegt (ECE, Brier, NLL, sichere Fehler, Abdeckung; alles außer Genauigkeit), und die keinen temperature-Pool hat. Runden <= 20 geben nur eine !!! warning pro Arm aus, der auf einem Trainingskorpus trainiert wurde, sodass ihre aufgezeichneten Specs weiterhin validieren.
    • kev.rounds validate lehnt einen Pool-Read ab, der (a) eine Trainings-Suite eines Arms, eine Komponente davon (sft-v1s inputs.components) oder die data-Suite seines Plans ist, (b) eine Quelle poolt, auf der ein Arm trainiert hat, oder (c) die calibration- oder development-Partition irgendeines Trainingskorpus liest; es lehnt außerdem einen Pool ab, den es nicht prüfen kann (ein Arm, dessen Training unbekannt ist, eine Suite ohne Manifest oder aufgeführte Quellen). Checkpoint-Arme ohne einen Versuch dürfen trained_on nennen.
    • Das Read-out erfasst temperature_source jedes Arms; die Tabelle gibt !!! aus für einen Arm, der bei den Development-Zeilen seines Versuchs aus einem Trainingskorpus bedient wird (Runden 5-19 waren alle so; ab jetzt ist eine solche Temperatur nur Screening).
    • scripts/calibrate_checkpoint.py lehnt dieselben Fit-Sets ab (geprüft gegen die Trainings-Suite von head.pt); --allow-in-distribution dient nur dem Reproduzieren eines alten Fits und wird in head.pt["temperature_fit"] erfasst.
    • Die In-Trial-Temperatur eines Versuchs (result.json calibration_fit) sagt role: in-trial screening ... not a served or shipped temperature.
    • Parents werden bei der Temperatur bedient, die auf den Development-Zeilen ihres Versuchs gefittet wurde (für Kev-27B ist das seine ausgelieferte 1.38, gefittet auf denselben Zeilen); das Read-out erfasst das und ihr ausgeliefertes head.pt T (parent_temperature_source), und validate warnt, wenn die beiden auf den Zeilen eines Trainingskorpus um mehr als 0.05 voneinander abweichen.
    • Die Disjunktheitsprüfung erfolgt nach Quellen-NAME (nominal, nicht semantisch): Zwei Suites, die denselben Datensatz unter verschiedenen Namen tragen, bestehen sie. Ein Pool muss also Quellen verwenden, die in Kev konstruktionsbedingt nur zur Evaluation dienen, wie die acht zurückgehaltenen öffentlichen Quellen von transfer-r3 und MMLU-Pro von transfer-v9. Die sources-Allowlist eines Pool-Reads muss Quellen nennen, die seine Suite auflistet (ein Tippfehler ist ein Problem), und Training, das der Checker nicht auflisten kann (eine data-Datei außerhalb von evals/, ein Manifest ohne Quellen), ist ein Problem für eine neue Runde.
    • calibrate_checkpoint.py --temperature T (ein manueller Wert, nichts gefittet) braucht --reason, erfasst in head.pt["temperature_fit"] (z. B. “copied from the pool fit of runs/r20-readout”).
  5. uv run python -m kev.rounds validate experiments/rounds/r<N>.json (füge --partitions hinzu, um die Partitionen zu verifizieren), bis es ok ausgibt. Committe den PLAN-Abschnitt und die Spec in einem Commit, pushe. Diese Commit-Zeit ist die Registrierungszeit.

4. Von Anfang bis Ende ausführen

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 &
  • Zähle in den ersten fünf Minuten jeder Studie die Optimizer-Schritte pro Minute in modal container logs <id> und projiziere die Wandzeit gegen das Timeout (ep0 step N/M: M zählt über alle Epochen). Ein zeitlich ausgefallener Container speichert nichts; brich ab (FunctionCall.from_id(cid).cancel()) und starte unter einem neuen Studynamen mit weniger Datensätzen oder einem längeren Timeout neu.
  • watch pollt die gespawnten Versuche, zieht jede fertige Studie (ein Pull pro Studie zur Zeit), startet die Reads dieses Arms einmal (ein gebatchter ::benchmarks-Aufruf pro Arm, 60 s auseinander), wartet auf sie und schreibt runs/r<N>-readout/round<N>.json und eine Tabelle. Es ist neustartbar: Der Zustand liegt in runs/<study>.watch.json und die Startabsicht in runs/r<N>-reads-<arm>.json. Von Hand: launch-reads <spec> [--arms a,b] [--parents] [--dry-run], readout <spec>.
  • Schreibe das Read-out in den PLAN-Abschnitt: jeder Arm, jedes Kriterium mit seinem Intervall, das Verdict und was fehlgeschlagen ist.
  • Die Bestätigung erfolgt bewusst, niemals automatisch. Für den Kandidaten, den das Read-out nennt, schreibe die Wahl in PLAN.md und committe sie, dann pro Stufe: launch-reads <spec> --stage <stage> --arm <arm>, dann confirm <spec> --stage <stage> --arm <arm> (→ runs/r<N>-verdict/<size>-<stage>.json). Teste Panels vor dem gesperrten Read. Je ein Read, keine Ausnahmen.
  • Mehrere registrierte Runden nacheinander unter einer Obergrenze: uv run python -m kev.autoresearch session experiments/rounds/r19.json [...] --spend-start <baseline> --spend-cap <authorization>. Es validiert, startet und beobachtet jede Runde bis zu ihrem Read-out, stoppt vor einer Runde, deren Budgets die Obergrenze überschreiten würden, hängt an runs/autoresearch-sessions.jsonl an und gibt die Bestätigungsbefehle aus; es führt sie nie aus. kev.autoresearch leaderboard aktualisiert runs/leaderboard.{jsonl,md} (nicht committet), compare paart Versuche gegen eine Referenz auf Transfer-Genauigkeit, release-check --study <name> prüft jede Konfiguration in dieser Studie (jede Konfiguration besteht nur, wenn alle ihre Seeds ihre Gates bestehen).

5. Was eine Sitzung anfassen darf und was nicht

Darf: Specs, Pläne und PLAN.md-Abschnitte schreiben; neue eingefrorene Daten unter neuen Verzeichnissen bauen; Studien und Reads über modal_app.py starten; Skripte und Infrastrukturkonstanten von modal_app.py ändern; PRs für Code öffnen, der auf main gehört.

Darf nicht, ohne Jareds ausdrückliche Zustimmung:

  • etwas auf dem Hub veröffentlichen oder ändern (kev.publish, hf upload, hf repos tag, scripts/publish_space.sh, ein veröffentlichtes head.pt), ein privates Repo öffentlich machen oder einen öffentlichen Endpunkt bereitstellen;
  • auf main committen, force-pushen oder einen PR mergen (Code erreicht main über reviewte, squash-gemergte PRs mit grüner CI);
  • etwas bearbeiten, das unter evals/ existiert (eingefroren), oder den Evaluator: kev/experiment.py: EVALUATOR_FILES, die Gates, kev/metrics.py, den gepaarten Read von kev/rounds.py. Eine nötige Evaluator-Änderung ist ihr eigener PR, verifiziert mit kev-verify und tests/test_rounds.py, bevor eine Runde von ihr abhängt;
  • --allow-test übergeben oder locked_test außerhalb einer registrierten Bestätigungsstufe ausführen;
  • irgendeine Jev-Ausgabe oder irgendeine Generierung eines geschlossenen Modells in Trainingsdaten stecken;
  • lokal trainieren (ein 32-GB-Mac kann diese Modelle nicht halten) oder zwei Trainingsprozesse auf einer Maschine ausführen;
  • einen Checkpoint oder einen Snapshot vom Runs-Volume löschen (modal volume rm, shutil.rmtree in einem Container) oder die Snapshots eines Full-Weight-Versuchs in einer registrierten Spec ausschalten ("snapshot_fractions": "none"). Full-Weight-Versuche behalten Snapshots bei 0.25, 0.5 und 0.75 ihrer Schritte (kev.experiment.SNAPSHOT_FRACTIONS), damit ein Read nach dem Ende eines Laufs den besten Punkt finden kann: Runde 19 konnte das nicht, weil der einzige Zwischenzustand ein Resume-Punkt war, der beim Ende des Laufs gelöscht wurde, und AutoJevs bester Checkpoint bei 0.7 Epoche lag. Die Snapshots eines 27B sind ~154 GB Volume pro Versuch; der Platz ist Jareds Entscheidung, nicht die der Sitzung. Snapshots liegen auf dem Runs-Volume (primär); ein privater Hub-Spiegel (snapshot_hub_repo in einem Plan oder modal_app.py::mirror_snapshots) ist Langzeitspeicher für einen Checkpoint, der es wert ist, behalten zu werden, kein Ersatz: das Spiegeln von 27B-Checkpoints (~51 GB pro Stück, in ein privates Repo wie jaredpalmer/kev-snapshots) ist ebenfalls Jareds Entscheidung, und niemals in ein öffentliches Repo.

Wenn ein Arm blockiert ist (Authentifizierung, ein Ausgabenlimit, ein Deploy, das in 30 Minuten nicht funktioniert), schreibe auf, was passiert ist, und gehe zum nächsten Arm über. Warte nicht auf einen Menschen.

6. Resilienz

  • State-Datei runs/<session>-state.json (runs/ ist gitignored; git add -f sie auf dem Forschungsbranch): Basis und Autorisierung, Ausgabenmesswerte mit UTC-Zeiten, jede Studie mit ihren Spawn-IDs, Bound und Status, gestartete und abgeholte Reads, Kandidaten, PRs, ausstehende Entscheidungen. Aktualisiere sie nach jedem Start, Pull und Read und committe sie mit dem PLAN-Abschnitt.
  • Abgekoppelte Jobs. Studien spawnen auf der bereitgestellten App und überleben den lokalen Client; ein lokaler Fehler nach study kann trotzdem Versuche gestartet haben, führe daher modal container list aus, bevor du neu startest, und starte niemals unter demselben Studynamen neu. Probes und Benchmarks laufen mit --detach.
  • Watcher sind lokale Prozesse und sterben mit der Maschine oder dem Netzwerk. Führe sie unter nohup und caffeinate aus; starte watch nach jeder Unterbrechung neu (es nimmt seinen Zustand wieder auf). Es wiederholt DNS- und Verbindungsfehler selbst; die eigene Exception eines Versuchs ist ein Fehler und wird gemeldet.
  • Zeitlich ausgefallene Full-Weight-Versuche werden vom Watcher fortgesetzt, nicht von Modal. Versuche spawnen mit Modals Retries aus; wenn der Aufruf eines Full-Weight-Versuchs durch sein Timeout endet, führt watch modal_app.py::resume --trial <label> aus, das den nächsten Versuch startet (er setzt vom letzten committeten Resume-Punkt fort) mit der GPU und dem Timeout, für die die Studie zugelassen wurde, und ihn in runs/<study>.spawn.json erfasst (attempts, höchstens 1 + kev.budget.FULL_FT_RETRIES pro Versuch, die Anzahl, mit der die Admission Bound berechnet wurde; ein Versuch, dessen aktueller Aufruf noch läuft, wird nie fortgesetzt). Solange der Watcher aus ist, wird nichts fortgesetzt: Starte ihn neu, und er nimmt das Timeout auf. Warum: Modal berechnete jeden zeitlich ausgefallenen Versuch doppelt (das Timeout und dann die Aufgabe, die es 30 s später tötete), sodass Retries(2) dem Versuch von Runde 22 zwei seiner drei Versuche gab, und der Retry des Kills neben einem laufenden Versuch starten kann (scripts/modal_retry_probe.py). Eine Studie, die vor dem Ledger gespawnt wurde, hat keine Anzahl: resume --trial <label> --beyond-bound setzt sie von Hand fort, außerhalb jeder Bound, und sagt das auch. Zwei Versuche teilen sich nie einen Trial: Jeder wird vor seinem Spawn als ausstehend erfasst, und jeder hält ein Lease auf dem kev-leases- Volume (Heartbeat jede Minute); ein neuer Versuch verweigert, solange das Lease eines anderen frisch ist, und eine Fortsetzung wartet bis zu kev.budget.LEASE_STALE (15 min) nach dem letzten Heartbeat eines getöteten Versuchs, bevor sie spawnt.
  • Netzwerkabbrüche töten lokale Clients, nicht die entfernte Arbeit: Ein Read, dessen Client starb, ist auf Modal meist fertig; hole sein Verzeichnis vom Volume (modal volume get kev-runs /<name> runs/<name>), statt es neu zu starten.
  • Ein fehlgeschlagenes Benchmark oder Probe hinterlässt sein Verzeichnis auf dem Volume; wiederhole es unter einem neuen Namen.

7. Berichterstattung

Am Ende der Sitzung (und in der State-Datei fortlaufend):

  • Der PLAN.md-Abschnitt jeder Runde trägt ihre Registrierung, ihre Read-out-Tabelle, ihre Bestätigungsergebnisse und ihr Verdict, ob negativ oder nicht, mit Berichtspfaden.
  • Aktualisiere in PLAN.md „Where we stand” (veröffentlichte und bestätigte Kandidaten, laufende Jobs, Ausgaben) und „What we have learned”, wenn sich ein Befund geändert hat; füge jede Runde der Record-Tabelle hinzu.
  • Eine Sitzungszusammenfassung in PLAN.md: Ausgaben (Basis, finaler Messwert, laufende Bounds), was auf Modal aussteht mit den exakten Befehlen zum Abschließen, Vorfälle und höchstens drei nächste Schritte mit ihren Belegen.
  • Jede Zahl trägt Checkpoint, Suite und Partition, n und Berichtspfad; committe die Read-outs und Verdicts, aus denen die Zahlen stammen (.gitignore behält Berichte, nicht Prediction-Dumps; füge eine Regel für neue Read-out-Verzeichnisse hinzu).
  • Uhrzeiten: Registrierungs- und Ergebniszeiten sind Commit-Zeiten. Schreibe keine Zeit in eine Überschrift, bevor sie geschieht; das Scratchpad von Nacht 3 tat das, und seine Zeitstempel waren nicht verwendbar.

8. Bekannte Fallstricke

  • Modal-Rate-Limit beim App-Erstellen. Mehr als etwa drei abgekoppelte modal runs innerhalb einer Minute scheitern mit “App create rate limit exceeded”, und nichts läuft. kev.rounds staffelt Starts 60 s auseinander und batched die Reads eines Arms in einen Aufruf; mach es von Hand genauso.
  • repo@sha in Benchmark-Jobs verschob früher jedes Feld von run@suite@name@flags; modal_app.parse_jobs parst jetzt von rechts, sodass gepinnte Hub-Revisionen sicher sind. Suites und Namen dürfen kein @ oder , enthalten.
  • Ein Pull pro Studie. Gleichzeitige Pulls derselben Studie löschten gegenseitig ihre Trial-Verzeichnisse; pull_study hält jetzt ein Lock pro Studie. Ein Pull, während Versuche noch laufen, ist sicher und aktualisiert nur unfertige Versuche.
  • Pulls lassen vollständige Gewichte auf dem Volume. ::pull (und watch) überspringt Full-Weight-Shards (model*.safetensors, ~51 GB pro 27B-Checkpoint oder -Snapshot) und Resume-Punkte; alles andere kommt herunter (Ergebnisse, Zeilen, head.pt, Configs). Lies einen Checkpoint oder einen Snapshot auf dem Volume: ::benchmarks --jobs "/runs/<study>/<trial>/snapshots/step-<N>/checkpoint@<suite>@<name>". ::pull --weights kopiert die Shards, wenn etwas lokal sie wirklich braucht.
  • Nach den Daten deployen. Das Image kopiert evals/; der Launcher prüft nur kev/*.py-Hashes, daher scheitert ein Versuch, dessen Datendatei nach dem Deploy hinzugefügt wurde, im Container. --gpu H200 bei study braucht eine App, die mit KEV_GPU=H200 bereitgestellt wurde.
  • 27B. Nur H200 (bf16-Backbone, 55 GB resident); Study-Timeouts bis 28,800 s (ein 1-Epochen-Skills-Delta bei lr 2e-5 lief etwa 8.8 s pro Optimizer-Schritt); fp32-Reads etwa dreimal so lang wie die eines 9B (Spec read_timeout: {"27b": 14400}); der gesperrte Read braucht --timeout 14400 --memory-mb 131072 (Spec locked_args) auf einer H200 (die GPU kommt aus dem gpu der Spec / der bereitgestellten App oder per Hand aus --gpu H200). Jeder Versuch mit bf16-Gewichten scheitert am In-Trial- isolation_and_packing-Gate (eine fp32-Prüfung); lies Ergebnisse aus den Zeilen und miss die bediente Isolation separat in bf16.
  • locked_test-Benennung. Wenn ein In-Trial-Screening-Gate scheiterte, verlangt das Tool das Suffix -ungated (kev-4b-r8-ungated); das Verdict folgt trotzdem der registrierten Regel.
  • Read-Timeouts pro Suite. modal_app.READ_TIMEOUTS setzt Long-State-Panels auf 7,200 s, Dokumente auf 5,400 s, transfer-v9 3,600 s, sonst 1,800 s. Ein globales --timeout bläht die Admission Bound jedes Jobs im Batch auf.
  • Budget-Zulassung. Ein Start über seinem --budget beendet sich, bevor etwas läuft; starte mit einem Budget neu, das mindestens die ausgegebene Bound ist.
  • Externe Server sind Single-Flight. AutoJevs Server beantwortete jeweils eine Anfrage (HTTP 529, wenn beschäftigt); teste einen fremden Endpunkt vor einem langen kev.benchmark --remote und setze --remote-concurrency auf das, was er verkraftet. Zähle die Anfragen, die er ablehnt (zum Beispiel ein 422 jenseits seines Kontexts), als Abdeckung, verwerfe sie niemals stillschweigend.
  • Temperatur: ausgeliefert vs. in-trial. Das result.json eines Versuchs und seine gesperrte Zusammenfassung werden beim In-Trial-Fit bewertet; ein Release liefert das T aus, das scripts/calibrate_checkpoint.py in head.pt geschrieben hat. Der erste AutoJev-Head-to-Head bediente Kev-27B beim In-Trial-Wert 1.19 statt der ausgelieferten 1.38 und musste korrigiert werden. Sag, welches T jede Zahl verwendet und wo es gefittet wurde (Abschnitt 3, Regel 4: zurückgehaltene Datensätze, niemals die eigenen Partitionen des Trainingskorpus).
  • Langkontext-Kalibrierung. Ein Panel mit "by_length": true berichtet Genauigkeit, ECE, Brier und sichere Fehler pro Zustands-Token-Bucket (unter 8k bis 64k+, und die 8k+/16k+/32k+-Enden), und ein Kriterium kann eines gaten (long.ece_16k_plus.candidate <= 0.05). Token werden aus den Suite-Datensätzen der Reads gezählt, sodass beide Seiten dieselben Buckets teilen.
  • Suite-Korrekturen ohne neue Suite-Version. Ein Panel kann Quellen, Aufgaben oder eine (private, hash-registrierte) Liste von IDs oder Quellen auf beiden Seiten weglassen (exclude_sources, exclude_tasks, exclude_file), und ein reines Berichts-Panel ist mit "optional": true markiert, sodass ein fehlender Berichts-Read einen Kandidaten nie unvollständig macht. Wähle Ausschlüsse nach Label-Gültigkeit vor jedem Read-out unter ihnen (Runde 24 nahm sie aus dem Audit vom 2026-09-27), und committe niemals eine private Liste.
  • Workspace-Kapazität. Der Workspace hat höchstens etwa zehn GPU-Container gleichzeitig ausgeführt; ausstehende Container sind Kapazität, kein Bug, also starte sie nicht neu.
  • Kleine Suites. Ein Guard auf 89 oder 144 Fragen kann einen Boden von 2-3 pp nicht auflösen; gate sie über ein gepooltes Panel.
  • Jev-Reads scheitern mittendrin bei Gateway-503s; führe den ganzen Read unter einem neuen Namen erneut aus, statt Teilzeilen zusammenzuflicken.
  • Soft-Target-Daten. Wenn du einen Builder schreibst, prüfe eine Handvoll Datensätze mit dem Auge: target summiert sich zu 1, und die Masse des Labels ist mindestens 0.5, es sei denn, der Datensatz ist unerkennbar (kev.data.none_pair trainierte einst null Masse auf Soft-Targets, behoben in #60).
  • Leite die Ausgabe von modal run ...::study in eine Logdatei um; ein Filter kann das SystemExit verbergen, das erklärt, warum nichts gestartet wurde.