Yapay Zekanın Ürettiği SQL'in Doğruluğu Nasıl Ölçülür? Kendi Sonuçlarımızla

Bir text-to-SQL aracının sayfasında "%97 doğruluk" yazıyorsa ilk sorulacak soru şudur: neyi saydınız? Çünkü bu alanda iki farklı şey "doğru" diye ölçülüyor ve aradaki fark, yanlış rakamla karar vermekle doğru rakamla karar vermek arasındaki fark kadar büyük.

"Doğru görünen" sorgu neden yetmez?

Ucuz yöntem, üretilen SQL metnini referans SQL ile karşılaştırmaktır. Ama aynı soruyu doğru cevaplayan onlarca farklı SQL yazılabilir; tersine, referansa çok benzeyen bir sorgu tek kelimelik farkla yanlış veri döndürebilir. Sorgu çalışır, bir sayı gelir, sayı yanlıştır ve hata mesajı yoktur. Bu yüzden biz metne hiç bakmıyoruz.

Bizim yöntem: sonucu say, metni değil

• Her test sorusu için önceden elle yazılmış, doğruluğu bilinen bir referans sorgu var.
• Modelin ürettiği sorgu canlı bir veritabanında gerçekten çalıştırılıyor.
• Dönen veri, referans sorgunun döndürdüğü veriyle satır satır karşılaştırılıyor. Kolon sırası farklıysa ama değerler doğruysa geçer; model istenenden fazla bağlam kolonu eklediyse ve istenen değerler içindeyse yine geçer.
• Sette bilerek cevaplanamaz sorular da var: veritabanında karşılığı olmayan bir soruya model SQL uydurmak yerine "bu veriyle cevaplanamaz" diyebiliyor mu, o da ayrıca test ediliyor.

Güncel sonuçlar, süzgeçsiz

Son tam koşuda set 661 gerçek sorudan oluşuyordu; sorular dört motorda (PostgreSQL, SQL Server, MySQL, Oracle) ve satış, hastane, İK, üniversite gibi farklı alan şemalarında koşuldu. Genel sonuç 593/661, yani %90. Tipik iş şemalarında (anlamlı tablo ve kolon adları olan) süitler %94 ile %100 arasında; sitedeki %94 rakamı bu sınıfın özetidir.

Peki geri kalan nerede kayboluyor? Kasıtlı olarak zorlaştırılmış "legacy" süitlerde: kolon adları kriptik kısaltmalardan oluşan, açıklamasız eski şemalar. Orada sonuç %60-80 bandına iniyor. Bunu saklamıyoruz çünkü işin en önemli pratik dersi tam burada: text-to-SQL doğruluğunun bir numaralı değişkeni model değil, şemanızın okunabilirliği. Kriptik kolonlara uygulama içinden açıklama eklemek, doğruluğu en çok artıran tek hamle.

En çok hangi hataları yapıyor?

• Fazladan satır: bir birleştirme beklenenden fazla satır çoğaltıyor; referans 5 satır beklerken 6 gelmesi gibi. Ölçüm bunu anında yakalar.
• Yanlış kolon seçimi: benzer adlı iki kolondan yanlışını kullanmak. Kriptik şemaların klasik hatası.
• Belirsiz sorunun farklı yorumu: "en yoğun servis" gibi bir ifadeyi modelin başka bir metrikle yorumlaması. Teknik olarak savunulabilir ama referanstan farklı; biz yine hata sayarız.

Bu hata sınıflarının hiçbiri veri bozmaz, çünkü üretim salt-okunurdur; risk yanlış bilgi riskidir. Panzehiri de ölçümün kendisi ve sorgunun her zaman görünür olması: rakama güvenmeden önce neye baktığınızı görebilirsiniz.

Yöntemin kısa özeti ve güncel skor persight.ai/dogruluk sayfasında duruyor. Kendi verinizde nasıl davrandığını görmek en sağlıklısı; beta sırası persight.ai/beta adresinde.