OrgGraph AI: Ein agiler Wissensgraphen ohne manuellen Code für HR-Daten.
Wie ein LLM ein Graph-Schema aus beliebigen Excel- oder CSV-Dateien erkennt, es mit dynamischem Cypher in Neo4j lädt und Personalfragen über einen LangGraph-Chat-Agenten beantwortet.
Quellen: Building a Fully Agentic Employee Knowledge Graph: **OrgGraph AI — using LangGraph & Neo4j**
Kleine Unternehmen verfügen über mehr Daten zu ihren Mitarbeitern als je zuvor, doch die Personalbesetzung erfolgt weiterhin aufgrund von Vermutungen. Die HR-Hierarchien befinden sich in Workday, die Projektzuweisungen in Jira. Fähigkeiten, Kompetenzniveaus und Zertifizierungen liegen hingegen in alten Schulungsportalen. Dann kommt ein hochprioritisches KI-Projekt, und ein Projektleiter fragt, wer im Büro in Mumbai oder Pune über fortgeschrittene Python-Kenntnisse verfügt, eine AWS-Zertifizierung hat, mit KI/Maschinellem Lernen vertraut ist, bereits an Bankprojekten gearbeitet hat und trotzdem noch Kapazitäten frei hat.
Die Beantwortung dieser Frage dauert etwa eine Woche – sofern überhaupt. Die notwendigen Informationen existieren zwar, sind aber in getrennten Systemen vergraben, die nicht in der Lage sind, Zusammenhänge zwischen den Dingen herzuleiten.
OrgGraph AI ist ein System, das entwickelt wurde, um diese Lücke zu schließen. Es nimmt rohe organisatorische Daten in beliebiger Excel- oder CSV-Form entgegen, lässt ein LLM eigenständig das Graphenschema ermitteln, lädt alles in Neo4j und beantwortet anschließend Fragen in alltäglicher Sprache. Keine Domänenspezifische Logik ist irgendwo fest codiert.
Beziehungen sind wichtiger als Datensätze
Standardmäßige HR-Tools basieren auf flachen SQL-Tabellen. Es ist für sie einfach, alle Mitarbeiter in Bangalore oder alle Personen aufzulisten, die Python kennen. Bei komplexeren Fragen, bei denen gleichzeitig mehrere Beziehungsdimensionen berücksichtigt werden müssen, stoßen sie auf Schwierigkeiten. Ein Wissensgraphus ermöglicht vier Arten der Arbeit:
- Präzise Personalplanung. Man findet die einzige Person, die über Fähigkeit A, Zertifizierung B und Standort C verfügt sowie freie Kapazitäten hat – und das in einer einzigen Abfrage statt durch vier separate Verknüpfungen.
Was „kein Hardcoding“ bedeutet
Die meisten Knowledge-Graph-Projekte teilen ein unangenehmes Geheimnis: Das Schema ist fest codiert. Ein Ingenieur liest die Tabellenkalkulation, entscheidet, dass Mitarbeiter Knoten und Fähigkeiten ebenfalls Knoten sind, wobei eine HAS_SKILL-Kante sie verbindet, schreibt für jede Entität speziellen Cypher-Code und liefert ihn aus. Danach fügt das Personalabteilung eine Certifications-Tabelle hinzu oder ändert den Namen von PrimarySkill in TechStack – daraufhin funktioniert der gesamte Prozess nicht mehr.
OrgGraph AI dreht das um. Die große Sprachmodelle entscheiden, wie das Schema aussehen sollte. Für jede tabellarische Datei führt das System folgende Schritte aus:
- Es analysiert die Daten, einschließlich der Spaltenarten, Kardinalitäten sowie möglicher Fremdschlüssel
- Es leitet auf der Grundlage der strukturierten Ausgaben der großen Sprachmodelle ein Graphenschema ab, das durch Pydantic überprüft wird
- Es erzeugt und führt dynamisch Cypher-
MERGE-Abfragen aus - Es untersucht das fertige Graphen, damit ein Chatbot darauf abfragen kann
Niemand erstellt Karten von Hand, und kein Cypher wird im Voraus geschrieben. Wenn man morgen die HR-Daten durch Logistikdaten der Lieferkette ersetzt, erzeugt derselbe Codebase ein völlig anderes Diagramm. Das Testdatenset war synthetisch, bestand aus etwa einem Dutzend Tabellenblättern, und der Pipeline verarbeitet einfach alles, was ihr gegeben wird.
Vier Phasen
Das System läuft in vier Phasen ab, die mit Python, LangChain, LangGraph, Pydantic und Neo4j gesteuert werden.
Phase 1: Profilierung der Metadaten
Bevor irgendein LLM eingesetzt wird, analysiert ein MetadataProfiler die Rohdaten lokal und erstellt einen kompakten strukturellen Fingerabdruck. Dies ist eine bewusste Entscheidung im Hinblick auf die Privatsphäre – echte Mitarbeiterdaten erreichen das Modell niemals. Es erhält Spaltennamen, Datentypen, die Anzahl der unterschiedlichen Werte pro Spalte sowie einige Beispielwerte.
Der wertvollste Trick des Profilers ist die automatische Erkennung von Fremdschlüsseln. Er markiert eine Spalte als möglichen Fremdschlüssel, wenn ihre Werte größtenteils in einer Primärschlüsselspalte an anderer Stelle enthalten sind:
# Simplified FK detection logic from profiler.py
overlap = col_values & ref_values
if len(overlap) / len(col_values) >= 0.8:
fk_candidates.append({
"source_table": tname,
"source_column": col,
"target_table": ref_table,
"target_column": ref_col,
"match_pct": round(len(overlap) / len(col_values) * 100, 1),
})
In dem HR-Datensatz zeigt sich, dass Manager_Employee_ID in der Employees-Tabelle zu mehr als 80 Prozent mit Employee_ID übereinstimmt, was auf eine selbstverweisende REPORTS_TO-Beziehung hindeutet. Der Hinweis geht an das LLM, welches aus den reinen Spaltennamen keine Hierarchie ableiten konnte.
Phase 2: Schema-Entdeckung
Das Profil wird an ein LLM übergeben, das zwischen OpenAI GPT-4o, Google Gemini und Groq konfiguriert werden kann, wobei eine Anweisung es als leitenden Graph-Datenbank-Architekten einsetzt.
Das zentrale ingenieurwissenschaftliche Problem besteht darin, dass LLMs freiformigen Text erzeugen, während Graph-Datenbanken eine strenge Struktur erfordern. LangChains with_structured_output() überbrückt diese Lücke, indem es das Modell zwingt, ein validiertes Pydantic-Objekt zurückzugeben:
# The LLM is coerced to return this exact structure
class GraphMappingModel(BaseModel):
nodes: List[NodeMapping] # What becomes a Node?
relationships: List[RelationshipMapping] # What becomes an Edge?
notes: str # LLM's reasoning notes
class NodeMapping(BaseModel):
label: str # e.g., "Employee"
source_table: str # e.g., "Employees"
primary_key_column: str # e.g., "Employee_ID"
properties: List[PropertyMapping] # All columns to map
class RelationshipMapping(BaseModel):
type: str # e.g., "HAS_SKILL"
from_node_label: str # e.g., "Employee"
to_node_label: str # e.g., "Skill"
from_key_column: str # FK column in source table
to_key_column: str # PK column of target node
properties: List[PropertyMapping] # Edge properties
Dieses GraphMappingModel dient als Vertrag für das gesamte System. Der Schema-Agent erzeugt es und der Ingestion-Engine nutzt es. Falls die Validierung fehlschlägt, wird die LLM erneut angefragt, sodass kein fehlerhaftes Schema bei Neo4j ankommt.
Phase 3: dynamische Cypher-Ingestion
Mit einem validierten Schema schreibt die Engine parametrisierte Cypher-Anweisungen direkt im Laufzeitbetrieb. Es gibt weder Vorlagen noch Switch-Anweisungen pro Entitätsart. Sie liest die Zuordnungen und erstellt MERGE- sowie SET-Anweisungen für jede Node- und Beziehungsart:
# Dynamically generated Cypher from the mapping — zero hardcoding
UNWIND $rows AS row
MERGE (n:Employee {employee_id: row.employee_id})
SET n.full_name = row.full_name,
n.designation = row.designation,
n.date_of_joining = row.date_of_joining,
n.annual_ctc_lpa = toFloat(row.annual_ctc_lpa)
Da die abgeleiteten Schema-Names Primärschlüssel sind, verwendet der Motor MERGE und nicht CREATE, wodurch der Pipeline-Prozess idempotent wird. Dreimalige Ausführung auf denselben Daten ergibt dasselbe Diagramm ohne Duplikate. Zudem werden Typen umgewandelt (toInteger(), toFloat()), NaN in None umgewandelt und Zeilen mit einem null-Primärschlüssel übersprungen.
Das Demo-Datensatz ist kein Spielzeug: 151 Mitarbeiter in 13 miteinander verbundenen Tabellen, darunter 935 Fähigkeitszuordnungen, 285 Projektzuweisungen, 107 Zertifizierungen, 313 Bewertungen und 453 Schulungseinträge, verteilt auf 10 Abteilungen und 10 globale Büros.
Phase 4: das agierende GraphRAG-Chat-System
Die Chat-Schicht ist mehr als nur ein Übersetzer von Text in Cypher. Es handelt sich um einen vierknotigen LangGraph-Zustandsautomaten mit integrierter Fehlerbehebung:
User Question
↓
┌─────────────┐
│ Planner │ → Analyzes intent, extracts entities, maps to schema
└──────┬──────┘
↓
┌─────────────┐
│ CypherGen │ → Generates Cypher query using schema + few-shot examples
└──────┬──────┘
↓
┌─────────────┐ ┌─── Error? ───→ Retry CypherGen (up to 2x)
│ Executor │ ────┤
└──────┬──────┘ └─── Success ──→
↓
┌──────────────┐
│ Synthesizer │ → Formats raw graph data into natural language
└──────────────┘
Drei Eigenschaften machen es anpassungsfähig.
Runtimeschema-Introspektion. Beim Start holt der Agent das aktuelle Schema von Neo4j ab, wobei angezeigt wird, welche Knoten- und Beziehungsarten vorhanden sind, ihre Eigenschaften sowie wie sie miteinander verbunden sind. Dieses Schema wird in jede Anfrage einbezogen, sodass der Agent niemals voraussetzen kann, was in der Datenbank enthalten ist.
Selbst generierte Few-Shot-Beispiele. Viele GraphRAG-Systeme verwenden fest codierte Cypher-Beispiele. Hier erstellt das große Sprachmodell seine eigenen Few-Shot-Beispiele auf Basis des aktuellen Schemas und von ausgewählten Daten, und diese werden automatisch neu generiert, wenn ein neuer Upload das Schema ändert.
fehlerbewusste Wiederholungsversuche. Wenn eine generierte Abfrage fehlschlägt, gelangt die Fehlermeldung zurück zum CypherGen-Knoten, der die Abfrage korrigiert und es bis zu zweimal erneut versucht. Dadurch ist der Agent besonders widerstandsfähig gegen Syntaxprobleme in Randfällen.
Unternehmensbezogene Aspekte
Privatsphäre. Das LLM erkennt Strukturen, nicht Personen. Nur Spaltennamen, Typen und Kardinalitäten verlassen den Profiler, während die personenbezogenen Daten auf Ihrem Server bleiben.
Flexibilität des Anbieters. Mithilfe des LLM Factory-Musters lässt sich zwischen OpenAI, Gemini und Groq durch Änderung einer Umgebungsvariable wechseln:
# .env: LLM_PROVIDER=gemini | openai | groq
llm = get_llm() # Returns the configured ChatModel
Keine Codeänderungen und kein Vendor Lock-in.
Unordentliche Daten. Unternehmens-Tabellenkalkulationen sind niemals sauber. Der Eingabemechanismus kommt mit überflüssigem Leerzeichen, gemischten Datumsformaten, unerwarteten NaN-Werten sowie leeren Primärschlüsseln zurecht, indem er problematische Zeilen überspringt oder umwandelt, anstatt abzustürzen.
Von der Hochladen bis zu den Ergebnissen
Die Benutzeroberfläche ist ein Streamlit-Dashboard. Der Nutzer lädt eine Excel- oder CSV-Datei über die Seitenleiste hoch und verfolgt in Echtzeit den Ablauf des Pipelines: Profilierung, Schema-Erkennung, Eingabe sowie anschließende Initialisierung des Agents. Danach kann er einfach chatten.
Eine separate Demo verwendet Vis.js für die grafikbasierte Darstellung unter Berücksichtigung physikalischer Gesetze sowie GSAP für animationsgesteuerte Effekte beim Scrollen. Die Knoten werden schrittweise mit Schwerkraft- und Abstoßungskräften angezeigt. Durch Klicken auf einen Knoten öffnet sich ein Panel mit seinen Eigenschaften sowie den damit verbundenen Beziehungen. Ein simulierter Chat zeigt sowohl die Antwort in natürlicher Sprache als auch die dahinter generierte Cypher-Abfrage.
Jenseits von HR
Die Architektur ist nicht auf Personalwesen beschränkt. Derselbe Code könnte ein Wissensgraph für die Verwaltung von IT-Ressourcen erstellen, in dem Server, Anwendungen, Teams und Abhängigkeiten dargestellt werden. Er könnte auch Lieferanten, Materialien, Lager und Logistikwege in einer Lieferkette verfolgen oder Forscher, wissenschaftliche Arbeiten, Institutionen und Finanzierungsquellen in einem Forschungsnetzwerk vernetzen.
Datenpipelines, die sich an die Daten anpassen, anstatt dass Ingenieure die Daten in starre Schemata zwingen, sind der Weg, den agentbasierte Architekturen einschlagen – und dieses Projekt ist ein Entwurf dafür.