Chatbot Geliştirmek Hakkında Keşke Baştan Bilmiş Olsaydım Dediğim Şeyler

Erik bir chatbot geliştirme ajansı işletiyor. Özellikle müşteri hizmetleri ve pazarlama alanında büyük şirketlere chatbot çözümleri sağlıyorlar.

Erik bana bir yandan işlerin çok iyi gittiğini çünkü sohbet robotları için yapılan tekliflerin dönüşüm oranının son derece yüksek olduğunu söyledi. Bu belki de kendisinin bu alanda pazara ilk girenlerden biri olduğu gerçeğini yansıtıyor.

Aynı zamanda, kaliteli sohbet robotlarını verimli bir şekilde oluşturmak için doğru araçları bulmakta zorlanıyordu.

Chatfuel ve Motion.ai gibi kodsuz platformları ilk keşfettiğinde, bu araçların sorununu çözeceği konusunda iyimserdi. Botların prototipini oluşturmak için iyi çalıştıklarını fark etse de kısa sürede sorunlarla karşılaştı.

Birçok botun yalnızca kodla temsil edilebilecek şekilde özelleştirilmesi gerekiyordu ve bu platformlar kodlamayı desteklemiyordu. Bazı botların müşterinin eski sistemleriyle entegre edilmesi gerekiyordu ve bu da yine mümkün değildi.

Sadece bu sorunlar bile anlaşmayı bozuyordu, ancak çözülebilseler bile, tüm mantık ve verilerin üzerinde hiçbir kontrolü olmayan üçüncü taraf bir sistemde bulunmasından yine de rahatsız oluyordu. Müşterileri genellikle güvenlik nedenleriyle botu kendilerinin barındırması konusunda ısrar ediyordu.

Bu nedenle botları Microsoft Bot Framework kullanarak sıfırdan kodlatmaya ve mümkün olan yerlerde düşük maliyetli ülkelerdeki geliştiricileri kullanmaya karar verdi. Bu öngörülebilirliği yapmak başka sorunlar yarattı.

Artık kodun ve verilerin sahibi olmasına ve botu istediği ölçüde özelleştirebilmesine rağmen sonuçlar karışıktı.

Kısa sürede tüm botların rol tabanlı güvenlik, abonelikler, yayın yapma, döngüdeki insan gibi birçok ortak özelliğe sahip olduğunu fark etti, ancak bu özellikler geliştiriciler tarafından sıfırdan kodlanıyordu, bu da geliştirme süresini gereksiz yere artırıyor ve kar marjlarını azaltıyordu.

Geliştirme riskleri de gereksiz yere yüksekti çünkü farklı geliştiriciler özellikleri farklı şekillerde kodluyor ve genel mimari geçici bir şekilde gelişiyordu. Bazı geliştiriciler bu sorunun farkına varmış ve ortak özellikler için yeniden kullanılabilir kütüphaneler oluşturmaya başlamıştı, ancak bu kütüphaneler onun işini üzerine inşa etmek isteyeceği yüksek kaliteli kütüphaneler değildi. Özellikle ihtiyaç duyulan işlevsellik karmaşık olduğunda, kendi risklerini ve istenmeyen bağımlılıklarını ortaya koyuyorlardı. Müşterilerine inşa edilen her şeyin yeterince yüksek standartta olduğuna dair güven vermek bir yana, kaliteyi doğrulamak bile onun için zordu.

Kısa bir süre kendi platformunu oluşturma fikrini düşündü ancak bu aşırıya kaçmak gibi görünüyordu. Bunu yapmak gereksiz geliştirme ve bakım maliyetlerinin yanı sıra müşterilerin tercih edeceği piyasa standardı çerçeveler ortaya çıkarsa potansiyel satış sorunları yaratacaktı, ki bunun olacağına inanıyordu. Bu sadece bir zaman meselesiydi.

Ona göre bu sorun, internetin doğuşunda web geliştiricilerinin karşılaştığı soruna benziyordu. O zamanlar Wordpress gibi içerik yönetim araçları yoktu, bu nedenle web sitelerinin her seferinde sıfırdan kodlanması gerekiyordu. Bu da geliştirme maliyetlerinin artması, kod ve çıktı kalitesinin değişken olması gibi şu anda botları oluştururken karşılaştığı sorunlarla aynı sorunları yaratıyordu.

Erik Botpress.io adresini internette bulduğunda, Botpress adresinin sorunlarına potansiyel bir çözüm sunduğunu fark etmesi uzun sürmedi. Teoride modüler mimariyi sevdi ve botlar için bir CMS eşdeğeri oluşturmak ona mantıklı geldi. İhtiyaç olduğuna inandığı şey buydu. Bulmacadaki eksik parça bu olabilirdi ama önce bazı soruların yanıtlanması gerekiyordu.

Öncelikle çözümün sağlam, güvenli ve güvenilir olduğundan emin olması gerekiyordu.

İkinci olarak, gerekli olduğunu belirlediği tüm ortak kritik özelliklerin çerçeve aracılığıyla kullanılabilir olduğundan emin olması gerekiyordu

Üçüncü olarak, ekonominin ajansı için işe yarayacağından emin olması gerekiyordu.

Kendisi de uygulamalı ve teknik bir kişi olarak, sistemi gerçekten test ederek ilk iki soruyu kişisel olarak doğrulamaya karar verdi. Botpress topluluğuna katıldı ve açık kaynak sürümünü kullanarak bazı video eğitimleri üzerinde çalıştı.

Yazılımı kullanan geniş ve aktif bir geliştirici topluluğu olması, yazılımın savaş testinden geçmiş olması anlamına geliyordu ki bu da iyi bir şeydi.

Başlangıçta Botpress 'un açık kaynak kodlu olmasından ve müşterilerinin bunu bir güvenlik riski olarak görmesinden (çoğu durumda haklı olarak) endişe duyuyordu. Ancak Botpress 'un, özellikle güvenlik sorunlarını ele almak için açık kaynak sürümünden ayrı olarak tutulan küratörlü bir kurumsal sürümü olduğunu öğrendi.

Elbette açık kaynak sürümü, kullanımının ücretsiz olması ve birçok durumda kurumsal kullanım durumunun dışında botlar geliştirmek için ideal olması açısından bazı avantajlar sunuyordu. Bu, bileşenlerin ve yaklaşımın birçok farklı geliştirici tarafından yoğun bir şekilde kullanıldığı ve onaylandığı anlamına geliyordu.

Müşterilerinin çoğu, sohbet robotunu şirket içinde barındırmalarını ve güvenlik ve ticari nedenlerle verileri kontrol etmelerini talep ediyordu ve Botpress bunu destekliyordu. Ayrıca, Botpress kodun tamamen özelleştirilmesine ve dahili sistemlerle entegrasyona izin veriyordu ki bu da "kodsuz" platformlarla yaşadığı asıl sorundu.

İstediği özelliklerin çoğu mevcuttu. Bunlar arasında rol tabanlı güvenlik, çok kullanıcılı yönetim ve botların dağıtım sonrası yönetimi için kullanıcı arayüzleri yer alıyordu. Eksik olanları bir modül olarak kolayca ekleyebilirdi.

Aslında modüler mimari ve sistemin grafik arayüzleri, her şeyin nereye yerleştirildiğini anlamayı çok kolaylaştırdı. Bu, bir projenin yarısında yeni geliştiricilere geçse veya uzun bir aradan sonra birinin kodu devralması gerekse bile ilgili kişinin hız kazanmasının uzun sürmeyeceği anlamına geliyordu. Buraya kadar her şey yolunda.

Ekonomi sorusu da tabii ki önemliydi. Botpress adresini kullanmak genel geliştirme maliyetlerini azaltacak mıydı? Kâr marjları kısıtlıydı. Beklentisi, Botpress gibi bir çerçeve kullanmanın geliştirme maliyetlerini azaltacağı ve aynı zamanda kalite ve özellikleri artıracağı yönündeydi.

Beklentilerinin doğru olduğu ortaya çıktı. Botpress 'u çalıştırmanın maliyeti, bazı özellikleri kendi başına oluşturmanın maliyetinin küçük bir kısmıydı ve kalite, tescilli bir çözümden daha iyiydi.

Çerçeve yaklaşımının gizli faydası, chatbot kullanıcı arayüzü ve işlevselliği üzerinde daha fazla zaman harcayabilmesi ve böylece son müşteri deneyimini önemli ölçüde iyileştirebilmesiydi.

Piyasadaki sohbet robotlarının çoğunun o kadar da iyi olmadığını gözlemlemişti. Hatta bir sektör olarak chatbot üreticilerinin müşterilerini hayal kırıklığına uğrattıkları bile söylenebilirdi.

Bunun nedeninin, şirketlerin sonuçlardan emin olmadıkları için sohbet robotları geliştirmeye makul fonlar ayırmaya hazır olmamaları olduğu söylenebilir.

Bir diğer argüman ise, chatbot üreticilerinin chatbot geliştirmek için verimli araçlara sahip olmaması ve bu nedenle geliştirme maliyetinin büyük kısmının esasen altyapıya odaklanması nedeniyle chatbot geliştirme sürecinin bugüne kadar çok verimsiz olduğu yönündedir.

Botpress gibi çerçevelerin ortaya çıkması, kullanıcı deneyimine daha fazla geliştirme bütçesi harcandıkça sohbet robotlarının kalitesini büyük ölçüde artırma potansiyeline sahipti.

Kayıtlara geçmesi açısından, Erik gerçek bir kişi değil, sorunları, gereksinimleri ve chatbotların yapabileceklerine olan ilgileriyle bizimle iletişime geçen bazı ajans sahiplerinin bir bileşimidir. Çeşitli şekillerde "Müşterilerim için sohbet robotları geliştirme konusunda başlangıçta bilmek istediklerim" versiyonunu paylaştılar.

Ana konuları özetleyecek olursak bunlar

• Harika sohbet robotları oluşturmak için koda ve verilere erişim gerekir.
• Geliştiricilerin iş mantığını özelleştirmesi ve dahili sistemlerle entegre etmesi gerekir. Geliştiriciler olmadan harika chatbotlar oluşturmak mümkün değildir.
• Birçok kurumsal müşterinin güvenlik endişeleri vardır ve bu nedenle sohbet robotlarını şirket içinde çalıştırmak isterler. Ayrıca, kullandıkları herhangi bir yazılımdan bekledikleri rol tabanlı güvenlik ve kullanıcı yönetiminin aynısını istiyorlar.
• Bir ajansın seçtiği çerçeve, kutudan çıkar çıkmaz çok çeşitli ortak özellikler sağlamalıdır.
• Herhangi bir ajansın (veya geliştirme mağazasının) kendi veritabanlarını sıfırdan oluşturması ne kadar mantıklıysa, dahili kullanımları için kendi chatbot çerçevelerini oluşturmaları da o kadar mantıklı değildir. Bu sadece ekonomik olmamakla ve büyük bakım maliyetleri yaratmakla kalmaz, aynı zamanda müşterileri de muhtemelen çekirdek olmayan altyapıyı kendileri oluşturmaya çalışmak yerine, amaca yönelik olarak oluşturulmuş, iyi anlaşılmış altyapı ürünlerini kullanmayı tercih edecektir.
• Sektör, daha fazla geliştirme harcamasının altyapıdan ziyade kullanıcı deneyimine yönelebilmesi için çerçevelere ihtiyaç duyuyor.