Bir modeli geniş liderlik tablolarında test etmek, onun genel kültür sorularını ve standart testleri ne kadar iyi yönettiğini söyler. Ancak, üretim sistemlerinizin gerçekte karşılaştığı karmaşık ve kısıtlı problemler üzerinde nasıl muhakeme yapacağı hakkında size neredeyse hiçbir şey söylemez. Herhangi bir büyük dil modelini kullanıcılara sunmadan önce, uygulamanızın gerektirdiği özel bilişsel kalıpları zorlayan bir test düzeneğine (harness) ihtiyacınız vardır. Muhakeme (reasoning) kıyaslamaları, modellerin kendilerini sohbet botlarından ayırdığı noktadır.

Bu kılavuz, sıfırdan odaklanmış bir muhakeme kıyaslaması oluşturma sürecini adım adım anlatmaktadır. Üç farklı mimariyi karşılaştıracaksınız: DeepSeek R1 671B MoE, Llama 3.3 70B ve Qwen 3 32B. GPU kümelerini bir araya getirmeye çalışmak yerine, her üçünü de Oxlo.ai üzerinden çalıştıracaksınız. Değerlendirme için, çıktıları muhakeme netliği, doğruluk ve kod kalitesi açısından puanlamak üzere bir hakem olarak Kimi K2.6'yı kullanacaksınız.

Muhakeme Neden İlk Sırada Bozulur?

Üretim ortamındaki hatalar nadiren dil bilgisi hataları veya reddetme şeklinde görülür. Bunlar daha çok ince mantık hataları şeklinde ortaya çıkar. Bir model, bir kısıtlamayı yanlış anlarken, bir adımı atlarken veya süreç ortasında sessizce bir değişkeni değiştirirken kendinden emin bir metin üretebilir. Genel kıyaslamalar genellikle derinlik yerine genişliğe ağırlık verir, bu nedenle bir model zor bir kombinatoryal problemi hiç çözmeden yüksek puan alabilir.

Hedef odaklı bir kıyaslama, sorunu zorunlu kılar. Her modele aynı kısıtlı optimizasyon görevini verir, izlenebilir bir düşünce zinciri (chain of thought) talep eder ve üretilen çözümün kuralları gerçekten karşılayıp karşılamadığını ölçer. Eğer bir model ayrık matematik (discrete math) üzerinde tutarlı bir şekilde muhakeme yapamıyorsa, envanter tahsisinizi, planlama motorunuzu veya kaynak yönlendiricinizi de güvenilir bir şekilde yönetemeyecektir.

Modeller ve Platform

DeepSeek R1 671B MoE, mixture-of-experts tasarımı kullanır. Her bir token için 671 milyar parametresinin yalnızca bir kısmı etkinleşir; bu da maliyet-performans eğrisini ve bazen muhakemesinin dokusunu değiştirir. Llama 3.3 70B yoğun (dense) bir modeldir, Qwen 3 32B ise güçlü çok dilli ve kodlama yeteneklerine sahip daha küçük bir ölçekte yer alır. Bu üçünü karşılaştırmak, muhakeme kalitesinin toplam parametre sayısı, aktif parametre sayısı veya eğitim metodolojisi ile paralel gidip gitmediğini size gösterir.

Oxlo.ai bu modelleri birleşik bir API arkasında barındırır. Çıkarım (inference) altyapısını yönetmek veya ayrı sağlayıcı anlaşmalarıyla uğraşmak zorunda kalmazsınız. Platform ayrıca token başına fiyatlandırma yerine istek başına (per-request) fiyatlandırma kullanır. İki bin kelimelik bir sistem istemi (system prompt), kısa bir tek satırlık istemle tam olarak aynı maliyettedir. Bu detay, göründüğünden daha önemlidir. Bu, girdi token maliyetlerinin şişmesini izlemek zorunda kalmadan kapsamlı talimatlar yazabileceğiniz, ayrıntılı biçimlendirme gereksinimleri ekleyebileceğiniz ve few-shot örnekleri dahil edebileceğiniz anlamına gelir. Kelime kalabalığı için değil, çağrı başına ödeme yaparsınız.

Python 3.10 veya daha yeni bir sürüme, OpenAI Python kütüphanesine ve bir Oxlo.ai API anahtarına ihtiyacınız olacak.

Adım 1: Uç Noktasına (Endpoint) Bağlanın

Oxlo.ai, OpenAI ile uyumlu bir API sunduğu için entegrasyon oldukça basittir. OpenAI SDK'sını Oxlo temel URL'sine yönlendirin, API anahtarınızı girin ve DeepSeek R1'e yapılacak hafif bir istek ile bağlantıyı doğrulayın. Mantık kontrolünü (sanity check) atlamayın. Gecikmeyi (latency) onaylayın, model tanımlayıcısının tanındığını doğrulayın ve ortamınızın saklamak istediğiniz yanıt formatını akış (stream) olarak alabileceğinden veya tamponlayabileceğinden (buffer) emin olun. El sıkışma (handshake) başarılı olduğunda, tek bir dizeyi (string) değiştirerek her üç modele de hitap edebilen tek bir istemciye sahip olursunuz.

Adım 2: Görevi Tasarlayın

Adım adım mantık gerektiren ve nesnel olarak ölçülebilir bir cevabı olan bir problem seçin. Bin-packing (kutulama) problemi olağanüstü iyi sonuç verir. Bu problem NP-hard'dır; yani açgözlü sezgisellerin (greedy heuristics) öngörülebilir şekillerde başarısız olduğu anlamına gelir ve modeli aynı anda birden fazla kısıtlamayı takip etmeye zorlar. Farklı boyutlardaki öğeler, limitleri aşmadan sabit kapasiteli kutulara sığmalıdır.

İstemini (prompt), modelin iki şey yapmasını gerektirecek şekilde kurgulayın: muhakeme sürecini tanımlasın ve ardından örneği çözen çalışan bir Python kodu sağlasın. Modelin herhangi bir kod yazmadan önce düşünce zincirini (chain-of-thought) göstermesini açıkça talep eden bir sistem istemi kullanın. Bu, genişletilmiş muhakeme izleri için optimize edilmiş olan DeepSeek R1 için özellikle önemlidir. Modelin kapasite kontrollerini düşünerek mi ilerlediğini yoksa sadece eğitim verilerine karşı örüntü eşlemesi (pattern-matching) mi yaptığını görmek istersiniz. İyi bir görev, şablon yanıtların başarısız olacağı kadar zorlayıcı (adversarial) olmalıdır.

Adım 3: Kıyaslamayı Çalıştırın

Feed the identical prompt to DeepSeek R1, Llama 3.3 70B, and Qwen 3 32B. Capture the full text responses, not just the final code blocks. Store them with timestamps and model identifiers. Since Oxlo.ai prices per request, you do not need to truncate your prompt or strip out clarifying instructions to save money. You can afford to be precise. That stability allows you to iterate on prompt design without cost anxiety, which leads to cleaner experiments and more reproducible results.

Run each model multiple times if your budget allows. Reasoning models can vary across stochastic generations, and you want to know whether a high score represents consistent competence or a lucky sample.

Step 4: Grade with an LLM Judge

Manual scoring does not scale, but numeric rubrics alone miss nuance. The middle ground is an LLM judge. Here, you will use Kimi K2.6. Feed it the original problem, the rubric, and each candidate response. Ask it to evaluate three specific dimensions:

  • Reasoning clarity: Does the explanation actually trace the logic, or does it hand-wave?
  • Correctness: Does the proposed solution satisfy all stated constraints?
  • Code quality: Is the Python clean, runnable, and free of obvious bugs?

Instruct the judge to return scores in JSON format. Structured output makes it trivial to diff results, plot trends, and feed downstream automation. Keep the judge prompt strict. If you give it a vague instruction like "rate the answer," you will get vague results. Instead, define what counts as a correct bin-packing solution. Capacities must not be exceeded. Every item must be assigned. The code must be syntactically valid. The more concrete your criteria, the more reliable your grades become.

Always spot-check the judge. If Kimi K2.6 consistently overrates one model because of surface-level polish, your benchmark is broken. A small human audit layer prevents garbage-in-garbage-out evaluation.

Step 5: Build the Report

Aggregate the JSON scores and pair them with excerpts from the raw model outputs. Drop everything into a single file that lives in your repository. When you update a model version or tweak the prompt, the diff in your pull request shows exactly how behavior shifted. A well-maintained benchmark becomes living documentation. It justifies why your production pipeline uses one model over another, and it catches silent regressions before they reach users.

Structure the report so a teammate can read it without running the code. Include the problem statement, the prompt template, the scores, and representative quotes from each model’s reasoning trace. Transparency matters. If DeepSeek R1 scores high but hallucinates a constraint, you want that visible in the text excerpt, not buried in an average.

Automating the Pipeline

A benchmark that lives only on your laptop is forgotten within a week. Move it into a nightly CI job. Every night, the harness spins up, queries the current model versions on Oxlo.ai, runs the bin-packing task, grades the outputs, and commits the results. If a model update causes a ten-point drop in correctness, you will know before your users do.

Once the core harness is stable, extend it. Test long-context variants by stuffing the prompt with irrelevant documents, then placing the bin-packing question at the end. Large context windows are useless if reasoning collapses under noise. See which models maintain logical discipline when the signal is buried in ten thousand tokens of distraction.

The Real Takeaway

Public leaderboards measure general knowledge. Your application measures something narrower and harder. A simple, repeatable harness that forces models to reason through constrained optimization, grades them with consistent criteria, and versions the results in git will give you more actionable insight than any aggregate score. Build the benchmark that fits your problem, run it across architectures that matter to you, and let the results dictate your production choice.

Source: DeepSeek R1 Model Architecture and Benchmarks

Community: GyaanSetu AI on Telegram