Adaptives Lernen für dein EdTech-MVP

Adaptives Lernen ist Software, die anhand der bisherigen Leistung entscheidet, was ein Lernender als Nächstes sieht. Antwort richtig? Es geht weiter. Dreimal hintereinander bei den Brüchen daneben? Statt des nächsten Quiz bekommst du ein durchgerechnetes Beispiel und eine leichtere Aufgabe. Der Lernpfad ist persönlich, wird in Echtzeit berechnet und sieht für jeden Nutzer anders aus.

Das ist die ganze Idee, und sie ist älter als der aktuelle KI-Hype. Intelligente Tutorensysteme aus den 1980ern haben Lernende schon damals abhängig von ihren Antworten durch den Stoff verzweigt. Neu sind die Datenmengen und die Modellierung. Moderne Systeme für adaptives Lernen erfassen pro Lernendem Tausende kleiner Interaktionen und nutzen diese Historie, um vorherzusagen, was jemand kann und was als Nächstes drankommen sollte.

Für Gründer ist diese Einordnung hilfreich: Adaptives Lernen ist kein Feature, das du am Ende noch dazuschraubst. Es ist eine Schleife. Inhalt zeigen, Antwort beobachten, deine Einschätzung des Wissensstands aktualisieren, dann die nächste Aufgabe wählen. Alles Weitere in diesem Leitfaden dreht sich darum, eine schlanke, ehrliche Version dieser Schleife in ein erstes Produkt zu bauen, das du in Wochen statt in Jahren launchen kannst.

Lässt man das Marketing weg, läuft eine adaptive Engine in vier Schritten als Kreislauf.

Zuerst spielt sie eine Aufgabe aus: eine Frage, ein Video, einen Text, eine Programmierübung. Dann erfasst sie die Antwort und die Signale drumherum: richtig oder nicht, benötigte Zeit, genutzte Hinweise, Versuche. Im dritten Schritt aktualisiert sie das Lernermodell, eine laufende Schätzung, wie gut die Person jeden Skill in deinem Curriculum beherrscht. Und im vierten Schritt greift eine Auswahllogik, die das aktualisierte Modell liest und die nächste Aufgabe bestimmt. Dabei balanciert sie zwei Ziele gleichzeitig: den Lernenden in der Zone halten, in der die Arbeit schwer genug zum Lernen ist, aber nicht so schwer, dass er aufgibt.

Das Lernermodell ist der Teil, den die meisten unterschätzen. Ein verbreiteter, gut verstandener Ansatz ist Bayesian Knowledge Tracing: Jeder Skill wird als Wahrscheinlichkeit modelliert, dass der Lernende ihn beherrscht, und diese Wahrscheinlichkeit wird nach jeder Antwort nach oben oder unten korrigiert. Eine andere Familie, die Item-Response-Theorie, schätzt sowohl die Schwierigkeit jeder Aufgabe als auch die Fähigkeit jedes Lernenden auf derselben Skala, sodass du beide zueinander passend machen kannst. Beide sind seit Jahren produktiv im Einsatz, und keines davon braucht ein großes Sprachmodell.

Die Auswahllogik kann anfangs simpel sein, ein Satz Regeln. Sinkt die Mastery bei Skill X unter 0,6, wird Skill X neu erklärt. Liegt sie über 0,95, geht es vorwärts. Regeln sind transparent, leicht zu debuggen und für ein erstes Release völlig ausreichend. Auf optimierungsbasierte Auswahl steigst du später um, wenn du genug Lernerdaten gesammelt hast, um den Aufwand zu rechtfertigen.

Über KI-gestütztes adaptives Lernen wird oft geredet, als liefe alles auf derselben Technologie. Tut es nicht. Es gibt zwei klar getrennte Schichten, und sie lösen verschiedene Probleme.

Die erste Schicht ist die Modellierung, die die Adaptivität selbst antreibt: Knowledge Tracing, das Schätzen von Aufgabenschwierigkeit und die Auswahl der nächsten Aufgabe. Das sind statistische und Machine-Learning-Verfahren, und sie sind ausgereift. Deep Knowledge Tracing, das mit neuronalen Netzen die Wahrscheinlichkeit vorhersagt, dass ein Lernender die nächste Frage richtig beantwortet, ist seit 2015 vielfach veröffentlicht und reproduziert worden. Eine ordentliche Version dieser Schicht baust du, ohne ein Foundation-Modell anzufassen.

Die zweite Schicht ist generative KI, und hier verdienen sich große Sprachmodelle ihren Platz. Sie sind gut darin, Inhalte und Feedback in Masse zu erzeugen: Übungsfragen zu einem Skill entwerfen, Distraktoren für Multiple-Choice generieren, eine falsche Antwort verständlich erklären oder die Woche eines Lernenden zusammenfassen. Schwach sind sie beim zuverlässigen Bewerten offener Aufgaben und bei allem, was ohne menschliche Kontrolle exakt stimmen muss.

Eine praxistaugliche Aufteilung für den ersten Bau: klassisches ML für die Entscheidung, was als Nächstes gezeigt wird, und ein LLM zum Generieren und Erklären von Inhalten, die geprüft werden. So bleibt der Teil, der berechenbar sein muss, berechenbar, und die Generierung kommt dort zum Einsatz, wo Fehler billig und korrigierbar sind. Wenn du das sauber in deinen Stack einziehen willst, ist genau das der Kern eines jeden KI-Integrationsprojekts.

Bevor du baust, schau dir an, was es schon gibt, denn manches kannst du kaufen oder integrieren, statt es selbst zu schreiben.

Etablierte adaptive Lernplattformen lassen sich grob in ein paar Kategorien einteilen. Es gibt vollständige Courseware-Systeme für Hochschulen und Schulen, die Inhalte und Engine komplett selbst besitzen. Es gibt Sprach- und Skill-Apps, die ihre eigene Adaptivität rund um eine enge Domäne gebaut haben. Und es gibt reine Engine- oder Komponenten-Anbieter, die Knowledge Tracing oder Aufgabenauswahl über eine API bereitstellen, sodass du die Inhalte lieferst und sie die Mathematik.

Für ein MVP hängt die Frage Selberbauen oder integrieren davon ab, wo deine Differenzierung steckt. Liegt dein Vorsprung im Content, in deiner Lehrmethode, im Design der Assessments, in deinen Daten zu einer bestimmten Lernergruppe, dann bau eine schlanke Engine und steck deine Energie in die Inhalte. Liegt dein Vorsprung in der Engine selbst, also in einer klügeren Art, Wissen zu modellieren, dann baust du genau den schweren Teil und solltest keine Runway verbrennen, um ein Autorentool nachzubauen, das du lizenzieren könntest.

Die meisten Gründer, mit denen wir arbeiten, gehören zur ersten Gruppe. Ihre adaptive Lerntechnologie ist ein Mittel, um eine didaktische Erkenntnis auszuliefern, nicht das Produkt selbst. Das spricht für eine kleine, eigene Engine statt für eine schwergewichtige Plattform, die du dir zurechtbiegst.

Ein MVP ist keine kleinere Version des fertigen Produkts. Es ist das Kleinste, das deine zentrale Wette beweist. Bei einem adaptiven Produkt lautet die Wette meist: Verbessert das Personalisieren des Lernpfads tatsächlich das Lernen oder die Bindung unserer Nutzer, verglichen mit einem festen Pfad?

Um das zu testen, brauchst du ein Fachgebiet, einen Lernertyp und eine vollständige Schleife. Such dir einen einzelnen Skill-Bereich, für den du vielleicht 80 bis 150 gut verschlagwortete Aufgaben über mehrere Schwierigkeitsstufen schreiben oder generieren kannst. Bau den Vier-Schritte-Kreislauf aus dem vorigen Abschnitt nur gegen diese Aufgaben. Mehrere Fächer, Lehrer-Dashboards, Gamification und Integrationen lässt du weg, bis die Schleife sie sich verdient hat.

Eine sinnvolle Disziplin ist, vom ersten Tag an einen A/B-Vergleich zu fahren: Die Hälfte deiner Nutzer bekommt den adaptiven Pfad, die andere eine vernünftige feste Reihenfolge. Bewegt die Adaptivität deine Kernkennzahl nicht, also Abschluss, Mastery oder Retention, hast du etwas weit Wertvolleres gelernt als ein poliertes Feature, und das günstig.

Genau hier hilft ein Modell mit festem Scope und Festbudget. In EdTech ist die Versuchung groß, immer mehr Fächer und Rollen draufzupacken, weil jede Lehrkraft noch eine Sache will. Sperr das MVP auf eine Schleife, eine Kohorte, eine Kennzahl, und bring es in Wochen raus. Erweitern kannst du, sobald echte Lernende dir bestätigt haben, dass die Engine das Erweitern wert ist. Wenn die Engine später in einem größeren System sitzen soll, sorgt eine Roadmap Richtung Custom Software dafür, dass das schlanke MVP keine Sackgasse wird.

Das Datenmodell entscheidet still und leise über Erfolg oder Scheitern adaptiver Produkte. Wird es früh richtig gemacht, ist das spätere Hinzufügen von Fächern leicht. Wird es falsch gemacht, baust du es zum denkbar ungünstigsten Zeitpunkt komplett neu.

Fang mit einem Skill-Graphen an, manchmal auch Wissenslandkarte genannt. Liste die einzelnen Skills auf, die deine Inhalte vermitteln, und die Voraussetzungsbeziehungen dazwischen: schriftliches Dividieren geht nicht vor dem Subtrahieren einstelliger Zahlen. Schon eine flache Liste von 20 bis 40 Skills mit ein paar Voraussetzungspfeilen reicht für den Start, und sie ist das Rückgrat, in das das Lernermodell schreibt.

Jedes Content-Element, ob Frage, Video oder Text, braucht Metadaten: welchen oder welche Skills es berührt, seine Schwierigkeit, seinen Typ sowie die richtige Antwort plus etwaige akzeptierte Varianten. Diese Verschlagwortung ist die undankbare Arbeit, die alles andere erst möglich macht. Ist ein Element keinem Skill zugeordnet, kann deine Engine nicht damit umgehen.

Dazu kommen die Interaktionsdaten, das Event-Log jeder Antwort: Lernender, Aufgabe, Skill, Ergebnis, Zeitstempel, Bearbeitungszeit, genutzte Hinweise. Dieses Log ist das Gedächtnis deines Produkts und deine künftigen Trainingsdaten. Speichere es vom ersten Tag an sauber, selbst wenn du noch nichts damit machst, denn die Lernhistorie lässt sich im Nachhinein nicht wiederherstellen.

Beim Thema Compliance berührt EdTech oft Minderjährige und Schülerdaten, also plane das früh ein, statt es nachzurüsten. In den USA setzen Rahmenwerke wie FERPA und COPPA, in Europa die DSGVO Erwartungen rund um Schülerdaten, Einwilligung der Eltern und Datensparsamkeit. Das sind allgemeine Hinweise, keine Rechtsberatung; zieh für dein konkretes Produkt und deine Märkte qualifizierte Fachleute hinzu. Die bautechnische Konsequenz ist greifbar: Erhebe nur die Daten, die deine Schleife braucht, halte sie pro Lernendem trennbar und plane das Löschen von Anfang an mit ein.

Ein paar Fehler versenken adaptive MVPs immer wieder.

Die Content-Lücke ist der häufigste. Adaptivität braucht genug Aufgaben pro Skill und über genug Schwierigkeitsstufen, um den Lernenden überhaupt irgendwohin schicken zu können. Hast du acht Fragen zu einem Skill und die Engine will nach einem Fehler eine leichtere geben, ist da nichts. Gründer unterschätzen den Content-Bedarf um Größenordnungen und schieben es dann auf die Engine.

Das Cold-Start-Problem ist der zweite. Kommt ein Lernender neu, weißt du nichts über ihn, dein Modell hat also nichts, worauf es reagieren könnte. Ein kurzer Einstiegstest oder vernünftige Voreinstellungen, die durchschnittliche Fähigkeit annehmen und sich schnell nachjustieren, fangen das ab. Wer das ignoriert, macht die erste Sitzung, die darüber entscheidet, ob jemand bleibt, zur am wenigsten adaptiven überhaupt.

Die Engine zu überkonstruieren ist der dritte, und für technische Gründer ist er verführerisch. Ein tiefes neuronales Knowledge-Tracing-Modell ist spannend, braucht aber Daten von Tausenden Lernenden, um ein simples Modell zu schlagen. Mit null Nutzern gewinnt das simple Modell, weil es funktioniert und du es debuggen kannst. Bau die ausgefeilte Variante, wenn die Daten es rechtfertigen.

Und schließlich: Vorsicht davor, die falsche Kennzahl zu optimieren. Eine Engine, die richtige Antworten maximiert, kann die Aufgaben zu leicht machen und nichts beibringen. Adaptivität sollte auf produktive Anstrengung zielen, also auf das Schwierigkeitsband, in dem Lernende gefordert sind, aber oft genug Erfolg haben, um dranzubleiben. Leg dieses Ziel fest, bevor du irgendetwas tust.

Wenn du noch in der Ideenphase steckst, schreib deinen Skill-Graphen für ein Fach auf und die eine Kennzahl, die belegen würde, dass Adaptivität sich lohnt. Dieses Dokument ist gerade mehr wert als jede Technologieentscheidung, weil es dich zwingt, die Wette beim Namen zu nennen.

Von da an ist der Weg kurz: einen kleinen Content-Pool verschlagworten, ein einfaches Lernermodell implementieren, eine regelbasierte Auswahl der nächsten Aufgabe verdrahten, alles loggen und das Ganze mit einem A/B-Vergleich vor echte Lernende stellen. Das ist ein echtes adaptives Produkt, und es passt in einen Bau von Wochen statt in einen über mehrere Quartale. Die klügere Modellierung und das breitere Curriculum kommen, nachdem die Schleife sich bewiesen hat, finanziert von den Daten, die diese ersten Lernenden erzeugen.