Yapay Zekâ Prototipini Üretim Sistemine Taşırken Ne Değişir?

Bir hafta sonunda yazılan demo çalışır. Ekip toplantıda görür, yönetim ikna olur, karar verilir: bunu yayına alalım.

Üç ay sonra özellik hâlâ yayında değildir ve kimse tam olarak neyin bu kadar uzun sürdüğünü anlatamaz. Kod ortadadır, model aynıdır, çalıştığı da görülmüştür.

Aradaki farkı anlamanın en iyi yolu, prototipin sessizce yaptığı varsayımları saymaktır. Demo bir soruyu cevaplar: bu iş yapılabilir mi? Üretim başka bir soruyu cevaplamak zorundadır: kötü günde ne oluyor?

Demo neyi kanıtlar, neyi kanıtlamaz?

Bir prototip, en iyi durumun mümkün olduğunu gösterir. Değerli bir bilgidir — mümkün olmadığını erkenden öğrenmek daha pahalıya mal olurdu.

Ancak prototip, bir dağılım hakkında hiçbir şey söylemez. Yirmi örnekte çalışan bir özelliğin yirmi binde ne yapacağı, aynı türden bir bilgi değildir. Üretimde önemli olan da ortalama değil, kuyruktur: nadir ama kötü sonuçlar.

Aşağıdaki dört varsayım, demo sırasında farkına varılmadan yapılır ve maliyetleri hep sonradan çıkar.

Varsayım 1: Kullanıcı sizsiniz

Demoyu, özelliğin ne yapması gerektiğini bilen kişi kullandı. Ne yazacağını biliyordu, nereye kadar zorlayacağını biliyordu ve çıktı tuhaf geldiğinde bunu bir hata olarak değil bir ayar meselesi olarak gördü.

Gerçek kullanıcı bunların hiçbirini bilmiyor. Tek kelime yazıyor. Soruyu yarım bırakıyor. Özelliği tasarlanan işin dışında bir iş için kullanmayı deniyor — ve çoğu zaman haklı bir sezgiyle, çünkü arayüz ona sınırını söylemedi.

Buradaki fark bir kullanıcı eğitimi sorunu değildir. Prototipin ölçtüğü şey, en iyi girdiyle en iyi çıktıydı. Üretimin karşılaşacağı şey, girdi kalitesinin bütün bir yelpazesi. Yayına almadan önce yapılacak en ucuz iş, gerçek kullanıcıların ilk otuz denemesini toplamak ve demoda hiç denenmemiş girdi biçimlerini görmektir.

Varsayım 2: Girdi temiz gelir

Prototipte kullanılan örnekler seçilmiştir. Seçilmedikleri iddia edilse bile seçilmişlerdir; çünkü çalışmayanlar sessizce elenmiştir.

Üretimde gelen şey ise şudur: boş belge, dört yüz sayfalık belge, taranmış ve metin katmanı olmayan PDF, yanlış dilde metin, iki dilin karıştığı metin, tablo olarak biçimlendirilmiş veri, kopyala-yapıştır sırasında bozulmuş karakterler.

Bunların çoğu bir hata vermez — daha kötüsünü yapar, makul görünen bir çıktı üretir. Boş bir belgeden üretilen özet de akıcıdır. Sistemin "bu girdiyle çalışamam" diyebilmesi, doğru cevap verebilmesi kadar önemlidir ve prototipte hiç gerekmediği için hiç yazılmamıştır.

Varsayım 3: Sağlayıcı hep ayakta ve hep aynı

Demo sırasında sağlayıcı çalışıyordu, hızlıydı ve her seferinde cevap verdi. Üç şey bu varsayımı bozar.

Kesinti ve limitler. Sağlayıcı bir süreliğine cevap vermeyebilir veya hız limitine takılabilirsiniz. Asıl soru teknik değil ürün sorusudur: o anda kullanıcı ne görüyor? Kuyruğa alınıp sonra mı haber veriliyor, yoksa özellik geçici olarak kapanıp iş eski yöntemle mi yürüyor? Cevap verilmezse ortaya çıkan davranış, sonsuza kadar dönen bir bekleme göstergesi olur.

Gecikmenin kuyruğu. Demoda cevap birkaç saniyede geldi. Üretimde bazı çağrılar çok daha uzun sürer. Zaman aşımı süresi, yeniden deneme sayısı ve yeniden denemenin maliyeti — çünkü her deneme ayrıca ücretlendirilir — baştan kararlaştırılmadığında bunlar ilk yoğun günde kendiliğinden ve kötü biçimde kararlaştırılır.

Zeminin kayması. Geleneksel yazılımda bir bağımlılık siz güncellemedikçe değişmez. Model tabanlı bir özellikte, altınızdaki sürüm değiştiğinde aynı kod farklı çıktı üretebilir; kullandığınız sürümün emeklilik takvimi de sizin planınıza sorulmadan işler. Bu yüzden sürümün açıkça sabitlenmesi ve değişiklikten önce karşılaştırma yapılabilecek bir örnek setinin bulunması gerekir. O set yoksa, "eskiden daha iyiydi" bir izlenim olarak kalır ve tartışılamaz.

Varsayım 4: Çıktının başında biri var

Prototipi çalıştıran kişi her çıktıyı gördü. Üretimde özellik, kimse bakmadan çalışır — ve bu, en pahalı varsayımdır.

Bakmayan bir sistemde üç şeyin kendi kendine haber vermesi gerekir.

Kalite. Klasik izleme, hata ve yanıt süresi ölçer; ikisi de normal görünürken çıktı kalitesi düşebilir. Bunu yakalamanın pratik yolu, gerçek kullanımdan derlenen küçük bir değerlendirme setini düzenli çalıştırmak ve kullanıcının davranışını sinyal olarak saymaktır: kaç kez düzeltildi, kaç kez yok sayıldı, kaç kez elle baştan yapıldı.

Maliyet. Kimsenin bakmadığı bir sistemde harcama da izlenmez. Bir üst sınır ve o sınıra yaklaşıldığında bir uyarı, faturanın sürpriz olmasını engelleyen tek mekanizmadır.

Kayıt. Bir sonucun neden öyle çıktığı sonradan sorulduğunda cevap verebilmek için girdinin, sürümün ve çıktının kaydedilmiş olması gerekir. Bu kayıtların içeriği aynı zamanda bir veri kararıdır; ne kadar tutulacağı ve kimin göreceği, LLM entegrasyonlarında veri güvenliği tarafında ayrıca ele alınmalıdır.

Özellik yayına girdiğinde iş de değişir

Dört varsayımın hepsi teknikti. Beşinci fark teknik değildir ve genellikle en geç görülenidir: özellik yayına girdiğinde, etrafındaki iş de ona göre yeniden şekillenir.

Ekip bir süre sonra eski adımı yapmayı bırakır. Elle yapılan kontrol seyrekleşir, o işi bilen kişi başka bir role kayar ve altı ay sonra özelliği kapatmak, açmaktan çok daha pahalı hâle gelir. Bu, dijital dönüşümün yalnızca yazılım satın almak olmadığı tespitinin küçük ölçekli hâlidir.

Pratik sonucu şudur: kapatma yolu, henüz ucuzken tanımlanmalıdır. Özellik devre dışı bırakıldığında işin nasıl yürüyeceği tek cümleyle yazılabiliyorsa, hem sağlayıcı kesintisi hem kalite düşüşü yönetilebilir birer olaydır. Yazılamıyorsa, geçici bir aksaklık doğrudan işin durmasına dönüşür.

Prototip kodu üretim kodu değildir

Geçişte tekrar eden bir tartışma vardır: mevcut kod üzerine mi devam edilsin, yoksa baştan mı yazılsın?

Prototipin değeri kodunda değil, öğrettiği şeydedir — hangi yaklaşımın işe yaradığı, hangi girdilerin zorladığı, çıktının nasıl görünmesi gerektiği. O bilgi taşındıktan sonra kodun kendisi çoğu zaman ucuzdur.

Asıl risk, prototip kodunun karar verilmeden üretime kalmasıdır: kimse "bunu böyle bırakıyoruz" demez, yalnızca kimse değiştirmez. Bu, teknik borcun iş problemine dönüşmesinin en tipik başlangıcıdır ve önlenmesi, tek bir açık kararla mümkündür.

Yayına almak bir an değil, bir eğri

Bu varsayımların hepsini masa başında çözmeye çalışmak gereksiz ve yavaştır. Daha ucuz yol, açılışı kademelendirmektir.

Önce iç ekip kullanır; girdi çeşitliliği sınırlıdır ama en bariz kırılmalar burada çıkar. Sonra kullanıcıların küçük bir bölümü açılır ve gerçek dağılım görünür. Ardından kapsam genişletilir.

İlk dönemde denetimin sıkı tutulması, sonradan gevşetmenin veri toplamasını sağlar — bu, insan denetiminin kademelendirilmesindeki aynı mantıktır. Bu sırayla ilerlemenin asıl faydası, hataların küçük bir kitleye ve geri alınabilir bir ölçekte denk gelmesidir.

Sonuç

Prototiple üretim arasındaki mesafe, çoğu ekibin sandığı gibi bir tamamlama işi değildir. Demo en iyi durumu kanıtlar; üretim ise kötü durumu yönetmek zorundadır — ve bu iş, ayrı bir iştir.

Bu mesafeyi kısaltmanın yolu daha uzun bir prototip aşaması değil, varsayımları erken açığa çıkarmaktır: girdi gerçekte nasıl geliyor, sağlayıcı sustuğunda ne oluyor, kalite düştüğünde kim fark ediyor. Bu üç soru cevaplandığında geriye kalan iş öngörülebilir hâle gelir.

Yapay zekâ entegrasyonu çalışmalarımızda prototip aşaması, bu soruların cevabını ürettiği ölçüde başarılı sayılır — çalıştığını göstermesi tek başına yeterli değildir.