Bir yapay zeka pilotu ne zaman canlıya hazırdır?

Pilot bir soruyu yanıtlar: Bu iş olur mu? Canlı kullanım ise bir söz verir: Sistem gün be gün ve her model güncellemesinden sonra da, işletmenin kabul ettiği bir maliyetle çalışmaya devam edecek; çalışmadığında da adı belli bir kişi bundan sorumlu olacak. Pek çok yapay zeka pilotu ilk soruyu ikna edici biçimde yanıtlar, ama bu sözü veremeden yarıda kalır.

Eksik olan nadiren modeldir. Eksik olan, modelin çevresindeki her şeydir: kimsenin yazıya dökmediği kriterler, kimsenin tasarlamadığı onay adımı, kimsenin öngörmediği fatura, kimsenin sahiplenmediği işletim kılavuzu. Geliştirdiğimiz her sistem canlıya geçmeden önce, iş akışının sahibiyle birlikte sekiz koşulu kontrol ederiz. Biri eksikse sistem bekler. Aşağıda listeyi ve her maddenin neden listede olduğunu bulacaksınız.

İyi pilotlar neden yarıda kalır?

Pilotlar elverişli koşullarda çalışır. Örnekler özenle seçilir, sistemi geliştirenler kullanıcıların yanı başındadır ve herkes ara sıra yapılan hataları “nasılsa pilot” diyerek hoş görür. Canlı kullanım bu üçünü de ortadan kaldırır. Girdiler dağınık ve eksik gelir, geliştirenler başka işlere geçer ve yanlış bir yanıtın ucunda bu kez bir müşteri, bir tutar ya da bir son tarih vardır.

Tıkanma noktaları önceden bellidir:

• Ortak bir “iyi” tanımı yok. Demo etkileyiciydi, ama geniş ölçekte hangi doğruluğun, hızın ya da maliyetin kabul edilebilir olduğu konusunda kimse anlaşmadı.
• Geç kalan incelemeler. Güvenlik, hukuk ve veri koruma ekipleri sistemi canlıya geçişten bir hafta önce görür ve haklı olarak yanıtlanması aylar sürecek sorular sorar.
• Bilinmeyen işletme maliyetleri. Pilottaki kullanım azdı; tam hacimde faturanın ne olacağını kimse hesaplamadı.
• Sahip yok. Pilot ekibi ayrılır ve iş tarafında sistemi nasıl işleteceğini, düzelteceğini ya da geliştireceğini bilen kimse kalmaz.

Bunların her birini pilottan önce çözmek, sonra çözmekten daha ucuzdur. Bu yüzden kontrol listesi pilotun son haftasında değil, ilk gününde başlar.

Kalite: iyi sonuç nasıl tanımlanır?

1. Kabul kriterleri üzerinde anlaşıldı ve yazıya döküldü. Geliştirmeye başlamadan önce süreç sahibi ve ekip, sistemin canlıya geçmek için neyi başarması gerektiğini yazar. İyi kriterler test edilebilir: önerinin uzman kararıyla örtüştüğü vakaların payı, bir yanıt için kabul edilebilecek en uzun bekleme süresi, iş gerekçesinin kaldırabileceği vaka başına maliyet. İyi kriterler, oranı ne olursa olsun kabul edilemeyecek hataları da adıyla belirtir: yanlış bir iade tutarı ya da politikayla çelişen bir tavsiye gibi.

2. Değerlendirme seti gerçek örneklerden oluşturuldu. Kriterlerin neyle test edileceği de belli olmalıdır. Gerçek vakalardan, genellikle birkaç yüz vakalık bir değerlendirme seti oluştururuz; her vakanın yanında bir uzmanın kabul edeceği sonuç yer alır. Vakalar bir demo senaryosundan değil, canlı işten gelir ve zor olanları da içerir: eksik formlar, alışılmadık talepler, doğru yanıtın işi yetkili kişiye aktarmak olduğu vakalar. Setin bir bölümü promptları ayarlamak için hiç kullanılmaz; böylece son test dürüst kalır.

Kontrol: kim neyi görür, kararı kim verir?

3. Veriler sınıflandırıldı ve erişim haritalandı. Sistemin okuduğu her kaynağı, kaynağın neler içerdiğini, nerede işlendiğini ve çıktıyı kimlerin görebileceğini listeleriz. Sistem, kişilere zaten tanımlı yetkileri devralır: Hiç kimseye kendisinin açamayacağı bir belgeyi göstermemelidir. İşleme yerleri ve saklama süreleri, KVKK ve GDPR gerekliliklerine uygun biçimde BT ve uyum ekipleriyle birlikte belirlenir.

4. İnsan onay noktaları tanımlandı. Sistemin yapabileceği her işlem için şunları sorarız: Geri alınabilir mi, maliyet doğurur mu, müşteriye ulaşır mı, ikinci bir göz ister mi? Yanıt bir insanı gerektiriyorsa tasarıma bir onay adımı eklenir ve inceleyen kişi yalnızca öneriyi değil, kanıtı da görür. Sistem bir görevi güvenilir biçimde tamamlayamadığında vaka, o ana kadar toplanan her şeyle birlikte bir insana gider.

5. Prompt enjeksiyonu ve veri sızıntısı testleri geçildi. Bir yapay zeka sistemi başkalarının yazdığı metinleri okur: e-postaları, belgeleri, formları. Bunların bazıları, sistemin yaptığı işi değiştirmeye çalışan talimatlar içerebilir. Canlıya geçmeden önce sistemi kötü niyetli girdilerle deneriz. Örneğin bir belge, sistemden başka müşterilerin verilerini açıklamasını ya da bir onay adımını atlamasını ister; sistemin bunu reddettiğini doğrularız. Bu testler değerlendirme setine eklenir, böylece her değişiklikten sonra yeniden çalıştırılır.

Pilot, bir şeyin mümkün olduğunu kanıtlar. Canlı kullanım ise onun güvenilir, uygun maliyetli ve sahibi belli olduğunu kanıtlar.

Maliyet: fatura gelmeden tutar nasıl öngörülür?

6. Maliyet tavanı ve uyarılar ayarlandı. Pilot sırasında vaka başına toplam maliyeti ölçeriz: model kullanımı, altyapı ve insanların incelemeye harcadığı süre. Bu maliyetin canlı kullanım hacminde ne olacağını hesaplar ve süreç sahibiyle bir tavan üzerinde anlaşırız. Uyarılar tavana gelinmeden çok önce devreye girer. Tasarım, tavana ulaşılırsa ne olacağını da söyler: Bir sonraki faturada sürprizle karşılaşmak yerine rutin vakalar daha küçük bir modele geçer ya da kuyruktaki işler insanları bekler. Hesabın nasıl yapıldığını token maliyetini hata maliyetiyle karşılaştıran notumuzda bulabilirsiniz.

Operasyon: sistem nasıl izlenir, bozulduğunda ne yapılır?

7. İzleme ve regresyon testleri çalışıyor. Canlı kullanımda kalite, kimse sisteme dokunmadan değişebilir: Sağlayıcı bir modeli günceller, bir politika belgesi yenisiyle değiştirilir, yeni bir ürün grubu yeni türde vakalar getirir. Kaliteyi; yanıt süresi, maliyet ve kullanımın yanında, insanların düzenli olarak incelediği bir örneklemle izleriz. Bir modelde, promptta ya da veri kaynağında yapılan her değişiklik, canlıya çıkmadan önce değerlendirme setinin yeniden çalıştırılmasını gerektirir. İnsan müdahalelerinin artması en yararlı erken uyarılardan biridir; diğer sinyalleri canlıya geçişten sonra neyin izleneceğini anlatan notumuzda bulabilirsiniz.

8. İşletim kılavuzu, dokümantasyon ve eğitim teslim edildi. İşletim kılavuzu, bir olay anında sorulacak soruları yanıtlar: Kalite düştüğünde, bir kaynak sistem çöktüğünde, maliyetler fırladığında ya da bir kullanıcı zararlı bir yanıt bildirdiğinde ne yapılır; sistem nasıl geri alınır ve kim aranır? Dokümantasyon promptları, veri akışlarını ve bunların arkasındaki kararları kapsar. Kullanıcılar ve süreç sahipleri rollerine göre eğitim alır; böylece sistemi işletenler onu geliştirebilir de.

Onayı kim verir?

Sistemi geliştiren ekip değil, iş akışının sahibi. Kısa bir canlıya geçiş değerlendirmesinde sekiz koşulun her birini kanıtıyla birlikte gözden geçiririz: değerlendirme sonuçları, erişim haritası, onay tasarımı, test kaydı, maliyet öngörüsü, izleme ekranı ve işletim kılavuzu. Üç olası sonuç vardır: canlıya geçmek, sınırlı kapsamla canlıya geçmek (önce tek bir ekip, kanal ya da vaka türü) veya bir koşul karşılanana kadar beklemek. Karar ve gerekçeleri yazıya dökülür.

Gerçek bir iş akışında bu neye benzer?

Temsili bir örnek ele alalım: Bir finans ekibi için tedarikçi faturalarından ERP kaydı taslakları hazırlayan bir pilot. Kabul kriterleri, bir taslağın muhasebecinin gireceği kayıtla ne sıklıkta örtüşmesi gerektiğini ve yanlış tutarın ya da yanlış tedarikçinin asla kabul edilemeyeceğini söyler. Değerlendirme setinde iade faturaları, elle yapılmış düzeltmeler ve iki dilde düzenlenmiş faturalar dahil birkaç yüz geçmiş fatura vardır. Erişim haritası, sistemin faturaları ve satın alma siparişlerini okuduğunu ama bordroya hiç erişmediğini gösterir. Her kaydı, sisteme işlenmeden önce bir muhasebeci onaylar; sistemin emin olmadığı her şey işaretli gelir. Enjeksiyon testleri arasında, tedarikçinin banka bilgilerinin değiştirilmesini isteyen gizli bir metin taşıyan bir fatura da vardır. Maliyet öngörüsü ortalama bir günü değil, ay sonu yoğunluğunu kapsar. İşletim kılavuzu da ayın son iş gününde ERP çöktüğünde ekibin ne yapacağını anlatır.

Bunların hiçbiri sıra dışı değil. Yalnızca canlıya geçişten sonra fark edilmek yerine önceden yazıya dökülür.

Canlıya geçtikten sonra ne değişir?

İlk haftalar daha sıkı bir incelemeyle geçer: İnsanlar daha büyük bir vaka örneklemini kontrol eder, süreç sahibi ekiple her hafta toplanır. Sayılar korunduğunda inceleme olağan ritmine oturur ve kapsam, bir sistemin tek ekipten birçok ekibe yaygınlaştırılmasında olduğu gibi adım adım genişler. İki iş hiç bitmez: Maliyet kontrolü ve izleme, sistem çalıştığı sürece devam eder.

Yönlendirme komitesinde hangi sekiz soru sorulmalı?

Canlıya geçmeye hazırlanan her yapay zeka pilotu için şu sekiz soruyu sorun:

1. “Yeterince iyi”nin ne demek olduğunu yazıya döktük mü?
2. Test için elimizde, uzmanların onayladığı yanıtlarla gerçek örnekler var mı?
3. Sistemin hangi verileri okuduğunu ve çıktısını kimlerin görebileceğini biliyor muyuz?
4. Bir insanın nerede onay vereceğini ve sistem emin olmadığında ne olacağını biliyor muyuz?
5. Sistemi kandırmayı denedik mi ve sistem dayandı mı?
6. Tam hacimde aylık maliyeti ve tavana ulaşıldığında ne olacağını biliyor muyuz?
7. Canlıya geçtikten sonra kalite düşerse bunu fark edecek miyiz?
8. Bizim tarafımızda, sistemi kötü bir günde nasıl işleteceğini bilen biri var mı?

Bunlardan herhangi birinin yanıtı “henüz değil” ise elinizde canlı bir sistem değil, bir pilot vardır. Herkes hangisine baktığını bildiği sürece bunda bir sakınca yok.