Text-to-SQL karşılaştırmaları erişim kontrolünü yok sayıyor, LLM tablo açıklamaları ise retrieval'ı bozabiliyor

Aynı kör noktaya işaret eden iki bulgu

Ashish Sinha'nın dev.io'da paylaştığı iki sonuç, doğal dilden SQL'e sistemlerinin aynı zayıf noktasında birleşiyor: şemanın hangi parçalarının modele ulaştığına karar veren adım. İlki, ana akım text-to-SQL benchmark skorlarının erişim kontrolü olmadan ölçüldüğünü gösteren, SIGMOD 2027'ye kabul edilmiş bir makale. İkincisi ise şemayı LLM yazımı açıklamalarla zenginleştirme yönteminin retrieval'ı ölçülebilir biçimde kötüleştirebileceğini gösteren uygulamalı bir deney.

Sonunda kimin sorduğunu soran bir benchmark

dev.io'daki yazıya göre, Yang Fei, Yangfan Jiang, Yin Yang ve Xiaokui Xiao imzalı "Benchmarking Text-to-SQL under Role-Based Access Control" makalesi (arXiv, Temmuz 2026), sistemlerin çoğunun değerlendirildiği üç benchmark — Spider, BIRD ve LiveSQLBench — alıyor ve hepsinde eksik olan şeyi ekliyor: roller ve rollere bağlı politikalar. Genişletilmiş veri seti 53 veritabanı, 399 tablo, 3.353 sütun ve 21.502 rol etiketli sorgu örneğini kapsıyor; politikalar sütun-işlem düzeyinde tanımlı, yani soru bir rolün tabloyu okuyup okuyamadığı değil, belirli bir sütunu SELECT edip edemeyeceği. Roller, kapsamlı yönetici rolleri de dahil olmak üzere LLM destekli bir pipeline ile veritabanı başına sentezlendi.

Mevcut sistemler bu benchmark'a göre puanlandığında, yüksek performanslıların çoğu — özellikle açık ağırlıklı LLM'ler — keskin biçimde düşüyor; yazarlar bunu sık RBAC ihlallerine bağlıyor. Sinha, akılda tutulmaya değer uyarılar ekliyor: benchmark henüz yayınlanmadı, makale pipeline, araç seti ve veri setleri için genel bir depo sözü veriyor ve Sinha bunu kendisi çalıştırmamış.

RBAC tarafından reddedilen başarılar

Makalenin en keskin katkısı, metriklerinin ortaya çıkarmak için tasarlandığı bir başarısızlık kategorisi: sıradan puanlama altında doğru satırları döndüren ama erişim politikasını ihlal eden sorgular. Spider'ın veya BIRD'ın puanlaması altında bu sorgular başarı sayılıyor. Düşüşün keskin olmasının nedeni kısıtlar altında SQL yazmanın doğası gereği zor olması değil, hiçbir zaman yetkilendirmeyi kontrol etmeyen bir metriğin ihlalleri sessizce başarı olarak saymasıdır. Sinha'nın aktardığı mimari neden ise yerleşimle ilgili. Gerçek şemalar bir prompt için fazla büyüktür; bu yüzden her stack önce retrieval adımıyla aday tabloları daraltır. Veritabanı erişim kontrolü — grant'ler, satır düzeyinde güvenlik — daha sonra, yürütme aşamasında devreye girer. Ranker kimin sorduğunu göremez; dolayısıyla bir destek temsilcisinin sorusu modele bir maaş tablosunu iletebilir, model buna karşı doğru SQL yazar ve satır düzeyi güvenlik tüm satırları filtreler. Kullanıcı "böyle bir veri yok" ile "izin yok" arasında ayrım yapmanın bir yolunun olmadığı boş bir sonuç görür ve temsilci kendinden emin biçimde öncekini rapor eder. Daha kötüsü, şemanın kendisi bilgidir: bir prompt'a yerleştirilen tablo adı, hiç satır dönmediğinde bile bir şey ifşa eder ve satır filtreleme bir adı geri alamaz.

Yazıya göre çözüm seçim aşamasında olmalı: kısıtlı nesneler aday kümesinde bulunmamalı, yalnızca düşük sıralanmamalı ve kısıtlı bir nesne var olmayan bir nesneden ayırt edilemez olmalı ki şema taranamasın. Ayrıca kapsam belirlemenin kimlik doğrulama olmadığı, kullanıcının kimliğini sağlayan hangi bileşen olursa olsun bir güven sınırı haline geldiği uyarısı yapılıyor.

Açıklamaların retrieval'ı bozduğu durum

İkinci bulgu, gerçek bir 1.245 nesneli şema üzerinde yapılmış, kendi raporladığı bir deney. Her tablo için LLM açıklaması üretmek ve bunları adların yanında indekslemek recall'ı düşürdü. Adı tam olarak contacts olan tablo, "show the contacts of xmagnet" sorusu için kataloglamadan önce üçüncü sırada yer alırken, kataloglamadan sonra 40. sıranın altına düştü. Açıklamalar doğruydu — ve koreleydi.

Mekanizma BM25 aritmetiği. Bir CRM'de tabloların neredeyse her biri bir anlamda contacts ile ilgilidir; bu yüzden kataloglamadan sonra "contact" token'ı 1.245 belgeden yaklaşık 1.072'sinde geçiyor ve inverse document frequency'i 0,15'e düşüyor; yalnızca adların indekslendiği durumda ise bu terim 17 belgede geçiyor ve değer 4,27. Bu arada BM25'in uzunluk normalizasyonu uzun belgeleri cezalandırıyor ve merkez tablo — contacts 55 sütuna sahip — güvenilir biçimde en uzun olan. IDF çöküşü sıralamayı düzleştiriyor; uzunluk normalizasyonu ise aktif olarak çevre tabloları öne çıkarıyor. En çok bozulan sorgular, açıklamaların hizmet etmek için var olduğu sade İngilizce olanlardı.

İşe yarayan çözüm

Tek bir indeks içinde açıklama metninin ağırlığını düşürmek yalnızca biraz yardımcı oldu ve açıklamaların en güçlü senaryosunu da maliyetli kıldı: "per member per month cost" sorusunu, adlar üzerinden hiçbir leksik yolun köprü kuramadığı v_pmpm adlı tabloya eşleyen durum. İşe yarayan şey, alan başına ayrı BM25 indeksleri oldu — tanımlayıcılar birinde, yazılı metin diğerinde — her biri kendi IDF ve uzunluk istatistiklerine sahip, skorlar yerine sıralamalar üzerinden reciprocal rank fusion ile birleştiriliyor. Alan başına IDF, yaygın terimlerin ayırt edici gücünü yapısal olarak geri getirdi; alan başına uzunluk istatistikleri de geniş tabloları cezalandırmayı bıraktırdı. Sinha, aynı mekanizmanın indekslemeden önce belgeleri üretilmiş özetlerle zenginleştiren her pipeline için tehdit oluşturduğunu belirtiyor.

Neden önemli

Her iki bulgu da kullanıcının sorusu ile modelin prompt'u arasındaki katmana çarpıyor. Spider, BIRD veya LiveSQLBench'ten alıntılanan benchmark sayıları sınırsız okuma erişimiyle üretildi; dolayısıyla bir sistemin gerçek izinlere sahip gerçek kullanıcılar için nasıl davrandığı hakkında çok az şey söylüyorlar. Ve bir şemayı LLM ile kataloglama tavsiyesi, smoke test'lerden geçerken hedeflediği sorguları sessizce kötüleştirebiliyor. Her iki sonucun da uyarıları var — bir benchmark yayınlanmadı, diğeri tek yazarlı, tek şemalı bir ölçüm ve Sinha sonucundan çıkar sağlayabileceği açık kaynaklı bir seçim kütüphanesi sürdürüyor — ama birlikte, veritabanları üzerinde AI inşa eden herkes için somut kontroller tanımlıyorlar: roller altında değerlendirin ve zenginleştirmeden önce ve sonra retrieval'ı ölçün.