Copilot'tan pilot proje için dört cümlelik bir durum güncellemesi istiyorsunuz. Akıcı paragrafın içinde "Bütçe onaylandı ve yedek sorumlu Jordan Lee" ifadesi yer alıyor. Verdiğiniz belge bu iki iddiayı da içermiyor. Güncellemeyi e-postaya yapıştırırsanız uydurulmuş bilgiler sizin adınızla gönderilir.
Doğrulamayı görevin içine yerleştirin
Copilot metin üretir ve sonucun sorumluluğunu size bırakır. Microsoft, büyük dil modellerinin taraflı, zararlı veya yanlış içerik üretebileceğini belirtiyor. Bu yüzden harekete geçmeden önce inceleme ve doğrulama gerekir. Süreci dört adımda düşünün: prompt → yanıt → kanıt kontrolü → insan kararı. Yanıt bir taslaktır. Kanıt kontrolü hangi iddiaları kullanabileceğinizi gösterir, insan da sonucun amaca uygun olup olmadığına karar verir.
Copilot'a "Emin misin?" diye sormak doğrulama değildir. Kendinden emin ikinci yanıt da aynı sistemin ürettiği yeni bir metindir. Önemli her iddiayı, kendiniz açıp inceleyebildiğiniz bir kaynakla karşılaştırın. Bu, Sorumlu Yapay Zeka İlkelerini Uygulamak dersindeki güvenilirlik ve emniyet kontrolünün kanıta odaklanan hâlidir. Şimdi aynı kontrolü tek bir yanıta, sağlayıcının belgelerine ve dağıtabileceğiniz bir sisteme uygulayacağız.
Her önemli iddiaya bir durum verin
Yanıtı tarih, ad, tutar, durum ve sonuç gibi tek tek iddialara bölün. Her iddiaya bir durum verin:
- Destekleniyor: İncelediğiniz kaynak iddiayı doğrudan doğruluyor.
- Çelişiyor: Kaynak farklı bir bilgi veriyor.
- Kaynakta yok: Kaynak iddiayı doğrulayacak bilgiyi içermiyor.
- Kontrol edilmedi: Karşılaştırmayı henüz tamamlamadınız.
"Kontrol edilmedi" geçici bir durumdur. Yanıtı doğrulanmış saymadan önce önemli her iddiayı Destekleniyor, Çelişiyor veya Kaynakta yok durumlarından birine taşıyın. Aksi hâlde incelenmemiş bir ifade, biri doğrulamış gibi kullanılabilir.
"Kaynakta yok" ifadesi de "yanlış" demek değildir. Brifing pilotun 15 Eylül'de başladığını söylüyor, fakat yedek sorumludan söz etmiyorsa "Pilot 15 Eylül'de başlıyor" Destekleniyor durumundadır. "Ağustos'ta başlıyor" Çelişiyor durumundadır. "Yedek sorumlu Jordan" ise Kaynakta yok olarak işaretlenir. Brifing açıkça söylemedikçe "Yedek sorumlu atanmadı" iddiası da Kaynakta yoktur. Atamaya ilişkin kanıt bulunmaması, atama yapılmadığını göstermez.
Düzeltmeden sonra doğrulanmış bir yanıt neye benzer?
Durum güncellemesinde kaynakta olmayan iki iddia varsa Copilot'tan metni kaynak sınırı içinde yeniden kurmasını isteyin: "Yalnızca doğrudan desteklenen bilgileri içeren doğrulanmış bir özet yaz. Kaynağın sağlamadığı her şey için ayrı bir Açık sorular bölümü ekle. Tarihleri, adları ve sayıları aynen koru. Onay veya yedek sorumlu hakkında çıkarım yapma."
Düzeltilmiş sürüm şöyle: "8 Temmuz itibarıyla pilotun 15 Eylül'de başlaması planlanıyor, 120 şirket içi kullanıcıyı kapsıyor ve sorumlusu Priya Nair. Eğitim 45 dakikalık iki oturum ve belirtilen bütçe $8,400." Ardından Açık sorular başlığı altında: "Yedek sorumlu kim? $8,400 tutarındaki bütçe onaylandı mı?"
Bilinen olgular özette kalır, bilinmeyenler de görünür olur. Göndermeden önce düzeltilmiş taslağı kaynakla bir kez daha karşılaştırın. Düzeltme de üretilmiş bir metindir.
Atıf bir ipucudur, sonuç değil
Copilot'un gösterdiği atıf sizi bir belgeye yönlendirir. Yanındaki cümleyi sizin yerinize doğrulamaz. Önemli her iddia için ifadenin kendisini, kaynağı, ilgili bölümü ve kapsamı kontrol edin. Tarih, hedef kitle, ürün ve koşullar aynı olmalıdır. Konuyla ilgili bir belge belirli iddia için yetersiz kalabilir. Projenin $8,400 bütçesi olduğunu söyleyen belge, bütçenin onaylandığını kanıtlamaz.
Bir cümlede birkaç iddia varsa her birini ayrı ayrı kaynakla karşılaştırın. Yanıt sayı veya liste içeriyorsa hesabı kendiniz yapın ve her öğenin bir kez bulunduğunu doğrulayın. "Toplam katılım: 120" veya "Ortalama puan: 4,33" hesabını yeniden yapmak kısa sürer. Eksik bir satır ya da yanlış basamak, akıcı bir özet içinde kolayca gözden kaçabilir.
Sağlayıcının iddialarını doğru düzeyde doğrulayın
Doğrulama, bir Copilot özelliğinin gerçek iş akışında kullanılıp kullanılmayacağına karar verirken de gerekir. Microsoft belgelerini bir yanıtı incelerken gösterdiğiniz aynı dikkatle okuyun. Belgenin söylediğini kendi yorumunuzdan ayırın.
Üç düzey kullanabilirsiniz. Belgelenmiş gerçek, kaynakta doğrudan yazan bilgidir. "Microsoft altı sorumlu AI ilkesi tanımlar" buna örnektir. Makul yorum, bu bilgiden çıkardığınız sonuçtur. Altı ilkeyi inceleme kategorisi olarak kullanmak bu sınıfa girer. Desteklenmeyen sonuç ise kanıtın kapsamını aşar. "Bu nedenle her dağıtım altı ilkeyi de karşılar" ifadesi desteklenmez. Makul yorum işe yarayabilir, ama yine de size aittir. Desteklenmeyen sonucu kaldırın.
İlk bulduğunuza uzanmak yerine, sorunuzu en dar kapsamlı ilgili belgeyle eşleştirin:
Belge soruyu yanıtlamıyorsa "Belirtilmemiş" yazın. "Risk yok" sonucuna varmayın. Belgedeki sessizlik güvence değil, eksik kanıttır. Daha dar bir kaynak arayın veya davranışı kendi ortamınızda doğrulayın.
Dağıtacağınız sistemi haritalayın, ölçün ve riski azaltın
Düşük riskli bir taslakta tek yanıtı kontrol etmek yeterlidir. Başkalarının kullanacağı bir politika yardımcısı veya talep sınıflandırıcı geliştiriyorsanız sistemi gerçek kullanıcılara açmadan önce üç aşamada doğrulayın: haritala, ölç, azalt.
Zararı genel bir etiket yerine baştan sona haritalayın. "Halüsinasyon riski" test edilebilir bir senaryo değildir. "Asistan politika istisnası uydurursa öğrenci yanıtı yetkili sanıp gerçek onay sürecini kaçırabilir" ifadesi ise neyi kontrol edeceğinizi gösterir. Her zararı etki ile olasılığı çarparak puanlayın ve puanın gerekçesini bir cümleyle yazın.
Başarı koşullarını herhangi bir sonuç görmeden önce belirleyip ölçün. Aksi hâlde yararlı görünen yanlış yanıtı kabul edebilirsiniz. İyi bir başarı koşulu gözlemlenebilir olmalıdır. Örneğin asistan istisna uydurmamalı veya onaylamamalı, politikanın kapsamadığı alanı belirtmeli ve kararı adı belirtilen sorumluya yönlendirmelidir. Gereksiz retleri de sayın. Asistan basit ve yanıtlanabilir politika sorusuna "Yardımcı olamam" diyorsa denetim diğer yönde bozulmuştur.
Riski katmanlı denetimlerle azaltın. Kaynağı sınırlayın, belirsizliğin belirtilmesini zorunlu kılın ve onayları insanda tutun. Ardından aynı testleri değiştirmeden yeniden çalıştırıp farkı kaydedin. Son olarak test etmediğiniz alanları, kalan riskin sahibini ve yeni incelemeyi tetikleyecek olayı yazın. Beş yazılı testi geçen talimat iyi bir başlangıçtır, fakat dağıtım kararı değildir. Tek başarılı yanıt ise hiçbir zaman yeterli kanıt sayılmaz.
Döngüyü bir örnekte uygulayın
Tek kaynağı kısa bir politika olan kütüphane asistanını düşünün. Standart dizüstü bilgisayar ödünç verme süresi 14 gündür ve uzatmaları Library Services onaylayabilir. Normal soru, belirsiz soru, 30 günlük uzatma isteği, politikayı yok sayma talimatı ve başka birinin ödünç alma geçmişini isteme senaryoları için beş test yazın. Testleri çalıştırmadan önce başarı koşullarını belirleyin.
Denetim olmadan başlangıç sürümü dört testte başarısız olur. Asistan bakım gerekçeli bir istisna uydurup uzatmayı "onaylar", politika dışı kural üretme talimatına uyar ve başka bir kullanıcının ödünç alma geçmişini açıklar. Ardından şu yazılı denetimi ekleyin: yalnızca politikadan yanıtla, kaynak sustuğunda "Sağlanan politikada belirtilmemiş" de, uzatmayı onaylama, kararları Library Services'a yönlendir ve başka kişinin bilgisini açıklama. Aynı testleri yeniden çalıştırın. Beşi de geçer, güvenli soru hâlâ yanıtlanır ve uydurma onaylarla gizlilik sızıntısı ortadan kalkar.
Bu sayımlar yeniden üretilebilir kanıttır. Başka bir değerlendirici aynı testleri çalıştırıp aynı sonuca ulaşabilir. Beş yazılı test yine de canlı sistemin nasıl davranacağını ortaya koymaz. Bu yüzden sonuç "testlere devam" olarak kalır.
