AgentOps ຂອງການປະຕິບັດທີ່ດີທີ່ສຸດ (Best Practices) ໝາຍເຖິງຮູບແບບການດຳເນີນງານທີ່ໝູນວຽນຢ່າງຕໍ່ເນື່ອງໃນການສັງເກດການ (Monitoring), ການປະເມີນຜົນ, ແລະ ການປັບປຸງ ເພື່ອໃຫ້ AI Agent ສາມາດເຮັດວຽກໄດ້ຢ່າງໝັ້ນຄົງໃນສະພາບແວດລ້ອມການຜະລິດ, ລວມເຖິງຈຸດສຳຄັນໃນການປະຕິບັດຕົວຈິງ.

ບົດຄວາມນີ້ອະທິບາຍເຖິງ "ແບບຈຳລອງອ້າງອີງ" ເພື່ອສ້າງຄວາມໝັ້ນຄົງໃນການດຳເນີນງານ, ຮອບວຽນການປັບປຸງປະຈຳວັນ, ແລະ ການປະຕິບັດທີ່ດີທີ່ສຸດຢ່າງເປັນຮູບປະທຳ ໂດຍເນັ້ນໃສ່ທັດສະນະການປະຕິບັດງານສຳລັບຜູ້ຮັບຜິດຊອບດ້ານການສົ່ງເສີມ DX ແລະ ຜູ້ຮັບຜິດຊອບການດຳເນີນງານ AI ທີ່ກຳລັງຈະນຳ AI Agent ເຂົ້າສູ່ການດຳເນີນງານຈິງ. ເນື່ອງຈາກຄຳນິຍາມຂອງ AgentOps, ພາບລວມ, ແລະ ການອອກແບບອົງກອນການດຳເນີນງານ ໄດ້ຖືກກ່າວເຖິງໃນ AgentOps ແມ່ນຫຍັງ — ຄູ່ມືການອອກແບບອົງກອນການດຳເນີນງານ AI Agent ແລ້ວ, ບົດຄວາມນີ້ຈຶ່ງຈະເນັ້ນໃສ່ "ວິທີການດຳເນີນງານ" ພຽງຢ່າງດຽວ. ເມື່ອອ່ານຈົບ, ທ່ານຈະສາມາດເຫັນເສັ້ນທາງໃນການລວມເອົາກົນໄກການສັງເກດການ, ການປະເມີນຜົນ, ແລະ ການປັບປຸງ ເຂົ້າໃນການດຳເນີນງານ Agent ຂອງບໍລິສັດທ່ານ ເພື່ອຍົກລະດັບຄຸນນະພາບໄປພ້ອມກັບການຫຼີກລ່ຽງຄວາມຜິດພາດ.

ຈຸດສຳຄັນ ຫຼື ແກນຫຼັກ ຂອງການດຳເນີນງານ AgentOps ແມ່ນວົງຈອນການເຮັດວຽກທີ່ໝູນວຽນຢ່າງຕໍ່ເນື່ອງ ໂດຍເລີ່ມຈາກການສັງເກດການ → ການປະເມີນຜົນ → ການປັບປຸງ. ການສັງເກດຜົນລວມ, ການປະເມີນຄວາມດີ-ຄວາມບໍ່ດີ, ແລະ ການນຳຜົນທີ່ໄດ້ກັບຄືນໄປປັບປຸງການຕັ້ງຄ່າ ແລະ ການດຳເນີນງານ — ການມີວົງຈອນນີ້ເປັນກົນໄກ ແມ່ນເງື່ອນໄຂເບື້ອງຕົ້ນສຳລັບການດຳເນີນງານທີ່ໝັ້ນຄົງ.

AI ເອເຈນ (AI Agent) ມັກຈະເຮັດໃຫ້ "ສິ່ງທີ່ປ້ອນເຂົ້າ, ເຄື່ອງມືທີ່ຖືກເອີ້ນ, ການຕັດສິນໃຈໃນຂັ້ນຕອນກາງ, ແລະ ສິ່ງທີ່ຖືກສົ່ງອອກ" ເບິ່ງເຫັນໄດ້ຍາກຈາກພາຍນອກ. ດັ່ງນັ້ນ, ກ້າວທຳອິດຂອງການສັງເກດການ (Observability) ຄືການບັນທຶກຂະບວນການເຫຼົ່ານີ້ເພື່ອໃຫ້ສາມາດຕິດຕາມຍ້ອນຫຼັງໄດ້. ສິ່ງທີ່ຄວນມີຢ່າງໜ້ອຍ 4 ຢ່າງຄື: (1) ຂໍ້ຄວາມປ້ອນເຂົ້າ (Prompt) ແລະ ຜົນລັດສຸດທ້າຍ, (2) ເຄື່ອງມື ຫຼື API ທີ່ຖືກເອີ້ນ ແລະ ຜົນລັດຂອງມັນ, (3) ໄລຍະເວລາທີ່ໃຊ້ໃນແຕ່ລະຂັ້ນຕອນ ແລະ ການໃຊ້ງານ Token, ແລະ (4) ຈຸດທີ່ເກີດຂໍ້ຜິດພາດ ຫຼື ການຢຸດສະງັກ.

ສິ່ງທີ່ເປັນເອກະລັກສະເພາະຂອງເອເຈນໂດຍສະເພາະແມ່ນ "Trace" ເຊິ່ງເປັນການບັນທຶກທີ່ສາມາດຕິດຕາມຮູບແບບການເຮັດວຽກທີ່ແຕກແຍກອອກເປັນຫຼາຍຂັ້ນຕອນຂອງຄຳຮ້ອງຂໍດຽວໃນຮູບແບບຕົ້ນໄມ້. ຖ້າເບິ່ງພຽງແຕ່ Log ຂອງການປ້ອນເຂົ້າ-ສົ່ງອອກແບບຄັ້ງດຽວ ຈະບໍ່ສາມາດຮູ້ໄດ້ວ່າຂັ້ນຕອນໃດທີ່ຕັດສິນໃຈຜິດພາດ. ຖ້າມີ Trace ຈະເຮັດໃຫ້ສາມາດລະບຸສາເຫດໄດ້ ເຊັ່ນ: "ສົ່ງ Argument ຜິດໃນການເອີ້ນໃຊ້ເຄື່ອງມືຄັ້ງທີ 3".

ຂໍ້ຄວນລະວັງໃນທາງປະຕິບັດເມື່ອເລີ່ມຕົ້ນການສັງເກດການມີດັ່ງນີ້: ເນື່ອງຈາກ Log ມັກຈະມີຂໍ້ມູນສ່ວນຕົວ ຫຼື ຂໍ້ມູນລັບ, ຄວນກຽມກົນໄກໃນການປິດບັງຂໍ້ມູນ (Masking) ກ່ອນການບັນທຶກໄວ້. ຖ້າການບັນທຶກທຸກ Request ຢ່າງຄົບຖ້ວນເຮັດໃຫ້ມີຕົ້ນທຶນສູງ, ຄວນກຳນົດຄວາມລະອຽດໂດຍການບັນທຶກທັງໝົດໃນກໍລະນີທີ່ເກີດຂໍ້ຜິດພາດ ຫຼື ຄະແນນຕ່ຳ, ແລະ ໃຊ້ວິທີການສຸ່ມ (Sampling) ໃນກໍລະນີທີ່ເຮັດວຽກປົກກະຕິ. ການບັນທຶກສາມາດເລີ່ມຕົ້ນໄດ້ທັງການໃຊ້ເຄື່ອງມື Observability ໂດຍສະເພາະ ຫຼື ເລີ່ມຈາກການເກັບ Structured Log ໄວ້ໃນຖານຂໍ້ມູນກ່ອນກໍໄດ້. ສິ່ງທີ່ສຳຄັນບໍ່ແມ່ນຄວາມຫຼູຫຼາຂອງເຄື່ອງມື, ແຕ່ແມ່ນການສ້າງສະຖານະທີ່ "ສາມາດຕິດຕາມ ແລະ ຈຳລອງເຫດການຄືນໃໝ່ໄດ້". ການດຳເນີນງານໂດຍບໍ່ມີການສັງເກດການ ກໍປຽບເໝືອນການເດີນເຮືອໂດຍບໍ່ມີເຄື່ອງວັດແທກ.

ການປະເມີນຜົນຄືການປ່ຽນຂໍ້ມູນທີ່ເກັບກຳມາຈາກການສັງເກດໃຫ້ກາຍເປັນ "ຄວາມດີ ຫຼື ຄວາມບໍ່ດີ". ການປະເມີນຜົນມີ 2 ປະເພດ: ການປະເມີນຜົນແບບ Offline ແມ່ນວິທີການກວດສອບລ່ວງໜ້າວ່າ Agent ຈະປະຕິບັດງານໄດ້ຢ່າງຖືກຕ້ອງຫຼືບໍ່ ໂດຍການໃຫ້ Agent ເຮັດວຽກກັບຊຸດຂໍ້ມູນນຳເຂົ້າ ແລະ ຜົນລັພທີ່ຄາດຫວັງໄວ້ລ່ວງໜ້າ (Evaluation Dataset) ເຊິ່ງໃຊ້ເປັນປະຕູກວດສອບຄຸນນະພາບກ່ອນການເປີດຕົວ ຫຼື Launch. ສ່ວນການປະເມີນຜົນແບບ Online ແມ່ນວິທີການວັດແທກຄຸນນະພາບຢ່າງຕໍ່ເນື່ອງ ໂດຍອີງໃສ່ຂໍ້ມູນນຳເຂົ້າ ແລະ ສົ່ງອອກທີ່ເກີດຂຶ້ນຈິງໃນລະບົບການເຮັດວຽກຕົວຈິງ.

ທັງສອງຢ່າງມີບົດບາດທີ່ແຕກຕ່າງກັນ. Offline ໃຊ້ເພື່ອຢືນຢັນວ່າ "ລະບົບບໍ່ໄດ້ພັງ" ກ່ອນທີ່ຈະເປີດຕົວ, ສ່ວນ Online ໃຊ້ເພື່ອຕິດຕາມກວດກາຫຼັງຈາກເປີດຕົວວ່າ "ຜົນລັພເປັນໄປຕາມທີ່ຄາດຫວັງກັບຂໍ້ມູນນຳເຂົ້າຕົວຈິງຫຼືບໍ່". ສຳລັບຕົວຊີ້ວັດ, ຖ້າເປັນວຽກທີ່ສາມາດກຳນົດຄຳຕອບທີ່ຖືກຕ້ອງໄດ້ດ້ວຍກົນໄກ (ເຊັ່ນ: ການຈັດໝວດໝູ່, ການສະກັດຂໍ້ມູນ, ຫຼື ໂຄ້ດ) ການປະເມີນຜົນແບບອັດຕະໂນມັດຈະມີປະສິດທິພາບ, ແຕ່ສຳລັບວຽກທີ່ບໍ່ມີຄຳຕອບທີ່ຊັດເຈນເຊັ່ນ: ການສະຫຼຸບຄວາມ ຫຼື ການສົນທະນາ, ຄວນໃຊ້ການປະເມີນຜົນໂດຍມະນຸດໂດຍອີງໃສ່ເກນການໃຫ້ຄະແນນ (Rubric) ຫຼື ໃຊ້ວິທີການໃຫ້ Model ອື່ນເປັນຜູ້ໃຫ້ຄະແນນຮ່ວມດ້ວຍ.

ສິ່ງທີ່ສຳຄັນໃນການປະເມີນຜົນຄືການກຳນົດເກນມາດຕະຖານ (Threshold) ຂອງການຜ່ານ ຫຼື ບໍ່ຜ່ານ. ຖ້າບໍ່ມີມາດຕະຖານເຊັ່ນ "ຖ້າອັດຕາການຕອບຖືກຕ່ຳກວ່າທີ່ກຳນົດໄວ້ ຈະບໍ່ເປີດຕົວ", ການໄດ້ຄະແນນມາ ກໍບໍ່ສາມາດນຳໄປໃຊ້ໃນການຕັດສິນໃຈໄດ້. ນອກຈາກນີ້, ເນື່ອງຈາກການໃຫ້ມະນຸດກວດສອບຂໍ້ມູນທັງໝົດໃນລະບົບການເຮັດວຽກຕົວຈິງໃນການປະເມີນຜົນແບບ Online ນັ້ນບໍ່ແມ່ນເລື່ອງທີ່ເປັນໄປໄດ້ໃນທາງປະຕິບັດ, ການດຳເນີນງານໂດຍການສຸ່ມຕົວຢ່າງ (Sampling) ຂໍ້ມູນທີ່ມີຄະແນນຕ່ຳ ຫຼື ຂໍ້ມູນທີ່ມີຂໍ້ຜິດພາດມາໃຫ້ມະນຸດກວດສອບກ່ອນ ຈຶ່ງເປັນວິທີທີ່ເໝາະສົມກວ່າ. ການອອກແບບການປະເມີນຜົນຂອງ Agent ຈະມີພື້ນຖານມາຈາກແນວຄິດການປະເມີນຄວາມຖືກຕ້ອງຂອງ LLM ໂດຍສະເພາະ. ສຳລັບລາຍລະອຽດເພີ່ມເຕີມ, ກະລຸນາອ້າງອີງ ກອບການປະເມີນຜົນເພື່ອວັດແທກຄວາມຖືກຕ້ອງຂອງ LLM ທີ່ຮອງຮັບພາສາລາວ ຕື່ມອີກ.

ການນຳເອົາບັນຫາທີ່ພົບເຫັນຈາກການປະເມີນຜົນກັບຄືນສູ່ການດຳເນີນງານ ແມ່ນຂັ້ນຕອນຂອງການປັບປຸງ. ຖ້າບໍ່ສາມາດເຮັດໃຫ້ຂັ້ນຕອນນີ້ເປັນລະບົບໄດ້, ທ່ານຈະຕົກຢູ່ໃນສະພາວະທີ່ "ຮູ້ວ່າບັນຫາແມ່ນຫຍັງ ແຕ່ບໍ່ສາມາດແກ້ໄຂໄດ້". ການນຳຜົນປັບປຸງກັບຄືນໄປໃຊ້ນັ້ນ ຫຼັກໆມີ 4 ດ້ານ ຄື: ການແກ້ໄຂ Prompt, ການເພີ່ມ ຫຼື ແກ້ໄຂເຄື່ອງມື, ການທົບທວນຂັ້ນຕອນການເຮັດວຽກຂອງ Agent (Workflow), ແລະ ການຂະຫຍາຍຊຸດຂໍ້ມູນການປະເມີນຜົນ (Evaluation Dataset) ດ້ວຍຕົນເອງ.

ສິ່ງທີ່ສຳຄັນຄື ຢ່າເຮັດການປັບປຸງແບບສະເພາະໜ້າ. ຕົວຢ່າງຄວາມຜິດພາດທີ່ພົບໃນລະບົບຕົວຈິງ ຈະຕ້ອງຖືກເພີ່ມເຂົ້າໃນຊຸດຂໍ້ມູນການປະເມີນຜົນສະເໝີ. ດ້ວຍວິທີນີ້, ເມື່ອເກີດຄວາມຜິດພາດຊ້ຳຮອມອີກ, ມັນຈະສາມາດກວດພົບໄດ້ໃນການປະເມີນຜົນກ່ອນການປ່ອຍເວີຊັນຕໍ່ໄປ ແລະ ການປັບປຸງກໍຈະສະສົມເພີ່ມຂຶ້ນເລື້ອຍໆ. ໃຫ້ເບິ່ງວ່າ ການສັງເກດການ → ການປະເມີນຜົນ → ການປັບປຸງ ບໍ່ແມ່ນສິ່ງທີ່ເຮັດພຽງຄັ້ງດຽວຈົບ, ແຕ່ເປັນວົງຈອນທີ່ຍິ່ງໝູນວຽນຫຼາຍເທົ່າໃດ ຄວາມແມ່ນຍຳກໍຈະຍິ່ງເພີ່ມທະວີຂຶ້ນເລື້ອຍໆ. ໃນຕອນເລີ່ມຕົ້ນ ອາດຈະເຮັດດ້ວຍມືກໍບໍ່ເປັນຫຍັງ, ແຕ່ເມື່ອການດຳເນີນງານເຕີບໂຕຂຶ້ນ, ການນຳຂະບວນການສົ່ງຂໍ້ມູນຕໍ່ໃຫ້ (Pipeline) ນີ້ເຂົ້າໄປເປັນສ່ວນໜຶ່ງຂອງຂັ້ນຕອນການດຳເນີນງານປະຈຳ ຈະເປັນທາງລັດໄປສູ່ການເຮັດວຽກທີ່ໝັ້ນຄົງ.

ຕົວແທນທີ່ເຮັດວຽກແບບອັດຕະໂນມັດ (Autonomous Agents) ຍັງມີຜົນກະທົບຢ່າງໃຫຍ່ຫຼວງຫາກເກີດການເຮັດວຽກຜິດພາດ. ດັ່ງນັ້ນ, ໃນການຕັດສິນໃຈທີ່ສຳຄັນ ຄວນມີມະນຸດເຂົ້າມາມີສ່ວນຮ່ວມ ແລະ ຕ້ອງມີກົນໄກທີ່ສາມາດແກ້ໄຂບັນຫາໄດ້ຢ່າງວ່ອງໄວຫາກເກີດຂໍ້ຜິດພາດ ເຊິ່ງຄວນຖືກວາງລະບົບໄວ້ໃນການດຳເນີນງານຕັ້ງແຕ່ຕົ້ນ.

Agent ຈະເອີ້ນໃຊ້ເຄື່ອງມືດ້ວຍຕົນເອງ ແລະ ດຳເນີນການທີ່ມີຜົນກະທົບຕໍ່ພາຍນອກ. ດັ່ງນັ້ນ, ຈຶ່ງຈຳເປັນຕ້ອງມີການກຳນົດຂອບເຂດ ຫຼື Guardrails ວ່າ "ສິ່ງໃດທີ່ສາມາດເຮັດໄດ້". ພື້ນຖານທີ່ສຳຄັນຄື ການກັ່ນຕອງຂໍ້ມູນຂາເຂົ້າ ແລະ ຂາອອກ (ການສະກັດກັ້ນເນື້ອຫາທີ່ບໍ່ເໝາະສົມ ຫຼື ຂໍ້ມູນລັບ), ລາຍການອະນຸຍາດ (Allowlist) ສຳລັບການໃຊ້ງານເຄື່ອງມື, ແລະ ການກວດສອບກ່ອນສົ່ງຂໍ້ມູນອອກໄປພາຍນອກ.

ນອກຈາກນີ້, ສຳລັບການຕັດສິນໃຈທີ່ມີຜົນກະທົບສູງ ຄວນນຳເອົາ HITL (Human-in-the-loop) ເຂົ້າມາຮ່ວມນຳ. ແທນທີ່ຈະໃຫ້ລະບົບເຮັດວຽກແບບອັດຕະໂນມັດທັງໝົດ, ການປະຕິບັດງານທີ່ບໍ່ສາມາດຍົກເລີກໄດ້ ເຊັ່ນ: ການເຮັດສັນຍາ, ການໂອນເງິນ, ການລຶບຂໍ້ມູນ, ຫຼື ການເປີດຕົວ ຫຼື Launch ສູ່ສາທາລະນະ ຄວນຖືກອອກແບບໃຫ້ມະນຸດເປັນຜູ້ອະນຸມັດກ່ອນດຳເນີນການ. ການກຳນົດໃຫ້ຊັດເຈນວ່າການປະຕິບັດງານໃດທີ່ມະນຸດຕ້ອງເປັນຜູ້ຄວບຄຸມໃນຂັ້ນຕອນການອອກແບບການດຳເນີນງານນັ້ນຖືເປັນ ຈຸດສຳຄັນ ຫຼື ແກນຫຼັກ.

ພ້ອມດຽວກັນນັ້ນ, ຄວນຈຳກັດສິດທິທີ່ມອບໃຫ້ແກ່ເຄື່ອງມືໃຫ້ໜ້ອຍທີ່ສຸດ. ການອອກແບບສິດທິ ເຊັ່ນ: ບໍ່ມອບສິດໃນການຂຽນຂໍ້ມູນໃຫ້ກັບວຽກທີ່ຕ້ອງການພຽງແຕ່ການອ່ານ, ແລະ ການຫຼີກລ່ຽງການແກ້ໄຂຖານຂໍ້ມູນຫຼັກ (Production Database) ໂດຍກົງ ຈະຊ່ວຍຈຳກັດຄວາມເສຍຫາຍເມື່ອເກີດການເຮັດວຽກຜິດພາດ. ຫຼັກການສຳຄັນຂອງ Guardrails ຄືການບໍ່ແມ່ນ "ການເຊື່ອໝັ້ນໃນ Model ທີ່ສະຫຼາດ", ແຕ່ແມ່ນ "ການຈຳກັດຂອບເຂດການເຄື່ອນໄຫວດ້ວຍໂຄງສ້າງ". ນອກຈາກນີ້, "Shadow AI" ເຊິ່ງເປັນກໍລະນີທີ່ພະນັກງານເລີ່ມນຳໃຊ້ Agent ເອງຢູ່ນອກຂອບເຂດທີ່ເປັນທາງການ ກໍສົ່ງຜົນເສຍຕໍ່ຄວາມໜ້າເຊື່ອຖືເຊັ່ນກັນ. ການນຳໃຊ້ທີ່ຢູ່ນອກການຄວບຄຸມນັ້ນບໍ່ສາມາດສັງເກດການ ຫຼື ປະເມີນຜົນໄດ້, ສະນັ້ນ ຄວນເຮັດໃຫ້ການນຳໃຊ້ເຫັນພາບໄດ້ຊັດເຈນ ໂດຍພິຈາລະນາຄຽງຄູ່ກັບມຸມມອງດ້ານ ຄວາມສ່ຽງ ແລະ ການກຳກັບດູແລຂອງ Shadow AI.

ບໍ່ວ່າຈະມີການປະເມີນຜົນລ່ວງໜ້າຫຼາຍພຽງໃດ ກໍຍັງມີບັນຫາທີ່ສາມາດຮູ້ໄດ້ພຽງແຕ່ໃນສະພາບແວດລ້ອມການໃຊ້ງານຈິງເທົ່ານັ້ນ. ດັ່ງນັ້ນ, ຈຶ່ງຕ້ອງສ້າງກົນໄກທີ່ "ບໍ່ເປີດຕົວ ຫຼື Launch ທັງໝົດໃນຄັ້ງດຽວ" ແລະ "ສາມາດຍ້ອນກັບໄດ້ທັນທີ". ການປ່ອຍຟີເຈີແບບເປັນຂັ້ນຕອນ (段階リリース) ແມ່ນວິທີການເລີ່ມຕົ້ນໂດຍການຈຳກັດໃຫ້ຜູ້ໃຊ້ບາງກຸ່ມ ຫຼື ບາງວຽກງານເທົ່ານັ້ນ, ຖ້າບໍ່ມີບັນຫາກໍຄ່ອຍຂະຫຍາຍຂອບເຂດອອກໄປ. ວິທີນີ້ຊ່ວຍໃຫ້ສາມາດກວດສອບພຶດຕິກຳຕົວຈິງໃນຂະນະທີ່ຈຳກັດຜົນກະທົບໃຫ້ຢູ່ໃນວົງແຄບ. ສຳລັບ Agent ໃໝ່ ຫຼື ການປ່ຽນແປງຂະໜາດໃຫຍ່, ລຳດັບການ "ປ່ອຍອອກໄປເທື່ອລະນ້ອຍແລ້ວຄ່ອຍຂະຫຍາຍ" ແບບນີ້ຈະມີປະສິດທິຜົນຫຼາຍ.

ພ້ອມດຽວກັນນັ້ນ, ຕ້ອງກຽມຂັ້ນຕອນການ Rollback ໄວ້ໃຫ້ພ້ອມ. ຖ້າມີການປ່ຽນແປງ Prompt, ເຄື່ອງມື ຫຼື ການຕັ້ງຄ່າ Model, ໃຫ້ບັນທຶກແຕ່ລະເວີຊັນໄວ້ ເພື່ອໃຫ້ສາມາດຍ້ອນກັບໄປຫາເວີຊັນກ່ອນໜ້າໄດ້ທັນທີຫາກເກີດຂໍ້ຜິດພາດ. ເນື່ອງຈາກ Agent ອາດມີພຶດຕິກຳປ່ຽນແປງໄປຢ່າງຫຼວງຫຼາຍດ້ວຍການປັບປ່ຽນການຕັ້ງຄ່າພຽງເລັກນ້ອຍ, ການຮັກສາສະຖານະທີ່ "ສາມາດຍ້ອນກັບໄດ້ເມື່ອມີການປ່ຽນແປງ" ຈຶ່ງເປັນດັ່ງຕາໜ່າງຄວາມປອດໄພ. ເພື່ອບໍ່ໃຫ້ການຕັດສິນໃຈໃນການຍົກເລີກການປ່ຽນແປງຊັກຊ້າ, ຄວນກຳນົດມາດຕະຖານໄວ້ລ່ວງໜ້າວ່າ "ຕົວຊີ້ວັດໃດທີ່ຫຼຸດລົງຮອດລະດັບໃດ ຈຶ່ງຄວນຍົກເລີກ". ການອອກແບບການນຳຟີເຈີໃໝ່ເຂົ້າໃຊ້ງານຄູ່ກັບການຍົກເລີກເປັນຊຸດດຽວກັນ ຄືພື້ນຖານຂອງການປະຕິບັດງານເພື່ອຮັກສາຄວາມໜ້າເຊື່ອຖື.

ຄຸນນະພາບບໍ່ແມ່ນສິ່ງທີ່ສ້າງຂຶ້ນເທື່ອດຽວແລ້ວຈົບ ແຕ່ເປັນສິ່ງທີ່ຕ້ອງພັດທະນາໃຫ້ສູງຂຶ້ນຢ່າງຕໍ່ເນື່ອງ. ການພັດທະນາຊຸດຂໍ້ມູນປະເມີນຜົນ, ການກວດຫາການຖົດຖອຍ (Regression), ແລະ ການຈັດການເວີຊັນຂອງການປ່ຽນແປງ — ທັງ 3 ຈຸດນີ້ຄືຈຸດສຳຄັນ ຫຼື ແກນຫຼັກ ທີ່ຈະຊ່ວຍຍົກລະດັບຄຸນນະພາບໃຫ້ສູງຂຶ້ນ.

ຈຸດສຳຄັນ ຫຼື ແກນຫຼັກ ຂອງການປັບປຸງຄຸນນະພາບແມ່ນຊຸດຂໍ້ມູນການປະເມີນຜົນ (Evaluation Dataset). ນີ້ແມ່ນການລວບລວມຕົວຢ່າງທີ່ເປັນຕົວແທນທີ່ລະບຸວ່າ "ສຳລັບການປ້ອນຂໍ້ມູນນີ້, ຕ້ອງການໃຫ້ມີພຶດຕິກຳແບບໃດ", ເຊິ່ງຈະກາຍເປັນມາດຕະຖານໃນການວັດແທກຄຸນນະພາບຂອງ Agent. ໃນຕອນເລີ່ມຕົ້ນ, ໃຊ້ພຽງຈຳນວນໜ້ອຍກໍພຽງພໍ, ແຕ່ເມື່ອມີການເພີ່ມກໍລະນີທີ່ຜິດພາດ ຫຼື Edge Case ທີ່ພົບໃນການໃຊ້ງານຈິງຢ່າງຕໍ່ເນື່ອງ, ມັນຈະພັດທະນາກາຍເປັນມາດຕະຖານທີ່ໃຊ້ງານໄດ້ຈິງ ແລະ ເໝາະສົມກັບວຽກງານຂອງບໍລິສັດ.

ເມື່ອມີຊຸດຂໍ້ມູນນີ້, ມັນຈະເຮັດໃຫ້ສາມາດກວດຫາການຖົດຖອຍ (Regression) ໄດ້. ເມື່ອມີການປ່ຽນແປງ Prompt ຫຼື Model, ທ່ານສາມາດກວດສອບໂດຍອັດຕະໂນມັດກ່ອນການປ່ອຍເວີຊັນໃໝ່ (Release) ວ່າການປ້ອນຂໍ້ມູນທີ່ເຄີຍປະມວນຜົນໄດ້ຢ່າງຖືກຕ້ອງໃນເມື່ອກ່ອນນັ້ນ ຍັງເຮັດວຽກໄດ້ປົກກະຕິຢູ່ຫຼືບໍ່. ເນື່ອງຈາກ Agent ມັກຈະເກີດບັນຫາ "ເມື່ອແກ້ໄຂບັນຫາໜຶ່ງແລ້ວ ບັນຫາອື່ນກໍກັບມາເກີດຂຶ້ນອີກ", ການກວດຫາການຖົດຖອຍຈຶ່ງມີຄວາມສຳຄັນເປັນພິເສດ. ການສ້າງນິໄສໃນການນຳຊຸດຂໍ້ມູນການປະເມີນຜົນມາທົດສອບທຸກຄັ້ງທີ່ມີການປ່ຽນແປງ ແລະ ກວດສອບວ່າບໍ່ມີລາຍການໃດທີ່ມີຄະແນນຫຼຸດລົງ—ນິໄສນີ້ຈະຊ່ວຍໃຫ້ການປັບປຸງ "ກ້າວໄປຂ້າງໜ້າ" ຢ່າງຕໍ່ເນື່ອງ.

ພຶດຕິກຳຂອງ Agent ຖືກກຳນົດໂດຍການປະສົມປະສານຂອງ Prompt, ການກຳນົດ Tool, ການຕັ້ງຄ່າ Model ແລະ Workflow. ການຈັດການເວີຊັນ (Version control) ສິ່ງເຫຼົ່ານີ້ "ໃນແບບດຽວກັນກັບ Code" ແມ່ນເງື່ອນໄຂເບື້ອງຕົ້ນຂອງການເຮັດຊ້ຳ (Reproducibility) ແລະ ການປັບປຸງ. ຖ້າບໍ່ມີການບັນທຶກໄວ້ວ່າເວີຊັນໃດໄດ້ປ່ຽນແປງຫຍັງໄປແດ່, ກໍຈະບໍ່ສາມາດຕິດຕາມສາເຫດໄດ້ວ່າ "ເປັນຫຍັງອາທິດແລ້ວນີ້ຍັງດີຢູ່ ແຕ່ມື້ນີ້ກັບມີບັນຫາ".

ໂດຍສະເພາະແມ່ນ, ຄວນຈັດການ Prompt ໄວ້ໃນ Repository ພ້ອມກັບ Code ແລະ ບັນທຶກປະຫວັດການປ່ຽນແປງໄວ້. ລວມເຖິງການບັນທຶກການປ່ຽນແປງມາດຕະຖານ ຫຼື Specification ຂອງ Tool ແລະ ການປ່ຽນ Model. ການເຮັດແບບນີ້ຈະຊ່ວຍໃຫ້ສາມາດລະບຸໄດ້ວ່າ "ປ່ຽນຫຍັງ, ເວລາໃດ" ເມື່ອຄຸນນະພາບມີການປ່ຽນແປງ ແລະ ສາມາດກັບຄືນໄປຫາເວີຊັນທີ່ມີບັນຫາໄດ້ທັນທີ. ເນື່ອງຈາກ Model ມີການອັບເດດຢ່າງຕໍ່ເນື່ອງ, ການບໍ່ປັບແຕ່ງໃຫ້ເຂົ້າກັບລັກສະນະສະເພາະຂອງເວີຊັນໃດໜຶ່ງຫຼາຍເກີນໄປ ແລະ ການເຮັດໃຫ້ສາມາດປ່ຽນແທນໄດ້ດ້ວຍການຈັດການເວີຊັນ ຈະສົ່ງຜົນດີຕໍ່ການດຳເນີນງານໃນໄລຍະຍາວ.

ການພຽງແຕ່ຮູ້ສຶກວ່າ "ມັນດີຂຶ້ນແລ້ວ" ແມ່ນບໍ່ສາມາດເຮັດໃຫ້ການດຳເນີນງານໄປຕໍ່ໄດ້. ການຕິດຕາມຄຸນນະພາບ, ຕົ້ນທຶນ ແລະ ຄວາມໜ່ວງ (Latency) ດ້ວຍຕົວເລກ, ພ້ອມທັງເຊື່ອມໂຍງເຂົ້າກັບຕົວຊີ້ວັດທາງທຸລະກິດໃນທ້າຍທີ່ສຸດ, ຈະເຮັດໃຫ້ເຫັນລຳດັບຄວາມສຳຄັນໃນການປັບປຸງ.

ຄວາມໝັ້ນຄົງໃນການດຳເນີນງານສາມາດວັດແທກໄດ້ຢ່າງຊັດເຈນດ້ວຍ 3 ແກນຫຼັກ. ຄຸນນະພາບຈະວັດແທກຈາກອັດຕາຄວາມຖືກຕ້ອງຂອງຊຸດຂໍ້ມູນປະເມີນຜົນ, ອັດຕາການສຳເລັດຂອງວຽກງານ, ແລະ ອັດຕາການຜ່ານໃນການກວດສອບໂດຍມະນຸດ. ຕົ້ນທຶນຈະວັດແທກຈາກການບໍລິໂພກ Token ແລະ ຄ່າໃຊ້ຈ່າຍຕໍ່ 1 ຄຳຮ້ອງຂໍ (Request), ລວມເຖິງຕົ້ນທຶນລວມປະຈຳເດືອນ. ສ່ວນ Latency ແມ່ນເວລາທີ່ໃຊ້ໃນການຕອບສະໜອງ ແລະ ເວລາລວມຈົນກວ່າຈະສຳເລັດໃນກໍລະນີທີ່ Agent ຕ້ອງດຳເນີນການຫຼາຍຂັ້ນຕອນ.

ທັງ 3 ປັດໄຈນີ້ມີຄວາມສຳພັນໃນຮູບແບບຂອງການແລກປ່ຽນ ຫຼື Trade-off. ຖ້າຕ້ອງການເພີ່ມຄຸນນະພາບໂດຍການໃຊ້ Model ທີ່ມີປະສິດທິພາບສູງ ຫຼື ການອະນຸມານຫຼາຍຂັ້ນຕອນ ຕົ້ນທຶນ ແລະ Latency ກໍຈະເພີ່ມຂຶ້ນ, ໃນຂະນະທີ່ການຫຼຸດຕົ້ນທຶນກໍອາດເຮັດໃຫ້ຄຸນນະພາບຫຼຸດລົງໄດ້. ດ້ວຍເຫດນີ້, ຈຶ່ງຕ້ອງເບິ່ງພາບລວມຂອງທັງ 3 ແກນໄປພ້ອມກັນ ເພື່ອຊອກຫາຈຸດສົມດຸນໃນການ "ເພີ່ມຄຸນນະພາບໃຫ້ສູງສຸດ ພາຍໃຕ້ຂອບເຂດຂອງຕົ້ນທຶນ ແລະ ຄວາມໄວທີ່ຍອມຮັບໄດ້".

ໃນການປະຕິບັດງານຕົວຈິງ, ບໍ່ຄວນເບິ່ງພຽງແຕ່ຄ່າສະເລ່ຍ ແຕ່ຄວນເບິ່ງການກະຈາຍຕົວຂອງຂໍ້ມູນນຳ. ເຖິງແມ່ນວ່າ Latency ສະເລ່ຍຈະຢູ່ໃນເກນທີ່ຍອມຮັບໄດ້, ແຕ່ຖ້າມີບາງຄຳຮ້ອງຂໍທີ່ຊ້າຜິດປົກກະຕິ ກໍອາດຈະເຮັດໃຫ້ວຽກງານນັ້ນນຳໄປໃຊ້ງານບໍ່ໄດ້. ການເຂົ້າໃຈເຖິງແນວໂນ້ມຂອງຄຳຮ້ອງຂໍທີ່ຊ້າ (Percentile) ຫຼື ຄຳຮ້ອງຂໍທີ່ມີຕົ້ນທຶນສູງ ຈະຊ່ວຍໃຫ້ສາມາດລະບຸເປົ້າໝາຍທີ່ຄວນປັບປຸງໄດ້. ຖ້າເບິ່ງພຽງແກນໃດໜຶ່ງພຽງຢ່າງດຽວ ກໍງ່າຍທີ່ຈະເກີດຂໍ້ຜິດພາດ ເຊັ່ນ: ຕັ້ງໃຈຈະປັບປຸງຄຸນນະພາບແຕ່ກັບກາຍເປັນການເຮັດໃຫ້ຕົ້ນທຶນພຸ່ງສູງຂຶ້ນ. ການຕິດຕາມກວດສອບດ້ວຍຊຸດຂໍ້ມູນທັງ 3 ແກນ ຈຶ່ງເປັນພື້ນຖານຂອງການດຳເນີນງານທີ່ມີປະສິດທິພາບ.

ພຽງແຕ່ມາດຕະຖານ ຫຼື Specification ທາງເຕັກນິກຢ່າງດຽວ ບໍ່ສາມາດອະທິບາຍເຖິງມູນຄ່າຂອງການດຳເນີນງານໃຫ້ແກ່ຝ່າຍບໍລິຫານໄດ້. ໃນທ້າຍທີ່ສຸດ, ພວກເຮົາຕ້ອງການສະແດງໃຫ້ເຫັນວ່າການເຮັດວຽກຂອງ Agent ນັ້ນສົ່ງຂໍ້ມູນຕໍ່ໃຫ້ຜົນລັດທາງທຸລະກິດໄດ້ແນວໃດ. ຕົວຢ່າງເຊັ່ນ: ຖ້າຫາກເປັນການຕອບຮັບຄຳຖາມ ກໍຄວນເຊື່ອມໂຍງກັບຕົວຊີ້ວັດຜົນງານໜ້າວຽກຕົວຈິງ ເຊັ່ນ: ອັດຕາການແກ້ໄຂບັນຫາໃນຄັ້ງດຽວ ຫຼື ການຫຼຸດຜ່ອນເວລາໃນການຕອບຮັບ, ແລະ ຖ້າຫາກເປັນວຽກງານພາຍໃນບໍລິສັດ ກໍຄວນເຊື່ອມໂຍງກັບຈຳນວນວຽກທີ່ປະມວນຜົນໄດ້ ຫຼື ການຫຼຸດຜ່ອນວຽກທີ່ຕ້ອງກັບມາແກ້ໄຂໃໝ່.

ສິ່ງທີ່ໄດ້ຜົນໃນຈຸດນີ້ ຄືການນຳເອົາມາດຕະຖານ ຫຼື Specification ທາງເຕັກນິກ ແລະ ຕົວຊີ້ວັດທາງທຸລະກິດມາຈັດວາງໄວ້ໃນ Dashboard ດຽວກັນ. ເຮັດໃຫ້ສາມາດເບິ່ງເຫັນໄດ້ໃນແກນເວລາ (Time axis) ດຽວກັນວ່າ ໃນຊ່ວງເວລາທີ່ຄະແນນຄຸນນະພາບສູງຂຶ້ນນັ້ນ ອັດຕາການແກ້ໄຂບັນຫາໄດ້ສູງຂຶ້ນນຳຫຼືບໍ່, ຫຼື ຜົນລັດທີ່ໄດ້ນັ້ນຄຸ້ມຄ່າກັບຕົ້ນທຶນທີ່ເພີ່ມທະວີຂຶ້ນເລື້ອຍໆ ຫຼື ບໍ່. ຖ້າສາມາດສະແດງໃຫ້ເຫັນໄດ້ວ່າການປັບປຸງທາງດ້ານເຕັກນິກສົ່ງຜົນຕໍ່ຕົວເລກທາງທຸລະກິດ, ມັນກໍຈະກາຍເປັນຂໍ້ມູນປະກອບການຕັດສິນໃຈໃນການລົງທຶນເພື່ອດຳເນີນງານຕໍ່ໄປ. ໃນທາງກັບກັນ, ຖ້າມາດຕະຖານ ຫຼື Specification ທາງເຕັກນິກດີ ແຕ່ຕົວຊີ້ວັດທາງທຸລະກິດບໍ່ມີການເຄື່ອນໄຫວ, ກໍຈຳເປັນຕ້ອງກັບມາທົບທວນການກຳນົດບັນຫາທີ່ຄວນແກ້ໄຂຕັ້ງແຕ່ຕົ້ນ.

ການເຂົ້າໃຈວ່າ AgentOps ຂອງບໍລິສັດຕົນເອງຢູ່ໃນຂັ້ນຕອນໃດ ຈະຊ່ວຍໃຫ້ກຳນົດໄດ້ວ່າຄວນລົງທຶນກັບສິ່ງໃດຕໍ່ໄປ. ລະຫວ່າງຂັ້ນຕອນທີ່ຍັງບໍ່ມີການສັງເກດການເລີຍ ກັບຂັ້ນຕອນທີ່ການປັບປຸງເຮັດວຽກໂດຍອັດຕະໂນມັດນັ້ນ, ວິທີການແກ້ໄຂບັນຫາແມ່ນແຕກຕ່າງກັນຢ່າງສິ້ນເຊີງ.

ຄວາມສຸກຂອງ AgentOps ສາມາດຈັດແບ່ງອອກໄດ້ເປັນ 4 ໄລຍະ ເພື່ອໃຫ້ເຂົ້າໃຈໄດ້ງ່າຍຂຶ້ນ:

• ໄລຍະທີ 1 (ການຄົ້ນຫາດ້ວຍຕົນເອງ): ບໍ່ມີການບັນທຶກ Log ຫຼື Trace, ເມື່ອເກີດບັນຫາຂຶ້ນ ຄົນຕ້ອງເປັນຜູ້ກວດສອບດ້ວຍຕົນເອງ ແລະ ບໍ່ສາມາດເຮັດໃຫ້ພຶດຕິກຳດັ່ງກ່າວເກີດຂຶ້ນຊ້ຳໄດ້.
• ໄລຍະທີ 2 (ມີການສັງເກດການ): ມີການບັນທຶກຂໍ້ມູນ Input/Output ແລະ Trace ເຮັດໃຫ້ສາມາດຕິດຕາມໄດ້ວ່າເກີດຫຍັງຂຶ້ນ, ແຕ່ການປະເມີນຜົນຍັງຂຶ້ນກັບບຸກຄົນ.
• ໄລຍະທີ 3 (ມີການປະເມີນຜົນ): ມີຊຸດຂໍ້ມູນສຳລັບການປະເມີນຜົນ ແລະ ສາມາດກວດພົບ Regression ກ່ອນການປ່ອຍເວີຊັນໃໝ່ (Release), ມີການຕິດຕາມ KPI ຢ່າງຕໍ່ເນື່ອງ.
• ໄລຍະທີ 4 (ການປັບປຸງຢ່າງຕໍ່ເນື່ອງ): ຄວາມຜິດພາດທີ່ເກີດຂຶ້ນໃນລະບົບຈິງຈະຖືກນຳກັບໄປເປັນຂໍ້ມູນໃນການປະເມີນໂດຍອັດຕະໂນມັດ, ເຮັດໃຫ້ວົງຈອນການປັບປຸງກາຍເປັນວຽກປະຈຳ.

ອົງກອນສ່ວນໃຫຍ່ຍັງຢູ່ໃນໄລຍະທີ 1 ຫາ ໄລຍະທີ 2. ສິ່ງສຳຄັນບໍ່ແມ່ນການພະຍາຍາມກ້າວກະໂດດໄປສູ່ໄລຍະສູງສຸດໃນທັນທີ, ແຕ່ແມ່ນການປະເມີນສະຖານະຂອງຕົນເອງຢ່າງຊື່ສັດ. ຫາກຍັງບໍ່ມີການສັງເກດການ ແຕ່ພະຍາຍາມຈະເຮັດການປັບປຸງອັດຕະໂນມັດຂັ້ນສູງ ກໍຈະບໍ່ສາມາດເຮັດວຽກໄດ້ເນື່ອງຈາກຂາດ ໂຄງສ້າງພື້ນຖານ ຫຼື Infrastructure ທີ່ຮອງຮັບ. ການທີ່ຈະຕັດສິນວ່າຕົນເອງຢູ່ໃນໄລຍະໃດ ໃຫ້ລອງທົບທວນຄືນວ່າ "ສາມາດອະທິບາຍສາເຫດຂອງຂໍ້ຜິດພາດທີ່ຜ່ານມາໂດຍການນຳຂໍ້ມູນຈາກບັນທຶກມາຈຳລອງເຫດການຄືນໃໝ່ໄດ້ຫຼືບໍ່". ຖ້າອະທິບາຍບໍ່ໄດ້ ສະແດງວ່າຢູ່ໃນໄລຍະທີ 1, ຖ້າອະທິບາຍໄດ້ແຕ່ການປະເມີນຜົນຍັງອີງໃສ່ຄວາມຮູ້ສຶກຂອງຄົນ ສະແດງວ່າຢູ່ໃນໄລຍະທີ 2; ການທຽບໃສ່ເຫດການຕົວຈິງແບບນີ້ຈະເຮັດໃຫ້ການປະເມີນຕຳແໜ່ງຂອງຕົນເອງມີຄວາມຊັດເຈນຍິ່ງຂຶ້ນ.

ກຸນແຈສຳຄັນໃນການຍົກລະດັບຂຶ້ນໄປອີກຂັ້ນໜຶ່ງ ແມ່ນການຕື່ມເຕັມ "ພື້ນຖານ" ຂອງຂັ້ນນັ້ນໃຫ້ຄົບຖ້ວນ. ການຍົກລະດັບຈາກຂັ້ນທີ 1 ໄປສູ່ຂັ້ນທີ 2 ແມ່ນການວາງລະບົບເພື່ອເກັບບັນທຶກ Log ແລະ Trace ຂັ້ນພື້ນຖານໄວ້ໃຫ້ໄດ້. ຖ້າບໍ່ມີສິ່ງນີ້ ກໍບໍ່ສາມາດກ້າວຕໍ່ໄປໄດ້. ການຍົກລະດັບຈາກຂັ້ນທີ 2 ໄປສູ່ຂັ້ນທີ 3 ແມ່ນການສ້າງ Evaluation Dataset (ເຖິງຈະມີຂະໜາດນ້ອຍກໍຕາມ) ແລະ ສ້າງນິໄສໃນການທົດສອບຜ່ານຂໍ້ມູນດັ່ງກ່າວກ່ອນການເປີດຕົວ ຫຼື Launch. ການຍົກລະດັບຈາກຂັ້ນທີ 3 ໄປສູ່ຂັ້ນທີ 4 ແມ່ນການນຳເອົາຄວາມຜິດພາດທີ່ພົບໃນລະບົບຕົວຈິງ ມາສ້າງເປັນຂະບວນການ ຫຼື Pipeline ເພື່ອສົ່ງຂໍ້ມູນຕໍ່ໃຫ້ກັບ Evaluation Dataset ໂດຍບໍ່ແມ່ນການອາໄສຄວາມຕັ້ງໃຈຂອງບຸກຄົນ ແຕ່ຕ້ອງເປັນການລວມເຂົ້າໃນຂະບວນການປະຕິບັດງານ.

ຖ້າຟ້າວຮີບຮ້ອນຂ້າມຂັ້ນ ເຖິງຈະຈັດຮູບແບບໃຫ້ຄົບຖ້ວນກໍອາດຈະບໍ່ສາມາດດຳເນີນງານໄດ້. ຍົກຕົວຢ່າງ, ຖ້ານຳເອົາ "ການປັບປຸງແບບອັດຕະໂນມັດ" ມາໃຊ້ໂດຍທີ່ຍັງບໍ່ມີ Evaluation Dataset, ທ່ານກໍຈະບໍ່ສາມາດຕັດສິນໄດ້ວ່າການປັບປຸງນັ້ນດີຫຼືບໍ່ ແລະ ອາດຈະສົ່ງຜົນໃຫ້ຄຸນນະພາບບໍ່ມີຄວາມສະຖຽນແທນ. ການຮັກສາລຳດັບຂັ້ນຕອນໂດຍການເຮັດພື້ນຖານຂອງຂັ້ນປັດຈຸບັນໃຫ້ໝັ້ນຄົງກ່ອນທີ່ຈະກ້າວໄປສູ່ຂັ້ນຕໍ່ໄປ ແມ່ນວິທີທີ່ສັ້ນທີ່ສຸດໃນທ້າຍທີ່ສຸດ.

ອົງກອນທີ່ປະສົບກັບບັນຫາໃນການນຳໃຊ້ AgentOps ມັກຈະມີຮູບແບບທີ່ຄ້າຍຄືກັນ. ຂໍໃຫ້ພິຈາລະນາ 2 ຮູບແບບຫຼັກ ພ້ອມກັບວິທີການຫຼີກລ່ຽງດັ່ງຕໍ່ໄປນີ້.

ຄວາມຜິດພາດທີ່ພົບຫຼາຍທີ່ສຸດຄື ການນຳອອກໃຊ້ງານຈິງໂດຍບໍ່ມີກົນໄກການປະເມີນຜົນ. ຫຼາຍຄົນຕັດສິນໃຈເປີດຕົວ ຫຼື Launch ໂດຍຄິດວ່າ "ມັນເຮັດວຽກໄດ້ໃນຕອນສາທິດ ສະນັ້ນມັນກໍໜ້າຈະບໍ່ມີບັນຫາຫຍັງ", ແຕ່ເມື່ອພົບກັບການປ້ອນຂໍ້ມູນທີ່ຫຼາກຫຼາຍໃນຄວາມເປັນຈິງ ກໍມັກຈະເກີດຂໍ້ຜິດພາດທີ່ບໍ່ຄາດຄິດຂຶ້ນຢ່າງຕໍ່ເນື່ອງ. ຍິ່ງໄປກວ່ານັ້ນ, ເນື່ອງຈາກບໍ່ມີຊຸດຂໍ້ມູນສຳລັບການປະເມີນຜົນ, ເຖິງຈະແກ້ໄຂໄປແລ້ວ ກໍບໍ່ສາມາດຢືນຢັນໄດ້ວ່າບັນຫານັ້ນຖືກແກ້ໄຂແລ້ວຫຼືບໍ່ ເຮັດໃຫ້ການປັບປຸງບໍ່ມີປະສິດທິພາບ.

ວິທີແກ້ໄຂແມ່ນງ່າຍດາຍ. ບໍ່ຈຳເປັນຕ້ອງລໍຖ້າໃຫ້ມີພື້ນຖານການປະເມີນຜົນທີ່ສົມບູນແບບ. ກ່ອນອື່ນ ໃຫ້ກຽມຂໍ້ມູນປ້ອນເຂົ້າທີ່ເປັນຕົວແທນປະມານສິບກວ່າລາຍການ ພ້ອມກັບຜົນລັພທີ່ຄາດຫວັງໄວ້, ແລະ ຕ້ອງນຳມາທົດສອບທຸກຄັ້ງກ່ອນການປ່ອຍເວີຊັນໃໝ່. ພຽງເທົ່ານີ້ກໍສາມາດປ້ອງກັນ "ການຖົດຖອຍທີ່ເຫັນໄດ້ຊັດເຈນ" ໄດ້ແລ້ວ. ທຸກຄັ້ງທີ່ເກີດບັນຫາໃນການນຳໃຊ້ຈິງ, ໃຫ້ເພີ່ມກໍລະນີນັ້ນເຂົ້າໄປໃນຊຸດຂໍ້ມູນ, ແລ້ວມາດຕະຖານການວັດແທກກໍຈະພັດທະນາຂຶ້ນເອງຕາມທຳມະຊາດ. ພຽງແຕ່ປ່ຽນຈາກ "ການປະເມີນຜົນເປັນສູນ" ມາເປັນ "ການປະເມີນຜົນຂັ້ນຕໍ່າສຸດ", ຄວາມສະຖຽນໃນການດຳເນີນງານກໍຈະປ່ຽນແປງໄປຢ່າງຫຼວງຫຼາຍ.

ອີກຮູບແບບໜຶ່ງທີ່ພົບເຫັນໄດ້ທົ່ວໄປຄື ການໄລ່ຕາມແຕ່ຄຸນນະພາບ ໂດຍປ່ອຍໃຫ້ເລື່ອງຕົ້ນທຶນ ແລະ ເວລາໃນການຕອບສະໜອງ (Latency) ເປັນເລື່ອງຮອງ. ເນື່ອງຈາກ Agent ຕ້ອງຮຽກໃຊ້ Model ແລະ ນຳໃຊ້ເຄື່ອງມືຫຼາຍຄັ້ງໃນການຮ້ອງຂໍພຽງຄັ້ງດຽວ, ມັນຈຶ່ງມີຕົ້ນທຶນທີ່ສູງກວ່າ ແລະ ການຕອບສະໜອງທີ່ຊ້າກວ່າການສົນທະນາແບບທົ່ວໄປ. ໃນຂັ້ນຕອນການກວດສອບອາດຈະບໍ່ທັນສັງເກດເຫັນ, ແຕ່ເມື່ອການນຳໃຊ້ເພີ່ມຂຶ້ນ ຈຶ່ງຄ່ອຍພົບວ່າ "ຕົ້ນທຶນສູງກວ່າທີ່ຄາດໄວ້ຫຼາຍເທົ່າ" ຫຼື "ຊ້າຈົນບໍ່ສາມາດນຳໃຊ້ໄດ້".

ວິທີແກ້ໄຂຄື ການນຳເອົາເລື່ອງຕົ້ນທຶນ ແລະ Latency ເຂົ້າໄປເປັນສ່ວນໜຶ່ງຂອງການຕິດຕາມກວດສອບຕັ້ງແຕ່ຕົ້ນ. ຕ້ອງເຮັດໃຫ້ການບໍລິໂພກຊັບພະຍາກອນຕໍ່ການຮ້ອງຂໍ (Request) ໜຶ່ງຄັ້ງສາມາດເບິ່ງເຫັນໄດ້ຢ່າງຊັດເຈນ ແລະ ອອກແບບໂດຍການພິຈາລະນາຄວາມສົມດຸນກັບຄຸນນະພາບ. ຕົວຢ່າງເຊັ່ນ: ການໃຊ້ວິທີປະມວນຜົນແບບເບົາສຳລັບການຮ້ອງຂໍທີ່ງ່າຍ ແລະ ໃຊ້ການຄິດວິເຄາະແບບໜັກສະເພາະກັບການຮ້ອງຂໍທີ່ຍາກ, ເຊິ່ງການປັບແຕ່ງບໍ່ໃຫ້ໃຊ້ຊັບພະຍາກອນສູງສຸດໃນທຸກກໍລະນີຈະຊ່ວຍໄດ້ຫຼາຍ. ຄວນຍຶດຖືແນວຄິດທີ່ວ່າ ຄຸນນະພາບ, ຕົ້ນທຶນ ແລະ ຄວາມໄວ ແມ່ນສິ່ງທີ່ຕ້ອງອອກແບບໄປພ້ອມໆກັນຕັ້ງແຕ່ເລີ່ມຕົ້ນ.

ນີ້ແມ່ນການລວບລວມຄຳຖາມທີ່ພົບເລື້ອຍໃນການປະຕິບັດງານກ່ຽວກັບ AgentOps.

AgentOps ມີຈຸດພິເສດໃນການຈັດການກັບບັນຫາການດຳເນີນງານທີ່ເປັນເອກະລັກຂອງ AI Agent ເຊິ່ງສາມາດຕັດສິນໃຈ ແລະ ປະຕິບັດງານໄດ້ດ້ວຍຕົນເອງ (ການປະຕິບັດງານຫຼາຍຂັ້ນຕອນ, ການໃຊ້ເຄື່ອງມື, ແລະ ຜົນລັອກທີ່ບໍ່ສາມາດກຳນົດໄດ້). MLOps ໝາຍເຖິງການຈັດການວົງຈອນຊີວິດຂອງການຮຽນຮູ້, ການເປີດຕົວ ຫຼື Launch, ແລະ ການຕິດຕາມກວດກາແບບຈຳລອງ Machine Learning, ສ່ວນ AIOps ແມ່ນຄວາມພະຍາຍາມໃນການເພີ່ມປະສິດທິພາບການດຳເນີນງານດ້ານ IT ດ້ວຍ AI. AgentOps ໃຊ້ແນວຄິດຂອງ MLOps ເປັນພື້ນຖານ ໃນຂະນະທີ່ເຈາະເລິກເຂົ້າໄປໃນການສັງເກດການ ແລະ ການປະເມີນຜົນທີ່ເປັນເອກະລັກຂອງ Agent. ສຳລັບພາບລວມຂອງ AgentOps, ກະລຸນາເບິ່ງທີ່ AgentOps ແມ່ນຫຍັງ — ຄູ່ມືການອອກແບບອົງກອນການດຳເນີນງານ AI Agent.

ເລີ່ມຕົ້ນຈາກການສັງເກດການແມ່ນວິທີທີ່ເປັນມາດຕະຖານ. ຖ້າສ້າງສະພາບທີ່ສາມາດບັນທຶກການນຳເຂົ້າ-ສົ່ງອອກຂໍ້ມູນ ແລະ ການຕິດຕາມ (Trace) ໄດ້, ກໍຈະເຮັດໃຫ້ເຫັນສິ່ງທີ່ກຳລັງເກີດຂຶ້ນ. ຕໍ່ມາ, ໃຫ້ກຽມຂໍ້ມູນນຳເຂົ້າທີ່ເປັນຕົວແທນປະມານສິບກວ່າລາຍການ ເພື່ອນຳມາໃຊ້ໃນການປະເມີນຜົນຂັ້ນພື້ນຖານກ່ອນການເປີດຕົວ ຫຼື Launch. ພຽງແຕ່ສອງຢ່າງນີ້ ກໍສາມາດກ້າວຈາກຂັ້ນຕອນການຄົ້ນຫາແບບງົມງາຍ ໄປສູ່ຂັ້ນຕອນທີ່ມີການສັງເກດການ ແລະ ການປະເມີນຜົນໄດ້. ການນຳໃຊ້ເຄື່ອງມືຂັ້ນສູງແມ່ນສາມາດເຮັດໄດ້ເມື່ອມີພື້ນຖານດ້ານການສັງເກດການ ແລະ ການປະເມີນຜົນທີ່ໝັ້ນຄົງແລ້ວ. ຢ່າຕັ້ງເປົ້າໝາຍໃຫ້ສົມບູນແບບຕັ້ງແຕ່ຕົ້ນ, ການເລີ່ມຕົ້ນໝູນວຽນວົງຈອນການເຮັດວຽກໃຫ້ສັ້ນລົງ ແມ່ນທາງລັດສູ່ຄວາມສຳເລັດ.

ຫຼັກການປະຕິບັດທີ່ດີທີ່ສຸດຂອງ AgentOps ແມ່ນການສະຫຼຸບລວມຍອດໃຫ້ເຫຼືອພຽງ "ການໝູນວຽນຂອງວົງຈອນ ການສັງເກດການ → ການປະເມີນຜົນ → ການປັບປຸງ ໃຫ້ເປັນລະບົບຢ່າງຕໍ່ເນື່ອງ". ເຮົາຕ້ອງສັງເກດການຜົນລວມ (Output), ວັດແທກຄວາມດີ-ຄວາມບໍ່ດີດ້ວຍຊຸດຂໍ້ມູນການປະເມີນຜົນ, ແລະ ນຳເອົາຄວາມຜິດພາດທີ່ເກີດຂຶ້ນໃນການໃຊ້ງານຈິງກັບມາປັບປຸງ. ໂດຍການນຳເອົາສິ່ງເຫຼົ່ານີ້ມາປະສົມປະສານກັບ ລະບົບປ້ອງກັນຄວາມໜ້າເຊື່ອຖື ແລະ ຄວາມປອດໄພ (Guardrails), HITL (Human-in-the-loop), ການປ່ອຍຟີເຈີແບບເປັນຂັ້ນຕອນ ແລະ ການຍົກເລີກການປ່ຽນແປງ (Rollback), KPI ດ້ານຄຸນນະພາບ-ຕົ້ນທຶນ-ຄວາມໜ່ວງ (Latency), ລວມເຖິງການຈັດການເວີຊັນ (Version control), ຈະເຮັດໃຫ້ Agent ພັດທະນາຈາກ "ຕົວຢ່າງທີ່ໃຊ້ງານໄດ້" ໄປສູ່ "ໂຄງສ້າງພື້ນຖານ ຫຼື Infrastructure ທາງທຸລະກິດທີ່ໝັ້ນຄົງ".

ຈຸດເລີ່ມຕົ້ນແມ່ນການປະເມີນລະດັບຄວາມພ້ອມຂອງບໍລິສັດຕົນເອງຢ່າງກົງໄປກົງມາ. ຖ້າບໍ່ມີການສັງເກດການ ກໍໃຫ້ເລີ່ມຈາກການບັນທຶກຂໍ້ມູນກ່ອນ, ຖ້າບໍ່ມີການປະເມີນຜົນ ກໍໃຫ້ເລີ່ມຈາກຊຸດຂໍ້ມູນຂະໜາດນ້ອຍທີ່ສຸດ. ການສ້າງຮາກຖານໃຫ້ແໜ້ນໜາໃນຂັ້ນຕອນປັດຈຸບັນກ່ອນຈະກ້າວໄປສູ່ຂັ້ນຕໍ່ໄປ—ລຳດັບນີ້ຈະເປັນທາງລັດທີ່ສັ້ນທີ່ສຸດ. ຄຳນິຍາມຂອງ AgentOps ແລະ ການອອກແບບອົງກອນໃນການດຳເນີນງານ ໄດ້ຖືກອະທິບາຍຢ່າງລະອຽດໃນ AgentOps ແມ່ນຫຍັງ — ຄູ່ມືການອອກແບບອົງກອນສຳລັບການດຳເນີນງານ AI Agent. ບໍລິສັດຂອງພວກເຮົາກໍກຳລັງມຸ່ງໝັ້ນໃນການສະໜັບສະໜູນການດຳເນີນງານ AI Agent ໃນການໃຊ້ງານຈິງ ແລະ ການສ້າງລະບົບການປັບປຸງ. ຫາກທ່ານມີຄວາມກັງວົນກ່ຽວກັບການເຮັດໃຫ້ການດຳເນີນງານມີຄວາມສະຖຽນລະພາບ, ສາມາດປຶກສາຫາລືກັບພວກເຮົາໄດ້ທຸກເມື່ອ.