⏱️ Lectura: 11 min
Cualquiera que haya escrito un paper académico conoce el mismo dolor: tenés la metodología clara en la cabeza, los resultados tabulados, la discusión redactada, pero la figura que debe explicar tu arquitectura se resiste. Abrís Inkscape, Figma, PowerPoint o matplotlib y empieza un ciclo interminable de alinear cajitas, elegir colores, reescribir etiquetas y pedir feedback a tus coautores. Las horas invertidas en diagramas rara vez se reconocen, pero son las que determinan si un revisor entiende tu contribución en treinta segundos o la descarta.
📑 En este artículo
En este contexto aparece PaperBanana, un proyecto open source desarrollado por investigadores de la Universidad de Pekín, Google Research y colaboradores, que propone automatizar la generación de ilustraciones académicas mediante un sistema multi-agente con modelos de lenguaje visual y generación de imágenes. La idea no es reemplazar al diseñador, sino producir borradores de alta calidad a partir del texto del método y una descripción de la figura, acelerando el ciclo de iteración.
Qué es PaperBanana
PaperBanana es un framework reference-driven que transforma contenido científico crudo en diagramas y gráficos de calidad publicable. Está descrito en un paper alojado en Hugging Face y se publicó bajo licencia Apache 2.0. La versión original nació dentro de Google Research como PaperVizAgent; este repositorio es un fork que continúa la evolución con foco en confiabilidad y diversidad de escenarios.
El núcleo del sistema son cinco agentes especializados que trabajan en pipeline, cada uno con una responsabilidad clara:
- Retriever Agent — identifica diagramas de referencia relevantes en una colección curada para guiar a los agentes siguientes. Es el paso que le da el carácter reference-driven al sistema.
- Planner Agent — traduce el contenido del método y la intención comunicativa en descripciones textuales detalladas, usando in-context learning con los ejemplos recuperados.
- Stylist Agent — refina las descripciones para que cumplan con estándares estéticos académicos, usando guías de estilo sintetizadas automáticamente.
- Visualizer Agent — transforma esas descripciones en imágenes reales mediante modelos generativos de última generación.
- Critic Agent — cierra un bucle de refinamiento iterativo con el Visualizer, criticando el resultado y pidiendo mejoras en varias rondas.
El resultado es un ciclo estructurado que emula el trabajo de un equipo creativo: alguien investiga referencias, alguien planifica, alguien estiliza, alguien dibuja y alguien revisa. Sobre esta base, el framework admite tareas de diagramas conceptuales y de gráficos de datos, con soporte para modelos de OpenAI, Anthropic, Google Gemini y cualquier proveedor compatible con OpenRouter.
Instalación
PaperBanana está escrito en Python 3.12 y se apoya en uv, el gestor de paquetes de Astral, para aislar dependencias. A continuación, los pasos comunes y las instrucciones específicas por sistema operativo.
Paso 1: clonar el repositorio
Este paso es idéntico en los tres sistemas operativos, asumiendo que tenés git instalado.
git clone https://github.com/dwzhu-pku/PaperBanana.git
cd PaperBananaPaso 2: instalar uv
uv reemplaza a pip, virtualenv y pip-tools con una sola herramienta escrita en Rust. La instalación cambia según el sistema.
Windows
powershell -ExecutionPolicy ByPass -c "irm https://astral.sh/uv/install.ps1 | iex"macOS
curl -LsSf https://astral.sh/uv/install.sh | shLinux
curl -LsSf https://astral.sh/uv/install.sh | shPaso 3: entorno virtual y dependencias
Una vez instalado uv, los comandos son prácticamente iguales en todos los sistemas, salvo cómo se activa el entorno virtual.
Windows (PowerShell)
uv venv
.venv\Scripts\activate
uv python install 3.12
uv pip install -r requirements.txtmacOS y Linux
uv venv
source .venv/bin/activate
uv python install 3.12
uv pip install -r requirements.txtPaso 4: configuración de credenciales
El framework necesita al menos una clave de API. Duplicá configs/model_config.template.yaml como configs/model_config.yaml (este último está ignorado por git) y completá los campos. No necesitás configurar todo: alcanza con una clave de Google Gemini o una de OpenRouter. Si ponés ambas, el sistema prefiere OpenRouter por enrutamiento flexible.
defaults:
main_model_name: "google/gemini-2.5-pro"
image_gen_model_name: "google/imagen-3"
api_keys:
google_api_key: "tu-clave-aqui"
# openrouter_api_key: "tu-clave-openrouter"Opcionalmente podés descargar el dataset PaperBananaBench desde Hugging Face y colocarlo en data/PaperBananaBench/. Si no lo hacés, el framework sigue funcionando, pero pierde la capacidad de few-shot del Retriever y la calidad de los primeros borradores puede bajar.
Uso básico
El primer ejemplo funcional es la interfaz de línea de comandos. Con el entorno activado, ejecutá:
python main.py \
--dataset_name "PaperBananaBench" \
--task_name "diagram" \
--split_name "test" \
--exp_mode "dev_full" \
--retrieval_setting "auto"Los parámetros controlan el pipeline:
- task_name —
diagrampara ilustraciones conceptuales,plotpara gráficos de datos. - exp_mode — determina qué agentes intervienen.
vanillagenera directo sin planificar,dev_plannerañade planificación,dev_fullcorre el pipeline completo con los cinco agentes. - retrieval_setting —
auto,manual,randomonone. Connonese salta el Retriever.
Si preferís la vía visual, el demo de Streamlit es el camino más corto:
streamlit run demo.pyLa interfaz tiene dos pestañas. En Generate Candidates pegás el método en Markdown y el caption de la figura, elegís cantidad de candidatos y rondas de crítica, y en paralelo se generan hasta veinte variantes con sus líneas de evolución visible. En Refine Image subís un diagrama existente, describís los cambios y obtenés una versión refinada a 2K o 4K.
Para una experiencia sin instalación alguna, el equipo publicó el demo en Hugging Face Spaces. Basta con ingresar tu clave de OpenRouter o Gemini, pegar el método y presionar generar.
Integración en proyectos reales
El escenario más común para un investigador o un equipo de R&D es integrar PaperBanana dentro de un flujo reproducible de escritura de papers. Imaginá un grupo que publica varios artículos por trimestre y que mantiene un repositorio con la metadata de cada figura en YAML o JSON; el objetivo es regenerar figuras automáticamente cuando cambia la arquitectura de un modelo o la configuración de un experimento.
Un patrón razonable es envolver la llamada al pipeline en un script orquestador. Supongamos que cada figura se describe con el texto del método y un caption:
import subprocess
import json
from pathlib import Path
def generate_figure(figure_id, method_text, caption, mode="dev_full"):
spec = {
"figure_id": figure_id,
"method": method_text,
"caption": caption,
}
spec_path = Path(f"tmp/{figure_id}.json")
spec_path.parent.mkdir(exist_ok=True)
spec_path.write_text(json.dumps(spec, ensure_ascii=False))
subprocess.run([
"python", "main.py",
"--task_name", "diagram",
"--exp_mode", mode,
"--retrieval_setting", "auto",
"--input_spec", str(spec_path),
], check=True)
figuras = json.loads(Path("paper/figures.json").read_text())
for f in figuras:
generate_figure(f["id"], f["method"], f["caption"])Con esta estructura podés versionar las descripciones de figuras junto al código del paper, disparar regeneraciones desde CI cuando cambia el método, y mantener un historial reproducible de qué prompt produjo qué imagen. El modo dev_planner_critic es buena opción cuando querés calidad alta sin el costo del Stylist completo.
Otro patrón útil es aprovechar la generación paralela. PaperBanana puede producir hasta veinte candidatos simultáneamente, lo que cambia la forma de trabajar: en vez de iterar manualmente, generás una batería grande, revisás los pipelines de evolución, descartás los peores y seleccionás uno o dos para refinar. Este enfoque aprovecha mejor el costo de las APIs de generación de imagen y se parece más a una selección editorial que a un proceso de diseño.
Si trabajás con proveedores que imponen límites de concurrencia, vale la pena usar OpenRouter y rotar entre modelos, o directamente configurar una clave con cuotas altas. El README advierte explícitamente que generar muchos candidatos en paralelo requiere infraestructura preparada para concurrencia.
Cuándo usarlo y cuándo no
PaperBanana es una herramienta potente, pero no resuelve todos los escenarios. Ser honesto sobre sus trade-offs ahorra frustraciones.
Tiene sentido usarlo cuando:
- Necesitás borradores rápidos de diagramas conceptuales para discutir con coautores antes de encargar la versión final.
- Trabajás con papers iterativos donde la arquitectura cambia seguido y rehacer figuras manualmente es costoso.
- Buscás explorar múltiples estilos visuales para la misma idea y comparar en paralelo.
- Querés aprovechar modelos de visión de frontera sin construir tu propio pipeline de agentes.
Probablemente no sea la herramienta indicada cuando:
- Necesitás gráficos editables en formato vectorial con precisión milimétrica. PaperBanana produce imágenes rasterizadas; para SVG editable existen otras opciones.
- Tu figura depende de datos exactos que deben ser matemáticamente precisos, como curvas de rendimiento o barras de error. Para plots estadísticos rigurosos seguís necesitando matplotlib, seaborn o ggplot.
- Tenés requisitos estrictos de accesibilidad, branding corporativo o cumplimiento gráfico que exigen control pixel a pixel.
- Operás sin conexión o en un entorno sin APIs externas. El framework depende de modelos en la nube.
El coste económico también importa. Cada ronda de Critic implica llamadas adicionales a modelos de visión y generación, y producir veinte candidatos con refinamiento puede acumular un ticket no trivial. Medir el gasto por figura y compararlo con el tiempo humano ahorrado es una decisión que depende de tu contexto.
Alternativas
El ecosistema de generación automática de figuras científicas está creciendo. Vale la pena conocer algunas referencias cercanas antes de adoptar PaperBanana:
- PaperVizAgent — la versión original publicada por Google Research que dio origen a PaperBanana. Útil como referencia del diseño inicial del pipeline.
- AutoFigure-Edit — proyecto de ResearAI enfocado en la edición automática de figuras existentes, complementario a la generación desde cero.
- Paper2Any — de OpenDCAI, explora la conversión directa de contenido de paper a diversos formatos visuales.
- Edit-Banana — del BIT-DataLab, orientado a figuras editables, algo que PaperBanana aún no cubre nativamente.
- PaperBanana-Pro — fork comunitario con soporte mejorado para chino y un pipeline más estable para usuarios finales.
Cada herramienta tiene un foco distinto: algunas priorizan edición, otras generación, otras soporte multilingüe. No hay un ganador universal; la elección depende de si tu cuello de botella está en crear figuras nuevas, editar las existentes o producir versiones en distintos idiomas.
Conclusión
PaperBanana representa un paso concreto hacia la automatización del trabajo visual en la investigación académica. Su diseño multi-agente es transparente, su licencia Apache 2.0 lo hace apto para uso profesional y su integración con múltiples proveedores de modelos lo vuelve flexible ante cambios en el ecosistema de IA. No resuelve todos los problemas de ilustración científica, pero sí recorta drásticamente el tiempo entre la idea y un primer borrador visual decente.
Para equipos de LATAM que publican en conferencias internacionales, adoptar este tipo de tooling puede equilibrar la cancha frente a grupos con diseñadores dedicados. La curva de entrada es corta, el stack es familiar para cualquier equipo Python y la ganancia en iteración es inmediata.
Podés explorar el código, clonar el proyecto o contribuir con issues y PRs en el Repositorio oficial en GitHub. Si querés probarlo sin instalar nada, el demo en Hugging Face Spaces es el camino más directo.
📱 ¿Te gusta este contenido? Únete a nuestro canal de Telegram @programacion donde publicamos a diario lo más relevante de tecnología, IA y desarrollo. Resúmenes rápidos, contenido fresco todos los días.
0 Comentarios