NL2SQL’de Asıl Soru: Prompt mu, Veritabanı mı?
NL2SQL ilk bakışta bayağı masum dürüyor. Kullanıcı soruyor, model SQL yazıyor, veritabanı cevaplıyor… kağıt üstünde her şey temiz. Ama açık konuşayım, kurumsal tarafa girince işin rengi değişiyor. Hatta bazen epey değişiyor.
Benim bu konudaki refleksim hep aynı öldü: “Tamam da model neyi bilmiyor?” Çünkü mesele sadece SQL üretmek değil; doğru tabloyu bulmak, ilişkiyi kaçırmamak, yetki sınırını aşmamak ve en önemlisi yanlış ama kendinden emin bir cevap vermemek. Geçen yıl Şubat ayında, İstanbul’da bir finans müşterisinde buna benzer bir PoC yaptık; ekip hızlıca demo aldı. Canlı veriye yaklaşınca schema’nın ne kadar konuşkan olmayan bir yapı olduğunu yüzümüze çarptı. Şey… tam burada işler ciddileşiyor.
Jerry Nixon’ın yazısındaki ana fikir bence yerli yerinde: veritabanını doğrudan prompt gibi kullanmak cazip, ama riskli. Ben de Azure danışmanlığı yaparken bunu defalarca gördüm. 2019’da kendi lab ortamımda küçük bir ERP şemasında deneme yapmıştım; model gayet düzgün görünen ama semantik olarak yanlış join’ler üretti (evet, doğru duydunuz). O gün anladım ki problem modelin “isteksizliği” değil, bizim ona verdiğimiz bağlamın eksikliği.
Neden NL2SQL bu kadar çekici?
Açıkçası, İşin çekiciliği aslında çok net. Kullanıcıya ekran doldurtmadan soru sorduruyorsun. Rapor beklemeden cevap alıyorsun. Analist beklemeden iş görüyorsun. En çok da satış, operasyon ve yöneticiler için bu bayağı rahat bir deneyim sağlıyor. Teknik ekip tarafında düşününce de daha az özel rapor, daha az tek seferlik sorgu, daha az “bana şunu çıkarır mısın?” mesajı demek.
Çok konuştum, örnekle göstereyim.
Ha bu arada küçük startup ile enterprise arasında fark tam da burada başlıyor. Startup’ta veri modeli çoğu zaman daha temiz oluyor; çünkü sistem yeni kurulmuş oluyor, tarihsel bagaj az oluyor. Enterprise tarafta işe tablo başka: farklı dönemlerden kalma uygulamalar, birleşmeler, işim karmaşası, yarım kalmış migration’lar… Kısacası schema bazen şirketin hafızası değil, travma günlüğü gibi dürüyor.
Bir de şu var: kullanıcı deneyimi açısından NL2SQL insanı cezbediyor çünkü doğal dil bariyerini kaldırıyor — valla güzel iş çıkarmışlar —. Ama doğal dil rahatlığıyla birlikte kontrol hissi azalıyor. Güvenlik tarafında kontrol azalınca benim içimdeki AZ-500 refleksi hemen ayağa kalkıyor. Veriye erişim kolaylaşsın derken yanlış veri sızıntısı ya da gereksiz geniş yetki açılması çok kolay oluyor.
Modelin iyi SQL yazması yetmez; doğru SQL’i yetkili, bağlamlı ve denetlenebilir şekilde yazması gerekir.
Sorun nerede başlıyor?
Sorun genelde şurada patlıyor: insanlar schema’yı prompt’a koyunca her şeyin çözüleceğini sanıyor. Evet, kolon adları önemli. İlişkiler önemli. Örnek satırlar da bazen işe yarıyor. Ama bunlar tek başına yeterli değil çünkü veritabanı çoğu zaman iş kuralını anlatmaz; sadece saklar (kendi tecrübem)
Bak şimdi, Mesela “aktif müşteri” ne demek? Son siparişi olan mı — Son 90 günde işlem yapan mı? — Sözleşmesi devam eden mi? Schema bunu söylemez. Model de çoğu zaman bunu sezemez; sezmiş gibi yapar… ve işte en tehlikeli kısım orasıdır.
Bunu yaşayan biri olarak söyleyeyim, 2023’te Ankara’daki bir üretim firmasında buna benzer bir durumda kaldık. Model stok tablosunu doğru okudu ama depo transferlerini bağımsız işlem sandığı için raporu kaydırdı. Hata log’una baktığımda asıl sorun SQL syntax — en azından ben öyle düşünüyorum — değildi; anlam hatasıydı. Düzeltme için iki hafta boyunca business glossary çıkardık (evet, sıkıcıydı) ama sonuçta doğruluk ciddi arttı.
Schema açıklamazsa model uydurur
Bence en kritik gerçek bu: modeller boşluğu sevmez, doldurur. Boşluk varsa tahmin ederler. Tahmin iyiyse sorun yok gibi görünür; kötü tahminse kimse ilk anda fark etmez bile.
Aslında, Kurduğum bazı Azure SQL senaryolarında özellikle column naming standardı olmayan yapılarda bunun acısını gördüm. Bir tabloda Status, diğerinde IsActive, öbüründe LkpStateCode olunca model hangi mantığı izleyecek? İnsan bile zorlanıyor yanı. Azure Functions’ta Retry Fırtınasını Durdurmak: Backoff ve Circuit Breaker yazımızda bu konuya da değinmiştik. .NET MAUI Artık CoreCLR’da: Mono’nun 24 Yıllık Yolculuğu yazımızda bu konuya da değinmiştik.
MCP burada neden önemli?
Bence, MCP yaklaşımı bana göre işi biraz toparlıyor çünkü modeli doğrudan veritabanının üstüne salmak yerine araç katmanı üzerinden kontrollü erişim sağlıyor. Yanı model her şeyi bilmek zorunda kalmıyor; belirlenmiş araçlarla konuşuyor.
Hani, Açık söyleyeyim, bu yaklaşım mükemmel değil ama düz prompt’a göre daha olgun dürüyor. En azından audit edilebilirlik artıyor, yetki sınırı çizilebiliyor ve hangi işlemin nasıl yapıldığı izlenebiliyor. Daha fazla bilgi için Visual Studio Agent Skills: Copilot’a Takımınızı Öğretmek yazımıza bakabilirsiniz.
SQL MCP Server neyi değiştiriyor?
Bana göre SQL MCP Server’ın asıl değeri “sorgu üretmek”ten çok “sorgu üretimini disipline etmek”. Bu ufak fark gibi geliyor ama enterprise dünyada ufak farklar bütünüyle oyunu değiştirir.
Düşünün; model doğrudan tablo şemasını ezberlemeye çalışmıyor artık.
Bir araç katmanı var.
Bu katman hem erişimi daraltıyor hem de niyet ile uygulama arasına kontrollü bir mesafe koyuyor.
Ben buna bazen dijital turnike diyorum — herkes geçsin diye kapıyı ardına kadar açmıyorsun.
| Konu | Sadece Prompt ile NL2SQL | MCP Tabanlı Yaklaşım |
|---|---|---|
| Erişim kontrolü | Zayıf / dağınık | Daha net ve denetlenebilir |
| Semaantik doğruluk | Sıklıkla tahmine dayanır | Araç katmanıyla yönlendirilebilir |
| Bakım maliyeti | Zamanla artar | Daha yönetilebilir olur |
| Kurum içi uyum | Zorlayıcı olabilir | Daha kolay kabul görür |
E tabi burada küçük bir hayal kırıklığını da söylemem lazım: MCP sihirli değnek değil. Eğer altında kötü isimlendirilmiş tablolarınız varsa ya da business rule’larınızı hiç dokümante etmediyseniz, MCP sadece o karmaşayı daha düzenli taşır… çözmez. Daha fazla bilgi için Microsoft SQL ile Agentic AI Güvenliği: Katman Katman Savunma yazımıza bakabilirsiniz.
Bütçe ve ölçek açısından bakınca…
Vallahi, Tamam şimdi gelelim para tarafına ki genelde kimsenin yüksek sesle konuşmadığı yer burasıdır. Azure tarafında böyle bir mimarı kurarken maliyet yalnızca LLM çağrısı değildir; ağ trafiği, güvenlik katmanı, loglama, App Service ya da container altyapısı. Veri erişim desenleri de faturaya eklenir.
Bakın, burayı atlarsanız yazının kalanı anlamsız kalır. Segment Heap: Visual Studio’da C++ Belleği Neden Değişti? yazımızda bu konuya da değinmiştik.
Küçük ekipler için sade tutmak şarttır. Başlangıç aşamasında Data API Builder ile belli uçları dışarı açıp üzerine sınırlı bir agent akışı kurmak mantıklı olabilir. Enterprise seviyede işe ayrıntılı logging, role-based access control ve ince taneli policy tasarımı olmadan yola çıkmak pek akıllıca olmaz. Bence Türkiye’de birçok kurumun yaptığı hata şu: önce gösterişli demo kuruyorlar sonra güvenlik ve işletme kısmını sonradan düşünmeye çalışıyorlar…
Bende bıraktığı pratik dersler neler?
Bak şimdi, AZ-305’e hazırlanırken mimarı kararların kağıt üstündeki güzelliği ile prod’daki gerçekliği arasındaki farkı çok net hissetmiştim.
NL2SQL konusunda da aynı şey geçerli.
Demo’da güzel olan şeylerin yarısı prod’da duvara tosluyor.
Hele bir de performans ve yetkilendirme tarafında bunu defalarca yaşadım.
{
"approach": "MCP",
"controls": [
"allow-listed tools",
"read-only operations where possible",
"row-level security",
"query logging",
"prompt sanitization"
],
"risk_reduction": true
}- Küçük ekip: Önce dar kapsamlı birkaç tabloyla başlayın.
- Büyük kurum: Business glossary + governance + audit zinciri kurun.
- Bütçe kısıtlıysa: Direkt full agent yerine kontrollü tool layer deneyin. (bu kritik)
- Kritik veri varsa: Yazma işlemlerini hemen devreye almayın; önce salt-okuma ilerleyin. — bunu es geçmeyin
Bana göre doğru başlangıç sırası şöyle:
- Sadece okunacak veri alanlarını seçin.
- Tanınmış terimler için sözlük hazırlayın.
- Sorgu kayıtlarını toplayın ve yanlış örnekleri ayıklayın.
- Aynı işi yapan birkaç prompt varyasyonu deneyip karşılaştırın.
- Daha sonra güvenlik politikalarını sıkıştırın.
- Anlam doğruluğunu ölçmeden canlıya çıkmayın.
Türkiye’de bu konu neden daha hassas?
Bunu Türkiye’deki şirketler açısından değerlendirirsek durum biraz farklı ilerliyor.
Kurumsal müşterilerimde gördüğüm kadarıyla bizde veri sahipliği konusu hâlâ tam oturmamış olabiliyor.
Yanı teknik ekip başka söylüyor,
iş birimi başka anlıyor,
rapor başka davranıyor…
Sonra herkes aynı cümleyi kuruyor:
“Veri doğru ama sonuç yanlış.” İşte klasik sahne budur.
Bu yüzden Türk şirketlerinde NL2SQL’i sadece teknoloji projesi gibi görmek bana eksik geliyor.
Aslında bu biraz organizasyon tasarımı işi.
Ayrıca regülasyon tarafını da hafife almamak lazım.
Finansta KVKK,
sağlıkta gizlilik,
kamuda erişim sınırları…
Böyle ortamlarda doğal dil arayüzü kullanıcının işini kolaylaştırırken güvenlik ekibinin yükünü artırabilir.
Ben Logosoft’ta çalışırken bankacılık tarafında buna benzer projelerde hep aynı noktaya takıldık:
kim hangi soruyu sorabilecek?
hangi kolon maskelenecek?
hangi satır seti gösterilmeyecek?
Sorular basit görünüyor ama cevapları basit değil.
Peki alternatif ne?
Eğer bütçeniz kısıtlıysa ya da kurum henüz hazır değilse tam otomatik NL2SQL yerine hibrit yaklaşımı öneririm.
Mesela önce sabit analitik endpoint’ler açarsınız,
sonra doğal dil katmanını yalnızca birkaç senaryo için devreye alırsınız.
Bu yöntem biraz daha yavaş ilerler ama hata maliyeti düşük olur.
Bir de açık konuşayım:
her şeyi AI’a bırakmak zorunda değilsiniz.
Bazen iyi hazırlanmış parametrik sorgular,
iyi etiketlenmiş dashboard’lardan bile daha faydalıdır.
Sıkça Sorulan Sorular
MCP Server NL2SQL için şart mı?
Şart değil aslında, ama ciddi avantaj sağlıyor. İşte, en çok da kurumsal ortamlarda kontrol, izleme ve yetkilendirme ihtiyacı varsa bence güçlü bir aday. E peki, sonuç ne öldü? Küçük PoC’lerde hani düz prompt yaklaşımı yeter gibi görünüyor, ama iş büyüdükçe eliniz kolunuz bağlanabiliyor.
Hmm, bunu nasıl anlatsamdı…
Sadece schema paylaşmak yeter mi?
Açıkçası pek saymaz. Schema önemli tabiî, ama iş kuralını anlatmıyor. Yanı kolon adları ve ilişkiler tek başına çok da anlam taşımıyor; bu yüzden sözlük, örnek sorgular ve kural notları eklemek gerekiyor.
NL2SQL güvenli mi?
Rastgele verilirse hayır, kontrollü verilirse evet demeye yaklaşıyoruz. Mesela read-only erişim, satır bazlı güvenlik, loglama ve allow-list ile risk ciddi düşüyor.
Küçük ekipler nereden başlamalı?
Tecrübeme göre düşük riskli birkaç tablo seçip başlamak en mantıklısı. Önce okuma senaryolarını çözün, sonra kapsam genişletin. Her şeyi aynı anda yapmak genelde aceleci oluyor.
Kaynaklar ve İleri Okuma
Orijinal Microsoft Azure SQL Blog Yazısı
Azure SQL Güvenlik Genel Bakış Dokümantasyonu
Azure Architecture Center Rehberi
Microsoft GitHub Deposu💡 Bilgi: Denemek istiyorsanız ilk iş küçük bir read-only senaryo seçin; ardından logging’i açın ve yanlış sonuç örneklerini toplayın. Doğruluk ölçmeden üretime çıkmayın. İnanın sonra toparlamak daha zahmetli oluyor.Sıkça Sorulan Sorular
Neyse uzatmayayım: Benim görüşüm şu — NL2SQL heyecan verici, ama ham hâliyle bırakılırsa riskli. MCP Server işe işi büyük ölçüde çözmüyor, ama düzgün bir çerçeve çiziyor. Kurumsal dünyada asıl kazanç da zaten burada geliyor: kontrolsüz zekâ değil, kontrollü otomasyon.
Araçları daraltın; modele tüm veritabanını vermeyin.
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