Yazılım Eğitimi LLM'lerinde Model Yönlendirme ve Maliyet Kontrolü

Yazılım eğitimi isteklerini görev sınıfına göre yönlendirin

Bir yazılım eğitimi asistanında 'binary search neden O(log n)?' ile 'bu Terraform planı production'a uygulanabilir mi?' isteğini aynı modele göndermek gereksizdir. İlk istek kısa, açıklayıcı ve düşük etkili; ikincisi ise altyapı değişikliği önerdiği için yüksek risklidir. Yönlendirme kararını modelin kendi doğal dil yanıtına bırakmayın. API katmanında görev türü, dosya bağlamı, beklenen çıktı uzunluğu ve etki alanını sayısal bir risk skoruna dönüştürün. Bu skor, hem hangi modelin seçileceğini hem de maksimum çıktı token'ını belirlemelidir.

Aşağıdaki TypeScript örneği, basit görevlerde ucuz modeli seçer; production, migration veya secrets içeren istekleri daha yetenekli modele ve insan onayı akışına taşır. `estimatedInputTokens` değeri, gerçek sağlayıcı kullanım bilgisinden önce `js-tiktoken` ile hesaplanabilir. Kritik ayrıntı: yönlendirme anahtarını kullanıcının serbest metninden değil, normalize edilmiş sunucu tarafı metadata'dan üretin; aksi halde kullanıcı 'low-risk' yazarak politikayı etkileyebilir.

type Route = { model: string; maxTokens: number; requireReview: boolean };

type RequestMeta = {
  task: 'explain' | 'debug' | 'review' | 'generate';
  filesChanged: number;
  estimatedInputTokens: number;
  hasProductionTerm: boolean;
  hasSecretLikeValue: boolean;
};

export function route(meta: RequestMeta): Route {
  const risk =
    (meta.task === 'review' ? 3 : 0) +
    (meta.task === 'generate' ? 1 : 0) +
    (meta.filesChanged > 8 ? 2 : 0) +
    (meta.estimatedInputTokens > 12000 ? 2 : 0) +
    (meta.hasProductionTerm ? 4 : 0) +
    (meta.hasSecretLikeValue ? 10 : 0);

  if (risk >= 7) {
    return { model: 'high-reasoning-model', maxTokens: 1800, requireReview: true };
  }
  if (risk >= 3) {
    return { model: 'balanced-model', maxTokens: 1200, requireReview: false };
  }
  return { model: 'fast-model', maxTokens: 700, requireReview: false };
}

Dosya içeriği taşıyan isteklerde yalnızca kelime aramak yeterli değildir. Örneğin `prod` adlı test fixture yanlış pozitif üretebilir, buna karşılık Kubernetes manifestindeki `kind: Secret` veya Terraform'daki `aws_iam_policy` daha güçlü sinyaldir. `tree-sitter` ile dile göre AST çıkarıp dosya uzantısı, kaynak türü ve değişen node sayısını metadata'ya ekleyin. CI üzerinde `npx tree-sitter parse infra/main.tf` komutu ile parse hatalarını görün; parse edilemeyen girdiyi düşük riskli yola göndermek yerine varsayılan olarak inceleme gerektiren yola alın.

Redis ile istek bazlı token ve para bütçesi uygulayın

Model yönlendirme tek başına maliyet sınırı değildir; aynı kullanıcı paralel 20 istek açarsa her worker kendi yerel sayacını görür ve aylık limiti aşabilir. Redis'te kullanıcı ve gün anahtarını atomik artıran Lua script kullanın. Ön provizyon, çağrıdan önce tahmini en kötü durum maliyetini rezerve eder; sağlayıcı yanıtındaki gerçek `input_tokens` ve `output_tokens` geldikten sonra fark iade edilir. Böylece timeout yaşayan bir çağrı, belirsiz kullanım maliyetini sessizce sınırsızlaştırmaz.

Aşağıdaki script, `limitMicros` değerini aşan rezervasyonu reddeder. Para değerini float yerine micro-USD gibi tamsayı birimde tutmak önemlidir: JavaScript `number` ile çok sayıda küçük maliyeti toplamak, sınırda karşılaştırma hatası üretebilir. Script'i `EVALSHA` ile çağırın ve anahtara UTC günü ekleyin; yerel saat dilimiyle gün döndürmek, gece yarısı yakınındaki istekleri iki farklı bütçe dönemine yanlış yazabilir.

-- reserve.lua
-- KEYS[1] = budget:{tenantId}:2026-08-27
-- ARGV[1] = requestedMicros, ARGV[2] = limitMicros, ARGV[3] = ttlSeconds
local used = tonumber(redis.call('GET', KEYS[1]) or '0')
local requested = tonumber(ARGV[1])
local limit = tonumber(ARGV[2])
if used + requested > limit then
  return {0, used, limit}
end
local nextUsed = redis.call('INCRBY', KEYS[1], requested)
redis.call('EXPIRE', KEYS[1], ARGV[3])
return {1, nextUsed, limit}

İade işlemini çağrı kimliğiyle idempotent yapın. Aynı HTTP isteği ağ kesintisi nedeniyle yeniden işlendiğinde hem rezervasyon hem iade iki kez uygulanabilir. PostgreSQL'de `llm_usage(request_id primary key, reserved_micros, actual_micros, status)` tablosuna önce `pending` kaydı ekleyin; yanıt alındığında `UPDATE ... WHERE status = 'pending'` ile tek seferlik mutabakat yapın. `request_id` için istemciden gelen değeri doğrudan kabul etmeyin; gateway'de UUID üretin ve OpenTelemetry trace id ile ilişkilendirin.

Kalite eşiğini ikinci model çağrısı olmadan tasarlayın

Her düşük maliyetli yanıtı ikinci bir LLM'e puanlatmak, bazı sistemlerde toplam çağrı sayısını ikiye katlar. Önce deterministik, göreve özgü kontroller uygulayın. Kod açıklaması isteniyorsa yanıtın alıntıladığı sembollerin gerçekten repository'de bulunup bulunmadığını `ripgrep` veya Language Server Protocol üzerinden doğrulayın. Bir hata ayıklama önerisi için de önerilen komutların allowlist dışında olmadığını kontrol edin. Bu kontroller, modelin ikna edici fakat mevcut olmayan `UserRepository.findByEmailCached` gibi API uydurmasını yakalar.

Örnek olarak aşağıdaki denetim, markdown içindeki backtick ile yazılmış TypeScript sembollerini `rg` üzerinden arar. Bu bir güvenlik sandbox'ı değildir; `execFile` kullanımı shell injection riskini azaltır, fakat repository yolunu yine sunucu tarafından sabitlemeniz gerekir. Sembol bulunamadığında hemen pahalı modele geçmek yerine kullanıcıya 'sembol bağlamda yok' geri bildirimi ve kaynak dosya seçme seçeneği verin; bu, gereksiz eskalasyonları azaltır.

import { execFile } from 'node:child_process';
import { promisify } from 'node:util';
const execFileAsync = promisify(execFile);

export async function verifySymbols(answer: string, repoDir: string) {
  const symbols = [...answer.matchAll(/`([A-Za-z_$][\w$]*)`/g)]
    .map(m => m[1])
    .filter(s => s.length > 2)
    .slice(0, 20);

  const missing: string[] = [];
  for (const symbol of symbols) {
    const result = await execFileAsync('rg', ['-l', '--glob', '*.{ts,tsx}', symbol, repoDir]);
    if (result.stdout.trim() === '') missing.push(symbol);
  }
  return { pass: missing.length === 0, missing };
}

Deterministik kontrolün kapsamadığı mimari yorumlar için örnekleme tabanlı denetim kullanın. Her route için yüzde 2 trafik örnekleyip, körleştirilmiş değerlendirme setinde insan veya ayrı bir değerlendirme modeliyle doğruluk puanı toplayın. PostgreSQL sorgusunda `WHERE hashtextextended(request_id, 42) % 100 < 2` benzeri kararlı örnekleme, yeniden denemelerde aynı isteğin tekrar seçilmesini sağlar. Rastgele `Math.random()` ile seçim yapmak, retry trafiğinde örnekleme oranını bozabilir.

Model yönlendirme performansını önce-sonra ölçün

Bu değişikliği sadece ortalama maliyetle değerlendirmeyin. OpenTelemetry ile her LLM çağrısına `llm.model`, `llm.route`, `llm.input_tokens`, `llm.output_tokens`, `llm.cost_micros`, `llm.first_token_ms` ve `llm.total_ms` özniteliklerini ekleyin. Grafana veya Honeycomb'da route bazında p50, p95 ve hata oranını ayırın. Streaming kullanan uygulamalarda kullanıcı deneyimini çoğunlukla `first_token_ms` belirler; yalnızca toplam süreyi ölçmek, hızlı başlayan ama uzun süren yanıtlarla geç başlayan kısa yanıtları birbirine karıştırır.

Önce iki hafta boyunca mevcut 'tek model' akışını kontrol grubu olarak kaydedin. Sonra tenant bazlı sabit hash ile trafiğin yüzde 10'unu routing politikasına atayın. Aynı görev sınıfı için karşılaştırın: örneğin `debug` isteklerinde p95 ilk token süresi, istek başına medyan micro-USD ve deterministik kontrol geçiş oranı. Aşağıdaki SQL, route farkını günlük toplam yerine istek dağılımı üzerinden görünür yapar; `percentile_cont` olmadan yalnızca ortalama almak, uzun kuyruktaki pahalı istekleri gizler.

SELECT
  route,
  percentile_cont(0.50) WITHIN GROUP (ORDER BY first_token_ms) AS p50_first_token_ms,
  percentile_cont(0.95) WITHIN GROUP (ORDER BY first_token_ms) AS p95_first_token_ms,
  percentile_cont(0.50) WITHIN GROUP (ORDER BY cost_micros) AS p50_cost_micros,
  avg(CASE WHEN quality_check_pass THEN 1.0 ELSE 0.0 END) AS pass_rate
FROM llm_request_metrics
WHERE created_at >= now() - interval '14 days'
  AND task = 'debug'
GROUP BY route;

Önce-sonra kararında bir koruma eşiği belirleyin: örneğin deney kolunun medyan maliyeti azalırken kalite kontrol geçiş oranı kontrol grubuna göre 1 yüzde puandan fazla düşerse rollout'u durdurun. İstatistiksel anlamlılık için küçük örneklerde güven aralığı hesaplayın; Python'da `scipy.stats.bootstrap` ile `pass_rate` farkının yüzde 95 güven aralığını çıkarabilirsiniz. Maliyet düşüşü gözlenirken kalite düşüşünün rastlantısal olup olmadığını bu ayrım olmadan söyleyemezsiniz.

Streaming, retry ve fallback döngülerini sınırlayın

En sık gözden kaçan hata, streaming bağlantısı koptuğunda gateway'in aynı isteği farklı modele tekrar göndermesidir. Sağlayıcı ilk token'ları üretmiş olabilir; retry hem çift maliyet hem de kullanıcıya iki farklı yanıt yaratır. İstemcinin `AbortSignal` iptalini sağlayıcı SDK'sına iletin, `request_id` ile kısmi yanıtı saklayın ve yalnızca hiç byte alınmamışsa otomatik retry yapın. HTTP katmanında `Idempotency-Key` başlığını `request_id` ile eşleştirin.

Fallback zincirine en fazla bir geçiş ve mutlak bir deadline koyun. Örnekte ilk model 429 veya 5xx dönerse fallback yapılır, fakat doğrulama başarısızlığında tekrar tekrar model çağrısı yapılmaz. Bu ayrım önemlidir: geçici sağlayıcı hatası ile modelin yetersiz yanıtı aynı retry politikasına konursa, kalitesiz bir girdide bütçe hızla tüketilir.

const deadline = AbortSignal.timeout(12_000);

async function completeWithOneFallback(input: string, requestId: string) {
  for (const model of ['fast-model', 'balanced-model']) {
    try {
      return await provider.complete({ input, model, requestId, signal: deadline });
    } catch (err: any) {
      const retryable = err.status === 429 || err.status >= 500;
      if (!retryable || model === 'balanced-model' || deadline.aborted) throw err;
    }
  }
}

Operasyonel olarak fallback oranı için alarm kurun. Prometheus sayaçları `llm_requests_total{route,model,outcome}` ve `llm_fallback_total{reason}` şeklinde tutulursa, `sum(rate(llm_fallback_total[10m])) / sum(rate(llm_requests_total[10m]))` sorgusu ile ani model bozulmasını görebilirsiniz. Yüzde 3 üzerindeki fallback oranında otomatik olarak daha ucuz modele geçmek doğru değildir; önce sağlayıcı hata kodu, token aşımı ve kalite kontrol nedenlerini ayrı etiketlerde inceleyin.

Sık Sorulan Sorular

Yazılım eğitimi uygulamasında hangi LLM isteği pahalı modele yönlendirilmeli?

Görev adı tek başına yeterli değildir. `review` görevi, production veya secrets sinyali, değişen dosya sayısı ve tahmini giriş token'ı gibi metadata ile risk skoru üretin. Örneğin Terraform IAM policy içeren bir code review isteğini yüksek risk yoluna alın; kısa bir algoritma açıklamasını düşük maliyetli modele gönderin.

Yazılım eğitimi LLM maliyet limiti Redis ile nasıl güvenilir uygulanır?

Çağrıdan önce en kötü durum token maliyetini Redis Lua script'iyle atomik rezerve edin. Yanıttaki gerçek kullanım verisi geldiğinde PostgreSQL'deki `request_id` anahtarlı kayıt üzerinden yalnızca bir kez iade veya ek tahsilat yapın. Yerel process belleğindeki sayaçlar çok worker ve paralel isteklerde limit aşımını engelleyemez.

Model yönlendirme kalitesini hangi metriklerle ölçmeliyim?

OpenTelemetry ile route, model, input-output token, `first_token_ms`, toplam süre, micro-USD maliyet ve kontrol sonucu kaydedin. Kontrol ve deney gruplarını sabit request hash'iyle ayırın; `debug` gibi aynı görev sınıfında p95 ilk token süresi, medyan maliyet ve kalite kontrol geçiş oranını PostgreSQL percentile sorgusuyla karşılaştırın.

Yazılım eğitimi asistanında LLM fallback neden sonsuz retry olmamalı?

429 ve 5xx gibi geçici sağlayıcı hatalarında en fazla bir fallback mantıklıdır. Şema veya repository sembol kontrolü başarısız olduğunda yeniden üretim döngüsü ise aynı hatalı bağlam için maliyeti büyütür. Tek fallback, ortak deadline ve `request_id` tabanlı idempotency kullanın.