Ürününüze yapay zekâ eklemenin gerçek maliyeti

“Ürünümüze yapay zekâ eklemek ne kadara mal olur?” sorusuna genellikle ilk geliştirme için bir rakamla cevap verilir. Bu rakam gerçektir, ama gerçek maliyetin en küçük kısmıdır. Yapay zekâ özelliklerinin, tipik bir yazılım özelliğine hiç benzemeyen, süreklilik arz eden bir maliyet yapısı vardır ve bunu planlamayan ekipler yayından birkaç ay sonra tatsız bir sürprizle karşılaşır.

Maliyet 1: İlk geliştirme

Herkesin bütçelediği kısım budur: özelliği tasarlamak, bir modeli entegre etmek, etrafındaki ürün deneyimini oluşturmak ve test etmek için harcanan mühendislik zamanı. Sıfırdan model eğitmek yerine mevcut bir modeli kullanan, kapsamı iyi belirlenmiş bir özellik için bu, genellikle orta karmaşıklıktaki herhangi bir özelliği geliştirmekle kıyaslanabilir. Genellikle pahalı olan kısım bu değildir.

Maliyet 2: İstek başına kullanım maliyetleri

Ekiplerin en sık hafife aldığı kalem budur. Ürününüz bir dil modelini her çağırdığında bunun için ödeme yaparsınız; genellikle giren ve çıkan metin miktarına göre. Tek bir istek ucuzdur. Binlerce aktif kullanıcı tarafından günde defalarca kullanılan bir özellik ise ürününüzün başarısıyla doğru orantılı olarak büyüyen, gerçek ve düzenli bir gider kalemine dönüşür. Bir demoda sohbet başına kuruşlara mal olan bir sohbet özelliği, gerçekten popüler hâle geldiğinde barındırma faturanızın kayda değer bir kısmını oluşturabilir. Eskiden tamamen artı olan büyüme, artık doğrudan maliyetleri de artırabilir.

Çözüm yapay zekâ özelliklerinden kaçınmak değil, onları baştan maliyeti gözeterek tasarlamaktır: tekrarlanan sorguları önbelleğe almak, basit görevler için daha küçük ve ucuz bir model, yalnızca gerçekten gereken yerlerde daha büyük bir model kullanmak ve tek bir kullanıcının ya da kontrolden çıkan bir hatanın sürpriz bir fatura çıkaramayacağı gerçek kullanım sınırları koymak.

Maliyet 3: Veri ve bilgi getirme hattı

Özelliğinizin kendi verilerinizden — destek belgeleri, ürün kataloğu, şirket içi bilgiler — cevap vermesi gerekiyorsa, bu verileri güncel, indeksli ve aranabilir tutan gerçek bir veri hattına ihtiyacınız vardır (bkz. retrieval-augmented generation). Bu hat bir kerelik bir geliştirme değildir. Dokümantasyon değişir, ürünler eklenir, politikalar güncellenir; alttaki indeks buna ayak uyduramazsa yapay zekâ özelliğiniz kimseyi uyarmadan sessizce güncelliğini yitirmiş cevaplar vermeye başlar.

Maliyet 4: Sürekli kalite izleme

Geleneksel yazılımın aksine bir yapay zekâ özelliği, hiçbir kod değişikliği olmadan zamanla daha kötü davranmaya başlayabilir: Model sağlayıcısı modelini güncellediği için, kullanıcılarınızın soruları değiştiği için ya da kendi verileriniz sistemin ayarlandığı hâlinden uzaklaştığı için. Sürekli değerlendirmeyi atlayan ekipler kalite sorunlarını bir panelden değil, öfkeli müşterilerden öğrenir ve bu, öğrenmenin çok daha pahalı bir yoludur.

Maliyet 5: İnsan güvenlik ağı

Yanılmanın gerçek bir bedeli olan her yapay zekâ özelliği, bir insanın hataları yakalayıp düzeltebileceği bir yönteme ihtiyaç duyar: bir inceleme adımı, kullanıcının kötü bir cevabı kolayca işaretleyebileceği bir yol, gerçek bir kişiye yönlendiren bir eskalasyon süreci. Bu güvenlik ağını kurmak ve ona personel ayırmak gerçek ve sürekli bir maliyettir; yalnızca mühendislik zamanını hesaba katan bir ilk tahminde kolayca gözden kaçar.

Bunu gerçekte nasıl bütçelemelisiniz?

• Kullanım maliyetlerini bir demoda test ettiğiniz hacme göre değil, gerçekçi bir hacim projeksiyonuna göre tahmin edin. Maliyeti mevcut ölçeğinize göre değil, hedef ölçeğinize göre modelleyin.
• “Geliştirme” bütçesini “çalıştırma” bütçesinden açıkça ayırın ve çalıştırma bütçesinin yalnızca ilk yayın için değil, sürekli olarak birinin sorumluluğunda olduğundan emin olun.
• Maliyete duyarlı kullanım senaryoları için özelliğin daha hafif bir sürümünü planlayın; her istek mevcut en pahalı modele ihtiyaç duymaz.
• Kaliteyi yalnızca yayından önce değil, yayından sonra da izlemek için gerçek zaman ayırın.

Dürüst özet

Yapay zekâ özelliklerinin maliyet yapısı çoğu yazılımdan gerçekten farklıdır: geliştirme için daha düşük sabit maliyet, çalıştırma için gerçek ve büyüyen değişken maliyet ve geleneksel özelliklerin çoğunlukla ihtiyaç duymadığı sürekli bakım. Bunların hiçbiri yapay zekâyı kötü bir yatırım yapmaz. Ancak gerçek bütçe konuşmasının ilk şaşırtıcı faturadan sonra değil, geliştirme başlamadan önce yapılması gerektiği anlamına gelir.

Burncode olarak her müşterimizle erken aşamada bu konuşmayı yapıyoruz: Bir özelliğin yalnızca demoda değil, gerçek ölçekte çalıştırılmasının gerçekte neye mal olacağını modelliyoruz; böylece özellik kullanıcılarınız arasında gerçekten popüler hâle geldiğinde sürprizlerle karşılaşmazsınız.