Yapay Zeka & İleri Analitik / Karar Destek
Kurumun verisini makine öğrenmesiyle tahmine, tahmini de aksiyona çeviren; MLOps ve büyük veri altyapısıyla yönetilen uçtan uca bir yapay zeka ve karar destek platformudur.
Kurumlar artık "bir dashboard" değil, geleceği tahmin edip aksiyon öneren sistemler istiyor: talep ve stok tahmini, müşteri kaybı (churn), dolandırıcılık ve risk skorlama, bakım/arıza öngörüsü, fiyat ve rota optimizasyonu. Bu sayfa, böyle bir yatırımı şartname öncesi araştıran bilgi işlem, veri ve iş birimi ekipleri için; bir yapay zeka platformunun neyi kapsadığını, nasıl kıyaslanacağını ve teknik şartnamede nelere dikkat edileceğini anlatır.
Çözüm neyi kapsar?
İleri analitik tek bir üründen ibaret değildir; birbirini besleyen dört katmandan oluşur. Verinin toplandığı ve temizlendiği veri katmanı (data lake / lakehouse, akış ve toplu işleme), modellerin eğitildiği model katmanı (makine öğrenmesi, zaman serisi, optimizasyon), modellerin yaşam döngüsünü yöneten MLOps katmanı (sürümleme, izleme, yeniden eğitim) ve sonucun kullanıcıya ulaştığı karar/servis katmanı (API, pano, uyarı, iş akışına gömme). Karar destek değeri, tahminin bir ekranda kalması değil bir sürece bağlanmasıyla ortaya çıkar.
Analitik olgunluk: hangi soruya cevap veriyorsunuz?
Yatırımın kapsamını netleştirmenin en pratik yolu, hangi olgunluk seviyesini hedeflediğinizi belirlemektir. Aşağıdaki referans tablo, seviyeleri sorduğu soruya, kullanılan tekniğe ve örnek kullanıma göre özetler:
| Seviye | Sorduğu soru | Teknik | Örnek kullanım |
|---|---|---|---|
| Betimsel | Ne oldu? | Raporlama, agregasyon | Satış & operasyon panosu |
| Tanısal | Neden oldu? | Kök-neden, korelasyon | Müşteri kaybı analizi |
| Tahminleyici | Ne olacak? | ML regresyon / sınıflandırma, zaman serisi | Talep & stok tahmini |
| Öngörücü | Ne yapmalı? | Optimizasyon, senaryo, pekiştirmeli öğrenme | Fiyat / rota / kaynak optimizasyonu |
Çoğu kurum betimsel raporlamayı çözmüştür; asıl değer tahminleyici ve öngörücü seviyelerdedir. Şartnamenizi "hangi kararı iyileştireceğim?" sorusuyla kurgulamak, gereksiz kapsam şişmesini önler.
Büyük veri ve MLOps: modeli üretimde canlı tutmak
Bir modeli eğitmek işin küçük parçasıdır; onu aylarca doğru tutmak asıl mühendisliktir. MLOps, yazılımdaki CI/CD'ye modelin yeniden eğitimini (continuous training) ekler. Olgun bir kurulum; öznitelik deposu (feature store), model kayıt defteri (model registry), sürümlenmiş veri hattı ve üretim izleme içerir. Kritik risk veri kaymasıdır (data / concept drift): gerçek dünya değişir, model eskiyip sessizce yanlışlamaya başlar. Bu yüzden doğruluk tek seferlik bir kabul değil, sürekli ölçülen bir SLA olmalıdır.
Modelleri objektif kıyaslamak için ölçülebilir metrikler şarttır. Şartnameye yazılabilecek başlıca metrikler:
| Metrik | Ne ölçer | Tipik kullanım |
|---|---|---|
| MAPE · RMSE · MAE | Tahmin hatası büyüklüğü | Talep, satış, zaman serisi |
| Precision · Recall · F1 | Sınıflandırma isabeti | Churn, dolandırıcılık, risk |
| AUC-ROC | Ayırt etme gücü | İkili skorlama modelleri |
| PSI / drift skoru | Veri kayması | Üretimde sürekli izleme |
Bir ölçüt örneği: tahmin doğruluğu ve iş değeri
Tahmin kalitesini iş diline çevirmek için basit iki formül işinizi görür. Ortalama mutlak yüzde hata:
MAPE = (1 / n) × Σ ( | gerçek − tahmin | / | gerçek | ) × 100
Bunu doğrudan getiriye bağlamak için: Yıllık beklenen kazanç ≈ doğruluk artışı × karar başına etki × yıllık karar hacmi. Örneğin (yalnızca yöntem gösteren örnek): stok tahmininde hatayı %20'den %12'ye çekmek, kalem başına yıllık 1.000 TL fazla/eksik stok maliyeti ve 10.000 kalemde yaklaşık %8'lik iyileşme demek — bu tür bir hesap, yatırımın geri dönüşünü şartname öncesinde savunulabilir kılar. Rakamlar örnektir; gerçek değer kurumun kendi verisiyle ölçülür.
Teknik şartnamede dikkat edilecekler
- Metodoloji ve standart: proje yaklaşımı CRISP-DM gibi bir çerçeveye, yönetişim ise ISO/IEC 42001 (yapay zeka yönetim sistemi) ve NIST AI RMF ilkelerine dayansın.
- Veri sahipliği ve dışa aktarım (lock-in önlemi): eğitilen modeller ONNX/PMML gibi taşınabilir formata, öznitelik tanımları ve eğitim verisi ise dışa aktarılabilir olmalı. Aksi hâlde sağlayıcıya kilitlenirsiniz.
- Entegrasyon: REST/gRPC API, mesaj kuyruğu (Kafka), veri ambarı bağlantısı ve mevcut BI araçlarıyla uyum zorunlu tutulmalı.
- SLA ve performans: tahmin gecikmesi (p95 latency), yeniden eğitim sıklığı, doğruluk eşiği ve eşik altına düşünce devreye giren yeniden-eğitim yükümlülüğü, model olayları için MTTR.
- Açıklanabilirlik ve belgeleme: SHAP/LIME ile karar gerekçesi, her model için model kartı ve veri sayfası.
- Mevzuat: KVKK uyumu, kişisel veride yurt içi saklama, otomatik kararda insan gözetimi; veri güvenliği için ISO 27001.
- Veri kalitesi kabulü: eksiksizlik, tekillik ve tutarlılık kuralları ölçülebilir kriter olarak yazılmalı.
Seçim kriterleri
- İş sonucu odağı: demo doğruluğu değil, hangi kararı ölçülebilir biçimde iyileştirdiği.
- Veri gerçekçiliği: mevcut veri olgunluğunuza uygun, pilotla başlayan kademeli yol haritası.
- Taşınabilirlik: açık formatlar ve dışa aktarımla düşük bağımlılık.
- Operasyonel olgunluk: izleme, drift alarmı ve yeniden eğitim otomasyonunun hazır olması.
- Yönetişim: açıklanabilirlik, denetim izi ve KVKK/ISO 42001 uyumunun kanıtlanabilmesi.
Tahminleyici yapay zekanın nasıl çalıştığını ve nereden başlanacağını Tahminleyici Yapay Zeka rehberimizde veriyle ele alıyoruz. Mevcut verinizi ve önceliklendirilmiş kullanım senaryolarınızı birlikte değerlendirip bir pilot ve şartname taslağı çıkaralım — aşağıdaki formdan ihtiyacınızı iletmeniz yeterli.
Merak edilenler
Hazır bir yapay zeka platformu mu almalı, açık kaynakla mı kurmalıyız?
İkisi de geçerlidir; ölçüt bağımlılık (lock-in) ve toplam sahip olma maliyetidir. Ticari platformlar hızlı devreye alma, yönetişim ve destek sunar; açık kaynak (Python, scikit-learn, Spark, MLflow) esneklik ve maliyet avantajı verir. Kritik olan, hangi yol seçilirse seçilsin modelin ONNX/PMML gibi taşınabilir formata, veri ve öznitelik tanımlarının ise dışa aktarılabilir olmasını şartnamede zorunlu tutmaktır. Böylece sağlayıcı değişse bile varlıklarınız sizde kalır.
Model doğruluğu ne kadar olmalı ve bu sözleşmede nasıl garanti edilir?
Tek bir "yeterli doğruluk" eşiği yoktur; iş etkisine göre belirlenir. Talep tahmininde MAPE, dolandırıcılık tespitinde recall ve yanlış-pozitif oranı gibi metrikler kullanılır. Şartnamede doğruluğu soyut değil, kabul kriteri olarak yazın: örneğin "test kümesinde MAPE ≤ %X" ve üretimde bu eşiğin altına düşerse yeniden eğitim yükümlülüğü. Doğruluğun kalıcı olmadığını, veri kayması (drift) nedeniyle zamanla düşebileceğini de sözleşmeye ekleyin.
Verilerimiz dağınık ve kalitesi düşük; yine de yapay zeka kurabilir miyiz?
Evet, ancak proje çoğunlukla modelleme değil veri hazırlığıyla ilerler; sektörde veri hazırlığının toplam eforun büyük kısmını aldığı yaygın bir gözlemdir (yaklaşık/örnek). Doğru yaklaşım, tam veri ambarı beklemeden dar kapsamlı bir pilot ile başlamak, veri kalitesi kurallarını (eksik, tekil, tutarlılık) ölçmek ve kademeli olgunlaştırmaktır. "Çöp girer, çöp çıkar" ilkesi gereği veri kalitesi metrikleri projenin ayrılmaz parçası olmalıdır.
Kara kutu modeller mevzuata ve denetime uygun mu?
Yüksek etkili kararlarda (kredi, işe alım, sağlık) açıklanabilirlik beklenir. SHAP/LIME gibi yöntemlerle her tahminin hangi değişkenlere dayandığını raporlayabilir, model kartı ve veri sayfası ile kaynağı ve sınırları belgeleyebilirsiniz. ISO/IEC 42001 (yapay zeka yönetim sistemi), NIST AI RMF ve KVKK, otomatik kararlarda şeffaflık ve insan gözetimini öne çıkarır; şartnamede açıklanabilirlik çıktısını zorunlu madde yapmak denetim riskini azaltır.
Kurumunuza özel çözümü konuşalım.
İhtiyacınızı yazın; yapay zeka, veri analitiği ve siber güvenlik çözümlerini değerlendirip 1 iş günü içinde dönelim. Aradığınız yoksa talep üzerine geliştiririz.
Talep Oluştur