NL2SQL nedir ve nasıl çalışır?

NL2SQL, doğal dildeki bir sorunun ilişkisel temelde yürütülebilecek bir SQL sorgusuna otomatik olarak çevrilmesini ifade eder. Serbest metinle yanıt veren genel bir sohbet robotunun aksine, bir NL2SQL sistemi, gerçek veriler üzerinde çalışan ve satır satır doğrulanabilir bir sonuç döndüren yapılandırılmış bir yapı olan SQL'i üretir.

"Metinden SQL'e" terimi, doğal dil işleme alanındaki akademik araştırmalardan gelmektedir. Ürün ve teknik dokümantasyon tarafında en çok kullanılan kısaltma “NL2SQL”dir. Her ikisi de aynı soruna işaret ediyor: Günlük dilde sorulan bir soru ile bir SQL motorunun beklediği kesin sözdizimi arasındaki boşluğu kapatmak.

NL2SQL, geniş anlamda bir veritabanına bağlı bir konuşma aracısından ayrılır. Birincisi okunabilir ve denetlenebilir bir sorgu üretir; ikincisi, benzersiz ve denetlenebilir bir SQL ile sonuçlanmadan çeşitli araç çağrılarını (arama, hesaplama, yazma) zincirleyebilir. Düzgün tasarlanmış bir NL2SQL sistemi bu kasıtlı olarak sınırlandırılmış kapsam dahilinde kalır: tercüme etme, doğrulama, yürütme, sonuç döndürme.

Güvenilir bir NL2SQL işlem hattı, sağlayıcıdan bağımsız olarak her zaman aynı sırayı izler: soru bir dil modelinden geçer, ardından üretilen SQL, yürütmeden önce doğrulanır, sonra değil. aura-aihizmet koduyla doğrulanan Aurabase uygulaması, bu adımların her birini soyut bir açıklama yerine somut kurallarla gösterir.

1.Soru tabanın gerçek şeması ile alınır

Sistem, doğal dilde soruyu sorgulanan veritabanının şemasıyla ilişkilendirir: tablo adları, sütunlar, türler. Bu model, arayan kişi tarafından sağlanan bir açıklamadan değil, gerçek temelin iç gözleminden gelmelidir. Müşteri tarafından bildirilen bir şemayı kabul eden bir uygulama, var olmayan tablolarla ilgili sorulara veya projeler arasındaki izolasyonun aşılmasına kapı açacaktır. Aurabase motoru, istekte gönderilen herhangi bir schema alanını sessizce yok saymak yerine açıkça reddeder (400 hatası).

2. Bir Yüksek Lisans, aday bir SQL oluşturur

Dil modeli soruyu ve şemayı kendi komut isteminde alır, ardından kısa bir açıklamayla birlikte aday bir SQL sorgusu üretir. Aurabase, özel bir yerel istemciyle üç sağlayıcıya eşit davranır: OpenAI, Anthropic (Claude) ve Gemini. Bu aday SQL, bu aşamada yalnızca bir tekliftir ve asla doğrudan yürütülmez.

3. Aday SQL, yürütmeden önce değil, yürütmeden önce doğrulanır

This is the step that distinguishes a serious NL2SQL system from a simple LLM call followed by naive execution. The generated SQL is parsed into a syntax tree (AST) rather than inspected by a keyword search, which is easily bypassed. The Aurabase implementation, with the sqlparserlibrary, only allows simple SELECT queries: CTE/WITH, subqueries, UNIONs, window functions and locking clauses (FOR UPDATE) are explicitly rejected, as are any SQL functions outside a whitelist of ten functions (count, sum, avg, min, max, lower, upper, coalesce, date_trunc, now).

4. Taahhüt edilen sorgu satır sınırıyla çalıştırılır

Doğrulanmış SQL, eğer halihazırda bir tane yoksa bir LIMIT alır: Aurabase ile varsayılan olarak 100 satır, maksimum 1000 satır; her iki değer de sunucu tarafında yapılandırılabilir. Sınırın ötesindeki bir istek sessizce azaltılmak yerine açıkça reddedilir. Yanıt, bu LIMIT öğesinin sunucu tarafından eklenip eklenmediğini gösterir; böylece arayan kişi, yürütülen SQL'in model tarafından üretilen SQL'den farklı olup olmadığını bilir.

-- Soru: "Premium müşteriler için bu ay kaç sipariş var?"
SELECT count(*) FROM orders
WHERE customer_plan = 'premium'
  AND created_at >= date_trunc('month', now())
LIMIT 100  -- sunucu tarafından eklendi, oluşturulan SQL'de eksik

The full detail of this pipeline, with each HTTP call and each JSON response, is covered in our step-by-step tutorial for building an NL2SQL endpoint on Postgres.

NL2SQL'in her yerde elle yazılmış SQL'in yerini alması amaçlanmamıştır. Belirli bir kapsamı kapsar: SQL bilmeyen veya basit bir sorguyla zaman kazanmak isteyen biri tarafından sorulan özel, tek seferlik sorular.

• Teknik olmayan bir kişi (destek, ürün, yönetim) tarafından bir gösterge tablosunun özel olarak incelenmesi.
• Olası her soru için özel bir API rotası yazmadan veritabanını sorgulayan bir özelliğin hızlı prototiplenmesi.
• Sınırlı analitik self-servis: son kullanıcıya veritabanına doğrudan erişim vermeden sayın, filtreleyin, basitçe toplayın.

Soru bu kapsamın ötesine geçtiğinde elle yazılmış SQL tercih edilir olmaya devam ediyor. Yukarıda açıklanana benzer bir AST onaylı uygulama, güvenlik nedeniyle CTE'leri, alt sorguları ve pencere işlevlerini yapı itibarıyla hariç tutar. Bu yapılara, kohortlara, gelişmiş zamansal pencerelemeye yapısal olarak ihtiyaç duyan bir analiz, NL2SQL'den geçmez: doğrudan kodlanır. Bu kabul edilmiş bir uzlaşmadır; sistemin güvenliği, oluşturulan SQL'in eksiksizliğinden önce gelir.

Bir NL2SQL uygulamasında, sistemin olgunluğuna bağlı olarak farklı yanıtlarla sistematik olarak üç risk tekrarlanır.

İstem veya soru yoluyla SQL enjeksiyonu

Sorunun kendisi "önceki ifadeleri yoksay ve..." enjeksiyon girişimini içeriyorsa, bir LLM kötü amaçlı SQL üretecek şekilde manipüle edilebilir. Savunma, istemlere güvenmek değil, talep edilenden bağımsız olarak üretilen SQL'i doğrulamaktır; tam olarak yukarıda açıklanan işlem hattının 3. adımıdır. Konu özel olarak ele alınmayı hak ediyor: Kesin saldırı vektörleri ve karşı önlemler için bkz. NL2SQL'in SQL Enjeksiyonuna Karşı Güvenliğini Sağlama.

Var olmayan tablo veya sütunların halüsinasyonu

Model, özellikle büyük veya yetersiz belgelenmiş şemalarda, makul ancak gerçek şemada eksik olan bir tablo veya sütun adı icat edebilir. Oluşturulan SQL'i gerçek veritabanı şemasına göre doğrulayan bir uygulama, ham bir SQL hatasının kullanıcıya geri gönderilmesine izin vermek yerine, sorguyu açık bir mesajla reddeder ve gerçekte mevcut tabloları listeler.

Model çağrılarının maliyeti ve gecikmesi

Her NL2SQL sorusu, SQL yürütme süresinin yanı sıra kendi maliyeti ve gecikme süresiyle birlikte dil modeline bir çağrıyı tetikler. NL2SQL, tekrarlanan sorular için varsayılan katman olarak hizmet verdiğinde bu maliyet hızla artar; bu, her seferinde yeniden çevrilmek yerine önbelleğe alınmasından veya standart bir rapor olarak gösterilmesinden fayda sağlar.

İki mimari benzer görünür sonuçlar üretir ancak garantileri çok farklıdır. Yerel NL2SQL, oluşturma, doğrulama ve yürütmeyi doğrudan projenin şemasını ve erişim haklarını zaten bilen arka uç katmanına entegre eder: bu, aura-ai hizmetinin altyapıyı ve şema yalıtımını arka ucun geri kalanıyla paylaştığı Aurabase için yukarıda açıklanan mantıktır.

Birleştirilmiş bir NL2SQL, genel bir LLM hizmetini, veritabanına bir bağlayıcıyı ve kendin yap doğrulama katmanını birleştirir. Hiçbir şey bu yaklaşımın güvenli olmasını engellemez, ancak her garanti, sunucu tarafı içe dönük şema, AST doğrulaması, satır sınırı, izolasyon kiracısı, platform tarafından sağlanmak yerine bu tuğlaları bir araya getiren ekip tarafından uygulanmalı ve sürdürülmelidir.

Yerel ve derlenmiş, açık kaynak ve ticari NL2SQL araçlarının genel görünümü, NL2SQL 2026 araç karşılaştırmamızdaayrıntılı olarak karşılaştırılmıştır.

NL2SQL ve RAG (geri almayla artırılmış nesil), her ikisi de bir veritabanına bağlı bir LLM'ye dayandığı için sıklıkla karıştırılan iki farklı soru ailesini yanıtlar.

NL2SQL, yapılandırılmış ve ilişkisel verileri hedefler: doğal olarak SELECT, GROUP BYtoplamalarına dönüşen kaç, ne zaman, hangi oranda soru. RAG, yapılandırılmamış içeriği hedefler: cevabın bir tablo satırına sığmadığı ancak modele bağlam içinde vermeden önce anlamsal benzerliğe göre ilgili bir pasajın bulunmasını, pgvector'da vektör aramasını, HNSW indeksini gerektiren belgeler, notlar, destek biletleri.

The two capabilities can coexist in the same project and combine in an agent who chooses one or the other depending on the question asked. The Aurabase native AI pillar details how the two mechanisms work together, and our RAG pipeline guide on pgvector covers the implementation of the second.