OrgForge: A Multi-Agent Simulation Framework for Verifiable Synthetic Corporate Corpora

Das Open-Source-Framework OrgForge nutzt eine Multi-Agenten-Simulation mit einer deterministischen Ereignis-Grundwahrheit, um verifizierbare, zeitlich konsistente und rechtlich unbedenkliche synthetische Unternehmensdaten für die Evaluierung von RAG-Pipelines zu generieren.

Das Wesentliche

Das große Problem: Der Lügen-Generator

Stell dir vor, du möchtest testen, wie gut ein neuer, super-intelligenter Roboter (eine KI) ist, der Firmendokumente lesen und Fragen dazu beantworten soll. Dazu brauchst du einen riesigen Haufen an Papieren: E-Mails, Chat-Nachrichten, Fehlerberichte und Meeting-Protokolle.

Das Problem ist: Echte Firmendaten sind schwer zu bekommen (zu viele Geheimnisse, zu viel Chaos).
Die Lösung, die viele bisher versucht haben, war: „Lass eine KI einfach alles erfinden!"

Aber das ist wie ein Koch, der ein Rezept erfindet, ohne die Zutaten zu kennen. Die KI schreibt einen Chat-Nachricht: „Der Server ist seit 3 Uhr morgens down." Aber in einem anderen Dokument, das sie gleichzeitig erfindet, steht: „Der Server fiel um 9 Uhr aus."*
Für den Roboter, der das liest, ist das ein Albtraum. Er weiß nicht, was wahr ist. Die KI hat sich selbst widersprochen, weil sie keine „Wahrheits-Instanz" hat.

Die Lösung: OrgForge – Die „Fakten-Fabrik"

Jeffrey Flynt hat OrgForge gebaut. Stell dir das nicht als einen Text-Generator vor, sondern als eine kleine, simulierte Welt, die wie ein Videospiel funktioniert.

Hier ist das Geniale daran: Die Fakten und die Geschichte werden strikt getrennt.

1. Der Dirigent und die Musiker (Die Architektur)

Stell dir ein Orchester vor:

• Der Dirigent (Die Python-Engine): Er hält das Taktstock. Er weiß genau, wer wann was macht. Er entscheidet: „Um 10:00 Uhr fällt der Server aus. Herr Müller ist gerade im Urlaub. Frau Schmidt ist gestresst." Der Dirigent schreibt diese Fakten in ein unveränderliches Logbuch (die „SimEvent"-Datenbank). Das ist die absolute Wahrheit.
• Die Musiker (Die KI-Modelle): Sie dürfen nur spielen, was der Dirigent ihnen sagt. Sie schreiben die Worte für die E-Mails und Chats. Sie dürfen aber niemals entscheiden, ob der Server ausfällt oder nicht. Wenn der Dirigent sagt „Server aus", schreibt die KI einen Text darüber, aber sie darf nicht plötzlich schreiben „Nein, der Server läuft".

Der Vorteil: Da der Dirigent die Fakten kontrolliert, kann die KI sich nie widersprechen. Die Geschichte ist immer logisch.

2. Der Stress-Wellen-Effekt (Die Graph-Dynamik)

In einer echten Firma breitet sich Stress aus. Wenn der Chef gestresst ist, wird er vielleicht unfreundlich, und das stresst seine Mitarbeiter.
OrgForge simuliert das wie eine Welle in einem Teich:

• Es gibt eine Karte, wer mit wem befreundet ist (wer oft mit wem spricht).
• Wenn ein großer Fehler passiert, steigt der Stress bei den direkt Beteiligten.
• Dieser Stress „fließt" wie Wasser durch die Freundschafts-Verbindungen zu den Kollegen weiter.
• Wenn jemand zu viel Stress hat, wird er „ausgebrannt" und kann weniger arbeiten.
• Wichtig: Das passiert automatisch nach mathematischen Regeln, nicht weil die KI das „fühlt". Es ist wie ein physikalisches Gesetz in der Simulation.

3. Die Zeitreise-Verhinderung (Die Uhr)

Ein häufiger Fehler bei KI-generierten Geschichten ist, dass die Zeit durcheinandergerät. Eine Antwort auf eine E-Mail kommt vor der E-Mail selbst an.
OrgForge nutzt eine persönliche Uhr für jeden Mitarbeiter.

• Wenn Herr Müller eine E-Mail schreibt, bewegt sich seine Uhr vorwärts.
• Wenn Frau Schmidt antwortet, muss ihre Uhr nach Herr Müllers Uhr stehen.
• Das System sorgt dafür, dass die Zeit immer logisch fließt. Man kann die Geschichte wie einen Film rückwärts abspielen, und alles ergibt Sinn.

4. Der Lärm im Büro (Soziale Unterbrechungen)

Echte Arbeitsplätze sind nicht nur reine Arbeit. Man redet über das Mittagessen, man verliert sich in kleinen Chats.
OrgForge fügt absichtlich „Büro-Lärm" hinzu.

• Manchmal wird ein Mitarbeiter von einer belanglosen Slack-Nachricht abgelenkt.
• Das kostet Zeit.
• Das ist wichtig, um zu testen, ob der KI-Roboter lernen kann, zwischen wichtigen Informationen (Fehler im System) und lärmenden Informationen (Essenspläne) zu unterscheiden.

Wozu dient das alles?

OrgForge erzeugt einen riesigen Haufen an simulierten Firmendokumenten (Chats, Tickets, E-Mails), die perfekt logisch und faktenbasiert sind.

Mit diesen Daten können Forscher testen:

1. Findet der KI-Roboter die richtige Antwort, wenn er durch den Chaos der Chats sucht?
2. Versteht er, dass ein Fehler um 10 Uhr passiert ist, aber erst um 11 Uhr gemeldet wurde?
3. Erkennt er, wenn eine E-Mail einfach ignoriert wurde (ein „loches" in der Kommunikation)?

Das Fazit in einem Satz

OrgForge ist wie ein Simulator für eine Firma, bei dem ein strenger Computer-Regisseur die Fakten festlegt und eine KI nur die Dialoge schreibt – so entsteht eine perfekte, widerspruchsfreie Welt, um zu testen, ob andere KIs wirklich schlau sind oder nur raten.

Es ist der erste Schritt, um KI-Systeme nicht nur mit „schönen Worten", sondern mit überprüfbarer Wahrheit zu trainieren und zu testen.

Technische Zusammenfassung

1. Problemstellung

Die Evaluation von Retrieval-Augmented Generation (RAG)-Systemen im Unternehmenskontext leidet unter einem Mangel an geeigneten Testdaten. Bestehende Ressourcen wie das Enron-Korpus weisen rechtliche Unsicherheiten, demografische Verzerrungen und keine strukturierte „Ground Truth" (Wahrheitsgrundlage) auf. Reine synthetische Daten, die von Large Language Models (LLMs) generiert werden, lösen zwar das Rechtsproblem, führen jedoch zu einem subtileren, aber kritischen Fehler: LLMs neigen dazu, Fakten zu halluzinieren, die sich über verschiedene Dokumente hinweg widersprechen (z. B. ein Slack-Thread, der einen Incident um 3 Uhr morgens datiert, während ein JIRA-Ticket denselben Incident auf 9 Uhr legt). Ohne eine externe, verifizierbare Wahrheit sind solche Korpora für eine zuverlässige RAG-Evaluation unbrauchbar, da Inkonsistenzen die Bewertungsergebnisse verfälschen.

2. Methodik: OrgForge-Architektur

OrgForge ist ein Open-Source-Framework zur Simulation von Unternehmensprozessen, das eine strikte Trennung zwischen Faktenkontrolle und Textgenerierung vornimmt. Die Architektur wird als Tupel $M = (S, P, V, E)$ formalisiert:

• S (State): Ein deterministischer Python-Engine-Zustand, der alle veränderbaren Variablen verwaltet (Systemgesundheit, Team-Moral, Stresslevel, offene Tickets).
• P (Planners): LLM-basierte Agenten, die nur Vorschläge für Aktivitäten machen (Prose-Generierung), aber keine Fakten direkt manipulieren dürfen.
• V (Validator): Eine deterministische Funktion, die alle LLM-Vorschläge gegen den aktuellen Zustand $S$ und die Historie $E$ prüft. Nur validierte Ereignisse werden ausgeführt.
• E (Events): Ein unveränderlicher, append-only „SimEvent"-Log, der als einzige Quelle der Wahrheit (Ground Truth Bus) dient.

Schlüsselmechanismen:

• SimEvent-Bus: Jedes signifikante Ereignis erzeugt einen strukturierten Datensatz, der als Referenz für alle generierten Texte (Slack, JIRA, E-Mails, Git) dient.
• Graph-Dynamik: Drei deterministische Mechanismen steuern das Organisationsverhalten unabhängig von LLMs:
  1. Stress-Propagation: Über Betweenness-Zentralität werden Stresslevel von „Key Players" auf Kollegen verteilt.
  2. Temporale Kantengewicht-Decay: Beziehungen stärken sich durch Interaktion und schwächen sich ohne Kontakt ab.
  3. Dijkstra-Eskalation: Eskalationspfade werden als kürzeste Wege im inversen Gewichtsgraphen berechnet, um realistische Kommunikationspfade zu simulieren.
• Actor-Local Clock: Ein eigener Zeitcursor für jeden Akteur garantiert kausale Konsistenz der Zeitstempel über alle Artefakttypen hinweg und verhindert zeitliche Paradoxa.
• Soziale Unterbrechungen: Ein Modell für „benigne Rauschen" (z. B. Smalltalk), das die Kapazität der Agenten realistisch reduziert und Evaluationssysteme vor dem blinden Vertrauen in reine Aufgabenorientierung warnt.
• Externe E-Mail-Engine: Simuliert eingehende Vendor-Warnungen und Kundenbeschwerden sowie ausgehende HR-Korrespondenz, inklusive probabilistischem „Drop" (Verlust von Nachrichten), um Lücken in der Kommunikation zu testen.

3. Wichtige Beiträge

Das Paper stellt folgende wesentliche Beiträge vor:

• Architektonische Trennung: Ein Framework, das LLM-Halluzinationen durch eine Validierungsschicht eliminiert, bevor Texte generiert werden.
• Formalisierte Graph-Dynamik: Deterministische Regeln für Stress, Beziehungspflege und Eskalation, die das Organisationsverhalten steuern.
• Kausale Nachverfolgbarkeit: Ein Subsystem (CausalChainHandler), das Artefakte pro Incident chronologisch verknüpft und eine hybride Reciprocal-Rank-Fusion (RRF) zur Erkennung wiederkehrender Fehlerklassen nutzt.
• Umfassende Evaluations-Pipeline: Ein Toolset (eval_harness.py, scorer.py), das acht Fragekategorien generiert (Recherche, Kausalität, Zeitlichkeit, Lückenerkennung, Routing, Planung, Eskalation, Wissenslücken) und Antworten mit partieller Punktzahl bewertet.
• Reproduzierbarkeit: Das System ist konfigurierbar (Organigramm, Personas, Trigger) und erzeugt bei festem Seed identische Korpora.

4. Ergebnisse

Eine Simulation über 22 Arbeitstage (43 Personen, 8 Abteilungen) generierte ein Korpus mit 1.079 Dokumenten und 83 Evaluierungsfragen.

• Kosten: Die Simulation kostete ca. 285 USD an LLM-Kosten (Input/Output Tokens).
• Retrieval-Benchmarks:
  • BM25 (Keyword-basiert): Erzielte insgesamt bessere Ergebnisse (MRR@10: 0,28) als dichte Suche. Besonders stark bei Kausalitätsfragen (0,54), da Post-Mortem-Dokumente spezifische Terminologie enthalten.
  • Dense Retrieval (Embeddings): Performte schlechter (MRR@10: 0,20). Dies deutet darauf hin, dass allgemeine Embedding-Modelle (1.5B Parameter) Schwierigkeiten haben, die strukturierte Unternehmensvokabel von OrgForge zu erfassen.
  • Schwächen: Beide Methoden scheiterten bei Planungs- und Eskalationsfragen (Score 0,0), da diese mehrstufiges logisches Schlussfolgern erfordern, das über reine Textähnlichkeit hinausgeht.
  • Zeitliche Fragen: Zeigten ebenfalls sehr niedrige Scores, was bestätigt, dass zeitliches Reasoning eine große Herausforderung für aktuelle RAG-Systeme bleibt.

5. Bedeutung und Ausblick

OrgForge adressiert eine kritische Lücke in der RAG-Forschung, indem es erstmals synthetische Unternehmensdaten mit verifizierbarer Ground Truth und kausaler Konsistenz bereitstellt. Es ermöglicht die Bewertung von Systemen unter realistischen Bedingungen, einschließlich zeitlicher Dynamik, cross-artifakter Verknüpfungen und kommunikativer Lücken.

Die Ergebnisse zeigen, dass aktuelle Retrieval-Methoden (sowohl keyword-basiert als auch dichte Suche) bei komplexen, mehrstufigen Unternehmensszenarien an ihre Grenzen stoßen. OrgForge bietet somit nicht nur ein Testkorpus, sondern einen Benchmark, der die Entwicklung von Agenten-Systemen vorantreiben kann, die über einfaches Suchen hinausgehen und kausale sowie zeitliche Zusammenhänge verstehen müssen. Zukünftige Arbeiten sollen End-to-End-Evaluationen von RAG-Agenten und Simulationen über mehrere Organisationen hinweg umfassen.