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

ทำไม unit tests ถึงไม่เพียงพอสำหรับ AI agents

Unit tests ใช้ได้ผลกับโค้ดแบบดั้งเดิมเพราะ input แบบเดิมจะให้ output แบบเดิมเสมอ “2 + 2 = 4” คือสิ่งที่คุณสามารถตรวจสอบได้ด้วยการเช็คความเท่ากันแบบง่ายๆ อย่างไรก็ตาม LLM-driven agent จะเปลี่ยน output ไปตาม prompt, บริบทแวดล้อม และสถานะของเครื่องมือภายนอก (external tools) ที่เรียกใช้ การทดสอบที่เช็คแค่ความเท่ากันของ string จะพลาดเรื่องการหลอน (hallucinations), การเปลี่ยนโทนเสียง หรือการละเมิด guardrails ความล้มเหลวที่เงียบเชียบซึ่งทำให้ผมเสียลูกค้าแสดงให้เห็นว่า คุณต้องประเมินการโต้ตอบทั้งหมด ไม่ใช่แค่ฟังก์ชันที่แยกส่วนกัน

การสร้าง evaluation harness ก่อนเริ่มเขียนโค้ดฟีเจอร์ใดๆ

ผมสลับลำดับการพัฒนา: ออกแบบ evaluation harness แบบสี่ชั้นก่อน แล้วค่อยเขียน agent ตัว harness นี้รันการทดสอบ 131 รายการในการรันเพียงครั้งเดียว มีค่าใช้จ่ายประมาณ 3 เซนต์ต่อการรันหนึ่งครั้ง และใช้เวลาประมาณ 11 นาที ผมกำหนดให้แต่ละการทดสอบใช้โมเดลที่เล็กที่สุดเท่าที่จะจัดการได้ โดยจะสำรองโมเดลที่ใหญ่และแพงกว่าไว้สำหรับช่วงเวลาที่จำเป็นต้องใช้จริงๆ เท่านั้น

Layer 1 – การทำงานของเครื่องมือ (Tool functionality)

ด่านแรกคือการตรวจสอบว่า agent สามารถเรียกใช้เครื่องมือได้อย่างถูกต้องหรือไม่ การทดสอบครอบคลุมถึงการค้นหาที่สำเร็จ, การส่ง query ที่ตั้งใจทำให้ผิดรูปแบบ และการจำลองความล้มเหลวของ API เนื่องจากเครื่องมือส่วนใหญ่ทำงานแบบ deterministic—ไม่ว่าจะเป็นการสร้าง request ที่ถูกต้องหรือ API ส่ง error กลับมา—การใช้ Python assertions แบบง่ายๆ จึงเพียงพอแล้ว การตรวจพบ request ที่ผิดรูปแบบตั้งแต่ขั้นตอนนี้จะช่วยป้องกันความสับสนในขั้นตอนถัดไป

Layer 2 – การปฏิบัติตามคำสั่ง (Instruction following)

ต่อมา harness จะตรวจสอบว่า agent เคารพ guardrails หรือไม่ โดยใช้ LLM ขนาดเล็กทำหน้าที่เป็นผู้ประเมิน (evaluator) เพื่อสแกนคำตอบของ agent ว่าเป็นไปตามข้อกำหนดหรือไม่ เช่น การรักษาบุคลิก (character), การหลีกเลี่ยงหัวข้อที่ต้องห้าม และการส่งออก JSON schema ตามที่กำหนด เลเยอร์นี้จะตรวจจับ semantic drift ที่ unit tests มองไม่เห็น เช่น การหลุดเข้าไปในบุคลิกที่ไม่ตั้งใจ หรือการหลุดข้อมูล prompt ภายในออกมา

Layer 3 – พฤติกรรมที่มุ่งเน้นเป้าหมาย (Goal-oriented behavior)

เลเยอร์ที่สามคือส่วนที่สำคัญที่สุด มันตั้งคำถามว่า agent บรรลุวัตถุประสงค์ของมันจริงๆ หรือไม่ สำหรับบอทหาลูกค้า (lead-generation bot) นั่นหมายถึงการยืนยันว่ามันถามคำถามคัดกรองที่ถูกต้อง และส่งต่อให้มนุษย์เมื่อถึงเวลาที่เหมาะสม ผมใช้โมเดลที่เน้นการใช้เหตุผล (reasoning-oriented model) ในขั้นตอนนี้ เพราะมันสามารถประเมินภาพรวมของบทสนทนาได้โดยไม่ทำให้ค่าใช้จ่ายสูงเกินไป หากบอทไม่สามารถบรรลุเป้าหมายได้—แม้ว่าจะผ่านสองเลเยอร์แรกมาแล้วก็ตาม—มันจะถูกทำเครื่องหมายเพื่อนำไปออกแบบใหม่

Layer 4 – ประสิทธิภาพ (Performance)

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

ทางเลือกในการประหยัดต้นทุน

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

ข้อแลกเปลี่ยน: ความเร็ว กับ ความปลอดภัย

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

สิ่งที่ควรจับตามองต่อไป

  • Model-driven evaluators: เมื่อ LLM เก่งขึ้น ผู้ประเมินใน Layer 2 จะสามารถมีความละเอียดอ่อนมากขึ้น ช่วยลด false positives ในขณะที่ยังสามารถตรวจพบการละเมิดนโยบายที่แนบเนียนได้

บทสรุป

หากคุณสร้าง AI agent เพื่อใช้งานจริง การมี evaluation harness แบบแบ่งเลเยอร์ไม่ใช่ทางเลือก แต่เป็นพื้นฐานสำคัญ การลงทุนกับต้นทุนการทดสอบที่ครอบคลุมตั้งแต่เนิ่นๆ—0.03 ดอลลาร์ต่อการรัน, 11 นาทีต่อหนึ่งชุดการทดสอบ—จะช่วยปกป้องคุณจากความล้มเหลวที่เงียบเชียบซึ่ง unit tests ไม่สามารถตรวจพบได้