Evals (AI Evaluation)

Evals (ย่อจาก evaluations) คือการทดสอบวัดผลระบบ ai อย่างเป็นระบบ: เตรียม "ชุดข้อสอบ" ที่เป็นตัวอย่างคำถามหรือ input พร้อมคำตอบที่คาดหวัง ป้อนให้ llm หรือแอปที่สร้างบน AI ทำข้อสอบทั้งชุด แล้วตรวจให้คะแนนตามเกณฑ์ที่กำหนดไว้ล่วงหน้า ผลที่ได้คือตัวเลขจับต้องได้ เช่น ตอบถูกกี่เปอร์เซ็นต์ ผ่านกี่ข้อ ตกกี่ข้อ แทนที่จะเป็นความรู้สึกลอยๆ ว่า "ดูเหมือนตอบดีนะ" ฝั่ง OpenAI นิยาม evals ว่าเป็นเครื่องมือทดสอบว่า output ของ model ตรงตามเกณฑ์ด้านเนื้อหาและสไตล์ที่เรากำหนดหรือไม่ และถือว่าการเขียน evals เป็นส่วนประกอบจำเป็นของการสร้างแอป AI ที่เชื่อถือได้ ส่วนฝั่ง Anthropic เรียกว่า empirical evaluations และวางไว้เป็นหัวใจของวงจร prompt-engineering: ตั้งเกณฑ์ · สร้างข้อสอบ · ทดสอบ · ปรับ · วนซ้ำ

ส่วนประกอบหลักของ eval มีสามอย่าง: หนึ่ง dataset คือชุดข้อสอบพร้อมเฉลย (ground truth) ที่ควรสะท้อนงานจริงและใส่ edge case แปลกๆ เข้าไปด้วย เช่น คำถามกำกวมหรือ input ที่ยาวผิดปกติ · สอง prompt หรือระบบที่เราต้องการวัด · สาม grader หรือวิธีตรวจให้คะแนน ซึ่งเลือกตามลักษณะงาน: งานที่มีคำตอบชัดเจน (เช่นจัดหมวดหมู่ ticket เป็น Hardware / Software / Other) ใช้ code ตรวจแบบ exact match หรือ string check ได้เลย · งานที่คำตอบถูกได้หลายแบบใช้การวัดความคล้ายเชิงความหมาย (semantic similarity) หรือ metric อย่าง ROUGE · ส่วนเรื่อง subjective อย่างน้ำเสียงหรือความเห็นอกเห็นใจ ใช้ LLM อีกตัวเป็นกรรมการตรวจ (แนวทางที่เรียกกันว่า LLM-as-a-judge) โดยให้คะแนน 1-5 หรือตอบ yes/no ก็ได้ Anthropic ย้ำว่าเกณฑ์ความสำเร็จต้อง specific และ measurable เช่น "F1 score อย่างน้อย 0.85 บนชุดทดสอบ 10,000 ข้อ" ไม่ใช่แค่ "อยากให้ตอบดี" และแนะให้เน้นข้อสอบจำนวนมากที่ตรวจอัตโนมัติได้ มากกว่าข้อสอบไม่กี่ข้อที่ต้องนั่งตรวจมือ

ทำไมคนทำงานยุค AI ต้องรู้จักคำนี้: เพราะระบบ AI ไม่เหมือนโปรแกรมทั่วไป แก้ prompt นิดเดียวหรืออัปเกรดเป็น model รุ่นใหม่ พฤติกรรมอาจเปลี่ยนทั้งระบบโดยเราไม่ทันสังเกต วิธีเดียวที่จะรู้ว่าเวอร์ชันใหม่ "ดีขึ้นจริง" หรือแค่ "รู้สึกว่าดีขึ้น" คือรัน evals ชุดเดิมแล้วเทียบคะแนนก่อนหลัง ซึ่งช่วยจับอาการถดถอย (regression) ได้ก่อนที่ของเสียจะไปถึงมือลูกค้า องค์กรไหนกำลังจะเอา chatbot มาตอบลูกค้าหรือให้ AI สรุปเอกสารสำคัญ ควรมองว่า evals คือด่าน QA ของยุค AI: ไม่มีตัวเลข ก็ไม่มีทางรู้ว่าระบบพร้อมใช้จริงหรือยัง และเมื่อระบบขึ้นใช้จริงแล้ว evals ยังต้องทำงานคู่กับ observability ที่คอยเก็บร่องรอยของคำขอจริงไว้ เพราะผ่านข้อสอบตอนพัฒนาไม่ได้แปลว่าจะไม่พังหน้างาน

ตัวอย่างจากบทสนทนาจริง

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

ทีม AI: การสุ่มถามเองไม่กี่ข้อยังเป็นแค่ vibe check ครับ ก่อนปล่อยจริงเราต้องทำ evals ก่อน: รวบรวมคำถามจริงจากลูกค้าสัก 100-200 ข้อพร้อมคำตอบที่ถูกต้อง รันให้ระบบตอบทั้งชุดแล้วตรวจคะแนนอัตโนมัติ จะได้ตัวเลขว่าตอบถูกกี่เปอร์เซ็นต์ และครั้งหน้าพอแก้ prompt หรือเปลี่ยน model ก็รันข้อสอบชุดเดิมซ้ำ เทียบได้ทันทีว่าดีขึ้นหรือแย่ลงตรงไหน

ระวังสับสนกับ

• benchmark : benchmark คือข้อสอบมาตรฐานกลางที่ใช้เทียบความสามารถของ "ตัวโมเดล" ข้ามค่าย เช่นเอาไว้ดูว่าโมเดลไหนเก่งคณิตกว่ากัน ส่วน evals ในบริบทการทำงานมักหมายถึงข้อสอบที่ทีมสร้างขึ้นเอง เพื่อวัด "แอปหรืองานเฉพาะของเรา" เช่น chatbot ของบริษัทเราตอบเรื่องสินค้าเราแม่นแค่ไหน
• guardrails : guardrails คือกลไกป้องกันตอนระบบทำงานจริง คอยกันไม่ให้คำตอบอันตรายหลุดออกไปแบบ realtime ส่วน evals คือการวัดผลช่วงพัฒนาและก่อนปล่อยใช้ ว่าระบบทำงานได้ตามเกณฑ์หรือไม่ · ใช้คู่กัน แต่คนละจังหวะเวลา
• vendor-lock-in : การมีชุด evals ของทีมเองไว้ทดสอบได้หลายโมเดลพร้อมกัน ช่วยให้เทียบผลข้ามค่ายเป็นตัวเลขจริง เวลาต้องประเมินว่าจะย้ายผู้ให้บริการ AI หรือไม่