Bir dil modeline soru sordurup etkileyici bir demo çıkarmak bir günlük iş. Aynı sistemin her gün yüzlerce kullanıcıya tutarlı ve maliyeti öngörülebilir cevap vermesi bambaşka bir mühendislik işi. Aradaki farkı yaratan beş şey.
Son iki yılda yapay zeka demosu görmeyen yönetici kalmadı. Toplantıda ekrana yansıtılan sistem soruyu anlıyor, düzgün cevap veriyor, herkes etkileniyor. Sonra proje başlıyor ve aylar sonra aynı sistem ya hiç yayına çıkmıyor ya da çıktıktan kısa süre sonra kimse kullanmıyor.
Sebep genelde modelin yetersizliği değil. Demoyu üretimden ayıran beş mesele var ve hiçbiri "hangi modeli seçelim" sorusuyla ilgili değil.
1. Demo mutlu senaryoyu gösterir
Sunumda sorulan sorular, sistemin cevaplayabildiği sorulardır. Gerçek kullanıcı ise ilk gün beklenmedik bir şey sorar: yarım cümle, yazım hatası, sistemin hiç bilmediği bir konu, hatta bilerek sınırı zorlayan bir soru.
Üretime çıkacak bir sistemin tasarımında asıl emek, bilmediği durumda ne yapacağına harcanır. "Bilmiyorum" diyebilmek, uydurmaktan çok daha zor bir yetenektir ve tasarımla kazandırılır.
2. Maliyet kimse hesaplamaz
Demoda otuz soru sorulur, maliyeti kuruş mertebesindedir. Aynı sistem günde binlerce soru aldığında tablo değişir — özellikle her soruda uzun bir bağlam gönderiliyorsa.
Bunu kontrol altına almanın yolları var: sık sorulanları önbelleğe almak, kolay soruları küçük ve ucuz bir modele yönlendirmek, gönderilen bağlamı gerçekten gereken parçayla sınırlamak. Doğru kurgulanmış bir sistemde maliyeti kayda değer oranda düşürmek mümkün — ama bunun proje başında düşünülmesi gerekir.
Yapay zeka projelerinde en sık atlanan kalem, kullanım başına maliyetin ölçülmesidir. Ölçmediğiniz gideri yönetemezsiniz.
3. RAG'da asıl iş model seçimi değil
Kendi verinizle konuşan bir sistem kuruyorsanız (RAG mimarisi), sonucun kalitesini belirleyen şey model değil, belgelerinizin nasıl parçalandığı ve nasıl arandığıdır.
Bir sözleşmeyi ortasından kesen kötü bir parçalama, en iyi modeli bile işe yaramaz hale getirir; çünkü model kendisine verilmeyen bilgiyi bilemez. Tablo içeren PDF'ler, taranmış belgeler ve çok başlıklı yönetmelikler bu konuda ayrı ayrı ilgi ister.
Pratikte projelerin bu aşamasına ayrılan zaman, model tarafına ayrılandan kat kat fazla oluyor — ve olması gereken de bu.
4. Yanlış cevabın bedeli her yerde aynı değil
Yapay zekanın hata yapacağını kabul etmek gerekiyor; soru şu: hata olduğunda ne oluyor?
- Düşük riskli: Uzun bir raporun özeti biraz eksik çıkar. Kullanıcı fark eder, kaynağa bakar. Kabul edilebilir.
- Orta riskli: Müşteri sorusuna eksik cevap verilir. İnsan onayı katmanıyla yönetilebilir.
- Yüksek riskli: Resmî bir bildirimde tutar hesaplanır. Burada model karar verici değil, olsa olsa yardımcı olabilir.
Sistemi kurarken bu üçünü ayırıyor, yüksek riskli adımlara insan onayı koyuyoruz. Riski yok saymak yerine sınırlamak, projenin yayında kalmasını sağlayan şey.
5. En işe yarayan kullanımlar gösterişli olmaz
Yönetim toplantısında en çok ilgi çeken fikir genelde "her şeyi bilen bir asistan" olur. Oysa ölçülebilir kazanç neredeyse her zaman sıkıcı işlerden gelir:
- Gelen e-postaların otomatik sınıflandırılması ve doğru ekibe yönlendirilmesi
- Faturalardan ve irsaliyelerden veri çıkarımı (OCR + doğrulama)
- Uzun teknik raporların yönetici özetine indirgenmesi
- Müşteri sorularının ilk kademede yanıtlanması, gerektiğinde insana devri
Bunların hiçbiri sunumda alkış almaz ama haftada saatler kazandırır ve kazancı sayıyla gösterilebilir. Yapay zeka yatırımını sürdürülebilir kılan da bu ölçülebilirlik.
Nereden başlamalı
Önerimiz genelde şu: tek bir dar süreç seçin, onun için ölçülebilir bir hedef koyun ("gelen taleplerin yüzde altmışı ilk temasta çözülsün" gibi) ve iki üç hafta içinde üretime çıkarın. Çalıştığını gördükten sonra genişletmek kolay; büyük bir vaatle başlayıp altı ay sonra hiçbir şey yayınlayamamak ise en sık rastladığımız senaryo.
Bu sitede sağ altta duran asistan da bizim kurduğumuz canlı bir örnek — hız sınırı, kimlik tanımı ve hata yönetimiyle birlikte çalışıyor. Yapay zeka hizmetimize göz atabilir veya bize yazabilirsiniz.
