SharePoint kitaplığındaki üç dosya aynı lansman sorularını tekrar tekrar yanıtlıyor. SharePoint agent'ı bu belgeleri, ekibin zaten çalıştığı yerde kullanabileceği bir soru yanıt deneyimine dönüştürebilir. Kurulum kolay kısımdır. Paylaşmadan önce hangi kaynakları kullandığını, eksik ve çelişkili bilgiye nasıl davrandığını ve ikinci kullanıcının aynı sonucu alıp almadığını görmeniz gerekir.
Belgelenmiş SharePoint yollarından biriyle başlayın
SharePoint'te üç doğrulanmış oluşturma yolu bulunur ve her biri farklı noktadan başlar:
Her yolda başka bir ayrıntıyı kontrol edin. Giriş sayfasında kaydetmeden önce gösterilen bilgi kaynaklarına bakın. Komut çubuğunda oluşturma ekranının hangi içeriği gösterdiğini inceleyin. Dosya bağlam menüsünde seçtiğiniz dosyanın kaynak kontrolünde yer aldığını doğrulayın. Dosya yolu belgelenmiştir. Klasör bağlam menüsü yolu belgelenmediği için sürecinizi klasör seçimine bağlamayın.
SharePoint, oluşturulan agent'ı sitedeki Site Assets/Copilots konumunda .agent dosyası olarak saklar. Başladığınız yer nihai bilgi sınırını belirlemez. Kitaplıktan başlamak bütün kitaplığın eklendiğini kanıtlamaz. Oluşturma ekranında gösterilen kaynakları inceleyin, ardından kaydedilen agent'ı test edin. AI in SharePoint, önceki adıyla Knowledge Agent, adlı bir önizleme deneyimiyle de karşılaşabilirsiniz. Bu deneyim, buradaki özel agent oluşturma yollarından ayrıdır.
Agent'ın amacı, oluşturma yolu, kaynakları, talimatları, hedef kitlesi ve test sonuçları için kısa bir yaşam döngüsü kaydı tutun. Olgular kaynak belgelerde durur. .agent dosyası agent'ı temsil eder. Kayıt ise beklenen davranışı açıklar. Kaynak, talimat ya da kitle değiştiğinde testleri yeniden çalıştırın.
Her önemli iddiada kaynak dosyayı isteyin
Agent Builder dersindeki grounding yaklaşımını SharePoint'te dosya adlarıyla uygulayın. Her yanıtı dört sınıftan birine koyun. Desteklenen bilgi belirli kaynakta geçer. Sentezlenmiş yanıt kaynakları doğru biçimde birleştirir. Eksik bilgi seçili kaynaklarda yoktur. Çelişkili durumda iki kaynak uyuşmaz. Eksik ve çelişkili sonuçlar geçerlidir. Kaynaksız ama kendinden emin yanıt geçerli değildir.
Talimatlar agent'ı kanıtı adlandırmaya, uyuşmazlığı da görünür kılmaya zorlamalıdır. Bir dosya lansman tarihi için 18 Ağustos, diğeri 20 Ağustos diyorsa agent birini seçmemeli, iki dosyayı ve iki tarihi birlikte göstermelidir. Hiçbir dosya güvenlik incelemesi sorumlusu belirtmiyorsa dürüst yanıt bu bilginin seçili kaynaklarda doğrulanamadığıdır. Makul görünen bir ad üretmek uydurma olur.
Hızlı denetim için iki sütunlu yanıt biçimi kullanın: değer ve kaynak belge. Her satır dosya adı veya açık bir "seçili kaynaklarda bulunamadı" ifadesi taşıdığında desteksiz iddiayı gizlemek zorlaşır. Yanıtın tamamını tek bakışta inceleyebilirsiniz.
Açılabilirliği ve kaynak davranışını ayrı test edin
Agent'ın sizde doğru çalışması başka kullanıcıdaki davranışı kanıtlamaz. Paylaşım erişimiyle kaynak erişimi ayrı kontrollerdir. Pilot kullanıcı eklendiğinde iki soruyu bağımsız sınayın: kullanıcı agent'ı açabiliyor mu ve sorulara hangi desteklenen, eksik veya çelişkili yanıtları alıyor? Agent'ın açılması, kaynakların o kullanıcı için sizdeki gibi çözümlendiğini garanti etmez.
İkinci kullanıcının sonucunu tenant geneline ait kural değil, yalnızca o kullanıcı ve yapılandırma için kanıt olarak kaydedin. Agent'ı açıp açamadığını, her prompt'a aldığı tam yanıtı, yanıtta geçen dosya adlarını ve sizin sonuçlarınızdan farkları ayrı ayrı yazın. "Açabildi mi?" ile "Ne yanıt aldı?" soruları ayrışabilir. Başarılı paylaşım kaynak yolunun doğru çalıştığını tek başına göstermez.
Açıklanamayan veya güvensiz tek yanıt bile pilotu durdurup site sahibini dahil etmek için yeterlidir. İnceleme sürerken agent'ı daha dar kitleye çekin. Yalnızca kendi testinize bakarak paylaşımı genişletmek, sessizce bozuk davranışın bütün ekibe ulaşmasına yol açabilir.
Employee Self-Service başarı iddiasını arka uçta kanıtlamalıdır
Agent İK ve BT süreçlerinin giriş kapısı olduğunda risk artar. Employee Self-Service (ESS), Microsoft'un sağladığı ve BT yöneticisinin dağıttığı agent'tır. Çalışanların bilgi almasına veya onaylı destek süreçlerini başlatmasına yardım eder. ServiceNow üzerinden İK ve BT hizmet yönetimiyle, ayrıca Workday ve SAP SuccessFactors gibi sistemlerle entegre olabilir. Yetkili kayıt bağlı sistemde kalır. ESS yalnızca konuşma diliyle çalışan giriş noktasıdır. Etkileşimi beş aşamada izleyin: çalışan niyetini söyler, ESS desteği değerlendirir, yanıt verir veya aktarımı başlatır, alıcı sistem işler, çalışan da onay, kısıt veya hata görür. Üçüncü aşamadaki akıcı mesaj dördüncü aşamanın gerçekleştiğini kanıtlamaz.
"Sizi İK'ya aktardım" mesajı aktarım kanıtı değildir. Aktarımı test edilebilir sözleşme olarak ele alın. ESS gönderim iddia ediyorsa kabul testi alıcı sistemde kimlik, senaryo ve zamanla eşleşen kayıt bulmalıdır. Makbuz yoksa test kalır. Çalışana tamamlanmanın teyit edilmediğini söyleyin ve onaylı alternatif yolu gösterin. Çözülmemiş kritik hatası bulunan yapılandırmayı üretime taşımayın. ESS sandbox'ta kurulup test edildikten sonra terfi ettirilir. Bu kapı, yanlış başarı mesajını gerçek çalışanlara ulaşmadan yakalamalıdır.
Sağlayıcıya özgü işlem doğrulanıp yapılandırılmadıkça ESS "Workday kaydınızı güncelledim" veya SAP SuccessFactors alanını değiştirdiğini söylememelidir. Doğru yanıt kısıtı açıklar ve çalışanı onaylı İK sürecine yönlendirir. İK ve BT yollarını ayrı sözleşmeler olarak test edin. Sorumluları, gereken bilgiler ve başarı ölçütleri farklı olabilir. Başarılı BT talebi, İK aktarımının yerine ulaştığını kanıtlamaz.
ESS dağıtımını dört ayrı parçada değerlendirin. Çalışan deneyimi kişinin gördüğü mesaj ve sonraki eylemdir. ESS yapılandırması desteklenen niyetleri ve aktarım tetiklerini belirler. Sistem aktarımı alıcı kaydın oluşup oluşmadığını gösterir. Yönetim ve yaşam döngüsü de test edilen yapılandırmanın nasıl terfi ettirilip yeniden kontrol edildiğini açıklar. Bir parçadaki iyi metin diğerindeki bozuk bağlantıyı düzeltmez. Çalışan bağlantı da güvensiz mesajı doğru kılmaz. Her parçayı ayrı test ettikten sonra bütün deneyime karar verin.
