หมายเหตุ
การเข้าถึงหน้านี้ต้องได้รับการอนุญาต คุณสามารถลอง ลงชื่อเข้าใช้หรือเปลี่ยนไดเรกทอรีได้
การเข้าถึงหน้านี้ต้องได้รับการอนุญาต คุณสามารถลองเปลี่ยนไดเรกทอรีได้
หลังจากที่คุณคัดแยกความล้มเหลวของกรณีทดสอบแต่ละกรณีแล้ว คุณอาจดำเนินการแก้ไขและยังคงพบว่าประสิทธิภาพโดยรวมของเอเจนต์ปรับปรุงเพียงเล็กน้อยหรือไม่ได้ผลเลย ผลลัพธ์นี้มักบ่งชี้ถึงปัญหาเชิงระบบ ไม่ใช่ชุดของความล้มเหลวที่ไม่เกี่ยวข้องกัน
การวิเคราะห์รูปแบบช่วยให้คุณมองภาพรวมของกรณีทดสอบที่ล้มเหลวหลายกรณีเพื่อค้นหาสัญญาณที่เกิดซ้ำและสาเหตุร่วมกัน ใช้การวิเคราะห์รูปแบบเพื่อเน้นการเปลี่ยนแปลงที่แก้ไขกลุ่มความล้มเหลวพร้อมกัน แทนที่จะแก้ไขความล้มเหลวแต่ละครั้งแยกจากกัน
สำคัญ
ใช้คำแนะนำนี้หลังจากที่คุณทำการวิเคราะห์และจัดลำดับความสำคัญของความล้มเหลวเสร็จเรียบร้อยแล้ว และนำการเปลี่ยนแปลงการแก้ไขมาใช้ การวิเคราะห์รูปแบบจะมีประโยชน์อย่างมากหลังจากที่คุณคัดแยกความล้มเหลวอย่างน้อยห้ากรณี
เมื่อใดควรใช้การวิเคราะห์รูปแบบ:
การวิเคราะห์รูปแบบจะมีประโยชน์มากเมื่อคุณพบเงื่อนไขต่อไปนี้อย่างใดอย่างหนึ่งหรือมากกว่าหนึ่งข้อ:
- ความล้มเหลวจำนวนมากในชุดการประเมินเดียวกัน
- ความล้มเหลวที่เกิดซ้ำโดยมีลักษณะคล้ายกัน
- การปรับปรุงกรณีทดสอบแต่ละกรณีที่คะแนนโดยรวมไม่เปลี่ยนแปลง
- การปรับปรุงในด้านหนึ่งที่ทำให้เกิดการถดถอยในอีกด้านหนึ่ง
การแก้ไขข้อผิดพลาดทีละข้อถือว่าไม่มีประสิทธิภาพในสถานการณ์เหล่านี้ การวิเคราะห์รูปแบบช่วยให้คุณระบุปัจจัยร่วมของความล้มเหลว เพื่อให้คุณสามารถแก้ไขสาเหตุหลักได้
การวิเคราะห์การกระจุกตัว
หลังจากที่คุณจำแนกความล้มเหลวแต่ละรายการแล้ว ให้มองหารูปแบบทั่วทั้งชุด
| รูปแบบ | บ่งชี้อะไร | การดำเนินการที่แนะนำ |
|---|---|---|
| ความล้มเหลว 80% หรือมากกว่านั้นเป็นปัญหาการตั้งค่าการประเมิน | ชุดการประเมินต้องการการปรับเทียบ ไม่ใช่การเปลี่ยนแปลงเอเจนต์ | หยุดการวนซ้ำของเอเจนต์ ตรวจสอบและแก้ไขคุณภาพการประเมินก่อน แล้วทดสอบใหม่เพื่อให้ได้สัญญาณที่ชัดเจน |
| ความล้มเหลว 80% ขึ้นไปเป็นปัญหาการกำหนดค่าเอเจนต์ในด้านเดียว (เช่น ด้านที่เกี่ยวข้องกับความรู้ทั้งหมด) | ช่องว่างการกำหนดค่าเอเจนต์เชิงระบบ | มุ่งเน้นการแก้ไขในด้านนั้น ปัญหานี้มักเป็นข้อจำกัดทางสถาปัตยกรรม (เช่น โครงสร้างแหล่งความรู้) ไม่ใช่การแก้ไขรายกรณี |
| มากกว่า 80% ของความล้มเหลวเป็นข้อจำกัดของแพลตฟอร์ม | เอเจนต์ถึงขอบเขตของแพลตฟอร์ม | ประเมินผลขอบเขตของเอเจนต์ใหม่ ยกระดับไปยังทีมแพลตฟอร์ม ปรับเกณฑ์หรือถือว่ารายการที่ได้รับผลกระทบเป็นข้อจำกัดที่ทราบแล้วตามความเหมาะสม |
| ความล้มเหลวกระจายอย่างสม่ำเสมอในแต่ละประเภทสาเหตุหลัก | ไม่มีปัญหาเชิงระบบ | ดำเนินการแก้ไขต่อเป็นกรณี ๆ ไปโดยใช้การแมปการแก้ไข |
วิธีการวิเคราะห์การกระจุกตัว
สรุปจำนวนความล้มเหลวที่จัดประเภทตามสาเหตุหลัก:
- ปัญหาการตั้งค่าการประเมิน
- ปัญหาการกำหนดค่าเอเจนต์
- ข้อจำกัดของแพลตฟอร์ม
- ไม่ได้จัดประเภท
คำนวณเปอร์เซ็นต์สำหรับแต่ละประเภท
หากประเภทใดประเภทหนึ่งมีสัดส่วน 80% ขึ้นไป ซึ่งบ่งชี้ถึงปัญหาเชิงระบบ ให้ดำเนินการแก้ไขที่ประเภทนั้น ไม่ใช่แต่ละกรณี
หากปัญหาการกำหนดค่าเอเจนต์กระจุกตัวอยู่ในสัญญาณคุณภาพเดียว (ตัวอย่างเช่น ห้าในหกเป็นการยึดโยงความรู้) รูปแบบนั้นชี้ไปที่สาเหตุเชิงสถาปัตยกรรม
รูปแบบข้ามสัญญาณ
เมื่อความล้มเหลวเกิดขึ้นในหลายชุดการประเมิน มักจะชี้ไปที่สาเหตุรากร่วมกัน ตรวจสอบรูปแบบต่อไปนี้:
| รูปแบบ | น่าจะบ่งชี้อะไร | ประเด็นที่ควรตรวจสอบ |
|---|---|---|
| ความถูกต้องตามข้อเท็จจริงและการเชื่อมโยงองค์ความรู้ล้มเหลวทั้งคู่ | ปัญหาแหล่งความรู้ (ไม่ถูกต้อง สูญหาย ไม่สามารถเข้าถึงได้ หรือเก่า) | การกำหนดค่าองค์ความรู้ สถานะการจัดทำดัชนี และความใหม่ของเนื้อหา |
| การเรียกใช้เครื่องมือและการกำหนดเส้นทางทริกเกอร์ล้มเหลวทั้งคู่ | ปัญหาการกำหนดค่าการประสานงาน—หัวข้อและเครื่องมือไม่ได้เชื่อมต่อหรือกำหนดค่าอย่างถูกต้อง | ตรวจสอบวิธีการกำหนดเส้นทางของหัวข้อไปยังเครื่องมือ ตรวจสอบโฟลว์ที่ตัดการเชื่อมต่อหรือกำหนดค่าไม่ถูกต้อง |
| โทนไม่ผ่าน แต่ความแม่นยำผ่าน | เอเจนต์ได้คำตอบที่ถูกต้องแต่สื่อสารได้ไม่ดี | เน้นคำแนะนำด้านสไตล์ของพร้อมท์ ส่วนโครงสร้างพื้นฐานด้านความถูกต้องนั้นดีอยู่แล้ว |
| ผ่านด้านความปลอดภัย แต่ไม่ผ่านด้านความแม่นยำ | เอเจนต์อาจถูกจำกัดมากเกินไป—ระมัดระวังเกินไป, ปฏิเสธที่จะตอบเมื่อควร | ทบทวนคำแนะนำด้านความปลอดภัยสำหรับข้อจำกัดที่กว้างเกินไปซึ่งปิดกั้นคำตอบที่เหมาะสม |
| ทุกอย่างผ่านยกเว้นกรณีที่เกิดขึ้นได้ยาก | ลักษณะการทำงานหลักมีความมั่นคง | มุ่งเน้นการขยายความทนทานที่ขอบ; รูปแบบนี้เป็นสัญญาณที่ดี |
| ความแม่นยำเพิ่มขึ้นแต่โทนเสียงลดลง | ความขัดแย้งของคำสั่ง—คำแนะนำความแม่นยำใหม่อาจไปกลบคำแนะนำเกี่ยวกับโทนเสียง | ทบทวนการเปลี่ยนแปลงของพร้อมท์ล่าสุด และคำนึงถึง "งบประมาณคำสั่ง" |
| การประเมินผลหลายชุดมีคุณภาพลดลงพร้อมกัน | น่าจะเป็นสาเหตุเดียวที่มีผลกระทบในวงกว้าง | ตรวจสอบการเปลี่ยนแปลงพร้อมท์ระบบล่าสุด การอัปเดตแหล่งความรู้ หรือการอัปเดตโมเดลแพลตฟอร์ม |
จะจัดการกับรูปแบบสัญญาณข้ามอย่างไร
- ระบุสาเหตุหลักที่ใช้ร่วมกัน: หากสัญญาณทั้งสองล้มเหลวพร้อมกัน มีแนวโน้มว่าทั้งสองจะมีการพึ่งพาองค์ประกอบเดียวกัน เช่น แหล่งความรู้ ส่วนพร้อมท์ หรือการกำหนดค่าเครื่องมือ
- แก้ไขการขึ้นต่อกันที่ใช้ร่วมกัน: อย่าแก้ไขแต่ละสัญญาณแยกกัน
- เรียกใช้ชุดการประเมินทั้งสองอีกครั้ง: หลังจากการแก้ไข ให้ตรวจสอบว่าทั้งสองชุดมีผลลัพธ์ที่ดีขึ้น
- หากมีการปรับปรุงเพียงรายการเดียว สัญญาณจะไม่แสดงสาเหตุที่แท้จริงร่วมกัน คัดแยกและจัดการความล้มเหลวที่เหลืออยู่โดยอิสระ
การวิเคราะห์แนวโน้มข้ามรอบการวนซ้ำ
ติดตามการเปลี่ยนแปลงของคะแนนข้ามรอบการปรับปรุงเพื่อดูว่ากลยุทธ์การแก้ไขของคุณมีประสิทธิภาพหรือไม่
| แนวโน้ม | การตีความ | การดำเนินการ |
|---|---|---|
| คะแนนดีขึ้นในแต่ละรอบการปรับปรุง | การแก้ไขได้ผล | ดำเนินการต่อไปจนกว่าจะถึงเกณฑ์ที่กำหนด |
| คะแนนคงที่แม้จะมีการเปลี่ยนแปลง | การแก้ไขไม่ได้มุ่งเป้าไปที่สาเหตุที่แท้จริง | คัดแยกใหม่; การจำแนกสาเหตุที่แท้จริงอาจไม่ถูกต้อง |
| คะแนนลดลงหลังจากการเปลี่ยนแปลง | การถดถอย—การเปลี่ยนแปลงทำให้เกิดข้อผิดพลาด | ย้อนการเปลี่ยนแปลง ตรวจสอบว่าอะไรถดถอยและทำไม |
| ชุดการประเมินหนึ่งดีขึ้น อีกชุดหนึ่งแย่ลง | การประนีประนอม: การแก้ไขมิติหนึ่งส่งผลกระทบต่ออีกมิติหนึ่ง | ตรวจสอบความเชื่อมโยง ซึ่งมักเกิดจากความขัดแย้งของคำสั่ง (ดูที่ การเดินทาง 3) |
| คะแนนที่ผันผวนระหว่างแต่ละรอบการรัน (มีความแปรปรวนมากกว่า +/-10%) | ความไม่เสถียรของเกรดเดอร์หรือการทำงานแบบไม่กำหนดแน่นอนของเอเจนต์ | ตรวจสอบความน่าเชื่อถือของเกรดเดอร์ก่อน (ดูการตรวจสอบความถูกต้องของเกรดเดอร์) รันอย่างน้อยสามครั้งต่อการทำซ้ำแต่ละรอบ |
การสร้างภาพรวมแนวโน้ม
หลังจากการทำซ้ำแต่ละครั้ง ให้บันทึก:
- วันที่
- การเปลี่ยนแปลงที่ดำเนินการ
- ชุดการประเมิน
- คะแนนก่อนหน้า
- คะแนนหลัง
- เดลตา
ข้อมูลนี้จะช่วยให้คุณ:
- ยืนยันว่าคุณกำลังเข้าใกล้เกณฑ์ที่กำหนด
- ระบุการถดถอยอย่างรวดเร็ว
- ตรวจจับที่ราบสูงตั้งแต่เนิ่น ๆ (การเดินทาง 2)
บันทึกความล้มเหลว:
บันทึกความล้มเหลวที่เป็นระบบจะช่วยสร้างองค์ความรู้ขององค์กรตลอดรอบการปรับปรุง ขาดการจดบันทึก ทีมมักจะกลับไปวิเคราะห์ปัญหาเดิมซ้ำ
เหตุผลที่ต้องบันทึกความล้มเหลว
- เร่งการคัดแยกในอนาคต: คุณจดจำรูปแบบความล้มเหลวที่ทราบได้ทันที
- จัดเตรียมหลักฐานสำหรับการยกระดับ: รวบรวมบันทึกข้อจำกัดของแพลตฟอร์มเพื่อเพิ่มน้ำหนักให้กับข้อเสนอที่นำเสนอต่อทีมแพลตฟอร์ม
- สนับสนุนการเรียนรู้ของทีม: บันทึกช่วยลดการตรวจสอบซ้ำเมื่อมีหลายคนทำงานกับเอเจนต์เดียวกัน
- ติดตามช่องว่างที่ทราบ: อย่าลืมติดตามความล้มเหลวที่จัดประเภทเป็น "ไม่แก้ไข" หรือ "ข้อจำกัดที่ทราบ"
ใช้เทมเพลตบันทึกความล้มเหลว
ใช้เทมเพลตบันทึกความล้มเหลว เพื่อบันทึกความล้มเหลวในรูปแบบแบบย่อหรือแบบละเอียด โดยขึ้นอยู่กับขนาดของทีมและวุฒิภาวะของกระบวนการ
สิ่งที่ต้องบันทึก
อย่างน้อยที่สุด ให้บันทึกข้อมูลต่อไปนี้สำหรับแต่ละความล้มเหลวที่ได้รับการคัดแยกแล้ว:
- กรณีทดสอบใดที่ล้มเหลว
- คุณจัดประเภทสาเหตุหลักของปัญหาเป็นประเภทใด
- เกิดอะไรขึ้นโดยเฉพาะเจาะจง
- สิ่งที่คุณเปลี่ยนเพื่อแก้ไข
- การแก้ไขได้ผลหรือไม่
สำหรับความล้มเหลวที่ยังไม่ได้รับการแก้ไข ให้บันทึกด้วย:
- สิ่งที่คุณพยายามจนถึงตอนนี้
- เหตุใดจึงยังไม่ได้รับการแก้ไข
- เมื่อใดที่ควรประเมินใหม่ (เช่น "หลังจากอัปเดตแพลตฟอร์ม X")
เวิร์กโฟลว์การปรับปรุงอย่างต่อเนื่อง
ใช้รายการตรวจสอบนี้หลังแต่ละขั้นตอนการคัดแยกและการแก้ไขเพื่อให้แน่ใจว่าคุณได้บันทึกผลลัพธ์และขั้นตอนถัดไปแล้ว
รายการตรวจสอบหลังการวนซ้ำ
| เสร็จสมบูรณ์หรือไม่ | งาน |
|---|---|
| ✓ | บันทึกความล้มเหลวที่ผ่านการคัดแยกทั้งหมดในบันทึกความล้มเหลว |
| ✓ | ระบุและบันทึกการกระจุกตัวของสาเหตุที่แท้จริง |
| ✓ | ตรวจสอบรูปแบบข้ามสัญญาณ |
| ✓ | บันทึกคะแนนสำหรับการติดตามแนวโน้ม |
| ✓ | ระบุข้อจำกัดที่ทราบพร้อมวิธีแก้ไขปัญหา |
| ✓ | ระบุลำดับความสำคัญของรอบถัดไปตามความล้มเหลวที่เหลืออยู่ |
| ✓ | จัดกำหนดการประเมินซ้ำ (ชุดการประเมินใดบ้าง และเมื่อใด) |
เมื่อใดที่ควรหยุดการวนซ้ำ
หยุดการวนซ้ำเมื่อ:
- ชุดการประเมินทั้งหมดผ่านเกณฑ์ที่กำหนด
- ได้มีการบันทึกช่องว่างที่พบแล้ว
- คะแนนสอดคล้องกัน (ผลต่าง < 5%)
- ไม่มีปัญหาการกำหนดค่าเอเจนต์ที่ยังไม่ได้แก้ไขซึ่งส่งผลต่อสัญญาณที่บล็อก
อย่าหยุดการวนซ้ำเมื่อ:
- คุณไม่ได้ตรวจสอบความล้มเหลวอย่างต่อเนื่อง
- คุณลบกรณีทดสอบที่ยากออกเพื่อให้ถึงเกณฑ์
- คุณไม่ได้จัดทำเอกสารข้อจำกัดของแพลตฟอร์ม
ดูข้อมูลเพิ่มเติมในหัวข้อการกำหนดว่าเมื่อใดที่การทำซ้ำเสร็จสมบูรณ์
ขั้นตอนถัดไป
- ทบทวนตัวอย่างที่ใช้งานได้จริง ซึ่งแสดงให้เห็นว่าชั้นต่าง ๆ ของเฟรมเวิร์กทำงานร่วมกันอย่างไรในสถานการณ์จริง
- ใช้ เทมเพลตบันทึกความล้มเหลว เพื่อติดตามผลการวิเคราะห์ของคุณ