Tensorflow Deep Learning

Einheitliche Struktur für TensorFlow/Keras-Projekte: Modell, Datenpipeline und Training konsistent halten.

Original-Beschreibung der Autoren: TensorFlow and deep learning rules for building, training, evaluating, and deploying neural network models

Die Regel

---
description: TensorFlow and deep learning rules for building, training, evaluating, and deploying neural network models
globs: ["**/*.py", "**/*.ipynb", "pyproject.toml", "requirements*.txt", "environment*.yml"]
alwaysApply: false
---

# TensorFlow and Deep Learning Rules

## Project Structure

- Separate data loading, model definition, training, evaluation, and serving code.
- Use `tf.data` pipelines for scalable input processing.
- Keep model hyperparameters in typed config files or dataclasses.
- Store checkpoints, logs, and exported models outside source directories.
- Keep notebooks exploratory; move repeatable training code into modules.

## Model Development

- Start with a small baseline model and a tiny overfit test before scaling.
- Use Keras layers and models unless lower-level TensorFlow APIs are required.
- Prefer explicit input shapes and named inputs/outputs.
- Use callbacks for checkpointing, early stopping, learning-rate scheduling, and TensorBoard logging.
- Use mixed precision only after validating numerical stability.
- Pin random seeds where reproducibility matters, while documenting nondeterministic GPU behavior.

## Training

- Validate data shapes, dtypes, label ranges, and class balance before training.
- Split data before augmentation or normalization fitting.
- Use validation data for tuning and a separate test set for final reporting.
- Track loss curves, metrics, learning rate, and resource use.
- Save the best checkpoint by validation metric, not by final epoch.

## Evaluation

- Report task-appropriate metrics such as AUROC, F1, calibration, perplexity, BLEU/ROUGE, or MAE/RMSE.
- Include confusion matrices or error slices for classification tasks.
- Evaluate on edge cases and distribution shifts when data allows.
- Compare against non-neural baselines when the dataset is small or tabular.

## Deployment

- Export models with clear input signatures.
- Keep preprocessing consistent between training and serving.
- Add smoke tests that load the exported model and run inference on sample inputs.
- Monitor latency, memory, prediction drift, and input schema changes.

## Common Mistakes

- Do not tune architecture before verifying labels and data quality.
- Do not leak validation data through preprocessing or augmentation.
- Do not rely on accuracy alone for imbalanced data.
- Do not deploy a notebook-only model.
- Do not ignore batch size, dtype, and device differences between training and inference.

So nutzt du sie

Die Regel kopieren (Button oben) oder als Datei herunterladen und im Projekt unter .cursor/rules/ ablegen — Cursor lädt sie beim nächsten Start automatisch. Ältere Cursor-Versionen lesen alternativ eine einzelne .cursorrules-Datei im Projektstamm; dort einfach den Regel-Text ohne den Kopfblock zwischen den ----Zeilen einfügen.

Der Regel-Text ist englisch — Cursor versteht ihn unabhängig von der Sprache, in der Sie mit dem Editor chatten.

Im Detail

Regel für Deep-Learning-Code mit TensorFlow/Keras: einheitliche Modellstruktur (Subclassing oder funktionale API), klare Trennung von Datenpipeline (tf.data), Trainingsloop und Evaluation sowie Konventionen für Checkpointing und Mixed-Precision-Training. Hilfreich für ML-Teams, die viele ähnliche Trainingsskripte pflegen und Wildwuchs bei Modell-Definitionen vermeiden wollen. Wer auf PyTorch setzt, profitiert nicht davon — die Regel ist TensorFlow-spezifisch und hilft am meisten bei klassischen Supervised-Learning-Projekten, weniger bei exotischen Custom-Training-Loops.

Praxis-Tipp

Bei neuen Modellen explizit „mit tf.data-Pipeline und funktionaler Keras-API“ anfordern, damit Cursor nicht auf ältere Sequential-Patterns zurückfällt.

Lizenz & Quelle

• Lizenz: CC0 1.0
• Quelle: PatrickJS/awesome-cursorrules (GitHub)

Lade …