Yapay zekâ ile BI grafik ve pano taslağı oluşturma

Pano tasarım toplantılarında son bir yılın en sık duyulan cümlesi şu: “Bunu yapay zekâ kuramıyor mu?” Soru haksız değil. Boş bir sayfayı doldurmak, çoğu zaman arkasındaki veriyi hazırlamaktan uzun sürüyor.

Bedeli de görünmez değil. İş birimiyle yapılan ilk toplantı somut bir şey üzerinde değil, herkesin kafasındaki farklı panolar üzerinde geçer. İkinci toplantıya kadar tasarımcı tahminle ilerler, iş birimi de gördüğü ilk sürümde fikrini değiştirir. Üçüncü turda tartışılan konu artık veri değil, geçen iki haftadır.

Grafik taslağı hangi girdiden üretiliyor?

BI Portal’daki yardımcı boş sayfayı üç adımda kapatır:

  • Girdi. Yazdığınız doğal dil istemi, seçili veri nesnesinin mevcut alanları ve konuşma bağlamı.
  • Üretilen çıktı. Bir grafik tanımı ya da birden çok widget içeren sayfa düzeni taslağı.
  • Kontrol. Dönen yapı doğrudan ekrana basılmaz; izinli grafik tipleri, izinli agregasyonlar ve gerçekten var olan alan adlarıyla doğrulanır. Pano taslağında ayrıca widget sayısı ve yerleşim kuralları kontrol edilir.

Yani yardımcının önerebileceği şey, sizin veri kümenizde karşılığı olan bir grafik ya da sayfa düzenidir. Önerilen görsel de serbest değil: grafik, KPI, gösterge, ızgara, harita, huni ve şelale gibi tanımlı widget tipleri arasından seçilir. Veri kümesinde bulunmayan bir alanı isteyip sonucu görmek, bu sınırı kendi ortamınızda sınamanın pratik bir yoludur.

Pano taslağını kim kaydediyor?

Hiçbir taslak kendiliğinden kaydedilmiyor. Çıktı ön yüze gelir; kaydetmek, düzenlemek ve yayımlamak kullanıcının işidir. Bu ayrım kozmetik değil: ölçü seçimi, kırılım ve biçimlendirme panonun iş anlamını belirler ve bunları doğrulayan bir mekanizma yoktur. Doğrulama alan ve tip düzeyindedir, iş mantığı düzeyinde değil. Taslak, işin doğru kurgulandığını göstermez; teknik olarak tutarlı bir başlangıç noktası verir.

Kendi ortamınızda yapabileceğiniz karşılaştırma şu: sonucunu zaten bildiğiniz bir veri nesnesini seçin, aynı grafiği hem elle hem istemle kurun, iki tarafta da toplam rakamı okuyun. Fark çıkarsa bakılacak yer genellikle model değil, ölçünün hangi kırılımda toplandığıdır — ve o kararı vermek hâlâ tasarımcının işi.

Model anahtarı ve günlük çağrı limiti

Bu yardımcılar kendiliğinden çalışmaz. Kayıtlı bir sağlayıcı, kullanıcıya ait bir API anahtarı ve model seçimi gerekir; projede doğrulanmış yol OpenRouter üzerinden geçer ve anahtara son kullanma tarihi ile günlük çağrı limiti tanımlanabilir. İki sonucu var: hangi ekibin yardımcıyı ne ölçüde kullandığı görünür hâle gelir ve istem ile alan bağlamının kurum dışındaki bir sağlayıcıya gittiği, bilinçli verilen bir karar olarak masada durur.

Bir sonraki pano tasarım toplantınızda küçük bir deney yapın: gündemdeki veri nesnesini seçin, istediğiniz grafiği tek cümleyle yazın ve çıkan taslağı ekibin boş sayfada ürettiği ilk öneriyle yan yana koyun. Hangi kararın taslağa, hangisinin tasarımcıya kaldığı o karşılaştırmada netleşir. Bu oturumu kendi veri nesnenizle kurmak isterseniz kapsamı beraber çıkaralım.