Rund sechs Wochen lang hat ein Frontier-KI-Modell viermal am Tag ein festes Skript in mein Journal vorgelesen. Was ich daraus über den Platz des Modells gelernt habe – und warum ich kein eigenes trainiert habe.
Mein Tag beginnt mit einer Journalseite: Datum, offene Aufgaben, Kalender, das über Nacht Eingegangene in Kürze. Im März baute eine zeitgesteuerte Claude-Aufgabe diese Seite viermal am Tag, um 05:00, 09:00, 13:00 und 17:00, und arbeitete dabei etwa siebzehn nummerierte Schritte aus einer langen Anweisungsdatei ab: die Seite aus einer Vorlage anlegen, erledigte Aufgaben abhaken, den Kalender übernehmen, die Mails sortieren. Das funktionierte gut – mit dem leistungsfähigsten Modell, das ich mieten konnte.
Was das Modell da tat
Am 21. März, dem Tag der Restart-Notiz aus Beitrag 2, schrieb ich eine Konzeptnotiz und markierte darin, welche dieser Schritte überhaupt ein Sprachmodell brauchten. Die meisten nicht: Eine Vorlage ausfüllen, eine Tabelle sortieren, Daten abgleichen – das ist gewöhnliche Programmierung. Der Assistent lief trotzdem fünf weitere Wochen. Er funktionierte, und etwas zu ersetzen, das funktioniert, schiebt man gern auf.
Im Mai ließ ich Claude die gesamte Aufzeichnung durchgehen und 885 Sitzungen von Februar bis Mai in drei Stufen einteilen: reines Python genügt (198), ein kleines lokales Modell genügt (401), oder die Aufgabe braucht ein Frontier-Modell (286). Die Methode war grob, gestützt auf Signale wie die erste Nachricht, den Umfang der Ausgabe und den Werkzeugmix; ich schätze ihre Unschärfe auf etwa 15 Prozent in beide Richtungen. Beim geplanten Assistenten, rund 160 Läufe, war das Urteil eindeutig: „pure orchestration, stepping through a fixed script“.
Der Assistent selbst war schon am 25. April abgeschaltet worden, vor der Analyse; Python hatte seine Routinen übernommen.
Drei Stufen
Meine Regel seitdem, für jede neue Aufgabe: zuerst Python, dann ein lokales Modell, zuletzt ein Frontier-Modell, jeweils nur dort, wo das einfachere nicht reicht. Am 31. August zählte ich 67 geplante Jobs auf meinen Rechnern; vier davon riefen ein Cloud-Modell auf, rund 6 Prozent. Drei der vier Jobs, die noch zur Migration anstanden, gab es in dieser Form nicht mehr; der Umzug war stückweise nebenbei geschehen, im Zuge anderer Arbeit.
Soll ich ein eigenes Modell trainieren?
Im Juli kam die umgekehrte Versuchung: ein Modell mit meinen eigenen Daten zu trainieren, mit sechs Monaten Chatverlauf und einem Ordner voller Notizen. Claude riet ab. Training bringt einem Modell Verhalten bei, keine Fakten, und mein Notizordner (englisch „Vault“) besteht überwiegend aus Fakten, die in einen Suchindex gehören. Zuerst also ein Prüfstand.
Bevor es Belege gab, schrieb ich eine Entscheidungsregel auf: Wenn fünf abgerufene Beispiele im Prompt gut genug wären, gäbe es kein Training, und das würde als Erfolg zählen. Der Prüfstand, ein Evaluations-Harness, nutzte 100 Buchungen, deren Kategorie eine Person korrigiert hatte, und maß, ob ein Modell Bereich und Kategorie exakt traf. qwen3 mit acht Milliarden Parametern kam ohne Beispiele auf 22 Prozent, mit fünf ähnlichen Einträgen aus meiner Historie auf 70 Prozent. Acht Beispiele brachten dieselben 70. Das größere gemma3 mit zwölf Milliarden schnitt schlechter ab und lief etwa neunmal langsamer, weil es nicht in den Speicher der 8-GB-Grafikkarte passte.
Zwei Dinge, die der Prüfstand aufgedeckt hat
Beim Bauen fielen zwei Fehler auf. Claudes Analyse hatte behauptet, ein bestimmtes Datenbankfeld kennzeichne von Menschen bestätigte Antworten. Es kennzeichnete keine; das eigentliche Signal steckte im Audit-Log, wo eine namentlich genannte Person eine Kategorie korrigiert hatte. Der zweite Fehler war meiner: Viele Einträge enthielten Kommentare zur Korrektur selbst, sodass ein Modell hätte punkten können, indem es die Antwort aus seiner Eingabe ablas. Claude und ich haben sie bereinigt. Jedes System, das seine eigenen Änderungen protokolliert, kann so seine Antworten verraten.
Das Muster
Python, wo Vorhersagbarkeit zählt, ein lokales Modell für Routine-Urteile, ein Frontier-Modell, wo das Urteil das Produkt ist – und messen, bevor man trainiert. Eine Frage entscheidet beide Geschichten: Braucht die Aufgabe eine feste Regel, eine routinemäßige Klassifikation oder etwas, bei dem Qualität sichtbar wird? Dem Journal-Assistenten hatte ich sie nicht gestellt; der Prüfstand stellte sie der Trainingsidee, bevor ich etwas investiert hatte.
Ganz gelöst ist es nicht. Die 70 Prozent lassen einen Rest, und manche Fehltreffer liegen vielleicht an der Eingabe selbst: Eine Versicherungsabbuchung kann zum Auto gehören oder zur Reise. Interaktive Arbeit (Morgen- und Quartals-Review, Schreiben, Gestaltung) bleibt bewusst beim Frontier-Modell.
Teil 3 von zwölf in der Serie darüber, wie ich mein AI OS gebaut habe. Der Anfang: das Vorwort.
Als Nächstes: drei Maschinen und ein Laptop, der schläft. Das meiste, was in meinen ersten sechs Monaten schiefging, hatte eine einzige Ursache.
* Rechnernamen sind geändert (hier: Yavin, mein Heimserver). Die echten stammen aus einer anderen Saga.
Anhang – für alle, die selbst bauen
- Liste die Schritte einer Aufgabe auf, bevor du ein Modell wählst. Markiere jeden: feste Regel, Routine-Urteil oder Urteil, bei dem Qualität sichtbar wird. Oft genügt ein regulärer Ausdruck, ein kleines lokales Modell oder ein Mensch, der das Ergebnis liest; das Frontier-Modell heb dir für Gestaltung, Fehlersuche und Schreiben auf.
- Probiere abgerufene Beispiele im Prompt, bevor du feintunest. Bei mir brachten fünf den Großteil des Gewinns, acht nichts mehr.
- Baue das Golden Set aus menschlichen Korrekturen, nicht aus Modellausgaben; entferne alles, was die Antwort verrät; halte den Beispielpool getrennt von den Messdaten.
- Schreib die Entscheidungsregel vor dem Ergebnis auf. Ist die Mühe erst investiert, fällt das schwer.
- Führe Nutzungsprotokolle. Mit ihnen konnte ich 885 Sitzungen im Nachhinein einordnen.
- Was ich stattdessen erwogen habe: alles beim Frontier-Modell lassen (am einfachsten, beste Qualität, aber man bezahlt für Klempnerarbeit und hängt an der Verbindung), ein feingetuntes persönliches Modell (falsch für Fakten, schlechter für die Privatsphäre) und alles lokal (billig, aber schwächer, wo Qualität zählt). Ich habe drei Stufen gewählt, weil so jede Aufgabe das Günstigste bekommt, was sie verlässlich erledigt.