Pilot Arafı: Demo Çalışıyor ama Hiçbir Şey Canlıya Çıkmıyor

Yapay zeka pilotlarının çoğu başarısız olmuyor. Başarısız olsalar işe yarardı, çünkü başarısızlık bir karar üretir. Bunun yerine kararlı bir duruma giriyorlar: demo hâlâ çalışıyor, yönlendirme komitesi hâlâ üç ayda bir toplanıyor, sunumda hâlâ umut verici sonuçlar yazıyor ve ortada ne canlıya çıkış tarihi var, ne adı konmuş bir sahip, ne de bir bütçe kalemi. Biz buna pilot arafı diyoruz ve adını bir kez koyduğunuzda her yerde görmeye başlıyorsunuz. Bu bir teknoloji sorunu değil, nadiren de bir yetenek sorunu. Bir pilotun kanıtladığı şeyle canlı bir sistemin kanıtlamak zorunda olduğu şey arasındaki belirli boşluklar sorunu ve bu boşlukların hepsi öngörülebilir.

Durum kararlı, çünkü kimse bunun bedelini ödemiyor. Pilot, hayatta tutulacak kadar ucuz ve iptal edilmesi vizyonsuzluk gibi görünecek kadar gösterişli. Tedarikçi parasını almış, sponsorun sunacak bir şeyi var ve sistemi işletmek zorunda kalacak operasyon ekibinden henüz hiçbir taahhüt istenmemiş durumda. Bu arada model sağlayıcıları yeni sürümler çıkarıyor, külliyat büyüyor, demoyu yazan insanlar başka işlere geçiyor ve sistem, canlıya çıkmadığı her ay canlıya çıkması biraz daha zorlaşan bir şeye dönüşüyor. Arafın gerçek bir maliyeti var ama o maliyet kimsenin sahiplendiği bir bütçe kalemine hiçbir zaman yazılmıyor.

Altta yatan boşluk şu: pilot, gerçekliğin dost bir diliminde yapılabilirliği kanıtlar; canlı sistem ise düşmanca gerçekliğe karşı güvenilirliği kanıtlamak zorundadır. Yapılabilirlik için seçilmiş bir külliyat, tek kullanıcı, sıfır yetki kuralı ve son tarih olmaması yeterlidir. Güvenilirlik için rastgele bir örneklem, otuz eşzamanlı kullanıcı, gerçekten uygulanan yetkiler, bir gecikme bütçesi, bir maliyet tavanı, nöbet listesi ve geri alma yolu gerekir. Bizim deneyimimizde bu iki durum arasındaki sertleştirme eforu, demoyu üreten mühendisliğin 2,5 ila 4 katıdır. Demo yüzde 80 tamamlanmış gibi kapsamlandırılan projelerin bitiş çizgisi hissi veren yerde takılmasının sebebi tam olarak budur.

İyi haber şu ki bu boşluklar tek tek sayılabilir ve her biri yirminci haftada değil ikinci haftada kapatıldığında çok daha ucuza gelir. Aşağıda, hataların genelde geldiği sırayla üzerinden geçtiğimiz listeyi ve ardından kimse canlı bütçesini serbest bırakmadan önce bir pilotun sağlaması gerektiğini düşündüğümüz çıkış kriterlerini bulacaksınız. Bunu bir deneme yazısı gibi değil bir kontrol listesi gibi okuyun, çünkü değeri erken uygulanmasında. İşin para tarafı da gerekiyorsa harcamanın tüm yapısını yapay zeka projesi gerçekte ne kadar tutar yazımızda ele aldık; pilotun hiç göstermediği işletme gideri de orada.

Gartner Gerçekte Ne Dedi, Ne Demedi

İnsanların birbirine söylediği rakam Gartner'ın Haziran 2025 tarihli basın açıklamasından geliyor. Açıklama, artan maliyetler, belirsiz iş değeri ve yetersiz risk kontrolleri gerekçesiyle agentic AI projelerinin yüzde 40'tan fazlasının 2027 sonuna kadar iptal edileceğini belirtiyor ve 3.400'den fazla katılımcıyla yapılan bir ankete dayanıyor. Belirtilen üç gerekçeyi dikkatle okumakta fayda var, çünkü hiçbiri modelin yetersiz olması değil. Üçü de alıcı ile tedarikçinin birlikte kontrol ettiği şeyler: harcamanın nasıl yönetildiği, değerin en baştan tanımlanıp tanımlanmadığı ve kontrollerin pilot başlamadan önce tasarlanıp tasarlanmadığı. Yani rapor teknolojiyi değil yönetimi işaret ediyor.

Bulgunun ne demediğini görmek de aynı ölçüde önemli. İptal edilmek teknik olarak başarısız olmakla aynı şey değil ve özellikle agentic projelere dair bir öngörü; belge asistanları, erişim sistemleri veya sınıflandırıcılar hakkında bir hüküm değil. Gartner ayrıca kurumsal uygulamaların yüzde 40'ının 2026 sonuna kadar göreve özel yapay zeka ajanları içereceğini, bu oranın 2025'te yüzde 5'in altında olduğunu öngörüyor. İki ifade aynı anda doğru olabilir: dar kapsamlı ve iyi tanımlanmış ajanların yaygınlaşması ile iddialı ve belirsiz olanların yüksek iptal oranı. Bu iki grup arasındaki fark, teknik derinlikten çok kapsam disiplinidir.

Aynı yeri işaret eden bir veri noktası daha taşımaya değer. Bir NVIDIA 2026 anketi, engel olarak katılımcıların yüzde 48'inin veriyle ilgili sorunları, yüzde 38'inin yapay zeka uzmanlığı eksikliğini ve yüzde 30'unun yatırım getirisi netliğinin olmamasını gösterdiğini bildirdi. Veri, insan ve ölçüm; tam olarak bu sırayla. Bu listedeki hiçbir madde farklı bir model seçilerek çözülmüyor ve hiçbiri pilot bittikten sonra da çözülmüyor; üçü de pilotun ilk haftalarında ele alınması gereken şeyler. Yazının geri kalanı, bu üç başlığın gerçek bir projede gerçek bir salı öğleden sonrasında neye benzediği konusunda somut olma denemesidir.

Birinci Hata Biçimi: Demo Verisi ile Canlı Veri Aynı Şey Değil

Pilot, birinin seçtiği bir külliyat üzerinde koştu. Tipik olarak 200 ila 2.000 belge; temiz oldukları, güncel oldukları, ilginç vakaları temsil ettikleri ve kolay ulaşılabildikleri için elle seçilmiş. Canlı sistem ise kimsenin seçmediği 50.000 ila iki milyon belge üzerinde koşar: 2011'de faks çağından kalma bir cihazla alınmış taramalar, aynı poliçenin neredeyse birebir dört sürümü, ikinci bir dildeki belgeler, yürürlükten kalkmış ama hiç işaretlenmemiş olanlar ve üç bölümün de bir diğerine ait sandığı klasör. Bunlar aynı arayüzü giymiş, birbirinden tamamen farklı iki problemdir.

Aradaki değişim ölçülebilir ve somuttur. Tarama kalitesinin dağılımı genişler, dolayısıyla metin çıkarma doğruluğu tek bir sayı olmaktan çıkar. Kopyalar ve yürürlükten kalkmış sürümler aynı erişim slotları için yarışmaya başlar ki bu belgenin hiç bulunamamasından daha kötüdür, çünkü sistem iki yıl önce doğru olan bir belgeden kendinden emin biçimde cevap verir. Çalıştayda kimsenin bahsetmediği belge türleri hacmin yüzde 3 ila 8'i olarak ortaya çıkar. Pilotta tek kullanıcı her şeye erişebildiği için hiç var olmayan yetki sınırları ise birden, belirli bir kişi için hangi belgenin hukuken getirilebileceğini belirleyen ana kısıt hâline gelir.

Etki, projenin güvenilirliğini sarsacak kadar büyük. Bizim deneyimimizde, seçilmiş bir demo diliminde yaklaşık yüzde 90 ölçülen erişim kalitesi, rastgele bir canlı örneklemle ilk karşılaştığında sıklıkla 20 ila 35 puan aşağıya iniyor. Kimse yanlış bir şey yapmış değil; pilot sadece asıl önemli olandan başka bir şeyi ölçmüş oluyor. Ama o rakamın sunulduğu toplantı, umut verici bir pilotun tartışmalı bir pilota dönüştüğü toplantıdır ve genelde bütçe konuşmasından önce değil sonra gerçekleşir; bu da olabilecek en kötü sıralamadır. Aynı ölçümü pilotun ilk haftasında yapsanız, aradaki fark bir kriz değil planlanmış bir veri kalemi olurdu.

Çözüm usule dair ve başlangıçta hiçbir şeye mal olmuyor. Pilot külliyatını seçerek değil rastgele örnekleyerek çekin ve çirkin belgelerin içeri girmesine izin verin. Pilotun doğruluğunu hem bu rastgele örnekleme hem de seçilmiş dilime karşı ayrı ayrı raporlayın ki aradaki fark herkesin gözü önünde olsun ve planlanabilsin. Sonra bu farkı kapatmayı kendi bütçesi olan veri işi olarak ele alın; bunu yapay zeka projesi için veri hazırlığı yazımızda ayrıntılandırdık. Temsil gücü olan veriyle başlayan pilot etkilemekte daha yavaş, canlıya çıkmakta çok daha hızlıdır.

İkinci Hata Biçimi: Demodan Önce Kabul Kriterlerinde Anlaşılmadı

Bir demo değerlendirmesindeki altı kişiye sistemin ne zaman yeterince iyi olacağını sorun; hiçbiri yazılı olmayan altı ayrı cevap alırsınız. Operasyon müdürü zaman kazandırıp kazandırmadığını düşünüyordur. Uyum sorumlusu olabilecek en kötü çıktıyı düşünüyordur. Mühendis erişim isabetini, sponsor ise yönetim kuruluna ne anlatacağını. Önceden hiçbir eşikte anlaşılmadığı için demo izlenime göre değerlendirilir ve izlenim, doğru mühendislikle ulaşabileceğiniz bir durum değildir. Dolayısıyla sonraki her yineleme, odadaki dinleyici değiştikçe yer değiştiren bir hedefe nişan alır ve ekip ilerlediğini kanıtlayamaz. Üç ay sonra aynı sistem hem yeterince iyi hem de yetersiz olarak anılmaya başlar ve iki görüşü de destekleyen hiçbir ölçüm yoktur.

Kabul kriteri, mühendis olmayan birinin kontrol edebileceği, içinde sayı geçen bir cümledir. Örnek: üzerinde anlaşılan 240 soruluk altın veri setinde cevapların en az yüzde 85'i doğru maddeyi kaynak göstermeli; en fazla yüzde 2'si bir denetçinin yakalayamayacağı biçimde kendinden emin şekilde yanlış olabilir; 30 eşzamanlı kullanıcıda p95 yanıt süresi 6 saniyenin altında kalmalı; cevaplanan soru başına maliyet üzerinde anlaşılan tavanı aşmamalı; ve her cevap kullanıcının tek tıkla açabileceği bir kaynak taşımalı. Beş cümle, birinci haftada mutabık kalınmış ve bütçeyi onaylayacak kişiler tarafından imzalanmış olmalı.

Bu cümlelerin siyasi işlevi teknik işlevi kadar önemli. Onlar olmadan yeterince doğru değil ifadesi yanlışlanamaz, dolayısıyla düzeltilemez; onlarla birlikte konuşma bu beş sayıdan hangisi kalıyor ve onu ne oynatır sorusuna dönüşür. Ayrıca pilotu ters yöndeki hatadan da korurlar: belirtilen her kriteri rahatça geçen bir sistemin, biri demoda tek bir kötü cevap bulduğu için reddedilmesi. İki sonuç da aynı bütçeyi harcar, aynı itibarı zedeler ve ikisi de baştan yazılan aynı bir sayfalık belgeyle önlenir. Kriterleri yazmak bir günden az sürer; yazmamanın bedeli ise genelde bir çeyreklik gecikme olarak ödenir.

Kriterleri ilk demodan sonra değil önce ve ortak yazın. Eşikleri tek başına öneren bir tedarikçi sizin risk iştahınızı tahmin ediyordur; tek başına belirleyen bir alıcı ise genelde kullanım senaryosunun değerinin üç katına mal olacak bir doğruluk ister. Pazarlığın kendisi değerlidir, çünkü sistem yanıldığında ne olacağını ve bunun sorumluluğunu kimin taşıyacağını birinin yüksek sesle söylemesini zorunlu kılar. Biz bunu teslimatın değil kapsam belirlemenin parçası sayıyoruz; mekaniği yapay zeka projesinde kapsam nasıl belirlenir yazımızda anlattık. Kriterleri imzalayan kişilerin adlarını da belgenin başına koyun; altı ay sonra eşiği kimin kabul ettiği tartışması bu şekilde hiç başlamaz.

Üçüncü Hata Biçimi: Devirden Sonra Sahip Yok, Entegrasyon Borcu Var

Pilotun bir sponsoru vardır. Canlı sistemin bir sahibi gerekir ve bunlar farklı rollerdir. Sponsor belirli bir dönem için bütçe ve ilgi sağlar; sahip ise kalıcı bir operasyonel yük üstlenir: nöbet listesi, bir iş listesi, aylık bir maliyet kalemi, sistem müşteriye yanlış bir şey söylediğinde doğrudan sorumluluk ve her yıl bunu ödemeye devam edip etmeme tartışması. Pilot arafında sponsor vardır, sahip yoktur; bu yüzden her teknik kutu işaretlense bile proje bir adım ileri gidemez. Kimse açıkça reddetmiyordur; sadece bunun işi olduğu kimse yoktur ve kimse gönüllü olmaz.

Bu hatanın diğer yarısı entegrasyon borcudur. Pilot, birinin her cuma bir klasöre bıraktığı CSV dışa aktarımını okuyordu. Canlı sistemde kimlik doğrulamalı, artımlı senkronizasyonlu, yetki taşıyan, yeniden deneme yapan ve üst sistem bakımdayken ne yapacağı tanımlanmış canlı bir bağlayıcı gerekir. Planlama rakamı olarak bu sistem başına 3 ila 6 kişi-haftadır ve normalde dokuzuncu hafta civarında, yani demo takvim beklentisini çoktan oluşturduktan sonra keşfedilir. İşin içine girdiği sonradan anlaşılan üç dört sistemle çarpın; geriye kalan iş, o güne kadar yapılan her şeyi rahatlıkla aşar.

İkisini de önlemek ucuz. Canlı sistemin sahibini pilot başlamadan önce pilot beratında adıyla yazın ve bütçe kalemini sponsorun değil onun altına koyun. Sonra bağlayıcılardan tam olarak birini pilot bittikten sonra değil pilot sırasında, hem de en kolay sistemi değil en zahmetlisini seçerek gerçekten yazın. Pilot demoda daha az parlak görünecek ama geriye kalan her şey için gerçekçi bir tahmin taşıyacaktır. Bu takas neredeyse her zaman yapmaya değer, çünkü sahibi olan biraz daha az etkileyici bir demo canlıya çıkar, sahibi olmayan muhteşem bir demo hiçbir zaman çıkmaz.

Dördüncü Hata Biçimi: Değerlendirme Altyapısı Yok, Değişikliğin Güvenli Olduğu Kanıtlanamıyor

Er ya da geç sizin seçmediğiniz bir şey değişir. Sağlayıcı üzerine inşa ettiğiniz model sürümünü kullanımdan kaldırır, bir kütüphane varsayılanını değiştirir, külliyatınız üçte bir büyür ya da biri tek bir şikâyeti gidermek için promptu düzenler. Değerlendirme altyapısı olmadan kötüleşti mi sorusuna verilebilecek tek cevap, birinin birkaç sorguya dair hatırasıdır. Hiçbir risk komitesi bunun üzerine canlı sürüm onayı vermez ve gayet haklı olarak vermez. Çalışan bir pilotu kalıcı bir pilota çeviren mekanizma tam olarak bu eksikliktir ve genelde en son fark edilir.

Somut olarak bu altyapı beş şeydir. Üzerinde anlaşılmış doğru cevaplarıyla 150 ila 300 gerçek maddeden oluşan bir altın veri seti. Cevap kalitesinden ayrı puanlanan erişim metrikleri; böylece sistemin belgeyi bulamadığını mı yoksa bulup kötü akıl yürüttüğünü mü ayırt edebilirsiniz. Ekipten herkesin tetikleyebildiği ve her değişiklikten önce koşulacak kadar hızlı biten otomatik bir regresyon koşusu. Kalite puanlarının yanında maliyet ve gecikme üzerine iddialar. Ve kimse rakamları görmeden önce bir insanın onayladığı bir puanlama rubriği. Orta ölçekli bir sistemde ilk kurulum tipik olarak 4 ila 8 kişi-haftadır.

Kurumsal etkisi mühendislik etkisinden büyüktür. Altyapı bir tartışmayı bir sayıya çevirir ve bir sayı imzalanabilir. Uyum birimine sistemin zor vakalarda tam olarak nasıl davrandığını gösterebilirsiniz ve iki haftalık ayrı bir değerlendirme projesi planlamak yerine model yükseltmesini salı günü kabul edip geçebilirsiniz. Tedarikçi ilişkisini de değiştirir, çünkü iki taraf artık geçen hafta en yüksek sesle şikâyet eden kişinin topladığı anekdotlar üzerinden değil, aynı skor tablosu üzerinden konuşmak zorunda kalır. Sözleşmeye altyapının çıktısının müşteriye ait olduğunu yazdırmak, tedarikçi değiştirseniz bile ölçüm sürekliliğini korur ve ikinci tedarikçiyle aynı zemine oturmanızı sağlar.

Bir pilotun bu altyapısı yoksa, canlı bütçesi istemeden önce eklenecek en değerli şey, önerilen herhangi bir doğruluk iyileştirmesinden önce budur. Başkasının kurduğu bir sistemi devraldığınızda da ilk isteyeceğiniz belge budur, çünkü yokluğu size ne kadar ölçülmemiş risk devraldığınızı kabaca söyler. Metrik seçimlerini, altın veri seti kurgusunu ve test ettiğiniz modelle puanlama yapma tuzağını yapay zeka sistemlerini değerlendirme yazımızda ele aldık. Pratik bir başlangıç kuralı: altın veri setinin en az üçte biri, sistemin cevap vermemesi gereken sorulardan oluşsun. Kapsam dışı soruyu reddetme davranışı da en az doğru cevap üretmek kadar ölçülmesi gereken bir yetenektir ve pilotlarda neredeyse hiç ölçülmez.

Beşinci Hata Biçimi: Gecikme ve Maliyet Ancak Gerçek Hacimde Görünür

Pilot, günde belki 50 sorgu koşan, genelde öğleden sonra çalışan ve genelde kısa sorular soran tek bir hevesli kullanıcıdır. Canlı sistem ise dalgalar hâlinde gelen günde 5.000 sorgudur; pazartesi sabahı aynı on dakika içinde otuz kişi giriş yapar, daha büyük bir indekse karşı daha uzun sorular sorar ve birkaçı aynı anda belge yükler. Pilotta bunların hiçbiri ölçülmediği için pilot bunların hiçbirini öngörmez. Bu, en son gelen ve en çok acıtan hata biçimidir, çünkü canlıya çıkıştan önce değil sonra ortaya çıkar ve düzeltmesi en pahalı andır.

Gecikme, tek kullanıcıda hiç görünmeyen biçimlerde bozulur. p95'te 2 ila 4 saniyede cevap veren bir demo; embedding çağrıları toplu yapılmıyorsa, tekrar eden sorguların önünde önbellek yoksa ve istekler makul bir geri basınç politikasıyla kuyruklanmıyorsa gerçek eşzamanlılıkta 3 ila 5 kat yukarı çıkabilir. İlk 50 adayın yeniden sıralanması tek başına kabaca 100 ila 400 milisaniye ekler; bu kalite için iyi bir takas ama kimse bütçelemediyse kötü bir sürprizdir. Kullanıcılar on beş saniye süren bir aracı, doğruluğu ne olursa olsun ikinci haftada terk eder.

Maliyet kabaca hacimle aynı katsayıda artar ama birim rakam da yükselir, çünkü canlı promptlar pilot promptlarından uzundur. Daha fazla getirilmiş bağlam, daha uzun konuşma geçmişi, uç vakalardan biriken daha fazla sistem talimatı. Biz token başına değil tamamlanmış iş başına maliyet planlıyor, bunu pilotta gerçekçi prompt uzunluklarıyla ölçüyor, sonra dürüst hacimle çarpıp bağlamın her zaman gerçekleşen büyümesi için ayrıca pay ekliyoruz. Yuvarlama hatası kadar tutan bir pilot, kimsenin talep etmediği bir onay basamağı gerektiren aylık bir kaleme dönüşebilir. Model yönlendirme, önbellekleme ve daha küçük modellere düşürme gibi tedbirleri canlıda değil pilot sırasında ölçüp planlayın.

Çözüm, pilot sırasında beklenen tepe eşzamanlılığın üç katında yük testi yapmak, ortalama değil p95 kaydetmek ve aylık maliyet tavanını ilk faturadan sonra değil canlıya çıkıştan önce uyarıyla birlikte devreye almaktır. Her iki rakamı da kabul kriterlerine koyun ki gözlem değil kapı olsunlar. Sonra bunları iş gerekçesine taşıyın, çünkü iş başına belirli bir maliyette yapmaya değen bir sistem, o maliyetin dört katında değmeyebilir; bunu dürüst tutma yöntemini yapay zeka yatırım getirisini ölçmek yazımızda anlattık. Yük testini gerçek promptlarla koşun; sentetik kısa sorularla yapılan test, canlıda göreceğiniz gecikmeyi sistematik olarak iyimser gösterir ve kimseyi hazırlamaz.

Altıncı Hata Biçimi: Güvenlik ve Yetki İncelemesi En Sona Kalıyor

Pilot, her şeyi okuyabilen bir servis hesabıyla, bir klasörün kopyası üzerinde, bir dizüstünde veya bir deneme ortamında koştu. Kimse yetkileri sormadı, çünkü tek bir kullanıcı vardı ve o kullanıcının hepsini görme hakkı vardı. Sonra proje canlıya yaklaşıyor, bilgi güvenliği ilk kez davet ediliyor ve sorular başlıyor. Soruların hepsi tek tek makul. Aynı zamanda hepsi birlikte, planda hiç yer almamış ve planın en az esnekliğinin kaldığı anda gelen birkaç haftalık iş demek; bu yüzden makul sorular kriz gibi hissettiriyor. Bilgi güvenliği ekibi geciktirici değildir; sadece kendisine ilk kez en yanlış anda soruluyordur ve elinde tasarımı etkileyecek zaman kalmamıştır.

İnceleme şunları soracak: sorgu anında kimin yetkileri geçerli ve sistem bunu nasıl kanıtlıyor, ne kaydediliyor, ne kadar saklanıyor, veri fiziksel olarak nereye gidiyor ve hangi alt işleyiciler dokunuyor, kullanıcı prompta gizli bir metin yapıştırdığında ne oluyor, getirilen bir belgenin içinde modele yönelik talimatlar varsa sistem nasıl davranıyor ve kayıtları kim görebiliyor. 6698 sayılı Kanun'da aydınlatma yükümlülüğünü düzenleyen 10. madde ile veri güvenliğine ilişkin 12. madde bu cevaplarla doğrudan ilgilidir ve baştan tasarlamak, sonradan uydurmaktan çok daha ucuza gelir. Bu soruların cevaplarını bir sayfada toplayıp pilot beratının ekine koymak, incelemenin süresini haftalardan saatlere indirir.

Bizim deneyimimizde dokuzuncu haftada gelen bir güvenlik incelemesi 3 ila 6 kişi-haftalık mühendislik ve onaylar için iki ila dört haftalık takvim ekliyor; ara sıra da bir mimari tercihi tamamen geçersiz kılıyor, örneğin belge bazlı erişim kontrolü olmadan kurulmuş bir indeks gibi. Çözüm, ikinci haftada bir sayfalık mimari şema, veri akışları listesi ve adı konmuş bir denetçiyle bir saatlik inceleme yapmaktır. Neredeyse hiçbir şeye mal olmaz ve pahalı keşfi, tasarımı değiştirmenin hâlâ ucuz olduğu noktaya taşır; bu deseni yapay zeka ve veri gizliliği yazımızda daha ayrıntılı anlattık.

Bir Pilotun Canlı Bütçesini Hak Etmesi İçin Geçmesi Gereken Çıkış Kriterleri

Uygulayacağımız kapı şu ve bilinçli olarak hiç romantik değil. Bir, 150 ila 300 maddelik bir altın veri seti ve bütçeyi onaylayan kişilerce yazılı olarak mutabık kalınmış eşiklerle bir değerlendirme altyapısı mevcut. İki, doğruluk seçilmiş bir dilime karşı değil canlı külliyattan rastgele bir örnekleme karşı raporlanıyor ve iki rakam yan yana gösteriliyor. Üç, bütçe kalemi ve nöbet düzeni olan, adı konmuş bir canlı sistem sahibi var. Dört, en az bir gerçek entegrasyon dosya aktarımıyla taklit edilmiyor, gerçekten canlı çalışıyor. Beş, p95 gecikme beklenen tepe eşzamanlılığın üç katında ölçülmüş durumda.

Altı, tamamlanmış iş başına maliyet canlı prompt uzunluklarıyla ölçülmüş, aylık tavan ve uyarı kurulmuş. Yedi, yetki modeli en az ayrıcalıklı bir hesapla ve kullanıcının açamayacağı belgelere ulaşmayı deneyen bilinçli olarak düşmanca bir sorgu setiyle test edilmiş. Sekiz, geri alma yolu var: önceki prompt, indeks ve model sürümü, orijinal yazarı olmayan biri tarafından otuz dakikanın altında geri yüklenebiliyor. Dokuz, olay müdahale kılavuzu bir nöbetçi sahibi adlandırıyor ve bir acil durdurma mekanizmasını belgeliyor. On, kayıt ve saklama süreleri ilgili KVKK yükümlülüklerine karşı gözden geçirilmiş durumda.

Bunu bir kapı olarak yazmanın anlamı, bir pilotun bu kapıdan geçememesine izin verilmesidir. Pilot geçemiyorsa dürüst sonuçlar ya belirli bir boşluğu fonlamak ya da durmaktır ve ikisi de bir çeyrek daha umut verici sonuçtan iyidir. Bir alışkanlık daha ekleyelim: sistemin insanların yanında cevap verdiği ama cevaplarına göre işlem yapılmadığı üç ila dört haftalık bir gölge dönem koşun ve iki tarafı karşılaştırın. Elde edilebilecek en ucuz canlı seviye kanıt budur. Canlı sürümü kimin geliştireceğini de değerlendiriyorsanız sorulacak sorular yapay zeka geliştirme tedarikçisi nasıl seçilir yazımızda toplu hâlde duruyor.

Pilotları Mezun Olabilsinler Diye Nasıl Yürütüyoruz

Pilotlarımız ilk iki haftada sıkıcı, son iki haftada inandırıcı olacak şekilde tasarlanır. Külliyatı rastgele örnekleyerek çekeriz ve seçilmiş dilime göre oluşan doğruluk farkını saklamak yerine açıkça gösteririz. Altın veri setini sizin konu uzmanlarınız için değil onlarla birlikte kurarız, çünkü mühendislerin yazdığı bir set yalnızca mühendislerin varsaydığı şeyi ölçer. Kabul kriterlerini ilk demodan önce yazar ve rakamları demonun kendisiyle aynı sayfaya koyarız. Ve bağlayıcılardan birini pilot sırasında, en dost sistemi değil en zahmetlisini seçerek gerçekten yazarız. Güvenlik incelemesini de ikinci haftaya alırız, çünkü mimariyi değiştirmenin ucuz olduğu tek zaman aralığı orasıdır.

Cevabın geliştirmemek olduğu dalı da açıkça söylemeye çalışıyoruz. Yetenek bir emtiaysa, hacim düşükse ve piyasadaki bir ürün bunu kabul edilebilir biçimde zaten yapıyorsa, bu sonuca varmanın pahalı yolu bir pilot, ucuz yolu iki haftalık bir ürün değerlendirmesidir. Bu kararı yapay zekada satın al mı geliştir mi yazımızda düzgünce ele aldık. Pilot, herkes öyle yaptığı için atılan varsayılan ilk adım değil, bir satın almanın çözemeyeceği bir sorunun cevabı olmalıdır. Pilot bütçesini onaylamadan önce sorulacak en ucuz soru şudur: bu yeteneği hazır alsak, gerçekten neyi kaybederdik?

caseon.ai, DiligenceAI, SYDhub ve VinçTakip boyunca tutarlı desen şuydu: demo ile canlı arasındaki iş, demodan önceki işten büyüktü ve bu oranı en baştan hesaba katan projeler canlıya çıkabildi. Pilotunuz iki çeyrektir umut verici görünüyorsa, yararlı bir sonraki adım genelde başka bir model denemesi değil çıkış kriteri değerlendirmesidir. özel yazılım geliştirme ekibimiz bu değerlendirmeyi sabit kapsamlı bir çalışma olarak yürütüyor; kararın daha geniş bağlamı ise işletmeler için yapay zeka yazımızda duruyor. Değerlendirmenin çıktısı her zaman aynı biçimdedir: geçilen kriterler, kalınan kriterler ve her biri için kaç kişi-haftalık iş gerektiği. Bu listeyle başka bir tedarikçiye gitmeniz de bizim açımızdan sorun değildir.