Yazılım Eğitimi Asistanlarında LLM Canary ve Geri Alma Tasarımı

Yazılım eğitimi asistanında değişiklik birimi: sürüm paketi

Bir canary dağıtımında yalnızca model adını değiştirmek yeterli değildir. Prompt revizyonu, model parametreleri, sistem araç politikası ve retrieval indeks sürümü birlikte bir release paketi oluşturmalıdır. Aksi halde bir hatalı yanıtı tekrar üretmeye çalışırken aynı prompt ile farklı indeksin veya farklı temperature değerinin kullanıldığı bir birleşim elde edersiniz. Her istek başında paketi çözün, paket kimliğini konuşma dönüşüyle PostgreSQL'e yazın ve streaming başladıktan sonra bu nesneyi değiştirmeyin.

type Release = {
  id: string;
  model: string;
  promptRevision: string;
  retrievalIndex: string;
  temperature: number;
};

async function answerTurn(input: TurnInput, release: Release) {
  await db.query(
    `insert into assistant_turn
       (id, conversation_id, release_id, prompt_revision, retrieval_index)
     values ($1, $2, $3, $4, $5)`,
    [input.turnId, input.conversationId, release.id,
     release.promptRevision, release.retrievalIndex]
  );

  return llm.stream({
    model: release.model,
    temperature: release.temperature,
    system: await prompts.load(release.promptRevision),
    documents: await search.index(release.retrievalIndex).query(input.text)
  });
}

Bu kayıt, canary sonucunu yalnızca kullanıcı memnuniyetiyle değil, belirli bir release paketiyle ilişkilendirir. Yaygın hata, `current_prompt` gibi process belleğindeki değişkeni stream devam ederken okumaktır: deploy veya feature-flag yenilemesi sonrasında yanıtın ilk yarısı eski sistem talimatıyla, araç çağrısı ise yeni politikayla yürüyebilir. Release paketini istek sınırında immutable nesne olarak taşımak bu yarış durumunu ortadan kaldırır.

Promptfoo ile davranış regresyon kapısı kurun

Canary'den önce, üretimde karşılaşılan hatalardan türetilmiş sabit bir test kümesini CI içinde çalıştırın. Kod üreten bir yazılım eğitimi asistanı için testler yalnızca metin benzerliği ölçmemeli; parametrik SQL, hata mesajının korunması ve istenmeyen API kullanımı gibi denetlenebilir özellikleri kapsamalıdır. Promptfoo, aynı fixture'ı aday ve mevcut release'e gönderip assertion sonuçlarını JSON olarak dışa aktarabilir.

description: code-assistant-release-gate
providers:
  - id: openai:chat:gpt-4o-mini
prompts:
  - file://prompts/debug-typescript.txt
tests:
  - vars:
      source: 'const q = `select * from users where id = ${id}`'
      request: 'SQL injection riskini düzelt ve nedenini açıkla.'
    assert:
      - type: icontains
        value: '$1'
      - type: not-icontains
        value: 'eval('
      - type: javascript
        value: 'output.length > 80 && output.includes("parameter")'

  - vars:
      source: 'await client.get(`/users/${id}`)'
      request: 'Bu çağrı timeout olduğunda tekrar deneme ekle.'
    assert:
      - type: icontains
        value: 'AbortController'
      - type: icontains
        value: 'retry'

Pipeline'da bu dosyayı `npx promptfoo eval -c promptfooconfig.yaml --output results.json` ile çalıştırın ve aday release'in kritik assertion başarısızlık oranısını mevcut release ile karşılaştırın. Özellikle LLM çıktısında markdown code fence bulunduğunda doğrudan `node --check` çalıştırmak yanlış negatif üretir; önce fence'leri güvenilir bir parser ile ayıklayın veya test isteğinde yalnızca derlenebilir kaynak kod istenmesini zorunlu tutun. Deterministik assertion'lar ile ayrı bir insan inceleme kuyruğunu ayırmak da önemlidir: kodda `$1` geçmesi otomatik ölçülebilir, öğretici açıklamanın doğruluğu ise örneklem tabanlı inceleme gerektirir.

Kararlı canary ataması ve araçsız gölge trafik

Kullanıcıyı her istekte rastgele aday modele göndermek, aynı konuşmada farklı davranışlar ürettiği için ölçümü bozar. Kararlı bir HMAC kovası kullanın; aynı kullanıcı ve aynı rollout tuzu, oturumlar arasında aynı pakete gider. Tuzu rollout tamamlanana kadar değiştirmeyin. Ham kullanıcı kimliğini metrik etiketi olarak göndermeyin; Prometheus'ta yüksek cardinality oluşturur ve kimlik verisi sızdırır.

import { createHmac } from 'node:crypto';

function inCanary(userId: string, rolloutSalt: string, percent: number) {
  const digest = createHmac('sha256', rolloutSalt)
    .update(userId)
    .digest();
  const bucket = digest.readUInt32BE(0) % 10_000;
  return bucket < percent * 100;
}

const release = inCanary(user.id, process.env.ROLLOUT_SALT!, 5)
  ? releases.candidate
  : releases.stable;

Gölge trafikte kullanıcıya yalnızca kararlı release'in yanıtını gösterin; aday çağrıyı aynı normalize edilmiş istemle arka planda çalıştırıp çıktıyı değerlendirme deposuna yazın. Ancak gölge çağrıda tool calling kapalı olmalıdır. Adayın `create_ticket` veya `run_code` aracıyla yaptığı yan etkiyi sonradan silmek güvenilir bir telafi stratejisi değildir. Araç davranışını da ölçmek gerekiyorsa gerçek aracın yerine isteği kaydeden bir fake endpoint kullanın ve her çağrıya `turnId` tabanlı idempotency key verin.

Gecikme profilini k6 ve OpenTelemetry ile önce-sonra ölçün

Canary kararında sadece toplam hata oranına bakmak, kullanıcı ilk tokenı beklerken oluşan kuyruklanmayı gizler. OpenTelemetry span'larında `llm.release_id`, `llm.model_family`, `llm.streaming` ve `llm.tool_mode` gibi düşük cardinality alanları tutun; prompt metnini, kullanıcı kimliğini ve tam konuşma kimliğini attribute yapmayın. Stream döngüsünde ilk delta anını `ttft_ms`, son delta anını `ttlc_ms` olarak histogram'a kaydedin.

const started = performance.now();
let firstTokenAt: number | undefined;

for await (const event of stream) {
  if (event.type === 'text_delta' && firstTokenAt === undefined) {
    firstTokenAt = performance.now();
    metrics.ttftMs.record(firstTokenAt - started, {
      release_id: release.id,
      route: 'assistant'
    });
  }
  response.write(event.delta ?? '');
}
metrics.ttlcMs.record(performance.now() - started, {
  release_id: release.id,
  route: 'assistant'
});

Örneğin gateway'de model sağlayıcısına giden bağlantı havuzunun eşzamanlılık sınırını 8'den 24'e çıkarmayı düşünüyorsanız, bunu doğrudan üretimde varsaymayın. Aynı model, aynı retrieval indeksi ve aynı 20 temsilci istemle önce `MAX_INFLIGHT_MODEL_CALLS=8`, sonra `MAX_INFLIGHT_MODEL_CALLS=24` çalıştırın. k6 ile 30 dakika sabit varış hızında yük üretin: `k6 run --vus 40 --duration 30m scripts/assistant-stream.js`. Karar için p95 `ttft_ms`, p95 `ttlc_ms`, sağlayıcı 429 oranı ve gateway kuyruk süresini birlikte kıyaslayın. Daha yüksek sınır p95 ilk token süresini düşürürken 429 oranını yükseltiyorsa, mekanizma sağlayıcı tarafındaki rate limit kuyruğudur; sınırı büyütmek yerine tenant bazlı kuyruk ve exponential backoff gerekir.

Argo Rollouts ile ölçüme bağlı otomatik geri alma

Kubernetes üzerinde Argo Rollouts kullanıyorsanız, aday pod'un HTTP 200 dönmesini başarı ölçütü saymayın. LLM geçidi 200 ile boş, kesilmiş veya sonradan güvenlik filtresine takılan stream döndürebilir. Prometheus'ta uygulama seviyesinde `llm_completed_total{release_id,outcome}` sayacı üretin; `outcome` kümesini `ok`, `provider_error`, `timeout`, `policy_block` gibi sabit değerlerle sınırlayın. Ardından adayın hata oranını rollout analizine bağlayın.

apiVersion: argoproj.io/v1alpha1
kind: AnalysisTemplate
metadata:
  name: llm-candidate-health
spec:
  metrics:
    - name: candidate-failure-rate
      interval: 1m
      count: 5
      failureLimit: 1
      successCondition: result[0] < 0.015
      provider:
        prometheus:
          address: http://prometheus.monitoring.svc:9090
          query: |
            sum(rate(llm_completed_total{release_id='candidate',outcome=~'provider_error|timeout'}[5m]))
            /
            clamp_min(sum(rate(llm_completed_total{release_id='candidate'}[5m])), 1)

Rollout adımlarında önce yüzde 1 trafik, ardından en az beş analiz penceresi, sonra yüzde 5 ve yüzde 25 trafik kullanın. Bunun yanında product metriği olarak kullanıcı tarafından kabul edilen kod oranını veya aynı dönüş içinde yapılan manuel düzeltme sayısını release bazında kaydedin. Otomatik rollback yalnızca teknik hata oranına bağlanırsa, derlenen fakat yanlış öğretici yönlendirme veren bir aday uzun süre yaşayabilir. Buna karşılık ürün metriğini istatistiksel olarak anlamlı örnek sayısına ulaşmadan rollback tetikleyicisi yapmak da gürültülüdür; bu metriği alarm ve insan onayı için kullanmak daha güvenli bir ayrımdır.

Sık Sorulan Sorular

Yazılım eğitimi asistanında LLM canary yüzdesi nasıl seçilir?

İlk adımı yüzde 1 ile başlatın, ancak yüzdeyi kullanıcı sayısına göre değil tamamlanmış istek sayısına göre değerlendirin. Örneğin aday için en az 500 tamamlanmış stream, beş adet 1 dakikalık Prometheus analiz penceresi ve kabul edilebilir `provider_error|timeout` oranı olmadan yüzde 5'e geçmeyin. Aynı kullanıcıyı HMAC kovasıyla sabit pakete bağlayın.

Yazılım eğitimi için LLM gölge trafiğinde tool calling neden kapatılmalı?

Gölge çağrı kullanıcıya görünmese de aday model gerçek HTTP aracı üzerinden bilet açabilir, kod çalıştırabilir veya veri değiştirebilir. Shadow worker'a yalnızca read-only retrieval aracı verin; yazma araçlarını fake endpoint'e yönlendirin. Fake endpoint istek gövdesi, tool adı ve `turnId` idempotency key'ini denetim deposuna kaydetmelidir.

LLM canary gecikmesini hangi metriklerle ölçmeliyim?

OpenTelemetry histogram'larında p50 ve p95 `ttft_ms` ile `ttlc_ms` ölçün; buna gateway queue süresi, sağlayıcı 429 oranı ve stream kesilme oranını ekleyin. k6 ile aynı istem setinde önce ve sonra en az 30 dakikalık sabit yük testi çalıştırın. Sadece ortalama süre kullanmak, az sayıdaki uzun kuyruk beklemesini görünmez kılar.

Prompt değişikliğinde rollback için yalnızca HTTP hata oranı yeterli mi?

Yeterli değildir. HTTP 200 alan bir stream yanlış SQL, eksik hata yönetimi veya politika ihlali içerebilir. CI kapısında Promptfoo assertion'larıyla parametrik sorgu, yasak API ve beklenen hata yönetimi kurallarını test edin; üretimde ise `policy_block`, stream kesilmesi ve kullanıcı düzeltme oranını release kimliğiyle ayrı ayrı izleyin.