Yapay Zekâ Gözlemlenebilirliği: Tokenlar, Maliyet ve Veri Kaybını Önleme

Yapay zekâ projelerinde en yaygın hata, sistemlerin yalnızca çıktı yanıtlarını kaydetmekle yetinmesidir. Oysa AI çağrıları sıradan HTTP istekleri değildir — gizli token maliyetleri, karmaşık araç kullanımları ve hassas veriler gözden kaçabilir.

Örneğin, aşağıdaki beş satırlık fonksiyonu düşünün:

async function soruSor(soruMetni: string) {
  const yanıt = await openai.responses.create({
    model: "o4-mini",
    input: soruMetni
  });
  console.log("yanıt:", yanıt.output_text);
  return yanıt.output_text;
}

Bu kod çalışır, testleri geçer ve üretime gönderilir. Ancak ay sonunda fatura geldiğinde 4.000 dolarlık gizli maliyetin farkına varırsınız — çünkü model 40 tokenlık basit bir yanıtı üretmek için 8.000 gizli akıl yürütme tokenı harcamıştır.

İşte yapay zekâ gözlemlenebilirliğinin asıl sorunu da burada yatıyor: API yanıtları başarılı görünse de arka planda neler olup bittiğini anlamak için çok daha fazlasını izlemeniz gerekiyor.

İzlenmesi Gereken Dört Kritik Veri Boyutu

Tüm yapay zekâ sistemlerinde dikkat edilmesi gereken dört ana izleme boyutu vardır. Çoğu ekipse sadece bunlardan birini veya ikisini takip etmektedir:

• Kayıtlar (Logs): Gelen istek, yanıt, hata ve gecikme süreleri. Geleneksel uygulama performans izleme (APM) sistemlerinin zaten yaptığı temel izleme.

• İstemler (Prompts): Modele gönderilen ve modelden alınan gerçek metin içerikleri. Sistem istemleri, araç tanımlamaları ve geçmiş konuşmaları da içerir.

• Araç Çağrıları (Tool Calls): Modelin hangi aracı seçtiği, kullanılan argümanlar, dönen yanıtlar, çağrı sırası ve yeniden deneme sayısı.

• Maliyet (Cost): Giriş tokenları, çıkış tokenları, önbelleğe alınan tokenlar, akıl yürütme tokenları, kullanılan model ve milyon başına token fiyatı. Bu veriler kullanıcı, özellik ve istek bazında ayrıştırılmalıdır.

Bu dört boyuttan herhangi birini kaybetmek, AI sisteminizin farklı bir yönünü kör şekilde yönetmek anlamına gelir. Maliyet verisini kaybederseniz, finans departmanından gelen bir Slack mesajıyla uyanırsınız. Araç çağrılarını izlemezseniz, ajansınızın yanlış uçuşu rezervasyon yapmasını nedenini asla anlayamazsınız. İstem verilerini kaybederseniz, üretimdeki bir regresyonu tahmin oyununa dönüştürürsünüz. Basit kayıtları bile kaybederseniz, AI çağrısının gerçekleştiğinden bile haberdar olamazsınız.

İyi haber: 2026 yılında tüm bu dört boyutu yakalamanın standart bir yöntemi geliştirilmiştir. Kötü haberse, çoğu ekip hala kendi izleme sistemlerini elle oluşturmaya çalışmakta ve verilerin yarısını kaçırmaktadır.

Kayıtlar: Nelere Dikkat Etmeli ve "200 OK" Neden Yetersiz?

İzlemeye en temel düzeyden başlayalım. Her LLM çağrısı için en az aşağıdaki bilgileri içeren yapılandırılmış bir kayıt oluşturulmalıdır:

• Zaman damgası, istek kimliği ve üst izleme kimliği.

• Sağlayıcı (openai, anthropic, bedrock ya da kendi geçit hizmetiniz), model adı ve varsa model versiyonu.

• Uç nokta ya da işlem (chat.completions, responses, messages).

• Gecikme süresi — hem toplam süre hem de ilk token gelene kadar geçen süre (akışta gönderim yapılıyorsa).

• HTTP durum kodu, hata sınıfı ve hata içeriği.

• Bitiş nedeni (stop, length, tool_calls, content_filter).

Bu son madde aslında bir tuzak içermektedir: API'den gelen 200 OK yanıtı, modelin soruyu yanıtladığı anlamına gelmez. finish_reason değeri length ise yanıtın ortasında kesildiğini gösterir. content_filter değeri ise güvenlik sisteminin içeriği engellediğini belirtir. tool_calls değeri ise modelin sizden yardımcı araç çağırmasını istediğini ve konuşmanın henüz tamamlanmadığını ortaya koyar. Eğer izlemenizde tüm 200 OK yanıtlarını başarı olarak sayarsanız, aslında kesilen yanıtları ve reddedilen içerikleri de başarılı olarak değerlendiriyorsunuz demektir.

Akış (streaming) durumunda kayıt yapmak ise ayrı bir zorluk oluşturur. Akışta gönderilen bir yanıt HTTP 200 durumu dönebilir, ilk birkaç kelimeyi gönderebilir ve ardından bağlantı kopabilir. "Bu çağrı başarılı mıydı?" sorusunun yanıtı akışın sonunda verilmek zorundadır — başlıkta değil. Gönderilen ve alınan byte sayısıyla birlikte parça sayısını da kaydedin. Örneğin, 40 parça yerine yalnızca 3 parça alan bir yanıt, modelin erken öldüğünü ve ilk token gecikme süresinin kullanıcıya faydalı bir içerik sunmadığını gösterir.

İlk tokena kadar geçen süre, kullanıcıların algıladığı hızla doğrudan ilişkili olan gecikme metriğidir. Toplam süre faturalandırma ve kapasite planlaması için önemlidir, ancak ilk tokenı 600 milisaniyede alan ve son tokenı 8 saniyede veren bir sistem kullanıcıya hızlı hisseder. Buna karşın, ilk yanıtı 4 saniyede veremeyen bir sistem kullanıcı açısından yavaş algılanır — toplam süresi ne kadar kısa olursa olsun.

İstemler: Tüm Konuşmayı Kaydedin, Sonrasında Hassas Verileri Temizleyin

Bir üretim hatasıyla karşılaştığınızda öğreneceğiniz ilk kural: istemle ilgili bir sorun yaşandığında (yanlış yanıt, tuhaf tonlama, olmaması gereken bir reddetme) bunu özetlerden değil, birebir metinden çözümlemeniz gerekir. Modele gönderilen sistem istemi, tüm konuşma geçmişi, araç tanımları ve veri alma sonuçlarının hepsini kaydetmelisiniz.

Bu noktada çoğu yerel izleme sisteminin düştüğü hata, prompt.length === 4720 gibi basit bir istatistik kaydetmektir — çünkü gerçek metni depolamak gereksiz gibi görünür. Ardından bir kullanıcı asistandan basketbol hakkında yanıt alırken tenis sorduğunu iddia eder ve sizde elinizde yalnızca bir metin uzunluğu ve model adı vardır. Sorunun kaynağı, başka bir kullanıcının oturumundan kalan eski bir bellek parçasının sistem istemine sızmasıdır — bunu göremezsiniz, çünkü metni kaydetmemişsinizdir.

Tüm istemleri kaydedin. Disk alanı ucuz, zamanınız pahalıdır. Ancak iki önemli uyarı var:

Ağınızdan ayrılmadan önce hassas kişisel verileri (PII) temizleyin. İstemler yapılandırılmamış kullanıcı girdileridir. İsimler, e-postalar, adresler, kredi kartı numaraları, dahili hesap kimlikleri ve daha fazlasını içerebilir. Bu verileri üçüncü taraf bir izleme aracına gönderirseniz, bir hata ayıklama aracını GDPR sorumluluğu taşıyan bir riske dönüştürmüş olursunuz. OpenTelemetry GenAI çalışma grubu bu konuya özel önem vermiştir — hassas tokenleri kolektörünüzden ayrılmadan önce temizleyen bir PII-redaction işlemcisi kavramını ortaya koymuştur. Datadog'un LLM Gözlemlenebilirliği aracıysa varsayılan olarak e-posta ve IP adreslerini tarayan hassas veri tarayıcılarıyla birlikte gelir. Ya kendi redaksiyon adımınızı geliştirin ya da bunu zaten yapmış bir satıcı seçin. İşlenmemiş istemleri körü körüne göndermeyin.

Sistem istemlerini versiyonlayın. Sistem istemini değiştirdiğinizde programı değiştirmiş olursunuz. Bunu bir git ile izlenen öğe gibi düşünün, bir versiyon atayın ve her isteği üreten versiyonla damgalayın. Yeni bir sistem istemini A/B testi yaptığınızda ve bir varyantta performans düşüşü yaşadığınızda, metriklerinizi prompt.version ile dilimleyebilmek istiyorsunuz — tıpkı deploy.sha ile yaptığığınız gibi.

Kayıt altına alınacak mantıklı bir sistem istemi yapısı aşağıdaki gibidir:

{
  "system_prompt": "Versiyon 2.1: Kullanıcıya kibarca yanıt ver, teknik detayları sadeleştir.",
  "messages": [
    {"role": "user", "content": "Python'daki async fonksiyonları nasıl kullanırım?"},
    {"role": "assistant", "content": "Async fonksiyonlar 'async def' ile tanımlanır..."