Chain of Thought Nedir? Yapay Zeka Nasıl Muhakeme Yapar?

Chain of thought nedir? Chain of thought (muhakeme zinciri), bir yapay zeka modelinin doğrudan son cevaba atlamak yerine, metin olarak ara adımlar üretip bu adımları takip ederek sonuca ulaşmasını sağlayan bir akıl yürütme yöntemidir. Model, “2+2 kaça eşittir” gibi basit bir soruda değil ama çok adımlı bir matematik probleminde, bir kod hatasını ayıklarken veya karmaşık bir mantık bulmacasında, önce ara adımları metin olarak üretir, sonra bu adımlara dayanarak nihai cevabı verir.

2026 itibarıyla bu teknik artık bir “prompt hilesi” olmaktan çıkıp, GPT-5.5, Claude’un genişletilmiş düşünme (extended thinking) modu, Gemini Deep Think ve DeepSeek R1 gibi modellerin eğitim ve çıkarım yöntemleriyle desteklenen bir davranış haline geldi. Bu yazıda chain of thought’un nasıl çalıştığını, günümüz muhakeme modellerinde nasıl uygulandığını, gerçek API örnekleriyle nasıl kullanılacağını ve maliyet/performans dengesini ele alıyoruz.

Chain of Thought Nedir, Nasıl Ortaya Çıktı?

Kavram akademik olarak ilk kez 2022 yılında Google araştırmacılarının yayınladığı bir makalede “chain-of-thought prompting” adıyla tanımlandı. Araştırmacılar, modele soruyu doğrudan sormak yerine “adım adım düşün” talimatı eklediklerinde veya örnek çözümlerde ara adımları gösterdiklerinde, özellikle matematik ve mantık problemlerinde doğruluk oranının belirgin şekilde arttığını gözlemledi.

Klasik Prompt ile Chain of Thought Farkı

Klasik bir promptta model, soruyu okur ve doğrudan cevabı üretir; ara adımlar modelin “kafasında” (gizli katmanlarında) kalır ve dışarıdan izlenemez. Chain of thought yaklaşımında ise model, bu ara adımları açıkça metne döker: “Önce şu değeri hesaplayayım, sonra bunu şu formülde kullanayım, son olarak…” gibi bir akış izler. Bu, hem modelin kendi ürettiği ara adımları bir sonraki adımda “okuyarak” hataları düzeltebilmesine hem de bizim modelin nasıl bir sonuca vardığını takip edebilmemize imkân tanır.

Yapay Zeka Neden Adım Adım Düşününce Daha Doğru Sonuç Veriyor?

Büyük dil modelleri, cevabı tek seferde, token token üreten istatistiksel sistemlerdir. Karmaşık bir problemi tek adımda çözmeye çalışmak, modelin sınırlı “hesaplama bütçesini” tek bir tahmine sıkıştırması anlamına gelir. Ara adımlar ürettiğinizde ise model, her bir token için ayrı bir hesaplama turu harcar; bu da toplamda probleme çok daha fazla “düşünme” (hesaplama) ayrılması demektir.

Token Bazlı Hesaplama ve “Düşünme Süresi”

Bu noktada devreye “test-time compute” (çıkarım anı hesaplaması) kavramı giriyor. Bir modelin eğitim sırasında ne kadar güçlü olduğu sabittir, ama çıkarım anında ona ne kadar “düşünme tokeni” harcama izni verdiğiniz değişkendir. OpenAI’nin o-serisi modelleri ve devamı olan GPT-5.5’in reasoning modu, Claude’un extended thinking özelliği ve Gemini Deep Think, kullanıcıya bu “düşünme bütçesini” ayarlama imkânı sunuyor: daha fazla düşünme tokeni genellikle daha yüksek doğruluk, ama daha yüksek maliyet ve gecikme anlamına geliyor.

2026’da Muhakeme Modelleri Nasıl Çalışıyor?

Günümüzün reasoning modelleri, chain of thought’u kullanıcıdan gizli bir “iç monolog” olarak çalıştırıyor ve sadece özetlenmiş bir sürümünü ya da doğrudan nihai cevabı gösteriyor. Bunun nedeni hem kullanıcı deneyimini sadeleştirmek hem de modelin ham düşünce sürecinin bazen yanıltıcı veya güvenlik açısından hassas ayrıntılar içerebilmesi.

Görünür vs Gizli Muhakeme Zinciri

Bazı sağlayıcılar (örneğin Claude’un extended thinking modu) düşünme sürecinin bir kısmını kullanıcıya gösterirken, bazıları (OpenAI’nin o-serisi ve sonrası) ham muhakeme zincirini gizleyip yalnızca bir özet sunuyor. DeepSeek R1 ise açık kaynak modeller arasında, muhakeme adımlarını görece daha şeffaf sunmasıyla dikkat çekmişti. Bu tercih farkı, geliştiriciler için önemli bir sonuç doğuruyor: gizli muhakeme kullanan bir API’de, modelin “neden” o cevaba vardığını hata ayıklama (debugging) amacıyla incelemek daha zor olabiliyor.

Chain of Thought’un Riskleri ve Sınırlamaları

Chain of thought’u “modelin gerçekten düşündüğünün kanıtı” gibi görmek yaygın ama yanıltıcı bir yorum. Araştırmacılar, modelin ürettiği ara adımların bazen sonradan uydurulmuş bir açıklama (post-hoc rationalization) niteliğinde olabileceğini, yani modelin gerçek iç hesaplamasını birebir yansıtmayabileceğini gösterdi. Bu duruma literatürde “unfaithful reasoning” (sadık olmayan muhakeme) deniyor.

Sadık Olmayan Muhakeme Ne Anlama Geliyor?

Pratikte bu şu anlama gelir: model, doğru cevaba başka bir yoldan ulaşmış olsa bile, size “mantıklı” görünen ama gerçek karar sürecini yansıtmayan bir adım zinciri sunabilir. Bu durum özellikle güvenlik ve denetlenebilirlik açısından önemli; bir modelin muhakeme zincirini “açıklanabilirlik” (explainability) kanıtı olarak sunmak, her zaman teknik olarak doğru bir varsayım değil.

Uzun Muhakeme Zincirlerinde Sürüklenme Riski

Çok uzun muhakeme zincirlerinde model, ilk adımlarda küçük bir hata yaptığında bu hatayı sonraki adımlara taşıyabilir ve zincirin sonunda tutarlı ama yanlış bir cevaba “kendini ikna edebilir”. Bu yüzden kritik görevlerde tek bir uzun muhakeme zincirine güvenmek yerine, self-consistency gibi tekniklerle birden fazla bağımsız deneme karşılaştırılması öneriliyor.

Pratikte bu riski azaltmanın bir başka yolu da, muhakeme zincirini tek bir dev adımlar bütünü olarak değil, ara sonuçları dış bir araçla (hesap makinesi fonksiyonu, veritabanı sorgusu, birim testi) doğrulayan daha küçük parçalara bölmek. Özellikle kod üretimi gibi görevlerde, modelin ürettiği her fonksiyonu ayrı ayrı test etmek, tüm çözümü tek seferde üretip sonunda doğrulamaya kıyasla hataları çok daha erken yakalar.

Chain of Thought Türleri: Karşılaştırma Tablosu

Kendi Uygulamanızda Chain of Thought Nasıl Kullanılır? Adım Adım Rehber

1. Görevi sınıflandırın: Basit sınıflandırma veya kısa metin üretimi gibi görevlerde chain of thought genelde gereksiz maliyet katar; çok adımlı matematik, kod hata ayıklama veya planlama gerektiren görevlerde ise belirgin fayda sağlar.
2. Doğru modeli/parametreyi seçin: Yerleşik reasoning modeli kullanıyorsanız API’nin “düşünme bütçesi” parametresini (ör. OpenAI’de reasoning effort, Claude’da thinking bütçesi) görevin zorluğuna göre ayarlayın.
3. Prompt tabanlı CoT gerekiyorsa örnek ekleyin: Reasoning modeli kullanmıyorsanız, prompta “adım adım düşün” talimatı ve mümkünse 1-2 örnek çözüm ekleyin.
4. Kritik görevlerde self-consistency uygulayın: Yüksek doğruluk gereken senaryolarda aynı soruyu birkaç kez çalıştırıp çoğunluk cevabını seçmek, tek seferlik cevaba göre daha güvenilir sonuç verir.
5. Çıktıyı doğrulayın: Modelin ürettiği ara adımları, özellikle sayısal hesaplamalarda, ayrı bir kod parçasıyla veya insan gözüyle kontrol edin; muhakeme zinciri “makul görünse” bile sonuç hatalı olabilir.
6. Maliyeti izleyin: Reasoning modelleri, normal modellere göre çok daha fazla token tüketir; kullanım başına maliyeti düzenli olarak izleyin ve gereksiz yere yüksek düşünme bütçesi harcamayın.

Kod Örneği: OpenAI API ile Reasoning Effort Ayarlama (PHP)

<?php

$apiKey = getenv('OPENAI_API_KEY');

$payload = [
    'model' => 'gpt-5.5',
    'reasoning_effort' => 'high', // low | medium | high
    'messages' => [
        ['role' => 'system', 'content' => 'Sen bir matematik ve mantık asistanısın.'],
        ['role' => 'user', 'content' => 'Bir depoda 3 farklı ürün var. Toplam 240 adet ürünün '
            . 'yüzde 25 orani A, yüzde 40 orani B, kalanı C ürünü. Her ürün grubunun adedini bul.'],
    ],
];

$ch = curl_init('https://api.openai.com/v1/chat/completions');
curl_setopt_array($ch, [
    CURLOPT_RETURNTRANSFER => true,
    CURLOPT_POST => true,
    CURLOPT_HTTPHEADER => [
        'Content-Type: application/json',
        "Authorization: Bearer {$apiKey}",
    ],
    CURLOPT_POSTFIELDS => json_encode($payload),
]);

$response = json_decode(curl_exec($ch), true);
curl_close($ch);

echo $response['choices'][0]['message']['content'];

Buradaki reasoning_effort parametresi, modelin ne kadar “düşünme tokeni” harcayacağını belirler. Basit sorularda low, çok adımlı problemlerde high seçmek, maliyet ile doğruluk arasında pratik bir denge kurar.

Kod Örneği: Zero-Shot CoT Prompt Şablonu (Reasoning Modeli Olmayan API’ler İçin)

function buildCotPrompt(string $question): string
{
    return <<<PROMPT
Aşağıdaki soruyu çözerken adımlarını açıkça göster:
1. Verilenleri listele.
2. Hangi formül veya mantığı kullanacağını belirt.
3. Hesaplamayı adım adım yap.
4. Son satırda "CEVAP:" ile başlayan net bir sonuç ver.

Soru: {$question}
PROMPT;
}

Bu şablon, reasoning modu olmayan daha ucuz/hafif modellerde bile chain of thought benzeri bir davranışı tetikleyerek doğruluğu artırabilir. Bu yaklaşımı, daha önce Fine-Tuning Nedir yazımızda ele aldığımız model özelleştirme tekniklerinden biriyle (belirli bir formatta çözüm üreten örneklerle ince ayar) birleştirmek, tutarlılığı daha da artırabilir.

Laravel Job Kuyruğunda Reasoning Modeli Kullanımı

Reasoning modelleri, klasik modellere göre belirgin şekilde daha uzun yanıt süresine sahip olabiliyor; bazı karmaşık görevlerde bu süre saniyeler yerine dakikalar mertebesine çıkabilir. Bu nedenle bir Laravel uygulamasında reasoning modelini senkron bir HTTP isteği içinde çağırmak yerine, bir kuyruk (queue) job’u olarak çalıştırıp sonucu daha sonra kullanıcıya bildirmek, hem sunucu kaynaklarını hem de kullanıcı deneyimini korur. Uzun süren bir isteği doğrudan web sunucu sürecinde bekletmek, zaman aşımı hatalarına ve gereksiz sunucu yükü artışına yol açabilir; bu da özellikle paylaşımlı hosting ortamlarında dikkat edilmesi gereken bir nokta.

Maliyet ve Performans Dengesi

Reasoning modelleri, ara adımları da token olarak ürettiği için, aynı soruyu klasik bir modele sormaya kıyasla belirgin şekilde daha fazla token tüketir. Bu fark, basit bir soruda birkaç kat, çok adımlı karmaşık bir problemde çok daha yüksek olabilir. Pratikte izlenebilecek yaklaşım şu: üretim ortamında önce görevi düşük çabalı (low effort) bir ayarla deneyin, sonuç yetersizse kademeli olarak düşünme bütçesini artırın. Bu, her isteği en yüksek reasoning seviyesinde çalıştırmaya kıyasla token maliyetini önemli ölçüde azaltabilir.

Bağlam penceresi yönetimi de bu noktada devreye giriyor; uzun bir muhakeme zinciri, modelin bağlam penceresini hızla doldurabilir. Bu konuyu daha önce Context Window Nedir yazımızda ele almıştık; reasoning modelleriyle çalışırken bu sınırı özellikle göz önünde bulundurmak gerekiyor.

Çok adımlı bir ajan sistemi kurarken, her adımda yeniden reasoning modeli çağırmak yerine, hangi adımların gerçekten karmaşık muhakeme gerektirdiğini önceden belirlemek de maliyeti kontrol altında tutmanın bir başka yolu. Örneğin bir belge işleme hattında, belgeyi sınıflandırma adımı standart bir modelle yapılabilirken, çelişkili veya belirsiz içerik tespit edildiğinde devreye giren “ikinci kontrol” adımı reasoning moduna devredilebilir. Bu tür karma (hybrid) mimariler, tüm hattı en pahalı modelle çalıştırmaya kıyasla toplam maliyeti belirgin şekilde düşürebilir.

Üretim Öncesi Kontrol Listesi

• Görev-seviye eşlemesi: Hangi görev tipi hangi reasoning effort seviyesinde çalışacak, bu net bir tabloyla belgelenmiş mi?
• Token bütçesi izleme: Reasoning modelinin ürettiği toplam token sayısı (görünür + gizli muhakeme dahil) izleniyor mu?
• Zaman aşımı politikası: Uzun süren reasoning isteklerinde kullanıcıya bekleme süresi hakkında bilgi veriliyor mu, yoksa arka plan işlemine mi devrediliyor?
• Doğrulama katmanı: Kritik sayısal veya hukuki sonuçlar, ayrı bir mekanizmayla (kod çalıştırma, kural motoru, insan gözden geçirmesi) çapraz kontrol ediliyor mu?
• Model değişikliğine dayanıklılık: Sağlayıcı reasoning davranışını güncellediğinde (örneğin varsayılan düşünme bütçesini değiştirdiğinde) sisteminizin maliyet ve doğruluk metrikleri yeniden test ediliyor mu?

Sık Yapılan Hatalar ve Çözümleri

1. Her görevde en yüksek reasoning seviyesini kullanmak

Hata: Basit sınıflandırma görevlerinde bile “high” reasoning effort kullanmak.
Çözüm: Görev zorluğuna göre kademeli bir eşleme yapın; basit görevlerde düşük, karmaşık görevlerde yüksek çaba seviyesi seçin.

2. Muhakeme zincirini doğrulama olmadan güvenmek

Hata: Model “mantıklı” bir ara adım zinciri ürettiği için sonucu sorgusuzca kabul etmek.
Çözüm: Özellikle sayısal sonuçları, ayrı bir hesaplama katmanıyla (kod çalıştırma, harici doğrulama) çapraz kontrol edin.

3. Gizli muhakemeyi hata ayıklama için beklemek

Hata: Ham muhakeme zincirini gizleyen bir API’de, modelin “neden” yanlış cevap verdiğini doğrudan görmeye çalışmak.
Çözüm: Modelden ayrıca kısa bir gerekçe özeti istemek veya görünür muhakeme sunan bir modele geçmek, hata ayıklamayı kolaylaştırabilir.

4. Prompt tabanlı CoT ile reasoning modelini karıştırmak

Hata: Yerleşik reasoning moduna sahip bir modele ayrıca “adım adım düşün” talimatı eklemek; bu genelde gereksiz token tüketimine yol açar.
Çözüm: Kullandığınız modelin reasoning’i yerleşik mi yoksa prompt tabanlı mı desteklediğini belgelerden kontrol edin ve buna göre prompt tasarlayın.

5. Maliyeti izlemeden üretime almak

Hata: Reasoning modelini test ortamında birkaç kez deneyip, token tüketimini ölçmeden doğrudan üretime almak.
Çözüm: Üretime almadan önce tipik istek başına token tüketimini ölçün ve aylık maliyeti bu veriyle projelendirin.

Kime, Hangi Durumda Uygun?

Basit metin üretimi, kısa özetleme veya sınıflandırma gibi görevler yapıyorsanız, chain of thought veya reasoning modu genelde gereksiz bir maliyet katmanı ekler; standart bir model bu görevler için hem daha hızlı hem daha ucuzdur. Ancak çok adımlı matematik, kod hata ayıklama, planlama gerektiren ajan görevleri veya karmaşık mantık gerektiren analizlerle uğraşıyorsanız, reasoning modelleri belirgin bir doğruluk artışı sağlayabilir.

Bütçe kısıtlı küçük projeler için önerilen yaklaşım, önce düşük reasoning seviyesiyle başlamak ve sonucu yetersiz bulduğunuzda kademeli olarak yükseltmek. Kurumsal ölçekte, çok adımlı ajan iş akışları çalıştıran ekiplerin ise görev bazlı bir reasoning seviyesi haritası çıkarması (hangi görev hangi seviyede çalışacak) hem maliyet hem doğruluk açısından daha sürdürülebilir bir yaklaşım sunuyor.

Bir diğer pratik ölçüt de görevin geri alınabilirliği: Sonucu kolayca düzeltilebilen düşük riskli görevlerde (taslak metin, ilk özet) düşük reasoning seviyesi yeterli olabilirken, sonucu doğrudan bir işleme (fatura hesaplama, sözleşme analizi, kod dağıtımı) besleyen yüksek riskli görevlerde hem yüksek reasoning seviyesi hem de ayrı bir doğrulama katmanı bir arada düşünülmeli.

Sonuç

Chain of thought, yapay zeka modellerinin karmaşık problemleri çözme biçimini kökten değiştiren bir teknik oldu. 2022’de bir prompt mühendisliği hilesi olarak başlayan bu yaklaşım, 2026 itibarıyla GPT-5.5, Claude, Gemini Deep Think ve DeepSeek R1 gibi modellerin eğitim ve çıkarım yöntemleriyle desteklenen bir davranış haline geldi. Doğru kullanıldığında doğruluğu belirgin şekilde artırırken, gereksiz kullanıldığında maliyet ve gecikmeyi de artırabilir; bu yüzden görev bazlı bir reasoning stratejisi kurmak, hem geliştiriciler hem de bütçe yöneticileri için giderek daha kritik bir beceri haline geliyor.

Sık Sorulan Sorular

Chain of thought ile reasoning model aynı şey mi?

Tam olarak değil. Chain of thought bir tekniktir; reasoning modeller ise bu tekniği eğitim sürecine gömerek otomatikleştiren model ailesidir. Prompt tabanlı chain of thought, herhangi bir modelle uygulanabilirken, reasoning modelleri bu davranışı ek talimat olmadan sergiler.

Chain of thought her zaman daha doğru sonuç verir mi?

Hayır. Basit görevlerde fark yaratmayabilir, hatta bazı durumlarda gereksiz uzun ve dolaylı cevaplara yol açabilir. Fayda, görevin karmaşıklığıyla doğru orantılı artıyor.

Reasoning modelleri neden daha pahalı?

Çünkü nihai cevaba ek olarak ara adımları da token olarak üretiyorlar; bu da aynı soru için toplam token tüketimini artırıyor.

Muhakeme zincirini kullanıcıya göstermek güvenli mi?

Her zaman değil. Ham muhakeme bazen yanıltıcı, tutarsız veya hassas ayrıntılar içerebilir; bu yüzden bazı sağlayıcılar yalnızca özetlenmiş bir sürüm gösteriyor.

Küçük bir proje için reasoning modeline ihtiyacım var mı?

Göreviniz çok adımlı matematik, kod hata ayıklama veya karmaşık planlama içermiyorsa muhtemelen hayır; standart bir model çoğu görev için hem yeterli hem daha ekonomik olacaktır.

API Örneğinin Üretim Sınırları

Yukarıdaki PHP örneği Chat Completions söz dizimini kullanır: reasoning_effort bu uç noktanın alanıdır. Responses API’de reasoning: {"effort":"high"}, input ve farklı çıktı yapısı kullanılır. Modelin desteklediği çaba değerlerini kontrol edin. Eksik API anahtarı, cURL hatası, zaman aşımı ve HTTP hata kodu ayrı ele alınmadan örneği üretimde kullanmayın. Görünür çözüm özeti, modelin ham iç muhakemesinin kaydı değildir; daha yüksek çaba da doğruluk garantisi vermez.

Teknik kaynak: OpenAI — Reasoning modelleri.