ການອອກແບບລະບົບຢຸດການເຮັດວຽກສຸກເສີນສຳລັບ AI Agent — ຄູ່ມືການນຳໃຊ້ Circuit Breaker
AI Agent Circuit Breaker ແມ່ນກົນໄກຄວາມປອດໄພທີ່ກວດຈັບ ແລະ ຢຸດການເຮັດວຽກໂດຍອັດຕະໂນມັດ ເມື່ອເກີດການເຮັດວຽກຜິດປົກກະຕິ, ຄ່າໃຊ້ຈ່າຍເກີນກຳນົດ ຫຼື ການວົນລູບຂອງ Agent. ບົດຄວາມນີ້ຈະອະທິບາຍຂັ້ນຕອນການປະຕິບັດຕົວຈິງສຳລັບນັກພັດທະນາ ແລະ MLOps Engineer ທີ່ອອກແບບລະບົບຢຸດສຸກເສີນສຳລັບ AI Agent ທີ່ໃຊ້ LLM, ຕັ້ງແຕ່ຮູບແບບການນຳໃຊ້ Circuit Breaker ໄປຈົນເຖິງການເຊື່ອມໂຍງກັບ AI Guardrails.
AI ເອເຈນ (AI Agent) ຂອງ Circuit Breaker ແມ່ນກົນໄກຄວາມປອດໄພທີ່ໃຊ້ໃນການກວດສອບການເຮັດວຽກທີ່ຜິດປົກກະຕິ, ຄ່າໃຊ້ຈ່າຍທີ່ເກີນກຳນົດ, ແລະ ການເກີດ Loop ທີ່ຄວບຄຸມບໍ່ໄດ້ຂອງເອເຈນແບບ Real-time ເພື່ອຢຸດການປະມວນຜົນໂດຍອັດຕະໂນມັດກ່ອນທີ່ຄວາມເສຍຫາຍຈະຂະຫຍາຍຕົວ. ບົດຄວາມນີ້ມີຈຸດປະສົງສຳລັບນັກພັດທະນາ ແລະ ວິສະວະກອນ MLOps ທີ່ນຳໃຊ້ AI ເອເຈນທີ່ມີ LLM ເຂົ້າໄປໃນການປະຕິບັດງານຈິງ, ໂດຍຈະອະທິບາຍຂັ້ນຕອນຕັ້ງແຕ່ການສ້າງຊັ້ນການຕິດຕາມກວດກາ (Monitoring Layer), ການຕັ້ງຄ່າເງື່ອນໄຂການກະຕຸ້ນ (Trigger conditions), ການຈັດຕັ້ງປະຕິບັດ Kill switch ແລະ Fallback, ຈົນເຖິງການເຊື່ອມໂຍງກັບ Guardrails. ເມື່ອອ່ານຈົບ, ທ່ານຈະສາມາດອອກແບບ "ກົນໄກການຢຸດການເຮັດວຽກ" ໃຫ້ກັບເອເຈນຂອງບໍລິສັດທ່ານຕັ້ງແຕ່ຂັ້ນຕອນການອອກແບບ ແລະ ສາມາດກຳນົດແນວທາງການຈັດຕັ້ງປະຕິບັດທີ່ຊັດເຈນເພື່ອຫຼຸດຜ່ອນຄ່າໃຊ້ຈ່າຍທີ່ເກີດຈາກການເຮັດວຽກທີ່ຜິດພາດ ແລະ ອຸບັດຕິເຫດດ້ານຄວາມປອດໄພ.
AI ເອເຈນທີ່ຕັດສິນໃຈຢ່າງເປັນອິດສະຫຼະຢ່າງຕໍ່ເນື່ອງ ອາດຈະເອີ້ນໃຊ້ງານເຄື່ອງມືຕ່າງໆເກີນກວ່າທີ່ຜູ້ອອກແບບໄດ້ຄາດຄິດໄວ້ ເຊິ່ງອາດສົ່ງຜົນໃຫ້ຕົ້ນທຶນ ແລະ ຄວາມສ່ຽງເພີ່ມທະວີຂຶ້ນເລື້ອຍໆ. ການອອກແບບລະບົບຢຸດການເຮັດວຽກສຸກເສີນ (Emergency Stop) ແມ່ນເງື່ອນໄຂເບື້ອງຕົ້ນທີ່ຕ້ອງມີ "ກົນໄກການຢຸດ" ທີ່ມີຄວາມສຳຄັນເທົ່າທຽມກັບ "ກົນໄກການເຮັດວຽກ". ໃນທີ່ນີ້, ຈະຂໍສະຫຼຸບສາມເຫດຜົນທີ່ບໍ່ສາມາດລະເລີຍການອອກແບບລະບົບຢຸດການເຮັດວຽກໄດ້ ຄື: ຕົ້ນທຶນ, ຄວາມປອດໄພ ແລະ ກົດລະບຽບ.
ຄວາມສ່ຽງຈາກການເຮັດວຽກທີ່ຄວບຄຸມບໍ່ໄດ້ຂອງ Agent: ຄ່າໃຊ້ຈ່າຍ, ຄວາມປອດໄພ ແລະ ຄວາມໜ້າເຊື່ອຖື
ແອັບພລິເຄຊັນແບບດັ້ງເດີມມີການຕອບໂຕ້ແບບ 1 ຕໍ່ 1 ກັບຄຳຮ້ອງຂໍ ຈຶ່ງເຮັດໃຫ້ສາມາດຄາດຄະເນຂອບເຂດຂອງຄວາມເສຍຫາຍໄດ້ງ່າຍ. ໃນທາງກົງກັນຂ້າມ, AI Agent ຈະເຊື່ອມໂຍງການເອີ້ນໃຊ້ເຄື່ອງມື ແລະ ການອະນຸມານຂອງ LLM ເຂົ້າດ້ວຍກັນຫຼາຍສິບຄັ້ງຈາກຄຳສັ່ງດຽວ. ຖ້າການເຊື່ອມໂຍງນີ້ສິ້ນສຸດລົງຕາມທີ່ຄາດໄວ້ກໍຈະບໍ່ມີບັນຫາ, ແຕ່ຖ້າຕັດສິນເງື່ອນໄຂຂອງ Loop ຜິດພາດ ການເອີ້ນໃຊ້ງານຈະບໍ່ຢຸດ ແລະ ຄ່າໃຊ້ຈ່າຍຈະເພີ່ມທະວີຂຶ້ນເລື້ອຍໆ.
ຄວາມສ່ຽງແບ່ງອອກເປັນສາມຊັ້ນໃຫຍ່ໆ. ຢ່າງທີໜຶ່ງແມ່ນ ຄ່າໃຊ້ຈ່າຍ (Cost)—ການຄິດໄລ່ເງິນຕາມ Token ຫຼື ການຄິດໄລ່ເງິນຕາມການໃຊ້ງານຂອງ API ພາຍນອກຈະສູນເສຍການຄວບຄຸມ. ຢ່າງທີສອງແມ່ນ ຄວາມປອດໄພ (Security)—ຖືກຊັກຈູງໂດຍ Prompt Injection ຈົນເຮັດໃຫ້ປະຕິບັດການທີ່ບໍ່ໄດ້ຮັບອະນຸຍາດ (ການສົ່ງອີເມວ, ການລຶບຂໍ້ມູນ, ການສົ່ງຂໍ້ມູນອອກໄປພາຍນອກ). ຢ່າງທີສາມແມ່ນ ຄວາມໜ້າເຊື່ອຖື (Reliability)—ການສົ່ງຜົນລວມເຖິງ Hallucination ໄປເປັນຂໍ້ມູນທີ່ຢືນຢັນແລ້ວເພື່ອສົ່ງຂໍ້ມູນຕໍ່ໃຫ້ຂະບວນການຖັດໄປ (Downstream processing) ເຮັດໃຫ້ຂໍ້ມູນທາງທຸລະກິດເປິເປື້ອນ. ທັງສາມຢ່າງນີ້ບໍ່ໄດ້ແຍກອອກຈາກກັນ, ແຕ່ໃນເວລາທີ່ເກີດການເຮັດວຽກຜິດພາດ (Runaway) ມັນຈະເຊື່ອມໂຍງກັນ ແລະ ເກີດຂຶ້ນພ້ອມໆກັນ. ດ້ວຍເຫດນີ້, ຈຶ່ງຈຳເປັນຕ້ອງມີກົນໄກຮ່ວມໃນການ "ກວດຈັບ ແລະ ຢຸດ" ແທນທີ່ຈະເປັນມາດຕະການແຍກສ່ວນ.
ໄພຄຸກຄາມຈາກການບໍລິໂພກຊັບພະຍາກອນທີ່ບໍ່ຈຳກັດ ແລະ ການເຮັດວຽກທີ່ເກີນຂອບເຂດ
ຄວາມສ່ຽງສະເພາະຂອງ AI Agent ໄດ້ຖືກລະບຸໄວ້ຢ່າງຈະແຈ້ງໃນໝວດໝູ່ໄພຄຸກຄາມສຳລັບແອັບພລິເຄຊັນ LLM ຂອງ OWASP. ຕົວຢ່າງທີ່ໂດດເດັ່ນຄື Unbounded Consumption ແລະ Excessive Agency.
Unbounded Consumption ໝາຍເຖິງສະພາວະທີ່ບໍ່ມີການກຳນົດຂອບເຂດສຳລັບການປ້ອນຂໍ້ມູນ ຫຼື ການຮຽກໃຊ້ແບບ Recursive ເຮັດໃຫ້ຊັບພະຍາກອນຄຳນວນ, ຄ່າໃຊ້ຈ່າຍ ແລະ Token ຖືກນຳໃຊ້ຢ່າງບໍ່ມີຂອບເຂດ. ເຊິ່ງລວມເຖິງການເກີດ Loop ບໍ່ສິ້ນສຸດ ຫຼື ການໂຈມຕີແບບປະຕິເສດການໃຫ້ບໍລິການ (DoS) ທີ່ຜູ້ໂຈມຕີຕັ້ງໃຈສົ່ງວຽກທີ່ມີຄວາມໜັກໜ່ວງເຂົ້າມາ.
Excessive Agency ໝາຍເຖິງສະພາວະທີ່ສິດທິ, ເຄື່ອງມື ແລະ ຄວາມເປັນອິດສະຫຼະທີ່ມອບໃຫ້ແກ່ Agent ມີຫຼາຍເກີນໄປ ເຮັດໃຫ້ຂອບເຂດຜົນກະທົບເມື່ອເກີດການເຮັດວຽກຜິດພາດກວ້າງຂວາງເກີນໄປ. ການອອກແບບທີ່ "ມອບສິດທິໃນການຂຽນຂໍ້ມູນໃຫ້ກັບວຽກທີ່ຕ້ອງການພຽງແຕ່ການອ່ານ" ຫຼື "ສາມາດດຳເນີນການທີ່ບໍ່ສາມາດຍົກເລີກໄດ້ໂດຍບໍ່ມີການອະນຸມັດຈາກມະນຸດ" ແມ່ນຕົວຢ່າງທີ່ພົບເຫັນໄດ້ທົ່ວໄປ. Circuit Breaker ຈະຊ່ວຍຄວບຄຸມບັນຫາທຳອິດ, ໃນຂະນະທີ່ການຫຼຸດຜ່ອນສິດທິໃຫ້ເຫຼືອໜ້ອຍທີ່ສຸດ (ການອອກແບບສິດທິຂັ້ນຕໍ່າສຸດ) ຈະຊ່ວຍຄວບຄຸມບັນຫາຫຼັງ. ທັງສອງຢ່າງນີ້ມີຄວາມສຳພັນແບບຕື່ມເຕັມເຊິ່ງກັນແລະກັນ, ໂດຍທີ່ການປ້ອງກັນພຽງດ້ານດຽວອາດບໍ່ພຽງພໍ.
ຂໍ້ກຳນົດການຄວບຄຸມການຢຸດການເຮັດວຽກຕາມ AI Governance ແລະ EU AI Act
ການປ້ອງກັນການເຮັດວຽກທີ່ຜິດພາດ (Runaway prevention) ບໍ່ພຽງແຕ່ເປັນບັນຫາທາງດ້ານເຕັກນິກເທົ່ານັ້ນ ແຕ່ຍັງເປັນຂໍ້ກຳນົດດ້ານການປະຕິບັດຕາມກົດລະບຽບ (Compliance) ອີກດ້ວຍ. EU AI Act ທີ່ໄດ້ມີການບັງຄັບໃຊ້ຢ່າງເຕັມຮູບແບບແລ້ວ ໄດ້ກຳນົດໃຫ້ລະບົບ AI ທີ່ມີຄວາມສ່ຽງສູງຕ້ອງມີ ວິທີການທີ່ມະນຸດສາມາດເຂົ້າໄປຄວບຄຸມ (Human Oversight) ເພື່ອຢຸດການເຮັດວຽກຂອງລະບົບໄດ້ຕາມຄວາມຈຳເປັນໃນຂະນະທີ່ລະບົບກຳລັງດຳເນີນການ. ການທີ່ມີລະບົບຄວບຄຸມທີ່ປຽບສະເໝືອນປຸ່ມຢຸດສຸກເສີນ (Kill switch) ຖືກອອກແບບມາໃນລະບົບນັ້ນ ຖືເປັນຈຸດສຳຄັນໃນການປະເມີນຄວາມສອດຄ່ອງ.
ກ່າວຄື: Kill switch ບໍ່ແມ່ນສິ່ງທີ່ "ມີໄວ້ກໍອຸ່ນໃຈ" ອີກຕໍ່ໄປ ແຕ່ໃນຂົງເຂດທີ່ຖືກຄວບຄຸມນັ້ນ ມັນກຳລັງກາຍເປັນອົງປະກອບທີ່ "ຖ້າບໍ່ມີ ກໍຈະບໍ່ຜ່ານຂໍ້ກຳນົດ". ເຖິງແມ່ນວ່າພາບລວມລວມເຖິງກົດລະບຽບພາຍໃນ ແລະ ການຮອງຮັບການກວດສອບຈະຖືກຮວບຮວມໄວ້ໃນ ຄູ່ມືການປະຕິບັດງານດ້ານ AI Governance ແລ້ວກໍຕາມ, ແຕ່ໃນມຸມມອງຂອງການຄວບຄຸມການຢຸດລະບົບນັ້ນ ຢ່າງໜ້ອຍຄວນມີການລະບຸໄວ້ເປັນລາຍລັກອັກສອນໃນຂັ້ນຕອນການອອກແບບດັ່ງນີ້: (1) ໃຜເປັນຜູ້ຢຸດລະບົບໄດ້ ແລະ ພາຍໃຕ້ເງື່ອນໄຂໃດ, (2) ການຢຸດລະບົບ ແລະ ເຫດຜົນມີການບັນທຶກໄວ້ໃນ Log ຫຼືບໍ່, ແລະ (3) ສາມາດກັບຄືນສູ່ສະຖານະທີ່ປອດໄພຫຼັງຈາກການຢຸດລະບົບໄດ້ຫຼືບໍ່.
ເງື່ອນໄຂເບື້ອງຕົ້ນ ແລະ ແນວທາງການອອກແບບທີ່ຄວນກວດສອບກ່ອນການນຳໃຊ້ແມ່ນຫຍັງ?
Circuit Breaker ບໍ່ສາມາດເຮັດວຽກໄດ້ດ້ວຍຕົວມັນເອງ. ມັນຈະເຮັດວຽກໄດ້ກໍຕໍ່ເມື່ອມີ ໂຄງສ້າງພື້ນຖານ ຫຼື Infrastructure ໃນການສັງເກດການວ່າ "ມີຫຍັງເກີດຂຶ້ນ", ມີນະໂຍບາຍວ່າ "ໃຜຈະເປັນຜູ້ເຂົ້າແຊກແຊງ ແລະ ແຊກແຊງເຖິງຂັ້ນໃດ", ແລະ ມີການກຳນົດຄ່າ Threshold ວ່າ "ຈະໃຫ້ຢຸດທີ່ຄ່າໃດ". ກ່ອນຈະເຂົ້າສູ່ການ Implement, ໃຫ້ກວດສອບສາມເງື່ອນໄຂເບື້ອງຕົ້ນນີ້ກ່ອນ.
ການກວດສອບສະຖານະການກຽມພ້ອມຂອງໂຄງສ້າງພື້ນຖານ ຫຼື Infrastructure ດ້ານ AI Observability
ກົນໄກການຢຸດການເຮັດວຽກຈະເຮັດວຽກໄດ້ພາຍໃນຂອບເຂດທີ່ສາມາດສັງເກດການໄດ້ເທົ່ານັ້ນ. ການໃຊ້ງານ Token ແລະ ຈຳນວນຮອບວຽນ (Loop) ຈະບໍ່ສາມາດຖືກກະຕຸ້ນໄດ້ຫາກບໍ່ມີການວັດແທກ. ດັ່ງນັ້ນ, ເງື່ອນໄຂເບື້ອງຕົ້ນແມ່ນການມີພື້ນຖານ AI Observability ເພື່ອເຮັດໃຫ້ສະຖານະພາຍໃນຂອງ Agent ສາມາດເບິ່ງເຫັນໄດ້.
ໂດຍສະເພາະ, ມັນຈຳເປັນຕ້ອງສາມາດບັນທຶກຂໍ້ມູນ Input, Output, Token ທີ່ໃຊ້, ການຮຽກໃຊ້ Tool, Latency ແລະ Error ຂອງແຕ່ລະຂັ້ນຕອນຕາມລຳດັບເວລາໃນຮູບແບບຂອງ Trace. ຫາກນຳແນວຄິດການເຮັດ Distributed Tracing ເຊັ່ນ OpenTelemetry ມາປະຍຸກໃຊ້ກັບການຮຽກໃຊ້ LLM ແລະ ຈັດໂຄງສ້າງເປັນ "1 Task = 1 Trace" ແລະ "1 Step = 1 Span", ທ່ານກໍຈະສາມາດຂຽນເງື່ອນໄຂການຕັດສິນດ້ວຍ Threshold ໃນຂັ້ນຕອນຕໍ່ໄປໄດ້ໂດຍກົງ. ເຖິງແມ່ນວ່າການອອກແບບໂຄງສ້າງພື້ນຖານ ຫຼື Infrastructure ດ້ານການສັງເກດການຈະຖືກກ່າວເຖິງໃນ ຄູ່ມືການປະຕິບັດງານ AI Observability ແລ້ວ, ແຕ່ບົດຄວາມນີ້ຈະດຳເນີນໄປໂດຍມີເງື່ອນໄຂວ່າ "ສາມາດດຶງຂໍ້ມູນ Metrics ທີ່ວັດແທກໄວ້ແລ້ວມາໃຊ້ໄດ້". ຫາກຍັງບໍ່ທັນມີຄວາມພ້ອມ, ການເລີ່ມຕົ້ນຈາກການສັງເກດການກ່ອນຖືເປັນລຳດັບທີ່ຖືກຕ້ອງ.
ການກຳນົດລະດັບການແຊກແຊງແບບ Human-in-the-loop / On-the-loop
ຕໍ່ໄປແມ່ນການຕັດສິນໃຈວ່າ ຈະໃຫ້ມະນຸດມີສ່ວນຮ່ວມໃນການຕັດສິນໃຈຢຸດການເຮັດວຽກແນວໃດ. ຄວາມເຂັ້ມຂຸ້ນຂອງການແຊກແຊງສາມາດຈັດລະບຽບໄດ້ງ່າຍໂດຍການພິຈາລະນາເປັນ 3 ລະດັບໃຫຍ່ໆ.
In-the-loop ແມ່ນວິທີການທີ່ຕ້ອງມີການອະນຸມັດຈາກມະນຸດກ່ອນການດຳເນີນການທີ່ສຳຄັນສະເໝີ. ເໝາະສຳລັບຂະບວນການທີ່ບໍ່ສາມາດຍົກເລີກໄດ້ ຫຼື ມີຄວາມສ່ຽງສູງ ແຕ່ຈະເຮັດໃຫ້ປະສິດທິພາບ (Throughput) ຫຼຸດລົງ. On-the-loop ແມ່ນວິທີການທີ່ Agent ດຳເນີນການດ້ວຍຕົນເອງ ໃນຂະນະທີ່ມະນຸດຄອຍຕິດຕາມສະຖານະການຜ່ານ Dashboard ແລະ ເຂົ້າໄປແຊກແຊງ ຫຼື ຢຸດການເຮັດວຽກເມື່ອຈຳເປັນ. Out-of-the-loop ແມ່ນການເຮັດວຽກແບບອັດຕະໂນມັດຢ່າງສົມບູນ ໂດຍການຢຸດການເຮັດວຽກຈະຂຶ້ນກັບກົນໄກການກະຕຸ້ນ (Trigger) ຂອງເຄື່ອງຈັກ.
ໃນການປະຕິບັດງານຕົວຈິງ, ການປັບປ່ຽນລະດັບໃຫ້ແຕກຕ່າງກັນໄປຕາມແຕ່ລະເຄື່ອງມື ໂດຍອີງໃສ່ຄວາມສາມາດໃນການຍົກເລີກຂອງຂະບວນການ ແລະ ຄວາມສ່ຽງນັ້ນຖືເປັນເລື່ອງທີ່ເໝາະສົມ. ຕົວຢ່າງເຊັ່ນ: "ການຄົ້ນຫາແມ່ນເຮັດແບບອັດຕະໂນມັດ, ການສົ່ງຂໍ້ມູນອອກພາຍນອກຕ້ອງໄດ້ຮັບການອະນຸມັດ, ແລະ ການຊຳລະເງິນຕ້ອງມີການອະນຸມັດສອງຊັ້ນ" ເປັນຕົ້ນ. ພື້ນຖານຂອງການອອກແບບການແຊກແຊງສາມາດອ່ານລາຍລະອຽດເພີ່ມເຕີມໄດ້ທີ່ ຄຳອະທິບາຍກ່ຽວກັບ Human-in-the-loop (HITL). ສຳລັບ Circuit Breaker, ຄວນກຳນົດປາຍທາງໃນການສົ່ງຂໍ້ມູນຕໍ່ໃຫ້ (Escalation) ເມື່ອມີການຢຸດການເຮັດວຽກໃຫ້ຊັດເຈນ ເພື່ອບໍ່ໃຫ້ຂັດກັບລະດັບການແຊກແຊງເຫຼົ່ານີ້.
ການກຳນົດຕົວຊີ້ວັດຂີດຈຳກັດ (ຈຳນວນ Token, ຄ່າໃຊ້ຈ່າຍ, ຈຳນວນຮອບລູບ) ເພື່ອເປັນຕົວສັ່ງການຢຸດ
ເງື່ອນໄຂເບື້ອງຕົ້ນສຸດທ້າຍແມ່ນການເລືອກຕົວຊີ້ວັດເພື່ອຕັດສິນໃຈວ່າຈະຢຸດເມື່ອໃດ. ໃຫ້ເລືອກຕົວຊີ້ວັດຂີດຈຳກັດ (Threshold) ທີ່ເປັນຕົວແທນ ໂດຍພິຈາລະນາຈາກຄວາມງ່າຍໃນການສັງເກດ ແລະ ຄວາມຍາກໃນການເກີດການກວດຈັບຜິດພາດ.
| ຕົວຊີ້ວັດ | ຕົວຢ່າງ | ສິ່ງທີ່ປ້ອງກັນເປັນຫຼັກ |
|---|---|---|
| ຈຳນວນ Token ສະສົມ | 1 ວຽກ 50,000 Token | ຄ່າໃຊ້ຈ່າຍບານປາຍ |
| ຄ່າໃຊ້ຈ່າຍສະສົມ | 1 ວຽກ 0.5 USD | ຄ່າໃຊ້ຈ່າຍບານປາຍ |
| ຈຳນວນຂັ້ນຕອນ / ຈຳນວນຮອບວຽນ | 30 ຂັ້ນຕອນ | ການວົນລູບແບບບໍ່ສິ້ນສຸດ |
| ອັດຕາຄວາມຜິດພາດຕໍ່ເນື່ອງ | ລົ້ມເຫຼວ 3 ໃນ 5 ຄັ້ງຫຼ້າສຸດ | ການເກີດບັນຫາຕໍ່ເນື່ອງຈາກພາຍນອກ |
| ເວລາທີ່ຜ່ານໄປ | 10 ນາທີຕໍ່ເຊສຊັນ | ການຄ້າງ ຫຼື ການຕົກຄ້າງ |
ສິ່ງທີ່ສຳຄັນຄື ການບໍ່ເພິ່ງພາຕົວຊີ້ວັດດຽວ ແຕ່ໃຫ້ໃຊ້ຫຼາຍຕົວຊີ້ວັດປະສົມປະສານກັນ. ຖ້າໃຊ້ພຽງຈຳນວນ Token ຢ່າງດຽວ ອາດຈະເຮັດໃຫ້ພາດ "ການວົນລູບທີ່ມີລາຄາຖືກແຕ່ບໍ່ສິ້ນສຸດ" ແລະ ຖ້າໃຊ້ພຽງຈຳນວນຂັ້ນຕອນຢ່າງດຽວ ກໍອາດຈະພາດ "ການຮຽກໃຊ້ເຄື່ອງມືທີ່ມີຈຳນວນໜ້ອຍແຕ່ມີລາຄາສູງ". ຢ່າຕັ້ງເປົ້າໝາຍໃຫ້ຂີດຈຳກັດສົມບູນແບບຕັ້ງແຕ່ຕົ້ນ, ໃຫ້ຕັ້ງໄວ້ໃນລະດັບທີ່ປອດໄພກ່ອນໂດຍມີເງື່ອນໄຂວ່າຈະປັບປ່ຽນໃນພາຍຫຼັງໂດຍເບິ່ງຈາກການກະຈາຍຂອງ Metrics ໃນການໃຊ້ງານຈິງ (p50 / p95). ສຳລັບວິທີການກຳນົດຄ່າສູງສຸດຂອງລະບົບຄ່າໃຊ້ຈ່າຍ ຄວນພິຈາລະນາຮ່ວມກັບການອອກແບບງົບປະມານໃນ ຄູ່ມືການປັບຄ່າໃຊ້ຈ່າຍ LLM ໃຫ້ເໝາະສົມ.
ຂັ້ນຕອນທີ 1: ຈະສ້າງຊັ້ນການຕິດຕາມກວດກາແນວໃດ?
Circuit Breaker ຕົວຈິງແລ້ວແມ່ນວົງຈອນຂອງ "ການວັດແທກ → ການຕັດສິນ → ການຕັດການເຊື່ອມຕໍ່". ຂັ້ນຕອນທຳອິດແມ່ນການສ້າງຊັ້ນການຕິດຕາມກວດກາເພື່ອເກັບກຳ Metrics ທີ່ໃຊ້ເປັນຂໍ້ມູນໃນການຕັດສິນໃຈແບບ Real-time. ໃນທີ່ນີ້, ຈະມີການວັດແທກສາມລະບົບຄື: ປະລິມານການບໍລິໂພກ, ຄວາມຄືບໜ້າ, ແລະ ສັນຍານຄວາມຜິດປົກກະຕິ.
ການວັດແທກການໃຊ້ Token, ຈຳນວນການເອີ້ນໃຊ້ API ແລະ Latency ແບບ Real-time
ພື້ນຖານຂອງຊັ້ນການຕິດຕາມກວດກາ (Monitoring layer) ແມ່ນຕົວນັບທີ່ສະສົມປະລິມານການໃຊ້ງານໃນແຕ່ລະຂັ້ນຕອນຂອງ Agent. ໂດຍການຫຸ້ມຫໍ່ LLM client ແລະ ການປະມວນຜົນ Tool ດ້ວຍ Wrapper, ທຸກຄັ້ງທີ່ມີການຮຽກໃຊ້ ຈະມີການບວກຈຳນວນ Token, ຄ່າໃຊ້ຈ່າຍ, ຈຳນວນຄັ້ງ ແລະ Latency ເຂົ້າໄປໃນ Context ຂອງແຕ່ລະ Task.
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)ຈຸດສຳຄັນ ຫຼື ແກນຫຼັກ ແມ່ນການແຍກການວັດແທກອອກຈາກ Logic ຫຼັກຂອງ Agent ແລະ ເກັບໄວ້ໃນຊັ້ນ Wrapper. ດ້ວຍວິທີນີ້, ເຖິງແມ່ນວ່າຈະມີການປ່ຽນແປງເງື່ອນໄຂຂອງ Breaker ໃນພາຍຫຼັງ ກໍບໍ່ຈຳເປັນຕ້ອງໄປແຕະຕ້ອງກັບຕົວ Logic ຫຼັກ. ສ່ວນ Latency ນັ້ນ ຈະຖືກບັນທຶກໄວ້ພ້ອມກັນ ເພື່ອເປັນດັດຊະນີໃນການກວດຈັບສັນຍານເຕືອນໄພລ່ວງໜ້າ ໃນກໍລະນີທີ່ຄວາມຊັກຊ້າຂອງ API ພາຍນອກສົ່ງຜົນຕໍ່ເນື່ອງຈົນເຮັດໃຫ້ລະບົບທັງໝົດຄ້າງ.
ການຕິດຕາມຄວາມຄືບໜ້າຂອງ Task Graph ແລະ ລໍຈິກການກວດຈັບ Infinite Loop
ນອກຈາກປະລິມານການບໍລິໂພກແລ້ວ ສິ່ງທີ່ສຳຄັນບໍ່ແພ້ກັນຄືການຕິດຕາມວ່າ "Agent ກຳລັງກ້າວໄປຂ້າງໜ້າຫຼືບໍ່". ວົງຈອນທີ່ບໍ່ມີວັນສິ້ນສຸດ (Infinite loop) ສ່ວນຫຼາຍມັກຈະເກີດຂຶ້ນໃນຮູບແບບຂອງການໃຊ້ເຄື່ອງມືຊະນິດດຽວກັນດ້ວຍ Argument ດຽວກັນຊ້ຳໆ ຫຼື ການວົນວຽນຢູ່ໃນສະຖານະເດີມ.
ພື້ນຖານຂອງການກວດຈັບມີສອງຢ່າງ: ຢ່າງທຳອິດຄື ຂີດຈຳກັດຂອງຂັ້ນຕອນ (Step limit) — ກຳນົດຈຳນວນຂັ້ນຕອນສູງສຸດຕໍ່ໜຶ່ງ Task, ຖ້າເກີນກຳນົດໃຫ້ຢຸດການເຮັດວຽກທັນທີ. ຢ່າງທີສອງຄື ການກວດຈັບການຊ້ຳ (Repetition detection) — ເກັບ Hash ຂອງຊື່ເຄື່ອງມື ແລະ Argument ຂອງ N ຂັ້ນຕອນຫຼ້າສຸດໄວ້, ຖ້າພົບຮູບແບບດຽວກັນເກີນຈຳນວນທີ່ກຳນົດໄວ້ (Threshold) ໃຫ້ຖືວ່າເປັນ Loop.
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 ທີ່ແຍກການວາງແຜນ (Planning) ແລະ ການປະຕິບັດ (Execution) ອອກຈາກກັນ, ເຮົາສາມາດກວດສອບການປ່ຽນແປງຂອງ Node ໃນ Task graph ໂດຍກົງໄດ້. ສຳລັບຮູບແບບການອອກແບບ ສາມາດອ້າງອີງໄດ້ທີ່ ຄຳອະທິບາຍກ່ຽວກັບ Multi-agent AI. ສ່ວນສະຖານະ "Stuck" ທີ່ຄວາມຄືບໜ້າບໍ່ມີການອັບເດດໃນໄລຍະເວລາທີ່ກຳນົດ ກໍສາມາດກວດຈັບໄດ້ດ້ວຍການຕັ້ງ Timeout ແຍກຕ່າງຫາກ.
ການເກັບກຳສັນຍານຜິດປົກກະຕິຈາກ Prompt Injection ແລະ Hallucination
ນອກຈາກປະລິມານ ແລະ ຄວາມຄືບໜ້າແລ້ວ, ຍັງຕ້ອງເກັບກຳ "ຄວາມຜິດປົກກະຕິດ້ານຄຸນນະພາບ" ຂອງຜົນລັພທີ່ອອກມາໄວ້ເປັນສັນຍານນຳອີກ. ສິ່ງນີ້ຈະກາຍເປັນວັດຖຸດິບໃນການກະຕຸ້ນໃຫ້ເກີດການໃຊ້ Guardrails ຫຼື ການແຊກແຊງຈາກມະນຸດໃນຂະບວນການ ຫຼື Pipeline ຫຼັງຈາກນັ້ນ.
ສຳລັບສັນຍານເຕືອນຂອງ Prompt Injection, ໃຫ້ຕິດຕາມການປະກົດຕົວຂອງຄຳສັບທີ່ພະຍາຍາມຂຽນທັບຄຳສັ່ງຂອງລະບົບ (ເຊັ່ນ: "ໃຫ້ລະເລີຍຄຳສັ່ງກ່ອນໜ້ານີ້"), ການຮຽກໃຊ້ເຄື່ອງມືທີ່ບໍ່ໄດ້ຮັບອະນຸຍາດຢ່າງກະທັນຫັນ, ແລະ ຮູບແບບການຮົ່ວໄຫຼຂອງ URL ພາຍນອກ ຫຼື ຂໍ້ມູນການຢືນຢັນຕົວຕົນທີ່ລວມຢູ່ໃນຜົນລັພ. ສ່ວນສັນຍານເຕືອນຂອງ Hallucination, ໃຫ້ເກັບກຳການອ້າງອີງເຖິງຂໍ້ເທັດຈິງທີ່ບໍ່ມີຢູ່ຈິງໃນຜົນລັພຂອງເຄື່ອງມື, ລະດັບຄວາມໝັ້ນໃຈທີ່ລາຍງານດ້ວຍຕົນເອງສູງ ຫຼື ຕ່ຳຜິດປົກກະຕິ, ແລະ ຄວາມບໍ່ຄົງທີ່ຂອງຄຳຕອບຕໍ່ຄຳຖາມດຽວກັນ.
ສິ່ງສຳຄັນຄື ສິ່ງທີ່ເກັບກຳມາໃນທີ່ນີ້ເປັນພຽງ "ສັນຍານ" ເທົ່ານັ້ນ ແລະ ບໍ່ຄວນໃຊ້ເປັນພື້ນຖານໃນການຢຸດການເຮັດວຽກຢ່າງເດັດຂາດພຽງລຳພັງ. ຖ້າມີການກວດພົບຜິດພາດຫຼາຍເກີນໄປ ກໍອາດຈະເຮັດໃຫ້ວຽກງານປົກກະຕິຖືກສະກັດກັ້ນໄປນຳ. ການສ້າງເຫດຜົນໃນການກວດຈັບຈະມີຄວາມແມ່ນຍຳສູງຂຶ້ນຫາກເຂົ້າໃຈວິທີການຂອງຝ່າຍໂຈມຕີ — ເຊິ່ງຄວນສຶກສາຮູບແບບການໂຈມຕີທີ່ເປັນແບບຢ່າງຈາກ AI Red Teaming ໄວ້.
ຂັ້ນຕອນທີ 2: ຈະຕັ້ງຄ່າເງື່ອນໄຂການສັ່ງການ Circuit Breaker ແນວໃດ?
ຂັ້ນຕອນນີ້ແມ່ນການປ່ຽນແປງເມຕຣິກທີ່ເກັບກຳມາຈາກການຕິດຕາມກວດກາ ໃຫ້ກາຍເປັນການຕັດສິນໃຈວ່າຈະ "ຢຸດ ຫຼື ບໍ່ຢຸດ" ການເຮັດວຽກ. ເຊັ່ນດຽວກັນກັບ Circuit Breaker ຂອງ Microservices, ລະບົບຈະກຳນົດຕົວກະຕຸ້ນ (Trigger) ໂດຍອີງໃສ່ 3 ປັດໄຈຫຼັກ ຄື: ຕົ້ນທຶນ (Cost), ອັດຕາຄວາມຜິດພາດ (Error rate) ແລະ ເວລາໝົດເວລາ (Timeout). ຕໍ່ໄປ, ພວກເຮົາຈະມາເບິ່ງການອອກແບບຄ່າຂີດຈຳກັດ (Threshold) ຂອງແຕ່ລະສ່ວນ.
ການຄວບຄຸມໂດຍອີງໃສ່ຄ່າໃຊ້ຈ່າຍ: ການຕັ້ງຂີດຈຳກັດງົບປະມານ LLM Token
ຈຸດເລີ່ມຕົ້ນແມ່ນອີງໃສ່ງົບປະມານ. ໂດຍກຳນົດຂີດຈຳກັດຂອງຄ່າໃຊ້ຈ່າຍ Token ແລະ ຈຳນວນຄັ້ງໃນການເອີ້ນໃຊ້ສຳລັບແຕ່ລະ Task, ພ້ອມທັງອອກແບບພຶດຕິກຳເມື່ອເກີນຂີດຈຳກັດໄວ້ເປັນຊຸດ. ການກຳນົດຂີດຈຳກັດບໍ່ຄວນເປັນມາດຕະຖານດຽວ, ແຕ່ຄວນມີຢ່າງໜ້ອຍສາມລະດັບເພື່ອໃຫ້ງ່າຍຕໍ່ການດຳເນີນງານ.
| ລະດັບ | ຕົວຢ່າງ | ພຶດຕິກຳເມື່ອເກີນຂີດຈຳກັດ |
|---|---|---|
| ຂີດຈຳກັດແບບອ່ອນ (Soft limit) | 0.3 USD | ແຈ້ງເຕືອນ + ປ່ຽນໄປໃຊ້ Model ທີ່ມີລາຄາຖືກກວ່າ |
| ຂີດຈຳກັດແບບແຂງ (Hard limit) | 0.5 USD | ຢຸດການເຮັດວຽກແບບບັງຄັບ + ສົ່ງຂໍ້ມູນຕໍ່ໃຫ້ມະນຸດ |
| ຂີດຈຳກັດການເອີ້ນໃຊ້ | LLM 30 ຄັ້ງ / Tool 50 ຄັ້ງ | ບັງຄັບຢຸດ Loop |
ຄ່າທີ່ເໝາະສົມຈະປ່ຽນແປງໄປຕາມລັກສະນະຂອງ Task. Task ທີ່ເຂົ້າສູ່ຈຸດສິ້ນສຸດໄດ້ງ່າຍເຊັ່ນ: ການສະກັດຂໍ້ມູນ (Extraction) ຫຼື ການຈັດຮູບແບບ (Formatting) ຈະມີຄ່າໃຊ້ຈ່າຍຕ່ຳ, ໃນຂະນະທີ່ການຄົ້ນຄວ້າ ຫຼື ການວາງແຜນໄລຍະຍາວຈະຄາດເດົາຈຳນວນຮອບວຽນໄດ້ຍາກ. ການຈັດປະເພດເປັນ "ກຸ່ມສຳຫຼວດ / ກຸ່ມສະກັດຂໍ້ມູນ / ກຸ່ມສ້າງຂໍ້ມູນ" ແລ້ວແຍກງົບປະມານອອກຈາກກັນ ຈະຊ່ວຍຫຼີກລ່ຽງສະຖານະການທີ່ໃຊ້ຂີດຈຳກັດດຽວກັນກັບທຸກ Task ເຊິ່ງອາດເຮັດໃຫ້ "90% ວ່າງເກີນໄປ ແລະ 10% ເຂັ້ມງວດເກີນໄປ". ແນວຄິດໃນການວາງງົບປະມານໃຫ້ເປັນຈຸດສຳຄັນ ຫຼື ແກນຫຼັກ ຂອງການອອກແບບຄ່າໃຊ້ຈ່າຍທັງໝົດ ໄດ້ອະທິບາຍໄວ້ຢ່າງລະອຽດໃນ AI Agent Economic Model.
ການຕັດການເຊື່ອມຕໍ່ໂດຍອີງໃສ່ອັດຕາຄວາມຜິດພາດ: ການຢຸດອັດຕະໂນມັດຕາມຈຳນວນຄັ້ງທີ່ລົ້ມເຫຼວຕໍ່ເນື່ອງ
ອັນທີສອງແມ່ນຕົວກະຕຸ້ນທີ່ອີງໃສ່ອັດຕາຄວາມຜິດພາດ (Error rate-based trigger) ເຊິ່ງເປັນສິ່ງທີ່ໃກ້ຄຽງກັບ "Circuit Breaker" ທີ່ແທ້ຈິງຫຼາຍທີ່ສຸດ. ໂດຍປະຕິບັດຕາມຮູບແບບຂອງ Microservices ແລະຈັດການດ້ວຍ 3 ສະຖານະດັ່ງນີ້:
- Closed (ປິດ): ການເຮັດວຽກປົກກະຕິ. ຍອມໃຫ້ມີການຮຽກໃຊ້ງານຜ່ານໄປໄດ້ ແຕ່ຈະນັບຈຳນວນຄວາມຜິດພາດໄວ້.
- Open (ເປີດ): ເມື່ອຄວາມຜິດພາດເກີນຂີດຈຳກັດ (Threshold) ທີ່ກຳນົດໄວ້ ວົງຈອນຈະເປີດອອກ ແລະ ປະຕິເສດການຮຽກໃຊ້ງານທັງໝົດໃນທັນທີເປັນເວລາໜຶ່ງ (Fail-fast).
- Half-Open (ເຄິ່ງເປີດ): ຫຼັງຈາກໝົດເວລາ Cool-down ຈະທົດລອງໃຫ້ມີການຮຽກໃຊ້ງານຜ່ານໄປໄດ້ສອງ-ສາມຄັ້ງ, ຖ້າຫາກລະບົບຟື້ນຕົວແລ້ວຈະກັບຄືນສູ່ສະຖານະ Closed.
1if breaker.state == "open":
2 if now < breaker.retry_at:
3 raise CircuitOpen("ກຳລັງຕັດການເຊື່ອມຕໍ່ເນື່ອງຈາກການເພິ່ງພາພາຍນອກບໍ່ສະຖຽນ")
4 breaker.state = "half_open" # ທົດລອງເປີດໃຊ້ງານຄືນໃໝ່ດ້ວຍວິທີນີ້, ເມື່ອ API ພາຍນອກ ຫຼື ເຄື່ອງມືຕ່າງໆຂັດຂ້ອງ ຈະສາມາດປ້ອງກັນສະຖານະການທີ່ເສຍເວລາ ແລະ ຄ່າໃຊ້ຈ່າຍໄປກັບການພະຍາຍາມຮຽກໃຊ້ງານຊ້ຳໆ ທັງທີ່ຮູ້ວ່າມັນຈະລົ້ມເຫຼວ. ຖ້າຫາກກຳນົດຂີດຈຳກັດໄວ້ເປັນອັດຕາເຊັ່ນ "ລົ້ມເຫຼວ M ຄັ້ງ ໃນ N ຄັ້ງຫຼ້າສຸດ" ຈະຊ່ວຍຫຼີກລ່ຽງການເປີດວົງຈອນເກີນຄວາມຈຳເປັນຈາກຄວາມຜິດພາດທີ່ເກີດຂຶ້ນພຽງຄັ້ງດຽວໃນຄວາມຖີ່ຕ່ຳໄດ້.
ການຢຸດໂດຍອີງໃສ່ Timeout: ການຈຳກັດໃນລະດັບ Step ແລະ Session
ອັນທີສາມແມ່ນອີງຕາມເວລາ. ເປັນການກວດຈັບກໍລະນີທີ່ຕົ້ນທຶນ ແລະ ຂໍ້ຜິດພາດຍັງຢູ່ໃນຂອບເຂດທີ່ກຳນົດໄວ້ ແຕ່ເກີດການຕິດຂັດຂອງລະບົບທັງໝົດເນື່ອງຈາກການລໍຖ້າການຕອບສະໜອງຈາກພາຍນອກ ຫຼື ເຄື່ອງມືຄ້າງ. ການກຳນົດເວລາ (Timeout) ຈະຖືກຈັດການເປັນລຳດັບຊັ້ນ.
ໃນລະດັບຂັ້ນຕອນ (Step), ຈະມີການກຳນົດເວລາສູງສຸດສຳລັບການຮຽກໃຊ້ LLM ແຕ່ລະຄັ້ງ ຫຼື ການປະຕິບັດງານຂອງເຄື່ອງມື ຖ້າເກີນເວລາທີ່ກຳນົດໄວ້ ຈະມີການຕັດການເຮັດວຽກນັ້ນ ແລະ ປ່ຽນໄປສູ່ການລອງໃໝ່ (Retry) ຫຼື ການສຳຮອງ (Fallback). ໃນລະດັບເຊສຊັນ (Session), ຈະມີການກຳນົດເວລາສູງສຸດສຳລັບໄລຍະເວລາລວມຂອງໜຶ່ງວຽກງານ ຖ້າເກີນກຳນົດ ຈະມີການຢຸດການເຮັດວຽກຢ່າງປອດໄພເຖິງແມ່ນວ່າວຽກງານນັ້ນຈະຍັງບໍ່ທັນສຳເລັດກໍຕາມ. ຖ້າບໍ່ໃຊ້ທັງສອງວິທີນີ້ຮ່ວມກັນ, ອາດຈະເຮັດໃຫ້ເກີດກໍລະນີ "ແຕ່ລະຂັ້ນຕອນໄວ ແຕ່ເກີດການວົນລູບທີ່ບໍ່ມີວັນຈົບ" ຫຼື "ຂັ້ນຕອນດຽວຄ້າງຈົນເຮັດໃຫ້ລະບົບທັງໝົດຢຸດຊະງັກ" ໂດຍທີ່ກວດບໍ່ພົບ.
ໃນດ້ານການປະຕິບັດງານ, ຕ້ອງນຳໄປໃຊ້ຮ່ວມກັບກົນໄກການຍົກເລີກການປະມວນຜົນແບບບໍ່ພ້ອມກັນ (Asynchronous) (ເຊັ່ນ: await ທີ່ມີການກຳນົດ Timeout, ຫຼື Cancellation Token) ເພື່ອໃຫ້ແນ່ໃຈວ່າຊັບພະຍາກອນຕ່າງໆ (ການເຊື່ອມຕໍ່, ໄຟລ໌ຊົ່ວຄາວ, ການລັອກ) ຈະຖືກປົດປ່ອຍຢ່າງແນ່ນອນເມື່ອມີການຢຸດການເຮັດວຽກ. ຖ້າການຢຸດການເຮັດວຽກບໍ່ສົມບູນ, ມັນຈະກາຍເປັນ "Zombie Task" ທີ່ຍັງຄົງປະມວນຜົນຢູ່ເບື້ອງຫຼັງທັງທີ່ຄິດວ່າໄດ້ຢຸດໄປແລ້ວ.
ຂັ້ນຕອນທີ 3: ຈະນຳໃຊ້ Kill Switch ແລະ ຂະບວນການ ຫຼື Pipeline ສຳຮອງແນວໃດ?
ຫຼັງຈາກທີ່ Trigger ເຮັດວຽກແລ້ວ, ຂັ້ນຕອນນີ້ແມ່ນການອອກແບບວິທີການຢຸດ ແລະ ສິ່ງທີ່ຈະສົ່ງກັບຄືນຫຼັງຈາກຢຸດ. ວິທີການຢຸດມີຄວາມແຕກຕ່າງກັນທາງດ້ານລະດັບຄວາມຮຸນແຮງ, ເຊິ່ງຕ້ອງເລືອກໃຊ້ໃຫ້ເໝາະສົມກັບຜົນກະທົບຕໍ່ການດຳເນີນງານ. ນອກຈາກນີ້, ຍັງຕ້ອງເພີ່ມຄວາມປອດໄພຫຼາຍຊັ້ນໂດຍການນຳໃຊ້ Guardrails ແລະ ການແຍກ Multi-agent ເຂົ້າຮ່ວມນຳ. ຕໍ່ໄປຈະເປັນການເບິ່ງຈຸດສຳຄັນໃນການຈັດຕັ້ງປະຕິບັດ.
ການເລືອກໃຊ້ລະຫວ່າງ Hard Stop ແລະ Soft Stop
ການຢຸດມີສອງປະເພດ. Hard Stop ແມ່ນສະວິດຕັດການທຳງານທີ່ຕັດຂະບວນການ ຫຼື Pipeline ທັນທີ. ໃຊ້ໃນກໍລະນີທີ່ການດຳເນີນຕໍ່ມີຄວາມສ່ຽງ ເຊັ່ນ: ຄ່າໃຊ້ຈ່າຍທີ່ຄວບຄຸມບໍ່ໄດ້ ຫຼື ການລະເມີດຄວາມປອດໄພທີ່ຊັດເຈນ. Soft Stop ແມ່ນວິທີທີ່ໃຫ້ສຳເລັດຂັ້ນຕອນປັດຈຸບັນກ່ອນ ແລ້ວຈຶ່ງຢຸດຢູ່ຈຸດທີ່ປອດໄພ ຫຼື ລົດຟັງຊັນລົງແລ້ວດຳເນີນຕໍ່. ເໝາະສຳລັບກໍລະນີທີ່ຕ້ອງການຮັກສາປະສົບການຂອງຜູ້ໃຊ້.
| ສະຖານະການ | ຄຳແນະນຳ | ພຶດຕິກຳຫຼັງຢຸດ |
|---|---|---|
| ເກີນຂີດຈຳກັດຄ່າໃຊ້ຈ່າຍ | Hard | ຢຸດ ແລ້ວສົ່ງຜົນລັດທີ່ໄດ້ຮັບ ພ້ອມເຫດຜົນ |
| API ພາຍນອກລົ້ມເຫຼວຕໍ່ເນື່ອງ | Soft | ລົດລະດັບໄປໃຊ້ Model ລາຄາຖືກ ຫຼື ຕອບຈາກ Cache |
| ກວດພົບ Injection | Hard | ແຍກ ແລ້ວຕັດ Session ນັ້ນ |
| Latency ເກີນກຳນົດ | Soft | ສົ່ງຜົນລັດບາງສ່ວນ ແລ້ວດຳເນີນຕໍ່ແບບ Async |
Kill Switch ຄວນກຽມໄວ້ທັງແບບ Global ທີ່ມີຜົນຕໍ່ Agent ທຸກຕົວ ແລະ Tenant ທຸກລາຍພ້ອມກັນ ແລະແບບ Scoped ທີ່ຈຳກັດສະເພາະ Task ຫຼື User ໃດໜຶ່ງ ເພື່ອໃຫ້ສາມາດຈຳກັດຄວາມເສຍຫາຍໃຫ້ຢູ່ໃນຂອບເຂດທີ່ນ້ອຍທີ່ສຸດເມື່ອເກີດຄວາມຜິດພາດ. ທຸກຄັ້ງທີ່ຢຸດ ຕ້ອງສ້າງທັງຂໍ້ຄວາມທີ່ສົ່ງຄືນໃຫ້ຜູ້ໃຊ້ ແລະ Log ພາຍໃນລະບົບ.
ການເຊື່ອມໂຍງກັບ AI Guardrails: ການຕັດການເຊື່ອມຕໍ່ລ່ວງໜ້າດ້ວຍ Prompt Firewall
ໃນຂະນະທີ່ Circuit Breaker ເປັນກົນໄກຫຼັງເກີດເຫດທີ່ໃຊ້ເພື່ອ "ຢຸດຂະບວນການທີ່ກຳລັງເຮັດວຽກຢູ່", Guardrail ເປັນກົນໄກກ່ອນເກີດເຫດທີ່ໃຊ້ເພື່ອ "ສະກັດກັ້ນການປ້ອນຂໍ້ມູນ ຫຼື ການສະແດງຜົນທີ່ອັນຕະລາຍ". ເນື່ອງຈາກທັງສອງມີຊັ້ນໃນການຢຸດທີ່ແຕກຕ່າງກັນ ຈຶ່ງຄວນນຳມາປະສົມປະສານກັນເພື່ອສ້າງເປັນການປ້ອງກັນຫຼາຍຊັ້ນ (Multi-layer defense).
ຢູ່ຝັ່ງການປ້ອນຂໍ້ມູນ (Input), ຈະໃຊ້ Prompt Firewall ເພື່ອກວດຫາການ Injection ຫຼື ຫົວຂໍ້ທີ່ຖືກຫ້າມ ແລະ ສະກັດກັ້ນກ່ອນທີ່ຈະສົ່ງຂໍ້ມູນຕໍ່ໃຫ້ Agent. ສ່ວນຝັ່ງການສະແດງຜົນ (Output), ຈະຜ່ານການກັ່ນຕອງຂໍ້ມູນສ່ວນຕົວ, ຂໍ້ມູນການຢືນຢັນຕົວຕົນ ແລະ ຂໍ້ຄວາມທີ່ເປັນອັນຕະລາຍ ກ່ອນທີ່ຈະສົ່ງຂໍ້ມູນຕໍ່ໃຫ້ພາກສ່ວນຖັດໄປ. ເຫດການທີ່ຖືກສະກັດກັ້ນໃນຂັ້ນຕອນນີ້ ຈະຖືກນຳໄປສະທ້ອນໃນຕົວນັບ (Counter) ຂອງ Breaker ເປັນສັນຍານຄວາມຜິດປົກກະຕິທີ່ເກັບມາຈາກຂັ້ນຕອນກ່ອນໜ້າ ເພື່ອໃຫ້ເກີດການເຮັດວຽກຮ່ວມກັນ ເຊັ່ນ: "ການຕັດການເຊື່ອມຕໍ່ທັງໝົດຂອງ Session ທີ່ຖືກ Guardrail ສະກັດກັ້ນຊ້ຳໆ".
ພາບລວມຂອງການອອກແບບ ແລະ ການຈັດຕັ້ງປະຕິບັດ Guardrail ໄດ້ສະຫຼຸບໄວ້ໃນ AI Guardrail Implementation Guide. ກົນໄກການຢຸດການເຮັດວຽກໃນບົດຄວາມນີ້ ຄວນຖືກຈັດວາງໃຫ້ເປັນຕາໜ່າງນິລະໄພຊັ້ນສຸດທ້າຍ ເພື່ອຮັບມືກັບ "ການເຮັດວຽກທີ່ຄວບຄຸມບໍ່ໄດ້ໃນຂະນະປະມວນຜົນ" ທີ່ຫຼຸດລອດຈາກ Guardrail ອອກມາ.
ການອອກແບບການຢຸດບາງສ່ວນ ແລະ ການແຍກສ່ວນໃນລະບົບ Multi-agent
ໃນລະບົບທີ່ຫຼາຍ Agent ເຮັດວຽກຮ່ວມກັນ, ຄວາມລະອຽດຂອງການຢຸດເຮັດວຽກ (Granularity of failure) ແມ່ນມີຄວາມສຳຄັນ. ຖ້າຫາກວ່າ Sub-agent ພຽງຕົວດຽວເກີດການເຮັດວຽກຜິດພາດແລ້ວເຮັດໃຫ້ລະບົບທັງໝົດຢຸດເຮັດວຽກ, ມັນຈະສົ່ງຜົນກະທົບຢ່າງຮ້າຍແຮງຕໍ່ຄວາມພ້ອມໃຊ້ງານ (Availability).
ພື້ນຖານຂອງການອອກແບບແມ່ນ ການແຍກສ່ວນ (Bulkhead). ໂດຍການຈັດສັນງົບປະມານ, ເບຣກເກີ (Breaker), ແລະສະພາບແວດລ້ອມການປະມວນຜົນ (Execution context) ໃຫ້ແກ່ Sub-agent ແຕ່ລະຕົວຢ່າງເປັນອິດສະຫຼະ ເພື່ອໃຫ້ແນ່ໃຈວ່າເຖິງແມ່ນວ່າຕົວໜຶ່ງຈະຢຸດເຮັດວຽກ ແຕ່ຕົວອື່ນໆກໍຍັງສາມາດເຮັດວຽກຕໍ່ໄປໄດ້. Orchestrator ຈະເຮັດໜ້າທີ່ຕັດແຍກໜ້າວຽກຂອງ Node ທີ່ຢຸດເຮັດວຽກອອກ, ຈາກນັ້ນກໍທຳການປ່ຽນເສັ້ນທາງ (Re-routing) ໄປຍັງເສັ້ນທາງສຳຮອງ ຫຼື ສົ່ງຂໍ້ມູນຕໍ່ໃຫ້ມະນຸດເພື່ອດຳເນີນການຕໍ່.
1[Orchestrator]
2 ├─ Agent A (breaker: closed) → ສືບຕໍ່ເຮັດວຽກ
3 ├─ Agent B (breaker: open) → ແຍກສ່ວນ ແລະ ຈັດສັນໃໝ່
4 └─ Agent C (breaker: closed) → ສືບຕໍ່ເຮັດວຽກຖ້າຫາກວ່າ Agent ຕ່າງໆມີການໃຊ້ເຄື່ອງມື ຫຼື ສະຖານະ (State) ຮ່ວມກັນ, ການເຮັດວຽກຜິດພາດຂອງຕົວໜຶ່ງອາດຈະສົ່ງຜົນກະທົບຕໍ່ເນື່ອງໄປຫາສ່ວນອື່ນໆທັງໝົດ. ດັ່ງນັ້ນ, ຄວນກຳນົດຂີດຈຳກັດສະເພາະ ແລະ ການຄວບຄຸມການເຂົ້າເຖິງສຳລັບຊັບພະຍາກອນທີ່ໃຊ້ຮ່ວມກັນ. ສຳລັບລາຍລະອຽດເພີ່ມເຕີມກ່ຽວກັບການອອກແບບການເຮັດວຽກຮ່ວມກັນ, ກະລຸນາເບິ່ງທີ່ Multi-agent AI. ໂຄງສ້າງທີ່ສາມາດຮອງຮັບການຢຸດເຮັດວຽກບາງສ່ວນໄດ້ນັ້ນ ຈະຖືກຕັດສິນໃຈຕັ້ງແຕ່ຂັ້ນຕອນການເລືອກໂຄງສ້າງພື້ນຖານ ຫຼື Infrastructure ໃນຕອນເລີ່ມຕົ້ນ.
ຂໍ້ຜິດພາດທົ່ວໄປໃນການນຳໃຊ້ ແລະ ວິທີຫຼີກລ່ຽງ?
ການຢຸດເຮັດວຽກສຸກເສີນ (Emergency stop) ບໍ່ແມ່ນ "ຕິດຕັ້ງແລ້ວຈົບ". ຖ້າກຳນົດຄ່າ Threshold ຫຼື ການອອກແບບການດຳເນີນງານຜິດພາດ ອາດຈະສົ່ງຜົນໃຫ້ການເຮັດວຽກປົກກະຕິຢຸດສະງັກ ຫຼື ບໍ່ສາມາດໃຊ້ງານໄດ້ໃນເວລາທີ່ຈຳເປັນ. ຂໍຍົກຕົວຢ່າງສອງຄວາມຜິດພາດທີ່ພົບເຫັນເລື້ອຍໆໃນໜ້າວຽກຕົວຈິງ ແລະ ວິທີການຫຼີກລ່ຽງ.
ກໍລະນີທີ່ຕັ້ງຂີດຈຳກັດສູງເກີນໄປຈົນເຮັດໃຫ້ Task ປົກກະຕິຖືກຢຸດ
ຄວາມຜິດພາດທີ່ພົບເຫັນຫຼາຍທີ່ສຸດ ຄືຮູບແບບທີ່ຕັ້ງຄ່າຄວາມປອດໄພໄວ້ສູງເກີນໄປ ຈົນເຮັດໃຫ້ເກີດການຕັດການເຮັດວຽກທີ່ຜິດພາດ (False Positive) ເລື້ອຍໆ. ຜົນຈາກການຕັ້ງຄ່າຂີດຈຳກັດຂອງ Token ໄວ້ທີ່ຄ່າສະເລ່ຍພໍດີ ເຮັດໃຫ້ວຽກງານທີ່ປົກກະຕິແຕ່ມີຄວາມໜັກໜ່ວງເລັກນ້ອຍຖືກຢຸດສະງັກໄປໝົດ, ເຊິ່ງໃນມຸມມອງຂອງຜູ້ໃຊ້ຈະເຫັນວ່າເປັນ "ຟັງຊັນທີ່ຢຸດເຮັດວຽກເລື້ອຍໆ ແລະ ໃຊ້ງານບໍ່ໄດ້".
ວິທີແກ້ໄຂມີ 3 ປະການ: ປະການທຳອິດ, ການກຳນົດຄ່າ Threshold ຄວນອີງຕາມການກະຈາຍຂອງ Metrics ໃນການໃຊ້ງານຈິງ ໂດຍບໍ່ຄວນໃຊ້ p50 ແຕ່ໃຫ້ໃຊ້ p95 ຫຼື p99 ເປັນມາດຕະຖານ ເພື່ອວາງຕຳແໜ່ງໃຫ້ກວມເອົາວຽກງານປົກກະຕິສ່ວນໃຫຍ່. ປະການທີສອງ, ຢ່າໃຊ້ການຢຸດການເຮັດວຽກແບບທັນທີ (Hard stop) ໃນທັນທີ, ແຕ່ໃຫ້ເລີ່ມຈາກການໃຊ້ຂີດຈຳກັດແບບອ່ອນ (Soft limit) ເພື່ອແຈ້ງເຕືອນ ແລະ ຫຼຸດປະສິດທິພາບຂອງ Model ລົງກ່ອນ ເພື່ອໃຫ້ມີຜົນແບບເປັນຂັ້ນຕອນ. ປະການທີສາມ, ໃນເບື້ອງຕົ້ນໃຫ້ເປີດໃຊ້ Breaker ໃນ ໂໝດສັງເກດການ (Shadow mode) ເພື່ອບັນທຶກສະເພາະ Log ວ່າ "ຖ້າຫາກເປີດໃຊ້ງານແລ້ວ ຈະຢຸດວຽກງານໃດ ແລະ ຈັກຄັ້ງ". ການທົດລອງເດີນເຄື່ອງເປົ່າແບບນີ້ເພື່ອເບິ່ງອັດຕາການກວດພົບທີ່ຜິດພາດກ່ອນທີ່ຈະເລີ່ມການຕັດການເຮັດວຽກຈິງ ຈະຊ່ວຍຫຼຸດອຸບັດເຫດຫຼັງຈາກນຳໄປໃຊ້ງານຈິງໄດ້ຢ່າງຫຼວງຫຼາຍ. ຄວນເບິ່ງວ່າຄ່າ Threshold ບໍ່ແມ່ນຄ່າຄົງທີ່, ແຕ່ເປັນສິ່ງທີ່ຕ້ອງປັບປ່ຽນຢ່າງຕໍ່ເນື່ອງໃນລະຫວ່າງການດຳເນີນງານ.
Anti-pattern ທີ່ບໍ່ມີບັນທຶກ Log ການຢຸດເຮັດໃຫ້ບໍ່ສາມາດກວດສອບສາເຫດໄດ້
ອີກຮູບແບບໜຶ່ງທີ່ພົບເຫັນເລື້ອຍໆ ຄືການທີ່ມົວແຕ່ສົນໃຈກັບການຢຸດການເຮັດວຽກ ແຕ່ບໍ່ໄດ້ບັນທຶກ "ສາເຫດທີ່ຢຸດ" ເອົາໄວ້. ເຖິງຈະຢຸດແລ້ວແຕ່ບໍ່ມີ Log, ເມື່ອຜູ້ໃຊ້ລາຍງານວ່າ "ຢຸດກາງຄັນ" ກໍບໍ່ສາມາດຕິດຕາມໄດ້ວ່າ Trigger ໃດທີ່ເຮັດວຽກດ້ວຍຄ່າໃດ. ແບບນີ້ຈະບໍ່ສາມາດປັບປ່ຽນ Threshold ຫຼື ປ້ອງກັນການເກີດຊ້ຳໄດ້ເລີຍ.
ສຳລັບເຫດການຢຸດການເຮັດວຽກ ຄວນບັນທຶກເປັນ Structured Log ຢ່າງໜ້ອຍດັ່ງນີ້: (1) ປະເພດຂອງ Trigger (Cost / Error rate / Timeout / Guardrail), (2) ຄ່າທີ່ວັດແທກໄດ້ຈິງໃນຂະນະທີ່ເຮັດວຽກ ແລະ ຄ່າ Threshold, (3) Task, User, Trace ID ທີ່ກ່ຽວຂ້ອງ, (4) ປະເພດການຢຸດ (Hard / Soft) ແລະ ພຶດຕິກຳຫຼັງຈາກນັ້ນ, (5) Timestamp. ຖ້າມີຂໍ້ມູນເຫຼົ່ານີ້ຄົບຖ້ວນ ກໍຈະສາມາດກວດສອບຄວາມສົມເຫດສົມຜົນຂອງການຢຸດການເຮັດວຽກໄດ້ໃນພາຍຫຼັງ ແລະ ສາມາດປັບປ່ຽນ Threshold ໂດຍມີຫຼັກຖານອ້າງອີງໄດ້.
ນອກຈາກນີ້, ຄວນຕິດຕາມອັດຕາການເກີດການຢຸດ ແລະ ອັດຕາການຕັດການເຮັດວຽກທີ່ຜິດພາດຜ່ານ Dashboard ຢ່າງຕໍ່ເນື່ອງ ແລະ ແຈ້ງເຕືອນເມື່ອມີການເພີ່ມທະວີຂຶ້ນເລື້ອຍໆ. ມຸມມອງທີ່ວ່າກົນໄກການຢຸດການເຮັດວຽກເອງກໍເປັນເປົ້າໝາຍໃນການຕິດຕາມນັ້ນ ຍັງເຊື່ອມໂຍງໄປເຖິງການສ້າງຫຼັກຖານຂອງ "ການແຊກແຊງໂດຍມະນຸດທີ່ສາມາດອະທິບາຍໄດ້" ເຊິ່ງ EU AI Act ໄດ້ກຳນົດໄວ້. Log ການຢຸດການເຮັດວຽກຈະກາຍເປັນຂໍ້ມູນຂັ້ນຕົ້ນສຳລັບການໝູນວຽນວົງຈອນການປັບປຸງທັງໃນດ້ານ Cost ແລະ Incident.
ສະຫຼຸບ — ການອອກແບບລະບົບຢຸດສຸກເສີນຕ້ອງລວມເຂົ້າຕັ້ງແຕ່ "ຂັ້ນຕອນການອອກແບບ"
ວົງຈອນຕັດໄຟ (Circuit Breaker) ຂອງ AI Agent ຈະເຮັດວຽກໄດ້ກໍຕໍ່ເມື່ອມີການລວມເອົາຂະບວນການ "ການວັດແທກ → ການຕັດສິນ → ການຕັດການເຮັດວຽກ → ການບັນທຶກ" ເຂົ້າໄປໃນຂັ້ນຕອນການອອກແບບຕັ້ງແຕ່ຕົ້ນ ບໍ່ແມ່ນການເພີ່ມຟັງຊັນເຂົ້າມາພາຍຫຼັງການນຳໃຊ້. ສະຫຼຸບຂັ້ນຕອນໃນບົດຄວາມນີ້ມີດັ່ງນີ້:
- ການກຳນົດເງື່ອນໄຂເບື້ອງຕົ້ນ: ກຳນົດໂຄງສ້າງພື້ນຖານ ຫຼື Infrastructure ດ້ານການສັງເກດການ (Observability), ລະດັບການແຊກແຊງ ແລະ ຕົວຊີ້ວັດຂີດຈຳກັດໄວ້ລ່ວງໜ້າ.
- ຊັ້ນການຕິດຕາມກວດກາ: ວັດແທກສາມລະບົບຄື: ປະລິມານການບໍລິໂພກ, ຄວາມຄືບໜ້າ ແລະ ສັນຍານຄວາມຜິດປົກກະຕິ ຜ່ານຊັ້ນ Wrapper.
- ຕົວກະຕຸ້ນ (Trigger): ຕັດສິນໃຈແບບຫຼາຍຊັ້ນໂດຍອີງໃສ່ສາມລະບົບຄື: ຕົ້ນທຶນ, ອັດຕາຄວາມຜິດພາດ ແລະ ເວລາໝົດກຳນົດ (Timeout).
- ສະວິດປິດການເຮັດວຽກ (Kill Switch): ນຳໃຊ້ຮາດແວ/ຊອບແວໃຫ້ເໝາະສົມ, ພ້ອມທັງສ້າງລະບົບປ້ອງກັນ (Guardrail) ແລະ ການແຍກ Multi-agent ໃຫ້ເປັນຫຼາຍຊັ້ນ.
- ການດຳເນີນງານ: ໃຊ້ Shadow mode ເພື່ອກວດສອບການວິເຄາະທີ່ຜິດພາດ ແລະ ປັບປ່ຽນຂີດຈຳກັດຢ່າງຕໍ່ເນື່ອງຈາກບັນທຶກການຢຸດເຮັດວຽກ.
ກົນໄກການຢຸດການເຮັດວຽກນີ້ ເປັນການລົງທຶນທີ່ຊ່ວຍສະໜັບສະໜູນສາມດ້ານພ້ອມກັນ ຄື: ການຄວບຄຸມຕົ້ນທຶນທີ່ເກີດຈາກການເຮັດວຽກທີ່ຜິດປົກກະຕິ, ການສະກັດກັ້ນອຸບັດຕິເຫດດ້ານຄວາມປອດໄພ ແລະ ການປະຕິບັດຕາມກົດລະບຽບ. ບໍລິສັດຂອງພວກເຮົາແນະນຳໃຫ້ລວມເອົາການອອກແບບການຢຸດການເຮັດວຽກນີ້ ເປັນຂໍ້ກຳນົດທີ່ຈຳເປັນໃນສະຖາປັດຕະຍະກຳເບື້ອງຕົ້ນ ເມື່ອໃຫ້ການສະໜັບສະໜູນການນຳ AI Agent ໄປໃຊ້ງານຈິງ. ຫາກທ່ານຕ້ອງການປຶກສາຫາລືກ່ຽວກັບການນຳໃຊ້ Agent ຫຼື ການເຮັດໃຫ້ການອອກແບບລະບົບຢຸດການເຮັດວຽກສຸກເສີນມີຄວາມຊັດເຈນຍິ່ງຂຶ້ນ, ກະລຸນາຕິດຕໍ່ຫາພວກເຮົາ.
Author & Supervisor
Yusuke Ishihara
ເລີ່ມຂຽນໂປຣແກຣມຕັ້ງແຕ່ອາຍຸ 13 ປີ ດ້ວຍ MSX. ຫຼັງຈົບການສຶກສາຈາກມະຫາວິທະຍາໄລ Musashi, ໄດ້ເຮັດວຽກໃນການພັດທະນາລະບົບຂະໜາດໃຫຍ່ ລວມທັງລະບົບຫຼັກຂອງສາຍການບິນ ແລະ ໂຄງສ້າງ Windows Server Hosting/VPS ທຳອິດຂອງຍີ່ປຸ່ນ. ຮ່ວມກໍ່ຕັ້ງ Site Engine Inc. ໃນປີ 2008. ກໍ່ຕັ້ງ Unimon Inc. ໃນປີ 2010 ແລະ Enison Inc. ໃນປີ 2025, ນຳພາການພັດທະນາລະບົບທຸລະກິດ, NLP ແລະ ແພລດຟອມ. ປັດຈຸບັນສຸມໃສ່ການພັດທະນາຜະลິດຕະພັນ ແລະ ການສົ່ງເສີມ AI/DX ໂດຍນຳໃຊ້ generative AI ແລະ LLM.
Recommended Articles
