การออกแบบระบบหยุดการทำงานฉุกเฉินสำหรับ AI Agent: คู่มือการติดตั้ง Circuit Breaker
เซอร์กิตเบรกเกอร์ (Circuit Breaker) สำหรับ AI Agent คือกลไกความปลอดภัยที่ทำหน้าที่ตรวจจับและหยุดการทำงานโดยอัตโนมัติเมื่อเกิดพฤติกรรมผิดปกติ ค่าใช้จ่ายเกินกำหนด หรือการทำงานวนลูปไม่สิ้นสุด ในบทความนี้จะอธิบายขั้นตอนเชิงปฏิบัติสำหรับนักพัฒนาและวิศวกร MLOps ที่เกี่ยวข้องกับการออกแบบระบบหยุดการทำงานฉุกเฉินสำหรับ AI Agent ที่ใช้ LLM โดยครอบคลุมตั้งแต่รูปแบบการติดตั้งเซอร์กิตเบรกเกอร์ไปจนถึงการบูรณาการเข้ากับ AI Guardrails
เซอร์กิตเบรกเกอร์ (Circuit Breaker) สำหรับ AI Agent คือกลไกความปลอดภัยที่ทำหน้าที่ตรวจจับการทำงานที่ผิดปกติ การใช้จ่ายเกินงบประมาณ หรือการวนลูปไม่สิ้นสุดของ Agent แบบเรียลไทม์ เพื่อหยุดการทำงานโดยอัตโนมัติก่อนที่ความเสียหายจะขยายตัว บทความนี้จัดทำขึ้นสำหรับนักพัฒนาและวิศวกร MLOps ที่ใช้งาน AI Agent ซึ่งรวม LLM ในระบบงานจริง โดยจะอธิบายขั้นตอนตั้งแต่การสร้างเลเยอร์การตรวจสอบ การตั้งค่าเงื่อนไขการทริกเกอร์ (Trigger) การติดตั้งคิลสวิตช์ (Kill Switch) และระบบสำรอง (Fallback) ไปจนถึงการบูรณาการเข้ากับระบบป้องกัน (Guardrails) เมื่ออ่านจบ คุณจะสามารถออกแบบและติดตั้ง "กลไกการหยุดทำงาน" ให้กับ Agent ของคุณได้ตั้งแต่ขั้นตอนการออกแบบ พร้อมทั้งวางแนวทางการใช้งานจริงเพื่อควบคุมต้นทุนที่เกิดจากการทำงานผิดพลาดและป้องกันอุบัติเหตุทางความปลอดภัยได้
AI เอเจนต์ที่ตัดสินใจได้อย่างอิสระและต่อเนื่อง อาจเรียกใช้เครื่องมือต่างๆ เกินกว่าที่ผู้ออกแบบคาดการณ์ไว้ ซึ่งส่งผลให้ต้นทุนและความเสี่ยงเพิ่มสูงขึ้นแบบทวีคูณ การออกแบบระบบหยุดทำงานฉุกเฉิน (Emergency Stop Design) จึงเป็นเงื่อนไขสำคัญที่ต้องให้ความสำคัญกับ "กลไกการหยุด" ไม่น้อยไปกว่า "กลไกการทำงาน" ในที่นี้ เราจะสรุปเหตุผล 3 ประการที่ทำให้การออกแบบระบบหยุดทำงานเป็นสิ่งที่ละเลยไม่ได้ ได้แก่ ต้นทุน ความปลอดภัย และกฎระเบียบ
ความเสี่ยงที่เกิดจากการทำงานที่ควบคุมไม่ได้ของ Agent: ต้นทุน ความปลอดภัย และความน่าเชื่อถือ
แอปพลิเคชันแบบดั้งเดิมมีการตอบสนองต่อคำขอแบบหนึ่งต่อหนึ่ง ทำให้สามารถประเมินขอบเขตความเสียหายได้ง่าย ในทางกลับกัน AI Agent จะเชื่อมโยงการเรียกใช้เครื่องมือและการอนุมานของ LLM เข้าด้วยกันนับสิบครั้งจากคำสั่งเพียงคำสั่งเดียว หากการเชื่อมโยงนี้สิ้นสุดลงตามที่คาดไว้ก็ไม่มีปัญหา แต่หากตัดสินเงื่อนไขการวนซ้ำผิดพลาด การเรียกใช้งานจะไม่หยุดลงและค่าใช้จ่ายจะพุ่งสูงขึ้นอย่างไร้ขีดจำกัด
ความเสี่ยงแบ่งออกเป็นสามระดับหลัก ประการแรกคือ ต้นทุน ซึ่งเกิดจากการที่ค่าใช้จ่ายโทเค็นและค่าบริการตามการใช้งานของ API ภายนอกไม่สามารถควบคุมได้ ประการที่สองคือ ความปลอดภัย ซึ่งเกิดจากการถูกชักจูงด้วย Prompt Injection จนนำไปสู่การดำเนินการที่ไม่อนุญาต (เช่น การส่งอีเมล การลบข้อมูล หรือการส่งข้อมูลออกภายนอก) ประการที่สามคือ ความน่าเชื่อถือ ซึ่งเกิดจากการนำผลลัพธ์ที่รวมถึงอาการหลอน (Hallucination) ไปใช้เป็นข้อมูลที่ถูกต้องในกระบวนการขั้นถัดไปจนทำให้ข้อมูลทางธุรกิจเสียหาย ทั้งสามประการนี้ไม่ได้แยกจากกัน แต่จะเชื่อมโยงและปรากฏขึ้นพร้อมกันเมื่อเกิดเหตุการณ์ควบคุมไม่ได้ ด้วยเหตุนี้ เราจึงจำเป็นต้องมีกลไกส่วนกลางที่ทำหน้าที่ "ตรวจจับและหยุดยั้ง" แทนที่จะใช้มาตรการแก้ไขเป็นรายกรณีไป
ภัยคุกคามจาก Unbounded Consumption และ Excessive Agency
ความเสี่ยงเฉพาะของ AI Agent ได้รับการระบุไว้อย่างชัดเจนในหมวดหมู่ภัยคุกคามสำหรับแอปพลิเคชัน LLM ของ OWASP โดยมีสองประเด็นหลักคือ Unbounded Consumption และ Excessive Agency
Unbounded Consumption หมายถึงสภาวะที่การป้อนข้อมูลหรือการเรียกซ้ำ (Recursive call) ไม่มีขีดจำกัด ทำให้มีการใช้ทรัพยากรคำนวณ ต้นทุน และโทเค็นอย่างไม่สิ้นสุด ตัวอย่างเช่น การเกิดลูปไม่รู้จบ หรือการโจมตีแบบปฏิเสธการให้บริการ (DoS) ที่ผู้โจมตีจงใจส่งงานที่มีภาระหนักเข้าสู่ระบบ
Excessive Agency หมายถึงสภาวะที่ Agent ได้รับสิทธิ์ เครื่องมือ หรือความเป็นอิสระมากเกินไป จนทำให้ขอบเขตความเสียหายเมื่อเกิดการทำงานผิดพลาดขยายวงกว้างเกินควร ตัวอย่างที่พบบ่อยคือการออกแบบที่ "ให้สิทธิ์การเขียนในงานที่ควรมีเพียงสิทธิ์การอ่าน" หรือ "สามารถดำเนินการที่ไม่สามารถย้อนกลับได้โดยไม่ต้องผ่านการอนุมัติจากมนุษย์" โดย Circuit Breaker จะช่วยควบคุมปัญหาในกรณีแรก ในขณะที่การจำกัดสิทธิ์ให้น้อยที่สุด (การออกแบบตามหลักสิทธิ์ขั้นต่ำ) จะช่วยควบคุมปัญหาในกรณีหลัง ทั้งสองมาตรการนี้มีความสัมพันธ์แบบส่งเสริมซึ่งกันและกัน และไม่สามารถป้องกันภัยคุกคามได้หากขาดมาตรการใดมาตรการหนึ่งไป
การกำกับดูแล AI: ข้อกำหนดด้านการควบคุมการหยุดทำงาน (Stop Control) ตามกฎหมาย EU AI Act
การป้องกันการทำงานที่ผิดพลาด (Runaway prevention) ไม่ได้เป็นเพียงความท้าทายทางเทคนิคเท่านั้น แต่ยังเป็นข้อกำหนดด้านการปฏิบัติตามกฎระเบียบ (Compliance) อีกด้วย EU AI Act ซึ่งมีผลบังคับใช้เต็มรูปแบบแล้ว กำหนดให้ระบบ AI ที่มีความเสี่ยงสูงต้องมี มาตรการที่มนุษย์สามารถเข้ามาควบคุมและหยุดการทำงานของระบบได้ตามความจำเป็น (Human Oversight) การที่การออกแบบระบบมีการติดตั้งระบบควบคุมที่เทียบเท่ากับปุ่มหยุดฉุกเฉิน (Kill switch) นั้น ถือเป็นประเด็นสำคัญในการประเมินความสอดคล้องตามกฎระเบียบ
กล่าวคือ Kill switch ไม่ได้เป็นเพียงสิ่งที่ "มีไว้ก็อุ่นใจ" แต่กำลังกลายเป็นองค์ประกอบสำคัญที่ "หากไม่มี ก็จะไม่ผ่านเกณฑ์ข้อกำหนด" ในพื้นที่ที่อยู่ภายใต้การกำกับดูแล แม้ว่าภาพรวมซึ่งรวมถึงกฎระเบียบภายในองค์กรและการรองรับการตรวจสอบจะถูกสรุปไว้ใน คู่มือการปฏิบัติงานด้านธรรมาภิบาล AI (AI Governance) แล้ว แต่ในมุมของการควบคุมการหยุดทำงาน ควรมีการระบุข้อกำหนดขั้นต่ำ 3 ประการไว้ในการออกแบบตั้งแต่ต้น ได้แก่ (1) ใครเป็นผู้มีสิทธิ์หยุดระบบและภายใต้เงื่อนไขใด (2) การดำเนินการหยุดระบบและเหตุผลมีการบันทึกไว้ใน Log หรือไม่ และ (3) สามารถกู้คืนระบบให้กลับสู่สถานะที่ปลอดภัยหลังจากหยุดการทำงานได้หรือไม่
สิ่งที่ควรตรวจสอบก่อนเริ่มการติดตั้ง (Implementation) และแนวทางการออกแบบคืออะไร?
Circuit Breaker จะไม่ทำงานด้วยตัวมันเอง แต่จะทำงานได้ก็ต่อเมื่อมีองค์ประกอบครบทั้งสามประการ ได้แก่ โครงสร้างพื้นฐานสำหรับสังเกตการณ์ว่า "เกิดอะไรขึ้น" นโยบายที่กำหนดว่า "ใครสามารถแทรกแซงได้ถึงระดับไหน" และการกำหนดค่า Threshold ว่า "จะหยุดที่ค่าใด" ก่อนเริ่มการ Implement เราต้องตรวจสอบเงื่อนไขเบื้องต้นทั้งสามประการนี้ก่อน
ตรวจสอบสถานะการเตรียมความพร้อมของโครงสร้างพื้นฐาน AI Observability
กลไกการหยุดทำงานจะทำงานได้เฉพาะในขอบเขตที่สามารถสังเกตการณ์ได้เท่านั้น หากไม่มีการวัดผลทั้งการใช้โทเค็นและจำนวนรอบของลูป ก็จะไม่สามารถกำหนดเงื่อนไขเพื่อสั่งการ (Trigger) ได้ ดังนั้น ข้อกำหนดเบื้องต้นประการแรกคือการมีโครงสร้างพื้นฐานด้าน AI Observability ที่สามารถทำให้สถานะภายในของเอเจนต์มองเห็นได้ชัดเจน
โดยเฉพาะอย่างยิ่ง จำเป็นต้องมีการบันทึกข้อมูลอินพุต, เอาต์พุต, โทเค็นที่ใช้, การเรียกใช้เครื่องมือ (Tool calls), ค่าความหน่วง (Latency) และข้อผิดพลาดในแต่ละขั้นตอนตามลำดับเวลาในระดับ Trace หากนำแนวคิดเรื่อง Distributed Tracing เช่น OpenTelemetry มาประยุกต์ใช้กับการเรียก LLM โดยจัดโครงสร้างเป็น "1 งาน = 1 Trace" และ "1 ขั้นตอน = 1 Span" จะทำให้สามารถเขียนเงื่อนไขการตัดสินเกณฑ์ (Threshold) ในภายหลังได้โดยตรง แม้ว่าการออกแบบโครงสร้างพื้นฐานสำหรับการสังเกตการณ์นั้นจะอ้างอิงจาก คู่มือการปฏิบัติงาน AI Observability แต่ขั้นตอนในบทความนี้จะดำเนินไปโดยมีสมมติฐานว่า "สามารถดึงข้อมูลเมตริกที่วัดผลไว้แล้วมาใช้งานได้" หากยังไม่มีการเตรียมความพร้อม การเริ่มต้นจากการวางระบบสังเกตการณ์ถือเป็นลำดับขั้นตอนที่ถูกต้องที่สุด
การกำหนดระดับการแทรกแซงของ Human-in-the-loop / On-the-loop
ถัดมาคือการตัดสินใจว่าจะให้มนุษย์เข้ามามีส่วนร่วมในการตัดสินใจหยุดการทำงานอย่างไร ซึ่งสามารถจัดระเบียบได้ง่ายโดยแบ่งระดับความเข้มข้นของการแทรกแซงออกเป็น 3 ระดับหลัก
In-the-loop คือรูปแบบที่ต้องผ่านการอนุมัติจากมนุษย์ก่อนดำเนินการที่สำคัญเสมอ เหมาะสำหรับกระบวนการที่ไม่สามารถย้อนกลับได้และมีความเสี่ยงสูง แต่จะทำให้ปริมาณงาน (throughput) ลดลง On-the-loop คือรูปแบบที่เอเจนต์ดำเนินการเองโดยอัตโนมัติ ในขณะที่มนุษย์คอยดูสถานการณ์ผ่านแดชบอร์ดตรวจสอบ และจะแทรกแซงหรือหยุดการทำงานเมื่อจำเป็น ส่วน Out-of-the-loop คือการทำงานอัตโนมัติเต็มรูปแบบ โดยการหยุดการทำงานจะขึ้นอยู่กับกลไกทริกเกอร์ของเครื่องจักร
ในทางปฏิบัติ การปรับเปลี่ยนระดับตามเครื่องมือแต่ละชนิดโดยพิจารณาจากความสามารถในการย้อนกลับและความเสี่ยงของกระบวนการนั้นถือเป็นเรื่องสมเหตุสมผล ตัวอย่างเช่น การแบ่งเป็น "การค้นหาเป็นแบบอัตโนมัติ การส่งข้อมูลภายนอกต้องได้รับการอนุมัติ และการชำระเงินต้องได้รับการอนุมัติสองชั้น" พื้นฐานของการออกแบบการแทรกแซงสามารถดูรายละเอียดเพิ่มเติมได้ที่ คำอธิบายเกี่ยวกับ Human-in-the-loop (HITL) สำหรับ Circuit Breaker นั้น ควรระบุปลายทางของการแจ้งเตือนเมื่อเกิดการหยุดทำงานให้ชัดเจน เพื่อไม่ให้ขัดกับระดับการแทรกแซงเหล่านี้
กำหนดดัชนีเกณฑ์ที่เป็นตัวกระตุ้นให้หยุดทำงาน (จำนวนโทเค็น, ต้นทุน, จำนวนรอบการทำงาน)
ส่วนสุดท้ายของข้อกำหนดเบื้องต้นคือการเลือกตัวชี้วัดว่าจะหยุดการทำงานเมื่อใด โดยเลือกตัวชี้วัดเกณฑ์มาตรฐาน (Threshold) ที่เป็นตัวแทนจากความง่ายในการสังเกตและความยากในการเกิดผลบวกปลอม (False Positive)
| ตัวชี้วัด | ตัวอย่าง | สิ่งที่ป้องกันเป็นหลัก |
|---|---|---|
| จำนวนโทเค็นสะสม | 50,000 โทเค็นต่อ 1 งาน | ค่าใช้จ่ายพุ่งสูง |
| ต้นทุนสะสม | 0.5 USD ต่อ 1 งาน | ค่าใช้จ่ายพุ่งสูง |
| จำนวนขั้นตอน / จำนวนรอบการวนซ้ำ | 30 ขั้นตอน | การวนซ้ำไม่สิ้นสุด |
| อัตราความผิดพลาดต่อเนื่อง | ล้มเหลว 3 ใน 5 ครั้งล่าสุด | การลุกลามของความผิดพลาดจากภายนอก |
| เวลาที่ผ่านไป | 10 นาทีต่อเซสชัน | การค้างหรือการหยุดชะงัก |
สิ่งสำคัญคืออย่าพึ่งพาตัวชี้วัดเพียงตัวเดียว แต่ให้ใช้หลายตัวร่วมกัน หากใช้เพียงจำนวนโทเค็นอาจพลาด "การวนซ้ำที่ราคาถูกแต่ไม่จบสิ้น" และหากใช้เพียงจำนวนขั้นตอนอาจพลาด "การเรียกใช้เครื่องมือที่มีจำนวนน้อยแต่มีราคาสูง" ไม่จำเป็นต้องกำหนดเกณฑ์มาตรฐานให้สมบูรณ์แบบตั้งแต่แรก แต่ให้ตั้งค่าไว้ในระดับที่ปลอดภัยไว้ก่อน โดยมีแผนที่จะปรับเปลี่ยนในภายหลังตามการกระจายตัวของเมทริกซ์จริง (p50 / p95) สำหรับวิธีการกำหนดค่าเพดานสูงสุดของต้นทุน ควรพิจารณาร่วมกับการออกแบบงบประมาณใน คู่มือการเพิ่มประสิทธิภาพต้นทุน LLM
ขั้นตอนที่ 1: จะสร้างเลเยอร์การตรวจสอบ (Monitoring Layer) อย่างไร?
เซอร์กิตเบรกเกอร์ (Circuit Breaker) มีกลไกหลักคือลูปของ "การวัดผล → การตัดสินใจ → การตัดการทำงาน" ขั้นตอนแรกคือการสร้างเลเยอร์การตรวจสอบ (Monitoring Layer) เพื่อรวบรวมเมทริกซ์ (Metrics) ที่ใช้ในการตัดสินใจแบบเรียลไทม์ โดยในขั้นตอนนี้จะทำการวัดผลข้อมูล 3 ระบบ ได้แก่ ปริมาณการใช้งาน (Consumption), ความคืบหน้า (Progress) และสัญญาณความผิดปกติ (Anomaly signals)
การวัดผลแบบเรียลไทม์สำหรับ Token Consumption, API Call Count และ Latency
รากฐานของเลเยอร์การตรวจสอบ (Monitoring Layer) คือตัวนับที่สะสมปริมาณการใช้งานในทุกๆ 1 ขั้นตอนของเอเจนต์ โดยการใช้ Wrapper ครอบ LLM Client และการทำงานของเครื่องมือ (Tool execution) ไว้ เพื่อบวกจำนวนโทเค็น ต้นทุน จำนวนครั้ง และความหน่วง (Latency) เข้ากับบริบทระดับงานทุกครั้งที่มีการเรียกใช้งาน
1class UsageTracker:
2 def __init__(self, budget):
3 self.tokens = 0
4 self.cost = 0.0
5 self.calls = 0
6 self.budget = budget
7
8 def record(self, usage):
9 self.tokens += usage.total_tokens
10 self.cost += usage.cost
11 self.calls += 1
12 # คืนค่า True หากอยู่ในเกณฑ์ และ False หากเกินเกณฑ์เพื่อให้ฝั่งที่เรียกใช้งานทำการตัดการทำงาน
13 return (self.tokens <= self.budget.max_tokens
14 and self.cost <= self.budget.max_cost)หัวใจสำคัญคือการแยกการวัดผลออกจากตรรกะหลักของเอเจนต์ และจำกัดไว้ในเลเยอร์ Wrapper วิธีนี้จะช่วยให้สามารถเปลี่ยนเงื่อนไขของตัวตัดการทำงาน (Breaker) ได้ในภายหลังโดยไม่ต้องแก้ไขโค้ดส่วนหลัก ส่วนค่าความหน่วง (Latency) จะถูกบันทึกควบคู่ไปด้วยเพื่อใช้เป็นดัชนีชี้วัดในการตรวจจับสัญญาณเตือนล่วงหน้า กรณีที่ความล่าช้าของ API ภายนอกส่งผลกระทบต่อเนื่องจนทำให้ระบบทั้งหมดค้าง
ตรรกะการติดตามความคืบหน้าของ Task Graph และการตรวจจับ Infinite Loop
นอกเหนือจากปริมาณการใช้งานแล้ว สิ่งที่สำคัญไม่แพ้กันคือการติดตามว่าเอเจนต์ "กำลังก้าวไปข้างหน้าหรือไม่" ลูปไม่รู้จบ (infinite loop) ส่วนใหญ่มักปรากฏในรูปแบบของการใช้เครื่องมือเดิมซ้ำด้วยอาร์กิวเมนต์เดิม หรือการวนเวียนอยู่ระหว่างสถานะเดิมซ้ำๆ
พื้นฐานของการตรวจจับมีสองประการ ประการแรกคือ การจำกัดจำนวนขั้นตอน (step limit) โดยกำหนดจำนวนขั้นตอนสูงสุดต่อหนึ่งงาน หากเกินกว่านั้นให้ยุติการทำงานโดยอัตโนมัติ ประการที่สองคือ การตรวจจับการทำซ้ำ (repetition detection) โดยเก็บค่าแฮชของชื่อเครื่องมือและอาร์กิวเมนต์ในช่วง N ขั้นตอนล่าสุด หากพบรูปแบบเดิมซ้ำเกินจำนวนครั้งที่กำหนด (threshold) ให้ถือว่าเป็นลูป
1def is_looping(history, window=6, repeat=3):
2 recent = history[-window:]
3 sigs = [hash((h.tool, h.args_digest)) for h in recent]
4 return any(sigs.count(s) >= repeat for s in set(sigs))ในโครงสร้างแบบมัลติเอเจนต์ (multi-agent) ที่แยกการวางแผนและการดำเนินการออกจากกัน เราสามารถตรวจสอบการเปลี่ยนผ่านของโหนดในกราฟงาน (task graph) ได้โดยตรง สำหรับรูปแบบการออกแบบ สามารถดูได้ที่ คำอธิบายเกี่ยวกับ Multi-agent AI นอกจากนี้ สถานะ "ค้าง" (stuck) ที่ไม่มีการอัปเดตความคืบหน้าภายในระยะเวลาที่กำหนด จะถูกตรวจจับด้วยการตั้งค่าหมดเวลา (timeout) แยกต่างหาก
การรวบรวมสัญญาณความผิดปกติของ Prompt Injection และ Hallucination
นอกจากปริมาณและความคืบหน้าแล้ว ควรเก็บรวบรวม "ความผิดปกติของคุณภาพ" ของผลลัพธ์ไว้เป็นสัญญาณด้วย ข้อมูลส่วนนี้จะเป็นวัตถุดิบในการกระตุ้นการทำงานของ Guardrails หรือการแทรกแซงโดยมนุษย์ในขั้นตอนถัดไป
สำหรับสัญญาณบ่งชี้ของ Prompt Injection ให้เฝ้าระวังการปรากฏของคำที่พยายามเขียนทับคำสั่งระบบ (เช่น "ให้เพิกเฉยต่อคำสั่งก่อนหน้านี้" เป็นต้น) การเรียกใช้เครื่องมือที่ไม่ได้รับอนุญาตอย่างกะทันหัน รวมถึงรูปแบบการรั่วไหลของ URL ภายนอกหรือข้อมูลรับรอง (Credentials) ที่รวมอยู่ในผลลัพธ์ ส่วนสัญญาณบ่งชี้ของ Hallucination ให้ตรวจจับการอ้างถึงข้อเท็จจริงที่ไม่มีอยู่จริงในผลลัพธ์จากเครื่องมือ, การรายงานระดับความมั่นใจของตนเองที่สูงหรือต่ำจนผิดปกติ, และความไม่สอดคล้องของคำตอบต่อคำถามเดิม
สิ่งสำคัญคือข้อมูลที่รวบรวมได้ที่นี่เป็นเพียง "สัญญาณ" เท่านั้น ไม่ควรใช้เป็นเหตุผลในการหยุดการทำงานอย่างเด็ดขาดเพียงลำพัง หากมีการตรวจจับผิดพลาด (False Positive) มากเกินไป อาจส่งผลให้งานปกติถูกปิดกั้นไปด้วย การพัฒนาตรรกะการตรวจจับให้แม่นยำขึ้นทำได้โดยการทำความเข้าใจกลวิธีของฝ่ายโจมตี ซึ่งควรศึกษาแบบแผนการโจมตีทั่วไปผ่าน AI Red Teaming ไว้ด้วย
ขั้นตอนที่ 2: จะตั้งค่าเงื่อนไขการทริกเกอร์ของ Circuit Breaker อย่างไร?
ขั้นตอนนี้คือการแปลงเมทริกซ์ที่รวบรวมได้จากการตรวจสอบ (Monitoring) ให้เป็นการตัดสินใจว่าจะ "หยุด / ไม่หยุด" การทำงาน เช่นเดียวกับ Circuit Breaker ในไมโครเซอร์วิส เราจะกำหนดทริกเกอร์ (Trigger) ไว้ 3 ด้าน ได้แก่ ต้นทุน (Cost), อัตราข้อผิดพลาด (Error rate) และการหมดเวลา (Timeout) ต่อไปเราจะมาดูการออกแบบเกณฑ์ (Threshold) ของแต่ละด้านกัน
การจำกัดปริมาณการใช้งานแบบอิงตามต้นทุน (Cost-based Throttling): การกำหนดเพดานงบประมาณโทเค็นสำหรับ LLM
ตัวกระตุ้นแรกคือการใช้เกณฑ์งบประมาณ โดยกำหนดเพดานของจำนวนโทเค็น ต้นทุน และจำนวนครั้งที่เรียกใช้ในแต่ละงาน พร้อมทั้งออกแบบพฤติกรรมเมื่อมีการใช้งานเกินกำหนดไว้ด้วย ทั้งนี้ เพดานดังกล่าวไม่ควรเป็นค่าเดียวที่ใช้กับทุกงาน แต่การแบ่งออกเป็นอย่างน้อย 3 ระดับจะช่วยให้การบริหารจัดการทำได้ง่ายขึ้น
| ระดับ | ตัวอย่าง | พฤติกรรมเมื่อเกินกำหนด |
|---|---|---|
| เพดานแบบผ่อนปรน (Soft Limit) | 0.3 USD | แจ้งเตือน + เปลี่ยนไปใช้โมเดลราคาถูก |
| เพดานแบบเข้มงวด (Hard Limit) | 0.5 USD | หยุดการทำงานทันที + ส่งเรื่องให้มนุษย์ดำเนินการต่อ |
| เพดานจำนวนครั้งที่เรียกใช้ | LLM 30 ครั้ง / เครื่องมือ 50 ครั้ง | บังคับยุติการทำงานแบบวนซ้ำ |
ค่าที่เหมาะสมจะแตกต่างกันไปตามลักษณะของงาน งานที่สรุปผลได้ง่ายอย่างการสกัดข้อมูลหรือการจัดรูปแบบจะมีต้นทุนต่ำ ในขณะที่งานด้านการค้นคว้าหรือการวางแผนระยะยาวนั้นคาดเดาจำนวนรอบการทำงานได้ยาก การจำแนกประเภทงานออกเป็น "กลุ่มสำรวจ / กลุ่มสกัดข้อมูล / กลุ่มสร้างเนื้อหา" แล้วแยกงบประมาณออกจากกัน จะช่วยหลีกเลี่ยงสถานการณ์ที่การกำหนดเพดานเดียวกันกับทุกงานส่งผลให้ "90% ของงานมีเพดานที่หลวมเกินไป และอีก 10% มีเพดานที่เข้มงวดเกินไป" แนวคิดในการวางตำแหน่งงบประมาณไว้ในการออกแบบต้นทุนโดยรวมได้อธิบายไว้อย่างละเอียดใน โมเดลเศรษฐศาสตร์ของ AI Agent
การตัดการเชื่อมต่อตามอัตราความผิดพลาด (Error Rate-based Blocking): การตัดการเชื่อมต่ออัตโนมัติเมื่อเกิดความล้มเหลวต่อเนื่อง
ประการที่สองคือทริกเกอร์แบบอิงตามอัตราความผิดพลาด (Error rate-based trigger) ซึ่งถือว่าใกล้เคียงกับ "Circuit Breaker" ที่แท้จริงมากที่สุด โดยจะใช้รูปแบบของ Microservices และจัดการผ่านสถานะ 3 สถานะ ดังนี้:
- Closed (ปิด): การทำงานปกติ จะปล่อยให้มีการเรียกใช้งานผ่านไปได้แต่จะนับจำนวนความผิดพลาดไว้
- Open (เปิด): เมื่อความผิดพลาดเกินเกณฑ์ที่กำหนด วงจรจะเปิดออกและปฏิเสธการเรียกใช้งานทั้งหมดทันทีในช่วงเวลาหนึ่ง (Fail-fast)
- Half-Open (กึ่งเปิด): หลังจากผ่านช่วงคูลดาวน์ จะทดลองปล่อยให้มีการเรียกใช้งานผ่านไปได้เพียงไม่กี่ครั้ง หากระบบฟื้นตัวแล้วจะกลับไปสู่สถานะ Closed
1if breaker.state == "open":
2 if now < breaker.retry_at:
3 raise CircuitOpen("กำลังตัดการเชื่อมต่อเนื่องจาก External dependency ไม่เสถียร")
4 breaker.state = "half_open" # ทดลองเปิดใช้งานอีกครั้งวิธีนี้ช่วยป้องกันสถานการณ์ที่ต้องเสียเวลาและทรัพยากรไปกับการลองเรียกใช้งานซ้ำๆ ทั้งที่รู้อยู่แล้วว่าจะล้มเหลว ในขณะที่ External API หรือเครื่องมือต่างๆ กำลังล่ม การกำหนดเกณฑ์เป็นอัตราส่วน เช่น "ล้มเหลว M ครั้ง ในการเรียก N ครั้งล่าสุด" จะช่วยป้องกันไม่ให้วงจรเปิดออกมากเกินไปจากความผิดพลาดเพียงครั้งเดียวที่เกิดขึ้นไม่บ่อยนัก
การหยุดทำงานแบบกำหนดเวลา (Timeout-based suspension): การจำกัดตามขั้นตอน (Step) และตามเซสชัน (Session)
ประการที่สามคือการใช้เวลาเป็นเกณฑ์ (Time-based) เพื่อตรวจจับกรณีที่ต้นทุนและข้อผิดพลาดอยู่ในเกณฑ์ที่กำหนด แต่กระบวนการโดยรวมกลับหยุดชะงักเนื่องจากการรอการตอบกลับจากภายนอกหรือเครื่องมือค้าง โดยการกำหนดค่า Timeout จะแบ่งออกเป็นระดับชั้นดังนี้:
ระดับขั้นตอน (Step-level): กำหนดเวลาสูงสุดสำหรับการเรียกใช้ LLM หรือการทำงานของเครื่องมือแต่ละรายการ หากเกินเวลาที่กำหนดให้ยกเลิกการเรียกใช้นั้นแล้วดำเนินการ Retry หรือ Fallback ต่อไป ระดับเซสชัน (Session-level): กำหนดเวลาสูงสุดสำหรับระยะเวลาดำเนินการของงานทั้งหมด หากเกินเวลาที่กำหนดให้ยุติการทำงานอย่างปลอดภัยแม้จะยังไม่เสร็จสิ้น หากไม่ใช้ทั้งสองวิธีร่วมกัน อาจทำให้พลาดกรณี "แต่ละขั้นตอนทำงานเร็วแต่เกิดลูปไม่รู้จบ" หรือ "ขั้นตอนเดียวค้างจนทำให้ทั้งระบบหยุดชะงัก" ไปได้
ในเชิงการนำไปใช้งานจริง ต้องใช้ร่วมกับกลไกการยกเลิกการประมวลผลแบบอะซิงโครนัส (เช่น await ที่มี Timeout หรือ Cancellation Token) เพื่อให้มั่นใจว่าทรัพยากรต่างๆ (การเชื่อมต่อ, ไฟล์ชั่วคราว, ล็อก) จะถูกปลดปล่อยอย่างแน่นอนเมื่อมีการหยุดชะงัก หากการหยุดชะงักไม่สมบูรณ์ อาจก่อให้เกิด "Zombie Task" ซึ่งเป็นกระบวนการที่ยังคงทำงานอยู่เบื้องหลังแม้จะตั้งใจหยุดไปแล้วก็ตาม
ขั้นตอนที่ 3: จะดำเนินการติดตั้ง Kill Switch และกระบวนการ Fallback อย่างไร?
ขั้นตอนนี้คือการออกแบบว่าจะหยุดการทำงานอย่างไรหลังจากที่ Trigger ทำงานแล้ว และจะส่งค่าอะไรกลับไปหลังจากหยุดการทำงานนั้น วิธีการหยุดมีทั้งแบบเบาและแบบหนัก ซึ่งต้องเลือกใช้ให้เหมาะสมตามผลกระทบต่อธุรกิจ นอกจากนี้ยังสามารถเพิ่มความปลอดภัยแบบหลายชั้น (Multi-layered) โดยใช้ร่วมกับ Guardrails หรือการแยกส่วน Multi-agent ต่อไปเราจะมาดูประเด็นสำคัญในการนำไปใช้งานจริง
การเลือกใช้ Hard Stop และ Soft Stop
การหยุดการทำงานมีสองประเภท ฮาร์ดสต็อป (Hard stop) คือคิลสวิตช์ (kill switch) ที่ใช้ตัดการทำงานทันที ใช้ในกรณีที่การดำเนินการต่อมีความเสี่ยง เช่น ค่าใช้จ่ายพุ่งสูงเกินควบคุมหรือมีการละเมิดความปลอดภัยที่ชัดเจน ส่วน ซอฟต์สต็อป (Soft stop) คือวิธีการที่ให้ขั้นตอนปัจจุบันทำงานจนเสร็จสิ้นแล้วจึงหยุด ณ จุดที่ปลอดภัย หรือลดระดับการทำงาน (degrade) เพื่อดำเนินการต่อ เหมาะสำหรับกรณีที่ต้องการรักษาประสบการณ์ของผู้ใช้งาน
| สถานการณ์ | คำแนะนำ | พฤติกรรมหลังหยุดการทำงาน |
|---|---|---|
| ค่าใช้จ่ายเกินขีดจำกัด | ฮาร์ด | ยุติการทำงานและส่งผลลัพธ์บางส่วนพร้อมเหตุผลกลับไป |
| API ภายนอกล้มเหลวต่อเนื่อง | ซอฟต์ | ลดระดับไปใช้โมเดลราคาถูกหรือการตอบกลับจากแคช |
| ตรวจพบการทำ Injection | ฮาร์ด | แยกเซสชันนั้นออกและตัดการเชื่อมต่อ |
| ค่าความหน่วง (Latency) เกินกำหนด | ซอฟต์ | ส่งผลลัพธ์บางส่วนกลับไปและดำเนินการต่อแบบอะซิงโครนัส |
ควรเตรียมคิลสวิตช์ไว้ทั้งแบบ โกลบอล (Global) ที่มีผลกับเอเจนต์และผู้เช่าทั้งหมดพร้อมกัน และแบบ มีขอบเขต (Scoped) ที่จำกัดเฉพาะงานหรือผู้ใช้บางราย เพื่อจำกัดความเสียหายให้เหลือน้อยที่สุดเมื่อเกิดปัญหา ทั้งนี้ เมื่อมีการหยุดการทำงาน จะต้องสร้างข้อความสำหรับส่งกลับไปยังผู้ใช้และบันทึกข้อมูลลงในล็อกภายในทุกครั้ง
การบูรณาการเข้ากับ AI Guardrails: การสกัดกั้นเชิงรุกด้วย Prompt Firewall
ในขณะที่ Circuit Breaker เป็นกลไกที่ทำงานภายหลังเพื่อ "หยุดการประมวลผลที่กำลังทำงานอยู่" แต่ Guardrail เป็นกลไกที่ทำงานล่วงหน้าเพื่อ "ป้องกันไม่ให้มีการรับเข้าหรือส่งออกข้อมูลที่เป็นอันตราย" เนื่องจากทั้งสองกลไกทำงานในเลเยอร์ที่แตกต่างกัน จึงควรนำมาใช้ร่วมกันเพื่อสร้างการป้องกันแบบหลายชั้น (Defense in Depth)
ในฝั่งขาเข้า (Input) จะใช้ Prompt Firewall เพื่อตรวจจับการทำ Injection หรือหัวข้อที่ต้องห้าม และสกัดกั้นก่อนที่จะส่งต่อไปยัง Agent ส่วนในฝั่งขาออก (Output) จะผ่านตัวกรองข้อมูลส่วนบุคคล ข้อมูลรับรอง (Credentials) และเนื้อหาที่เป็นอันตรายก่อนที่จะส่งไปยังปลายทาง เหตุการณ์ที่ถูกสกัดกั้นในขั้นตอนนี้จะถูกนำไปสะท้อนเป็นสัญญาณความผิดปกติที่รวบรวมไว้ในตัวนับ (Counter) ของ Circuit Breaker เพื่อให้เกิดการทำงานที่เชื่อมโยงกัน เช่น "การตัดการเชื่อมต่อทั้งเซสชันหากพบว่ามีการละเมิด Guardrail ซ้ำๆ"
ภาพรวมของการออกแบบและการติดตั้งใช้งาน Guardrail ได้สรุปไว้ใน คู่มือการติดตั้งใช้งาน AI Guardrail กลไกการหยุดการทำงานที่กล่าวถึงในบทความนี้ ควรถูกมองว่าเป็นตาข่ายนิรภัยชั้นสุดท้ายที่คอยรับมือกับ "การทำงานที่ผิดพลาดระหว่างรันไทม์" ที่เล็ดลอดผ่าน Guardrail ออกมาได้
การออกแบบการหยุดทำงานบางส่วนและการแยกส่วนในระบบมัลติเอเจนต์ (Multi-agent System)
ในระบบที่เอเจนต์หลายตัวทำงานร่วมกัน ความละเอียดในการหยุดการทำงาน (granularity of shutdown) เป็นสิ่งสำคัญ หากเพียงเพราะซับเอเจนต์ตัวหนึ่งทำงานผิดพลาดแล้วสั่งหยุดการทำงานทั้งหมด จะส่งผลเสียต่อความพร้อมใช้งาน (availability) อย่างมาก
หลักการพื้นฐานของการออกแบบคือ การแยกส่วน (Bulkhead) โดยการจัดสรรงบประมาณ เบรกเกอร์ และบริบทการทำงาน (execution context) แยกกันสำหรับซับเอเจนต์แต่ละตัว เพื่อให้เมื่อตัวหนึ่งหยุดทำงาน ตัวอื่นยังคงทำงานต่อไปได้ ตัวออร์เคสเตรเตอร์ (Orchestrator) จะทำหน้าที่ตัดงานของโหนดที่หยุดทำงานออก แล้วเปลี่ยนเส้นทางไปยังช่องทางสำรองหรือส่งเรื่องต่อไปยังมนุษย์
1[Orchestrator]
2 ├─ Agent A (breaker: closed) → ดำเนินการต่อ
3 ├─ Agent B (breaker: open) → แยกส่วน/จัดสรรใหม่
4 └─ Agent C (breaker: closed) → ดำเนินการต่อหากเอเจนต์มีการใช้เครื่องมือหรือสถานะร่วมกัน ความผิดพลาดของตัวหนึ่งอาจลุกลามเป็นลูกโซ่ไปยังส่วนอื่นได้ ทรัพยากรที่ใช้ร่วมกันจึงต้องมีการกำหนดขีดจำกัดและระบบควบคุมการเข้าถึงแยกเฉพาะ สำหรับรายละเอียดเพิ่มเติมเกี่ยวกับการออกแบบการทำงานร่วมกัน โปรดดูที่ Multi-agent AI โครงสร้างที่รองรับการหยุดทำงานบางส่วน (partial shutdown) จะถูกกำหนดตั้งแต่ขั้นตอนการเลือกสถาปัตยกรรมในระยะเริ่มต้น
ข้อผิดพลาดในการใช้งานที่พบบ่อยและวิธีหลีกเลี่ยงคืออะไร?
การหยุดฉุกเฉิน (Emergency Stop) ไม่ใช่แค่ "ติดตั้งแล้วจบไป" หากกำหนดค่าเกณฑ์ (Threshold) หรือวางระบบการใช้งานผิดพลาด อาจทำให้การดำเนินงานปกติหยุดชะงัก หรือไม่สามารถใช้งานได้จริงในยามจำเป็น ต่อไปนี้คือความผิดพลาดสองประการที่พบเห็นได้บ่อยในหน้างาน พร้อมแนวทางแก้ไข
กรณีที่การตั้งค่าเกณฑ์ (Threshold) สูงเกินไปจนทำให้งานปกติหยุดชะงัก
ความผิดพลาดที่พบบ่อยที่สุดคือการตั้งค่าความปลอดภัยที่เข้มงวดเกินไปจนทำให้เกิดการตัดการทำงานที่ผิดพลาด (False Positive) บ่อยครั้ง ผลจากการตั้งค่าขีดจำกัดโทเค็นไว้ที่ค่าเฉลี่ยพอดี ทำให้งานที่ปกติแต่ใช้ทรัพยากรสูงเล็กน้อยถูกยกเลิกทั้งหมด ส่งผลให้ผู้ใช้งานมองว่าเป็น "ฟังก์ชันที่หยุดทำงานบ่อยและใช้งานไม่ได้"
วิธีแก้ไขมีสามประการ ประการแรก กำหนดเกณฑ์จากข้อมูลการกระจายตัวของเมทริกซ์จริง โดยใช้ค่า p95 หรือ p99 แทน p50 เพื่อวางเกณฑ์ในตำแหน่งที่ครอบคลุมงานปกติส่วนใหญ่ ประการที่สอง อย่าใช้การหยุดทำงานแบบทันที (Hard Stop) แต่ให้เริ่มจากขีดจำกัดแบบผ่อนปรน (Soft Limit) เพื่อแจ้งเตือนและลดระดับการทำงานของโมเดลลงก่อน เพื่อให้ส่งผลกระทบแบบค่อยเป็นค่อยไป ประการที่สาม ในช่วงแรกให้รันเบรกเกอร์ใน โหมดสังเกตการณ์ (Shadow Mode) โดยบันทึกเฉพาะล็อกว่า "หากเปิดใช้งานจริง จะหยุดการทำงานกี่ครั้งและเป็นงานประเภทใดบ้าง" การตรวจสอบอัตราการตรวจจับที่ผิดพลาดผ่านการรันจำลองนี้ก่อนเริ่มตัดการทำงานจริง จะช่วยลดอุบัติเหตุหลังนำไปใช้งานจริงได้อย่างมาก ทั้งนี้ ควรเข้าใจว่าค่าเกณฑ์ไม่ใช่ค่าคงที่ แต่เป็นสิ่งที่ต้องปรับจูนอย่างต่อเนื่องระหว่างการใช้งานจริง
รูปแบบการใช้งานที่ไม่เหมาะสม (Anti-pattern) ที่ทำให้ไม่สามารถตรวจสอบสาเหตุได้เนื่องจากไม่มีบันทึก (Log) การหยุดทำงาน
อีกรูปแบบหนึ่งที่พบบ่อยคือการเขียนโปรแกรมที่มุ่งเน้นไปที่การหยุดทำงานเพียงอย่างเดียว โดยละเลยการบันทึกว่า "ทำไมถึงหยุด" แม้ระบบจะหยุดทำงานไปแล้วแต่กลับไม่มีการบันทึก Log ทำให้เมื่อผู้ใช้รายงานว่า "ระบบหยุดทำงานกลางคัน" เราก็ไม่สามารถตรวจสอบได้ว่า Trigger ใดทำงานด้วยค่าเท่าใด ซึ่งทำให้ไม่สามารถปรับค่า Threshold หรือป้องกันการเกิดซ้ำได้
ในเหตุการณ์การหยุดทำงาน (Stop event) ควรมีการบันทึกข้อมูลอย่างน้อยดังต่อไปนี้ในรูปแบบ Structured Log: (1) ประเภทของ Trigger (Cost / Error rate / Timeout / Guardrail), (2) ค่าที่วัดได้จริง ณ ขณะที่ Trigger ทำงานและค่า Threshold, (3) Task ID, User ID หรือ Trace ID ที่เกี่ยวข้อง, (4) ประเภทการหยุด (Hard / Soft) และพฤติกรรมหลังจากนั้น, และ (5) Timestamp หากมีข้อมูลเหล่านี้ครบถ้วน เราจะสามารถตรวจสอบความสมเหตุสมผลของการหยุดทำงานย้อนหลัง และปรับค่า Threshold ได้อย่างมีหลักฐานอ้างอิง
นอกจากนี้ ควรมีการเฝ้าติดตามอัตราการเกิดการหยุดทำงานและอัตราการหยุดทำงานที่ผิดพลาด (False positive) บน Dashboard อย่างต่อเนื่อง และแจ้งเตือนเมื่อมีการเพิ่มขึ้นอย่างรวดเร็ว มุมมองที่ว่ากลไกการหยุดทำงานเองก็เป็นสิ่งที่ต้องถูกเฝ้าติดตามด้วยนั้น ยังนำไปสู่การสร้างหลักฐานสำหรับ "การแทรกแซงโดยมนุษย์ที่อธิบายได้" (Explainable human intervention) ตามที่ EU AI Act กำหนด โดย Log การหยุดทำงานจะกลายเป็นข้อมูลปฐมภูมิสำหรับการสร้างวงจรการปรับปรุงทั้งในด้านต้นทุนและด้านเหตุการณ์ไม่พึงประสงค์ (Incident)
บทสรุป — การออกแบบระบบหยุดฉุกเฉินต้องรวมไว้ตั้งแต่ "ขั้นตอนการออกแบบ"
เซอร์กิตเบรกเกอร์ (Circuit Breaker) สำหรับ AI Agent จะทำงานได้ก็ต่อเมื่อมีการผนวกกระบวนการ "วัดผล → ตัดสินใจ → ตัดการทำงาน → บันทึกข้อมูล" เข้าไปเป็นเงื่อนไขพื้นฐานตั้งแต่ขั้นตอนการออกแบบ ไม่ใช่เป็นเพียงฟังก์ชันเสริมที่เพิ่มเข้ามาภายหลัง โดยสรุปขั้นตอนจากบทความนี้ได้ดังนี้:
- การเตรียมความพร้อม: กำหนดโครงสร้างพื้นฐานด้าน Observability, ระดับการแทรกแซง และตัวชี้วัดเกณฑ์มาตรฐาน (Threshold) ไว้ล่วงหน้า
- เลเยอร์การตรวจสอบ: วัดผลผ่าน Wrapper Layer ใน 3 ด้าน ได้แก่ ปริมาณการใช้งาน, ความคืบหน้า และสัญญาณความผิดปกติ
- ตัวกระตุ้น (Trigger): ตัดสินใจผ่านหลายช่องทางใน 3 ด้าน ได้แก่ ต้นทุน, อัตราข้อผิดพลาด และการหมดเวลา (Timeout)
- คิลสวิตช์ (Kill Switch): เลือกใช้ระหว่างแบบ Hard/Soft และสร้างระบบหลายชั้นด้วย Guardrail และการแยกส่วน Multi-agent
- การดำเนินงาน: ใช้ Shadow Mode เพื่อตรวจสอบการตรวจจับที่ผิดพลาด และปรับปรุงเกณฑ์มาตรฐานอย่างต่อเนื่องจากบันทึกการหยุดทำงาน
กลไกการหยุดทำงานคือการลงทุนที่สนับสนุนทั้งการควบคุมต้นทุนที่บานปลาย การป้องกันอุบัติเหตุทางความปลอดภัย และการปฏิบัติตามกฎระเบียบไปพร้อมกัน ในการสนับสนุนการนำ AI Agent ไปใช้งานจริง บริษัทของเราแนะนำให้ผนวกการออกแบบระบบหยุดทำงานนี้เป็นข้อกำหนดที่จำเป็นในสถาปัตยกรรมเริ่มต้น หากท่านต้องการคำปรึกษาเกี่ยวกับการนำ Agent ไปใช้งานหรือการออกแบบระบบหยุดทำงานฉุกเฉิน โปรดติดต่อเรา
ผู้เขียน・ผู้ตรวจสอบ
Yusuke Ishihara
เริ่มเขียนโปรแกรมตั้งแต่อายุ 13 ปี ด้วย MSX หลังจบการศึกษาจากมหาวิทยาลัย Musashi ได้ทำงานพัฒนาระบบขนาดใหญ่ รวมถึงระบบหลักของสายการบิน และโครงสร้าง Windows Server Hosting/VPS แห่งแรกของญี่ปุ่น ร่วมก่อตั้ง Site Engine Inc. ในปี 2008 ก่อตั้ง Unimon Inc. ในปี 2010 และ Enison Inc. ในปี 2025 นำทีมพัฒนาระบบธุรกิจ การประมวลผลภาษาธรรมชาติ และแพลตฟอร์ม ปัจจุบันมุ่งเน้นการพัฒนาผลิตภัณฑ์และการส่งเสริม AI/DX โดยใช้ generative AI และ Large Language Models (LLM)
บทความแนะนำ
