Yapay Zekâ Aracı Kurmak Kolay, Şirketi Dönüştürmek Değil

Bir şirkette çok sayıda yazılım bulunması, tekrarlanan işlerin azaldığı anlamına gelmiyor. Ana sistemlerin yanında tablolar, e-postalar ve çalışanların kendi kurduğu küçük çözümler yaşamaya devam ediyor. Yapay zekâ bu işleri kolaylaştıracak yeni araçlar üretmeyi hızlandırıyor. Fakat şirketin çalışma biçimi aynı hızla değişmiyor.

Benedict Evans, “AI, tools and transformation” yazısında bu farkı tartışıyor. Araç üretmek kolaylaşsa da hangi sorunun çözülmesi gerektiğini görmek, doğru çözümü bulmak ve başkalarının da onu kullanmasını sağlamak ayrı işler. Bir çalışanın kendi ihtiyacı için geliştirdiği çözüm, başka ekiplerin işini ve kararlarını etkilemeye başladığında yeni sorumluluklar doğuruyor. Bakımını kimin yapacağı, hangi veriye güvenileceği ve hatanın kim tarafından düzeltileceği belirlenmek zorunda.

Bu değerlendirmeyi kendi çalışmalarımda da karşılığı olduğu için anlamlı buluyorum. Özellikle müşteriyle satış ekibi arasındaki görüşmeleri yapay zekâyla analiz etmeye çalışırken, başlangıçta basit görünen işin ne kadar çok bilgiye ve karara bağlı olduğunu gördük.

Konuşmayı okumak yetmedi

İlk bakışta iş oldukça açık görünüyordu: Görüşme metinlerini yapay zekâya verecek, belirlediğimiz ölçütlere göre analiz ettirecektik. Ancak konuşmayı doğru değerlendirmek için metnin dışında kalan bilgilere de ihtiyacımız olduğu ortaya çıktı. Farklı kaynaklardan veri toplamak gerekiyordu.

Müşteri ilişkilerini yönettiğimiz CRM sistemindeki veriler de bu analiz için hazır değildi. Kayıtlar, müşteriye veya potansiyel müşteriye bakan çalışanın hızlıca fikir edinmesini kolaylaştıracak biçimde tutuluyordu. Bu amaç için kullanışlı olan düzen, yapay zekâyla ayrıntılı analiz yapmak istediğimizde sorun çıkardı.

Bir insanın kayda bakıp iş tecrübesiyle tamamladığı anlamı, modelin kendiliğinden bilmesini bekleyemiyoruz. Modelin önüne koyduğumuz veride hangi bilginin neyi temsil ettiği yeterince açık olmalı. Bizim verimiz bu açıdan kirliydi. Günlük işte kullanılan kayıtla analize uygun veri arasındaki farkı çalışmanın içinde gördük.

Üstelik bir süredir güncellenmeyen, kullanım dışı kalmış veriler de bulduk. Bunların bir bölümü, bugün yapay zekâyla yapabileceğimiz analizler için yeniden işe yarayabilirdi. Elbette önce ne kadar güncel ve güvenilir olduklarını anlamak gerekiyordu. Verinin sistemde durması, analize doğrudan alınabileceği anlamına gelmiyordu.

Başlangıçta konuşma metinlerine bakmayı planlarken, müşteriyi ve görüşmenin koşullarını anlamak için hangi bilgilere ihtiyaç duyduğumuzu yeniden ele almaya başladık.

İyi bir görüşmenin ölçütü hazır gelmiyor

Verileri bir araya getirmek de tek başına yeterli olmadı. Yapay zekânın genel ölçütlerle yaptığı değerlendirme ile yöneticilerin aynı görüşmeye bakışı her zaman örtüşmüyordu. Yöneticilerin dikkate aldığı ayrıntılar ve istisnalar vardı.

Bu yüzden değerlendirme kriterlerini ve promptları defalarca gözden geçirdik. Hangi durumda neye bakılacağını, hangi ayrıntının sonucu değiştirdiğini daha açık anlatmak gerekiyordu.

Dışarıdan bakınca bu çalışma, modele daha iyi talimat yazmak gibi görünebilir. Fakat talimatı düzeltebilmek için önce kendi kararımızın gerekçesini açıklayabilmemiz gerekiyor. Bir görüşmeyi neden başarılı buluyoruz? Bir başkasında aynı davranışı neden farklı değerlendiriyoruz? Şirketin içinden bakınca anlaşılır olan bir istisna, yazıya dökülmediğinde model için görünmez kalıyor.

Yöneticinin her değerlendirmesini tartışmasız doğru kabul etmek de çözüm değil. Ayrışmanın kaynağını anlamak gerekiyor: Modele eksik bilgi mi verdik, ölçütü mü belirsiz bıraktık, yoksa kendi değerlendirmemizi de mi yeniden düşünmeliyiz?

Bu deneyimin bende bıraktığı ders, iş bilgisinin ne kadarının günlük muhakemenin içinde saklı olduğuydu. Analiz aracını kurarken o bilgiyi de ortaya çıkarmamız gerekti. Çalışmanın zaman isteyen kısmı, şirketin zaten bildiğini varsaydığımız şeyleri sisteme açıkça anlatabilmekti.

Yapabileceklerimizin sınırını da biz çiziyoruz

Bazı görevlerde ise sınırı veriye veya modele bakarak belirleyemeyiz. Sağlık bunun doğrudan bir örneği.

Bir chatbot hastadan bilgi toplamaya yardımcı olabilir. Aynı sisteme teşhis koyma görevi verdiğinizde, üstlendiği sorumluluk değişir. Örneğin AB Tıbbi Cihaz Tüzüğü, belirli tıbbi amaçlarla kullanılmak üzere tasarlanan yazılımları da kapsıyor. Amaçlanan kullanım belirleyici. Bir yazılımın sağlık kuruluşunda kullanılması tek başına tıbbi cihaz olduğu anlamına gelmiyor.

Bu ayrımı chatbot, triyaj ve tıbbi cihaz arasındaki farkı ele aldığım yazıda daha ayrıntılı anlatmıştım.

Biz de teşhis kararını doktorlara bırakmayı tercih ettik. Sektörün ve mevzuatın getirdiği sınırlar bu tercihin parçasıydı. Fakat doktorun kararını korumak, kendi çalışma yaklaşımımız açısından da istediğimiz sonuçtu. Modelin bir yanıt üretebilmesi, o kararı ona devretmek için yeterli gerekçe oluşturmuyor.

Dolayısıyla sistemi geliştirirken nerede duracağını da tasarlıyoruz. Bilgiyi toplamak, değerlendirmeye hazırlamak ve tıbbi karar vermek, aynı konuşmanın içinde gerçekleşebilse de ayrı sorumluluklar taşıyor.

Tek başıma tamamladığım işle şirketin işi aynı değil

Kişisel projelerimde ise yapay zekânın daha doğrudan bir faydasını gördüm. PeşinTaksit'in altyapısını sadeleştirirken, normalde zaman ayırmayacağım bir işi yaklaşık bir saatte tamamladım. Proje benimdi, ihtiyacı biliyordum ve değişiklik kararını kendim verebiliyordum.

Satış görüşmesi analizinde ise işin tanımı, veriler ve değerlendirme ölçütleri birlikte ele alınmak zorundaydı. Birindeki kısa geliştirme süresini diğerine taşımak, yapılması gereken işin bir bölümünü hesaptan çıkarmak olurdu.

Bu nedenle bir yapay zekâ projesi için süre veya bütçe konuşurken, veri hazırlamaya ve işi bilen insanlarla değerlendirme yapmaya da yer ayırmak gerekiyor. Bunlar aracın önündeki gereksiz beklemeler değil, aracın kullanılabilir olmasını sağlayan işin parçaları.

Çalışan bir ilk örnek, projenin ilerlediğini gösterir. Şirketin o örneğe dayanarak karar vermeye hazır olup olmadığını ise veriyi ve ölçütleri birlikte sınayarak öğreniriz.