Yazılım eğitimi asistanlarında adaptif görev zorluğu ve maliyet sınırı yönetimi

Makalenin hedefi ve başarım göstergeleri - yazılım eğitimi bağlamında

Bu makale, yazılım eğitimi asistanlarında adaptif görev zorluğu (adaptive difficulty) uygulayarak model çağrı maliyetini, ortalama token kullanımını ve öğrenci başarı oranını birlikte optimize etmenin somut yöntemlerini verir; kullanılacak ölçütler: çağrı/saniye, ortalama token/oturum, başarı oranı (% test geçişi). Teknik araçlar: Prometheus 2.x ile metrik toplama, Grafana dashboard, OpenTelemetry SDK (Python/Go) ile tracing.

Başarım göstergelerini (SLO) şu şekilde tanımlayın ve otomatik ölçün: 1) ortalama token/oturum <= X (Prometheus metric: llm_tokens_total / sessions_total), 2) model çağrı maliyeti/öğrenci <= Y (fatura/metrik karşılaştırması), 3) görev tamamlama oranı >= Z (test bazlı doğruluk). Prometheus'ta bu ölçüleri hesaplamak için örnek sorgu:

rate(llm_tokens_total[5m]) / rate(sessions_total[5m])

.

Adaptif görev zorluğu algoritması: somut uygulama ve kod örneği

Neden adaptif zorluk? Mekanizma: asistan, başlangıçta düşük tokenlı kısa istekler gönderir; öğrenci performansı iyi ise zorluk artırılır, kötü ise indirgenir. Bu, daha az model çağrısıyla hedeflenen öğrenme seviyesine ulaşılmasını sağlar çünkü model daha kısa bağlamlarda daha az rastgele yanıt üretir. Uygulama için gerekli bileşenler: Redis (öğrenci durum saklama), OpenAI/LLM istemcisi, Prometheus client.

Aşağıdaki Python örneği, Redis'te basit bir 'proficiency' göstergesi tutar, zorluk seviyesini (1-5) günceller ve istek başına hedef token sınırını belirler. Prometheus client ile metric artırımı gösterir:

from redis import Redis
from prometheus_client import Counter, start_http_server

redis = Redis(host='redis')
llm_calls = Counter('llm_calls_total', 'Total LLM calls')

def get_level(user_id):
    return int(redis.get(f'user:{user_id}:level') or 1)

def set_level(user_id, level):
    redis.set(f'user:{user_id}:level', level)

def target_tokens(level):
    return {1:120, 2:180, 3:320, 4:600, 5:1200}[level]

# değerlendirme döngüsü
def after_response_update(user_id, success):
    level = get_level(user_id)
    if success and level < 5:
        set_level(user_id, level + 1)
    elif not success and level > 1:
        set_level(user_id, level - 1)

# örnek kullanım
if __name__ == '__main__':
    start_http_server(8000)  # Prometheus scrappeable
    user = 'alice'
    level = get_level(user)
    tokens = target_tokens(level)
    # llm çağrısı burada yapılır (OpenAI/diğer)
    llm_calls.inc()

Bu basit modelde ölçülebilir kazanç: token/oturum'u Prometheus'ta izleyin (llm_tokens_total). Değişiklik yapmadan önce ve sonra 24 saatlik karşılaştırma yapın:

increase(llm_tokens_total[24h]) / increase(sessions_total[24h])

. Eğer ortalama token sayısı %25 azaldıysa, maliyet tahmini olarak benzer oranda düşer (faturalamada token başına price kullanılarak hesaplanır).

Gerçek zamanlı telemetri, profil ve before-after karşılaştırması

Profiling ve telemetri olmazsa değişikliğin etkisini kanıtlayamazsınız; kullanacağımız araçlar: py-spy (Python), pprof (Go), perf ve flamegraph, ayrıca dağıtık tracing için OpenTelemetry + Jaeger. Somut komutlar: Python hizmeti için py-spy ile örnek:

py-spy record -o profile.svg -- python app.py
# sonra profile.svg'i açıp hot path'leri inceleyin

Ölçüm planı (örnek): 1) Bazeline 48 saat veri topla (Prometheus, jaeger traces), 2) Adaptif algoritmayı deploy et, 3) 48 saat sonra tekrar topla. Karşılaştırma sorguları: latency için

histogram_quantile(0.95, sum(rate(http_request_duration_seconds_bucket[5m])) by (le))

; token kullanım için yukarıdaki llm_tokens_total sorgusu. CPU/heap hotspot için py-spy/pprof sonuçlarını flamegraph ile kıyaslayın. Bir değişiklik %10+ latency artışı veya %20+ error rate artışı getiriyorsa rollback kriteri koyun.

Edge case: py-spy sampling profiler, kısa süreli GC spike'larını kaçırabilir; bu yüzden critical path için pprof heap profiling veya valgrind massif gibi araçla memory leak analizi yapın:

go tool pprof -http=:8080 http://localhost:6060/debug/pprof/profile?seconds=30
# veya
valgrind --tool=massif ./binary
ms_print massif.out.pid

.

Token bütçesi, batching ve rate-limit uygulaması ile maliyet kontrolü

Maliyet kontrolü üç seviyede olmalı: istemci (frontend sınırları), servis (middleware token enforce) ve model çağrısı (batching). Örnek: envoy/nginx ile request-level rate limiting, Redis ile token-bucket. Nginx için somut limit_conf:

http {
  limit_req_zone $binary_remote_addr zone=one:10m rate=10r/s;
  server {
    location /api/llm {
      limit_req zone=one burst=20 nodelay;
    }
  }
}

İçeride, her istekten önce middleware token hesabı yapın; Python Flask örneği:

from flask import Flask, request, abort
from redis import Redis

app = Flask(__name__)
redis = Redis()

MAX_TOKENS_PER_SESSION = 5000

@app.before_request
def enforce_token_budget():
    user = request.headers.get('x-user')
    used = int(redis.get(f'user:{user}:tokens') or 0)
    if used > MAX_TOKENS_PER_SESSION:
        abort(429, 'token budget exceeded')

@app.route('/use_tokens', methods=['POST'])
def use_tokens():
    data = request.json
    user = request.headers.get('x-user')
    used = int(redis.get(f'user:{user}:tokens') or 0)
    redis.set(f'user:{user}:tokens', used + data['tokens'])
    return 'ok'

Batching örneği: arka planda Kafka/RabbitMQ ile kullanıcı isteklerini 50ms window ile toplayıp tek LLM çağrısına dönüştürün. Kafka consumer için somut parametre: fetch.min.bytes=1, fetch.max.wait.ms=50; bu, latency/throughput trade-off'unu ölçülebilir hale getirir. Ölçüm: batching ile çağrı başına token artışı vs çağrı sayısı düşüşü; Prometheus'ta çağrı_sayısı metric'inde değişim izleyin.

Üretim riskleri, doğrulama ve edge case testleri

Doğrulama adımları: deterministik replay için istek loglarını (input prompt + model response + seed) gzipped JSONL olarak saklayın ve pytest ile otomatik replay yapın. Örnek komut:

jq -c . events.jsonl | gzip > events.jsonl.gz
# replay script
python replay.py --input events.jsonl.gz --dry-run

Bu sayede adaptif değişikliklerin regresyona yol açıp açmadığını test edersiniz.

Edge case: zorluk seviyesinin hızlı sallanması (oscillation) - çözüm: hysteresis/adamant update ve minimum bekleme periyodu. Somut implementasyon: sadece 3 ardışık başarısızlık veya 5 başarılı olduysa seviye değiştir. Test için Hypothesis ile property-based test yazın:

from hypothesis import given, strategies as st
@given(st.lists(st.booleans(), min_size=1, max_size=100))
def test_stability(events):
    # events: True = success, False = fail
    ...

Güvenlik/sandbox: kod çalıştıran görevlerde Docker + seccomp + cgroups ile kaynak izolasyonu uygulayın; somut: docker run --rm --memory=256m --cpus="0.5" --security-opt seccomp=/path/seccomp.json. Ayrıca bir kötü modele karşı hızlı rollback: Kubernetes deployment için readiness probe ve Prometheus alert kullanın. Örnek Prometheus alert kuralı:

- alert: LLMErrorRateHigh
  expr: increase(llm_errors_total[5m]) / increase(llm_calls_total[5m]) > 0.05
  for: 2m

Sık Sorulan Sorular

Yazılım eğitimi asistanımda adaptif görev zorluğu nasıl ölçülür ve metrikleri nelerdir?

Somut metrikler: llm_tokens_total (Prometheus counter), sessions_total, llm_calls_total, llm_errors_total ve görev başına geçen süre (http_request_duration_seconds histogram). Ölçüm örneği: 24 saatlik token ortalaması için Prometheus sorgusu

increase(llm_tokens_total[24h]) / increase(sessions_total[24h])

. Bu metrikleri Grafana dashboard'larında SLO olarak koyun ve py-spy ile CPU hot path'lerini eşleyin.

Adaptif zorluk uygulaması maliyeti gerçekten düşürür mü, nasıl kanıtlarım?

Evet, ancak kanıtlanması için before-after deneyleri gerekir. Adımlar: 1) 48 saat baseline topla (Prometheus, billing export), 2) adaptif deploy et, 48 saat topla, 3) token/oturum ve çağrı/saniye karşılaştırması yap. Hesaplama: token başına fiyat * (ortalama token/oturum) * oturum sayısı. faturalama export CSV ile bunu eşleyin ve % değişimi raporlayın. Ayrıca py-spy/pprof ile CPU time değişimini de ölçün.

Yazılım eğitimi platformunda aşırı osilasyon (seviyenin sürekli değişmesi) problemi nasıl engellenir?

Uygulamalı çözüm: değişiklikleri hysteresis ile sınırlandırın — örn. seviyeyi yalnızca 3 ardışık başarı/başarısızlık sonrası değiştirin, minimum bekleme zamanı koyun. Teknik test: Hypothesis ile rastgele başarı/başarısız dizileri üretip davranışı doğrulayın; monitoring ile oscillation detekte edilirse Prometheus alert kuralı tetiklesin:

increase(level_changes_total[10m]) > 5

.