Metin, görsel, video, ses ve PDF — ilk kez tek bir vektör uzayında. Mart 2026'da yayınlanan model, AI altyapısının kurallarını yeniden yazıyor.
Bir metin sorgusuyla video içinde sahne aramak istediğinizde, şimdiye kadar önce o videoyu metne çevirmeniz gerekiyordu. Ayrı bir model, ayrı bir pipeline, ayrı bir maliyet kalemi. Google DeepMind'ın 10 Mart 2026'da public preview olarak yayınladığı Gemini Embedding 2, bu ara katmanları tek hamlede ortadan kaldıran ilk native multimodal embedding modeli.
Model adı "embedding" kelimesini taşıyor — ve bu, ChatGPT veya Gemini gibi üretken modellerden farklı bir kategori. Üretken modeller yeni içerik oluşturur; embedding modelleri ise mevcut verileri sayısal vektörlere dönüştürerek anlamlandırır, sınıflandırır ve aranabilir kılar.
Gemini Embedding 2, metin, görsel, video, ses ve PDF verilerini tek bir 3.072 boyutlu vektör uzayına dönüştüren Google'ın ilk multimodal embedding modelidir. 100'den fazla dili destekler, Gemini mimarisi üzerine inşa edilmiştir ve Gemini API ile Vertex AI üzerinden public preview olarak kullanılabilir.
Daha önceki embedding modelleri yalnızca metinle çalışıyordu. Bir e-ticaret sitesinde ürün görsellerini, bir hukuk firmasında toplantı kayıtlarını, bir medya şirketinde video arşivini aranabilir kılmak istediğinizde her biri için ayrı bir model ve ayrı bir vektör veritabanı kurmanız gerekiyordu. Gemini Embedding 2, beş farklı veri türünü tek API çağrısında aynı vektör uzayına yerleştirerek bu fragmentasyonu sonlandırıyor. Erken erişim partnerlerinden gelen veriler, birleşik pipeline'ın bazı iş akışlarında gecikmeyi %70'e kadar azalttığını gösteriyor.
Bu rehberde modelin teknik kapasitesini, mevcut alternatiflere karşı konumunu, pratik geçiş stratejisini ve kendi iş akışınızda nasıl değerlendirebileceğinizi ele alıyoruz.
Önce Temeli Anlayalım: Embedding Nedir?
Google Fotoğraflar'da "deniz manzarası" yazdığınızda uygulama etiketlemediğiniz fotoğrafları bile bulur. Spotify bir şarkıyı bitirdiğinizde tarzı benzer ama hiç duymadığınız bir parça önerir. İkisinin ortak noktası embedding: veriyi — kelime, görsel, ses parçası fark etmez — anlamını koruyan sayısal vektörlere çevirmek.
Teknik olarak bir embedding modeli, girdiyi çok boyutlu bir uzayda bir noktaya yerleştirir. Anlamca birbirine yakın iki veri parçası bu uzayda da yakın noktalara düşer. "Kış lastiği" ile "kar lastiği" yazdığınızda bu iki ifade neredeyse aynı vektöre dönüşür — çünkü embedding modeli kelimeleri değil, taşıdıkları anlamı okuyor.
Somut bir senaryo: Bir e-ticaret sitesinde müşteri "mavi çizgili yazlık gömlek" yazıyor. Geleneksel anahtar kelime eşleşmesi yalnızca başlığında tam bu ifade geçen ürünleri getirir. Embedding tabanlı semantik arama ise ürün açıklamalarını, görselleri ve hatta müşteri yorumlarını anlam düzeyinde tarayarak "lacivert çubuklu kısa kollu gömlek" gibi eşleşmeleri de bulur.
Buraya kadar bahsettiğimiz her şey — Google Fotoğraflar'dan e-ticaret aramasına — metin tabanlı embedding'lerin yapabildiği işler. Problem şu: gerçek dünya verisinin büyük kısmı metin değil. Toplantı kayıtları ses, ürün demoları video, sözleşmeler PDF, kataloglar görsel ağırlıklı. Şimdiye kadar bu veri türlerinin her biri için ayrı bir embedding modeli, ayrı bir vektör veritabanı ve bunları birleştiren ayrı bir yazılım katmanı gerekiyordu. Gemini Embedding 2'nin kırdığı eşik tam olarak bu: beş farklı veri türü, tek model, tek vektör uzayı.
Bir sonraki bölümde bu modelin desteklediği veri türlerini, her birinin kapasitesini ve pratik limitlerini inceliyoruz.
Neden Önemli: Multimodal Embedding Neyi Değiştiriyor?
Spesifikasyonlar tek başına bir modeli önemli kılmaz — onu önemli kılan, var olan bir iş akışını ne kadar temelden değiştirdiğidir. Gemini Embedding 2'nin kırdığı şey bir hız rekoru değil; yıllardır kabul edilmiş bir mimari varsayım: "Her veri türü kendi modelini, kendi index'ini, kendi retrieval katmanını gerektirir."
Bunu somutlaştırmak için tipik bir kurumsal bilgi tabanı düşünün. Şirket içi wiki'de metin belgeler var, Confluence'da ekran görüntülü teknik dökümanlar, Google Drive'da toplantı kayıtları, Slack'te paylaşılan PDF raporlar. Bugüne kadar bu veriyi birleşik şekilde aranabilir kılmak istediğinizde her format için ayrı bir embedding modeli çalıştırmanız, her birinin çıktısını ayrı bir vektör veritabanında saklamanız ve arama sonuçlarını birleştiren bir "yapıştırıcı" katmanı yazmanız gerekiyordu.
Metin → text-embedding-3 → Pinecone index A. Görsel → CLIP → Pinecone index B. Ses → Whisper transkript → text-embedding-3 → Pinecone index A. Video → ffmpeg ile kare çıkarma → CLIP + transkript. Sonuçları birleştiren özel bir sıralama katmanı. Beş farklı model, üç farklı index, onlarca yapıştırıcı kod satırı.
Metin + görsel + ses + video + PDF → tek API çağrısı → tek vektör index'i. Ara dönüşüm katmanı yok. Transkripsiyon adımı yok. Sonuç birleştirme mantığı yok.
Bu sadeleşmenin ilk etkisi performansta görünüyor. Ses verisini önce metne çevirip sonra embed etmek, iki aşamalı bir gecikme yaratır — ve her dönüşüm adımında bilgi kaybolur. Bir müşteri hizmetleri çağrısındaki ses tonu, tereddüt anları, vurgu farklılıkları transkripsiyon sırasında silinir. Gemini Embedding 2, ses dalgalarını doğrudan vektöre dönüştürdüğü için bu kayıp ortadan kalkar. Google'ın erken erişim partneri Sparkonomy, bu yaklaşımla metin-görsel ve metin-video çiftlerinde semantik benzerlik skorlarını 0.4'ten 0.8'e çıkardığını raporladı.
İkinci etki maliyet ve karmaşıklıkta. Üç ayrı model lisansı, üç ayrı veritabanı maliyeti ve bunları birleştiren mühendislik saatleri tek bir API endpoint'inin arkasında kaybolur. Erken veriler bazı iş akışlarında gecikmenin %70'e kadar azaldığını gösteriyor — ama bence asıl kazanç gecikme değil, bakım yükünün düşmesi. Ayrı pipeline'lar demek ayrı hata noktaları, ayrı versiyon uyumsuzlukları, ayrı monitoring gereksinimleri demek. Tek model bunları tekilleştiriyor.
Retrieval-Augmented Generation (RAG) sistemleri için bu değişiklik özellikle kritik. Bir RAG pipeline'ı artık yalnızca metin parçaları değil, görseller, ses klipleri ve PDF sayfaları da dahil olmak üzere tüm bilgi formatlarını tek bir unified index üzerinden sorgulayabiliyor. Bu, AI sistemlerinin içeriği nasıl okuduğu konusundaki temel varsayımları değiştiriyor.
Dijital pazarlama perspektifinden de bir not: Google'ın kendi ürünlerinde embedding teknolojisini kullanma biçimi, aramanın geleceğine dair ipuçları taşır. Google Fotoğraflar, YouTube önerileri, Google Arama'nın semantik anlama katmanı — hepsi embedding'lerle çalışır. Google'ın kendi multimodal embedding kapasitesini bu kadar agresif şekilde geliştirmesi, arama sonuçlarının yakın gelecekte metin, görsel ve videoyu çok daha entegre biçimde değerlendireceğine dair güçlü bir sinyal. İçerik stratejisi kurarken yalnızca metin SEO'su düşünmek, resmin giderek küçülen bir parçasını optimize etmek anlamına gelebilir.
Rakiplerle Karşılaştırma: OpenAI, Cohere, Amazon Nova
Gemini Embedding 2 boşlukta çıkmadı. 2025 sonundan itibaren multimodal embedding alanı hızla kalabalıklaştı: Amazon, Aralık 2025'te Nova Multimodal Embeddings'i duyurdu; Cohere, embed-v4 ile kurumsal müşterilere yöneldi; OpenAI ise text-embedding-3 serisini geniş geliştirici tabanıyla domine etmeye devam ediyor. Karar vermek için bu modellerin neyi farklı yaptığını görmek gerekir.
| Model | Modalite | Maks. Boyut | MRL Desteği | Dil | Statü |
|---|---|---|---|---|---|
| Gemini Embedding 2 | Metin, görsel, video, ses, PDF | 3.072 | Var (768–3.072) | 100+ | Public Preview |
| Amazon Nova Multimodal | Metin, görsel, video, ses, doküman | 3.072 | Var (256–3.072) | 200+ | GA (Bedrock) |
| Cohere embed-v4 | Metin, görsel | 1.024 | Var | 100+ | GA |
| OpenAI text-embedding-3 | Yalnızca metin | 3.072 | Var | Çoklu | GA |
* Tablo, Mart 2026 itibarıyla kamuya açık dokümantasyonlara dayanmaktadır. Fiyatlar ve özellikler değişebilir.
Tablo bağlamı olmadan eksik kalır. Bu modellerin her biri farklı bir ekosistem için optimize edilmiş — doğru seçim, hangi modelin "en iyi" olduğuna değil, mevcut altyapınıza ve ihtiyaç duyduğunuz modalite genişliğine bağlı.
Dürüst not: Gemini Embedding 2 şu an public preview statüsünde — production SLA'sı henüz yok. Ayrıca önceki model (gemini-embedding-001) ile vektör uzayları uyumsuz: mevcut veritabanınızdaki vektörleri yeni modelle karşılaştıramazsınız, tüm veriyi yeniden embed etmeniz gerekir. Preview'dan GA'ya geçişte model davranışında değişiklikler olabilir. Kritik production sistemlerinde doğrudan geçiş yerine bir sonraki bölümde anlattığımız shadow index stratejisini değerlendirin.
Mart 2026 itibarıyla öne çıkan embedding modellerinin modalite desteği, boyut seçenekleri ve ekosistem konumlandırması.
Kısa özet: Multimodal genişlik + Google ekosistemi → Gemini Embedding 2. AWS altyapısı + GA güvencesi → Amazon Nova. Kurumsal metin arama + maliyet optimizasyonu → Cohere. Mevcut OpenAI entegrasyonu + yalnızca metin → text-embedding-3. Hiçbiri diğerini geçersiz kılmıyor — doğru seçim, mevcut yığınınıza ve öncelikli kullanım senaryonuza bağlı.
Mevcut Sisteminizden Geçiş: Bilmeniz Gerekenler
Yeni bir embedding modeline geçmek, bir kütüphaneyi güncellemek kadar basit değil. Vektör uzayları arasında uyumluluk yok — gemini-embedding-001 ile ürettiğiniz vektörleri gemini-embedding-2-preview ile ürettiğiniz vektörlerle aynı index'te karşılaştıramazsınız. Farklı koordinat sistemleri, farklı benzerlik dağılımları. Bu, her embedding model geçişinin temel gerçeği: tüm veri yeniden embed edilmeli.
Ama burada gözden kaçan bir risk daha var: similarity threshold drift. Mevcut RAG pipeline'ınızda "cosine similarity 0.6 üzeri sonuçları getir" gibi bir eşik kullanıyorsanız, yeni modelde aynı eşik farklı sonuçlar döndürecektir. Her model vektörleri latent uzayda farklı dağıtır — 0.6'da iyi çalışan filtre yeni modelde 0.7 gerektirebilir veya 0.55'e düşebilir. Eşikleri yeniden kalibre etmeden geçiş yapmak, retrieval kalitesinde sessiz bir bozulmaya yol açar.
Durumunuza göre iki farklı yol var:
Mevcut bir embedding altyapısından Gemini Embedding 2'ye güvenli geçiş için dört aşamalı bir yol haritası:
Production sisteminize dokunmayın. Arka planda çalışan bir batch job ile mevcut veri kümenizi gemini-embedding-2-preview üzerinden yeniden embed edin ve ayrı bir index'e yazın. Batch API kullanarak maliyeti yarıya indirebilirsiniz — gerçek zamanlı yanıt gerekmediği için bu aşamada batch yeterli.
Shadow index hazır olduğunda, production sorgularını iki index'e paralel gönderin. Eski index'ten dönen sonuçlarla yeni index'ten dönen sonuçları retrieval kalitesi metrikleriyle (precision@k, recall@k, MRR) karşılaştırın. Bu aşamada similarity threshold'larınızı yeniden kalibre edin — eski modelde 0.6 olan eşik yeni modelde hangi değere karşılık geliyor, bunu burada tespit edersiniz.
Sonuçlar tatmin ediciyse trafiği kademeli olarak yeni index'e kaydırın: %5 → %20 → %50 → %100. Her aşamada retrieval metriklerini ve kullanıcı davranış sinyallerini izleyin. Bir aşamada kalite düşüşü görürseniz hemen geri alabilirsiniz — eski index hâlâ aktif.
Yeni index %100 trafik altında en az bir hafta stabil çalıştıktan sonra eski index'i kapatın. Modelin preview'dan GA'ya geçiş tarihini takip edin — GA sürümünde vektör uzayında küçük değişiklikler olabilir, bu durumda tekrar embed gerekebilir.
Pratik not: Bu dört adım büyük veri kümeleri olan ekipler için tasarlanmış. Birkaç bin doküman ve görselden oluşan küçük-orta ölçekli bir bilgi tabanı yönetiyorsanız, shadow index yerine doğrudan yeni bir index oluşturup test etmek genellikle yeterli. AI geliştirici araçlarıyla prototipleme sürecini hızlandırmak da bu ölçekte mantıklı bir kısayol — tüm veriyi birkaç saat içinde yeniden embed edebilirsiniz.
Son bir uyarı: Gemini Embedding 2 şu an preview statüsünde. Google'ın preview → GA geçişlerinde model davranışında küçük ama ölçülebilir değişiklikler olabiliyor. GA duyurusunu beklemeyi tercih eden ve bu sürede mevcut text-embedding-3 veya gemini-embedding-001 altyapısını sürdüren ekiplerin bu kararı yanlış değil — özellikle kritik production sistemlerinde sabır, hız kazandırır.
Sıkça Sorulan Sorular
Embedding, veriyi — metin, görsel, ses fark etmez — anlamını koruyan sayısal vektörlere dönüştüren bir tekniktir. Bu vektörler çok boyutlu bir uzayda noktalar olarak temsil edilir; anlamca yakın veriler uzayda da birbirine yakın düşer. Pratik sonucu: anahtar kelime eşleşmesi yerine anlam düzeyinde arama yapabilirsiniz. Google Fotoğraflar'da "gün batımı" yazıp etiketlemediğiniz fotoğrafları bulmanız bu teknolojiyle çalışır.
Geleneksel embedding modelleri yalnızca tek bir veri türüyle — genellikle metin — çalışır. Multimodal embedding ise metin, görsel, video, ses ve dokümanları aynı vektör uzayına yerleştirir. Bu sayede bir metin sorgusuyla video içinde sahne arayabilir veya bir fotoğrafla anlamca benzer metinleri bulabilirsiniz. Ayrı model, ayrı index, ayrı birleştirme katmanı ihtiyacı ortadan kalkar.
Temel kullanım alanları: multimodal RAG sistemleri (metin + görsel + ses birlikte sorgulanır), cross-modal semantik arama (metin sorgusuyla video veya ses bulma), içerik sınıflandırma ve kümeleme, doküman zekâsı (PDF'lerin görsel düzeni dahil embed edilmesi) ve çok dilli arama (100+ dil desteği). E-ticaret ürün kataloğundan hukuk belge taramasına, müşteri hizmetleri çağrı analizinden medya arşiv aramasına kadar geniş bir yelpaze.
OpenAI'ın text-embedding-3 serisi yalnızca metinle çalışır — 3.072 boyutlu, yüksek kaliteli metin vektörleri üretir ama görsel, video veya ses desteği yoktur. Gemini Embedding 2 ise beş farklı veri türünü tek bir modelde, tek bir vektör uzayında işler. Metin-only ihtiyacınız varsa OpenAI hâlâ güçlü bir seçenek; multimodal aramaya ihtiyaç duyuyorsanız Gemini Embedding 2 bu kapasiteyi native olarak sunuyor.
Model, Gemini API ve Vertex AI üzerinden public preview olarak erişime açık. Model adı: gemini-embedding-2-preview. Python, Node.js ve Go SDK'ları mevcut. Ayrıca LangChain, LlamaIndex, Haystack, Weaviate, Qdrant, ChromaDB ve Pinecone entegrasyonları hazır. Fiyatlandırma: metin embedding'leri milyon token başına 0,20 $, Batch API ile bu fiyat %50 düşüyor.
RAG (Retrieval-Augmented Generation), bir büyük dil modelinin cevap üretmeden önce ilgili bilgiyi bir veri tabanından çekerek bağlam olarak kullanmasıdır. Embedding bu sürecin altyapısı: verileriniz vektörlere dönüştürülüp bir vektör veritabanına yazılır, kullanıcı sorgusu da vektöre çevrilir, en yakın vektörler bulunur ve bu bilgiler modele bağlam olarak verilir. Gemini Embedding 2 ile RAG pipeline'ları artık yalnızca metin değil, görsel, ses ve video parçalarını da bağlam olarak getirebilir.
MRL, Rus matruşka bebekleri gibi "iç içe" bilgi yerleştirme tekniğidir. Model, en kritik semantik bilgiyi vektörün ilk boyutlarına yoğunlaştırır — böylece 3.072 boyutlu bir vektörü 768'e kessek bile anlam büyük ölçüde korunur. Pratikte bu, depolama maliyetinizi dörtte bire indirirken arama kalitesinden neredeyse hiçbir şey kaybetmemenizi sağlar. Google'ın benchmark verilerine göre 768 ile 3.072 boyut arasındaki MTEB skor farkı yalnızca 0,18 puan.
Embedding modelleri, AI sistemlerinin dünyayı "anlama" biçiminin altyapısıdır — kullanıcının görmediği ama her semantik aramanın, her RAG sorgusunun, her öneri motorunun arkasında çalışan katman. Gemini Embedding 2, bu katmanı beş farklı veri türünü tek bir uzayda buluşturarak yeniden tanımlıyor.
Model henüz preview aşamasında ve sınırları var. Ama temsil ettiği yön net: ayrı modeller, ayrı pipeline'lar, ayrı index'ler döneminin sonu başladı. Sıfırdan proje kuruyorsanız bu modelle başlamak mantıklı. Mevcut altyapınız varsa shadow index stratejisiyle test edin. Henüz harekete geçmek istemiyorsanız bile bu alandaki gelişmeleri takip edin — çünkü multimodal embedding, yalnızca geliştirici araç kutusunu değil, arama motorlarının içeriği nasıl değerlendirdiğini de değiştirecek.
Embedding modellerinden semantik aramaya, teknik SEO'dan içerik mimarisine — birlikte düşünelim.
