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.
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.
- 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ı.
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ı!
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.
4 comments