Human-in-the-Loop (ຕໍ່ໄປນີ້ຈະເອີ້ນວ່າ HITL) ແມ່ນແນວຄິດການອອກແບບທີ່ມະນຸດເຂົ້າໄປມີສ່ວນຮ່ວມ ແລະ ກວດສອບໃນຂະບວນການຕັດສິນໃຈຂອງ AI ເຊິ່ງເປັນ ຈຸດສຳຄັນ ຫຼື ແກນຫຼັກ ໃນການຮັບປະກັນຄຸນນະພາບ ແລະ ຄວາມໜ້າເຊື່ອຖືຂອງ AI BPO.

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

ເມື່ອອ່ານຈົບ, ທ່ານຈະໄດ້ຮັບຜົນລັພດັ່ງນີ້:

• ການກຳນົດຂອບເຂດທີ່ AI ຄວນປະມວນຜົນແບບອັດຕະໂນມັດ ແລະ ຂອບເຂດທີ່ມະນຸດຄວນເຂົ້າໄປມີສ່ວນຮ່ວມຢ່າງຊັດເຈນ
• ຂັ້ນຕອນການອອກແບບກົດເກນການແຍກວຽກໂດຍອີງໃສ່ຄະແນນຄວາມໜ້າເຊື່ອຖື ແລະ ການຈັດປະເພດຄວາມສ່ຽງຂອງວຽກງານ
• ວິທີການສ້າງວົງຈອນການປັບປຸງ AI ຢ່າງຕໍ່ເນື່ອງຜ່ານ Feedback loop

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

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

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

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

ຕໍ່ຈາກນີ້, ພວກເຮົາຈະມາສຶກສາເຖິງແນວຄວາມຄິດພື້ນຖານຂອງ HITL ໃນບໍລິບົດຂອງວຽກງານ BPO, ພ້ອມທັງວິທີການກຳນົດຈຸດທີ່ຈຳເປັນຕ້ອງມີການແຊກແຊງ ແລະ ພາບລວມຂອງຄວາມສ່ຽງທີ່ຈະເກີດຂຶ້ນຫາກບໍ່ມີການນຳໃຊ້ວິທີດັ່ງກ່າວຕາມລຳດັບ.

ການອັດຕະໂນມັດຢ່າງສົມບູນ (Fully Automated) ແມ່ນແນວຄິດການອອກແບບທີ່ "ເພີ່ມປະສິດທິພາບໃຫ້ສູງສຸດໂດຍການຕັດມະນຸດອອກຈາກຂະບວນການ". ໃນທາງກົງກັນຂ້າມ, Human-in-the-Loop (ຕໍ່ໄປນີ້ຈະເອີ້ນວ່າ HITL) ແມ່ນການອອກແບບຮ່ວມກັນທີ່ "ມອບໝາຍວຽກທີ່ AI ຖະໜັດໃຫ້ AI ເປັນຜູ້ຈັດການ, ແລະໃຫ້ມະນຸດເຂົ້າມາແຊກແຊງໃນສະຖານະການທີ່ການຕັດສິນໃຈມີຄວາມຫຍຸ້ງຍາກ". ຄວາມແຕກຕ່າງນີ້ບໍ່ແມ່ນພຽງແຕ່ຄວາມແຕກຕ່າງຂອງອັດຕາການອັດຕະໂນມັດເທົ່ານັ້ນ, ແຕ່ຍັງໝາຍເຖິງຄວາມແຕກຕ່າງໃນແນວຄິດການອອກແບບພື້ນຖານທີ່ວ່າ ຈະວາງຄວາມຮັບຜິດຊອບໃນການຈັດການຄວາມສ່ຽງໄວ້ບ່ອນໃດ.

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

ເຫດຜົນທີ່ການອັດຕະໂນມັດຢ່າງສົມບູນນັ້ນເຮັດໄດ້ຍາກ ມີ 3 ປະການຫຼັກໆ ດັ່ງນີ້:

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

ແກ່ນແທ້ຂອງການອອກແບບແບບ HITL ແມ່ນການ "ເພີ່ມສ່ວນທີ່ສາມາດອັດຕະໂນມັດໄດ້ໃຫ້ສູງສຸດ, ໃນຂະນະດຽວກັນກໍສຸມການແຊກແຊງໄປຍັງຈຸດທີ່ການຕັດສິນໃຈຂອງມະນຸດສ້າງມູນຄ່າໄດ້".

ໃນໜ້າວຽກ AI BPO, ບໍ່ແມ່ນທຸກຂະບວນການຈະສາມາດເຮັດວຽກແບບອັດຕະໂນມັດໄດ້ທັງໝົດ. ໂດຍຂຶ້ນກັບລັກສະນະຂອງວຽກ ແລະ ລະດັບຄວາມສ່ຽງ, ຍັງມີຫຼາຍສະຖານະການທີ່ການຕັດສິນໃຈຂອງມະນຸດເປັນສິ່ງທີ່ຂາດບໍ່ໄດ້.

3 ສະຖານະການຫຼັກທີ່ຕ້ອງການ HITL (Human-in-the-Loop) ມີດັ່ງນີ້:

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

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

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

ການລະບຸ 3 ສະຖານະການເຫຼົ່ານີ້ໄວ້ລ່ວງໜ້າພາຍໃນຂະບວນການເຮັດວຽກ ຄືຈຸດເລີ່ມຕົ້ນຂອງການອອກແບບ HITL.

ການຄິດວ່າ "ອັດຕາການອັດຕະໂນມັດຍິ່ງສູງຍິ່ງດີ" ແລ້ວລະເລີຍ HITL ຈະນຳໄປສູ່ສະຖານະການແບບໃດ—ໃນໜ້າວຽກຕົວຈິງ ມັກຈະມີຫຼາຍກໍລະນີທີ່ການອອກແບບເລີ່ມຕົ້ນໄປກ່ອນໂດຍທີ່ຍັງບໍ່ທັນໄດ້ຫາຄຳຕອບໃຫ້ກັບຄຳຖາມນັ້ນ.

ຖ້າບໍ່ນຳເອົາ HITL ມາໃຊ້, ຄວາມສ່ຽງຫຼັກ 3 ປະການຕໍ່ໄປນີ້ຈະປາກົດຂຶ້ນ:

• ການຂະຫຍາຍຕົວຂອງຂໍ້ຜິດພາດທີ່ຕໍ່ເນື່ອງກັນ: ຖ້າບໍ່ມີກົນໄກໃນການກວດສອບເຖິງແມ່ນວ່າ AI ຈະຕັດສິນໃຈຜິດພາດ, ຂໍ້ຜິດພາດນັ້ນກໍຈະ ສົ່ງຂໍ້ມູນຕໍ່ໃຫ້ ຂະບວນການຖັດໄປເລື້ອຍໆ. ໃນວຽກງານການປ້ອນຂໍ້ມູນ, ມີການລາຍງານກໍລະນີທີ່ການຈັດປະເພດຜິດພາດພຽງ 1 ລາຍການ ສົ່ງຜົນກະທົບຕໍ່ບັນທຶກຫຼາຍຮ້ອຍລາຍການ.
• ການຂາດຄວາມຮັບຜິດຊອບ: ມາດຕາ 22 ຂອງ EU GDPR ໄດ້ລະບຸຢ່າງຊັດເຈນກ່ຽວກັບ "ສິດໃນການແຊກແຊງໂດຍມະນຸດ" ສຳລັບການຕັດສິນໃຈແບບອັດຕະໂນມັດທີ່ມີຜົນກະທົບທາງກົດໝາຍ. ຖ້າໃນການອອກແບບບໍ່ມີຈຸດທີ່ມະນຸດຄວບຄຸມ, ມັນຈະກົງກັບບັນຫາດ້ານການປະຕິບັດຕາມກົດລະບຽບ (Compliance) ໂດຍກົງ.
• ການປ່ອຍປະລະເລີຍຄວາມຊຸດໂຊມຂອງໂມເດວ: ໃນສະພາວະທີ່ບໍ່ມີ Feedback loop, AI ຈະບໍ່ສາມາດຕິດຕາມການປ່ຽນແປງຂອງສະພາບແວດລ້ອມການເຮັດວຽກໄດ້. ເຖິງແມ່ນວ່າ Data drift ຈະດຳເນີນໄປ ແຕ່ຖ້າບໍ່ມີຕົວກະຕຸ້ນ (Trigger) ໃນການແກ້ໄຂ ກໍມີແນວໂນ້ມທີ່ຄວາມແມ່ນຍຳຈະຫຼຸດລົງໂດຍທີ່ບໍ່ຖືກກວດພົບເປັນເວລາດົນ.

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

ການຂາດ HITL ບໍ່ແມ່ນ "ການເພີ່ມປະສິດທິພາບ" ແຕ່ເປັນ "ການຜັດຜ່ອນຄວາມສ່ຽງອອກໄປ".

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

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

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

ໃນການສ້າງແຜນຜັງຂະບວນການ (Process Map), ໃຫ້ດຳເນີນການກວດສອບອົງປະກອບຕໍ່ໄປນີ້ຄຽງຄູ່ກັບການສອບຖາມຜູ້ຮັບຜິດຊອບວຽກງານ:

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

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

ການໃຊ້ວິທີການຂຽນແບບມາດຕະຖານ ເຊັ່ນ BPMN (Business Process Model and Notation) ໃນການສ້າງແຜນຜັງຂະບວນການ ຈະຊ່ວຍໃຫ້ວິສະວະກອນ ແລະ ຜູ້ຮັບຜິດຊອບວຽກງານສາມາດອ້າງອີງແຜນຜັງດຽວກັນໄດ້ ເຊິ່ງຈະຊ່ວຍປ້ອງກັນຄວາມເຂົ້າໃຈທີ່ຄາດເຄື່ອນ. ຖ້າຈັດລະບຽບແຜນຜັງການໄຫຼວຽນຂອງຂໍ້ມູນ (DFD) ໂດຍແບ່ງເປັນ 3 ອົງປະກອບ ຄື: ພາກສ່ວນພາຍນອກ (External Entity), ຂະບວນການ (Process) ແລະ ບ່ອນຈັດເກັບຂໍ້ມູນ (Data Store) ຈະເຮັດໃຫ້ຂອບເຂດການນຳເຂົ້າຂໍ້ມູນໄປຍັງໂມເດວ AI ມີຄວາມຊັດເຈນຍິ່ງຂຶ້ນ.

ຄວາມແມ່ນຍຳຂອງການອອກແບບ HITL ແມ່ນຂຶ້ນຢູ່ກັບວ່າທ່ານສາມາດອ່ານຄະແນນຄວາມເຊື່ອໝັ້ນ (Confidence Score) ທີ່ AI model ສົ່ງອອກມາໄດ້ຢ່າງຖືກຕ້ອງຫຼາຍສໍ່າໃດ.

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

• ຄວາມແມ່ນຍຳ (Precision): ອັດຕາສ່ວນທີ່ຖືກຕ້ອງແທ້ຈິງໃນຈຳນວນທີ່ໄດ້ຮັບການອະນຸມັດແບບອັດຕະໂນມັດ
• ອັດຕາການກວດພົບ (Recall): ອັດຕາສ່ວນທີ່ model ສາມາດກວດພົບໄດ້ຢ່າງຖືກຕ້ອງໃນຈຳນວນທີ່ຄວນຈະຖືກຕ້ອງ
• F1 Score: ຄ່າສະເລ່ຍແບບຮາໂມນິກ (Harmonic mean) ລະຫວ່າງ Precision ແລະ Recall. ໃຊ້ເພື່ອຢືນຢັນຄວາມສົມດຸນ
• ການກະຈາຍຕົວຂອງຄະແນນຄວາມເຊື່ອໝັ້ນ: ກວດສອບດ້ວຍຮິສໂຕແກຣມ (Histogram) ວ່າຄະແນນມີການກະຈຸກຕົວຢູ່ໃນຂອບເຂດໃດໜຶ່ງຫຼືບໍ່

ໃນດ້ານການແບ່ງເງື່ອນໄຂ, ສຳລັບວຽກງານທີ່ເນັ້ນຄວາມແມ່ນຍຳ (ຕົວຢ່າງ: ການສະກັດຂໍ້ມູນຈຳນວນເງິນໃນສັນຍາ) ແມ່ນມີປະສິດທິຜົນທີ່ຈະໃຊ້ແກນການຕັດສິນໃຈໂດຍການໃຫ້ຄວາມສຳຄັນກັບ Precision ແລະ ຕັ້ງຄ່າເກນ (Threshold) ໃຫ້ສູງ, ສ່ວນວຽກງານທີ່ການປ້ອງກັນການຕົກຫຼົ່ນມີຄວາມສຳຄັນ (ຕົວຢ່າງ: ການກວດພົບການລະເມີດກົດລະບຽບ) ແມ່ນໃຫ້ຄວາມສຳຄັນກັບ Recall ແລະ ຕັ້ງຄ່າເກນໃຫ້ຕ່ຳລົງ.

ນອກຈາກນີ້, ການກວດສອບເປັນປະຈຳວ່າການກະຈາຍຕົວຂອງຄະແນນໃນສະພາບແວດລ້ອມການນຳໃຊ້ຈິງ (Production) ມີຄວາມແຕກຕ່າງຈາກຕອນພັດທະນາຫຼືບໍ່ນັ້ນ ແມ່ນສິ່ງທີ່ຂາດບໍ່ໄດ້. ຖ້າຫາກເກີດ Data Drift, ອັດຕາການເຂົ້າແຊກແຊງອາດຈະປ່ຽນແປງຢ່າງກະທັນຫັນເຖິງແມ່ນວ່າຈະໃຊ້ເກນ (Threshold) ເດີມກໍຕາມ.

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

"HITL (Human-in-the-Loop) ຕ້ອງການນຳມາໃຊ້ ແຕ່ບໍ່ຮູ້ວ່າໃຜຄວນຮັບຜິດຊອບໃນການເຂົ້າແຊກແຊງ" — ນັກອອກແບບລະບົບຫຼາຍຄົນມັກປະສົບກັບບັນຫານີ້. ຖ້າເລີ່ມການດຳເນີນງານໂດຍທີ່ໂຄງສ້າງບໍ່ຊັດເຈນ, ຈະເກີດສະຖານະການທີ່ AI ສົ່ງຂໍ້ມູນຕໍ່ໃຫ້ຜູ້ຮັບຜິດຊອບແລ້ວ ແຕ່ບໍ່ມີຜູ້ຕອບສະໜອງເກີດຂຶ້ນເລື້ອຍໆ.

ຜູ້ຮັບຜິດຊອບການເຂົ້າແຊກແຊງຈຳເປັນຕ້ອງມີທັກສະຫຼັກໆ 2 ປະເພດ:

ຄວາມຮູ້ດ້ານທຸລະກິດ (Domain Knowledge)

• ມີຄວາມຮູ້ຄວາມເຂົ້າໃຈຢ່າງເລິກເຊິ່ງກ່ຽວກັບມາດຕະຖານການຕັດສິນໃຈ ແລະ ກົດລະບຽບຍົກເວັ້ນຂອງວຽກງານນັ້ນໆ
• ມີອຳນາດໃນການຕັດສິນໃຈຂັ້ນສຸດທ້າຍໂດຍອີງຕາມກົດໝາຍ ແລະ ກົດລະບຽບຂອງບໍລິສັດ
• ມີທັກສະໃນການອ່ານ ແລະ ວິເຄາະຜົນລັອກຈາກ AI ຢ່າງມີວິຈານຍານ

ຄວາມສາມາດໃນການປະຕິບັດງານ (Operational Capability)

• ສາມາດໃຊ້ງານເຄື່ອງມືໃນການເຂົ້າແຊກແຊງ (ໜ້າຈໍທົບທວນ, ການຈັດການ Flag) ໄດ້ຢ່າງຄ່ອງແຄ້ວ
• ເຂົ້າໃຈເຖິງມາດຕະຖານເວລາໃນການປະມວນຜົນ (SLA) ແລະ ສາມາດຈັດລຳດັບຄວາມສຳຄັນໄດ້
• ສາມາດບັນທຶກເຫດຜົນໃນການຕັດສິນໃຈລົງໃນແບບຟອມ Feedback ໄດ້ຢ່າງກະທັດຮັດ

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

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

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

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

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

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

ໂຄງສ້າງເກນມາດຕະຖານ 3 ລະດັບທີ່ແນະນຳ ມີດັ່ງນີ້:

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

ດ້ວຍການອອກແບບ 3 ລະດັບນີ້, ກໍລະນີທີ່ຢູ່ໃນເຂດສີເທົາສາມາດຈັດການໄດ້ດ້ວຍການປະມວນຜົນແບບປະສົມ (Hybrid) ຄື "ມະນຸດເປັນຜູ້ກວດສອບຂັ້ນສຸດທ້າຍ ໃນຂະນະທີ່ຍັງໄດ້ຮັບຜົນປະໂຫຍດຈາກການເຮັດວຽກແບບອັດຕະໂນມັດ".

ຈຸດສຳຄັນໃນການປະຕິບັດງານສຳລັບການຕັ້ງຄ່າເກນມາດຕະຖານ ມີ 3 ຂໍ້ດັ່ງນີ້:

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

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

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

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

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

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

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

ການກວດສອບຮູບແບບຂໍ້ຍົກເວັ້ນຢ່າງລະອຽດ ໂດຍເລີ່ມຈາກບັນທຶກການເຮັດວຽກທີ່ຜ່ານມາ ແລະ ປະຫວັດການສອບຖາມ ແມ່ນມີປະສິດທິພາບ. ຮູບແບບຂໍ້ຍົກເວັ້ນທົ່ວໄປມີດັ່ງນີ້:

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

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

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

HITL ຈະສາມາດເຮັດວຽກໄດ້ກໍຕໍ່ເມື່ອມີການຈັດລະບຽບຂະບວນການຕ່າງໆຢ່າງຄົບຖ້ວນ ເລີ່ມຕັ້ງແຕ່ປະເພດຂອງຕົວກະຕຸ້ນການເຂົ້າໄປມີສ່ວນຮ່ວມ (Intervention trigger), ວິທີການສົ່ງມອບວຽກໃຫ້ຜູ້ຮັບຜິດຊອບ, ຈົນເຖິງການສົ່ງຂໍ້ມູນຕໍ່ໃຫ້ກັບການຕອບກັບ (Feedback loop).

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

ປະເພດຂອງ Trigger ທັງ 3 ແບບ

• ການກວດຈັບແບບອັດຕະໂນມັດ (Automatic Detection): ໃນທັນທີທີ່ຄະແນນຄວາມເຊື່ອໝັ້ນ (Confidence Score) ຂອງໂມເດວ AI ຫຼຸດຕ່ຳກວ່າເກນທີ່ກຳນົດໄວ້, ລະບົບຈະສົ່ງວຽກເຂົ້າໄປໃນຄິວ (Queue) ໂດຍອັດຕະໂນມັດ. ວິທີນີ້ສາມາດຕັດສິນໃຈໄດ້ຢ່າງສະໝ່ຳສະເໝີໂດຍອີງຕາມກົດເກນ ໂດຍບໍ່ເຮັດໃຫ້ຄວາມໄວໃນການປະມວນຜົນຫຼຸດລົງ.
• ການຕິດປ້າຍກຳກັບດ້ວຍຕົນເອງ (Manual Flag): ຜູ້ຮັບຜິດຊອບວຽກງານ ຫຼື ພະນັກງານ BPO ສາມາດເລືອກ Escalation ວຽກທີ່ຮູ້ສຶກວ່າ "ຍັງລັງເລໃນການຕັດສິນໃຈ" ໄດ້ຕາມຄວາມສະໝັກໃຈ. ເຊິ່ງຈະຊ່ວຍເສີມໃນສ່ວນຂອງຄວາມຮູ້ສຶກຜິດປົກກະຕິທາງດ້ານບໍລິບົດ (Contextual) ທີ່ການກວດຈັບແບບອັດຕະໂນມັດອາດຈະເກັບມາບໍ່ໝົດ.
• ການກວດສອບແບບເປັນໄລຍະ (Periodic Review): ເຖິງແມ່ນວ່າວຽກງານຈະມີຄະແນນຄວາມເຊື່ອໝັ້ນຜ່ານເກນທີ່ກຳນົດໄວ້ກໍຕາມ, ແຕ່ກໍຈະມີການສຸ່ມຕົວຢ່າງໃນອັດຕາສ່ວນທີ່ແນ່ນອນ ເພື່ອໃຫ້ມະນຸດກວດສອບພາຍຫຼັງ. ເຊິ່ງມີບົດບາດສຳຄັນໃນການຄົ້ນຫາການປ່ຽນແປງຂອງໂມເດວ (Model Drift) ຢ່າງເປັນລະບົບໄດ້ຕັ້ງແຕ່ຫົວທີ.

ຂໍ້ຄວນລະວັງໃນການອອກແບບ

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

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

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

ຫຼັກການພື້ນຖານຂອງການອອກແບບ UI

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

• ຜົນການຕັດສິນໃຈຂອງ AI ແລະ ຄະແນນຄວາມເຊື່ອໝັ້ນ (Confidence score)
• ຂໍ້ມູນທີ່ຍົກມາຈາກຂໍ້ມູນນຳເຂົ້າທີ່ໃຊ້ເປັນພື້ນຖານໃນການຕັດສິນໃຈ
• ລິ້ງອ້າງອີງເຖິງກໍລະນີທີ່ຄ້າຍຄືກັນໃນອະດີດ ແລະ ການຕັດສິນໃຈຄັ້ງສຸດທ້າຍ
• ປຸ່ມເລືອກສຳລັບການອະນຸມັດ, ການສົ່ງກັບຄືນ (Remand), ແລະ ການແຈ້ງເຕືອນບັນຫາ (Escalation)

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

ການແບ່ງເງື່ອນໄຂຂອງການອອກແບບການແຈ້ງເຕືອນ

ສຳລັບວຽກທີ່ມີຄວາມຮີບດ່ວນສູງ (ການຈັດປະເພດທີ່ມີຄວາມສ່ຽງສູງ ຫຼື ກໍລະນີທີ່ມີເວລາ SLA ເຫຼືອໜ້ອຍ), ໃຫ້ໃຊ້ທັງການແຈ້ງເຕືອນແບບ Push ແລະ ອີເມວຮ່ວມກັນ, ສ່ວນວຽກທີ່ມີບຸລິມະສິດປົກກະຕິ ໃຫ້ສະແດງພຽງແຕ່ສັນຍາລັກ (Badge) ຢູ່ເທິງ Dashboard ເທົ່ານັ້ນ. ຖ້າໃຊ້ການແຈ້ງເຕືອນແບບ Push ກັບທຸກກໍລະນີ ຈະເຮັດໃຫ້ເກີດຄວາມເມື່ອຍລ້າຈາກການແຈ້ງເຕືອນ ແລະ ມີຄວາມສ່ຽງທີ່ການແຈ້ງເຕືອນທີ່ສຳຄັນຈະຖືກກົບຝັງໄປ.

ຮູບແບບການອອກແບບທີ່ຄວນຫຼີກເວັ້ນ

• ການອອກແບບທີ່ສົ່ງ Task queue ໄປຫາອີເມວສ່ວນຕົວໂດຍກົງ (ເຮັດໃຫ້ວຽກຄ້າງເມື່ອຜູ້ຮັບຜິດຊອບບໍ່ຢູ່)
• UI ທີ່ມີແຕ່ປຸ່ມອະນຸມັດ ແຕ່ບໍ່ສາມາດບັນທຶກເຫດຜົນໃນການສົ່ງກັບຄືນໄດ້ (ເຮັດໃຫ້ວົງຈອນການໃຫ້ຂໍ້ມູນຍ້ອນກັບຂາດຕອນ)
• ການດຳເນີນງານທີ່ຊ່ອງທາງການແຈ້ງເຕືອນແຍກອອກຈາກກັນໃນແຕ່ລະພະແນກ ແລະ ບໍ່ມີຄວາມເປັນເອກະພາບ

UI ແລະ ການແຈ້ງເຕືອນໃນການສົ່ງຕໍ່ວຽກງານ ຍັງເປັນຈຸດເລີ່ມຕົ້ນຂອງວົງຈອນການໃຫ້ຂໍ້ມູນຍ້ອນກັບ (Feedback loop) ເຊິ່ງຈະກ່າວເຖິງໃນພາກຕໍ່ໄປ.

「ຜົນການຕັດສິນໃຈທີ່ພະນັກງານຮັບຜິດຊອບໄດ້ແກ້ໄຂນັ້ນ, ມັນໄດ້ຖືກປະຖິ້ມໄວ້ໂດຍບໍ່ໄດ້ນຳໃຊ້ປະໂຫຍດຫຼືບໍ່?」—— ຄຳຖາມນີ້ຄືຈຸດເລີ່ມຕົ້ນຂອງການອອກແບບ Feedback Loop.

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

ຂັ້ນຕອນພື້ນຖານໃນການນຳເອົາ Feedback ມາລວມເຂົ້າໃນການຮຽນຮູ້ ມີດັ່ງນີ້:

• ການເຮັດໃຫ້ການຕິດປ້າຍກຳກັບເປັນມາດຕະຖານ (Standardization of Labeling): ອອກແບບ UI ທີ່ບັງຄັບໃຫ້ໃສ່ລະຫັດເຫດຜົນທຸກຄັ້ງ ເມື່ອພະນັກງານຮັບຜິດຊອບເລືອກ "ແກ້ໄຂ", "ອະນຸມັດ" ຫຼື "ສົ່ງຄືນ"
• ການພັກຂໍ້ມູນ (Data Buffering): ສະສົມຂໍ້ມູນທີ່ແກ້ໄຂແລ້ວໄວ້ໃນປະລິມານທີ່ກຳນົດ (ຕົວຢ່າງ: Batch ລາຍສັບປະດາ) ກ່ອນຈະນຳເຂົ້າສູ່ ຂະບວນການ ຫຼື Pipeline ການຮຽນຮູ້ ເພື່ອຫຼຸດຜ່ອນສິ່ງລົບກວນ (Noise)
• ການນຳໃຊ້ການຮຽນຮູ້ແບບແຕກຕ່າງ (Differential Learning): ແທນທີ່ຈະຮຽນຮູ້ໂມເດວທັງໝົດຄືນໃໝ່, ໃຫ້ໃຊ້ວິທີ Fine-tuning ສະເພາະໝວດໝູ່ທີ່ມີການຕັດສິນໃຈຜິດພາດຊ້ຳໆ ເພື່ອຄວບຄຸມຕົ້ນທຶນ
• ການບໍລິຫານຈັດການເວີຊັນຢ່າງເຂັ້ມງວດ: ບໍລິຫານຈັດການເວີຊັນຂອງໂມເດວທັງກ່ອນ ແລະ ຫຼັງການຮຽນຮູ້, ພ້ອມທັງກຽມລະບົບທີ່ສາມາດ Rollback ໄດ້ໃນກໍລະນີທີ່ຄວາມແມ່ນຍຳຫຼຸດລົງ

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

ການກວດສອບວ່າ Feedback Loop ເຮັດວຽກໄດ້ຢ່າງປົກກະຕິຫຼືບໍ່ນັ້ນ, ຈະຖືກຕິດຕາມຢ່າງຕໍ່ເນື່ອງຜ່ານ KPI (ການປ່ຽນແປງຂອງອັດຕາການແຊກແຊງ ແລະ ອັດຕາການແກ້ໄຂ) ເຊິ່ງຈະອະທິບາຍໃນພາກຕໍ່ໄປ.

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

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

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

① ອັດຕາການແຊກແຊງ (Human Intervention Rate)

ແມ່ນອັດຕາສ່ວນຂອງຈຳນວນຄັ້ງທີ່ມະນຸດເຂົ້າໄປແຊກແຊງ ເມື່ອທຽບກັບຈຳນວນການປະມວນຜົນທັງໝົດ.

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

② ອັດຕາການແກ້ໄຂ (Override / Correction Rate)

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

③ ເວລາໃນການປະມວນຜົນ (End-to-End Processing Time)

ໃຫ້ແຍກວັດແທກເວລາໃນການປະມວນຜົນລະຫວ່າງ ກໍລະນີທີ່ສຳເລັດດ້ວຍການປະມວນຜົນແບບອັດຕະໂນມັດພຽງຢ່າງດຽວ ແລະ ກໍລະນີທີ່ມີການແຊກແຊງຈາກມະນຸດ.

Dashboard ບໍ່ຄວນຈົບລົງພຽງແຕ່ການ "ເຮັດໃຫ້ເຫັນພາບ" ເທົ່ານັ້ນ, ແຕ່ສິ່ງສຳຄັນແມ່ນການອອກແບບເພື່ອຊຸກຍູ້ການຕັດສິນໃຈ.

ສຳລັບ Dashboard ຂອງການດຳເນີນງານແບບ HITL, ແນະນຳໃຫ້ບັນຈຸອົງປະກອບຕ່າງໆຢ່າງໜ້ອຍດັ່ງຕໍ່ໄປນີ້:

• ອັດຕາການແຊກແຊງແບບ Real-time: ການປ່ຽນແປງຕາມລຳດັບເວລາໃນຮອບ 1 ຊົ່ວໂມງ, 1 ມື້ ແລະ 1 ອາທິດທີ່ຜ່ານມາ
• ອັດຕາການແກ້ໄຂ ແລະ ການຈັດປະເພດເນື້ອໃນທີ່ແກ້ໄຂ: ເຮັດໃຫ້ເຫັນພາບໝວດໝູ່ທີ່ AI ຕັດສິນໃຈຜິດພາດ ເພື່ອນຳໄປໃຊ້ໃນການຈັດລຳດັບຄວາມສຳຄັນໃນການປັບປຸງ Model
• ເວລາໃນການປະມວນຜົນແຍກຕາມຜູ້ຮັບຜິດຊອບ ແລະ ທີມ: ໃຊ້ເພື່ອລະບຸຈຸດຄໍຂວດ (Bottleneck)
• ຈຳນວນກໍລະນີທີ່ຍັງບໍ່ທັນໄດ້ດຳເນີນການ Escalation: ເພື່ອຮັບຮູ້ຄວາມສ່ຽງຕໍ່ການລະເມີດ SLA ແບບ Real-time

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

ເພື່ອປ້ອງກັນ "Alert Fatigue" (ສະພາບທີ່ມີການແຈ້ງເຕືອນຫຼາຍເກີນໄປຈົນຖືກລະເລີຍ), ມາດຕະການທົ່ວໄປຄືການຈຳກັດຊ່ອງທາງການແຈ້ງເຕືອນ ແລະ ລະດັບຄວາມສຳຄັນໄວ້ປະມານ 3 ລະດັບ:

• P1 (ຕອບສະໜອງທັນທີ): ແຈ້ງເຕືອນຜ່ານ Slack ແລະ ອີເມວພ້ອມກັນ, ໃນກໍລະນີທີ່ມີແນວໂນ້ມວ່າຈະເກີດການລະເມີດ SLA ພາຍໃນ 30 ນາທີ
• P2 (ຕອບສະໜອງພາຍໃນມື້): ແຈ້ງເຕືອນຜ່ານອີເມວ, ໃນກໍລະນີທີ່ອັດຕາການແຊກແຊງເກີນຄ່າພື້ນຖານ 1.5 ເທົ່າ
• P3 (ທົບທວນຕາມຮອບ): ລວບລວມໄວ້ໃນລາຍງານປະຈຳອາທິດ

ສຳລັບສິດທິໃນການເຂົ້າເຖິງ Dashboard, ຄວນພິຈາລະນາແບ່ງຄວາມລະອຽດຂອງຂໍ້ມູນທີ່ສະແດງຕາມກຸ່ມຜູ້ໃຊ້ ເຊັ່ນ: ຜູ້ປະຕິບັດງານ, ຜູ້ຄວບຄຸມຄຸນນະພາບ ແລະ ຜູ້ບໍລິຫານ.

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

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

ຫຼາຍກໍລະນີທີ່ຕັ້ງໃຈຈະນຳໃຊ້ HITL ແຕ່ພັດພົບວ່າຕົກຢູ່ໃນສະຖານະການທີ່ "ມະນຸດຕ້ອງກວດສອບເກືອບທຸກລາຍການ".

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

ສາເຫດຫຼັກທີ່ເຮັດໃຫ້ຄວາມຖີ່ໃນການເຂົ້າແຊກແຊງສູງຂຶ້ນ

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

ຈະເກີດຫຍັງຂຶ້ນຫາກບັນຫາຍືດເຍື້ອໃນໄລຍະຍາວ

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

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

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

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

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

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

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

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

ນອກຈາກນີ້, "ສິດທິໃນການເຂົ້າແຊກແຊງໂດຍມະນຸດ" ທີ່ກຳນົດໄວ້ໃນ EU AI Act (ຄາດວ່າຈະເລີ່ມນຳໃຊ້ໃນປີ 2026) ແລະ GDPR ມາດຕາ 22, ລວມເຖິງ "ແນວທາງປະຕິບັດສຳລັບຜູ້ປະກອບການ AI (ສະບັບທີ 1.0)" ຂອງກະຊວງເສດຖະກິດ, ການຄ້າ ແລະ ອຸດສາຫະກຳ (ເຜີຍແຜ່ໃນເດືອນເມສາ 2024) ຈະເປັນແກນຫຼັກໃນການອ້າງອີງເພື່ອເສີມສ້າງການອອກແບບ HITL ຈາກມຸມມອງຂອງການປະຕິບັດຕາມກົດລະບຽບ (Compliance). ແນະນຳວ່າ ບໍ່ຄວນຈັດການເລື່ອງປະສິດທິພາບການເຮັດວຽກ ແລະ ການຕອບສະໜອງຕໍ່ກົດລະບຽບເປັນວຽກທີ່ແຍກຈາກກັນ, ແຕ່ຄວນລວມເຂົ້າໄປຕັ້ງແຕ່ຂັ້ນຕອນການອອກແບບ ເພື່ອໃຫ້ສາມາດບັນລຸທັງສອງເປົ້າໝາຍໄດ້ດ້ວຍການເຮັດວຽກພຽງຢ່າງດຽວ ຄືການບັນທຶກກົດລະບຽບການແຍກປະເພດ (Branching rules) ເປັນເອກະສານ.