Editörden

Günün en iyi yazısı OpenAI'dan geliyor ve konusu model değil: bir benchmark puanının aslında modeli değil onu çalıştıran *harness*'ı ölçtüğünü gösteriyorlar. İki API ayarı açınca puan üçe katlanmış. Bunu okuduktan sonra hiçbir benchmark tablosuna aynı gözle bakmayacaksın.

Günün Kapağı
OpenAI Research 29 Temmuz 20264 dk okuma orta

İki ayar puanı üçe katladı: benchmark modeli mi harness'ı mı ölçüyor?

How enabling two settings tripled our scores on the ARC-AGI-3 benchmark

OpenAI kendi modelinin bir benchmark'taki düşük puanına şaşırmış. GPT-5.6 Sol matematikte açık problemler çözüyor, Pokémon FireRed'i bitiriyor — ama 2B bulmaca oyunlarından oluşan ARC-AGI-3'te sadece %7,8 alıyor. Soru şu: 2B bulmacalar modeller için gerçekten mi bu kadar zor, yoksa başka bir şey mi oluyor?

Cevap ikincisi. Yazının kilit cümlesi şu: benchmark'lar modelleri yalıtılmış hâlde ölçmez. Aynı zamanda daha az görünür tercihleri de ölçerler — API ayarları, harness tasarımı ve prompt'lama. ARC-AGI-3 kasıtlı olarak jenerik bir harness kullanıyor: araç yok, özel özellik yok. Gerekçesi savunulabilir — basit harness modelin eksiklerini daha görünür kılar ve karşılaştırmayı adil tutar. Ama ticari geliştiriciler harness'ı optimize eder, dolayısıyla ölçülen şey iki dünyada aynı değildir.

OpenAI, ChatGPT ve Codex'te zaten kullandıkları iki API ayarını açmış: retained reasoning (akıl yürütmenin turlar arası korunması) ve compaction (bağlam dolduğunda geçmişin özetlenmesi). Sonuç: puan üçe katlanmış ve çıktı token'ları 6 kat azalmış. Yani hem daha iyi hem daha ucuz.

Öne çıkanlar

  • Aynı model, aynı görev, farklı harness → 3 kat fark. Puan farkının kaynağı modelde değildi.
  • Retained reasoning: modelin bir turdaki akıl yürütmesini sonraki turda kaybetmemesi. Ajanik döngülerde tekrar tekrar aynı şeyi düşünmesini önler.
  • Compaction: bağlam sınırına yaklaşırken geçmişi özetleyip yer açma. Uzun süren agent oturumlarında zorunlu hâle geliyor.
  • İyileşme token maliyetiyle gelmedi — tersine 6 kat daha az çıktı token'ı kullanıldı.

Neden önemli?

Model karşılaştırma tablolarını okurken bu yazıyı hatırla. Bir puan her zaman "model + harness + prompt + ayarlar" bileşiminin puanıdır. Kendi ürününde bir modeli değerlendirirken de aynısı geçerli: iki modeli farklı harness'larla karşılaştırırsan ölçtüğün şey model değil, senin kurulumundur.

Sende karşılığı

Bu yazı senin en somut faydalanabileceğin şeylerden biri. Bir LLM özelliği yazarken "model kötü" sonucuna varmadan önce şunları kontrol et: bağlam yönetimi doğru mu, önceki turların akıl yürütmesi korunuyor mu, prompt yapısı görevi net anlatıyor mu, araç açıklamaları modele *ne zaman* çağıracağını söylüyor mu? KlioAI'daki değerlendirme özelliğinde beklenenden kötü sonuç alıyorsan, ilk şüphelin model değil harness olsun. Ayrıca kendi değerlendirme setini kur: 20-30 gerçek örnek üzerinde kendi ölçümünü yapmak, dışarıdaki hiçbir benchmark tablosundan alamayacağın bir bilgidir.

Sözlük

harness koşum takımı
Modeli çalıştıran çerçeve: prompt yapısı, araçlar, bağlam yönetimi, döngü mantığı. Modelin kendisi kadar sonucu belirler.
retained reasoning korunan akıl yürütme
Modelin bir turda ürettiği düşünme adımlarının sonraki turlarda da bağlamda kalması.
compaction bağlam sıkıştırma
Konuşma geçmişi bağlam penceresini doldurmaya yaklaşınca eski kısmın özetlenerek yer açılması.
benchmark karşılaştırma testi
Modelleri standart bir görev kümesinde ölçen test; sonucu kurulum tercihlerinden bağımsız değildir.
Orijinali oku

Kısa Kısa

Cloudflare Blog 29 Temmuz 202612 dk okuma ileri

Kuantum sonrası kimlik doğrulama: neden şifrelemeden sonra sıra buna geldi

Post-quantum authentication to origins is now supported

Cloudflare'in kuantum sonrası (post-quantum) geçiş yol haritasında önemli bir eşik: origin sunucularına yapılan kimlik doğrulama artık kuantum sonrası algoritmalarla korunuyor.

Yazının en öğretici kısmı neden şimdi sorusunun cevabı. Son yıllarda odak şifrelemedeydi ve gerekçesi "şimdi topla, sonra çöz" (harvest-now/decrypt-later) saldırısıydı: saldırgan şifreli veriyi sessizce biriktirir, gelecekte kuantum bilgisayarla çözmeyi umar. Kimlik doğrulamada ise böyle bir gecikme yok — bir imzayı kırmak ancak canlıyken işe yarar. Ama kuantum hesaplama ve kriptanalizdeki son gelişmeler takvimleri öne çektiği için, artık klasik kimlik bilgilerini kırıp kimliğe bürünme (impersonation) saldırısı yapabilecek saldırganlara karşı da hazırlık başladı.

  • Cloudflare tam kuantum sonrası güvenlik için 2029'u hedefliyor; bu ilk kilometre taşı.
  • Ziyaretçi→Cloudflare ve Cloudflare→origin bağlantıları farklı tehdit profillerine sahip; ikisi ayrı ayrı ele alınıyor.
  • Yazıda "utanç verici bir itiraf" bölümü var — mühendislik yazılarında nadir görülen bir dürüstlük.

Sende karşılığı

Kuantum sonrası kriptografi bugün senin işin değil, ama iki kavram doğrudan işine yarar. Birincisi mTLS (karşılıklı TLS): sadece sunucu değil istemci de sertifikayla kimliğini kanıtlar — servisler arası iletişimde API anahtarından çok daha güçlüdür ve Spring Boot ile yapılandırılabilir. İkincisi tehdit modeli düşünmek: "bu veri 10 yıl sonra çözülse zarar verir mi?" sorusu, sağlık ya da finans verisi tutan her sistemde bugün sorulması gereken bir soru.

Sözlük

post-quantum cryptography kuantum sonrası kriptografi
Kuantum bilgisayarların kırabileceği klasik algoritmaların yerine geçen, kuantuma dayanıklı şifreleme ve imza yöntemleri.
harvest-now, decrypt-later şimdi topla, sonra çöz
Bugün çözülemeyen şifreli veriyi biriktirip gelecekte çözmeyi hedefleyen saldırı stratejisi.
mTLS (mutual TLS) karşılıklı TLS
Hem sunucunun hem istemcinin sertifikayla kimliğini kanıtladığı TLS kurulumu.
Orijinali oku
OpenAI Research 29 Temmuz 20267 dk okuma orta

Modeli hızlandırmak yetmiyor: çıkarım yığınının her katmanı

How GPT-5.6 fuses frontier intelligence with frontier efficiency

OpenAI, GPT-5.6 ailesinin verimlilik kazanımlarını anlatıyor ve yazının değerli kısmı model değil çıkarım yığını (inference stack). Ana tez tek cümlede: bir model yalıtılmış hâlde çok verimli olabilir, ama istekler kötü dağıtılıyorsa, donanım boş bekliyorsa ya da veri hareketi hesabı yavaşlatıyorsa sunması yine de pahalıdır.

Saydıkları optimizasyon katmanları klasik sistem mühendisliği: yük dengeleme, spekülatif kod çözme (speculative decoding), önbellekleme ve çekirdek (kernel) optimizasyonu. Yani kazanç tek bir yerden değil, her katmandan biraz gelmiş.

  • Talep kapasiteden hızlı büyüdüğünde verimlilik bir sistem tasarım kısıtı hâline geliyor.
  • Aynı model ailesinde Sol/Terra/Luna gibi kademeler var — zekâ, hız ve fiyat ayrı eksenler.

Sende karşılığı

"Sistem yalıtılmış hâlde hızlı ama üretimde yavaş" durumu senin de başına gelecek. Bunun tipik sebepleri bu yazıdakilerle aynı: istekler eşit dağılmıyor, kaynak boşta bekliyor, veri gereksiz yere ağdan geçiyor. Spring Boot'ta bir endpoint'in yerelde 20 ms, üretimde 400 ms sürmesinin cevabı genelde kodda değil bu üç yerden birindedir. Ölçmeden optimize etmeye başlama — önce nerede beklendiğini bul.

Sözlük

inference çıkarım
Eğitilmiş bir modeli çalıştırıp çıktı üretme aşaması.
speculative decoding spekülatif kod çözme
Küçük ve hızlı bir modelin birkaç token'ı tahmin etmesi, büyük modelin bunları toplu doğrulaması; üretimi hızlandırır.
Orijinali oku
Google Cloud Blog 29 Temmuz 20266 dk okuma orta

Veriyi taşımadan sorgulamak: Iceberg REST kataloğu

Introducing the borderless Lakehouse

Google Cloud, Apache Iceberg üzerine kurulu "sınırsız lakehouse" iyileştirmelerini duyuruyor: şirket içi sistemler, farklı bulutlar ve SaaS uygulamaları tek bir sorgu yüzeyinden erişilebiliyor — veriyi taşımadan.

Teknik anahtar Iceberg REST kataloğu üzerinden katalog federasyonu. Dosyaları kopyalamadan uzak veriyi keşfedip sorgulayabiliyorsun; farklı veri ekipleri Iceberg verisinin aynı kopyası üzerinde çalışıyor. SAP, Salesforce, Workday gibi uygulamalara sıfır-kopya entegrasyon da aynı fikrin uzantısı: BigQuery canlı uygulama verisini karmaşık ETL kurmadan doğrudan sorguluyor.

  • "Kopyalama yerine federasyon" son yılların en belirgin veri mimarisi eğilimi — her kopya bir tutarsızlık kaynağı.
  • Iceberg açık bir tablo formatı; kilitlenmeyi (vendor lock-in) azaltması bu mimarinin can damarı.

Sende karşılığı

Buradaki ilke küçük projelerde de geçerli: her veri kopyası bir senkronizasyon borcudur. Bir raporlama ihtiyacı için tabloyu ikinci bir yere kopyalamadan önce sor — kaynağı doğrudan sorgulayabilir miyim? PostgreSQL tarafında postgres_fdw (foreign data wrapper) tam olarak bunu yapar: başka bir veritabanındaki tabloyu yerelmiş gibi sorgularsın, kopya tutmadan. Küçük ölçekte federasyonun ne olduğunu anlamanın en hızlı yolu.

Sözlük

Apache Iceberg Apache Iceberg
Nesne depolamadaki büyük veri kümelerini tablo gibi yönetmeyi sağlayan açık tablo formatı.
zero-copy sıfır kopya
Veriyi çoğaltmadan, bulunduğu yerde sorgulama yaklaşımı.
catalog federation katalog federasyonu
Farklı sistemlerdeki tablo kataloglarının tek bir arayüzden görünür kılınması.
Orijinali oku