Geliştirme

Müşteri desteğinde yapay zekâ: nerede yardım eder, nerede engel olur

Dil modeli yanıldığında bile kendinden emin yanıt verir. Destekte yapay zekânın nerede faydalı olduğunu, önceden neyin hazırlanması gerektiğini ve ona neyin emanet edilmemesi gerektiğini ele alıyoruz.

Desteği bir dil modeliyle değiştirme fikri bariz görünür: sorular tekrarlanır, yanıtlar belgelerde vardır, model tutarlı konuşabilir. Pratikte gerçekten fayda vardır ama arandığı yerde tam olarak durmaz ve asıl risk bir demoda görünmeyecek şekilde kuruludur. Aşağıda yakından nasıl göründüğünü anlatıyoruz.

İki kullanım biçimi ve eşit değiller

İlk hat olarak yapay zekâ. Model müşteriye doğrudan yanıt verir. Hızlı, günün her saati, aynı türden soruların akışını karşılar. Tüm risk de buradadır: her yanıt dışarı çıkar ve kimse kontrol etmemiştir.

Operatöre öneri olarak yapay zekâ. Model talebi okur, bilgi tabanında uygun parçaları bulur, yanıt taslağı önerir. Operatör düzeltir ve gönderir. Zaman tasarrufu ilk seçenekten azdır ama hata şirketin dışına çıkmaz.

İkinci seçenek neredeyse her zaman önce başlatılmalıdır. Aynı temeli — bilgi tabanı, onda arama, talep sistemiyle entegrasyon — sağlarken istatistik de toplar: taslak ne sıklıkla düzeltmesiz kullanılabiliyor, model nerede yanılıyor, hangi verileri eksik. Birkaç aylık böyle bir çalışmadan sonra hangi konuların özerk moda devredilebileceği, hangilerinin devredilemeyeceği görülür. Doğrudan müşterilere başlatmak sizi bu bilgiden tam da en çok ihtiyaç duyduğunuz anda mahrum eder.

Asıl risk: kendinden emin ve yanlış

Dil modeli makul görünen metin üretir. Makullük ile doğruluk sık sık örtüşür ama her zaman değil ve yanıtın biçiminden ikisini ayırt etmek imkânsızdır: yanlış yanıt doğrusuyla tamamen aynı görünür — aynı sakinlikte ve aynı tonda.

Destek için bu somut şeyler anlamına gelir:

  • Model sizde olmayan bir koşulu söyleyebilir: iade süresi, teslimat seçeneği, ürün yeteneği.
  • İki doğru parçadan yanıt kurup yanlış bir sonuca varabilir — yakalaması en zor hata budur.
  • Müşteri kendinden emin iddia ederse onun yanlış ifadesine seve seve katılır.
  • Söylenmedikçe dün sizde tam olarak neyin değiştiğini bilmez.

Müşteri, botun verdiği sözü şirketin sözü olarak algılar. Buna itiraz etmek anlamsızdır ve insani olarak haklıdır.

Pratik çıkarım: riski modeli daha dikkatli olmaya ikna ederek değil, sistemin yapısıyla azaltmak gerekir. Yanıt yalnızca bilgi tabanınızda bulunan parçalar üzerine kurulur; uygun bir şey bulunmazsa yanıt yoktur, insana aktarım vardır. Serbest diyalogdan belirgin şekilde daha sıkıcı ve belirgin şekilde daha güvenlidir.

Lansmandan önce neyin hazırlanması gerekir

Yanıt kalitesi model seçimiyle değil, modelin neyden yanıt verdiğiyle belirlenir. Bilgi tabanının hazırlanması projenin asıl işidir ve müşteri genellikle bunu hafife alır.

  1. Kaynakları toplayın. Yönetmelikler, geçmiş dönemin destek yanıtları, ürün açıklamaları, koşullar, talimatlar. Bir zamanlar yazılmış olanlar değil, gerçekten kullanılan her şey.
  2. Çelişkileri temizleyin. İki belgede farklı iade koşulları varsa model birini seçer ve doğrusu olmayabilir. Çelişkiler sonra değil önce giderilmelidir.
  3. Bağımsız parçalara bölün. Bir parça belgenin geri kalanı olmadan anlaşılabilmelidir. "Yukarıdaki bölüme bakın" gibi atıflar parçalar üzerinden aramada çalışmaz.
  4. Sahip atayın. Bilgi tabanının her bölümünün değişikliklerde onu güncelleyen bir sorumlusu vardır. Sahipsiz bilgi tabanı birkaç ayda eskir ve zarar vermeye başlar.
  5. Kamuya açık olanı iç bilgiden ayırın. İç yorumlar, alış fiyatları, VIP müşteriler için istisna talimatları müşteriye verilen yanıtın oluşturulduğu sete girmemelidir.
  6. Canlı verileri ayrıca bağlayın. Sipariş durumu, hesap bakiyesi, randevu tarihi bilgi tabanı değil, sisteme bir sorgudur. Model bunları tahmin etmemeli, bir fonksiyon çağırıp sonucu aktarmalıdır.

Altıncı madde genellikle faydayı belirler. Yalnızca metinleri bilen yapay zekâ genel soruları yanıtlar. Belirli bir siparişe bakabilen yapay zekâ gerçek talepleri kapatır.

İnsana aktarım zorunlu bir parçadır

Bu bir acil çıkış değil, senaryonun olağan bir öğesidir. Önceden ve kurallarla tasarlanır.

Diyalog bir insana aktarılmalıdır:

  • bilgi tabanında uygun bir parça olmadığında;
  • müşteri istediğinde — ilk seferde, tutma girişimi olmadan;
  • konu para olduğunda: iade, yeniden hesaplama, tazminat, ödeme anlaşmazlığı;
  • mesajda belirgin bir rahatsızlık veya şikâyet anıldığında;
  • soru sağlık, hukuk, güvenlikle ilgili olduğunda;
  • müşteri üçüncü kez sorduğunda — yani yanıtlar yardım etmediyse.

Aktarımda operatör "müşteri bekliyor" bildirimini değil, diyaloğun tamamını almalıdır. Hikâyeyi baştan anlatmak zorunda kalmak, botun kendisinden daha çok sinir bozar.

Mesai dışı hakkında ayrıca. Şu anda operatör yoksa, bunu söyleyip talebi net bir yanıt süresiyle kaydetmek, kişiyi otomatik ifadelerin döngüsünde dolaştırmaktan daha dürüsttür.

Modele neler emanet edilmemeli

Teknik olarak mümkün olsa bile otomasyona bırakılmayan kararlar vardır.

  • Finansal işlemler. İadeler, indirimler, tahsilatlar, paket değişikliği. Model talebi hazırlayabilir, kararı insan verir.
  • Hukuki önemi olan ifadeler. Sözleşme, garanti yükümlülükleri, kişisel veriler hakkındaki yanıtlar. Burada yeniden anlatım değil, onaylanmış hazır bir metin gerekir.
  • Tıbbi ve hukuki öneriler. Yanıt bir tavsiye değil, uzmana giden bir yol olmalıdır.
  • Bireysel istisnalar. "Sizin için bir istisna yapalım" bir yönetim kararıdır.
  • Kimlik doğrulamadan kişisel verilerle işlem. Bir sipariş hakkında herhangi bir şey söylemeden önce sistem, sahibiyle konuştuğunu bilmelidir. Bu ayrı bir mekanizmadır, sohbetteki isme dayalı bir tahmin değil.

Talep verilerinin nereye gittiği sorusu da buraya girer. Dış bir servis kullanılıyorsa tam olarak neyin dışarı gönderildiğini anlamak ve gereksiz bilgileri yazışmadan önceden temizlemek gerekir. İlgili konu güvenlik bölümünde ele alınıyor.

İşe yarayıp yaramadığı nasıl ölçülür

"Daha iyi oldu" hissi güvenilir değildir. Her biri ilk günden toplanabilecek net işaretlere bakmak gerekir:

  • operatör katılımı olmadan kapatılan taleplerin payı — ama yalnızca bir sonraki maddeyle birlikte;
  • otomatik yanıttan sonra aynı konuda yeniden başvuranların payı: artıyorsa bot çözmüyor, erteliyor demektir;
  • operatörün kaç taslağı düzeltmeden gönderdiği ve kaçını tamamen yeniden yazdığı;
  • insana aktarımın en sık gerçekleştiği konular — bilgi tabanının hangi bölümünün tamamlanması gerektiğine dair ipucu;
  • ayrı bir liste olarak — botun yanlış yanıt verdiği durumlar. Bunlar yüzde olarak sayılmamalı, tek tek incelenmelidir.

Son madde diğerlerinden önemlidir. İade koşulları hakkında tek bir yanlış yanıt, operatörün tasarruf ettiği yüz dakikadan daha pahalıya mal olur.

Pratik uygulama sırası

  1. Müşterilere özerk yanıtlarla değil, operatöre öneriyle başlayın.
  2. Bilgi tabanını toplayın ve temizleyin. İşin asıl kısmı budur; buna yalnızca geliştiricilerin değil şirket içinden kişilerin zamanını ayırın.
  3. Yanıtları kesinlikle bulunan parçalara göre ayarlayın; kaynak yoksa yanıt vermeyi reddetsin.
  4. Canlı verileri yeniden anlatımla değil, sistemlerinize yapılan çağrılarla bağlayın.
  5. Operatöre aktarım kurallarını tarif edin ve diyaloğun bütünüyle aktarıldığını kontrol edin.
  6. Otomatik yanıt için yasaklı konuların listesini hazırlayın ve gerçek taleplerde test edin.
  7. Birkaç haftalık çalışmadan sonra yalnızca taslakların düzeltmesiz gittiği konuları özerk moda geçirin.

Bu sıra "bir haftada modeli sohbete bağlamak"tan yavaştır ama sonradan yerine getirmek zorunda kalacağınız taahhütler yaratmaz. Durumunuzu somut olarak ele almak isterseniz — bize yazın.