Agentische KI

Ein agentisches KI-System besteht aus folgenden Komponenten:

• Eine Agent Orchestration-Komponente verwaltet und koordiniert die Aktionen einer Gruppe von Agenten. Die Agent Orchestration-Komponente kann ein LLM nutzen, um Workflows zu analysieren und dynamisch zu generieren, um komplexe Aufgaben zu lösen, oder sie verwendet ausschließlich statisch definierte Workflows, die mit Technologien wie Business Process Modelling Notation (BPMN), Business Process Execution Language (BPEL) oder anderen Workflow-Technologien definiert sind.
  
  
• Einer oder mehrere Agenten, Software, die sich selbst bestimmen und Aktionen ausführen können, um bestimmte Ziele zu erreichen. Agenten verwenden in der Regel ein LLM, um dynamisch Pläne zur Erledigung von Aufgaben zu erstellen. Agenten können auch Tools verwenden, um mit externen Systemen zu interagieren, z. B. eine Anwendungs-API, Anwendungen speichern, z. B. Wikipedia abfragen oder Berechnungen durchführen, z. B. mathematische Operationen, die mit einem LLM allein nicht genau oder effektiv durchgeführt werden können.
  
  
• Schließlich interagieren die Tools mit unternehmenseigenen und externen Quellen und Systemen, um Informationen abzurufen und Datensysteme zu aktualisieren.

Agenten haben ihre eigene konzeptionelle Architektur, die in der Abbildung unten veranschaulicht wird.

Agenten bestehen aus folgenden Kernkomponenten:

• Die Eingabekomponente ist eine oder mehrere Eingabequellen, die den Agenten zur Ausführung einer Aktion veranlassen. Üblicherweise handelt es sich dabei um eine Abfrage in natürlicher Sprache seitens eines Benutzers, es kann sich aber auch um ein Systemereignis handeln, wie beispielsweise die Erstellung einer Datei, eine Nachricht in einer Kafka-Warteschlange oder einen strukturierten API-Aufruf.
  
  
• Die Ausführungskomponente koordiniert die Aktivitäten des Agenten, um die erforderliche Aufgabe auszuführen. Üblicherweise besteht die erste Aufgabe der Ausführungskomponente darin, (i) eine Liste der dem Agenten zur Verfügung stehenden Werkzeuge und Ressourcen zusammenzustellen und (ii) die Planungs- und Reflexionskomponente aufzurufen, um einen Aktivitätsplan zur Durchführung der Aufgabe zu generieren. Die Ausführungskomponente führt dann den generierten Plan aus und ruft Werkzeuge und Ressourcen bei Bedarf auf, um Informationen zu sammeln oder die externe Umgebung des Agenten zu verändern; und kann die Komponente Planung und Reflexion regelmäßig erneut aktivieren, um den Aktivitätsplan je nach Reaktionen oder Ausfällen des Werkzeugs anzupassen.
  
  
• Die Planungs- und Reflexionskomponente, in der Regel ein LLM, ermöglicht es dem Agenten, als Reaktion auf seine Eingaben Schritt-für-Schritt-Aktionspläne zu erstellen, um eine Aufgabe zu erfüllen, und über die Ergebnisse der Aktionen zu reflektieren und seine Pläne entsprechend anzupassen.
  
  
• Die Tool Integration-Komponente ermöglicht es dem Agenten, „Werkzeuge“ zu nutzen, um APIs aufzurufen und auf Ressourcen zuzugreifen, um Aktionen abzuschließen und Informationen zu sammeln, die zur Erfüllung der Gesamtaufgabe beitragen.
  
  
• Die Speicherkomponente verwaltet kurzfristiges, aufgabenbezogenes Kontextwissen sowie langfristiges Wissen, das es dem Agenten ermöglicht, den Kontext über Aufgabenaufrufe hinweg aufrechtzuerhalten (z. B. „Die letzte Bestellung stornieren“) und eine Grundlage für die Analyse vergangener Aktionen und die Optimierung zukünftiger Aktionen zu schaffen.
  

Zusätzliche Komponenten, die in der Abbildung nicht dargestellt sind, können hinzugefügt werden, um die operative Agentenverwaltung, Leistung und Sicherheitskontrollen wie Identitätsverbreitung und Schutz vor Datenlecks zu ermöglichen.

Das folgende Diagramm illustriert den Fluss von Steuerung und Information durch die konzeptuelle Architektur.

1. Ein Benutzer sendet eine Anfrage an eine generative KI-Anwendung (z.B. einen Chatbot oder eine Abfrageoberfläche innerhalb einer Unternehmensanwendung)
   
   
2. Die generative KI-Anwendung leitet die Anfrage des Benutzers an den Agent Orchestrator weiter, entweder in Form der Rohanfrage, z. B. die KI-Anwendung ist eine Chat-Schnittstelle, oder das Auslösen eines vordefinierten Workflows, z. B. der Einleitung einer Bestellanforderung. Für den Walkthrough wird eine Raw Query angenommen.
   
   
3. Der Router verwendet einen optimierten LLM, um die Benutzeranfrage in eine Reihe von Aktionen oder Schritten zu zerlegen, die notwendig sind, um zu einer Antwort zu gelangen. Zum Beispiel, um die Frage zu beantworten: „Wie hoch ist die aktuelle Temperatur in Winnipeg, Manitoba, Kanada? Wie verhält sich das zum historischen Durchschnitt für diese Jahreszeit?“ Das LLM könnte darauf mit folgender konzeptioneller Liste von Maßnahmen antworten:
   
   
   • Suchen Sie mit dem Wetteragenten nach den aktuellen Temperaturen für Winnipeg
   • Schlagen Sie das aktuelle Datum mithilfe des Kalenderagenten nach.
   • Ermitteln Sie mithilfe des Suchagenten die Durchschnittstemperatur in Winnipeg an diesem Datum
   • Ermitteln Sie mithilfe des Rechners die Differenz zwischen der aktuellen Temperatur und dem historischen Durchschnitt
   • Formulieren Sie eine natürliche Sprachantwort mit dem Sprach-Agente
     
     
4. Der Orchestrator ruft dann für jede Aktion in der Liste den entsprechenden Agenten auf. Fortfahren mit dem Beispiel aus Schritt 3:
   
   
   • Der Orchestrator ruft den Wetter-Agenten auf, um die aktuelle Temperatur für Winnipeg abzurufen (-1 °C).
   • Der Orchestrator ruft den Kalenderagenten auf, um das aktuelle Datum, den 9. November 2023, zu erhalten.
   • Der Orchestrator nutzt den Such-Agenten, um die Normaltemperatur in Winnipeg am 9. November bei 1,4 °C zu bestimmen.
   • Der Orchestrator ruft den Rechner-Agenten auf, um die Differenz zwischen den beiden Temperaturen zu ermitteln: -1 - 1,4 = -2,4
   • Der Orchestrator verwendet den Sprachagenten, um anhand der gesammelten Daten eine Antwort auf die ursprüngliche Anfrage zu formulieren.
      
5. Wenn ein Agent aufgerufen wird, kann er, ähnlich wie der Orchestrator, ein LLM verwenden, um seine Aktionen zu planen. Um fortzufahren beim Beispiel, der Wetteragent würde die Anfrage „Wie hoch ist die aktuelle Temperatur in Winnipeg?“ erhalten und daraufhin folgenden Plan generieren:
   
   
   • Schauen Sie nach, in welchem Land Winnipeg liegt
   • Suchen Sie nach dem maßgeblichen nationalen Wetterdienst für Winnipegs Land
   • Verwenden Sie die Weather API, um den Wetterdienst nach der aktuellen Temperatur in Winnipeg abzufragen.
   • Der Agent würde dann das Land, in dem Winnipeg liegt (Kanada), entweder mit einem LLM oder einem externen Dienst nachschlagen, diesen Wert nutzen, um den nationalen Wetterdienst für Kanada (Environment Canada) nachzuschlagen, und mit der Weather API die aktuelle Temperatur für Winnipeg ermitteln.
      
6. Die resultierende Antwort wird dann an die generative KI-Anwendung zurückgegeben; in unserem Beispiel: „Die aktuelle Temperatur in Winnipeg beträgt -1 °C. Das ist 2,4 °C kühler als der historische Durchschnitt von 1,4 °C.
   
   
7. Die formulierte Antwort wird an den Nutzer zurückgegeben.

Das obige Diagramm veranschaulicht die Zuordnung von IBM Produkten zur agentischen KI-Architektur.

Watsonx Orchestrate ist eine umfassende agentische KI-Lösung, die Folgendes kombiniert:

• Veröffentlichung und Verwaltung von Werkzeugen (in Watsonx Orchestrate als Skills bezeichnet);
• Zusammensetzung von Skills in komplexen, mehrstufigen Prozessen mithilfe deklarativer Workflows; und
• vorkonfigurierte domänenspezifische Agenten für horizontale Geschäftsbereiche wie HR und Einkauf.

Der watsonx.ai Agent Builder ist ein Low-Code-/No-Code-Tool, mit dem Entwickler Agenten erstellen und Tools mithilfe vorkonfigurierter/vorgefertigter Abläufe definieren und verwalten können.

Orchestrierungsstrategie

Die Agentenorchestrierung kann mit verschiedenen Ansätzen implementiert werden. Bei einem zentralisierten Orchestrierungsansatz wird eine einzige Master-Orchestrierungskomponente verwendet, um die Aktionen aller anderen Agenten im System zu steuern. Eine einzige Konfigurations- und Verwaltungsstelle macht das Gesamtsystem einfach zu verwalten und zu kontrollieren und erleichtert die Fehlerbehebung. Der Nachteil ist, dass ein einziger Kontrollpunkt zu einem Engpass werden und zu Problemen bei der Skalierbarkeit führen kann, wenn das Anfragevolumen und/oder die Anzahl der Agenten steigt.

Ein dezentraler Orchestrierungsansatz implementiert eine Aufgabenwarteschlange, bei der Agenten Aufgaben abziehen und Ergebnisse posten und mehrteilige Aufgaben untereinander routen; ähnlich wie ein Blackboard-System. Dezentrale Orchestrierungslösungen sind hoch robust und fehlertolerant, sind aber schwer zu entwerfen und zu beheben, da die Systeme größer werden und größere Funktionen erhalten.

Ein hierarchischer Orchestrierungsansatz schließlich kombiniert Elemente des zentralisierten und des dezentralen Ansatzes. Bei der hierarchischen Orchestrierung wird ein Master-Orchestrator eingesetzt, um die Aktionen von übergeordneten Agenten zu koordinieren, die wiederum andere Agenten aufrufen können, um komplexe Aufgaben zu erledigen. Dadurch bleibt ein Großteil der einfachen Verwaltung und Kontrolle eines zentralisierten Ansatzes erhalten, gleichzeitig wird jedoch das Risiko verringert, dass die zentrale Steuerungskomponente bei hohem Anfrageaufkommen und/oder einer großen Anzahl von Agenten zu einem Engpass wird.

Granularität des Agenten

Die Granularität eines KI-Agenten bezieht sich auf die Komplexität der Aufgaben, die der Agent ausführen kann. Ein Agent mit hoher Granularität kann viele Aufgaben oder eine kleine Anzahl von Aufgaben sehr detailliert ausführen, während ein Agent mit niedriger Granularität möglicherweise nur in der Lage ist, eine kleine Anzahl oder sogar nur eine einzige Aufgabe mit geringer Detailgenauigkeit zu erledigen. Um das klarer zu machen, ziehen Sie einen Kundenservice in Betracht. Ein Agent mit geringer Granularität kann möglicherweise nur einfache Fragen zu einem Produkt beantworten (z. B. „Gibt es das auch in Schwarz?“), wohingegen ein Agent mit hoher Granularität in der Lage ist, lokale Bestände zu prüfen und die Lieferung des Produkts zum Kunden nach Hause zu veranlassen.

Designer von agentischen Lösungen müssen entscheiden, wie granulär die einzelnen Agenten im System gestaltet werden, z. B. wenn sie eine kleine Anzahl von hochgranularitätsfähigen Agenten oder eine größere Anzahl von niedriggranularitätsfähigen Agenten haben. Die weitreichenden Funktionen von Agenten mit hoher Granularität gehen mit einem höheren Bedarf an Ressourcen und einer längeren Bearbeitungszeit für Aufgaben einher. Agenten mit niedriger Granularität sind zwar weniger leistungsfähig, benötigen aber aufgrund ihres engen Fokus weniger Rechenressourcen und erledigen ihre Aufgaben im Allgemeinen viel schneller.

Obwohl das „richtige“ Granularitätsniveau noch unbekannt ist, deuten frühe Erfahrungen darauf hin, dass die Erstellung von Agenten mit niedriger Granularität, die auf fokussierte Geschäftsprozesse abgestimmt sind, z. B. Purchase_Order_Processing_Agent, ein gutes Gleichgewicht zwischen Ressourcenanforderung, Verarbeitungsgeschwindigkeit und Lösungskomplexität schafft. Die Agenten mit niedriger Granularität können dann in statische Workflows integriert oder von Agenten mit hoher Granularität als Teil eines größeren Prozesses aufgerufen werden.

Statische und dynamische Workflows im Vergleich

Die Entwickler von agentischer KI-Lösungen müssen ein Gleichgewicht zwischen Agenten finden, die vordefinierten, statischen Prozessen und Workflows folgen, und solchen, bei denen Workflows dynamisch als Reaktion auf Prompts generiert werden. Auch wenn es keine richtige oder falsche Antwort gibt, wird Architekten empfohlen, die folgenden Empfehlungen und Überlegungen zu berücksichtigen:

• Statische Workflows sollten für Geschäftsprozesse verwendet werden, die aus mehreren komplexen Schritten bestehen, die Wissensbereiche überschreiten (z. B. Recht und Rechnungswesen) oder die der Aufsicht von Aufsichtsbehörden unterliegen. Die Verwendung statischer Workflows bietet Architekten in diesen Fällen mehrere Vorteile:

  • Statische Workflows sind (vergleichsweise) einfach zu instrumentieren, zu überwachen und zu prüfen, und die Workflows selbst können als Nachweis für die Einhaltung gesetzlicher Vorschriften verwendet werden. Dynamisch generierte Workflows sind während ihrer Ausführung schwieriger zu überwachen, und die Ausführung einzelner Prozesse muss anhand der Protokolle einzelner Agenten rekonstruiert werden. Dynamische Workflows haben zudem das Potenzial, die Abfolge der Aufgaben zu verändern, was Audit- und Compliance-Überwachung zusätzlich erschwert.
    
    
  • Klar definierte „Übergaben“ zwischen den Fachgebieten ermöglichen eine klare Entkopplung der Verantwortung und machen es einfach sicherzustellen, dass die übermittelten Informationen vollständig und korrekt sind. Das Gleiche kann zwar mit einem dynamisch generierten Workflow erreicht werden, erfordert jedoch mehr Aufmerksamkeit bei Design und Implementierung
    
    
• Dynamische Workflows sollten für „Einzelschritt“-Aktivitäten oder -Funktionen verwendet werden, die zeitlich dicht beieinander ausgeführt werden, nicht Wissensdomänen überschreiten und deren Ausführung nicht regulatorischer Aufsicht oder Kontrollen unterliegt.