ทดลองก่อนแก้: โปรโตคอล 5 ส่วนที่ทำให้ปรับจูน AI Agent โดยไม่ต้องเดา (และไม่เผาเงิน)

ผมดูแลระบบ AI agent ที่ทำงานจริงทุกวัน และเกือบทุกสัปดาห์มันมีจุดให้อยากปรับ — เปลี่ยนโมเดลตัวนี้ เพิ่ม guard ตรงนั้น ขยับ threshold ให้เร็วขึ้น ความอยากที่จะ "แก้เลย" มันแรงมาก เพราะดูเหมือนใช้เวลาห้านาที แต่ผมเรียนบทเรียนนี้มาแบบเสียเงิน: ครั้งหนึ่งผมยิงการทดลองแบบเต็มรูปแบบที่ต้องจ่ายเงินก่อนจะลองแบบเล็ก ๆ ผลคือเจอ output ถูกตัดกลาง (truncation), provider ตอบ 404, และตัวอย่างน้อยเกินจนสรุปอะไรไม่ได้ — หลังจาก จ่ายเงินไปแล้ว ทั้งหมดนั้นคือ confound ที่ออกแบบให้หายได้ตั้งแต่ต้นถ้าผมลองเล็กก่อน บทความนี้คือกฎที่ผมใช้กันไม่ให้เกิดซ้ำ พร้อมเทมเพลตที่ก็อปไปใช้ได้เลย

1. ทำไม "แก้เลย" ถึงแพงกว่าที่คิด

ในงานที่ผมทำมาสายวัดความเสี่ยงของโมเดล (model risk) มีกฎเหล็กข้อหนึ่ง: คุณไม่ push โมเดลขึ้น production เพราะ "รู้สึกว่ามันดีขึ้น" คุณต้อง validate ก่อน มีหลักฐาน มีตัวเลขเทียบ before/after ที่ทำซ้ำได้ การเปลี่ยน config ของ AI agent ก็ควรอยู่ใต้มาตรฐานเดียวกัน เพราะ agent ยุคนี้ลงมือทำจริง — มันรันคำสั่ง แก้ไฟล์ เรียก API ที่มีค่าใช้จ่าย การเปลี่ยนตามความรู้สึกแล้วผิด ไม่ได้เสียแค่คุณภาพ แต่เสียเงินและเสียความน่าเชื่อถือของทั้งระบบ

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

ทำไมมันสำคัญกับเรา: "แก้เลย" ให้ความรู้สึกว่าเร็ว แต่มันคือการกู้เงินจากอนาคต — คุณจ่ายคืนตอนที่ระบบพังแล้วหาสาเหตุไม่เจอ การทดลองก่อนแก้ที่ดูช้ากว่าห้านาที จริง ๆ แล้วคือทางที่ถูกกว่าในระยะยาว เพราะทุกการเปลี่ยนมีหลักฐานกำกับ

2. กฎเดียวที่มาก่อนทุกอย่าง: เขียน protocol ก่อนแตะ API

หัวใจของทั้งระบบมีอยู่ประโยคเดียว: เขียนโปรโตคอลก่อน แล้วค่อยลงมือ ก่อนจะยิง API สักครั้ง ผมบังคับตัวเองให้เขียนไฟล์ protocol.md ที่ตอบคำถามเหล่านี้ให้ครบก่อน — และถ้าตอบไม่ได้ แปลว่ายังไม่พร้อมทดลอง ไม่ใช่พร้อมจ่ายเงิน

โปรโตคอลที่ดีตอบห้าเรื่อง: (1) คำถาม/สมมติฐาน ที่จะทดสอบคืออะไร วัดว่า "ดีขึ้น" ด้วยอะไร (2) วิธีการ — harness ไหน, เทียบกับ oracle/เฉลยอะไร, metric อะไร (3) backend ที่จะเทส ครบทุกตัวที่ระบบใช้จริง ไม่ใช่ตัวเดียว (4) งบประมาณ เป็นเงินและจำนวนตัวอย่าง พร้อมเหตุผล (5) รายการ confound ที่รู้ล่วงหน้า — เช่น max_tokens (กัน truncation), การ pin provider (กันผลไม่คงที่), จำนวนตัวอย่าง (กัน noise)

ทำไมมันสำคัญกับเรา: การเขียน confound checklist ก่อนรัน คือส่วนที่แยกการทดลองจริงออกจากการลองผิดลองถูก เพราะปัญหาส่วนใหญ่ที่ทำให้ต้องรันซ้ำ — output ถูกตัด, provider ไม่คงที่, ตัวอย่างน้อยไป — เป็นสิ่งที่ คาดเดาได้ ถ้าคุณคิดถึงมันตอนออกแบบ ไม่ใช่ตอนอ่านผลที่พัง

3. Artifact: โฟลเดอร์ทดลอง 5 ส่วนที่ก็อปไปใช้ได้เลย

พอแล้วสำหรับหลักการ นี่คือของจริง ทุกการทดลองของผมอยู่ในโฟลเดอร์เดียว ชื่อ lab/experiments/<วันที่>_<ชื่อสั้น>/ และข้างในมี 5 ส่วนตายตัว — ใครเปิดมาก็ reproduce ได้เองโดยไม่ต้องถามและไม่ต้องรันซ้ำ:

lab/experiments/2026-07-08_router-threshold/
├── protocol.md      # 1. คำถาม/วิธี/backends/งบ/confounds — เขียนก่อนแตะ API
├── harness.py       # 2. โค้ดที่ใช้รันจริง (หรือ path ไป tool ที่เรียก)
├── commands.md      # 3. คำสั่งที่รัน verbatim — ก็อปวางซ้ำได้ทันที
├── results/         # 4. report.md + raw JSON ของ "ทุก" call (ห้ามทิ้ง)
└── findings.md      # 5. สรุป + decision + ลิงก์ไป artifact ที่เกี่ยวข้อง

ส่วนที่คนมักทำหลุดคือข้อ 4 — เก็บ output ดิบทุก call ไว้ ไม่ใช่เก็บแค่ตารางสรุป เพราะเมื่อไหร่ที่คุณอยากดูรายละเอียดเพิ่ม (เกิดอะไรกับตัวอย่างที่ 7 ทำไมมันพลาด) คุณจะได้ re-analyze จากไฟล์ ไม่ใช่ยิง API ซ้ำเสียเงินรอบสอง นี่คือเทมเพลต protocol.md ขั้นต่ำที่ก็อปไปเริ่มได้เลย:

# Experiment: <ชื่อ> (<วันที่>)

## คำถาม
เปลี่ยน <อะไร> แล้ว <metric> ดีขึ้นไหม เทียบกับ baseline ปัจจุบัน?

## สมมติฐาน
<คาดว่าเกิดอะไร และเพราะอะไร>

## วิธีวัด
- harness: <ไฟล์/คำสั่ง>
- oracle/เฉลย: <วัดถูก-ผิดด้วยอะไร>
- metric: <ตัวเลขที่ตัดสิน เช่น pass-rate, tokens, latency>

## Backends ที่เทส (ครบทุกตัวที่ระบบใช้จริง)
- [ ] local (ฟรี)
- [ ] free-tier API
- [ ] paid (เทสท้ายสุด)

## งบประมาณ
- ตัวอย่าง: N = <จำนวน> ต่อ backend  (เหตุผล: <กัน noise>)
- เพดานเงิน: $<cap>  (หยุดถ้าเกิน)

## Confound checklist (กันไว้ก่อนรัน)
- [ ] max_tokens สูงพอ — กัน output ถูกตัด
- [ ] pin provider/เวอร์ชันโมเดล — กันผลไม่คงที่
- [ ] N ≥ 3 ต่อเงื่อนไข — กัน n=1 noise
- [ ] แยก state ระหว่างรัน — กันปนเปื้อน

4. วินัยกันเผาเงิน: pilot ก่อน paid เสมอ

กฎที่แพงที่สุดที่ผมได้มาคือข้อนี้ — ยิง pilot 1 call ต่อ 1 backend ให้ผ่านก่อน แล้วค่อยรันเต็ม เพราะ pilot ตัวเล็ก ๆ นี่แหละที่จับ truncation, provider ผิด, format เพี้ยน ได้ในราคาถูก ก่อนที่คุณจะยิงเต็มร้อยตัวอย่างแล้วเจอปัญหาเดียวกันตอนบิลมาแล้ว ผมสรุปวินัยเรื่องเงินไว้สี่ข้อ:

• Pilot ก่อน full เสมอ — 1 call/1 sample ต่อ backend เพื่อจับปัญหาถูก ๆ ก่อนจ่ายจริง
• Free-first — validate harness บนโมเดล local หรือ free-tier ($0) ให้เวิร์กก่อน ค่อยแตะตัวที่จ่ายเงิน แนวคิดเดียวกับที่ผมเขียนไว้ในการ route งานไป local ก่อน
• เก็บ raw output ทุก call — re-analyze แบบ offline ได้โดยไม่ยิง API ซ้ำ
• แก้ confound ที่ตอนออกแบบ ไม่ใช่ตอน re-run — ตั้ง max_tokens, pin provider, เพิ่ม N ให้ถูกตั้งแต่ก่อนรัน แล้วให้ pilot ยืนยัน

หลักคิดนี้คือ least-privilege ในเวอร์ชันต้นทุนการทดลอง: จ่ายเท่าที่จำเป็นต้องรู้ในขั้นนั้นจริง ๆ ไม่ใช่จ่ายเต็มเผื่อไว้ตั้งแต่ยังไม่รู้ว่า harness เวิร์กไหม

ทำไมมันสำคัญกับเรา: ต้นทุนต่ำไม่ใช่แค่เรื่องประหยัด มันคือ staying power — ถ้าการทดลองแต่ละครั้งถูกและทำซ้ำได้ คุณจะกล้าทดลองบ่อย และระบบที่ถูกปรับจูนด้วยการทดลองบ่อย ๆ จะดีขึ้นเร็วกว่าระบบที่เจ้าของกลัวค่าใช้จ่ายจนไม่กล้าแตะ

5. ปิด loop: เปลี่ยน infra จริงต่อเมื่อผ่าน ROBUST

ผลการทดลองครั้งเดียวยังไม่พอจะเปลี่ยนระบบจริง ผมตั้งเกณฑ์ไว้ว่าจะอัปเดต infra ต่อเมื่อผลนั้น ROBUST — ทำซ้ำแล้วได้ทิศเดียวกันหลายครั้ง ไม่ใช่ฟลุ้กครั้งเดียว ระหว่างที่ยังไม่ ROBUST การเปลี่ยนอยู่แค่ในเอกสาร ยังไม่แตะโค้ดที่รันจริง นี่คือ safety valve เดียวกับที่กันไม่ให้โมเดลที่ perform ดีเพราะบังเอิญ หลุดขึ้น production

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

ทำไมมันสำคัญกับเรา: เกณฑ์ ROBUST คือเส้นแบ่งระหว่าง "ระบบที่ค่อย ๆ ดีขึ้นอย่างมั่นคง" กับ "ระบบที่แกว่งไปมาตามการทดลองครั้งล่าสุด" การมีเกณฑ์ชัดว่าอะไรถึงจะเปลี่ยนของจริงได้ ทำให้ kaizen เป็นการสะสม ไม่ใช่การสุ่ม

ภาพรวม

ทดลองก่อนแก้ไม่ใช่พิธีที่ทำให้ช้าลง มันคือวิธีทำให้ทุกการเปลี่ยนแปลงมีหลักฐานและทำซ้ำได้ — เขียน protocol ก่อนแตะ API, เก็บทุกอย่างไว้ในโฟลเดอร์เดียว 5 ส่วน, pilot ก่อน paid เสมอ, และเปลี่ยน infra จริงต่อเมื่อผลนิ่งพอที่จะเรียกว่า ROBUST นี่คือ discipline เดียวกับที่คนทำ model validation ใช้กับโมเดลเครดิต แค่ย้ายมาใช้กับ AI agent

สิ่งที่ผมเล่าในบทนี้คือกรอบและเทมเพลตที่เริ่มใช้เองได้วันนี้ ส่วนระบบเต็ม — backend registry ที่ครอบทุกโมเดลในที่เดียว, เกณฑ์ ROBUST ที่ calibrate จากการรันจริง, และการต่อ pipeline ทดลองเข้ากับ QC และ guard อัตโนมัติ — ผมประกอบไว้ทั้งชุดในคอร์ส Claude Code พร้อม workspace ที่ก็อปไปทั้งก้อนแล้วรันได้