Kullanım ve Gecikme Raporu

Her çağrı arka planda dört adımdan geçer — ses tanıma, yapay zeka, ses üretimi, telefon hattı — ve her adımın ayrı bir gecikmesi vardır. Bu rapor hesabından düşen dakikaları ve o dört adımın gecikmesini birlikte gösterir: ne kadar konuşuldu, hangi adım aramayı yavaşlattı. Haziran 2026’da yapılan bir optimizasyon turunda bu ölçümler sayesinde yapay zeka cevap süresi (p95) 3,80 saniyeden 975 ms’ye indi — yaklaşık 4 kat. Ölçmediğin gecikmeyi iyileştiremezsin; bu rapor tam olarak onu ölçer.

Neden hem kullanım hem gecikme aynı raporda?

Çünkü ikisi aynı deneyimin iki yüzü. Gecikme büyüdükçe görüşmeler uzar, uzayan görüşme daha çok dakika harcar; dakikan nereye gittiğini anlamak için önce nerede beklendiğini görmen gerekir.

Bir çağrı arka planda şu hattı izler:

Karşı taraf konuşur
        ↓
STT: sesi yazıya çevirir                       ⏱ latency.stt
        ↓
LLM: cevabı üretir                             ⏱ latency.llm_ttft
        ↓
TTS: yazıyı sese çevirir                       ⏱ latency.tts
        ↓
SIP: sesi telefon hattına taşır
        ↓
Karşı taraf duyar

STT (Speech-to-Text) = ses tanıma, LLM (Large Language Model) = cevabı kuran yapay zeka, TTS (Text-to-Speech) = metni sese çeviren motor, SIP = çağrının telefon şebekesine çıktığı hat. Dört adım, art arda çalışır.

Gecikme neden bu kadar önemli?

İnsan konuşmasında doğal bir tempo vardır — biri konuşmayı bitirdiğinde diğeri yarım saniye içinde tepki verir. Yapay zeka asistanı bu pencereyi kaçırırsa “düşünüyor” hissi verir; 800 ms’yi aşarsa çoğu kişi “hattı mı kaybettik” diye tekrar konuşmaya başlar — üstüne konuşma (barge-in), asistanın cevabını yarıda kesme ve genel bir kopukluk hissi doğar. Panelin çağrı detayında gecikme kutucukları bu yüzden renk kodludur:

Bu eşikler STT, LLM ve TTS’in her biri için ayrı ayrı geçerlidir — üçü art arda geldiği için toplam gecikme bu üçünün toplamına yakındır.

p50 / p95 / p99 ne anlama gelir?

Ortalama (avg) tek başına yanıltıcıdır — birkaç çok hızlı çağrı, birkaç çok yavaş çağrıyı gizleyebilir. Bu yüzden rapor yüzdelik dilim (percentile) kullanır:

Bir müşteri asistanı “yavaş” olarak hatırlıyorsa genelde ortalamayı değil, en kötü aramasını (p95/p99 bölgesi) hatırlıyordur. Optimizasyon yaparken önce p95’e bak.

Gerçek bir örnek: Purvisor’ın kendi altyapısında yapılan bir tur sonunda ölçülen değerler — LLM p95 3,80 saniyeden 975 ms’ye (gpt-4o-mini, önbelleğe uygun sabit prompt + son 12 mesaja kırpılmış geçmiş), STT p50 ~150 ms (Deepgram, AB bölgesi sunucusu), TTS ~175 ms (ElevenLabs Turbo v2.5). Sonuç: tur başına toplam gecikme p50 ~1,1 saniye / p95 ~1,45 saniye — sesli bir asistan için doğal sayılan bölge. Bu rakamlar o ana özgü bir ölçümdür, kullandığın modele/sağlayıcıya göre kendi hesabında farklı çıkar; önemli olan yöntem: p95’i düzenli izlemek.

Kullanım nereden geliyor?

Hesabından düşen tek birim dakikadır. Rapordaki dakikalar çağrı süresinden yeniden hesaplanmaz; dakika defterinden (usage hareketleri) okunur — yani panelde gördüğün sayı, bakiyenden fiilen düşen sayının aynısıdır. Hangi sağlayıcının kullanıldığı, kaç token harcandığı gibi ayrıntılar faturalandırmanı etkilemez; Purvisor arka planda sağlayıcı değiştirse bile senin tarafında değişen bir şey olmaz.

Rapordaki alanlar

Seçtiğin dönem (varsayılan 7 gün, istersen daha uzun bir aralık) için panel şu alanları gösterir:

{
  "period": { "days": 7, "since": "2026-07-06T00:00:00.000Z" },
  "minutes": {
    "total": 412,
    "callCount": 200,
    "avgPerCall": 2.06,
    "daily": { "2026-07-12": 63, "2026-07-11": 71 },
    "today": 18
  },
  "latency": {
    "aggregated": {
      "stt": { "p50": 150, "p95": 240, "p99": 310, "avg": 162, "sampleCount": 180 },
      "llm_ttft": { "p50": 975, "p95": 1420, "p99": 1900, "avg": 1050, "sampleCount": 180 },
      "tts": { "p50": 175, "p95": 260, "p99": 340, "avg": 190, "sampleCount": 180 }
    },
    "realtime": { "stt": 150, "llm_ttft": 980, "tts": 178 }
  }
}

(Sayılar gösterim amaçlıdır; kendi hesabında farklı çıkar.)

📸 [Ekran görüntüsü: Raporlar → Kullanım ve Gecikme sayfası — dönem seçici, gecikme p50/p95 kutucukları, günlük seri grafiği]

Tek bir çağrıda gecikme dağılımı

Herhangi bir çağrının detayını açtığında, o çağrıya ait gecikme kutucukları adım adım görünür: ses tanıma, yapay zeka cevabı ve ses üretimi ayrı ayrı ölçülür.

📸 [Ekran görüntüsü: Çağrı detayı — adım adım gecikme kutucukları]

İyi uygulamalar

• Ortalamaya değil p95’e bak. Ortalama iyi görünse de p95 yüksekse, müşterilerinin bir kısmı gerçekten yavaş bir deneyim yaşıyordur.
• Dakika tüketimi artıyorsa görüşme uzunluğuna bak. Uzun prompt’lar ve gereksiz uzun asistan cevapları görüşmeyi uzatır. (Bkz. Prompt Yazma Rehberi)
• Kısa dönemleri (7 gün) düzenli kontrol et — ani bir kullanım veya gecikme sıçramasını haftalar sonra değil, gün içinde yakala.
• Ani p95 sıçraması genelde bir sağlayıcı kaynaklıdır (Deepgram/LLM/TTS tarafında geçici yavaşlama) — coincide eden bir kesinti olup olmadığını kontrol et.

Sorun giderme

İlgili