AdalFlow: Prompt-Optimierung als Trainingsschleife für LLM-Workflows

Das Problem: Prompts als handgetunte Strings

Die meisten LLM-Anwendungen entstehen heute als Kette aus Prompt-Strings, Retrieval-Schritten und Modellaufrufen. Der Prompt ist dabei ein Literal im Quelltext, das jemand nach Gefühl verändert. Es gibt keine Gradienten, keine Lernrate, keinen Trainingsschritt, nur Copy-Paste und einen Blick auf ein paar Beispielantworten. AdalFlow setzt genau dort an. Das README beschreibt die Bibliothek als PyTorch-ähnlich und verspricht, dass man sich vom manuellen Prompting verabschieden kann. Die Zielgruppe sind damit nicht Endanwender, sondern Entwickler, die bereits eine Pipeline besitzen und deren Qualität systematisch statt intuitiv verbessern wollen. Der Anspruch reicht von Chatbots über RAG bis zu Agenten, also über mehrere Aufgabenklassen hinweg, was für eine junge Bibliothek ein sehr breites Versprechen ist.

Wie die Optimierung mechanisch funktioniert

AdalFlow überträgt das Trainingsmodell aus dem Deep Learning auf Textbausteine. Ein Prompt ist kein konstanter String, sondern eine Struktur mit veränderbaren Teilen, die der Optimierer während des Trainings anpasst. Das README nennt zwei Verfahren: eine Zero-Shot-Optimierung und eine Few-Shot-Optimierung, die auf den eigenen Arbeiten LLM-AutoDiff und Learn-to-Reason Few-shot In Context Learning basieren. Der Ablauf folgt dem Muster aus dem Klassifikationsbeispiel im Repository: Ausgangsprompt definieren, Beispieldaten mit Labels bereitstellen, Optimierungslauf starten, optimierten Prompt verwenden. Die Retrieval-Seite ist davon getrennt und als eigener Baustein organisiert; die Topic-Liste des Repositories führt BM25, FAISS, Reranker und Retriever als separate Komponenten. Das bedeutet: Der Optimierer verbessert die Formulierung, nicht das Abrufen. Wer schlechte Dokumente in den Kontext schiebt, bekommt auch mit optimiertem Prompt schlechte Antworten.

Modellwechsel per Konfiguration, nicht per Refactoring

Ein zweiter Baustein ist die Modellunabhängigkeit. Das README formuliert es als Versprechen, die Anwendung per Konfiguration auf ein anderes Modell umzustellen. Sichtbar wird das an der Struktur der Modell-Clients: Im Agent-Beispiel wird OpenAIClient aus adalflow.components.model_client.openai_client importiert und zusammen mit model_kwargs wie model und temperature an den Agenten übergeben. Der Modellname und die Sampling-Parameter liegen also nicht im Prompt-Code, sondern daneben. Für Teams, die zwischen Anbietern vergleichen oder ein lokales Modell gegen ein gehostetes testen wollen, ist das der praktisch nützlichste Teil der Bibliothek. Es bleibt allerdings eine Abstraktion über unterschiedliche APIs, und solche Schichten können Parameter verlieren, die nur ein Anbieter kennt. Wie vollständig die Abbildung ist, lässt sich aus dem vorliegenden Material nicht beurteilen.

Installation und der erste Agent in Code

Die Installation ist einzeilig: pip install adalflow. Der Agent selbst wird deklarativ aufgebaut. Im README-Beispiel entsteht ein Agent aus name, einer Liste von tools, einem model_client, model_kwargs und max_steps. Die Tools sind gewöhnliche Python-Funktionen mit Docstring und Typannotation, etwa calculator(expression: str), web_search(query: str) oder ein Generator counter(limit: int), der ToolCallActivityRunItem-Objekte yieldet und am Ende die gesammelten Ausgaben ausgibt. Ausgeführt wird das Ganze über Runner(agent=agent) mit runner.call(prompt_kwargs={"input_str": ...}), wobei prompt_kwargs den Eingabetext trägt und das Ergebnis als RunnerResult mit result.answer und der vollständigen Ausführungshistorie zurückkommt. Bemerkenswert ist, dass asynchrone Tools im Beispiel vorgesehen sind: web_search ist als async def deklariert und wartet intern mit asyncio.sleep. Wer seine Tools synchron schreibt, verliert diesen Parallelisierungspfad, ohne dass die Bibliothek das erzwingt.

Wo die Bibliothek an ihre Grenzen stößt

Der Optimierer braucht eine Metrik. Ohne eine bewertbare Größe, die pro Beispiel eine Zahl liefert, kann kein Trainingslauf entscheiden, welche Prompt-Variante besser ist. Für Klassifikation ist das offensichtlich, für eine offene Zusammenfassung oder einen Dialog wird es schwierig, weil die Qualität nicht ohne Weiteres in einen Skalar passt. Das README zeigt das Optimierungsbeispiel in der Abbildung classification_opt_prompt, also im Klassifikationskontext. Wer eine solche Metrik nicht hat, muss sie erst bauen, und dieser Aufwand fällt vor dem ersten Optimierungslauf an, nicht danach. Ein zweiter Punkt: Das README bewirbt Tracing und Human-in-the-Loop als Funktionen ohne zusätzliche API, was bedeutet, dass der Betrieb beim Nutzer liegt. Wer einen gehosteten Trace-Dienst mit Weboberfläche erwartet, muss diese Infrastruktur selbst betreiben. Die im README genannten Genauigkeitswerte stammen aus den hauseigenen Papern; ob sie sich auf fremde Datensätze übertragen, ist damit nicht geklärt.

Abgrenzung zu LangChain und LlamaIndex

Der naheliegende Vergleich sind LangChain und LlamaIndex, und der Unterschied liegt nicht im Funktionsumfang, sondern im Zentrum der Bibliothek. LangChain organisiert eine Anwendung als Komposition aus Chains und seit LangChain Expression Language als deklarative Pipeline; der Prompt bleibt ein von Hand gepflegtes Objekt. LlamaIndex stellt das Indexieren und Abfragen von Dokumenten in den Mittelpunkt und liefert dafür fertige Abstraktionen. AdalFlow setzt den Schwerpunkt auf die Rückkopplung zwischen Evaluierung und Prompt: Der Prompt ist ein Parameter, der gegen eine Metrik optimiert wird. Das ist ein engerer, aber tieferer Anspruch. Wer viele verschiedene Integrationen braucht, ist bei den größeren Ökosystemen besser aufgehoben. Wer eine einzige Pipeline mehrfach verbessern will, findet hier den kürzeren Weg, weil kein Wechsel des Frameworks nötig ist, um den Optimierer zu nutzen.

Wartung, Releases und Lizenz

Die Release-Historie ist dicht: v1.1.1 im August 2025, v1.1.2 im August 2025, v1.1.3 im September 2025. Drei Patch-Releases innerhalb von rund sechs Wochen deuten auf aktive Pflege hin, bedeuten aber auch, dass sich APIs zwischen Minor-Versionen bewegen können. Wer AdalFlow produktiv einsetzt, sollte die Version pinnen und die Release Notes vor jedem Upgrade lesen, statt ungeprüft zu aktualisieren. Die Lizenz ist MIT, was die kommerzielle Nutzung und Modifikation erlaubt, sofern der Copyright-Hinweis erhalten bleibt. Eine rechtliche Bewertung ist das nicht; wer die Bibliothek in einem regulierten Umfeld einsetzt, muss die Lizenzbedingungen selbst prüfen. Ein Kostenfaktor, der leicht übersehen wird: Jeder Optimierungslauf verbraucht Modellaufrufe, und die Anzahl der Durchläufe skaliert mit der Zahl der Beispiele. Das ist ein laufender Posten, kein einmaliger.

Redaktionelles Fazit

Wer bereits eine RAG- oder Klassifikations-Pipeline mit festen Prompts betreibt und die Prompt-Qualität messbar machen will, findet in AdalFlow einen Optimierer, der sich in bestehenden Python-Code einhängen lässt. Wer dagegen einen fertigen, gehosteten Agenten mit Graph-Editor sucht, wird mit der Bibliothek nicht glücklich: Tracing und Human-in-the-Loop sind hier selbst zu betreibende Komponenten, kein Dienst. Vor dem ersten Commit sollte man prüfen, ob die eigene Evaluierungsmetrik als trainierbare Größe formulierbar ist, denn ohne sie läuft der Optimierer ins Leere. Und man sollte im eigenen Setup verifizieren, ob die im Repository dokumentierten Optimierungsgewinne auf das eigene Aufgabenformat übertragbar sind, da die Zahlen aus den begleitenden Papern stammen, nicht aus unabhängigen Läufen.

Offizielle Quellen

1. License: MIT
2. Project website
3. README
4. Releases
5. SylphAI-Inc/AdalFlow on GitHub