Regression testing

Regression testing คือการรันชุดทดสอบเดิมซ้ำทุกครั้งที่มีการแก้อะไรในระบบ เพื่อดูว่าสิ่งที่เคยทำงานถูกต้องอยู่แล้วยังทำงานเหมือนเดิมหรือไม่ คำว่า regression หมายถึงอาการถอยหลัง คือข้อที่เคยผ่านกลับไม่ผ่านหลังการแก้ครั้งล่าสุด แนวปฏิบัตินี้มาจากงานพัฒนาโปรแกรมทั่วไปมานานแล้ว แต่พอย้ายเข้ามาอยู่ในงาน AI ชุดทดสอบที่ว่ามักถูกเรียกว่า evals ซึ่งคู่มือ evals ของ OpenAI นิยามไว้ว่า "Evaluations (often called evals) test model outputs to ensure they meet style and content criteria that you specify." คือทดสอบผลลัพธ์ที่ model ตอบออกมาว่าตรงกับเกณฑ์ด้านรูปแบบและเนื้อหาที่เรากำหนดไว้หรือไม่ และหน้าเดียวกันเขียนต่อว่าการเขียน evals เพื่อดูว่าระบบงานที่เราสร้างทำได้ตามที่คาดหวังแค่ไหน เป็นองค์ประกอบสำคัญของการสร้างระบบที่เชื่อถือได้ โดยเฉพาะตอนเปลี่ยนไปใช้ model รุ่นใหม่หรือทดลอง model ตัวอื่น

กลไกของมันไม่ซับซ้อน สิ่งแรกที่ต้องมีคือชุดข้อมูลทดสอบที่เก็บโจทย์ชุดเดิมไว้ใช้ซ้ำทุกรอบ แบบที่พบบ่อยคือเก็บคำตอบที่ถือว่าถูกไว้คู่กันด้วย ซึ่งตัวอย่างในคู่มือ evals ของ openai เรียกส่วนหลังนี้ว่า ground truth labels (ground-truth) แต่ไม่ใช่ทุกชุดทดสอบที่ต้องมีเฉลย ตัวอย่างจับ regression ของ prompt ของ OpenAI เองใช้วิธีให้ model อีกตัวให้คะแนนตามเกณฑ์ที่เขียนไว้แทน ถัดมาคือตัวให้คะแนนที่เรียกว่า grader ทำหน้าที่ตัดสินว่าคำตอบที่ได้ผ่านเกณฑ์หรือไม่ คู่มือ Detecting prompt regressions ฉบับเดียวกันนี้อธิบายโครงสร้าง evals ไว้ว่า "Evals have two parts, the 'Eval' and the 'Run'. An 'Eval' holds the configuration for your testing criteria and the structure of the data for your 'Runs'. An Eval can have many runs that are evaluated by your testing criteria." แปลว่าเกณฑ์ตั้งไว้ครั้งเดียวแล้วรันซ้ำได้หลายรอบ จึงเอารอบที่ใช้ prompt เดิมมาเทียบกับรอบที่ใช้ prompt ใหม่ด้วยไม้บรรทัดอันเดียวกันได้ อีกเรื่องที่ควรรู้คือหน้าคู่มือ evals ของ OpenAI ขึ้นประกาศไว้ด้านบนว่าบริษัทกำลังเลิกใช้เครื่องมือ Evals ของตัวเอง โดยเนื้อหา evals ที่มีอยู่เดิมยังใช้ได้ระหว่างช่วงเปลี่ยนผ่าน จะเหลือสถานะอ่านได้อย่างเดียวสำหรับผู้ใช้เดิมในวันที่ 31 ตุลาคม 2026 และมีกำหนดปิดในวันที่ 30 พฤศจิกายน 2026 ส่วนฝั่ง anthropic วางหลักออกแบบชุดทดสอบไว้ในหน้า Define success criteria and build evaluations ว่าให้ "Design evals that mirror your real-world task distribution. Don't forget to factor in edge cases!" และให้ตั้งคำถามในรูปที่ตรวจให้คะแนนอัตโนมัติได้ (automated-check) โดยยกตัวอย่างวิธีตรวจไว้เช่น multiple-choice, string match, code-graded และ LLM-graded พร้อมระบุว่า "More questions with slightly lower signal automated grading is better than fewer questions with high-quality human hand-graded evals." คือมีข้อทดสอบเยอะแม้สัญญาณจะอ่อนลงหน่อย ยังดีกว่ามีข้อทดสอบน้อยแล้วให้คนไล่ตรวจมือทีละข้อ ในองค์กรที่ทำเรื่องนี้จริงจัง ชุดทดสอบจะถูกผูกติดกับขั้นตอนปล่อยของอัตโนมัติ เอกสาร Observability in Generative AI ของ Microsoft Foundry เขียนว่าทีมสามารถ "integrate automated quality gates into CI/CD pipelines" ได้ คือตั้งด่านคุณภาพอัตโนมัติคั่นไว้ก่อนของจะขึ้นระบบจริง

คนทำงานมักเจอคำนี้ตอนที่ทีมแก้ prompt เพียงบรรทัดเดียวเพื่ออุดปัญหาที่ลูกค้าบ่นมา แล้วอีกสองสัปดาห์ถัดมาถึงรู้ว่างานอีกประเภทที่เคยตอบดีอยู่แล้วเพี้ยนไปตั้งแต่วันนั้น จุดที่งาน AI ต่างจากงานโปรแกรมทั่วไปคือผลลัพธ์ไม่ได้คงที่ (non-determinism) เอกสาร API ของ OpenAI อธิบายค่า seed ซึ่งกำกับสถานะไว้ว่ายังเป็น Beta ว่า "If specified, our system will make a best effort to sample deterministically, such that repeated requests with the same seed and parameters should return the same result. Determinism is not guaranteed, and you should refer to the system_fingerprint response parameter to monitor changes in the backend." คือแม้จะตรึงค่าให้เหมือนเดิมทุกอย่างแล้ว ระบบก็ทำได้แค่พยายามอย่างดีที่สุด ไม่ได้รับประกันว่าจะได้ผลเดิม การแก้ถ้อยคำใน prompt (prompt-engineering) จึงไม่มีอะไรฟ้องขึ้นมาทันทีเวลามันไปทำของอื่นพัง ก่อนของจะถึงมือผู้ใช้จริง ตัวที่บอกได้คือชุดทดสอบเดิมที่ถูกเอากลับมารันซ้ำ ข้อควรระวังคือชุดทดสอบไม่ได้แปลว่าครอบคลุมทุกอย่าง หน้ากำหนดเกณฑ์ความสำเร็จของ Anthropic เขียนไว้ว่า "Most use cases need multidimensional evaluation along several success criteria." คืองานส่วนใหญ่ต้องวัดหลายมิติไปพร้อมกัน วัดมิติเดียวไม่พอ และหน้าเดียวกันยังจัดให้ "Ambiguous test cases where even humans would find it hard to reach an assessment consensus" เป็นหนึ่งในกรณีขอบที่ควรใส่ไว้ในชุดทดสอบ คือข้อกำกวมที่ต่อให้เป็นคนก็ยังตกลงกันไม่ได้ว่าคำตอบไหนถูก แต่เอกสารไม่ได้บอกว่าให้ใครเป็นคนชี้ขาดข้อกลุ่มนี้ ทีมจึงต้องตกลงเกณฑ์กันเองผ่าน human-review ก่อนว่าคำตอบแบบไหนนับว่าผ่าน แล้วอ่านคะแนนของข้อกลุ่มนี้อย่างระวัง

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

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

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

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

• evals : evals คือตัวชุดทดสอบและวิธีให้คะแนน ส่วน regression testing คือวินัยของการเอาชุดนั้นกลับมารันซ้ำทุกครั้งที่แก้ของ แล้วเทียบผลกับรอบก่อนหน้า ทีมที่มี evals อยู่แล้วแต่ไม่เคยรันซ้ำหลังแก้ ยังไม่นับว่าได้ทำ regression testing
• benchmark : benchmark วัดว่า model ตัวไหนทำโจทย์กลางที่คนอื่นตั้งไว้ได้ดีกว่ากัน ส่วน regression testing วัดว่างานเฉพาะของเราที่เคยทำได้ยังทำได้อยู่หรือไม่ โจทย์จึงมาจากงานจริงของเราเอง ไม่ใช่ชุดข้อสอบสาธารณะ
• observability : observability คือการเฝ้าดูระบบที่ให้บริการอยู่จริงเพื่อรู้ว่าเกิดอะไรขึ้น ส่วน regression testing คือการรันชุดทดสอบเดิมซ้ำก่อนปล่อยของ ข้อควรระวังคือเอกสารของ Microsoft Foundry ใช้คำว่า observability กว้างกว่านั้น คือนับตั้งแต่ขั้นเลือก model ไปจนถึงการเฝ้าดูหลังขึ้นระบบจริง และจัดการประเมินก่อน production ไว้เป็นหนึ่งในความสามารถของ observability เอง โดยขั้นก่อน production ใช้ชุดข้อมูลทดสอบตรวจความพร้อม ส่วนขั้นหลัง production เพิ่มการประเมินการใช้งานจริงแบบสุ่มตัวอย่างเข้ามา