Analizar renders arquitectónicos con Gemini API: revisión paso a paso

¿Qué aprenderás en este tutorial?

Esta guía explica el flujo básico para enviar un render arquitectónico a Gemini API junto con una solicitud de análisis específica. El objetivo no es pedir una aprobación automática de la imagen, sino describir sus elementos, clasificar características visibles o hacer preguntas sobre el render. La documentación de Google indica que los modelos Gemini pueden utilizarse en tareas multimodales como la descripción y clasificación de imágenes y la respuesta a preguntas sobre ellas.

En arquitectura y visualización, este método puede ayudar a describir los elementos visibles de una escena, revisar características destacadas de una imagen de presentación o iniciar una conversación sobre un render. La respuesta del modelo no sustituye una decisión de diseño ni una validación técnica. Considérala una evaluación auxiliar de la imagen y contrástala con la información del proyecto.

Requisitos

Este flujo requiere acceso a Gemini API, una imagen y una instrucción de análisis clara. El documento fuente incluye ejemplos para Python, JavaScript, Java, Go y REST. En los ejemplos se muestra gemini-3.8-flash como identificador del modelo. Como no se proporciona información sobre una versión específica del SDK ni sobre precios, aquí no se hacen suposiciones al respecto.

Puedes proporcionar la imagen de tres maneras:

• URL pública: La documentación incluye la opción de URL como método adecuado para imágenes de acceso público.

• Base64 en línea: Los datos de la imagen se adjuntan a la solicitud junto con la entrada de texto. El tamaño total de la solicitud —incluidos los prompts de texto, las instrucciones del sistema y los datos de la imagen— no debe superar los 20 MB.

• Files API: Para archivos grandes o cuando se vaya a reutilizar la misma imagen en varias solicitudes, se carga el archivo y se añade a la solicitud el URI devuelto junto con el tipo MIME.

El ejemplo del documento fuente bajo el encabezado de URL también utiliza el URI de un archivo cargado mediante Files API. Por eso, comprueba que el método de envío elegido en tu implementación coincida con los ejemplos actuales de la documentación de la API. Si utilizas el método en línea y el archivo se acerca al límite de tamaño, considera Files API, la opción recomendada en la documentación.

Análisis paso a paso de un render arquitectónico

1. Define el objetivo del análisis. Decide primero qué quieres preguntar sobre el render. En lugar de una solicitud general como «analiza la imagen», elige un tema concreto, como los elementos visibles del espacio, la impresión que produce la iluminación o la composición. No esperes que el modelo deduzca información del proyecto que no aparezca en la imagen.

2. Envía la imagen con el método adecuado. Si el render está disponible en una dirección pública, considera la opción de URL. Para archivos pequeños puedes usar datos en línea en formato Base64; con este método, el tamaño total de la solicitud no debe superar los 20 MB. Si el archivo es grande o vas a reutilizar la imagen, súbela con Files API y añade a la solicitud su URI y tipo MIME. Con cualquier método, asegúrate de que la instrucción de texto y la imagen respondan al mismo objetivo de análisis.

3. Redacta una instrucción clara y acotada. La guía de diseño de prompts de Google recomienda que la instrucción sea clara y específica, y que describa el formato de respuesta esperado cuando sea necesario. El siguiente ejemplo original solicita una lista únicamente de los elementos visibles en un render de interiores:

Bu iç mekân render’ını incele. Yalnızca görüntüde açıkça seçilebilen mekân öğelerini listele: duvar, döşeme, mobilya, aydınlatma ve açıklıklar. Görselde olmayan bilgileri tahmin etme. Emin olmadığın noktaları “belirsiz” olarak belirt. Yanıtı kısa maddeler hâlinde ver.

Esta instrucción acota el análisis y especifica que no se deben inferir datos que no sean visibles. Contrasta también la respuesta con la imagen y la documentación del proyecto.

1. Pide que clasifique una característica visible. Definir las opciones de antemano ayuda a delimitar la tarea de clasificación. El siguiente ejemplo etiqueta la impresión de la iluminación; no solicita una medición física de la luz:

Görseldeki aydınlatma izlenimini şu seçeneklerden biriyle sınıflandır: doğal ışık baskın, yapay ışık baskın, dengeli veya belirsiz. Seçimini destekleyen, görüntüde görülebilen iki ipucu yaz. Ölçüm değeri verme.

Esta clasificación puede facilitar la creación de notas con los mismos criterios para distintas imágenes. Sin embargo, la respuesta no significa que se hayan validado los cálculos de iluminación ni los ajustes del render.

1. Haz una pregunta concreta sobre la imagen. En un flujo de preguntas y respuestas sobre imágenes, conviene limitar la respuesta a elementos observables. Por ejemplo, puedes pedir que describa el área que más destaca en la composición:

Bu mimari görselde izleyicinin dikkatini ilk çekmesi muhtemel alanı tarif et. Görüntüdeki konumunu ve bu yorumu destekleyen görünür kompozisyon öğelerini belirt. Tasarım niyeti hakkında çıkarım yapma.

La interpretación del modelo no mide la reacción real de los espectadores. Por tanto, no presentes la respuesta como resultado de una investigación con usuarios ni como una evaluación definitiva del diseño.

1. Especifica el formato de respuesta y revisa el resultado. En la instrucción puedes pedir un párrafo breve, una lista o encabezados específicos. La guía destaca que los ejemplos también pueden orientar el formato de la respuesta y que el diseño de prompts es un proceso de prueba y mejora. Si la primera respuesta es demasiado general, delimita la tarea; por ejemplo, pide que enumere únicamente los materiales visibles en lugar de hacer comentarios generales.

Errores frecuentes

• Dar instrucciones ambiguas: «Evalúa el render» plantea una tarea demasiado amplia. Especifica qué característica debe analizarse y en qué formato debe responder.

• Esperar datos técnicos precisos a partir de la imagen: Una descripción o clasificación no es un informe de medición ni una validación del modelo del proyecto.

• Preguntar por información que no es visible: No esperes una respuesta concluyente sobre marcas de materiales, dimensiones o sistemas constructivos que no aparezcan en la imagen. Pide explícitamente que indique cuándo hay incertidumbre.

• No elegir el método de envío según las necesidades: Los datos en línea tienen un límite de 20 MB para el tamaño total de la solicitud. Para imágenes grandes o que se vayan a reutilizar, ten en cuenta la recomendación de Files API de la documentación.

• Compartir el resultado sin revisarlo: Contrasta las descripciones generadas con la imagen y no incorpores directamente a presentaciones o notas del proyecto comentarios sin fundamento.

Implicaciones para los flujos de trabajo de arquitectura y visualización

Este método puede ayudar a estudios de arquitectura, interioristas y equipos de visualización a describir renders y organizar notas preliminares de revisión. Los equipos que quieran aplicar los mismos criterios de manera recurrente pueden estandarizar sus instrucciones. La elección entre enviar la imagen por URL, Base64 o Files API depende de su accesibilidad, tamaño y necesidad de reutilización.

El uso de la API no sustituye el software de renderizado existente; las fuentes no proporcionan información sobre requisitos de hardware ni compatibilidad con software de visualización. Antes de empezar a usarla, los equipos deben evaluar por separado el acceso a la API y las condiciones de costes que no se especifican. Las respuestas del modelo no deben ser la única base para decisiones de diseño o técnicas; hay que verificarlas con la imagen y los datos del proyecto.

Próximos pasos

Haz la primera prueba con un solo render y una pregunta concreta. Después, comprueba cómo cambian las respuestas al usar distintas instrucciones claras para la misma imagen. Al comparar varias imágenes, pedir los mismos criterios y el mismo formato de respuesta puede facilitar la organización de los resultados; aun así, limita la comparación a la información visible.

Para tareas más específicas, como detectar objetos en la imagen o segmentar regiones, la documentación señala que se puede mejorar la precisión mediante entrenamiento adicional en determinados casos de uso. Esto no significa que se obtendrá el mismo nivel de rendimiento con todas las imágenes arquitectónicas. Si la necesidad va más allá de una descripción sencilla o una pregunta y respuesta, valida por separado el método utilizado y los resultados obtenidos.

Fuentes y licencia

Este tutorial se ha adaptado al turco a partir de la documentación de Google sobre comprensión de imágenes con Gemini API y diseño de prompts. Ambas fuentes están licenciadas bajo CC BY 4.0. Los prompts arquitectónicos para renders que aparecen aquí se han creado originalmente y no se han copiado de los ejemplos de las fuentes.