PaperBanana: agentische Diagrammerzeugung für wissenschaftliche Arbeiten

Welches Problem PaperBanana adressiert

Wer eine Arbeit einreicht, verbringt oft mehr Zeit mit dem Methodendiagramm als mit dem Text, der es erklärt. Das Diagramm muss die Pipeline, die Datenflüsse und die Komponenten eines Systems in einer einzigen Abbildung verdichten, und genau diese Übersetzungsleistung von Prosa in Grafik ist der Engpass, den PaperBanana adressiert. Das Projekt bezeichnet sich als agentisches Framework zur Erzeugung publikationsreifer akademischer Diagramme und statistischer Plots aus Textbeschreibungen. Die Zielgruppe ist eng umrissen: Forschende, die ihre Methode bereits verschriftlicht haben und daraus einen visuellen Entwurf ableiten wollen. Der Einstiegspunkt ist entsprechend der Methodenabschnitt, nicht eine leere Leinwand. Wer eine Grafik von Grund auf selbst gestalten will, braucht das Werkzeug nicht. Wer dagegen ohnehin einen Absatz über sein System geschrieben hat, liefert genau das Eingabematerial, für das die Pipeline gebaut ist.

Zwei Phasen, mehrere Agenten

Die README beschreibt eine zweiphasige Multi-Agenten-Pipeline mit iterativer Verfeinerung. Das Eingabematerial besteht aus einem Methodentext und einer Bildunterschrift, aus denen die Pipeline eine Abbildung erzeugt. Zwischen Text und Bild sitzt eine Optimierungsschicht für die Eingabe, die laut README die Generierungsqualität verbessern soll. Die genaue Wirkungsweise dieser Schicht lässt sich aus dem vorliegenden Material nicht rekonstruieren, und die README benennt sie auch nicht im Detail. Was sich benennen lässt, ist die Arbeitsteilung der Modelle: Ein VLM übernimmt das Verstehen des Methodentexts, ein Bildmodell die Erzeugung der Grafik. Beide Rollen sind getrennt konfigurierbar, was in der Praxis bedeutet, dass Fehler in zwei verschiedenen Modellklassen auftreten können und die Fehlersuche entsprechend zweigeteilt ist. Der Modus auto-refine und die Fortsetzung eines Laufs mit Nutzerfeedback deuten darauf hin, dass die Pipeline nicht als Einzelschuss gedacht ist, sondern als Schleife, in der ein Entwurf bewertet und überarbeitet wird. Das ist der eigentliche Kern des Ansatzes: nicht ein Prompt, ein Bild, sondern ein Zyklus mit Rückkopplung.

Installation und die erste Generierung

Die Installation erfolgt über pip install paperbanana, für die Entwicklung aus dem Quellbaum mit pip install -e ".[dev,openai,google]". Voraussetzung ist Python 3.10 oder neuer sowie ein API-Schlüssel von OpenAI oder Google Gemini, wobei die README den Gemini-Zugang als kostenlose Option über Google AI Studio nennt. Die Konfiguration läuft über eine .env-Datei, die aus .env.example kopiert wird. Dort stehen die Schlüssel OPENAI_API_KEY und GOOGLE_API_KEY, für Azure OpenAI oder Foundry zusätzlich OPENAI_BASE_URL in der Form https://<resource>.openai.azure.com/openai/v1. Optional lassen sich GOOGLE_BASE_URL für einen Gemini-Proxy sowie GOOGLE_VLM_MODEL und GOOGLE_IMAGE_MODEL überschreiben. Ein Assistent für Gemini ist über paperbanana setup erreichbar. Der eigentliche Aufruf lautet paperbanana generate --input examples/sample_inputs/transformer_method.txt --caption "Overview of our encoder-decoder arc". Für Container gibt es ein Dockerfile; der Lauf mountet den Methodentext nach /work/method.txt und ein Ausgabeverzeichnis nach /work/outputs, der Schlüssel wird per -e GOOGLE_API_KEY durchgereicht. Bemerkenswert ist, dass die README für Diagramme und Plots getrennte Unterbefehle vorsieht: paperbanana plot-batch verarbeitet viele statistische Plots aus einem Manifest, wobei jedes Element auf eine CSV- oder JSON-Datei verweist.

Schnittstellen jenseits der Kommandozeile

PaperBanana ist nicht nur ein CLI-Werkzeug. Die README nennt drei weitere Zugänge: eine Python-API, einen MCP-Server für die IDE-Integration und ein lokales Gradio-Weboberfläche namens PaperBanana Studio, das über paperbanana studio gestartet wird und Diagramme, Plots, Evaluierung, Batch-Verarbeitung sowie einen Run-Browser abdeckt. Für Claude Code existieren Skills für /generate-diagram, /generate-plot und /evaluate-diagram. Der MCP-Server trägt den Namen io.github.llmsresearch/paperbanana. Diese Bandbreite an Einstiegspunkten ist ungewöhnlich für ein Forschungsprojekt und deutet darauf hin, dass die Autoren den Aufruf aus einer Editor- oder Notebook-Umgebung für den Normalfall halten, nicht den Aufruf aus einem Terminal. Ein Colab-Notebook führt laut README durch Installation, Schlüssel und Diagrammerzeugung ohne lokale Einrichtung. Wer den Dienst in eine bestehende Werkzeugkette einbetten will, hat damit mehrere Ansatzpunkte, muss aber auch mehrere Oberflächen pflegen, wenn sich die Konfiguration ändert.

Wo der Ansatz an seine Grenzen stößt

Die README enthält einen Hinweis, der für die Bewertung wichtiger ist als jede Funktionsliste: Das Projekt ist eine inoffizielle, von der Community getriebene Implementierung des Papers von Dawei Zhu, Rui Meng, Yale Song, Xiyu Wei, Sujian Li, Tomas Pfister und Jinsung Yoon. Es steht in keiner Verbindung zu den Originalautoren oder Google Research, und die Implementierung basiert auf dem öffentlich verfügbaren Paper, kann also vom Originalsystem abweichen. Wer Ergebnisse aus PaperBanana in einer Publikation verwendet, sollte diesen Unterschied kennen und die Ausgabe nicht als Reimplementierung eines referenzierten Systems ausgeben. Dazu kommt eine technische Grenze, die sich aus der Architektur ergibt: Das Ergebnis entsteht in einem Bildmodell, also als Rasterbild. Ein solches Bild lässt sich nicht so nachbearbeiten wie eine Vektorgrafik mit benannten Ebenen und editierbaren Textfeldern. Für einen ersten Entwurf, den man ohnehin neu zeichnet, ist das unproblematisch. Für eine Kameraversion, in der Schriftgrößen und Abstände exakt den Vorgaben entsprechen müssen, ist es der falsche Weg. Ein weiterer Punkt: Die Pipeline hängt an externen Modellendpunkten. Ohne gültigen Schlüssel und ohne Netzwerkzugang zu OpenAI, Azure, Gemini oder Atlas Cloud passiert nichts, und die README nennt keine lokale Inferenzoption.

Abgrenzung zu Diagramm-als-Code

Die naheliegende Alternative ist der Diagramm-als-Code-Ansatz, also TikZ, Graphviz oder Mermaid, bei dem die Grafik aus einer textuellen Beschreibung deterministisch erzeugt wird. Der Unterschied liegt nicht im Komfort, sondern in der Reproduzierbarkeit. Ein TikZ-Dokument liefert bei jedem Lauf dasselbe Ergebnis, lässt sich versionieren und über einen Diff vergleichen. PaperBanana liefert bei jedem Lauf ein neues Bild, weil ein generatives Modell beteiligt ist. Für Anwendungsfälle, in denen ein Diagramm über zwanzig Überarbeitungen hinweg stabil bleiben soll, ist der Code-Ansatz überlegen. Der Vorteil von PaperBanana liegt woanders: Es verlangt keine Layout-Sprache. Wer TikZ schreibt, muss Knoten, Kanten und Koordinaten selbst platzieren. PaperBanana nimmt stattdessen den Methodentext und die Bildunterschrift, also Material, das beim Schreiben ohnehin entsteht. Das ist ein anderer Ausgangspunkt, und er passt zu explorativen Phasen, in denen noch nicht klar ist, welche Struktur die Abbildung überhaupt zeigen soll. Sobald die Struktur feststeht, ist der Wechsel zu einer deklarativen Beschreibung oft der günstigere Weg.

Lizenz und Pflegeaufwand

Das Projekt steht unter der MIT-Lizenz, was die Einbettung in eigene Werkzeuge und die kommerzielle Nutzung erlaubt, solange der Lizenztext und der Urheberrechtshinweis erhalten bleiben. Das ist eine der permissivsten gängigen Lizenzen, und sie bringt keine Copyleft-Verpflichtung für abgeleitete Werke mit sich. Ein Hinweis darauf, dass dies keine Rechtsberatung ist: Wer PaperBanana in ein Produkt einbettet, sollte die Lizenzbedingungen selbst prüfen, insbesondere im Zusammenspiel mit den Nutzungsbedingungen der Modellanbieter, die hier nicht Teil der Lizenz sind. Zum Pflegeaufwand gibt die Repository-Struktur einige Anhaltspunkte. Die letzten Releases sind v0.3.0 vom 12. Juni 2026, v0.2.0 vom 11. Juni 2026 und ein Datensatz-Mirror namens bench-data-v1, ebenfalls vom 11. Juni 2026. Zwei Releases an aufeinanderfolgenden Tagen deuten auf eine Phase rascher Änderungen hin. Der letzte Push datiert vom 9. September 2026, also rund drei Monate nach den Releases. Diese Zahlen belegen Aktivität, aber sie sagen nichts über die Stabilität der Schnittstellen. Wer die Python-API oder den MCP-Server einbindet, sollte damit rechnen, dass sich Signaturen zwischen Minor-Versionen verschieben. Die Optionalextras sind ein weiterer Kostenfaktor: PDF-Eingaben erfordern die Erweiterung paperbanana[pdf] mit PyMuPDF, die getrennt installiert werden muss und deren Abhängigkeiten bei einem Upgrade mitwandern.

Für wen sich der Einsatz lohnt

Der stärkste Anwendungsfall ist der frühe Entwurf. Ein Methodenabsatz liegt vor, eine Bildunterschrift ist formuliert, und man will sehen, wie eine Abbildung aussehen könnte, bevor man Stunden in die manuelle Gestaltung steckt. Dafür ist der Batch-Modus über ein YAML- oder JSON-Manifest nützlich, weil er mehrere Diagramme in einem Lauf erzeugt und den Vergleich ermöglicht. Auch die Einbindung über den MCP-Server in eine IDE ist plausibel, wenn der Arbeitsablauf ohnehin im Editor stattfindet. Weniger geeignet ist das Werkzeug für Arbeiten, die bereits eine feste Abbildungssprache verwenden, und für alles, was ohne externen Modellaufruf laufen muss. Die README nennt keine lokale Inferenz, also bleibt jeder Lauf von einem Schlüssel und einem erreichbaren Endpunkt abhängig. Wer die Ausgabe in einer Veröffentlichung verwendet, sollte den Hinweis auf die fehlende Verbindung zum Originalsystem ernst nehmen und die Grafik nach den eigenen Qualitätsmaßstäben prüfen, statt sich auf die Bezeichnung publikationsreif zu verlassen.

Redaktionelles Fazit

Sinnvoll ist PaperBanana für Forschende, die ihre Methodenabschnitte bereits als Text vorliegen haben und daraus schnell erste Diagrammentwürfe brauchen, sowie für Teams, die den MCP-Server in ihre IDE einbinden wollen. Wer exakte Vektorgrafik mit reproduzierbarem Layout für eine Kameraversion benötigt, ist hier falsch, weil das Ergebnis ein generiertes Rasterbild ist. Prüfe vor dem Einsatz zuerst die tatsächliche Modellbelegung in deiner .env (GOOGLE_VLM_MODEL, GOOGLE_IMAGE_MODEL, OPENAI_BASE_URL) und ob dein Endpunkt die in der README genannten Modellnamen akzeptiert, denn davon hängt ab, ob die Pipeline überhaupt startet.

Offizielle Quellen

1. Issues
2. License: MIT
3. llmsresearch/paperbanana on GitHub
4. README
5. Releases