Geliştirmek, satın almak ya da beklemek: her yapay zeka iş akışı için nasıl karar verilir?

“Yapay zekayı kendimiz mi geliştirelim, yoksa satın mı alalım?” tek bir karar gibi görünür. Pratikte her iş akışı için bir tane olmak üzere bir düzine karardır ve yanıtlar birbirinden farklıdır. Bu soruyu bir politika olarak bir kez yanıtlayan şirket, sonunda ya rekabet ettiği iş akışına hazır bir ürünü zorla uydurur ya da kendi toplantı özetleme aracını geliştirir.

Bunun yerine her iş akışı için ayrı karar verin. Her şirketin ihtiyaç duyduğunu satın alın. İş akışı sizin rekabet biçiminizse ya da veriyi, promptları ve değerlendirmeyi kontrol etmeniz gerekiyorsa geliştirin. İş akışının sahibi yoksa ya da verisine erişilemiyorsa bekleyin. Karar kıl payıysa iki seçeneği de aynı örneklerle test edin.

“Geliştirmek mi, satın almak mı?” neden yanlış ilk sorudur?

Çünkü kararı belirleyen soruları atlar: hangi iş akışı, sahibi kim, bugün kaça mal oluyor ve iyi bir sonuç neye benzer? Bunlar olmadan bir ürün demosu ile özel bir geliştirme önerisi karşılaştırılamaz, çünkü ikisi de hiçbir şeye karşı ölçülmemiştir. Üçüncü yanıtı, yani beklemeyi de dışarıda bırakır; oysa beklemek, yarıda kalan bir projeden ucuzdur. Yönetim ekiplerinin ilk projeden önce sorduğu sorular notundaki kısa yanıt hâlâ geçerli; bu not da onun uzun hali.

Her aday iş akışını tablodan geçirin. En çok yanıtı toplayan sütun bir hüküm değil, bir başlangıç noktasıdır.

Hiçbir şey güçlü biçimde başka bir yönü göstermiyorsa varsayılan tercih şudur: yaygın işler için satın alın; yalnızca ürünlerin sizin örneklerinizde yapamadığını geliştirin.

Aynı şirket, farklı iş akışları için genellikle aynı anda hem satın almalı, hem geliştirmeli, hem de beklemelidir.

Satın almak ne zaman daha iyi yanıttır?

İş sizin şirketinizde de her yerdekiyle aynıysa: toplantıları özetlemek, taslak yazmak ve metinleri yeniden yazmak, bir kişinin zaten açabildiği belgelerde arama yapmak, görüşmeleri yazıya dökmek. Tedarikçiler bu özelliklerin maliyetini çok sayıda müşteriye yayar ve onları tek bir şirketin yapabileceğinden daha hızlı geliştirir.

Satın almak en iyi, şu üç koşul sağlandığında işe yarar. Ürün sistemlerinize standart bağlayıcılarla ulaşır. Veri koşulları ve veri işleme yerleri veri koruma görevlinizin (DPO) incelemesinden geçer. İyi bir yanıtın ne olduğuna dair anlayışı da sizinkine yeterince yakındır; aradaki farkı kod değil, yapılandırma kapatır.

Bedelleri görünürdür: kullanım yaygınlaştıkça artan fiyatlar, sizin yol haritanız yerine tedarikçinin yol haritası ve yalnızca dışarıdan ölçebildiğiniz bir kalite. Genel işler için bu bedeller genellikle ödemeye değer. Verimlilik asistanları ile özel sistemler farklı işler görür ve muhtemelen ikisine de ihtiyacınız olacak.

Geliştirmek ne zaman daha iyi yanıttır?

İş akışı sizin rekabet biçiminizse geliştirin: hizmet vaadiniz, teklif hazırlama biçiminiz, talepleri ele alış yönteminiz. Ürünler ortalama müşteriye hizmet eder; sizi farklı kılan şey ise tanımı gereği ortalama değildir.

Kaliteyi tanımlayan şeyi kontrol etmeniz gerektiğinde de geliştirin: bulutunuzda ya da sunucularınızda kalması gereken veriler, bir tedarikçiye devredemeyeceğiniz politikaları içeren promptlar, kararlar ileride sorgulanacağı için sahibi olmanız gereken bir değerlendirme seti ve denetim kaydı. Bir ürün neredeyse uyuyor ama sistemlerinize ulaşamıyor ya da kurallarınızı izleyemiyorsa yine geliştirin; özel yapay zeka yazılımı tam da bu boşluğu kapatmak için var.

Geliştirmek sıfırdan başlamak demek değildir. Model erişimini, bulutu ve çoğu zaman arama bileşenlerini yine satın alırsınız; geliştirdiğiniz, bunların üzerindeki iş akışına özgü katmandır. Bakımını da üstlenirsiniz: izleme, bir sağlayıcı modeli güncellediğinde regresyon testleri ve canlıya geçtikten sonra bir sahip.

Beklemek ne zaman doğru karardır?

Herhangi bir yanıt için gereken koşullar eksikse bekleyin:

• Sahip yok. İyi yanıtları kimse tanımlamayacak, tasarımı kimse onaylamayacak, canlıya geçtikten sonra sistemi kimse işletmeyecek.
• Erişilebilir veri yok. Bilgi kişisel klasörlerde, e-posta yazışmalarında ya da insanların aklında.
• Yerinde durmayan bir süreç. İş akışı yeniden tasarlanıyor ya da temel sistemi değiştiriliyor; şimdi geliştirilen her şey iki kez geliştirilir.
• Yüksek risk, belirsiz fayda. Hatalar pahalıya patlar ve kimse mevcut sürecin maliyetini bilmiyor.

Beklemek hiçbir şey yapmamak değildir. İlk proje, sahibi belirlemek, veri erişimini açmak ya da başlangıç ölçümünü almak olur; bu yapıldığında iş akışı yeniden gündeme gelir.

Pratikte hibrit bir yapı neye benzer?

Olağan sonuç tek bir yanıt değil, katmanlı bir yapıdır: herkesin kullandığı platformları ve genel asistanları satın alın, ardından iş akışına özgü parçaları onların üzerine geliştirin; kaynaklarınız üzerinde bilgi erişimi, kurallarınız, inceleme ekranları, entegrasyonlar ve değerlendirme seti gibi.

Bir perakendecinin müşteri hizmetleri ekibinden temsili bir karşılaştırma ele alalım. Ekibin kullandığı destek masası (helpdesk) ürünü, destek taleplerini özetleyen ve bilgi bankasından yanıt öneren bir yapay zeka özelliği sunuyor. İade ekibi ise başka bir şey istiyor: her iade kararının sipariş, fotoğraflar ve geçerli politika paragrafıyla hazırlanması ve bir insanın onaylaması.

Aynı birkaç yüz geçmiş iade üzerinde çalıştırıldığında yanıtlar ayrışır. Satın alınan özellik iyi bir özet ve kibar bir yanıt yazar, birkaç günde de canlıya alınır; ama sipariş sistemini okuyamaz, fotoğrafları ürün kaydıyla karşılaştıramaz ya da politikaya atıf yapamaz; bu yüzden kararı hazırlayamaz. Temsili İade zekası çalışması gibi özel bir iş akışı ise yaklaşık altı ila on haftalık bir pilottan sonra bunu yapabilir. Sonuç: yanıt özelliğini satın almaya devam edin, karar adımını geliştirin ve bu adımın ölçülmüş bir geçmişi oluşana kadar para iadelerinin otomatikleştirilmesini bekletin.

Bir ürün ile özel bir geliştirme adil biçimde nasıl karşılaştırılır?

İkisi için de aynı kanıtı kullanın. İki üç ürünü kısa listeye alın, yaklaşık aynı sürede özel bir prototip geliştirin ve kimse bir şey çalıştırmadan önce kabul kriterlerini yazın.

1. Tek bir değerlendirme seti. Uzmanların onayladığı yanıtlarla, zorlu vakalar da dahil birkaç yüz gerçek vaka; demo örnekleri üzerinde değil, uygun bir veri sözleşmesiyle sizin verileriniz üzerinde çalıştırılır.
2. Vaka türüne göre sonuçlar. Ortalama, her seçeneğin başarısız olduğu vakaları gizler.
3. İnceleme süresi. Bir kişinin her çıktıyı kontrol edip düzeltmek için harcadığı dakikalar. Çoğu zaman en büyük maliyet budur ve demoların gizlediği de budur.
4. Tamamlanan görev başına maliyet. Gerçek hacminizde lisanslar ya da kullanım ücreti, altyapı, inceleme süresi ve bakım.
5. Entegrasyon. İş akışının ihtiyaç duyduğu sistemleri, çalışanlarınızın zaten sahip olduğu yetkilerle okuyup onlara yazabiliyor mu?
6. Cila değil, sonuç. Bir prototip bir üründen daha kaba görünür; her birinin neyi doğru yaptığını karşılaştırın.

Bağımlılık ve çıkış konusunda neler sorulmalı?

Her seçenek sizi bir yerden bağlar; bu yüzden ayrılırken değil, imzalamadan önce sorun:

• Promptları, yapılandırmayı, değerlendirme setlerini ve kayıtları kullanılabilir bir formatta dışa aktarabilir miyiz?
• Ürünün içinde oluşturduğumuz promptların ve değerlendirme setlerinin sahibi kim? Bunu tedarikçiye olduğu kadar hukuk danışmanınıza da sorun.
• Tedarikçi alttaki modeli değiştirdiğinde ne olur: önceden haber alır mıyız ve değişiklik kullanıcılara ulaşmadan kendi değerlendirme setimizle yeniden test edebilir miyiz?
• Kendi model sağlayıcımızı kullanabilir miyiz ve verilerimiz nerede işleniyor?
• Özel geliştirmede: kodun, promptların, değerlendirme setlerinin ve dokümantasyonun sahibi biz miyiz ve tasarım modelden bağımsız mı?

Soru listesinin tamamı tedarikçi değerlendirmesinin konusudur. Hangi yolu seçerseniz seçin, en iyi sigortanız değerlendirme setinizdir: onunla, tedarikçi değiştirmek karanlığa atılan bir adım değil, bir test olur.

Tablo her iş akışına nasıl uygulanır?

Aday iş akışlarınızı listeleyin, her birini tablodan geçirin ve “satın alma”, “geliştirme” ya da “bekleme” olarak işaretleyin. Kararın kıl payı olduğu durumlarda, kimse imza atmadan önce yan yana testi yapın. Bir yapay zeka stratejisi ve keşif çalışması, her aday için tam olarak bu kararla biter: geliştirme, satın alma, bekleme ya da durdurma. Ya da tek bir iş akışını bize anlatın ve oradan başlayalım.