Entwurf widerstandsfähiger KI-Agenten-Graphen: Wiederholungen, Fallback-Mechanismen und GraphRAG
Ermitteln Sie, wie man fehlertolerante Workflows für KI-Agenten mit expliziten Fehlerverarbeitungswege, Wiederholungslogik, LangGraph sowie bei Situationen erstellt, in denen GraphRAG besser abschneidet als herkömmliches RAG oder Agentenschleifen.
Wenn Fehler auftreten: Planung alternativer Wege
Um dort weiterzumachen, wo die vorherige Diskussion aufgehört hat, stellen wir uns vor, dass der Finanzforschungsagent zu diesem Zeitpunkt deutlich fortschrittlicher geworden ist.
Erinnern wir uns an die Beispielfrage, die ein Portfoliomanager stellen könnte – etwa warum ein bestimmter Aktienkurs nach dem Quartalsbericht gefallen ist und welche Risiken künftig beachtet werden sollten. Das System kann solche Fragen analysieren, Daten aus mehreren Quellen abrufen, die Ergebnisse untersuchen, eine Antwort entwerfen, diese überprüfen und bei Bedarf an einen menschlichen Prüfer weiterleiten – im Grunde ein Verfahren mit menschlicher Beteiligung.
Es gibt jedoch einen Punkt, den wir bisher noch nicht behandelt haben: was passiert, wenn ein Schritt in diesem Prozess fehlschlägt?
Stellen Sie sich vor, das System erreicht den für Marktdaten zuständigen Teil des Prozesses.
Es wird eine Anfrage nach Preisbewegungen und Handelsvolumen gesendet, doch der Datenanbieter antwortet nicht.
In einer solchen Situation ist es nicht möglich, direkt zum Analyze-Schritt überzugehen, als wäre nichts passiert.
Gleichzeitig ist es in der Regel zu extrem, den gesamten Ablauf einfach abzubrechen, da produktionstaugliche Systeme eine Art Fallback-Verhalten benötigen.
Deshalb sollte ein Fehler als eigene Abzweigung im Diagramm behandelt werden und nicht als nachträgliche Überlegung.
Der ursprüngliche, einfache Ablauf sieht so aus:
Search Market Data
↓
Analyze
Wir können ihn stattdessen in etwas Ähnliches umformen:
Search Market Data
/ \
↓ ↓
Success Failure
↓ ↓
Analyze Retry (how to handle this!?)
Mit dieser Struktur hat das Diagramm eine klare Anweisung dafür, was zu tun ist, wenn eine Anfrage fehlschlägt.
Verwaltung der Wiederholungslogik
Falls die Wiederholung erfolgreich ist, setzt der Workflow einfach wie gewohnt fort.
Falls es erneut fehlschlägt, macht es vermutlich mehr Sinn, auf eine andere Datenquelle umzusteigen oder die Angelegenheit einer menschlichen Überprüfung zu übergeben, anstatt denselben Anfrage wiederholt zu senden.
Hier ist eine detailliertere Version dieser Struktur:
Search Market Data
/ \
↓ ↓
Success Failure
↓ ↓
Analyze Retry
↓
┌──────┴──────┐
↓ ↓
Success Failure
↓ ↓
Analyze Alternative
Source
Wichtig ist hier nicht, wie viele Wiederholungsversuche man zulässt – vielmehr ist es die Tatsache, dass die Fehlerbehandlung von Anfang an in der Struktur des Graphen integriert ist. Wie das Diagramm zeigt, können verschiedene Arten von Fehlern zu unterschiedlichen Abläufen führen.
Nehmen wir an, die API für Marktdaten läuft einfach aus. Ein erneuter Versuch ist sinnvoll, da das Problem vermutlich vorübergehend ist.
Aber nehmen wir an, die Anfrage wird erfolgreich abgewickelt, liefert aber für den betreffenden Zeitraum einfach keine nützlichen Daten. Das Wiederholen derselben Anfrage bringt nichts.
In diesem Fall ist es besser, eine alternative, genehmigte Datenquelle abzufragen.
Falls auch das keine Ergebnisse liefert, ist es vermutlich sinnvoll, die Situation an einen menschlichen Prüfer weiterzuleiten. Genau solche Details unterscheiden einen instabilen Arbeitsablauf von einem zuverlässigen.
Die Steuerfunktion dafür könnte wie folgt aussehen:
def route_after_market_search(state):
if state["market_data"]:
return "analyze"
if state["retry_count"] < 2:
return "retry"
return "human_review"
Diese Bedingungen geben dem Graphen klare Grenzen – es ist erlaubt, es zu wiederholen, aber nicht endlos.
Das gleiche Prinzip gilt für den gesamten Graphen, da im Laufe des Prozesses viele Dinge schiefgehen können:
- Ein Abrufschritt kann fehlschlagen
- Eine Anfrage an das LLM kann fehlschlagen
- Eine bestimmte Quelle kann vorübergehend nicht erreichbar sein
- Eine generierte Antwort kann eine Validierungsprüfung nicht bestehen
Anstatt die gesamte Anwendung in einem einzigen umfangreichen Fehlerhandler zu verpacken, kann man Node für Node entscheiden, was genau an dem Punkt geschehen soll, an dem etwas schiefgeht.
Dies ist ein Grund, warum das Modellieren eines Workflows als Graph so attraktiv ist. Wenn es zu einem Fehler kommt, müssen Sie nicht mit einer vagen Frage wie „Warum ist der Agent fehlgeschlagen?“ herumlaufen.
Stattdessen können Sie den genauen Ablauf verfolgen und genau feststellen, wo etwas schiefgelaufen ist:
Understand
↓
Search Filings ✓
↓
Search Earnings ✓
↓
Search Market Data ✗
↓
Retry ✓
↓
Analyze
↓
Write
↓
Check
Das gibt Ihnen etwas Konkretes zum Untersuchen anstelle einer Black Box.
Natürlich erfordert das Manuelle Verwalten all dieser Elemente, je größer der Graph wird, zunehmend viel Aufwand – und das ist durchaus berechtigt.
Zu diesem Zeitpunkt müssen Sie sich mit Ausführungslogik, Zustandsverwaltung, bedingtem Routing, Wiederholungsmechanismen, Persistenz sowie einer Möglichkeit beschäftigen, herauszufinden, was während eines bestimmten Ablaufs tatsächlich passiert ist.
Genau in solchen Situationen hilft ein Framework dabei, nicht jedes Mal von vorn die gleiche Orchestrierungslogik entwickeln zu müssen.
Dies ist die Lücke, die LangGraph schließen soll.
LangGraph
Mit einem solchen Framework kann Ihr Arbeitsablauf in separate Forschungsaufgaben unterteilt werden, die Ergebnisse anschließend zusammengeführt, fehlgeschlagene Schritte erneut ausgeführt, eine Pause eingelegt werden, damit ein Mensch eingreifen kann, und der Zustand während des Übergangs von einer Phase zur nächsten verfolgt werden.
Selbstverständlich erfordert die Definition dieses Graphen sowie seine tatsächliche Ausführung weiterhin Arbeit.
Man könnte die gesamte Orchestrierung selbst umsetzen, doch dadurch müsste man eine erhebliche Menge an Infrastruktur verwalten, die um die Kernlogik der KI herum entsteht.
LangGraph ist genau dafür konzipiert, diese Schicht zu übernehmen.
LangGraph ist ein Framework zur Erstellung zustandsbehafteter, graphbasierter Agenten-Arbeitsabläufe. Anstatt einen Agenten als eine einzige Schleife zu betrachten, die ständig ein Sprachmodell fragt, was als Nächstes zu tun ist, definieren Sie explizit die Knoten, die Übergänge zwischen ihnen, den gemeinsamen Zustand sowie den gesamten Ausführungsbefehl.
Für den zuvor erwähnten NVIDIA-Forschungsagenten lässt sich seine Struktur wie folgt skizzieren:
Question
↓
Understand
↓
┌──────────┼──────────┐
↓ ↓ ↓
Filings Earnings Market
↓ ↓ ↓
└──────────┼──────────┘
↓
Analyze
↓
Write
↓
Check
↙ ↓ ↘
Search Rewrite Human
↓ ↓ Review
└───────┴───────┘
↓
Send
Bemerkenswert ist, dass die Struktur des Graphen und die eigentliche Anwendungslogik in derselben Codebasis zusammenexistieren können.
from langgraph.graph import StateGraph, END
builder = StateGraph(ResearchState)
builder.add_node("understand", understand)
builder.add_node("search_filings", search_filings)
builder.add_node("search_earnings", search_earnings)
builder.add_node("search_market", search_market)
builder.add_node("analyze", analyze)
builder.add_node("write", write)
builder.add_node("check", check)
builder.set_entry_point("understand")
builder.add_edge("understand", "search_filings")
builder.add_edge("understand", "search_earnings")
builder.add_edge("understand", "search_market")
builder.add_edge("analyze", "write")
builder.add_edge("write", "check")
Der obige Auszug ist absichtlich minimal gehalten, damit Sie sich auf das zugrundeliegende Denkmodell konzentrieren können – nämlich die Verknüpfung der zuvor in dieser Serie vorgestellten Knoten, Kanten und Zustandskonzepte.
- Jeder Knoten handelt eine Arbeitseinheit ab
- Der Graph definiert, wie diese Einheiten miteinander verbunden sind
- Zustände übertragen Informationen von einem Knoten zum nächsten
Das ist im Grunde alles. Dieses Denkmodell lässt sich viel leichter verstehen als der Versuch, alles in einen einzigen umfangreichen Agentenbefehl zu packen.
Man kann sich den Graphen selbst ansehen und verstehen, was der Workflow leisten soll, noch bevor man sich mit der Implementierung jedes einzelnen Knotens beschäftigt.
Nehmen wir an, man möchte einen Schritt zur menschlichen Freigabe vor der Auslieferung der endgültigen Antwort einfügen – dann würde man die Struktur des Workflows direkt ändern:
Check
↓
Human Review
↓
Send
Es ist nicht notwendig, eine solche Entscheidung irgendwo in einer Anweisung zu verbergen. Die Struktur selbst macht sie klar und erleichtert es dem Team, ihr zu folgen.
Warum LangGraph gegenüber einem einfachen Agenten-Loop wählen?
Ein herkömmlicher Agenten-Loop folgt in der Regel dieser Struktur:
Think
↓
Choose Tool
↓
Use Tool
↓
Think Again
↓
Choose Tool
↓
...
In dieser Konfiguration hat das Modell erhebliche Freiheit bei der Entscheidung darüber, was als Nächstes geschieht. Diese Flexibilität ist besonders wertvoll, wenn die zu bewältigende Aufgabe von Natur aus offenen Charakters ist.
Aber ein Finanzforschungs-Arbeitsablauf wie der hier beschriebene umfasst mehrere Entscheidungspunkte, die Sie wahrscheinlich strenger kontrollieren möchten. Diese Unterscheidung ist der Kern der Angelegenheit.
Nicht jeder Arbeitsablauf erfordert einen Agenten-Loop.
Betrachten Sie einige Beispiele:
- Möglicherweise müssen Sie, dass das System spezifische Beweise sammelt, bevor es eine Antwort liefern darf.
- Möglicherweise möchten Sie, dass Marktdaten und Unterlagen unabhängig voneinander abgerufen werden.
- Möglicherweise benötigen Sie einen Überprüfungsschritt, bevor etwas an einen menschlichen Prüfer weitergeleitet wird.
- Möglicherweise möchten Sie, dass der Prozess nach einer bestimmten Anzahl an Wiederholungsversuchen automatisch gestoppt wird.
Das sind keine Entscheidungen, die Sie unbedingt der Improvisation des Modells bei jedem Lauf überlassen möchten. Innerhalb eines Loops gibt es keine Möglichkeit, sicherzustellen, dass das Modell jedes Mal denselben Aufruf vornimmt.
Ein Graph ermöglicht es, diese Einschränkungen direkt in die Struktur des Workflows einzubauen. Das Modell kann weiterhin innerhalb jedes einzelnen Knotens logisch vorgehen, doch das umgebende System bestimmt, wohin es als Nächstes gehen darf.
Das ist der entscheidende Unterschied, den man im Gedächtnis behalten sollte. Das Ziel besteht nicht darin, dem Agenten das Denken wegzunehmen – vielmehr geht es darum, bewusst zu entscheiden, wo dieses Denken stattfinden soll und wo eine deterministische Orchestrierung besser geeignet ist.
Während man weiterhin Workflows entwickelt, die mit strukturierten Finanzdaten arbeiten, taucht eine neue Frage auf.
Derzeit holt unser Agent Dokumente und Zahlen aus verschiedenen Quellen. Doch was passiert, wenn die zugrunde liegenden Informationen Verbindungen aufweisen, die tatsächlich von Bedeutung sind?
- Unternehmen beschäftigen Führungskräfte
- Diese Führungskräfte sitzen oft in den Vorständen der Unternehmen
- Ein Unternehmen kann ein anderes übernehmen
Bis jetzt haben wir jede Datenmenge als isoliert betrachtet. Doch die oben gezeigten Verbindungen lassen sich nur schwer darstellen, wenn Ihre Wissensbasis lediglich aus einer Ansammlung von eigenständigen Dokumenten besteht.
Das führt uns zu einem weiteren zentralen Konzept: GraphRAG.
GraphRAG
Bislang haben wir Graphen hauptsächlich verwendet, um das Verhalten des Agenten zu steuern. Doch Graphen können auch einen zweiten Zweck erfüllen:
die Kenntnisse selbst zu organisieren.
In unserem Beispiel könnte eine herkömmliche RAG-Einrichtung Dokumente heranziehen, die Nvidias Gewinne, Prognosen, Umsatzzahlen, Marge sowie die Reaktion des Marktes erwähnen.
Der Ansatz funktioniert gut, wenn die Antwort hauptsächlich in einer Handvoll relevanter Dokumente zu finden ist. Doch finanzielle Fragen sind nicht immer so begrenzt.
Eine sinnvolle Antwort hängt oft davon ab, Informationen, die über mehrere getrennte Dokumente verstreut sind, miteinander zu verknüpfen.
Stellen Sie sich nun vor, man möchte nicht nur verstehen, was NVIDIA berichtet hat, sondern auch, wie sich die verschiedenen Teile dieses Berichts gegenseitig beziehen (das ist genau die Situation, mit der wir es zu tun haben).
Darum ist ein Wissensgraph genau das Richtige.
Anstatt Wissen rein als Textabschnitte zu speichern, können wir die wichtigen Entitäten sowie die Beziehungen zwischen ihnen modellieren:
NVIDIA ──→ produces ──→ GPUs
│
├──→ reports ──→ Earnings
│
├──→ depends on ──→ Suppliers
│
├──→ competes with ──→ AMD
│
└──→ operates in ──→ AI Infrastructure
Der Graph erfasst nun Verbindungen, die beim Lesen eines einzelnen Dokuments für sich genommen möglicherweise nie zum Vorschein kommen.
RAG im Vergleich zu GraphRAG
Standardmäßig funktioniert RAG dadurch, dass relevante Auszüge abgerufen und dem Modell als Kontext bereitgestellt werden. Hier ist eine vereinfachte Darstellung dieses Ablaufs:
Question
↓
Retrieve relevant chunks
↓
LLM
↓
Answer
GraphRAG fügt eine zusätzliche Schicht ein. Das System kann sich auf Beziehungen zwischen Entitäten stützen, um herauszufinden, welche Informationen tatsächlich wichtig sind:
Question
↓
Identify entities
↓
Traverse relationships
↓
Retrieve relevant information
↓
LLM
↓
Answer
Für unseren Finanzforschungsagenten wird dies wertvoll, sobald eine Frage erfordert, dass mehrere Entitäten oder Dokumente gleichzeitig miteinander verbunden werden.
Nehmen wir an, der Portfoliomanager fragt: Welche Risiken könnten NVIDIA treffen, falls die Nachfrage nach KI-Infrastruktur nachlässt?
Eine gute Antwort darauf erfordert möglicherweise die Verknüpfung von NVIDIA mit seinen Produkten, Kunden, Lieferanten, Konkurrenten, den allgemeinen Marktbedingungen sowie den Risiken, die das Unternehmen bereits in früheren Unterlagen angegeben hat.
Ein Graph bietet dem Abrufsystem einen strukturierten Weg, um all diese Verbindungen zu erkunden.
NVIDIA
/ | \
/ | \
Products Suppliers Competitors
| | |
↓ ↓ ↓
AI GPUs Supply Risk AMD
|
↓
AI Infrastructure
|
↓
Demand
Von dort aus kann das Modell über alles nachdenken, was von diesen vernetzten Entitäten eingeholt wurde.
Dies bedeutet nicht, dass GraphRAG immer besser ist als herkömmliches RAG. Die zusätzliche Struktur lohnt sich insbesondere dann, wenn die Beziehungen zwischen den Informationen zentral für die gestellte Frage sind.
Falls die Antwort ordentlich in einem einzigen Gewinnbericht zu finden ist, reicht vermutlich ein herkömmlicher Abrufprozess aus.
Falls die Beantwortung der Frage bedeutet, Informationen zusammenzutragen, die über viele Entitäten und Quellen verteilt sind, erscheint eine graphbasierte Lösung deutlich attraktiver.
Es gibt hier noch eine weitere Unterscheidung, die man klar erkennen sollte: Ihr Workflow-Graph und Ihr Wissensgraph sind zwei völlig unterschiedliche Dinge.
Das Workflow-Diagramm beantwortet die Frage, was der Agent als Nächstes tun sollte. Das Wissensgraph zeigt, was mit was innerhalb der von Ihnen verwendeten Daten verbunden ist.
In unserem System können beide nebeneinander existieren:
WORKFLOW GRAPH:
Question
↓
Retrieve
↓
Analyze
↓
Write
↓
Check
während im Hintergrund die Abrufschicht arbeitet:
KNOWLEDGE GRAPH:
NVIDIA
├── Products
├── Suppliers
├── Competitors
├── Executives
├── Filings
└── Industry
Beachten Sie die Aufgabenteilung: Eine Struktur steuert die Ausführung, während die andere das Wissen sowie die darin vorhandenen Beziehungen organisiert.
Sobald diese beiden Konzepte anfangen, sich gegenseitig zu stärken, wird der Finanzforschungsagent erheblich leistungsfähiger.
- Das Workflow bestimmt wie die Forschung durchgeführt wird.
- Das Wissensgraph bestimmt welche Informationen miteinander verbunden sind.
Natürlich stellt sich hier eine weitere Frage: Wenn Graphen solch große Kontrollmöglichkeiten bieten, sollte dann jeder Workflow als einer konstruiert werden?
Nicht unbedingt.
In vielen Fällen reicht bereits ein einfacher Agentenzyklus aus, um das Problem zu lösen.
Anstatt daher jeden KI-Workflow standardmäßig in einen Graphen umzuwandeln, lohnt es sich, die beiden Ansätze direkt miteinander zu vergleichen und herauszufinden, wann die zusätzliche Komplexität der Graphenkonstruktion tatsächlich Vorteile bringt.
Man sollte bedenken, dass Graphen zwar mehr Kontrolle ermöglichen, diese Kontrolle jedoch mit zusätzlicher Arbeit einhergeht: Man muss nun die Struktur selbst entwerfen und warten.
Falls die zugrundeliegende Aufgabe tatsächlich einfach ist, kann das Einbetten in einen Graphen das System sogar schwerer verständlich machen, ohne nennenswerte Vorteile zu bringen.
Kehren wir zum Beispiel des Finanzforschungs-Agenten zurück. Angenommen, der Benutzer fragt etwas wie: Zusammenfassen Sie Nvidias neuesten Gewinnbericht.
Das ist eine spezifische, eigenständige Anfrage.
Diese könnte man bewältigen, indem man den entsprechenden Bericht abruft und ihn dem Modell zur Erstellung eines Zusammenfassens übergibt:
Question
↓
Retrieve Report
↓
Summarize
↓
Answer
Es gibt keine wirklichen Branching-Strukturen und auch keine komplizierte Logik, die man verwalten müsste. Ein einfacher RAG-Pipeline oder ein grundlegender Agenten-Loop würde das problemlos handhaben.
Vergleichen wir das nun mit einer umfassenderen Anfrage, bei der der Benutzer verstehen möchte, was den Rückgang des Aktienkurses nach der Gewinnmitteilung verursacht hat, dieses Ergebnis mit den Prognosen der Analysten vergleichen möchte, eine Liste der Risiken erhalten will, die künftig im Auge behalten werden sollten, sowie die Möglichkeit haben möchte, die Erkenntnisse vor ihrer Aufnahme in einen Portfolio-Bericht zu überprüfen.
Das ist eine völlig andere Art von Problem.
Diese Version beinhaltet verschiedene Arten von Forschung, zieht aus unterschiedlichen Quellen Informationen heran, benötigt Validierung, kann mehrere Versuche erfordern und umfasst außerdem einen Schritt der menschlichen Überprüfung.
Der Workflow sieht jetzt eher so aus:
Question
↓
Understand
↓
┌──────────┼──────────┐
↓ ↓ ↓
Filings Earnings Market
↓ ↓ ↓
└──────────┼──────────┘
↓
Analyze
↓
Write
↓
Check
↙ ↓ ↘
Search Rewrite Human
↓ ↓ Review
└───────┴──────┘
↓
Send
Bei dieser Komplexitätsstufe lohnt es sich, den Workflow ausdrücklich darzulegen.
Wann reicht ein Agentenloop aus?
Ein Agentenloop ist in der Regel die richtige Wahl, wenn das Modell von etwas Freiheit profitiert, um selbst zu wählen, welches Werkzeug es als Nächstes verwenden soll.
Zum Beispiel:
Question
↓
LLM decides what to do
↓
Tool
↓
LLM decides what to do next
↓
Tool
↓
Answer
Wenn die Aufgabe erkundend ist und man die Anzahl der Schritte im Voraus nicht vorhersagen kann, ist diese Flexibilität wirklich wertvoll.
Der Agent könnte entscheiden, dass er einen Einkommensauszug überprüfen muss, anschließend eine bestimmte Kennzahl heranziehen und danach nach weiterem Kontext suchen. Es ist nicht notwendig, bereits im Voraus alle möglichen Abläufe durchzudenken.
Wann wird ein Graph verständlicher?
Ein Graph ist dann nützlich, wenn der Ablaufprozess Regeln enthält, die tatsächlich eine Bedeutung haben.
Für das Finanzforschungssystem könnten diese Regeln wie folgt aussehen:
Retrieve evidence
↓
Run analysis
↓
Generate draft
↓
Verify claims
↓
Human review
↓
Publish
Es handelt sich dabei um Einschränkungen auf Workflow-Ebene, und ein Graph ermöglicht es, diese direkt zu kodieren, anstatt darauf zu hoffen, dass das Modell sie von selbst ableitet.
Der Kompromiss
Ein Graph gibt Ihnen mehr Kontrolle, bedeutet aber auch einen höheren Aufwand in der Architektur.
Ihre Überlegungen müssen nun umfassen:
- wie der Zustand strukturiert ist
- die Routenlogik
- was passiert, wenn etwas fehlschlägt
- das Verhalten bei erneuten Versuchen
- die Persistenz
Nichts davon ist an sich schlecht – es bedeutet lediglich, dass das Graph die damit verbundene Überlast rechtfertigen muss.
Für den NVIDIA-Forschungsagenten wäre es sinnlos, das gesamte Graph von vornherein aufzubauen, nur weil Graphen interessant sind.
Stattdessen sollte die zusätzliche Struktur nur dann eingeführt werden, wenn der Workflow sie tatsächlich erfordert:
- Fangen Sie einfach an.
- Fügen Sie Verzweigungen hinzu, sobald sie wirklich notwendig sind.
- Fügen Sie parallele Ausführung hinzu, sobald die Aufgaben tatsächlich unabhängig voneinander laufen können.
- Fügen Sie Kontrollpunkte hinzu, wenn der Workflow pausiert oder von einer Unterbrechung wiederhergestellt werden muss.
- Fügen Sie einen Schritt zur menschlichen Überprüfung hinzu, wenn die Bedeutung die zusätzliche Komplexität rechtfertigt.
- Führen Sie GraphRAG ein, sobald die Beziehungen innerhalb des Wissens selbst wichtig werden.
Auf diese Weise existiert das Diagramm, weil das Problem es erfordert, und nicht, weil es verfügbar ist.
Fazit
Das ist wohl die zentrale Lektion aus der Bearbeitung dieses Designs.
Ein Diagramm dient nicht dazu, ein KI-System anspruchsvoll erscheinen zu lassen. Es existiert, um den Arbeitsablauf leichter verstehen und steuern zu können.
Der über diese Diskussion entwickelte Finanzforschungsagent kann nun abzweigen, erneut versuchen, pausieren, einen menschlichen Prüfer einbeziehen und sogar auf Beziehungen zwischen Wissenselementen zurückgreifen, wenn das sinnvoll ist.
Trotzdem bedeutet das nicht, dass jedes System ein Diagramm benötigt. Manchmal reicht bereits ein einfacher RAG-Pipeline aus. Manchmal deckt eine Agentenschleife bereits alles ab, was das Problem erfordert.
Die wahre Fähigkeit besteht darin, den Punkt zu erkennen, an dem ein Problem kompliziert genug geworden ist, dass ein Diagramm die Investition lohnenswert macht.