Bir yapay zeka sistemi canlıya alındıktan sonra neler izlenmeli ve kalite neden düşer?

Bir yapay zeka sistemi kabul testlerini geçer, canlıya alınır ve işini yapar. Aylar sonra koduna kimse dokunmamıştır, ama yanıtlar kötüleşmiştir. Bir politika yenisiyle değiştirilmiş, bir ürün grubu eklenmiş, sağlayıcı modeli güncellemiştir. Bunların hiçbiri hiçbir kayıtta hata üretmemiştir.

Canlıdaki bir yapay zeka sisteminin olağan hayatı budur; onu izlemenin sıradan bir yazılımı izlemekten farklı olmasının nedeni de bu. LLM izleme metrikleri dört sinyal ailesini birlikte ele alır: kalite, maliyet, hız ve kullanım. Her biri vaka türüne ve dile göre ayrılır. Artan müdahale oranını (override rate), yani insanların çıktıyı daha sık düzeltmesini ya da reddetmesini de alabileceğiniz en erken uyarı olarak görürsünüz.

Kalite canlıya geçişten sonra neden değişir?

Çünkü sistem yerinde dursa da çevresi hareket eder. Olağan nedenler şunlardır:

• Belgeler güncellenir. Bir politika yeniden yazılır ya da bir fiyat listesi değiştirilir; bilgi erişimi bu kez yeni metni ya da eski ve yeni sürümleri yan yana bulur.
• İş değişir. Yeni ürünler, politikalar ve kanallar, değerlendirme setinde hiç bulunmayan vaka türleri getirir.
• Vaka dağılımı kayar. Ay sonu, kampanyalar ve sezonluk iadeler zor vakaların payını değiştirir; hiçbir şey kötüleşmese bile ortalamalar oynar.
• Sağlayıcı modeli günceller. Aynı adın arkasındaki yeni bir sürüm ya da model değiştirmeye zorlayan bir kullanımdan kaldırma; üslubu, biçimi ve doğruluğu değiştirebilir.
• Girdiyi sağlayan sistemler değişir. Adı değişen bir ERP alanı, yeni bir OCR motoru ya da yeniden tasarlanan bir web formu, modele ulaşan girdiyi değiştirir.

Bunların hiçbiri hata vermez. Sistem akıcı biçimde yanıt vermeyi sürdürür; yalnızca bazı vaka türlerinde daha sık yanılır.

Hangi kalite sinyalleri izlenmeli?

Bunların her birini vaka türüne ve dile göre ayırın. Genel ortalama sabit kalırken tek bir ürün grubu, tek bir kanal ya da Türkçe vakalar giderek kötüleşebilir. Kayma (drift) bu kırılımda görünür hale gelir.

Hangi maliyet ve hız sinyalleri önemlidir?

Maliyet ve kalite, sanıldığından daha sık birlikte hareket eder. Yanıtları uzatan bir model güncellemesi hem faturayı hem inceleme süresini artırır. Bağlam ekleyen bir bilgi erişimi değişikliği, görev başına token sayısını artırırken yanıtları iyileştirebilir. İki tabloyu yan yana okuyun.

Kullanım neyi söyler, neyi söylemez?

Kullanım, sistemin işin bir parçası olup olmadığını söyler: uygun vakaların ne kadarının sistemden geçtiğini, her hafta kaç kişinin sistemi kullandığını, açılıp sonra bir kenara bırakılan taslakları ve bunun yerine eski yolla yürütülen vakaları. Sistemi kullanmayı bırakan bir ekip size geri bildirim veriyordur; hem de çoğu zaman kimse şikayette bulunmadan önce.

Kullanımın söyleyemeyeceği şey, çıktının doğru olup olmadığıdır. Yoğun kullanım düşük kaliteyle bir arada var olabilir; özellikle inceleme bir formaliteye dönüşmüşse. Sıfıra yakın bir müdahale oranı ve saniyeler süren onaylar kutlamayı değil, kontrolü hak eder.

İnsanlar bir örneklemi ne sıklıkla incelemeli?

Her hafta, işin sahibi olan kişiler, değerlendirme setiyle aynı puanlama ölçütünü kullanarak. Örneklemi her vaka türü ve dil içinde rastgele çekin; böylece seyrek ama önemli vakalar her zaman görünür. Buna hedefli örneklemler ekleyin: bir değişiklikten etkilenen vaka türleri, yeni türde vakalar ve sistemin emin olmadığını işaretlediği çıktılar. Canlıya geçişten sonraki ilk haftalarda ve her değişiklikten sonra daha yoğun inceleyin, ardından olağan rutine dönün.

Temsili bir vaka düşünün. Bir distribütörün satış destek asistanı, fiyat ve stok sorularını fiyat listesini kaynak göstererek yanıtlıyor. Finans ekibi bir ürün grubu için yeni fiyat listesini ayrı bir dosya olarak yayımlıyor ve eski dosya kütüphanede kalıyor. Ertesi günden itibaren o ürün grubuyla ilgili bazı yanıtlar geçerliliğini yitirmiş fiyatları gösteriyor. Hiçbir yerde hata çıkmıyor ve genel kalite puanı neredeyse kıpırdamıyor, çünkü bu ürün grubu vakaların küçük bir kısmı. Kıpırdayan, o vaka türündeki müdahale oranı: Satış personeli yanıt vermeden önce fiyatları düzeltiyor. Haftalık örneklem bunu doğruluyor; sorunun kaynağı modelde değil, kütüphanede. Çözüm: eski dosyayı kaldırmak, yeniden dizinlemek, yeni fiyatları değerlendirme setine eklemek ve mükerrer fiyat listeleri için bir kontrol eklemek.

Bu tür bulgular, müdahalelerden beslenen bir geri bildirim döngüsünü anlatan notumuzdaki rutine aktarılmalıdır.

Kayma hata vermez. İnsanların sistemi daha sık düzeltmesiyle kendini gösterir.

Tek ekranlık bir gösterge panelinde neler olmalı?

Beş bölüm yeterlidir:

1. Her aile için ana sayılar. Örneklem kalitesi ve müdahale oranı, görev başına maliyet, en yavaş isteklerin yanıt süresi ve uygun vakaların sistemden geçen payı; her biri kabul aşamasında belirlenen eşikle birlikte.
2. Kırılım. Vaka türüne ve dile göre bir tablo; bir önceki döneme kıyasla değişim büyüklüğüne göre sıralı, böylece en büyük hareket en üstte durur.
3. Değişiklik zaman çizelgesi. Her model, prompt, kaynak ve girdi sistemi değişikliği zaman ekseninde işaretlenir; böylece bir kayma nedeniyle eşleştirilebilir.
4. Açık uyarılar ve her birinin adı belli sahibi. Sahibi olmayan bir uyarı, kimsenin okumadığı bir bildirimdir. Her uyarı kimin bakacağını, ne kadar hızlı bakacağını ve ilk adımın ne olduğunu söyler; ciddi olanlar olay müdahale planını izler.
5. İnceleme durumu. Kaç vakanın örneklemde incelendiği, neler bulunduğu ve hangi düzeltmelerin beklediği.

Ritim, ekran kadar önemlidir: uyarılara her gün kısa bir bakış, süreç sahibiyle haftalık bir gözden geçirme ve üç ayda bir eğilimlere ve bir sonraki iyileştirmeye bakış.

Hangi iki sinyalle başlamalı?

Canlıdaki bir sisteminizde bunların hiçbiri yoksa iki sinyalle başlayın: vaka türüne göre müdahale oranı ve haftalık örneklem incelemesi. İkisi de ucuzdur ve aksi halde önce müşterilerin bulacağı sorunları yakalar. İzleme, canlıya geçmeden önce kontrol ettiğimiz sekiz koşuldan biridir; canlıya geçtikten sonra da izlemeyi yapay zeka güvenilirliği hizmetimiz sürdürür.

Kaynaklar

1. Artificial Intelligence Risk Management Framework (AI RMF 1.0), NIST AI 100-1 ABD Ulusal Standartlar ve Teknoloji Enstitüsü (NIST) nvlpubs.nist.gov/nistpubs/ai/NIST.AI.100-1.pdf