Hook + problem tanımı

Aynı baraj, aynı türbin, aynı su ama “yarınki gelir” çoğu zaman sahadaki gerçeklerden değil, PTF’nin nereye gittiğinden etkilenir.
Kâğıt üzerinde basit görünen problem şudur: “Ertesi gün 24 saatlik PTF’yi doğru tahmin edelim.”
Gerçekte ise PTF, yalnızca geçmiş fiyatların devamı değil; hava durumu, arıza riski, iletim kısıtları ve talep belirsizliği gibi faktörlerin aynı anda devreye girdiği,
zaman zaman rejim değiştiren bir süreçtir. Üstelik PTF, tekliflerin bir optimizasyon/uzlaştırma mekanizmasıyla eşleşmesinden çıkan bir “sonuç” fiyatıdır [1][4].
Bu yüzden PTF tahmini, veri bilimiyle “sadece model kurmak” değil; doğru veri, doğru zaman hizası, doğru feature mantığı ve operasyonel geri besleme gerektiren bir karar problemidir [5][6].

PTF nedir? Neyi tahmin etmeye çalışıyoruz?

PTF (Piyasa Takas Fiyatı), Türkiye’de Gün Öncesi Piyasası’nda (GÖP) her saat için piyasanın eşleşme sonucunda oluşan referans fiyatıdır.
Basitçe “yarın saat 19:00 fiyatı kaç?” sorusunun piyasa cevabıdır. Ancak burada kritik detay şudur: PTF, bir “etiket” değil; arz-talep tekliflerinin kısıtlar altında çözülmesiyle ortaya çıkan bir optimizasyon çıktısıdır [1].
Yani PTF, katılımcı davranışının, maliyetlerin, beklentilerin ve sistem koşullarının birleşik sonucudur.

Elektrik fiyatı neden diğer emtialardan farklı davranır?

Elektrik depolaması sınırlıdır, denge anlıktır, talep kısa vadede “inatçı” olabilir. Bu, fiyatların yüksek volatilite, nonlineer ilişkiler ve uç olaylara (spike) açık olmasına neden olur [5][6].
Bu yüzden literatürde elektrik fiyat tahmini, “ortalama hatayı düşürme” kadar “uç saatleri yakalama” problemi olarak ele alınır [6].

PTF tahmini için dört ana zorlayıcı (hava, arıza, iletim, talep)

Blog konumuzdaki dört faktörü, pratik bir modelleme çerçevesine oturtalım:

• Talep belirsizliği: Yarınki yük tahmini hatası, marjinal santral seçimini değiştirir; bu, PTF’ye birebir yansır [5][10].
• Hava: Talep tarafını ve RES/GES üretimini aynı anda etkiler. Hidroda da dolaylı etkiler (yağış/kar erimesi) vardır [5][7].
• Arızalar: Beklenmeyen devre dışılar, özellikle “pik saatlerde” arzı sıkıştırıp spike yaratır [6].
• İletim kısıtları: Şebeke kısıtı, ekonomik sıralamanın (merit order) bozulmasına ve sistemin farklı bir denge noktasına gitmesine yol açabilir [9][10].

Nasıl çalışır?

Bu bölümde “değişkenler → veri kaynakları → feature mantığı” akışını net bir şekilde kuralım.

Değişkenler: PTF’yi sürükleyen temel driver aileleri

Literatür ve saha pratiği genelde driver’ları şu ailelerde toplar [5][6]:

• Geçmiş fiyat ve takvim etkisi: Saat-gün-hafta sezonsallığı, tatiller, ay başı/sonu davranışları [5].
• Talep & talep belirsizliği: Yük seviyesi + yük tahmini hatası (forecast error) [5][10].
• Arz karması: Doğalgaz/ithal kömür/hidro/RES/GES üretim düzeyleri (marjinal yakıt) [7][8].
• Yakıt & makro göstergeler: Gaz, kömür, döviz, bazı piyasalarda CO₂ vb. [8].
• Sistem ve şebeke koşulları: İletim kısıtları, kısıt yönetimi, kesintiler, operasyonel talimatlar [9][10].
• Arıza/planlı bakım/kapasite: Zorunlu devre dışılar, ünite kullanılabilirliği [6].

Veri kaynakları: “hangi veri nereden gelir?” (TR odak)

PTF tahmini için veri kaynaklarının “resmi” ve “operasyonel” ayrımı önemlidir:

• EPİAŞ Şeffaflık Platformu: PTF ve çok sayıda piyasa/üretim/tüketim verisi için ana kaynak [2].
• EPİAŞ Şeffaflık – eknik dokümantasyon: Veri erişim yöntemleri ve servis mantığı (entegrasyon) [3].
• Meteoroloji verileri: Sıcaklık, rüzgâr hızı, bulutluluk, yağış; mümkünse bölgesel kırılımla. (Kaynak seçimi kurumunuza göre değişir.)
• TEİAŞ/ENTSO-E benzeri şebeke & iletim görünürlüğü: Kısıtlar, bölgesel darboğazlar, planlı çalışmalar [10].
• Tesis içi SCADA/EMS verileri: HES için debi, head, kapak, Kw, ünite durumları (PTF tahminini “miktar riskiyle” birlikte düşünmek için kritik).

Feature mantığı: En çok hata yapılan yer zaman hizası

Model performansını çoğu ekip “hangi algoritma?” diye tartışıyor; pratikte en büyük kırılım genellikle feature mühendisliğinde yaşanır. İki kritik kural var:

Kural-1: “Bilinen zaman” prensibi (data leakage yok).

Yarın 18:00 PTF tahminini yaparken, yarın 18:00’de ortaya çıkan bir veriyi (gerçekleşen üretim/gerçekleşen talep gibi) feature’a koyarsanız model harika görünür, üretimde çöker.

Kural-2: Tahmin ufku kadar “gecikmeli” feature tasarla.

Day-ahead tahminde; meteoroloji tahminleri, talep tahminleri, planlı bakım listeleri gibi bid-time’da bilinen sinyaller kullanılmalı.
“Gerçekleşen” veriler ise modelin eğitimi için kullanılabilir ama tahmin anında aynısı yoksa mutlaka proxy üretmek gerekir [5][6].

HES / enerji tesisi tarafında etkisi

HES için PTF tahmini neden daha “operasyon bağımlı”?

Bazı üretim teknolojileri için fiyat tahmini, ağırlıkla piyasa dinamiği ve yakıt maliyetleri üzerinden yürür. HES’te ise ek bir katman vardır: suyun saatlere taşınması.
Yani HES, fiyatı sadece “izleyen” değil, doğru saatlere su planlayarak fiyatı monetize eden taraftır.
Bu yüzden PTF tahmini HES’te şu iki soruyla birleşir:

• Yarın fiyat nerede?
• Yarın “o saatlerde” üretim garantim ve riskim ne? (debi belirsizliği, ekipman durumu, çevresel kısıtlar)

Bu ikinci soru devreye girdiğinde; PTF tahmini tek başına değil, operasyonel risk görünürlüğüyle birlikte değer üretir.

HES’te PTF hatası nerede “paraya dönüşür”?

• Yanlış saatlere su koyma: Yüksek fiyat beklerken fiyat gelmez → fırsat maliyeti
• Pik saatlerde üretim tutmaması: PTF doğru olsa bile miktar sapar → gelir erir
• Reaktif düzeltme döngüsü: “Plan bozuldu” → son dakika aksiyon → karar kalitesi düşer
• Teminat / risk profili baskısı: Belirsizlik arttıkça finansal tarafta risk iştahı düşer (piyasa mekanizması detayları kurumlara göre değişse de risk yönetimi pratikte bu şekilde görünür.)

Örnek senaryo / mini hesap / akış

Senaryo: Barajlı HES — “soğuk hava + rüzgâr sapması + iletim kısıtı” günü

Varsayalım yarın için şu sinyaller var:

• Meteoroloji: Akşam saatlerinde soğuk artışı → talep artış riski
• Bölgesel rüzgâr tahmini: Beklenen üretim var ama belirsizlik yüksek
• Şebeke: Belirli hatlarda planlı çalışma → bölgesel kısıt ihtimali
• Tesis: Ünite-2’de sıcaklık/titreşim trendi normalin üst sınırına yaklaşmış (kritik değil ama risk sinyali)

Amaç: Yarın 17:00–22:00 bandında en iyi gelir-risk dengesini kurmak.

Adım adım akış (karar şeması)

1. Talep & hava senaryosu oluştur:
   Normal / soğuk / çok soğuk senaryosu
   Her senaryoda saatlik talep sapma bandı
2. RES belirsizliğini modele sok:
   Tek sayı üretim değil, tahmin aralığı (P10-P50-P90)
   Bu aralık, arz eğrisinin eğimini değiştirir → PTF dağılımı değişir [5][6]
3. İletim kısıtı etkisini “rejim” olarak düşün:
   Kısıt yok / kısıt var (bölgesel darboğaz)
   Kısıt varsa marjinal üretim değişebilir [10]
4. HES üretim riskini dahil et (SCADA + bakım sinyali):
   Ünite-2 riskliyse pik saatlerde %100 güvenme
   “Kesin üretim” ve “opsiyonel üretim” bandını ayır
5. Çıktı: Saatlik PTF dağılımı + aksiyon bandı
   “Bu saatlerde suyu artır” yerine:
   “Bu saatlerde suyu artır ama risk tetiklenirse fallback plan şu” yaklaşımı

Mini not: Burada finansal danışmanlık vermiyoruz; hedef, karar mantığını göstermek.

İnfografik Taslağı:

DRIVER KATMANI (4 Ana Kuvvet)

DATA KATMANI (Kaynaklar)

FEATURE KATMANI (Aileler)

Marjinal Yakıt Proxy: Doğal gaz ve kömür maliyet göstergeleri.

Kısıt Flag: İletim rejimi ve arz kısıt işaretleri.

İnfografik-1
İnfografik PTF tahminini sistematik hale getiren uçtan uca şablon: sürücüler → veri kaynakları → feature aileleri → senaryo/dağılım çıktısı → HES karar bandı.
2024 Türkiye piyasası ölçek ve üretim karması göstergeleri eklenmiştir.

Hydrowise / Renewasoft yaklaşımı

Problem tesiste nasıl görünür?

Birçok tesiste PTF tahmini, ticaret ekibinin “ayrı bir işi” gibi yaşar; SCADA ve saha ise ayrı bir dünyadır. Sonuçta şu tablo oluşur:

• Ticaret: “Fiyatı yakaladık.”
• Operasyon: “Saha koşulları değişti.”
• Finans: “Gün sonunda neden sapma/gelir farkı var?”

Bu kopukluğu azaltmanın yolu; PTF tahminini tek başına değil, veriyle açıklanabilir bir karar akışı olarak tasarlamaktır.

Hydrowise ile veri-odaklı PTF tahmini nasıl konumlanır?

Hydrowise yaklaşımını, “forecast + içgörü + operasyonel bağ” diye düşün:

Uygulanabilir öneri: 2 haftalık MVP yol haritası

• Hafta-1: EPİAŞ verilerini çek + temel özellik seti (takvim, geçmiş PTF, volatilite) [2][3]
• Hafta-2: Meteoroloji + talep tahmini + “spike risk etiketi” ekle; canlı testte leakage kontrol listesi uygula [5][6]

Sık sorulan sorular

Sonuç + CTA

PTF tahmini, “yarın fiyat kaç?” sorusundan daha büyük bir problemdir: yarınki arz-talep dengesi hangi koşullarda oluşacak ve hangi saatlerde rejim değişecek?
Hava, talep belirsizliği, arızalar ve iletim kısıtları; PTF’yi bir “zaman serisi” gibi değil, kısıtlı bir optimizasyon çıktısı gibi düşünmemizi gerektirir [1][5][6][10].
Bu nedenle iyi tahmin yaklaşımı; doğru veri kaynaklarını birleştiren, leakage’siz feature üreten, belirsizliği senaryolaştıran ve HES operasyonu ile aynı ekranda buluşturan bir karar destek akışıdır.