QC Pipeline สำหรับ AI Output: วิธีที่ Data Scientist ในแบงก์ตรวจงาน AI ก่อนเข้า Production

ผมทำงานด้าน Model Risk Management (MRM) ในธนาคารไทยมาหลายปี สิ่งที่ฝังอยู่ใน DNA ของงานนี้คือ "ห้ามเชื่อ output โดยไม่ตรวจสอบ" — ไม่ว่าจะเป็น credit scoring model, ECL forecast, หรือ NLP Early Warning System ที่ผมสร้างเอง ทุก output ต้องผ่าน validation ก่อนนำไปตัดสินใจทางธุรกิจ เมื่อผมสร้างระบบ agentic AI ที่รัน task อัตโนมัติ ความคิดแรกที่เกิดขึ้นคือ: ต้องมี QC pipeline ก่อน output ออกสู่โลกจริง

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

ก่อนมีระบบ QC ผมใช้วิธีที่ดูสมเหตุสมผล: ให้ AI รันก่อน แล้วค่อยไปดูผล แต่ในงานจริงมัน fail เร็วมากด้วย failure mode ที่ซ้ำกัน 3 อย่าง

Thinking leak — AI thinking model (โมเดลที่ "คิด" ก่อนตอบ) บางครั้งหลุด internal monologue ออกมาใน output เช่น (Wait, let me reconsider...) หรือ (Note: the instruction says...) ประโยคพวกนี้ไม่ใช่ content จริง แต่ถ้าไม่มีระบบจับ มันวิ่งเข้า pipeline ถัดไปราวกับว่าเป็นคำตอบที่ถูกต้อง ผมเคยเจอกรณีที่ reasoning ของโมเดลหลุดกลางย่อหน้าจนเอกสารอ่านไม่รู้เรื่อง

Format drift — เมื่อ session ยาวขึ้น context window เริ่มแน่น output structure เริ่มเบี่ยงจาก template ที่ตกลงไว้ section ที่ควรมีหาย header ที่ต้องเป๊ะกลายเป็นอะไรก็ได้ ปัญหานี้เกิดบ่อยกว่าที่คิด เพราะ AI model ไม่ได้ "จำ" template เหมือนมนุษย์ — มัน infer จาก context ที่เหลืออยู่

Cascade error — output จาก step แรกที่ผิดพลาดเล็กน้อย กลายเป็น input ของ step ถัดไป ความผิดพลาดสะสมไปเรื่อย ๆ จน trace กลับมาหา root cause ได้ยากมาก ในระบบที่รัน task ต่อ task อัตโนมัติ cascade error แค่ครั้งเดียวอาจทำให้งานหลายชั่วโมงต้องทำใหม่ทั้งหมด

ทำไมมันสำคัญกับเรา: ใน MRM ทุก model output ต้องผ่าน validation ก่อนใช้ตัดสินใจ regulatory framing เดียวกันใช้กับ AI agent ได้เลย — "trust but verify" ไม่ใช่แค่ best practice มันคือ first principle ของการทำงานกับระบบอัตโนมัติ

2. QC Pipeline 3 ชั้นที่ใช้งานจริง

ระบบของผมแบ่ง QC ออกเป็น 3 ชั้น แต่ละชั้นมีหน้าที่ชัดเจน ทำงานตามลำดับก่อนที่ output จะถูก accept เข้าสู่ขั้นถัดไป

ชั้นที่ 1 — Thinking Leak Detector

ชั้นแรกสแกน output ด้วย pattern matching หา signature ของ internal monologue เช่น (Wait, (Note: (I will (Correction: ถ้าเจอ → ส่งกลับทันที ไม่ proceed ต่อ

สิ่งที่ทำให้ thinking leak อันตราย: มันไม่ได้แค่ทำให้ output อ่านยากขึ้น มันบ่งชี้ว่าโมเดลอาจยัง "resolve" ความไม่แน่ใจของตัวเองไม่เสร็จก่อนให้คำตอบ — ซึ่งแปลว่า content ที่ตามมาอาจ unreliable โดยเฉพาะใน task ที่ต้องการความแม่นยำสูง

ชั้นที่ 2 — Numbers Audit

ชั้นนี้ดึงตัวเลขทุกตัวออกมาพร้อม context รอบข้าง เพื่อให้ reviewer หรือ automated check ถัดไปตรวจสอบว่าตัวเลขมีที่มาที่เชื่อถือได้หรือไม่ เช่น ถ้าโมเดลเขียนตัวเลข NPL ratio ของธนาคาร ระบบจะ flag ตัวเลขนั้นพร้อมประโยคโดยรอบเพื่อ verify

ทำไม AI ถึงเป็นอันตรายกับตัวเลข? เพราะ language model ถูก train ให้สร้าง text ที่ "ดูน่าเชื่อในบริบท" ไม่ใช่ text ที่ "arithmetic ถูกต้อง" — ตัวเลขที่ดูเหมือนสมเหตุสมผลอาจเป็นการ hallucinate ที่แนบเนียนมาก วิธีเดียวที่ catch ได้คือ explicit audit ทุกตัว — ผมขยายแนวคิดนี้เป็นสามด่านตรวจตัวเลขที่ผู้เขียนโกงตัวเองไม่ได้ พร้อมสคริปต์ที่ก็อปไปใช้ได้ ตัวอย่าง: โมเดลอาจเขียน NPL ratio ของธนาคารออกมาเป็น "ตัวเลขที่ดูสมเหตุสมผล" โดยไม่มี source จริง

ชั้นที่ 3 — Structure และ Compliance Check

สำหรับ content-heavy output ชั้นนี้ตรวจ:

• Section structure ตรง template ที่กำหนดไหม
• มี required element เช่น CTA หรือ disclaimer ตามที่กำหนดไหม
• มีการอ้างข้อมูล risky โดยไม่มี disclaimer ที่เหมาะสมไหม
• Body length ถึง minimum threshold ไหม (ป้องกัน truncated output)

ทำไมมันสำคัญกับเรา: pipeline 3 ชั้นนี้เหมือน "automated test suite" สำหรับ AI output — แทนที่จะ test code เรา test content ก่อนที่มันจะออกสู่ระบบ downstream แนวคิดนี้มาตรงจากงาน model validation

3. Askback Loop — จัดการ Failure อย่างประหยัด

เมื่อ output fail QC มีทางเลือก 3 อย่าง:

1. Rerun ทั้งหมด — แพง ใช้ token เยอะ และมักได้ผลเดิมถ้าไม่เปลี่ยน prompt
2. Ignore — ผิด ความผิดพลาดยิ่งสะสมและซ้ำในครั้งต่อไป
3. Askback — ระบุ exact point ที่ fail แล้วให้โมเดลแก้เฉพาะจุดนั้น

ผมเลือกแนวทางที่สาม: askback loop — อ่าน output head ก่อน (ประหยัด context) → รัน QC script → ระบุจุดที่ fail → ส่ง targeted correction กลับไปหาโมเดล ทำซ้ำไม่เกิน 4 รอบ → ถ้าผ่านแล้ว proceed; ถ้าไม่ผ่านหลัง 4 รอบ → flag สำหรับ human review

หลักการที่ควบคู่กันคือ "patch and proceed" — ถ้า output ถูกต้องส่วนใหญ่ (โครงสร้างผ่าน, ข้อมูลครบ) ให้ patch จุดที่ผิดแล้วไปต่อ ไม่ต้อง rerun ทั้งหมด วิธีนี้ทำให้ระบบที่รัน task จำนวนมากต่อวันยัง scale ได้โดยไม่เผาผลาญ token โดยไม่จำเป็น

ทำไมมันสำคัญกับเรา: ใน model validation เราไม่ retrain ทุกครั้งที่เจอ edge case — เราออกแบบ feedback loop ที่ targeted และวัดผลได้ แนวคิดเดียวกัน ประหยัดทั้ง cost และเวลาในระบบ AI agent

4. Journal QC — ตรวจสอบ Knowledge Base ตัวเอง

QC ระดับที่สี่ที่คนมักมองข้าม: ตรวจสอบ knowledge ที่ระบบสะสมไปเอง

AI agent ในระบบของผมเขียน journal ทุก session — บันทึก decision, finding, hypothesis, และ experiment result ที่ผ่านมา Journal เหล่านี้กลายเป็น input ของ session ถัดไปผ่าน wiki second brain ดังนั้นถ้า journal ผิด → session ถัดไปเริ่มด้วยข้อมูลผิด → เกิด cascade error ที่ต้นน้ำ

ระบบ journal QC ตรวจ:

• Format ถูกต้องตาม schema ที่กำหนดไหม (ไม่มี placeholder ที่ลืมแก้)
• Timestamp และ reference slug ถูกต้องและ consistent กันไหม
• ไม่มี ghost template — section ที่ AI copy มาจาก template แต่ไม่ได้ fill ข้อมูลจริง
• ไม่มีส่วนที่ pre-written ก่อนงานจริง (ป้องกัน AI เขียน insight ก่อนทำงาน)

การรักษา quality ของ knowledge base ที่สะสมไปในระยะยาวคือ competitive advantage ของระบบ ดูเพิ่มเติมว่า wiki second brain ทำงานในระบบนี้ยังไงได้ที่ wiki second brain สำหรับ agentic AI lab และดูว่าระบบ autonomous runner ที่รัน task ต่อเนื่องทำงานอย่างไรได้ที่ autonomous runner 24/7

ภาพรวม

QC pipeline ที่ดีสำหรับ AI agent ไม่ใช่แค่ "check ว่า output มีหรือเปล่า" — มัน validate ว่า output มีคุณภาพพอที่จะ proceed ต่อในแต่ละมิติ: ไม่มี thinking leak, ตัวเลขมี traceability, โครงสร้างตรง template, และ knowledge base ที่สะสมไปยังคง integrity อยู่

สิ่งที่ผมพบคือ mindset จากงาน MRM (ทุก model output ต้องผ่าน validation ก่อนใช้) ทำให้การออกแบบ QC สำหรับ AI agent เป็นเรื่องที่ flow มาตามธรรมชาติ — ไม่ใช่ overhead ที่ add on ทีหลัง แต่เป็น first principle ที่ออกแบบเข้าไปตั้งแต่ต้น

ตัวเต็ม — รวม script จริง (qc_output.py, script_check.py, journal_qc.py), threshold ที่ calibrate จาก lab data, integration pattern กับ dispatch system, กลไก askback loop แบบ token-efficient, และ workspace ที่ก็อปไปใช้ได้เลย — อยู่ในคอร์ส Claude Code สำหรับ Data Scientist ดูรายละเอียดคอร์ส