เกณฑ์ประเมินคือทฤษฎีของงานที่ดี

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

ข้อผิดพลาดไม่ใช่ประโยคที่อ่อน แต่คือนิยามของคำว่า ดี ที่อ่อน

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

เกณฑ์คือทฤษฎีเกี่ยวกับงาน จงทดสอบทฤษฎี

เริ่มจากความผิดที่ทำให้ตกทันที

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

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

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

รอบแรกเล็กได้ แต่กำกวมไม่ได้

1. เจ้าของงาน

   กรณีดี ผิด และมีข้อโต้แย้ง

   เป็นฐาน
2. ตรวจสิ่งแน่นอน ตัวตน · สิทธิ์ · ปลายทาง

   โค้ดบังคับข้อเท็จจริง

   เป็นฐาน
3. เกณฑ์เชิงความหมาย

   ให้โมเดลตัดสินเฉพาะสิ่งต้องตีความ

   เป็นฐาน
4. ทบทวนความต่าง

   แก้ป้ายและเกณฑ์

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

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

คะแนนรับจุดบอดของเกณฑ์มา

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

หากเกณฑ์ให้รางวัลคำตอบสวยและไม่เคยตรวจว่าคืนเงินจริงไหม ระบบอัตโนมัติจะขยายการละเลย ตัวเลขทศนิยมสองตำแหน่งดูแม่นยำ แต่ยังอาจวัดสิ่งผิด

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

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

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

ผูกผลลัพธ์กับการประเมิน

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

คู่มือคอนเน็กเตอร์ Brevo อธิบายว่าการเรียก API สำเร็จอาจอยู่พร้อมแอตทริบิวต์ที่หาย การประเมินที่ตรวจแค่ว่าเอเจนต์เรียก endpoint จะพลาดผล ที่ตรวจแค่ปลายทางอาจพลาดเส้นทางต้องห้ามที่บังเอิญได้ค่าถูก ทั้งคู่สำคัญเมื่อเส้นทางมีความเสี่ยง

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

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

แดชบอร์ดแสดงคะแนนได้ แต่เกณฑ์เท่านั้นที่บอกว่านับอะไร