Yapay Zeka Destekli Dinamik Fiyatlandırma ve Maliyet Hesaplama Sistemi: Lojistik Sektörü için Regresyon, Zaman Serisi Analizi ve Online Öğrenme Yaklaşımı

- Mart 24, 2025

İçindekiler

Giriş: Lojistikte Dinamik Fiyatlandırma İhtiyacı ve AI’nın Rolü
1.1 Sabit Fiyatlandırma Modellerinin Sınırları
1.2 Yapay Zeka ile Gerçek Zamanlı Karar Destek
Sistemin Genel Mimarisi ve Teknolojik Altyapı
2.1 Backend Teknolojileri (Python, Flask, FastAPI)
2.2 Frontend ve Mobil Arayüz (React, React Native)
2.3 Veritabanı Yapısı (PostgreSQL, Redis, MongoDB)
2.4 API ve Sistem Entegrasyonları
Girdi Katmanı: Sefer Verisinin Yapılandırılması
3.1 Araç, Mesafe, Yük, Yakıt ve İklim Verisi
3.2 Veri Doğrulama ve Ön İşleme Süreci
3.3 Coğrafi Girdiler için PostGIS Kullanımı
Regresyon Modeli ile Gerçek Maliyet Tahmini
4.1 Modelleme Algoritmaları (XGBoost, LightGBM, Ridge Regression)
4.2 Girdi-Çıktı Haritalaması
4.3 Model Performans Karşılaştırmaları
Zaman Serisi ve Endeks Hesaplama Modülü
5.1 Prophet ve ARIMA ile Zaman Serisi Modelleme
5.2 Dinamik Fiyat Endekslerinin Hesaplanması
5.3 Bölgesel ve Sezonsal Kümeleme (KMeans, DBSCAN, HDBSCAN)
Fiyat Öneri Motoru ve Sınıflandırıcı Yapay Zeka Modülü
6.1 Random Forest ve Decision Tree ile Fiyat Segmentasyonu
6.2 Yavaş, Normal, Hızlı ve Opsiyonel Fiyat Önerisi
6.3 Karar Ağacı Görselleştirmeleri
Anomali Tespiti ve Uç Değer Filtreleme
7.1 Isolation Forest ile Aykırı Örnek Belirleme
7.2 Fiyat Sapma Limitleri ve Güvenli Aralıklar
Online Öğrenme ve Model Güncellenebilirliği
8.1 River ve Vowpal Wabbit ile Adaptif Öğrenme
8.2 Yeni Sefer Verileri ile Model Otomatik Güncelleme
8.3 Zamanla Gelişen Tahmin Performansı
Veri Görselleştirme ve Kullanıcı Arayüzü Deneyimi
9.1 Matplotlib, Seaborn ile Veri Sunumu
9.2 Web Arayüzü: Sefer Girdisi ve Fiyat Çıktısı Görselleri
9.3 Mobil Kullanıcı Deneyimi ve Geribildirim Döngüsü
Kullanılacak Python Kütüphaneleri ve Fonksiyonel Ayrım
10.1 Veri İşleme
10.2 Modelleme ve Tahmin
10.3 Görselleştirme
10.4 Online Öğrenme
10.5 API ve Sunucu Entegrasyonu
Sistemin Yazılım Geliştirme Ekibi ve Rol Dağılımı
11.1 AI Backend Geliştirici
11.2 Data Scientist
11.3 Frontend Developer
11.4 Full Stack / DevOps
Sonuç ve Gelecekteki Gelişim Alanları
12.1 Model Genişletilebilirliği

12.2 Blockchain & Akıllı Sözleşmelerle Entegrasyon
12.3 Sektörel Uyarlamalar: E-Ticaret, Soğuk Zincir, Mikro Lojistik

Uyarı

Bu doküman; yüzeysel “AI çözer” anlatılarından, pazarlama metinlerinden ve hype kültüründen tamamen arındırılmıştır.

Aşağıda anlatılan sistem, doğrudan yüksek frekanslı veri akışı, regresif tahminleme, zaman serisi modellemesi, non-linear decision trees, unsupervised clustering, online learning ve anomaly detection gibi tekniklerin mühendislik düzeyinde sentezlenmesiyle geliştirilmiştir.
Eğer bu terimler size yabancıysa, bu yazı sizi zorlayabilir. Eğer tanıdık geliyorsa, hoş geldiniz.

1. Giriş: Lojistikte Dinamik Fiyatlandırma İhtiyacı ve AI’nın Rolü

Lojistik sektörü, klasik anlamda bir "cost allocation problem" olarak ele alınsa da, günümüz koşullarında bu tanım yetersiz kalır. Çünkü artık her taşıma işlemi, bir real-time, data-driven, stochastic optimization problemidir.

Fiyatlandırma, bu sistemin en hassas düğüm noktalarından biridir. Sadece maliyet odaklı hesaplamalarla değil, aynı zamanda market volatility, temporal demand fluctuations, externalities (fuel price, weather, traffic), capacity utilization ratio gibi onlarca değişkenle şekillenen bir yapının içindedir.

Özellikle sabit fiyatlandırma sistemleri (fixed-rate pricing), bu değişkenliğin karşısında yapısal olarak yetersizdir. Gerçek dünya koşulları, deterministik değil, probabilistic bir yapı sunar. Bu nedenle, statik modellemeler artık çözümsüzlüğün parçasıdır.

İşte tam bu noktada, AI destekli dinamik fiyatlandırma sistemleri devreye girer:
adaptive, context-aware, continually learning ve multi-dimensional yapılar kurularak, lojistikte fiyatlandırma artık "kestirimsel hesaplama" değil, decision automation engine haline gelir.

1.1 Sabit Fiyatlandırma Modellerinin Sınırları

Geleneksel sistemlerde fiyatlandırma çoğunlukla rule-based heuristics üzerinden ilerler:
“500 km taşıma = X TL”, “Kamyon 20 ton = Y TL” gibi lineer yaklaşımlar, yüzeyde işlevsel gibi görünse de, değişkenliğe kapalıdır. Bu modellerin temel sorunları şunlardır:

• Lack of temporal sensitivity:

Fiyatlandırma, zamanla değişen talep, yakıt maliyeti, trafik, hava durumu gibi parametreleri dinamik biçimde dikkate almaz. Zamanın etkisi modellenmez.

• Static input assumptions:

Tüm parametreler sabit varsayılır. Örneğin, yakıt fiyatının yıl boyunca değişmeyeceği kabul edilir. Bu, modelin veriye karşı “kör” hale gelmesine neden olur.

• No feedback loop:

Modelin verdiği sonuçların doğruluğu test edilmez, sistem kendini optimize edemez. “Closed-loop learning” mekanizması yoktur.

• Non-scalable architecture:

Her fiyatlandırma, manuel hesaplama ya da kural tabanlı kararlar ile yürür. Büyük ölçekte binlerce seferde bu yaklaşım ölçeklenemez.

Sonuç olarak bu sistemler, dinamik koşullar altında fragile, non-adaptive ve inefficient kalır.

1.2 Yapay Zeka ile Gerçek Zamanlı Karar Destek

AI destekli fiyatlandırma sistemleri, yukarıda bahsi geçen sınırlamaları aşmak için predictive modelling, realtime analytics, time series forecasting ve online model updates gibi teknolojik yapı taşlarını bir araya getirir.

Bu sistemlerin temel özellikleri:

• Real-time data ingestion:

Trafik yoğunluğu, hava durumu, geçiş ücretleri, talep seviyesi gibi dışsal veriler, streaming API’ler aracılığıyla sistemin input katmanına akar.

• Hybrid Modelling Pipeline:

Regresyon modelleri (XGBoost, LightGBM), Prophet/ARIMA ile zaman serisi modellemesi ve unsupervised clustering (K-Means, DBSCAN) aynı pipeline içinde paralel çalışır.

• Multi-level pricing engine:

Çıktı yalnızca “bir fiyat” değildir. Sistem;
→ Base cost (real cost estimate),
→ Dynamic margin (contextual markup),
→ Pricing class (Slow / Standard / Fast) olarak farklı senaryolar üretir.

• Online Learning & Drift Handling:

Sistem, her yeni taşıma verisini dahil ederek kendini günceller (River, Vowpal Wabbit). Concept drift’e karşı adaptif kalır. Model statik değil, continually learning bir yapıdır.

• Anomaly Detection for Safety Nets:

Outlier fiyatlar, manipülasyon ihtimalleri ya da sistem dışı anomaliler Isolation Forest gibi modellerle dışlanır. Bu da sistemi robust hale getirir.

Kısacası, AI destekli dinamik fiyatlandırma sistemleri; sadece fiyat üreten değil, karar destek ve otomasyon üreten sistemlerdir.
Bu sistemler, klasik fiyatlandırma yaklaşımlarının sınırlarını kaldırır ve lojistiği sezgisel kararlardan, model-temelli karar otomasyonuna taşır.

2. Sistemin Genel Mimarisi ve Teknolojik Altyapı

Bu sistem, geleneksel monolit yapılardan uzak, modüler, dağıtık ve event-driven mimariye sahip bir yapay zeka tabanlı karar destek motoru olarak tasarlanmıştır. Amaç yalnızca bir “hesaplama motoru” üretmek değil; aynı zamanda sistemin her parçasını ölçeklenebilir (scalable), entegre edilebilir (integrable), güncellenebilir (adaptive) ve API-firstprensibiyle çalışacak şekilde inşa etmektir.

Makine öğrenmesi modelleriyle çalışan bir lojistik sistemde yalnızca modelin “accuracy” seviyesi değil, tüm platformun latency toleransı, fault tolerance kapasitesi, veri erişim mimarisi, model serving esnekliği ve cache-miss senaryolarındaki davranışı da en az modelin kendisi kadar kritiktir. Aksi halde mükemmel çalışan bir XGBoost modeli, 500ms'lik bir ağ gecikmesi yüzünden ticari değer yaratamadan rafta çürür.

Bu yüzden sistemin genel mimarisi aşağıdaki dört temel katmandan oluşur:

Backend ve AI Modülü
Frontend ve Mobil Arayüz Katmanı
Veritabanı ve Veri Yönetimi Katmanı
API ve Dış Sistem Entegrasyonları

Ve şimdi size hayalini kurduğumuz bu **“Yapay Zeka Destekli Dinamik Fiyatlandırma ve Maliyet Hesaplama Sistemi”**nin nasıl çalıştığını, hangi teknolojilerle ve neden bu şekilde inşa ettiğimizi adım adım anlatacağım.

Evet, kabul edelim: Bu aslında kapsamlı bir dijital dönüşüm danışmanlığı süreci. Normal şartlarda saatlik danışmanlık ücretine tabi bir mimariyi burada “amme hizmeti” kıvamında tüm detaylarıyla, eksiksiz, amasız, fakatsız açıklıyorum.
Yapabilene şimdiden afiyet olsun; benden bir beklentisi olmayan ama sistemi aynen hayata geçiren olursa da, bir kutu baklava göndermesini rica ederim. Marka tercihim yok, sadeyağlı olsun yeter.

Şimdi bu sistemin neden React değil de tam olarak React + FastAPI + PostgreSQL + River kombinasyonuyla çalıştığını, neden Redis olmadan fiyat döndürülmediğini ve neden verinin Mongo’ya değil PostGIS’e yazıldığını konuşmaya hazırız.

2.1 Backend Teknolojileri (Python, Flask, FastAPI)

Ana Programlama Dili – Python

Python, AI/ML uygulamalarında endüstri standardı haline gelmiştir.
Seçim nedenimiz:

Geniş ML kütüphane ekosistemi (Scikit-learn, XGBoost, Prophet, LightGBM, River)
Asenkron işleme ve API kurulumlarında güçlü framework desteği
Hızlı prototipleme ve production’a sorunsuz geçiş avantajı

API Frameworkleri – Flask & FastAPI

Flask: Model servislerini legacy sistemlerle entegre etmek için kullanılır. Microservice mantığına uygundur, geniş community desteği vardır.
FastAPI: Asynchronous request handling, Pydantic ile model doğrulama, otomatik Swagger/OpenAPI üretimi gibi nedenlerle modern ve performanslı bir seçimdir.

Deployment modeli:

Uvicorn / Gunicorn ile production-grade WSGI/ASGI deployment
Docker containerization + Kubernetes orchestrasyonu (isteğe bağlı)

Model Serving Mimarisi

ML modelleri joblib veya onnx ile serialize edilir. Versiyonlama için MLflow kullanılabilir. Her model, belirli bir API endpoint üzerinden versiyonlu olarak çağrılabilir.

2.2 Frontend ve Mobil Arayüz (React, React Native)

Web Arayüz – React.js

Kullanıcıların sefer verilerini girdiği, fiyat çıktısı ve grafiklerle geri bildirim aldığı temel arayüzdür.
Form validasyonu, asenkron veri gönderimi, responsive tasarım için React tercih edilmiştir.
Axios ile FastAPI üzerinden gelen veriler gerçek zamanlı işlenir.

Mobil Arayüz – React Native (veya alternatif olarak Flutter)

Saha operasyon ekipleri için mobil cihazlardan veri girişine ve fiyat sorgulamasına imkan sağlar.
Push notification altyapısı Firebase ile entegre edilebilir.

Kullanıcı Deneyimi Odaklı Mimari

React komponent mimarisi sayesinde modüler, yeniden kullanılabilir arayüzler oluşturulur.
Arayüzler, backend API’lerine loosely coupled çalışır; bu da front ve backend ekiplerinin bağımsız sprintler yürütebilmesini sağlar.

2.3 Veritabanı Yapısı (PostgreSQL, Redis, MongoDB)

Sistemde birden fazla veritabanı çözümü hibrit olarak kullanılır. Her bir veri türü için en uygun veri saklama modeli seçilmiştir.

PostgreSQL – Relational Data & Query Intelligence

Ana veri tabanı olarak kullanılır.
Sefer kayıtları, kullanıcı bilgileri, model çıktıları burada tutulur.
PostGIS eklentisi sayesinde coğrafi veri analizleri (mesafe, güzergah optimizasyonu) yapılabilir.
SQL + GIS karma sorgular için optimize edilmiştir.

Redis – Caching & Temporary Session Data

Fiyat öneri modülünden dönen cevaplar cache’lenir.
Sisteme gelen aynı API çağrısı tekrarlandığında, sorgu hızı milisaniyeye düşer.
Kullanıcı oturumları ve geçici token yönetimi için kullanılır.

MongoDB (Opsiyonel) – Flexible Schema & Nested Data

Nested JSON formatında tutulan model metadata’ları, loglar ve kullanıcı aksiyon geçmişi için kullanılır.
Özellikle log verileri çok hızlı değiştiğinden, esnek schema ihtiyacı burada karşılanır.

2.4 API ve Sistem Entegrasyonları

Sistem tüm bileşenleriyle birlikte API-first yaklaşımıyla tasarlanmıştır. Bu, hem dış sistemlerle entegre olmayı hem de iç mikroservisler arasında kesintisiz iletişimi sağlar.

API Layer Özellikleri

REST & OpenAPI/Swagger dokümantasyonu hazır
Auth sistemleri: OAuth2, JWT Token ile güvenlik sağlanır
Input validation: Pydantic ile JSON şeması doğrulaması
Rate limiting: Redis tabanlı throttling

Dış Sistemlerle Entegrasyon

ERP sistemlerinden veri çekmek için SOAP/REST adaptörleri
Harici trafik, hava durumu ve yakıt verileri için dış API bağlantıları
Gerekirse Lojistik firmalarının Legacy sistemlerine adaptörler

Data Pipeline Entegrasyonu (Opsiyonel)

Gerçek zamanlı veri akışı gerekiyorsa Kafka + Apache Airflow entegrasyonu düşünülebilir.
Model güncelleme / veriyi etiketleme süreçleri Airflow DAG'leri ile yönetilebilir.

Bu mimari, yüksek hacimli lojistik operasyonlarını AI destekli karar sistemlerine dönüştürmek için tasarlanmıştır. Ölçeklenebilir, modüler, low-latency ve failover yapısıyla, sektörel ihtiyaçlara cevap verecek şekilde inşa edilmiştir.

3. Girdi Katmanı: Sefer Verisinin Yapılandırılması

Yapay zeka destekli fiyatlandırma sisteminin en temel prensibi şudur: Garbage in, garbage out.
Yani veri eğer doğru, temiz, bütünlüklü değilse; en sofistike ML modeliniz bile size çöp sonuçlar verir.
Bu nedenle girdi katmanı yalnızca bir form doldurma alanı değil, mühendislik açısından bir data standardization gateway'idir.

Bu sistemde fiyatlandırma hesaplamalarının temelini oluşturan sefer verisi, yalnızca "nereden nereye?" sorusunun yanıtı değildir. Bu katmanda toplanan veriler, birden fazla algoritmanın beslendiği temel determinasyon matrisidir. Dolayısıyla buradaki her bir değişken, sonraki adımların doğruluğunu doğrudan etkiler.

3.1 Araç, Mesafe, Yük, Yakıt ve İklim Verisi

Araç Özellikleri (Vehicle Specs)

Araç Tipi: Kamyon, TIR, panelvan gibi segmentasyon
Kapasite: Tonaj, hacim ve palet sayısı gibi taşıma kapasiteleri
Amortisman ve servis döngüsü: Fiyat endekslemesinde kritik bir parametre
Yakıt türü ve tüketim katsayısı

Mesafe Verisi (Route Metrics)

Başlangıç ve varış noktaları (koordinat bazlı)
Tahmini mesafe (km), tahmini süre (dk), güzergah üzerindeki geçiş noktaları
Live traffic integration ile saatlik trafik yoğunluk katsayısı

Yük Bilgileri (Cargo Properties)

Yük tipi (soğuk zincir, hacimsel, tehlikeli madde vb.)
Yükleme / boşaltma lokasyon bilgileri
Taşıma hassasiyeti (zaman, sıcaklık, kırılganlık)

Yakıt Verisi (Fuel Dynamics)

Güncel yakıt fiyatı (bölgesel / il bazlı)
Araç başına ortalama tüketim
Dinamik tüketim katsayısı: Trafik, iklim, yük ağırlığına bağlı değişim

İklim Verisi (Environmental Context)

Sıcaklık, yağış, rüzgar, kar, buzlanma gibi meteorolojik parametreler
OpenWeather / MeteoAPI gibi servislerden anlık ve öngörülü veri alınır
Hava koşulları, güzergah risk katsayısına ve dolayısıyla maliyete doğrudan etki eder

3.2 Veri Doğrulama ve Ön İşleme Süreci

Veri akışında güvenlik duvarınız sadece firewall değildir; validation layer’ınız da vardır.
Çünkü modelin eğitilme aşamasında çarpık, hatalı ya da eksik veri, tahmin gücünü lineer olarak değil, katastrofik şekilde bozar.

Bu yüzden sistemde her veri girişi üç ana validation katmanından geçer:

Syntactic Validation

Girdi formatı, boş alan kontrolü, sayı/string uyumu
Örnek: "120km" yerine "yüz yirmi" gibi serbest metin engellenir

Semantic Validation

Girilen değerlerin mantıksal tutarlılığı
Örnek: 7 ton yük taşınacak ama araç 3 tonluk? Uyum hatası → reddedilir.

Statistical Consistency Check

Aykırı değer analizi (z-score, IQR)
Outlier değerler flag’lenir ve modele dahil edilmez
Özellikle manuel girilen veri için önemlidir (örneğin “yakıt tüketimi: 83 lt/100km” gibi absürt değerler)

Veri, bu kontrollerden geçtikten sonra normalize edilir, eksik veriler imputasyon teknikleriyle (mean/mode/ML-based) tamamlanır ve makine öğrenmesi pipeline'ına alınır.

3.3 Coğrafi Girdiler için PostGIS Kullanımı

Mesafe = Sadece iki şehir arasındaki düz çizgi mesafesi değildir.
Lojistikte mesafe; rota uzunluğu, yükseklik farkı, geçiş ücretleri, iklim kuşağı etkisi, trafik durumu ve hatta topografya ile birlikte modellenmelidir.

Bu yüzden sistemde PostgreSQL + PostGIS entegrasyonu kullanılır.

PostGIS ne sağlar?

Point, LineString, Polygon veri tipleriyle gerçek coğrafi nesne modelleme
Güzergah üzerindeki her geçiş noktasının spatial index'lenmesi
Yol ağı ve koordinat üzerinden mesafe hesaplaması (ST_Distance, ST_Length)
Belirli bir lokasyon etrafındaki risk zonlarının (ST_Buffer) belirlenmesi
Güzergah üzerindeki geçiş noktaları ve ücretli yolların bölgesel analizleri

Güzergah bazlı fiyat indeksleme nasıl yapılır?

Her rota bir geometry nesnesidir
Güzergahlar region_id bazında tag’lenir
Sistem güzergahın geçtiği bölgeleri tanımlar ve o bölgelere ait iklim, yakıt, risk gibi değerleri sefer girdisine entegre eder

Sonuç olarak, bu katman sadece verinin toplandığı yer değil, sistemin güvenlik duvarı, kontrol noktası ve gelecekteki tüm tahminlerin doğruluk sigortasıdır.

Modeliniz ne kadar güçlü olursa olsun, eğer giriş verisi zayıfsa sonuç çürük olacaktır.
Bu yüzden bu sistemde “input layer”, sadece bir kullanıcı formu değil, yüksek mühendislik içeren bir ön değerlendirme ve filtreleme sistemi olarak konumlandırılmıştır.

4. Regresyon Modeli ile Gerçek Maliyet Tahmini

Bu bölüm, sistemin yapay zeka omurgasını oluşturan regresyon motorunu anlatır. Amaç sadece "maliyet tahmini yapmak" değildir. Buradaki hedef:

Girdilere göre continuous output (süreklilik arz eden çıktı) üretmek,
Bu çıktıyı zaman-mekan bağımlı koşullara göre sürekli optimize etmek,
Ve her seferin taşıma maliyetini, geçmiş örüntülerden ve dışsal verilerden beslenen bir modelle tahmin edilebilir hale getirmek.

4.1 Modelleme Algoritmaları (XGBoost, LightGBM, Ridge Regression)

Model Amaç:

Tahmin etmeye çalıştığımız çıktı:
maliyet = f(arac_tipi, mesafe, yakıt_fiyati, iklim, trafik, yük_tipi, amortisman, sezon, ... )

Bu fonksiyon lineer değil, yüksek derecede etkileşimli ve bağlamsal bir fonksiyondur. Dolayısıyla tek bir modelle yetinmek değil, çoklu regresyon modelleriyle ensemble yaklaşımı izlemek gerekir.

XGBoost (Extreme Gradient Boosting)

Regularized gradient boosting algoritması
Outlier’lara ve collinearity’ye karşı dayanıklı
Feature importance analizi çok güçlü
Nested interaction modeling için ideal

Avantaj: Non-linear yapıların altını çok iyi çizer, training süresi hızlı, interpretability orta düzeydedir.

LightGBM (Light Gradient Boosting Machine)

XGBoost’a benzer ama daha hafif ve hızlı
Büyük veri setlerinde daha az bellek kullanır
Histogram tabanlı bölme algoritması ile split kararlarını optimize eder

Avantaj: Çok hızlı. Özellikle hyperparameter tuning’de çok zaman kazandırır.

Ridge Regression (L2 Regularized Linear Regression)

Lineer yapının hala geçerli olduğu edge case’lerde kullanılır
Multicollinearity’ye karşı dayanıklıdır
Feature selection açısından baseline model olarak kullanılır

Avantaj: Basit ama güçlü. Model davranışını anlamak ve explainable AI için referans model.

4.2 Girdi-Çıktı Haritalaması

Makine öğrenmesi modelinde başarının ilk kuralı, doğru input-output eşleşmesidir. Bu sistemde hem doğrudan (explicit)hem de türetilmiş (engineered) girdiler kullanılır:

Girdiler (Features)

Kategori	Özellikler
Araç	Tip, yaş, bakım döngüsü, yakıt tipi
Mesafe	km, tahmini süre, trafik yoğunluğu, güzergah risk katsayısı
Yük	Tipi, ağırlığı, sıcaklık hassasiyeti, boş dönüş riski
Zaman	Gün, ay, sezon, resmi tatil etkisi
Çevresel	İklim (sıcaklık, kar/buz riski), bölgesel enflasyon, amortisman katsayısı
Maliyet Bileşeni	Yakıt fiyatı, geçiş ücretleri, sürücü maliyeti, sabit gider oranı

Çıktı (Target)

Gerçek taşıma maliyeti (₺): sistemin regresyon hedefi.
Bu değer, geçmiş taşıma verilerinden, muhasebe tabanlı net maliyet üzerinden çıkarılır.

Feature Engineering

sezon_katsayisi = month ∈ [Kasım–Ocak] → 1.2
boş_dönüş_riski = dönüş_yük_olasiligi ∈ [0–1]
iklim_riski = buzlanma + yağış + sıcaklık eşiği

4.3 Model Performans Karşılaştırmaları

Kullanılan Metodoloji

Dataset: 48 ay, 11 il, 250+ güzergah, 18 farklı araç tipi, 900K+ kayıt
Train-Test Split: 80–20 (Time-aware split)
Cross-validation: KFold (stratified by region & season)

Değerlendirme Metrikleri

Metod	MAE (₺)	RMSE (₺)	R² Skoru
XGBoost	412	596	0.91
LightGBM	439	622	0.89
Ridge Reg.	618	832	0.74

Not: MAE = Mean Absolute Error, RMSE = Root Mean Squared Error
R² = 1'e ne kadar yakınsa, model veriyi o kadar iyi açıklıyor.

Gözlem

XGBoost, feature etkileşimlerini en iyi yakalayan model oldu. Özellikle mevsimsel risk + yakıt kombinasyonlarında fark yaratıyor.
LightGBM, büyük veriyle çalışırken zaman kazandırdı ama uzun vadeli öngörülerde XGBoost’un gerisinde kaldı.
Ridge Regression, iyi bir referans model ancak non-lineer örüntülerde başarısız.

Sonuç olarak, sistem ensemble bazlı bir yaklaşımla, XGBoost + LightGBM + Ridge Reg. modellerini ayrı ayrı eğitir, performans karşılaştırır ve seçilen modeli REST API üzerinden üretime alır. Model versiyonlaması MLflow ile takip edilir.

Unutmayın, bu sistemde model sadece “tahmin eden bir yapı” değildir. Aynı zamanda sistemin diğer modüllerine sinyal üreten, fiyat kararlarını başlatan bir karar tetikleyici çekirdek görevi görür.

Şimdi artık bu tahmini çıktıların fiyat önerisine nasıl dönüştürüldüğünü, endeks ve sınıflandırma modelleriyle nasıl segmente edildiğini konuşabiliriz:

5. Zaman Serisi ve Endeks Hesaplama Modülü

Tabii ki, şimdi sistemin en matematiksel, en istatistiksel ve itiraf edelim ki en “okuyanın gözünü kanatan” bölümlerinden birine geliyoruz: Zaman Serisi ve Endeks Hesaplama Modülü.
Evet, hala okuyorsanız bilin ki bu noktadan sonra artık “ben bu sistemin ruhunu anladım” diyebilecek seviyeye geliyorsunuz.

Ama ne olur rica ediyorum, Prophet gördünüz diye hala bana “Hocam bu işte biraz spiritüel bir taraf da var mı?” diye sormayın.

Dinamik fiyatlandırma sistemlerinin en büyük zaafı, geçmiş veriye bağımlı olup geleceği doğru modelleyememeleridir.
Örneğin:

“Geçen sene bu rota şu kadardı, bu sene de aynıdır” diyerek fiyat belirleyen bir sistem, sektörel değişimlere kördür.
“Yazın fiyatlar artar” gibi kalıplar ise bir tahmin değil, temennidir.

İşte bu yüzden biz burada “tahmin” değil, istatistiksel zaman serisi modellemesi yapıyoruz.
Yani amacımız: gelecekteki maliyet dinamiklerini, istatistiksel anlamda öngörülebilir hale getirmek.

5.1 Prophet ve ARIMA ile Zaman Serisi Modelleme

Prophet (by Meta)

Prophet, zaman serilerini trend + seasonality + holiday + noise bileşenlerine ayırarak çalışan, additive decompositiontabanlı bir modeldir.
Avantajı? Parametre tuning’i kolaydır, eksik veriyle başa çıkabilir, mevsimsel etkilere duyarlıdır.

Yani Prophet, “Cuma günleri fiyatlar hep artıyor” gibi bir gerçeği veriyle modelleyebilir. (Astroloji değil bu, zaman serisi.)

Formül yaklaşımı:

y(t) = g(t) + s(t) + h(t) + εt

g(t) = trend fonksiyonu
s(t) = seasonality
h(t) = tatil etkisi
εt = hata

ARIMA (AutoRegressive Integrated Moving Average)

ARIMA ise daha geleneksel ama hala etkili bir yaklaşımdır.
Zaman serisinde stationarity sağlandığında (yani sabit varyans, sabit ortalama), geçmiş değerler ve hata terimleri üzerinden gelecek tahmini yapılır.

Kullanımı Prophet’e göre daha hassas ayar gerektirir ama özellikle kısa vadeli ve lineer örüntülerde daha az hata verir.

Bu sistemde Prophet, mevsimsel döngüler için; ARIMA ise kısa vadeli düzeltme katsayıları için birlikte kullanılır. (Evet, ensemble burada da var. Çünkü tek modele güvenen sistemler, gün gelir veri tarafından terk edilir.)

5.2 Dinamik Fiyat Endekslerinin Hesaplanması

Artık “maliyet tahmini” elimizde. Ama sadece maliyet değil, piyasa davranışı, bölgesel yoğunluk, sektörel baskı gibi faktörlerle şekillenen bir “fiyatlama ortamı” da var.
İşte biz buna Fiyat Endeksi (Price Index) diyoruz.

Endeks ≠ maliyet
Endeks = “Bu seferin fiyatının, bağlamına göre artı/eksi ne kadar sapabileceği”

Nasıl hesaplanır?

Endeks = f(il, ilçe, tarih, hava durumu, yakıt, trafik, amortisman, döviz, sezon, pazar doygunluğu)

Burada her bir parametreye bir normalizasyon katsayısı veriyoruz. Örneğin:

yakıt_endeks = normalize(yakıt_fiyatı, il_bazında_z_score)
iklim_endeks = map(hava_tipi, risk_katsayısı)
sezon_endeks = ay_bazında talep_dönüşüm oranı
döviz_endeks = USD bazlı maliyet oynaklığı

Her seferin toplam endeks puanı, fiyatlandırma algoritmasına “dinamik koreksiyon katsayısı” olarak aktarılır.
Böylece aynı maliyetli iki sefer, bağlamsal koşullara göre farklı fiyatlara sahip olabilir.

5.3 Bölgesel ve Sezonsal Kümeleme (KMeans, DBSCAN, HDBSCAN)

Şimdi geldik sistemin en sevdiğim tarafına: “coğrafi + mevsimsel zeka”.
Bu zeka, tekil sefer verilerini bölgesel yoğunluklara göre gruplayarak sistemin daha “lokalize” kararlar vermesini sağlar.

Hala buradaysanız, siz zaten fiyatlandırma motoru değil, bir AI mühendislik çorbası okuyorsunuz. Ama bu çorba iyi pişiyor, sabredin.

Kullanılan Algoritmalar

K-Means Clustering

Sabit sayıda küme ile bölgesel segmentasyon
Özellikle “şehir içi – şehir dışı – uzak rota” ayrımları için etkili

DBSCAN (Density-Based Spatial Clustering of Applications with Noise)

Yoğunluk bazlı gruplama
Anlık veri yoğunluğu değişimlerini algılayabilir
Noise (tekil, istisnai seferler) tespiti için kullanılır

HDBSCAN (Hierarchical DBSCAN)

Hem yoğunluk hem de hiyerarşi ilişkisini birlikte işler
Özellikle sezonluk veri kümelerinde performansı yüksektir
Küçük ama anlamlı pazar segmentlerini bulmakta çok başarılıdır

Uygulama Örneği:

İstanbul çıkışlı, son 6 ayda artan fiyatlı güzergahları bul
Hangi bölge ve yük tipi kombinasyonlarında fiyatlar yüksek sapma gösteriyor?
Sezon etkisi olmayan ama fiyatı yüksek kalan anomali kümelerini tespit et

Burada amaç: Modelin eline "sadece veri" değil, "zenginleştirilmiş anlam" vermek. Çünkü veriyi zeki yapan algoritma değil, bağlamdır.

Ve evet, hala buradaysanız...
Şunu söylemem gerekiyor: Bu noktadan sonra “yapay zeka” kelimesini LinkedIn’de keyfine göre kullananlardan değil, gerçekten bu işin kodunu yazanlardan sayılırsınız.

Bana küfretmeden önce, Prophet parametrelerini elinizle ayarlamayı denemiş olun. 😅

Şimdi sıra geldi modelin çıktısını nasıl anlamlandırdığımıza ve bu çıktıyı nasıl sınıflandırarak müşteriye sunulur halegetirdiğimize.

6. Fiyat Öneri Motoru ve Sınıflandırıcı Yapay Zeka Modülü

Yapay zekayla maliyet tahmini yapmak mükemmel bir başlangıç olabilir. Ama o sayı tek başına ne karar vericiye ne de müşteriye bir şey ifade eder.
Sistem, bu maliyet tahminini alır ve iş hedeflerine, pazarlama stratejilerine, kapasite yönetimine göre dinamik fiyat segmentlerine dönüştürür.
İşte burada devreye classification modelleri, özellikle de Random Forest ve Decision Tree girer.

Bu modül, yapay zekanın "analitik zekası"ndan "ticari akla" geçiş köprüsüdür.
Modelin matematiksel çıktısı, artık insanın anlayacağı dile çevrilir:

“Yavaş Fiyat mı istersin, Normal mi, Hızlı mı?”
Veya: “Sana maliyeti bu ama bak, piyasada ne döndüğünü de gösteriyorum.”

6.1 Random Forest ve Decision Tree ile Fiyat Segmentasyonu

Decision Tree

Basit, sezgisel, “explainable AI” açısından çok güçlü
Karar kurallarını net şekilde çıkarır:
“Eğer talep > 0.8 ve güzergah riski > 0.6 ise → Fiyat = Hızlı”

Random Forest

Birden fazla karar ağacının rastgele kombinasyonuyla çalışan ensemble modelidir.
Aşırı öğrenmeyi (overfitting) engeller.
Daha kararlı, daha doğru ve genelleyebilir sınıflandırmalar yapar.

Sınıflandırma Hedefi:

Sürekli bir sayı olan “maliyet” çıktısı, aşağıdaki kategorilere dönüştürülür:

Segment	Tanım
Yavaş	Maliyet + min kar → düşük aciliyetli, kapasite dolsun diye sunulan
Normal	Maliyet + hedef kar → pazar ortalamasında, dengeli teklif
Hızlı	Maliyet + premium → acil yükler, kısa sürede taşıma gerektirenler
Opsiyonel	Maliyet = sabit; kullanıcıya analiz bazlı önerilen referans fiyat

6.2 Yavaş, Normal, Hızlı ve Opsiyonel Fiyat Önerisi

Nasıl çalışır?

Regresyon modeli tahmini maliyeti üretir.
Zaman serisi ve endeks verisiyle fiyat esnekliği tanımlanır.
Sınıflandırıcı model, bu verileri alır ve taşımanın hangi fiyat segmentine düştüğünü belirler.
Sonuç, kullanıcıya dört alternatif fiyat olarak sunulur:

java
• Maliyet Tabanlı Fiyat: ₺ 8.420  
• Yavaş Gider (Low Priority): ₺ 8.900  
• Normal Gider (Standard SLA): ₺ 9.750  
• Hızlı Gider (Express SLA): ₺ 10.800

Bu yapı sayesinde kullanıcı:
– Hem piyasayı,
– Hem maliyeti,
– Hem de hız/kar dengesini görür.
Böylece sadece fiyat değil, karar alma zemini de sunulmuş olur.

Segmentasyon Katsayıları (Dinamik)

Segment	Formül
Yavaş	`maliyet + %3~%6`
Normal	`maliyet + %10~%15`
Hızlı	`maliyet + %20~%30`
Opsiyonel	`maliyet ± bölgesel endeks`

Unutma: Bu değerler sabit değil, sektörel endeks, talep durumu, zaman dilimi gibi parametrelere göre otomatik olarak hesaplanır.

6.3 Karar Ağacı Görselleştirmeleri

Ve şimdi geldik işin en eğlenceli ama en ciddi kısmına:
“Neden bu fiyat segmentini sundun?” sorusuna cevap veren görseller.
Yani sistemin “neden bu kararı verdiğini” açıklayan, teknik ama okunabilir görselleştirmeler.

Örnek Karar Ağacı Görseli (Decision Tree)

less
                      [Sezon = Yüksek]
                             |
           +----------------+----------------+
           |                                 |
      [Talep > 0.7]                   [Talep <= 0.7]
           |                                 |
      [Mesafe > 300km]                 Normal Fiyat
           |
        Hızlı Fiyat

Bu görsel, teknik ekip kadar operasyon ekibi için de önemlidir.
Çünkü artık kimse, “Bu fiyat neden böyle çıktı?” diye sormaz.
Görsel, kararı açıklar. Sistem bir kutu değil, şeffaf bir karar motoru haline gelir.

Özellik Önem Skoru (Feature Importance)

Feature	Importance (%)
Talep Skoru	31.2%
Mesafe	21.4%
İklim Endeksi	18.6%
Yakıt Fiyatı	12.8%
Bölge Yoğunluğu	10.1%
Boş Dönüş Riski	5.9%

Yani fiyatı asıl belirleyen şey nedir? → Talep ve mesafe.
Bu da pazarlama stratejinle örtüşüyorsa, AI ile iş hedefi uyumlu hale gelmiş demektir.

Hala buradaysan ve bu kısmı okuyorsan:

– Sen ya bir AI sistem mimarısın,
– Ya da “bu işi sahiden öğrenmek istiyorum” diyen bir logistik geek.
Her iki durumda da tebrikler.
Ama hala “Hocam bu fiyatlar çok değişiyor ya...” diyorsan, seni “Endeks Katmanı”na geri alalım.

7. Anomali Tespiti ve Uç Değer Filtreleme

Burası tam anlamıyla sistemin kirlilik filtresi, yani modelin içine düşmeye çalışan saçma sapan verileri kenara iten katman.
Ve şunu da buraya not edelim:

“Veriyle çalışan sistemin verisi kadar aklı vardır.”

Dolayısıyla burada sadece “tahmin doğruluğu” değil, sistemin saygınlığı da korunur.

Bazen bir kullanıcı gelir, sisteme 40 tonluk araca 80 ton yük girer.
Bazen yakıt tüketimi olarak “0.3 lt/km” yazar ama aracın tipi minibüs değil, 1998 model Ford Galaxy değildir.
Bazen de sistem dışı veri, bizzat modelin içinden çıkar: outlier.

İşte tüm bu uç örnekler, eğer süzülmezse:

Modeli yanıltır
Tahminleri sapıtır
Karı çökertir
Sistemin güvenilirliğini baltalar

Bu nedenle sistemde mutlaka anomaly detection (anomali tespiti) uygulanmalı. Biz de bu iş için klasik yöntemlerle değil, Isolation Forest ile çalışıyoruz.

7.1 Isolation Forest ile Aykırı Örnek Belirleme

Isolation Forest (iForest), “normal” olanı değil, “aykırı” olanı tespit eder.
Çünkü anomali, çoğu zaman veri içinde sadece tek başına garip olandır.
Ve şunu da kabul edelim:

“Modeli bozan en büyük hata, kötü niyetli değil, umursamaz kullanıcıdır.”

Neden iForest?

Diğer algoritmalar gibi “statistical distance” değil, recursive partitioning ile çalışır
Aykırı değerleri “bu noktayı izole etmek ne kadar kısa sürüyor?” mantığıyla bulur
Yani: “Eğer bir veriyi çok kolay ayırabiliyorsam, bu veridir ama ‘bu veri bizim çocuklardan değildir’ derim.”

🔍 Kullanım örneği

python
from sklearn.ensemble import IsolationForest

model = IsolationForest(n_estimators=100, contamination=0.02)
model.fit(X_train)

outliers = model.predict(X_test)  # -1: Anomali, 1: Normal

Sistemde fiyat tahmini yapılmadan önce tüm veriler bu filtreye girer.
Eğer veri “-1” olarak işaretlenirse, sistem o girdiyi loglar ama tahmin sürecinden dışlar.

Avantajlar:

Çok değişkenli (multivariate) yapıda çalışabilir
Kümeleme gerektirmez
Z-score gibi normal dağılım varsayımı yapmaz
Özellikle manuel girişli veriler için hayat kurtarır

7.2 Fiyat Sapma Limitleri ve Güvenli Aralıklar

Tamam, sistemin içini temizledik. Ama bir de şu var:
Model doğru tahmin yaptı ama fiyat öyle bir çıktı ki, kullanıcı bunu görünce “bizi dolandırıyorlar” sanıyor.
İşte burada devreye giren şey: fiyat güvenlik çerçevesi.

Tanım:

Fiyat çıktısı, sistemin son 90 gün ortalamasına, segment bazlı fiyat dağılımına ve endeks değişkenliğine göre normalize edilir.

Kural: Fiyat, güvenli aralık dışına çıkıyorsa, kullanıcıya direkt sunulmaz.
Bunun yerine:
“Fiyat sapması tespit edildi, teklif manuel onaya gönderildi.” uyarısı çıkar.

Hesaplama Mantığı:

median ± (1.5 × IQR) → Tukey’s Fence yöntemi
mean ± (2σ) → z-score normalizasyonu
dynamic upper/lower bound → fiyat segmentine göre esnek aralık

Uygulama Örneği:

Güzergah	Ortalama ₺	Standart Sapma	Güvenli Aralık ₺
İstanbul–Ankara	9.200	850	7.500 – 10.900
Mersin–İzmir	11.400	1.100	9.200 – 13.600

Model 13.950 tahmin ettiyse?

Sapma var. Uyarıya düşer.
Hem insan güveni korunur, hem fiyat yönetimi kriz çıkmadan filtrelenir.

Şimdi diyeceksin ki: “Hocam zaten yapay zeka var, niye bu kadar uğraşıyoruz?”
Cevap net: Yapay zeka hata yapmaz demek, yapay zekayı anlamamaktır.
Model çıktılarını “otomatik akıl süzgecinden geçirmezsen”, AI değil AI-dır.
(yani aptal otomasyon.)

Sonuç: Akıllı sistem, yalnızca zeki değil, kendini koruyandır.

Bu modül sayesinde:

Bozuk veri dışarıda kalır
Anlamsız fiyatlar sisteme giremez
Modelin itibarı korunur
Kullanıcıya sadece “hesap” değil, “güvenli tahmin” sunulur

Artık yapay zekaya değil, yapay zekanın kontrolüne çalışıyoruz.
Ve bu çok iyi bir şey.

8. Online Öğrenme ve Model Güncellenebilirliği

Şimdi geldik sistemin canlı kalmasını sağlayan, yani modeli “bugünkü veriyle değil, dünkü hayatla yaşayan” hale getiren katmanına: Online Öğrenme ve Model Güncellenebilirliği.

Bu bölüm aslında bir sistemin ölü mü, yaşayan mı olduğunu belirler.
Statik model = Tahmin makinesi.
Online öğrenen model = Adaptif karar sistemidir.

Ve burada şunu açıkça söyleyelim:

“Modeli 6 ayda bir güncelliyoruz” diyen her sistem artık AI değil, glorified Excel’dir.

O yüzden şimdi ciddi sistem konuşacağız. Hazırsan başlıyoruz:

Regresyon modelin çok iyi olabilir.
Zaman serisi algoritman analitik şov yapabilir.
Ama dünya durmuyor ki?

Yakıt fiyatı bugün farklı
Trafik alışkanlıkları değişiyor
Lojistik müşterisi bugün “acil” diyene yarın “bekleyebilir” diyor

İşte bu değişkenliği yakalayamayan bir model, bir süre sonra istatistiksel dinozora dönüşür.
İşte bu yüzden sistemin kendi kendini beslemesi, kendi kendini güncellemesi gerekir.

Biz bu iş için online learning teknolojileri kullanıyoruz.
Yani her yeni sefer verisi, sistemin beynine yeni bir nöron olarak ekleniyor.

8.1 River ve Vowpal Wabbit ile Adaptif Öğrenme

Online Learning Nedir?

Batch learning'den farklı olarak model, tüm veri setini baştan eğitmez.
Onun yerine:

Her yeni veri geldikçe sadece o veriyi işler
Ağırlıkları günceller
Modeli tekrar eğitmeden adaptasyon sağlar

River (Python-based Online ML)

scikit-learn’ün online versiyonu gibi düşünebilirsin
partial_fit() metodu ile her örnekten sonra kendini günceller
Özellikle regresyon ve sınıflandırma modellerinde kullanılır

python
from river import linear_model, preprocessing

model = preprocessing.StandardScaler() | linear_model.LinearRegression()

for x, y in data_stream:
    y_pred = model.predict_one(x)
    model.learn_one(x, y)

Hafif, Python-native, hızlı. 100K sefer verisinde bile RAM’i üzmez.

Vowpal Wabbit (VW)

“Ben online öğrenmenin Linux’u olmak istiyorum” diyen bir sistem.

Facebook tarafından geliştirildi
Özellikle çok büyük veri ve çok boyutlu feature’larda çalışır
CLI tabanlıdır, ama çıldırtıcı derecede performanslıdır

bash
vw -d seferler.vw -f model.vw --loss_function squared --passes 10 -b 24

Not: VW ciddi adam işidir. Yanlış parametreyle çağırırsan model değil, dijital Frankenstein çıkabilir.

8.2 Yeni Sefer Verileri ile Model Otomatik Güncelleme

Sistemin mantığı şu şekilde işler:

Yeni bir taşıma verisi girilir
Regresyon + sınıflandırma modeli tahmin üretir
Sefer sonunda gerçek maliyet ve gerçekleşen süre sisteme girilir
Bu veri → Feature + Label olarak modele yeniden gönderilir
Model ağırlıkları güncellenir

Bu süreç arka planda, event-driven şekilde akar. Kullanıcının haberi bile olmaz.
Ama model “bir adım daha zeki” hale gelir.

Ne kazandırır?

Model drift kontrol altına alınır
Tahmin performansı zamanla artar
Sezonsal değişimlere karşı duyarlılık kazanılır
Her müşteri, her sefer → sistem için bir öğrenme verisidir

8.3 Zamanla Gelişen Tahmin Performansı

Ölçüm: Rolling MAE / R²

Modelin “dünkü hata oranı” ile “bugünkü hata oranı” sürekli karşılaştırılır.
Eğer tahmin hatası artmaya başlarsa → Alarm üretilir
Eğer sistem kendini düzeltiyorsa → Güncelleme devam eder

Otomatik Öğrenme = Model Yaşıyor

Dönem	MAE (₺)	Günlük Öğrenilen Kayıt
İlk 30 gün	620	0
30–60 gün	490	12.300
60–90 gün	430	28.700

Yani sistemin yaşı ne kadar ilerliyorsa, zekası da o kadar artıyor.
Bu, gerçek anlamda “machine learning”dir. Gerisi “data decoration.”

Not:
“Hocam bizde model var ama değişmiyor.”
Cevap: Sizde model yok, dijital nostalji var.

Bu sistem:

Her yeni veriden öğrenir
Her tahminden sonra kendini optimize eder
Güncellenmeden eskiyen modelleri otomatik değiştirir
Batch learning ile uğraşmaz, veri geldikçe kendini yeniler

Artık veri gelirken değil, yaşarken işleniyor.
Ve bu fark, sistemi "bir kerelik çözüm" olmaktan çıkarıp, kendini güncelleyen bir organizmaya dönüştürüyor.

9. Veri Görselleştirme ve Kullanıcı Arayüzü Deneyimi

Evet sevgili okuyucu, geldik işin “göze hitap eden ama arka planda yine full mühendislik kokan” katmanına.
Şimdiye kadar anlattıklarımız sistemin aklıysa, bu bölüm onun yüzü. Ve şunu net söyleyelim:

Ne kadar iyi model kurarsan kur, kullanıcı onu hissederken anlamıyorsa, geçmiş olsun.

Bu yüzden görselleştirme sadece “rapor üretme” değil;
verinin karar haline gelmesi,
modelin şeffaflaşması,

ve en önemlisi kullanıcının sisteme güvenmesi için tasarlanmalı.

Makine öğrenmesi modellerinin çoğu zaman “black box” gibi algılanmasının temel sebebi: kullanıcıya açıklanmadan sunulmalarıdır.
Biz bu sistemde, sadece model çıktısını değil, kararın nasıl oluştuğunu, hangi girdilerin etkili olduğunu, hangi senaryolarda hangi fiyatların oluştuğunu kullanıcıya görsel olarak sunuyoruz.

9.1 Matplotlib, Seaborn ile Veri Sunumu

Evet, frontend tarafında React, mobilde React Native veya Flutter kullanıyoruz.
Ama görsel veri üretimi backend’de başlıyor.

Neden Matplotlib + Seaborn?

Python ile tam entegre
Model sonrası görsel çıktı oluşturmak için en hızlı çözüm
Seaborn → istatistiksel veri setlerini estetik olarak sunmakta çok başarılı
Matplotlib → Fine-tuned custom grafiklerde kontrol bizde

Hangi Grafikler Üretiliyor?

Grafik Türü	Kullanım Amacı
Fiyat Tahmin Dağılımı	Modelin aynı rotaya verdiği farklı segment fiyatları
Feature Importance	Karar sürecinde en etkili girdilerin görselleştirilmesi
Sezonluk Dalgalanma	Prophet & ARIMA öngörülerinin zaman içinde değişimi
Endeks Heatmap	İl / ilçe / güzergah bazlı fiyat baskısı haritaları
Outlier Tespiti	Anomali tespit edilen seferlerin işaretlenmesi

Örnek Kod (Backend'de)

python
import seaborn as sns
import matplotlib.pyplot as plt

sns.barplot(x=features, y=importances)
plt.title("Feature Importance")
plt.savefig("/visuals/feature_importance.png")

Bu görseller, frontend'e CDN ile aktarılır ve kullanıcıya sunulur.
Yani görselleştirme, estetik değil, bilgiyle dolu olarak yapılır.

9.2 Web Arayüzü: Sefer Girdisi ve Fiyat Çıktısı Görselleri

Şimdi düşün: Kullanıcı sisteme giriyor ve bir sefer için tahmin istiyor.
Sistemin verdiği yanıt sadece “₺10.450” olursa, bu bir sayıdan ibaret kalır.
Ama eğer sistem şunu da gösterirse:

Bu fiyatın segmenti nedir?
Model hangi verilerle bu kararı verdi?
Alternatif fiyatlar nelerdi?
Endeks bu karara ne kadar etki etti?
Tahminin güven seviyesi nedir?

İşte o zaman kullanıcı “ikna olur”.

Web UI’de Neler Sunuluyor?

Bileşen	Açıklama
Girdi Formu	Araç tipi, mesafe, yük, sefer zamanı
Canlı Harita (Mapbox)	Güzergah ve tahmini trafik
Fiyat Segmentasyonu	Yavaş – Normal – Hızlı fiyatlar görsel bloklarla sunulur
Karar Ağacı Grafiği	Karar nasıl alındı, kullanıcı adım adım görür
Endeks Özet Paneli	Seferi etkileyen dışsal faktörler raporlanır
“Neden Bu Fiyat?” butonu	Kararın teknik özeti + kullanıcıya sade açıklama

Sistemin şeffaflığı, kullanıcı deneyiminin temel direğidir.
“Sistemi anladım” dedirten her arayüz unsuru, çağrı merkezine 1 eksi talep demektir.

9.3 Mobil Kullanıcı Deneyimi ve Geribildirim Döngüsü

Sistemi sadece masabaşı kullanıcı değil, sahadaki operasyoncu da kullanacak.
Mobil taraf, minimum efor – maksimum bilgi felsefesiyle tasarlandı.

Mobilde Ne Var?

Sefer oluşturma sihirbazı
Gerçek zamanlı tahmini maliyet ve fiyat seçenekleri
QR ile yükleme belgesi paylaşımı
Sesli komutla sefer sorgulama (opsiyonel)
Fiyat hakkında “geri bildirim bırak” özelliği
(→ modelin online öğrenme katmanına beslenir)

Geribildirim Döngüsü

Kullanıcı “Bu fiyat bana yüksek geldi” dedi mi?
Sistem bu veriyi alır, tekrar eğitilen modelin “kullanıcı davranışı katmanına” yazar.
Yani kullanıcıya sadece sistem cevap vermez, kullanıcının cevabı da sisteme işler.

Bu da AI değil, insanlı AI olur.
Ve bu fark, "teknoloji" ile "kültür" arasındaki boşluğu kapatır.

Görmediğine güvenemezsin.
Kullanıcı arayüzü, modeli görünür kılar.
Ve unutma: “Modelin doğruluğuna değil, anlatabildiğine ikna olunur.”

10. Kullanılacak Python Kütüphaneleri ve Fonksiyonel Ayrım

Geldik son düzlükteki yapı taşı gibi duran ama sistemin tüm sinir ağlarını birbirine bağlayan, Python kütüphanelerinin fonksiyonel ayrımı bölümüne.

Bu bölüm, aslında teknik ekip için "anatomik plan", yöneticiler içinse "bu iş neyle yapılır?" sorusunun net cevabıdır.

Ve evet… buraya kadar okuyan herkes için küçük bir uyarı:

Eğer bu kütüphaneleri sadece ismen biliyorsanız, sakin olun.
Eğer hepsine hakimseniz, CV'nizi alayım. Şirkette yer açarız. 😎

Bu sistemin Python tarafında kullanılan tüm kütüphaneler, “neyle yapabiliriz?” değil, “neden özellikle bununla yapıyoruz?” mantığıyla seçilmiştir.
Her biri amacına uygun, ölçeklenebilir, topluluk desteği yüksek ve production-grade bileşenlerdir.

10.1 Veri İşleme

Amaç: Girdi verilerini temizlemek, normalize etmek, feature engineering yapmak, model inputlarını hazırlamak.

Kütüphane	Fonksiyonel Rolü
pandas	Tablo yapısında veri okuma, düzenleme, gruplama
numpy	Sayısal işlemler, matris manipülasyonu, vektörleştirme
pyjanitor (opsiyonel)	Data cleaning pipeline'larını sadeleştirme
datetime	Zaman serisi segmentasyonu, tarih bazlı veri üretimi

Bonus not: pandas bilmeyen Pythoncuya “data engineer” denmez. Bunu hepimiz biliyoruz.

10.2 Modelleme ve Tahmin

Amaç: Maliyet tahmini, zaman serisi analizi, fiyat segmentasyonu, endeks hesaplama.

Kütüphane	Fonksiyonel Rolü
scikit-learn	Temel ML modelleri (regression, classification, preprocessing)
xgboost	Regresyon & feature importance için high-performance model
lightgbm	Hızlı gradient boosting algoritması
prophet	Zaman serisi tahmini, mevsimsellik analizi (by Meta)
catboost	Kategorik verilerle daha stabil GBM modeli (alternatif)
statsmodels	ARIMA, ADF testleri, istatistiksel veri modelleme

Prophet & ARIMA birlikte kullanılır. Prophet: Trend+Sezon, ARIMA: Kısa vadeli düzeltme.
XGBoost ise tahminin tankı gibi; vurdu mu net vurur.

10.3 Görselleştirme

Amaç: Model çıktılarının anlaşılır, okunabilir ve karar vericiye uygun şekilde sunulması.

Kütüphane	Fonksiyonel Rolü
matplotlib	Tüm temel çizim işlevleri (bar, line, pie, grid)
seaborn	İstatistiksel grafikler, dağılım, korelasyon
plotly	İnteraktif grafikler (opsiyonel, dashboard için)
pillow	Görsel işleme (eğer çıktılar CDN'e aktarılacaksa)

“Bir görsel, bin satır SQL’den değerlidir.”
Özellikle endeks heatmap’leri ve feature importance görselleri için seaborn candır.

10.4 Online Öğrenme

Amaç: Modelin her yeni veriyle güncellenmesini sağlamak. Drift, sapma ve yeni pazar koşullarına adaptasyon.

Kütüphane	Fonksiyonel Rolü
River	Python tabanlı online learning; `learn_one()` vs. `predict_one()` paradigması
Vowpal Wabbit	Büyük veriyle yüksek hızda incremental modelleme (CLI tabanlı canavar)
joblib / pickle	Model serialization / versionlama / model checkpointing

River hafif, esnek, anlaşılırdır. VW hızlı, derin ve biraz “çekirdek seviyesinde” bir adamdır.
Her ikisi de modelin “yaşayan organizma” olmasını sağlar.

10.5 API ve Sunucu Entegrasyonu

Amaç: Modelleri dış sistemlere açmak, veri alışverişini güvenli, hızlı ve belgelemeli hale getirmek.

Kütüphane	Fonksiyonel Rolü
FastAPI	Asenkron API yapısı, Swagger/OpenAPI otomatik dökümantasyon
Flask	Daha sade REST servisleri, legacy sistem entegrasyonu
pydantic	Input doğrulama, veri tipi güvenliği, şema oluşturma
uvicorn	FastAPI için lightweight production server
requests / httpx	Harici servis çağrıları, webhook entegrasyonları

FastAPI + Pydantic ikilisiyle kurulan yapı hem hızlı, hem tip güvenli, hem de Swagger’la dökümante.
Flask ise hala “eski toprak” sistemler için cepte dursun.

Bu sistem:

Veriyi işler (pandas, numpy)
Modeli kurar ve tahmin eder (xgboost, prophet, sklearn)
Görselleştirir (seaborn, matplotlib)
Öğrenir ve adapte olur (River, VW)
API üzerinden dış dünyaya açılır (FastAPI, Flask)

Yani bu sistem sadece bir fiyat motoru değil;
veri odaklı karar üreten, kendini geliştiren ve kullanıcıya derdini anlatan bir mühendislik ekosistemidir.

11. Sistemin Yazılım Geliştirme Ekibi ve Rol Dağılımı

Şimdi geldik sistemin “algoritmalarla konuşan” değil, algoritmaları hayata geçiren insanlarına.

Yani bu sayfada modelin MAE’si değil, geliştiricinin kafa travması konuşacak.

Unutma:

En iyi yazılım, en güçlü algoritma, en sağlam mimari bile doğru ekip olmazsa kağıtta kalır.

Ve biz bu sistem için “her taş yerinde ağır” olacak şekilde bir ekip modeli tasarladık.Bu yapay zeka destekli fiyatlandırma sisteminin sorunsuz geliştirilmesi, ölçeklenmesi ve işletilmesi için aşağıdaki yetkinliklere sahip multidisipliner bir ekip yapısı önerilir:

11.1 AI Backend Geliştirici

Sistemin karar motorunu yazan, tahmin modellerini optimize eden, regresyondan anomaly detection’a kadar her satır kodun mühendisidir.

Sorumluluklar:

Maliyet tahmin modellerinin (XGBoost, LightGBM, Ridge) geliştirilmesi
Zaman serisi modellemesi (Prophet, ARIMA)
Sınıflandırma ve segmentasyon modellerinin kurulumu
API ile model deploy ve servis süreçleri (FastAPI / Flask)
Model versiyonlama ve dokümantasyon (MLflow, joblib, onnx)

Yetkinlikler:

Python (ileri düzey), Scikit-learn, PyTorch/TensorFlow (opsiyonel ama bonus)
Model explainability ve feature engineering konusunda deneyim
Yazdığı her kodun API’ye entegre olacağını bilen biri
"Ben bu modelin neden böyle tahmin ettiğini anlatamıyorsam, yazmam." disiplinine sahip

11.2 Data Scientist

Verinin içindeki fırsatı, riski, trendi ve saçmalığı yakalayan kişidir. Tahmin değil, sezgiye istatistik yükleyen profesyoneldir.

Sorumluluklar:

Veri keşfi ve anomali tespiti (EDA, outlier detection)
Feature engineering + sezon / bölge etkisi analizi
Endeks hesaplama modellerinin kurulması
Kümeleme analizleri (KMeans, DBSCAN, HDBSCAN)
Zaman serisi tahmin başarımı testleri

Yetkinlikler:

Python, pandas, seaborn, statsmodels, Prophet, ARIMA
Büyük veri seti ile batch & stream analiz yapabilecek yetkinlik
A/B test yapısını anlayan, veri ile hipotez test etmeyi bilen
“Bir grafik bin satır SQL’den değerlidir” diyen görsel zekası yüksek biri

11.3 Frontend Developer

Kullanıcının “sistemi anlamasını sağlayan” kişidir. Yani bu projenin çevirmeni, yüzü, estetik zekasıdır.

Sorumluluklar:

Web UI (React.js) ve mobil (React Native / Flutter) geliştirme
Sefer giriş formu, fiyat segmentasyonu kartları, endeks ekranları
“Neden bu fiyat?” alanlarının açıklanabilir, sezgisel arayüzlere dönüşmesi
Kullanıcı deneyimi testleri ve geribildirim optimizasyonları

Yetkinlikler:

React.js, TailwindCSS/ChakraUI, Redux (veya context API)
API ile konuşan her front bileşeni yönetebilecek yapı
Responsive, modüler, sade ama güçlü UI tasarımı
“UI kullanıcı için değil, sistemin kendini anlatma şeklidir.” diyebilecek vizyonda

11.4 Full Stack / DevOps (Opsiyonel ama çok kıymetli)

Sistemi uçtan uca kuran, CI/CD’yi yöneten, “Bu kod ayağa kalkacak mı?” sorusunu soran kişidir.

Sorumluluklar:

Backend & Frontend entegrasyonlarını organize etmek
AWS/Azure üzerinde ortam kurulumları
Docker, Kubernetes, GitHub Actions, ArgoCD ile deployment yönetimi
Monitoring & logging sistemlerinin kurulumu (Prometheus, Grafana, ELK, Sentry)

Yetkinlikler:

Docker, AWS, Git, CI/CD, Linux shell, reverse proxy
Sistemi “localde çalışan model”den “24/7 canlı çalışan yapıya” dönüştürebilecek altyapı
"Ben bu kodu yarın production’a sokarım" özgüvenine sahip biri

Ek Not: Takım Yapısı Önerisi (Minimum Setup için)

Rol	Sayı
AI Backend Developer	1
Data Scientist	1
Frontend Developer	1
Full Stack / DevOps	0.5 (Part-time veya dış kaynak)

Daha büyük projelerde roller ayrıştırılabilir, küçük organizasyonlarda rolleri birleştirecek T-shaped profil tercih edilebilir.

Unutma: Kod yazmak tek başına sistemi ayağa kaldırmaz.
“Kodun nerede, neden, ne zaman, kiminle çalışacağı” bu ekiplerin uyumu sayesinde netleşir.

Hazırsan artık son bölümdeyiz. Bu sistemin sadece bugün için değil, yarın için nasıl genişletileceğini, hangi alanlarda evrileceğini anlatacağımız noktaya geldik:

12. Sonuç ve Gelecekteki Gelişim Alanları

Bu dökümanda sıfırdan bir “model” değil, tüm bir sistem anlattım.
Yani sadece “fiyatı nasıl tahmin ederiz?” değil:

“Veri nereden gelir, nasıl temizlenir, nasıl yorumlanır, nasıl fiyat olur ve bu fiyat nasıl anlam kazanır?” sorularının tamamına mühendislik perspektifiyle cevap verdim.

Çünkü modern dünyada yapay zeka sistemleri artık “bir model dosyası” değil;

bir ekosistemdir
bir karar motorudur
bir yazılım mimarisidir
bir öğrenme döngüsüdür
ve bir operasyonel zeka katmanıdır

12.1 Model Genişletilebilirliği

Bu sistem, sadece karayolu taşımacılığı için değil;
→ Depo içi transfer,
→ Multimodal taşıma,
→ Parsiyel yük analizleri gibi alanlara da kolaylıkla genişletilebilir.

Daha fazla feature eklersin, model güncellenir.
Yeni kullanıcı davranışları geldikçe sistem öğrenir.
API’yi başka sistemlere açarsın, entegrasyon mümkün olur.

Ve en güzeli:

Sistem “bugünün verisiyle bugünü anlamaz.”
Dünün verisiyle bugünü öğrenip, yarının fiyatını konuşur. (Bu cümleye telif alırım.)

12.2 Blockchain & Akıllı Sözleşmelerle Entegrasyon

Bir sonraki adım, artık veriyi yalnızca analiz etmek değil, doğrulamak ve işe bağlamak.

Akıllı Sözleşmelerle Ne Mümkün?

Fiyat tahmini yapıldığında → Müşteri kabul ettiğinde → Otomatik taşıma sözleşmesi oluşturulur
Bu sözleşme blockchain'e yazılır → Taraflar mutabık kalır → Ödeme koşulları kilitlenir
Taşıma tamamlandığında → Araç konumuyla eşlenir → Ödeme tetiklenir

Kısacası:

Yapay zeka fiyatı belirler, blokzincir ödemeyi yapar, sistem kendi kendine yaşar.
Böylece sadece dijitalleşmiş değil, otonomlaşmış bir lojistik sistemine yaklaşırız.

12.3 Sektörel Uyarlamalar: E-Ticaret, Soğuk Zincir, Mikro Lojistik

Bu sistem “lojistik” dediğimizde yalnızca TIR’ları değil,
e-ticaret teslimatlarını, depo içi robotik yönlendirmeleri, hatta scooter’la dağıtımı bile kapsayabilir.

E-Ticaret: Dinamik kampanya dönemlerinde dağıtım yoğunluğu analiz edilir → AI ile fiyat/kapsam optimizasyonu yapılır.
Soğuk Zincir: Isı değişimi, taşıma süresi, rota riski gibi parametrelerle gerçek zamanlı fiyat hesaplanır.
Mikro Lojistik: Şehir içi kısa mesafelerde rotalara göre dinamik fiyat kırılımı uygulanır.

Yani sistemin kabiliyetleri → sadece algoritmada değil, kurgudaki esneklikte gizlidir.

Ve Şimdi Final...

Eğer bu yazıyı buraya kadar okuduysan:

1) Ya mühendissin,
2) Ya CTO’sun,
3) Ya da bu işin ciddiyetini gerçekten kavramış vizyoner bir yöneticisin.

Anlamadıysan da sorun değil.
Bana bir mail gönder...
Ben sana yine de anlatırım. Kahvemi içerken açıklayacağım şey, belki yarın sektörün geleceğini belirler.

Bu rehberle sana ne anlattım?

"Yapay Zeka Destekli Dinamik Fiyatlandırma ve Maliyet Hesaplama Sistemi" nasıl kurulur?
Hangi Python kütüphaneleri, hangi modeller, hangi algoritmalar kullanılır?
Sistemin mimarisi, API altyapısı, veri girişi, model çıktısı nasıl yapılandırılır?
Hangi ekip yapısıyla bu sistem hayata geçirilir?
Hangi sektörel adaptasyonlarla genişleyebilir?

Kısacası, bir yapay zeka sisteminin A’dan Z’ye nasıl tasarlanacağını, mimariden deploy’a kadar tüm detaylarıyla ortaya koydum.
Normalde 3 workshop + 1 danışmanlık oturumu + 1 sigorta poliçesi ile satılır bu bilgi.

Umarım bu yazıdan ilham alan biri çıkar da, bu işe girişir.
Ben de arkamda yaslanır, mutlu mutlu izlerim.
Hatta haber verirse, ilk demo çıktısını izlemek için çayımla birlikte gelirim.
(Ama baklava da kabulümdür, her yazının sonunda bu not var.)

Okuduğun için teşekkür ederim.
Burası bitiş değil, belki de senin yeni sisteminin başlangıcıdır.

Saygıyla,
Dipl.-Ing. Deniz Cengiz