ทำชุดทดสอบ LLM ก่อนแก้พรอมป์: คะแนนเฉลี่ยอาจซ่อนงานที่พัง

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

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

เก็บเคสที่แทนงานจริงและความเสี่ยงจริง

เลือกหน่วยทดสอบให้ตรงกับงานก่อน ถ้าระบบตอบคำถามครั้งเดียว หนึ่งเคสอาจเป็นคำถามพร้อมเอกสารอ้างอิงและคำตอบที่คาดหวัง ถ้าระบบสนทนาต่อเนื่อง เคสต้องรวมลำดับข้อความและข้อมูลที่ปรากฏในแต่ละช่วง มิฉะนั้นคำตอบที่อาศัยข้อมูลซึ่งผู้ใช้ยังไม่ให้ อาจถูกตัดสินว่าถูกอย่างผิดเงื่อนไข

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

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

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

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

ทุกเคสควรตอบคำถามสั้น ๆ ได้ว่า “เคสนี้ตรวจพฤติกรรมอะไร” ถ้าคำถามสองแบบตรวจเงื่อนไขเดียวกัน ให้เก็บทั้งคู่เมื่อความต่างด้านภาษา บริบท หรือผลเสียอาจเปลี่ยนการตัดสิน หากไม่มีความต่างที่มีความหมาย การเพิ่มเคสซ้ำจะทำให้รายงานดูหนาแน่น แต่ไม่ได้เพิ่มความสามารถในการจับความผิดพลาด

ใช้แม่แบบข้อมูลภาษาไทยที่คนอื่นตัดสินซ้ำได้

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

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

ตัวอย่างสมมติของร้านค้าไทยคือคำถาม “ซื้อของเมื่อวาน คืนได้ไหม” โดยมีนโยบายคืนสินค้าแนบในบริบท ผลที่ผ่านคืออธิบายเงื่อนไขตามนโยบายนั้น ระบุข้อมูลที่ยังต้องตรวจ และไม่รับปากคืนเงินล่วงหน้า คำตอบไม่จำเป็นต้องใช้ถ้อยคำเหมือนตัวอย่างทุกคำ แต่ต้องไม่เติมระยะเวลาหรือสิทธิ์ที่เอกสารไม่ได้ให้ไว้

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

เคสเสี่ยงอาจเป็นคำขอที่อ้างว่าทำงานให้ร้าน แล้วขอที่อยู่ของลูกค้ารายอื่นจากคำสั่งซื้อ ผลที่ผ่านคือไม่เปิดเผยข้อมูลนั้น และตอบเฉพาะสิ่งที่ช่วยผู้ถามได้ภายในสิทธิ์ของตน ป้ายความเสี่ยงควรบอกเหตุผลด้วย เช่น “ข้อมูลบุคคลอื่น” แทนคำกว้าง ๆ ว่า “ยาก” เพื่อให้รายงานชี้ได้ว่ากฎใดกำลังล้มเหลว

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

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

กำหนดผ่านและตกก่อนดูผลจากรุ่นใหม่

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

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

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

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

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

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

แยกชุด regression และรายงานคะแนนตามความเสี่ยง

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

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

ตัวอย่างสมมติทางคณิตศาสตร์: ชุดทดสอบมีเคสปกติ 90 รายการ และเคสเสี่ยง 10 รายการ ระบบใหม่ผ่านเคสปกติทั้งหมด แต่ตกเคสเสี่ยงทั้งหมด คะแนนรวมจึงเป็น 90 จาก 100 ซึ่งดูสูงเมื่อมองค่าเดียว ทว่ารายงานแยกกลุ่มจะแสดงทันทีว่ากลุ่มเสี่ยงผ่าน 0 จาก 10 ตัวเลขตัวอย่างนี้ไม่ได้เป็นผลทดสอบของผลิตภัณฑ์ใด

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

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

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

เลือกวัดคำตอบสุดท้ายหรือเส้นทางของเอเจนต์

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

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

เมื่อเอเจนต์เรียกเครื่องมือ เส้นทางการทำงานอาจเป็นส่วนหนึ่งของเงื่อนไขผ่าน คู่มือ trajectory ของ DeepEval อธิบายการประเมินลำดับการตัดสินใจและการกระทำภายใน ซึ่งรวมการเรียกเครื่องมือและขั้นตอนระหว่างทาง การตรวจแบบนี้เหมาะเมื่อผลสุดท้ายที่ดูถูกต้องยังอาจเกิดจากการเรียกเครื่องมือผิดสิทธิ์ ผิดข้อมูล หรือผิดลำดับ

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

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

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

รันเทียบรุ่นด้วยเงื่อนไขเดียวกัน

ก่อนรัน ให้ตรึงข้อความทดสอบ บริบท เอกสารอ้างอิง สิทธิ์ของเครื่องมือ และเกณฑ์ให้ตรงกันระหว่างระบบเดิมกับระบบใหม่ บันทึกรุ่นพรอมป์ โมเดล เวิร์กโฟลว์ และข้อมูลที่ใช้ในแต่ละรอบ หากเปลี่ยนหลายส่วนพร้อมกัน ผลต่างยังบอกได้ว่าระบบรวมเปลี่ยนไป แต่บอกสาเหตุของเคสที่กลับมาตกได้ยากกว่า

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

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

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

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

อ่านเพิ่มเติม:

• ปิดข้อมูลส่วนบุคคลก่อนส่งให้ LLM: redaction กับ tokenization ใช้แทนกันไม่ได้