หน่วย 9 / 11

การตรวจสอบอย่างต่อเนื่อง การสังเกต และการดริฟท์

กำไร:

  • ความสามารถในการกำหนดตัวชี้วัดที่ตรวจสอบการใช้งาน ความปลอดภัย คุณภาพ และสัญญาณประสิทธิภาพ
  • ความสามารถในการตรวจจับการเบี่ยงเบนของคุณภาพเอาต์พุตด้วยการตรวจวัดพื้นฐานและการสุ่มตัวอย่าง
  • ความสามารถในการตั้งค่าลูปการเตือนและการตอบสนองสำหรับความผิดปกติและคลื่นการเจลเบรค

การนำระบบ AI มาใช้จริงถือเป็นจุดเริ่มต้น ไม่ใช่จุดสิ้นสุด แม้ว่าโมเดลจะยังคงเหมือนเดิม แต่โลกก็เปลี่ยนไป: พฤติกรรมผู้ใช้ ข้อมูลขาเข้า เทคนิคการโจมตี และบริบททางธุรกิจมีการเปลี่ยนแปลงอยู่ตลอดเวลา ตอบถูกเมื่อวานอาจจะผิดวันนี้ ดังนั้นเสาหลักสุดท้ายของการรักษาความปลอดภัยคือการตรวจสอบและการสังเกตอย่างต่อเนื่อง — ความสามารถในการมองเห็นจากภายนอกว่าเกิดอะไรขึ้นภายในระบบ ในหน่วยนี้ เราจะเรียนรู้ว่าเมตริกใดบ้างที่ต้องตรวจสอบ วิธีบันทึกการเบี่ยงเบนของคุณภาพเอาต์พุต และวิธีแจ้งเตือนความผิดปกติ

ทำไมต้องมีการตรวจสอบอย่างต่อเนื่อง?

ในซอฟต์แวร์คลาสสิก "มันใช้งานได้" เป็นคำถามไบนารี่ ไม่ว่าจะตอบหรือไม่ก็ตาม ใน AI แม้ว่าระบบดูเหมือนจะ "ทำงาน" แต่อาจเสื่อมลงอย่างเงียบๆ ได้ คำตอบจะค่อยๆ ไม่ถูกต้อง ค่าใช้จ่ายเพิ่มขึ้น ความพยายามในการเจลเบรกเพิ่มขึ้น วิธีเดียวที่จะจับสิ่งเหล่านี้ได้คือการวัดสัญญาณที่ถูกต้องอย่างต่อเนื่อง

ข้อควรพิจารณา: การทำงานที่อันตรายที่สุดคือการทำงานแบบเงียบ ไม่ใช่การทำงานที่มีเสียงดัง ระบบไม่เกิดข้อผิดพลาด แต่คุณภาพจะลดลงเท่านั้น หากคุณไม่ได้ตั้งค่าการตรวจสอบ บุคคลแรกที่สังเกตเห็นจะเป็นลูกค้าหรือผู้ตรวจสอบบัญชีของคุณ ไม่ใช่คุณ

สี่ครอบครัวสัญญาณที่น่าจับตามอง

  • การใช้งานและต้นทุน: ปริมาณคำขอ การใช้โทเค็น ต้นทุนต่อผู้ใช้ กระโดดกะทันหัน; อาจเป็นสัญญาณของการละเมิด การผสานรวมที่วนซ้ำ หรือสวิตช์ที่รั่ว
  • สัญญาณความปลอดภัย: การพยายามแหกคุก/การฉีดยา, การเรียกรถถูกปฏิเสธ, ข้อผิดพลาดในการอนุญาต การเพิ่มขึ้นอาจบ่งบอกถึงแคมเปญการโจมตีที่ทำงานอยู่
  • คุณภาพและการดริฟท์: คุณภาพผลผลิตลดลงเมื่อเวลาผ่านไป (ดริฟท์) ตัวอย่างเช่น อัตราการผ่านการตรวจสอบ อัตราการแก้ไขในการอนุมัติของมนุษย์ ความพึงพอใจของผู้ใช้
  • ประสิทธิภาพ: เวลาแฝง อัตราข้อผิดพลาด หมดเวลา มันส่งผลโดยตรงต่อประสบการณ์ผู้ใช้และต้นทุน

Drift คืออะไรและจะจับมันได้อย่างไร?

การดริฟท์คือการที่คุณภาพของอินพุตหรือเอาท์พุตของโมเดลเปลี่ยนไปโดยไม่มีใครสังเกตเห็นเมื่อเวลาผ่านไป มีสองประเภท: การเลื่อนข้อมูล (การกระจายของคำขอที่เข้ามาเปลี่ยนแปลง - หัวข้อใหม่ ภาษาใหม่) และการเลื่อนคุณภาพ (ผลลัพธ์สำหรับงานเดียวกันจะค่อยๆ แย่ลง) จำเป็นต้องมีพื้นฐานในการจับภาพ: บันทึกช่วงปกติของการวัดเมื่อระบบแข็งแรง ปล่อยให้ความเบี่ยงเบนกลายเป็นสัญญาณเตือน

ทีละขั้นตอน: การตั้งค่าการตรวจสอบ

  1. วัดพื้นฐาน. บันทึกช่วงปกติของแต่ละสัญญาณเมื่อระบบแข็งแรง
  2. กำหนดเกณฑ์และการเตือน ส่วนเบี่ยงเบนใดจะเตือนใครและอย่างไร?
  3. การสุ่มตัวอย่าง + การตรวจสอบโดยมนุษย์ ให้มนุษย์ตรวจสอบตัวอย่างผลลัพธ์อย่างสม่ำเสมอ (การเคลื่อนตัวของคุณภาพมักจะมองเห็นได้เพียงเท่านั้น)
  4. ติดตั้งแดชบอร์ด ตรวจสอบตระกูลสัญญาณสี่ตระกูลบนหน้าจอเดียว
  5. ห่วงข้อเสนอแนะ เชื่อมโยงข้อค้นพบจากการติดตามไปจนถึงการปรับปรุงพร้อมท์/การควบคุม

เทมเพลตที่คัดลอกได้สี่แบบ

พร้อมท์การประเมินการสุ่มตัวอย่างคุณภาพ (การติดตามการดริฟท์ด้วย LLM-ในฐานะผู้ตัดสิน):

ด้านล่างนี้คือ 20 รายการพิมพ์แบบสุ่มจากสัปดาห์นี้ ให้คะแนนแต่ละรายการว่า "ดี / ยอมรับ / ไม่ดี" และเขียนเหตุผลสั้นๆ สุดท้ายผมจะเปรียบเทียบอัตราที่เสียกับอัตราของสัปดาห์ที่แล้ว หากมีรูปแบบ (การเกิดซ้ำของข้อผิดพลาดประเภทเดียวกัน) ที่โดดเด่นในสัปดาห์นี้ ให้ทำเครื่องหมายไว้<outputs>{{ examples }}</outputs>

พร้อมท์สรุปความผิดปกติ:

ตรวจสอบตัวชี้วัดรายวันต่อไปนี้: จำนวนคำขอ โทเค็น ต้นทุน การเรียกเครื่องมือถูกปฏิเสธ ความพยายามในการเจลเบรก เวลาแฝงโดยเฉลี่ย ทำเครื่องหมายเมตริกใดๆ ที่เบี่ยงเบนมากกว่า 30% จากเส้นพื้นฐานเป็น "ความผิดปกติ" และประเมินสาเหตุที่เป็นไปได้ (การโจมตี บั๊ก การละเมิด)<metrics>{{ daily_data }}</metrics>

กฎการกำหนดเกณฑ์การเตือน:

กำหนดการเตือนสำหรับแต่ละสัญญาณ: - ค่าใช้จ่าย: หากเกินค่าเฉลี่ยรายวัน 2 เท่า -> การแจ้งเตือนที่มีลำดับความสำคัญสูง - ความพยายามในการเจลเบรก: หากเกิน 10 ต่อชั่วโมง -> แจ้งทีมรักษาความปลอดภัย - อัตราการส่งผ่านการตรวจสอบ: หากต่ำกว่า 90% -> การตรวจสอบคุณภาพ - เวลาแฝง: หาก p95 เกินเป้าหมาย 2 เท่า -> การตรวจสอบประสิทธิภาพ

พรอมต์การวิจัยดริฟท์:

อัตราการผ่านการยืนยันลดลงจาก 94% เป็น 78% ในช่วง 2 สัปดาห์ที่ผ่านมา ช่วยฉันตอบคำถามเหล่านี้: (1) มีหัวข้อ/ภาษา/รูปแบบใหม่ปรากฏในคำขอที่เข้ามาหรือไม่ (2) ข้อผิดพลาดกระจุกตัวอยู่ในหมวดหมู่ใดหมวดหนึ่งโดยเฉพาะหรือไม่ (3) ระยะเวลาตรงกับการเปลี่ยนแปลงพรอมต์/รุ่น/เครื่องมือหรือไม่? ตั้งชื่อข้อมูลที่จะตรวจสอบสำหรับแต่ละรายการ

พรอมต์ที่อ่อนแอ / พรอมต์ที่แข็งแกร่ง

วิธีการที่ไม่ดี

แนวทางที่แข็งแกร่ง

“หากมีข้อผิดพลาดเราจะได้ดู”

ค่าพื้นฐาน + เกณฑ์ + สัญญาณเตือนเชิงรุก

แค่ตรวจสอบว่าระบบยังอยู่หรือไม่

การตรวจสอบสัญญาณสี่กลุ่ม (การใช้งาน ความปลอดภัย คุณภาพ ประสิทธิภาพ)

ไม่สุ่มตัวอย่างคุณภาพผลผลิตเลย

การสุ่มตัวอย่างโดยมนุษย์ตามปกติ + LLM-ในฐานะผู้ตัดสิน

ไม่รวบรวมและดูตัวชี้วัด

แดชบอร์ด + ลูปข้อเสนอแนะ

มินิเคสสามอัน

กรณีที่ 1 — สัญญาณเตือนค่าใช้จ่ายตรวจพบกุญแจรั่ว ต้นทุนโทเค็นรายวันของบริษัทเพิ่มขึ้นสามเท่าในชั่วข้ามคืน การแจ้งเตือนเกณฑ์แจ้งเตือนทีมรักษาความปลอดภัย การสอบสวนพบว่ารหัสทดสอบรั่วไหลและถูกใช้โดยบอท กุญแจถูกเพิกถอนใน 25 นาที; หากไม่มีสัญญาณเตือนภัย บิลจะถูกสังเกตเห็นตอนสิ้นเดือน

กรณีที่ 2 — การดริฟท์แบบไร้เสียง อัตราการส่งผ่านการตรวจสอบของผู้ช่วยฝ่ายสนับสนุนลดลงอย่างเงียบๆ จาก 95% เป็น 80% ในสามสัปดาห์ การสุ่มตัวอย่างรายสัปดาห์จับสิ่งนี้ เหตุผลก็คือลูกค้าเริ่มถามเกี่ยวกับสายผลิตภัณฑ์ใหม่และฐานความรู้ของโมเดลนั้นไม่สมบูรณ์ อัตราการกู้คืนเมื่อมีการอัปเดตฐานความรู้

กรณีที่ 3 — คลื่นการแหกคุกเกิดขึ้นเร็ว ความพยายามในการฉีดยาใส่ผู้ช่วยเพิ่มขึ้นจาก 2 เป็น 40 ต่อชั่วโมงในหนึ่งวัน สัญญาณเตือนภัยถูกกระตุ้น; พบว่ามีการแชร์ "สูตร" สำหรับการแคร็กระบบในฟอรัม ทีมงานได้อัปเดตบัญชีที่น่าสงสัยพร้อมท์การป้องกันและจำกัดอัตรา คลื่นสงบลงก่อนที่จะกลายเป็นรอยรั่วจริง

เคล็ดลับ: อย่าชำระเพียงเมตริกของเครื่องจักร การเบี่ยงเบนของคุณภาพมักเกิดขึ้นได้จากการให้มนุษย์อ่านผลลัพธ์ของตัวอย่าง กิจวัตรเล็กๆ ในการตรวจสอบงานพิมพ์แบบสุ่ม 15-20 ชิ้นต่อสัปดาห์จะตรวจพบข้อผิดพลาดที่มีราคาแพงที่สุดตั้งแต่เนิ่นๆ

ข้อผิดพลาดทั่วไป

  • ไม่นำไปปฏิบัติจริงและตั้งค่าการตรวจสอบ ("ใช้งานได้ โอเค")
  • ไม่สามารถระบุความผิดปกติได้โดยไม่ต้องวัดค่าพื้นฐาน
  • พลาดดริฟท์คุณภาพโดยดูแค่ว่า "มันยืนไหว" หรือเปล่า
  • ไม่ได้สุ่มตัวอย่างคุณภาพผลผลิตผ่านสายตามนุษย์เลย
  • ไม่ส่งสัญญาณเตือนและทราบปัญหาจากลูกค้า/หัวหน้างาน
  • ไม่เชื่อมโยงผลการตรวจสอบกับการปรับปรุง (ไม่มีการวนซ้ำผลตอบรับ)

โดยสรุป

  • ระบบ AI อาจเสื่อมลงอย่างเงียบๆ ความผิดปกติที่อันตรายที่สุดคือการทำงานที่ไม่ทำให้เกิดข้อผิดพลาด แต่จะลดคุณภาพลงเท่านั้น
  • ติดตามสัญญาณสี่กลุ่ม: การใช้งาน/ต้นทุน ความปลอดภัย คุณภาพ/การดริฟท์ และประสิทธิภาพ
  • การดริฟท์ (การดริฟท์ของคุณภาพอินพุตหรือเอาท์พุตในช่วงเวลาหนึ่ง) จะถูกบันทึกเมื่อเปรียบเทียบกับค่าพื้นฐานเท่านั้น
  • การสุ่มตัวอย่างโดยมนุษย์เป็นประจำนอกเหนือจากหน่วยเมตริกของเครื่องจักรจะบันทึกการเคลื่อนตัวของคุณภาพ
  • เชื่อมต่อการตรวจสอบเข้ากับลูปสัญญาณเตือนและฟีดแบ็ค การวัดและการไม่มองไม่ใช่การติดตาม

งานสมัคร

เลือกอย่างน้อยหนึ่งตัววัดจากแต่ละกลุ่มสัญญาณจากสี่กลุ่มสัญญาณสำหรับระบบ AI ของคุณเอง และจดบันทึกข้อมูลพื้นฐานปัจจุบัน (หรือโดยประมาณ) กำหนดเกณฑ์การแจ้งเตือนสำหรับแต่ละเมตริก จากนั้นนำผลลัพธ์ของภาคการศึกษาสุดท้ายของคุณ 15 รายการมาให้คะแนนตามข้อความแจ้งการสุ่มตัวอย่างด้านบน สังเกตอัตรา "ไม่ดี" ให้นี่เป็นพื้นฐานแรกของคุณเพื่อเปรียบเทียบการดริฟท์ในอนาคต

รายการตรวจสอบ

  • [ ] ฉันกำหนดหน่วยเมตริกจากกลุ่มสัญญาณสี่กลุ่ม (การใช้งาน ความปลอดภัย คุณภาพ ประสิทธิภาพ)
  • [ ] ฉันตั้งค่าพื้นฐานและเกณฑ์การเตือนสำหรับแต่ละเมตริก
  • [ ] ฉันสุ่มตัวอย่างคุณภาพผลงานผ่านสายตามนุษย์เป็นประจำ
  • [ ] ฉันตรวจสอบสัญญาณบนหน้าจอเดียวด้วยแผงจอแสดงผล
  • [ ] สัญญาณเตือนไปที่ทีมรักษาความปลอดภัยสำหรับความผิดปกติและการแหกคุก
  • [ ] ฉันถือว่าผลการตรวจสอบเป็นผลจากการปรับปรุงพร้อมท์/การควบคุม