Devrin ne zaman olacağını önceden tanımla

Kullanıcı bankasının uygulamasındaki asistana yazıyor: kartından tanımadığı bir ödeme çekilmiş. Asistan hesap hareketlerine nasıl bakılacağını anlatıyor. Kullanıcı baktığını, işyerini tanımadığını, kartın kapatılması gerektiğini yazıyor. Asistan aynı adımları biraz farklı sözlerle tekrarlıyor. Üçüncü mesajda kullanıcı biriyle konuşmak istediğini yazıyor, ünlem işaretiyle. Asistan çok üzgün olduğunu söylüyor ve başka nasıl yardımcı olabileceğini soruyor.

Bu konuşmada üç ayrı işaret vardı. Konu riskliydi, kullanıcı aynı isteği tekrarladı ve öfkesini açıkça söyledi. Hiçbiri devri başlatmadı, çünkü devrin hangi koşulda olacağını kimse yazmamıştı. Karar her mesajda modele kalıyordu ve model her mesajda yanıt vermeyi seçti.

Zarar zamanla büyüyor. Tanımadığı ödemeyi bildiren kullanıcı için geçen her dakika yeni bir çekim riski taşıyor. Döngüden çıkamayan kullanıcı telefona sarılıyor ve temsilcinin karşısına hem öfkeli hem de beklemiş olarak çıkıyor. Bazıları vazgeçip pencereyi kapatıyor ve o konuşma panoda kapanmış bir konuşma olarak duruyor.

Devrin koşulu yazılmamışsa her konuşma modelin o anki yargısına kalır.

AI'ın başarısı çözdüğü konuşmalarla ölçülür ve her devir bu sayıdan düşer. Ekipler devri sıkı tutmak ister ve bunun haklı bir nedeni var. Intercom'un kendi belgesi geniş devir yönergelerinin devirleri keskin biçimde artırdığını¹ ve Fin'in çözebileceği durumlarda bile müşterilerin çoğunun devir teklifini kabul ettiğini yazıyor. Ama devri sıkı tutmanın yolu koşulu hiç yazmamak olunca risk ve öfke de AI'ın içinde kalır.

Model her mesajı ayrı bir yardım fırsatı olarak yanıtlar ve konuşmanın gidişatını saymaz. Aynı soruya aynı yanıtı vermeyi sürdürür, özrünü yeniler. Öfkeyi fark etse de “yardımcı ol” talimatı onu konuşmada tutar. Sistem promptuna “gerekirse insana aktar” yazmak devir kararını yine aynı modele bırakır, kural yalnız modelin o anki yorumu kadar çalışır.

Üçüncü neden ölçümde. Devredilmeyen ama çözülmeyen konuşma panoda AI'ın kapattığı bir konuşma gibi görünür. Kullanıcı vazgeçip telefonla aradığında o çağrı başka bir sistemde, başka bir sayıya yazılır. Döngünün bedeli AI'ın panosuna hiç uğramaz.

Devrin koşulları ürün kurulurken yazılır, yanıt akışında çalışır ve her devir hangi koşuldan doğduğunu kaydeder.

1. Koşulları adıyla yaz. Beş aile çoğu ürüne yeter: insanın açık isteği, öfke, tekrar, riskli konu ve değer eşiği (yüksek tutar, öncelikli müşteri). Her koşulun bir adı, bir sahibi, bir ölçütü ve bir hedef ekibi olur.
2. Riskli konuda yanıt üretme. Dolandırıcılık, hesap güvenliği, sağlık, hukuki talep ve kişisel veri gibi konular eşleşince AI kendi yanıtını yazmaz, konuşmayı doğru ekibe aktarır. Beklerken güvenli olan tek adımı söyleyebilir, kartı geçici olarak kapatmak gibi.
3. Tekrarı kod saysın. Aynı isteği üçüncü kez yazan, aynı yanıtı ikinci kez alan ya da art arda anlaşılmayan kullanıcı döngüdedir. Sayacı kod tutar ve eşik aşılınca devir başlar.
4. Öfkede bir kez dene, ikincide devret. Öfke her zaman hemen devir istemez, AI bir kez sorunu çözmeyi deneyebilir. İkinci işarette devri teklif etmez, yapar. Aynı devir teklifini art arda sunmak da bir döngüdür.
5. Kuralı akışta çalıştır, devri kaydet. Koşullar model yanıt üretmeden önce, yanıt akışında denetlenir. Her devir koşulun adıyla kaydedilir. Fazla geniş ya da hiç tetiklenmeyen koşul böylece görünür olur.

Riskli konuyu yazan kullanıcı ilk mesajda doğru ekibe ulaşır. Döngüye giren kullanıcı üçüncü mesajda döngüden çıkar.

Aynı ödeme itirazı, iki ayrı asistanla. Soldaki riskli konuyu, tekrarı ve öfkeyi görmeden aynı adımları anlatıyor ve özür diliyor. Sağdakinde tanınmayan harcama önceden yazılmış bir devir koşulu. Koşul eşleşiyor, AI kendi yanıtını üretmiyor ve konuşmayı kart güvenliği ekibine aktarıyor.

Intercom'un Fin'i varsayılan olarak müşteri açıkça insan istediğinde, güçlü bir öfke algıladığında ve müşteri tekrar eden bir döngüye girdiğinde¹ devrediyor. Müşteri üç tur boyunca kendini tekrarladığında Fin devri teklif ediyor. Teklifi art arda iki kez sunmuyor, ikinci kez tetiklenirse doğrudan devrediyor. Ekip bunların üstüne veri tabanlı kurallar ekleyebiliyor: duygu durumu olumsuz, konu hata bildirimi, sipariş tutarı bir eşiğin üstünde ya da müşteri öncelikli. Kural eşleşince Fin soruya yanıt üretmiyor, konuşmayı ekibe aktarıyor.

Microsoft Copilot Studio'da varsayılan geri dönüş konusu, ajan kullanıcının niyetini anlayamadığında kullanıcıdan yeniden ifade etmesini istiyor. İki denemeden sonra² konuşmayı Escalate adlı sistem konusuyla bir temsilciye aktarıyor. Kullanıcı konuşmanın ortasında “talk to agent” yazdığında da ajan onu aynı konuya yönlendiriyor. İnsan gerektiren konular için ekip devir düğümünü konunun kendisine³ ekliyor.

Google'ın Dialogflow CX'inde anlaşılmayan girdi için numaralı olaylar var. Ekip sys.no-match-1, sys.no-match-2 gibi işleyiciler tanımlarsa Dialogflow bunları varsayılan işleyicinin yerine sırayla çağırıyor⁴. Devir işareti bir sayfanın giriş adımına ya da sorunun yalnız bir insanla çözülebileceğine karar veren bir webhook yanıtına⁵ konabiliyor. Tekrar sayacı ve devir böylece akışın kendisinde duruyor.

Bu deseni ölçen bağımsız bir araştırma ya da onu doğrudan gösteren bir olay bulamadık. Kanıt satıcı belgelerinde ve belgeler aynı koşullarda buluşuyor: açık istek, öfke, tekrar ve insan gerektiren konu. Tekrarın eşiği de birbirine yakın. Intercom üç turluk tekrarda devri teklif ediyor, Copilot Studio iki yeniden sorma denemesinden sonra devrediyor.

Koşul yazılmadığında ne olduğunu ABD Tüketici Finansal Koruma Bürosu'nun (CFPB) 2023 raporu anlatıyor. Rapora göre sohbet botları müşteriyi tekrar eden, işe yaramaz yanıtlardan oluşan ve insana çıkışı olmayan döngülere sokabiliyor. Büro müşterilerin bu “doom loops” içinde sıkıştığına dair şikâyetler aldığını⁶ yazıyor ve bu döngülerin çoğunlukla müşterinin sorunu botun sınırlı yeteneklerinin dışına düştüğünde oluştuğunu söylüyor. Önceden yazılmış bir devir koşulu tam bu anı yakalar.

Belgeler ürünlerin neyi yapabildiğini söyler, koşulların hangi eşikte doğru çalıştığını söylemez. CFPB'nin örnekleri de şikâyetlerden derlendi ve sıklık ölçmüyor. Eşiği kendi konuşmalarında ölçmen gerekiyor.

• Döngüde kalan konuşma. Aynı isteğin üç kez yazıldığı ya da AI'ın aynı yanıtı iki kez verdiği konuşmaları say. Bunların devirle bitmeyen payı sıfıra yakın olmalı.
• Nedensiz devir. Her devrin kaydında hangi koşuldan doğduğu yazmalı. Koşul alanı boş devir sıfır olmalı.
• Riskli konuda AI yanıtı. Riskli konu koşuluna uyan ama AI'ın kendisinin yanıtladığı konuşmalar. Hedef sıfır.
• Gereksiz devir. Temsilcinin bilgi tabanındaki hazır bir yanıtla kapattığı devirler. Bir koşulda bu pay yüksekse o koşul fazla geniş.
• Vazgeçen kullanıcı. Devir olmadan ve çözülmeden kapanan konuşmalardan sonra aynı kişinin başka bir kanaldan aynı konuyla gelmesi.

Üç metin var. Denetim promptu ürünündeki asistanın devir kararını nerede ve nasıl verdiğini tarar. Koşulların yazılı olup olmadığını, kodda mı promptta mı durduğunu, tekrarın ve riskli konunun yakalanıp yakalanmadığını raporlar, hiçbir dosyayı değiştirmez. Uygulama promptu deseni koda geçirir. Önce planı gösterir, onayınla devir koşullarını yanıt akışına koyar, tekrar sayacını kurar ve her koşulu sınayan testler ekler. Kural kodlama ajanının kendi çalışması için: bir asistan yazarken devri modelin takdirine bırakmasın.

Bu depoda kullanıcıyla konuşan bir AI asistanı var: destek sohbeti, sesli asistan ya da uygulama içi yardımcı. Görevin, konuşmanın hangi koşulda bir insana devredileceğinin önceden tanımlanıp tanımlanmadığını denetlemek. Hiçbir dosyayı değiştirme, yalnız rapor yaz.

1. Devrin başladığı yerleri bul: devir aracı ya da fonksiyonu, "insana aktar" niyeti, kuyruk ya da bilet oluşturan çağrı. Her birinin hangi koşulda tetiklendiğini çıkar.
2. Koşullar nerede duruyor? Kodda (kural, sayaç, sınıflandırıcı) mı, yoksa yalnız sistem promptunda "gerekirse insana aktar" gibi bir cümle olarak mı?
3. Şu beş koşul ailesinin her biri için ayrı bak ve var mı, yok mu, nerede, yaz: (a) kullanıcının açık insan isteği ("temsilci", "insanla konuşmak istiyorum"), (b) öfke ya da hayal kırıklığı, (c) tekrar (aynı isteğin tekrar yazılması, AI'ın aynı yanıtı tekrar vermesi, art arda anlaşılmayan girdi), (d) riskli konu (dolandırıcılık, hesap güvenliği, sağlık, hukuki talep, kişisel veri), (e) değer ya da müşteri eşiği (yüksek tutar, öncelikli müşteri).
4. Tekrar sayılıyor mu? Sayacı kod mu tutuyor, model mi? Eşik kaç ve eşik aşılınca ne oluyor?
5. Riskli konu eşleştiğinde AI yine de kendi yanıtını üretiyor mu, yoksa yanıt üretmeden devrediyor mu?
6. Devir teklif edilip kullanıcı reddederse ne oluyor? Aynı teklif art arda tekrar ediliyor mu?
7. Her devir hangi koşuldan doğduğuyla kaydediliyor mu? Mesai dışında ya da insan ekibi yokken koşul eşleşirse ne oluyor?
8. Bu koşulları sınayan testler var mı?

Rapor biçimi: her koşul ailesi için durum (kodda, yalnız promptta, yok), ilgili dosya ve satır, kullanıcının döngüde kalabileceği bir senaryo (örnek: tanınmayan harcamayı bildiren kullanıcı üç mesaj boyunca aynı yanıtı alır) ve önerdiğin düzeltme. Riskli konu ve tekrar koşullarından başla.

Bu depodaki AI asistanına "devrin ne zaman olacağını önceden tanımla" desenini uygula. Önce planı göster, onayımı aldıktan sonra kodu değiştir.

Hedef davranış:
1. Devir koşulları kodda, adı ve açıklamasıyla tek bir listede tanımlı: açık insan isteği, öfke, tekrar, riskli konu, değer ya da müşteri eşiği. Her koşulun sahibi ve hedef ekibi belli.
2. Koşullar her kullanıcı mesajında, model yanıt üretmeden önce yanıt akışında denetlenir.
3. Riskli konu ya da değer eşiği eşleşince model kendi yanıtını üretmez. Asistan devri bildirir ve varsa beklerken güvenli olan tek adımı söyler.
4. Tekrarı kod sayar: aynı isteğin üçüncü kez yazılması, asistanın aynı yanıtı ikinci kez vermesi ya da art arda anlaşılmayan girdi. Eşik aşılınca devir başlar.
5. Öfke işaretinde asistan bir kez çözmeyi deneyebilir. İkinci işarette devri teklif etmez, yapar. Aynı devir teklifi art arda iki kez sunulmaz.
6. Her devir hangi koşuldan doğduğuyla kaydedilir.
7. İnsan ekibi yokken ya da mesai dışında koşul eşleşirse asistan bunu açıkça söyler ve bir yol verir (bilet, geri arama, acil durum hattı).

Uygularken:
- Önce mevcut devir yollarını ve koşulları çıkar, hangisinin yalnız promptta durduğunu göster.
- Koşul listesini yapılandırılabilir tut, ama kodda çalıştır. Promptta koşulların kopyası durmasın.
- Öfke sınıflandırıcısını tek başına ölçüt yapma, tekrar sayacıyla birlikte kullan.
- Testler ekle: (a) aynı isteği üç kez yazan kullanıcının devredildiğini doğrula. (b) "kartımdan tanımadığım bir ödeme çekildi" mesajında modelin yanıt üretmediğini ve devrin başladığını doğrula. (c) "temsilciyle konuşmak istiyorum" mesajında devrin tek adımda başladığını doğrula. (d) her devir kaydında koşul adının dolu olduğunu doğrula. (e) insan ekibi yokken koşul eşleşince asistanın bunu söylediğini doğrula.

## Devrin ne zaman olacağını önceden tanımla
- Kullanıcıyla konuşan bir asistan yazarken devir koşullarını kodda, adıyla tanımla: açık insan isteği, öfke, tekrar, riskli konu, değer eşiği.
- Devir kararını yalnız sistem promptuna "gerekirse insana aktar" diye yazıp bırakma.
- Tekrar sayacını kodda tut, modelin saymasına güvenme.
- Riskli konu eşleşince modelin kendi yanıtını üretmesine izin verme.
- Her devri koşul adıyla kaydet ve her koşul için bir test ekle.

Koşul listesi büyüdükçe AI'a iş kalmaz. Intercom'un uyarısı açık: devir yönergesi genişledikçe devirler keskin biçimde artıyor¹ ve çözüm oranı düşüyor. Koşulları en dar hâliyle yaz ve kayıttan hangisinin gereksiz devir ürettiğine bak.

Devredecek kimse yoksa devir koşulu boş bir söz olur. Intercom'da hiçbir insan hedefi tanımlanmamışsa Fin devri hiç teklif etmiyor¹. Mesai dışında, kuyruk doluyken ya da insan ekibi olmayan bir üründe koşul eşleştiğinde ne olacağını da yaz: bilet açmak, geri arama zamanı vermek, acil durumlar için bir telefon numarası.

Öfke algısı yanılır. İroni, argo ve kısa cümleler duygu sınıflandırıcısını şaşırtır. Öfkeyi tek başına ölçüt yapma, tekrar sayacı gibi davranış işaretleriyle birlikte kullan.

Desen insana giden yolun açık olmasını ve devrin bağlamıyla yapılmasını çözmez. Koşul eşleştikten sonra olanlar ayrı desenlerin işi.