Veritabanınıza Türkçe sorun

Çınar Atölye adında, sabun ve çay satan küçük bir çevrimiçi dükkânınız olduğunu düşünün. Her pazartesi birkaç sayı öğrenmek istiyorsunuz: geçen ay en çok kim harcadı, Ekim’de neler sipariş edildi, İstanbul’da kimler oturuyor. Yanıtlar dükkânın veritabanında, ama siz SQL yazmıyorsunuz, yazan kişi de meşgul. İstediğiniz şey, bir iş arkadaşınıza soracağınız gibi sormak: Türkçe, “Hangi müşteri toplamda en çok harcama yaptı?”, ve karşılığında bir konuşma değil, satırlar almak.

Bu işin bir adı var: metinden SQL’e (text-to-SQL). Bir model sorunuzu ve veritabanının bir tanımını okur, soruyu yanıtlayan sorguyu yazar. SQL, veritabanlarının konuştuğu dildir: bir sorgu hangi tabloya bakılacağını, hangi satırların tutulacağını ve neyin toplanacağını söyler. Sorguyu model yazar. Onu veritabanı çalıştırır. Bu yazı ikisinin buluştuğu yerle ilgili ve Hati Glint SQL adlı Türkçe bir metinden SQL modelinin orada ne yaptığıyla.

Yazının sonunda şunları bilecek olacaksınız:

• bir metinden SQL modelinin ne okuduğunu ve ne yazdığını, sayıları neden model değil veritabanının ürettiğini;
• bir sorgunun nasıl çalışıp satır döndürdüğü hâlde yine de yanlış olabileceğini ve bir insanın bunu nasıl yakaladığını;
• yürütme doğruluğunun neyi ölçtüğünü, Hati Glint SQL’in kendi değerlendirmemizde bunda ne skor aldığını ve neye yönelik olmadığını.

Sayıları doğrudan bir sohbet botuna sorsam olmaz mı? Veritabanına ne gerek var?

Siparişlerinizi hiç görmemiş bir sohbet botu sayıları ancak tahmin eder, satışlarınız hakkında kendinden emin bir tahmin ise hiç yanıt vermemekten kötüdür. Gerçek satırlar veritabanındadır ve veritabanı onlar üzerinde kesin hesap yapar. Metinden SQL modeli ona tek başına yapamayacağı şeyi verir: Türkçe sorunuzu veritabanının anladığı kesin talimata çevirir.

Hati Glint SQL, RuneLab’in ilk Hati modeli. Qwen3.5-9B’nin LoRA ile (tüm ağırlıkları değil, küçük bir ek ağırlık kümesini eğiten bir yöntem) Türkçeden SQL’e göre ince ayarlanmasıyla yapılmış 9B’lik bir model. Türkçe ve İngilizce soruları okuyor, SQLite sorguları yazıyor, Apache 2.0 ile (2026-10-10 tarihinde) yayımlandı ve şirket içinde, kontrol ettiğiniz donanımda çalışabiliyor. Model kartı onu “kendi değerlendirmemizde 10B altındaki en güçlü açık Türkçe metinden SQL modeli” diye tanımlıyor; bu niteleyicinin ne anlama geldiğine birazdan döneceğiz.

Kart, neye yönelik olmadığı konusunda da aynı ölçüde açık. Ürettiği SQL’i yazma izniyle ya da gözden geçirmeden çalıştırmayın, SQLite dışında bir lehçe yazmasını beklemeyin ve hangi verinin kime açık olacağına karar vermesi için kullanmayın. Bu üçünü aklınızda tutun: aşağıdaki şekil nedenini göstermek için yapıldı.

Dur bir dakika. Model, veritabanımın içinde ne olduğunu nereden biliyor?

Kendisine söyleniyor. Sorudan önce modele veritabanının şeması verilir: tabloların adları, sütunlarının adları ve her birinin türü. Bir sorgu yazması için gereken tek şey bu ve aşağıdaki örnekte modele verilen de yalnızca bu. Satırların kendisi veritabanında kalıyor.

İşte Çınar Atölye’nin veritabanı: customers, products ve orders adlı üç tablo ve bu yazı için uydurulmuş her satır. Bir soru seçin ve adım adım ilerlemek için sorunun altındaki düğmeye basın. Önce modele şema verilir, sonra model SQL’i yazar, sonra veritabanı bu sorguyu çalıştırır ve satırları döndürür. Sorular, sizin yazacağınız gibi Türkçe. Bu şekildeki her şey elle yazılmış bir örnektir, canlı bir modelin çıktısı değildir. “En çok harcayan” sorusunda son düğmeye basmadan önce tahmin edin: en çok kim harcadı?

Bu şekil JavaScript gerektirir. Kurgusal bir dükkân veritabanı (customers, products, orders) hakkındaki beş Türkçe soruyu üç adımdan geçirir: modele verilen şema, modelin yazdığı SQL ve salt okunur çalıştırma. “Hangi müşteri toplamda en çok harcama yaptı?” sorusunda sorgu orders, customers ve products tablolarını birleştirir ve her müşteri için adet çarpı fiyatı toplar: veritabanı tek bir satır döndürür, Mehmet Kaya, 329. İkinci yol uydurulmuş bir hatayı gösterir: adedi hiç kullanmadan fiyatları toplayan bir sorgu hatasız çalışır ve Elif Şahin, 168 döndürür. Öteki sorular İstanbul’daki müşteriler, Ekim 2026’daki siparişler, şemanın yanıtlayamadığı bir yaş ortalaması ve salt okunur denetimin reddettiği bir fiyat artırma talimatıdır.

Her durumda modelin payı birkaç satır SQL’de biter. Bir soru sorduğunuzda model şemayı okur ve bir sorgu yazar; sayıları model değil, veritabanı üretir. “En çok harcayan” sorusunu bir kez daha adım adım geçin ve yeşil satırlara bakın: Mehmet Kaya’nın iki siparişi 5 × 45 ve 2 × 52, veritabanı bunları toplayıp 329 buldu. Hiçbir model saymadı ve her sayıyı tabloyla karşılaştırıp doğrulayabilirsiniz.

Şekilde, Mehmet Kaya için 329 sayısını hangi parça üretiyor?

1. Model, dükkânlar hakkında öğrendiklerinden.
2. Toplamları tutan şema.
3. Veritabanı, SQL’i satırları üzerinde çalıştırırken.

Yanıtı göster

Veritabanı. Model yalnızca sorguyu yazar; 329, orders tablosunun iki satırından ve products tablosunun iki satırından hesaplanan 5 × 45 + 2 × 52 değeridir; bunlar şekildeki yeşil satırlardır.

A değil: bu örnekte model satırları hiç görmüyor, dolayısıyla toplanacak sayıları yok. Olsa olsa bir sayı tahmin edebilir.

B değil: şema tablo adlarını, sütun adlarını ve türleri listeler, hiçbir değer içermez.

Öteki sorular her biri bir şey daha öğretiyor. “İstanbul’daki müşteriler” en basiti: tek tablo, tek filtre. “Ekim siparişleri” tarihleri karşılaştırır; bu veritabanı tarihleri 2026-10-08 gibi düz metin olarak sakladığı için sorgu metni karşılaştırır. “Yaş ortalaması”nın şemada yanıtı yok; dikkatli bir yanıtın ne yaptığına bakın: bunu söyler ve sorgu yazmaz, hiçbir şey uydurulmaz. “Fiyatları artır” ise bir soru değil, bir talimat. Çalıştırın ve çalıştırmanın neden salt okunur olduğunu görün.

Peki model yanlış ama yine de çalışan bir sorgu yazarsa ne olur?

Ciddiye alınması gereken durum bu, o yüzden şekilde bunun için bir anahtar var. Bir soru seçin, sonuna kadar ilerleyin, sonra yolu “Normal yol”dan “Ters gidebilecekler”e çevirin. Her soru için makul bir hata var. Bunlar bu yazı için uydurulmuş, gerçek bir modelin çıktısı değil ve her biri bir insanın da yapabileceği türden bir sürçme. Çalıştırmadan sonra sorgunun yanlış kısmı altı çizilir ve bir not, bir insanın bunu nasıl yakalayacağını söyler.

Ne olduğuna bakın. Veritabanı hiç yanlış yapmadı: her seferinde tam olarak sorulanı çalıştırdı. “En çok harcayan” hiçbir hata vermeden başka bir isim verdi (Mehmet Kaya, 329 yerine Elif Şahin, 168). “İstanbul’daki müşteriler” hiçbir şey döndürmedi, çünkü tablo şehri noktalı büyük İ ile yazıyor, sorgu ise öyle yazmadı; boş bir yanıtı da “orada kimse yok” diye okumak kolay. “Ekim siparişleri” geçen yılın Ekim’ini de içeri aldı. Beş hatanın üçü tek bir uyarı bile vermeden çalıştı.

İstanbul’daki müşteriler için yazılan bir sorgu hatasız çalışıyor ve 0 satır döndürüyor. En iyi sonraki adım nedir?

1. SQL’i veriyle karşılaştırmak, yazımdan başlayarak.
2. Ona güvenmek: hata yok demek orada müşteri yok demektir, yani yanıt sıfırdır.
3. Birkaç satır çıkana kadar yeniden çalıştırmak.

Yanıtı göster

Sorguyu veriyle karşılaştırın. Şekilde tablo İstanbul sözcüğünü noktalı büyük İ ile yazıyor, sorgu ise Istanbul yazmış; bu yüzden hiçbir şey eşleşmedi. Beklemediğiniz bir sonuç, SQL’i okumak için bir nedendir.

B değil: “hata yok” yalnızca sorgunun geçerli olduğunu söyler. Doğru şeyi sorduğunu söylemez ve tabloda İstanbul’da oturan iki müşteri var.

C değil: aynı sorgu her seferinde aynı satırları verir, yeniden çalıştırmak hiçbir şeyi değiştirmez.

İki hata farklı. “Yaş ortalaması”, şemada olmayan bir sütun istiyor ve veritabanı no such column: age diyerek reddediyor. Bu güvenli bir başarısızlık: hiçbir sayı çıkmıyor. “Fiyatları artır”da ise modelin UPDATE ifadesiyle verileriniz arasında duran tek şey salt okunur denetim; kart da ürettiği SQL’i yazma izniyle ya da gözden geçirmeden çalıştırmayı kapsam dışı sayıyor.

Peki bir modelin sorgusu ne sıklıkla doğru? Olağan ölçü yürütme doğruluğudur: modelin sorgusunu çalıştırmak, bir insanın yazdığı referans sorguyu çalıştırmakla aynı sonucu veriyorsa soru doğru sayılır. Bunun için burada iki Türkçe test kümesi kullanılıyor: TURSpider ve BIRDTurk. BIRDTurk açıkça daha zor olanı: üzerindeki her skor TURSpider’dakinden düşük. Aşağıdaki bütün sayılar model kartından, RuneLab’in kendi değerlendirmesinde dev kümeleri üzerinde ölçülmüş değerlerdir; modelin o sorularda nasıl performans gösterdiğini söylerler, sizin veritabanınızda nasıl olacağını değil.

Şekil, temel modeli Qwen3.5-9B’yi Hati Glint SQL ile karşılaştırıyor. Üç ayarı sırayla açın. Doğrudan, düşünme modu kapalıyken tek yanıttır, Düşünme modu düşünme modunu açar, Ajan ise geri bildirim ekler (bunu birazdan anlatacağız).

Yürütme doğruluğu (%), temel model ve Hati Glint SQL

DoğrudanDüşünme moduAjan

Tek yanıt, düşünme modu kapalı.

TURSpider dev+9,09

Temel model64,12

Hati Glint SQL73,21

BIRDTurk dev+7,17

Temel model40,09

Hati Glint SQL47,26

0255075100

Skor, 0 ile 100 arası

Okumak için bir satırın üzerine gelin, dokunun ya da odaklanın.

• Temel model
• Hati Glint SQL

Çubuklar 0 ile 100 arasındadır. Kartın belirtmediği değişimler, gösterilen yuvarlanmış skorlardan hesaplanmıştır.

Tablo olarak görün

Ayar	Temel model	Hati Glint SQL	Değişim
Doğrudan	64,12	73,21	+9,09
Düşünme modu	71,18	76,79	+5,61
Ajan (düşünme + geri bildirim)	66,63	77,85	+11,22

Çubuklar 0 ile 100 arasındadır. Kartın belirtmediği değişimler, gösterilen yuvarlanmış skorlardan hesaplanmıştır.

Ayar	Temel model	Hati Glint SQL	Değişim
Doğrudan	40,09	47,26	+7,17
Düşünme modu	48,11	54,37	+6,26
Ajan (düşünme + geri bildirim)	43,35	55,35	+12,00

Çubuklar 0 ile 100 arasındadır. Kartın belirtmediği değişimler, gösterilen yuvarlanmış skorlardan hesaplanmıştır.

Doğrudan ayarda Hati Glint SQL, TURSpider dev’de 73,21 skor alıyor; temel modelin skoru 64,12 (+9,09). BIRDTurk dev’de ise 47,26 ile 40,09 (+7,17). Öteki iki ayarda da önde: TURSpider dev’de düşünme modunda 76,79’a karşı 71,18, BIRDTurk dev’de ajanla 55,35’e karşı 43,35.

55,35 mi? Yani BIRDTurk’te yanıtların neredeyse yarısı hâlâ yanlış.

Bu testte yüzde kırkın üzerinde, evet: 55,35 skoru, her yüz sorudan 44,65’inin referans sonuçla eşleşmediği anlamına geliyor. Endişelenmek yerinde. Bu aynı zamanda SQL’in satırların yanında ekranda kalmasının, çalıştırmanın salt okunur olmasının ve önemli bir iş için yanıta güvenmeden önce bir insanın sorguyu okumasının nedeni. Daha yüksek skor daha az hata demektir, hiç hata demek değil.

Uzmanlaşmanın bir bedeli de var ve kart onu da bildiriyor. Dört genel testte sayılar eğitimden sonra hafifçe düşüyor:

Genel kıyaslamalar (%), temel model ve Hati Glint SQL

TurkishMMLU−1,11

Temel model66,22

Hati Glint SQL65,11

Belebele-TR−0,45

Temel model86,67

Hati Glint SQL86,22

XCOPA-TR−0,20

Temel model91,80

Hati Glint SQL91,60

MMLU−0,20

Temel model78,80

Hati Glint SQL78,60

0255075100

Skor, 0 ile 100 arası

Okumak için bir satırın üzerine gelin, dokunun ya da odaklanın.

• Temel model
• Hati Glint SQL

Çubuklar 0 ile 100 arasındadır. Kartın belirtmediği değişimler, gösterilen yuvarlanmış skorlardan hesaplanmıştır.

Tablo olarak görün

Görev	Temel model	Hati Glint SQL	Değişim
TurkishMMLU	66,22	65,11	−1,11
Belebele-TR	86,67	86,22	−0,45
XCOPA-TR	91,80	91,60	−0,20
MMLU	78,80	78,60	−0,20

Çubuklar 0 ile 100 arasındadır. Kartın belirtmediği değişimler, gösterilen yuvarlanmış skorlardan hesaplanmıştır.

TurkishMMLU 66,22’den 65,11’e, Belebele-TR 86,67’den 86,22’ye, XCOPA-TR 91,80’den 91,60’a ve MMLU 78,80’den 78,60’a iniyor. Kart ayrıca İngilizce Spider’da (79,40’tan 84,24’e) ve ayrı tutulmuş bir Türkçe araç çağırma kümesinde (76,90’dan 78,90’a) artış bildiriyor. Kartın başlığındaki niteleyici de aynı nedenle önemli: “10B altındaki en güçlü açık Türkçe metinden SQL modeli, kendi değerlendirmemizde” bu testler hakkında, modeli yapanların yürüttüğü bir iddiadır.

Yürütme doğruluğunda bir soru ne zaman doğru sayılır?

1. Modelin sorgusu, referans sorguyla birebir aynı yazıldığında.
2. Modelin sorgusunu çalıştırmak, referansla aynı sonucu verdiğinde.
3. Modelin sorgusu hatasız çalıştığında.

Yanıtı göster

Metni değil, sonuçları karşılaştırır: aynı satırları döndüren, farklı yazılmış iki sorgunun ikisi de doğru sayılır. Ölçünün adı bu yüzden yürütme doğruluğu ve yukarıdaki şekildeki skor, satırların ne sıklıkla eşleştiğini söyler.

A değil: birçok farklı sorgu aynı satırları döndürür ve yürütme doğruluğu hepsini kabul eder.

C değil: bir sorgu hatasız çalışıp yine de yanlış satırlar döndürebilir; ilk şekildeki “En çok harcayan” gibi.

Şekildeki üçüncü ayar olan Ajan, “düşünme artı geri bildirim”dir. Model kartı, agent/ klasöründe küçük bir sarmalayıcı, HatiSQLAgent ile geliyor: modelin sorgularını salt okunur bir sanal ortamda çalıştırıyor ve bir sorgu hatayla başarısız olunca yeniden deniyor. Yalın söyleyişle: tek atış yerine model, veritabanının şikâyet ettiğini görüyor ve bir kez daha deneyebiliyor. Ajan ayarında temel model TURSpider dev’de 66,63, Hati Glint SQL 77,85 skor alıyor; BIRDTurk dev’de 43,35’e karşı 55,35: şekildeki en büyük farklar.

Düşünme modunun sayılabilir bir bedeli var. Model yanıtlamadan önce akıl yürütmesini yazıyor ve Hati Glint SQL aynı dev kümelerinde temel modelden daha az akıl yürütme token’ı kullandı: TURSpider dev’de 1.089’a karşı 299, BIRDTurk dev’de 1.582’ye karşı 522. Token, bir sözcüğün küçük bir parçasıdır; yani daha az akıl yürütme token’ı, sorgu görünmeden önce üretilecek daha az metin demektir.

Yeniden deneme döngüsü veritabanını ancak veritabanı şikâyet ettiğinde duyar. Çalışan ve yanlış şeyi sayan bir sorgu hata vermez.

Döngünün sınırı bu. Şekildeki “En çok harcayan” hatası, yalnızca hatada yeniden deneyen bir ajanın içinden olduğu gibi geçerdi, çünkü veritabanının şikâyet edecek bir şeyi yoktu. Döngü, hatalardan dönmeyi ucuzlatır. Yanıt önemli olduğunda SQL’i okuyan ve satırları örnekleyerek kontrol eden bir insanın yerini almaz.

Model sayfası, Hati Glint SQL, bilgileri, sayıları ve çalıştırma kodunu içeriyor; Hugging Face kartı ise runelab-ai/Hati-Glint-SQL-9B-v1 adresinde. bf16 ağırlıklar yaklaşık 16,8 GB GPU belleği gerektiriyor ve kart, çalıştırmanın yolları olarak Hugging Face transformers ve vLLM’i listeliyor. Düşünme modu varsayılan olarak kapalı; kartın örneği onu enable_thinking=True ile açıyor.

Yani dükkânımın verilerini kendi makinemde tutup yine de Türkçe soru sorabilir miyim?

Modeli kontrol ettiğiniz donanımda çalıştırabilirsiniz; burada şirket içi (on-premise) bunu ifade ediyor. Ona başka ne bağlarsanız bağlayın, bir sohbet penceresi, bir panel, satırları bir yere gönderen bir betik, verinin nereye gideceği konusunda kendi kuralları olacaktır.

Denerseniz, yukarıda gördüklerimizden yola çıkarak neyin işe yaradığına ve neyin yaramadığına dair kısa bir liste:

• Yapın: ona bir SQLite veritabanının şemasını verin ve çalıştırmayı salt okunur tutun.
• Yapın: SQL’i satırların yanında gösterin ve yanıt önemli olduğunda okuyun. Bir sayıyı elle doğrulayın.
• Yapın: boş bir sonucu ya da şaşırtıcı bir sayıyı sorguyu okumak için bir neden sayın.
• Yapmayın: ona yazma izni vermeyin; önemsediğiniz veride SQL’ini gözden geçirmeden çalıştırmayın.
• Yapmayın: başka SQL lehçeleri için sorgu beklemeyin; hangi verinin kime açık olacağına karar vermesine izin vermeyin.

Bu yazıdaki Hati Glint SQL ile ilgili her sayının kaynağı model kartıdır: Hugging Face’te Hati-Glint-SQL-9B-v1. TURSpider ve BIRDTurk adları, bu iş için olağan başlangıç noktası olan iki İngilizce ölçütü andırıyor: alanlar arası metinden SQL için bir veri kümesi olan Spider, “Spider: A Large-Scale Human-Labeled Dataset for Complex and Cross-Domain Semantic Parsing and Text-to-SQL Task” (Yu ve arkadaşları, 2018) makalesinde; daha büyük ve daha dağınık veritabanlarına genişletilmiş hâli ise “Can LLM Already Serve as A Database Interface? A BIg Bench for Large-Scale Database Grounded Text-to-SQLs” (Li ve arkadaşları, 2023) makalesinde. LoRA ise “LoRA: Low-Rank Adaptation of Large Language Models” (Hu ve arkadaşları, 2021) makalesinden geliyor.

Bu yazı çok şeyi dışarıda bırakıyor: modelin nasıl eğitildiğini, gerçek ve büyük veritabanlarının modele nasıl tarif edildiğini ve bir sorgunun içerebileceği her türlü hatayı. Dükkân, satırları, modelin yanıtları ve ilk şekildeki hatalar öğretmek için uydurulmuştur; gösterilen sorgular, gösterilen satırları verdiklerini doğrulamak için gerçek bir SQLite’ta çalıştırıldı, ama onları hiçbir model canlı üretmedi.

Metinden SQL, bir soruyu iki işe ayırır. Model şemanızı okur ve bir sorgu yazar; veritabanı onu çalıştırır ve sayıları üretir. Bu ayrım yanıtları denetlenebilir kılar, çünkü her sayı bir tablodaki satırlara kadar izlenebilir; riskin de olduğu yer burasıdır, çünkü çalışan bir sorgu doğru bir sorgu demek değildir. Hati Glint SQL, RuneLab’in kendi değerlendirmesinde iki Türkçe test kümesinde temel modelinden yüksek skor alıyor, genel testlerde küçük düşüşler var ve hâlâ kusursuzdan uzak. Onu bir şemayla, salt okunur, SQL ekranda ve önemli olanı bir insan kontrol ederek kullanın.