2024-2025 döneminde piyasaya çıkan BI Copilot’ların büyük çoğunluğu aynı sorunla karşılaştı: doğal dilde sorulan "geçen ay en karlı 5 şube" sorusu, LLM tarafından sentaks olarak doğru ama semantik olarak yanlış SQL üretiyor. "Şube karlılığı" kurumun tanımı ile değil LLM’nin yorumu ile çevriliyor. Çözüm bir LLM markası değil — semantic layer denilen ara katman.
Semantic layer nedir?
Semantic layer; tablo ve kolonların ham yapısı ile iş tarafının kullandığı dil arasındaki çevirmen katmandır. Üç ana yapı taşı:
- EntityMap: hangi tablo hangi iş varlığını temsil eder (örn.
dbo.customers→ "Müşteri"). - MetricDefinition: bir KPI’nın nasıl hesaplandığını tek bir formül ile sabitler (örn. "Şube karlılığı = SUM(profit_amount) WHERE branch_id = X").
- BusinessTerm: kurumsal sözlük (örn. "PEP", "AML eşik", "VIP segment").
Bunların yanına ColumnPolicy (görünür/maskeli kolonlar) ve sertifikalı few-shot örnekleri eklenir.
NL → SQL akışı
Semantic layer üzerine kurulan bir BI Copilot’un akışı:
- Intent: kullanıcı ne soruyor — veri sorgusu, KPI açıklaması, glossary?
- Retrieve: vektör arama ile ilgili EntityMap, MetricDefinition ve geçmiş örnek (few-shot) çekilir.
- Plan: LLM bir QuerySpec JSON üretir — tablo, kolonlar, filtreler, gruplama, sıralama. Doğrudan SQL değil!
- Validate: QuerySpec semantic layer ve katalog ile doğrulanır — izinli kolon mu, doğru join yolu mu, PII kontrolü.
- Synthesize: QuerySpec parametrik, salt-okunur SQL’e çevrilir.
- Execute: ayrı bir read-only DB hesabı ile sandbox’ta çalışır.
- Mask: ColumnPolicy ile rol bazlı maskeleme.
- Narrate: anlatımcı LLM, sonucu doğal dilde özetler; sayı, para birimi ve toplam doğrulaması yapılır.
Doğrudan SQL üretmek neden başarısız?
LLM SQL’i sentaks olarak rahatlıkla üretiyor; ama "şube karlılığı" sorusunda hangi tablonun "şube"yi tuttuğunu, "karlılık"ın nasıl hesaplandığını, hangi kolonun PII olduğunu bilmiyor. Doğrudan SQL üretimi pratikte üç hata sınıfı doğurur:
- Yanlış JOIN: aynı isimli iki tablo, yanlış foreign key.
- Yanlış metrik: "karlılık" için profit_amount yerine net_amount kullanmak.
- PII sızıntısı: müşteri TC kimlik kolonunun çıktıya dahil edilmesi.
QuerySpec ara katmanı bu hatalara karşı yapısal bir kapı koyar; LLM sadece "ne istediğimi söyle", arkadaki sentez katmanı SQL’in nasıl yazılacağına karar verir.
Sertifikalı few-shot
Few-shot örnekleri semantic layer’ın canlı belleği gibidir. Banka için iyi bir başlangıç dataset’i:
- "Geçen ay en karlı 5 şube" → QuerySpec → SQL.
- "Bireysel kredi başvuruları onay oranı son hafta" → QuerySpec → SQL.
- "PEP segment portföy hacmi YTD" → QuerySpec → SQL.
Bu örnekler dil bazlı (TR / EN / AZ / RU) ayrı tutulur; LLM ilgili dile uygun few-shot ile beslenir, dil kayması (model TR sorgu için EN cevap üretmesi) önlenir.
Banking domain pack
Doğal dilde "VIP müşteriler hangi şubelerde yoğun?" gibi soruların doğru cevaplanması için kuruma özel terim seti gerekir. Domain pack şu yapıyı içerir: BusinessTerm sözlüğü, MetricDefinition seti, sertifikalı few-shot. Banking-tr ve banking-en pack’leri ortak bir tabandan başlar; her banka kendi terminolojisi ile zenginleştirir.
Operasyonel kapatma
NL → SQL hattı operasyonelleşmek için üç kontrol noktasına ihtiyaç duyar:
- Suggestion inbox: LLM yeni QuerySpec önerirse admin onayı.
- PromptAuditLog: tüm aşamalar audit kaydına; KVKK 90 gün veya RegulatedFinance 7 yıl saklama.
- Confidence threshold: düşük güven sorgusu otomatik olarak insan analiste yönlendirilir.
Kapanış
BI Copilot iyi bir LLM ile değil, iyi bir semantic layer ile çalışır. Yatırımın %70’i tablo ve metric tanımlarına, %20’si few-shot’a, %10’u model seçimine harcanmalı. Bu denge tutturulduğunda doğal dil sorgusu IT bottleneck’ini çözen kalıcı bir analiz arayüzüne dönüşür.
