Bir yapay zeka projesinin maliyetini ne belirler ve maliyet nasıl öngörülebilir tutulur?
Pahalı olan çoğu zaman model değildir. Maliyeti bağladığınız sistemler, verinin durumu, inceleme tasarımı, diller, güvenlik incelemeleri ve rutinlerin ne kadar değişeceği belirler. Her aşamanın sabit bir kapsamı olması maliyeti öngörülebilir tutar.
veridive5 dk okuma
Üç tedarikçi aynı yapay zeka projesi için teklif verir ve fiyatlar birbirinden o kadar uzaktır ki farklı projeleri anlatıyor gibidirler. Çoğu zaman gerçekten de öyledir. Biri bir prototipi, biri tek bir sistem üzerinde bir pilotu, biri de şirket genelinde canlı kullanımı fiyatlamıştır.
Pahalı olan nadiren modeldir. Yapay zeka projesi maliyeti, modelin etrafındaki işe bağlıdır: bağlanacak sistemler, verinin durumu, inceleme tasarımı, diller, güvenlik ve veri koruma incelemeleri ve ekibin rutininin ne kadar değişmesi gerektiği. Bu maliyeti öngörülebilir tutan şey, her aşamanın sabit bir kapsamının olmasıdır.
“Yapay zeka kaça mal olur?” sorusu neden tek bir rakamla yanıtlanamaz?
Çünkü “yapay zeka projesi”, bir günlük bir prototipten üç ERP’den veri okuyan, birine kayıt yazan ve iki dilde çalışan bir sisteme kadar her şeyi kapsar. İkisinde de model çağrısı benzerdir. Geri kalan neredeyse her şey farklıdır.
Zor olmasının bir nedeni de en büyük bilinmeyenlerin ancak bakınca ortaya çıkmasıdır: veriye erişilebiliyor mu, gerçek vakalar ne kadar dağınık, iş akışında kaç istisna var, güvenlik incelemesi neler soracak? Dürüst bir tedarikçi, biri bunlara bakmadan onları fiyatlayamaz. İlk adımın küçük, sabit ve bilinmeyenleri ortadan kaldıracak biçimde tasarlanmış olması bu yüzden gerekir.
Geliştirme maliyetini en çok ne etkiler?
İki teklif arasındaki farkı genellikle şu yedi etken açıklar:
| Etken | Neden önemli | Nasıl azaltılır |
|---|---|---|
| Entegrasyonlar | Her sistem erişim, alan eşleştirme, hata yönetimi ve test ister; yazmak okumaktan pahalıdır | Tek bir sistemle ve yalnızca okuyarak başlayın |
| Veri erişimi | Onaylar, yetkiler, formatlar ve temizlik, her türlü yapay zeka işinden önce gelir | Verisine zaten erişilebilen bir iş akışı seçin |
| Diller | Her dil kendi örneklerini, inceleyicilerini ve testlerini ister | Tek dilde canlıya geçin; sonrakini kendi vakalarıyla ekleyin |
| İnceleme ekranları | İnsanların tek adımda onaylayabilmesi için kanıtı önlerinde görmeleri gerekir | İnsanların zaten çalıştığı araçları kullanın |
| Değerlendirme | Uzmanlar birkaç yüz vaka için referans yanıt yazar | Onların zamanını baştan bütçeleyin |
| Güvenlik ve veri koruma incelemesi | Geç gelen sorular işin yeniden yapılmasına yol açar | İnceleyicileri ilk hafta sürece katın |
| Değişim yönetimi | Eğitim, yeni rutinler ve sahiplik | Tek bir ekip ve onun gerçek görevleriyle başlayın |
Son ikisi tekliflerde kolayca atlanır; oysa sistemin canlıya geçip geçmeyeceğini ve kullanılıp kullanılmayacağını onlar belirler.
Pahalı olan nadiren modeldir. Pahalı olan, modelin etrafındaki iştir.
Bir projeyi göründüğünden pahalı yapan nedir?
Basit bir tanımın arkasında birkaç çarpan saklanır:
- Yalnızca okumak değil, yazmak. Bir ERP’ye kayıt atmak onay adımları ve geri alma ister; bir öneri taslağı hazırlamaktan çok daha fazla test de gerektirir.
- Çok sayıda varyant. Her tedarikçinin belge düzeni, her belge şablonu ya da kanal, test edilecek vakaları artırır.
- Doğru olması şart olan nadir vakalar. Olağan dışı vakaları doğru yapmak, yaygın olanları doğru yapmaktan daha pahalıdır.
- Belirsiz sahiplik. Kararlar bekler ve bekleme de faturalanır.
- Geliştirme sırasında büyüyen kapsam. “Hazır elimiz değmişken…” bir projedeki en pahalı cümledir.
Temsili bir vaka bunu iyi gösterir: aynı fatura iş akışı, iki farklı kapsamla. İlk kapsamda tek bir şirketin faturaları okunur, satın alma siparişleriyle eşleştirilir ve tek bir ERP’de Türkçe kayıt taslağı olarak hazırlanır. İkincisinde aynı iş, üç ayrı ERP kullanan üç şirketi (örneğin SAP, Logo ve Microsoft Dynamics) Türkçe ve İngilizce olarak kapsar. Bilgi çıkarma ve eşleştirme mantığı büyük ölçüde ortaktır; bu yüzden ikinci kapsam üç katı tutmaz. Ama üç entegrasyonu vardır ve her birinin kendi veri modeli, test ortamı ve onay akışı bulunur. Eğitilecek üç finans ekibi vardır. Değerlendirme seti de sistem ve dil kombinasyonlarının hepsini, yani toplam altısını kapsamak zorundadır, çünkü bir kombinasyonda doğru işlenen bir fatura bir diğerinde hata verebilir. Geliştirmesi daha pahalı, test edilmesi ise çok daha pahalıdır.
Maliyeti ne düşürür?
Çoğunlukla bilerek yapılan ters tercihler: başlangıçta tek iş akışı, tek sahip, tek sistem ve tek dil; onaylı sistemlerde zaten erişilebilen veri; işlemden önce taslak; ilk hafta yapılan incelemeler ve geliştirmeden önce yazılan kabul kriterleri. Kabul kriterleri sayesinde, sistem yeterince iyi olduğunda ayarlama turları da biter. Değerlendirme setinin yeterince iyi olduğunu gösterdiği yerde daha küçük bir model işletme maliyetini düşürebilir; ama geliştirme maliyetini nadiren fazla değiştirir.
İşletme maliyetleri geliştirme maliyetiyle nasıl kıyaslanır?
Geliştirme maliyeti her aşamada bir kez ödenir. İşletme maliyetleri ise sistem kullanıldığı sürece her ay tekrarlanır: model kullanımı, altyapı, insanların çıktıyı incelemek için harcadığı dakikalar, izleme ve promptları, kaynakları ve değerlendirme setini iyileştirmenin sürekli emeği. Bir sistemin ömrü boyunca işletme maliyetleri geliştirme maliyetini aşabilir; en büyük kalem de çoğu zaman inceleme süresidir.
Bunları başta tahmin etmek yerine pilot sırasında ölçün. Nasıl yapılacağını LLM işletme maliyetlerini tahmin etme notumuz gösteriyor; token maliyetini hata maliyetiyle karşılaştıran not ise hataların bedelini ekliyor.
Güvenebileceğiniz bir fiyata nasıl ulaşılır?
Projeyi, her biri sabit kapsamlı ve sabit fiyatlı aşamalar halinde satın alın. Her aşama, bir sonrakinin fiyatlandırılmasını zorlaştıran bilinmeyenleri ortadan kaldırır:
- Yönetici Atölyesi (1 gün): yönetim ekibiyle birlikte gerçek bir iş akışı üzerinde çalışan bir prototip ve önceliklendirilmiş üç fırsat.
- Keşif Çalışması (yaklaşık iki hafta): başlangıç ölçümü, veri ve erişim incelemesi, riskler ve kabul kriterleriyle bir pilot planı.
- Pilottan Canlıya (yaklaşık altı ila on hafta): onaylı veriler üzerinde, sınırları belli bir pilot. Üzerinde anlaşılan kriterleri karşıladığında ayrı bir canlı kullanım kapsamı gelir.
Bunlar sunduğumuz başlangıç formatlarıdır; özel yapay zeka yazılımı çalışmalarımız da genellikle bir pilotla başlar. Kiminle çalışırsanız çalışın, tekliflerin karşılaştırılabilmesi için her tedarikçiye aynı soruları sorun:
- Kapsamda tam olarak ne var: hangi iş akışı, sistemler, diller ve vaka türleri?
- Kapsam dışında ne var ve iş ortasında yeni bir şey çıkarsa ne olur?
- “Bitti”yi hangi kabul kriterleri tanımlıyor ve bunları kim test ediyor?
- Verilerimiz ve erişimimiz hakkında neyi varsayıyorsunuz?
- Ekibimizden ne kadar zamana, kimin zamanına ihtiyacınız var?
- Bizim hacmimizde aylık işletme maliyeti ne olacak ve bu hesap neye dayanıyor?
- Sonunda neyin sahibi oluyoruz: kod, promptlar, değerlendirme setleri, dokümantasyon?
- Fiyat bu aşama için sabit mi ve ne değişiklik sayılır?
Teklifler nasıl karşılaştırılabilir hale gelir?
Her aday iş akışı için bir paragraf yazın: dokunduğu sistemler, çalıştığı diller, hacmi ve sahibi. Bu, herhangi bir tedarikçinin ilk tahmin için ihtiyaç duyduğu bilginin büyük kısmıdır ve yanıtları karşılaştırılabilir kılar. Sabit kapsamlı yazılı bir öneri isterseniz iş akışınızı bize anlatın.
Bu notu bir yapay zeka asistanına sorun