Das Entwicklungsteam hinter dem Model Context Protocol (MCP) hat die MCP Registry als Preview eingeführt – einen offenen Katalog und eine API, um öffentlich verfügbare MCP-Server ausfindig zu machen und zu verwenden. Bei MCP handelt es sich um ein offenes Protokoll für den Zugriff von Large Language Models (LLMs) auf externe Datenquellen.

Öffentliche MCP-Server hinzufügen und finden

Bereits vor einigen Monaten teilte das MCP-Team auf GitHub mit, an einem zentralen Register für das MCP-Ökosystem zu arbeiten. Die nun veröffentlichte, quelloffene MCP Registry soll das Verfahren standardisieren, wie MCP-Server verteilt und entdeckt werden. Sie bietet Server-Maintainern die Möglichkeit, ihre Server hinzuzufügen, und Client-Maintainern, auf Serverdaten zuzugreifen.

Um der Registry einen Server hinzuzufügen, muss dieser auf einer Package Registry wie npm, PyPI oder DockerHub veröffentlicht sein. Eine detaillierte Anleitung findet sich auf GitHub. Dort erfahren Developer, wie sie eine server.json-Datei für ihren Server erstellen, Authentifizierung mit der Registry erreichen, ihren Server veröffentlichen und die Veröffentlichung verifizieren können.

Umgang mit Sub-Registries

Wie das MCP-Team betont, soll das zentrale Register als hauptsächliche Source of Truth für öffentlich verfügbare MCP-Server dienen, jedoch den bereits bestehenden Registries von Community und Unternehmen nicht im Weg stehen. Diese können in der MCP Registry öffentliche oder private Sub-Registries anlegen, wie das MCP-Team auf GitHub beschreibt.

Bereits existierende Sammlungen sind etwa eine lange, gepflegte Liste auf GitHub und ein Docker-Verzeichnis für MCP-Quellen.

Da es sich bei der MCP Registry derzeit um eine Preview handelt, gibt es keine Garantie für die Beständigkeit der darin enthaltenen Daten. Auch sind Breaking Changes möglich, bevor die Registry die allgemeine Verfügbarkeit erreicht.

Weitere Informationen sind auf dem MCP-Blog zu finden.

(mai)

Die bisherigen Beiträge dieser Serie haben gezeigt, dass neuronale Netze aus einfachen Bausteinen bestehen. Erst die Kombination vieler dieser Bausteine in mehreren Schichten ermöglicht jedoch die Durchbrüche, die moderne KI-Systeme prägen. Genau hier setzt das Konzept „Deep Learning“ an: Es beschreibt maschinelles Lernen mit tiefen, also mehrschichtigen, neuronalen Netzen.

Deser Beitrag klärt, was „tief“ im Kontext neuronaler Netze bedeutet, warum zusätzliche Schichten die Leistungsfähigkeit erhöhen und welche typischen Architekturen in der Praxis verwendet werden.

Was „deep“ wirklich heißt

Von Deep Learning spricht man, wenn ein neuronales Netz mehrere verborgene Schichten enthält – in der Regel deutlich mehr als zwei oder drei. Jede Schicht abstrahiert die Ausgaben der vorherigen Schicht und ermöglicht so, komplexe Funktionen zu modellieren. Während einfache Netze vor allem lineare und leicht nichtlineare Zusammenhänge erfassen, können tiefe Netze hochdimensionale Strukturen und Muster erkennen.

Die Entwicklung hin zu tieferen Netzen wurde erst durch drei Faktoren möglich:

1. Stärkere Rechenleistung – insbesondere durch Grafikkarten (GPUs) und später spezialisierte Hardware wie TPUs.
2. Größere Datenmengen, die zum Training genutzt werden können.
3. Verbesserte Trainingsverfahren, darunter die Initialisierung von Gewichten, Regularisierungstechniken und optimierte Aktivierungsfunktionen.

Hierarchisches Lernen von Merkmalen

Ein Kernprinzip des Deep Learning ist die hierarchische Merkmalsextraktion. Jede Schicht eines tiefen Netzes lernt, auf einer höheren Abstraktionsebene zu arbeiten:

• Frühe Schichten erkennen einfache Strukturen, zum Beispiel Kanten in einem Bild.
• Mittlere Schichten kombinieren diese zu komplexeren Mustern, etwa Ecken oder Kurven.
• Späte Schichten identifizieren daraus ganze Objekte wie Gesichter, Autos oder Schriftzeichen.

Diese Hierarchiebildung entsteht automatisch aus den Trainingsdaten und macht Deep Learning besonders mächtig: Systeme können relevante Merkmale selbst entdecken, ohne dass Menschen sie mühsam vordefinieren müssen.

Typische Architekturen

Im Deep Learning haben sich verschiedene Architekturen etabliert, die für bestimmte Datenarten optimiert sind.

Convolutional Neural Networks (CNNs) sind spezialisiert auf Bild- und Videodaten. Sie verwenden Faltungsschichten („Convolutional Layers“), die lokale Bildbereiche analysieren und so translationinvariante Merkmale lernen. Ein CNN erkennt beispielsweise, dass ein Auge im Bild ein Auge bleibt, egal wo es sich befindet. CNNs sind der Standard in der Bildklassifikation und Objekterkennung.

Recurrent Neural Networks (RNNs) wurden entwickelt, um Sequenzen wie Text, Sprache oder Zeitreihen zu verarbeiten. Sie besitzen Rückkopplungen, durch die Informationen aus früheren Schritten in spätere einfließen. Damit können sie Zusammenhänge über mehrere Zeitschritte hinweg modellieren. Varianten wie LSTMs (Long Short-Term Memory) und GRUs (Gated Recurrent Units) beheben typische Probleme wie das Vergessen relevanter Informationen.

Autoencoder sind Netze, die Eingaben komprimieren und anschließend wieder rekonstruieren. Sie lernen dabei implizit eine verdichtete Repräsentation der Daten und werden etwa für Anomalieerkennung oder zur Vorverarbeitung genutzt. Erweiterte Varianten wie Variational Autoencoders (VAE) erlauben auch generative Anwendungen.

Diese Architekturen bilden die Grundlage vieler moderner KI-Anwendungen. Sie sind jedoch noch nicht der Endpunkt: In den letzten Jahren haben Transformer klassische RNNs in vielen Bereichen abgelöst, insbesondere in der Sprachverarbeitung. Darum wird es in einer späteren Folge dieser Serie gehen.

Herausforderungen des Deep Learning

Tiefe Netze sind leistungsfähig, bringen aber neue Herausforderungen mit sich:

• Großer Datenhunger: Ohne ausreichend Trainingsdaten tendieren tiefe Modelle zum Überfitting.
• Rechenintensiv: Training und Inferenz erfordern spezialisierte Hardware und hohe Energieaufwände.
• Schwer erklärbar: Mit wachsender Tiefe nimmt die Nachvollziehbarkeit weiter ab, was für viele Anwendungsbereiche problematisch ist.

Trotzdem hat sich Deep Learning als Schlüsseltechnologie für die meisten aktuellen KI-Durchbrüche etabliert.

Ausblick

Die nächste Folge widmet sich den Transformern – der Architektur, die Large Language Models und viele andere moderne Systeme ermöglicht. Sie erläutert, warum klassische RNNs an ihre Grenzen stießen und wie Self-Attention die Verarbeitung von Sprache revolutionierte.

(rme)

Sprintziele gehören zu den stärksten Werkzeugen im Scrum-Framework. In dieser Folge diskutieren Dominique Winter und Oliver Winter, wie es Teams gelingt, Sprintziele so zu etablieren, dass sie Orientierung geben, Wirkung entfalten und Vertrauen schaffen. Ein Sprintziel ist schließlich mehr als eine Pflichtübung im Sprint Planning. Richtig eingesetzt, schafft es Klarheit über das „Warum“ der nächsten Iteration und verbindet die tägliche Arbeit mit der Produktvision.

Schwierigkeiten mit Sprintzielen

Vielen Teams fällt die Nutzung von Sprintzielen jedoch schwer. Häufig gibt es gar kein Ziel oder es bleibt auf der Ebene von Aufgabenlisten stecken. Statt echter Wirkung wird dann nur Output gemessen. Die Folge: wenig Fokus, kaum Begeisterung bei Stakeholdern und sinkendes Vertrauen in den Wert von Sprintzielen.

Gute Sprintziele: Outcome-orientiert und im Alltag präsent

Doch gerade hier liegt der Hebel. Ein gut formuliertes Sprintziel richtet die Arbeit am Outcome aus. Es beantwortet die Frage, welchen Mehrwert das Team in den kommenden zwei Wochen schaffen will, und gibt damit eine klare Orientierung für Entscheidungen im Sprint. Statt einer Sammlung von Backlog-Items entsteht ein gemeinsamer Fokus. Im Daily oder im Review lässt sich damit jederzeit prüfen, ob die Arbeit noch auf das eigentliche Ziel einzahlt.

Dominique Winter und Oliver Winter machen aber auch deutlich, dass Sprintziele eben nicht im stillen Kämmerlein entstehen sollten. Entscheidend ist die gemeinsame Gestaltung mit den Developern. Wer das Ziel aktiv mitformuliert, wird es auch eher als eigenes Commitment ansehen. So entsteht nicht nur mehr Akzeptanz, sondern auch die Bereitschaft, externe Einflüsse auszuhalten und das Ziel zu verteidigen. Product Owner bringen dabei den strategischen Rahmen ein – etwa Vision, Roadmap oder Product Goal – und öffnen einen Raum, in dem das Team das nächste sinnvolle Ziel bestimmen kann.

Ein gutes Sprintziel ist aber auch sichtbar und im Alltag präsent: in Dailys, in Gesprächen mit Stakeholdern und sogar in der spontanen Antwort auf die Frage „Woran arbeitet ihr gerade?“. Nur so werden sie zu einem lebendigen Orientierungspunkt statt zu einem Protokolleintrag. Wenn ein Team das gemeinsam vereinbarte Sprintziel erreicht, gilt es, diesen Erfolg sichtbar zu feiern; nicht die Anzahl der erledigten Backlog-Items, sondern den erzielten Mehrwert. Gerade im Sprint Review eröffnet das die Chance, Stakeholder zu begeistern und ihnen zu zeigen, warum sich die investierte Arbeit gelohnt hat. So wird das Konzept Sprintziele gestärkt und gewinnt wieder Vertrauen.

Zusammengefasst helfen Sprintziele Teams dabei, sich auf das Wesentliche zu konzentrieren, Entscheidungen leichter zu treffen und Stakeholder einzubeziehen. Wer sie konsequent auf Outcome ausrichtet, gemeinsam gestaltet und sichtbar macht, etabliert ein Instrument, das weit mehr ist als eine Formalität. Es ist ein Kompass, der Produktteams eine gemeinsame, wertvolle Richtung gibt.

Die aktuelle Ausgabe des Podcasts steht auch im Blog der Produktwerker bereit: „So etablierst du Sprintziele, die wirklich helfen„.

(mai)