LLM gözlemlenebilirliği kurmak

Gözlemlenebilirlik kurulumlarının çoğu, model çağrısını ölçüp orada duruyor. Oysa kullanıcının yaşadığı gecikmenin büyük kısmı çoğu zaman model çağrısının dışında: geri getirme, araç çağrıları, sıraya girme, yeniden denemeler. Model çağrısını tek başına ölçmek, doğru sayıyı yanlış soruya cevap olarak vermektir.

1. 1İstek girişi

   Bağıntı kimliği burada üretilir ve bütün alt adımlara taşınır.

2. 2Geri getirme

   Sorgu, dönen aday sayısı ve süre; boş dönüş ayrı bir sonuç durumu olarak işaretlenir.

3. 3Model çağrısı

   Her çağrı ayrı adım; yeniden denemeler tek adıma sıkıştırılmaz.

4. 4Araç çağrıları

   Dış sistem çağrıları kendi süreleri ve hata sınıflarıyla kaydedilir.

5. 5Yanıt çıkışı

   İz burada kapanır; toplam süre kullanıcının gördüğü süreyle aynı olmalıdır.

Şema sonradan yazıldığında, elinizdeki geçmiş kayıtların yarısında alanlar eksik olur ve karşılaştırma yapılamaz. Alan listesini baştan sabitlemenin asıl faydası tutarlılık: aynı soruyu iki farklı serviste aynı sorguyla sorabilmek.

{
  "iz_kimligi": "<bagintilandirma-kimligi>",
  "adim_kimligi": "3",
  "adim_turu": "model_cagrisi",
  "sure_ms": 0,
  "ilk_token_ms": 0,
  "girdi_token": 0,
  "cikti_token": 0,
  "model_kunyesi": "<cozulmus-model-kimligi>",
  "sonuc_durumu": "basarili",
  "hata_sinifi": null,
  "deneme_no": 1
}

Girdi ve çıktı tokenları aynı şey değil, hem maliyet hem gecikme tarafında farklı davranıyorlar. Girdi tokenları tek bir ön işleme geçişinde toplu değerlendirilir; bu yüzden uzun bağlamın bedeli ağırlıkla ilk token süresine biner, üretim süresine token başına eklenmez. Çıktı tokenları ise tek tek üretilir; her ek token doğrudan toplam süreye yazılır. Tek bir toplam alan tuttuğunuzda, gecikme artışının bağlamdan mı yanıt uzunluğundan mı geldiğini ayırt edemezsiniz.

• Girdi tokenı: sistem istemi, geri getirilen bağlam, konuşma geçmişi ve araç şemaları dâhil.
• Çıktı tokenı: üretilen yanıt; akıl yürütme çıktısı ayrı raporlanıyorsa ayrı alanda tutun.
• Önbellekten okunan girdi: sağlayıcı böyle bir alan veriyorsa ayrı yazın, yoksa alanı hiç açmayın.
• Deneme başına tekrar: yeniden denenen çağrının tokenları da gerçekten harcanmıştır.

Doğrulama adımı: bir günlük kayıttaki çağrı düzeyinde token toplamını, sağlayıcının kendi kullanım raporuyla karşılaştırın. Aradaki fark, kaydı atlanan çağrıların — genellikle yeniden denemelerin ve arka plan işlerinin — payıdır.

Ortalama gecikme, kullanıcıyı rahatsız eden şeyi göstermez. Şikâyetler kuyruktan gelir: yüz istekten beşinde yaşanan uzun bekleme, ortalamayı çok az oynatır ama algıyı belirler. Bu yüzden her bileşen için p50 ve p95 birlikte raporlanmalı; ikisi arasındaki açıklık, sistemin ne kadar kararsız olduğunu anlatır.

Akış (streaming) kullanıyorsanız kullanıcının algıladığı gecikme ilk token süresine yaklaşır, ama toplam süre hâlâ kaynak tüketimini belirler. İkisini birlikte raporlayın; yalnızca ilk token süresine bakmak, arka planda uzayan üretimleri gizler.

"Kalite ölçülemez" yaygın bir kabul ama yanlış: doğrudan ölçülemeyen şey cevabın doğruluğu, yoksa kalitenin bozulduğunu haber veren birkaç sinyal üretim kaydından bedava çıkıyor. Bu sinyaller kaliteyi tanımlamaz, ama kötüleştiğinde neredeyse her zaman birlikte hareket ederler.

• Şema doğrulama hatası: yapılandırılmış çıktı beklerken gelen bozuk yanıtların oranı.
• Kaçış cevabı oranı: modelin "bu konuda bilgim yok" benzeri bir çıkışa düştüğü istekler.
• Boş geri getirme: arama hiç aday döndürmediğinde; uydurma riskinin en güçlü habercisi.
• Kesilen yanıt: azami çıktı sınırına çarpıp yarıda kalan üretimler.
• Araç çağrısı hatası: şemaya uymayan veya var olmayan aracı çağırma denemeleri.
• Kullanıcı geri bildirimi: açıkça verilen olumsuz işaret ve yeniden sorma davranışı.

Kalite düşüşünde ilk bakılan yer model olur, oysa sık karşılaşılan senaryo şu: model de istem de aynı, değişen şey kullanıcıların ne sorduğu. Yeni bir ürün duyurulur, bir kampanya başlar, bir bölge açılır — girdi dağılımı kayar ve sistem daha önce hiç görmediği soru tipleriyle karşılaşır.

• İstek uzunluğu dağılımı: kısa sorular uzun sorulara dönüştüyse bağlam bütçesi de değişmiştir.
• Dil dağılımı: tek dilde kurulmuş bir hattın çok dilli trafik alması sessiz bir kalite kaybıdır.
• Konu dağılımı: kabaca etiketleme yeterli; kesin sınıflandırma şart değil.
• Yeni terim oranı: daha önce hiç görülmemiş kelimelerin payı.
• Oturum başına istek sayısı: artması çoğu zaman ilk cevabın yetersiz kaldığını gösterir.

Karşılaştırmayı sabit pencerelerle yapın: aynı gün sayısı, aynı saat aralığı. Hafta içi ile hafta sonunu karşılaştırmak, gerçek olmayan bir kayma üretir ve ilk uyarı kurulumlarının en sık hatası budur.

Mutlak eşikler kitaptan alınır ve sizin sisteminizde ya sürekli çalar ya hiç çalmaz. Doğrusu, kendi dağılımınızı ölçüp eşiği onun üstüne koymak. Taban ölçüm süresi, sistemin bütün doğal dalgalanmasını görecek kadar uzun olmalı: en azından bir tam hafta, mevsimsel iş yükü varsa daha fazlası.

Her izi sonsuza kadar saklamak ne gerekli ne mümkün. Ama örnekleme kararı baştan verilirse, tam da incelemek isteyeceğiniz nadir hatalar örneklemenin dışında kalır. Çözüm, kararı izin sonunda vermek: sonucu hatalı veya süresi eşiğin üstünde olan izler tamamıyla saklanır, geri kalanından oran belirlenerek örnek alınır.

1. 01Hatalı ve yavaş izleri istisnasız sakla; incelemenin tamamı buradan çıkar.
2. 02Başarılı izlerden sabit oranda örnek al; oran dağılımı bozmayacak kadar büyük olsun.
3. 03Sayısal ölçümleri örneklemeden geçirme; toplu ölçüm izden bağımsız toplanmalı.
4. 04Metin alanları için ayrı ve daha kısa bir saklama süresi tanımla.
5. 05Silme işini takvime değil hattın kendisine bağla.

Doğrulama adımı: saklama süresi dolmuş bir dönemi sorgulayın. Kayıtlar hâlâ duruyorsa politika yazılı ama uygulanmıyordur; bu, denetimde kâğıt üstündeki politikadan daha kötü bir durumdur.