Metinden SQL'e: LLM Doğruluk Karşılaştırması

18 yıldır veri analizi için SQL'i kullanıyorum ve bu yolculuğum danışmanlık günlerimle başladı. Doğal dildeki soruları SQL'e çevirmek, verilere erişimi daha kolay hale getirir ve teknik becerilere sahip olmayan herkesin doğrudan veritabanlarıyla çalışmasına olanak tanır.

34 büyük dil modelini (LLM) metinden SQL'e kıyaslama metodolojimiz ile test ederek SQL komut üretimi performanslarını değerlendirdik:

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

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

Yanlış birleştirme mantığı

Modeller, tablolar arasında gerekli `JOIN` işlemlerini doğru şekilde tanımlamakta ve uygulamakta genellikle zorlanır ve bazen bunları tamamen atlar veya daha az etkili alt sorguları yanlış kullanır.

LLM, `frpm` ve `schools` tablolarını `CDSCode` kullanarak doğru şekilde birleştirmeyi başaramadı. Ayrıca sütun adlarını (`Charter`) ve filtre değerlerini (`County = ‘Fresno’`) uydurdu.

Birleştirme mantığındaki hatalar, birden fazla tablo içeren sorgularda verilerin eksik veya yanlış alınmasına neden olarak sorgunun ilişkisel yönünü temelinden bozar.

Toplama ve gruplama hataları

Toplama fonksiyonlarını (`MAX`, `AVG`, `COUNT`, `SUM`) veya `GROUP BY` ifadelerini yanlış uygulamak başka bir yaygın başarısızlık noktasıdır ve bu da kullanıcı amacına anlamca uymayan sonuçlara yol açar.

LLM, “en yüksek ortalama puan” ifadesinin verileri bölgeye göre gruplamayı (GROUP BY dname) ve bir toplama fonksiyonunu (AVG(AvgScrRead)) kullanmayı gerektirdiğini doğru şekilde belirledi. Bu mantık kısmı doğrudur.

Yine de, LLM sorudaki “aktif” kelimesi gibi kritik bir filtreyi başarısız bir şekilde dahil etmeyi başaramadı. Bu gereksinimi karşılamak için sorgu, satscores tablosunu schools tablosuyla birleştirmeli ve ardından WHERE T1.StatusType = ‘Active’ ifadesiyle sonuçları filtrelemelidir.

Bu, yaygın bir LLM başarısızlığını ortaya koyar: birincil, açık talimatı (bir ortalama hesaplamak) doğru bir şekilde uygularken ikincil ama eşit derecede önemli bir koşulu (duruma göre filtreleme) kaçırmak. Bu, birden fazla kısıtlamayı tek bir doğru sorguda sentezlemede bir zayıflığı gösterir.

Eksik veya yanlış filtreler

Modeller bazen gerekli `WHERE` ifadelerini eklemeyi atlayabilir veya `SELECT` ifadesinde yanlış sütunları seçebilir ve bu da isteminde açıkça belirtilen kısıtlamaları veya bilgiyi tam olarak ele almaz.

LLM, okulu bulmak için mantığı doğru şekilde belirledi (`ORDER BY NumGE1500 DESC LIMIT 1`), ancak istenen `Phone` numarasını seçmeyi başaramadı ve bunu almak için gerekli olan `schools` tablosuyla birleştirme işlemini atladı.

Bu tür hatalar genellikle kullanıcının isteğinin eksik ayrıştırılmasından veya isteğin tüm parçalarının nihai SQL sorgu bileşenlerine haritalanamamasından kaynaklanır.

Sözdizimi hataları

Anlamsal hataların ötesinde, yanlış tablo takma adlarının kullanılması veya eksik SQL ifadelerinin üretilmesi gibi düz sözdizimi hataları da meydana geldi ve bu da sorgunun çalışmasını engelledi.

LLM, yanlış takma adlar kullandı (`accounts` yerine `account`) ve eksik bir dize sabiti (`’POPLATEK PO OBRATU…’`) ekledi ve bu da geçersiz SQL sözdizimine neden oldu.

Bu sözdizimi sorunları, SQL dilbilgisi ve veritabanına özgü kurallara sıkı sıkıya uyan kod üretmede karşılaşılan zorlukları ortaya koyar.

Bazı LLM'lerin SQL konusunda neden daha iyi olduğu

Bir Büyük Dil Modelinin (LLM) düz bir İngilizce soruyu doğru bir SQL veritabanı sorgusuna dönüştürme başarısını belirleyen birkaç önemli faktör vardır.

1. Model boyutu ve eğitim verisi

• Boyut ve tasarım: Daha büyük modeller veya belirli yapılarla inşa edilmiş modeller, SQL üretimi gibi karmaşık görevleri daha etkili bir şekilde ele alabilir.
• Ne öğrendi: LLM'in eğitildiği veri çok önemlidir. Eğer sorgulama (JOIN) veya hesaplama (SUM, AVG) gibi karmaşık işlemler içeren sorularla SQL yanıtlarının eşleştirildiği birçok örneği görürse, muhtemelen daha iyi performans gösterecektir.

2. SQL görevleri için ince ayar

• Modellere metinden SQL'e görevlerine odaklanan ek eğitim verilebilir. Bu “ince ayar”, onların veritabanı yapılarını ve SQL kurallarını yalnızca genel metin üzerinde eğitilmiş modellere göre daha etkili bir şekilde anlamasına yardımcı olur. Belirli talimatlar üzerinde eğitim de yardımcı olur.

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

• Akıl yürütme: LLM, bazen belirsiz bir sorudan tam olarak hangi adımların gerektiğini ne kadar iyi çıkarabilir? SQL oluşturma genellikle mantıksal adımlar gerektirir.
• Veritabanı haritasını (Şema) anlama: Bazı LLM'ler, isimler hemen açık olmasa bile, sorudaki kavramları (örneğin “müşteriler” veya “toplam satış”) veritabanındaki gerçek tablo ve sütun adlarıyla bağlamada daha iyidir.

LLM'lerin SQL üretme şekli: Adım adım bir bakış

“Akıl yürütme” ve “şema eşleme” gibi faktörleri hareket halinde görmek için bir modelin bir sorgu üretmek için izlediği adımları inceleyelim. Bu tüm iş akışı, Geriye Çağırma ile Artırılmış Üretim (RAG) adı verilen bir teknikle çalışır.

Aşama 1: Başlangıç analizi ve veritabanı seçimi

Bir soruyla karşılaşıldığında, LLM önce kullanıcı amacını analiz ederek en ilgili veritabanı aracını seçer.

• Soru: “İşlem sırasında bir ekstrenin oluşturulması isteğiyle sahiplik durumuna sahip kaç hesap vardır?”
• LLM'in Eylemi: Model, “hesaplar”, “durum” ve “işlem” gibi anahtar kelimeleri belirler. financial veritabanı aracının california_schools veya superhero gibi diğerlerine göre doğru seçim olduğunu sonucuna varır.

Aşama 2: Şemanın RAG ile alınması

Model bir araç seçtikten sonra veritabanının “haritası” olan şemaya ihtiyaç duyar. Bu bilgiyi ezberlememiştir. Bunun yerine, RAG sistemi bunu gerçek zamanlı olarak alır.

1. 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ı için tanımlamalar gibi en ilgili şema ayrıntılarını bulur ve alır.
2. Artırma: Alınan şema metni, orijinal soruyla birlikte otomatik olarak isteme eklenir.
3. Üretim: LLM artık devam etmesi için gereken tüm bağlamı almıştır.

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

Soruyla RAG tarafından sağlanan şemayı elinde bulunduran model, kullanıcının isteğindeki kavramları yeni aldığı özel tablo ve sütun adlarıyla eşler.

LLM'in iç monologu:

1. Amaç: Kullanıcı bir sayı istiyor, bu yüzden SELECT COUNT(...) ile başlayacağım.
2. Koşullar:
   • “…sahip durumu…” -> disp tablosu şemasında type sütunu var. type = 'OWNER' için bir WHERE ifadesine ihtiyacım var.
   • “…işlem sırasında bir ekstrenin oluşturulması isteği…” -> accounts tablosu şemasında frequency sütunu var. Filtre frequency = 'POPLATEK PO OBRATU' olmalıdır.
3. Birleştirmeler: Bilgi accounts ve disp tabloları arasında bölünmüştür. Şema, bunların account_id ile bağlantılı olduğunu gösterir, bu yüzden bunları JOIN yapmam gerekir.

Aşama 4: Nihai SQL'in oluşturulması

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

1. Akıl yürütme yeteneği: Modelin, kullanıcının isteğini sağlanan şemayla mantıksal olarak bağlama yeteneği.
2. Eğitimden gelen SQL bilgisi: Modelin SQL sözdizimi ve fonksiyonlarına dair temel anlayışı.

Bu süreç, neden hataların meydana geldiğini açıklar. Alınan şema belirsizse veya sorudaki bir terim temiz bir şekilde eşleşmiyorsa, LLM eğitilmiş bir tahminde bulunmak zorunda kalır ve bu da daha önce analiz ettiğimiz hatalara yol açabilir.

Metinden SQL'e nedir?

Metinden SQL'e, günlük dili yapılandırılmış sorgu dili olan 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 bir veritabanında çalıştırılabilecek bir SQL ifadesi oluşturur.

Metinden SQL'e teknolojisinin temel amacı, insanların veri hakkında düşünme şekliyle veritabanlarının sorguların nasıl yazılması gerektiği arasındaki boşluğu azaltmaktır. Bu özellikle iş bağlamını anlayan ancak SQL sözdizimini baştan yazmaktan hoşlanmayan teknik olmayan kullanıcılar ve veri analistleri için geçerlidir.

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

• “Geçen ay New York’tan alışveriş yapan tüm müşterileri göster.”

Sistem, doğru sütunları seçen, tarih ve konum kısıtlamalarını kullanarak satırları filtreleyen ve gerekli veritabanı tablolarını birleştiren bir SQL sorgusu oluşturur. Çıktının kalitesi, sistemin kullanıcı amacını ve veritabanı şemasını yansıtan doğru sorgular oluşturup oluşturamamasına bağlıdır.

Metinden SQL'e bugün nerede faydalıdır?

Metinden SQL'e şu alanlarda makul düzeyde iyi çalışır:

• Veri analistlerinin gözden geçirip ayarlayabileceği taslak sorgular oluşturmak.
• Hızın doğruluktan daha önemli olduğu keşfedici veri analizini desteklemek.
• Teknik olmayan kullanıcıların önceden tanımlanmış şemalar aracılığıyla basit verilere erişmesine izin vermek.
• Tekrarlanan sorguları yazma ihtiyacını azaltarak SQL kullanıcılarına yardımcı olmak.

Bu durumlarda metinden SQL'e, özerk bir sistemden ziyade yardımcı bir yapay zeka aracı olarak işlev görür. İnsan incelemesi, özellikle doğruluk önemli olduğunda iş akışının bir parçası olmaya devam eder.

Metinden SQL'e nasıl çalışır?

Günümüzdeki metinden SQL'e sistemleri, doğal dil soruları ile SQL sorgularının eşleştirildiği çiftler üzerinde eğitilmiş büyük dil modellerine dayanır. Bu modeller, günlük dile SQL yapılarını, tablo adlarını, sütunları ve ilişkileri bağlayan kalıpları öğrenir. Süreç genellikle bir dizi adımı takip eder:

Doğal dil anlama

Sistem önce kullanıcı girişini analiz ederek amacı, kısıtlamaları ve varlıkları 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ıklamak
• İş bağlamı gerektirebilecek belirsiz ifadeleri yorumlamak

Bu aşamadaki hatalar genellikle yanlış soruya cevap veren doğru görünümlü bir SQL sorgusuna yol açar.

Şema eşleme

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

• Sorudaki kavramları tablo adları ve sütunlarla eşleştirmek
• Tablolar arasındaki ilişkileri anlamak
• Tarihler, sayısal alanlar veya kategoriler gibi veri türlerine saygı duymak

Tablo sayısı arttıkça veya sütun adları kullanıcıların doğal dilde veriyi tanımlama şekline yakın değilse şema eşleme daha zor hale gelir.

SQL sorgu oluşturma

Amaç ve şema öğeleri belirlendikten sonra sistem SQL sorgusunu oluşturur. Bu şunları içerebilir:

• Doğru tabloları ve sütunları seçmek
• Gerekli tüm tablolar arasında birleştirmeler eklemek
• Filtreler, toplamalar ve gruplama mantığı uygulamak
• MySQL veya PostgreSQL gibi sistemler için sözdizimsel olarak geçerli SQL kodu üretmek

Bu aşamada sistem, yanlış birleştirme koşulu veya toplama kullanarak geçerli ama mantıksal olarak yanlış SQL kolayca üretebilir.

Doğrulama ve yürütme

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

Yine de doğrulama, doğru bir cevabı nadiren garanti eder. Bir sorgu başarıyla çalışabilir ve yine de ince yollarla yanlış olabilir.

Sınırlamalar ve pratik riskler

Güçlü kıyaslama puanlarına rağmen gerçek dünya kullanımı göz ardı edilemeyecek birkaç sınırlamayı ortaya çıkarır.

Güvenilirlik ve doğruluk

En iyi performans gösteren modeller bile karmaşık sorguların önemli bir kısmında doğru SQL üretmekte başarısız olur. %20 veya daha yüksek bir hata oranı şunu anlamına gelir:

• Her beş sorgudan biri yanıltıcı sonuçlar döndürebilir
• Hatalar genellikle sözdizimsel değil anlamsaldır
• Yanlış birleştirmeler, filtreler veya toplamalar fark edilmeyebilir

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

İnsan denetimine bağımlılık

Şimdiki performans göz önünde bulundurulduğunda oluşturulan SQL'i SQL ve veritabanını anlayan birinin incelemesi gerekir. Bu denetim olmadan:

• Kullanıcılar sorgu başarıyla çalıştığı için yanlış bir sorguya güvenebilir
• Hatalar panolara, raporlara veya alt sistemlere yayılabilir
• Kararlar yapay zeka tarafından oluşturulan çıktıya dayanıyorsa sorumluluk belirsiz hale gelir

Metinden SQL'e SQL uzmanlığı ihtiyacını ortadan kaldırmaz; bu uzmanlığın nerede uygulandığını değiştirir.

Karmaşıklık sınırı

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

• Birçok tablo arasında birden fazla birleştirme
• İç içe mantık ve alt sorgular
• Alanlara özel hesaplamalar
• Veritabanı şemasına dair derin bilgi gerektiren sorgular

BIRD-SQL gibi kıyaslama testleri, karmaşık sorguların gelişmiş modeller için bile birincil başarısızlık noktası olduğunu vurgular.

Model değişkenliği

Modeller arasındaki performans farkları önemlidir. Bazı dil modelleri makul düzeyde iyi performans gösterirken diğerleri aynı veri kümesinde sık sık başarısız olur. Bu şu anlama gelir:

• Model seçimi doğrudan doğruluk üzerinde etkili olur
• İnce ayar ve eğitim verisi önemlidir
• Genel amaçlı modeller alan uyumlandırması olmadan iyi çalışmayabilir

Veritabanları ve kullanım alanları boyunca eşit derecede iyi çalışan evrensel bir çözüm yoktur.

Veri yönetimi ve gizlilik

Metinden SQL'e sistemleri ek erişim riskleri getirir:

• Kullanıcılar etkilerini anlamadan hassas tablolara sorgu gönderebilir
• Oluşturulan SQL, veritabanı şeması hakkında meta veri ortaya çıkarabilir
• Veri gizlilik kontrolleri dil modeli dışında uygulanmalıdır

Güçlü erişim kontrolleri olmadan metinden SQL'e mevcut yönetim uygulamalarını zayıflatabilir.

Google Arama'da daha fazla kıyaslamamızı ve veri odaklı içgörülerimizi görün.

Tercih edilen kaynak olarak ekle

Metinden SQL'e kıyaslama metodolojisi

Bu kıyaslama, veri kümesi yapımı, ajan mimarisi, anlamsal belirsizlik zorluğu ve tam puanlama kılavuzu hakkında ayrıntılı bilgi veren ajan RAG kıyaslama testimizle değerlendirme çerçevesini paylaşır.

Her iki kıyaslama da aynı 500 soruluk BIRD-SQL¹ alt kümesini, ajan hattını, ChromaDB destekli şema alımını ve LLM-as-Judge değerlendirmesini Claude 4 Sonnet ile kullanır. Burada bildirilen metrik, doğru SQL komut üretme oranı, modelin hem doğru veritabanına yönlendirildiği hem de anlamsal olarak doğru bir SQL sorgusu ürettiği soruların yüzdesidir. Tüm modeller sıfır örnekli koşullar altında, sıcaklık 0 ve alanlara özgü ipuçları olmadan değerlendirildi.

Daha fazla okuma

Diğer RAG kıyaslama testlerini keşfedin, örneğin:

• Gömme Modelleri: OpenAI vs Gemini vs Cohere
• Qdrant vs Weaviate vs Pinecone: RAG için En İyi Vektör Veritabanı
• Hibrit RAG: RAG Doğruluğunu Artırma
• Ajan RAG kıyaslama testi: çoklu veritabanı yönlendirme ve sorgu üretimi
• RAG için En İyi 10 Çok Dilli Gömme Modeli

Değişiklik Günlüğü

20 Nisan 2026

Kıyaslama testine 1 yeni model eklendi:

• Anthropic: Claude Opus 4.7 (anthropic/claude-opus-4.7)

20 Şubat 2026

Kıyaslama testine 2 yeni model eklendi:

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

10 Şubat 2026

Kıyaslama testine 2 yeni model eklendi:

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

SSS'ler

Bu benchmarkı kaynak gösterin

Yayınlayacağınız yere uygun formatı seçin. Bağlantılı sürümü CMS'inize yapıştırmak, geri bağlantıyı korur.

@misc{dilmegani2026,
  author = {Dilmegani, Cem and Sarı, Ekrem},
  title  = {{Metinden SQL'e: LLM Doğruluk Karşılaştırması}},
  year   = {2026},
  month  = jun,
  howpublished    = {\url{https://aimultiple.com/text-to-sql}},
  note   = {AIMultiple. Erişim tarihi: 30 Haziran 2026}
}

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. Yorumlar orijinal dilinde bırakılır.

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