Anlık Haber Deneyi: Bir Haber Sayfasını Ajanlı Yayın Sistemine Çevirmek

Anlık Haber ilk bakışta basit bir fikir gibi görünüyordu: Blog içinde daha kısa, daha hızlı akan, gündemi takip eden ayrı bir haber yüzeyi oluşturalım.

Sonra proje büyüdü.

Bir sayfa yapmaktan çıktık; kaynak toplayan, haberleri sıraya alan, editoryal karar veren, görsel seçen, yayınlayan ve kendi hatalarından ders çıkarması gereken küçük bir haber sistemine doğru ilerledik.

Bu yazı o sürecin düzgün parlatılmış başarı hikayesi değil. Daha değerlisi: Ne denedik, nerede zorlandık, neleri düzelttik ve sonunda neden frene bastık?

İlk fikir: Blogdan ayrı bir haber akışı

Başlangıç hedefi teknik olarak mütevazıydı. Ana blog akışını bozmadan, daha sık güncellenebilecek ayrı bir Anlık Haber alanı kurmak istiyorduk.

İlk mimari karar şuydu:

• Haberler blog yazılarıyla aynı koleksiyona karışmayacak.
• Ayrı bir içerik tipi kullanılacak.
• Ayrı bir haber layout’u olacak.
• Ana sayfa daha gazete benzeri, daha taranabilir bir akış hissi verecek.
• Listeleme yüzeyi büyüdüğünde 1000 haber tek sayfaya yığılmayacak; görünürde akıcı, altta sayfalı bir yapı olacak.

Yani ilk mesele “Astro ile haber sayfası nasıl yapılır?” sorusuydu. Ayrı content collection, ayrı route’lar, detay sayfaları, kategori çipleri, hero alanı, kart grid’i…

Ama kısa sürede şunu gördük: Haber sayfası sadece layout değildir.

Bir haber sayfasında asıl ağırlık, ekranda görünen kartlardan önce başlar: Haber nereden gelecek? Nasıl seçilecek? Aynı haberin iki varyantı nasıl engellenecek? Başlık Türkçeye nasıl çevrilecek? Tek kaynaklı iddia yayınlanacak mı? Görsel nereden bulunacak?

İşte o noktada proje “sayfa yapımı” olmaktan çıktı.

İkinci aşama: Python tabanlı haber pipeline’ı

Haberleri elle girmek bir süre sonra anlamsız olacaktı. Bu yüzden blog projesinin içine ayrı bir news_pipeline omurgası kurduk.

Buradaki karar şuydu: Yayın yüzeyi Astro kalacak, ama haber toplama ve işleme tarafı Python’da ilerleyecek. Doğrudan veritabanı bağlamak yerine dosya tabanlı bir köprü kullanacaktık. Küçük proje için bu daha sakin, daha izlenebilir ve daha az kırılgan bir yoldu.

Pipeline kabaca şu parçalardan oluştu:

1. RSS kaynaklarından haberleri toplama.
2. Haberleri normalize etme.
3. Basit duplicate kontrolü.
4. Queue kaydı üretme.
5. Haberleri new, reviewing, approved, rejected, published gibi durumlarla izleme.
6. Onaylanan kayıtları Markdown taslağına dönüştürme.
7. Düşük riskli haberlerde kontrollü yayın akışı açma.

Bu aşamada en önemli ilke şuydu:

Önce queue, sonra yayın.

Çünkü haber otomasyonu blog otomasyonundan daha riskli. Yanlış bir blog yazısı kötü görünür; yanlış bir haber itibari, hukuki ve editoryal risk üretir.

Bu yüzden sistem ilk günden “her bulduğunu yayınla” diye tasarlanmadı. Daha çok: “Topla, sıraya al, puanla, riskliyse beklet, temizse yayınlamayı düşün” çizgisinde ilerledi.

Asteria: Ajanı editör koltuğuna oturtmak

Pipeline çalışmaya başlayınca sıradaki soru şuydu:

Queue’daki haberleri kim değerlendirecek?

Burada Asteria devreye girdi. Onu genel amaçlı bir yardımcı gibi değil, dar görevli bir haber editörü ajanı gibi konumlandırdık.

Asteria’nın işi şuydu:

• Queue’yu kontrol etmek.
• Düşük riskli haberleri seçmek.
• Tek kaynaklı, hassas veya hukuki risk taşıyan haberlerde yayınlamamak.
• Haber metnini kısa ama gerçek haber akışı gibi yazmak.
• Özet/bülten maddeleri gibi değil, 3-5 kısa paragraflık doğal gövde üretmek.
• Temiz yayınlarda dar kapsamlı commit/push yapabilmek.

Bu kulağa şık geliyor, ama pratikte ilk ders hızlı geldi: Ajanın “yetkisi” kadar “yaşam alanı” da önemli.

Başta Asteria’yı yanlış yere yerleştirdik. Blog repo içine ajan dosyaları sızdı. Bu kabul edilemezdi. Sonra Asteria için ayrı bir workspace açıldı; kimlik dosyaları, görev sınırları, risk kuralları ve repo hijyen ilkeleri oraya taşındı.

Bu küçük gibi görünen karar önemliydi. Bir ajanı projeye dahil ederken sadece prompt yazmıyorsun; ona nerede yaşayacağını, neye dokunabileceğini, neyi asla kirletmemesi gerektiğini de söylüyorsun.

İlk canlı sonuçlar ve ilk gerçek sorunlar

Sistem kısa sürede haber üretmeye başladı. İlk canlı yayınlar geldi. Asteria queue’dan haber seçebiliyor, Markdown üretebiliyor, siteye içerik ekleyebiliyordu.

Ama “çalışıyor” ile “iyi çalışıyor” aynı şey değil.

İlk kalite sorunları şuralarda toplandı:

• Bazı metinler haberden çok günlük bülten özeti gibi duruyordu.
• Kapanış paragrafları fazla robotikleşebiliyordu.
• Kaynak dağılımı dengesizdi; TechCrunch ve benzeri kaynaklar fazla baskın hale geliyordu.
• Görseller çoğu zaman alakasız veya jenerikti.
• Kategori sistemi ilk haliyle yayın çizgisini taşımıyordu.
• Bazı haberler event-level duplicate sayılabilecek kadar yakındı.

Bu aşama projenin en öğretici kısmıydı. Çünkü teknik olarak çalışan bir pipeline’ın editoryal olarak hâlâ zayıf olabileceğini çıplak şekilde gördük.

Bir RSS kaydını Markdown’a çevirmek kolay. Onu güvenilir, dengeli, iyi kategorize edilmiş ve görsel olarak doğru bir haber deneyimine çevirmek bambaşka iş.

Kategori çizgisini yeniden kurmak

Başta haber yüzeyi daha genel bir kategori mantığıyla ilerliyordu. Fakat zamanla şunu fark ettik: Türkiye merkezli gündem, sayfanın global Türkçe haber çizgisini bozuyordu.

Bu yüzden Anlık Haber’i daha net bir yayın kimliğine çektik:

• Türkiye kategorisi kaldırıldı.
• Sonra Dünya kategorisi de kaldırıldı.
• Kategori seti Siyaset, Ekonomi, Teknoloji, Bilim, Kültür olarak sadeleştirildi.

Bu sadece UI düzenlemesi değildi. Mevcut haberleri yeniden dağıttık, pipeline schema’sını güncelledik, kategori fallback’lerini temizledik, yayın talimatlarını değiştirdik.

Bu kararın arkasındaki fikir şuydu:

“Dünya” çok geniş bir sepet. Asıl anlam, haberin ne hakkında olduğunda.

Bir uluslararası seçim haberi Siyaset, bir piyasa haberi Ekonomi, bir yapay zeka gelişmesi Teknoloji, bir uzay/araştırma haberi Bilim, bir sinema/yayıncılık haberi Kültür altında daha net duruyordu.

Bu değişiklik sayfayı daha okunabilir yaptı. Aynı zamanda pipeline’a da daha güçlü bir editoryal pusula verdi.

Duplicate sorunu: Aynı olay, farklı URL

Haber otomasyonunda duplicate meselesi sadece aynı URL’yi iki kez görmeyi engellemek değildir.

Asıl problem şudur: Aynı olay farklı kaynaklarda, farklı başlıklarla, farklı URL’lerle gelir. Hatta bazen aynı kaynaktan bile farklı açılarla gelir. Sistem bunu anlamazsa kullanıcıya aynı haberin hafif oynatılmış iki versiyonunu yayınlar.

Biz de bunu yaşadık.

Çözüm olarak duplicate kontrolünü URL/title/description seviyesinden daha ileri taşıdık. Topic token’lar, birleşik token setleri, ana aktör/kurum ve olay çekirdeği gibi sinyaller devreye girdi.

Bu kusursuz bir haber clustering sistemi değil. Ama pratikte şunu sağladı:

• Aynı olayın çok yakın varyantları daha iyi yakalanıyor.
• Tekrarlı kaynak davranışı daha görünür hale geliyor.
• Asteria’ya “aynı kaynak + aynı aktör + aynı olay” kombinasyonunda daha temkinli davranması söylenebiliyor.

Bu tür projelerde erken alınması gereken derslerden biri bu:

Duplicate kontrolünü en başta hafife alırsan, kalite sorununu sonradan editoryal kriz olarak yaşarsın.

Kaynak çeşitliliği: Güçlü kaynak iyi, tek kaynak kötü

Bir süre sonra başka bir desen çıktı: Sistem kaliteli bulduğu bazı kaynaklara fazla yaslanıyordu.

Bu doğal. Scoring mantığına “güvenilir, temiz, hızlı, iyi metadata veren kaynak” sinyalleri koyarsan, bazı kaynaklar sürekli öne çıkar. Ama haber ürünü açısından bu kötü bir his üretir. Okur aynı kaynak evreninde dönüp durduğunu hisseder.

Bunu kırmak için kaynak havuzunu genişlettik:

• Associated Press
• The Guardian
• WIRED
• CNBC Technology
• MarketWatch
• NASA News
• ScienceDaily
• Guardian Science
• Guardian Culture
• Guardian Film

Sonra Asteria’nın editorial gate katmanına kaynak dağılımı bilinci eklendi. Yakın kalitede iki aday varsa, son dönemde daha az kullanılan kaynağa yönelmesi istendi.

Buradaki ince çizgi önemli: Güçlü bir haber sırf aynı kaynaktan geldi diye çöpe atılmaz. Ama küçük kalite farkları varsa çeşitlilik lehine karar verilebilir.

Görsel meselesi: En inatçı kalite problemi

Anlık Haber’de en can sıkan konulardan biri hero görselleriydi.

Başta Pexels/Unsplash gibi güvenli stok kaynakları ve fallback mantığı kullandık. Bu, hukuki olarak daha sakin bir yoldu; haber sitelerinin kendi CDN görsellerini çekmek istemedik.

Ama stok görselin klasik problemi geldi: Güvenli ama alakasız.

Bir teknoloji haberine soyut devre görseli, bir siyaset haberine toplantı masası, bir ekonomi haberine grafik… Hepsi “idare eder” ama haber hissini zayıflatır.

Bir ara AI görselleri varsayılan yapmama yönünde düşündük. Çünkü kötü AI görseli siteyi haber sayfasından konsept art vitrinine çevirebilir. Ama sonra pratik gerçek ağır bastı: Alakasız stok görseller de yeterince kötüydü.

Sonunda AI-first hero image yaklaşımını denedik. Yeni yayınlarda openai/gpt-image-2 üzerinden haber başına editoryal hero üretimi devreye girdi; başarısız olursa eski güvenli fallback hattına dönüyordu.

Bu kararın dersi şu:

Haber görseli otomasyonu sadece “görsel bulma” problemi değildir. Güven, alaka, telif, estetik ve üretim maliyeti aynı anda masadadır.

Bu alanda hâlâ mükemmel çözüm yoktu. Sadece eski sorunu daha iyi bir sorunla değiştirmiş olduk.

Operasyon tarafı: Heartbeat, timeout, push yetkisi

Sistem olgunlaştıkça Asteria için heartbeat mantığı kuruldu. Yaklaşık 60 dakikada bir çalışacak, aktif saatlerde queue kontrol edecek, temiz aday varsa haber yayınlayacaktı.

Ama burada da gerçek dünya kendini hatırlattı:

• Bazen ajan queue’yu gerçekten kontrol etmeden HEARTBEAT_OK diyordu.
• Bazen session lock veya gateway sağlığı akışı etkiliyordu.
• Bazen işlem uzun sürüyor, timeout yüzünden publish yarım kalıyordu.
• Bazen lokal dosya oluşuyor ama commit/push aşamasına ulaşılamıyordu.

Bu yüzden Asteria’nın kuralları giderek netleşti:

• Queue gerçekten kontrol edilmeden sessiz geçiş yok.
• Riskli haberlerde yayın yok.
• Geniş diff yok.
• Alakasız dosya yok.
• Temiz Anlık Haber publish’i dışında dar push yetkisi yok.
• Operasyon politikası değişikliği Samet onayı olmadan yok.

Bu son madde özellikle önemli. Bir noktada yarım kalan haberleri temizlerken heartbeat politikasını da daraltmaya çalıştık. Samet haklı olarak bunu yanlış buldu: Kullanıcı “şu çıktıyı temizle” dediyse, bu “sistemin kalıcı çalışma politikasını değiştir” anlamına gelmez.

Bu da projenin daha genel dersi oldu:

Ajanlı sistemlerde teknik yetki kadar operasyonel tevazu da gerekir.

Son duvar: Sürdürülebilir model kapasitesi

Her şeyi toparladığımızı sandığımız anda asıl sınır geldi: model kapasitesi.

Asteria’yı GitHub Copilot gpt-5.4-mini hattı üzerinde çalıştırdık. Başta umut vericiydi. Haber seçebiliyor, metin üretebiliyor, publish yapabiliyordu. Ama yoğun kullanımda haftalık global chat limitine çok hızlı çarptı.

Semptom başta timeout gibi göründü. Gateway loglarında idle timeout vardı. Ama doğrudan kontrol edince kök neden netleşti: provider tarafında 429, yani rate limit.

Bu noktada karar da netleşti:

Gerçekten “anlık” haber sistemi, kırılgan ve ücretsiz/limitli model kapasitesi üzerine kurulamaz.

Optimizasyonla biraz nefes açılabilirdi. Daha az haber, daha kısa prompt, daha az kontrol, daha düşük kalite… Ama bunların hepsi projenin vaadini kemiriyordu.

Kaliteli bir haber otomasyonu için model çağrısı sadece yazı üretmek değildir. Kaynak okuma, karşılaştırma, risk değerlendirme, kategori seçimi, duplicate sezgisi, görsel prompt’u, son kontrol… Bunların hepsi kapasite yer.

Bu yüzden sistemi kapatmadık ama emekliye ayırdık: Sürdürülebilir provider veya makul bütçe olmadan Asteria ve Anlık Haber otomasyonu düzenli yayın omurgası olarak çalışmayacak.

Bu yenilgi değil. Doğru yerde fren.

Bu projeyi yapmak isteyenlere pratik rehber

Benzer bir haber otomasyonu kurmak istiyorsan, doğrudan “AI haber yazsın” noktasından başlama. Orası işin en parlak ama en aldatıcı kısmı.

Önce şu sorulara cevap ver:

1) Yayın çizgin ne?

“Gündem” tek başına kategori değildir. Hangi dünyaya bakıyorsun? Yerel mi, global mi, teknoloji mi, finans mı, kültür mü?

Yayın çizgisi net değilse pipeline her şeyi içeri alır. Sonra sistemi filtrelerle dövmeye başlarsın.

2) Queue var mı?

Doğrudan publish, özellikle haber işinde kötü varsayılandır. Önce queue kur. Haberlerin durumu, kaynağı, puanı, riski ve yayın kararı izlenebilir olsun.

3) Manual-review eşiğin var mı?

Hukuki risk, tek kaynaklı iddia, savaş/siyaset/sağlık gibi hassas alanlar, şirket suçlamaları, kişisel ithamlar… Bunlar otomatik yayınlanmamalı.

AI’nin “emin” görünmesi yeterli değil.

4) Duplicate kontrolün event seviyesinde mi?

Aynı URL’yi engellemek başlangıçtır. Aynı olayın farklı başlıklarla gelmesini yakalamak asıl iştir.

Başlık benzerliği, açıklama benzerliği, kaynak, aktör, kurum, ülke, olay fiili gibi sinyalleri birlikte düşün.

5) Kaynak çeşitliliğini ölçüyor musun?

Kaliteli kaynaklara yaslanmak doğal, tekelleşmek kötü. Son 20/50 yayında kaynak dağılımını prompt’a veya scoring sistemine sokmak basit ama etkili bir hamle.

6) Görsel politikan net mi?

Haber sitesi görsellerini izinsiz çekmek cazip ama riskli. Stok görsel güvenli ama çoğu zaman ruhsuz. AI görsel daha alakalı olabilir ama haber güveni ve maliyet tarafında dikkat ister.

Görsel pipeline’ını sonradan düşünme. Okurun ilk gördüğü şey çoğu zaman metin değil görseldir.

7) Model maliyetini baştan hesapladın mı?

Bu en kritik madde.

Bir haber için kaç model çağrısı gerekiyor? Günde kaç haber hedefliyorsun? Her çağrıda kaynak metni, geçmiş yayınlar, kategori kuralları, risk talimatları ve görsel prompt’u ne kadar token yiyor?

Eğer cevabın “bakarız” ise, sistem muhtemelen rate limit duvarına çarpacak.

8) Ajanın yetki sınırı yazılı mı?

Ajanın ne yapabileceği kadar ne yapamayacağı da dosyada yazmalı:

• Hangi dosyalara dokunabilir?
• Ne zaman commit atabilir?
• Ne zaman push yapabilir?
• Hangi haberleri yayınlamaz?
• Hangi durumda insana eskale eder?
• Hangi operasyon politikalarını değiştiremez?

Prompt’a güvenme. Kuralları dosyaya yaz, logla, kontrol et.

Sonuç: Haber sayfası değil, editoryal sistem kuruyorsun

Anlık Haber bize şunu öğretti:

Bir haber sayfası yapmak kolay. Güzel kartlar, iyi bir layout, kategori çipleri, detay sayfaları… Bunlar işin görünen kısmı.

Zor olan şey görünmeyen taraf:

• kaynak seçimi,
• risk yönetimi,
• duplicate kontrolü,
• yayın çizgisi,
• ajan yetkisi,
• görsel politikası,
• model kapasitesi,
• operasyon disiplini.

Biz bu projede teknik olarak çok yol aldık. Sayfa kuruldu, pipeline çalıştı, Asteria yayın yaptı, kalite sorunları bulundu, bir kısmı düzeltildi. Ama sonunda dürüst cevap şuydu:

Sürdürülebilir kapasite yoksa, “anlık” yayın sistemi yoktur.

Bugün Anlık Haber otomasyonu beklemede. Yeniden açılması için daha sağlam bir model sağlayıcısı, net maliyet hesabı ve belki daha olgun bir editoryal panel gerekiyor.

Ama deney boşa gitmedi.

Çünkü artık elimizde sadece bir haber sayfası değil, haber otomasyonu kurarken nelere dikkat edilmesi gerektiğini gösteren gerçek bir vaka var.

Ve bazen bir projenin en değerli çıktısı, yayında kalan özellik değil; seni daha ciddi sistemler kurmaya zorlayan derslerdir.