เมื่อระบบขึ้นข้อผิดพลาด HTTP 500 ถี่ขึ้น AI อาจตอบทันทีว่าเวอร์ชันล่าสุดทำให้หน่วยความจำรั่ว แต่พอคนตรวจแล้วไม่ใช่ ก็เปลี่ยนไปโทษตัวตรวจความพร้อมของบริการ สุดท้ายคนดูแลระบบยังต้องไล่หาหลักฐานและถามกลับทีละข้อ
ตามบทถอดเสียงที่เก็บไว้ Willem Pienaar ซึ่งแนะนำตัวว่าเป็นผู้ร่วมก่อตั้งและ CTO ของ Cleric ในการบรรยายทางช่อง AI Engineer ยกตัวอย่างนี้เพื่ออธิบายว่า Agent ที่ช่วยเขียนโค้ดได้ดี ยังอาจวิเคราะห์ปัญหาในระบบที่เปิดใช้งานจริงหรือ production พลาด เพราะไม่มีสัญญาณตอบกลับที่ชัดเหมือนผลทดสอบโค้ด
แนวทางที่ Pienaar อธิบายในบทถอดเสียงคือให้ Agent ตรวจหลายสมมติฐาน เทียบกับสภาพปกติของระบบ และส่งหลักฐานต่อกันให้ครบ จากนั้นติดตามด้วยว่าคนแก้ตามคำแนะนำแล้วปัญหาหายจริงหรือไม่ บทความนี้เรียบเรียงวิธีดังกล่าว พร้อมแยกข้อเสนอสำหรับนำไปใช้ในทีมออกจากผลที่ผู้บรรยายรายงาน
ลิงก์วิดีโอต้นทางสำหรับอ้างอิง (ไม่พร้อมรับชมเมื่อตรวจสอบวันที่ 10 ตุลาคม 2026): Your AI Agent Is Confidently Wrong About Production — Willem Pienaar, Cleric · ช่อง AI Engineer · ผู้บรรยาย Willem Pienaar, Cleric
ทำไมระบบจริงจึงตรวจคำตอบยากกว่าโค้ด
งานเขียนโค้ดมีขอบเขตค่อนข้างชัด เมื่อ Agent แก้ไฟล์แล้วคอมไพล์ไม่ผ่าน ชุดทดสอบล้มเหลว หรือเครื่องมือตรวจโค้ดพบปัญหา มันได้รับข้อมูลกลับไปแก้รอบถัดไปได้ทันที แต่ใน production หลักฐานอาจกระจายอยู่ในบันทึกเหตุการณ์ ตัวชี้วัด และการเปลี่ยนแปลงของหลายทีม
Pienaar แบ่งความยากออกเป็นสามเรื่อง:
- ขอบเขตไม่ชัด: ปัญหาอาจข้ามบริการ คลัสเตอร์ หรือทีม Agent จึงไม่รู้ว่าควรค้นกว้างแค่ไหน
- สถานะเปลี่ยนระหว่างตรวจ: มีการปล่อยเวอร์ชันหรือปรับระบบอยู่เรื่อย ๆ ข้อมูลที่เห็นตอนเริ่มอาจต่างจากตอนสรุป
- เหตุการณ์เกิดชั่วคราว: บางปัญหาปรากฏเพียงช่วงสั้น ๆ และย้อนกลับไปทำซ้ำไม่ได้เหมือนการรันทดสอบโค้ด
คำว่า production “ไม่มีตัวตรวจสอบ” ในบทถอดเสียงจึงหมายถึงการขาดสัญญาณตอบกลับที่ชัดและรวมอยู่ในจุดเดียว ไม่ใช่ว่าระบบจริงตรวจสอบอะไรไม่ได้ โจทย์ที่ Pienaar อธิบายคือรวบรวมสัญญาณเหล่านั้นให้ Agent ใช้ทบทวนคำตอบระหว่างสืบหาปัญหาและหลังแก้ไข
ผู้บรรยายยังตั้งข้อสังเกตว่า งานวิเคราะห์เหตุขัดข้องต้องอาศัยความสงสัยและการตัดสมมติฐานทิ้ง ขณะที่โมเดลมักตอบอย่างรวดเร็วและมั่นใจ ประเด็นนี้เป็นคำอธิบายของเขาถึงปัญหาที่พบ ไม่ใช่ผลวัดคุณภาพของโมเดลทุกตัว
ความผิดพลาดสี่แบบที่ Pienaar กล่าวถึง
1. เห็นอาการแล้วคิดว่าเจอต้นเหตุ
Agent ตามการแจ้งเตือนไปยังบริการหนึ่ง เจอ error log แล้วหยุดค้น ทั้งที่บริการนั้นอาจรับผลกระทบมาจากอีกส่วนของระบบ การค้นเจอข้อความที่เกี่ยวข้องจึงยังไม่เพียงพอจะยืนยันต้นเหตุ
2. ไม่รู้ว่าข้อผิดพลาดแบบไหนเกิดอยู่แล้ว
คนที่ดูแลระบบมานานอาจรู้ว่า log บางชนิดเกิดทุกวันและไม่เกี่ยวกับเหตุขัดข้องครั้งนี้ แต่ Agent ที่ไม่มีข้อมูลอ้างอิงอาจมองสิ่งแรกที่พบว่าเป็นความผิดปกติ แล้วใช้เวลาไล่ตรวจผิดจุด
3. หลักฐานหายระหว่างส่งงานให้ Agent ตัวอื่น
เมื่อ Agent ย่อยส่งกลับมาเพียงบทสรุป Agent หลักอาจไม่เห็นข้อมูลดิบและรายละเอียดที่จำเป็นต่อการตัดสินใจ Pienaar เรียกปัญหานี้ว่า abstraction problem: ข้อมูลถูกย่อระหว่างทางจนผู้ตัดสินใจเห็นภาพไม่ครบ แต่ยังตอบอย่างมั่นใจ
4. ยึดคำอธิบายจากเหตุการณ์เก่า
ความจำช่วยให้ค้นงานที่ผ่านมาได้ แต่ก็ทำให้ Agent ด่วนสรุปว่าอาการที่คล้ายสัปดาห์ก่อนต้องเกิดจากสาเหตุเดิม ข้อมูลเก่าจึงควรเป็นจุดเริ่มต้นของการตรวจ ไม่ใช่หลักฐานแทนเหตุการณ์ปัจจุบัน
ตัวอย่างสมมติสำหรับทีมธุรกิจคือระบบรับคำสั่งซื้อที่ขัดข้อง: การพบ error ที่หน้าร้านยังไม่ได้ยืนยันว่าหน้าร้านเป็นต้นเหตุ และคำตอบจากเหตุขัดข้องรอบก่อนยังต้องผ่านการตรวจใหม่ หลักเดียวกันนี้ช่วยให้ทีมถามต่อได้ แม้ไม่ได้เป็นผู้เขียนโค้ดเอง
เริ่มจากหลายสมมติฐานและค่าปกติของระบบ
Pienaar เล่าว่าเทคนิคหนึ่งที่ Cleric ใช้ในเวลานั้นคือให้ Agent สร้างคำอธิบายหลายแบบและสำรวจไปพร้อมกัน Pienaar ให้เหตุผลว่า Agent เปรียบเทียบและจัดอันดับทางเลือกได้ดีกว่าการให้คะแนนคำตอบหนึ่งแบบลอย ๆ จึงควรมีสมมติฐานอื่นให้ตรวจเทียบ แทนการรีบยึดคำตอบแรก
หากนำมาออกแบบรายงานของทีม แต่ละสมมติฐานควรตอบได้สี่ข้อ: อธิบายอาการอย่างไร มีหลักฐานอะไรสนับสนุน มีอะไรขัดแย้ง และต้องตรวจอะไรต่อเพื่อยืนยันหรือตัดทิ้ง นี่เป็นรูปแบบใช้งานที่ประยุกต์จากแนวคิดในบทถอดเสียง ไม่ใช่ข้อกำหนดตายตัวของ Cleric และสมมติฐานแต่ละข้อควรต่างกันจริง ไม่ใช่เปลี่ยนถ้อยคำของคำตอบเดิม
อีกส่วนคือ baseline หรือข้อมูลอ้างอิงว่าสภาพปกติของระบบเป็นอย่างไร ผู้บรรยายยกตัวอย่างการจัดกลุ่ม log และส่งสถิติความถี่ให้ Agent เห็นว่าข้อความใดเกิดซ้ำทุกวัน แทนการส่งข้อความดิบอย่างเดียว วิธีเดียวกันนี้ใช้ประกอบการอ่านตัวชี้วัดและสถานะของส่วนต่าง ๆ ในระบบได้
สำหรับทีมเล็ก จุดเริ่มต้นอาจเป็นเอกสารสั้น ๆ ว่า error ใดพบเป็นประจำ ตัวชี้วัดใดใช้ติดตามเหตุขัดข้อง และใช้ข้อมูลช่วงไหนเป็นค่าปกติ ข้อเสนอนี้เป็นการประยุกต์ของบทความ โดยควรทบทวนข้อมูลอ้างอิงเมื่อระบบเปลี่ยนด้วย เพื่อไม่ให้ baseline เก่ากลายเป็นอีกเหตุผลที่พา Agent ไปผิดทาง
ตรวจความเชื่อมโยง เวลา และที่มาของหลักฐาน
การทำให้คำตอบยึดกับหลักฐาน หรือ grounding ตามคำอธิบายในบทถอดเสียง ไม่ได้จบที่ส่งข้อมูลให้มากขึ้น Pienaar เล่าว่าทีมใช้ข้อมูลต่อไปนี้เพื่อตรวจว่าคำอธิบายสอดคล้องกับระบบจริงหรือไม่
แผนผังความสัมพันธ์ระหว่างบริการ
ตามที่ Pienaar อธิบาย Cleric สร้าง dependency graph เพื่อแสดงว่าบริการใดพึ่งพากัน หาก Agent อ้างว่าปัญหาจากบริการหนึ่งส่งผลถึงอีกบริการ ก็ให้ Agent อีกตัวตรวจข้ออ้างนั้นกับเส้นทางเชื่อมโยงในแผนผัง หากไม่สอดคล้องกัน ต้องกลับไปสืบต่อ
ทีมที่ยังไม่มีระบบนี้อาจเริ่มจากขอแผนภาพบริการหลักจากทีมไอทีหรือผู้รับจ้าง แล้วใช้ตรวจคำอธิบายของ AI แต่แผนผังเป็นหลักฐานประกอบ ไม่ใช่ใบรับรองว่าทุกความสัมพันธ์ที่วาดไว้จะเป็นต้นเหตุของปัญหารอบนั้น
ลำดับเวลาของเหตุการณ์
ผู้บรรยายเสนอให้ตรวจว่าต้นเหตุเกิดก่อนอาการ และใช้ความใกล้กันของเวลาช่วยจัดอันดับสิ่งที่ควรตรวจต่อ อย่างไรก็ตาม การเกิดใกล้กันยังไม่พิสูจน์เหตุและผล จึงต้องอ่านคู่กับความเชื่อมโยงของระบบและหลักฐานอื่น ไม่ใช่โทษการเปลี่ยนแปลงล่าสุดโดยอัตโนมัติ
หลักฐานที่ตรวจย้อนกลับได้
Agent ที่ส่งงานต่อกันควรระบุว่าตรวจข้อมูลอะไร พบค่าใด และเกิดเมื่อใด Pienaar เปรียบกับวิศวกรดูแลความน่าเชื่อถือของระบบที่อธิบายข้อสรุปด้วยตัวชี้วัดและเวลาที่พบ ไม่ใช่รายงานเพียงว่า “ระบบกลับมาปกติแล้ว”
ในรายงานของทีมจึงควรเก็บลิงก์หรือจุดอ้างอิงของหลักฐาน พร้อมสิ่งที่ยังตรวจไม่ได้ไว้ด้วย เพื่อให้คนหรือ Agent ตัวถัดไปทบทวนเหตุผลได้โดยไม่ต้องเริ่มค้นใหม่ทั้งหมด
ต้นทุนและข้อจำกัดของการตรวจหลายทาง
ผู้บรรยายย้ำว่าการทดลองที่กล่าวถึงเป็นการจำลอง และแต่ละบริษัทมีระบบต่างกัน จึงไม่ควรคาดว่าผลจะเหมือนกันเมื่อนำแนวทางนี้ไปใช้กับระบบของตนเอง
Pienaar กล่าวว่าการตรวจห้าหรือหกสมมติฐานพร้อมกันใช้ token มากกว่าการตรวจแบบเจาะจงจุดเดียว ข้อแลกเปลี่ยนที่ผู้บรรยายเสนอคือ Agent อาจสืบต่อเองได้นานขึ้น โดยไม่ต้องให้คนคอยชี้ทางบ่อยเท่าเดิม
ข้อเสนอสำหรับทีมคือเลือกความละเอียดตามความเสี่ยง ปัญหาที่จำกัดอยู่จุดเดียวอาจเริ่มจากการตรวจเฉพาะจุด ส่วนเหตุขัดข้องที่ข้ามหลายบริการหรือมีหลักฐานขัดกันค่อยเพิ่มการตรวจหลายทาง ความคุ้มค่าควรนับทั้งค่าใช้ AI เวลาที่คนต้องเข้ามาช่วย และผลการแก้ปัญหา ไม่ใช่ดูเฉพาะค่าเรียกโมเดลต่อรอบ
ตรวจผลหลังแก้ แล้วจึงปรับเทียบความมั่นใจ
การให้เหตุผลได้ดีขึ้นยังไม่ตอบว่าคำแนะนำถูกจริงหรือไม่ Pienaar จึงอธิบายวิธีติดตามต่อจากการตรวจพบปัญหา วิเคราะห์ และเสนอวิธีแก้ ไปถึงการเปลี่ยนแปลงที่เกิดขึ้นและผลของมัน:
- ตรวจว่าการเปลี่ยนแปลงที่ทีมใช้จริงสอดคล้องกับคำวิเคราะห์ที่ Agent เสนอหรือไม่ เช่น มีการรวมโค้ดที่แก้ปัญหานั้นเข้าระบบหรือยัง
- ติดตามว่าบริการ ตัวชี้วัด log และสถานะที่เกี่ยวข้องกลับสู่ baseline หรือไม่
- เทียบหลายสัญญาณร่วมกันก่อนนับว่าแก้สำเร็จ
เหตุผลของข้อสุดท้ายชัดมาก: การปิดเสียงแจ้งเตือนก็ทำให้ดูเหมือนปัญหาหายได้ ทั้งที่บริการยังผิดปกติอยู่ จึงต้องแยก “ไม่มีการแจ้งเตือน” ออกจาก “ระบบกลับมาทำงานได้”
ข้อมูลผลลัพธ์จริงยังใช้ปรับเทียบความมั่นใจ หรือ calibration ได้ ความหมายของการปรับเทียบคือ ในกลุ่มคำตอบที่ Agent ให้ความมั่นใจ 90% สัดส่วนที่ตอบถูกเมื่อประเมินหลายกรณีควรอยู่ใกล้ 90% ตัวเลขจึงจะสะท้อนความแม่นยำที่เกิดขึ้นจริง ไม่ใช่เพียงน้ำเสียงมั่นใจที่แปลงเป็นเปอร์เซ็นต์
ข้อควรระวังเมื่อนำไปใช้คือ การเพิ่มหลักฐานไม่ได้ทำให้คะแนนเชื่อถือได้ทันที ทีมยังต้องตรวจคะแนนกับผลลัพธ์ของงานตัวเองก่อนใช้ประกอบการตัดสินใจ และแม้คะแนนจะปรับเทียบดีแล้ว คำตอบที่มั่นใจสูงก็ยังมีโอกาสผิด
นำไปใช้ในทีมอย่างไร
รายการต่อไปนี้เป็นข้อเสนอประยุกต์จากแนวคิดในบทถอดเสียงสำหรับเริ่มทดสอบในทีม ไม่ใช่ขั้นตอนติดตั้งผลิตภัณฑ์ของ Cleric:
- เลือกงานนำร่องที่ตรวจผลได้: ใช้เหตุขัดข้องที่มีข้อมูลย้อนหลังและรู้ผลการแก้แล้ว พร้อมระบุขอบเขตและข้อมูลที่ Agent เข้าถึงได้
- เก็บสมมติฐานกับผลตรวจไว้ด้วยกัน: หาก AI เปลี่ยนคำตอบ ให้ระบุหลักฐานใหม่ที่ทำให้เปลี่ยนอันดับหรือตัดคำตอบเดิมทิ้ง
- แนบข้อมูลปกติพร้อมข้อมูลเหตุการณ์: หาก Agent ติดอยู่กับ error ที่เกิดทุกวัน ให้เทียบความถี่และสภาพระบบก่อนกับระหว่างเหตุขัดข้อง
- ตรวจเส้นทางและเวลา: คำอธิบายต้องสอดคล้องกับบริการที่พึ่งพากัน และลำดับเหตุการณ์ต้องไม่ขัดกับข้ออ้างเรื่องต้นเหตุ
- ไม่ตัดหลักฐานออกจากรายงานย่อย: เก็บแหล่งข้อมูล เวลา สิ่งที่พบ และข้อจำกัดให้คนหรือ Agent ที่รับช่วงตรวจต่อได้
- แยกความจำออกจากหลักฐานปัจจุบัน: เหตุการณ์เก่าใช้ตั้งสมมติฐานได้ แต่ต้องตรวจข้อมูลรอบใหม่ก่อนยืนยัน
- บันทึกทั้งสิ่งที่แนะนำและสิ่งที่ทำจริง: จากนั้นตรวจหลายสัญญาณกับ baseline ก่อนปิดเหตุการณ์ อย่านับการแจ้งเตือนที่เงียบลงเป็นความสำเร็จเพียงอย่างเดียว
- ประเมินต้นทุนพร้อมความแม่นยำ: ดูค่าใช้ AI เวลาที่คนเข้ามาช่วย และผลหลังแก้ รวมถึงตรวจความสัมพันธ์ระหว่างคะแนนความมั่นใจกับอัตราตอบถูก ก่อนตั้งกติกาทำงานอัตโนมัติ
จากแก้เหตุขัดข้องสู่การตรวจตั้งแต่ขั้นพัฒนา
ช่วงท้ายของบทถอดเสียง Pienaar กล่าวถึงทิศทางที่ Cleric กำลังมุ่งไปในเวลานั้น: นำ baseline แผนผังระบบ และแบบจำลองความสัมพันธ์กลับไปใช้ในขั้นพัฒนา เพื่อช่วยคาดการณ์ปัญหาก่อนปล่อยการเปลี่ยนแปลง นี่เป็นทิศทางที่ผู้บรรยายอธิบาย ไม่ใช่การยืนยันสถานะผลิตภัณฑ์ปัจจุบันหรือคำรับรองว่าจะป้องกันเหตุขัดข้องได้ทั้งหมด
สำหรับทีมที่นำแนวคิดนี้ไปต่อยอด งานที่เริ่มได้คือเก็บเหตุการณ์เก่าพร้อมหลักฐานและผลจริง แยกบทบาทเสนอคำตอบกับตรวจคำตอบโดยให้ทั้งสองฝ่ายเข้าถึงหลักฐาน และใช้แผนผังความสัมพันธ์ตั้งคำถามถึงผลกระทบก่อนเปลี่ยนระบบ
ก่อนใช้คำวิเคราะห์ของ AI กับระบบจริง จึงควรถามให้ครบว่า “หลักฐานอยู่ไหน มีคำอธิบายอื่นหรือไม่ และหลังแก้แล้วอะไรยืนยันว่าปัญหาหาย” คำตอบสามข้อนี้ช่วยให้ทีมตรวจงานต่อได้มากกว่าการรับเพียงข้อสรุปกับเปอร์เซ็นต์ความมั่นใจ
