QC ผลงานของ AI ก่อนขึ้น production: 4 ชั้นที่ใช้ตรวจงานตอนสร้าง Terminal

AI agent ทำงานเร็ว แต่ความเร็วไม่มีความหมายถ้าไม่มีใครตรวจ นี่คือด่าน QC 4 ชั้นที่ใช้จริงตอนสร้าง Boom Leverage Terminal — จากสคริปต์จับความคิดรั่ว ไปจนถึงด่านก่อนเผยแพร่ที่ห้ามตัวเลขไม่มีที่มา — พร้อมเคสที่ด่านเองก็พลาด และสถิติว่า 96% ของแผนถูกตีกลับให้แก้

โดย วรัญชัย ยิ่งคำนึง (Boom) · เผยแพร่ครั้งแรก 27 มิถุนายน 2569 · ตรวจทานล่าสุด 27 กันยายน 2569

ตอนให้ AI agent ช่วยสร้าง Boom Leverage Terminal สิ่งที่ผมกลัวที่สุดไม่ใช่งานที่ออกมาพังให้เห็น แต่คืองานที่ ดูเรียบร้อย แต่ผิดเงียบๆ — ตัวเลขที่ดูสมเหตุสมผลแต่ไม่มีที่มา สรุปที่อ่านลื่นแต่ข้ามประเด็นสำคัญ

ในงาน model validation ของธนาคาร เราไม่เชื่อ output ของโมเดลเพราะมันดูดี เราตรวจมันเป็นชั้นๆ ก่อนให้ใครใช้ตัดสินใจ ผมเอาวิธีคิดเดียวกันมาทำเป็นด่าน QC ใน harness ของ agent (พื้นฐานเรื่อง harness อยู่ใน Harness คืออะไร)

ทำไม "รัน AI แล้วดูผล" ถึงไม่พอ?

เพราะคนที่ดูผลเหนื่อยเป็น และความผิดพลาดของ language model มีลักษณะเฉพาะ: มันถูกฝึกให้เขียนข้อความที่ ดูน่าเชื่อในบริบท ไม่ใช่ข้อความที่ ถูกต้องตามข้อเท็จจริง ตัวเลขที่แต่งขึ้นจึงแนบเนียนกว่าที่ตาคนจับได้ในการอ่านรอบเดียว

เมื่อ agent รันงานหลายสิบชิ้นต่อวัน การตรวจด้วยตาอย่างเดียวจะหลุดแน่นอน ต้องมีเครื่องช่วยกรองก่อน แล้วค่อยให้คน (หรือโมเดลที่เก่งกว่า) ตรวจเฉพาะส่วนที่ต้องใช้วิจารณญาณ

QC 4 ชั้นหน้าตาเป็นยังไง?

ชั้น 1–2 ถูกมากเพราะเป็นสคริปต์ ชั้น 3 แพงกว่าเพราะใช้โมเดลตัวใหญ่ การเรียงแบบนี้ทำให้งานที่พังชัดๆ ถูกคัดออกก่อนเสียเงินกับชั้นแพง

ทำไมความคิดรั่วถึงเป็นสัญญาณอันตราย?

ไม่ใช่แค่เพราะมันทำให้ข้อความอ่านยาก แต่มันบอกว่าโมเดลอาจยัง ไม่ได้สรุปความไม่แน่ใจของตัวเอง ก่อนตอบ เนื้อหาที่ตามมาจึงไว้ใจได้น้อยลง โดยเฉพาะงานที่ต้องแม่นยำ

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

MiniMax M3 emits <think>…</think> instead and sailed through this check as a clean PASS on 2026-08-10.

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

ถ้างานไม่ผ่าน ต้องรันใหม่ทั้งหมดไหม?

ไม่ มี 3 ทางเลือกเมื่องานตก QC:

1. รันใหม่ทั้งหมด — แพง และมักได้ผลเดิมถ้าไม่เปลี่ยนอะไร
2. ปล่อยผ่าน — ผิด ความผิดพลาดจะสะสม
3. askback — ชี้จุดที่ผิดแล้วให้โมเดลแก้เฉพาะจุดนั้น

ระบบใช้ทางที่ 3: อ่านหัวผลงานก่อน (ประหยัดบริบท) → รันสคริปต์ QC → ส่งคำสั่งแก้แบบเจาะจง ไม่เกิน 2–4 รอบ → ถ้ายังไม่ผ่านให้คนตรวจ คู่กับกฎ "patch and proceed": ถ้าผลถูกเกิน 80% (โครงสร้างผ่าน ข้อมูลครบ) Claude แก้ส่วนที่เหลือเองแล้วไปต่อ ไม่สั่งรันใหม่

อีกกฎที่ห้ามข้าม: ห้ามทำงานซ้ำเองเงียบๆ (shadow-execute) — ถ้าผลลูกน้องไม่ดี ให้ตีกลับพร้อมเหตุผล ไม่ใช่ทำเองใหม่แล้วทิ้งผลเดิม เพราะไม่อย่างนั้นเราจะไม่มีวันรู้ว่าลูกน้องพลาดตรงไหน และจะไม่มีวันแก้ guard ให้ดีขึ้น

แผนงานต้องผ่าน QC ด้วยไหม?

ต้อง และนี่คือชั้นที่ให้ผลเยอะที่สุด ก่อนเปลี่ยนโครงสร้างระบบหรือสรุปผลการทดลอง แผนต้องผ่าน ด่านตรวจแบบ adversarial: ส่งให้โมเดลอีก 2 ตัวโจมตีแผนคนละมุม (สมมติฐานที่ไม่ได้ตั้งคำถาม และกรณีขอบที่ทำให้พัง) แล้ว Claude อ่านทั้งสองฝั่งก่อนแก้แผน

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

ด่านสุดท้ายก่อนถึงมือผู้ใช้คืออะไร?

ด่านของ product เอง ตัวอย่างจากรอบนำร่องชุดข้อมูล 56-1 (12 ก.ค. 2026) ที่ต้องผ่านครบ 4 ข้อก่อนเผยแพร่:

กฎที่อยู่เบื้องหลังทั้งหมดคือกฎเดียวกับที่ Terminal ใช้กับทุกผลค้นหา: บรรทัดที่ชี้กลับไปหน้าต้นฉบับไม่ได้ จะไม่ถูกแสดง ตัวอย่างการอ่านเอกสารแบบอ้างหน้าได้ดูใน อ่านงบการเงิน 3 มุม

สรุป

QC ของงาน AI ไม่ใช่ขั้นตอนเดียวตอนท้าย แต่เป็นชั้นที่เรียงจากถูกไปแพง: สคริปต์จับของพังชัดๆ, ตัวเลขทุกตัวถูกดึงออกมาตรวจ, Claude ตรวจความหมายและสั่งแก้เฉพาะจุด และ product มีด่านสุดท้ายที่ไม่ยอมให้ตัวเลขไม่มีที่มาผ่าน ที่สำคัญคือต้องทดสอบด่านกับของใหม่เสมอ เพราะวันที่ด่านพลาดคือวันที่มันเจอสิ่งที่ไม่เคยเห็น (ภาพรวมของระบบอยู่ใน ทำไมผมสร้าง Terminal ด้วย Claude Code)