Entwicklung & Code
Künstliche Neuronale Netze im Überblick 5: Trainingsschleifen und Batching
Neuronale Netze sind der Motor vieler Anwendungen in KI und GenAI. Diese Artikelserie gibt einen Einblick in die einzelnen Elemente. Der erste Teil stellt das künstliche Neuron vor. Der fünfte Teil der Serie erstellt eine vollständige Trainingsschleife, zeigt die Unterschiede zwischen dem Training mit und ohne explizite Mini-Batches und stellt schließlich Techniken wie Dropout und Gewichtsabnahme zur Verbesserung der Generalisierung vor.
Prof. Dr. Michael Stal arbeitet seit 1991 bei Siemens Technology. Seine Forschungsschwerpunkte umfassen Softwarearchitekturen für große komplexe Systeme (Verteilte Systeme, Cloud Computing, IIoT), Eingebettte Systeme und Künstliche Intelligenz.
Er berät Geschäftsbereiche in Softwarearchitekturfragen und ist für die Architekturausbildung der Senior-Software-Architekten bei Siemens verantwortlich.
Um einem Netzwerk beizubringen, seinen Verlust zu minimieren, muss man wiederholt Daten präsentieren, Vorhersagen berechnen, Fehler messen, Gradienten propagieren und Parameter aktualisieren. Dieser Berechnungszyklus bildet die Trainingsschleife. Je nach Rechenressourcen und Problemdimensionen kann man sich dafür entscheiden, den gesamten Datensatz auf einmal, eine Probe nach der anderen oder mehrere Proben, die zu Mini-Batches gruppiert sind, zu verarbeiten.
Eine grundlegende Trainingsschleife in PyTorch beginnt mit der Definition eines Datenladers, der Batches von gelabelten (Eingabe-Ziel-) Paaren liefert, der Instanziierung eines Optimierers und einer Verlustfunktion und der anschließenden Iteration über Epochen. Nachfolgend finden Sie ein vollständiges Beispiel, das Mini-Batches verwendet. Jeder Teil des Codes wird ausführlich erklärt.
import torch
import torch.nn as nn
import torch.optim as optim
from torch.utils.data import DataLoader, TensorDataset
# Angenommen, wir haben einen Merkmals-Tensor X der Form (1000, 20) und einen Ziel-Tensor y der Form (1000,)
dataset = TensorDataset(X, y)
# Erstellen Sie einen DataLoader, der Batches der Größe 32 ausgibt und jede Epoche mischt
data_loader = DataLoader(dataset, batch_size=32, shuffle=True)
model = SimpleMLP(input_dim=20, hidden_dim=50, output_dim=1)
loss_fn = nn.MSELoss()
optimizer = optim.SGD(model.parameters(), lr=0.01, momentum=0.9)
num_epochs = 20
for epoch in range(num_epochs):
epoch_loss = 0.0
# Iterieren Sie über den Datensatz in Mini-Batches
for batch_inputs, batch_targets in data_loader:
# Setzen Sie die aus dem vorherigen Schritt akkumulierten Gradienten auf Null
optimizer.zero_grad()
# Berechnen Sie die Modellvorhersagen für den aktuellen Batch
batch_predictions = model(batch_inputs)
# Berechne den Verlust zwischen Vorhersagen und tatsächlichen Zielen
loss = loss_fn(batch_predictions, batch_targets)
# Backpropagation durch das Netzwerk, um Gradienten zu berechnen
loss.backward()
# Aktualisiere die Modellparameter basierend auf den Gradienten
optimizer.step()
# Akkumuliere den Verlustwert für die Berichterstellung
epoch_loss += loss.item() * batch_inputs.size(0)
# Teile durch die Gesamtzahl der Samples, um den durchschnittlichen Verlust zu erhalten
epoch_loss /= len(dataset)
print(f"Epoch {epoch+1}/{num_epochs}, Verlust: {epoch_loss:.4f}")
Der Code fasst zunächst die Merkmals- und Ziel-Tensoren in einem TensorDataset zusammen, das jede Eingabe mit der entsprechenden Beschriftung verknüpft. Anschließend erstellt er einen DataLoader, der in jeder Epoche Teilmengen der Daten in zufälliger Reihenfolge mit einer Größe von 32 ausgibt. Die Instanziierung des Modells, der Verlustfunktion und des Optimierers folgt den zuvor beschriebenen Mustern.
Die äußere Schleife verarbeitet die Daten für num_epochs
vollständige Durchläufe. Innerhalb dieser Schleife initialisieren wir eine laufende Summe für den Verlust der Epoche. Jedes Mal, wenn der DataLoader einen Stapel von Eingaben und Zielen ausgibt, löscht die Anwendung alle vorherigen Gradienteninformationen, indem sie optimizer.zero_grad()
aufruft. Die Berechnung von model(batch_inputs)
ruft die Vorwärtsmethode des Netzwerks auf und liefert Vorhersagen. Der Code vergleicht diese Vorhersagen mit den tatsächlichen Zielen, indem er die Verlustfunktion aufruft, die einen skalaren Tensor erzeugt.
Der Aufruf von loss.backward()
löst die automatische Differenziation von PyTorch aus, um die Gradienten des Verlusts in Bezug auf jeden lernbaren Parameter im Modell zu berechnen. Diese Gradienten werden im Attribut .grad
jedes Parameters gespeichert. Der Aufruf von optimizer.step()
ändert dann die Parameterwerte an Ort und Stelle gemäß der ausgewählten Aktualisierungsregel (in diesem Fall stochastischer Gradientenabstieg mit Momentum). Wir multiplizieren loss.item()
mit der Batchgröße, um die Summe der Verluste pro Stichprobe zu ermitteln, akkumulieren diese und dividieren sie am Ende durch die Datensatzgröße, um den durchschnittlichen Verlust für die Epoche anzugeben.
Das Training ohne explizite Mini-Batches ist möglich, indem wir den gesamten Datensatz als einen Batch (Stapel) behandeln. In diesem Fall kann man den DataLoader überspringen und schreiben:
# Alle Daten als einen einzigen Batch behandeln
optimizer.zero_grad()
predictions = model(X)
loss = loss_fn(predictions, y)
loss.backward()
optimizer.step()
Dieser Full-Batch-Ansatz liefert zwar bei jedem Schritt den tatsächlichen Gradienten, kann jedoch bei großen Datensätzen ineffizient sein und mehr Speicherplatz als verfügbar erfordern. Umgekehrt kann die Verwendung von Einzelproben-Updates (stochastisch) durch Setzen von batch_size=1
im DataLoader zu einer hohen Varianz in der Gradientenschätzung führen, was zu einer verrauschten Konvergenz führt, die jedoch leichter aus flachen lokalen Minima entkommen kann. Mini-Batches stellen einen pragmatischen Kompromiss dar, indem sie die Varianz reduzieren und gleichzeitig die Speicherbeschränkungen einhalten.
Selbst wenn wir dieses Trainingsverfahren befolgen, können große neuronale Netze die Trainingsdaten überanpassen und statt Muster zu lernen, die sich auf neue Beispiele verallgemeinern lassen, zum Rauschen führen. Um die Überanpassung zu verringern, kann man Techniken für die Regularisierung anwenden.
Gewichtsabnahme, mathematisch äquivalent zur L2-Regularisierung, fügt dem Verlust eine Strafe proportional zur quadrierten Norm der Gewichte hinzu. In der Praxis signalisiert man dem Optimierer die Gewichtsabnahme. Um beispielsweise einen Koeffizienten von 1e-4 zu jedem Parameter außer den Biases hinzuzufügen, schreibt man:
optimizer = optim.SGD(
[
{'params': model.fc1.weight, 'weight_decay': 1e-4},
{'params': model.fc2.weight, 'weight_decay': 1e-4},
{'params': model.fc1.bias, 'weight_decay': 0},
{'params': model.fc2.bias, 'weight_decay': 0}
],
lr=0.01,
momentum=0.9
)
Durch die Angabe von weight_decay
für jede Parametergruppe fügt der Optimierer weight_decay * θ
zum Gradienten jedes Gewichts hinzu und führt so effektiv die Aktualisierungsregel
θ ← θ − η ( ∂L/∂θ + λ · θ )
für jedes Gewicht θ aus, wobei λ der Gewichtsabklingkoeffizient ist.
Eine weitere leistungsstarke Regularisierungstechnik ist Dropout. Während des Trainings setzt Dropout bei jedem Vorwärtsdurchlauf zufällig einen Bruchteil p der Aktivierungen jeder Schicht auf Null, wodurch eine gegenseitige Anpassung der Neuronen verhindert wird. Zum Testzeitpunkt erfolgt die Deaktivierung von Dropout und die Skalierung der Aktivierungen um (1–p), um sie an die erwartete Größe anzupassen. In PyTorch fügt man Dropout-Schichten in die Modelldefinition ein. Um beispielsweise Dropout nach der ersten versteckten Schicht hinzuzufügen:
import torch.nn as nn
class MLPWithDropout(nn.Module):
def __init__(self, input_dim, hidden_dim, output_dim, p=0.5):
super().__init__()
self.fc1 = nn.Linear(input_dim, hidden_dim)
self.dropout = nn.Dropout(p=p)
self.relu = nn.ReLU()
self.fc2 = nn.Linear(hidden_dim, output_dim)
def forward(self, x):
x = self.fc1(x)
x = self.relu(x)
# Randomly zero a fraction p of elements during training
x = self.dropout(x)
x = self.fc2(x)
return x
Wenn sich das Modell im Trainingsmodus befindet – was sich durch den Aufruf von model.train()
sicherstellen lässt –, erfolgt bei jedem Vorwärtsdurchlauf die Auswahl einer neuen zufälligen Binärmaske, die einen Bruchteil p der Elemente in der versteckten Darstellung auf Null setzt. Durch den Aufruf von model.eval()
vor dem Auswerten der Validierungsdaten lässt sich Dropout deaktivieren und der gesamte Satz von Aktivierungen verwenden.
Über den Gewichtsabbau und Dropout hinaus kann Early Stopping vor Overfitting schützen, indem die Leistung anhand eines Holdout-Validierungssatzes überwacht und das Training abgebrochen wird, wenn sich der Validierungsverlust nicht mehr verbessert. In der Regel speichert man die Modellparameter, wenn der Validierungsverlust abnimmt, und beendet das Training, wenn über eine bestimmte Anzahl von Epochen keine Verbesserung mehr auftritt.
Mit diesen Regularisierungsstrategien kann man tiefere und breitere Netzwerke trainieren und gleichzeitig eine robuste Generalisierung aufrechterhalten. Im nächsten Kapitel werden wir auf dieser Grundlage aufbauen und konvolutionale neuronale Netzwerke, rekurrenten Netzwerke und hybride Architekturen untersuchen, die mehrere Schichttypen kombinieren.
(rme)
Entwicklung & Code
Meta integriert KI-Chats in Empfehlungen auf Facebook und Instagram
Ab dem 16. Dezember 2025 will Meta Gespräche mit seinen KI-Funktionen in die Personalisierung von Facebook und Instagram einbeziehen. Damit sollen nicht nur Likes, Kommentare oder geteilte Inhalte eine Rolle spielen, sondern auch Text- und Sprachinteraktionen mit „Meta AI“. Diese zusätzlichen Datenpunkte erweitern laut Ankündigungsbeitrag die Möglichkeiten des Unternehmens, Empfehlungen gezielter auf die Interessen der Nutzerinnen und Nutzer abzustimmen.
Als Beispiel nennt Meta eine Unterhaltung übers Wandern: Wer ein solches Thema mit der KI bespricht, kann künftig Empfehlungen zu passenden Facebook-Gruppen, Reels über Outdoor-Themen oder Werbung für Ausrüstung sehen. Das Vorgehen folgt derselben Logik wie bisherige Personalisierungsmechanismen, erweitert diese jedoch um den direkten Austausch mit den KI-Funktionen.
Umgang mit sensiblen Daten
Meta betont, sensible Informationen nicht für Werbezwecke nutzen zu wollen. Dazu zählen Angaben zu Religion, sexueller Orientierung, politischer Einstellung, Gesundheit, ethnischer Herkunft oder Gewerkschaftszugehörigkeit. Gespräche über diese Themen sollen weder Inhalte im Feed noch personalisierte Anzeigen beeinflussen.
Damit versucht das Unternehmen, Sorgen vor einer zu tiefgehenden Auswertung privater Themen zu adressieren. In den offiziellen Informationen unterstreicht Meta, dass diese Grenzen bereits bei der bisherigen Datennutzung gelten und auch in den neuen KI-basierten Systemen eingehalten werden sollen.
Kontrolle für Nutzerinnen und Nutzer
Neben den automatischen Personalisierungen sollen weiterhin individuelle Anpassungen möglich sein. Über die bekannten Werkzeuge wie Ads Preferences oder Feed-Kontrollen können Nutzende ihre Anzeige- und Inhaltseinstellungen verändern. Damit bleibt es ihnen selbst überlassen, den Einfluss von KI-Empfehlungen einzugrenzen oder zu verstärken.
Außerdem können Menschen entscheiden, wie sie mit Meta AI interagieren möchten – per Spracheingabe oder Text. Bei Sprachbefehlen erscheint ein Hinweislicht, das signalisiert, dass das Mikrofon aktiv genutzt wird. Meta betont, dass eine Aufnahme nur erfolgt, wenn die Zustimmung vorliegt und eine entsprechende Funktion bewusst Verwendung findet.
Kontenverknüpfung entscheidet über Reichweite
Ein zentraler Punkt ist die Verknüpfung verschiedener Meta-Dienste über das Accounts Center. Nur wenn Nutzerinnen und Nutzer ihre Konten dort registrieren, fließen die Daten auch plattformübergreifend in die Empfehlungen ein. Wer beispielsweise WhatsApp nicht mit dem Accounts Center verbindet, muss laut Ankündigungsbeitrag nicht damit rechnen, dass KI-Chats aus dem Messenger das Facebook- oder Instagram-Erlebnis beeinflussen.
Auf diese Weise versucht Meta, den Nutzenden selbst mehr Kontrolle über die Reichweite ihrer Interaktionen zu geben. Die Entscheidung, welche Informationen zwischen den Plattformen geteilt werden, liegt bei denjenigen, die ihre Konten verknüpfen oder getrennt halten.
Zeitplan und weitere Pläne
Die geplanten Änderungen treten am 16. Dezember 2025 in Kraft. Meta kündigt an, Nutzerinnen und Nutzer vorab per Benachrichtigungen und E-Mails zu informieren, sodass ausreichend Zeit bleiben soll, Einstellungen zu überprüfen oder anzupassen.
Die Einführung soll schrittweise erfolgen. Zunächst wird das Update in den meisten Regionen umgesetzt, später möchte das Unternehmen die Funktion weltweit bereitstellen.
(mdo)
Entwicklung & Code
Jakarta EE Developer Survey 2025 zeigt Wachstum bei Java 21 und Cloud
Die Eclipse Foundation hat die Ergebnisse des 2025 Jakarta EE Developer Survey veröffentlicht. Mit über 1.700 Teilnehmenden – ein Plus von 20 Prozent gegenüber dem Vorjahr – liefert die Befragung einen umfangreichen Einblick in den Stand von Enterprise Java weltweit. Die Resultate unterstreichen den wachsenden Einfluss von Jakarta EE, insbesondere im Kontext von Cloud-nativen Anwendungen und moderner Java-Entwicklung.
Die Eclipse Foundation ist eine der größten Open-Source-Organisationen und betreut Projekte wie Jakarta EE. Mit dem jährlichen Jakarta EE Developer Survey erhebt sie Trends und Prioritäten der weltweiten Java-Community.
Jakarta EE überholt Spring
Zum ersten Mal liegt die Java-Plattform Jakarta EE mit 58 Prozent Nutzung vor Spring (56 Prozent). Dieser Wechsel markiert einen Meilenstein in der Enterprise-Java-Welt. Ausschlaggebend sei einerseits die Veröffentlichung von Jakarta EE 11, andererseits eine wachsende Aufmerksamkeit dafür, dass Spring selbst auf Jakarta-EE-Spezifikationen basiert.
Das Balkendiagramm zeigt die Nutzung von Spring/Spring Boot, Jarkata EE und MicroProfile. Spring liegt erstmals vorne.
(Bild: Eclipse Foundation)
Obwohl die vollständige Plattformversion erst nach Abschluss der Umfrage erschien, setzen bereits 18 Prozent der Befragten auf Jakarta EE 11. Besonders dominant ist der frühe Einsatz in kleineren Unternehmen (weniger als 500 Mitarbeitende), doch auch Großunternehmen ab 10.000 Beschäftigten zeigen signifikantes Interesse.
(Bild: Playful Creatives / Adobe Stock)
Am 14. Oktober dreht sich bei der betterCode() Java 2025 alles um das frisch veröffentlichte Java 25. Die von iX und dpunkt verlag ausgerichtete Online-Konferenz behandelt in sechs Vorträgen die wesentlichen Neuerungen. Eine Keynote von Adam Bien zu 30 Jahren Java rundet den Tag ab.
Java 21 setzt sich durch
Ein klarer Trend: 43 Prozent der Entwicklerinnen und Entwickler nutzen bereits Java 21 – ein deutlicher Sprung von 30 Prozent im Jahr 2024. Gleichzeitig geht die Nutzung älterer Versionen wie Java 8 und 17 zurück. Java 11 erlebt dagegen ein leichtes Comeback und erreicht 37 Prozent.
Die Grafik zeigt Nutzung der Java-Versionen: Java 8 führt vor Java 17; Platz 3 belegt Java 21 und am wenigsten genutzt wird Java 11.
(Bild: Eclipse Foundation)
Cloud-Strategien bleiben vielfältig – Unsicherheit wächst
Die Strategien zur Cloud-Migration sind weiterhin unterschiedlich verteilt. Zwar bleibt Lift-and-Shift mit 22 Prozent führend, doch gleichzeitig steigt offenbar die Unsicherheit: 20 Prozent der Befragten haben 2025 noch keine klare Cloud-Strategie, fast doppelt so viele wie im Vorjahr.
Die Prioritäten der Community verschieben sich gemäß Umfrage deutlich in Richtung Cloud-native Readiness und eine schnellere Implementierung von Jakarta-EE-Spezifikationen in Applikationsservern. Developer wünschen sich zudem offenbar praxistaugliche Kubernetes-Features wie Health Checks, Secrets-Management und Telemetrie-Unterstützung.
Ein Wendepunkt für Enterprise-Java
Die Ergebnisse der diesjährigen Umfrage zeigen, wie sich Enterprise Java Schritt für Schritt weiterentwickelt. Entwicklerinnen und Entwickler setzen verstärkt auf Jakarta EE, nutzen schneller neue Java-Versionen wie Java 21 und greifen zunehmend auf Cloud-native Ansätze zurück.
Viele Teams arbeiten bereits aktiv an Cloud-Migrationen, doch ein Teil sucht offenbar noch nach der passenden Strategie. Gleichzeitig gestalten Unternehmen ihre Architekturen flexibler und passen bestehende Systeme an moderne Anforderungen an. Damit rückt Jakarta EE verstärkt in den Mittelpunkt der aktuellen Entwicklungen im Java-Ökosystem.
Weitere Informationen sowie der Zugang zum Survey finden sich im Blogbeitrag auf der Seite der Eclipse Foundation.
(mdo)
Entwicklung & Code
Proxmox Mail Gateway 9.0 mit mehr Schutz und einfacherem Quarantäne-Management
Die Proxmox Server Solutions GmbH aus Wien hat mit dem Proxmox Mail Gateway 9.0 ihre Open-Source-Plattform für sichere E-Mail aktualisiert. Ebenso wie die Virtualisierungslösung Proxmox VE 9.0 und der Proxmox Backup Server 4.0 arbeitet das Mail Gateway damit auf Basis von Debian GNU/Linux 13.0 „Trixie“. Während Debian standardmäßig einen Linux-Kernel 6.12 LTS verwendet, habe sich das Proxmox-Entwicklerteam für einen angepassten Linux-Kernel 6.14.11-2 entschieden.
Das Dateisystem ZFS hat gerade den zweiten Release Candidate für Version 2.4 veröffentlicht (zfs-2.4.0-rc2), Proxmox setzt jedoch auf die neueste stabile ZFS-Version 2.3.4. Als Datenbank-Engine kommt PostgreSQL 17 zum Einsatz. Gegen Spam, Viren, Trojaner und Phishing-E-Mails sollen unter anderem Open-Source-Technologien wie ClamAV 1.4.3 und SpamAssassin 4.0.2 mit aktualisierten Rulesets schützen.
In der Statistik-Ansicht erhalten Nutzerinnen und Nutzer eine Übersicht über ein- und ausgehende sowie Junk-, Virus-Mails und Bounces.
(Bild: Proxmox Server Solutions GmbH)
Überarbeitetes Quarantäne-Interface für Mobilgeräte
Das neue Quarantäne-Interface wurde speziell für Mobilgeräte optimiert und ermöglicht es seinen Benutzern, ihre quarantänisierten Nachrichten komfortabel über eine überarbeitete Weboberfläche zu verwalten. Entwickelt mit dem Rust-basierten Yew-Framework soll es die bisherige Implementierung komplett ersetzen.
Die Authentifizierungsfunktionen und SSO-Integration (Single Sign-On) wurden deutlich erweitert: OpenID-Connect-Realms lassen sich nun vollständig über die grafische Oberfläche konfigurieren, inklusive Claim-Zuordnungen und automatischer Rollenvergabe. Dadurch wird eine nahtlose Anbindung an gängige Identity- und Access-Management-Lösungen wie Keycloak, Zitadel oder LemonLDAP::NG ermöglicht.
Mehr Sicherheit soll die Anpassung der Content-Type-Filter-Engine erreichen, die aktualisierten MIME-Typen für Microsoft-Ausführungsdateien zuverlässiger erkennen und blockieren kann.
Verfügbarkeit und Preise
Alle Verbesserungen und Änderungen, aber auch mögliche auftretende Probleme beim Umstieg von vorherigen Versionen des Proxmox Mail Gateway sind in dem Wiki dokumentiert.
Das Proxmox Mail Gateway 9.0 steht als Open-Source-Software ab sofort zum Download bereit und darf kostenlos eingesetzt werden. Der Zugriff auf das Enterprise-Repository kostet 180 Euro (netto) pro Jahr, professioneller Support ist von 510 bis 1800 Euro (netto) pro Jahr erhältlich.
(mdo)
-
UX/UI & Webdesignvor 2 Monaten
Der ultimative Guide für eine unvergessliche Customer Experience
-
UX/UI & Webdesignvor 1 Monat
Adobe Firefly Boards › PAGE online
-
Social Mediavor 2 Monaten
Relatable, relevant, viral? Wer heute auf Social Media zum Vorbild wird – und warum das für Marken (k)eine gute Nachricht ist
-
Entwicklung & Codevor 2 Monaten
Posit stellt Positron vor: Neue IDE für Data Science mit Python und R
-
Entwicklung & Codevor 1 Monat
EventSourcingDB 1.1 bietet flexiblere Konsistenzsteuerung und signierte Events
-
UX/UI & Webdesignvor 3 Wochen
Fake It Untlil You Make It? Trifft diese Kampagne den Nerv der Zeit? › PAGE online
-
Apps & Mobile Entwicklungvor 3 Monaten
Firefox-Update 141.0: KI-gestützte Tab‑Gruppen und Einheitenumrechner kommen
-
Online Marketing & SEOvor 2 Monaten
So baut Googles NotebookLM aus deinen Notizen KI‑Diashows