Mit Schritt 10 hatte ich einen Wendepunkt erreicht. Ich hatte beschlossen, mein bisheriges System nicht einzustampfen, auch wenn ich wusste: ChatGPT baue ich nicht nach. Aber das System funktionierte. Das eigentliche Problem war nicht die Technik – es war meine Vorstellung, dass alles eine einzige große KI sein müsse.
Deshalb begann ich, die Frage anders zu stellen. Nicht mehr: „Wie baue ich eine KI, die alles kann?“ Sondern: „Welche einzelne Fähigkeit brauche ich gerade?“
Hinweis zur Serie: Du arbeitest bereits modular und möchtest direkt zum für mich wichtigsten Architekturwechsel? Dann geht es in Schritt 12 darum, warum Ollama irgendwann nur noch formulieren sollte.
Das erste Umdenken
Es war ein schleichender Prozess. Ich hatte mir angewöhnt, in Funktionen zu denken. Wenn Wissen ein eigenes Problem ist – warum bekommt Wissen dann keinen eigenen Bereich? Wenn Lernen etwas anderes ist – warum soll Lernen im selben großen Codeblock stecken? Und wenn das System wissen soll, was gerade passiert – warum bekommt auch dieser Zustand keinen eigenen Bereich?
Damit begann ich, Funktionen voneinander zu trennen. Nicht aus dem Wunsch nach einer eleganten Architektur, sondern weil ich bei jedem Problem merkte: Ich suche immer wieder an derselben Stelle nach der Lösung, und trotzdem muss ich dabei den ganzen Codeblock im Kopf haben.
Das Modul „Wissen“
Der Bereich Wissen sollte sich darum kümmern, welche Informationen bereits vorhanden sind. Also:
- Wissen speichern
- Wissen wiederfinden
- vorhandene Informationen bereitstellen
- erkennen, ob etwas bereits bekannt ist
Wichtig war mir von Anfang an: Wissen wird dadurch nicht automatisch richtig oder vertrauenswürdig. Ich speicherte nicht nur Fakten, sondern auch Notizen, Beobachtungen und Zwischenstände. Die Bewertung von Informationen wurde erst später ein eigenes Thema.
Das Modul „Lernen“
Lernen bedeutete für mich nicht, dass mein System sein Sprachmodell neu trainiert. Das war technisch ohnehin nicht machbar – und auch gar nicht nötig. Lernen war zunächst viel einfacher:
- neue Informationen erkennen
- entscheiden, ob sie überhaupt relevant sind
- sie sinnvoll speichern
- später wieder darauf zugreifen können
Das Sprachmodell selbst wurde dadurch nicht verändert. Mein eigenes System erweiterte seinen Wissensbestand. Dieser Unterschied war für mich zentral.
Das Modul „Bewusstsein“
Ich nannte einen Bereich meines Systems „Bewusstsein“. Dabei muss ich an dieser Stelle sehr deutlich sein: Mit „Bewusstsein“ meine ich kein menschliches Bewusstsein. Keine Gefühle, kein Selbstbewusstsein, keine Empfindungen.
Der Name bezeichnete für mich eher die Frage: Was weiß das System gerade über seinen eigenen Zustand? Zum Beispiel:
- Welche Aufgabe wird gerade bearbeitet?
- In welchem Zusammenhang befindet sich die Anfrage?
- Welche Informationen liegen bereits vor?
- Welche Schritte wurden bereits ausgeführt?
- Was ist gerade noch offen?
Es war also ein technischer Zustands- und Kontextbereich. Ich wollte, dass das System Arbeitsschritte nachvollziehen kann, statt bei jeder Anfrage bei null zu beginnen.
Warum getrennte Module plötzlich sinnvoll waren
Der größte Vorteil zeigte sich, wenn etwas nicht funktionierte. Wenn eine Funktion nicht arbeitete, musste ich nicht mehr überall suchen. Ich konnte gezielt fragen: Ist das Wissen falsch? Dann prüfte ich den Wissensbereich. Funktioniert das Lernen nicht? Dann untersuchte ich genau diesen Teil.
Auch neue Fähigkeiten wurden einfacher. Wenn ich etwas ergänzen wollte, musste ich nicht das gesamte System neu schreiben. Ich fügte einen Baustein hinzu und ließ ihn erst einmal einzeln laufen. Das machte das Projekt für mich wieder übersichtlich.
Ein Modul muss nicht intelligent sein
Ein wichtiger Punkt war für mich: Nicht jedes Modul braucht ein Sprachmodell. Ein Modul kann auch ganz normale Programmlogik sein. Zum Beispiel:
- Bedingungen
- Datenbankabfragen
- Regeln
- Vergleiche
- Zustände
- feste Abläufe
Das Sprachmodell war nur dort nötig, wo seine Fähigkeiten tatsächlich gebraucht wurden: beim Verstehen von Texten, beim Formulieren, beim Erkennen von Zusammenhängen, die nicht durch feste Regeln abbildbar sind. Damit wanderte immer mehr Verantwortung aus Ollama heraus in mein eigenes System.
Wie die Module zusammenarbeiten
Ich möchte das Prinzip an einem einfachen Beispiel zeigen:
Eine Frage kommt ins System. Ein Teil erkennt, worum es ungefähr geht. Ein anderer Teil sucht vorhandenes Wissen. Ein anderer prüft, was bereits passiert ist. Ein anderer nimmt neue Informationen auf, wenn es welche gibt. Und erst wenn es wirklich nötig ist, wird Ollama eingebunden.
Das ist keine fertige Pipeline, die ich damals geplant hätte. Ich wollte nur eines verstehen: Mehrere kleine Teile können zusammenarbeiten, anstatt dass ein einziger großer Block alles erledigt. Dieses Prinzip wurde für mich zur Grundlage von Eureka.
Warum das für mich besser passte
Dieser Aufbau entsprach viel mehr meiner Art zu arbeiten. Ich bin jemand, der gern ein Problem nach dem anderen löst. Ein Problem, eine Funktion, ein Test – dann der nächste Baustein.
Vorher hatte ich oft versucht, eine riesige KI auf einmal zu verstehen. Das gelang nicht. Mit den Modulen konnte ich einzelne Teile betrachten, ohne den Überblick zu verlieren. Das Projekt wurde für mich wieder beherrschbar.
Neue Ideen wurden plötzlich einfacher
Mit getrennten Fähigkeiten konnte ich später weitere Module ergänzen, ohne das gesamte System umzubauen. Zum Beispiel:
- Recherche
- Quellenprüfung
- Planung
- Entscheidungen
- Speicherung
- Diagnose
- andere Spezialfunktionen
Ich möchte hier nicht behaupten, dass diese Module schon fertig waren. Sie waren noch nicht einmal geplant. Aber die modulare Struktur machte solche Erweiterungen überhaupt denkbar. Zum ersten Mal konnte ich mir vorstellen, dass aus meinem Projekt ein eigenständiges System werden könnte – nicht nur eine Sammlung von Prompt-Tricks.
Ein Problem blieb bestehen
Obwohl mein System modularer wurde, hatte Ollama immer noch zu viel Einfluss auf die eigentliche Antwort. Es bekam Informationen, Regeln und Aufgaben und sollte daraus entscheiden, was es sagt. Und genau damit war ich noch nicht zufrieden.
Je länger ich daran arbeitete, desto stärker wurde der Gedanke: Warum soll Ollama überhaupt noch entscheiden, was richtig ist? Vielleicht sollte mein eigenes System diese Entscheidungen treffen. Und Ollama bekommt am Ende nur noch eine Aufgabe – formulieren.
Der Punkt, an dem Eureka Form annahm
Mit den Modulen bekam Eureka erstmals wirklich eine eigene Struktur. Nicht perfekt, nicht fertig. Aber ich konnte erkennen, dass daraus tatsächlich mein eigenes System werden konnte.
Das war für mich ein wichtiger Unterschied. Es ging nicht mehr darum, Ollama mit immer mehr Funktionen zu umgeben. Es ging darum, ein eigenes System zu bauen, das Ollama als einen Baustein benutzt. Dieser Gedanke trug mich durch alle weiteren Schritte.
Schritt 11 ist geschafft, wenn …
Nach diesem Schritt solltest du Folgendes verstanden haben:
- große Probleme können in einzelne Fähigkeiten zerlegt werden
- Wissen und Lernen sind nicht dasselbe
- Lernen bedeutet hier nicht, das Sprachmodell neu zu trainieren
- „Bewusstsein“ ist in meinem Projekt eine technische Bezeichnung für Zustand und Kontext
- Module können auch normale Programmlogik sein
- nicht jede Aufgabe braucht ein Sprachmodell
- durch Modularität übernimmt das eigene System immer mehr Verantwortung
Ausblick auf Schritt 12
Schritt 12 wird für mich zum entscheidenden Architekturwechsel. Der Titel lautet sinngemäß: „Ollama soll nur noch formulieren“.
Je länger ich Eureka baute, desto weniger Entscheidungen wollte ich dem Sprachmodell überlassen. Mein eigenes System sollte bestimmen:
- welche Informationen relevant sind
- was geprüft wird
- was gespeichert werden darf
- welche Fakten verwendet werden
- welche Regeln gelten
Ollama sollte diese Entscheidungen nicht mehr treffen. Das Sprachmodell bekommt am Ende nur noch die bereits vorbereiteten Informationen und macht daraus eine verständliche Antwort. An diesem Punkt begann Eureka, meinen ursprünglichen Vorstellungen wirklich zu entsprechen.