Test-Time Compute (TTC) Nedir? Yapay Zekâ Ek Hesaplamayla Daha Doğru Cevaplara Nasıl Ulaşabiliyor?

Bu durumlarda modelden yalnızca tek bir yanıt almak yerine alternatifler üretmesini, sonuçları kontrol etmesini veya çözümünü yeniden düzenlemesini istemek fayda sağlayabilir. Ancak bütün bu işlemler ek hesaplama gerektirir.

Test-Time Compute (TTC), model eğitildikten sonra bir problemi çözerken kullanılan hesaplama kaynaklarını ifade eder. Bu bütçeyi artırarak performansı geliştirmeye yönelik yaklaşım ise test-time scaling veya inference-time scaling olarak adlandırılır.

Temel fikir, her problemi aynı hesaplama bütçesiyle çözmeye çalışmamaktır. Basit bir işlem kısa sürede tamamlanabilirken karmaşık bir görev için daha fazla aday, kontrol veya arama adımı kullanılabilir.

Bununla birlikte daha fazla hesaplama, otomatik olarak daha doğru cevap anlamına gelmez. Ek kaynakların nasıl kullanıldığı ve sonuçların nasıl değerlendirildiği belirleyicidir.

Test-Time Compute Nedir?

Test-Time Compute, bir modelin kullanım sırasında tahmin veya yanıt oluşturmak için harcadığı hesaplamadır. Büyük dil modelleri açısından buna şu işlemler dâhil olabilir:

• Daha uzun bir çözüm süreci yürütmek.
• Birden fazla aday cevap üretmek.
• Adayları puanlamak ve karşılaştırmak.
• Önceki cevabı kontrol ederek düzeltmek.
• Farklı çözüm yollarını araştırmak.
• Test veya hesaplama araçlarından geri bildirim almak.

Dolayısıyla TTC, tek bir algoritmanın adı değildir. Çıkarım sırasında kullanılabilecek hesaplama bütçesini anlatan geniş bir kavramdır.

Ayrıca bu bütçe yalnızca bekleme süresiyle ölçülmez. Üretilen token sayısı, model çağrılarının sayısı, değerlendirici işlemleri ve araç kullanımı da önemlidir.

Eğitim Hesaplamasından Farkı Nedir?

Eğitim sırasında model ağırlıkları güncellenir. Model, veri üzerinden dil örüntülerini, görev davranışlarını veya tercih edilen yanıt özelliklerini öğrenir.

Standart test-time scaling uygulamalarında ise mevcut model, belirli bir soruyu çözmek için daha fazla çalıştırılır. Modelin ağırlıkları bu işlem sırasında genellikle değişmez.

Bu ayrım, eğitimin önemsiz olduğu anlamına gelmez. Ek çözüm adımlarını etkili kullanabilen bir model veya güvenilir bir değerlendirici geliştirmek için ayrıca eğitim gerekebilir.

Çıkarım sırasında daha fazla kaynak kullanabilmek ile bu kaynaklardan yararlanmayı öğrenmiş olmak farklı konulardır.

Ek Hesaplama Nasıl Kullanılıyor?

Başlıca iki yaklaşım vardır: Tek çözümü daha fazla işlemek veya birden fazla çözüm üretmek.

Tek çözüm üzerinde daha fazla çalışma

Model bir çözüm oluşturur, kontrol eder ve gerektiğinde yeniden düzenler. Örneğin hazırladığı kodu test sonuçlarına göre düzeltebilir.

Bu yaklaşımda sonraki adım önceki sonuçlara bağlıdır. Bu nedenle işlem süresi uzayabilir.

Birden fazla aday üretme

Model aynı problem için farklı cevaplar veya çözüm yolları oluşturur. Ardından adaylar karşılaştırılır.

Aday üretimi uygun altyapıda paralel yapılabilir. Böylece toplam hesaplama artsa da kullanıcının bekleme süresi aynı oranda artmayabilir.

Ancak burada yeni bir sorun ortaya çıkar: Hangi adayın gerçekten daha iyi olduğu nasıl belirlenecek?

Test-Time Compute Teknikleri

Farklı yöntemler, ek bütçeyi farklı biçimlerde kullanır.

Chain of Thought gibi yöntemler ara çözüm adımları oluşturabilir. Ancak bu adımların uzunluğu veya ikna edici görünmesi, sonucun doğru olduğunu kanıtlamaz.

Benzer şekilde Self-Consistency, “en güzel açıklamayı” seçmekten ziyade farklı örneklemelerde elde edilen nihai cevaplar arasındaki uyumu değerlendirmeyi hedefler.

Bir Kod Örneğinde Nasıl İşler?

Bir kullanıcı, ürün kayıtlarını kodlarına göre birleştiren bir fonksiyon istesin. Aynı kod birden fazla kez geçiyorsa miktarların toplanması gerekiyor.

Tek denemede üretilen kod, normal verilerde çalışabilir. Fakat boş listeyi, eksik miktar alanını veya beklenmeyen veri türlerini yanlış işleyebilir.

Ek hesaplama bütçesiyle sistem şu süreci uygulayabilir:

1. İlk kod adayını oluşturur.
2. Normal durumlar ve sınır durumları için testler hazırlar.
3. Kodu çalıştırarak sonuçları inceler.
4. Başarısız testlere göre düzenleme yapar.
5. Güncellenen kodu yeniden kontrol eder.

Buradaki avantaj, yalnızca daha uzun bir cevap yazılması değildir. Çalıştırılabilir geri bildirim, düzeltme için somut bir dayanak sağlar.

Yine de testlerin eksik hazırlanması, hatalı kodun başarılı görünmesine neden olabilir. Kontrolün kapsamı, sonuç kadar önemlidir.

Değerlendirici Neden Kritik?

Çok sayıda aday üretmek, iyi adayı seçemeyen bir sistemde sınırlı fayda sağlar.

Bir değerlendirici; nihai cevabı, çözüm adımlarını, test sonuçlarını veya belirli kurallara uyumu inceleyebilir. Ancak her görevin kolayca doğrulanabilir bir cevabı yoktur.

Matematikte bazı sonuçlar hesaplama araçlarıyla kontrol edilebilir. Kodda testler kullanılabilir. Açık uçlu bir politika değerlendirmesinde veya kapsamlı bir açıklamada ise “en iyi cevap” daha belirsizdir.

Yanlış ölçüt kullanan bir değerlendirici, doğru fakat kısa bir cevap yerine uzun ve ikna edici bir yanlışı seçebilir. Bu nedenle test-time scaling’in başarısı, üretim ile doğrulamanın birlikte tasarlanmasına bağlıdır.

Daha Fazla Hesaplama Ne Zaman Fayda Sağlamaz?

Bazı problemlerde model gerekli bilgiye sahip değildir. Aynı soruyu tekrar tekrar ele almak, eksik bilgiyi güvenilir biçimde oluşturmaz. Böyle durumlarda bilgi erişimi veya uygun araç kullanımı gerekebilir.

Başka durumlarda modelin bütün adayları benzer bir hatayı paylaşır. Daha fazla örnek üretmek, hatayı çeşitlendirmek yerine çoğaltabilir.

Ek hesaplama şu nedenlerle de verimsiz olabilir:

• Soru zaten basittir.
• Değerlendirme ölçütü hatalıdır.
• Düzeltme adımları doğru cevabı bozuyordur.
• Adaylar birbirine çok benzerdir.
• Hesaplama bütçesi yanlış aşamaya ayrılmıştır.

Bu nedenle “modele daha uzun düşünmesini söylemek”, tek başına güvenilir bir optimizasyon yöntemi değildir.

Dinamik Hesaplama Bütçesi Nedir?

Her isteğe aynı bütçeyi ayırmak yerine, görevin ihtiyacına göre kaynak seçilebilir.

Basit bir sınıflandırma tek çağrıda tamamlanabilir. Başarısız test içeren bir kod görevine ise ek düzeltme turları ayrılabilir. Belirsiz bir soruda önce açıklık sağlamak veya bilgi toplamak daha uygun olabilir.

Böyle bir sistemin durma koşulları da bulunmalıdır:

• Belirlenen bütçe dolduğunda.
• Sonuç yeterli kontrolleri geçtiğinde.
• Yeni denemeler anlamlı iyileşme sağlamadığında.
• Gerekli bilgi veya araç mevcut olmadığında.

Amaç, her istekte mümkün olan en fazla hesaplamayı yapmak değil, ek hesaplamayı fayda sağlayacağı yere ayırmaktır.

Maliyet ve Gecikme Dengesi

Test-time scaling; token tüketimini, işlem sayısını ve enerji kullanımını artırabilir. Ancak ek hesaplama her zaman daha fazla GPU belleği gerektirmez. İşlemlerin sırayla veya paralel yürütülmesi bellek ihtiyacını farklı biçimlerde etkiler.

Paralel aday üretimi bekleme süresini azaltabilir, fakat daha fazla eşzamanlı kaynak ister. Ardışık düzeltme ise daha az eşzamanlı kaynakla yürütülebilirken yanıt süresini uzatabilir.

Bu nedenle performans değerlendirmesinde doğruluğun yanında toplam maliyet, gecikme ve başarısızlık oranı da ölçülmelidir.

Sık Sorulan Sorular

Uzun cevap, daha fazla akıl yürütme yapıldığını gösterir mi?

Hayır. Uzunluk tek başına çözüm kalitesini göstermez. Ek hesaplamanın anlamlı alternatifler veya doğrulama adımları için kullanılması gerekir.

Model bu süreçte kalıcı olarak öğrenir mi?

Standart uygulamada ağırlıklar güncellenmez. Mevcut görevde elde edilen geri bildirim, ayrıca eğitim veya bellek mekanizmasına aktarılmadıkça kalıcı model öğrenmesine dönüşmez.

Küçük model, ek hesaplamayla büyük modeli geçebilir mi?

Bazı görevlerde mümkün olabilir. Ancak sonuç; modellerin yeteneklerine, bütçeye ve değerlendirme yöntemine bağlıdır. Bütün görevler için geçerli bir üstünlük değildir.

RAG ile birlikte kullanılabilir mi?

Evet. RAG ilgili bilgiyi getirirken ek hesaplama, bu bilgiden hareketle alternatif çözümler üretmek veya cevabı kontrol etmek için kullanılabilir. Yanlış kaynak seçimi ise ek hesaplamayla otomatik olarak düzelmez.

Kaynaklar: Charlie Snell ve diğerleri — Scaling LLM Test-Time Compute Optimally Can Be More Effective Than Scaling Model Parameters; Xuezhi Wang ve diğerleri — Self-Consistency Improves Chain of Thought Reasoning in Language Models; Shunyu Yao ve diğerleri — Tree of Thoughts: Deliberate Problem Solving with Large Language Models; Aman Madaan ve diğerleri — Self-Refine: Iterative Refinement with Self-Feedback.

Editör Notu

Bu içerik, çıkarım aşamasındaki hesaplama bütçesinin büyük dil modeli performansına etkisini ele alan bir araştırma ve değerlendirme yazısıdır. İçerikte yer alan değerlendirmeler editoryal yorum niteliğindedir. Ek hesaplamanın sağladığı fayda; modelin yeteneklerine, görevin niteliğine, aday üretim yöntemine ve doğrulama mekanizmasına bağlıdır. Daha fazla token, daha uzun işlem süresi veya daha çok deneme, doğruluğun artacağını tek başına garanti etmez.