Was ist ReWOO?

Die ersten LLMs (wie die GPT-1- und GPT-2-Modelle von OpenAI) lieferten direkte Antworten; die nachfolgende Welle von Chain-of-Thought-Modellen, die 2022 debütierte, fügte ein Element des externalisierten Denkens hinzu, wobei die Modelle im Wesentlichen „laut denken“, wenn sie zu einer Antwort kommen, was die Genauigkeit und Erklärbarkeit verbessert. 

Als Nächstes kam eine Generation von erweiterten Sprachmodellen („ALM-Systemen“) und KI-Agenten, die zusätzlich zu dieser Argumentation auch Funktionen zum Aufrufen von Tools hinzufügten. Die frühen ALM-Frameworks – wie React – verwenden ein Denk-Aktion-Beobachten-Muster, bei dem das System beobachtet, was es generiert, bevor es erneut anfängt, darüber nachzudenken. Frameworks wie React sind zwar im Allgemeinen effektiv, können jedoch einen hohen Token-Verbrauch erfordern, da jeder nachfolgende Tool-Aufruf den gesamten Konversationsverlauf enthalten muss, der ihm vorausgeht — Kosten, die sich mit jedem Schritt erhöhen. 

ReWOO löst sich vom Denk-Aktion-Beobachten-Muster, indem es die Argumentation von externen Beobachtungen entkoppelt und es dem Modell ermöglicht, seine Argumentationskette intern zu planen, bevor es selektiv Tools aufruft oder Informationen abruft. Diese Trennung reduziert unnötiges Hin und Her und ermöglicht es dem Modell, während der gesamten Aufgabe einen Plan beizubehalten.

ReWOO verwendet drei verschiedene Module, die komplexe Aufgaben aufteilen und meistern. Zunächst entwirft ein Planer-Modul einen Blueprint dafür, wie sich das Modell auf der Grundlage der Eingabeaufforderung des Benutzers verhalten wird. Als Zweites führt ein Worker-Modul den Plan aus und ruft externe Tools auf (ohne kostspielige LLM-API-Aufrufe zum „Denken“ zu wiederholen, wie in ReAct). Schließlich nimmt ein Solver-Modul die Pläne und Beweise auf und fasst die endgültige Antwort zusammen. 

Obwohl der Unterschied in der Herangehensweise gering erscheinen mag, sind die Ergebnisse dramatisch: ReWoo schneidet bei einigen Benchmarksgenauso gut (oder etwas besser) ab als React – und das alles mit etwa 80 % weniger Tokens. (Ein Token ist eine Einheit mit semantischer Bedeutung für ein KI-Modell. Je mehr Tokens es gibt, desto höher sind die Betriebskosten.) Beim HotpotQA-Datensatz (eine Reihe von Fragen zur Bewertung von KI-Systemen) erreicht ReWOO beispielsweise eine Genauigkeit von 42,4 % mit 2.000 Token, während ReAct eine Genauigkeit von 40,8 % mit 10.000 Token erreicht.  

Entscheidend ist, dass diese Optimierung der Token-Effizienz Reasoning-Modelle in großem Maßstab wirtschaftlich rentabel macht.

Um den Unterschied zwischen diesen beiden gängigen generativen KI-Frameworks zu veranschaulichen, schauen wir uns einen konkreten Anwendungsfall an. Überlegen Sie, wie unterschiedlich ein ReAct-System im Vergleich zu einem ReWOO-System auf eine Benutzeranfrage reagieren würde, in der um Hilfe beim Packen für eine Reise gebeten wird, die einen Flug zwischen New York und Chicago am morgigen Tag und eine Fahrt nach Milwaukee am darauffolgenden Tag beinhaltet.

Ein ReAct-System würde das Problem in eine Abfolge von drei Gedanken-Handlungs-Beobachtungszyklen zerlegen, bevor es seine endgültige Antwort gibt. Im ersten Zyklus würde es denken: „Ich muss das Wetter von morgen in New York überprüfen“, mithilfe von Retrieval-Augmented Generation (RAG) nach diesem Wetter suchen (eine Aktion) und schließlich das Ergebnis beobachten. Diese Ergebnisse dienen dann als Grundlage für einen weiteren dreistufigen Zyklus zum Denken, Handeln und Beobachten des Wetters in Chicago. Drittens würde es das Gleiche für das Wetter in Wisconsin tun. Schließlich werden die Ergebnisse in einem Output zusammengefasst (z. B. „Packen Sie Schichten ein, weil es an jedem Ort kälter wird“). 

Im Gegensatz dazu würde ein System im ReWOO-Stil an Effizienz gewinnen, indem die gesamte Planung im Voraus durchgeführt wird. Zuerst würde es planen: „Ich muss morgen das Wetter in New York, morgen das Wetter in Chicago und übermorgen das Wetter in Milwaukee abrufen.“ Als Nächstes würde es funktionieren, indem Wetter-APIs in einer engen Abfolge (oder möglicherweise parallel) aufgerufen werden, ohne dass man bei diesem Arbeitsschritt kostspielig „denken“ muss. Schließlich würde es eine Lösung finden, die Beweise zusammentragen und eine endgültige Antwort ausgeben.  

Neben der Token-Effizienz bietet ReWOO einen zusätzlichen Nutzen: Robustheit bei Toolausfällen. Wenn beispielsweise ein Tool unter ReAct ausfällt, kann das System in einer Endlosschleife hängen bleiben (da das LLM z. B. wiederholt eine defekte Datenbank nach dem Wetter in Chicago abfragt).

ReWOO ist schneller. Selbst wenn ein Tool einen bestimmten Beweis nicht liefern kann, bleibt der ursprüngliche übergreifende Plan bestehen: Das Worker-Modul kann weiterarbeiten, und das Solver-Modul wird zumindest eine Teilantwort liefern können. Anstatt sich in einer Endlosschleife zu verfangen, in der eine Datenbank nach dem Wetter in Chicago abgefragt wird, würde das Solver-Modul zumindest eine Antwort zurückgeben, die den Benutzer über das Wetter in New York und Milwaukee informiert (vorausgesetzt, das Worker-Modul war in der Lage, diese Informationen abzurufen), was letztendlich für die Planung des Benutzers hilfreich sein könnte. 

Trotz der Vorteile von ReWOO ist es kein universell überlegenes Framework; es ist einfach besser für bestimmte Arten von Aufgaben geeignet, insbesondere wenn die Arten und Mengen der benötigten Beweise regelmäßig und vorhersehbar sind. Wo ReWOO jedoch zu kurz kommt, sind weniger vorhersehbare oder strukturierte Probleme, die Kreativität, Erkundung oder Improvisation erfordern. Bei bekannten Unbekannten ist ReWOO hervorragend, aber bei Unbekannten gerät es ins Wanken.

Beispielsweise wäre ReWOO nicht optimal für das Debuggen von Python-Code geeignet, da es sich um einen explorativen und iterativen Prozess handelt, bei dem jede Korrektur neue Fehler und Hinweise liefern kann und die besten Pläne schnell zunichte gemacht werden. Ein anpassungsfähigeres Framework wie ReAct wäre zwar abstrakt gesehen weniger token-effizient, würde aber letztendlich besser zu einem solchen Problem passen. 

Wie bei den meisten KI-Systemen und -Frameworks gibt es auch für die Implementierung von ReWOO-Workflows verschiedene Ansätze. Eine „offizielle“ Implementierung des Frameworks, das erstmals vom Forscher Binfeng Xu (zusammen mit seinen Kollegen im Jahr 2023[1]) beschrieben wurde, ist über Github verfügbar. Generative KI-Frameworks wie LangGraph (das seine Module als „Knoten“ bezeichnet) und das verwandte LangChain sind ebenfalls beliebt. Und eine mehrstufige Argumentationsmethodik im ReWOO-Stil ist auch mit IBM Granite verfügbar.

Man kann erste Schritte mit ReWOO auf konzeptioneller Ebene in jeder LLM-Umgebung mit einem gut ausgearbeiteten Prompt machen, der die KI dazu ermutigt, einen Schritt-für-Schritt-Plan zur Beantwortung weiterer Fragen zu erstellen, bevor man mit der Eingabe in das Tool fortfährt. 

Das Papier, das zunächst ReWOO beschreibt, enthält Beispiele für Prompts, darunter eines, das wie folgt beginnt: „Erstellen Sie für die folgende Aufgabe Pläne, die das Problem Schritt für Schritt lösen können. Geben Sie für jeden Plan an, welches externe Tool zusammen mit der Tool-Eingabe verwendet werden soll, um die Beweise abzurufen.“ Die Autoren der Studie fügen jedoch hinzu, dass „ReWOO ein allgemeines Paradigma ist und die Prompts nicht unbedingt festgelegt sind. Wir ermutigen Leser und Benutzer, die Prompts an ihre eigenen Bedürfnisse anzupassen.“ ¹