Förderjahr 2025 / Projekt Call #20 / ProjektID: 8018 / Projekt: Qriouso
Acht Monate Entwicklung, über 20.000 Konzepte aus dem AHS-Lehrplan und eine Pipeline, die jede Antwort prüft, bevor sie ein:e Schüler:in sieht. Ein ehrlicher Zwischenstand aus dem netidee-Projekt Qriouso – inklusive dem, was wir verworfen haben.
Acht Monate später: Warum ein KI-Tutor mehr als einen guten Prompt braucht
Vor acht Monaten haben wir hier geschrieben, dass wir einen KI-Tutor bauen wollen, der Schüler:innen nicht einfach die Lösung verrät.
Das klingt zunächst nach einer Anweisung im System-Prompt: „Gib niemals die Antwort.“ Inzwischen wissen wir: Das reicht nicht. Wer Non-Spoiling ernst meint, muss es technisch erzwingen.
Dieser Beitrag zeigt, was daraus geworden ist, welche Teile bereits funktionieren und was wir unterwegs wieder verworfen haben.
Der aktuelle Stand
Die Plattform läuft derzeit lokal. Die aufbereitete Wissensbasis umfasst inzwischen die grundlegenden Unterrichtsfächer mit rund 20.000 Konzepten, die aus den Subkompetenzen entstanden sind. Durch die natürliche Anordnung im Curriculum, kann man dadurch sogenannte Pre-Requisite Chains herauslesen, sprich: welches Wissen und in diesem Fall welche Konzepte muss ich beherrschen, bevor ich weiterführende angehen sollte.
Der sokratische Tutor funktioniert, die vierstufige Hinweisleiter ist eingebaut und das Lehrkräfte-Dashboard zeigt den Lernstand einer Klasse auf Konzeptebene statt nur als Notenliste. Verschiedene Erklärstile sind technisch angebunden, unterscheiden sich im Dialog aber noch nicht deutlich genug voneinander.
Was noch fehlt, ist der Produktivbetrieb – und damit der entscheidende Test im echten Unterricht.
Warum „kein Spoiler“ ein Architekturproblem ist
Eine 2025 in PNAS veröffentlichte Feldstudie mit knapp 1.000 Schüler zeigt ziemlich genau, warum uns dieses Thema beschäftigt.
Während der Übungsphase schnitten Jugendliche mit einem frei antwortenden KI-Tutor deutlich besser ab. Sobald sie ohne KI geprüft wurden, lagen ihre Ergebnisse jedoch 17 Prozent unter jenen der Kontrollgruppe. Ein Tutor mit pädagogischen Schutzmechanismen konnte diesen negativen Effekt weitgehend verhindern.
Das Problem ist also nicht, dass KI im Unterricht eingesetzt wird. Entscheidend ist, welche Denkarbeit sie den Lernenden abnimmt.
Ein System-Prompt wie „Verrate niemals die Lösung“ hält dem Alltag nicht lange stand. Schüler:innen fragen nach, formulieren um oder verlangen irgendwann einfach direkt die Antwort. Ein gewöhnliches Sprachmodell gibt unter diesem Druck früher oder später nach.
Deshalb ist Non-Spoiling bei uns ein technischer Prüfprozess und kein bloßes Versprechen. Bevor eine Tutorantwort angezeigt wird, durchläuft ihr Entwurf drei Schutzebenen:
1. Begriffliche Grenze: Das System prüft deterministisch, ob die Antwort Begriffe, Formeln, Lösungsschritte oder Konzepte enthält, die im aktuellen Lernschritt noch gesperrt sind.
2. Semantische Prüfung: Auch Umschreibungen können eine Lösung verraten. Deshalb wird geprüft, ob der Entwurf einem gesperrten Inhalt sinngemäß zu nahekommt.
3. Strukturiertes Modellurteil: Ein eigener Prüfschritt bewertet, ob eine Antwort, eine Methode oder ein geschütztes Konzept preisgegeben wurde. Das Ergebnis enthält Risikostellen, Belege und die erforderliche Aktion.
Ist der Entwurf sicher, wird er freigegeben. Ist er riskant, wird er als sokratische Rückfrage neu geschrieben und erneut geprüft. Wenn auch das nicht zuverlässig gelingt, liefert das System eine vorbereitete, sichere Hilfestellung.
Nehmen wir die Aufgabe:
2x² + 5x + 3 = 0
Ein normales Modell möchte sofort die Diskriminante nennen, die Formel einsetzen und die Zahl der Lösungen bestimmen. Im gesperrten Lernmodus wird genau das abgefangen.
Stattdessen könnte der Tutor fragen:
Welche Größe hilft dir zu entscheiden, ob eine quadratische Gleichung keine, eine oder zwei reelle Lösungen hat?
Im Zweifel bekommt ein Schüler also eine vorsichtige Rückfrage – nicht eine riskante Antwort.
Das ist der Unterschied zwischen „Wir bitten das Modell, nichts zu verraten“ und „Wir prüfen jede Antwort, bevor sie den Tutor verlässt“.
Was wir gebaut und wieder gelöscht haben
Im Förderantrag war vorgesehen, Wikipedia-Inhalte mit dem österreichischen Lehrplan zu verknüpfen. Wir haben diesen Ansatz umgesetzt – und anschließend wieder entfernt.
Der Grund war unspektakulär: Die Ergebnisse waren zu ungenau.
Wikipedia-Artikel sind enzyklopädisch aufgebaut, nicht didaktisch. Bei der Verknüpfung mit einzelnen Lehrplankompetenzen entstanden viele Konzepte, die zwar fachlich verwandt, für den konkreten Lernschritt aber nicht hilfreich waren. Gleichzeitig fehlten genau jene kleinen Zwischenschritte, an denen Schüler:innen im Unterricht tatsächlich hängen bleiben.
Stattdessen bauen wir nun eine vorbereitete Inhaltsdatenbank. Für jede Teilkompetenz entstehen Konzepte, Hinweisleitern, Einstiegsfragen, Übungsaufgaben und typische Fehlvorstellungen. Diese Inhalte werden zuerst vorab erzeugt, können aber jederzeit adaptiert werden.
Lehrkräfte entscheiden, welche Inhalte für ihre Klasse und das jeweilige Lernziel tatsächlich relevant sind. Besonders bei abstrakten Kompetenzen, etwa im Sprachunterricht, lässt sich diese kuratierende Rolle nicht sinnvoll automatisieren. Sie ist kein Hindernis im Prozess, sondern ein zentraler Teil davon.
Lernen, beweisen, weiterbauen
Der Lernablauf folgt fünf Schritten und einer einfachen Regel: Fortschritt wird nicht durch das Lesen einer Erklärung bewiesen, sondern durch selbstständiges Anwenden.
Diagnose – Ein kurzes Einstiegsquiz sucht entlang des Vorwissensgraphen nach Lücken.
Lernen – Konzepte werden mit ausgearbeiteten Beispielen und passenden Erklärungen aus dem Curriculum-Graphen erschlossen.
Üben – Der Tutor führt einen sokratischen Dialog und gibt abgestufte Hinweise, ohne die Lösung vorwegzunehmen.
Beweisen – Ein Miniquiz prüft das Konzept ohne Tutor. Im aktuellen Lernpfad liegt die Schwelle bei 70 Prozent. Vor dem Schulbetrieb vereinheitlichen wir noch ältere Programmteile, die derzeit unterschiedliche Mastery-Schwellen verwenden.
Wiederholen – Fragen werden auf Basis von FSRS, einem modernen Spaced-Repetition-Verfahren, zum passenden Zeitpunkt erneut vorgelegt.
Der vierte Schritt ist uns besonders wichtig: Der Dialog unterrichtet, aber die Prüfung entscheidet.
Während des Mastery-Checks tritt die KI ab. Wer die Schwelle nicht erreicht, wird über eine Remediation-Verbindung an die passende Stelle im Lernpfad zurückgeführt, nicht zu einem Lösungsschlüssel.
Auch Begriffe, die Schüler:innen während eines Dialogs in ihre Wortsammlung übernehmen, können als Wiederholungskarten gespeichert werden. Die Wiederholungslogik auf Fragenebene funktioniert bereits. Die verschiedenen Wiederholungspfade für Quizze, Lernpfade und Begriffskarten müssen vor dem Pilotbetrieb allerdings noch vollständig zu einer gemeinsamen sichtbaren Warteschlange zusammengeführt werden.
Für Lehrkräfte: eine Klasse auf Konzeptebene
Eine Note sagt, dass etwas nicht funktioniert hat. Sie sagt selten, woran es lag.
Deshalb zeigt das Lehrkräfte-Dashboard keine bloße Notenliste, sondern eine Heatmap aus Schüler:innen und Konzept. Statt „Julia hat eine Vier“ sieht die Lehrkraft beispielsweise:
In dieser Klasse gibt es bei neun von 24 Schüler eine Lücke beim Erweitern von Brüchen.
Zugewiesene Konzepte werden automatisch in eine sinnvolle Vorwissensreihenfolge gebracht. Wer eine notwendige Grundlage noch nicht beherrscht, wird zuerst dorthin zurückgeführt.
Auch der Datenschutz wurde dafür von Beginn an mitgedacht. Die serverseitige Auswertung arbeitet mit klassenbezogenen Pseudonymen. In der Heatmap werden echte Namen erst im Browser der Lehrkraft entschlüsselt – mit einem Schlüssel, den der Server nicht kennt.
Wer nur die Datenbank sieht, erhält dadurch keine direkt lesbare Zuordnung zwischen Lernstand und Namen.
Warum die Schuldemo erst im Herbst stattfindet
Ursprünglich war der Schuleinsatz für April vorgesehen. Anschließend sollten fünf Monate für die Einarbeitung des Feedbacks bleiben. In Abstimmung mit netidee verschieben wir die Pilotphase auf das Wintersemester 2026/27.
Dafür gibt es zwei Gründe.
Erstens war der Entwicklungsaufwand größer als geschätzt. „Läuft lokal“ und „ist bereit für eine Schulklasse“ sind zwei verschiedene Zustände.
Zweitens wäre eine Pilotierung im Mai oder Juni didaktisch wenig aussagekräftig gewesen. Nach Abschluss des Maturajahrgangs steht kaum neuer Stoff im Vordergrund, und auch in den unteren Stufen wird gegen Schuljahresende hauptsächlich wiederholt.
Eine solche Pilotierung hätte uns wahrscheinlich freundliches, aber wenig belastbares Feedback geliefert.
Wir wollen wissen, ob der Tutor im echten Unterricht trägt: bei neuem Stoff, in einer vollständigen Klasse und mit Schüler:innen, die tatsächlich etwas noch nicht verstanden haben. Dafür ist der Schulbeginn der ehrlichere Test.
Fördersumme, Stundensätze und der geplante Gesamtaufwand bleiben von der Verschiebung unberührt.
Was als Nächstes passiert
August und September 2026: Produktivbetrieb, Accessibility-Feinschliff nach WCAG 2.1 und Onboarding der Pilotschule
September bis November 2026: Erprobung im laufenden Unterricht, User-Testing sowie Vor- und Nachbefragungen
Bis Jänner 2027: Überarbeitung auf Basis des Feedbacks und weitere Lasttests
Februar 2027: Endbericht, Dokumentation für Anwender und Entwickler sowie eine Self-Hosting-Anleitung für Schulen
Die Software wird unter AGPL-3.0-or-later auf GitHub veröffentlicht. Für die offene Projektdokumentation ist CC BY-SA 4.0 vorgesehen.
Mitmachen
Wir suchen Lehrkräfte, die im Wintersemester mit einer Klasse pilotieren möchten.
Ein Fach, eine Klasse – und gerne die schwierigste Frage aus Ihrem Unterricht.
Kontakt: steven.ludwig.school@gmail.com
Einen ersten Überblick über Architektur und Funktionsweise gibt es unter:
