# Veritabanınıza gündelik dille soru sormak: doğal dilden SQL üretimi nerede işe yarar? > Bu saha notunda veridive, iş verisinde doğal dilden SQL üretiminin nerede işe yaradığını anlatıyor. Ham ERP ve veri ambarı tablolarında başarısız olur, çünkü iş tanımları şemanın dışında durur. Terim sözlüğüyle desteklenen düzenlenmiş görünümlerde, salt okunur erişim, satır sınırları ve zaman aşımlarıyla, her yanıt sorgusunu ve tanımını gösterdiğinde ve gerçek sorulardan bir değerlendirme seti olduğunda çalışır. Doğal dilden SQL üretimi, iş tanımları ve salt okunur erişimle belgelenmiş küçük bir düzenlenmiş görünüm kümesinde çalışır; ham ERP tablolarına yöneltildiğinde kendinden emin ama yanlış sayılar üretir. Her yanıtın arkasındaki sorguyu ve veriyi gösterin. ## Öne çıkanlar - Ham ERP tablolarına yöneltilen doğal dilden SQL üretimi kendinden emin ama yanlış sayılar verir, çünkü iş tanımları şemanın dışında durur. - Doğal dilden SQL, küçük bir düzenlenmiş görünüm kümesinde ve net satış, aktif müşteri gibi terimleri tanımlayan bir terim sözlüğüyle çalışır. - Yalnızca bu görünümleri gören salt okunur bir hesap, satır sınırları ve sorgu zaman aşımları kullanın; böylece hiçbir şey yazılamaz, hiçbir sorgu kontrolden çıkamaz. - Her yanıtla birlikte sorguyu, tanımı ve verinin bağlantısını gösterin; sistemi onaylı sonuçları olan gerçek sorularla değerlendirin. Demo her zaman ikna edicidir. Biri sohbet kutusuna “ciroya göre ilk on müşteri” yazar, bir sorgu belirir, ardından bir tablo gelir ve toplantı odasındakiler bir daha hiç rapor beklemeyeceklerini hayal eder. Sonra aynı araç gerçek ERP’ye bağlanır ve ilk yanıt, kimsenin açıklayamadığı bir farkla yanlış çıkar. Doğal dilden SQL üretimi (text-to-SQL) işe yarar, ama demonun düşündürdüğünden daha dar bir zeminde: belgelenmiş küçük bir düzenlenmiş görünüm kümesi, iş tanımlarından oluşan bir terim sözlüğü, salt okunur erişim ve gerçek sorulardan oluşan bir değerlendirme seti. Ham ERP tablolarına yöneltildiğinde kendinden emin ama yanlış sayılar üretir. Her yanıt da sorgusunu ve tanımını göstermelidir; böylece okuyan kişi kontrol edebilir. ## Doğal dilden SQL nedir ve neden cazip gelir? Doğal dilden SQL üretiminde bir dil modeli, gündelik dille sorulan bir soruyu veritabanı sorgusuna çevirir, sorguyu çalıştırır ve sonucu sunar. SQL, iş veritabanlarının çoğunun anladığı sorgu dilidir. Cazibesi gerçektir: rapor talepleri küçük bir analitik ekibinin önünde birikir, yöneticiler talep açmadan ek sorular sormak ister ve üretilen bir sorgu saniyeler sürer. Bu, belgelerden yanıt vermekten farklı bir iştir. Sayılar kaynak sistemlerden gelir; modelin işi yanıtı bilmek değil, sorguyu yazmaktır. [Yapay zekayla yönetim raporlarını anlatan not](https://veridive.com/tr/saha-notlari/yonetim-raporlamasi-yapay-zeka/) aynı noktayı raporlama için vurguluyor: sayılar sistemlerden, sözler modelden. ## Ham ERP ve veri ambarı tablolarında neden başarısız olur? Çünkü bir sorgu geçerli olup yine de yanlış bir sayı verebilir. Olağan nedenler: - **Anlaşılmaz şemalar.** Kısaltmalarla adlandırılmış tablolar ve kodları veritabanının hiçbir yerinde açıklanmamış durum sütunları. Model adlardan tahmin yürütür. - **Veritabanının dışındaki tanımlar.** “Net satış”, iadeler, iskontolar ve iptaller düşüldükten sonraki faturalanmış tutar anlamına gelebilir; grup şirketleri arasındaki satışlar hariç. Tablolarda bunu söyleyen hiçbir şey yoktur. - **Satırları çoğaltan birleştirmeler (join).** Siparişleri sipariş satırlarına, onları da sevkiyatlara bağlamak satırları çoğaltır ve toplam iki kez sayılır. Sorgu çalışır; toplam akla yatkındır ve yanlıştır. - **Sayılmaması gereken kayıtlar.** İptal edilmiş, ters kayıtla kapatılmış ve test amaçlı kayıtlar gerçek kayıtlarla aynı tablolarda durur. - **Tarihler ve para birimleri.** Kayıt tarihi mi, belge tarihi mi; takvim yılı mı, mali yıl mı; birkaç para biriminde tutulan tutarlar. - **Uygulamanın içindeki yetkiler.** ERP ekranlarının uyguladığı satır düzeyindeki kurallar ham tablolarda yoktur. > SQL hatası gürültülüdür. Yanlış bir tanım ise sessiz. ## İşe yaraması için ne gerekir: görünümler, tanımlar ve örnekler? Modelin üzerinde durduğu zemini daraltın: - **Düzenlenmiş görünümler.** Yüzlerce ham tablo yerine veri ekibinin kurduğu bir düzine görünüm; “gün ve bölgeye göre net satış” gibi sade adlarla. Birleştirmeler yapılmış, iptal ve test kayıtları ayıklanmış, para birimi açıkça belirtilmiştir. - **İş tanımlarından oluşan bir terim sözlüğü,** finans ve satış ekipleriyle üzerinde anlaşılmış: net satış, aktif müşteri ya da bölge neyi kapsar? Model sözlüğü okur, yanıt da ondan alıntı yapar. - **Sütun açıklamaları ve izin verilen değerler;** böylece bir durum kodu bir sayı olarak değil, “sevk edildi” olarak anlaşılır. - **Onaylı sorgularıyla örnek sorular;** modele şirketin kalıplarını gösterir. - **Varsa bir anlamsal katman (semantic layer):** metrikler ve boyutlar bir kez tanımlanır; model serbest SQL yazmak yerine “mali yıl için bölgelere göre net satış” metriğini seçer. Mevcut olduğunda daha güvenli tasarım budur. En çok talep edilen raporlarınızın arkasındaki görünümlerle başlayın. Her yeni görünümün, model onu sorgulamadan önce bir sahibi ve yazılı tanımları olmalıdır. ## Sistem nasıl güvenli tutulur? Modelin dil dökerek aşamayacağı kontrollerle: - **Yalnızca düzenlenmiş görünümleri gören salt okunur bir hesap.** Yazma yok, şema değişikliği yok; bunu prompt değil, veritabanı uygular. - **Satır sınırları ve sorgu zaman aşımları,** veri ambarı sorgularında maliyet sınırlarıyla birlikte. - **Çalıştırmadan önce doğrulama:** üretilen SQL ayrıştırılır, görünümlerin izin listesine göre kontrol edilir ve birden fazla komut içeriyorsa reddedilir. - **Kullanıcı bazında satır düzeyinde güvenlik;** böylece bir bölge müdürünün sorusu yalnızca kendi bölgesinin verisini döndürür. - **Asgari kişisel veri:** görünümler, soruların ihtiyaç duymadığı sütunları dışarıda bırakır. - **Kayıtlar:** soru, sorgu, sonucun boyutu ve kullanıcı. ## Yanıtlar kullanıcılara nasıl gösterilmeli? Kanıtıyla birlikte bir sayı olarak: sonuç, kullanılan tanım, uygulanan filtreler, sorgu ve aynı veriyi raporlama aracında açan bir bağlantı. Temsili bir örnek ele alalım: Bir satış direktörü “kuzey bölgesinde net satışlar ne kadardı?” diye soruyor. Terim sözlüğü net satışı; iadeler, iskontolar ve iptaller düşüldükten sonraki faturalanmış tutar olarak tanımlıyor, grup içi satışlar hariç. Bölge tablosu da “kuzey” değerini belirli satış bölgelerine eşliyor. Dönem belirtilmemiş; bu yüzden sistem tek bir soru soruyor: mali yıl başından bugüne mi, yoksa belirli bir ay mı? Direktör mali yıl başından bugüne seçeneğini seçiyor. Sistem, kuzey bölgesine ve içinde bulunulan mali yıla göre filtrelenmiş net satış görünümünü sorguluyor. Yanıtta toplam tutar, tanımı aktaran bir satır, filtreler, “sorguyu göster” bağlantısının arkasındaki sorgu ve görünümü gösterge panelinde açan bir düğme yer alıyor. Direktör rakama itiraz ederse tartışma tanım üzerine döner; olması gereken yer de orasıdır. Bu netleştirici soru bir kusur değil, bir özelliktir. Belirsiz sorulara tahminle değil, soruyla karşılık verilir. ## Doğal dilden SQL nasıl değerlendirilir? Rapor taleplerinden ve analistlere gelen taleplerden derlenmiş gerçek iş sorularından oluşan bir değerlendirme setinde. Her sorunun onaylı bir sorgusu ve onaylı bir sonucu vardır; setin sahibi veri ekibi ile iş birimidir. - **SQL metnini değil, sonuçları puanlayın.** İki farklı sorgu da doğru olabilir; ikisini de çalıştırın ve sayıları üzerinde anlaşılmış bir yuvarlama toleransı içinde karşılaştırın. - **Belirsiz soruları da ekleyin:** doğru davranışın netleştirici bir soru olduğu sorular ve görünümlerin yanıtlayamadığı, doğru davranışın bunu söylemek olduğu sorular. - **Zorluğa göre etiketleyin:** tek görünüm, bir toplama işlemi, zaman içinde karşılaştırma, bir sıralama. - **Her değişiklikte yeniden çalıştırın:** görünümlerde, terim sözlüğünde, promptlarda ya da modelde. - **Canlı yanıtları da kontrol edin.** Bir analist her hafta canlı kullanımdaki sorulardan bir örneklemi elle yeniden çalıştırır. - **Yanıtlanamayan soruları saklayın.** Yeni görünümler ve tanımlar için iş listesi bunlardır. ## Neden önce görünümler kurulmalı? Analistlerinizin en sık yanıtladığı yirmi soruyu alın, her biri için onaylı sorguyu ve tanımı yazın ve bu soruların ihtiyaç duyduğu görünümleri kurun. Bu görünümlerin yanıtlayamadığı bir soru, doğal dilden SQL için hazır değildir. Görünümler, terim sözlüğü ve değerlendirme seti [veri ve yapay zeka altyapısı](https://veridive.com/tr/hizmetler/veri-ve-yapay-zeka-altyapisi/) çalışmasının konusudur; ERP’nin içinde yanıtlanan sorular için [ERP ve kurumsal iş akışları](https://veridive.com/tr/cozumler/erp-ve-kurumsal-is-akislari/) sayfasına bakın. ## Sık sorulan sorular ### Doğal dilden SQL üretimi nedir? Doğal dilden SQL üretimi, bir dil modelinin gündelik dille sorulan bir soruyu veritabanı sorgusuna çevirdiği, sorguyu çalıştırdığı ve sonucu sunduğu bir tekniktir. İnsanlar böylece SQL yazmadan “kuzey bölgesinde net satışlar ne kadardı?” diye sorabilir. Ancak üzerinde anlaşılmış iş tanımları olan, iyi belgelenmiş verilerde, salt okunur erişimle ve arkasındaki sorguyu gösteren yanıtlarla güvenilir biçimde çalışır. ### ERP veritabanında doğal dilden SQL kullanılabilir mi? Ham tablolarda güvenle kullanılamaz. ERP şemaları anlaşılmaz adlar kullanır, iptal edilmiş ve test kayıtlarını saklar ve net satış gibi iş tanımlarını veritabanının dışında bırakır; bu yüzden üretilen sorgular çalışır ve akla yatkın ama yanlış sayılar döndürür. Tanımları içeren bir terim sözlüğüyle birlikte küçük bir düzenlenmiş, salt okunur görünüm kümesi kurun ve modelin yalnızca bunları sorgulamasına izin verin.