FrankS-IntelLab/agentic-kaggle-skill

Agentic Kaggle Skill

Betriebsschleife

Behandle jeden Wettbewerb zuerst als Validierungsproblem und dann als Modellierungsproblem. Die Standard-Zielplattform ist Kaggle, daher bevorzuge Kaggle-native Notebooks/Skripte, Datensätze, Modellartefakte, Wettbewerbseinreichungen und Score-Belege. Bei Code-Wettbewerben nimm an, dass das finale Notebook/Kernel von Kaggle gegen versteckte Daten erneut ausgeführt wird, es sei denn, die Wettbewerbsunterlagen beweisen das Gegenteil.

1. Lies die Wettbewerbsseite, klassifiziere den Einreichungsmodus als klassische Dateieinreichung oder Code-/Notebook-Bewertung, überprüfe dann die Regeln, Datennutzungsbedingungen, Freigaberichtlinie, Datenwörterbuch, Metrik, Einreichungsformat, Hinweise zur Aufteilung von Trainings-/Testdaten und Leakage-Warnungen.
2. Wenn Live-Wettbewerbs-Intelligenz-Tools verfügbar sind, überprüfe top-öffentliche Open-Solution-Notebooks und relevante Diskussionsaktivitäten, bevor große Architekturentscheidungen getroffen werden; behandle sie als Hinweise, nicht als Autorität.
3. Identifiziere den Aufgabentyp: binär, multiklassen, multilabel, Regression, Ranking, Bild, Segmentierung, Text, Zeitreihe, gruppierte Entitäten oder ein Hybrid.
4. Entwerfe Folds vor Feature-Engineering oder Modellierung. Bevorzuge eine Fold-Spalte, die in die Trainingsdaten gespeichert wird, damit jedes Experiment dieselbe Vergleichsfläche verwendet.
5. Baue die einfachste metrikkorrekte Baseline und erstelle Out-of-Fold (OOF)-Vorhersagen sowie eine gültige Einreichung.
6. Plane proaktiv eine stärkere Architektur, sobald die Baseline vertrauenswürdig ist: verschiedene Modellfamilien, Feature-/Embedding-Producer, Augmentierungs-/Pseudo-Labeling-/Distillationsstufen, Kalibrierung/Postprocessing und ein Ensemble oder Stacker.
7. Iteriere mit Validierungsgates: Teste nach Möglichkeit jeweils eine sinnvolle Änderung, starte aber mehrere unabhängige Producer-Notebooks parallel, wenn sie verschiedene Artefakte erstellen, die per OOF-Score oder Ensemble-Diversität verglichen werden können.
8. Lagere schweres Training, Inferenz, Embedding-Generierung, Bild-/Text-Experimente oder speicherintensive Jobs an Kaggle-Notebooks/Skripte aus, wenn die lokale Rechenleistung für OOM oder zu lange Laufzeiten anfällig ist.
9. Teile für anspruchsvolle Architekturen die Arbeit in eine kleine Kaggle-Pipeline auf: Führe zuerst mehrere unabhängige Producer-Notebooks/Skripte aus, speichere jede nützliche Producer-Ausgabe als privaten Kaggle-Datensatz, führe dann ein Consumer-Notebook/Skript aus, das diese Datensätze anhängt und die finalen OOF-/Test-/Einreichungsausgaben erstellt. Wenn ein Producer ein Modell trainiert, sollten sein Checkpoint, Tokenizer/Konfiguration, Fold-Metadaten, OOF-/Test-Vorhersagen und ein Manifest als Kaggle-Datensatz exportiert werden; nachgelagerte Notebooks laden das Modell von /kaggle/input/....
10. Reiche das finale einreichungsproduzierende Artefakt bei Kaggle zur Bewertung ein und rufe den resultierenden Einreichungsstatus/Score ab.
11. Wenn Kaggle einen Code-Wettbewerbsfehler oder einen vagen Bewertungsfehler zurückgibt, betrete die Debugging-Schleife: Rufe verfügbare Logs ab, klassifiziere den wahrscheinlichen Fehlermodus, patche defensiv, führe den finalen Kernel erneut aus, reiche erneut ein und wiederhole, bis bewertet oder konkret blockiert.
12. Verfolge lokale CV, entfernten Kaggle-Run-Status, Kaggle-Einreichungs-Score, öffentliches LB, private Risikonotizen, Seed, Code-Version, Datenversion und Artefaktpfade für jeden Durchlauf.
13. Ensemble nur mit OOF-Vorhersagen, die ohne In-Fold-Leakage generiert wurden.

Ressourcenkarte

• Lies references/method-map.md für die neutrale Workflow-Karte hinter dem Skill.
• Lies references/information-sharing-policy.md, bevor Wettbewerbs-Code, Notebooks, Datensätze, Modelle, Artefakte oder Berichte außerhalb des aktiven Teams oder Arbeitsbereichs veröffentlicht werden.
• Lies references/competition-intel.md, wenn ein Kaggle-Wettbewerbs-Slug, URL, Titel, öffentlicher Leaderboard-Kontext, offene Lösungen oder Diskussionsaktivitäten den Ansatz informieren könnten.
• Lies references/cross-validation-and-metrics.md bei der Wahl von Folds, Metriken, Schwellwerten oder Leakage-Checks.
• Lies references/tabular-workflow.md für kategoriale Variablen, Feature-Engineering, -Auswahl und Hyperparameter-Tuning.
• Lies references/image-text-workflow.md für Ansätze bei Bild-, Segmentierungs- und NLP-Wettbewerben.
• Lies references/kaggle-code-competition-pipeline.md, wenn das Ziel ein Kaggle-Code-Wettbewerb, versteckter Re-Run, finaler Notebook-Bewertungsfluss oder Modellartefakt-Übergabe zwischen Producer- und Consumer-Notebooks ist.
• Lies references/advanced-notebook-architecture.md, wenn eine stärkere Lösung mehrere Modellfamilien, gestaffelte Feature-/Embedding-/Modell-Producer, Pseudo-Labeling, Distillation, Postprocessing, Blending, Stacking oder parallele Kaggle-GPU-Notebooks erfordert.
• Lies references/kaggle-offload.md, wenn lokale Läufe schwer sind, GPU nützlich ist, Kaggle-Datenzugriff benötigt wird oder entfernte Notebook-Ergebnisse gesammelt werden müssen.
• Lies references/kaggle-pipeline-datasets.md, wenn mehrere Kaggle-Notebooks, Zwischendatensätze, Notebook-Ausgabequellen oder kagglehub verwendet werden.
• Lies references/submission-endgame.md, bevor die Arbeit eingestellt wird; dieses Skill ist nicht abgeschlossen, bis ein Kaggle-Scoring versucht und das Ergebnis gesammelt oder ein konkretes Hindernis dokumentiert wurde.
• Lies references/code-competition-debugging.md, wenn eine Kaggle-Code-Wettbewerbseinreichung fehlschlägt, timeoutet, OOMt, keinen Score liefert oder einen vagen versteckten Run-/Scoring-Fehler meldet.
• Lies references/ensembling-and-reproducibility.md für Projektlayout, OOF-Artefakte, Stacking, Blending und Wiederholbarkeit.
• Lies references/research/ oder examples/ nur, wenn der Benutzer nach historischen Fallstudien, Hermes-Ära-Mustern oder konkreten Wettbewerbslektionen aus diesem Repository fragt.
• Führe scripts/scaffold_competition.py aus, um einen Wettbewerbsarbeitsbereich zu erstellen.
• Führe scripts/make_folds.py aus, um eine Fold-Spalte zu einem Trainings-CSV hinzuzufügen.
• Führe scripts/prepare_kaggle_kernel.py aus, um einen Kaggle-Kernel-Ordner mit Metadaten und abrufbaren Experiment-Logs zu erstellen.
• Führe scripts/prepare_kaggle_dataset.py aus, um Metadaten und Befehle für versionierte Zwischenartefakt-Datensätze zu erstellen.

Standard-Kaggle-Verfahren

Beginne mit der Metrik und Validierung:

• Reproduziere die Wettbewerbsmetrik lokal, einschließlich Clipping, Transformationen, Durchschnittsmodus, Schwellwerten und Stichprobengewichten.
• Überprüfe, ob der Wettbewerb öffentlichen Code, externe Daten, vortrainierte Gewichte, generierte Artefakte und öffentliche Repositories erlaubt, bevor etwas außerhalb des Teams geteilt wird.
• Klassifiziere den Kaggle-Einreichungspfad frühzeitig. Wenn es ein Code-Wettbewerb oder ein notebook-bewerteter Workflow ist, gestalte das finale Consumer-Notebook von Anfang an als Bewertungsartefakt.
• Verwende MCP-Tools wie kaggle-competition-intel, wenn verfügbar: top_open_solutions für nach Score sortierte plus neueste hochbewertete Notebooks und competition_discussions für am höchsten bewertete plus kürzlich aktive Diskussionsthemen, bevor teure Baselines gewählt werden.
• Wähle Folds, die zur versteckten Testverteilung passen. Verwende Stratifizierung für Klassifikation, gebinnte Stratifizierung für Regression, Gruppensplits für wiederholte Entitäten, zeitbewusste Splits für Zeitreihendaten und multilabel-bewusste Splits, wenn Label-Ko-Okkurrenz wichtig ist.
• Speichere OOF-Vorhersagen für jedes Modell. OOF-Dateien sind die Währung für Fehleranalyse, Schwellwert-Tuning, Blending und Stacking.
• Vergleiche den mittleren Fold-Score und die Fold-Varianz, nicht nur den besten Fold.
• Behandle einen öffentlichen LB-Sprung, der mit der CV nicht übereinstimmt, zuerst als Validierungsfrage, bevor du ihn als Modellierungserfolg betrachtest.

Baue dann Baselines in dieser Reihenfolge:

1. Nur-Metrik- oder konstante Baseline zur Überprüfung des Scoring- und Einreichungsformats.
2. Schnelle klassische Baseline: LightGBM/CatBoost/XGBoost für tabellarisch, TF-IDF plus lineares Modell für Text, vortrainiertes Backbone für Bilder.
3. Starke Baseline mit stabilen Folds, sauberen Artefakten und OOF-Vorhersagen.
4. Feature-/Modell-Experimente mit Run-Logs und einer primären Metrik.
5. Ensembling oder Stacking, nachdem mehrere verschiedene, einzeln validierte Modelle existieren.

Warte nicht darauf, dass der Benutzer explizit nach Raffinesse fragt, wenn der Wettbewerb sie rechtfertigt. Nach einer stabilen Baseline schlage eine stärkere gestaffelte Architektur vor und führe sie aus, wenn öffentliche Lösungen, Diskussions-Intelligenz, Datenmodalität, Metrikdruck oder CV-Plateau darauf hindeuten, dass ein einzelnes Notebook/Modell unterperformen wird. Halte die Architektur durch OOF-Beweise, Artefakt-Manifeste und finales Kaggle-Scoring abgesichert.

Wenn ein Lauf wahrscheinlich den lokalen RAM/VRAM übersteigt, eine GPU/TPU erfordert oder Kaggle-exklusive Daten-Mounts benötigt, bereite einen Kaggle-Kernel-Lauf vor, anstatt ihn lokal zu erzwingen. Der entfernte Lauf muss experiment_log.json, metrics.jsonl und ein Artefakt-Manifest ausgeben, sodass Ergebnisse nach kaggle kernels output abgerufen und interpretiert werden können.

Wenn die Lösung mehrere schwere Stufen hat, halte den entfernten Graphen flach und überprüfbar:

• Verwende weniger als fünf unabhängige Producer-Notebooks/Skripte pro Welle.
• Gib jedem Producer eine einzige Verantwortung, wie Feature-Generierung, Embedding-Extraktion, Fold-Training, Checkpoint-Training, Modelldistillation oder Inferenz.
• Für Code-Wettbewerbe bevorzuge Producer-Notebooks, die Modelle/Checkpoints trainieren und als private Kaggle-Datensätze exportieren; der finale Consumer sollte diese Datensätze anhängen, Modelle von /kaggle/input/... laden und versteckte-test-sichere Inferenz durchführen.
• Speichere Ausgaben von Producer-Notebooks als versionierte private Kaggle-Datensätze für dauerhafte Wiederverwendung und als stabile Eingaben für nachgelagerte Notebooks; verwende direkte kernel_sources nur für kurzlebige Ketten, bei denen Haltbarkeit/Versionierung unnötig ist.
• Führe ein finales Consumer-Notebook/Skript aus, das die erstellten Datensätze anhängt, ihre Artefakte liest, die finalen OOF-, Testvorhersagen, Blend-/Stack-Bericht und Einreichung schreibt und dann dieses finale Artefakt/Kernel bei Kaggle zur Bewertung einreicht.
• Verwende kagglehub innerhalb von Python, wenn es bequemer ist, Datensätze, Wettbewerbsdateien, Notebook-Ausgaben herunterzuladen oder Datensatzversionen programmatisch hochzuladen.

Abschlussdefinition

Höre nicht bei einem Plan, Gerüst, trainierten Modell, Notebook-Lauf, heruntergeladener Ausgabe oder lokalem Validierungsscore auf. Fahre fort, bis eines dieser Kriterien erfüllt ist:

• Eine Wettbewerbseinreichung wurde an Kaggle gesendet, Kaggle hat sie verarbeitet und der öffentliche Score oder Einreichungsstatus wurde abgerufen und aufgezeichnet.
• Ein finales Code-Wettbewerbs-Notebook/Kernel hat alle erforderlichen Producer-Artefakte verbraucht, wurde mit seiner Kernel-/Versionsreferenz eingereicht, und der resultierende Einreichungsstatus/Score wurde abgerufen und aufgezeichnet.
• Ein konkretes externes Hindernis verhindert die Bewertung: fehlende Kaggle-Anmeldedaten, nicht akzeptierte Regeln, Kontingent nach Wiederholungsversuchen erschöpft, Wettbewerb geschlossen, Bewertung deaktiviert, erforderliche manuelle UI-Aktion, nicht verfügbare Kernel-Version oder Kaggle-Dienstausfall. Dokumentiere das genaue Hindernis und den nächsten benötigten Befehl/die nächste Aktion.

Validierungsoptionen

Verwende diese schnelle Zuordnung:

• Ausgeglichene Klassifikation: StratifiedKFold.
• Unausgeglichene Klassifikation: stratifizierte Folds plus metriksensitive Schwellwertanpassung oder Klassen-Gewichte.
• Regression: KFold für gewöhnliche Ziele, gebinnte stratifizierte Folds für schiefe oder multimodale Ziele.
• Gleicher Benutzer, Patient, Produkt, Sitzung, Dokument oder Bildquelle erscheint mehrfach: GroupKFold oder stratifizierte Gruppenteilung.
• Geordnete Ereignisse oder Prognosen: Zeitteilung, Expanding-Window-Validierung oder wettbewerbsspezifische Periodenteilung.
• Bilder vom gleichen Subjekt oder Szene: Gruppierung nach Subjekt/Szene vor der Augmentierung.
• Text mit duplizierten Quellen, Autoren, Fragen, Produkten oder Aufforderungen: Gruppierung nach Quellenschlüssel.
• Kleine Daten: wiederholte Folds oder mehr Folds, aber halte die finale Modellauswahl-Disziplin streng.

Modellierungsprioritäten

• Für tabellarische Wettbewerbe bevorzuge zuerst Tree-Boosting, es sei denn, die Daten sind meist spärlicher Text oder hochkardinale kategoriale Interaktionen. Füge CatBoost hinzu, wenn kategoriale Spalten zentral sind.
• Für lineare Modelle und neuronale Netze: Skaliere numerische Features und codiere Kategoriale sorgfältig.
• Für Baummodelle: Beginne mit Label-/Count-/Frequenz-Codierungen und sinnvollen fehlenden Werten; Skalierung ist normalerweise unnötig.
• Für Target-Codierung: Berechne Codierungen immer out-of-fold, mit Glättung und ohne Sichtbarkeit des Validierungsreihenziels.
• Für Bildaufgaben: Richte Datensatz, Transformationen, Labels, Masken und Metrik korrekt ein, bevor die Architektur geändert wird.
• Für Textaufgaben: Behalte eine TF-IDF-Baseline, auch wenn Transformatoren verwendet werden; sie ist schnell, interpretierbar und lässt sich oft gut blenden.
• Für Hyperparameter-Suche: Tune erst, wenn Folds und Baselines vertrauenswürdig sind. Suche Lernrate, Tiefe/Blätter, Regularisierung, Sampling und Anzahl der Schätzer mit Early Stopping.

Wettbewerbshygiene

• Halte Rohdaten schreibgeschützt.
• Halte Wettbewerbsdaten, private Datensätze, Modellcheckpoints, heruntergeladene Ausgaben, Einreichungen, Anmeldedaten und datenabgeleitete Artefakte aus öffentlichen Git-Repositories fern, es sei denn, die Wettbewerbsregeln und Artefakt-Lizenzen erlauben explizit öffentliche Weiterverteilung.
• Lege alle experimentverändernden Werte in Konfiguration oder Befehlszeilenargumente.
• Seed Python, NumPy, Framework und Modellbibliotheken, wenn möglich.
• Speichere Modelldateien, OOF-Vorhersagen, Testvorhersagen, Fold-Scores, Feature-Listen und Einreichungsdateien mit Run-IDs.
• Für Kaggle-ausgelagerte Jobs: Schreibe abrufbare Logs und Artefakte in das Notebook-Arbeitsverzeichnis, einschließlich Run-ID, Git-Commit, Konfiguration, Fold, Metrik, Hardware, verstrichene Zeit, OOM-Notizen und Ausgabedateipfade.
• Für Multi-Notebook-Pipelines: Pflege ein Pipeline-Manifest mit Producer-Kernel-Referenzen, erstellten Datensatzreferenzen, Datensatzversionen, Artefakt-Schemas, Metriken und der finalen Consumer-Run-ID.
• Halte Producer-Datensätze, Kernel und Modellartefakte standardmäßig privat. Mache sie nur öffentlich, nachdem die Zielwettbewerbsregeln, Datenlizenz, Drittanbieter-IP und Benutzerabsicht überprüft wurden.
• Zeichne Einreichungsnachricht, Einreichungsbefehl oder Kernel/Version, Kaggle-Einreichungszeitstempel, Status, öffentlichen Score falls verfügbar und jeden von Kaggle zurückgegebenen Fehler auf.
• Für vage Code-Wettbewerbsfehler: Zeichne den beobachteten Status, verfügbare Logs, vermutete Fehlerklasse, versuchten Patch und nächsten Wiederholungsbefehl auf.
• Trainiere niemals einen Stacker auf In-Sample-Basisvorhersagen.
• Wähle niemals Features, Target-Encoder, Skalierer, Schwellwerte oder Augmentierungen mit Validierungszielen außerhalb der Fold-Grenze.
• Bevorzuge Skripte für wiederholbares Training und Notebooks für Exploration und Plots.

Nützliche Befehle