เกณฑ์ที่ชัดเจนเอาชนะคำสั่งกำกวม

แนวคิด

เวลาอยากให้โมเดลตัดสินใจอย่างแม่นยำ เช่น รีวิวโค้ดแล้วชี้ปัญหา สิ่งที่ได้ผลไม่ใช่การสั่งกว้าง ๆ แต่เป็นการให้เกณฑ์ที่ชัดเจนเป็นรูปธรรม เอกสารฝั่ง prompt engineering ย้ำหลักเดียวกันคือ "be clear and direct" ยิ่งบอกให้ชัดว่าอะไรนับ อะไรไม่นับ ผลลัพธ์ยิ่งสม่ำเสมอ

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

ทำไมสำคัญ

จุดที่คนมักเข้าใจผิดคือคิดว่าเติมคำกำกับความมั่นใจแล้วจะแม่นขึ้น เช่น สั่งว่า "be conservative" หรือ "รายงานเฉพาะสิ่งที่มั่นใจสูง" (high-confidence) คำพวกนี้ฟังดูช่วยลด false positive แต่จริง ๆ ไม่ได้เพิ่ม precision เพราะมันไม่ได้บอกโมเดลว่าเส้นแบ่งอยู่ตรงไหน โมเดลยังต้องเดาเองว่าอะไรคือ "มั่นใจพอ" การกรองด้วยความมั่นใจจึงเลื่อนลอย ไม่ใช่เกณฑ์เชิงหมวดหมู่ที่ตรวจสอบได้

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

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

ตัวอย่าง

// กำกวม — precision ไม่ดีขึ้น เพราะไม่มีเส้นแบ่ง
"ตรวจว่า comment ถูกต้อง และ be conservative รายงานเฉพาะที่มั่นใจสูง"

// ชัดเจน — เกณฑ์เชิงหมวดหมู่ที่วัดได้
"flag comment เฉพาะเมื่อพฤติกรรมที่ comment อ้าง ขัดกับพฤติกรรมจริงของโค้ด
 รายงาน: bug ที่ทำให้ผลลัพธ์ผิด, ช่องโหว่ security
 ข้าม: เรื่อง style, การตั้งชื่อ, pattern ที่ทีมใช้อยู่แล้ว"

แบบล่างไม่ได้ขอให้ระวังตัว แต่บอกตรง ๆ ว่าอะไรเข้าข่ายอะไรไม่ ผลลัพธ์จึงซ้ำเดิมได้ในทุกรอบ ไม่ขึ้นกับว่าโมเดลตีความคำว่า "มั่นใจ" อย่างไรในวันนั้น

เช็คความเข้าใจ

อ่านต่อ

• Prompt engineering — be clear and direct, use examples
• Structured outputs