กำไร:
- ความสามารถในการรับรู้สาเหตุเงียบ ๆ ของการเสื่อมสภาพของแบบจำลอง (การเบี่ยงเบนของข้อมูล การเบี่ยงเบนของแนวคิด ข้อผิดพลาดต้นทาง) และสร้างการตรวจสอบสามชั้น (การปฏิบัติงาน อินพุต และเอาต์พุต)
- ความสามารถในการประเมินระบบ LLM ในหลายเลเยอร์ด้วยการตรวจสอบกฎ ผู้ตัดสิน LLM และการประเมินโดยมนุษย์ และปรับเทียบด้วยจุดยึดมนุษย์ของผู้ตัดสิน LLM
- ความสามารถในการออกแบบชุด eval ที่มี Edge และกล่องความปลอดภัย และเปลี่ยนข้อผิดพลาดที่ตรวจพบแต่ละรายการให้เป็นกรณีทดสอบถาวร
เมื่อแบบจำลองเข้าสู่การผลิต งานของคุณยังไม่เสร็จสิ้น ความรับผิดชอบที่แท้จริงเพิ่งเริ่มต้นขึ้น เพราะโมเดลสามารถพังอย่างเงียบๆ เมื่อไม่มีใครมอง ในหน่วยนี้ เราครอบคลุมสองสาขาวิชาเสริม: การประเมิน (การวัดคุณภาพของแบบจำลองอย่างเป็นระบบ) และการติดตาม (การตรวจสอบแบบจำลองในการผลิตอย่างต่อเนื่อง) โดยเฉพาะอย่างยิ่งในระบบ LLM การประเมินจะยากกว่าและต้องการการดูแลมากกว่า ML แบบคลาสสิก
ทำไมโมเดลการผลิตถึงพังทลายลงอย่างเงียบๆ
บั๊กขัดข้อง พิมพ์บันทึก สัญญาณเตือนดับลง ในทางกลับกัน โมเดล ML อาจผิดพลาดได้โดยไม่ทำให้เกิดข้อผิดพลาด สาเหตุหลักสามประการของการเสื่อมสภาพ:
- การเคลื่อนตัวของข้อมูล: การกระจายของข้อมูลอินพุตที่เปลี่ยนแปลงไปตามกาลเวลา (ผลิตภัณฑ์ใหม่ พฤติกรรมผู้ใช้ที่เปลี่ยนแปลง ฤดูกาล) โมเดลยังคงเหมือนเดิมแต่โลกเปลี่ยนไป
- แนวคิดล่องลอย: ความสัมพันธ์ระหว่างอินพุตและเอาท์พุตเปลี่ยนไป กลยุทธ์การฉ้อโกงและรูปแบบสแปมมีวิวัฒนาการ สิ่งที่ถูกต้องเมื่อวานก็จะผิดในวันนี้
- ความเสียหายต้นทาง: แหล่งข้อมูลเปลี่ยนรูปแบบ พื้นที่กลายเป็นอิสระ โมเดลน้ำลายไหลอย่างเงียบๆ ด้วยอินพุตที่เสียหาย
การติดตามกำลังทำให้การบิดเบือนแบบเงียบๆ เหล่านี้สามารถได้ยินได้
สิ่งที่ต้องดู: สามชั้น
การตรวจสอบที่ดีครอบคลุมสามชั้น:
- ตัวชี้วัดการดำเนินงาน: เวลาแฝง อัตราข้อผิดพลาด ปริมาณคำขอ การใช้ทรัพยากร “ระบบอยู่หรือเปล่า?”
- ตัวชี้วัดข้อมูล/อินพุต: การกระจายอินพุตคล้ายกับในการฝึกอบรมหรือไม่ อัตรามูลค่าที่หายไปเพิ่มขึ้นหรือไม่? มีหมวดหมู่ใหม่มาถึงแล้วหรือยัง? “แบบจำลองเห็นข้อมูลที่คุ้นเคยหรือไม่”
- ตัวชี้วัดโมเดล/เอาท์พุต: บันทึกการกระจายการคาดการณ์? คะแนนความมั่นใจลดลงไหม? และถ้าเป็นไปได้ อะไรคือความแม่นยำเมื่อเทียบกับความจริงภาคพื้นดิน? “แบบจำลองยังแม่นยำอยู่หรือไม่”
ชั้นที่สามเป็นชั้นที่มีค่าที่สุดแต่ชั้นที่ยากที่สุด เพราะผลที่แท้จริงมักจะมาพร้อมกับความล่าช้า (จะชัดเจนหลังจากผ่านไปหลายเดือนว่าจะชำระคืนเงินกู้ได้หรือไม่)
เคล็ดลับ: หากผลลัพธ์จริงล่าช้า ให้ตรวจสอบอินพุตและการแจกแจงการคาดการณ์ก่อน การเปลี่ยนแปลงของการกระจายอินพุตเป็นสัญญาณเริ่มต้นของการลดความแม่นยำ และสามารถสร้างสัญญาณเตือนได้โดยไม่ต้องรอผลลัพธ์ที่แท้จริง
การประเมินระบบ LLM: ความท้าทายพิเศษ
ใน ML แบบคลาสสิก "คำตอบที่ถูกต้อง" นั้นชัดเจน (คลาส 0 หรือ 1) ในทางกลับกัน ผลลัพธ์ของ LLM เป็นแบบปลายเปิด: อาจมีคำตอบที่ถูกต้องมากมายสำหรับคำถามเดียวกัน "ความถูกต้อง" ไม่พอดีกับตัวเลขตัวเดียว แนวทางการประเมิน LLM:
- ตัวชี้วัดอ้างอิง: การเปรียบเทียบผลลัพธ์กับคำตอบในอุดมคติ จำกัด; เพราะอาจถือว่าคำตอบที่ถูกต้องแสดงออกมาต่างกันว่า "ผิด"
- การตรวจสอบตามกฎ: เอาต์พุต JSON ถูกต้องหรือไม่ มีคำต้องห้ามมั้ย? มีฟิลด์ที่ต้องการหรือไม่? ราคาถูกเชื่อถือได้แน่น
- LLM-judge (LLM-ในฐานะผู้พิพากษา): อย่าให้แบบจำลองถามว่า "คำตอบนี้ดีตามเกณฑ์นี้หรือไม่" มันปรับขนาดได้ แต่ผู้ตัดสินจะต้องได้รับการตรวจสอบ
- การตรวจสอบโดยมนุษย์: มาตรฐานระดับ Gold แต่มีราคาแพงและช้า มันถูกใช้กับตัวอย่าง
ในทางปฏิบัติจะใช้สิ่งเหล่านี้ร่วมกัน: การตรวจสอบกฎราคาถูกในแต่ละเอาท์พุต, LLM-ตัดสินกับตัวอย่างขนาดใหญ่, การประเมินโดยมนุษย์กับตัวอย่างขนาดเล็กแต่เข้มงวด
แนวทางที่อ่อนแอ / แนวทางที่แข็งแกร่ง
อ่อนแอ: "LLM-ฉันถามกรรมการแล้ว 92% ของคำตอบของเรานั้นดี ระบบดีมาก"
Güçlü: "เราเริ่มงานพิมพ์ที่ติดป้ายกำกับโดยมนุษย์ 100 ชิ้นแรก เราดำเนินการจัดพิมพ์ LLM-ผู้พิพากษาด้วยงานพิมพ์เดียวกัน 100 ชิ้นและวัดผลข้อตกลงระหว่างผู้พิพากษากับมนุษย์ — 85% ถือว่ายอมรับได้ เราบันทึกจุดที่ผู้พิพากษาทำผิดอย่างเป็นระบบ (แนวโน้มที่จะค้นหาคำตอบยาวๆ ที่ดีอย่างไม่ยุติธรรม) และแก้ไขการโต้ตอบของเขา เมื่อนั้นเท่านั้นที่เราเชื่อถือคะแนนของผู้พิพากษา"
ความแตกต่าง: วิธีการที่เข้มงวดจะตรวจสอบผู้ตัดสินด้วยจุดยึดที่เป็นมนุษย์ ไม่ใช่สุ่มสี่สุ่มห้า ผู้ตัดสิน LLM ที่ไม่ได้รับการยืนยันให้ความมั่นใจที่ดูดีแต่ผิดพลาด
ข้อควรสนใจ: ผู้ตัดสิน LLM ก็เป็นตัวอย่างเช่นกัน มีอาการประสาทหลอน มีอคติ (ชอบคำตอบที่ยาว/มั่นใจ) อาจไม่สอดคล้องกัน ปรับเทียบคะแนนผู้ตัดสินด้วยแท็กมนุษย์ก่อนตัดสินใจในการผลิต
ชุดการประเมินผล: ออกแบบมาอย่างพิถีพิถัน
ชุดการประเมินที่ดีแสดงถึงความหลากหลายของการใช้งานจริงและกรณีที่ยากลำบาก การประเมินที่เต็มไปด้วยตัวอย่างง่ายๆ จะทำให้คุณตกอยู่ในความมั่นใจที่ผิดพลาด อย่าลืมวางไว้ในคลัสเตอร์ eval:
- กรณี Edge: อินพุตว่างเปล่า อินพุตยาวมาก มีรูปแบบที่ผิดปกติ
- กรณียากที่ทราบ: ตัวอย่างที่แบบจำลองเคยทำผิดพลาดในอดีต (เป็นการทดสอบการถดถอย)
- เหตุการณ์ด้านความปลอดภัย: ความพยายามฉีดข้อมูลทันที คำขอที่เป็นอันตราย กับดักการละเมิดความเป็นส่วนตัว
คลัสเตอร์การประเมินจะเติบโตขึ้นเมื่อเวลาผ่านไป: แต่ละจุดบกพร่องใหม่ที่คุณตรวจพบในการใช้งานจริงจะกลายเป็นกรณีทดสอบสำหรับการประเมินครั้งต่อไป
สัญญาณเตือนและการแทรกแซง
การตรวจสอบยังคงไม่สมบูรณ์หากไม่มีสัญญาณเตือน ควรมีเกณฑ์และแผนการตอบสนองสำหรับตัวชี้วัดที่สำคัญแต่ละรายการ: "แจ้งวิศวกรหากอินพุตเบี่ยงเบนเกิน X", "ย้อนกลับอัตโนมัติหากอัตราข้อผิดพลาดเกิน Y" รักษาการแจ้งเตือนให้มีความหมาย — การแจ้งเตือนที่ผิดพลาดมากเกินไปจะทำให้ทีมหมดสติและทำให้พวกเขาพลาดสัญญาณเตือนที่แท้จริง
มินิเคสสามอัน
กรณีที่ 1 - การเตือนภัยล่วงหน้า ความแม่นยำที่แท้จริงของแบบจำลองการคาดการณ์ความต้องการจะปรากฏให้เห็นในช่วงปลายสัปดาห์เท่านั้น ทีมงานกำลังตรวจสอบการกระจายอินพุตและพบว่าหมวดหมู่ผลิตภัณฑ์ใหม่เพิ่มขึ้นอย่างกะทันหันในวันอังคาร ซึ่งเป็นสิ่งที่โมเดลไม่เคยเห็นมาก่อน พวกเขาอัปเดตโมเดลโดยไม่ต้องรอให้ความแม่นยำลดลง การตรวจสอบอินพุตวันที่บันทึกไว้
กรณีที่ 2 - ผู้ตัดสินที่ไม่ได้รับการยืนยัน ทีมหนึ่งรายงานว่า "คุณภาพของเรายอดเยี่ยม" โดยอิงจากผู้ตรวจสอบ LLM เมื่อข้อร้องเรียนจากลูกค้าเพิ่มมากขึ้น ได้มีการนำการตรวจสอบโดยมนุษย์เข้ามาใช้ โดยผู้ตัดสินนับคำตอบที่มั่นใจแต่ไม่ถูกต้องว่า "ดี" เมื่อผู้ตัดสินได้รับการปรับเทียบด้วยแท็กของมนุษย์ คุณภาพที่แท้จริงก็ปรากฏให้เห็นและต่ำกว่ามาก บทเรียน: อย่าเชื่อใจผู้ตัดสินโดยไม่ตรวจสอบ
กรณีที่ 3 - การทดสอบการถดถอย การเปลี่ยนแปลงทันทีช่วยแก้ไขปัญหาหนึ่งในขณะที่ทำลายอีกปัญหาหนึ่งอย่างเงียบๆ แต่ทีมเก็บข้อผิดพลาดในอดีตไว้ในกลุ่มการประเมิน เมื่อทดสอบการเปลี่ยนแปลงใหม่บนคลัสเตอร์นี้ เคสที่เสียหายจะถูกตรวจพบทันทีและการเปลี่ยนแปลงได้รับการแก้ไขแล้ว บทเรียน: ทุกจุดบกพร่องที่ได้รับการแก้ไขควรกลายเป็นกรณีทดสอบถาวร
เทมเพลตที่คัดลอกได้
จัดทำแผนการติดตามสำหรับแบบจำลองการผลิตนี้ ครอบคลุมสามชั้น:1) การปฏิบัติงาน (เวลาแฝง อัตราข้อผิดพลาด ปริมาณ)2) อินพุต/ข้อมูล (การเปลี่ยนแปลงการกระจาย ค่าที่หายไป หมวดหมู่ใหม่)3) โมเดล/เอาท์พุต (การกระจายการคาดการณ์ ความมั่นใจ ความแม่นยำ หากเป็นไปได้) รุ่น: [คำอธิบาย] ต้องใช้เวลานานเท่าใดกว่าผลลัพธ์จริงจะมาถึง: [ระยะเวลา]เพิ่มเกณฑ์และคำแนะนำการแทรกแซงสำหรับแต่ละเมตริก
เสนอกลยุทธ์การประเมิน (ประเมิน) สำหรับระบบ LLM นี้ งาน: [คำอธิบาย] กำหนดเลเยอร์:- การตรวจสอบตามกฎใดที่ควรใช้ในแต่ละเอาต์พุต - เกณฑ์ใดที่อนุญาโตตุลาการ LLM ควรประเมิน และควรตรวจสอบความถูกต้องอย่างไร (จุดยึดของมนุษย์) - ตัวอย่างใดที่ควรทำการประเมินโดยมนุษย์? แสดงรายการ Edge และกรณีด้านความปลอดภัยที่ฉันควรใส่ไว้ในชุดการประเมิน
ตรวจสอบพรอมต์ผู้ตัดสินของ LLM นี้:- เกณฑ์การประเมินชัดเจนหรือเป็นแบบอัตนัยหรือไม่- มีแนวโน้มที่จะมีอคติด้านความยาว/ความมั่นใจหรือไม่- ฉันจะปรับเทียบผู้ตัดสินด้วยแท็กของมนุษย์ได้อย่างไร พรอมต์ของผู้ตัดสิน: [พร้อมท์]
เขียนสมุดการตอบสนองสำหรับสัญญาณเตือนการตรวจสอบนี้ สัญญาณเตือน: [เช่น เกินเกณฑ์การเลื่อนอินพุต] ต้องมี: ขั้นตอนการควบคุมเริ่มต้น สาเหตุที่เป็นไปได้ เกณฑ์การย้อนกลับ ผู้ที่ต้องแจ้ง
ตารางสาเหตุการเสื่อมสภาพ
การบิดเบือน
อาการ
วิธีการตรวจพบตั้งแต่เนิ่นๆ
ข้อมูลดริฟท์
การเปลี่ยนแปลงการกระจายอินพุต
การตรวจสอบการกระจายอินพุต
การเปลี่ยนแนวคิด
ความชอบธรรมตกอยู่เงียบๆ
การทำนาย + การเปรียบเทียบตามจริง
ข้อผิดพลาดต้นน้ำ
ช่องว่างเปล่า/มีการเปลี่ยนแปลงรูปแบบ
การตรวจสอบสคีมา + อัตราที่ขาดหายไป
ความไม่สอดคล้องกันของโมเดล
การเปลี่ยนแปลงการกระจายเอาต์พุต
การตรวจสอบการกระจายเอาต์พุต
ข้อผิดพลาดทั่วไป
- ไม่จัดให้มีการตรวจติดตาม โมเดลพังเงียบๆ ไม่มีใครเห็น
- ติดตามตัวชี้วัดการดำเนินงานเท่านั้น ระบบพังแต่คำทำนายอาจผิดพลาดได้
- การใช้ LLM โดยไม่ตรวจสอบผู้ตัดสิน มันให้ความมั่นใจที่ผิดพลาด
- ประเมินด้วยตัวอย่างง่ายๆ มันไม่ได้บ่งบอกถึงความยากลำบากที่แท้จริง
- ไม่รวมข้อผิดพลาดในอดีตในการประเมิน ข้อผิดพลาดเดิมกลับมาอีกครั้ง
- สัญญาณเตือนดัง ทีมเริ่มหมดสติและพลาดสัญญาณเตือนภัยที่แท้จริง
โดยสรุป
โมเดลอาจคลาดเคลื่อนได้โดยไม่ทำให้เกิดข้อผิดพลาดในการผลิต ดังนั้นการประเมินและการติดตามจึงมีความสำคัญพอๆ กับการพัฒนา สร้างการตรวจสอบสามชั้น (ปฏิบัติการ อินพุต เอาท์พุต) ใช้การเบี่ยงเบนของอินพุตเป็นการเตือนล่วงหน้าหากผลลัพธ์จริงเกิดความล่าช้า ในระบบ LLM การประเมินเป็นแบบปลายเปิด ใช้การตรวจสอบกฎ ผู้ตัดสิน LLM และการประเมินโดยมนุษย์ร่วมกัน แต่ต้องแน่ใจว่าได้ตรวจสอบความถูกต้องของผู้ตัดสิน LLM ด้วยจุดยึดที่เป็นมนุษย์ เติมเต็มคลัสเตอร์ Eval ของคุณด้วย Edge และกรณีการรักษาความปลอดภัย และเปลี่ยนทุกข้อผิดพลาดที่ตรวจพบให้เป็นกรณีทดสอบถาวร
งานสมัคร
เขียนแผนการตรวจสอบสามชั้นสำหรับแบบจำลองการผลิต (หรือใกล้การผลิต) และกำหนดเกณฑ์ + สัญญาณเตือนสำหรับเมตริกการกระจายอินพุตอย่างน้อยหนึ่งตัว หากคุณมีระบบ LLM: แท็ก 30 เอาต์พุตด้วยมนุษย์ เรียกใช้ผู้ตัดสิน LLM บนเอาต์พุตเดียวกัน และวัดข้อตกลงระหว่างผู้ตัดสินที่เป็นมนุษย์ สังเกตอคติอย่างเป็นระบบของผู้ตัดสิน เพิ่มอย่างน้อย 3 Edge และ 2 เคสความปลอดภัยให้กับคลัสเตอร์ Eval ของคุณ
รายการตรวจสอบ
- [ ] การตรวจสอบครอบคลุมทั้งสามชั้น (การทำงาน อินพุต และเอาต์พุต)
- [ ] ฉันใช้การเบี่ยงเบนของอินพุตเป็นการเตือนล่วงหน้าหากผลลัพธ์ที่แท้จริงเกิดความล่าช้า
- [ ] ฉันปรับเทียบอนุญาโตตุลาการ LLM ด้วยป้ายกำกับของมนุษย์
- [ ] คลัสเตอร์ Eval ประกอบด้วย Edge และกล่องความปลอดภัย
- [ ] ฉันเปลี่ยนทุกข้อบกพร่องที่พบให้เป็นกรณีทดสอบถาวร
- [ ] แต่ละตัวชี้วัดที่สำคัญมีเกณฑ์และแผนการตอบสนอง