LLM ile Doğal Dilden SQL Sorgusu Üretmek: Text-to-SQL Rehberi

Text-to-SQL nedir, hangi problemi çözer?

Text-to-SQL, kullanıcının Türkçe ya da başka bir doğal dilde sorduğu bir soruyu büyük dil modeli (LLM) yardımıyla SQL sorgusuna çevirme yaklaşımıdır. Örneğin "Geçen çeyrekte hangi bölgede iade oranı en yüksekti?" sorusu, ilgili tablolar üzerinde çalışan bir sorguya dönüştürülür ve sonuç kullanıcıya sunulur.

Amaç, SQL bilmeyen iş birimlerinin veriye kendi başına ulaşabilmesidir (self-servis analitik). Böylece veri ekibi her küçük rapor talebine yetişmek zorunda kalmaz. Ancak modelin ürettiği sorgu kendiliğinden doğru ve güvenli değildir; sistemin gerçek değeri, modeli çevreleyen şema bilgisi, doğrulama ve güvenlik katmanlarında yatar.

Temel akış: soru, şema, sorgu, sonuç

Basit bir text-to-SQL sisteminin akışı şu adımlardan oluşur: • Kullanıcı soruyu doğal dilde yazar • Sistem, soruyla ilgili veritabanı şemasını (tablolar, sütunlar, ilişkiler) modele iletir • Model SQL sorgusunu üretir • Sorgu doğrulanır ve yalnızca izin verilen kapsamda çalıştırılır • Sonuç kullanıcıya tablo ya da özet olarak sunulur

Bu akışta en kritik girdi şemadır. Model, tabloların ve sütunların ne anlama geldiğini bilmezse tahmin yürütür. Sütun adı "amt" ise bunun tutar mı, miktar mı olduğu açıklanmalıdır. Şema ne kadar anlaşılır tanımlanırsa üretilen sorgu o kadar isabetli olur.

Örnek bir akış: kullanıcı 'geçen ay en çok iade edilen ürün kategorisi hangisi' diye sorar. Sistem, sipariş, iade ve ürün tablolarını ve bunların birleşim anahtarlarını modele verir; model bir gruplama ve sıralama sorgusu üretir. Doğrulama katmanı sorgunun yalnızca okuma yaptığını ve izinli tablolara eriştiğini kontrol eder, sonuç bir tablo ve kısa bir yorumla kullanıcıya döner.

Prompt mühendisliği ile SQL üretimi

İlk iyileştirme alanı isteminin (prompt) tasarımıdır. Modele hangi SQL lehçesinin kullanılacağını, hangi tabloların erişime açık olduğunu ve çıktının yalnızca sorgu olması gerektiğini açıkça söylemek sonucu iyileştirir. İstemde birkaç örnek soru ve doğru sorgu çifti vermek (few-shot), modelin kurumun sorgu tarzını ve iş tanımlarını öğrenmesine yardım eder.

İş tanımları önemlidir. "Aktif müşteri" kavramı kurumdan kuruma değişir; bu tanım istemde ya da şema açıklamasında yoksa model kendi varsayımını kullanır ve yanlış ama makul görünen bir sorgu üretir. Belirsiz sorularda modelin tahmin etmek yerine netleştirme sorusu sorması da istenebilir.

İstemde çıktı biçimini de sabitleyin: yalnızca sorgu, ek açıklama olmadan ve belirlenen lehçede. Örnek soru-sorgu çiftlerini kurumun gerçekten sorulan sorularından seçin; özellikle tarih aralıkları, iade ve iptal gibi duruma bağlı filtreler ve birden çok tablonun birleştiği sorular iyi örnek olur. Örnekler arttıkça istem uzar ve maliyet yükselir; bu yüzden soruyla en ilgili örnekleri dinamik seçmek ayrı bir iyileştirme adımıdır.

RAG ile şema zenginleştirme ve özel model eğitimi

Kurumsal veritabanları yüzlerce tablo içerebilir; tüm şemayı isteme sığdırmak hem pahalı hem de dikkat dağıtıcıdır. RAG (geri getirmeyle zenginleştirilmiş üretim) yaklaşımında soruyla en ilgili tablolar, sütun açıklamaları ve örnek sorgular bir arama katmanıyla bulunur ve yalnızca bunlar modele verilir. Böylece model daha az ama daha alakalı bilgiyle çalışır.

Fine-tuning, yani modelin kuruma özgü soru-sorgu örnekleriyle ek eğitimi, daha ileri bir seçenektir. Önce prompt ve RAG ile ulaşılabilecek kalite denenmeli, bunlar yetmezse özel model düşünülmelidir. Eğitim verisi hazırlamak ve modeli güncel tutmak maliyetli bir iştir; her kurum için gerekli değildir.

Sonuç doğrulama ve güvenlik

Üretilen sorgu doğrudan veritabanında çalıştırılmamalıdır. Önce sözdizimi ve şemaya uygunluk kontrol edilir; sorgunun yalnızca okuma yaptığı, yetkisiz tabloya erişmediği doğrulanır. Veritabanı kullanıcısı salt okunur ve sınırlı yetkiyle tanımlanmalı, çalışma süresi ve döndürülen satır sayısı sınırlandırılmalıdır.

Güvenlik riskleri arasında kullanıcı sorusuna gömülmüş kötü niyetli talimatlar (prompt injection), hassas verilerin sızması ve aşırı maliyetli sorgular bulunur. Kişisel veri içeren alanların maskelenmesi ve satır düzeyinde yetkilendirme, yanlış kişiye yanlış verinin gösterilmesini önler. Sonucun doğruluğu için de kritik raporlarda sorgu ve yorumun bir uzman tarafından incelenmesi önerilir.

Bir uygulama örneği: salt okunur bir veritabanı kullanıcısı tanımlayın, yalnızca onaylı görünümlere erişim verin ve her sorguya bir çalışma süresi sınırı koyun. Sorgu çalıştırılmadan önce bir ayrıştırıcıyla incelenip yazma ya da silme içeren ifadeler reddedilir. Bu önlemler modelin hatasını veya kötü niyetli bir yönlendirmeyi sistemin geri kalanından yalıtır.

Üretim mimarisi, değerlendirme ve sürekli iyileştirme

Prototipten üretime geçerken kullanıcı arayüzü, kimlik ve yetki yönetimi, şema ve açıklama kataloğu, kayıt tutma ve geri bildirim mekanizması bir arada tasarlanır. Her sorunun, üretilen sorgunun ve kullanıcının geri bildiriminin kaydedilmesi, hataları anlamak için gerekli veriyi oluşturur.

Değerlendirme için bir test seti kurulur: temsilci sorular ve bunların doğru sorguları ya da doğru sonuçları. Her değişiklikten sonra sistem bu setle ölçülür. Başarı yalnızca sorgunun çalışmasıyla değil, doğru sonucu üretmesiyle değerlendirilir; çalışan ama yanlış sonuç veren sorgu, en tehlikeli hata türüdür. Kullanıcı geri bildirimleri düzenli olarak test setine eklenir.

Mindset programlarında text-to-SQL

Mindset'in LLM ile Veri Sorgulama (Text-to-SQL) programı bu akışı modüllere böler: text-to-SQL sistemlerinin temelleri, LLM prompt mühendisliği ile SQL üretimi, RAG tabanlı şema zenginleştirme, fine-tuning ve özel model eğitimi, sonuç doğrulama ve güvenlik, üretim mimarisi ve self-servis analitik ile değerlendirme, izleme ve sürekli iyileştirme.