Teil 3 einer Serie über das Hierarchical Reasoning Model (HRM) und seinen Einsatz im Unternehmen
In den ersten beiden Teilen haben wir über Architektur und Use Cases gesprochen. Das klingt logisch und vielversprechend. Aber oft bleibt bei KI-Konzepten ein diffuses Gefühl zurück:
„Okay, aber wie macht das System das eigentlich? Woher kommt die Magie?“
Heute ändern wir das. Wir öffnen die Black Box und schauen uns einen konkreten Denkprozess (Reasoning Trace) in Zeitlupe an.
Wir sehen uns an, wie das High-Level Network (der Stratege) und das Low-Level Network (der Arbeiter) zusammenspielen, um ein Problem zu lösen, an dem klassische LLMs oft scheitern.
Das Szenario: Eine dynamische Routenplanung
Nehmen wir ein vereinfachtes, aber realistisches Problem aus der Logistik (siehe Teil 2):
Aufgabe: Ein Lieferfahrzeug muss von Startpunkt A zu Zielpunkt B. Bedingungen:
- Es gibt drei mögliche Hauptrouten.
- Auf Route 1 wird plötzlich ein Stau gemeldet.
- Route 2 hat eine Höhenbeschränkung (für LKW unpassend).
- Route 3 ist der Umweg, aber frei.
- Das Fahrzeug hat begrenzten Treibstoff.
Ein LLM würde versuchen, die Antwort basierend auf ähnlichen Textmustern vorherzusagen. HRM hingegen simuliert die Lösung hierarchisch.
Schritt 1: Die Wahrnehmung & Abstraktion
Zuerst nimmt das System die Rohdaten auf (Karte, Verkehrsdaten, Fahrzeugtyp). Aber es füttert diese nicht einfach in ein riesiges Netz.
Das High-Level Network (HLN) erstellt eine abstrahierte Repräsentation des Problems. Es ignoriert Details wie Straßenamen oder Hausnummern und sieht nur:
- Knotenpunkte (Start, Ziel, Zwischenstationen)
- Einschränkungen (Stau, Höhe, Treibstoff)
Interner Zustand (High-Level):
Ziel: A → B. Status: Initialisierung. Constraint 1: Route 1 blockiert (Kosten: ∞). Constraint 2: Route 2 blockiert für Typ LKW (Kosten: ∞). Strategie: Finde Pfad mit minimalen Kosten unter Berücksichtigung von Constraints.
Schritt 2: Die Strategische Planung (High-Level)
Jetzt beginnt das eigentliche Reasoning. Das HLN versucht nicht, jeden Meter der Straße zu berechnen. Es setzt Teilziele (Sub-Goals).
Es formuliert einen Plan:
- Prüfe Machbarkeit Route 1.
- Prüfe Machbarkeit Route 2.
- Prüfe Machbarkeit Route 3.
- Wähle beste Option.
High-Level-Kommando an Low-Level:
„Untersuche Route 1 auf Durchfahrbarkeit.“
Schritt 3: Die operative Ausführung (Low-Level)
Das Low-Level Network (LLN) empfängt das Teilziel. Es arbeitet auf einer viel schnelleren Zeitebene und schaut sich die Details an.
Aktion (Low-Level):
- Lade Verkehrsdaten für Route 1.
- Erkenne: „Stau, Verzögerung > 2 Stunden.“
- Berechne: Kostenfaktoren steigen ins Unendliche.
Feedback (Low-Level an High-Level):
„Route 1 fehlgeschlagen. Grund: Zeitüberschreitung (Stau).“
Schritt 4: Adaption und Neuplanung
Hier passiert der entscheidende Unterschied zu einfachen Scripten oder LLMs. Das High-Level Network bricht nicht ab und halluziniert auch keine freie Straße. Es verarbeitet das Feedback und aktualisiert seinen internen Zustand.
Interner Zustand (High-Level):
Route 1 = ungültig. Nächster Schritt: Prüfe Route 2.
High-Level-Kommando an Low-Level:
„Untersuche Route 2 auf Durchfahrbarkeit für Fahrzeugtyp LKW.“
Aktion (Low-Level):
- Prüfe Höhendaten für Route 2.
- Vergleiche mit Fahrzeugprofil.
- Erkenne: „Brückenhöhe 3.8m < Fahrzeug 4.0m.“
Feedback (Low-Level an High-Level):
„Route 2 fehlgeschlagen. Grund: Physische Restriktion (Höhe).“
Schritt 5: Die Lösungskonvergenz
Das High-Level Network hat nun zwei Optionen eliminiert. Es muss nicht „raten“, welche übrig bleibt. Es folgt logisch dem nächsten Schritt im Plan.
High-Level-Kommando an Low-Level:
„Untersuche Route 3.“
Aktion (Low-Level):
- Prüfe Verkehr: Frei.
- Prüfe Restriktionen: Keine.
- Prüfe Treibstoff: Strecke länger, aber Tank reicht knapp.
Feedback (Low-Level an High-Level):
„Route 3 möglich. Kosten: Hoch (Zeit/Sprit), aber machbar.“
Schritt 6: Das Ergebnis und der „Trace“
Das High-Level Network hat sein Ziel erreicht. Es generiert nun die finale Ausgabe.
Aber – und das ist für Unternehmen essenziell – es liefert nicht nur „Nimm Route 3“. Da das Modell den Prozess explizit durchlaufen hat, kann es den Reasoning Trace (die Denkspur) mitliefern.
Output an den Nutzer:
Empfehlung: Route 3.
Begründung:Route 1 wurde verworfen wegen kritischer Verkehrsverzögerung.Route 2 wurde verworfen wegen Höhenbeschränkung (Unterführung km 45).Route 3 ist die einzig verbleibende valide Option.
Warnung: Treibstoffreserve beachten (Reichweite nach Ankunft: 15km).
Warum ist das besser als Chain-of-Thought bei LLMs?
Manche werden sagen: „Aber GPT-4 kann ich mit Chain-of-Thought (CoT) auch dazu bringen, so zu argumentieren.“
Das stimmt bedingt, aber es gibt fundamentale Unterschiede:
- Deterministische Logik vs. Probabilistische Imitation: Das LLM imitiert die Sprache einer logischen Herleitung. Es kann aber mitten im Satz vergessen, dass das Fahrzeug ein LKW ist, wenn der Kontext zu lang wird („Lost in the Middle“). HRM muss die Hierarchie einhalten. Wenn das Low-Level sagt „Passt nicht“, kann das High-Level das nicht ignorieren.
- Ressourceneffizienz: Um diesen Gedankengang im LLM stabil zu halten, brauchen Sie riesige Modelle und lange Prompts. HRM macht das mit einem Bruchteil der Rechenleistung, weil die Architektur (High/Low) genau dafür gebaut ist.
- Fehlerkorrektur: Wenn ein LLM sich in einer CoT-Kette verrennt, halluziniert es oft eine Begründung, um den Fehler zu rechtfertigen. HRM erhält ein negatives Feedback-Signal vom Low-Level-Netzwerk und muss einen anderen Pfad im Planungsbaum wählen.
Was wir sehen, ist „System 2“ in Aktion
In der Kognitionspsychologie beschreibt Daniel Kahneman „System 1“ als schnelles, intuitives Denken und „System 2“ als langsames, anstrengendes, logisches Denken.
- Klassische LLMs sind mächtige System-1-Maschinen. Sie haben eine unglaubliche Intuition für Sprache und Wissen.
- HRM ist der Versuch, System 2 technisch zu bauen. Es ist langsamer (im Sinne von Schritten), aber es prüft, plant und validiert.
Für Unternehmen bedeutet das: Wir müssen uns nicht mehr blind auf die „Intuition“ der KI verlassen. Wir bekommen ein System, das seine Hausaufgaben macht und uns den Rechenweg zeigt.
Wie trainiert man so etwas?
Jetzt fragen Sie sich vielleicht: „Muss ich dem Modell jede Straßenregel einzeln beibringen?“
Nein. Aber das Training unterscheidet sich deutlich vom simplen „Füttern mit Texten“. Es braucht eine spezielle Art von Daten – Demonstrationen von Lösungswegen.
Wie man solche Daten aufbereitet und ein HRM für einen eigenen Business Case trainiert, das schauen wir uns im nächsten Teil an.
Nächster Artikel: Teil 4 – HRM trainieren: Ein Business Use Case von Anfang bis Ende
Dieser Artikel ist Teil der Serie „HRM für Unternehmen“. Er veranschaulicht die abstrakte Funktionsweise des Hierarchical Reasoning Models anhand eines konkreten Beispiels.
