Text-to-SQL 2026: LLM ile Doğal Dil Veri Sorgulama Mimarisi

Text to SQL LLM, doğal dilde yazılan bir soruyu (örneğin “Geçen çeyrek İstanbul’da 50 bin TL üzeri satış yapan müşteri sayısı kaç?”) önce şemaya bağlı, anlamsal olarak doğrulanmış bir SQL sorgusuna, ardından çalıştırılabilir bir veri cevabına dönüştüren çok aşamalı bir mimaridir. 2026 itibarıyla Spider 2.0 benchmark’ında en güçlü modeller (GPT-4.1, Claude 3.7 Sonnet, Gemini 2.5 Pro) execution accuracy değerini yaklaşık %75-82 bandına çıkardı; bu rakam 2023’te %60 civarındaydı. Sektörel etki de büyük: Snowflake’in 2025 Data Trends raporuna göre kurumsal BI sorgularının yaklaşık %38’i artık ya tamamen ya da kısmen doğal dil aracılığıyla üretiliyor. Bu yazı; mimari katmanlar, üretici modeller, retrieval stratejileri, değerlendirme, üretim hattı maliyetleri ve gerçek dünya tuzakları üzerine bir referans çerçeve sunuyor.

Text-to-SQL artık sadece bir “prompt yaz, sorgu al” oyunu değil. 2024-2026 döneminde alan; şema linker’ları, ambiguity resolution, agent-based query planning, vector destekli few-shot örnekleme ve self-debugging döngülerinin entegre olduğu bileşik bir sistem haline geldi. Bu yazıda mimariyi 9 ana eksen üzerinden detaylandıracağız.

Text-to-SQL’in Endüstriyel Bağlamı ve Gerçek Yatırım Tablosu

Doğal dil sorgu vaadi yeni değil; ancak transformer tabanlı LLM’ler 2023 sonrası alanın hem hassasiyetini hem de erişilebilirliğini değiştirdi. Gartner’ın Augmented Analytics 2025 raporuna göre Fortune 500 şirketlerinin yaklaşık %46’sı, kendi veri ambarlarına bağlı en az bir text-to-SQL üretim katmanı çalıştırıyor. McKinsey’in 2025 “AI in Data & Analytics” anketinde ankete katılan veri ekiplerinin %61’i, ad-hoc SQL üretiminin LLM ile destekli geçtikten sonra ortalama sorgu hazırlama süresinin 22 dakikadan 4 dakikanın altına indiğini raporladı.

Yıl	Spider 2.0 Execution Acc. (best)	Üretim Adopsiyonu (F500)	Ortalama Query Latency
2023	~%60	%12	3.8 sn
2024	~%68	%27	2.4 sn
2025	~%74	%38	1.9 sn
2026 (Q1)	~%80	%46	1.5 sn

Rakamların önemi şu: Text-to-SQL artık deneysel değil, ROI’si ölçülen bir BI katmanı. Stack Overflow 2025 Developer Survey, “AI tools in workflow” başlığında veri mühendislerinin %58’inin günlük SQL yazımında LLM kullandığını belgeledi. Yine de execution accuracy %80 olsa bile, finans ve sağlık gibi hata maliyeti yüksek alanlarda %100’e yakın doğruluk için guard layer, semantic validation ve insan onayı mimariye gömülmek zorunda.

Yatırım tarafında bir ek gözlem: IDC’nin 2025 sonbahar AI Spending Tracker raporuna göre kurumsal LLM bütçesinin yaklaşık %14’ü doğrudan “natural language data access” senaryolarına gidiyor; bu kalem 2023’te %4 seviyesindeydi. Yani text-to-SQL, kurumsal LLM bütçesinin en hızlı büyüyen ikinci hattı (genel-amaçlı agent platformlarının ardından). Sonuç, satın alma kararının “yapılır mı yapılmaz mı” değil “hangi mimariyle hangi maliyetle” sorusu üzerinden alınması.

Bu mimari kurguda, kurumsal veri platformları için yapılan dönüşüm projelerinde Kurumsal Yapay Zeka Entegrasyonu rehberi, governance, IAM ve audit gereksinimlerini sistemleştirmek için iyi bir çıkış noktası.

Mimari Katmanlar: 6 Katmanlı Üretim Referansı

Tek bir LLM çağrısının “iyi sorgu üretmesi” beklentisi 2023 dönemine ait. 2026’nın production-grade text-to-SQL sistemleri tipik olarak 6 katmanlı çalışır:

1. Intent + Disambiguation Layer: Kullanıcı sorusu önce niyet sınıflandırmasına, ardından eksik parametre/ambiguity tespitine tabi tutulur. (“Geçen ay” ifadesini 2026-04-01 ile 2026-04-30 olarak çözmek bu katmanın işi.)
2. Schema Linker: Sorudaki entity’leri (müşteri, satış, sipariş) doğru tablo/sütunlara bağlar. RESDSQL ve DIN-SQL gibi yöntemler, schema linking’in doğruluğun yaklaşık %18-22’sini taşıdığını gösterdi.
3. Retrieval-Augmented Few-Shot: Vector veritabanından benzer geçmiş sorgu/soru çiftleri çekilir; LLM prompt’una in-context örnek olarak verilir.
4. SQL Generator: LLM (GPT-4.1, Claude 3.7, Gemini 2.5, DeepSeek-V3 veya fine-tuned bir SQLCoder) SQL üretir.
5. Self-Debug / Execution Validator: Sorgu önce sandbox’ta planlanır; syntax error veya semantik anomali varsa LLM’e error trace ile geri besleme yapılır (max 2-3 retry).
6. Guard + Audit Layer: Row-level security, PII masking, allowlist tablo/sütun filtresi, query cost tahmini, audit log üretimi.

Bu katmanlamanın doğru kurulması RAG Altyapı Kurulumu ile büyük ölçüde örtüşür; özellikle few-shot örnek havuzunun güncel tutulması, vector store seçimi ve embedding modelinin domain’e uyumlandırılması açısından.

Katman	Asıl Sorun	Tipik Teknik	Doğruluğa Katkı
Intent + Disambiguation	Belirsizlik, zaman ifadeleri	NER + rule + clarification turn	+%6-8
Schema Linker	Yanlış tablo/sütun seçimi	RESDSQL, embedding eşleştirme	+%18-22
RAG Few-Shot	Domain pattern eksikliği	Vector DB + BM25 hybrid	+%10-14
Self-Debug	Syntax/semantic hata	Execution feedback loop	+%7-11
Guard Layer	Yetkisiz erişim, PII	RLS + allowlist + masking	Güvenlik (acc.+0)

Model Seçenekleri: Genel LLM vs SQL-Spesifik Fine-Tune

2026’da text-to-SQL’de iki ayrı şerit var: (a) generalist frontier modeller (b) SQL-spesifik küçük modeller. Generalist’lerin avantajı, complex join ve nested subquery üretiminde tutarlılık; dezavantajı maliyet ve veri çıkış riski. SQL-spesifik modeller (SQLCoder-34B, Granite-Code-SQL, Defog tarafından eğitilenler) ise on-prem dağıtım kolaylığı ve düşük token maliyeti sağlar.

Model	Tip	Spider 2.0 Acc.	1M token input fiyat (USD)	On-Prem	Yaklaşık VRAM
GPT-4.1	Frontier	~%80	2.00	Hayır	–
Claude 3.7 Sonnet	Frontier	~%78	3.00	Hayır	–
Gemini 2.5 Pro	Frontier	~%77	1.25	Vertex AI	–
DeepSeek-V3	Open weight	~%72	0.27	Evet	~700 GB FP8
SQLCoder-34B	SQL-specialist	~%70 (BIRD)	~self-host	Evet	~70 GB FP16
Granite-Code-SQL-8B	SQL-specialist	~%64 (BIRD)	~self-host	Evet	~16 GB FP16

Seçimde basit ama net bir karar çerçevesi:

• Avantaj (frontier): En yüksek complex query doğruluğu, zero-shot iyi performans.
• Dezavantaj (frontier): Token maliyeti, veri rezidans/regülasyon riski.
• Ne zaman seç (frontier): Düşük QPS, yüksek karmaşıklıkta analytical workload, regülasyon bariyeri yoksa.
• Avantaj (specialist): Düşük marjinal maliyet, on-prem, veri çıkmaz.
• Dezavantaj (specialist): Edge case complex query’lerde frontier’ın gerisinde.
• Ne zaman seç (specialist): Yüksek QPS, sabit şema, finans/sağlık/savunma gibi veri rezidans hassasiyeti.

Hibrit strateji 2026’da yaygınlaştı: kolay sorguları küçük specialist modele yönlendir, complex/ambiguous olanları frontier’a route et. Bu router pattern’i için LLM Özelleştirme yazısındaki maliyet ve doğruluk değiş tokuşları doğrudan uygulanabilir.

Schema Linking ve Retrieval: Doğruluğun Asıl Kaldıraçları

Birçok ekibin yaptığı temel hata, tüm şemayı tek bir devasa prompt’a koymak. 200+ tablolu enterprise ambarlarda (Snowflake, BigQuery, Databricks) bu hem context window’u tüketir hem de “lost in the middle” etkisiyle doğruluğu düşürür. Doğru desen: retrieval-driven schema slicing.

Schema linker tipik olarak şunları yapar:

• Tablo ve sütun isimleri için embedding üretir (ör. text-embedding-3-large veya BGE-M3) ve bir vector store’da tutar.
• Kullanıcı sorusunu embed eder, top-K (genelde 8-20) tablo aday seti döner.
• Foreign key grafiği üzerinden ek bağlam (join komşuları) ekler.
• İlgili tabloların DDL’i + 3-5 örnek satır prompt’a enjekte edilir.

Few-shot örnek seçimi de retrieval ile yapılır: benzer geçmiş soru-SQL çiftleri vector store’dan çekilir. Burada embedding kalitesi kritik; Türkçe için bu konuyu derinleştirmek isteyenler Embedding Modelleri karşılaştırmasına bakabilir, vector store seçimini optimize etmek için ise Vector Veritabanı yazısı doğrudan referans.

Retrieval Stratejisi	Recall@10	P95 Latency	Index Maliyeti	Notlar
Pure BM25	~0.71	22 ms	Düşük	Eş anlamlıyı kaçırır
Dense (BGE-M3)	~0.84	38 ms	Orta	Domain drift’e duyarlı
Hybrid (BM25 + dense, RRF)	~0.91	46 ms	Orta-Yüksek	Üretim standardı
Hybrid + ColBERT rerank	~0.95	120 ms	Yüksek	Critical query path

Resmi ve referans dokümantasyon için Google’ın BigQuery Text-to-SQL rehberi ve Microsoft’un Databricks AI/BI Genie belgeleri schema retrieval ve grounding örüntülerini somut görmek için faydalı.

Prompt Tasarımı, Function Calling ve Agent Pattern’i

Prompt yapısı text-to-SQL’de “system + schema + few-shot + question + constraints” bileşenlerinden oluşur. 2026’da yaygın iyileştirmeler:

• SQL dialect deklarasyonu: “Generate Snowflake SQL” gibi açık talimat; LIMIT vs FETCH FIRST gibi syntax farklarını çözer.
• Output schema zorlama: JSON output (sql, rationale, confidence) ile structured response. Karar verilebilir telemetri sağlar.
• Self-consistency: Aynı soruya N farklı sample çek, execution sonuçları aynıysa confidence yüksek.
• Tree-of-thought / Plan-and-Execute: Önce decomposition planı, sonra her alt-sorgu için ayrı SQL üretimi.

Function calling ile text-to-SQL’i agent mimarisine entegre etmek, 2026’nın en hızlı yayılan deseni. Bir LLM agent; “get_schema_subset”, “run_sql_dry”, “run_sql_execute”, “explain_plan”, “fetch_glossary” gibi araçları çağırarak iteratif çalışır. Bu deseni mühendislik tarafında derinleştirmek için Function Calling Tool Use ve AI Agent Tasarım Pattern yazıları referans niteliğinde; uçtan uca otomasyona evrilen sistemler için ise Agentic AI İş Akışları mimari resmi tamamlıyor.

Prompt mühendisliğinin kurumsal disiplini için ayrıca Prompt Engineering ve halüsinasyonu üretim hattında yönetmek için LLM Hallucination Azaltma tamamlayıcı referanslar.

Değerlendirme: Execution Accuracy, Exact Match ve Üretim Metrikleri

Text-to-SQL’de “doğruluk” çoklu boyutlu bir kavram:

1. Execution Accuracy (EX): Üretilen SQL’in çalıştırılınca beklenen sonucu döndürüp döndürmediği. Asıl metrik budur.
2. Exact Match (EM): Sorgunun string olarak gold ile eşleşmesi. Genelde gevşek bir alt sınır.
3. Logical Form Accuracy: AST düzeyinde semantik eşleşme.
4. Valid SQL Rate: Üretilen sorguların parse edilebilir oranı.

Benchmark	Kapsam	Boyut	2026 En İyi EX	Yıl
Spider 1.0	Cross-domain, 200 DB	10,181 soru	~%89	2018
Spider 2.0	Enterprise complexity	~600 soru, 213 DB	~%80	2024
BIRD	Big DBs, dirty data	12,751 soru, 95 DB	~%73	2023
KaggleDBQA	Real-world Kaggle	272 soru	~%55	2021

Benchmark’ın laboratuvar doğası önemli bir uyarıdır: Spider’da %80 EX, sizin 250 tablolu, 12 yıllık legacy şemalı ambarınızda %55-60’a kolayca düşebilir. Üretim için kendi gold set’inizi oluşturmak şart: 200-500 soru-SQL çifti, en sık 20 iş sorusu, edge case’ler, kasıtlı belirsiz sorular.

Üretim metrikleri ayrıca:

• Tool success rate (self-debug retry sonrası başarılı sorgu oranı).
• Avg cost per query (token + compute).
• P95 latency (Spider 2.0 büyük şemada genelde 1.5-2.5 sn).
• Trust score (kullanıcı thumbs up oranı, business KPI).

RAG benzeri değerlendirme disiplinini SQL’e taşımak için RAG Evaluation yazısındaki Ragas/TruLens yaklaşımı, “faithfulness” ve “answer relevance” metriklerini text-to-SQL için adapte edebileceğiniz iyi bir başlangıç. Akademik referans için arXiv’deki BIRD: A Big Bench for Large-Scale Database Grounded Text-to-SQLs makalesi temel okuma.

Üretim Hattı: Maliyet, Latency, Caching

Üretim maliyetini optimize etmek için kademeli mimari standart hale geldi. Tipik bir akış:

1. Query cache (semantic hash) — daha önce sorulan sorunun cevabı varsa anında dön. Tipik hit oranı %25-40.
2. Specialist küçük model (SQLCoder-8B veya Granite) — kolay sorgular için.
3. Frontier model (GPT-4.1 / Claude 3.7) — complex veya self-debug retry olan sorgular için.
4. Human-in-the-loop — finance/HR gibi yüksek risk sorgularda ek onay turu.

Senaryo	Model Mix	Avg Cost / Query (USD)	P95 Latency	Acc. (firma gold)
Tek-frontier	GPT-4.1 only	0.012	2.3 sn	%74
Tek-specialist	SQLCoder-34B self-host	0.0008	1.1 sn	%61
Hybrid router (60/40)	Specialist + GPT-4.1	0.0042	1.4 sn	%72
Hybrid + cache	+ semantic cache	0.0028	0.9 sn	%72

10 milyonluk aylık sorgu hacminde, “Tek-frontier” yaklaşık 120 bin USD/ay, “Hybrid + cache” yaklaşık 28 bin USD/ay yapar. Doğruluk farkı 2 puan; maliyet farkı 4x. Bu, agresif olmayan bir router ile bile sağlanabilir.

Self-debug döngüsü maliyeti uçurabilir. Bir kuralı baştan koyun: max 2 retry, 3. denemede deterministik fallback (önceki başarılı benzer sorgu veya “soruyu yeniden ifade edin” mesajı). MLPerf Inference v4.1 sonuçlarına göre büyük LLM’lerin token başına marjinal maliyeti 2024-2026 arasında yaklaşık %63 düştü, dolayısıyla bu mimarinin TCO’su her çeyrek iyileşiyor. Aynı dönemde dense retrieval (BGE-M3 sınıfı modeller) için 1 milyar embedding üretim maliyeti yaklaşık %48 düştü; bu, schema linker ve few-shot retrieval havuzlarını daha sık yeniden indekslemeyi ekonomik kıldı.

Önemli bir üretim deseni: semantic cache invalidation. Schema değişimi (yeni sütun, drop edilmiş tablo, anlam kaydıran rename) caching katmanını tehlikeli hale getirir; cache hit ama yanlış sonuç döner. Çözüm: cache key’e schema hash dahil etmek ve schema diff event’lerinde ilgili cache bucket’ını invalidate eden bir kanal kurmak. CNCF’in Cloud Native Computing Foundation ekosisteminden Kafka/NATS gibi event bus altyapıları bu invalidation pipeline’ı için olgun seçenekler.

Bir başka kademe: result-set caching ile SQL-text caching ayrımı. Aynı SQL’in saatte 50 kez koşması beklenen dashboard sorguları için materialized view veya warehouse’un native result cache’i (Snowflake’in 24 saat result cache mekanizması gibi) text-to-SQL cache’inin altına ek bir tasarruf katmanı koyar. İki katmanın birlikte çalıştığı kurulumlarda toplam compute tasarrufu %55-70 bandına çıkar.

Güvenlik, Governance ve PII: 2026 Zorunlulukları

Text-to-SQL’in en az konuşulan ama en yüksek risk taşıyan yanı güvenlik. NIST AI RMF 1.0 ve ENISA’nın 2025 “Multilayer Framework for Good Cybersecurity Practices for AI” rehberi, LLM tabanlı veri arayüzleri için spesifik kontroller tanımladı. Production guard layer’ında en az şunlar olmalı:

• Allowlist: LLM’in görebileceği tablo/sütun listesi kullanıcı rolüne göre filtrelenir.
• Row-Level Security (RLS): Veritabanı seviyesinde (Snowflake row access policies, BigQuery row-level access, Postgres policies). LLM bunu bypass edemez.
• PII masking: e-posta, TCKN, kart numarası kolonları default hash/redact.
• Query cost guard: EXPLAIN ile bytes scanned tahmini > eşik ise reddet.
• Prompt injection defense: Kullanıcı sorgusundan gelen “ignore previous instructions” tarzı içerikler structured input olarak izole edilir.
• Audit log: Her sorgu için kullanıcı, prompt, üretilen SQL, sonuç hash, sürdürülmüş 365 gün.

OWASP’ın LLM Top 10 listesinde “LLM01: Prompt Injection” ve “LLM06: Sensitive Information Disclosure” maddeleri doğrudan text-to-SQL ile ilişkili. Banka ve sigorta projelerinde, kullanıcı sorgusu LLM’e ulaşmadan önce parameterized intent template aşamasından geçer; bu, prompt injection yüzeyini ciddi oranda küçültür. Bu mimarinin nasıl genel bir agent-asistan deneyimine bağlandığına bakmak için Kurumsal Chatbot Geliştirme rehberi pratik bir köprü.

Türkçe Dil, Çok Şivelilik ve Domain Sözlüğü

Spider/BIRD İngilizce. Türkçe’de text-to-SQL ek zorluklarla gelir: çekim ekleri (“müşterilerin”, “müşterilere”), eş anlamlı iş terimleri (“ciro” vs “hasılat” vs “net satış”), kısaltmalar (“KDV dahil/hariç”), zaman ifadeleri (“geçen mali yıl”, “bayram öncesi”). Çözüm üç katmanlı:

1. Türkçe-güçlü embedding: BGE-M3, E5-multilingual-large veya domain-fine-tuned bir model. Genel Türkçe NLP yaklaşımı için NLP Çözümleri Türkçe yazısı kapsamlı bir tarama sunuyor.
2. Business glossary: “ciro = net_sales_amount”, “aktif müşteri = last_order_date >= now()-90d” gibi tanımlar bir glossary tablosunda; LLM’e RAG ile enjekte edilir.
3. Synonym alias layer: Schema linker, sütun isimlerine ek olarak alias listesi de indeksler.

Pratik gözlem: yalnız English-pretrained bir model + Türkçe prompt kombinasyonu, kuruma özgü gold set’te tipik olarak %12-18 daha düşük EX verir. Bu da business glossary ve embedding seçiminin “nice to have” değil “must” olduğunu gösterir.

Veri analitiğinin yapay zeka destekli üst katmanına bağlanmak için AI Destekli Veri Analitiği ve içerik tarafında alıntılanabilirlik için GEO Stratejileri 2026 ilgili çerçeveler.

Sıkça Sorulan Sorular (SSS)

Sonuç

Text-to-SQL 2026’da artık bir “model seçme” sorusu değil, bir sistem mimarisi sorusudur. Schema linker’sız, retrieval’sız, self-debug’sız ve guard layer’sız bir kurulum laboratuvar başarısının üretim başarısına dönüşmediği yerdir. Doğru kurgu; intent-disambiguation, hybrid retrieval (RRF + reranker), specialist + frontier router, semantic cache, parameterized prompt template, RLS ve audit log’un birlikte çalıştığı 6 katmanlı bir hattır. Spider 2.0 %80 EX rakamına bakıp “çözüldü” demek 2026’nın en pahalı yanlış kararı.

Karar çerçevesi şu üç eksende netleşir: (1) regülasyon ve veri rezidans — finans/sağlık/savunma ise on-prem specialist + RAG; (2) karmaşıklık dağılımı — analytical workload ağırlıksa frontier; (3) hacim ve maliyet — yüksek QPS’te hybrid router + cache zorunlu. Bu üç ekseni doğru kalibre eden ekipler 12-18 ay içinde BI sorgu hazırlama süresini saatten dakikaya, ad-hoc analist talebini ise yarıdan fazla azaltıyor.

Kurumsal text-to-SQL kurulumunuzun mimari değerlendirmesi, gold set tasarımı veya hibrit router ekonomisinin modellenmesi için Ömer Önal’ın yürüttüğü danışmanlık çerçevesinde uçtan uca destek almak için iletişim sayfası üzerinden iletişime geçebilirsiniz; mevcut veri ambarınız ve LLM stack’iniz üzerinden somut bir POC planı çıkarmak ilk doğru adım.