Context Engineering: Prompt und Graph Engineering verbinden

Prompt Engineering steuert, wie eine Aufgabe an ein Sprachmodell formuliert wird; Context Engineering entscheidet, welche Informationen, Werkzeuge und Zustände das Modell im richtigen Moment erhält. Graph Engineering ergänzt Beziehungen und Ablaufstrukturen. Zusammen bilden die drei Disziplinen eine belastbare Grundlage für KI-Assistenten und Agenten, die im Mittelstand nicht nur antworten, sondern Geschäftsprozesse nachvollziehbar bearbeiten.

Warum reicht gutes Prompt Engineering für Unternehmens-KI nicht mehr aus?

Noch vor wenigen Jahren ließ sich ein großer Teil der praktischen Arbeit mit Large Language Models auf eine Frage reduzieren: Wie muss eine Anweisung formuliert sein, damit das Modell möglichst brauchbare Ergebnisse erzeugt? Daraus entstand Prompt Engineering. Rollenbeschreibungen, Beispiele, Ausgabeformate, System Prompts, Few-Shot-Beispiele und strukturierte Instruktionen wurden zu wichtigen Werkzeugen.

Das bleibt relevant. Ein schlecht formulierter Auftrag wird nicht automatisch gut, nur weil im Hintergrund eine aufwendige technische Architektur arbeitet. Für eine isolierte Aufgabe wie „Fasse diesen Text für die Geschäftsführung zusammen“ kann ein guter Prompt sogar einen erheblichen Teil der Lösung ausmachen.

Unternehmensanwendungen funktionieren jedoch anders. Ein Vertriebsassistent soll nicht nur einen guten Text schreiben. Er muss wissen, welcher Kunde gemeint ist, welche Angebote aktuell sind, welche Konditionen gelten, welche Produkte zusammenpassen, welche Informationen vertraulich sind und was bereits mit dem Kunden vereinbart wurde. Ein Serviceagent benötigt möglicherweise Maschinenakte, Wartungsvertrag, Ersatzteilinformationen, frühere Störungen, Zuständigkeiten und aktuelle Einsatzdaten.

Damit verschiebt sich die Entwicklungsaufgabe. Entscheidend ist nicht mehr nur, was man dem Modell sagt, sondern was das Modell für genau diesen Arbeitsschritt wissen und verwenden darf.

Genau an dieser Stelle beginnt Context Engineering.

Wie hängen Prompt Engineering, Context Engineering und Graph Engineering zusammen?

Die drei Begriffe beschreiben unterschiedliche Ebenen desselben KI-Systems.

Prompt Engineering gestaltet die Anweisung. Es legt Aufgabe, Ziel, Regeln, Sprache, Format und gegebenenfalls Beispiele fest.

Context Engineering gestaltet die Informationsumgebung des Modells. Dazu gehören beispielsweise Dokumente aus einem RAG-System, CRM-Daten, Datenbankabfragen, Gesprächsverlauf, Benutzerrechte, Ergebnisse vorheriger Arbeitsschritte, Toolbeschreibungen, gespeicherte Notizen und temporärer Agentenzustand.

Graph Engineering geht einen Schritt weiter. Es modelliert Beziehungen zwischen Informationen oder strukturiert den Ablauf eines mehrstufigen KI-Prozesses als Graph aus Knoten und Verbindungen.

Das lässt sich vereinfacht so formulieren: Der Prompt beschreibt die Aufgabe. Der Kontext liefert die für diesen Moment benötigte Arbeitsgrundlage. Der Graph beschreibt Beziehungen und mögliche Wege durch Wissen oder Prozess.

Damit entsteht aus einem einzelnen LLM-Aufruf schrittweise ein Softwaresystem.

Was wird beim Context Engineering tatsächlich entwickelt?

Context Engineering bedeutet nicht, möglichst viele Daten in ein großes Kontextfenster zu laden. Genau dieser Ansatz verursacht in realen Anwendungen häufig Probleme.

Ein KI-System kann beispielsweise Zugriff auf zehntausende Dokumente besitzen. Für die Bearbeitung einer bestimmten Kundenreklamation sind davon vielleicht nur der Auftrag, die Produktspezifikation, eine E-Mail, zwei Servicetickets und die aktuelle Gewährleistungsregel relevant. Werden stattdessen umfangreiche Datenbestände wahllos in den Kontext geschrieben, steigen Tokenverbrauch und Laufzeit, während widersprüchliche oder nebensächliche Informationen die Antwort beeinflussen können.

Context Engineering beschäftigt sich deshalb unter anderem mit Retrieval, Chunking, Ranking, Metadaten, Benutzerrechten, Conversation State, Memory, Tool-Ergebnissen, Kontextkomprimierung und der Frage, wann bestimmte Informationen überhaupt geladen werden.

Interessant ist ein veröffentlichtes Experiment zu sogenanntem Contextual Retrieval. Durch zusätzliche Kontextinformationen an Dokumentabschnitten sank dort die Fehlerrate beim Auffinden relevanter Inhalte innerhalb der Top-20-Ergebnisse um 35 Prozent. Das zeigt, dass nicht allein die Größe des Datenbestands entscheidend ist, sondern seine Aufbereitung für die spätere Suche.

Für einen Mittelständler bedeutet das beispielsweise: Ein technischer Assistent sollte nicht das komplette Handbuch, sämtliche Serviceakten und das gesamte ERP-Exportfile gleichzeitig erhalten. Er sollte zur konkreten Seriennummer die passenden technischen Unterlagen, den aktuellen Gerätestatus und die für diesen Kunden geltenden Vertragsinformationen finden.

Das ist Context Engineering in der Praxis.

Warum ist ein größeres Kontextfenster nicht automatisch die bessere Lösung?

Moderne Modelle können sehr große Informationsmengen verarbeiten. Daraus lässt sich jedoch nicht ableiten, dass jede verfügbare Information dauerhaft in das Kontextfenster gehört.

Mit wachsendem Kontext konkurrieren relevante und weniger relevante Informationen miteinander. Bei langen Agentenabläufen kommen zudem neue Daten hinzu: Tool-Aufrufe, Zwischenergebnisse, Rückfragen, Suchresultate, Planänderungen und Fehlermeldungen.

Eine sinnvolle Architektur behandelt Kontext deshalb eher wie Arbeitsspeicher als wie ein Archiv.

Dauerhaftes Unternehmenswissen liegt beispielsweise in Dokumentenspeichern, relationalen Datenbanken, Vektordatenbanken oder Knowledge Graphs. Der Agent erhält nur den Ausschnitt, den er für den nächsten Schritt benötigt. Später können andere Informationen nachgeladen werden.

Dieser Ansatz wird besonders wichtig, sobald ein Agent über viele Arbeitsschritte hinweg tätig ist. Das System muss dann entscheiden, was behalten, verdichtet, erneut abgerufen oder verworfen wird.

Die wirtschaftliche Seite verändert sich gleichzeitig erheblich. Der AI Index von Stanford HAI https://hai.stanford.edu/ai-index/2025-ai-index-report/research-and-development dokumentierte für Modelle auf einem vergleichbaren Leistungsniveau innerhalb eines untersuchten Zeitraums einen Rückgang der Inferenzkosten um mehr als das 280-Fache. Dadurch werden umfangreichere KI-Prozesse wirtschaftlich interessanter. Trotzdem bleibt unnötiger Kontext unnötiger Rechenaufwand.

Welche zwei Bedeutungen hat Graph Engineering bei heutigen KI-Systemen?

Hier lohnt sich eine begriffliche Trennung, weil „Graph Engineering“ derzeit nicht so einheitlich verwendet wird wie Prompt Engineering.

Die etablierte Bedeutung ist Knowledge Graph Engineering. Dabei werden Entitäten, Eigenschaften und Beziehungen modelliert. Ein Maschinenbauer könnte beispielsweise Maschinen, Baugruppen, Seriennummern, Kunden, Standorte, Wartungsvorgänge und Ersatzteile als Knoten abbilden. Verbindungen beschreiben dann Beziehungen wie „ist verbaut in“, „gehört zu“, „steht an Standort“, „wurde ersetzt durch“ oder „benötigt Qualifikation“.

Knowledge Graph Engineering ist keine erst mit generativer KI entstandene Disziplin. Auch wissenschaftliche Arbeiten behandeln seit Jahren Modellierung, Ontologien, Datenintegration, Regeln und Pflege solcher Wissensgraphen.

Daneben etabliert sich im Agentenumfeld eine zweite Verwendung: Graph Engineering als Gestaltung eines Ausführungsgraphen.

Hier repräsentieren die Knoten keine Maschinen oder Kunden, sondern Arbeitsschritte, Agenten, Funktionen oder Prüfungen. Die Verbindungen bestimmen, welcher Schritt als Nächstes ausgeführt wird. Aktuelle Agenten-Frameworks modellieren solche Prozesse ausdrücklich als gerichtete Graphen aus Executoren und Edges, einschließlich Verzweigungen, Parallelisierung, Checkpoints und Human-in-the-Loop.

Für Unternehmensanwendungen sind beide Varianten interessant. Ein Knowledge Graph beschreibt, wie Wissen zusammenhängt. Ein Workflow Graph beschreibt, wie Arbeit zusammenhängt.

Wie unterscheiden sich Prompt, Context und Graph Engineering in der Praxis?

In produktiven Systemen treten die Ebenen selten isoliert auf. Ein Graphknoten kann beispielsweise einen eigenen Prompt besitzen, vom Context Layer genau definierte Informationen erhalten und sein Ergebnis anschließend an einen anderen Graphknoten weitergeben.

Wie sieht das Zusammenspiel bei einem Servicefall konkret aus?

Angenommen, ein mittelständischer Maschinenhersteller möchte eingehende Serviceanfragen mit KI unterstützen.

Eine E-Mail lautet: „Die Anlage stoppt seit gestern nach einigen Minuten mit Fehler 471. Können Sie prüfen, was wir tun sollen?“

Prompt Engineering definiert zunächst die Aufgabe des Serviceassistenten: Problem erfassen, keine nicht belegten technischen Anweisungen erfinden, benötigte Informationen identifizieren, relevante Quellen berücksichtigen und einen geeigneten nächsten Schritt vorschlagen.

Context Engineering ermittelt anschließend, welche Daten erforderlich sind. Über Absender, Kundennummer oder Seriennummer können CRM, Maschinenakte, Wartungshistorie, Servicevertrag, technische Dokumentation und bekannte Fehlermeldungen eingebunden werden. Entscheidend ist, dass nicht irgendeine Version des Handbuchs geladen wird, sondern die zur ausgelieferten Maschinenkonfiguration passende.

Ein Knowledge Graph könnte zusätzlich abbilden, dass genau diese Maschine eine bestimmte Steuerungsversion besitzt, diese Steuerung mit einer bestimmten Baugruppe verbunden ist und Fehler 471 bei dieser Version auf einen definierten Prüfpfad verweist.

Ein Ausführungsgraph kann daraus einen Prozess machen:

Anfrage analysieren → Maschine identifizieren → Vertragsstatus prüfen → relevante technische Informationen abrufen → Risikoklasse bestimmen → Antwortvorschlag erzeugen → bei sicherheitsrelevanten Fällen Servicetechniker einbeziehen → Vorgang dokumentieren.

Nicht jeder Knoten benötigt ein Sprachmodell. Vertragsstatus und Berechtigungen lassen sich beispielsweise deterministisch prüfen. Genau darin liegt eine wichtige Stärke graphbasierter Architekturen: KI wird dort eingesetzt, wo Interpretation notwendig ist; normale Software übernimmt Schritte, bei denen Regeln ausreichen.

Wie unterstützt GraphRAG Fragen, die mit normalem RAG schwierig werden?

Klassisches Retrieval-Augmented Generation arbeitet häufig mit Embeddings und Vektorsuche. Eine Frage wird in einen Vektor übersetzt, anschließend sucht das System semantisch ähnliche Textabschnitte.

Das funktioniert hervorragend für viele Aufgaben. Wer nach den Rückgabebedingungen eines Produkts fragt, benötigt möglicherweise lediglich den richtigen Abschnitt aus einer Richtlinie.

Schwieriger wird es bei Fragen wie:

„Welche Kunden könnten von dem Bauteil betroffen sein, das von Lieferant X geliefert, in Produktreihe Y verbaut und während Zeitraum Z produziert wurde?“

Hier reicht semantische Ähnlichkeit allein möglicherweise nicht aus. Die Antwort entsteht aus einer Kette von Beziehungen.

GraphRAG verbindet Retrieval deshalb mit Graphstrukturen. Entitäten und Relationen können traversiert werden, bevor die gefundenen Informationen in den Kontext des Modells gelangen. Das ist besonders interessant für Lieferketten, Produktionsstrukturen, Berechtigungen, IT-Abhängigkeiten, Vertragsbeziehungen, Produktkonfigurationen und Customer-360-Szenarien.

Dass GraphRAG dabei nicht zwangsläufig teurer sein muss, zeigt eine Untersuchung einer dynamischen GraphRAG-Suche: Dort konnte bei vergleichbarer Antwortqualität der Tokenaufwand gegenüber der untersuchten statischen Variante um 77 Prozent reduziert werden. Das ist kein allgemeiner Leistungswert für jede GraphRAG-Implementierung, zeigt aber, wie stark Retrievalstrategie und Graphstruktur die Wirtschaftlichkeit beeinflussen können.

Wann ist Graph Engineering unnötige Komplexität?

Nicht jedes Unternehmenswissen braucht einen Knowledge Graph und nicht jeder Prozess einen Agent Graph.

Wenn ein Unternehmen einen Assistenten benötigt, der aus einer überschaubaren Dokumentensammlung Fragen beantwortet, kann ein gutes RAG-System vollkommen ausreichen. Werden aus wenigen strukturierten Daten regelmäßig Berichte erstellt, reicht möglicherweise sogar ein normaler Datenbankzugriff mit einem gut definierten Prompt.

Graphstrukturen werden interessanter, wenn Beziehungen selbst Teil der Fragestellung sind.

Typische Hinweise sind mehrstufige Abhängigkeiten, viele miteinander verbundene Entitäten, unterschiedliche Zuständigkeiten, Versionsbeziehungen, zeitliche Veränderungen oder Fragen, bei denen mehrere Informationsquellen miteinander verbunden werden müssen.

Auch aktuelle Untersuchungen zu GraphRAG sprechen gegen die pauschale Annahme, ein Graph liefere grundsätzlich bessere Ergebnisse als klassisches RAG. Je nach Aufgabe können einfachere Retrieval-Verfahren gleichwertig oder überlegen sein.

Eine gute Architektur beginnt deshalb nicht bei der Technologie, sondern bei der Informations- und Prozessstruktur des konkreten Anwendungsfalls.

Welche Rolle spielt Graph Engineering bei KI-Agenten?

Ein Chatbot beantwortet Fragen. Ein Agent kann darüber hinaus Werkzeuge verwenden, Informationen suchen, Entscheidungen vorbereiten und über mehrere Schritte hinweg arbeiten.

Sobald daraus ein produktiver Geschäftsprozess wird, reicht die Anweisung „Löse die Aufgabe selbstständig“ häufig nicht aus.

Stellen wir uns einen Agenten für Angebotsanfragen vor. Er soll eine Anfrage lesen, Kundendaten prüfen, Produktinformationen abrufen, Lieferfähigkeit feststellen, einen Preisvorschlag berechnen, Besonderheiten markieren und einen Angebotsentwurf erstellen.

Ein vollständig freier Agent könnte diese Schritte jedes Mal anders durchführen. Für manche Aufgaben ist das erwünscht. Bei wiederkehrenden Unternehmensprozessen möchte man jedoch häufig bestimmte Übergänge und Kontrollpunkte vorgeben.

Ein Graph kann beispielsweise festlegen, dass ein Preisvorschlag erst nach erfolgreicher Produkt- und Kundenprüfung erstellt wird. Bei Überschreitung eines Rabattlimits führt eine Edge nicht direkt zur Angebotserstellung, sondern zu einer Freigabe. Nach der Freigabe setzt der Prozess an der richtigen Stelle fort.

Damit wird Graph Engineering zu einer Verbindung aus KI-Orchestrierung und klassischem Workflow Engineering.

Warum werden mehrere spezialisierte Agenten interessant?

Bei umfangreichen Aufgaben kann es sinnvoll sein, Arbeit auf mehrere Agenten mit getrennten Kontexten zu verteilen. Einer recherchiert, ein anderer analysiert Daten, ein weiterer prüft Ergebnisse und ein übergeordneter Agent führt sie zusammen.

Ein veröffentlichtes Experiment mit einem Multi-Agent-Research-System erreichte gegenüber dem dort verglichenen Single-Agent-System eine um 90,2 Prozent bessere Leistung in der internen Research-Evaluation. Das Ergebnis lässt sich nicht auf beliebige Unternehmensprozesse übertragen, zeigt aber, weshalb spezialisierte Agenten bei stark parallelisierbaren Aufgaben interessant sind.

Der Preis dafür ist zusätzliche Komplexität. Mehr Agenten bedeuten mehr Zustände, mehr Tool-Aufrufe, mehr Übergaben, mehr Fehlerpfade und höhere Betriebskosten.

Graph Engineering ist deshalb nicht das Ziel einer KI-Architektur, sondern eine mögliche Antwort auf Prozesse, deren Struktur diese zusätzliche Ebene rechtfertigt.

Was läuft bei solchen KI-Projekten in der Praxis häufig falsch?

Ein verbreiteter Fehler beginnt mit dem Prompt. Teams versuchen, immer mehr Regeln, Hintergrundinformationen, Sonderfälle und Prozesswissen in einen einzigen System Prompt zu schreiben. Der Prompt entwickelt sich zu einem schwer wartbaren Ersatz für Datenmodell, Regelwerk und Workflow.

Der zweite Fehler besteht darin, Context Engineering mit „mehr Kontext“ gleichzusetzen. Ganze Dokumentbestände werden in eine Vektordatenbank geladen, ohne Dokumenttypen, Versionen, Gültigkeitszeiträume, Kundenbezug oder Zugriffsrechte ausreichend zu modellieren. Die Suche findet dann semantisch passende Informationen, aber nicht zwingend die fachlich richtige Information.

Ein dritter Fehler entsteht beim Graph Engineering: Ein technisch beeindruckender Knowledge Graph wird aufgebaut, obwohl die tatsächlichen Fragen lediglich Dokumentensuche erfordern. Der Aufwand für Ontologie, Entity Resolution, Datenpflege und Aktualisierung steht dann in keinem Verhältnis zum Nutzen.

Das Gegenteil kommt ebenfalls vor. Ein Unternehmen besitzt hochgradig vernetzte Informationen, behandelt sie aber ausschließlich als Textabschnitte. Beziehungen wie „Teil gehört zu Maschine“, „Maschine gehört zu Kunde“, „Version löst Version ab“ oder „Mitarbeiter besitzt Qualifikation“ gehen bei rein semantischer Suche nur indirekt ein.

Die vierte Problemklasse betrifft Agenten. Zu viel Autonomie wird zu früh zugelassen. Für definierte Geschäftsregeln, Preisgrenzen, Freigaben, Berechtigungen oder sicherheitsrelevante Schritte sind deterministische Prüfungen meist sinnvoller als eine freie Modellentscheidung.

Wie könnte eine robuste Architektur für einen mittelständischen KI-Assistenten aussehen?

Eine pragmatische Architektur beginnt mit vorhandenen Datenquellen. Dazu können ERP, CRM, Dokumentenmanagement, SharePoint, E-Mail, Ticketsystem, Produktdatenbank und operative Fachanwendungen gehören.

Darüber liegt eine Zugriffsschicht, die Benutzerrechte und Mandantenbezug berücksichtigt.

Für unstrukturierte Inhalte entsteht eine Retrieval-Schicht mit Dokumentaufbereitung, Chunking, Metadaten, Embeddings, Suche und gegebenenfalls Re-Ranking. Strukturierte Geschäftsdaten werden häufig direkt aus Datenbanken oder APIs geladen.

Falls Beziehungen für den Anwendungsfall wichtig sind, ergänzt ein Knowledge Graph diese Ebene.

Darüber arbeitet der Context Layer. Er entscheidet zur Laufzeit, welche Information aus welchem System in den nächsten Modellaufruf gelangt.

Der Prompt Layer bestimmt Rolle, Aufgabe, Regeln und Ausgabeformat des jeweiligen Verarbeitungsschritts.

Bei einfachen Anwendungen endet die Architektur hier. Bei längeren Prozessen kann darüber ein Workflow- oder Agent Graph liegen, der Verarbeitungsschritte, Verzweigungen, Fehlerwege, Freigaben und Zustände koordiniert.

So entsteht kein einzelner „Super-Prompt“, sondern eine Architektur aus spezialisierten Bausteinen.

Wie beginnt ein Mittelständler sinnvoll mit Prompt, Context und Graph Engineering?

Der sinnvollste Startpunkt ist ein konkreter Geschäftsfall mit messbarem Ergebnis.

Ein Unternehmen könnte beispielsweise mit der Bearbeitung technischer Kundenanfragen beginnen. Zunächst wird festgelegt, welche Antwort oder Entscheidung unterstützt werden soll. Danach wird untersucht, welche Informationen ein erfahrener Mitarbeiter dafür benötigt.

Erst anschließend stellt sich die technische Frage: Liegen diese Informationen in Dokumenten, Datenbanken oder mehreren Systemen? Müssen Beziehungen verfolgt werden? Verändert sich der Datenbestand häufig? Gibt es Berechtigungen? Müssen Entscheidungen freigegeben werden? Besteht der Prozess aus mehreren abhängigen Arbeitsschritten?

Für einen ersten Prototyp reichen häufig Prompt Engineering und eine überschaubare Context-Schicht. Ein Knowledge Graph oder Workflow Graph sollte ergänzt werden, wenn Evaluationen zeigen, dass bestimmte Fragen oder Prozessabläufe mit der einfacheren Architektur nicht zuverlässig genug bearbeitet werden.

Die Entwicklung verläuft damit nicht nach dem Muster Prompt → Context → Graph als drei aufeinanderfolgende Modebegriffe. Es handelt sich vielmehr um drei technische Gestaltungsebenen, die je nach Aufgabe unterschiedlich stark benötigt werden.

Quellen der verwendeten Kennzahlen

Contextual Retrieval – Reduktion der Retrieval-Fehlerrate um 35 Prozent
Anthropic, „Contextual Retrieval in AI Systems“
https://www.anthropic.com/engineering/contextual-retrieval

GraphRAG – 77 Prozent geringere Tokenkosten im untersuchten Dynamic-Search-Szenario
Microsoft Research, „GraphRAG: Improving global search via dynamic community selection“
https://www.microsoft.com/en-us/research/blog/graphrag-improving-global-search-via-dynamic-community-selection/

Multi-Agent-System – 90,2 Prozent bessere Leistung in der internen Research-Evaluation
Anthropic, „How we built our multi-agent research system“
https://www.anthropic.com/engineering/multi-agent-research-system

Inferenzkosten – mehr als 280-facher Rückgang auf dem untersuchten Leistungsniveau
Stanford Institute for Human-Centered Artificial Intelligence, „The 2025 AI Index Report – Research and Development“
https://hai.stanford.edu/ai-index/2025-ai-index-report/research-and-development

Interessante Links

OpenAI – Best practices for prompt engineering with the OpenAI API
https://help.openai.com/en/articles/6654000-how-can-i-write-better-prompts-for-generative-models

Anthropic – Effective context engineering for AI agents
https://www.anthropic.com/engineering/effective-context-engineering-for-ai-agents

Microsoft – Agent Framework Workflows: Workflow Builder and Execution
https://learn.microsoft.com/en-us/agent-framework/workflows/workflows

FAQ

Ist Prompt Engineering durch Context Engineering überholt?

Nein. Prompt Engineering bleibt die Ebene, auf der Aufgabe, Regeln, Rollen und Ausgabeformate definiert werden. Context Engineering erweitert diesen Ansatz um die Frage, welche Informationen das Modell zur Bearbeitung benötigt. In produktiven Anwendungen ergänzen sich beide Disziplinen. Ein hochwertiger Kontext kompensiert keinen ungeeigneten Prompt, und ein guter Prompt ersetzt keine fehlenden Unternehmensinformationen.

Was ist der wichtigste Unterschied zwischen Prompt Engineering und Context Engineering?

Prompt Engineering bestimmt hauptsächlich, was ein Modell tun soll und wie das Ergebnis aussehen soll. Context Engineering organisiert dagegen die Informationen, Zustände und Werkzeuge, die dem Modell für den jeweiligen Verarbeitungsschritt zur Verfügung stehen. Dazu können RAG-Ergebnisse, Datenbankdaten, Benutzerrechte, Gesprächshistorie, Memory, Tool-Ausgaben und Ergebnisse vorheriger Agentenschritte gehören.

Was versteht man unter Graph Engineering bei KI?

Der Begriff wird in zwei verwandten Bedeutungen verwendet. Knowledge Graph Engineering modelliert Entitäten und ihre Beziehungen, beispielsweise Kunden, Maschinen, Produkte oder Verträge. Im Agentenumfeld bezeichnet Graph Engineering zunehmend auch die Gestaltung graphbasierter Prozesse. Dort bilden Nodes einzelne Verarbeitungsschritte und Edges die Übergänge, Bedingungen oder Abhängigkeiten zwischen diesen Schritten.

Ist GraphRAG besser als normales RAG?

Nicht grundsätzlich. Klassisches RAG eignet sich sehr gut für viele dokumentenbasierte Fragen und ist häufig einfacher zu implementieren und zu betreiben. GraphRAG wird besonders interessant, wenn Antworten von Beziehungen, Hierarchien oder mehrstufigen Verbindungen zwischen Informationen abhängen. Welche Variante bessere Ergebnisse liefert, sollte deshalb anhand echter Unternehmensfragen und definierter Evaluationen geprüft werden.

Wann braucht ein mittelständisches Unternehmen einen Knowledge Graph?

Ein Knowledge Graph lohnt sich vor allem dann, wenn Beziehungen selbst geschäftlich relevant sind. Beispiele sind Produktstrukturen, Maschinenkonfigurationen, Lieferketten, Organisationsbeziehungen, IT-Abhängigkeiten, Berechtigungen oder komplexe Kundenstrukturen. Für eine kleine Sammlung unabhängiger Dokumente wäre ein Graph häufig unnötig. Entscheidend ist, ob Fragen regelmäßig mehrere verbundene Entitäten oder Beziehungsketten betreffen.

Können Prompt Engineering, Context Engineering und Graph Engineering gemeinsam eingesetzt werden?

Ja, gerade anspruchsvollere Unternehmensanwendungen kombinieren die drei Ebenen. Ein Graphknoten kann einen spezifischen Prompt ausführen, während die Context-Schicht dafür passende Daten aus CRM, Dokumentensuche oder Knowledge Graph bereitstellt. Das Ergebnis verändert anschließend den Prozesszustand und bestimmt den nächsten Graphknoten. Dadurch werden Sprache, Wissen und Prozesssteuerung technisch voneinander getrennt, bleiben aber miteinander verbunden.

Welche Daten gehören in den Kontext eines KI-Agenten?

Nur Informationen, die für die aktuelle Aufgabe relevant und zulässig sind. Dazu können Stammdaten, Dokumentausschnitte, Prozessstatus, frühere Entscheidungen, Tool-Ergebnisse, Benutzerinformationen oder aktuelle Geschäftsdaten gehören. Kontext sollte außerdem zeitliche Gültigkeit, Quelle und Zugriffsrechte berücksichtigen. Ein vollständiger Datenbestand muss normalerweise nicht dauerhaft im Kontextfenster des Sprachmodells liegen.

Welche Rolle spielt eine Vektordatenbank beim Context Engineering?

Eine Vektordatenbank kann semantisch passende Inhalte aus größeren Dokumentbeständen auffinden und ist deshalb ein verbreiteter Bestandteil von RAG-Architekturen. Sie ist jedoch nur ein Baustein. Metadatenfilter, Re-Ranking, strukturierte Datenbankabfragen, Zugriffsrechte, Knowledge Graphs und Tool-Aufrufe können ebenso wichtig sein. Context Engineering koordiniert diese Quellen für den jeweiligen Modellaufruf.

Wann ist ein Workflow Graph für KI-Agenten sinnvoll?

Ein Workflow Graph bietet Vorteile, wenn ein Prozess aus mehreren abhängigen Arbeitsschritten, Bedingungen, Freigaben oder parallelen Teilaufgaben besteht. Typische Beispiele sind Angebotsbearbeitung, Reklamationen, Rechercheprozesse oder technische Servicefälle. Bei einer einfachen Textzusammenfassung wäre ein solcher Graph meist unnötig. Die zusätzliche Architektur sollte durch Prozessanforderungen und nicht durch technische Möglichkeiten begründet sein.

Wie sollte ein Unternehmen mit Context Engineering beginnen?

Der Einstieg sollte über einen begrenzten Anwendungsfall erfolgen. Zunächst wird dokumentiert, welche Informationen ein erfahrener Mitarbeiter zur Bearbeitung benötigt und aus welchen Systemen diese stammen. Danach lässt sich ein einfacher Retrieval- und Context-Prozess aufbauen und anhand realer Fragen evaluieren. Graphstrukturen kommen erst hinzu, wenn Beziehungen oder mehrstufige Prozesse einen nachweisbaren Nutzen daraus ziehen.