Azure SQL’de AI_GENERATE_EMBEDDINGS GA Oldu: Saha Notları

Geçen Salı sabahı, Logosoft’taki ofiste kahvemi yeni almıştım ki bir bankacılık müşterimizden mesaj geldi: “Aşkın Bey, biz bu RAG meselesini SQL tarafında halletsek ölür mu? Embedding pipeline’ı için ayrı bir Python servisi kuracağız. Bakım derdi olacak.” Mesajı okuyunca gülümsedim. Çünkü tam o sabah Microsoft’un duyurusunu görmüştüm, hani bazen denk geliyor ya, insanın eline cevap kendiliğinden düşüyor; cevabım da kısa öldü: “Artık ölür. Hem de T-SQL’in içinden.”

Size bir şey söyleyeyim, İşin aslı şu ki, Azure SQL Database ve Azure SQL Managed Instance üzerinde AI_GENERATE_EMBEDDINGS ve CREATE EXTERNAL MODEL resmî olarak GA öldü. Yanı preview etiketi kalktı, production tarafında kullanabiliyorsunuz. Güzel haber, evet. Ama dür bir saniye — bu işin rahat kısmı burada bitiyor gıbı; model seçimi, çağrı sınırları ve maliyet tarafını yine gözünüzün ucuyla takıp etmeniz gerekiyor.

Olay Aslında Ne? Sade Bir Anlatımla

Bakın şimdi, klasik bir RAG (Retrieval-Augmented Generation) kurulumunda ne yapıyorduk? Veritabanından metni çekiyorduk, sonra Python ya da.NET tarafında bir servise yolluyorduk, o servis Azure OpenAI’a gidiyordu, dönen vektörü tekrar veritabanına basıyorduk. Üç-dört hop var burada. Her hop ayrı dert, her hop ayrı gecikme.

Bir şey dikkatimi çekti: İşin güzel tarafı şu: bu yapı artık tek satıra kadar inebiliyor. Evet, bayağı bu kadar sadeleşiyor. Modeli bir kere tanımlıyorsun, sonra SQL’in içinde çağırıp embedding’i doğrudan kolona yazdırıyorsun; arada ekstra bir API katmanı yok, orchestration kodu yok, “bugün neden patladı?” diye bakacağın ayrı bir işçi süreç de yok.

İşte tam da bu noktada devreye giriyor.

Şöyle düşünün:

-- Modeli bir kere tanımlıyorsun
CREATE EXTERNAL MODEL MyEmbeddingModel
WITH (
LOCATION = 'https://my-aoai.openai.azure.com/openai/deployments/text-embedding-3-small/embeddings',
API_FORMAT = 'Azure OpenAI',
MODEL_TYPE = EMBEDDINGS,
MODEL = 'text-embedding-3-small',
CREDENTIAL = MyAOAICredential
);
-- Sonra istediğin yerde çağırıyorsun
UPDATE docs
SET docs.embedding = AI_GENERATE_EMBEDDINGS(docs.content USE MODEL MyEmbeddingModel)
FROM documents AS docs;

Aslında, Hepsi bu. Ne ayrı servis var ne de araya giren fazla bir katman. SQL motoru gidip embedding’i alıyor ve VECTOR tipindeki kolona yazıyor; açık konuşayım, ilk gördüğümde “tamam ya, iş görüyor” dedim.

İki Parça, Tek Boru Hattı

CREATE EXTERNAL MODEL, bildiğiniz DDL ifadesi gıbı çalışıyor. Yanı veritabanında kalıcı bir nesne oluşturuyor. Bir kere tanımlıyorsunuz, sonra defalarca kullanıyorsunuz. Lokasyonu içinde tutuyor, API formatını saklıyor (şu an Azure OpenAI ve OpenAI destekleniyor), model tipini belirtiyor (GA tarafında şimdilik sadece EMBEDDINGS var) ve kimlik doğrulamayı da yanında taşıyor.

Tuhaf ama, AI_GENERATE_EMBEDDINGS işe scalar bir fonksiyon. SELECT’te kullanırsınız, INSERT’te kullanırsınız, UPDATE’te ölür, MERGE’te ölür; yanı nereye koyarsanız orada çalışıyor (yanlış duymadınız). Stored procedure içinde de yürür, trigger’da da. nvarchar, varchar, nchar, char gıbı herhangi bir karakter ifadesini alıyor ve sonucu JSON dizi olarak dönüyor.

Peki neden?

Emin değilim ama sanırım en kilit fark şu: işi uygulama katmanından alıp verinin yanına getiriyor — itiraf edeyim, beklentimin üstündeydi —. Hani ne farkı var diyorsunuz, değil mi? Güzel fikir gıbı duruyor ama dür bir saniye — bunun bedeli de var tabii; yetkilendirme düzeni doğru kurulmazsa ya da model çağrıları gereksiz yere artarsa maliyet tarafı sessizce şişebiliyor.

Neyse uzatmayalım. Mantık net: daha az parça, daha az hoplama zıplama, biraz daha temiz akış.

Neden Önemli? “Pipeline Yorgunluğu” Diye Bir Şey Var

2023 sonunda, bir e-ticaret müşterisinde benzer bir RAG pipeline’ı kurmuştuk. Ürün açıklamaları için embedding üretiyorduk. Mimarı kabaca şuydu: Azure SQL, Service Bus, Azure Function, Azure OpenAI ve sonra tekrar SQL. Beş bileşen var, beş ayrı log kaynağı var, beş ayrı IAM ayarı var; işte insanı yoran taraf da tam burada başlıyor.

İlk üç ay fena gitmedi. Sonra Function timeout’ları patladı. Ardından Service Bus dead-letter kuyruğu doldu, peşinden de “embedding’ler neden bu sabah güncellenmemiş?” toplantıları başladı. Hani derler ya, her ek parça bir ekstra dert çıkarır diye — biraz sert. Açık konuşayım, bu senaryoda baya doğru çıktı.

Çok konuştum, örnekle göstereyim.

“Veriyi taşımadan, veriye gel” prensibi yıllardır vardı ama AI çağında biraz arka planda kalmıştı. Bu kabiliyetin o fikri geri getiriyor. Sessizce yapıyor bunu.

Açık konuşayım, Şimdi aynı sistemi bugün kursam ne yaparım? Tek UPDATE deyimiyle geçerim. Bitti gitti. Tabi her şey pürüzsüz değil; öyle olsa zaten konuşacak konu kalmazdı. Birazdan eksik taraflarına da geleceğim.

Adım Adım: İlk Embedding’ınızı Üretmek

Pratikte iş nasıl yürüyor, önü anlatayım. AZ-305’e çalışırken bile bu kadar iç içe bir kurgu görmemiştim; baya farklı bir his veriyor, hatta ilk bakışta biraz “bu gerçekten SQL mi?” dedirtiyor.

1. Credential’ı Hazırla

Önce Azure OpenAI endpoint’inize erişmek için bir DATABASE SCOPED CREDENTIAL lazım. Managed Identity kullanmanızı ben açık konuşayım daha mantıklı buluyorum, çünkü key-based auth tarafı artık biraz eski kafa kalıyor; hani çalışır mı, çalışır ama uğraştırır.

CREATE DATABASE SCOPED CREDENTIAL MyAOAICredential
WITH IDENTITY = 'Managed Identity', SECRET = '{"resourceid":"https://cognitiveservices.azure.com"}';

Tabi burada Azure SQL’in System-Assigned Managed Identity’sine, Azure OpenAI kaynağında “Cognitive Services OpenAI User” rolünü vermeyi de unutmayın. Ben geçen bunu atladım, 20 dakika boyunca ekrana bakıp “401 Unauthorized” mesajını izledim; yanı bazen sorun kodda değil, yetkide oluyor.

2. Modeli Tanımla

Yukarıda değindim ama bir kez daha söyleyeyim: LOCATION kısmına deployment URL’ını tam yazmanız gerekiyor. Sadece resource URL’i yetmiyor, deployment’a kadar inmeniz lazım; yoksa sistem beklediğiniz modeli bulamıyor, işin aslı bu kadar basit.

3. VECTOR Kolonu Ekle

ALTER TABLE documents
ADD embedding VECTOR(1536); — text-embedding-3-small için 1536 boyut

VECTOR tipi de yeni sayılır, ama idare eder bir tarafı var: kalıcı duruyor, indekslenebiliyor ve JSON içinde saklamaya göre çok daha temiz çalışıyor. Hatta şey, burada küçük gıbı görünen fark performansta baya hissediliyor.

4. Embedding Üret ve Sorgula

-- Üretim
UPDATE documents
SET embedding = AI_GENERATE_EMBEDDINGS(content USE MODEL MyEmbeddingModel)
WHERE embedding IS NULL;
-- Benzerlik araması
DECLARE @query VECTOR(1536) = AI_GENERATE_EMBEDDINGS(N'fatura iadesi nasıl yapılır' USE MODEL MyEmbeddingModel);
SELECT TOP 5 id, content, VECTOR_DISTANCE('cosine', embedding, @query) AS distance
FROM documents
ORDER BY distance ASC;

İşte kritik kısım burası. RAG’in retrieval tarafı bayağı SQL’in içine taşınıyor; güzel tarafı bu,. Dür bir saniye — LLM’e prompt gönderme işi hâlâ uygulama katmanında kalıyor. Yanı embedding üretimi ve vektör araması tek yerde toplanıyor, öte yandan cevap üretimi için dışarı çıkmanız gerekiyor.

İşte tam da bu noktada devreye giriyor.

Evet.

Türkiye’deki Şirketler İçin Ne Anlama Geliyor?

Açık konuşayım. Türkiye’de kurumsal tarafta en çok takıldığım yerlerden biri hep aynıydı: AI işi açılınca bir anda “tamam, ama bunun yanına bir sürü ek parça mı koyacağız?” sorusu geliyor. Bir bankaya gidip “Python servisi kuracağız, container’ları AKS’te çalıştıracağız, Service Bus ile orkestre edeceğiz” dediğiniz an, güvenlik ekibinin bakışı değişiyor; çünkü her yeni bileşen demek, yeni bir penetration test, yeni bir compliance dokümanı ve bir de CAB toplantısı demek, yanı iş uzuyor da uzuyor. Az Privilege AI Agent: Curity ve Microsoft’tan azd Şablonu yazımızda bu konuya da değinmiştik. Daha fazla bilgi için Claude Sonnet 4 GitHub Copilot’ta Emekli Oldu: Geçiş Rehberi yazımıza bakabilirsiniz.

Şahsen, Şimdi tablo biraz farklı. Müşteri zaten Azure SQL kullanıyorsa — ki çoğu kullanıyor — bu özellik mevcut güvenlik perimetresinin içinde kalıyor. Yeni bir attack surface çıkmıyor ortalığa. Bu detay, KVKK ve BDDK denetimi olan kurumlarda baya işe yarıyor. Geçen ay bir sigorta şirketinde tam bu yüzden projeyi 3 hafta erkene çektik.

İşte tam da bu noktada devreye giriyor.

Evet.

Bir de yetenek tarafı var, önü da es geçmeyeyim. Türkiye’de SQL bilen geliştirici sayısı, “modern AI pipeline” kuran geliştirici sayısından çok daha fazla; hatta arada öyle az buz fark yok. Yanı ekipteki kıdemli DBA’ınız, RAG mimarisinin yarısını kendi başına toparlayabiliyor (şey, hepsini değil belki. Büyük kısmını), bu da hem bordroda rahatlatıyor hem de teslim tarihini daha az ağrılı hâle getiriyor.

Kısacası, peki neden? Bu konuyla ilgili Mailbox Import/Export Graph API’leri GA: EWS’e Veda Vakti yazımıza da göz atmanızı tavsiye ederim. Bu konuyla ilgili Agent Pull Request’leri Her Yerde: Doğru Review Nasıl? yazımıza da göz atmanızı tavsiye ederim.

Enterprise mı, Startup mı? Karar Matrisi

Her özelliğin oturduğu yer farklı, bunu baştan kabul etmek lazım. Ben meseleye şöyle bakıyorum: önce işin temposu, sonra veri hacmi, en sonda da operasyonel yük; (ben de ilk duyduğumda şaşırmıştım). Tahmin eder mısınız? Bazen hızlı gitmek daha kıymetli oluyor, bazen de gece yarısı kilitlenen bir SQL transaction yüzünden bütün plan dağılıyor.

Senaryo	Önerim	Sebep
Küçük startup, hızlı prototip	AI_GENERATE_EMBEDDINGS	Tek altyapı, hızlı go-to-market
Kurumsal, milyonlarca doküman	Hibrit (batch için ayrı pipeline)	SQL transaction süresi uzar, kilitlenme riski
Real-time, kullanıcı sorgusu	AI_GENERATE_EMBEDDINGS	Inline çalışıyor, ek hop yok
Multi-modal (resim+metin)	Harici pipeline	Şu an sadece text embedding destekli

Şöyle söyleyeyim, Mesela küçük bir startup tarafında ben çoğu zaman AI_GENERATE_EMBEDDINGS’e daha sıcak bakıyorum; çünkü tek akışla ilerlemek insanı rahatlatıyor (buna dikkat edin). Bir bakıma, ama dür bir saniye — kurumsalda iş değişiyor, doküman sayısı büyüyünce aynı yöntemi her yere yaymak pek tatlı sonuç vermiyor.

Bakın, burayı atlarsanız yazının kalanı anlamsız kalır.

Hibrit yaklaşım burada baya iş görüyor. Batch tarafını ayrı bir pipeline’a almak, SQL transaction’ı gereksiz uzatmamak ve kilitlenme riskini azaltmak iyi fikir gıbı duruyor; tabi bu da “tek yerde topladık bitti” kolaylığını biraz bozuyor.

Kısacası, peki neden?

Çünkü real-time senaryoda inline çalışan bir yapı daha az sürpriz çıkarıyor. Kullanıcı sorgusu geldiğinde ekstra hop olmaması güzel şey. Çok fazla veriyle uğraşıyorsanız, işin aslı o kadar düz değil.

Multi-modal tarafta işe tablo netleşiyor. Resim + metin birlikte geliyorsa harici pipeline’a dönmek gerekiyor, çünkü şu an destek metin embedding ile sınırlı; yanı biraz idare eder,. Her senaryoya yetmiyor.

Evet.

Kısacası sihirli değnek falan değil bu. Senaryonuza bakacaksınız, veri hacmini tartacaksınız ve “bunu gerçekten canlıda nasıl taşıyacağım?” diye soracaksınız; yoksa kağıt üstünde iyi duran kararlar production’da çabuk tökezliyor.

Maliyet Tarafı: TL Bazında Düşününce

Embedding üretimi bedava değil. Azure OpenAI tarafında text-embedding-3-small modeli için 1M token başına yaklaşık 0.02 USD ödüyorsunuz, Kasım 2025 kurlarıyla bu da kabaca 0.85 TL ediyor; kulağa komik derecede düşük geliyor, değil mi?

Ama işin rengi biraz değişiyor. Bir müşterimizde dört milyon ürün açıklaması vardı, ortalama 200 token civarıydı; toplamda 800 milyon token yapıyor, yanı yaklaşık 16 USD, TL karşılığı da ~680 TL. Tek seferlikti, evet, fena değil (bizzat test ettim) Handoff Orchestration: Ajanlar Birbirine Topu Atınca Ne yazımızda bu konuya da değinmiştik.

Sorun başka yerde çıkıyor aslında. Ürün açıklamaları güncellendikçe embedding’i de yenilemek gerekiyor; eğer her UPDATE’te AI_GENERATE_EMBEDDINGS‘i çağırırsanız, gereksiz token yakarsınız (hem de boş yere), o yüzden trigger yazarken biraz temkinli olmak lazım:

• Sadece content kolonu değiştiyse embedding’i yenile
• Hash karşılaştırması yap, içerik aynıysa direkt geç
• Batch update’lerde transaction’ı küçük tut — büyük UPDATE’ler embedding API’sine yüzlerce çağrı yaptırır ve transaction kilidi uzar

Kısacası, size bir şey söyleyeyim, Bir de retry işi var. PARAMETERS ile retry_count ayarlayabiliyorsunuz: '{"sql_rest_options":{"retry_count":3}}'. Ben açıkçası 3’ü biraz az buluyorum, 5’e çekiyorum. Neden önemli bu? Azure OpenAI’ın 429 (rate limit) hatası verme huyu var, özellikle peak saatlerde, hani tam ihtiyaç anında insanı yokluyor (bu beni çok şaşırttı)

Karşılaştığım İlk Sorun: Token Limit Patlaması

İlk denemede başıma geldi. Geçen Çarşamba, net hatırlıyorum; 50 bin satırlık bir tabloya tek UPDATE attım ve iş yarıda kaldı, çünkü content alanı token sınırını zorluyordu, sonra da bildiğiniz patladı.

Token limit exceeded hatası çıktı. Kısa hikâye bu. Her satırdaki içerik 8K token sınırını aşıyordu,. Sistem daha başlamadan duvara tosladı; hani bazen işin en masum görünen kısmı asıl problemi çıkarır ya, tam öyle bir durum.

Çözüm var mı? Var gıbı. İki yoldan biriyle halledilebiliyor: (ciddiyim)

1. Chunking: Uzun metinleri uygulama katmanında parçalara bölün, her chunk için ayrı embedding üretin. Sonra arama sırasında ya ortalamasını alırsınız ya da en yakın olanı bulursunuz; biraz uğraştırıyor ama düzgün yol bu.
2. Filtreleme: LEFT(content, 6000) ile metni kırpın. Evet, kalite biraz düşüyor. Ama çalışıyor; bazen mesele zaten budur.

İlginç olan şu ki, İkincisi quick&dirty. Açık konuşayım, production tarafında ben ilkini tercih ederim; çünkü kırpma işi kısa vadede rahatlatıyor. Uzun vadede sızı sessizce köşeye sıkıştırabiliyor, özellikle de içerik çeşitlenince tablo garipleşiyor.

Neyse, çok dağıtmayayım. Bu konuyu Bankacılıkta Customer 360: Azure DocumentDB ile Pratik Yol yazımda da kısmen ele almıştım — orada DocumentDB özelinde benzer bir chunking yaklaşımından bahsetmiştim, yanı mevzu yeni değil ama burada can sıkan detay farklı.

Eksik Kalan Şeyler — Dürüst Olalım

Yazıyı öyle pazarlama broşürü gıbı parlatmak istemem. Bu kabiliyetin doğru tarafta duran bir adım, tamam, ama işin içinde hâlâ boş kalan yerler var:

Küçük bir detay: Birinçisi: Şu an sadece embedding modelleri destekleniyor. Chat completion tarafı, yanı LLM çağrıları, yok. Dolayısıyla hâlâ “prompt at, cevap al” kısmı için uygulama katmanına dönmeniz gerekiyor. Peki neden? Çünkü o parça henüz masaya gelmemiş gıbı duruyor, ya da ben öyle okuyorum; biraz beklemek gerekecek sanırım.

İkincisi: Provider listesi şimdilik dar. Azure OpenAI ve OpenAI var, başka da yok. Hugging Face yok, Cohere yok, Anthropıc de yok; hani bazı müşteriler maliyet yüzünden açık kaynak modellere kayıyor ya, işte onlar için bu özellik şu an pek anlamlı değil.

Üçüncüsü: Batch embedding API desteği yok. Bak şimdi, Azure OpenAI’ın batch API’si daha düşük maliyetle iş görüyor ama bu fonksiyon önü kullanmıyor; küçük işlerde çok göze batmaz belki ama büyük migrasyonlarda insanın canını sıkar, çünkü farkı direkt cüzdanda hissedersiniz.

Yine de kötülemeyeyim. Kağıt üstünde kalan bir fikir olmaktan çıkıp GA’ya gelmesi bile ayrı mesele. Bekleyelim biraz; pişecek gıbı duruyor.

Pratik İlk Adımlar: Bugün Ne Yapmalısınız?

Eğer bu özelliği denemek istiyorsanız, lafı gevelemeden başlayın.

1. Bir test Azure SQL Database oluşturun. Basic tier iş görür, 5 USD/ay civarı yeterli oluyor.
2. Bir Azure OpenAI kaynağı deploy edin, sonra text-embedding-3-small modelini seçin; burada işi büyütmeye gerek yok. — bunu es geçmeyin
3. Managed Identity’yi aktif edin ve OpenAI tarafında rolü verin. Bu kısım küçük görünüyor ama çoğu kişi burada takılıyor. (bu kritik)
4. Yukarıdaki kod örneklerini sırayla çalıştırın, önce basit akışı görün, sonra detaylara girersiniz.
5. 10-20 satırlık küçük bir tabloyla başlayın; scale etmeyi şimdilik kenara koyun, çünkü erken büyütme bazen sadece kafa karıştırıyor. (bence en önemlisi)

SQL ve MCP ekosistemi de hızla gelişiyor, şey yanı işin üçü baya açılıyor; bu bağlamda SQL MCP Server’ı App Service’te Çalıştırmak: Container’siz yazıma da bakmanızı tavsiye ederim. Python tarafıyla ilgileniyorsanız mssql-python’da Apache Arrow Desteği: Sahadan Notlar da bu yazıyla iyi gidiyor, hatta yan yana okuyunca bazı parçalar daha net oturuyor (buna dikkat edin)

Sıkça Sorulan Sorular

AI_GENERATE_EMBEDDINGS sadece Azure OpenAI ile mi çalışıyor?

Daha açık söyleyeyim, bir şey dikkatimi çekti: Hayır, OpenAI’ın public API’si de destekleniyor. API_FORMAT parametresinde ‘OpenAI’ seçeneğini seçmen yeterli. Ama aslında şu an için bu iki sağlayıcı dışında resmî destek yok. Mesela Hugging Face veya Cohere gıbı sağlayıcılar için harici bir pipeline kurman gerekiyor.

SQL Server on-premises’te de bu özellik var mı?

Bunu yaşayan biri olarak söyleyeyim, Şu anlık hayır (yanlış duymadınız). GA duyurusu yalnızca Azure SQL Database ve Azure SQL Managed Instance için yapıldı. SQL Server 2025 ile on-prem desteğinin geleceği konuşuluyor, ama henüz net bir tarih yok. Hibrit ortamlarda bu fonksiyona ihtiyaç varsa, açıkçası ilgili veritabanlarını cloud’a taşımayı düşünebilirsin.

İşte tam da bu noktada devreye giriyor.

VECTOR_DISTANCE ile VECTOR_SEARCH arasındaki fark nedir?

VECTOR_DISTANCE, iki vektör arasındaki uzaklığı — yanı cosine, euclidean gıbı metrikleri — hesaplayan scalar bir fonksiyon. Tablo üzerinde brute-force tarama yapıyor. VECTOR_SEARCH işe indeks destekli, milyonlarca satırda performanslı arama için tasarlanmış daha üst seviye bir API. Bence kısa özet şu: küçük tablolarda VECTOR_DISTANCE gayet yeter, büyük tablolarda VECTOR_SEARCH şart.

Embedding maliyetleri nasıl kontrol altında tutulur?

Dürüst olmak gerekirse, Temel olarak üç yöntem var. Birinçisi, içerik hash’i tutup değişmemişse yeniden çağrı yapmamak. İkincisi, Azure OpenAI tarafında TPM (token per minute) limitini iş yüküne göre ayarlamak. Üçüncüsü işe Azure Cost Management’ta budget alert kurmak. Tecrübeme göre aylık tahmini maliyetin %80’inde uyarı alacak şekilde ayarlamak en mantıklısı — böylece sürprizle karşılaşmıyorsun.

Bu özellik geleneksel full-text search’ün yerini alır mı?

Tamamen almıyor, hani öyle sihirli bir çözüm değil. Vektör araması “anlamsal” benzerlik için harika,. Tam eşleşme veya filtreleme söz konusu olunca full-text search hâlâ çok güçlü. Bence en iyi sonuç ikisini hibrit kullanmaktan geliyor: önce full-text ile dar bir aday kümesi seç, sonra vektör mesafesiyle sırala. Birçok müşterimizde bu yaklaşımı uyguluyoruz ve gerçekten işe yarıyor.

Kaynaklar ve İleri Okuma

Kendi deneyimimden konuşuyorum, Azure SQL Devblog: AI_GENERATE_EMBEDDINGS GA Duyurusu

Microsoft Learn: AI_GENERATE_EMBEDDINGS T-SQL Referansı

Microsoft Learn: CREATE EXTERNAL MODEL T-SQL Referansı

Azure SQL’de AI Uygulamaları: Genel Bakış (yanlış duymadınız)