Bir banka analisti "geçen ay vadeli mevduat geliri en yüksek 5 şube" diye sorduğunda, doğru cevap aslında zaten SQL'in içindedir. Onu güvenli şekilde dışarı çıkarmak ise birden çok kontrol gerektirir: kullanıcı yetkili mi, hangi metric tanımı kullanılacak, sonuçta TC kimlik veya IBAN sızabilir mi, sayılar gerçekten gösterilen dataframe ile uyuşuyor mu? CentraQL'ın AI BI Copilot pipeline'ı bu sorunu 11 aşamada yönetir.
Pipeline'ın hedefi
Doğal dil sorusunu izlenebilir, denetlenebilir ve kanıtlanabilir bir cevaba çevirmek. 'İzlenebilir' demek; her aşamada hangi LLM'in, hangi konteksle, ne yaptığı log'lanmış demektir. 'Kanıtlanabilir' demek; cevabın hangi SQL'den ve hangi semantik tanımlardan çıktığı kullanıcıya gösterilebilir demektir.
1. Guard
Sorgu yüzeye dokunmadan önce policy katmanı çağrılır: kullanıcı rolü, veri sınıflandırması, ComplianceProfile (örn. RegulatedFinance) kontrol edilir. Prompt-injection patternleri için lightweight regex + similarity filtresi uygulanır; injection skoru yüksek olan soru reddedilir ve audit log'a yazılır.
2. Intent
Kısa bir LLM çağrısı (genelde 7B planner) sorunun türünü sınıflandırır: agregasyon, trend, drilldown, anomali açıklama. Her tip farklı template ve farklı few-shot setine yönlendirilir.
3. Retrieve (Qdrant)
Domain pack içindeki sertifikalı few-shot ve KPI tanımları nomic-embed-text ile vektörlenmiştir. Sorunun semantik benzerleri çekilir; planner'a top-k (~5) konteks olarak iletilir.
4. Plan — QuerySpec JSON
Planner LLM'e few-shot + sorgu birleşik prompt'u verilir. Cevap özgür SQL değil, JSON QuerySpec'tir: hangi metric, hangi dimension, hangi filtre, hangi sıralama, hangi limit. JSON şema doğrulaması ile zorlanır; uyumsuz çıktı reddedilir, bir kez retry tetiklenir.
5. Validate
QuerySpec semantik katmana karşı doğrulanır. Metric tanımlı mı, dimension valid mi, filter alanı kullanıcının erişimine açık mı? RegulatedFinance profilinde ek kontrol: rangeOf, joinDepthMax, allowFreeText=false. Reddedilirse kullanıcıya gerekçeyle birlikte geri dönülür.
6. Synth — SQL
QuerySpec deterministik bir SQL builder ile T-SQL'e çevrilir. LLM bu aşamada kullanılmaz; yani halüsinasyon ihtimali sıfırdır. SQL formatlanır, hash'lenir, audit'e yazılır.
7. Execute (read-only)
Hazırlanan SQL read-only bir bağlantıdan çalıştırılır. Timeout default 30s, RegulatedFinance için 10s. Row limit profil bazlı; tipik 1000 satır.
8. Mask (PII)
Sonuç dataframe ColumnPolicy'ye göre filtrelenir: TC kimlik, IBAN, email, telefon maskelenir veya tamamen düşürülür. Maskeleme executerden sonra, narrate'ten önce yapılır — hassas alan asla LLM'e gitmez.
9. Chart
Sonuç tipine göre uygun grafik (line, bar, pie, table) ve eksenler üretilir. QuerySpec içinde önceden belirlenmiş olabilir; aksi durumda heuristik kullanılır.
10. Narrate (LLM)
Maskelenmiş sayısal sonuç + chart spec narrator LLM'e verilir; insan-okunaklı bir özet çıkar. Sanitization stage çıktıdaki sayı/yüzde/TL değerlerini orijinal tabloyla karşılaştırır; uyuşmazsa narrative düzeltilir.
11. Audit
Pipeline'ın her aşamasının metadata'sı PromptAuditLog tablosuna yazılır: sorgu hash, kullanıcı, timestamp, planner ve narrator model adları, token sayıları, dönen satır, maskelenen kolonlar, p50/p95 latency. BDDK için 365 gün retention.
Tipik latency
1×RTX 4090 + Qdrant + SQL Server üzerinde p95 ≈ 6-9 sn:
- Guard + Intent: 200 ms
- Retrieve: 80 ms
- Plan (7B q4): 2-3 sn
- Validate + Synth: 60 ms
- Execute: 150-800 ms
- Mask: 30 ms
- Narrate (14B q4): 1.5-3 sn
- Audit (async): 20 ms
Sonuç
CentraQL Copilot mimarisi 'LLM bana SQL üretsin' yaklaşımının tersidir: LLM yalnızca doğal dil ve özet üretiminde kullanılır; SQL deterministik builder'dan çıkar, semantik katmandan ve katalog sınırından geçer, çıktı maskelenir. Sonuç: halüsinasyon riski sıfıra indirilmiş, regülatöre sunulabilir bir mimari.
