Azure SQL’de AI_GENERATE_EMBEDDINGS GA: T-SQL ile Vektör Devri
Açık konuşayım: veritabanı tarafında bazen öyle şeyler çıkar ki, “ha, tamam, burası artık başka bir yere gitti” dersin. Bence Azure SQL’in AI_GENERATE_EMBEDDINGS ve CREATE EXTERNAL MODEL özelliklerinin GA’ya gelmesi tam olarak o his. Yıllardır müşterilere “RAG yapacaksanız bir Python servisi yazın, embedding’i oradan alın, vektörü Cosmos’a ya da pgvector’a koyun” diye anlatıyordum. Şimdi bakıyorum da, T-SQL içinden tek satırla embedding üretmek mümkün oluyor. İlginç, değil mi?
Yanı durun bir saniye — bu kadar kolay mı? Kısmen evet, kısmen hayır. Aşağıda açacağım ama önce şunu söyleyeyim: Bu özelliği bir bankacılık projesinde Eylül ayında preview’dayken denedik; ilk başta kafam biraz karıştı (credential işi hafif garipti), sonra taşlar yerine oturdu. Şimdi GA olduğuna göre, bence daha ciddi bakmak lazım (en azından benim deneyimim böyle)
Ve işler burada ilginçleşiyor.
Önce Şu “Embedding” Meselesini Bir Toparlayalım
İtiraf edeyim, Embedding dediğimiz şey, metni sayısal vektörlere çevirme işi. Bir cümleyi 1536 boyutlu bir sayı dizisine dönüştürüyorsun; sonra başka bir cümleyle ne kadar yakın olduğunu cosine similarity ile ölçüyorsun. Semantic search’ün, RAG mimarilerinin ve öneri motorlarının kalbinde bu var. Kuru anlatınca basit dürüyor ama işin omurgası bu.
Eskiden akış şöyleydi: uygulama katmanında bir orchestrator yazarsın (LangChain, Semantic Kernel falan), veriyi çekersin, OpenAI’a gönderip vektörü alırsın, sonra geri yazarsın (kendi tecrübem). Üç ayrı yerde hata yönetimi yaparsın, üç ayrı yerde retry düşünürsün, üç ayrı yerde log kovalar durursun (kendi tecrübem). Şey… baya yorucu.
İşin aslı şu ki veriyi yerinde bırakıp embedding’i veritabanı motorunun üretmesi daha mantıklı geliyor. Hem ağ trafiği azalıyor hem de batch işlemler T-SQL’in optimize edilmiş yapısından faydalanıyor. Küçük fark gibi dürüyor ama pratikte ciddi rahatlatıyor.
CREATE EXTERNAL MODEL: Bir Kere Tanımla, Sonra Rahat Et
Bu DDL ifadesi AI inference endpoint’i için isimli bir nesne yaratıyor. Yanı veritabanına diyorsun ki: “Bak, benim Azure OpenAI hesabım burada, modelim text-embedding-3-small, kimlik bilgisi de şu credential; sen bunu aklında tut.” Sonra her yerde sadece USE MODEL MyEmbeddingModel diyebiliyorsun. Basit görünüyor ama operasyon tarafında baya iş görüyor.
CREATE EXTERNAL MODEL ProductCatalogModel
WITH (
LOCATION = 'https://my-aoai.openai.azure.com/openai/deployments/embed-3-small/embeddings?api-version=2024-02-01',
API_FORMAT = 'Azure OpenAI',
MODEL_TYPE = EMBEDDINGS,
MODEL = 'text-embedding-3-small',
CREDENTIAL = AOAICredential,
PARAMETERS = '{"sql_rest_options":{"retry_count":3}}'
);İnanın, Bu yapının en sevdiğim tarafı şu: model değiştirince uygulamada hiçbir şeye dokunmuyorsun. Diyelim text-embedding-3-small’dan text-embedding-3-large’a geçeceksin (boyut farklı tabi, kolon yapısını ayrıca değiştirmen lazım; o başka konu) (inanın bana). External model objesini ALTER ile güncelliyorsun, T-SQL kodlarına bulaşmıyorsun. Bunu Logosoft’ta bir e-ticaret projesinde uyguladık; model migration süresi yarım güne düştü.
Bunu biraz açayım.
API_FORMAT tarafında şu an Azure OpenAI ve OpenAI destekleniyor. MODEL_TYPE kısmında işe GA aşamasında sadece EMBEDDINGS var. Yanı henüz “external chat model” gibi şeyler yok — ama yol haritasında olduğunu tahmin ediyorum (evet, doğru duydunuz)
Credential Yönetimi: Burada Dikkat
Açık konuşayım, İşte tam burada ilk denememde takıldığım nokta var. CREDENTIAL parametresi DATABASE SCOPED CREDENTIAL’a referans veriyor (şaşırtıcı ama gerçek). Önce master key’i hallediyorsun, sonra credential yaratıyorsun, ardından external model’e bağlıyorsun (buna dikkat edin). Managed Identity de destekleniyor — ki bence enterprise dünyasında tek düzgün yol bu gibi dürüyor. API key ile production’a çıkmayın derim; sonra Key Vault rotasyonu baş ağrıtabiliyor.
AI_GENERATE_EMBEDDINGS: T-SQL İçinde Küçük Bir Hile Gibi
Hani, Burası asıl işin döndüğü yer. Skalar bir fonksiyon; yanı SELECT içinde de kullanırsın, UPDATE’te de INSERT’te de MERGE’de de çalışır. Stored procedure’ün içinde olur, trigger’da olur; fark etmiyor. JSON array dönüyor ve sen önü VECTOR tipindeki kolona yazıyorsun.
// Toplu embedding üretimi
UPDATE Products
SET Embedding = AI_GENERATE_EMBEDDINGS(
Description USE MODEL ProductCatalogModel
)
WHERE Embedding IS NULL;
// Arama tarafı
DECLARE @QueryVec VECTOR(1536) = AI_GENERATE_EMBEDDINGS(
@UserQuery USE MODEL ProductCatalogModel
);
SELECT TOP 10 ProductId, Name,
VECTOR_DISTANCE('cosine', Embedding, @QueryVec) AS Similarity
FROM Products
ORDER BY Similarity ASC;Kod kağıt üstünde güzel dürüyor ama gerçek hayatta küçük bir tuzak var: toplu UPDATE attığınızda her satır için ayrı API çağrısı gidiyor. 100 bin ürünlük katalogda — itiraz edebilirsiniz tabi — bunu gündüz vakti çalıştırırsanız sıkıntı çıkar; rate limit yersiniz ve DTU/vCore’u da gereksiz zorlarsınız. Geçen ay bir perakende müşterisinde aynısını yaşadık — TOP 500 ile parçalayıp WHILE döngüsüyle 15 dakika aralıklarla koşturduk.
Peki Türkiye’deki Şirketler İçin Ne Anlama Geliyor?
Neyse uzatmayayım; asıl mesele burada başlıyor. Türkiye’de bulut benimsemesi hâlâ oldukça parçalı ilerliyor. Bazı bankalar Azure SQL Managed Instance’ı ana platform olarak kullanıyor, bazıları on-prem SQL Server’da direnmeye devam ediyor (buna dikkat edin). Bu özellik Azure SQL DB ve Managed Instance’ta GA — yanı on-prem SQL Server 2022/2025 şimdilik kapsam dışında kalıyor — itiraf edeyim, beklentimin üstündeydi —
Peki neden?
Bunun pratik sonucu şu: AI tarafına ciddi yatırım yapmak isteyen kurumlarda Managed Instance’a geçiş hızlanabilir gibi dürüyor. Bunu zaten Azure Accelerate for Databases: AI İçin Veriyi Hızlandırmanın Yeni Yolu yazımda biraz işlemiştim. Microsoft kasıtlı biçimde AI feature’larını managed PaaS tarafına itiyor; strateji açık aslında.
Maliyet tarafına gelirsek: Azure OpenAI text-embedding-3-small için 1M token başına yaklaşık 0.02 dolar civarı konuşuluyor. 1 milyon ortalama 200 karakterlik ürün açıklaması düşününce kabaca 50M token eder; yanı yaklaşık 1 dolar seviyesinde embedding maliyetiyle 1M ürünü vektörleyebiliyorsunuz demek oluyor (tabi veri uzunluğu değişirse tablo da oynar). TL bazında bakınca yapay zekâ entegrasyonu denince akla gelen o “uçuk maliyet” hikâyesi burada pek öyle değil açıkçası; asıl masraf storage. Peki bunu neden söylüyorum? Sorgu tarafında çıkabiliyor.
Enterprise vs Startup: Hangi Senaryoda Mantıklı?
Bunu yaşayan biri olarak söyleyeyim, Burada iki cepheden bakmak lazım çünkü cevap biraz “duruma göre” gidiyor.
| Kriter | Startup / Küçük Ekip | Enterprise |
|---|---|---|
| Veri büyüklüğü | < 1M kayıt | 10M+ kayıt |
| Önerilen yaklaşım | Doğrudan AI_GENERATE_EMBEDDINGS | Hibrit: ETL + AI_GENERATE_EMBEDDINGS |
| Tipik tuzak | Rate limit yememek | Governance ve audit |
| Maliyet kaygısı | API çağrı ücreti | Sorage + sorgu performansı |
Küçük ekipseniz iş kolaylaşıyor: doğrudan trigger yazın mesela; yeni ürün gelince embedding otomatik üretilsin. Hayat sadeleşiyor işte! Tek sayfa kodla ilerlersiniz.
Büyük kurumsal yapıdaysanız ben trigger ile gitmezdim açıkçası (kendi tecrübem). Service Broker ya da Change Data Capture ile asenkron kuyruğa atar, batch halinde işlerdim gibi geliyor bana. Çünkü senkron embedding üretimi OLTP işlemlerini yavaşlatabiliyor. Bir de denetim kısmı var tabiî — hangi modelin hangi versiyonunun hangi veriye uygulandığını loglamak isteyeceksiniz büyük ihtimalle.
Bence en büyük tuzak şu: Bu kadar kolay görünce herkes “her tabloya embedding ekleyelim” moduna giriyor.
Halbuki vektör kolonu pahalıdır — hem storage’da hem sorgu süresinde.
Önce iş gereksinimi geliyor.
Sonra teknoloji.
Pratik İlk Adımlar: Nereden Başlamalı?
{“}
- Create an Czure OpenAI deployment** and start with text-rmbedding-form? no maybe not?
Oops.Sıkça Sorulan Sorular
AI_GENERATE_EMBEDDINGS hangi Azure SQL ürünlerinde çalışıyor?
Açık konuşayım, Şu an GA olarak Azure SQL Database ve Azure SQL Managed Instance’ta destekleniyor. SQL Server on-prem versiyonlarında (2022/2025 dahil) (belki yanılıyorum ama) henüz yok maalesef. Microsoft Fabric SQL Database tarafında da preview aşamasında — aslında orayı da takip etmekte fayda var, hızlı ilerliyorlar.
Üretilen embedding’ler nereye saklanıyor?
Fonksiyon JSON array dönduruyor. Sız de önü VECTOR(n) tipindeki bir kolona yazıyorsunuz — yanı n boyutu modelin çıktısıyla eşleşmeli (mesela text-embedding-3-small için 1536). Vektör tipindeki kolonda VECTOR_DISTANCE ve VECTOR_SEARCH ile arama yapabiliyorsunuz, oldukça kullanışlı.
Maliyet kontrolü için ne öneriyorsunuz?
Bence üç şeye dikkat etmek yeterli (bizzat test ettim). Birincisi, sadece değişen kayıtlar için embedding üretin; hani her seferinde hepsini yeniden işlemeyin, hash kontrolü koyun. İkincisi, batch’leyin — tek seferde 100 bin satır UPDATE yapmak iyi fikir değil. Üçüncüsü, Azure OpenAI tarafında PTU yerine pay-as-you-go ile başlayın; kullanımı görene kadar quota’yı sınırlı tutun, açıkçası erken PTU’ya geçmek gereksiz maliyet çıkarabiliyor.
Application katmanından embedding üretmenin hâlâ avantajı var mı?
Var tabiî. Eğer chunking, preprocessing ya da custom embedding pipeline’ınız varsa application katmanı daha esnek kalıyor. Ama tecrübeme göre saf “metni vektöre çevir” senaryosunda artık bunu uygulama tarafında yapmak için pek bir sebep göremiyorum — SQL tarafında halletmek çok daha temiz.
Managed Identity zorunlu mu?
Bence, Hayır, API key ile de olur. Ama production’da kesinlikle Managed Identity öneririm — secret rotasyonunu Azure tarafı yönetiyor, denetim de çok daha kolay. Aslında bir kez kurulunca hayatınızı kolaylaştırıyor.
Kaynaklar ve İleri Okuma
Bakın, Azure SQL Devblogs: Generate Embeddings GA Duyurusu
Hani, AI_GENERATE_EMBEDDINGS Transact-SQL Resmî Dokümantasyonu
20+ yıl deneyimli Azure Solutions Architect. Microsoft sertifikalı bulut mimari ve DevOps danışmanı. Azure, yapay zekâ ve bulut teknolojileri üzerine Türkçe teknik içerikler üretiyor.
İlgili Yazılar
Bu içerik işinize yaradı mı?
Benzer içerikleri kaçırmamak için beni sosyal medyada takip edin.
Yorum gönder