Yazılım Eğitimi Asistanlarında Uzun Bağlam Doğruluk Mühendisliği

Yazılım eğitimi için uzun bağlamı ölçülebilir bir probleme çevirin

Uzun bağlam hatasını ölçmek için üretim konuşmalarını doğrudan etiketlemeye çalışmayın. Önce ders notu, API dokümantasyonu ve ödev açıklamalarından 200-500 satırlık bir JSONL seti üretin. Her kayıtta tek bir kanıt parçası, buna bağlı soru ve kanıtın bağlam içindeki hedef konumu bulunmalıdır. Aynı kanıtı başlangıç, orta ve son konuma taşıyarak modelin konum duyarlılığını ayrı ölçün. Sadece başlangıç konumunda başarılı olan bir sistem, gerçek yazılım eğitimi oturumunda uzun ders materyalinin ortasındaki kritik istisnayı kaçırabilir.

{"id":"retry-middle-01","question":"HTTP 429 sonrası bekleme nasıl hesaplanır?","evidence":"Retry-After varsa saniye olarak kullanılır; yoksa exponential backoff uygulanır.","position":"middle","expected_terms":["Retry-After","exponential backoff"]}

Değerlendirmeyi exact match ile sınırlamayın. Her örnekte answer correctness, evidence recall ve unsupported claim sayısını kaydedin. Örneğin yanıtın beklenen terimleri içermesi tek başına yeterli değildir: model Retry-After bilgisini doğru aktarıp yanında kaynakta olmayan 'maksimum üç deneme' kuralını eklediyse unsupported claim sayısı 1 olmalıdır. Bu ayrımı yapmak için cevapları kaynak parçalarına cümle düzeyinde eşleştiren bir NLI modeli veya manuel olarak doğrulanmış 100 örneklik bir alt küme kullanın.

• Başlangıç, orta ve son konum için ayrı accuracy hesaplayın.
• Her konumda en az 50 örnek tutun; tekil başarısızlık yerine dağılımı görün.
• Orta konum accuracy'si uç konumların ortalamasından 10 puandan fazla düşükse, sorunun model seçiminden önce bağlam derleyicide olduğunu varsayın.
• Test setinde aynı kavramın eski ve yeni sürümünü birlikte bulundurun; yalnızca doğru pasajı seçen yanıtı başarılı sayın.

Bağlam derleyicide tekrar ve çelişkiyi token göndermeden çözün

Uzun bağlamdaki gereksiz tokenların önemli kısmı, aynı bilginin ders slaytı, README ve çözüm açıklamasında tekrar edilmesinden gelir. Embedding benzerliği tek başına yeterli değildir: iki parça birbirine çok benzerken birinde eski bir API imzası bulunabilir. Bu nedenle önce normalize edilmiş metin hash'i ile birebir tekrarları eleyin, sonra aynı konu anahtarındaki parçaları sürüm, kaynak güveni ve güncellik alanlarıyla sıralayın. SHA-256, sadece aynı metni tekrar göndermeyi engeller; anlamsal tekrar için ayrı bir embedding eşiği gerekir.

import hashlib
import re

def canonical(text: str) -> str:
    return re.sub(r'\s+', ' ', text.strip().lower())

def dedupe_exact(chunks):
    seen = set()
    kept = []
    for chunk in chunks:
        key = hashlib.sha256(canonical(chunk['text']).encode()).hexdigest()
        if key not in seen:
            seen.add(key)
            kept.append(chunk)
    return kept

Çelişki çözümünü modele bırakmak, özellikle iki farklı kurs sürümü aynı oturumda seçildiğinde belirsiz sonuç üretir. Her parçaya topic_key, source_version, published_at ve authority alanlarını ekleyin. Aynı topic_key için birden fazla sürüm seçildiyse, daha yeni ve yüksek authority değerli parçayı bağlama alın; diğerini ancak kullanıcı açıkça eski sürümü soruyorsa ekleyin. PostgreSQL tarafında bu seçimi window function ile retrieval sonrası yapabilirsiniz.

SELECT * FROM (
  SELECT c.*, ROW_NUMBER() OVER (
    PARTITION BY topic_key
    ORDER BY authority DESC, published_at DESC
  ) AS rn
  FROM retrieved_chunks c
  WHERE course_id = $1
) ranked
WHERE rn = 1;

İnce ama pahalı bir hata, kod bloklarını normal metin gibi semantik olarak parçalamaktır. Bir Python fonksiyonunun imzasını bir chunk'a, hata işleme bloğunu sonraki chunk'a ayırmak, modelin eksik kod üretmesine neden olur. tree-sitter ile AST tabanlı chunking kullanın: Python'da function_definition ve class_definition, TypeScript'te function_declaration ve method_definition düğümlerini bölünmez birimler kabul edin. Token sınırı aşılırsa yalnızca fonksiyon gövdesini statement sınırlarından bölün ve her parçaya dosya yolu ile satır aralığını ekleyin.

Kaynak bağlı yanıt sözleşmesi ile uzun bağlam halüsinasyonunu sınırlayın

Uzun bağlamda modelin doğru pasajı görmesi, o pasaja dayanarak yanıt vereceği anlamına gelmez. Yanıt protokolünü claim ve citation çiftleri etrafında kurun. Her teknik iddia, seçilen chunk_id ve satır aralığına bağlanmalı; doğrulayıcı bu aralığın gerçekten bağlama gönderildiğini kontrol etmelidir. Citation üretimini serbest metin sonrasına eklenen bir süs olarak tasarlamak yerine, model çıktısının zorunlu alanı yapın.

from pydantic import BaseModel, Field, model_validator

class Claim(BaseModel):
    text: str = Field(min_length=8)
    chunk_id: str
    start_line: int = Field(ge=1)
    end_line: int = Field(ge=1)

class GroundedAnswer(BaseModel):
    answer: str
    claims: list[Claim]

    @model_validator(mode='after')
    def claims_must_exist(self):
        if not self.claims:
            raise ValueError('At least one cited claim is required')
        return self

Doğrulamada yalnızca chunk_id kontrolü yapmayın. Model, doğru chunk_id verip yanlış satır aralığını gösterebilir. Kaynak satırlarını yeniden çıkarın ve claim metni ile kaynak arasında embedding cosine similarity eşiği yerine önce lexical anchor kontrolü uygulayın. Örneğin API adı, hata kodu veya yapılandırma anahtarı gibi en az bir teknik varlığın kaynakta bulunmasını zorunlu kılın. Çünkü genel cümlelerde embedding benzerliği yüksek kalırken '429' ile '503' gibi operasyonel açıdan farklı değerler karışabilir.

Kaynak doğrulaması başarısız olduğunda otomatik olarak aynı modelden 'daha dikkatli olmasını' istemek yerine ikinci geçişte yalnızca ilgili 3-5 chunk'ı gönderin ve cevap kapsamını daraltın. Bu retry, önceki uzun bağlamı tekrar taşımadığı için çelişkili pasajların etkisini azaltır. Yanıt sözleşmesine 'kanıt yoksa bilmiyorum de' kuralını açık biçimde ekleyin ve bu durumu başarısız istek değil, evidence_missing metriği olarak kaydedin.

Uzun bağlam gecikmesini OpenTelemetry ile önce ve sonra karşılaştırın

Bağlam kısaltmanın etkisini ortalama istek süresiyle ölçmeyin. OpenTelemetry span'larında retrieval_ms, rerank_ms, prompt_tokens, time_to_first_token_ms ve generation_ms alanlarını ayrı kaydedin. Özellikle time_to_first_token, sağlayıcının istemi ön işlemesi ve kuyruk davranışından etkilendiği için kullanıcı deneyimindeki ilk görünür gecikmeyi temsil eder. Python servisinde span attribute'larını istek tamamlandıktan sonra değil, seçilen chunk listesi oluşur oluşmaz yazın.

from opentelemetry import trace
tracer = trace.get_tracer(__name__)

with tracer.start_as_current_span('answer_request') as span:
    selected = compile_context(query, candidates)
    span.set_attribute('llm.prompt_tokens', token_count(selected))
    span.set_attribute('context.chunk_count', len(selected))
    response = llm.stream(messages(selected))
    first_token_ms = wait_for_first_token(response)
    span.set_attribute('llm.ttft_ms', first_token_ms)

Önce-sonra deneyinde aynı 300 sorguluk sabit veri setini, aynı model yönlendirmesi ve aynı eşzamanlılık düzeyiyle iki kez çalıştırın. İlk koşulda ham top-20 chunk'ı gönderin; ikinci koşulda exact dedupe, sürüm çözümü ve token bütçeli seçim uygulayın. p50, p95 ve p99 TTFT ile evidence recall değerlerini birlikte raporlayın. Token sayısı azalırken evidence recall düşüyorsa, kazanç yanlış parçaları keserek elde edilmiştir ve üretime alınmamalıdır.

Token bütçesini karakter sayısıyla hesaplamak yaygın bir hatadır; kod, URL ve JSON yoğun metinlerde karakter-token oranı ciddi biçimde değişir. Model sağlayıcınızın tokenizer'ını kullanın. Örneğin tiktoken desteklenen bir model ailesinde gerçek token sayısını encode ile ölçebilir, sistem iletisi, araç şemaları ve beklenen çıktı için ayrıca rezerv bırakabilirsiniz.

import tiktoken
enc = tiktoken.get_encoding('cl100k_base')
MAX_INPUT = 12000
RESERVED_OUTPUT = 1800
RESERVED_SYSTEM = 900
context_budget = MAX_INPUT - RESERVED_OUTPUT - RESERVED_SYSTEM
used = len(enc.encode(compiled_context))
if used > context_budget:
    compiled_context = trim_by_rank(compiled_context, context_budget)

Canlı yazılım eğitimi trafiğinde konum yanlılığını izleyin

Canlı sistemde model yanıtını etiketlemek pahalı olduğundan, bağlam kalitesini proxy metriklerle izleyin. Her cevap için cited_chunk_rank, cited_chunk_position_percentile, prompt_tokens ve evidence_missing alanlarını olay olarak yazın. Citation'ların sürekli ilk iki chunk'ta toplanması, retrieval iyi olsa bile modelin orta konumdaki kanıtı ihmal ettiğini gösterebilir. Bu sinyali ClickHouse veya BigQuery üzerinde haftalık dağılım olarak sorgulayın.

SELECT
  quantile(0.5)(cited_chunk_position_percentile) AS p50_position,
  countIf(evidence_missing = 1) / count() AS missing_rate
FROM answer_events
WHERE event_time >= now() - INTERVAL 7 DAY
GROUP BY course_id;

Konum yanlılığı tespit edildiğinde ilk çözüm her şeyi başa taşımak değildir; bu yaklaşım farklı kanıtların birbirini ezmesine yol açar. Soru ile en güçlü ilişkili iki chunk'ı başa, ikinci derecedeki destekleyici kanıtı sona, birbirinin tekrarı olan ayrıntıları ise araya koyan deterministik bir paketleme kuralı deneyin. Ardından aynı sentinel testini yeniden çalıştırın. Başlangıç ve son başarıları korunurken orta konum başarısı yükselmiyorsa, sorun sıralama değil chunk sınırları veya çelişkili kaynak seçimi olabilir.

Dağıtımda paketleme kuralını feature flag ile açın ve isteklerin yüzde 5'inde yeni kuralı kullanın. Flag değerlendirmesinde yalnızca olumlu kullanıcı oyu değil, citation coverage, evidence_missing rate ve p95 TTFT değerlerini karşılaştırın. Özellikle daha kısa bağlamın p95 TTFT'yi düşürüp evidence_missing rate'i yükseltmesi, maliyet ve doğruluk arasında kabul edilmemiş bir takas olduğunu açıkça gösterir.

Sık Sorulan Sorular

Yazılım eğitimi asistanında uzun bağlam için kaç token göndermeliyim?

Sabit bir token sayısı seçmeyin. Sistem iletisi, araç şemaları ve hedef çıktı için rezerv ayırdıktan sonra kalan bütçeyi gerçek tokenizer ile hesaplayın. Ardından 5k, 10k ve 15k gibi bütçeleri aynı sentinel setinde karşılaştırın; evidence recall artmıyorsa daha büyük bağlamı göndermeyin.

Yazılım eğitimi chatbotunda model orta kısımdaki dokümanı neden kaçırıyor?

Uzun istemlerde konum yanlılığı oluşabilir ve benzer ya da çelişkili chunk'lar hedef kanıtın dikkat ağırlığını azaltabilir. Kanıtı başlangıç, orta ve son pozisyonda taşıyan sentinel test kurun. Sonra exact dedupe, topic_key bazlı sürüm çözümü ve AST tabanlı kod chunking uygulayarak sonucu tekrar ölçün.

Yazılım eğitimi içeriklerinde LLM yanıtının kaynağa dayandığını nasıl doğrularım?

Her teknik iddia için chunk_id ve satır aralığını zorunlu çıktı alanı yapın. Pydantic ile boş citation listesini reddedin; ikinci aşamada citation satırlarından API adı, hata kodu veya yapılandırma anahtarı gibi teknik anchor'ların claim içinde gerçekten geçtiğini kontrol edin.

Uzun bağlam optimizasyonunda hangi gecikme metriklerini izlemeliyim?

OpenTelemetry ile prompt_tokens, retrieval_ms, rerank_ms, time_to_first_token_ms ve generation_ms alanlarını ayrı span attribute olarak kaydedin. Ham top-20 bağlam ile token bütçeli derlenmiş bağlamı aynı sorgu seti üzerinde p50, p95, p99 TTFT ve evidence recall ile birlikte karşılaştırın.