Repro Lens: Reproduzierbarkeitsprüfung für ML-Agents

Repro Lens ist ein Reproduzierbarkeits-Prüftool für ML- und Coding-Agents: Es scannt Code auf Reproduzierbarkeitsrisiken, spielt Experimente erneut ab und vergleicht die Ausgaben vor und nach Änderungen. Wenn du nach einer Änderung an ML-Code bestätigen möchtest, dass Experimentresultate nicht beeinträchtigt wurden, ist das der Hauptzweck des Tools. Die statische Prüfung benötigt nur Python 3.11+ und Git – keine ML-Abhängigkeiten oder API-Keys. Das Replay von Experimenten hingegen benötigt die eigenen Abhängigkeiten des Experiments und muss von dir explizit ausgelöst werden.

Für wen es geeignet ist

• ML-/Forschungsingenieur:innen, die vor und nach Codeänderungen die Reproduzierbarkeit von Experimenten verifizieren müssen, sowie Teams, die für Coding-Agents einen Reproduzierbarkeits-Audit-Workflow einrichten.
• Nutzer:innen, die nur einen statischen Scan durchführen wollen: keine ML-Abhängigkeiten, kein API-Key nötig; der gescannte Code wird nicht importiert oder ausgeführt, und die Ausgabe liefert statische Fundstellen mit Dateipositionen.
• Nicht geeignet: Ohne Git-Umgebung ist keiner der beiden Installationswege nutzbar; bei Python unter 3.11 lässt sich der statische Prüfer nicht ausführen. Abgesehen von diesen Anforderungen nennt das Quellmaterial keine weiteren Systemvoraussetzungen; ob Plattformen wie Windows unterstützt werden, ist offiziell nicht angegeben.
• Was die Evidenz nicht hergibt, darf nicht angenommen werden: Es ist nicht deklariert, welche Text- oder Codesprachen unterstützt werden, noch in welchen Agent-Clients das Tool verfügbar ist.

Erster Versuch in 3 Minuten

Voraussetzung: Python 3.11+, Git und uv sind lokal installiert. Der empfohlene Hauptweg ist die Installation einer festgelegten Version aus dem offiziellen Repository per uv:

uv tool install 'git+https://github.com/00200200/[email protected]'

Als Alternative lässt sich dieselbe Git-URL in einer virtuellen Umgebung per pip installieren (ebenfalls mit Git) – dies ist nur ein sekundärer Einstieg und stellt keinen zweiten Hauptpfad dar.

Nach der Installation zuerst eine risikoarme, rein lesende statische Prüfung durchführen: Stelle in deinem Projekt an den Agent oder das Terminal die Aufgabe „Prüfe mit repro-lens check, ob diese Datei bekannte Reproduzierbarkeitsrisiken enthält“. Die zentrale Operation ist check: Sie liefert statische Fundstellen mit Dateipositionen, und der gescannte Code wird niemals importiert. Erfolgssignal: Die Ausgabe listet Fundstellen mit Dateipositionen auf (auch ein Ergebnis „keine Risiken gefunden“ zeigt an, dass der Lauf erfolgreich war).

Hinweis: check ist eine Diagnoseoperation – das bedeutet nur, dass der gescannte Code nicht importiert wird; ob sie Dateien liest oder schreibt, Befehle ausführt oder aufs Netzwerk zugreift, sagt das Quellmaterial nicht und kann nicht bestätigt werden. Das Experiment-Replay (verify, verlangt, dass die deklarierten Ausgaben beider Läufe übereinstimmen) führt das Experiment tatsächlich aus und ist eine Operation mit Nebenwirkungen – beim ersten Versuch nicht verwenden; falls doch, zuerst sicherstellen, dass alle Experiment-Abhängigkeiten vorhanden sind, und vor dem Auslösen explizit bestätigen.

Anwendungsfälle

Fall 1: Statischer Audit vor einer Änderung am Trainingsskript. An den Agent: „Führe repro-lens check auf dem Trainingsskript aus.“ Das Tool führt die Operation check aus und liefert statische Fundstellen mit Dateipositionen, ohne den Code zu importieren. Daran lässt sich ablesen, ob die Änderung bekannte Reproduzierbarkeitsrisiken einführt; wenn Details über das Quellmaterial hinaus (etwa eine konkrete Regelliste) fehlen, lässt sich nur bis zu „Fundstellen mit Positionen erhalten“ bestätigen.

Fall 2: Ausgabenvergleich nach einer Korrektur. Voraussetzung ist, dass du vor der Änderung einen Report über den offiziellen Workflow gespeichert hast. An den Agent: „Replay das Experiment mit repro-lens verify und vergleiche die beiden gespeicherten Reports mit compare.“ verify verlangt, dass die deklarierten Ausgaben beider Läufe exakt übereinstimmen; compare difft gespeicherte Reports. Erwartetes Ergebnis: verify bestätigt, dass die Ausgaben der Deklaration entsprechen; compare zeigt die Report-Differenzen. Das Replay benötigt die eigenen Abhängigkeiten des Experiments und ist ein expliziter Befehl – das Tool replayt nichts automatisch.

Nutzungsgrenzen

• Datei- und Befehlszugriff: check importiert den gescannten Code nicht; verify führt das Experiment aus (Abhängigkeiten erforderlich), und das Replay bleibt stets ein expliziter Befehl. Der Pre-Commit-Hook (Repository repro-lens, rev v0.3.0, id repro-lens) prüft nur Code und Projekt-Policies und replayt nicht automatisch. Ob Netzzugriff stattfindet, ist offiziell nicht angegeben.
• Bestätigungspunkt: Jede Operation, die ein Experiment ausführt (verify), sollte vor dem Auslösen hinsichtlich Experimentkonfiguration und Nebenwirkungen bestätigt werden.
• Installationsunterschiede: Empfohlen wird die Installation der festgelegten Version v0.3.0 per uv; die pip-Installation in einer virtuellen Umgebung ist die offiziell genannte Alternative. Das Quellmaterial erwähnt weder Marketplace noch andere Installationswege – nicht annehmen.
• Agent-Integration: Die Datei skills/reproducibility/SKILL.md im Repository kann bestehende Coding-Agents durch Audits oder autorisierte Korrekturen führen; ihr Launcher nutzt dieselbe Engine wie die CLI. Das vollständige Repository ist zudem ein Codex-Plugin (mit .codex-plugin/plugin.json). Darüber hinaus ist nicht offiziell aufgelistet, welche Agent-Clients konkret unterstützt werden.
• Unbestätigte Kerninformationen: Netzwerkverhalten, unterstützter Umfang an Codesprachen sowie die Lese-/Schreibgrenzen von check/compare sind offiziell nicht dokumentiert – vor der Nutzung die Repository-Dokumentation maßgeblich heranziehen.