|
เป้าหมาย |
ถามตัวเองว่า "ฉันต้องการบรรลุผลลัพธ์อะไรไม่ใช่: "ฉันต้องใช้เครื่องมืออะไร", "ฉันควรเรียกตัวเชื่อมต่อไหน" หรือ "ฉันควรสร้างหัวข้ออะไร"
ระบุให้ชัดเจนว่าเหตุผลที่เอเจนต์ควรมีอยู่คืออะไร เอเจนต์ควรบรรลุอะไร และใครคือกลุ่มเป้าหมาย เน้นผลลัพธ์เป็นหลัก ให้การออกแบบของเอเจนต์สอดคล้องกับปัญหา
ชี้แจง:- ปัญหาหรือช่องว่างของคุณค่า
- ผู้ใช้เป้าหมาย
- ผลกระทบที่คาดหวัง
- ความสำเร็จมีลักษณะอย่างไร
ใช้รูปแบบ Jobs-To-Be-Done:
-
ในฐานะ<ผู้ใช้>
-
ฉันต้อง<ทำงานให้เสร็จ>
-
เพื่อให้<ผลลัพธ์>
|
-
ในฐานะพนักงานใหม่ ฉันต้องการเข้าใจนโยบายด้านทรัพยากรบุคคลในพื้นที่ของฉัน เพื่อให้ฉันสามารถนำทางการปฐมนิเทศได้อย่างมั่นใจ
-
ในฐานะผู้จัดการฝ่ายสนับสนุน IT ฉันต้องการประมวลผลอีเมลสนับสนุนโดยอัตโนมัติ เพื่อลดการคัดกรองด้วยมือ
|
- เริ่มต้นจากการมุ่งที่คุณลักษณะของระบบ แทนที่จะเริ่มจากผลลัพธ์ที่ต้องการ
- การออกแบบสําหรับกรณีกำกวม
- ไม่ได้กำหนดเกณฑ์ความสำเร็จที่วัดผลได้
|
|
ทริกเกอร์ |
ทริกเกอร์ของเอเจนต์คือเหตุการณ์ เงื่อนไข หรืออินพุตเฉพาะที่แจ้งให้เอเจนต์เริ่มงานหรือภารกิจของตน ทริกเกอร์สามารถเริ่มต้นได้จากการกระทำของมนุษย์หรือเหตุการณ์อัตโนมัติ
เรียนรู้เพิ่มเติม: ค้นหาทริกเกอร์ที่เหมาะกับเหตุการณ์ของคุณ |
- ข้อความของผู้ใช้ในแชท
- อีเมลใหม่ในกล่องจดหมายที่แชร์
- เรคคอร์ดใหม่ในระบบ
- งานตามกำหนดการหรืองานที่เกิดซ้ำ
|
- เอเจนต์อัตโนมัติต้องการทริกเกอร์ที่ชัดเจน หากไม่มีทริกเกอร์ เอเจนต์จะไม่ทำงาน
- ทริกเกอร์ขึ้นอยู่กับลักษณะการทำงานของผู้ใช้ที่คาดเดาไม่ได้ เช่น การพึ่งพาผู้ใช้ในการพิมพ์คำสำคัญหรือวลีที่เฉพาะเจาะจง
- ทริกเกอร์ขาดบริบทที่จำเป็น เช่น เอเจนต์เริ่มทำงานแต่ไม่มีเมตาดาต้าาดาต้า (รหัสบันทึก, ข้อมูลประจำตัวผู้ใช้) เพียงพอที่จะดำเนินการได้อย่างมีประสิทธิภาพ
- ทริกเกอร์เปิดใช้งานบ่อยกว่าที่สถานการณ์ต้องการจริง ซึ่งนำไปสู่การดำเนินการที่ไม่จำเป็นและการใช้ทรัพยากรอย่างสิ้นเปลือง
- การออกแบบทริกเกอร์ไม่คำนึงถึงโควต้าหรือขีดจำกัดของแพลตฟอร์ม ส่งผลให้เอเจนต์ถึงขีดจำกัดการใช้งานหรือล้มเหลวภายใต้ภาระงาน
|
|
เครื่องมือและการรวมระบบ |
กำหนดการกระทำที่เอเจนต์ต้องสามารถดำเนินการได้ ไม่ใช่แค่สิ่งที่เอเจนต์รู้
เครื่องมือช่วยให้เอเจนต์สามารถเข้าถึงหรือปรับปรุงข้อมูล, เรียกใช้งาน API, เริ่มเวิร์กโฟลว์, ส่งข้อความ และดำเนินการธุรกรรมต่าง ๆ ได้ แสดงรายการระบบที่เอเจนต์ต้องใช้งานและข้อจำกัดของระบบเหล่านั้น (API ต่าง ๆ, โมเดลการรับรองความถูกต้อง, ข้อจำกัดด้านอัตราการใช้งาน และขอบเขตความเป็นเจ้าของและ SLA)
พิจารณาผลลัพธ์ที่คาดหวัง, เกณฑ์ความสำเร็จและคุณภาพ, วิธีจัดการกรณีสำรอง และลักษณะการทำงานเมื่อเกิดข้อผิดพลาด การพึ่งพาเป็นปัจจัยสำคัญต่อความเป็นไปได้—ควรจัดการตั้งแต่เนิ่นๆ
เรียนรู้เพิ่มเติม: กระบวนการในการเพิ่มเครื่องมือให้กับเอเจนต์ |
- ตัวเชื่อมต่อ ServiceNow → รับรายละเอียดตั๋ว
- ตัวเชื่อมต่อ Microsoft Entra ID → ดึงตำแหน่งที่ตั้งของผู้ใช้
- Jira API → อัปเดตรายการงาน
- ตัวเชื่อมต่อ Outlook → ตอบกลับอีเมล
|
- ไม่บันทึกการดำเนินการหรือจัดเก็บผลลัพธ์สำหรับการตรวจสอบ
- สมมติว่า API มีความเสถียรและพร้อมใช้งานเสมอ
- การให้สิทธิ์เครื่องมือมากเกินไป
- ไม่ได้กำหนดลักษณะการทำงานแนวทางสำรองในการเรียกใช้เครื่องมือ (ไม่มีการตรวจสอบความถูกต้องของผลลัพธ์จากเครื่องมือ ไม่มีแนวทางสำรองเมื่อเครื่องมือล้มเหลว และไม่มีแนวทางการแก้ไขเมื่อเกิดปัญหา)
- เพิกเฉยต่อการจำกัดอัตราหรือการควบคุมปริมาณ
- ขาดการแมปความขึ้นต่อกัน (ใครเป็นเจ้าของ API แต่ละรายการ ข้อตกลงระดับการให้บริการคืออะไร)
- ไม่ตรวจสอบเงื่อนไขเบื้องต้นก่อนดำเนินการ
|
|
ช่องทาง |
ช่องทางคือแพลตฟอร์มหรืออินเทอร์เฟซที่เอเจนต์ของคุณถูกปรับใช้และโต้ตอบกับผู้ใช้
ช่องทางนี้ยังมีอิทธิพลต่อความคาดหวังของผู้ใช้เกี่ยวกับเวลาแฝง การสลับบทสนทนา และประสบการณ์การใช้งาน |
- Microsoft Teams
- SharePoint
- Microsoft 365 Copilot
- เว็บแชทหรืออินเทอร์เฟซเสียง
|
- การเลือกช่องทางตามความสะดวกหรือความเรียบง่ายของการปรับใช้ แทนที่จะเป็นวิธีและสถานที่ที่ผู้ใช้ทำงานจริง
- สมมติว่าผู้ใช้จะปรับตัวเข้ากับช่องทางของเอเจนต์ แทนที่จะเข้าถึงผู้ใช้ในช่องทางที่พวกเขาใช้งานอยู่แล้ว
- ให้ความสำคัญกับความเป็นไปได้ทางเทคนิคมากกว่าประสบการณ์ของผู้ใช้ ซึ่งส่งผลให้การนำไปใช้ต่ำ แม้ว่าเอเจนต์จะทำงานได้อย่างถูกต้องก็ตาม
- การออกแบบโดยเน้นการสนทนาเป็นหลัก ทั้งที่ช่องทางที่แท้จริงคืออีเมลหรือเวิร์กโฟลว์ (เช่น การสร้างประสบการณ์ผู้ใช้แบบสนทนาเมื่อการสนับสนุนเกิดขึ้นจริงผ่าน Outlook โดยลืมไปว่าอีเมลเป็นการผลัดกันตอบ ไม่ใช่การสนทนาแบบต่อเนื่อง)
- การเพิกเฉยต่อข้อจำกัดเฉพาะช่องทาง (Outlook ต้องการการตอบที่สมบูรณ์ ไม่ใช่คำถามชี้แจง; Teams รองรับการ์ดที่ปรับเปลี่ยนได้ ในขณะที่อีเมลไม่รองรับ)
|
|
ความรู้และข้อมูล |
บันทึกข้อมูลหรือความรู้ที่เอเจนต์ต้องใช้ในการวิเคราะห์ และระบุสถานที่ที่ข้อมูลหรือความรู้เหล่านั้นมีอยู่ในขณะนี้ พิจารณาคุณภาพและความสดใหม่ของข้อมูล ข้อมูลที่มีโครงสร้างหรือไม่มีโครงสร้าง และขอบเขตการเข้าถึงและสิทธิ์
การเตรียมความพร้อมของข้อมูลเป็นหนึ่งในอุปสรรคในขั้นตอนท้ายที่พบได้บ่อย หากไม่ได้รับการแก้ไขตั้งแต่เนิ่นๆ |
- เอกสาร
- ฐานข้อมูล
- เว็บไซต์
- ฐานข้อมูลองค์ความรู้
- ระบบภายในหรือภายนอก
|
- การกำกับดูแลข้อมูลที่ขาดคุณภาพหรือไม่สอดคล้องกัน เมื่อไม่มีการกำหนดความเป็นเจ้าของ ความถี่ในการรีเฟรช และกระบวนการอัปเดต ข้อมูลจะล้าสมัยหรือขัดแย้งกันอย่างรวดเร็ว
- การสับสนระหว่าง "เอกสาร" กับ "ความรู้" และการอ้างอิงที่เก็บเอกสารขนาดใหญ่เป็นแหล่งข้อมูลหลักโดยไม่ได้ตรวจสอบว่าเอกสารเหล่านั้นเป็นข้อมูลล่าสุด มีโครงสร้างที่ดี หรือมีการติดป้ายกำกับอย่างสม่ำเสมอหรือไม่
- แหล่งความรู้ขัดแย้งกัน นโยบาย กระบวนงาน หรือชุดข้อมูลหลายเวอร์ชันนำเอเจนต์ไปสู่คำสั่งที่ขัดแย้งกัน
- สิทธิ์และการควบคุมการเข้าถึงไม่ได้ออกแบบมาอย่างชัดเจน เนื้อหาที่ละเอียดอ่อนถูกเปิดเผยโดยไม่ได้ตั้งใจ หรือเอเจนต์อ้างอิงความรู้ที่ผู้ใช้ปลายทางไม่มีสิทธิ์เข้าถึง
- การขยายแหล่งความรู้โดยไม่ตรวจสอบขอบเขตความปลอดภัย ซึ่งส่งผลให้เอเจนต์แชร์ข้อมูลมากเกินไปหรือล้มเหลวเมื่อการเข้าถึงถูกจำกัด
|
|
โฟลว์และการประสานรวม |
กำหนดวิธีการจัดโครงสร้างและลำดับงานภายในเอเจนต์: เมื่อใดควรใช้โฟลว์หรือหัวข้อแบบกำหนด เมื่อใดควรพึ่งการประสานงาน และเมื่อใดที่ต้องมีการมีส่วนร่วมของมนุษย์ เป้าหมายคือลักษณะการทำงานที่คาดเดาได้ ระบบอัตโนมัติที่ปลอดภัย และการเลื่อนระดับที่ชัดเจน
เมื่อใดที่ควรใช้โฟลว์หรือหัวข้อ:- การรวบรวมข้อมูลหลายขั้นตอน
- การแก้ไขปัญหาแบบมีการแนะนำหรือแผนผังการตัดสินใจ
- กระบวนการที่ขับเคลื่อนด้วยการปฏิบัติตามกฎระเบียบหรือนโยบาย
- การกระทำที่มีผลกระทบสูงหรือไม่สามารถย้อนกลับได้
หัวข้อเป็นกลไกหลักสำหรับตรรกะเชิงกำหนด
กำหนด:- สิ่งที่เอเจนต์สามารถดำเนินการได้โดยอิสระ
- สิ่งที่ต้องได้รับการอนุมัติ ตรวจสอบ หรือควบคุมโดยมนุษย์
- เมื่อเอเจนต์ต้องยกระดับหรือรอการดำเนินการ
- วิธีที่ข้อเสนอแนะจากมนุษย์ถูกส่งกลับไปใช้เพื่อพัฒนาและปรับปรุงระบบ
|
- เอเจนต์ Ask-Me-Anything: โฟลว์ที่กำหนดน้อยที่สุด อาศัยการประสานงานและการให้เหตุผลเชิงกำเนิดเป็นหลัก
- เอเจนต์อัตโนมัติ: ใช้โฟลว์หรือหัวข้อในการบังคับลำดับขั้นตอน การตรวจสอบความถูกต้อง และการตั้งค่าตัวป้องกันสำหรับขั้นตอนที่สำคัญ
- เวิร์กโฟลว์การอนุมัติ: เอเจนต์เตรียมบริบทและข้อเสนอแนะ มนุษย์อนุมัติหรือยกเลิกการดำเนินการที่มีผลกระทบสูง
|
- โฟลว์ที่ถูกจัดโครงสร้างมากเกินไป จะจำกัดความยืดหยุ่น และทำให้เอเจนต์ดูแข็งทื่อหรือเปราะบาง
- โฟลว์ที่มีโครงสร้างต่ำ ลดความน่าเชื่อถือ และทำให้ผลลัพธ์ไม่สามารถคาดเดาได้
- ไม่ใช้หัวข้ออย่างชัดเจนสำหรับตรรกะที่กำหนด ซึ่งนำไปสู่ลักษณะการทำงานเฉพาะกิจหรือไม่สอดคล้องกัน
- การแบ่งหน้าที่ระหว่างมนุษย์กับเอเจนต์ไม่ชัดเจน ส่งผลให้กระบวนการยกระดับปัญหาไม่ชัดเจน
- การให้มนุษย์ต้องอนุมัติการดำเนินการที่มีความเสี่ยงต่ำมากเกินไป ทำให้เกิดคอขวดและกีดกันการใช้เอเจนต์
- ตัวแทนที่กระทําโดยไม่มีขอบเขต "ไม่ดําเนินการ" ที่ชัดเจน โดยเฉพาะอย่างยิ่งในสถานการณ์กำกวมหรือสถานการณ์ที่มีความเสี่ยงสูง
|
|
คำสั่งและลักษณะการทำงาน |
คำสั่งจะกำหนด:- บทบาทและความรับผิดชอบของเอเจนต์
- เหตุผลและตอบสนองอย่างไร
- ควรใช้ความรู้ เครื่องมือ หรือเอเจนต์อื่น ๆ เมื่อใดและอย่างไร
- ลำดับของการดำเนินการที่ควรปฏิบัติตาม
- น้ำเสียง ขอบเขต และข้อกำหนดด้านความปลอดภัย:
คำสั่งที่ชัดเจนเชื่อมโยงความรู้ เครื่องมือ และขั้นตอนการทำงานเป็นระบบที่สอดคล้องกันและคาดการณ์ได้
เรียนรู้เพิ่มเติม: กำหนดค่าคำสั่งคุณภาพสูงสำหรับการประสานการทำงานที่สร้างโดยอัตโนมัติ และ เขียนคำสั่งที่มีประสิทธิภาพสำหรับเอเจนต์ที่กำหนดด้วยการประกาศ |
- บทบาทและขอบเขต: "คุณรับหน้าที่เป็นเอเจนต์สนับสนุนอีเมลด้านไอที มีหน้าที่อ่านข้อความในกล่องจดหมายขาเข้า แยกหมายเลขตั๋ว และตอบกลับด้วยข้อมูลที่ตรวจสอบแล้วจาก ServiceNow"
- ลักษณะการทำงานตามลำดับ: "ขั้นตอนที่ 1: ตรวจสอบฐานความรู้เพื่อค้นหานโยบายที่มีอยู่หรือปัญหาที่ทราบ ขั้นตอนที่ 2: หากไม่พบข้อมูลหรือข้อมูลไม่สมบูรณ์ ให้เรียกใช้เครื่องมือ ServiceNow เพื่อดึงรายละเอียดตั๋ว ขั้นตอนที่ 3: หากข้อมูลที่จำเป็นยังขาดหายไป ให้ตอบกลับโดยใช้รูปแบบ 'ฉันไม่ทราบ' และเลื่อนระดับ"
- กฎการใช้เครื่องมือ: "ต้องตรวจสอบความถูกต้องของรหัสที่แยกออกมาด้วยการเรียกใช้เครื่องมือทุกครั้งก่อนนำไปใช้ในการตอบกลับ"
- การจัดการความล้มเหลว: หากความรู้ขาดหายไปหรือการเรียกใช้เครื่องมือล้มเหลว อย่าเดา ตอบสนองด้วยข้อจำกัดที่ชัดเจนและขั้นตอนต่อไป"
|
- คำสั่งคลุมเครือเกินไป ตัวอย่างเช่น "ช่วยเหลือผู้ใช้เกี่ยวกับปัญหาการสนับสนุน" ไม่ได้ระบุโดเมน ขอบเขต หรือการดำเนินการที่อนุญาต
- ไม่มีความชัดเจนว่าเมื่อใดควรใช้ความรู้หรือเครื่องมือหรือร่วมงานกับเอเจนต์อื่น ๆ ซึ่งนำไปสู่ลักษณะการทำงานที่ไม่สอดคล้องกันหรือไม่มีประสิทธิภาพ
- คำสั่งไม่ได้กำหนดลำดับของการดำเนินการ ทำให้เอเจนต์ผสมผสานความรู้และผลลัพธ์ของเครื่องมือในลักษณะที่คาดเดาไม่ได้
- เพลิดเพลินกับบริการ Villa Host ตลอด 24 ชั่วโมง พร้อมสิทธิประโยชน์สุดพิเศษ ได้แก่ บริการรับส่งสนามบิน อาหารเช้าลอยน้ำ สปา สปาร์กลิงไวน์ 1 ขวด อาหารค่ำบนรูฟท็อประดับมิชลิน และซันเซ็ตค็อกเทล
- คำสั่งที่ขัดแย้งกัน เช่น "ถามคำถามที่ชี้แจงเสมอ" และ "ตอบกลับด้วยคำตอบสุดท้ายเท่านั้น"
- ไม่มีข้อกำหนด "ห้ามทำ" ที่ชัดเจน เช่น การแก้ไขข้อมูลที่ละเอียดอ่อน การเปิดเผยตัวระบุภายใน หรือการให้คำแนะนำด้านกฎหมายหรือทรัพยากรบุคคลโดยไม่มีแหล่งที่มาที่ได้รับการยืนยัน
|
|
สถาปัตยกรรมและองค์ประกอบของเอเจนต์ |
ใช้เอเจนต์หลายตัวเมื่อ:
- โดเมนมีขนาดใหญ่หรือแตกต่างกัน
- ความเป็นเจ้าของแตกต่างกันไปในแต่ละทีม
- การเข้าถึงหรือการอนุญาตแตกต่างกันไป
- จำเป็นต้องมีการให้เหตุผลหรือตรรกะเฉพาะทาง
การมอบหมายช่วยปรับปรุงความเป็นโมดูล ความชัดเจน และความสามารถในการบำรุงรักษาในระยะยาว
เรียนรู้เพิ่มเติม: สำรวจรูปแบบการประสานรวมแบบหลายเอเจนต์ |
- เอเจนต์หลักมอบหมายการค้นหาตั๋วให้กับเอเจนต์ไอที
- เอเจนต์ความรู้รับหน้าที่ตรวจสอบและประกันคุณภาพเอกสาร
- เอเจนต์จัดการเส้นทางจะตัดสินใจเลือกติดต่อเอเจนต์ผู้เชี่ยวชาญรายใด
|
- การแบ่งงานมากเกินไป (มีเอเจนต์มากเกินไป)—เช่น การสร้างเอเจนต์แยกสำหรับแต่ละงานเล็ก ๆ—อาจนำไปสู่การแผ่กิ่งก้านสาขาของสถาปัตยกรรม และทำให้การบำรุงรักษา ดีบัก รักษาความปลอดภัย หรืออัปเดตเอเจนต์เป็นเรื่องยาก
- การมอบหมายงานน้อยเกินไป (เอเจนต์แบบรวมศูนย์)—เช่น การมีเอเจนต์เดียวที่ต้องตอบคำถามด้าน HR, ค้นหาตั๋ว IT, จัดการแก้ไขปัญหา และสร้างใบสั่งซื้อหรือเหตุการณ์—อาจนำไปสู่เอเจนต์ที่มีลักษณะรวมศูนย์ เปราะบาง และยากต่อการบำรุงรักษา
- ขอบเขตการมอบหมายที่ไม่ชัดเจน ตัวอย่างเช่น เอเจนต์หลักไม่รู้ว่าจะต้องส่งต่องานเมื่อไหร่ เอเจนต์ย่อยไม่รู้ว่าควรคาดหวังข้อมูลอะไร หรือความรับผิดชอบทับซ้อนกัน (เช่น เอเจนต์สองตัวต่างค้นหาตั๋ว IT)
|
|
การกำกับดูแลและการบริหารความเสี่ยง |
กำหนดวิธีควบคุม รักษาความปลอดภัย และตรวจสอบเอเจนต์ เพื่อให้แน่ใจว่าเอเจนต์ทำงานอย่างมีความรับผิดชอบ ปลอดภัย และคาดการณ์ได้ตลอดวงจรชีวิต
คำจำกัดความนี้รวมถึงการควบคุมการเข้าถึง สิทธิ์ในการดำเนินการ ตัวป้องกันความปลอดภัย ความรับผิดชอบ และการกำกับดูแลอย่างต่อเนื่อง เพื่อจัดการความเสี่ยงทั้งด้านการดำเนินงานและความเสี่ยงที่เกี่ยวข้องกับ AI ตั้งแต่วันแรก
เรียนรู้เพิ่มเติม: รวบรวมข้อกำหนดด้านการกำกับดูแล และประยุกต์ใช้หลักการ AI ที่รับผิดชอบ |
- รูปแบบการรับรองตัวตนและการเข้าถึง: เอเจนต์จะใช้ข้อมูลประจำตัวระดับผู้ใช้เพื่อดึงข้อมูลเฉพาะที่ผู้ใช้ได้รับอนุญาตให้เข้าถึง ขณะที่ข้อมูลประจำตัวระดับระบบจะถูกจำกัดไว้เฉพาะการดำเนินการบริการที่กำหนดไว้อย่างชัดเจน
- สิทธิ์ในการดำเนินการและขอบเขตความปลอดภัย: เอเจนต์สามารถอัปเดตบันทึกงานหรือร่างการตอบได้ แต่ไม่สามารถดำเนินการที่ไม่สามารถย้อนกลับได้ (เช่น ปิดทิกเก็ตหรือส่งการสื่อสารไปยังภายนอก) โดยไม่ได้รับการอนุมัติล่วงหน้า
- การปกป้องข้อมูลและเนื้อหา: ข้อมูลที่ละเอียดอ่อนหรืออยู่ภายใต้ข้อบังคับจะถูกตรวจจับและบล็อกไม่ให้ถูกแชร์หรือดำเนินการโดยใช้มาตรการปกป้องของแพลตฟอร์ม (เช่น การป้องกันการสูญเสียข้อมูลหรือฟิลเตอร์ความปลอดภัย)
- การบันทึกข้อมูล การตรวจสอบ และการติดตามย้อนหลัง: กิจกรรมของเอเจนต์ทั้งหมด การเรียกใช้เครื่องมือ การปฏิเสธ และการยกระดับจะถูกบันทึกและสามารถตรวจสอบได้เพื่อการปฏิบัติตามข้อกำหนดและการทบทวน
- การรับผิดชอบการดำเนินงาน: เอเจนต์มีเจ้าของ ผู้สนับสนุน และผู้ดูแลการดำเนินงานที่กำหนดไว้ โดยสิทธิ์และลักษณะการทำงานจะได้รับการตรวจสอบเป็นระยะอย่างสม่ำเสมอ
|
- การออกแบบการกำกับดูแลและการควบคุมความเสี่ยงช้าเกินไป ส่งผลให้การปรับใช้ถูกระงับหรือเกิดความล่าช้าในการดำเนินงาน
- การอนุญาตสิทธิ์ให้เอเจนต์มากเกินไป "เพื่อความสะดวก" เพิ่มความเสี่ยงต่อการเปิดเผยข้อมูลหรือการดำเนินการโดยไม่ได้ตั้งใจ
- เอเจนต์ที่ให้สิทธิ์น้อยเกินไป ล้มเหลวขณะรันไทม์เมื่อไม่สามารถเข้าถึงระบบหรือข้อมูลที่จำเป็นได้
- ไม่ได้บูรณาการประเด็นเกี่ยวกับ AI ที่มีความรับผิดชอบเข้ากับการตัดสินใจด้านการกำกับดูแล
- การกำกับดูแลการดำเนินงานที่อ่อนแอ เช่น ไม่มีผู้รับผิดชอบที่ชัดเจน ไม่มีแผนการตรวจสอบ หรือไม่มีกระบวนการที่กำหนดไว้สำหรับการตอบสนองต่อเหตุการณ์
- ละเลยการติดตามลักษณะการทำงานของเอเจนต์หลังการปรับใช้ โดยคิดว่ามาตรการป้องกันเพียงอย่างเดียวก็เพียงพอแล้ว
|
|
การประเมินและการเพิ่มประสิทธิภาพ |
กำหนดการทดสอบที่จำลองสถานการณ์ในโลกแห่งความเป็นจริงเพื่อวัดความถูกต้อง ความเกี่ยวข้อง และคุณภาพของคำตอบของเอเจนต์ของคุณ ให้การตอบกลับที่คาดหวังและแสดงให้เห็นว่าการตอบสนองของเอเจนต์จับคู่กับการตอบสนองของคุณหรือการตอบกลับที่เป็นมาตรฐานที่สุดอย่างไร
วางแผนวิธีวัดและปรับปรุงประสิทธิภาพ:
- ความถูกต้องและความเกี่ยวข้อง
- การประหยัดเวลาหรือประสิทธิภาพ
- การนำไปใช้และการใช้งาน
- สัญญาณความพึงพอใจและความไว้วางใจ
- คุณภาพการอ้างอิง
- การปฏิบัติตามข้อกำหนดการอนุญาต
- การตรวจจับข้อมูลที่ไม่ถูกต้อง
- ชี้แจงพฤติกรรมของคำถาม
กำหนดข้อมูลการวัดและส่งข้อมูลทางไกลที่จะรวบรวม:
- การเรียกใช้เครื่องมือ
- การดำเนินการของเอเจนต์
- ความล้มเหลวและการลองซ้ำ
- ข้อคิดเห็นของผู้ใช้
ควรผนวกรวมการประเมินไว้ในกระบวนการออกแบบ ไม่ใช่เป็นเรื่องที่คิดทีหลัง เรียนรู้เพิ่มเติม: ออกแบบและดำเนินการประเมินเอเจนต์ |
- ตรวจสอบว่าการค้นหาตั๋วส่งกลับสถานะที่ถูกต้องและไม่ใช่สถานะที่ล้าสมัย
- ตรวจสอบว่าลิงก์การอ้างอิงชี้ไปยังเนื้อหาที่ได้รับอนุมัติในปัจจุบัน
- ตรวจสอบว่าเอเจนต์ปฏิเสธที่จะให้รายละเอียดเกี่ยวกับตั๋วของบุคคลอื่น
- ทดสอบว่าเอเจนต์สร้างหมายเลขตั๋วหรือบทความฐานความรู้ขึ้นมาเองหรือไม่
- วัดจำนวนอีเมลที่ประมวลผลโดยเอเจนต์อัตโนมัติต่อวัน และเปอร์เซ็นต์ของผู้ใช้ที่เลือกเอเจนต์มากกว่าช่องทางแบบด้วยตนเอง
|
- เรียกใช้การประเมินช้าเกินไป (หลังจากการปรับใช้งาน)
- ไม่มีพื้นฐานหรือเกณฑ์มาตรฐาน
- การประเมินที่ไม่เชื่อมโยงกับสถานการณ์จริง
- ไม่มีการตรวจจับการถดถอย
- ไม่มีการประเมินหลายรอบการสนทนา
- ไม่มีผู้ประเมินคุณภาพการใช้เครื่องมือ
- การตรวจสอบเฉพาะ "เส้นทางแห่งความสุข"
- ช่องว่างในการวัดและส่งข้อมูลทางไกล
|
