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.
📋 İçindekiler
-
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
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.
Bu yazı yapay zeka (büyük dil modelleri) ile hazırlanmış, insan editör tarafından incelenmiştir. İçerik üretim sürecimiz.Aşkın KILIÇYazar20+ 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.
AZ-305AZ-104AZ-500AZ-400DP-203AI-102İlgili Yazılar
İlginizi Çekebilir
Hakan G.
NL2SQL projelerinde “neden yanlış tablo seçiyor” sorusuyla çok boğuştuk, schema’yı prompt’a doğru beslemek gerçekten işin yarısı. Yetki sınırları meselesine de değinmeniz çok yerinde olmuş, o kısım genellikle göz ardı ediliyor. Bu arada Copilot’a takım bağlamı öğretme konusundaki yazınız da aklıma geldi: https://www.askinkilic.com.tr/visual-studio-agent-skills-copilota-takiminizi-ogretmek/
Ayşe T.
Şema tasarımının bu kadar belirleyici olduğunu pek düşünmemiştim açıkçası. Biz de bir projede sadece prompt’u geliştirmeye uğraştık ama tablo isimlerini ve ilişkileri düzeltince çok daha iyi sonuçlar aldık. Yetki sınırları kısmını merak ettim, o konuyu biraz daha açar mısınız?
Deniz R.
Prompt optimizasyonuna takılıp asıl meselenin schema tasarımı olduğunu gözden kaçırmak çok kolay. Özellikle yetki sınırları kısmı ilginç, bunu genellikle uygulama katmanında çözmeye çalışıyoruz ama veritabanı bağlamına taşımak mantıklı olabilir. Pratikte hangi yaklaşım daha iyi sonuç verdi sizde?
Barış U.
Tam da geçen ay bir projeде NL2SQL denerken takıldığım şey buydu, prompt ne kadar iyi olursa olsun schema bilgisi eksik kaldığında model saçmalıyor. Yetki sınırları meselesini de hiç düşünmemiştim açıkçası, o kısım kritikmiş.
Yorumlar kapalı.
4 comments