Sıcaklık (Temperature)

Sıcaklık (temperature), çıkarım (inference) anında iletilen ve bir LLM'in token seçiminin ne kadar "rastgele" veya "deterministik" olduğunu kontrol eden bir parametredir. İç mekanizmada, model olası her bir sonraki token üzerinde bir olasılık dağılımı hesaplar; sıcaklık, bir token örneklenmeden önce bu dağılımı yeniden ölçeklendirir. 0 sıcaklık (veya ona çok yakın) modelin neredeyse her zaman tek en yüksek olasılıklı token'ı seçmesini sağlar — deterministik, odaklı, tekrarlanabilir çıktı. Daha yüksek sıcaklıklar (1.0 ve üzeri) olasılık dağılımını düzleştirir; daha düşük olasılıklı token'lara seçilme şansı verir, daha çeşitli, yaratıcı, bazen şaşırtıcı çıktı üretir — ama uç noktalarda daha yüksek bir tutarsızlık veya halüsinasyon riski de taşır. Bu, SaaS geliştiricileri için pratikte en önemli ayar düğmelerinden biridir çünkü doğru sıcaklık tamamen göreve bağlıdır. Yapısal, gerçeklere dayalı veya kod üretimi görevleri (SQL üretimi, veri çıkarımı, sınıflandırma, API yanıt biçimlendirme) tutarlılık ve doğruluk için düşük sıcaklık ister (0 ila 0.3) — JSON şema çıkarıcınızın alan isimleriyle ara sıra yaratıcı davranmasını istemezsiniz. Yaratıcı görevler (pazarlama metni fikir üretimi, isim üretimi, hikaye yazımı), tekrarlayan, jenerik çıktıdan kaçınmak için daha yüksek sıcaklıktan (0.7 ila 1.0+) fayda görür. Somut bir örnek: bir LLM'e sıcaklık 0'da "Bir kahve abonelik kutusu için bir slogan ver" diye sormak, her seferinde güvenilir şekilde "Taze Kavrulmuş, Kapınıza Teslim" döndürebilir — güvenli ama birçok kullanıcı arasında tekrarlayıcı. Aynı istem sıcaklık 0.9'da bir seferde "Merakla Uyanın", bir sonrakinde "Günlük Ritüeliniz, Yeniden Tasarlandı" döndürebilir — daha fazla çeşitlilik; birden çok seçenek üretirken veya binlerce kullanıcı arasında jenerik bir his vermekten kaçınırken faydalı. Geliştiriciler, sıcaklığın kaliteyi artıran sihirli bir "yaratıcılık" düğmesi olmadığının farkında olmalıdır — yalnızca örnekleme rastgeleliğini kontrol eder; bu yüzden hassasiyet gerektiren görevlerde (metinden bir telefon numarası çıkarmak, geçerli kod üretmek) onu çok yükseğe çekmek, hiçbir avantaj olmadan hata oranlarını artırır. Sıcaklık genellikle daha ince kontrol için top-p örneklemeyle birleştirilir ve çoğu API, ikisinden birini ayarlamayı önerir, ikisini aynı anda değil. Bazı sağlayıcılar ayrıca sıcaklıkla birlikte bilinmeye değer ilgili parametreler sunar: `frequency_penalty` ve `presence_penalty` (bazı API'lerde mevcut), modelin aynı kelimeleri veya konuları tekrarlamasını caydırır; aksi halde tekrarlayıcı hale gelen uzun form üretim için kullanışlıdır. Ve bir `seed` parametresi (desteklendiği yerde), sabit bir sıcaklıkta çağrılar arasında tekrarlanabilirliği iyileştirebilir — ancak nadiren garanti eder — bu da test etme ve hata ayıklama için kullanışlıdır. Model çıktısı üzerinde otomatik değerlendirme hatları çalıştıran geliştiriciler, tipik olarak test koşularının kod değişiklikleri arasında karşılaştırılabilir olması için sıcaklığı özellikle 0'a sabitler; bir özellik değerlendirmeden bazı çeşitliliğin gerçekten arzu edildiği canlı, kullanıcıya yönelik üretime geçtikten sonra bunu gevşetirler.