Connect with us

Entwicklung & Code

Künstliche Neuronale Netze im Überblick 3: Aktivierungsfunktionen


Neuronale Netze sind der Motor vieler Anwendungen in KI und GenAI. Diese Artikelserie gibt einen Einblick in die einzelnen Elemente.


Michael Stal

Michael Stal

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.

Der dritte Teil zeigt, wie Operationen den Vorwärtsdurchlauf in seiner Allgemeinheit bilden und wie die Wahl der Aktivierungen mit der Netzwerktiefe zusammenwirkt.

Vorwärtsausbreitung, auch Vorwärtsdurchlauf genannt, bezeichnet den Prozess der Berechnung der Ausgabe eines neuronalen Netzwerks durch sukzessive Anwendung linearer Transformationen und nicht linearer Aktivierungsfunktionen auf die Eingabedaten. Für eine einzelne Schicht ℓ gilt, wenn wir die Aktivierungen der vorherigen Schicht mit a^(ℓ–1), die Matrix der Gewichte der Schicht mit W^(ℓ) und den Bias-Vektor mit b^(ℓ) bezeichnen, dann berechnet die Schicht den Präaktivierungsvektor z^(ℓ) als

z^(ℓ) = W^(ℓ) · a^(ℓ–1) + b^(ℓ)

Nach der Berechnung von z^(ℓ) wendet die Schicht eine elementweise nicht lineare Aktivierungsfunktion σ an, um die Ausgangsaktivierungen zu erzeugen:

a^(ℓ) = σ(z^(ℓ)).

Durch Zusammensetzen dieser Operationen für jede Schicht vom Eingang bis zum Ausgang wandelt das Netzwerk einen anfänglichen Eingabevektor in einen endgültigen Ausgabevektor um, der eine Vorhersage oder eine Merkmals-Einbettung darstellt.

Um diese Berechnungen konkret zu veranschaulichen, betrachten wir eine Gruppe von Eingabevektoren, die wir als Matrix X mit der Form (batch_size, input_dim) darstellen. Eine vollständig verbundene Schicht in PyTorch lässt sich manuell wie folgt implementieren, wobei W die Form (output_dim, input_dim) und b die Form (output_dim) hat:


import torch

batch_size = 32
input_dim = 10
output_dim = 50

# Simulieren Sie einen Stapel von Eingaben
X = torch.randn(batch_size, input_dim)

# Initialisieren Sie die Gewichtungsmatrix und den Bias-Vektor
W = torch.randn(output_dim, input_dim)
b = torch.randn(output_dim)

# Berechnen Sie die Voraktivierung für den Stapel: Z = X @ W^T + b
Z = X.matmul(W.t()) + b
# Wende eine Nichtlinearität (z. B. ReLU) an, um Aktivierungen A zu erhalten
A = torch.relu(Z)


In diesem Ausschnitt enthält der Tensor X zu Demonstrationszwecken zufällige Werte. Der Ausdruck W.t() bezeichnet die Transponierung von W, die die Form (input_dim, output_dim) hat. Die Batch-Matrixmultiplikation X.matmul(W.t()) erzeugt einen neuen Tensor Z mit der Form (batch_size, output_dim), da jede der batch_size-Zeilen von X mit Wᵀ multipliziert wird. Durch Hinzufügen von b zu Z übertragen wir den Bias-Vektor auf alle Zeilen, wodurch wir die vollständigen Voraktivierungswerte erhalten. Zuletzt führt torch.relu eine elementweise rektifizierte lineare Einheit auf Z aus, um A zu erzeugen.

Aktivierungsfunktionen führen die Nichtlinearität ein, die es neuronalen Netzen ermöglicht, komplexe Muster zu lernen. Die logistische Sigmoid-Funktion, definiert durch

σ(z) = 1 / (1 + exp(−z)),

bildet jede reelle Eingabe in den Bereich zwischen null und eins ab. Ihre Ableitung kann in Bezug auf ihre Ausgabe ausgedrückt werden als

σ′(z) = σ(z) · (1 − σ(z)).

Obwohl Sigmoid in der Vergangenheit sehr beliebt war, können seine Gradienten sehr klein werden, wenn |z| groß ist, was zu einem langsamen Lernen in der Tiefe eines Netzwerks führt.

In PyTorch können Sie eine Sigmoid-Aktivierung für einen Tensor Z mit folgendem Befehl berechnen:

A_sigmoid = torch.sigmoid(Z)

wobei torch.sigmoid die elementweise logistische Funktion auf jeden Eintrag von Z anwendet und einen neuen Tensor mit Werten zwischen null und eins erzeugt.

Die hyperbolische Tangensfunktion, definiert durch

tanh(z) = (exp(z) − exp(−z)) / (exp(z) + exp(−z)),

bildet reelle Eingaben auf den Bereich zwischen minus eins und eins ab. Ihre Ableitung ist gegeben durch 1 − tanh(z)^2. Da tanh nullzentriert ist, führt sie oft zu einer schnelleren Konvergenz als Sigmoid, leidet jedoch bei großen positiven oder negativen Eingaben unter verschwindenden Gradienten.

In PyTorch können Sie eine tanh-Aktivierung mit folgendem Befehl berechnen:

A_tanh = torch.tanh(Z)

Die in modernen tiefen Netzwerken am häufigsten verwendete Aktivierung ist die rektifizierte lineare Einheit (ReLU), definiert als

ReLU(z) = max(0, z)

Ihre Ableitung ist immer null, wenn z negativ ist, und immer eins, wenn z positiv ist. Diese einfache, stückweise lineare Form vermeidet eine Sättigung bei positiven Eingaben, was das Problem der verschwindenden Gradienten erheblich mildert. Allerdings können Neuronen während des Trainings „sterben“, wenn ihre Eingaben negativ werden und negativ bleiben, was zu dauerhaft null-Gradienten führt.

Sie können eine ReLU-Aktivierung in PyTorch entweder mit torch.relu oder durch Erstellen einer Instanz des Moduls anwenden:

A_relu = torch.relu(Z)import torch.nn as nnrelu_layer = nn.ReLU()A_relu_mod = relu_layer(Z)

Um das Problem des „sterbenden ReLU“ zu beheben, führt Leaky ReLU eine kleine Steigung α für negative Eingaben ein, definiert als

LeakyReLU(z) = max(α·z, z).

Ihre Ableitung ist α, wenn z negativ ist, und eins, wenn z positiv ist. Eine typische Wahl für α ist 0,01. Im Code können Sie eine leaky ReLU-Schicht in PyTorch mit folgendem Code erstellen und anwenden:

leaky_relu = nn.LeakyReLU(negative_slope=0.01)A_leaky = leaky_relu(Z)

Bei der Klassifizierung über mehrere Klassen wird die Softmax-Funktion verwendet, um einen Vektor mit beliebigen reellen Werten in eine Wahrscheinlichkeitsverteilung umzuwandeln. Für einen Vektor z mit Komponenten z_i gilt

softmax(z)_i = exp(z_i) / Σ_j exp(z_j).

Die Jacobi-Matrix von Softmax hat Einträge ∂σ_i/∂z_j = σ_i (δ_{ij} − σ_j). In der Praxis wird Softmax typischerweise mit dem Kreuzentropieverlust kombiniert, was zu einem numerisch stabilen und einfacheren kombinierten Gradienten führt. In PyTorch lässt sich Softmax entlang einer bestimmten Dimension anwenden. Für einen Batch von Logits mit dem Namen logits und der Form (batch_size, num_classes) können Sie beispielsweise schreiben:

import torch.nn.functional as Fprobabilities = F.softmax(logits, dim=1)

Das berechnet die Exponentialfunktionen jeder Zeile in logits, normalisiert sie anhand der Zeilensummen und gibt einen Tensor derselben Form zurück, der Werte zwischen null und eins enthält, die entlang jeder Zeile eins ergeben.

Über diese klassischen Aktivierungen hinaus haben neuere Funktionen wie Swish, definiert als z · sigmoid(z), und GELU, die Gaußsche Fehlerlineareinheit, für bestimmte Architekturen an Beliebtheit gewonnen, da sie glattere Gradienten und eine verbesserte Leistung bei Aufgaben wie der Sprachmodellierung bieten. Obwohl diese Funktionen in Bibliotheken wie PyTorch (z. B. über das Modul nn.GELU) verfügbar sind, bleiben ReLU und seine Varianten aufgrund ihres zusätzlichen Rechenaufwands für viele Praktiker die Standardwahl.

Nachdem wir nun sowohl die linearen Transformationen, aus denen die Voraktivierungen jeder Schicht bestehen, als auch die darauffolgenden nicht linearen Aktivierungsfunktionen behandelt haben, sind wir in der Lage, tiefe neuronale Netze zu bauen, die Eingabedaten in reichhaltige interne Darstellungen umwandeln.

Der nächste Teil der Serie zeigt, wie gut die Vorhersagen eines Netzwerks mit den gewünschten Zielen übereinstimmen, indem man Verlustfunktionen einführt. Anschließend zeigt der Beitrag gradientenbasierten Optimierungsalgorithmen, mit denen sich die Parameter des Netzwerks anpassen lassen.


(rme)



Source link

Entwicklung & Code

software-architektur.tv: Teamwork – Müssen wir darüber sprechen?


In der IT müssen die meisten Softwareentwicklerinnen, -architekten und andere Rollen aus verschiedenen Gründen in Teams arbeiten. Wer überzeugt ist, dass das nicht immer einfach ist, und zudem denkt, über Teamwork sei schon alles gesagt worden, der sollte die neue Episode nicht verpassen: denn Aino Vonge Corry und Lisa Maria Schäfer werden gemeinsam nochmals die wichtigsten Aspekte beleuchten – von Team Topologies über psychologische Sicherheit, Persönlichkeitstypen, Körpersprache, Remote-Arbeit in Teams bis hin zur ganz allgemeinen Kommunikation. Aino Vonge Corry und Lisa Maria Schäfer diskutieren all diese Themen und freuen sich auf Eure Fragen.

Weiterlesen nach der Anzeige

Aino Vonge Corry wird außerdem Ende November einen Vortrag beim Software Architecture Gathering halten, mit dem Titel „Was wir aus ‚Der Herr der Ringe‘ gelernt haben (sollten)“.

Da Lisa Maria Schäfer vor der Kamera ist, wird sie dieses Mal keine Sketchnotes malen.

Die Ausstrahlung findet am Donnerstag, 6. November 2025, live von 13 bis 14 Uhr statt. Die Folge steht im Anschluss als Aufzeichnung bereit. Während des Livestreams können Interessierte Fragen via Twitch-Chat, YouTube-Chat, Bluesky, Mastodon, Slack-Workspace oder anonym über das Formular auf der Videocast-Seite einbringen.

software-architektur.tv ist ein Videocast von Eberhard Wolff, Blogger sowie Podcaster auf iX und bekannter Softwarearchitekt, der als Head of Architecture bei SWAGLab arbeitet. Seit Juni 2020 sind über 250 Folgen entstanden, die unterschiedliche Bereiche der Softwarearchitektur beleuchten – mal mit Gästen, mal Wolff solo. Seit mittlerweile mehr als zwei Jahren bindet iX (heise Developer) die über YouTube gestreamten Episoden im Online-Channel ein, sodass Zuschauer dem Videocast aus den Heise Medien heraus folgen können.

Weitere Informationen zur Folge finden sich auf der Videocast-Seite.

Weiterlesen nach der Anzeige


(map)



Source link

Weiterlesen

Entwicklung & Code

Daily am Morgen vertreibt Kummer und Sorgen. Oder nicht?


Ein Daily, auch Stand-up oder Daily Scrum genannt, ist kein Status-Meeting. Es dient einerseits dazu, den Fortschritt in Richtung Sprint-Ziel zu hinterfragen. Das bedeutet schon mal, dass es ohne Sprint-Ziel kein Daily benötigt, oder? Der andere Zweck des Dailys besteht im Planen des bevorstehenden Arbeitstags. Wer macht was, um das Team dem Ziel näherzubringen? Aufgrund dieses Zwecks habe ich das Daily lange Zeit am frühen Vormittag verortet.

Weiterlesen nach der Anzeige


Escape the Feature Factory: Stefan Mintert

Escape the Feature Factory: Stefan Mintert

(Bild: 

Stefan Mintert

)

Stefan Mintert arbeitet mit seinen Kunden daran, die Unternehmenskultur in der Softwareentwicklung zu verbessern. Das derzeit größte Potenzial sieht er in der Leadership; unabhängig von einer Hierarchieebene.

Die Aufgabe, dieses Potenzial zu heben, hat er sich nach einem beruflichen Weg mit einigen Kurswechseln gegeben. Ursprünglich aus der Informatik kommend, mit mehreren Jahren Consulting-Erfahrung, hatte er zunächst eine eigene Softwareentwicklungsfirma gegründet. Dabei stellte er fest, dass Führung gelernt sein will und gute Vorbilder selten sind.

Es zeichnete sich ab, dass der größte Unterstützungsbedarf bei seinen Kunden in der Softwareentwicklung nicht im Produzieren von Code liegt, sondern in der Führung. So war es für ihn klar, wohin die Reise mit seiner Firma Kutura geht: Führung verbessern, damit die Menschen, die die Produkte entwickeln, sich selbst entwickeln und wachsen können.

Für Heise schreibt Stefan als langjähriger, freier Mitarbeiter der iX seit 1994.

Nach und nach hat sich mein Blick verändert, und das hat vor allem damit zu tun, dass in meinen Beratungsaufträgen ein Phänomen häufiger vorkommt: In den vergangenen Jahren treten immer mehr Entwickler an mich heran, um nach persönlichem Rat zu fragen. Es geht also nicht um Teamprobleme oder Fragen der gesamten Organisation, sondern um individuelle Herausforderungen, denen die einzelnen Personen gegenüberstehen. Dazu gehören Projektdruck, fehlende Wertschätzung und daraus resultierendes mangelndes Wohlbefinden.

Die häufigsten Fragen, die Antworten und die Tipps, die meine Kollegen und ich geben, haben wir unter dem Titel „Develop Happiness in 30 Weeks“ zusammengetragen; die Nutzung ist kostenlos. Und ein Tipp in dieser Sammlung betrifft meinen Umgang mit dem Daily.

Es geht darum, dass es bei hohem Projektdruck nicht leicht ist, nach der Arbeit abzuschalten. Viele Menschen nehmen die unerledigten Gedanken mit nach Hause und dort führen sie zum Grübeln und Nachdenken; ausgerechnet in einer Zeit, die sogar per Gesetz eine „ununterbrochene Ruhezeit von mindestens elf Stunden“ umfassen sollte.

Um diese Last zu vermeiden, empfehlen wir den Menschen, mit denen wir arbeiten, folgendes Vorgehen: Die letzten 15 Minuten der täglichen Arbeitszeit sollte jede Person der persönlichen Planung des nächsten Tages widmen. Von den üblichen 8 Stunden Arbeitszeit dürfen maximal 6 verplant werden. Der Plan soll aus einer kurzen Liste von To-dos bestehen. Wenn jede Aufgabe geschätzte 60 Minuten erfordert, wäre das also eine Liste von sechs Punkten; natürlich sind 6 Punkte à 60 Minuten ein Default.

Weiterlesen nach der Anzeige

Für manche Tätigkeiten passt vielleicht besser ein Punkt mit 360 Minuten. Die Zahl der To-dos darf und soll sich an die eigene Situation anpassen. Mehr als sechs Stunden dürfen es aber nicht werden. Die restlichen zwei Stunden sind für Unerwartetes reserviert. Doch damit nicht genug: Wenn die sechs Punkte abgearbeitet sind, muss man die Arbeit für den Tag beenden; vorausgesetzt der Arbeitgeber spielt mit, versteht sich. Stellt man im Laufe der Zeit fest, dass sechs Punkte und sechs Stunden nicht aufgehen, ändert man die Planung entsprechend. Wer regelmäßig nach vier Stunden fertig ist, fängt langsam an, mehr einzuplanen. Gleiches gilt für den Puffer von zwei Stunden für unerwartete Dinge.

Die Methode wirkt aus zwei Gründen:

Man bekommt an einem Arbeitstag endlich mal „alles“ fertig; nicht alles, was im Backlog steht, aber alles, was der Tagesplan enthält. Gerade für Menschen, die eine „Ever-Growing To-Do List“ haben und sich damit belasten, was sie alles nicht geschafft haben, ist das sehr wertvoll. Es funktioniert aber nur, wenn man die Arbeit wirklich beendet, sobald die geplanten Dinge erledigt sind.

Die Planung am Ende des Arbeitstags sorgt nicht nur für einen Abschluss. Sie vermittelt darüber hinaus das Gefühl, dass man sich auch um die nicht erledigten Dinge gekümmert hat. Diese Dinge sind zwar nicht „done“, aber man hat sie in geeigneter Weise behandelt.

Und wie passt das mit dem morgendlichen Daily zusammen?

Je mehr Leute im Team gegen Ende eines Arbeitstags mit der 6-Punkte-Planung den nächsten Tag planen, umso mehr bietet es sich an, das Team-Daily damit zu verbinden und es zum Beispiel auf den Nachmittag zu legen. Neben dem mentalen Vorteil für jedes einzelne Teammitglied kommt hinzu, dass man am nächsten Morgen ohne Regelmeeting in einen bereits geplanten Arbeitstag starten kann. Hier kann jeder die Startzeit nach seinem persönlichen Rhythmus wählen, falls nicht ein anderes Meeting die freigewordene Daily-Lücke füllt. Zusammengefasst bin ich immer mehr geneigt, meine ehemalige Best Practice „Daily am Morgen“ aufzugeben.

Was denkt Ihr darüber? Schreibt doch mal in die Kommentare, ob und gegebenenfalls zu welcher Uhrzeit Euer Team ein Daily durchführt.

Wenn Du die Themen, die ich im Blog anspreche, in Deiner Firma verbessern möchtest, komm‘ in unsere Leadership-Community für Softwareentwickler. Sie wirkt auch ohne Führungsposition. Mit dem Code „heisedev“ gibt’s den Heise-Rabatt für Interactive Members.


(rme)



Source link

Weiterlesen

Entwicklung & Code

Insomnia 12: Kong erweitert API-Tool um MCP-Unterstützung und KI-Hilfen


close notice

This article is also available in
English.

It was translated with technical assistance and editorially reviewed before publication.

Kong hat Version 12 seines Open-Source-Werkzeugs Insomnia freigegeben, ein Open-Source-Tool für die Entwicklung, das Testen und die Dokumentation von APIs. Das Update erweitert die Software um native Unterstützung für das Model Context Protocol (MCP) sowie um zwei experimentelle KI-Funktionen. Außerdem vereinfacht Kong den Zugang zu Kollaborationsfunktionen wie Git-Sync.

Weiterlesen nach der Anzeige

Ziel des Releases ist laut Ankündigungsbeitrag, API- und MCP-Entwicklung stärker zu vereinheitlichen und Routineaufgaben bei Tests und Dokumentation zu automatisieren.

Das neue MCP-Feature ermöglicht es, sogenannte MCP-Server direkt aus Insomnia heraus zu testen. Diese Server stellen Werkzeuge und Prompts für KI-Agenten bereit. Über die gewohnte Oberfläche lassen sich Aufrufe ausführen, Parameter verändern und Nachrichten auf Protokollebene nachvollziehen.

Der MCP-Client soll dieselbe Art von Test- und Debugging-Workflows ermöglichen, die Insomnia bereits für klassische APIs bietet.

Ebenfalls neu ist die Möglichkeit, Mock-Server automatisch zu erzeugen. Nutzerinnen und Nutzer können in natürlicher Sprache beschreiben, wie die API funktionieren soll, oder eine URL, JSON-Datei oder OpenAPI-Spezifikation angeben. Auf dieser Basis erstellt Insomnia ein funktionsfähiges Mock-Setup. Der Blogbeitrag bietet hierfür anschauliche Demo-Videos.

Weiterlesen nach der Anzeige

Das Feature richtet sich an Teams, die APIs noch in der Entwurfsphase testen möchten oder keinen Zugriff auf produktive Systeme haben. Laut Kong sollen sich so einfache Simulationen in Sekunden anlegen lassen, ohne separate Skripte oder manuelle Konfiguration.

Insomnia 12 schlägt außerdem Commit-Nachrichten automatisch vor. Die Software analysiert Änderungen im Repository und generiert passende Beschreibungen, die angepasst oder verworfen werden können. Ziel ist es, die Nachvollziehbarkeit von Änderungen zu verbessern, ohne zusätzliche Schreibarbeit.

Wie bei den Mock-Funktionen können Nutzer entscheiden, ob die KI-Funktion aktiviert wird und ob dafür ein externer Cloud-Anbieter oder ein lokales Sprachmodell zum Einsatz kommen soll. Kong weist darauf hin, dass KI-generierte Ergebnisse überprüft werden sollten.

Beim Kollaborationsmodell ergänzt Kong vor allem den kostenlosen Essentials-Tarif: Git-Sync ist darin jetzt für drei Nutzende enthalten. Wer erweiterte Funktionen wie SSO, SCIM oder rollenbasierte Zugriffskontrolle testen will, kann eine 14-tägige Enterprise-Testphase starten und bis zu 50 Plätze selbst verwalten.

Mit diesen Anpassungen will Kong die Nutzung von Insomnia in kleinen Teams erleichtern, ohne dass sofort ein kostenpflichtiges Abo nötig wird.


(mdo)



Source link

Weiterlesen

Beliebt