Kurumsal LLM projesi ne kadar sürer, neye mal olur?
Alperen
Kurumsal bir LLM projesi fizibilite, pilot ve üretim aşamalarından geçer. Süreyi belirleyen şey , verinin hazır olması ve karar mekanizmasının hızıdır. Maliyet iki kalemdir: bir defalık geliştirme ve aylık işletme. İşletme giderinin büyük kısmı token değil, çoğu projede altyapı ve insan zamanıdır.
Yapay zeka projelerinde bütçe sorusunun net cevap almamasının bir sebebi var: soru genellikle yanlış birimde soruluyor. "Bir chatbot ne kadar tutar" sorusu, "bir bina ne kadar tutar" sorusuyla aynı kesinlikte. Ama maliyetin nereden geldiği ve süreyi neyin belirlediği anlatılabilir. Bu yazı rakam değil, o iki soruya cevap veriyor.
Bir LLM projesi hangi aşamalardan geçer?
| Aşama | Süreyi belirleyen | Çıktı |
|---|---|---|
| Fizibilite | Problemin netliği | Yapılabilir mi, hangi yaklaşımla, hangi risklerle |
| Pilot | Veri kalitesi ve erişim izni | Gerçek veriyle çalışan, dar kapsamlı sürüm |
| Üretim | Entegrasyon ve güvenlik gereksinimleri | Ölçeklenen, izlenen, güvenli sistem |
| İyileştirme | Sürekli | Doğruluk ve maliyet ayarı |
Bu aşamaların toplam süresi kurumdan kuruma değişir ve bu değişkenliğin sebebi teknik değildir. Pratikte en sık gecikme sebebi kurumsaldır: veriye erişim izninin çıkması, yasal onay, ya da paydaşların kapsamda anlaşamaması. Bu üçü hızlı işliyorsa proje hızlı ilerler; işlemiyorsa hiçbir teknik karar bunu telafi etmez.
Maliyet hangi kalemlerden oluşur?
İki ayrı bütçe düşünün: bir defalık geliştirme ve süregelen işletme.
Geliştirme (bir defalık)
Ekip büyüklüğü × süre. Kurumsal bir LLM projesinde küçük ve karma bir ekip yeterlidir: yapay zeka mühendisi, yazılım mühendisi ve kısmi zamanlı bir alan uzmanı. Daha büyük ekip bu tip projelerde hız kazandırmaz; entegrasyon ve karar maliyeti getirir.
İşletme (aylık)
- Model kullanımı: Token başına ücret. Sorgu hacmi ve bağlam uzunluğuyla doğru orantılı.
- Altyapı: Vektör veritabanı, uygulama sunucusu, izleme, yedekleme.
- Bakım: Belge güncelleme akışı, değerlendirme setinin bakımı, model sürüm takibi.
Yaygın bir yanılgı, işletme maliyetinin tamamının token olduğudur. İç kullanıma dönük çoğu sistemde token, aylık giderin küçük kalemidir; asıl maliyet insan zamanı ve altyapıdır. Bu denge dışa dönük ve yüksek hacimli ürünlerde tersine döner; orada token optimizasyonu mimarinin merkezine geçer.
Maliyeti düşürmenin gerçek yolları nelerdir?
- Model yönlendirme. Her soruyu en güçlü modele göndermek gerekmez. Basit soruları küçük modele, karmaşık olanları büyük modele yönlendiren bir katman, kaliteyi belirgin şekilde düşürmeden maliyeti azaltır.
- Önbellekleme. Kurumsal kullanımda sorular tekrar eder. Anlamsal önbellek, aynı sorunun ikinci kez modele gitmesini engeller.
- Bağlam disiplini. Her sorguya on belge göndermek doğruluğu artırmaz; gürültü ekler ve maliyeti katlar. İyi bir yeniden sıralama katmanı hem ucuz hem daha doğrudur.
- İstem uzunluğu. Uzun sistem istemleri her sorguda tekrar ücretlendirilir. İstem önbellekleme desteği olan sağlayıcılarda bu kalem belirgin şekilde düşer.
Bütçelenmeyen ama mutlaka çıkan kalemler
Projelerde en sık atlanan üç kalem:
- Veri temizliği. Doküman arşivleri düzenli değildir: aynı belgenin üç sürümü, taranmış PDF'ler, boş şablonlar. Bu iş kimsenin planına girmez ama her projede çıkar.
- Değerlendirme altyapısı. Sistemin doğruluğunu ölçen test seti, "nice to have" değil temel gerekliliktir. Olmadan iyileştirme yapılamaz.
- Kullanıcı eğitimi ve benimseme. Teknik olarak çalışan ama kimsenin kullanmadığı sistem, başarısız sistemdir. Benimseme çalışması projenin parçasıdır.
Yatırımın karşılığı nasıl ölçülür?
Projeye başlamadan önce tek bir sayı belirleyin ve ölçmeye baştan başlayın. İyi metrikler somut ve mevcut durumla karşılaştırılabilir olanlardır: bir talebin ortalama cevaplanma süresi, bir belgede bilgi arama süresi, manuel işlenen kayıt sayısı.
Kötü metrik "kullanıcı memnuniyeti"dir: geç ölçülür, geç değişir ve neyin işe yaradığını söylemez. Sistem devreye alınmadan önce yapılan bir taban ölçüm, sonradan yapılacak her tartışmayı kısaltır.
Özet
Gerçekçi bir plan şöyle görünür: kısa bir fizibilite, ardından karar. Karar olumluysa dar kapsamlı bir pilot ve ölçülebilir bir sonuç. Sonuç tatmin ediciyse üretim çalışması. Her aşamanın süresi kapsam netleştikten sonra belirlenir. Takvimi bozan tek şey, kapsamın yolda büyümesidir; bunu önlemenin tek yolu ilk günden neyin kapsam dışı olduğunu yazılı hale getirmektir.
Sık sorulan sorular
- Bir LLM projesinin süresini ne belirler?
- Üç şey: kapsamın darlığı, verinin hazır olması ve karar mekanizmasının hızı. Tek bir kullanım senaryosuna odaklanmış dar kapsamlı bir pilot en hızlı çalışan kurgudur. Kapsam görülmeden verilen süre taahhüdü ya kapsamı gizliyordur ya da üretim gereksinimlerini atlıyordur.
- Token maliyeti aylık ne kadar tutar?
- Kullanım hacmine bağlı, ama çoğu kurumsal iç kullanım senaryosunda token maliyeti aylık giderin en küçük kalemidir. Günde birkaç yüz sorgu alan bir iç asistanın model maliyeti, genellikle aynı sistemin altyapı ve bakım maliyetinin altında kalır.
- Neden pilot ile üretim arasında bu kadar fark var?
- Pilot mutlu yolu çalıştırır; üretim geri kalan her şeyi. Erişim kontrolü, hata yönetimi, izleme, maliyet sınırlaması, veri güncelleme akışı, kullanıcı geri bildirimi ve değerlendirme altyapısı pilot aşamasında yoktur. Bu liste tipik olarak pilot kadar zaman alır.
- Kapsam netleşmeden neden fiyat verilmiyor?
- Çünkü yapay zeka projelerinde kapsam keşfedilerek netleşir. Kapsam görülmeden verilen bir bedel ya belirsizliği fiyata risk primi olarak ekler ya da kapsamı sessizce daraltır; iki durumda da bedelini kurum öder. Doğru sıra önce kısa bir fizibilite, sonra kapsama dayalı bir teklif.
Bu konuda çalışıyor musunuz?
Yapay zeka ve entegrasyon projelerinde nereden başlanacağını konuşalım.
İletişime geç