Ajanınız Üretim Ortamında Hata Verdi: Geçmiş Olsun, Şimdi Nasıl Yeniden Üreteceksiniz?

9:04

Üretim ortamında bir hata kaydı aldınız: LLM ajanı yanlış veriyi silmiş. Ancak kendi ortamınızda aynı prompt sorunsuz çalışıyor. Tekrar deneseniz de hata oluşmuyor. İşte bu, geliştiricilerin en büyük kabusu olan üretilebilirlik (reproducibility) problemidir.

"Üretilebilirlik" Gerçekte Ne Anlama Geliyor?

Burada iki kavramı ayırmalıyız: Bit düzeyinde determinizm (her zaman birebir aynı çıktıyı almak) ve yeniden oynatılabilirlik (replayability - gerçekleşen çalışmayı adım adım izleyebilmek). LLM'lerde determinizm zordur, bize lazım olan ise yeniden oynatılabilirliktir. Enerjimizi determinizme değil, izlenebilirliğe harcamalıyız.

Sıfır Sıcaklık (Temperature Zero) Sizi Kurtarmaz

temperature=0 yapmak logits (olasılık skorları) üzerindeki seçim kuralını (argmax) deterministik yapsa da, logits değerlerinin kendisinin her çalıştırmada aynı kalacağını garanti etmez. En ufak bir bit sapması tüm çıktıyı değiştirebilir. Körü körüne sıfır sıcaklığa güvenmeyin.

İlk Günah: Kayan Noktalı Sayılar Birleşmeli Değildir

Bilgisayarlarda kayan noktalı (floating point) sayılarda toplama sırası sonucu etkiler. Transformer modellerindeki milyonlarca işlemde, toplama sırasındaki en ufak değişiklik bir sonraki kelime seçimini tamamen değiştirebilir. LLM davranışlarını anlamak için sayısal hesaplama temelleri kritiktir.

Gerçek Suçlu Herkesin Söylediği Şey Değil

Sorun eşzamanlılık değil, grup bağımsızlığı (batch invariance) eksikliğidir. Üretim sunucuları istekleri gruplar (batch). İsteğinizin diğer hangi isteklerle gruplandığı, logits değerlerini ve dolayısıyla çıktıyı etkiler. Canlı ortam yükü, yerel testlerde simüle edilemeyen gizli bir değişkendir.

Uzmanlar Karışımı (MoE) Yeni Bir Kapı Açar

MoE modellerinde kapasite faktörü (capacity factor) nedeniyle, uzmanların (experts) doluluk oranına göre token'larınız alternatif yollara sapabilir. Bu da tekil isteklerde rastlantısallık yaratır. Modern mimarileri öğrenirken bu tarz donanım sınırlarını bilmeliyiz.

Tam 360 Derece: Altınızda Kayan Her Şey

LLM dışındaki dinamikler de çıktıyı değiştirir: dinamik promptlar, RAG indeksleri, API verileri ve model sürüm güncellemeleri. Geliştiriciler olarak tüm dış girdileri kontrol altında tutmalıyız.

Bekleyin: Aslında Bunun Bir Kısmını İstiyoruz

Determinizm peşinde koşarken ajanın kalitesini bozmamalıyız. Çeşitlilik (variation) yaratıcılık, hata ayıklama döngülerinden kaçış ve FunSearch gibi bilimsel keşifler için gereklidir. LLM'lerin gücü bu esneklikten gelir.

Uzlaşı

Çözüm; üretim (generation) aşamasında çeşitliliği korumak, yeniden oynatma (replay) aşamasında ise deterministik olmaktır.

Kaydet ve Yeniden Oynat (Record and Replay)

Hatayı çözmek için modeli tekrar çalıştırmak yerine hata anındaki girdileri, araç çağrılarını ve dönen yanıtları kaydedip incelemeliyiz. Bu sayede test ortamında (CI) maliyetsiz ve hızlı doğrulamalar yapabiliriz. Phoenix veya OpenInference gibi telemetri araçlarını entegre etmeliyiz.

Düzeltme Döngüsündeki Tuzak

Promptu değiştirdiğiniz an girdi değiştiği için kayıt geçersiz kalır. Bu yüzden testlerinizi ikiye bölmelisiniz: Akış kontrolü için yapısal eşleşme ve esnek kısımlar için LLM hakemli semantik kontrol.

Test Sürecinizde Bunu Nasıl Uygularsınız?

Ağ paketleri seviyesinde değil, ajan çerçevesi (LangGraph, LlamaIndex vb.) sınırlarında durum geçişlerini kaydetmelisiniz. Girdileri temizleyip (canonicalization) hash'lemelisiniz.

Pazartesi Günü Uygulayabileceğiniz Yol Haritası

• Determinizmi bırakın.
• Model sürümlerini sabitleyin.
• Tüm çalışma bağlamını kaydedin.
• Hata ayıklamak için yeniden oynatmayı kullanın.

Henüz Çözülmemiş Neler Var?

Grup bağımsızlığı sağlayan çekirdekler (kernels) henüz standart değil ve tescilli API modellerinin ağırlık güncellemelerini kontrol edemiyoruz.

9:04'e Geri Dönüş

Elinizde hata anının kaydı (envelope) olduğunda, ajanınızın neden hata yaptığını tam olarak görebilir ve sorunu hemen çözebilirsiniz.

Orijinal makaleye buradan ulaşabilirsiniz.