Metinden SQL'e Dönüştürme: LLM Doğruluğunun Karşılaştırılması

Danışmanlık günlerimden başlayarak 18 yıldır veri analizi için SQL kullanıyorum. Doğal dildeki soruları SQL'e çevirmek, verilere erişimi kolaylaştırarak, teknik becerisi olmayanların bile doğrudan veritabanlarıyla çalışmasına olanak tanıyor.

SQL komut üretimindeki performanslarını değerlendirmek için 34 büyük dil modeli (LLM) üzerinde metinden SQL'e dönüştürme kıyaslama metodolojimizi kullandık:

LLM tarafından oluşturulan SQL'de sık yapılan hatalar

LLM'ler genellikle dört tür hata yapar: hatalı birleştirmeler, toplama hataları, eksik filtreler ve sözdizimi hataları.

Yanlış birleştirme mantığı

Modeller genellikle tablolar arasındaki gerekli `JOIN` işlemlerini doğru bir şekilde belirleme ve uygulama konusunda zorluk yaşıyor, bazen bu işlemleri tamamen atlıyor veya daha az optimal alt sorguları yanlış kullanıyordu.

LLM, `CDSCode` kullanarak `frpm` ve `schools` tablolarını doğru şekilde birleştiremedi. Ayrıca sütun adlarında (`Charter`) ve filtre değerlerinde (`County = 'Fresno'`) yanıltıcı sonuçlar verdi .

Birleştirme mantığındaki hatalar, sorgunun ilişkisel yönünü temelden bozarak, birden fazla tablo söz konusu olduğunda eksik veya yanlış veri alınmasına yol açar.

Toplama ve gruplama hataları

Toplama fonksiyonlarının (örneğin `MAX`, `AVG`, `COUNT`, `SUM`) veya `GROUP BY` ifadelerinin yanlış uygulanması, kullanıcının amacına anlamsal olarak uymayan sonuçlara yol açan bir diğer yaygın hata noktasıydı.

LLM, " en yüksek ortalama puan " ifadesinin, verilerin ilçe bazında gruplandırılmasını (GROUP BY dname) ve bir toplama fonksiyonu (AVG(AvgScrRead)) kullanılmasını gerektirdiğini doğru bir şekilde belirledi. Mantığın bu kısmı doğrudur.

Ancak, LLM, sorudaki kritik bir filtreyi, yani " aktif " kelimesini , dahil etmeyi başaramadı . Bu gereksinimi karşılamak için, sorgunun satscores tablosunu schools tablosuyla birleştirmesi ve ardından sonuçları WHERE T1.StatusType = 'Active' koşuluyla filtrelemesi gerekiyordu.

Bu, yaygın bir LLM hatasını vurgular: birincil, açık bir talimatı (ortalama hesaplama) doğru bir şekilde yerine getirirken, ikincil ancak aynı derecede önemli bir koşulu (duruma göre filtreleme) gözden kaçırmak. Bu, birden fazla kısıtlamayı tek bir doğru sorguya sentezlemedeki bir zayıflığı gösterir.

Eksik veya yanlış filtreler

Modeller bazen gerekli `WHERE` koşullarını eklemekte veya `SELECT` ifadesinde yanlış sütunları seçmekte başarısız oluyor ve bu da kısıtlamaları veya istemde açıkça istenen bilgileri tam olarak ele almıyordu.

LLM, okulu bulmak için gereken mantığı (`ORDER BY NumGE1500 DESC LIMIT 1`) doğru bir şekilde belirledi, ancak istenen `Telefon` numarasını seçemedi ve bu numarayı almak için `okullar` tablosuna gerekli olan birleştirmeyi atladı.

Bu hatalar genellikle kullanıcının isteğinin eksik ayrıştırılmasından veya isteğin tüm kısımlarının nihai SQL sorgusu bileşenlerine eşleştirilememesinden kaynaklanır.

Sözdizimi hataları

Anlamsal hataların ötesinde, yanlış tablo takma adlarının kullanılması veya eksik SQL ifadelerinin oluşturulması gibi açık sözdizimi hataları da meydana geldi ve bu hatalar sorgunun yürütülmesini engelledi.

LLM, hatalı takma adlar (`account` yerine `accounts`) kullandı ve eksik bir dize sabiti (`'POPLATEK PO OBRATU…'`) içerdiğinden geçersiz SQL sözdizimine neden oldu.

Bu sözdizimi sorunları, SQL dilbilgisine ve veritabanına özgü kurallara sıkı sıkıya bağlı kod üretmenin zorluklarını ortaya koymaktadır.

Bazı Hukuk Lisans Mezunlarının SQL'de Daha İyi Olmasının Sebepleri

Büyük Dil Modeli'nin (LLM) basit bir İngilizce soruyu doğru bir SQL veritabanı sorgusuna dönüştürme yeteneğini belirleyen birkaç önemli faktör vardır.

1. Model boyutu ve eğitim verileri

• Boyut ve tasarım: Daha büyük modeller veya özel yapılarla üretilenler, SQL oluşturma gibi karmaşık görevleri daha etkili bir şekilde yerine getirebilir.
• Öğrendikleri: LLM'yi eğitmek için kullanılan veriler çok önemlidir. SQL yanıtlarıyla bağlantılı birçok soru örneği görürse, özellikle birleştirmeler veya hesaplamalar (TOPLAM, ORT) gibi karmaşık işlemler içeren sorular olursa, performansı muhtemelen daha iyi olacaktır.

2. SQL görevleri için ince ayar

• Modellere, özellikle metinden SQL'e dönüştürme görevlerine odaklanan ek eğitim verilebilir. Bu "ince ayar", modellerin yalnızca genel metin üzerinde eğitilmiş modellere kıyasla veritabanı yapılarını ve SQL kurallarını daha etkili bir şekilde anlamalarına yardımcı olur. Belirli talimatlar üzerinde eğitim de faydalıdır.

3. Akıl yürütme ve şema eşleme yetenekleri

• Mantıksal Akıl Yürütme: LLM, bazen belirsiz olan bir sorudan gereken adımları tam olarak ne kadar iyi belirleyebilir? SQL oluşturmak genellikle mantıksal adımlar gerektirir .
• Veritabanı haritasını (Şema) anlama: Bazı LLM'ler, sorudaki kavramları ("müşteriler" veya "toplam satışlar" gibi) veritabanındaki gerçek tablo ve sütun adlarıyla ilişkilendirmede daha iyidir; bu adlar hemen açık olmasa bile.

LLM'lerin SQL'i nasıl ürettiğine dair adım adım bir bakış

“Akıl yürütme” ve “şema eşleme” gibi faktörlerin nasıl işlediğini görmek için, bir modelin sorgu oluşturmak için izlediği adım adım süreci inceleyelim. Bu iş akışının tamamı, Geri Alma Destekli Üretim (RAG) adı verilen bir teknikle desteklenmektedir.

Aşama 1: İlk analiz ve veri tabanı seçimi

Bir soruyla karşılaştığında, LLM öncelikle kullanıcının niyetini analiz ederek en uygun veritabanı aracını seçer.

• Soru: “Kaç hesapta hesap sahibi tercihi bulunuyor ve işlem gerçekleştiğinde hesap özeti oluşturulması talep ediliyor?”
• LLM'nin Eylemi: Model, "hesaplar", "tasfiye" ve "işlem" gibi anahtar kelimeleri tanımlar. financial veritabanı aracının, california_schools veya superhero gibi diğerlerine göre doğru seçim olduğu sonucuna varır.

Aşama 2: RAG aracılığıyla şemayı alma

Model bir araç seçtikten sonra, veritabanının şemasını gösteren "haritaya" ihtiyaç duyar. Bu bilgiyi ezberinde tutmaz. Bunun yerine, RAG sistemi bu bilgiyi gerçek zamanlı olarak alır.

1. Veri Alma: Kullanıcının sorusu, şema bilgilerini depolayan bir vektör veritabanında arama yapmak için kullanılır. Arama, accounts ve disp tablolarının tanımları gibi en alakalı şema ayrıntılarını bulur ve getirir.
2. Genişletme: Elde edilen şema metni, orijinal sorunun yanına otomatik olarak eklenir.
3. Nesil: LLM artık ilerlemek için ihtiyaç duyduğu tüm bağlama sahip.

Bu RAG süreci, modelin yalnızca gerekli şema bilgilerini almasını sağlayarak görevini daha odaklı ve verimli hale getirir.

Aşama 3: Akıl yürütme ve sorgu oluşturma

Model, sorulan soru ve RAG tarafından sağlanan şema ile kullanıcının isteğindeki kavramları, aldığı belirli tablo ve sütun adlarına eşleştirir.

LLM'nin iç monologu:

1. Amaç: Kullanıcı sayı istiyor, bu yüzden SELECT COUNT(...) ile başlayacağım.
2. Koşullar:
   • “…sahibin tutumu…” -> disp tablo şemasında type sütunu var. type = 'OWNER' için WHERE maddesine ihtiyacım var.
   • “…bir işlem üzerine oluşturulacak ifade…” -> accounts tablo şemasında frequency sütunu bulunmaktadır. Filtre frequency = 'POPLATEK PO OBRATU' olmalıdır.
3. Birleştirmeler: Bilgiler accounts ve disp tablolarına bölünmüş durumda. Şema, bunların account_id ile bağlantılı olduğunu gösteriyor, bu yüzden bunları JOIN ile birleştirmem gerekiyor.

Aşama 4: Son SQL sorgusunun oluşturulması

Son olarak, model bu mantıksal parçaları sözdizimsel olarak doğru bir SQL sorgusuna dönüştürür. Bu çıktının kalitesi şunlara bağlıdır:

1. Mantıksal çıkarım yeteneği: Modelin, kullanıcının isteğini sağlanan şemaya mantıksal olarak bağlama yeteneği.
2. Eğitimden edinilen SQL bilgisi: Modelin SQL sözdizimi ve fonksiyonlarına dair temel anlayışı.

Bu süreç, hataların neden meydana geldiğini açıklar. Elde edilen şema belirsizse veya sorudaki bir terim düzgün bir şekilde eşleşmiyorsa, LLM'nin mantıklı bir tahminde bulunması gerekir; bu da daha önce analiz ettiğimiz hatalara yol açabilir.

Text-to-SQL nedir?

Metinden SQL'e dönüştürme (Text-to-SQL), günlük dili yapılandırılmış sorgu dilinde yazılmış bir SQL sorgusuna dönüştüren bir doğal dil işleme teknolojisidir. Kullanıcı, SQL kodunu elle yazmak yerine, doğal dilde bir soru sorar ve sistem, veritabanında yürütülebilecek bir SQL ifadesi oluşturur.

Metinden SQL'e dönüştürmenin temel amacı, insanların veriler hakkında düşünme biçimi ile veritabanlarının sorguların yazılmasını gerektirme biçimi arasındaki farkı azaltmaktır. Bu, özellikle iş bağlamını anlayan ancak sıfırdan SQL sözdizimi yazmakta rahat olmayan teknik olmayan kullanıcılar ve veri analistleri için önemlidir.

En temel düzeyde, bir kullanıcı şu gibi bir soru sorduğunda:

• "Geçtiğimiz ay New York'tan alışveriş yapan tüm müşterileri göster."

Sistem, bu isteği doğru sütunları seçen, tarih ve konum kısıtlamalarını kullanarak satırları filtreleyen ve gerekli veritabanı tablolarını birleştiren oluşturulmuş bir SQL sorgusuna dönüştürür. Çıktının kalitesi, sistemin hem kullanıcının amacını hem de veritabanı şemasını yansıtan doğru sorgular oluşturup oluşturamayacağına bağlıdır.

Günümüzde metinden SQL'e dönüştürme işleminin faydalı olduğu yerler

Text-to-SQL aşağıdaki durumlarda oldukça iyi sonuç verir:

• Veri analistlerinin inceleyip düzenleyebileceği taslak sorgular oluşturun.
• Hızın hassasiyetten daha önemli olduğu durumlarda keşifsel veri analizini destekleyin.
• Teknik bilgiye sahip olmayan kullanıcıların önceden tanımlanmış şemalar aracılığıyla basit verilere erişmesine olanak tanıyın.
• SQL kullanıcılarına tekrarlayan sorgular yazma ihtiyacını azaltarak yardımcı olun.

Bu durumlarda, metinden SQL'e dönüştürme işlemi, özerk bir sistemden ziyade yardımcı bir yapay zeka aracı olarak işlev görür. Özellikle doğruluğun önemli olduğu durumlarda, insan incelemesi iş akışının bir parçası olmaya devam eder.

Metinden SQL'e dönüştürme işlemi nasıl çalışır?

Modern metinden SQL'e dönüştürme sistemleri, doğal dil soruları ve SQL sorguları çiftleri üzerinde eğitilmiş büyük dil modellerine dayanır. Bu modeller, günlük dili SQL yapılarına, tablo adlarına, sütunlara ve ilişkilere bağlayan kalıpları öğrenir. Bu süreç tipik olarak şu adımları izler:

Doğal dil anlama

Sistem öncelikle kullanıcının girdisini analiz ederek niyetini, kısıtlamalarını ve varlıklarını belirler. Bu adım şunları içerir:

• Kullanıcının ne istediğini belirlemek (örneğin, toplamlar, filtreler, karşılaştırmalar)
• Zaman aralıkları, konumlar veya kategoriler gibi ilgili koşulları ayıklama
• İş bağlamı gerektirebilecek belirsiz ifadelerin yorumlanması

Bu aşamada yapılan hatalar genellikle doğru gibi görünen ancak yanlış soruyu yanıtlayan bir SQL sorgusuna yol açar.

Şema eşleme

Ardından sistem, sorudaki terimleri veritabanı şemasına eşler. Bu, şunları içerir:

• Sorudaki kavramları tablo adları ve sütunlarıyla eşleştirme
• Tablolar arasındaki ilişkileri anlamak
• Tarihler, sayısal alanlar veya kategoriler gibi veri türlerine saygı göstermek.

Tablo sayısı arttıkça veya sütun adları, kullanıcıların doğal dil sorularında verileri tanımlama biçimiyle yakından eşleşmediğinde şema eşleştirmesi daha zor hale gelir.

SQL sorgusu oluşturma

Amaç ve şema unsurları belirlendikten sonra, sistem SQL sorgusunu oluşturur. Bu işlem şunları içerebilir:

• Doğru tabloları ve sütunları seçmek
• Gerekli tüm tablolara birleştirmeler ekleniyor.
• Filtreleme, toplama ve gruplandırma mantığı uygulama
• MySQL veya PostgreSQL gibi sistemler için sözdizimsel olarak geçerli SQL kodu üretmek.

Bu aşamada, sistem örneğin yanlış birleştirme koşulu veya toplama işlemi kullanarak geçerli ancak mantıksal olarak yanlış SQL sorguları üretebilir.

Doğrulama ve yürütme

Bazı sistemler, oluşturulan SQL sorgusunun çalıştırılıp sonuç döndürebileceğini doğrulayan doğrulama katmanları içerir. Daha gelişmiş araçlar, sorgu belirsiz olduğunda sınırlı optimizasyon denemeleri yapabilir veya ek sorular sorabilir.

Ancak doğrulama nadiren doğru cevabı garanti eder. Bir sorgu başarıyla yürütülebilir ancak yine de ince ayrıntılarla yanlış olabilir.

Sınırlamalar ve pratik riskler

Yüksek performans puanlarına rağmen, gerçek dünya kullanımında göz ardı edilemeyecek çeşitli sınırlamalar ortaya çıkmaktadır.

Güvenilirlik ve doğruluk

En iyi performans gösteren modeller bile karmaşık sorguların önemli bir bölümü için doğru SQL kodu üretemez. %20 veya daha yüksek bir hata oranı şu anlama gelir:

• Oluşturulan sorguların beşte biri yanıltıcı sonuçlar döndürebilir.
• Hatalar genellikle sözdizimsel olmaktan ziyade anlamsaldır.
• Yanlış birleştirmeler, filtreler veya toplama işlemleri fark edilmeyebilir.

Bu durum, özellikle kullanıcıların çıktının doğru olduğunu varsaydığı raporlama, tahmin veya karar destek sistemlerinde oldukça risklidir.

İnsan gözetimine bağımlılık

Mevcut performans göz önüne alındığında, oluşturulan SQL kodunun SQL ve veritabanı konusunda bilgili biri tarafından incelenmesi gerekmektedir. Bu denetim olmadan:

• Kullanıcılar, sorgunun başarılı bir şekilde yürütüldüğü için hatalı bir sorguya güvenebilirler.
• Hatalar gösterge panellerine, raporlara veya alt sistemlere yayılabilir.
• Kararlar yapay zekâ tarafından üretilen çıktılara dayandığında hesap verebilirlik belirsizleşir.

Text-to-SQL, SQL uzmanlığına olan ihtiyacı ortadan kaldırmaz; sadece bu uzmanlığın uygulandığı alanı değiştirir.

Karmaşıklık tavanı

Sorgu karmaşıklığı arttıkça performans keskin bir şekilde düşer. Modeller şu konularda zorlanır:

• Birden fazla tablo arasında birden fazla birleştirme
• İç içe mantık ve alt sorgular
• Alana özgü hesaplamalar
• Veritabanı şemasına dair derin bilgi gerektiren sorgular

BIRD-SQL gibi kıyaslama testleri, gelişmiş modeller için bile karmaşık sorguların temel hata noktası olmaya devam ettiğini vurgulamaktadır.

Model değişkenliği

Modeller arasındaki performans farklılıkları önemli. Bazı dil modelleri oldukça iyi performans gösterirken, diğerleri aynı veri kümesinde sık sık başarısız oluyor. Bu şu anlama geliyor:

• Model seçimi, doğruluğu doğrudan etkiler.
• İnce ayar ve eğitim verileri önemlidir.
• Genel amaçlı modeller, alan uyarlaması yapılmadan iyi çalışmayabilir.

Veritabanları ve kullanım durumları genelinde aynı derecede iyi sonuç veren evrensel bir çözüm yoktur.

Veri yönetimi ve gizlilik

Metinden SQL'e dönüştürme sistemleri ek erişim riskleri getirir:

• Kullanıcılar, sonuçlarını anlamadan hassas tablolara sorgu yapabilirler.
• Oluşturulan SQL sorguları, veritabanı şeması hakkında meta veriler ortaya çıkarabilir.
• Veri gizliliği kontrolleri, dil modelinin dışında da uygulanmalıdır.

Güçlü erişim kontrolleri olmadan, metinden SQL'e dönüştürme işlemi mevcut yönetim uygulamalarını zayıflatabilir.

Metinden SQL'e dönüştürme için kıyaslama metodolojisi

Bu kıyaslama testi, veri kümesinin oluşturulmasını, ajan mimarisini, anlamsal belirsizlik sorununu ve tam puanlama kriterlerini ayrıntılı olarak açıklayan ajan tabanlı RAG kıyaslama testimizle aynı değerlendirme çerçevesini paylaşmaktadır.

Her iki kıyaslama da aynı 500 soruluk BIRD-SQL veri setini kullanmaktadır. ¹ alt küme, ajansal işlem hattı, ChromaDB destekli şema alma ve Claude 4 Sonnet ile LLM-hakem değerlendirmesi. Burada raporlanan ölçüt, doğru SQL komutu oluşturma oranı, modelin hem doğru veritabanına yönlendirdiği hem de anlamsal olarak doğru bir SQL sorgusu oluşturduğu soruların yüzdesidir. Tüm modeller, sıcaklık 0 ve alan özel ipuçları olmaksızın aynı sıfır atış koşulları altında değerlendirilmiştir.

Daha fazla okuma

Aşağıdakiler gibi diğer RAG kıyaslamalarını inceleyin:

• Gömme Modelleri: OpenAI vs Gemini vs Cohere
• RAG için En İyi Vektör Veritabanı: Qdrant vs Weaviate vs Pinecone
• Hibrit RAG: RAG Doğruluğunu Artırma
• Agentic RAG kıyaslama testi: çoklu veritabanı yönlendirme ve sorgu oluşturma
• RAG için en iyi 10 çok dilli gömme modeli

Değişiklik Günlüğü

20 Şubat 2026

Karşılaştırma listesine 2 yeni model eklendi:

• Google: Gemini 3.1 Pro Önizlemesi (google/gemini-3.1-pro-preview)
• Anthropic: Claude Sonnet 4.6 (antropik/claude-sonnet-4.6)

10 Şubat 2026

Karşılaştırma listesine 2 yeni model eklendi:

• Claude Opus 4.6 (antropik/claude-opus-4.6)
• Kimi K2.5 (moonshotai/kimi-k2.5)

SSS'ler

Referans Linkleri

1.

[2305.03111] Can LLM Already Serve as A Database Interface? A BIg Bench for Large-Scale Database Grounded Text-to-SQLs

Cem Dilmegani

Baş Analist

Takip Et

Cem, 2017'den beri AIMultiple'da baş analist olarak görev yapmaktadır. AIMultiple, her ay Fortune 500 şirketlerinin %55'i de dahil olmak üzere yüz binlerce işletmeye (benzer Web'e göre) bilgi sağlamaktadır. Cem'in çalışmaları, Business Insider, Forbes, Washington Post gibi önde gelen küresel yayınlar, Deloitte, HPE gibi küresel firmalar, Dünya Ekonomik Forumu gibi STK'lar ve Avrupa Komisyonu gibi uluslararası kuruluşlar tarafından alıntılanmıştır. AIMultiple'ı referans gösteren daha fazla saygın şirket ve kaynağı görebilirsiniz. Kariyeri boyunca Cem, teknoloji danışmanı, teknoloji alıcısı ve teknoloji girişimcisi olarak görev yapmıştır. On yıldan fazla bir süre McKinsey & Company ve Altman Solon'da işletmelere teknoloji kararları konusunda danışmanlık yapmıştır. Ayrıca dijitalleşme üzerine bir McKinsey raporu yayınlamıştır. Bir telekom şirketinin CEO'suna bağlı olarak teknoloji stratejisi ve tedarikini yönetmiştir. Ayrıca, 2 yıl içinde sıfırdan 7 haneli yıllık yinelenen gelire ve 9 haneli değerlemeye ulaşan derin teknoloji şirketi Hypatos'un ticari büyümesini yönetmiştir. Cem'in Hypatos'taki çalışmaları TechCrunch ve Business Insider gibi önde gelen teknoloji yayınlarında yer aldı. Cem düzenli olarak uluslararası teknoloji konferanslarında konuşmacı olarak yer almaktadır. Boğaziçi Üniversitesi'nden bilgisayar mühendisliği diplomasına ve Columbia Business School'dan MBA derecesine sahiptir.

Tam Profili Görüntüle

Araştıran

Ekrem Sarı

Yapay Zeka Araştırmacısı

Takip Et

Ekrem, AIMultiple'da yapay zeka araştırmacısı olarak çalışmakta olup, akıllı otomasyon, GPU'lar, yapay zeka ajanları ve RAG çerçeveleri üzerine yoğunlaşmaktadır.

Tam Profili Görüntüle

Yorumlar 1

Düşüncelerinizi Paylaşın

E-posta adresiniz yayınlanmayacak. Tüm alanlar gereklidir.

Ad

E-posta Adresi

Yorum

0/450

Yorumu Gönder

PFJ Rofgowski

Dec 10, 2025 at 20:04

Curious, how much of the context engineering and specific prompting did you apply in your benchmarks. Or, was it to review the models only? I have found much higher return of correct and consistent responses. A higher fidelity. To do that, I needed to provide a most sophisticated prompt that fed the context window as the question was being asked. Not perfect, but better than those scores represented in this article when using the Grok 4.x .

Yanıtla

Ekrem Sarı

Feb 10, 2026 at 08:46

Great point. This benchmark intentionally uses zero-shot, minimal prompting with temperature=0. No few-shot examples, no domain-specific instructions, no iterative refinement. The goal was to measure each model's baseline text-to-SQL capability. So your experience with Grok 4 getting higher fidelity through sophisticated context engineering is completely expected. A well-crafted prompt with detailed schema descriptions, few-shot examples, and domain-specific rules will improve any model's performance significantly. What this benchmark isolates is how well the model performs out-of-the-box when given only the raw question and retrieved schema, which helps compare the models' inherent SQL reasoning abilities on a level playing field.           We'll make this clearer in the methodology section. Thanks for raising it.

Yanıtla