Zeki olduğumu sanıyordum. Bağlam penceresinin tam olarak yüzde otuzunu ... olarak ayıran bir yardımcı fonksiyon yazdım

Kendimi zeki sanıyordum. Yapay zeka boru hattımız (pipeline) için bağlam penceresinin (context window) tam olarak yüzde otuzunu bir düşünme bütçesi olarak ayıran bir yardımcı fonksiyon yazmıştım. Temizdi, öngörülebilirdi ve Opus 4.5 üzerinde harika çalışıyordu. Sonra Opus 4.8'e geçtim ve her bir istek 400 hatasıyla çöktü. Özenle hazırladığım token matematiği bir gecede çöp olmuştu.

Eski desen basitti. Bir budget_tokens değeri ayarlıyordunuz ve model, bu sınırın içinde kalmak için düşünme sürecini oranlıyordu. Eğer 128K bağlam sunsaydım, kodum muhakeme için yaklaşık 38.000 token ayıracak ve geri kalanını cevaba bırakacaktı. Bu, sorumluluk sahibi bir yaklaşım gibi geliyordu. Bir arabayı hız sınırının altında tutmak gibi.

O model artık yok. Opus 4.7 ve 4.8 gibi yeni sürümler adaptif düşünme (adaptive thinking) kullanıyor. Artık bir sayı seçmiyorsunuz. Bunun yerine bir çaba ayarı (effort knob) iletiyorsunuz. Bu kulağa sadece bir isim değişikliği gibi geliyor ama bu iki kontrol birbirinden çok farklı. budget_tokens, modelin ne kadar düşünmesine izin verildiğine dair katı bir tavan belirliyordu. Çaba (effort) ise modelin en başta nasıl düşündüğünü ve hareket ettiğini kontrol eder. Biri benzin pompası sayacıysa, diğeri motor haritasıdır.

Çabayı Gerçek İşlere Eşlemek

Kontrol mekanizması değiştiğinde, eski sezgilerim işe yaramaz hale geldi. Her bir ayarın gerçekte ne sağladığını yeniden öğrenmem gerekiyordu. Her bir çaba seviyesinin pratikte nereye denk geldiğini bulmak için dahili trafiğimiz üzerinde testler yaptım.

Sınıflandırma ve yönlendirme işleri neredeyse her zaman low çaba kullanmalıdır. Bunlar hızlı kararlardır. Bu bir iade talebi mi yoksa bir satış sorusu mu? Bu günlük girişi bir üst birime iletilmeli mi? Bir monoloğa ihtiyacınız yok. Düşük çaba, gecikmeyi (latency) düşük tutar ve maliyeti yok denecek kadar az hale getirir.

Çoğu uygulama trafiği —özetleme, yeniden yazma, destek yanıtları ve içerik çıkarma gibi günlük işler— medium ile high arası çabaya uygundur. Bu, denge noktasıdır. Model, geniş bir düşünce zincirine (chain of thought) ihtiyaç duymayan bir görevde token yakmadan, gerçek belirsizlikleri çözmek için yeterli alanı bulur.

Kodlama ve ajansal döngüler (agentic loops) xhigh çabaya ihtiyaç duyar. Hataların katlanarak büyüdüğü yer burasıdır. Eğer model, bir araç çağırma (tool-calling) döngüsünün ilk adımında kötü bir plan yazarsa, sonraki üç adımı hasarı onarmakla geçirecektir. Ya da daha kötüsü, yanlış araçları çağıracak, parametreleri uyduracak (hallucinate) ve kullanıcıyı bozuk bir iş akışına bakarken bırakacaktır. Başlangıçtaki daha iyi muhakeme, bu sarmalı önler.

Kritik görevler max çaba almalıdır. Bunu her şey için kullanmayın. Bunu, yanlış bir cevabın herhangi bir token faturasından daha maliyetli olduğu anlar için saklayın. Finansal mutabakatlar, güvenlik kontrolleri, mimari kararlar ve tıbbi triyaj bunun için doğru tercihlerdir. Eğer bir hata, bir insanın karmaşayı saatlerce çözmesini gerektiriyorsa, ekstra düşünme için ödeme yapın.

Maliyet Sürprizi

Zihinsel modelimi yıkan kısım şuydu: Maksimum çabanın maliyetlerimi her zaman şişireceğini varsaymıştım. Tek bir adımda, öyle yapıyor. Muhakeme izi (reasoning trace) daha uzun sürüyor. Ancak çok adımlı ajansal görevlerde, toplam fatura genellikle düştü.

Model ilk denemede daha iyi plan yapıyor. Daha az araç çağrısı yapıyor. Kendini çıkmaz sokaklara sapmaktan alıkoyuyor. Normalde beş karşılıklı tur gerektiren bir veri çıkarma ajanının, modelin başlangıçta şemayı doğru ayrıştıracak kadar muhakeme alanına sahip olması sayesinde iki turda işini bitirdiğini gördüm. Maliyeti ölçerken isteği değil, işin tamamlanmasını baz alın. Adım başına daha büyük bir düşünme bütçesi, toplamda daha az adım anlamına gelebilir.

Diğer Her Şeyi Bozmadan Nasıl Geçiş Yapılır

Eğer kod tabanınızda hala dolaşan bir budget_tokens varsa, işte çıkış yolu: Üçüncü ve beşinci adımları atlamayın. Ben atladım ve bu bana bir öğleden sonramı hata ayıklamakla (debugging) kaybettirdi.

Kodunuzda budget_tokens ifadesini arayın. Her bir örneğin kaldırılması gerekiyor. Bu parametre yeni modellerde artık geçersizdir ve 400 hatasını tetikleyecektir.

Bütçe nesnesini bir adaptif düşünme bloğu ile değiştirin. thinking: { type: "adaptive" } kullanın.

Her çağrı için açık bir çaba seviyesi içeren output_config ekleyin. Trafiğiniz karışık ise bunu küresel bir varsayılan değerde bırakmayın. Hafif sıklet sınıflandırma uç noktanız (endpoint), yanlışlıkla kodlama ajanınızla aynı çaba ayarını devralmamalıdır. Çağrı noktasında açık olun.

Bütçe hesaplama yardımcı fonksiyonunuzu silin. Biliyorum, muhtemelen birim testleri (unit tests) vardır. Benim de vardı. Ancak artık gereksiz bir yük. Platform sizin token matematiğinizi istemiyor. Model kendi temposunu kendisi yönetiyor.

temperature, top_p ve top_k parametrelerini çıkarın. Opus 4.7 ve 4.8'de, bu örnekleme parametreleri 400 hatalarına yol açacaktır. Platform, bu nesilden onları kaldırdı. Eski sıcaklık ayarlama (temperature-tuning) yöntemleriniz burada geçerli değildir ve onları bırakmak geçiş sürecinizi sessizce bozacaktır.

Her modeli ayrı ayrı test edin. Opus 4.5 ve 4.8 bambaşka yapılardır. Birinde çalışan bir yapılandırma, diğerinde mutlaka çalışmayacaktır. Birden fazla sürümü destekliyorsanız, mantığınızı dallandırın veya onları ayrı backend'ler olarak ele alın.

Kullanıcı Arayüzü (UI) Donmasını Düzeltme

Eğer yönetmezseniz, kullanıcılarınızın kafasını karıştıracak bir akış (streaming) davranışı mevcut. Yeni modellerde, düşünme blokları akış halinde gelir ancak metin varsayılan olarak boştur. Arayüzünüzde bu durum, görünür bir ilerleme olmadan uzun ve tuhaf bir duraksama gibi görünecektir. Kullanıcılar uygulamanın donduğunu varsayacaktır.

Bunu düzeltmek için thinking: { type: "adaptive", display: "summarized" } parametresini geçirin. Bu, ham düşünce akışını sohbet penceresine boşaltmadan size görünür bir ilerleme göstergesi sağlar. Frontend'iniz yanıt vermeye devam eder ve kullanıcılarınız arka planda bir şeyler olupunu anlar.

Asıl Ders

Tedarikçinin asla kalıcı olmasını amaçlamadığı bir parametre üzerine tüm bir soyutlama katmanı inşa ettim. Ayarlarını kendi mantığımın içine sardım çünkü ödünleşimleri (tradeoff) platformdan daha iyi anladığımı düşünmüştüm. Öyle değildi. Adaptif düşünme (adaptive thinking) daha iyi bir seçenek çünkü model, ne zaman derinlemesine muhakeme yapması gerektiğine ve ne zaman akışına bırakabileceğine kendisi karar veriyor. Kod tabanım artık daha küçük. Sonuçlar daha keskinleşti. Bazen doğru mühendislik hamlesi, "akıllıca" yazılmış kodu silmek ve platformun işini yapmasına izin vermektir.

Orijinal geçiş notlarını okumak isterseniz, onlara buradan ulaşabilirsiniz. Bunun gibi daha fazla uygulamalı tartışma için Telegram'daki GyaanSetu AI topluluğuna katılın.