Kısa yanıt
NL2SQL (natural language to SQL), kullanıcının Türkçe yazdığı bir soruyu çalıştırılabilir SQL sorgusuna çeviren katmandır. MS SQL Server üzerinde güvenli bir kurulum üç unsurdan oluşur: modele yalnızca ilgili tabloların şeması ve iş sözlüğü verilir, üretilen sorgu çalıştırılmadan önce ayrıştırılıp yalnızca SELECT olduğu doğrulanır ve bağlantı salt okunur bir veritabanı kullanıcısıyla açılır. Doğru kurgulanmış sistemlerde iş sorularında %85–93 bandında doğru sonuç üretmek mümkündür.
NL2SQL nedir?
Kurumlarda veri var, veriye erişim yok. Satış müdürü bir soruyu yanıtlamak için IT'den rapor ister, rapor üç gün sonra gelir, o sırada soru değişmiştir. NL2SQL bu döngüyü kırar: kullanıcı soruyu kendi diliyle yazar, sistem sorguyu üretir, çalıştırır ve sonucu tablo + özet cümle olarak döner.
Basit görünür, tehlike de buradadır. Bir dil modelinden SQL istemek beş dakikalık iştir; doğru ve güvenli SQL üreten bir sistem kurmak ise mimari iştir.
Güvenli bir NL2SQL mimarisi
KULLANICI SORUSU
└─ NİYET AGENT'I Soru veri sorgusu mu, tanım sorusu mu?
└─ ŞEMA SEÇİCİ İlgili tabloları vektör aramasıyla belirler
└─ SQL ÜRETİCİ Yalnızca seçilen tabloların şeması + iş sözlüğü
└─ AYRIŞTIRICI SELECT mi? Alt sorgu güvenli mi? LIMIT var mı?
└─ ÇALIŞTIRICI Salt okunur kullanıcı, sorgu zaman aşımı, satır limiti
└─ ÖZETLEYİCİ Sonucu tablo + tek cümlelik yorum olarak döner
└─ LOG Soru, üretilen SQL, süre, satır sayısı, kullanıcıBu zincirde her adım tek işten sorumludur; çok ajanlı mimarinin tipik bir uygulamasıdır. En kritik iki adım, şema seçici ve ayrıştırıcıdır.
Şema bağlamı: doğruluğun %70'i burada
Model, veritabanınızı bilmez. Ona MUSTERI_HRK tablosunun ne olduğunu, DRM alanının "durum" anlamına geldiğini ve 1 değerinin "aktif" demek olduğunu siz anlatmak zorundasınız. Pratikte işe yarayan yapı şudur:
- Tablo ve kolon açıklamaları. MS SQL'de
sys.extended_propertiesüzerinden tanımlanan açıklamalar doğrudan bağlam olarak kullanılabilir. - İş sözlüğü. "Ciro", "aktif müşteri", "iptal edilmiş sipariş" gibi kurum terimlerinin hangi tablo ve koşula karşılık geldiği yazılı olmalı.
- Kod tabloları. Durum kodları ve karşılıkları örneklerle verilmeli.
- Örnek soru–SQL çiftleri. 20–40 iyi seçilmiş örnek, doğruluğu belirgin biçimde yükseltir.
- İlişki haritası. Hangi tablo hangi anahtarla hangi tabloya bağlanır; yabancı anahtar tanımlı değilse elle belgelenmeli.
Güvenlik: agent'a asla yazma yetkisi vermeyin
- Ayrı veritabanı kullanıcısı. Yalnızca
db_datareaderrolü; gerekiyorsa yalnızca belirli görünümlere (view) erişim. - Görünüm katmanı. Ham tablolar yerine iş odaklı görünümler sunun; hem güvenlik hem doğruluk artar.
- Sorgu ayrıştırma. Üretilen metin çalıştırılmadan önce parse edilmeli;
SELECTdışı ifade, çoklu komut (;) veya yorum enjeksiyonu reddedilmeli. - Zaman aşımı ve satır limiti. Her sorguya
SET LOCK_TIMEOUT, sorgu zaman aşımı ve otomatikTOPsınırı ekleyin. - Satır düzeyinde güvenlik. Kullanıcının göremeyeceği veriyi model de görmemeli; RLS ya da kullanıcıya göre parametrelenen görünümler kullanın.
- Kişisel veri filtresi. Sonuç setinde TCKN, telefon gibi alanlar varsa maskeleyin — KVKK gerekçeleri burada.
Doğruluğu artıran altı teknik
- Şema daraltma. 300 tablolu bir veritabanında modele 8 tablo verin. Az bağlam, daha isabetli sorgu demektir.
- Kendi kendini düzeltme. Sorgu hata verirse hata mesajını modele geri verip tek bir düzeltme denemesi yaptırın. Doğruluğu ciddi biçimde artırır.
- Sorgu planı ön kontrolü. Çalıştırmadan önce
SET SHOWPLAN_XMLile maliyeti bakın; çok pahalı sorguyu reddedin. - Belirsizlikte soru sorma. "Geçen ay" ifadesi takvim ayı mı, son 30 gün mü? Model tahmin etmek yerine sormalı.
- Sonuç mantık kontrolü. Negatif ciro, gelecekteki tarih, beklenmedik büyüklükte satır sayısı gibi durumlar uyarı üretmeli.
- Geri bildirim döngüsü. Kullanıcının "bu yanlış" işaretlediği sorular, örnek havuzuna eklenerek sistemi zamanla iyileştirir.
Performans ve maliyet kontrolü
NL2SQL sistemlerinde iki maliyet vardır: model çağrısı ve veritabanı yükü. İkisi de kontrol edilebilir:
| Önlem | Etkisi |
|---|---|
| Sık sorulan soruların sorgu önbelleği | Model çağrısını tamamen atlar |
| Şema bağlamının önbelleklenmesi | Token maliyetini belirgin biçimde düşürür |
| Basit sorularda küçük model kullanımı | Ortalama maliyeti düşürür |
| Raporlama replikası üzerinde çalışma | Üretim veritabanını korur |
| Sonuç satır limiti | Ağ ve bellek yükünü sınırlar |
Kimler için uygun, kimler için değil?
Uygun: Veri hacmi yüksek, iş birimlerinin sık ve değişken soruları olan, IT'nin rapor kuyruğunun uzadığı kurumlar. Emlak portföyleri, perakende satış verisi, lojistik operasyon kayıtları ve finansal hareketler tipik uygulama alanlarıdır. Emlak sektörü örneğine göz atabilirsiniz.
Uygun değil: Veri modeli belgelenmemiş, alan adları anlamsız ve kimsenin iş kurallarını yazılı hale getirmediği ortamlar. Bu durumda önce veri sözlüğü çalışması yapılmalı; NL2SQL o çalışmanın yerine geçmez, üzerine kurulur.