Text-to-SQL: LLM Doğruluk Karşılaştırması

Veri analizi için SQL'e 18 yıldır güveniyorum, danışmanlık günlerimden beri. Doğal dildeki soruları SQL'e çevirmek, verileri daha erişilebilir kılar ve teknik becerisi olmayanlar da dahil herkesin doğrudan veritabanlarıyla çalışmasına olanak tanır.

Text-to-SQL kıyaslama metodolojimizi 35'ten fazla büyük dil modeli (LLM'ler) üzerinde, SQL komutu oluşturma performanslarını değerlendirmek için kullandık:

LLM tarafından üretilen SQL'de yaygın hatalar

LLM'ler sıklıkla dört tür hata yapar: hatalı join'ler, toplama hataları, eksik filtreler ve sözdizimi hataları.

Yanlış join mantığı

Modeller, tablolar arasında gerekli `JOIN` işlemlerini doğru bir şekilde belirlemekte ve uygulamakta sıklıkla zorlandı, bazen bunları tamamen atladı veya daha az optimal alt sorguları yanlış kullandı.

LLM, `frpm` ve `schools` tablolarını `CDSCode` kullanarak doğru bir şekilde birleştiremedi. Ayrıca halüsinasyon gördü sütun adları (`Charter`) ve filtre değerleri (`County = ‘Fresno’`) ile ilgili.

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

Toplama ve gruplandırma hataları

Toplama işlevlerini (`MAX`, `AVG`, `COUNT`, `SUM`) veya `GROUP BY` ifadelerini yanlış kullanmak, kullanıcının amacına anlamsal olarak uymayan sonuçlara yol açan bir diğer yaygın başarısızlık noktasıydı.

LLM, “en yüksek ortalama puan” ifadesinin verileri ilçeye göre gruplandırmayı (GROUP BY dname) ve bir toplama işlevi (AVG(AvgScrRead)) kullanmayı gerektirdiğini doğru bir şekilde belirledi. Bu mantık kısmı doğru.

Ancak, LLM sorudan kritik bir filtreyi dahil etmeyi başaramadı: “active” kelimesi. Bu gereksinimi karşılamak için, sorgunun `satscores` tablosunu `schools` tablosuyla JOIN yapması ve ardından sonuçları `WHERE T1.StatusType = ‘Active’` ifadesiyle filtrelemesi gerekiyordu.

Bu, yaygın bir LLM başarısızlığını vurgulamaktadır: Birincil, açık bir talimatı doğru bir şekilde yürütürken (ortalama hesaplama), ikincil ama eşit derecede önemli bir koşulu (duruma göre filtreleme) kaçırmak. Bu, birden çok kısıtı tek ve doğru bir sorguda sentezlemede bir zayıflığı gösterir.

Eksik veya yanlış filtreler

Modeller bazen gerekli `WHERE` ifadelerini eklemekte veya `SELECT` deyiminde yanlış sütunları seçmekte başarısız oldular, kısıtlamaları veya istemde açıkça istenen bilgileri tam olarak ele almadılar.

LLM okulu bulma mantığını doğru bir şekilde belirledi (`ORDER BY NumGE1500 DESC LIMIT 1`), ancak istenen `Phone` numarasını seçmeyi ve onu almak için gerekli `schools` tablosuna join'i atladı.

Bu hatalar genellikle kullanıcının isteğinin eksik ayrıştırılmasından veya isteğin tüm bölümlerinin nihai SQL sorgu bileşenlerine eşlenememesinden kaynaklanır.

Sözdizimi hataları

Anlamsal hataların ötesinde, yanlış tablo takma adları kullanma veya eksik SQL ifadeleri üretme gibi düpedüz sözdizimi hataları meydana geldi ve bu, sorgunun yürütülmesini engeller.

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

Bu sözdizimi sorunları, SQL dil bilgisine ve veritabanına özgü kurallara sıkı sıkıya bağlı kod üretmedeki zorlukları vurgulamaktadır.

Bazı LLM'ler SQL'de neden daha iyidir?

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

1. Model boyutu ve eğitim verisi

• Boyut ve tasarım: Daha büyük modeller veya belirli yapılarla oluşturulmuş olanlar, SQL oluşturma gibi karmaşık görevleri daha etkili bir şekilde ele alabilir.
• Öğrendikleri: LLM'yi eğitmek için kullanılan veriler önemlidir. Soruların SQL yanıtlarıyla eşleştirildiği birçok örnek görürse, özellikle join'ler veya hesaplamalar (SUM, AVG) gibi karmaşık işlemleri içerenler, muhtemelen daha iyi performans gösterir.

2. SQL görevleri için ince ayar

• Modellere, özellikle text-to-SQL görevlerine odaklanan ekstra eğitim verilebilir. Bu “ince ayar”, genel metinler üzerinde eğitilmiş modellere göre veritabanı yapılarını ve SQL kurallarını daha etkili bir şekilde anlamalarına yardımcı olur. Belirli talimatlar üzerinde eğitim de yardımcı olur.

3. Muhakeme ve şema eşleme yetenekleri

• Muhakeme: LLM, bazen belirsiz bir sorudan gereken tam adımları ne kadar iyi çözebilir? 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), adlar hemen belli olmasa bile veritabanındaki gerçek tablo ve sütun adlarına bağlamada daha iyidir.

LLM'ler SQL'i Nasıl Üretir: Adım Adım Bir Bakış

“Muhakeme” ve “şema eşleme” gibi faktörleri eylem halinde 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ı, Retrieval-Augmented Generation (RAG) adı verilen bir teknikle desteklenmektedir.

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

Bir soru ile karşılaştığında, LLM önce en uygun veritabanı aracını seçmek için kullanıcının amacını analiz eder.

• Soru: “How many accounts have an owner disposition and request for a statement to be generated upon a transaction?”
• LLM'nin Eylemi: Model, “accounts”, “disposition” ve “transaction” gibi anahtar kelimeleri tanımlar. Diğer seçenekler olan california_schools veya superhero yerine financial veritabanı aracının doğru seçim olduğu sonucuna varır.

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

Model bir araç seçtikten sonra, veritabanının “haritasına”, yani şemaya ihtiyaç duyar. Bu bilgileri ezberlemiş değildir. 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ını aramak için kullanılır. Arama, en alakalı şema ayrıntılarını, örneğin accounts ve disp tablolarının tanımlarını bulur ve alır.
2. Zenginleştirme: Bu alınan şema metni, orijinal sorunun yanı sıra isteme otomatik olarak eklenir.
3. Üretim: LLM artık devam etmek için ihtiyaç duyduğu tüm bağlama sahiptir.

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

Aşama 3: Muhakeme ve sorgu oluşturma

Soru ve RAG tarafından sağlanan şema ile model, kullanıcının isteğindeki kavramları, az önce aldığı belirli tablo ve sütun adlarına eşler.

LLM'nin iç monoloğu:

1. Hedef: Kullanıcı bir sayım istiyor, bu yüzden SELECT COUNT(...) ile başlayacağım.
2. Koşullar:
   • “…owner disposition…” -> disp tablo şemasında bir type sütunu var. type = 'OWNER' için bir WHERE ifadesine ihtiyacım var.
   • “…statement to be generated upon a transaction…” -> accounts tablo şemasında bir frequency sütunu var. Filtre frequency = 'POPLATEK PO OBRATU' olmalı.
3. JOIN'ler: Bilgiler accounts ve disp tabloları arasında bölünmüş durumda. Şema, bunların account_id ile bağlantılı olduğunu gösteriyor, bu yüzden onları JOIN yapmam gerekiyor.

Aşama 4: Nihai SQL'i oluşturma

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

1. Muhakeme yeteneği: Modelin kullanıcının isteğini sağlanan şemaya mantıksal olarak bağlama becerisi.
2. Eğitimden gelen SQL bilgisi: Modelin SQL sözdizimi ve işlevleri hakkındaki temel anlayışı.

Bu süreç, hataların neden oluştuğunu açıklar. Alınan şema belirsizse veya sorudaki bir terim tam olarak eşlenmezse, LLM eğitimli bir tahmin yapmak zorunda kalır ve bu da daha önce incelediğimiz hatalara yol açabilir.

Text-to-SQL nedir?

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ı, manuel olarak SQL kodu yazmak yerine doğal dilde bir soru sorar ve sistem, bir veritabanında yürütülebilecek bir SQL ifadesi oluşturur.

Text-to-SQL'in temel amacı, insanların veri hakkında düşünme biçimi ile veritabanlarının sorguların yazılmasını gerektirme biçimi arasındaki boşluğu azaltmaktır. Bu, özellikle iş bağlamını anlayan ancak sıfırdan SQL sözdizimi yazma konusunda rahat olmayan teknik olmayan kullanıcılar ve veri analistleri için geçerlidir.

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

• “Geçen ay alışveriş yapan New York'taki 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 çevirir. Çıktının kalitesi, sistemin hem kullanıcı amacını hem de veritabanı şemasını yansıtan doğru sorgular oluşturup oluşturamayacağına bağlıdır.

Text-to-SQL bugün nerede faydalıdır?

Text-to-SQL aşağıdakiler için makul derecede iyi çalışır:

• Veri analistlerinin gözden geçirip düzeltebileceği taslak sorgular oluşturma.
• Hassasiyetten çok hızın önemli olduğu keşifsel veri analizini destekleme.
• Teknik olmayan kullanıcıların önceden tanımlanmış şemalar aracılığıyla basit verilere erişmesine izin verme.
• SQL kullanıcılarına, tekrarlayan sorgular yazma ihtiyacını azaltarak yardımcı olma.

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

Text-to-SQL nasıl çalışır?

Modern text-to-SQL 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. Süreç genellikle bir dizi adımı takip eder:

Doğal dil anlama

Sistem önce kullanıcı girdisini, amacı, kısıtlamaları ve varlıkları belirlemek için analiz eder. Bu adım şunları içerir:

• Kullanıcının ne istediğini belirleme (örneğin, toplamlar, filtreler, karşılaştırmalar)
• Zaman aralıkları, konumlar veya kategoriler gibi ilgili koşulları çıkarma
• İş bağlamı gerektirebilecek belirsiz ifadeleri yorumlama

Bu aşamadaki hatalar genellikle doğru 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ütunlarla eşleştirme
• Tablolar arasındaki ilişkileri anlama
• Tarihler, sayısal alanlar veya kategoriler gibi veri türlerine uyma

Tablo sayısı arttıkça veya sütun adları, kullanıcıların doğal dil sorularında verileri nasıl tanımladığıyla tam olarak eşleşmediğinde ş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çme
• Gereken tüm tablolara join'ler ekleme
• Filtreler, toplamalar ve gruplandırma mantığını uygulama
• MySQL veya PostgreSQL gibi sistemler için sözdizimsel olarak geçerli SQL kodu üretme

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

Doğrulama ve yürütme

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

Ancak, doğrulama nadiren doğru bir yanıtı garanti eder. Bir sorgu başarıyla yürütülebilir ve yine de ince şekillerde 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 çeşitli sınırlamaları ortaya çıkarmaktadır.

Güvenilirlik ve doğruluk

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

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

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

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

Mevcut performans göz önüne alındığında, oluşturulan SQL'in SQL'i ve veritabanını anlayan biri tarafından gözden geçirilmesi gerekir. Bu gözetim olmadan:

• Kullanıcılar, başarıyla yürütüldüğü için yanlış bir sorguya güvenebilir
• Hatalar panolara, raporlara veya alt sistemlere yayılabilir
• Kararlar yapay zeka tarafından oluşturulan çıktılara dayandığında hesap verebilirlik belirsizleşir

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

Karmaşıklık tavanı

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

• Birçok tablo arasında birden çok join
• İç içe mantık ve alt sorgular
• Alanda özel hesaplamalar
• Veritabanı şemasının derinlemesine bilgisini gerektiren sorgular

BIRD-SQL gibi kıyaslamalar, karmaşık sorguların gelişmiş modeller için bile birincil başarısızlık noktası olmaya devam ettiğini vurgulamaktadır.

Model değişkenliği

Modeller arasındaki performans farklılıkları önemlidir. Bazı dil modelleri makul derecede iyi performans gösterirken, diğerleri aynı veri kümesinde sıklıkla başarısız olur. Bu şu anlama gelir:

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

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

Veri yönetişimi ve gizlilik

Text-to-SQL sistemleri ek erişim riskleri getirir:

• Kullanıcılar, sonuçlarını anlamadan hassas tabloları sorgulayabilir
• Oluşturulan SQL, veritabanı şeması hakkındaki meta verileri açığa çıkarabilir
• Veri gizliliği kontrolleri dil modelinin dışında uygulanmalıdır

Güçlü erişim kontrolleri olmadan, text-to-SQL mevcut yönetişim 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

Text-to-SQL için kıyaslama metodolojisi

Bu kıyaslama, veri kümesi yapısını, ajan mimarisini, anlamsal belirsizlik zorluğunu ve tam puanlama cetvelini ayrıntılı olarak açıklayan ajan tabanlı RAG kıyaslamamızla değerlendirme çerçevesini paylaşmaktadır.

Her iki kıyaslama da aynı 500 soruluk BIRD-SQL¹ alt kümesini, ajan tabanlı işlem hattını, ChromaDB destekli şema alımını ve Claude 4 Sonnet ile LLM-as-Judge değerlendirmesini kullanır. Burada bildirilen metrik, doğru SQL komutu oluşturma oranı, modelin hem doğru veritabanına yönlendirildiğ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 alana özgü ipucu olmadan aynı sıfır atış koşulları altında değerlendirildi.

İleri okuma

Diğer RAG kıyaslamalarını keşfedin, örneğin:

• 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
• Ajansal RAG kıyaslaması: çoklu veritabanı yönlendirme ve sorgu oluşturma
• RAG için en iyi 10 çok dilli gömme modeli

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  = {{Text-to-SQL: LLM Doğruluk Karşılaştırması}},
  year   = {2026},
  month  = jul,
  howpublished    = {\url{https://aimultiple.com/text-to-sql}},
  note   = {AIMultiple. Erişim tarihi: 17 Temmuz 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