การตรวจสอบผลลัพธ์และการตรวจสอบโดยมนุษย์

กำไร:

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

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

เหตุใดจึงต้องมีการตรวจสอบผลลัพธ์?

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

ข้อควรระวัง: "แบบจำลองโดยทั่วไปมีความแม่นยำ" ไม่ใช่เกณฑ์ในการผลิต ในระบบที่ไม่มีการตรวจสอบ แม้แต่ข้อผิดพลาดหนึ่งในพันก็หมายถึงธุรกรรมที่ผิดพลาด 100 รายการต่อวันใน 100,000 คำขอต่อวัน

เลเยอร์ของการรับรองความถูกต้อง: ทีละขั้นตอน

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

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

โครงการ+"จัดไปถ้าไม่รู้" ร่วมกัน:

ส่งคืนการตอบกลับในสคีมา JSON ต่อไปนี้เท่านั้น: เขียน "ต่ำ" อย่าเขียนการประมาณการราวกับว่ามันเป็นค่าที่แน่นอน

การยืนยันด้วยรุ่นที่สอง (พร้อมท์จากผู้พิพากษา):

คุณเป็นผู้ตรวจสอบอิสระ ด้านล่างนี้เป็นข้อความ <source> และ <claim> ตรวจสอบเพื่อดูว่าทุกหมายเลขและวันที่ในการอ้างสิทธิ์เกิดขึ้นแบบคำต่อคำในแหล่งที่มาหรือไม่ สำหรับแต่ละรายการ ให้พูดว่า: "ตรวจสอบแล้ว | ไม่อยู่ในแหล่งที่มา | ขัดแย้งกับแหล่งที่มา" หากมีรายการใดรายการหนึ่ง 'ขาดหายไป/ขัดแย้งกัน' ให้ทำเครื่องหมายผลลัพธ์เป็น "จำเป็นต้องตรวจสอบโดยมนุษย์"<source>{{ text }}</source><claim>{{ model_output }}</claim>

กฎการกำหนดเส้นทางเกณฑ์การเชื่อถือ:

กฎการกำหนดเส้นทาง:- emin_misin = "สูง" และจำนวน < 10,000 TL -> การประมวลผลอัตโนมัติ- emin_misin = "ปานกลาง" หรือจำนวน 10,000-100,000 TL -> การตรวจสอบโมเดลที่สอง- emin_misin = "ต่ำ" หรือจำนวน > 100,000 TL -> ต้องได้รับการอนุมัติจากมนุษย์

การ์ดสรุปการตรวจสอบบุคคล (เร่งการตรวจสอบ):

เมื่อนำเสนอการตัดสินใจต่อบุคคล ให้แสดงการ์ดใบนี้:- จะมีการเสนออะไรบ้าง? (หนึ่งประโยค)- อ้างอิงจากแหล่งที่มาใด? (อ้างอิงบทความ/เอกสาร)- 2 สมมติฐานที่อ่อนแอที่สุดคืออะไร- หากอนุมัติแล้วสามารถย้อนกลับได้หรือไม่? (ใช่/ไม่ใช่)

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

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

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

"ลบจำนวนเงินออกจากใบแจ้งหนี้" (ข้อความอิสระ)

สคีมา JSON ที่เข้มงวด + ฟิลด์ null + ความน่าเชื่อถือ

เขียนผลลัพธ์โดยตรงไปยังระบบการชำระเงิน

สคีมา → กฎ → การอนุมัติโดยมนุษย์ (หากจำเป็น)

แค่บอกรุ่นว่า "มั่นใจ"

การตรวจสอบหมายเลข/วันที่ด้วยรุ่นที่สอง

ประมวลผลทุกเอาต์พุตด้วยความมั่นใจที่เท่าเทียมกัน

การกำหนดเส้นทางขึ้นอยู่กับอิทธิพลและความไว้วางใจ

แนวทางที่รัดกุมไม่ได้หวังว่าแบบจำลองนั้นถูกต้อง มันสร้างประตูที่จะจับคุณเมื่อคุณทำผิด

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

กรณีที่ 1 — โครงการเพียงอย่างเดียวไม่เพียงพอ ระบบบัญชีอัตโนมัติกำลังแยกยอดเงินจากใบแจ้งหนี้เป็น JSON โครงการถูกต้อง แต่แบบจำลองสร้าง "125,000" แทนที่จะเป็น "1,250.00" ในใบแจ้งหนี้ (การเปลี่ยนแปลงทศนิยม) โครงการนี้ล้มเหลวในการจับภาพนี้ การตรวจสอบความถูกต้องของกฎ ("จำนวนเงินจะต้องสอดคล้องกับยอดรวมของรายการใบแจ้งหนี้โดย ±1%)" ตรวจพบและป้องกันการบันทึกที่ไม่ถูกต้องจำนวน 112,500 TL

กรณีที่ 2 — โมเดลที่สองจับภาพหลอนได้ “การแจ้งการยกเลิก 30 วัน” ผู้ช่วยฝ่ายสนับสนุนทางกฎหมายกล่าวในสรุปสัญญา อย่างไรก็ตามในสัญญามีระยะเวลา 90 วัน เมื่อผู้พิพากษาอิสระตั้งค่าสถานะโมเดลว่า "ขัดแย้งกับแหล่งที่มา" ผลลัพธ์จะถูกส่งต่อไปยังมนุษย์และแก้ไข หากเป็นแบบอัตโนมัติลูกค้าจะแจ้งการยกเลิกตามวันที่ที่ไม่ถูกต้อง

กรณีที่ 3 — การกำหนดเส้นทางลดภาระลง 70% ระบบการเคลมประกันจะอนุมัติการเคลมในจำนวนต่ำและมีความปลอดภัยสูงโดยอัตโนมัติ และส่งเฉพาะการเคลมที่สูงกว่าเกณฑ์/มีความปลอดภัยต่ำไปยังผู้เชี่ยวชาญเท่านั้น จากความต้องการ 3,200 ครั้งต่อวัน มีเพียง 950 รายการที่ตกลงสู่มนุษย์ ผู้เชี่ยวชาญทุ่มเทเวลาให้กับผู้ที่มีความเสี่ยงอย่างแท้จริง 30% โดยเวลาการทำธุรกรรมโดยเฉลี่ยลดลงจาก 4 ชั่วโมงเหลือ 40 นาที

เคล็ดลับ: อย่าตั้งค่าการควบคุมโดยมนุษย์เพื่อให้ "ผู้คนสามารถมองเห็นทุกสิ่งได้" เพราะจะทำให้ผู้คนเบื่อหน่าย และการอนุมัติจะกลายเป็นตรายาง แต่ให้กำหนดเส้นทางเฉพาะผลลัพธ์ที่มีผลกระทบสูงและความมั่นใจต่ำไปยังมนุษย์เท่านั้น สิ่งนี้เน้นความสนใจไปที่สิ่งที่สำคัญจริงๆ

ทำให้การควบคุมของมนุษย์มีความหมาย

Human-in-the-loop ไม่ได้เกี่ยวกับการใส่ช่องทำเครื่องหมายลงบนกระดาษ ผู้ตรวจสอบต้องมี (1) บริบทในการทำความเข้าใจการตัดสินใจ (2) การเข้าถึงแหล่งที่มา และ (3) อำนาจในการพูดว่า "ไม่" มิฉะนั้นการควบคุมยังคงเป็นเครื่องสำอาง การ์ดตรวจสอบ (เทมเพลตที่สี่ด้านบน) มีไว้เพื่อให้บริบทนั้นเท่านั้น

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

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

โดยสรุป

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

งานสมัคร

ยกตัวอย่างจากเอาท์พุต AI ของคุณเอง ขั้นแรก ให้กำหนดสคีมา JSON และบังคับเอาต์พุตไปที่สคีมานั้น จากนั้นเขียนกฎเกณฑ์ทางธุรกิจอย่างน้อยสองข้อ (เช่น "จำนวนตรงกับผลรวมของรายการ") สุดท้าย ให้ตั้งค่าตารางเส้นทาง: ชุดค่าผสมของความไว้วางใจ/อิทธิพลใดจะไปโดยอัตโนมัติ ชุดใดไปที่รุ่นที่สอง ชุดใดไปที่มนุษย์ สร้างตัวอย่างที่ผิดพลาดและสังเกตว่าแต่ละชั้นจับตัวอย่างได้ที่ใด

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

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