Üretim yapay zeka ajanını GPT-5.6’ya geçirerek 2,2 kat hızlandırıp %27 ucuzlatma süreci

 (ploy.ai)
1 puan yazan GN⁺ 7 시간 전 | 1 yorum | WhatsApp'ta paylaş
  • Ploy, üretim pazarlama web sitelerini planlayan, oluşturan ve doğrulayan ajanını Claude Opus 4.8’den GPT-5.6 Sol’a geçirdi ve bunu tüm çalışma alanları için varsayılan model olarak belirledi
  • Değerlendirme altyapısındaki modele özgü varsayımlar düzeltildikten sonra, ana sayfa yeniden oluşturma işinde ortalama çalışma süresi 8 dakikadan 3 dakika 42 saniyeye düştü; maliyet $3.06’dan $2.22’ye inerek %27 azaldı ve görsel skor da 0.970’e yükseldi
  • GPT-5.6, araç çağrılarındaki 25 isteğe bağlı parametrenin tamamını rastgele değerlerle doldurduğu için dosya okumalarının %52~64’ü boş sonuç döndürüyordu; isteğe bağlı alanlar zorunlu ve nullable hâle getirilince boş okumalar %0’a indi ve araç çağrıları da yaklaşık %30 azaldı
  • OpenAI ile Anthropic’in önbellek kapsamı ve işlem hacmi yapısı arasındaki farklar nedeniyle GPT-5.6 başlangıçta yaklaşık %50 daha pahalı ölçüldü; ancak çalışma alanı düzeyinde önbellek anahtarı ve katmanlı breakpoint’ler uygulanarak ilk çağrı isabet oranı %0’dan %83,7’ye çıkarıldı ve önbelleğe alınmamış giriş token’ları %28 azaltıldı
  • Model değiştirmenin maliyeti ve performansı yalnızca modelin kendisine değil, değerlendirme bütçesine, araç şemasına, önbellek yapısına ve akıl yürütme yeniden oynatma biçimine de bağlı olduğundan, güvenilir karşılaştırma ve kararlı işletim için önce mevcut modele göre ayarlanmış sağlayıcıya özgü varsayımları bulup düzeltmek gerekir

Claude Opus’un yerini alan GPT-5.6 Sol

  • Ploy ajanı, üretim pazarlama web sitelerindeki sayfaları planlar, kod tabanını okur, bileşenler ve görseller üretir, sonucu ekran görüntüsüyle kontrol eder ve işin tamamlanıp tamamlanmadığına karar verir
  • Aylar boyunca Claude Opus’un yerini alacak ölçütleri karşılayan bir model çıkmadı; varsayılan model 4 ay boyunca sırasıyla Opus 4.7 ve 4.8 olarak kaldı
  • GPT-5.6 Sol, aynı işler üzerinde yapılan bire bir değerlendirmede ilk kez Opus’u geride bıraktı ve tüm Ploy çalışma alanlarının varsayılan modeli oldu
  • İlk değerlendirmelerde de tamamlanan build’lerin çalışma süresi yarıdan azdı, maliyet %27 daha düşüktü ve mevcut modelle aynı ya da daha yüksek skorlar aldı; bu da geçişi ilerletmek için dayanak oluşturdu
  • Ploy Vercel AI SDK kullanıyor; ancak model geçişi sırasında araç argümanı oluşturma, prompt önbellekleme ve turn’ler arası akıl yürütme yeniden oynatma konusunda sağlayıcıya özgü varsayımların stack’in geneline yayıldığını keşfetti
  • Migrasyon, değerlendirme altyapısı, araç şeması, prompt önbellekleme ve akıl yürütme yeniden oynatma sırasıyla düzeltilerek ilerledi

Değerlendirme sayılarına güvenmeden önce altyapıyı düzeltmek

  • Değerlendirme paketi, üretim ajanını sabit test çalışma alanlarında çalıştırır; ana sayfayı sıfırdan oluşturma işinden, kopyalama isteğinin güvenli biçimde yürütülüp yürütülemeyeceğini belirlemeye kadar yüzlerce vakayı kapsar
  • Build vakalarında görsel değerlendirici, referans tasarımla karşılaştırarak 10 ikili kontrol yapar
    • hero alanının ekranın tüm genişliğini dolduran bir fotoğraf sahnesi olup olmadığını kontrol eder
    • ana CTA’nın pill biçiminde değil, yuvarlatılmış köşeli dikdörtgen olup olmadığını doğrular
  • İçerik kontrolleri, araç yürütme yolu kontrolleri ve dosya assertion’ları da birlikte yapılır; başarısızlık durumunda araç çağrıları ve model metnini içeren tam çalışma izi incelenir

  • Mevcut modelin çağrı biçimine göre ayarlanmış kısıtlar

    • Mevcut araç çağrı bütçesi Opus’un sıralı çağrı biçimine göre ayarlanmıştı; GPT-5.6 ise paralel çağrılar kullandığı için sorunu doğru çözdüğü vakalarda bile bütçeyi aşıyordu
    • Değerlendirme çalıştırıcısı, Opus’un neredeyse hiç kullanmadığı toplu dosya okumayı desteklemiyordu; GPT-5.6 ise bunu sık kullanıyordu
    • İlk çalıştırmada ortaya çıkan ham başarısızlıkların yaklaşık üçte biri model davranışından değil, altyapının varsayımlarından kaynaklanıyordu ve modeller arasında eşit dağılmıyordu
    • Meydan okuyan model ile mevcut modelin çalışma izleri önce sınıflandırılmazsa, yeni model mevcut model gibi davrandıkça değerlendirmede avantajlı hâle gelir

  • Örtük skor eşikleri

    • minScore eksik olan veri kümeleri, hiçbir uyarı olmadan varsayılan 1.0 değerini devralıyordu
    • Bu yüzden GPT-5.6, hero skoru 0.98 olmasına rağmen başarısız sayıldı; Opus da tüm tekil kontrolleri geçtiği bir vakada başarısız olarak değerlendirildi
    • Her iki sonuç da savunulabilir tasarımlardı; ancak modelden değil, örtük eşikten dolayı elendiler

Düzeltilmiş benchmark sonuçları

  • Altyapı düzeltildikten sonra, marka ana sayfasını referans tasarıma uygun şekilde yeniden oluşturan değerlendirme paketi tekrar çalıştırıldı
Tamamlanan build başına ortalama Claude Opus 4.8 (n=11) GPT-5.6 (n=10)
Maliyet $3.06 $2.22
Çalışma süresi 8 dakika 00 saniye 3 dakika 42 saniye
Giriş token’ları 2,6 milyon 1,7 milyon
Çıkış token’ları 33.000 17.100
Görsel skor 0.936 0.970
  • GPT-5.6 sayfayı 2,2 kat daha hızlı tamamladı, maliyet %27 daha düşüktü ve çıkış token’ı da yaklaşık yarı yarıya daha az kullandı
  • Ürettiği kod miktarı da daha azdı
    • Bir karşılaştırma çiftinde Opus, çoğu kullanılmayan renk aileleri de dâhil olmak üzere 174 CSS değişkeni ve 17.957 karakterlik globals.css üretti
    • GPT-5.6 ise 45 CSS değişkeni ve 2.508 karakter kullanmasına rağmen benzer ya da daha iyi render sonuçları verdi

  • Tasarım kalitesi ve tutarlılığı

    • GPT-5.6 temiz, sık grid’li düzenlerde güçlü; ancak güçlü biçimde yönlendirilmezse bu stile yakınsama eğilimi gösteriyor
    • Opus 4.8 için tasarlanmış mevcut altyapıda, mevcut tasarım sistemini göz ardı edip sık sık temiz ama sıradan çıktılar üretiyordu
    • Tasarım ve mühendislik ekipleri modeli yönlendirme biçimini iyileştirdikten sonra, üretim için gereken marka uyumu standartlarını karşıladı

Araç çağrılarında isteğe bağlı parametrelerin işlenmesi

  • Ajanın code aracında 25 üst düzey parametre vardır; yalnızca action zorunludur, diğerleri isteğe bağlıdır
  • Claude yalnızca kullandığı 2~3 parametreyi gönderirken, GPT-5.6 her çağrıda 25’inin tamamını gönderir; kullanılmayan alanları da offset: 0, timeout: 120000, siteId: "00000000-0000-0000-0000-000000000000" gibi makul görünen değerlerle doldurur
  • 3 gün boyunca toplanan üretim code(read) çalışma izlerinde de aynı örüntü görüldü
Model Çağrı sayısı 25 özelliğin tamamını içeren çağrılar
gpt-5.6 6.635 6.635 çağrı, %100
claude-opus-4.8 2.898 4 çağrı, %0,1
claude-sonnet-5 1.933 0 çağrı

  • Boş dosya okumalarının nedeni

    • Sorun yalnızca argümanların uzun olması değildi; dosya okuma implementasyonu, modelin rastgele oluşturduğu değerlerle kullanıcının amaçladığı değerleri ayırt edemiyordu
    • Implementasyon offset: 0 değerini gerçek argüman olarak işledi ve GPT-5.6 dosya okumalarının %52~64’ü boş sonuç döndürdü
    • Araç hem geçerli okuma hem de boş okuma için success: true döndürdüğünden, model boş dosya okuduğunu anlayamıyordu
    • Boş sonuçları telafi etmek için daha fazla çağrı yapıyor, bu da sonuç kalitesini daha da düşürüyordu

  • Prompt ve strict modla çözülmeyen sorun

    • Araç açıklamasına kullanılmayan parametreleri atlamasını söyleyen talimat eklense de 25 parametrenin tamamı üretiliyordu
    • Her özelliğe OPTIONAL, omit if unused eklense de davranış değişmedi
    • OpenAI’nin strict modunda da aynı sonuç alındı; ayrıca bunu kullanmak için tüm şemalardan pattern, format ve dizi boyutu doğrulamalarını kaldırmak gerekiyordu
    • Bu davranış, modelin function calling üretme biçiminden kaynaklandığı için prompt yerine şema değiştirildi

  • Sağlayıcı sınırında şema dönüşümü

    • OpenAI ailesindeki modeller için tüm isteğe bağlı özellikler, anyOf: [T, null] biçiminde zorunlu ve nullable özellikler olarak yeniden yazıldı
    • Model kullanılmayan parametreleri açık null olarak dolduruyor; paylaşılan araç çağrısı sınırında doğrulamadan önce null değerler kaldırılıyor
    • Araç implementasyonu değiştirilmeden, kullanılmayan değerleri ifade edebilmesi yalnızca modele verilen şemada sağlandı
    // Değişiklikten önce: 25 anahtarın tamamı rastgele değerlerle dolduruluyordu
{ "action": "read", "file_paths": ["..."], "offset": 0, "timeout": 120000 }

// Değişiklikten sonra: 4 gerçek değer ve 21 null gönderiliyor, araç çalıştırılmadan önce null’lar kaldırılıyor
{ "action": "read", "file_paths": ["..."], "offset": null, "timeout": null }
    • Değişiklikten sonra boş dosya okumaları %52’den %0’a düştü
    • Aynı iş için gereken araç çağrısı sayısı da yaklaşık %30 azaldı; boş sonuçları tekrar tekrar okuma davranışı ortadan kalktı

OpenAI biçimine göre prompt önbellekleme

  • Her iki sağlayıcı da prompt önbellekleme sunuyor, ancak implementasyon biçimleri farklı
  • Bu fark hesaba katılmadan önce GPT-5.6, Opus’tan yaklaşık %50 daha pahalı görünüyordu; ancak neden model fiyatı değil, önbellek yapılandırmasıydı

  • Anthropic’in organizasyon düzeyinde önbelleği

    • Ajan prompt’u, araç şeması ve temel sistem prompt’undan oluşan yaklaşık 29.000 token’lık statik bir önek ile başlar ve tüm konuşmalarda aynıdır
    • Claude’da cache_control ile önbellek breakpoint’i işaretlenir ve önek organizasyon genelinde paylaşılır
    • Hangi çalışma alanındaki konuşma olursa olsun tek bir paylaşılan öğeyi kullanabilir; anahtar başına işlem hacmi sınırı da yoktur
    • Önbellek isabet oranı %92~96’dır

  • GPT-5.6’da değişen önbellek davranışı

    • Önceki GPT modelleri örtük olarak kısmi önek eşleşmesini önbelleğe alıyordu; GPT-5.6 ise kısmi önek eşleşmesini kaldırdı
    • Örtük önbellek, en yeni mesajları temel alarak tam prompt öğesi oluşturduğu için aynı 29.000 token’lık statik öneki paylaşan yeni konuşmalarda bile ilk çağrıda önbellek isabet oranı %0’dır
    • Bu nedenle her konuşmada önekin tamamı önbelleğe alınmamış ücretle yeniden faturalandırılır
    • Uygulamanın önbellek kullanıp kullanmamasından bağımsız olarak GPT-5.6, tüm önbelleğe alınmamış prompt’lara 1,25 kat önbellek yazma primi uygular

  • Açık önbellek anahtarının kısıtları

    • Açık önbellekleme için prompt_cache_breakpoint ve zorunlu prompt_cache_key gerekir
    • Anahtar da önbellek kimliğine dâhil olduğundan, aynı prompt bile anahtar farklıysa isabet almaz
    • Her anahtar, dakikada yaklaşık 15 isteği işleyen bir önbellek node’una eşlenir; bu aşılırsa OpenAI trafiği bağımsız cold cache’e sahip başka node’lara dağıtır
    • Bu yüzden anahtarın hangi birimde tanımlanacağı temel tasarım kararı hâline gelir
    • Konuşma başına anahtar: Yeni konuşmalar paylaşılan önekte isabet alamadığı için ilk çağrı isabet oranı %0’dı
    • Tek global anahtar: Tüm istekler tek node’a hash’lenir; üretim trafiği 15 rpm’i aşınca cold node’lara taşar
    • Çalışma alanı başına anahtar: Müşteri çalışma alanındaki tüm konuşmalar öğeleri paylaşırken anahtar başına trafik düşük kalır

  • Çalışma alanı düzeyinde katmanlı önbellek

    • Gerçek yapılandırma ws:{workspaceId} biçiminde çalışma alanı düzeyinde anahtar kullanır ve sistem prompt’unu breakpoint katmanlarına böler
    • Öğe A, araçları ve statik öneki içererek oturumun ilk çağrı maliyetini azaltır
    • Öğe B, statik öneke çalışma alanı bağlamını ekler
    • Öğe C, ilk turn’den en yeni mesaja kadar uzanan oturuma özgü tam prompt zinciridir
    • Çalışma alanı belleği değiştiğinde Öğe B ıskalar, ancak Öğe A isabet etmeye devam eder; böylece 29.000 token’ın tamamı yerine yalnızca değişen bağlam boyutu yeniden yazılır
    • Öğe C’de prompt katı bir append-only yapıda olduğundan, oturum içinde OpenAI’nin örtük tam prompt zincirinden yararlanılır
    • OpenAI’nin anahtar bölümlemesi nedeniyle statik önek çalışma alanları arasında paylaşılamaz
    • Buna karşılık Anthropic, anahtar bölümlemesi olmayan organizasyon düzeyinde önbellek kullandığı için önek paylaşımı mümkündür
    • GPT-5.6’da her çalışma alanı, boşta kalma zaman aralıklarında 29.000 token’ı bir kez cold write olarak yazar; maliyeti yaklaşık $0.18’dır
    • Bu maliyet sınırlı kapsamdadır ve öngörülebilirdir

  • Önbellek düzeltmesinin sonuçları

    • İlk çağrı önbellek isabet oranı yaklaşık %0’dan %83,7’ye yükseldi
    • Toplam önbelleğe alınmamış giriş token’ları %28 azaldı
    • GPT-5.6’nın değerlendirme paketi başına maliyeti Opus’tan düşük hâle geldi; başlangıçtaki maliyet farkının tamamı yanlış önbellek yapılandırmasından kaynaklanıyordu
    • Modeller arası maliyet karşılaştırması, modellerden yalnızca biri cold cache ile başlatılmışsa geçerli değildir

Akıl yürütme yeniden oynatmasını kendi kendine yeterli hâle getirme

  • GPT-5.6 Responses API, varsayılan olarak önceki turn’ün akıl yürütmesini sunucu tarafındaki öğe referanslarıyla yeniden oynatır; üretim konuşmalarında aralıklı olarak Item 'rs_...' not found hataları oluştu
  • store: false ayarlandığında SDK şifrelenmiş akıl yürütme içeriği ister ve sunucu durumunu gösteren pointer yerine kendi kendine yeterli blob’u yeniden oynatır
  • Uygulamanın gönderdiği baytlar append-only yapıda olsa bile, sunucu tarafındaki akıl yürütme durumu geçerli prompt’u değiştirebilir
  • Değerlendirme altyapısı, araç şeması, prompt önbelleği ve akıl yürütme yeniden oynatması düzeltildikten sonra GPT-5.6 Sol, Ploy’un üretimde varsayılan modeli olarak çalışıyor

İlgili okumalar

1 yorum

 
GN⁺ 7 시간 전
Hacker News yorumları

  • “Bu ölçekteki rakamlar modeli gerçekten taşımaya değer” gibi ifadeler fazlasıyla gülünç. Yazıyı yazdıran kişinin en azından tipik LLM üslubunu biraz törpülemesi iyi olurdu.
    Kısa ifadeleri iki nokta, virgül ve noktayla birbirine ekleme biçimi de berbat ve bunaltıcı. GPT-5.6’da kısmi önek eşleşmesi önbelleğinin kalktığı gibi iyi içgörüler var, ama okuması rahat bir yazı değil.

    • Bu yüzden AGENTS.md veya CLAUDE.md’nin yanına her zaman WRITING.md koyuyorum. Çoğu kişi modele yalnızca ne üretmesi gerektiğini söylüyor, nasıl yazması gerektiğini ise neredeyse hiç söylemiyor; oysa LLM’ler açık üslup yönergelerini şaşırtıcı derecede iyi takip ediyor.
      Gereksiz iki noktadan, uzun tirelerden, vurgu kılığına girmiş cümle parçalarından ve sık yaptığım dilbilgisi hatalarından kaçınması için kurallar yazdım; teknik yazının açık, konuşma diline yakın ve gösterişsiz olması için Brian Kernighan ile Rob Pike’ı da referans olarak ekledim. Belgeler yalnızca kolay okunur değil, okunmak istenir olmalı.
      Sık belge üretiyorsanız ajanın WRITING.md’ye başvurmasını sağlamak çok değerli. Çoğu zaman okunabilirliği en yeni modele geçmekten çok daha fazla artırıyor ve model değişse bile üslubu tutarlı tutabiliyorsunuz.
    • Özellikle bir AI şirketi söz konusuysa daha da kötü görünüyor. Ya modelleri yeterince kullanmadıkları için kendine özgü üslubu bilmiyorlar, ya bunun önemli olduğunun farkında değiller, ya genel durumu anlamıyorlar ya da okura saygı duymuyorlar demektir; seçeneklerin hiçbiri iyi değil.
    • Okuma biçiminiz yanlış. LLM’den kendi üslup tercihlerinize göre okuyup özetlemesini istemelisiniz. Hatta daha da ileri gidip hiçbir şeyi doğrudan okumayın; ajanın bunu daha sonra başvuracağı bir skill dosyasına dönüştürmesini sağlayın.
    • Bir yazının LLM ile yazıldığından şüphelenirsem hemen okumayı bırakıp kullandığım LLM aracına özetletiyor veya yeniden yazdırıyorum. Böylece en azından çıktı üslubu üzerinde bir ölçüde kontrol sahibi olabiliyorum.
    • Şu an kullandığım claude.md’de “load-bearing” ifadesini yasakladım; Claude bundan gerçekten nefret ediyor. Bazen yorumlarda “load-be…most specific” gibi takılacak kadar bu ifadeyi aşırı seviyor.

  • Eskiden 5.4-nano ve mini üzerinde çalıştırdığım çeşitli küçük ve basit iş akışlarını 5.6’ya taşıdım; genel olarak yazıda belirtilen aralıkta iyileşme gördüm, bazı sınıflandırma işlerinde kalite de arttı.
    Birçok şirkette bu tür model yükseltmeleri fiilen tek satırlık kod değişikliğidir. Kritik iş akışları için mükemmel bir model router mimarisi kullanıyoruz, ama basit işler için bunu kurmaya değmez; ayrıca kararlılık sorunlarını da hesaba katmak gerekir.

    • Bu yazının ana noktası, model yükseltmesinin tek satırlık bir kod değişikliği olmadığı.
    • Hangi SDK’yi kullanıyorsunuz? Yoksa kendi uygulamanız mı?
    • Sol’u ilk kullanma amacımız, 5.6’yı iş akışlarımızda değerlendirmekti. Önceden basit modellerin kalitesi yetersiz olduğu için tüm işler için 5.5 kullanıyorduk; şimdi dağınık ham verilerden açık ve örtük yapılandırılmış verileri çıkarmak için metin ve görüntüleri birlikte analiz ediyoruz.
      Genel olarak reklam edildiği gibi çalışıyor. Şu anda işlerin çoğunu terra’ya göndererek maliyeti yarıya indirdik ve yanıt süresini de %50 iyileştirdik. luna’yı OpenCV tespit sonuçlarını tamamlamak için kullanıyoruz; işlevi çok sınırlı ama hızlı ve neredeyse bedava. Sol, bizim işlerimizde terra’dan yalnızca biraz daha iyiydi.
      Sol ultra değerlendirmeyi de çok iyi yaptı. Makul önerilerle birlikte, elle kontrol edilip karşılaştırılması gereken çıktıların listesi, ham ve işlenmiş veriler ve sorgu başına CPM içeren büyük bir materyal hazırladı. Pro abonelik ücreti dışında ekstra harcama yapmadan birkaç saat çalıştırdığımızda maliyet ölçütü %50 düştü, iş hacmi ise %100 arttı.

  • Benim deneyimim de benzer. OpenRouter gibi failover’ı öne çıkaran hizmetler, sandbox testleri dışında neredeyse işe yaramaz. Prodüksiyon modelleri gerçekte birbirinin yerine kullanılabilir değil ve ciddi ajan işlerini yürüten çalıştırma ortamları beklenenden çok daha fazla modele özgü özelliğe bağlı.
    Başka bir model hatasız çalışsa bile performans ve verim ayrı konular. Claude ailesi gibi, eğitim sürecinde alıştığı ifade biçimine göre sistem prompt’unu ayarlamanız gereken modeller var; bazı modeller ise farklı ayırıcılarda daha iyi çalışıyor. En iyi performans önemliyse çalıştırma ortamı, prompt ve modeli tek bir sistem olarak görmelisiniz; bunların parça gibi serbestçe değiştirilebileceğini düşünmemelisiniz.

    • LLMOps’un bir parçası olarak araç yürütme yollarını vb. düzgün denetleyen bir failover planı oluşturmalısınız. Böylece yeterince iyi modelleri ucuzdan pahalıya doğru sıralayıp istediğiniz failover’ı gerçekleştirebilirsiniz.
      model -> {{prompts}, {tools descriptions}, ...} biçiminde eşleme tabloları yapanları da gördüm, ama bu fazla uç. Bir noktadan sonra modelin bizim prompt’larımıza uyum sağlaması gerekir; bunu yapamayan modelleri failover adaylarından çıkarır ve API isteği göndermeyiz.
    • OpenRouter başka bir modele failover yapmaz; aynı modeli sunan başka bir sağlayıcıya geçer.

  • Derin altyapı içgörüleriyle dolu bir yazının altında yorumların yarısının yalnızca zorlama üslubu eleştirmesi ironik. Claude cümleleri parlatmaya yardım etmiş olsa bile, API bütçesini %30 azaltan ve boş dosya okumalarını düzelten hemen uygulanabilir bir plan içeriyorsa asıl önemli olan bu değil mi?

    • Yapay zekayla ilgili her şeyden nefret edip kusur arayanlar olabilir, ama gerçekten bu üsluba katlanamadığı için yalnızca buna takılanlar da olacaktır.
      Şahsen üslup hakkında söylenmeyi komik buluyorum. Dilbilgisi ve imlada zayıf olduğumdan belki de aktarım biçiminden çok kavramlar, olgular ve argümanlar gibi asıl içeriğe odaklanıyorum. Dilbilgisi ve imla yalnızca ağaçlar; mesele ormanın kendisi.
      Yazılarımda çok fazla hata olmamasını dikteye ve kendi yaptığım kısayollara borçluyum. Seçili metni yerel LLM ile düzelttirip yerine koyuyor; yaşam kalitemi ve yazma kalitemi bu iki araç kadar artıran başka bir şey olmadı.

  • “Ploy ajanı bugünden itibaren bu sabah yayımlanan GPT-5.6 Sol’u kullanıyor” deniyor; yani sadece yarım günlük test sonucuyla mı geçiş yaptılar? Şirketi ergenler mi yönetiyor?

    • Aslında çalışan profili daha çok Staff ve Senior Staff seviyesine yakın. YC bağlantıları üzerinden GPT-5.6 önizleme modelini yaklaşık bir hafta test edip geri bildirim sağladılar
      Değerlendirme işleri GitHub CI üzerinde çalışıyor; ploy.ai’nin uzmanlık alanı olan web tasarımı ve pazarlama işlerinden oluşan 115’ten fazla değerlendirme setinin tamamı yaklaşık 15 dakikada çalıştırılabiliyor. PostHog feature flag ile modeli açtıktan sonra da hataları aktif biçimde izlediler
      İnternetin %1’inden fazlasına destek veren Webflow’u işletirken edinilen bilgiyi Ploy’a mümkün olduğunca aktararak internetin daha büyük bir kısmını desteklemeye çalışıyorlar
    • Böyle bir yazı yazabilecek şekilde değerlendirme yapmaları için bir miktar erken erişim almış olmaları gayet olası
    • Artık değerlendirme ve benchmark oluşturup bunları en yeni modellerde çalıştırmak oldukça kolay. LLM’ler kolay değiştirilebildiği için iyi bir değerlendirme seti çok yararlı; bazen de iyileşme o kadar belirgin olur ki değerlendirmeye bile gerek kalmaz
    • Yeni modeli karşılaştırmak için prodüksiyon tabanlı bir veri setine sahip olduklarını tahmin ediyorum

  • Ploy ajanının gerçek pazarlama web siteleri oluşturup düzenlediği; planlama, kod tabanını okuma, bileşen yazma, görsel üretme, kendi sonucunun ekran görüntüsünü alma ve tamamlanıp tamamlanmadığına karar verme gibi işler yaptığı söyleniyor. Yine de sıkı test yapılmamış olsa bile Fable’ın pazarlama sitesi üretiminde Opus’tan çok daha iyi olacağını beklerim. Sunum materyali üretiminde kesinlikle çok daha iyi

    • Tasarım konusunda GPT-5.6, Fable’dan çok daha iyi
    • 4.7’nin talimatları aşırı kelimesi kelimesine takip etme eğilimi var; bu yüzden kaynak yazıdaki sonuç da gayet makul olabilir

  • OpenAI ailesi modellere özel olarak tüm opsiyonel özellikleri hem zorunlu yapıp hem de anyOf: [T, null] ile null’a izin verecek şekilde değiştirme çözümü biraz kötü kokuyor. MCP’nin değiştirilmiş bir biçimini kullandım ama TypeScript tip tanımlarının ajandan çıkarım backend’ine gönderilen JSON Schema’yı neden etkilediği net değil
    MCP spesifikasyonunda opsiyonel parametreleri temsil eden alan açıkça var; bu yüzden TypeScript katmanı ile gerçekten gönderilen araç açıklaması arasında bir yerlerde bug var gibi görünüyor. Çıkarım backend’i “geçerli araç yanıtı üretme”den “opsiyonel parametresi olmayan JSON Schema’ya uygun geçerli yanıt üretme”ye geçmiş de olabilir; ama gerçek isteği görmeden karar vermek mümkün değil

    • Bu, şema üretimi ya da TypeScript bug’ı değil, OpenAI function calling’in iç işleyişi. Araç kullanımı için ince ayar yapılmış ağırlıklar, mümkün olduğunca eksiksiz veri yapıları çıktılamaya çalışır. Model sistem prompt’u bağlamında parametre adlarını gördüğünde, required dizisinde olmasalar bile değer doldurmaya çalışır
    • Fable, Opus ve 5.6 dahil güncel öncü modeller, araç çağrılarında oldukça gevşek davranıyor ve çoğu zaman şemayı tam olarak takip etmiyor. Pi’nin düzenleme/değiştirme araç çağrılarında Claude modellerinin var olmayan özellikler uydurduğu örnekler https://lucumr.pocoo.org/about/ adresinde görülebilir
      Sebebin bir kısmı, kısıtlı decoding kullanıldığında zekânın düşmesi olgusuyla ilişkili görünüyor. Şema geçerliliği garanti edilir ama yetenek ciddi biçimde azalır; bu yüzden sınıflandırma, özetleme ve prompt iyileştirme için uygun olsa da ajan döngülerinde dikkatli olmak gerekir
      Claude Code gibi çalışma ortamları ön işleme, kurtarma, temizleme vb. birçok işlem yapar ama bunlar genelde görünmez. Kusursuz doğruluğu varsayıp zorlamak yerine çalışma ortamını daha gevşek hale getirip model bazlı özelliklere uyarlamak pratikte daha kolay ve daha iyidir. Modeller de zaten bir iki ayda bir değişiyor. Hissiyatla yapılan uygulamalı yapay zeka budur

  • Opus ve Sol ile bir site oluşturmanın gerçek maliyetinin her biri için kabaca ne kadar olduğunu merak ediyorum

  • İş akışını Reasonix’e taşıyıp DeepSeek’te cache hit’lerden yararlanınca, sübvanse edilmeyen ABD sağlayıcıları kullanırken bile istek maliyeti fiilen bedavaya yakın hale geldi

    • Hangi kurulumu kullanıyorsunuz ve Pi ile karşılaştırınca nasıl?

  • Tüm Ploy workspace’lerinde varsayılan olarak GPT-5.6 Sol kullanmak yerine, gerçek araçlarla uğraşan işlerin bir kısmı için Luna değerlendirilebilir. Şaşırtıcı derecede yetenekli ve hızlı
    Sol, insanlarla konuşmak ve ajan çağrılarını koordine etmekte harika; ama her işte kullanmak için fazla pahalı. Sol’un tek çalıştırma maliyetine Luna beş kez çalıştırılabilir; istatistiksel olarak bir örneğin beş örneğe çıkması ciddi bir farktır

    • Luna çalıştırmasının her adımı %90 olasılıkla doğruysa beş adımın tamamının doğru olma olasılığı 0.9^5 = 0.59, yani %59. Sol’un tek çalıştırmadaki doğruluğu yaklaşık %95 olabilir. Gerçek sayılar değişir ama sonunda Sol ile doğrulamak daha ucuz olabilir
    • Alt ajanlarda her zaman birbirinden izole olma sorunu vardır. Bağlamı küçük tutup odaklanmalarını sağlamak gibi bir avantajı var; ancak kendilerine verilen işi sürdürebilmek için her birinin yeniden araştırma yapması gerekir ve bu da çoğu zaman cache’lenmemiş token tüketir
      Bir işte kaç ajan kullandığınıza bağlı olarak maliyet artarken sonuçlar aksine daha kötü hale gelebilir