HRM trainieren – Ein Business Use Case von Daten bis Modell - Teil 4

Masiar Ighani
Masiar Ighani
4 min read
HRM trainieren – Ein Business Use Case von Daten bis Modell - Teil 4

Teil 4 einer Serie über das Hierarchical Reasoning Model (HRM) und seinen Einsatz im Unternehmen

„Wir brauchen Millionen von Datenpunkten.“

Das ist der Satz, der die meisten KI-Projekte in spezialisierten Unternehmensbereichen tötet, bevor sie begonnen haben. Für ein allgemeines LLM stimmt er. Aber für ein Hierarchical Reasoning Model (HRM) ist er falsch.

HRM lernt nicht durch Masse, sondern durch Struktur.

In diesem Artikel gehen wir durch einen konkreten Trainingsprozess. Wir zeigen, wie man ein HRM baut, das komplexe B2B-Rabattfreigaben automatisiert – mit weniger als 1.000 Trainingsbeispielen.

Der Paradigmenwechsel: Von „Labeling“ zu „Demonstration“

Klassisches Machine Learning braucht Labels:

Input: Kunde X, Umsatz Y, Rabatt 10% → Output: Genehmigt.

HRM braucht Demonstrationen (Reasoning Traces):

Input: Kunde X, Umsatz Y, Rabatt 10%. Gedankengang: Umsatz ist hoch (>1M), aber Marge ist aktuell unter Druck. Rabatt von 10% verletzt Margen-Regel, außer es gibt ein strategisches Cross-Selling-Potenzial. Prüfung Cross-Selling: Negativ. Output: Abgelehnt (Grund: Margenschutz).

Wir bringen dem Modell nicht bei, was es entscheiden soll, sondern wie es abwägen soll.

Schritt 1: Die Datenakquise (Expert-in-the-Loop)

Wir haben keine Millionen Datensätze. Aber wir haben Experten (in unserem Fall: Senior Sales Controller).

Statt historische Excel-Tabellen blind zu importieren, führen wir „Think Aloud“-Sessions durch.

  1. Szenario-Auswahl: Wir wählen 50 typische und 20 schwierige Grenzfälle aus.
  2. Aufzeichnung: Ein Senior Controller bearbeitet diese Fälle und spricht dabei laut aus, was er denkt.
  3. Formalisierung: Wir transkribieren nicht nur den Text, sondern strukturieren ihn in die HRM-Logik (Ziele und Aktionen).

Das Rohmaterial:

„Okay, der Kunde will 15%. Das ist viel. Normalerweise ist bei 10% Schluss. Aber ich sehe hier, dass er Neukunde im Wachstumssegment 'Cloud' ist. Da dürfen wir bis 20% gehen, wenn der Vertrag 24 Monate läuft. Ah, Laufzeit ist nur 12 Monate. Dann geht das nicht. Ich würde ihm 12% anbieten oder 15% bei Laufzeitverlängerung.“

Schritt 2: Datenaufbereitung (Hierarchische Strukturierung)

Jetzt übersetzen wir das Expertenwissen in die Sprache des Modells. Wir teilen den Monolog in High-Level-Pläne und Low-Level-Checks.

Datensatz #001:

  • High-Level Ziel: Prüfe Rabatt-Validität für Neukunde Cloud.
    • Sub-Goal 1: Prüfe Standard-Limit. (Ergebnis: 10% < 15% → Limit verletzt)
    • Sub-Goal 2: Prüfe Ausnahme „Wachstumssegment“. (Ergebnis: Segment = Cloud → Ausnahme möglich bis 20%)
    • Sub-Goal 3: Prüfe Bedingungen für Ausnahme. (Ergebnis: Bedingung „24 Monate“ nicht erfüllt)
  • High-Level Entscheidung: Ursprünglicher Antrag abgelehnt.
  • Neue Strategie: Generiere Gegenvorschlag.
    • Option A: Rabatt senken auf 12% (Kulanz).
    • Option B: Laufzeit erhöhen auf 24 Monate für 15%.

Diesen strukturierten Datensatz nennen wir eine Trajektorie. Für ein robustes Modell in einer definierten Domäne reichen oft 500 bis 1.000 solcher Trajektorien.

Schritt 3: Das Training (Imitation Learning)

Wir trainieren das Netzwerk nun in zwei Phasen:

Phase A: Behavior Cloning (Nachahmung)

Das Modell lernt, die Trajektorien der Experten exakt nachzuvollziehen.

  • Das High-Level-Netz lernt, welche Teilziele in welcher Situation gesetzt werden (z.B. „Wenn Limit verletzt, suche nach Ausnahmen“).
  • Das Low-Level-Netz lernt, wie man die konkreten Datenpunkte (Laufzeit, Segment) prüft.

Hierarchische Modelle konvergieren hier extrem schnell, da der Suchraum durch die Struktur stark eingeschränkt ist. Es muss nicht die Grammatik der deutschen Sprache lernen (wie ein LLM), sondern nur die Logik der Rabattfreigabe.

Phase B: Self-Correction (Verstärkung)

Jetzt lassen wir das Modell auf neue, synthetische Fälle los.

  • Das Modell trifft eine Entscheidung.
  • Ein Regel-Validator (oder der Experte im Review) gibt Feedback: „Falsch, du hast die Margen-Untergrenze ignoriert.“
  • Das Modell passt seine internen Gewichtungen an, um diesen Fehler künftig zu vermeiden (ähnlich wie RLHF bei ChatGPT, aber fokussiert auf Logik, nicht auf Stil).

Schritt 4: Validierung & Safety-Checks

Bevor das Modell live geht, muss es durch den „TÜV“. Da HRM eine explizite Logik ausgibt, können wir automatisierte Tests schreiben, die nicht nur das Ergebnis, sondern den Weg prüfen.

Testfall: Input: Kunde X, 25% Rabatt. Erwartung: Ablehnung. HRM Output: Ablehnung. HRM Begründung: „Rabatt > 20% ist Hard-Stop durch CFO-Richtlinie.“

Test bestanden.

Hätte das Modell „Abgelehnt“ gesagt, aber mit der Begründung „Weil der Kunde unsympathisch ist“ (Halluzination), wäre der Test durchgefallen, obwohl das Ergebnis (Ablehnung) zufällig richtig war. Das ist ein riesiger Vorteil gegenüber Black-Box-Modellen.

Der Tech-Stack: Was brauche ich dafür?

Man braucht keine NVIDIA H100 Farm.

  • Hardware: Eine solide Workstation oder eine kleine Cloud-Instanz (z.B. AWS g4dn). Das Training dauert Stunden, nicht Monate.
  • Frameworks: PyTorch oder TensorFlow als Basis. Darauf aufbauend Bibliotheken für hierarchisches Reinforcement Learning (HRL) oder spezialisierte Frameworks, wie sie Sapient nutzt.
  • Daten-Pipeline: Ein Tool, um Experten-Input effizient in strukturierte JSON/XML-Trajektorien zu wandeln (hier kann ein LLM als Assistenz-Tool helfen!).

Die ROI-Rechnung des Trainings

Lohnt sich der Aufwand, 500 Fälle manuell zu strukturieren?

Klassischer ML-Weg:

  • Datenbeschaffung: 50.000 historische Datensätze bereinigen (3 Monate).
  • Training: Iterativ, Black Box (1 Monat).
  • Ergebnis: 85% Genauigkeit, keine Erklärbarkeit.

HRM-Weg:

  • Datenbeschaffung: 5 Workshops mit Experten + Strukturierung (3 Wochen).
  • Training: Schnell und gezielt (1 Woche).
  • Ergebnis: >95% Konsistenz mit Unternehmensrichtlinien + volle Erklärbarkeit.

Für Prozesse, in denen Fehler teuer sind oder Erklärungen Pflicht sind, gewinnt der HRM-Ansatz deutlich.

Fazit: Experten klonen, nicht Daten minen

Das Training von HRM ist weniger „Big Data“ und mehr „Knowledge Engineering“. Es ist der Prozess, die Intuition Ihrer besten Mitarbeiter in eine Software-Architektur zu gießen.

Das Modell wird nicht intelligenter als Ihre Experten – aber es wird so intelligent wie Ihr bester Experte an seinem besten Tag, und das 24/7, skalierbar und ohne Ermüdung.

Im nächsten Teil: Das Modell ist trainiert. Wie bringen wir es in die IT-Landschaft? Teil 5 – HRM in Produktion: Integration, Latenz und Monitoring.

Dieser Artikel ist Teil der Serie „HRM für Unternehmen“. Er beschreibt einen prototypischen Trainingsprozess für hierarchische Modelle.