Yapay zekaya iyi SQL yazdırmak: Text-to-SQL teknikleri

 (cloud.google.com)
4 puan yazan GN⁺ 2025-05-17 | 1 yorum | WhatsApp'ta paylaş
  • Gemini tabanlı Text-to-SQL özelliği, Google Cloud genelinde geliştiricilerin ve teknik olmayan kullanıcıların üretkenliğini artırmak için kullanılıyor
  • Gerçek ortamlarda iş bağlamı eksikliği, kullanıcı niyetini yorumlama zorluğu ve SQL lehçeleri arasındaki farklar nedeniyle doğru SQL üretmek zorlaşıyor
  • Google, bunu çözmek için akıllı veri arama, bağlama dayalı öğrenme ve anlamsal katmanlama gibi teknikleri devreye alıyor
  • Modelin kendi sınırlamaları, çoklu üretim sonrası en iyi seçimi yapma (self-consistency), doğrulama sonrası yeniden prompt verme ve SQL lehçesine özel eğitim gibi yöntemlerle aşılıyor
  • Değerlendirme ve iyileştirme ölçümü, kuruma özel benchmark'lar ve hakem olarak LLM kullanımını içeren tekniklerle gerçek ortama uygulanabilirliği artırıyor

Techniques for improving text-to-SQL

Metinden SQL'e dönüşüm: Google Cloud'un mevcut durumu

  • Kuruluşlar, hızlı ve doğru veri içgörüleri için SQL kullanıyor
  • Gemini, doğal dilden doğrudan SQL üreten text-to-SQL özelliği sunuyor
  • Bu özellik yalnızca geliştiriciler için değil, teknik olmayan kullanıcılar için de faydalı
  • Özellik şu anda BigQuery Studio, Cloud SQL Studio, AlloyDB Studio, Vertex AI ve diğer hizmetlerde sunuluyor

Text-to-SQL teknolojisinin başlıca zorlukları

1. İş bağlamını sağlama zorluğu

  • Doğru SQL yazmak için LLM'e veritabanı yapısı, sütun anlamları ve gerçek veri içeriği gibi yeterli bağlamın sağlanması gerekir
  • Bağlam, hem açık bilgilerden (şema, sütun bilgileri vb.) hem de örtük bilgilerden (belirli verilerin iş açısından anlamı vb.) oluşur
  • Veritabanı yapısındaki veya veri setlerindeki değişikliklere, şemadaki dönüşümlere uyum sağlamak için LLM'i sürekli eğitmek (fine-tuning) pratikte yüksek maliyetlidir
  • İş bilgisi ya da anlamsal bilginin düzgün biçimde düzenlenmemiş olması ve bunu eğitim verisine dönüştürmenin zor olması da ayrı bir sorundur
  • Örnek: Bir DBA, pcat_extension tablosundaki cat_id2 = 'Footwear' ifadesinin anlamını bilmiyorsa ayakkabı satışlarını sorgulayan SQL'i de yazamaz — LLM de aynı şekilde bağlam yetersiz olduğunda hatalı sorgu üretme riski taşır

2. Kullanıcı niyetini yorumlama sorunu

  • Doğal dil sorgularında, SQL'e kıyasla netlik eksikliği sık görülür
  • Gerçek veri analistleri veya mühendisler, soru belirsizse ek sorular sorarak netleştirebilir; ancak LLM'ler kendilerine verilen soruya doğrudan yanıt üretmeye eğilimli olduğundan yanlış bilgi üretme (hallucination) riski taşır
  • “En çok satılan ayakkabı hangisi?” gibi bir soruda, “en çok satılan” ifadesinin ölçütü (sipariş sayısı mı, ciro mu) ya da sonuç sayısı gibi ayrıntılar belirsizdir
  • Teknik yetkinliği olan kullanıcılar yaklaşık bir SQL'i başlangıç noktası olarak kullanabilir, ancak uzman olmayanlar için tam olarak çalışan SQL çok daha önemlidir
  • Etkili çalışabilmesi için LLM'in takip soruları, çıkarım açıklaması ve kullanıcı yönlendirmesi gibi işlevleri desteklemesi gerekir; ancak bu şekilde kullanıcının niyeti net olarak anlaşılabilir

3. LLM'lerin üretim sınırları

  • LLM'ler belge özetleme ve bilgi çıkarımı gibi alanlarda güçlü olsa da, doğru SQL sözdizimi ya da daha az kullanılan SQL özellikleri söz konusu olduğunda zayıflıkları vardır
  • SQL lehçeleri arasında sözdizimi farkları bulunur ve küçük farklar bile yüksek doğruluk gerektirir
  • Örnek: BigQuery'de EXTRACT(MONTH FROM timestamp_column) kullanılırken, MySQL'de MONTH(timestamp_column) yazılmalıdır
  • Karmaşık gereksinimlere sürekli uyacak şekilde SQL üretmek, LLM'ler için kolay bir görev değildir

Google Cloud'un Text-to-SQL iyileştirme teknikleri

Sorun: Şema ve iş bağlamı

  • Anlamsal tabanlı arama ve sıralama
  • Bağlam içinde öğrenme
  • Veri örnekleme ve ilişkilendirme
  • Anlamsal katman oluşturma
  • Kullanım kalıpları ve geçmiş analizi

Sorun: Kullanıcı niyetini yorumlama

  • LLM ile netleştirme
  • Varlık tanımlama, ilgili bilgileri kontrol etme ve uygun takip sorularını yönlendirme

Sorun: LLM sınırlarını aşma

  • Self-consistency ile birden çok sorgu üretip en iyisini seçme
  • Geçerlilik doğrulama ve yeniden prompt verme
  • SQL lehçesi örneklerini içeren bağlam içi öğrenme
  • Model fine-tuning'i

Başlıca teknik uygulama örnekleri

SQL-aware modeller

  • Gemini, yüksek kaliteli SQL üretimi için fine-tuning uygulanmış çeşitli sürümler kullanıyor
  • SQL lehçesi bazında doğruluğu sağlamak için model sürümü karışımları ve özelleştirilmiş ayarlamalar yapılıyor

Kullanıcı sorusunu netleştirme (Disambiguation)

  • Soru belirsiz olduğunda netleştirici sorular üretiliyor
  • Örnek: "En çok satan ayakkabı?" → “Sipariş sayısına göre mi, ciroya göre mi?” şeklinde yönlendirme

Anlamsal arama ve bağlam kurma

  • Çok aşamalı anlamsal eşleştirmeye dayalı vektör arama ile ilgili tablolar ve sütunlar belirleniyor
  • Prompt; kullanıcı sorgu geçmişi, iş kuralı örnekleri vb. unsurları içerecek şekilde oluşturuluyor
  • Uzun bağlam penceresi desteği sayesinde büyük ölçekli şemalar ele alınabiliyor

Doğrulama ve yeniden üretim

  • LLM'in ürettiği sorgularda parsing, dry-run gibi yöntemlerle açık hatalar tespit ediliyor
  • Hata algılanırsa yeniden prompt verilerek düzeltme teşvik ediliyor

Self-consistency

  • Tek bir sorgu yerine farklı yaklaşımlarla birden fazla sorgu üretiliyor
  • Birden fazla model aynı sorguyu önerdiğinde doğruluk artıyor

Değerlendirme ve performans ölçümü

  • Mevcut benchmark'lar (BIRD-bench vb.) faydalı olsa da gerçek şemaları yansıtma konusunda sınırlara sahip
  • Google, kendine ait sentetik benchmark setleri oluşturuyor

Değerlendirme stratejisi

  • SQL lehçelerini ve motor bazlı işlevleri kapsama: sorguların yanı sıra DDL, DML ve yönetim görevleri de dahil
  • Değerlendirme metrikleri: kullanıcı tepkileri, offline metrikler, LLM-as-a-judge
  • Sürekli değerlendirme: yeni modellerin ve prompt tekniklerinin etkinliği hızla doğrulanabiliyor

Sonuç

İlgili okumalar

1 yorum

 
GN⁺ 2025-05-17
Hacker News görüşü

  • Metinden SQL'e dönüşümün nihai hedefi üzerine düşünceler var: amaç bir veri analisti yardımcısı yapmak mı, yoksa analist olmadan iş içgörüsü elde etmek mi? Eğer ikincisiyse, sistem ne kadar gelişmiş olursa olsun uzman olmayan birinin SQL'in doğruluğunu ve yeterliliğini değerlendirmesi imkansız bir sorun. "Dün e-ticaret işlemleri neden %80 seviyesinde kaldı?", "Müşteri edinme maliyeti neden yükseliyor?", "New York kampanyası neden San Francisco'ya kıyasla daha kötü performans gösterdi?" gibi sorular text2sql kapsamının dışında.

    • Pratikte amacın daha çok ikinci hedefe yakın olduğunu düşünüyorum ama ortaya çıkan sonuç beklentinin altında kalıyor. İş dünyasında insanlar raporları son anda değiştirmek istiyor, ancak analist eksikliği yüzünden istedikleri bilgiyi zamanında alamıyorlar. Bunu "sonsuz hız" ile çözmeye çalışıyorlar, ama gerçekte sorun metrikler üzerine yeterince düşünülmemesinden kaynaklanıyor. Veri karmaşık, iş bilgisi örtük biçimde dışarıda saklı ve veri altyapısı yetersiz olduğu için analiz uzun sürüyor. Zeki analiz liderleri de yapay zeka dalgasını kullanıp temel altyapıya yatırım yapıyor.

    • Bence yukarıdaki sorular zaten baştan SQL ile çözülebilecek problemler değil. SQL esas olarak "ne" sorusuna yanıt verir, "neden" sorusuna değil. Text2SQL'in hedefi, analistin "ne" kısmını hızlıca halletmesi için harcadığı zamanı azaltmak ve böylece "neden" sorusuna odaklanmasına yardımcı olmaktır.

    • Doğru, ama bence doğal dil metni LLM sistemleri için evrensel girdi olabilir. Text2sql, daha karmaşık soruların yanıtını oluşturan bilgi erişiminin temeli olabilir. Kısa vadede iş destek işlevi, uzun vadede ise otomasyon, sonuç karşılaştırması ve daha büyük iş akışlarına entegrasyon için temel atmak hedef. Esas mesele, bu tür soruları yanıtlayacak zemini kurmak. Hâlâ yapılacak çok iş var.

    • Bir insan yapabiliyorsa, herhangi bir algoritma da inşa edilip test edilebilir. Elinizde 10 analist varsa, veritabanı ve iş bilgisini anlama düzeyleriyle becerileri birbirinden farklıdır. Otomasyon, en azından asgari beceri ve bilgi sağlayan bir standart sunar. Yeni analistler bile hemen daha iyi sonuç üretir. Sistemi uzmanlarla birlikte geliştirip test etmek ve yapay zekanın ödünleşimler, hatalar ve beklenen sonuçlarla karşılaştırmalar üzerinden yorum yapmasını sağlamak faydalı bir hedeftir. İçgörü ya da "zevk" otomatikleştirmesi zordur, ama alan uzmanı iyi tasarlanmış otomasyon ve makul sonuçlara dair sezgiyle çok ileri gidebilir. Kusursuz değil, ama benim hedefim bu.

  • OpenAI 4o modelini kullanma deneyimi paylaşılıyor: iş yönergeleri, sektör terminolojisi, tablo ve yabancı anahtar açıklamaları birlikte prompt'a veriliyor. Sonra karmaşık join sorguları üretip sonuç döndürüyor. Amaç SQL bilmeyen kullanıcılara sonuç sunmakmış, ancak referans olsun diye SQL'in kendisi de birlikte gösteriliyor.

  • Yapay zekanın kusursuz SQL üretmesi gerekmiyor. Benim durumumda çıktı kodla doğrulanabilir olsa bile, ince anlamsal fark riski yüzünden kopyalayıp kullanmıyorum. Bunun yerine yapay zeka bir yaklaşım önerirse ondan yararlanıp SQL'i baştan kendim yazıyorum.

  • Google AI Studio'daki en yeni Gemini'yi kullanma deneyimi: gerçekten şaşırtıcı derecede etkileyici ve çığır açıcı. Claude ve ChatGPT'nin kodlama çıktıları sanki başka bir yüzyıldan gelmiş gibi hissettiriyor. Sadece bir ay önce Claude'un harika olduğunu düşünüyordum, şimdi ise Google Gemini olmadan kodlamaya nasıl devam edebileceğimi bilmiyorum. Gemini AI Studio programlamada devasa bir sıçrama.

    • Daha fazla insanın bu değişimi henüz fark etmemiş olmasına şaşırıyorum. Claude küçük işleri iyi hallediyor, ama iş karmaşık problemlere gelince Gemini açık ara önde. Özellikle bağlam işleme yeteneği çok etkileyici. Onu sadece bir kodlama ajanı olarak değil, 85.000 kelimelik bir taslağın beta okuması için de kullanıyorum ve neredeyse gerçek zamanlı olarak uzman düzeyinde geri bildirim raporu alıyorum.

    • Bu hafta ücretsiz Gemini Pro'da akıl yürütme modunun devre dışı bırakılmış olabileceği hissine kapıldım. Kod yazmadan hemen önce durdurur ya da aşırı genelleştirmesini engellersen oldukça faydalı olabiliyor. Yine de Gemini'nin fazla kod yazma eğilimi var. Benim asıl kullanım şeklim, kod uygulamasına takılıp kalmadan Gemini'yi tasarımsal keşif için kullanmak. Örneğin Stripe ile abonelik hizmeti kurma senaryosunda, kendi teknoloji yığınıma ve kullanım örneklerime uygun mevcut verileri bağlama uygun şekilde görüp tek satır kod yazmadan önce bile tasarım yönünü değiştirebildim.

  • Cevap "semantic layer kullanmak". Doğru bağlamı aktarmanın en etkili yolu bu ve insan müdahalesi için de en uygun nokta. İnsan tüm temel metrikleri açıkça tanımlarsa LLM bunu her zaman kullanabilir. Örneğin MAU tanımlanırsa LLM sorguyu o tanıma göre üretir. SQL yerine JSON ile sorgu yazarsanız LLM çok daha tutarlı sonuç veriyor. Biz cube kullanıyoruz; en iyi açık kaynak semantic layer o. Tescilli seçenekler de var. Geçmişte çalıştığım şirket bununla ilgili bir blog da yazmıştı ama şimdi sahibi olan şirket barındırmayı durdurdu.

    • "Sorguları SQL yerine JSON ile yazabilmek" bir avantajdır iddiasına katılmak zor, bunu kesinlikle kabul edemiyorum.

  • Gerçek işte yapay zekayla SQL üretmek riskli. SQL bilmeyen biri yanlış sorgu yazıp sunucu üzerinde ciddi etki yaratabilir. Bizim ekipte veritabanı çoğu geliştiriciye göre büyük ama gerçekten devasa değil. Bazen optimize edilmiş sorguyu daha da iyileştirmesini diye yapay zekaya soruyorum ama daha iyi bir yanıt verdiği hiç olmadı. Bazen saçmalıyor ya da pratikte işe yaramayan önerilerde bulunuyor. Daha önce duyduğu şeyleri tekrarlayan aptal bir papağan gibi.

    • Benim deneyimime göre programlamayı iyi bilmeyen insanlar, yapay zeka olmasa da bir şeyi dener, işler bozulunca suçu başkasına atar. Yapay zeka sadece bu tür kazaların sıklığını artıracak.

  • Yapay zekanın metinden düzenli ifadeye dönüştürme özelliği olsa gerçekten çok kullanışlı olurdu diye düşünüyorum.

    • Bu görüşü sık görüyorum ve açıkçası şaşırıyorum. İnsanlar gerçekten regex bilmiyor mu diye merak ediyorum. Regex son derece yaygın kullanılıyor, çok fazla öğrenme kaynağı var ve giriş eşiği düşük. Kullanım alanlarının %90'ı çok basit; sonuçta bunu yapay zekaya anlatmaktansa kendin yazmak daha hızlı.

  • Şimdiye kadar kullandığım tüm yapay zeka araçları içinde en hayal kırıklığı yaratanı BigQuery'ye gömülü Gemini oldu. Sütun adları da açıktı, açıklamalar da iyiydi, ama problemi çözmeye hiç yaklaşamadı.

    • Şu ana kadar en çok sorgu yazdığım dil SQL. Yapay zekadan sorgu yazmasını istesem bile, sonucu toparlamak benim doğrudan yazmamdan çok daha fazla zaman alıyor. Yan not olarak, SQL'i çok daha hızlı yazdıracak tek bir özellik isterdim: şirketimizdeki DSL'de yabancı anahtarlara göre otomatik join yapan bir operatör var ve inanılmaz kullanışlı. SQL yazarken en sinir bozucu kısım 10, 20'den fazla join ifadesini tek tek yazmak. Onun dışındaki kısımlar buna kıyasla o kadar zor değil.

    • Deneyimime göre net kısıtlar ve doğru tanımlanmış yabancı anahtarlar varsa neredeyse her şey çözülüyor. Her tabloda açık kısıtlar olmalı ki yapay zeka tüm bağlantı yapısını doğru anlayabilsin. SQL çok kesin bir belirtime sahip, ama kısıtlar ve yabancı anahtarlar iyi tanımlı değilse yapay zeka doğru yanıtı veremiyor.

  • Tüm foundation model'lerde bu artık epey basitleşti. Tablo şemasına düzgün yorumlar eklenmişse sorgu üretmesini istemek kolay.

    • smolagents kütüphanesiyle modelin etrafına scaffolding kurarsanız oldukça kullanışlı oluyor. Text2sql demoda basit görünebilir ama bunu karmaşık gerçek vakalara uygulamanın çok zor olduğunu anlatan yazılar da var.

    • Step 1: Şemada binlerce tablo var ve neredeyse hiç açıklama yok. Step 2...

    • Bence de gerçekten böyle. Artık burada pek sihir kalmadı. Tablo oluşturma DDL'i zaten tablonun oldukça doğru bir açıklaması; aslında çoğu zaman daha fazlasına gerek yok. Sadece ihtiyaç duyulan sorguyu ayrıntılı anlatırsanız çoğu LLM sorguyu kolayca üretiyor.

  • "Show HN: We open sourced our entire text-to-SQL product" (2024) yazısında anılan kaynaklar arasında awesome-Text2SQL ve Awesome-code-llm > Benchmarks > Text to SQL gibi harika referanslar var.