Gemini API ile mimari render analizi: görseli adım adım inceleme

Bu eğitimde ne öğreneceksiniz?

Bu rehber, mimari bir render’ı Gemini API’ye görselle birlikte gönderip modelden belirli bir inceleme istemenin temel akışını anlatıyor. Bir görüntüyü otomatik olarak onaylatmak yerine, görseldeki unsurları tarif ettirmek, görünen özellikleri sınıflandırmak veya render hakkında soru sormak hedefleniyor. Google’ın dokümantasyonu, Gemini modellerinin görsel açıklama, sınıflandırma ve görsel soru-cevap gibi çok modlu görevlerde kullanılabildiğini belirtiyor.

Mimarlık ve görselleştirme çalışmalarında bu yaklaşım; sahnede görünen öğeleri metne dökmek, sunum görselindeki belirgin özellikleri kontrol etmek veya render’ı tartışmaya açmak için yardımcı olabilir. Model yanıtı tasarım kararı ya da teknik doğrulama yerine geçmez. Çıktıyı, görsel üzerinden alınmış bir yardımcı değerlendirme olarak ele alın ve proje bilgileriyle karşılaştırın.

Gereksinimler

İş akışı Gemini API erişimi, bir görsel ve bu görsel için açık bir inceleme talimatı gerektirir. Kaynak dokümanda Python, JavaScript, Java, Go ve REST örnekleri yer alıyor. Örneklerde model kimliği gemini-3.8-flash olarak gösterilmiş; belirli bir SDK sürümü veya fiyat bilgisi verilmediği için burada bunlara ilişkin bir varsayım yapılmıyor.

Görseli üç yolla sağlayabilirsiniz:

• Herkese açık URL: Dokümantasyon, herkese açık görseller için URL yolunu uygun bir seçenek olarak listeliyor.

• Satır içi Base64: Görsel verisi metin girdisiyle birlikte isteğe ekleniyor. Toplam istek boyutu; metin istemleri, sistem talimatları ve görsel verisi dâhil 20 MB’ı aşmamalı.

• Files API: Büyük dosyalar veya aynı görselin birden fazla istekte kullanılacağı durumlar için dosya yüklenip dönen URI, MIME türüyle birlikte isteğe ekleniyor.

Kaynağın URL başlığı altındaki örneği de Files API ile yüklenen dosyanın URI’sini kullanıyor. Bu nedenle uygulamada seçilen gönderim biçiminin API dokümantasyonundaki güncel örneklerle uyuştuğunu kontrol edin. Satır içi yöntemde boyut sınırına yaklaşan dosyalar için dokümanın önerdiği Files API seçeneğini değerlendirin.

Adım adım mimari render incelemesi

1. İnceleme hedefini seçin. Önce render’a hangi soruyu yönelteceğinizi belirleyin. Genel bir “görseli analiz et” talebi yerine, görünen mekân öğeleri, aydınlatma izlenimi veya kompozisyon gibi belirli bir başlık seçin. Modelden görselde bulunmayan proje bilgilerini çıkarmasını beklemeyin.

2. Görseli uygun yöntemle iletin. Görsel herkese açık bir adreste bulunuyorsa URL seçeneğini değerlendirin. Küçük dosyalar için Base64 biçiminde satır içi veri kullanılabilir; bu yöntemde toplam istek boyutunun 20 MB sınırını aşmaması gerekir. Dosya büyükse veya aynı görseli yeniden kullanacaksanız Files API ile yükleyip URI’sini ve MIME türünü isteğe ekleyin. Her yöntemde metin talimatının ve görsel girdisinin aynı inceleme amacına hizmet etmesine dikkat edin.

3. İstemi açık ve sınırlı yazın. Google’ın istem tasarımı rehberi, talimatın net ve belirli olmasını, gerekiyorsa beklenen yanıt biçiminin tarif edilmesini öneriyor. Aşağıdaki özgün örnek, bir iç mekân render’ında yalnızca görünür öğelerin dökümünü istemek için hazırlandı:

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.

Bu istem, inceleme alanını sınırlar ve görünmeyen bilgilerin tahmin edilmemesini açıkça söyler. Yanıtı görselle ve proje dokümanlarıyla ayrıca karşılaştırın.

1. Görünen bir niteliği sınıflandırmasını isteyin. Seçenekleri önceden tanımlamak, sınıflandırma talebinin kapsamını anlaşılır kılar. Aşağıdaki örnek ışık izlenimini etiketletir; fiziksel aydınlık ölçümü istemez:

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.

Bu sınıflandırma, farklı görseller için aynı başlıklarla not oluşturmayı kolaylaştırabilir. Ancak yanıt, ışık hesabının veya render ayarlarının doğrulandığı anlamına gelmez.

1. Görsel hakkında belirli bir soru sorun. Görsel soru-cevap akışında, yanıtı gözlemlenebilir unsurlarla sınırlandırmak yararlıdır. Örneğin kompozisyonda öne çıkan alanı tarif ettirebilirsiniz:

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.

Modelin yorumu, izleyicilerin gerçek tepkisini ölçmez. Bu nedenle yanıtı kullanıcı araştırması sonucu veya kesin tasarım değerlendirmesi gibi sunmayın.

1. Yanıt biçimini belirtin ve sonucu gözden geçirin. İstem içinde kısa paragraf, maddeler veya belirli başlıklar istediğinizi yazabilirsiniz. Rehber, örneklerin de yanıtın biçimini yönlendirebileceğini ve istem tasarımının deneme-iyileştirme süreci olduğunu vurguluyor. İlk yanıt fazla genel kalırsa görevi daraltın; örneğin genel yorum yerine yalnızca görünen malzemeleri listelemesini isteyin.

Sık yapılan hatalar

• Belirsiz talimat vermek: “Render’ı değerlendir” ifadesi geniş bir görev tanımlar. İncelenecek özelliği ve yanıt biçimini belirtin.

• Görselden kesin teknik veri beklemek: Açıklama veya sınıflandırma, ölçüm raporu ya da proje modelinin doğrulanması değildir.

• Görünmeyen bilgiyi sormak: Görselde yer almayan malzeme markası, ölçü veya yapı sistemi için kesin yanıt beklemeyin. İstemde belirsizliğin açıkça belirtilmesini isteyin.

• Dosya yöntemini ihtiyaca göre seçmemek: Satır içi veride toplam istek için 20 MB sınırı bulunuyor. Büyük veya tekrar kullanılacak görseller için dokümanın Files API önerisini göz önünde bulundurun.

• Çıktıyı kontrol etmeden paylaşmak: Üretilen açıklamaları görselle karşılaştırın; temelsiz yorumları sunum veya proje notlarına doğrudan aktarmayın.

Mimarlık ve görselleştirme iş akışına etkisi

Bu yöntem, render’ları tarif etme ve ilk kontrol notlarını düzenleme aşamasında mimarlık ofislerine, iç mimarlara ve görselleştirme ekiplerine yardımcı olabilir. Aynı ölçütleri tekrar tekrar kullanmak isteyen ekipler istemlerini standartlaştırabilir. Görseli URL, Base64 veya Files API ile göndermek arasındaki seçim ise erişilebilirlik, dosya boyutu ve yeniden kullanım ihtiyacına bağlıdır.

API kullanımı mevcut render yazılımının yerine geçmez; kaynaklarda donanım gereksinimi ya da görselleştirme yazılımlarıyla uyumluluk bilgisi verilmiyor. Ekipler, API erişimini ve açıklanmamış maliyet koşullarını kullanıma geçmeden önce ayrıca değerlendirmeli. Model yanıtları tasarım ve teknik kararlar için tek dayanak olmamalı; görsel ve proje verileriyle kontrol edilmelidir.

Sonraki adımlar

İlk denemeyi tek bir render ve tek bir hedef soruyla yapın. Ardından aynı görsel için farklı ama açık istemler kullanarak yanıtların nasıl değiştiğini inceleyin. Birden fazla görseli karşılaştırırken aynı ölçütleri ve yanıt biçimini istemek sonuçları düzenlemeyi kolaylaştırabilir; yine de karşılaştırmayı görüntüde görülebilen bilgilerle sınırlı tutun.

Görseldeki nesneleri bulma veya bölgeleri ayırma gibi daha özel işler için dokümantasyon, belirli kullanım senaryolarında ek eğitimle doğruluğun artırılabildiğini belirtiyor. Bu ifade her mimari görüntüde aynı başarı düzeyinin sağlanacağı anlamına gelmez. İhtiyaç basit açıklama veya soru-cevap görevini aşıyorsa kullanılacak yöntemi ve elde edilen çıktıyı ayrıca doğrulayın.

Kaynak ve lisans

Bu eğitim, Google’ın Gemini API görsel anlama ve istem tasarımı dokümanlarından Türkçeye uyarlanmıştır. Her iki kaynak da CC BY 4.0 lisanslıdır. Buradaki mimari render istemleri, kaynaklardaki örneklerden kopyalanmadan özgün olarak hazırlanmıştır.