Von Analyse-Agenten zum Energie-Cache: Wie sich die Pipeline veränderte
⚠️ Dieser Artikel beschreibt eine frühere Version des Systems. Die Multi-Agenten-Pipeline mit Klassifikation, Planung und Energie-Cache wurde vollständig durch einen einzigen GPT-5.2-Agenten ersetzt. Die vier Verarbeitungsströme (GENERAL_OVERVIEW, FULL_ANALYSIS, FOLLOW_UP, SIMPLE_CHAT) existieren nicht mehr — alle Fragen laufen durch einen einzigen Prompt mit dem vollständigen Karten-JSON.
Die aktuelle Architektur von Astrology Bot ist nicht die erste Version. Davor gab es einen anderen Ansatz — einfacher und günstiger — der aufgegeben werden musste. Nicht wegen der Kosten — wegen der Instabilität.
Der alte Ansatz: GPT-5-mini und Interpretationsfreiheit
Die erste Version lief auf GPT-5-mini. Die Pipeline war geradlinig:
- ◆Benutzer stellt eine Frage
- ◆Planer erstellt einen Plan: welche Kartenelemente analysiert werden müssen (4–10 Punkte)
- ◆Für jeden Punkt — ein separater Aufruf: Spezifikationsgenerierung, Datenextraktion aus der Karte, Analyse
- ◆Synthesizer fügt alles zu einer finalen Antwort zusammen
GPT-5-mini brauchte keine strenge Struktur — er verarbeitete großzügige Spezifikationen und lieferte etwas ab. Stellenweise war es ganz ordentlich. Es war günstig.
Das Problem lag woanders.
Warum der Abschied nötig war
Dasselbe Kartenelement wurde je nach Frage unterschiedlich interpretiert. Fragt man nach Beziehungen — betont das Modell das 7. Haus. Fragt man nach dem Charakter — und dieselben Beziehungen werden plötzlich über die Venus beschrieben, mit anderen Schwerpunkten und anderen Schlussfolgerungen. Beide Antworten konnten auf ihre Art richtig sein, aber sie widersprachen einander.
Für einen astrologischen Service ist das inakzeptabel. Wenn jemand zwei Fragen stellt und zwei verschiedene Beschreibungen desselben Elements seiner Karte erhält — bricht das Vertrauen in das System zusammen. Nicht weil die Antworten schlecht sind, sondern weil sie inkonsistent sind.
Das zweite Problem war das Fehlen von Akkumulation. Jede Frage generierte alles von Grund auf neu. Die zehnte Frage kostete genauso viel wie die erste. Kein „Lernen" des Systems über eine bestimmte Karte fand statt.
Die zentrale Erkenntnis: Kartenenergie ist statisch
Irgendwann wurde offensichtlich: Die Energie des 3. Hauses in einer Geburtskarte ist dieselbe, unabhängig von der Frage. Herrscher, Aspekte, Planeten im Haus, Spannungen und Unterstützungen — nichts davon ändert sich, egal ob die Person nach Geld oder nach Beziehungen fragt.
Das bedeutet: Man kann es einmal beschreiben — ausführlich, strukturiert, mit beiden Manifestationsmodi (als äußerer Druck und als persönliches Instrument) — und in jeder Analyse wiederverwenden. Über diese Energiebeschreibungen schreibe ich separat — es ist der arbeitsintensivste Teil des Projekts.
Diese Erkenntnis stellte die Architektur auf den Kopf.
Das aktuelle System: 4 Verarbeitungsströme
Jetzt durchläuft jede Frage einen Intent-Klassifikator — einen leichtgewichtigen Sonnet-Aufruf, der den Anfragetyp bestimmt. Danach wird in einen von vier Strömen geroutet:
GENERAL_OVERVIEW — „erzähl mir über den Charakter", „was ist interessant an der Karte?". Ein fester Plan aus 12 Häusern, alle Texte bereits im Cache (generiert bei der Karteninitialisierung). Sie werden sofort geladen, es bleibt nur die Synthese — der anspruchsvollste Teil in Bezug auf die Prompts.
FULL_ANALYSIS — eine konkrete Frage zu einem Thema: „wie steht es mit der Karriere?", „erzähl mir über Beziehungen". Der Planer erstellt einen Plan mit 4–10 Punkten (Häuser und Planeten), das System prüft den Cache, generiert nur die fehlenden Texte und synthetisiert dann die Antwort. Jeder für diese Analyse generierte Text wird gespeichert und steht für zukünftige Fragen zur Verfügung.
FOLLOW_UP — Präzisierung oder Fortführung innerhalb des aktuellen Themas. Erfordert keinen neuen Plan, trägt aber im Kontext alle Energietexte der Sitzung, den Persönlichkeitskern und das gesamte Gespräch. Kann zusätzliche Daten heranziehen, wenn das Gespräch in ein angrenzendes Thema abdriftet.
SIMPLE_CHAT — Begrüßungen, allgemeine Fragen, „was kannst du?". Ein einzelner Modellaufruf, ohne Astrologie.
Zwei Modelle, geteilte Rollen
Vorbereitende Agenten — Klassifikator, Planer, Energietext-Generatoren — laufen immer auf Sonnet. Es ist ein schnelles, günstiges Modell, das strukturierte Aufgaben gut bewältigt.
Die finale Antwort an den Benutzer — die Synthese — läuft über das Modell, das der Benutzer selbst wählt: Sonnet (schneller und günstiger) oder Opus (tiefgründiger und teurer). Genau in der Synthesephase zeigt sich der Qualitätsunterschied: Opus erkennt besser nicht offensichtliche Zusammenhänge zwischen Themen und erstellt ein stimmigeres Gesamtbild.
Was das gebracht hat
Stabilität. Ein Kartenelement — eine Interpretation. Das dritte Haus wird einmal beschrieben und ändert sich nicht von Frage zu Frage. Wenn das Modell die Energie qualitativ hochwertig beschrieben hat — funktioniert dieser Text in jedem Kontext.
Akkumulation. Jede Frage „wärmt" die Karte auf. Die erste Analyse ist die teuerste, weil das System neue Texte generiert. Die zweite ist günstiger. Die zehnte — noch günstiger. Die Karte wird mit jeder Frage reichhaltiger.
Der Wechsel zu Claude. Der alte Ansatz lief auf GPT-5-mini, der keine strenge Struktur brauchte. Der neue erfordert präzise Einhaltung des Energiebeschreibungsformats — und genau hier stellte sich heraus, dass GPT damit nicht zurechtkommt, Sonnet hingegen schon.
Es gibt den Gedanken, irgendwann einen leichtgewichtigen Modus mit weniger strukturierter Analyse zurückzubringen. Aber vorerst möchte ich die Oberfläche nicht überladen — sie ist stellenweise ohnehin etwas komplex.