SQL + AI: Elinizdeki Veriyi Bozmadan Akıllı Uygulama Kurmak
Şunu açık konuşayım: Yapay zekâ sohbetleri bazen insanı yoruyor (evet, doğru duydunuz). Her hafta yeni bir araç, yeni bir model, yeni bir “şöyle yapmanız gerekiyor” cümlesi çıkıyor… ama işin aslı şu ki, çoğu — itiraz edebilirsiniz tabi — anlatım sanki elinizdeki sistemi çöpe atıp sıfırdan başlamanızı bekliyor. Benim 20+ yıllık BT tarafındaki deneyimimde, özellikle kurumsal tarafta bu yaklaşım pek işlemiyor. Hani ne farkı var diyorsunuz, değil mi? Kimse çalışan bir SQL altyapısını sırf moda diye dağıtmak istemiyor.
İşte bu yüzden SQL merkezli AI yaklaşımı bana bayağı mantıklı geliyor. Veri yerinde kalsın, güvenlik modeli aynı kalsın, T-SQL bilen ekip yine kendi dilinde devam etsin; üstüne de semantik arama, embedding ve RAG gibi parçalar eklenebilsin. Kağıt üstünde güzel değil sadece, pratikte de iş görüyor. Tabiî her şey güllük gülistanlık değil; birazdan eksik taraflarına da geleceğim.
Bunu biraz açayım.
Geçen yıl Mart 2025’te bir finans müşterisinde benzer bir senaryoyu tartışıyorduk. Ekip “AI istiyoruz” diyordu ama veri dışarı çıkmasın şartı vardı. Klasik yaklaşımda ilk soru hep şuydu: “Peki hangi platforma taşıyalım?” Ben işe tam tersini sordum: “Neyi taşımadan akıllandırabiliriz?” Bu bakış açısı işi hızlandırdı.
Neden SQL’in Etrafında Dönmek Daha Mantıklı?
SQL dünyasında yıllardır çözmeye alıştığımız sorunlar var: yetkilendirme, erişim kontrolü, veri bütünlüğü, denetim izi… Şimdi bunların yanına birkaç yeni kelime eklendi diye oyun büyük ölçüde değişmiş değil. Sadece sözlük büyüdü. Embedding dediğimiz şey aslında veriye sayısal bir iz düşümü vermek. Metni makinenin anlayacağı daha sıkı bir forma sokmak. Çok teknik anlatınca kafa karışıyor, o yüzden şöyle düşünün: Bir dosya dolabındaki klasörlere renk kodu koymak gibi.
Durun, bir saniye.
Microsoft SQL ile çalışırken hoşuma giden taraf şu öldü: mevcut alışkanlıklarınız çöpe gitmiyor. T-SQL bilen ekip yine T-SQL yazıyor; veri yönetişimi bilen kişi yine aynı prensiplerle ilerliyor. Az-305 sınavına hazırlanırken de bunu çok net görmüştüm; mimarı kararların büyük kısmı teknoloji isminden çok işletme ihtiyacıyla ilgiliydi. Bugün Azure SQL Database ya da Managed Instance tarafında AI katmanı eklerken de mantık değişmiyor.
Bir dakika, şunu da ekleyeyim: Küçük startup ile enterprise arasında burada ciddi fark var. Startup tarafında hız ön planda olur; küçük ekip hızlıca prototip çıkarır ve hatayı çabuk görür. Enterprise tarafta işe governance tokadı gelir — güvenlik onayı, veri sınıflandırması, maliyet onayı… Hepsi sıraya girer. O yüzden tek reçete yok. Bu konuyla ilgili Visual Studio 2026’da C++ İçin Sessiz Devrim: Hız, Copilot ve PGO yazımıza da göz atmanızı tavsiye ederim.
Workshop Mantığı Neyi Değiştiriyor?
Ben workshop formatını seviyorum çünkü teoriyi masanın üstünden alıp ellere veriyor. İnsan izleyince anlıyor sanılıyor ama öyle olmuyor; gerçekten yaptığınızda anlaşılıyor. Geçen sene Kasım 2024’te İstanbul’da düzenlenen kapalı bir oturumda buna benzer bir deneyim yaşadık: katılımcılar embedding kavramını dinlerken başta biraz mesafeli duruyordu, sonra tabloyu canlı gördüklerinde yüz ifadeleri değişti.
Bence en değerli nokta şu: bu tarz etkinliklerde yalnızca model çağırmayı öğrenmiyorsunuz, trade-off düşünmeyi de öğreniyorsunuz. Latency ne olacak? Maliyet ne kadar artacak? Cevaplar doğru mu? Veri nerede tutulacak? Bunlar gerçek sorular ve iyi ki öyle sorular; çünkü prod ortamda kimse “demo güzelmiş” diye ödeme yapmıyor (ben de ilk duyduğumda şaşırmıştım) GitHub Advanced Security’de Bütçe Sınırı: Kontrol Artık Sıkı yazımızda bu konuya da değinmiştik.
Doğrusu, Ha bu arada, Microsoft partnerleriyle yapılan atölyelerin artısı da var: sahada neler döndüğünü duymuş insanlar size eşlik ediyor. Yanı kitap bilgisiyle değil… üretim kesintisi yaşamış biri gibi konuşuyorlar. Bu fark önemli! Bir müşteride Temmuz 2023’te yaşadığımız olay hâlâ aklımdadır; küçük görünen vector index ayarı yüzünden sorgu gecikmesi iki katına çıkmıştı.
Sahada İşe Yarayan Üç Parça
İşin özünü üç başlıkta toparlayabilirim: embeddings, vector search, RAG. Embedding veriyi temsil eder, vector search benzerliği bulur, RAG işe modeli kendi verinizle besleyip uydurma cevap riskini azaltır. Basit anlattım ama yeterli bence; çünkü çoğu ekip ilk aşamada bundan fazlasına ihtiyaç duymuyor. Daha fazla bilgi için Azure IaaS’ta Performans: VM’den Çok Daha Fazlası Var yazımıza bakabilirsiniz.
- Küçük ekip: Önce tek kullanım senaryosu seçin. (bu kritik)
- Büyük kurum: Yetki modeli ve loglama tasarımını baştan koyun. — bunu es geçmeyin
- Bütçe kısıtlıysa: Tam kapsamlı platform yerine dar alanlı pilot açın.
| Konu | Küçük Startup | Enterprise |
|---|---|---|
| Zamanlama | Pilot odaklı hızlı deneme | Aşamalı geçiş ve onay süreçleri |
| Maliyet hassasiyeti | Düşük bütçe ile maksimum çıktı | Maliyet optimizasyonu ve FinOps takibi |
| Güvenlik | Temel koruma yeterli olabilir | Sıkı rol tabanlı erişim şart |
| Kabul süreci | Ekip içi karar yeterli olabilir | CISO / hukuk / uyum devreye girer |
Maliyet Meselesi: Güzel Ama Bedava Değil
Neyse uzatmayalım… AI tarafının en sevmediğim yanı bazen maliyeti hafife aldırmasıdır. Demo ortamında her şey akıcı görünür ama gerçek hayatta embedding üretimi ayrı masraf kalemi olabilir, sorgu yoğunluğu başka yük getirir, model çağrıları derken fatura kabarır. TL bazında düşündüğünüzde bu daha da can alıcı hâle geliyor çünkü kur oynaklığı direkt hissediliyor.
Vallahi, Bunu Türkiye’deki şirketler açısından değerlendirirsek durum biraz daha netleşiyor: birçok kurum inovasyon istiyor. Bütçe disiplini de istiyor (haklı olarak). O yüzden ilk önerim büyük kurulumlara dalmadan önce ölçüm mekanizmasını koymak olurdu. Hangi istek ne kadar sürüyor? Hangi kullanıcı grubu kaç çağrı yapıyor? Hangi cevap tipi pahalıya patlıyor? Bunları bilmeden yola çıkarsanız sonradan frene basmak zor oluyor.
AI projesi başarısız olunca çoğu zaman sebep model olmuyor; yanlış kapsam oluyor.
Birden fazla use case’i aynı anda kovalamayın.
Önce tek problem seçin.
Sonra önü sağlam çözün.
Aksi hâlde proje güzel başlıyor ama sessizce dağılıyor…
Sahada Denediğimde Neler Çalıştı?
Daha Az Gösteriş, Daha Çok Kontrol
Ağustos 2024’te Ankara’daki bir kamu projesinde bunu birebir gördüm. Ekip çok parlak görünen bir chatbot fikriyle gelmişti. Veri kaynağı dağınıktı; belge deposu ayrı yerdeydi, operasyonel kayıtlar başka yerdeydi… Biz önce gösterişli katmanı bıraktık ve SQL üzerinde temiz retrieval tasarladık. Sonuç? İlk demo daha sakın görünüyordu ama doğruluk belirgin biçimde arttı. Daha fazla bilgi için Kubernetes v1.36: Silinemeyen Politikaların Sessiz Gücü yazımıza bakabilirsiniz.
T-SQL Bilen Ekibin Avantajı Büyük
Size bir şey söyleyeyim, T-SQL bilen insanların avantajı küçümsenmemeli.
Yeni araç öğrenmek elbette iyi ama mevcut kaş hafızasını kullanmak bambaşka şeydir.
Mesela geçen sene İzmir’de orta ölçekli bir üretim firmasına danışmanlık verirken geliştirme ekibi zaten raporlama için SQL’e hâkimdi.
Onlara yeni dil öğretmek yerine mevcut sorguları genişlettik;
bu hem adaptasyonu hızlandırdı hem de bakım yükünü düşürdü.
Az önce X dedim ama aslında Y daha doğru olabilir:
“Yeni teknolojiye geçelim” demekten önce,
“Mevcut teknolojiyi nasıl akıllandırırız?”
diye sormak çoğu zaman daha sağlıklı oluyor.
Bu konuda %100 emin değilim ama sanırım en büyük kazanım tam da burada geliyor;
kurumun bildiği zemini korurken yenilik ekliyorsunuz.
Bu bayağı rahatlatıcı! Daha fazla bilgi için Dependabot artık sbt’yi görüyor: Java ekosisteminde küçük ama etkili değişim yazımıza bakabilirsiniz.
Bazen Hayal Kırıklığı da Oluyor
Açık konuşayım,
ilk denediğim bazı vector aramalar beklediğim kadar iyi değildi.
Hele bir de kısa ve bağlamı zayıf kayıtlarla çalışırken sonuçlar biraz yamuk gelebiliyor.
Hani “olmuş mu?” dersiniz ya,
işte tam orası.
Çözüm genelde sihir değildi:
daha iyi chunking,
temiz metadata,
ve sorguyu iş amacına göre yeniden yazmak…
Bununla uğraşınca işler düzeliyor ama emek istiyor.
Yanı kolay para yok.
Kolay başarı hiç yok.
Denemek isteyen varsa ilk iş şu üç adımı atsın:
1) En değerli veri setinizi seçin
2) Tek senaryo tanımlayın
3) Ölçüm kriterini baştan koyun
Bitti.”
T-SQL örnek yaklaşım:
SELECT TOP (10)
DocumentId,
Title,
Score
FROM dbo.VectorSearchResults
WHERE TenantId = @TenantId
ORDER BY Score DESC;Bence En Doğru Başlangıç Nasıl Olur?
Eğer bugün sıfırdan başlayacaksanız ben şöyle ilerlerdim:
önce küçük bir içerik havuzu seçerdim,
sonra bunun üzerine RAG kurardım,
ardından güvenlik kontrollerini eklerdim.
Model seçimini sona bırakırdım bile diyebilirim;
çünkü asıl mesele çoğu zaman model değil,
verinin düzenidir.
Bir arkadaşım Haziran 2025’te bunu Bursa’daki SaaS girişiminde yaptı;
model için günler harcamadı,
önce kaynak veriyi toparladı.
Üç ay içinde destek taleplerinde gözle görülür azalma gördüler — rakam söylemeye gerek yok,
zaten takım mutluysa gerisi gelir.”
E tabi burada enterprise tarafta farklı davranırsınız:
loglama zorunlu olur,
erişim politikaları sıkılaşır,
ve belki bazı iş yüklerini Fabric tarafına taşımayı düşünürsünüz.
Kullanıcı sayısı yüksekse Hyperscale veya Managed Instance seçenekleri gündeme gelir;
ama sadece isimlerine bakıp karar vermeyin.
Mimarinin omurgası önemlidir!
Bana göre Microsoft’un verdiği mesaj yerinde:
SQL’i kenara itmeden AI eklemek mümkün.
Ama hâlâ ham olan yerler var;
özellikle fiyatlandırma şeffaflığı ve operasyonda gözlemleme tarafının daha pürüzsüz olması lazım.
Kağıt üstünde süper duran şeylerin prod’da nefes alması gerekir ya…
işte o nefes kısmı bazen eksik kalıyor.
Sıkça Sorulan Sorular
SQL verisiyle AI uygulaması kurmak zor mu?
Aslında — hayır dur, daha doğrusu düşündüğünüz kadar zor değil. Mevcut SQL altyapınızı bozmadan başlayabilirsiniz. İlk hedefiniz karmaşık agent mimarileri falan olmasın; yanı düzgün retrieval ve kontrollü cevap üretimi yeterli bir başlangıç noktası.
RAG neden önemli?
İtiraf edeyim, Bence en kritik nokta şu: cevapların kendi verinize dayanmasını sağlıyor. Modeli internette gezdirmek yerine sizin tablolarınıza bağlıyorsunuz. Bu da doğruluk. Denetlenebilirlik açısından ciddi fark yaratıyor — açıkçası bu farkı bir kez görünce geri dönmek istemiyorsunuz.
Küçük şirket mi yoksa büyük kurum mu daha rahat ilerler?
Küçük şirket daha hızlı hareket ediyor ama hata payını düşünecek çok zamanı olmuyor. Büyük kurumda süreç ağır işliyor, buna karşın kontrol seviyesi yüksek. Yanı ikisinin avantajı aslında bambaşka yerde — hangisinde olduğunuza göre stratejinizi şekillendirmeniz gerekiyor.
Maliyeti nasıl kontrol altında tutarım?
Açık konuşayım, Kullanımı ölçün, tek bir use case ile başlayın ve gereksiz model çağrılarını olabildiğince azaltın. Tecrübeme göre en pahalı bölüm hep kontrolsüz trafik oluyor. Pilot aşamasında limit koymak çok işe yarıyor — mesela bunu baştan yapmak sonradan çok büyük baş ağrısı kurtarıyor (şaşırtıcı ama gerçek)
Kaynaklar ve İleri Okuma
GitHub Copilot ile azd Terminalde Akıllı Kurulum Hızlı Çözüm
Python AI Uygulamalarında Azure App Service Hız Kazandıran Sessiz Değişim
SAP ve Azure’da Yeni AI Dönemi Kurumsal Akıl Nereye Gidiyor?”}
Intelligent applications with Azure SQL Database dokümantasyonu
Azure SQL Bloğu
SQL Server 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