Yapay zeka çevirisi aslında ne kadar düşünüyor?

Gemini, bitmek tükenmek bilmeyen bir nimet. Çoğu dil için, kullanıma hazır haliyle en iyi çeviri LLM'i. Düşünme yeteneği sayesinde deyimler, anime göndermeleri veya size özgü marka sesiniz™ gibi en zorlu sorunların bile üstesinden gelebilirsiniz.

Sorun şu ki, düşünmek zaman alıyor. Düşünmek paraya da mal oluyor; her bir token faturalandırılıyor. Bir geliştirici olarak her ikisini de kontrol altında tutmak istersiniz.

Gemini 2.5'te işimiz kolaydı. Gemini 3 bunu zorlaştırdı.

İşte Transept laboratuvarlarında öğrendiklerimiz

Gemini 3'te neler değişti

Gemini 2.5'te thinkingBudget vardı: akıl yürütme token'ları için sayısal bir üst sınır. Gemini 3 bunu kaldırdı. Bunun yerini thinkingLevel aldı: minimal, low, medium ve high olmak üzere dört değere sahip kategorik bir ayar. Bu iki parametre bir arada kullanılamaz; mevcut SDK'larda bir Gemini 3 modeline her ikisini birden göndermek 400 hatası döndürür.

Bu durum, pratikte "maliyeti kontrol etmenin" anlamını değiştiriyor. Eskiden, ne kadar harcamaya razı olduğunuza dair kesin bir üst sınır koyabiliyordunuz. Şimdi ise 'medium'un ne kadar bir harcamaya denk geldiğini belirlemek modele kalmış.

Bunun nedeninin, modellerin tıpkı insanlar gibi düşünme süresini farklı görev zorluklarına göre ayarlamak üzere sonradan eğitilmesi olduğunu varsayıyoruz. Dolayısıyla, keyfi sınırlar koymak bu yeteneğe zarar verecektir.

Peki low, medium ve high gerçekte kaç token harcıyor?

Veriler

İşte iki haftalık gerçek çeviri trafiğimizden bir örneklem: üç Gemini 3 modeli üzerinden yaklaşık 1000 çağrı. Düşünme token'ı verileri, her yanıtta yer alan ve mümkün olan en doğru kaynak olan usageMetadata.thoughtsTokenCount değerinden alınmıştır.

Modele göre düşünme token'ları

15.725 bir yazım hatası değil. Flash modelinde, orta ayarda yapılan tek bir çeviri çağrısı on beş bin akıl yürütme token'ı harcadı.

Genellikle bu tür token şişkinlikleri, Gemini'nin ham düşünme token'larını çıktıya sızdırmasından kaynaklanır. Bildiğiniz gibi, modelin "düşünmesi" aslında gerçekten düşündükleri değil, daha çok düzenlenmiş özetlerdir; LLM'nin gerçek akıl yürütme süreci daha ziyade bir bilinç akışına benzer.

Yine de belirtmekte fayda var ki bu özel durumda Gemini, içinde "saf çelik vernik ve boyaları reddeder" gibi bir dize geçen edebi bir metnin İngilizce->Ukraynaca çevirisi üzerinde sakin sakin uğraşıyordu. Çıktı içine sinene kadar adeta kaba kuvvet denemesi yapıyor ve on iki kadar seçeneği yüksek sesle okuyordu.

Birkaç hafta sonra yeni bir gelişme oldu. O 15,725, Gemini'nin tek seferlik bir özverisi değil, karmaşık görevlere özgü bir örüntüydü.

Trafik arttıkça, özellikle de gemini-3.1-flash-lite modelinde aynı sayı sürekli karşımıza çıkıyor. Şüpheli derecede dar bir 15,724–15,729 aralığı, onlarca çağrı boyunca devam ediyor ve bunların neredeyse tamamı sözlük denetimlerini harıl harıl işleyen Lite modellerinden oluşuyor. İlginçtir ki bunlar, en masraflı ayar olmasını beklemeyeceğiniz düşük düşünme eforuyla (low) çalışıyorlar.

Aynı sayıya on bir kez ulaşan bir model, bir ifade seçmiş değil, bir sınıra dayanmış demektir. Düşük düşünme ayarı (low) yaklaşık 15,7 bin token'da doygunluğa ulaşıyor. lite gibi küçük modeller daha az etkili düşündüğü için, zor görevler onları çok fazla token harcamaya iter; bu durum daha büyük modellerde asla yaşanmaz, çünkü onlarda her token'ın cevaba doğru anlamlı bir adım olma olasılığı daha yüksektir.

Üstelik bu doygunluğun bir bedeli var. Gemini 3'te düşünme token'ları maxOutputTokens sınırından düşülür. Düşünmeye 15,7 bin token harcayan bir çağrının cevap için neredeyse hiçbir payı kalmaz; ancak tüm düşünme süreci çıktı tarifesinden ücretlendirilir. 16 bin token'lık bir bütçede, küçük belgelerdeki denetimlerin yaklaşık yarısı boş döndü (finishReason=MAX_TOKENS), bu da bizi durumu araştırmaya itti.

Bütçeyi artırmak sorunun kaynağını değil, sadece belirtisini çözer. low ayarında denetim bütçesini 32 bine çıkardık, bu da doygunluğa ulaşan bir düşünme sürecinden sonra çıktı için yaklaşık 16 bin token bırakıyor — böylece boş yanıtlar kesildi. Ancak düşünme süreci kısalmadı. Gemini 3'te bunu sınırlayamıyorsunuz, bu yüzden hâlâ yaklaşık 15,7 bin token harcıyor; daha büyük bütçe sadece cevabın sığabileceği bir alan yaratıyor.

16 binlik 'thinkingmaxxing' sorununa tek gerçek çözüm, görev kapsamını daraltmaktı.

minimal, yaklaşık 2 bin token'lık bir tavanla gerçek bir sınır gibi davranan tek seviyedir. Ancak yalnızca Lite modellerinde mevcuttur.

Görev türüne göre düşünme token'ları (Flash ve Pro, her ikisi de medium ayarında)

Pro, düz çeviride Flash'tan neredeyse 2 kat daha az düşünüyor. Sadece yeniden yazma görevlerinde Flash'tan daha fazla düşünüyor. Akıl yürütme çabası modelin pazarlama sınıfına değil, görevin zorluğuna bağlıdır.

Pro'nun çeviri kıyaslamalarında daha iyi sonuçlar elde etmesinin, tam da gerektiğinde daha derin düşünebilme yeteneğinden kaynaklandığı söylenebilir.

Pratik çıkarımlar

• Gemini 3 modelinde thinkingBudget ayarlamayın. Ya göz ardı edilir ya da hata verir.
• medium ayarının üst limiti esnektir. Gerçekçi bir plan, çağrı başına 2 bin değil, ~4 bin p90 düşünme token'ıdır.
• Maliyet konusunda kesin bir sınıra ihtiyacınız varsa, mümkün olan yerlerde minimal kullanın. Çıktıları durdurmanın bir mantığı yoktur: her halükarda ücretlendirilirsiniz.
• Çağrı başına faturalandırma yapıyorsanız, her yanıttaki usageMetadata.thoughtsTokenCount değerini okuyun. Bu sayı yanıt gövdesinde bulunmaz, ancak faturada yer alır.
• medium ayarındaki Pro'nun basit görevlerde medyanından daha az, zor görevlerde ise daha fazla düşünmesi muhtemeldir. Lite ve Flash'ta bu değişkenlik yoktur.

Bu da, standart LLM seviyesinin ötesindeki redaksiyon ve iyileştirme işlemleri için en iyi modelin Pro olduğu anlamına gelir, çünkü yaratıcılığı tam da bu noktada devreye girer. Ham taslak çevirisi ise Flash'ta daha iyidir.

Ancak bu, zaman ve para gerektirir. Transept'te, Pro'yu yalnızca en zor kısımlarda devreye sokan akıllı bir redaksiyon mantığı kullanarak Pro maliyetlerini nasıl düşüreceğimizi bulduk. Ayrıca planlama ve karar alma süreçleri için de Pro'yu kullanıyor, yürütme işini ise daha küçük modellere ve ince ayarlı modellere devrediyoruz.

Böylece her şey sorunsuz çalışıyor.