คำตอบสั้นๆ: กำหนดว่า “ดี” สำหรับกรณีการใช้งานของคุณนั้นหมายถึงอะไร จากนั้นทดสอบด้วยข้อความแจ้งเตือนที่เป็นตัวแทนและมีการกำหนดเวอร์ชัน รวมถึงกรณีพิเศษต่างๆ จับคู่ตัวชี้วัดอัตโนมัติกับการให้คะแนนโดยมนุษย์ ควบคู่ไปกับการตรวจสอบความปลอดภัยจากภัยคุกคามและการตรวจสอบการแทรกข้อความแจ้งเตือน หากข้อจำกัดด้านต้นทุนหรือความหน่วงกลายเป็นสิ่งสำคัญ ให้เปรียบเทียบโมเดลโดยพิจารณาจากความสำเร็จของงานต่อปอนด์ที่ใช้ไป และเวลาตอบสนอง p95/p99
ประเด็นสำคัญ:
ความรับผิดชอบ : กำหนดผู้รับผิดชอบที่ชัดเจน เก็บรักษาบันทึกเวอร์ชัน และเรียกใช้การประเมินซ้ำหลังจากมีการเปลี่ยนแปลงข้อความแจ้งเตือนหรือแบบจำลองใดๆ
ความโปร่งใส : เขียนเกณฑ์ความสำเร็จ ข้อจำกัด และต้นทุนของความล้มเหลวก่อนเริ่มเก็บรวบรวมคะแนน
ความสามารถในการตรวจสอบ : รักษาชุดทดสอบที่ทำซ้ำได้ ชุดข้อมูลที่มีการติดป้ายกำกับ และตัวชี้วัดความหน่วง p95/p99 ที่ติดตามได้
ความสามารถในการโต้แย้ง : ใช้เกณฑ์การประเมินโดยมนุษย์และขั้นตอนการอุทธรณ์ที่กำหนดไว้สำหรับผลลัพธ์ที่มีข้อโต้แย้ง
การต้านทานการใช้งานในทางที่ผิด : การโจมตีแบบ Red-team prompt injection, หัวข้อที่ละเอียดอ่อน และการปฏิเสธที่จะปกป้องผู้ใช้มากเกินไป
ถ้าคุณกำลังเลือกโมเดลสำหรับผลิตภัณฑ์ โครงการวิจัย หรือแม้แต่เครื่องมือภายในองค์กร คุณไม่สามารถแค่คิดว่า “มันฟังดูฉลาดดี” แล้วก็ใช้งานได้เลย (ดู คู่มือการประเมินของ OpenAI และ NIST AI RMF 1.0 ) นั่นแหละคือสาเหตุที่คุณจะได้แชทบอทที่อธิบายวิธีการใช้ไมโครเวฟกับส้อมได้อย่างมั่นใจ 😬
บทความที่คุณอาจสนใจอ่านต่อหลังจากบทความนี้:
🔗 อนาคตของ AI: แนวโน้มที่กำหนดทิศทางทศวรรษหน้า
นวัตกรรมสำคัญ ผลกระทบต่อการจ้างงาน และจริยธรรมที่ต้องจับตาดู
🔗 อธิบายโมเดลพื้นฐานใน AI เชิงสร้างสรรค์สำหรับผู้เริ่มต้น
เรียนรู้ว่าโมเดลเหล่านี้คืออะไร วิธีการฝึกฝน และเหตุใดจึงมีความสำคัญ
🔗 ปัญญาประดิษฐ์ส่งผลกระทบต่อสิ่งแวดล้อมและการใช้พลังงานอย่างไร
สำรวจการปล่อยมลพิษ ความต้องการใช้ไฟฟ้า และวิธีการลดผลกระทบต่อสิ่งแวดล้อม
🔗 เทคโนโลยี AI ช่วยเพิ่มความคมชัดของภาพได้อย่างไร
ดูว่าโมเดลเพิ่มรายละเอียด ลดสัญญาณรบกวน และขยายภาพได้อย่างสะอาดหมดจดได้อย่างไร
1) การนิยามคำว่า “ดี” (ขึ้นอยู่กับหลายปัจจัย และนั่นก็ไม่เป็นไร) 🎯
ก่อนที่จะทำการประเมินใดๆ ให้ตัดสินใจก่อนว่าความสำเร็จมีหน้าตาอย่างไร มิเช่นนั้นคุณจะวัดทุกอย่างโดยไม่เรียนรู้อะไรเลย มันเหมือนกับการเอาไม้บรรทัดไปวัดการประกวดเค้ก แน่นอน คุณจะได้ตัวเลข แต่ตัวเลขเหล่านั้นไม่ได้บอกอะไรคุณมากนัก 😅
ชี้แจง:
-
เป้าหมายของผู้ใช้ : การสรุป การค้นหา การเขียน การให้เหตุผล การดึงข้อเท็จจริง
-
ต้นทุนของความล้มเหลว : การแนะนำภาพยนตร์ผิดๆ นั้นตลก แต่คำแนะนำทางการแพทย์ที่ผิดพลาดนั้น...ไม่ตลก (การกำหนดกรอบความเสี่ยง: NIST AI RMF 1.0 )
-
สภาพแวดล้อมการทำงาน : บนอุปกรณ์ ในระบบคลาวด์ หลังไฟร์วอลล์ ในสภาพแวดล้อมที่มีการควบคุม
-
ข้อจำกัดหลัก : เวลาในการตอบสนอง, ค่าใช้จ่ายต่อคำขอ, ความเป็นส่วนตัว, ความสามารถในการอธิบาย, การรองรับหลายภาษา, การควบคุมน้ำเสียง
โมเดลที่ "เก่ง" ในงานหนึ่ง อาจเป็นหายนะในอีกงานหนึ่งก็ได้ นี่ไม่ใช่ความขัดแย้ง แต่เป็นความจริง 🙂
2) กรอบการประเมินโมเดล AI ที่แข็งแกร่งควรมีลักษณะอย่างไร 🧰
ใช่แล้ว นี่คือส่วนที่คนส่วนใหญ่มองข้าม พวกเขาเลือกเกณฑ์มาตรฐานมาทดสอบแค่ครั้งเดียว แล้วก็จบไป กรอบการประเมินผลที่แข็งแกร่งนั้นต้องมีคุณสมบัติที่สอดคล้องกันอยู่บ้าง (ตัวอย่างเครื่องมือที่ใช้งานได้จริง: OpenAI Evals / คู่มือการใช้งาน OpenAI Evals ):
-
สามารถทำซ้ำได้ - คุณสามารถเรียกใช้ซ้ำได้ในสัปดาห์หน้าและเชื่อถือผลการเปรียบเทียบได้
-
เป็นตัวแทนที่ดี - สะท้อนให้เห็นถึงผู้ใช้และงานจริงของคุณ (ไม่ใช่แค่เรื่องเล็กน้อย)
-
แบบหลายชั้น - ผสานรวมการวัดผลอัตโนมัติ + การตรวจสอบโดยมนุษย์ + การทดสอบแบบต่อต้าน
-
ที่นำไปปฏิบัติได้จริง - บอกคุณว่าต้องแก้ไขอะไร ไม่ใช่แค่ "คะแนนลดลง"
-
ป้องกันการปลอมแปลง - ป้องกันการ "สอนเพื่อสอบ" หรือการรั่วไหลโดยไม่ตั้งใจ
-
คำนึงถึงต้นทุน - การประเมินผลไม่ควรทำให้คุณล้มละลาย (เว้นแต่คุณจะชอบความเจ็บปวด)
ถ้าการประเมินของคุณไม่สามารถทนต่อคำพูดของเพื่อนร่วมทีมที่สงสัยว่า “โอเค แต่ลองนำไปใช้ในระบบการผลิตดูก่อน” แสดงว่าการประเมินของคุณยังไม่เสร็จสมบูรณ์ นั่นคือการตรวจสอบความพร้อมของข้อมูล (vib check).
3) วิธีการประเมินโมเดล AI โดยเริ่มจากกรณีการใช้งานย่อย 🍰
นี่คือเคล็ดลับที่จะช่วยประหยัดเวลาได้มาก: แบ่งกรณีการใช้งานออกเป็นส่วนย่อย ๆ
แทนที่จะใช้คำว่า “ประเมินแบบจำลอง” ให้ใช้คำนี้แทน:
-
ความเข้าใจในเจตนา (เข้าใจสิ่งที่ผู้ใช้ต้องการหรือไม่)
-
การดึงข้อมูลหรือการใช้งานตามบริบท (ใช้ข้อมูลที่ให้มาอย่างถูกต้องหรือไม่)
-
การให้เหตุผล / งานหลายขั้นตอน (มีความสอดคล้องกันในแต่ละขั้นตอนหรือไม่)
-
การจัดรูปแบบและโครงสร้าง (ทำตามคำแนะนำหรือไม่)
-
ความปลอดภัยและการปฏิบัติตามนโยบาย (มีการหลีกเลี่ยงเนื้อหาที่ไม่ปลอดภัยหรือไม่ โปรดดู NIST AI RMF 1.0 )
-
น้ำเสียงและเอกลักษณ์ของแบรนด์ (ฟังดูเป็นอย่างที่คุณต้องการหรือไม่)
สิ่งนี้ทำให้ "วิธีการประเมินโมเดล AI" รู้สึกเหมือนไม่ใช่การสอบใหญ่ครั้งเดียว แต่เหมือนเป็นชุดแบบทดสอบย่อยที่เน้นเฉพาะเรื่อง แบบทดสอบย่อยอาจน่ารำคาญ แต่ก็พอรับมือได้ 😄
4) พื้นฐานการประเมินผลแบบออฟไลน์ - ชุดทดสอบ ป้ายกำกับ และรายละเอียดที่ไม่น่าดึงดูดแต่สำคัญ 📦
การประเมินแบบออฟไลน์ คือการทดสอบแบบควบคุมก่อนที่ผู้ใช้จะใช้งานจริง (รูปแบบขั้นตอนการทำงาน: การประเมินของ OpenAI )
สร้างหรือรวบรวมชุดทดสอบที่เป็นของคุณอย่างแท้จริง
ชุดทดสอบที่ดีมักประกอบด้วย:
-
ตัวอย่างที่ดีเยี่ยม : ผลลัพธ์ในอุดมคติที่คุณภาคภูมิใจที่จะส่งมอบ
-
กรณีพิเศษ : ข้อความแจ้งเตือนที่ไม่ชัดเจน, ข้อมูลป้อนเข้าที่ไม่เป็นระเบียบ, รูปแบบการจัดวางที่ไม่คาดคิด
-
การตรวจสอบโหมดความล้มเหลว : ข้อความแจ้งเตือนที่อาจชักจูงให้เกิดภาพหลอนหรือการตอบสนองที่ไม่ปลอดภัย (กรอบการทดสอบความเสี่ยง: NIST AI RMF 1.0 )
-
การครอบคลุมความหลากหลาย : ระดับทักษะของผู้ใช้ที่แตกต่างกัน สำเนียง ภาษา และสาขาต่างๆ
ถ้าคุณทดสอบเฉพาะกับข้อความที่ "สะอาด" เท่านั้น โมเดลของคุณจะดูดีมาก แต่พอผู้ใช้จริงพิมพ์ผิด พูดประโยคไม่จบ และคลิกด้วยความโกรธ นี่แหละคือความเป็นจริง.
ตัวเลือกการติดฉลาก (หรือระดับความเข้มงวด)
คุณสามารถกำหนดป้ายกำกับให้กับผลลัพธ์ได้ดังนี้:
-
ไบนารี : ผ่าน/ไม่ผ่าน (รวดเร็ว เข้มงวด)
-
ลำดับขั้น : คะแนนคุณภาพ 1-5 (ละเอียดอ่อนและเป็นอัตนัย)
-
คุณลักษณะหลายประการ : ความถูกต้อง ความครบถ้วน น้ำเสียง การใช้แหล่งอ้างอิง ฯลฯ (ดีที่สุด แต่ใช้เวลานานกว่า)
การพิจารณาคุณสมบัติหลายด้านเป็นจุดที่เหมาะสมที่สุดสำหรับหลายทีม มันเหมือนกับการชิมอาหารแล้วตัดสินความเค็มแยกจากเนื้อสัมผัส มิฉะนั้นคุณก็แค่พูดว่า "ดี" แล้วก็ยักไหล่.
5) ตัวชี้วัดที่ไม่โกหก และตัวชี้วัดที่อาจจะโกหกบ้าง 📊😅
ตัวชี้วัดต่างๆ นั้นมีคุณค่า...แต่ก็อาจเป็นเหมือนระเบิดประกายระยิบระยับ ส่องประกายไปทั่ว และยากที่จะทำความสะอาด.
ตระกูลเมตริกทั่วไป
-
ความแม่นยำ / การจับคู่ที่ตรงเป๊ะ : เหมาะอย่างยิ่งสำหรับการสกัดข้อมูล การจำแนกประเภท และงานที่มีโครงสร้าง
-
F1 / ความแม่นยำ / การเรียกคืนข้อมูล : มีประโยชน์เมื่อการพลาดบางสิ่งนั้นแย่กว่าสัญญาณรบกวนเพิ่มเติม (คำจำกัดความ: scikit-learn precision/recall/F-score )
-
รูปแบบการให้คะแนน BLEU/ROUGE มีความทับซ้อนกัน : เหมาะสำหรับงานสรุปข้อมูล แต่บางครั้งอาจทำให้เข้าใจผิดได้ (ตัวชี้วัดดั้งเดิม: BLEU และ ROUGE )
-
ความคล้ายคลึงของการฝังข้อมูล : มีประโยชน์สำหรับการจับคู่ความหมาย และสามารถให้รางวัลแก่คำตอบที่ผิดแต่คล้ายคลึงกันได้
-
อัตราความสำเร็จของงาน : “ผู้ใช้ได้รับสิ่งที่ต้องการหรือไม่” คือมาตรฐานสูงสุดเมื่อมีการกำหนดนิยามไว้อย่างชัดเจน
-
การปฏิบัติตามข้อจำกัด : เป็นไปตามรูปแบบ ความยาว ความถูกต้องของ JSON และการยึดมั่นในสคีมา
ประเด็นสำคัญ
หากงานของคุณเป็นงานที่ไม่มีจุดจบตายตัว (เช่น การเขียน การใช้เหตุผล การสนทนาให้ความช่วยเหลือ) การวัดผลด้วยตัวเลขเพียงตัวเดียวอาจไม่แม่นยำนัก ไม่ใช่ว่าไร้ประโยชน์ แต่ไม่แม่นยำ การวัดความคิดสร้างสรรค์ด้วยไม้บรรทัดนั้นทำได้ แต่คุณจะรู้สึกเขินอายที่ทำแบบนั้น (และอาจจะจิ้มตาตัวเองด้วย)
ดังนั้น: ควรใช้ตัวชี้วัด แต่ต้องยึดตัวชี้วัดเหล่านั้นกับการประเมินโดยมนุษย์และผลลัพธ์ของงานจริง (ตัวอย่างหนึ่งของการอภิปรายเกี่ยวกับการประเมินตาม LLM พร้อมข้อควรระวัง: G-Eval )
6) ตารางเปรียบเทียบ - ตัวเลือกการประเมินที่ดีที่สุด (พร้อมข้อแม้เล็กน้อย เพราะชีวิตก็มีเรื่องไม่คาดฝัน) 🧾✨
นี่คือตัวอย่างวิธีการประเมินผลที่นำไปใช้ได้จริง ลองผสมผสานดู ทีมส่วนใหญ่ก็ทำแบบนั้น.
| เครื่องมือ/วิธีการ | ผู้ชม | ราคา | เหตุผลที่มันได้ผล |
|---|---|---|---|
| ชุดทดสอบแบบทันทีที่สร้างขึ้นด้วยมือ | ผลิตภัณฑ์ + eng | $ | แม่นยำมาก ตรวจจับข้อผิดพลาดได้เร็ว - แต่คุณต้องดูแลรักษามันไปตลอด 🙃 (เครื่องมือเริ่มต้น: OpenAI Evals ) |
| คณะกรรมการให้คะแนนตามเกณฑ์ของมนุษย์ | ทีมที่สามารถส่งผู้ตรวจสอบมาได้ | $$ | เหมาะที่สุดสำหรับโทนเสียง ความละเอียดอ่อน คำถามที่ว่า "มนุษย์จะยอมรับสิ่งนี้ได้หรือไม่" และความสับสนเล็กน้อยขึ้นอยู่กับผู้วิจารณ์ |
| LLM-as-judge (พร้อมเกณฑ์การประเมิน) | ลูปการวนซ้ำที่รวดเร็ว | $-$$ | รวดเร็วและปรับขนาดได้ แต่มีโอกาสเกิดอคติ และบางครั้งการให้คะแนนอาจอิงจากความรู้สึกมากกว่าข้อเท็จจริง (งานวิจัยและปัญหาเรื่องอคติที่ทราบกันดี: G-Eval ) |
| การทดสอบการโจมตีแบบ Red Teaming ของฝ่ายตรงข้าม | ความปลอดภัย + การปฏิบัติตามกฎระเบียบ | $$ | ค้นพบรูปแบบความล้มเหลวที่น่าสนใจ โดยเฉพาะอย่างยิ่งการโจมตีแบบ Prompt Injection - ให้ความรู้สึกเหมือนกับการทดสอบความเครียดในโรงยิม (ภาพรวมภัยคุกคาม: OWASP LLM01 Prompt Injection / OWASP Top 10 สำหรับแอปพลิเคชัน LLM ) |
| การสร้างการทดสอบสังเคราะห์ | ทีมข้อมูลเบา | $ | ครอบคลุมดีมาก แต่ข้อความแจ้งเตือนอัตโนมัติอาจเรียบร้อยและสุภาพเกินไป...ผู้ใช้ไม่สุภาพหรอก |
| การทดสอบ A/B กับผู้ใช้จริง | ผลิตภัณฑ์สำเร็จรูป | $$$ | สัญญาณที่ชัดเจนที่สุด — และเป็นสิ่งที่สร้างความเครียดทางอารมณ์มากที่สุดเช่นกัน เมื่อตัวชี้วัดเปลี่ยนแปลงไป (คู่มือปฏิบัติคลาสสิก: Kohavi และคณะ, “การทดลองแบบควบคุมบนเว็บ” ) |
| การประเมินตามการดึงข้อมูล (การตรวจสอบ RAG) | แอปค้นหา + ถามตอบ | $$ | มาตรการต่างๆ “ใช้บริบทได้อย่างถูกต้อง” ช่วยลดการให้คะแนนอาการประสาทหลอนที่สูงเกินจริง (ภาพรวมการประเมิน RAG: การประเมิน RAG: การสำรวจ ) |
| การตรวจสอบ + การตรวจจับการเปลี่ยนแปลง | ระบบการผลิต | $$-$$$ | ตรวจจับความเสื่อมสภาพเมื่อเวลาผ่านไป - ดูไม่หวือหวาจนกว่าจะถึงวันที่มันช่วยคุณได้ 😬 (ภาพรวมการเปลี่ยนแปลงแนวคิด: แบบสำรวจการเปลี่ยนแปลงแนวคิด (PMC) ) |
โปรดสังเกตว่าราคานั้นไม่แน่นอนโดยเจตนา ราคาจะขึ้นอยู่กับขนาด เครื่องมือ และจำนวนการประชุมที่คุณสร้างขึ้นโดยไม่ได้ตั้งใจ.
7) การประเมินโดยมนุษย์ - อาวุธลับที่คนส่วนใหญ่มองข้าม 👀🧑⚖️
หากคุณใช้การประเมินอัตโนมัติเพียงอย่างเดียว คุณจะพลาดสิ่งต่อไปนี้:
-
น้ำเสียงไม่เข้ากัน (“ทำไมถึงพูดประชดประชันจัง”)
-
ข้อผิดพลาดทางข้อเท็จจริงเล็กน้อยที่ดูเป็นธรรมชาติ
-
นัยยะที่เป็นอันตราย ภาพลักษณ์เหมารวม หรือการใช้ถ้อยคำที่ไม่เหมาะสม (การกำหนดกรอบความเสี่ยงและอคติ: NIST AI RMF 1.0 )
-
ความล้มเหลวในการปฏิบัติตามคำสั่งที่ยังคงฟังดู "ฉลาด"
กำหนดเกณฑ์การประเมินให้ชัดเจน (มิเช่นนั้นผู้ประเมินจะกำหนดเกณฑ์เองโดยไม่มีหลักเกณฑ์)
เกณฑ์การประเมินที่ไม่ดี: “ความช่วยเหลือ”
เกณฑ์การประเมินที่ดีกว่า:
-
ความถูกต้อง : ถูกต้องตามข้อเท็จจริงเมื่อพิจารณาจากโจทย์และบริบท
-
ความครบถ้วน : ครอบคลุมประเด็นที่จำเป็นโดยไม่วกวน
-
ความชัดเจน : อ่านง่าย มีโครงสร้างชัดเจน ลดความสับสนให้น้อยที่สุด
-
นโยบาย/ความปลอดภัย : หลีกเลี่ยงเนื้อหาที่ถูกจำกัด และจัดการกับการปฏิเสธได้ดี (กรอบความปลอดภัย: NIST AI RMF 1.0 )
-
สไตล์ : สอดคล้องกับน้ำเสียง ระดับการอ่าน และน้ำเสียง
-
ความซื่อสัตย์ : ไม่สร้างแหล่งข้อมูลหรือข้อกล่าวอ้างที่ไม่มีหลักฐานสนับสนุน
นอกจากนี้ ควรตรวจสอบความสอดคล้องระหว่างผู้ประเมินบ้างเป็นครั้งคราว หากผู้ประเมินสองคนมีความเห็นไม่ตรงกันอยู่ตลอด นั่นไม่ใช่ปัญหาเรื่องคน แต่เป็นปัญหาเรื่องเกณฑ์การประเมิน โดยปกติแล้ว (หลักการพื้นฐานเกี่ยวกับความน่าเชื่อถือของผู้ประเมิน: McHugh เกี่ยวกับค่า kappa ของ Cohen )
8) วิธีการประเมินโมเดล AI ในด้านความปลอดภัย ความเสถียร และ "ความไม่พึงประสงค์ของผู้ใช้" 🧯🧪
นี่คือส่วนที่คุณต้องทำก่อนเปิดตัว และต้องทำต่อไปเรื่อยๆ เพราะอินเทอร์เน็ตไม่เคยหลับใหล.
การทดสอบความทนทานจะรวมถึง
-
คำผิด, คำแสลง, ไวยากรณ์ไม่ถูกต้อง
-
คำถามที่ยาวมากและคำถามที่สั้นมาก
-
คำสั่งที่ขัดแย้งกัน (“ให้กระชับแต่ต้องระบุรายละเอียดทุกอย่าง”)
-
การสนทนาแบบหลายรอบที่ผู้ใช้เปลี่ยนเป้าหมาย
-
การพยายามแทรกโค้ดแบบทันที (“ไม่สนใจกฎก่อนหน้า…”) (รายละเอียดภัยคุกคาม: OWASP LLM01 Prompt Injection )
-
หัวข้อที่ละเอียดอ่อนซึ่งต้องปฏิเสธอย่างระมัดระวัง (การกำหนดกรอบความเสี่ยง/ความปลอดภัย: NIST AI RMF 1.0 )
การประเมินความปลอดภัยไม่ได้หมายความแค่ว่า "เครื่องปฏิเสธที่จะทำงานหรือไม่"
แบบจำลองที่ดีควรมีคุณสมบัติดังนี้:
-
ปฏิเสธคำขอที่ไม่ปลอดภัยอย่างชัดเจนและใจเย็น (กรอบแนวทาง: NIST AI RMF 1.0 )
-
จัดหาทางเลือกที่ปลอดภัยกว่าเมื่อเหมาะสม
-
หลีกเลี่ยงการปฏิเสธคำถามที่ไม่เป็นอันตรายมากเกินไป (ผลลัพธ์ที่ผิดพลาด)
-
จัดการกับคำขอที่ไม่ชัดเจนด้วยการถามคำถามเพื่อความกระจ่าง (เมื่อได้รับอนุญาต)
การปฏิเสธมากเกินไปเป็นปัญหาที่แท้จริงของผลิตภัณฑ์ ผู้ใช้ไม่ชอบถูกปฏิบัติเหมือนภูตผีปีศาจที่น่าสงสัย 🧌 (ถึงแม้ว่าพวกเขาจะเป็นภูตผีปีศาจที่น่าสงสัยจริงๆ ก็ตาม)
9) ต้นทุน ความล่าช้า และความเป็นจริงในการปฏิบัติงาน - การประเมินที่ทุกคนลืมไป 💸⏱️
โมเดลอาจจะ "ยอดเยี่ยม" แต่ก็อาจไม่เหมาะกับคุณหากมันทำงานช้า ราคาแพง หรือมีปัญหาด้านการใช้งาน.
ประเมิน:
-
การกระจายของค่าความหน่วง (ไม่ใช่แค่ค่าเฉลี่ย - ค่าเปอร์เซ็นไทล์ 95 และ 99 ก็สำคัญด้วย) (เหตุใดค่าเปอร์เซ็นไทล์จึงสำคัญ: ดูได้ จาก Google SRE Workbook เกี่ยวกับการตรวจสอบ )
-
ต้นทุนต่อภารกิจที่สำเร็จ (ไม่ใช่ต้นทุนต่อโทเค็นโดยลำพัง)
-
ความเสถียรภายใต้ภาระ (การหมดเวลา การจำกัดอัตรา การพุ่งขึ้นผิดปกติ)
-
ความน่าเชื่อถือในการเรียกใช้เครื่องมือ (หากใช้ฟังก์ชัน ฟังก์ชันนั้นทำงานอย่างไร)
-
แนวโน้มความยาวของผลลัพธ์ (บางโมเดลเขียนเยิ่นเย้อ และการเขียนเยิ่นเย้อนั้นสิ้นเปลืองเงิน)
รถรุ่นที่ด้อยกว่าเล็กน้อยแต่เร็วกว่าสองเท่า อาจชนะได้ในทางปฏิบัติ ฟังดูเหมือนเป็นเรื่องพื้นฐาน แต่คนส่วนใหญ่กลับมองข้ามไป เหมือนกับการซื้อรถสปอร์ตมาใช้แค่ซื้อของชำ แล้วมาบ่นเรื่องพื้นที่เก็บของท้ายรถนั่นแหละ.
10) ขั้นตอนการทำงานแบบครบวงจรที่เรียบง่ายที่คุณสามารถคัดลอก (และปรับแต่ง) ได้ 🔁✅
นี่คือขั้นตอนปฏิบัติที่เป็นรูปธรรมสำหรับ การประเมินโมเดล AI โดยไม่ต้องติดกับดักการทดลองที่ไม่รู้จบ:
-
กำหนดความสำเร็จ : ภารกิจ ข้อจำกัด ต้นทุนความล้มเหลว
-
สร้างชุดทดสอบ "หลัก" ขนาดเล็ก : ตัวอย่าง 50-200 ตัวอย่างที่สะท้อนการใช้งานจริง
-
เพิ่มชุดขอบและชุดการโจมตีที่เป็นอันตราย : การพยายามฉีดข้อมูล, ข้อความแจ้งเตือนที่ไม่ชัดเจน, การตรวจสอบความปลอดภัย (คลาสการฉีดข้อความแจ้งเตือน: OWASP LLM01 )
-
เรียกใช้การตรวจสอบอัตโนมัติ : การจัดรูปแบบ ความถูกต้องของ JSON ความถูกต้องพื้นฐานเท่าที่จะเป็นไปได้
-
ดำเนินการตรวจสอบโดยมนุษย์ : ตัวอย่างผลลัพธ์ในแต่ละหมวดหมู่ ให้คะแนนตามเกณฑ์ที่กำหนด
-
เปรียบเทียบข้อดีข้อเสีย : คุณภาพ ต้นทุน ความล่าช้า ความปลอดภัย
-
โครงการนำร่องในวงจำกัด : การทดสอบ A/B หรือการทยอยเปิดตัว (คู่มือการทดสอบ A/B: Kohavi และคณะ )
-
ตรวจสอบใน ขั้นตอนการผลิต: การเปลี่ยนแปลงที่ค่อยเป็นค่อยไป การถดถอย วงจรการรับฟังความคิดเห็นจากผู้ใช้ (ภาพรวมการเปลี่ยนแปลงที่ค่อยเป็นค่อยไป: แบบสำรวจการเปลี่ยนแปลงแนวคิด (PMC) )
-
ทำซ้ำ : อัปเดตข้อความแจ้งเตือน การดึงข้อมูล การปรับแต่งอย่างละเอียด ข้อจำกัด แล้วเรียกใช้การประเมินอีกครั้ง (รูปแบบการทำซ้ำการประเมิน: คู่มือการประเมินของ OpenAI )
ควรจัดทำบันทึกเวอร์ชัน ไม่ใช่เพราะมันสนุก แต่เพราะตัวคุณในอนาคตจะขอบคุณคุณในขณะที่ถือกาแฟและพึมพำว่า “อะไรเปลี่ยนไปเนี่ย…” ☕🙂
11) ข้อผิดพลาดที่พบบ่อย (หรืออีกนัยหนึ่งคือ วิธีที่คนเรามักหลอกตัวเองโดยไม่รู้ตัว) 🪤
-
ฝึกฝนเพื่อทดสอบ : คุณปรับแต่งข้อความแจ้งเตือนจนผลลัพธ์ออกมาดีเยี่ยม แต่ผู้ใช้กลับต้องทนทุกข์ทรมาน
-
ข้อมูลการประเมินผลรั่วไหล : ข้อความแจ้งเตือนการทดสอบปรากฏขึ้นในข้อมูลการฝึกอบรมหรือการปรับแต่ง (ผิดพลาดแล้ว)
-
การยึดติดกับตัวชี้วัดเดียว : การไล่ตามคะแนนเพียงค่าเดียวที่ไม่สะท้อนถึงคุณค่าของผู้ใช้
-
การเพิกเฉยต่อการเปลี่ยนแปลงรูปแบบการกระจายสินค้า : พฤติกรรมของผู้ใช้เปลี่ยนแปลงไป และโมเดลของคุณก็ค่อยๆ เสื่อมถอยลง (การกำหนดกรอบความเสี่ยงในการผลิต: แบบสำรวจการเปลี่ยนแปลงแนวคิด (PMC) )
-
การให้ความสำคัญกับ "ความฉลาด" มากเกินไป : การใช้เหตุผลที่ชาญฉลาดไม่สำคัญหากมันทำลายรูปแบบหรือสร้างข้อเท็จจริงขึ้นมาเอง
-
การไม่ทดสอบคุณภาพของการปฏิเสธ : คำว่า “ไม่” อาจถูกต้อง แต่ก็ยังเป็นประสบการณ์ผู้ใช้ที่ไม่ดี
นอกจากนี้ โปรดระวังเดโม เดโมก็เหมือนตัวอย่างหนัง พวกมันแสดงเฉพาะส่วนสำคัญ ซ่อนส่วนที่น่าเบื่อ และบางครั้งก็โกหกด้วยดนตรีประกอบที่ดราม่า 🎬
12) บทสรุปสุดท้ายเกี่ยวกับการประเมินโมเดล AI 🧠✨
การประเมินโมเดล AI ไม่ใช่แค่การให้คะแนนเพียงอย่างเดียว แต่เป็นการรับประทานอาหารที่สมดุล คุณต้องมีโปรตีน (ความถูกต้อง) ผัก (ความปลอดภัย) คาร์โบไฮเดรต (ความเร็วและต้นทุน) และใช่ บางครั้งก็ต้องมีของหวาน (โทนและรสชาติ) 🍲🍰 (การกำหนดกรอบความเสี่ยง: NIST AI RMF 1.0 )
หากคุณจำอะไรไม่ได้เลย:
-
กำหนดความหมายของคำว่า “ดี” สำหรับกรณีการใช้งานของคุณ
-
ควรใช้ชุดทดสอบที่เป็นตัวแทน ไม่ใช่แค่ชุดทดสอบมาตรฐานที่มีชื่อเสียงเท่านั้น
-
ผสานรวมตัวชี้วัดอัตโนมัติกับการประเมินโดยมนุษย์
-
ทดสอบความทนทานและความปลอดภัยเสมือนว่าผู้ใช้มีเจตนาร้าย (เพราะบางครั้ง...พวกเขาก็เป็นเช่นนั้นจริงๆ) (คลาสการโจมตีแบบฉีดข้อมูลทันที: OWASP LLM01 )
-
ควรพิจารณาต้นทุนและเวลาแฝงในการประเมิน ไม่ใช่คิดถึงมันทีหลัง (เหตุใดเปอร์เซ็นไทล์จึงมีความสำคัญ: ดูได้จาก Google SRE Workbook )
-
ติดตามตรวจสอบหลังการเปิดตัว - โมเดลมีการเปลี่ยนแปลง แอปพลิเคชันพัฒนาขึ้น และมนุษย์ก็สร้างสรรค์สิ่งใหม่ๆ (ภาพรวมการเปลี่ยนแปลง: แบบสำรวจการเปลี่ยนแปลงแนวคิด (PMC) )
นี่คือ วิธีการประเมินโมเดล AI ที่ได้ผลดีเมื่อผลิตภัณฑ์ของคุณใช้งานจริงและผู้คนเริ่มทำสิ่งที่ไม่คาดคิด ซึ่งก็เกิดขึ้นอยู่เสมอ 🙂
คำถามที่พบบ่อย
ขั้นตอนแรกในการประเมินโมเดล AI สำหรับผลิตภัณฑ์จริงคืออะไร?
เริ่มต้นด้วยการกำหนดความหมายของคำว่า “ดี” สำหรับกรณีการใช้งานเฉพาะของคุณ อธิบายเป้าหมายของผู้ใช้ ต้นทุนของความล้มเหลว (ความเสี่ยงต่ำเทียบกับความเสี่ยงสูง) และที่ที่โมเดลจะทำงาน (คลาวด์ บนอุปกรณ์ สภาพแวดล้อมที่มีการควบคุม) จากนั้นระบุข้อจำกัดที่ชัดเจน เช่น ความหน่วง ต้นทุน ความเป็นส่วนตัว และการควบคุมโทนเสียง หากไม่มีพื้นฐานนี้ คุณจะวัดผลได้มากมายแต่ก็ยังตัดสินใจผิดพลาดอยู่ดี.
ฉันจะสร้างชุดทดสอบที่สะท้อนถึงผู้ใช้งานจริงได้อย่างไร?
สร้างชุดทดสอบที่เป็นของคุณเองอย่างแท้จริง ไม่ใช่แค่ชุดทดสอบมาตรฐานสาธารณะ รวมทั้งตัวอย่างที่ดีเยี่ยมที่คุณภาคภูมิใจที่จะนำเสนอ รวมถึงข้อความแจ้งเตือนที่อาจมีข้อผิดพลาดทางไวยากรณ์ ประโยคไม่สมบูรณ์ และคำขอที่ไม่ชัดเจน เพิ่มกรณีพิเศษและตัวอย่างตรวจสอบความล้มเหลวที่อาจทำให้เกิดความเข้าใจผิดหรือการตอบกลับที่ไม่ปลอดภัย ครอบคลุมความหลากหลายในระดับทักษะ สำเนียง ภาษา และโดเมน เพื่อให้ผลลัพธ์ไม่ล้มเหลวในการใช้งานจริง.
ฉันควรใช้ตัวชี้วัดใดบ้าง และตัวชี้วัดใดบ้างที่อาจทำให้เข้าใจผิดได้?
เลือกตัวชี้วัดให้เหมาะสมกับประเภทของงาน การจับคู่ที่ตรงกันทุกประการและความถูกต้องแม่นยำนั้นใช้ได้ดีกับการสกัดข้อมูลและผลลัพธ์ที่มีโครงสร้าง ในขณะที่ความแม่นยำ/การเรียกคืน และค่า F1 จะมีประโยชน์เมื่อการพลาดบางสิ่งนั้นแย่กว่าสัญญาณรบกวนเพิ่มเติม ตัวชี้วัดการทับซ้อน เช่น BLEU/ROUGE อาจทำให้เข้าใจผิดได้สำหรับงานปลายเปิด และความคล้ายคลึงของการฝังข้อมูลอาจให้รางวัลกับคำตอบที่ "ผิดแต่คล้ายกัน" สำหรับงานเขียน งานสนับสนุน หรือการให้เหตุผล ให้ผสมผสานตัวชี้วัดกับการตรวจสอบโดยมนุษย์และอัตราความสำเร็จของงาน.
ฉันควรวางโครงสร้างการประเมินอย่างไรเพื่อให้ได้ผลลัพธ์ที่ทำซ้ำได้และมีคุณภาพระดับใช้งานจริง?
กรอบการประเมินที่แข็งแกร่งนั้นต้องสามารถทำซ้ำได้ เป็นตัวแทนที่ดี มีหลายระดับ และนำไปปฏิบัติได้จริง ควรผสมผสานการตรวจสอบอัตโนมัติ (รูปแบบ ความถูกต้องของ JSON ความถูกต้องพื้นฐาน) เข้ากับการให้คะแนนตามเกณฑ์ของมนุษย์และการทดสอบแบบโต้แย้ง ทำให้การประเมินมีความทนทานต่อการแก้ไขเปลี่ยนแปลงโดยหลีกเลี่ยงการรั่วไหลและการ "สอนเพื่อการทดสอบ" ควรคำนึงถึงต้นทุนการประเมินเพื่อให้สามารถดำเนินการซ้ำได้บ่อยครั้ง ไม่ใช่แค่ครั้งเดียวก่อนเปิดตัว.
วิธีที่ดีที่สุดในการประเมินผลงานของมนุษย์โดยไม่ให้เกิดความวุ่นวายคืออะไร?
ใช้เกณฑ์การประเมินที่ชัดเจนเพื่อป้องกันไม่ให้ผู้ประเมินประเมินตามใจชอบ ให้คะแนนคุณลักษณะต่างๆ เช่น ความถูกต้อง ความครบถ้วน ความชัดเจน การจัดการด้านความปลอดภัย/นโยบาย ความสอดคล้องของรูปแบบ/น้ำเสียง และความเที่ยงตรง (ไม่สร้างข้ออ้างหรือแหล่งที่มาปลอม) ตรวจสอบความสอดคล้องระหว่างผู้ประเมินเป็นระยะ หากผู้ประเมินมีความเห็นไม่ตรงกันอย่างต่อเนื่อง แสดงว่าเกณฑ์การประเมินอาจต้องได้รับการปรับปรุง การตรวจสอบโดยมนุษย์มีคุณค่าอย่างยิ่งสำหรับความไม่สอดคล้องของน้ำเสียง ข้อผิดพลาดทางข้อเท็จจริงเล็กน้อย และความล้มเหลวในการปฏิบัติตามคำแนะนำ.
ฉันจะประเมินความปลอดภัย ความทนทาน และความเสี่ยงจากการฉีดเข้าเส้นเลือดดำอย่างรวดเร็วได้อย่างไร?
ทดสอบด้วยอินพุตที่ทำให้ผู้ใช้รู้สึก “หงุดหงิด” เช่น คำพิมพ์ผิด คำสแลง คำสั่งที่ขัดแย้งกัน คำถามที่ยาวหรือสั้นเกินไป และการเปลี่ยนแปลงเป้าหมายหลายรอบ รวมถึงการพยายามแทรกคำถาม เช่น “ไม่สนใจกฎก่อนหน้า” และหัวข้อที่ละเอียดอ่อนที่ต้องปฏิเสธอย่างระมัดระวัง ประสิทธิภาพด้านความปลอดภัยที่ดีไม่ได้หมายถึงแค่การปฏิเสธเท่านั้น แต่หมายถึงการปฏิเสธอย่างชัดเจน การเสนอทางเลือกที่ปลอดภัยกว่าเมื่อเหมาะสม และการหลีกเลี่ยงการปฏิเสธคำถามที่ไม่เป็นอันตรายมากเกินไปซึ่งจะส่งผลเสียต่อประสบการณ์ผู้ใช้.
ฉันจะประเมินต้นทุนและเวลาแฝงให้สอดคล้องกับความเป็นจริงได้อย่างไร?
อย่าวัดแค่ค่าเฉลี่ย – ให้ติดตามการกระจายของเวลาแฝง โดยเฉพาะ p95 และ p99 ประเมินต้นทุนต่อภารกิจที่สำเร็จ ไม่ใช่ต้นทุนต่อโทเค็นเพียงอย่างเดียว เพราะการลองใหม่และผลลัพธ์ที่ยืดเยื้ออาจทำให้การประหยัดหายไป ทดสอบความเสถียรภายใต้ภาระงาน (การหมดเวลา การจำกัดอัตรา การกระชาก) และความน่าเชื่อถือในการเรียกใช้เครื่องมือ/ฟังก์ชัน โมเดลที่แย่กว่าเล็กน้อยแต่เร็วกว่าหรือเสถียรกว่าสองเท่า อาจเป็นตัวเลือกผลิตภัณฑ์ที่ดีกว่า.
ขั้นตอนการทำงานแบบครบวงจรที่ง่ายที่สุดสำหรับการประเมินโมเดล AI คืออะไร?
กำหนดเกณฑ์ความสำเร็จและข้อจำกัด จากนั้นสร้างชุดทดสอบหลักขนาดเล็ก (ประมาณ 50-200 ตัวอย่าง) ที่จำลองการใช้งานจริง เพิ่มชุดทดสอบขอบเขตและชุดทดสอบที่เป็นอันตรายเพื่อความปลอดภัยและการทดสอบการแทรกข้อมูล เรียกใช้การตรวจสอบอัตโนมัติ จากนั้นสุ่มตัวอย่างผลลัพธ์เพื่อให้มนุษย์ประเมินตามเกณฑ์ที่กำหนด เปรียบเทียบคุณภาพกับต้นทุน กับความหน่วง กับความปลอดภัย ทดลองใช้งานในวงจำกัดหรือทำการทดสอบ A/B และตรวจสอบการเปลี่ยนแปลงและการถดถอยในสภาพแวดล้อมการใช้งานจริง.
ทีมงานมักเผลอหลอกตัวเองในการประเมินโมเดลด้วยวิธีใดบ้าง?
กับดักที่พบได้ทั่วไป ได้แก่ การปรับแต่งข้อความแจ้งเตือนเพื่อให้ได้คะแนนสูงสุดในเกณฑ์มาตรฐาน ในขณะที่ผู้ใช้กลับได้รับความเดือดร้อน การรั่วไหลของข้อความแจ้งเตือนในการประเมินไปสู่ข้อมูลการฝึกอบรมหรือการปรับแต่ง และการยึดติดกับตัวชี้วัดเพียงตัวเดียวที่ไม่สะท้อนถึงคุณค่าของผู้ใช้ ทีมงานยังเพิกเฉยต่อการเปลี่ยนแปลงการกระจายตัว ให้ความสำคัญกับ "ความฉลาด" มากเกินไป แทนที่จะให้ความสำคัญกับการปฏิบัติตามรูปแบบและความถูกต้อง และละเลยการทดสอบคุณภาพการปฏิเสธ การสาธิตอาจปกปิดปัญหาเหล่านี้ ดังนั้นควรพึ่งพาการประเมินที่มีโครงสร้าง ไม่ใช่แค่คลิปไฮไลท์.
เอกสารอ้างอิง
-
OpenAI - คู่มือการประเมินผลของ OpenAI - platform.openai.com
-
สถาบันมาตรฐานและเทคโนโลยีแห่งชาติ (NIST) - กรอบการบริหารความเสี่ยงด้านปัญญาประดิษฐ์ (AI RMF 1.0) - nist.gov
-
OpenAI - openai/evals (ที่เก็บ GitHub) - github.com
-
scikit-learn - precision_recall_fscore_support - scikit-learn.org
-
สมาคมภาษาศาสตร์เชิงคำนวณ (ACL Anthology) - BLEU - aclanthology.org
-
สมาคมภาษาศาสตร์เชิงคำนวณ (ACL Anthology) - ROUGE - aclanthology.org
-
arXiv - G-Eval - arxiv.org
-
OWASP - LLM01: Prompt Injection - owasp.org
-
OWASP - OWASP Top 10 สำหรับแอปพลิเคชันโมเดลภาษาขนาดใหญ่ - owasp.org
-
มหาวิทยาลัยสแตนฟอร์ด - Kohavi และคณะ, “การทดลองแบบควบคุมบนเว็บ” - stanford.edu
-
arXiv - การประเมิน RAG: การสำรวจ - arxiv.org
-
PubMed Central (PMC) - แบบสำรวจการเปลี่ยนแปลงแนวคิด (PMC) - nih.gov
-
PubMed Central (PMC) - McHugh เกี่ยวกับค่าสัมประสิทธิ์แคปปาของ Cohen - nih.gov
-
Google - คู่มือ SRE เกี่ยวกับการตรวจสอบ - google.workbook