Bir yapay zekâ projesinin maliyetini ne belirler?

Bir yapay zekâ projesinin maliyetini yalnızca kullanılan model değil, sistemin erişeceği veri, bağlanacağı araçlar, hata toleransı ve işletim sorumluluğu belirler. İhtiyaç netleşmeden tek bir fiyat vermek bu farkları gizleyebilir.

Bu yazı fiyat teklifi veya tasarruf taahhüdü değildir. Amaç, iki teklifin hangi kapsamlar üzerinden karşılaştırılabileceğini açıklamak ve görünmeyen iş kalemlerini ortaya çıkarmaktır.

Kurulum ile kullanımı ayrı değerlendirin

Kurulum; süreç analizi, veri hazırlığı, entegrasyon geliştirme ve değerlendirme setinin oluşturulmasını kapsayabilir. Kullanım tarafında model çağrıları, veri saklama, arama, sunucu ve izleme giderleri bulunabilir. Ekibin çıktı kontrolüne ayırdığı süre de operasyonun bir parçasıdır.

AWS’nin maliyet optimizasyonu yaklaşımı, sistemleri iş değeri sağlayacak maliyetle işletmeye odaklanır. Buradaki pratik karşılığı, en düşük görünen servis ücretini değil, ihtiyacı karşılayan toplam çözümü değerlendirmektir. AWS Well-Architected — Cost optimization.

Kapsamı değiştiren beş kalem

Kalem	Maliyeti etkileyen soru	Önceden hazırlanabilecek bilgi
Veri	Belgeler tutarlı ve güncel mi?	Kaynak listesi ve örnek kayıtlar
Entegrasyon	Araçların kullanılabilir API’si var mı?	Ürün/sürüm ve erişim kapsamı
Kontrol	Yanlış çıktının etkisi ne?	Onay ve durdurma kuralları
Kullanım	Kaç işlem, ne uzunlukta girdi?	Tipik ve yoğun dönem hacmi
Bakım	Değişen süreçleri kim takip edecek?	İş sahibi ve destek beklentisi

“Bir CRM’e bağlanacak” ifadesi kapsamı tek başına belirlemez. Yalnızca belirli kayıtları okumak ile iki yönlü eşitleme, çakışma çözümü ve hatadan kurtarma eklemek farklı işlerdir. Aynı biçimde küçük bir belge klasörü ile farklı erişim izinlerine sahip arşiv aynı hazırlığı gerektirmez.

İşlem başına maliyeti düşünün

Değerlendirme için kullanılabilecek basit bir hesap şöyledir: aylık sabit giderler, işlem hacmine bağlı giderler ve kontrol/bakım emeği birlikte ele alınır. Sonra bu toplam, gerçekten tamamlanan yararlı iş sayısıyla karşılaştırılır. Başarısız çağrılar ve yeniden denemeler de gider oluşturabilir; yalnızca ilk denemeyi saymak eksik bir tablo verir.

Örneğin bir teklif taslağı sistemi için “taslak sayısı” kadar, taslakların ne kadarının kullanılabilir bulunduğunu da izlemek gerekir. Gözden geçirme süresi artıyorsa model çağrısı ucuz olsa bile beklenen fayda gerçekleşmeyebilir. Bu örnek sayısal bir müşteri sonucu değildir.

Teklif isterken neyi netleştirmeli?

Teslimin yalnızca demo mu, pilot mu, yoksa işletilecek bir sistem mi olduğunu yazılı hâle getirin. Hangi araçların bağlanacağı, veri taşımanın kapsamı, hata durumları, kabul ölçütleri ve bakım sorumlusu aynı tarifin içinde bulunmalı.

Model veya dış servis bedellerinin teklife dahil olup olmadığını ayrıca belirleyin. Kullanım sınırlarını ve bu sınır aşıldığında sistemin ne yapacağını konuşun. Sabit kapsamın dışında kalan yeni akışlar için nasıl karar verileceğini baştan tanımlamak sonradan oluşan belirsizliği azaltır.

Bütçeyi koruyan ilk adım

İlk sürümde tek bir iş ve sınırlı veri kaynağı seçin. Başarı ölçütü karşılanınca genişletin. Bu yaklaşım her projeyi ucuz yapmaz; hangi ek harcamanın hangi iş sonucunu hedeflediğini açıklamayı kolaylaştırır.

Hazırlık için işin sıklığını, kullanılan araçları, tipik bir girdi/çıktı örneğini ve insan kontrolü gerektiren adımı yazmanız yeterlidir. İlk pilotu seçme rehberi bu notu oluşturmanıza yardımcı olur. Araçların birbirine nasıl bağlanacağını anlamak için entegrasyon rehberini okuyabilirsiniz.