Tek doğru takvim
Bir bakım planlayıcısının önünde 2.520 olası takvim var; yalnızca biri bütün kuralları sağlıyor. AWS’nin Grok 4.7 deneyi, düşünme bütçesini böyle bir problem üzerinde karşılaştırıyor. Sekiz hizmet dört geceye dağıtılıyor, her gece iki hizmet bakıma alınıyor ve aynı ekipten iki hizmet yan yana getirilemiyor. Doğru yanıt, model çalıştırılmadan önce bütün olasılıklar sayılarak bulunmuş. Burada ölçülen şey takvim hakkında ikna edici konuşmak değil, bilinen tek çözümü üretmek. Bu küçük ayrım, gösterişli bir eylemci anlatısını sınanabilir bir soruya çeviriyor.[1]
Takvim görevinin yanında iki başka problem var: alarm vermeyen iki arızalı hizmeti bulmak ve bütçe içinde en fazla risk azaltımını sağlayan geçişleri seçmek. Ortamda 20 hizmet ve 7 araç bulunuyor. Her problem, dört düşünme ayarında altışar kez çalıştırılmış; toplam 72 yanıt elde edilmiş. AWS’nin ölçümünde düşük ayar 18 yanıtın 15’ini, orta ve yüksek ayarlar 17’sini, en yüksek ayar tamamını doğru verdi. Bu sonuç, belirlenmiş problemleri çözme becerisi hakkında bilgi taşıyor. Eylemcinin gerçek bir kurumda bütün işi güvenilir biçimde yürütebildiğini aynı ölçümden çıkarmak ise mümkün değil.[1]
Aynı bilgi, daha fazla hesap
Ek düşünmenin bedeli açıkça görülüyor. AWS’nin deneyinde düşük ayarda ortalama çıktı 1.184 belirteçken, en yüksek ayarda 9.147 belirteç. Ortanca süre de 18 saniyeden 106 saniyeye çıkıyor. Buna karşılık ortalama araç çağrısı dört ayarda 17,2 ile 18,7 arasında kalıyor. Model daha yüksek ayarda çok daha fazla bilgi toplamış görünmüyor; aynı araç ortamında daha uzun hesap yapıyor. Bakım takvimi gibi aday çözümleri birbiriyle karşılaştırmayı gerektiren bir iş için bu, kararın nerede pahalılaştığını gösteren yararlı bir ayrım. Daha çok araç çağırmakla daha çok düşünmek, aynı işlem değil.[1]
Yine de 18’de 18 sonucu, yüksek ayarın hatasızlığını kanıtlamıyor. Her görev ve ayarda yalnızca 6 tekrar var; AWS de farkları istatistiksel olarak kesin saymıyor. Görülen farkın bir bölümü bu dar tekrar sayısındaki değişkenlikten kaynaklanabilir. Deneyin yararı buradan kaybolmuyor: aynı görevlerde düşük bütçeyi daha yüksek bütçeyle karşılaştırmak için bir başlangıç veriyor. Ancak bakım planını insanın kontrol ettiği bir kullanım ile yanıtın doğrudan uygulanması aynı karar eşiğine sahip değil. Kontrolün bulunduğu durumda belirteç tasarrufu, yanlış seçimin ayrıca yakalanmasıyla birlikte değerlendirilmeli.[1]
Yanıtın işe dönüşmesi
Doğru çözümün yanında ikinci bir koşul var: kullanılır bir yanıt almak. Bu deneyde 72 yanıtın hepsi değerlendirmeye uygun son satır içerdi. AWS, gerçek API kullanımında düşünme belirteçlerinin çıktı sınırını tükettiğini de açıklıyor. Sınır düşünme sırasında dolarsa kullanıcıya gösterilen yanıt boş kalabiliyor. Bu nedenle yüksek bütçe, yalnızca çözüm aramasına daha fazla kaynak vermek olarak görülemez; sonucun dışarı çıkmasına yetecek alanın da korunması gerekir. Deneydeki başarılı biçim sonucu ile uygulamadaki çıktı sınırı, iki ayrı hata yolunu tanımlıyor: yanlış yanıt ve hiç yanıt alamamak.[1]
Gerçek iş akışına geçişte ölçümün sınırı, görevlerin küçük olmasından daha somut. AWS’nin ortamı değişken gecikme ve kısmi araç hatalarını içermiyor; doğru yanıt da önceden biliniyor. Bir hizmetin yanıt vermediği, araç sonucunun eksik kaldığı ve sonucun bağımsız olarak doğrulanması gerektiği bir ortam ayrı bir sınama gerektiriyor. Bakım planlayıcısı için anlamlı sonraki ölçüm, bu koşullarda doğru ve uygulanabilir bir takvimi elde etmenin belirteç gideri ile tamamlanma oranı. Böyle bir ölçüm, düşünme bütçesini yalnızca daha yüksek puana değil, gerçekten bitirilen işe bağlar.[1]