Tutorial de edición en varias rondas con Nano Banana 2.1: 3 elementos que debes devolver para editar una imagen en 2 rondas consecutivas sin perder detalles

Nota del autor: Con un caso completo —«cambiar la corona por un gorro rojo y luego el corazón rosa por uno azul»— explicamos qué historial de conversación, imagen de la ronda anterior y firma de pensamiento hay que volver a enviar en cada ronda de edición con Nano Banana 2.1 para hacer cambios localizados sin perder los resultados anteriores.

Muchos desarrolladores se encuentran con el mismo problema la primera vez que usan gemini-nano-banana-2.1 para editar imágenes: la primera ronda queda muy bien, pero al intentar retocar un pequeño detalle en la segunda, el cambio anterior desaparece o se vuelve a dibujar toda la imagen con otro estilo. En este artículo explicamos cómo volver a enviar correctamente los datos en la edición de varias rondas con Nano Banana 2.1 para que puedas editar una imagen durante 2 rondas seguidas sin perder detalles.

Esto no es otro artículo de introducción a conceptos: presentamos un caso reproducible. En la primera ronda, cambiamos la corona de la cabeza del personaje por un gorro rojo. En la segunda, cambiamos solo el corazón rosa por uno azul y conservamos el gorro rojo. Incluimos el código completo de las dos solicitudes y explicamos qué datos hay que incluir en cada ronda.

Qué aprenderás: al terminar el artículo, entenderás cómo funciona la edición de varias rondas con Nano Banana 2.1, sabrás cuáles son los 3 elementos que debes volver a enviar en cada solicitud y podrás aplicar directamente el código para hacer ediciones localizadas consecutivas.

Aspectos clave de la edición en varias rondas con Nano Banana 2.1

Primero, aclaremos el concepto. Para describir con precisión la edición «nativa en varias rondas» de Nano Banana 2.1, es mejor hablar de «edición continua»: cada ronda es una solicitud de API independiente. El modelo parece «recordar» los cambios de la ronda anterior porque incluyes todo el contexto en la solicitud, no porque el servidor conserve la sesión por ti.

Por qué Nano Banana 2.1 «pierde detalles» al editar en varias rondas

El error más común es enviar en la segunda ronda solo la instrucción «cambia el corazón rosa a azul» junto con la imagen original. En ese caso, el modelo sigue viendo la imagen original con la corona, así que la conserva y desaparece el sombrero rojo de la primera ronda. Otro error es adjuntar únicamente la imagen de salida de la primera ronda, sin incluir el historial. Aunque el modelo recibe la versión con el sombrero rojo, no sabe que ese sombrero se cambió deliberadamente y que debe conservarse. Por eso, en la segunda ronda puede modificar sin querer su color o su forma.

La forma más fiable es devolver la interacción completa de la primera ronda como historial de la conversación: qué dijo el usuario, qué imagen devolvió el modelo y qué firma acompañaba la respuesta. La documentación oficial de Google describe así también los casos de edición de imágenes en varias rondas: el modelo prolonga el contexto de razonamiento mediante la firma incluida en el historial, de modo que solo modifica la parte que indicas.

Estructura de las solicitudes para editar en varias rondas con Nano Banana 2.1

El campo contents de la segunda solicitud es un arreglo ordenado cronológicamente que debe incluir, como mínimo, tres partes: el mensaje user de la primera ronda (imagen original e instrucción), la respuesta model de la primera ronda (con la imagen de salida y la firma) y la nueva instrucción user de la segunda ronda. Lo importante es reproducir «tal cual» la parte de la respuesta model. No extraigas solo la imagen en base64 para volver a montarla, porque es fácil que el campo de firma se pierda durante la conversión.

Guía rápida para la edición en varias rondas con Nano Banana 2.1

A continuación, usaremos Python y la biblioteca requests para llamar directamente al formato nativo generateContent de Gemini. No usamos el formato de chat compatible con OpenAI porque la edición en varias rondas requiere devolver la firma de pensamiento (thought signature) y las partes de imagen. El formato nativo conserva al máximo la estructura original de estos campos.

Lista de preparativos

Ejemplo mínimo: en la primera ronda, cambia la corona por un sombrero rojo

La primera ronda es una solicitud normal de edición de imágenes: un mensaje de usuario con la imagen original y las instrucciones. Lo importante es guardar completo el contenido devuelto por el modelo para usarlo en la siguiente ronda.

import base64, requests

BASE_URL = "https://api.apiyi.com/v1"  # Interfaz unificada de APIYI; consulta la documentación para conocer la ruta del formato nativo
API_KEY = "YOUR_API_KEY"
MODEL = "gemini-nano-banana-2.1"
URL = f"{BASE_URL}/models/{MODEL}:generateContent"
HEADERS = {"Authorization": f"Bearer {API_KEY}", "Content-Type": "application/json"}

img_b64 = base64.b64encode(open("origin.png", "rb").read()).decode()
user1 = {"role": "user", "parts": [
    {"inline_data": {"mime_type": "image/png", "data": img_b64}},
    {"text": "把角色头上的皇冠换成一顶红色的帽子，其他内容保持不变。"}]}

resp = requests.post(URL, headers=HEADERS, json={
    "contents": [user1],
    "generationConfig": {"responseModalities": ["TEXT", "IMAGE"]}}).json()
model1 = resp["candidates"][0]["content"]  # Guarda el objeto completo, incluidas la imagen y thoughtSignature

Lo más importante es la última línea: model1 toma directamente el objeto completo de candidates[0].content, no solo los datos de la imagen. Sus parts pueden incluir texto, imágenes y el campo thoughtSignature. Guardarlo tal cual evita que se pierda cualquiera de estos elementos.

Ejemplo completo: en la segunda ronda, cambia solo el corazón rosa a azul y conserva el sombrero rojo

La clave de la segunda ronda es construir contents: [user1, model1, user2]. El código completo de abajo incluye las dos llamadas, la comprobación de la firma y el guardado de la imagen; puedes ejecutarlo directamente.

import base64
import requests

BASE_URL = "https://api.apiyi.com/v1"  # Llamada a través de APIYI; consulta docs.apiyi.com para conocer la ruta del formato nativo
API_KEY = "YOUR_API_KEY"
MODEL = "gemini-nano-banana-2.1"
URL = f"{BASE_URL}/models/{MODEL}:generateContent"
HEADERS = {"Authorization": f"Bearer {API_KEY}", "Content-Type": "application/json"}
GEN_CONFIG = {"responseModalities": ["TEXT", "IMAGE"]}


def call(contents):
    """Envía una solicitud generateContent y devuelve el objeto content completo de la respuesta del modelo"""
    r = requests.post(URL, headers=HEADERS,
                      json={"contents": contents, "generationConfig": GEN_CONFIG},
                      timeout=180)
    r.raise_for_status()
    return r.json()["candidates"][0]["content"]


def save_image(content, path):
    """Extrae la imagen de la respuesta del modelo y la guarda"""
    for part in content.get("parts", []):
        data = part.get("inlineData") or part.get("inline_data")
        if data:
            open(path, "wb").write(base64.b64decode(data["data"]))
            return True
    return False


def has_signature(content):
    """Comprueba si la respuesta incluye una firma de pensamiento"""
    return any("thoughtSignature" in p or "thought_signature" in p
               for p in content.get("parts", []))


# ---------- Ronda 1: corona → sombrero rojo ----------
img_b64 = base64.b64encode(open("origin.png", "rb").read()).decode()
user1 = {"role": "user", "parts": [
    {"inline_data": {"mime_type": "image/png", "data": img_b64}},
    {"text": "Cambia la corona que lleva el personaje por un sombrero rojo y mantén todo lo demás sin cambios."}]}

model1 = call([user1])
save_image(model1, "round1_red_hat.png")
print("Firma presente en la ronda 1:", has_signature(model1))

# ---------- Ronda 2: corazón rosa → corazón azul; conserva el sombrero rojo ----------
user2 = {"role": "user", "parts": [
    {"text": "A partir de la imagen anterior, cambia solo el corazón rosa del pecho a color azul."
             "Mantén sin cambios el sombrero rojo y todos los demás detalles."}]}

# Clave: historial completo + model1 devuelto tal cual (incluye la imagen y la firma de la ronda anterior)
history = [user1, model1, user2]
model2 = call(history)
save_image(model2, "round2_blue_heart.png")
print("Firma presente en la ronda 2:", has_signature(model2))

# Para una tercera ronda, sigue añadiendo: history += [model2, user3]

🚀 Para empezar rápidamente: te recomendamos probar primero el código de las dos rondas de arriba con el crédito de prueba gratuito de APIYI en apiyi.com. Comprueba que el sombrero rojo siga en la imagen de round2 y que solo haya cambiado el color del corazón; después, intégralo en tu propio flujo de trabajo.

Cómo redactar la instrucción de la segunda ronda

Que la edición continua pueda «modificar solo una parte» depende también de cómo redactes la instrucción, además de la estructura que envías de vuelta. En la segunda ronda, recomendamos especificar tres cosas: sobre qué imagen se va a trabajar, qué parte hay que modificar y qué elementos deben mantenerse sin cambios. Por ejemplo, «Sobre la imagen anterior, cambia solo el corazón rosa por uno azul y conserva el sombrero rojo y los demás detalles tal como están» suele dar resultados mucho más consistentes que limitarse a decir «Cámbialo a azul».

Además, no vuelvas a adjuntar la imagen original en la segunda ronda. La imagen original ya está en user1. Si la incluyes otra vez en user2, es posible que el modelo la interprete como una nueva imagen de referencia y vuelva a la versión con la corona.

Comparación de tres formas de enviar el contexto en varias rondas de edición con Nano Banana 2.1

Para explicar por qué es imprescindible incluir «los tres elementos», vamos a comparar tres formas habituales de hacerlo. La siguiente tabla describe cualitativamente el comportamiento de cada una para que puedas identificar rápidamente cuál usa tu código.

Análisis de la comparación

Análisis de la forma A: su ventaja es que resulta muy fácil de implementar: cada ronda es una solicitud independiente. Sin embargo, el modelo no puede ver el resultado de la primera ronda, así que, en la práctica, vuelve a realizar una edición de una sola ronda. En cambio, reenviar el historial completo permite que en la segunda ronda el modelo continúe editando a partir del resultado de la primera.

Análisis de la forma B: esta forma ahorra espacio en la solicitud porque solo envía una imagen. Pero el modelo no tiene el contexto de que «el gorro rojo se añadió deliberadamente» ni recibe la firma, así que no se puede garantizar la consistencia de los detalles locales. Para diseños que requieren ajustes sucesivos, imágenes principales de productos para comercio electrónico y otros casos similares, la forma C sigue siendo la opción más fiable.

💡 Recomendación: si tu caso de uso requiere más de dos rondas de edición, te recomendamos adoptar directamente la forma C. Puedes ejecutar las tres formas con el mismo código en APIYI apiyi.com y comparar las imágenes resultantes; las diferencias se verán claramente.

Cómo elegir entre Nano Banana 2.1 y otros modelos de la misma serie

En APIYI hay varios modelos de la serie Nano Banana. La edición en varias rondas es una función avanzada de edición. La siguiente tabla te ayudará a elegir dentro de la misma serie.

Problemas frecuentes al editar en varias rondas con Nano Banana 2.1

En la práctica, la mayoría de los problemas en los que «se pierde un cambio» se deben a unas pocas causas recurrentes. Aquí tienes una lista ordenada por frecuencia para que puedas comprobar cada punto durante el diagnóstico.

1. Se pierde la firma: conviertes la respuesta del modelo a tu propia estructura de datos y luego la vuelves a ensamblar, pero cambian las mayúsculas y minúsculas de los nombres de los campos o los niveles de anidamiento. Como resultado, no se envía thoughtSignature. La solución es guardar y reenviar directamente el objeto content original.
2. El rol es incorrecto: marcas la respuesta del modelo de la primera ronda con el rol user. El modelo interpreta entonces su propia salida como una nueva imagen enviada por el usuario. La respuesta del modelo debe conservar role: model.
3. El orden está invertido: los elementos de contents deben estar ordenados cronológicamente: primero user1, luego model1 y, después, user2. No pongas la nueva indicación al principio.
4. Se mezclan formatos: usas un formato compatible con OpenAI en una ronda y cambias al formato nativo en la siguiente. La conversión de campos puede hacer que se pierda la firma. Se recomienda usar el formato nativo de Gemini durante todo el flujo de varias rondas.
5. El historial es demasiado largo: cuantas más rondas hay, más imágenes se incluyen en la solicitud, lo que aumenta tanto el tamaño como el tiempo de procesamiento. Si el flujo se prolonga más de dos o tres rondas, puedes considerar usar el resultado actual como una nueva imagen original en un punto clave y empezar un nuevo historial.

🎯 Recomendación técnica: durante el diagnóstico, imprime primero la estructura de parts de model1 para confirmar que el campo thoughtSignature está presente. Después, comprueba que la solicitud de la segunda ronda lo incluya exactamente tal como estaba. En el centro de documentación de APIYI apiyi.com encontrarás ejemplos de cómo ensamblar solicitudes con el formato nativo de Gemini y conversaciones de varias rondas para que puedas compararlos.

Preguntas frecuentes (FAQ)

Puntos clave de la edición en varias rondas con Nano Banana 2.1

• En esencia, es una edición continua: cada ronda es una solicitud independiente; el cliente mantiene el contexto al devolverlo.
• Hay tres elementos imprescindibles: el historial completo de la conversación, la imagen de salida de la ronda anterior y la firma de pensamiento.
• Devuelve el contenido de model tal cual: guarda directamente candidates[0].content para evitar que se pierda la firma.
• Usa el formato nativo: la estructura contents de generateContent es la más adecuada para devolver imágenes y firmas.
• Especifica claramente qué debe conservarse: en la segunda ronda, indica qué cambiar y qué debe permanecer igual para que las modificaciones localizadas sean más fiables.
• No vuelvas a adjuntar la imagen original: hacerlo en la segunda ronda puede hacer que el modelo vuelva a la versión anterior a los cambios.
• Validación de bajo costo: usa el crédito gratuito de APIYI, apiyi.com, para completar dos rondas antes de ponerlo en producción.

Resumen

Puntos clave de la edición en varias rondas con Nano Banana 2.1:

1. Mecanismo: la edición en varias rondas consiste en una edición continua cuyo contexto devuelve el cliente. La memoria automática del servidor no está verificada, así que no conviene depender de ella.
2. Contenido que se devuelve: la segunda solicitud debe incluir user1, model1 tal cual (con la imagen y la firma de pensamiento) y user2.
3. Consejos prácticos: usa siempre el formato nativo de Gemini, especifica en las indicaciones qué debe conservarse y no vuelvas a adjuntar la imagen original en una ronda nueva.

Con estos tres puntos, podrás reproducir de forma fiable ediciones consecutivas en dos rondas, como «cambiar la corona por un sombrero rojo y luego cambiar el corazón rosa por uno azul». También puedes ampliar la misma estructura a más rondas.

Te recomendamos validar rápidamente los resultados a través de APIYI, apiyi.com. La plataforma ofrece interfaces compatibles con OpenAI y con el formato nativo de Gemini. Con una sola clave API puedes invocar la serie Nano Banana y otros modelos populares. Se cobra según el uso, por lo que es ideal para hacer pruebas a pequeña escala antes de integrarla gradualmente en producción.

📚 Referencias

1. Documentación de Google Gemini API sobre generación y edición de imágenes: explicación oficial de la edición de imágenes en varias rondas
2. Enlace: ai.google.dev/gemini-api/docs/image-generation

3. Descripción: presenta la estructura de las solicitudes de edición de imágenes y cómo continuar la edición mediante una conversación

4. Documentación de Google Gemini API sobre las firmas de pensamiento: explicación del mecanismo thought signature

5. Enlace: ai.google.dev/gemini-api/docs/thought-signatures

6. Descripción: explica para qué sirven las firmas y cómo volver a enviarlas en solicitudes de varias rondas

7. Centro de documentación de APIYI: guías de desarrollo de la serie Nano Banana, guías para implementar conversaciones de varias rondas y guías para invocar el formato nativo de Gemini

8. Enlace: docs.apiyi.com
9. Descripción: incluye los endpoints de conexión, las rutas del formato nativo y ejemplos de cómo ensamblar el historial, que sirven de referencia para implementar el código de este artículo

Autor: Equipo técnico de APIYI
Consultas técnicas: Puedes contactarnos desde la página de inicio del sitio web de APIYI. Encontrarás más información para integrar la serie Nano Banana en el centro de documentación, en docs.apiyi.com.

Artículos relacionados

• Nano Banana 2 vs. 2.1 en renderizado de texto: comparación práctica de 5 grupos de pósteres y guía de selección: Todos dicen que Nano Banana 2.1 renderiza mejor el texto, ¿por qué algunos creen que la generación 2 es más precisa? Explícalo con 5 escenarios de póster reproducibles, criterios de aceptación y precios por llamada, indicando cuándo conviene cambiar y cuándo no.
• ¿Qué mejoras trae Nano Banana 2.1? Análisis de 6 grandes mejoras y comparación de rendimiento con Nano Banana Pro: Nano Banana 2.1 es una versión mejorada de Nano Banana 2 y ya supera a Nano Banana Pro en las puntuaciones oficiales de referencia, pero ¿realmente puede vencerlo en la generación de imágenes? Este artículo analiza seis mejoras clave, los datos de evaluaciones oficiales y de terceros, y ofrece recomendaciones para elegir entre Nano Banana 2.1 y Pro según el caso de uso.
• Análisis completo de precios de Nano Banana 2.1: 5 diferencias clave frente a Nano Banana 2 y cálculo del ahorro: Desglose de los precios de Nano Banana 2.1 según la página oficial de Google: el precio por imagen generada se reduce a la mitad, pero suben los precios de los tokens de entrada y de razonamiento, aumenta el consumo en 4K y se elimina la opción de 0,5K; incluye el coste por imagen en 1K/2K/4K, los precios por lotes, el punto de equilibrio y recomendaciones para la migración.
• ¿Una sola imagen engañó a 3 millones de personas? Tutorial en 2 pasos para crear imágenes turísticas satíricas de falso documental con IA usando GPT Image 2.5: Desglosa el video satírico de Wytse Koetse sobre París: primero usa gpt para redactar indicaciones estructuradas y luego usa gpt-image-2.5-sunburst o gemini-nano-banana-2.1 para crear en lote fotogramas pseudodocumentales con tono de «anuncio turístico falso».