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

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

HITL ແມ່ນຮູບແບບການອອກແບບທີ່ນຳເອົາການຕັດສິນໃຈຂອງມະນຸດເຂົ້າໄປໃນຂະບວນການປະມວນຜົນຂອງ AI. ຈຸດສຳຄັນບໍ່ແມ່ນຢູ່ທີ່ວ່າຈະວາງມະນຸດ "ໄວ້ທີ່ໃດ" ແຕ່ຢູ່ທີ່ "ລຳດັບໃດ" ທີ່ AI ແລະ ມະນຸດຈະມີສ່ວນຮ່ວມ.

ກະແສທີ່ຖືກຕ້ອງຂອງ HITL ແມ່ນ: ອິນພຸດ → AI ປະມວນຜົນ → ການຕັດສິນລະດັບຄວາມໜ້າເຊື່ອຖື → ມະນຸດກວດສອບ → ເອົາພຸດ. AI ຮັບອິນພຸດກ່ອນ ແລ້ວສົ່ງຜົນການປະມວນຜົນໃຫ້ມະນຸດ. ມະນຸດພຽງແຕ່ກວດສອບ ແລະ ແກ້ໄຂຜົນລັບຂອງ AI ເທົ່ານັ້ນ.

ຖ້າຫາກປ່ຽນລໍາດັບນີ້ໂດຍອອກແບບໃຫ້ "ມະນຸດຮັບອິນພຸດກ່ອນ ແລ້ວໃຫ້ AI ກວດສອບ", ມະນຸດຈະຕ້ອງປະມວນຜົນອິນພຸດທັງໝົດດ້ວຍຕົນເອງ. ຖ້າມີຄໍາຖາມ 100 ລາຍການ ກໍ່ຕ້ອງການກໍາລັງຄົນ 100 ລາຍການ, ແລະ ຖ້າເພີ່ມເປັນ 1,000 ລາຍການ ກໍ່ຈະຕ້ອງຮັບສະໝັກພະນັກງານເພີ່ມ 10 ເທົ່າ ຫຼື ຍອມຫຼຸດຄຸນນະພາບການຮັບໃຊ້. ນັ້ນໝາຍຄວາມວ່າ ບໍ່ສາມາດ scale ໄດ້.

ໃນທາງກົງກັນຂ້າມ, ຖ້າອອກແບບໃຫ້ AI ຮັບອິນພຸດ, ກໍລະນີທີ່ມີລະດັບຄວາມໜ້າເຊື່ອຖືສູງ (70〜85% ຂອງທັງໝົດ) ຈະຖືກປະມວນຜົນໂດຍອັດຕະໂນມັດ, ແລະ ມະນຸດຈໍາເປັນຕ້ອງກວດສອບພຽງ 15〜30% ທີ່ເຫຼືອເທົ່ານັ້ນ. ເຖິງແມ່ນວ່າປະລິມານວຽກຈະເພີ່ມຂຶ້ນ 10 ເທົ່າ, ປະລິມານວຽກຂອງມະນຸດກໍ່ຈະບໍ່ເພີ່ມຂຶ້ນ 10 ເທົ່າ. ນີ້ຄືຂໍ້ດີທີ່ໃຫຍ່ທີ່ສຸດຂອງການອອກແບບ HITL.

ໃນການຊ່ວຍເຫຼືອລູກຄ້າຂອງ Unimon Co., Ltd. ດ້ານການ automate ວຽກງານ, ຮູບແບບຄວາມລົ້ມເຫຼວທີ່ພົບເຫັນຫຼາຍທີ່ສຸດຄືການອອກແບບແບບ "ມະນຸດ→AI". ໃນກໍລະນີໜຶ່ງຂອງລູກຄ້າ, ເມື່ອພະຍາຍາມ automate ການຕອບອີເມລ customer support, ຂັ້ນຕອນທີ່ໃຊ້ຄືຜູ້ຮັບຜິດຊອບອ່ານອີເມລກ່ອນ, ຮ່າງຄຳຕອບ, ແລ້ວຈຶ່ງໃຫ້ AI ກວດ grammar ແລະແກ້ໄຂພາສາທາງການ. ຜົນທີ່ໄດ້ຮັບຄືເວລາເຮັດວຽກຂອງຜູ້ຮັບຜິດຊອບແทบຈະບໍ່ປ່ຽນແປງເລີຍ.

ຈາກນັ້ນຈຶ່ງປ່ຽນການອອກແບບໄປເປັນແບບ "AI→ມະນຸດ". ໂດຍໃຊ້ການຮັບອີເມລເປັນ trigger ໃຫ້ AI ສ້າງ draft ຄຳຕອບໂດຍອັດຕະໂນມັດ, ແລ້ວຜູ້ຮັບຜິດຊອບພຽງແຕ່ກວດເນື້ອຫາແລ້ວກົດປຸ່ມສົ່ງ. ຈຳນວນເຄດທີ່ຈັດການໄດ້ຕໍ່ຄົນຕໍ່ວັນເພີ່ມຂຶ້ນຈາກ 40 ເຄດ ເປັນ 120 ເຄດ, ແລະຄຸນນະພາບການຕອບ (customer satisfaction score) ກໍ່ດີຂຶ້ນຈາກ 4.2 → 4.5.

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

ອີງຕາມລະດັບການມີສ່ວນຮ່ວມຂອງ AI ແລະ ມະນຸດ, ມີ 3 ຮູບແບບດັ່ງນີ້.

Human-in-the-Loop（HITL） ແມ່ນຮູບແບບທີ່ມະນຸດກວດສອບ ແລະ ອະນຸມັດຜົນການປະມວນຜົນຂອງ AI. ຖືກນຳໃຊ້ໃນຂົງເຂດທີ່ບໍ່ອະນຸຍາດໃຫ້ເກີດຄວາມຜິດພາດ ເຊັ່ນ: ການຕັດສິນໃຈຂັ້ນສຸດທ້າຍດ້ານການວິນິດໄສທາງການແພດ, ການອະນຸມັດສິນເຊື່ອ, ແລະ ການກວດທານເອກະສານທາງກົດໝາຍ. ອັດຕາການແຊກແຊງຂອງມະນຸດແມ່ນຢູ່ທີ່ປະມານ 15〜30%.

Human-on-the-Loop（HOTL） ແມ່ນຮູບແບບທີ່ AI ດຳເນີນການປະມວນຜົນຢ່າງອິດສະລະ, ໃນຂະນະທີ່ມະນຸດເຝົ້າລະວັງໂດຍການຕິດຕາມ dashboard ໃນຖານະຜູ້ກວດກາ. ມະນຸດຈະແຊກແຊງສະເພາະເມື່ອມີການແຈ້ງເຕືອນຈາກລະບົບກວດຈັບຄວາມຜິດປົກກະຕິ. ການຄວບຄຸມຄຸນນະພາບໃນໂຮງງານ ແລະ ການຕິດຕາມເຄືອຂ່າຍແມ່ນຕົວຢ່າງຂອງຮູບແບບນີ້.

Human-out-of-the-Loop（HOOTL） ແມ່ນການອັດຕະໂນມັດຢ່າງສົມບູນທີ່ມະນຸດແทบຈະບໍ່ມີສ່ວນຮ່ວມ. spam filter ແລະ ການແປງຂໍ້ມູນຕາມຮູບແບບທີ່ກຳນົດໄວ້ແມ່ນຕົວຢ່າງຂອງຮູບແບບນີ້. ຢ່າງໃດກໍຕາມ, ວຽກງານທີ່ສາມາດນຳໃຊ້ HOOTL ໄດ້ນັ້ນມີຈຳກັດ, ແລະ ໃນຄວາມເປັນຈິງ ວຽກງານສ່ວນໃຫຍ່ຄວນເລີ່ມຕົ້ນດ້ວຍ HITL ຫຼື HOTL.

ສິ່ງທີ່ທຸກຮູບແບບມີຮ່ວມກັນ ຄື AI ເປັນຜູ້ຮັບ input ເປັນອັນດັບທຳອິດ. ການອອກແບບທີ່ໃຫ້ມະນຸດປະມວນຜົນ input ກ່ອນນັ້ນ ບໍ່ໄດ້ຖືກລວມຢູ່ໃນຮູບແບບໃດໆ ທັງໝົດ.

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

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

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

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

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

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

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

ຄາດການວ່າຂະໜາດຕະຫຼາດ HITL AI ຈະເຕີບໂຕຈາກ 5.4 ພັນລ້ານໂດລາໃນປີ 2025 ໄປເຖິງ 16.4 ພັນລ້ານໂດລາໃນປີ 2030 (CAGR 24.9%). Gartner ຄາດການວ່າພາຍໃນປີ 2027 ບໍລິສັດ 86% ຈະນຳໃຊ້ AI agent ໂດຍສ່ວນໃຫຍ່ຄາດວ່າຈະຮັບເອົາການອອກແບບ HITL ໃນຮູບແບບໃດໜຶ່ງ.

ສິ່ງທີ່ໜ້າສັງເກດຄືການເຕີບໂຕນີ້ຖືກຂັບເຄື່ອນໂດຍ «ການອອກແບບການຮ່ວມມືລະຫວ່າງ AI ແລະ ມະນຸດ» ບໍ່ແມ່ນ «ການປັບປຸງຄວາມແມ່ນຍຳຂອງ AI». ເຖິງແມ່ນວ່າ AI ຢ່າງດຽວຈະມີຄວາມແມ່ນຍຳ 95% ກໍຕາມ ແຕ່ໃນວຽກງານທີ່ສຳຄັນທາງທຸລະກິດຕ້ອງການຄວາມແມ່ນຍຳ 99.8% ຂຶ້ນໄປ. ສ່ວນທີ່ຂາດຫາຍໄປ 4.8% ນັ້ນຖືກຕື່ມໂດຍການກວດສອບຂອງມະນຸດ ແລະ ມີຫຼາຍກໍລະນີທີ່ລາຍງານວ່າການອອກແບບ HITL ສາມາດຍົກລະດັບຄວາມແມ່ນຍຳໂດຍລວມໄດ້ເຖິງ 99.8%.

ໃນກອບການຄຸ້ມຄອງຄວາມສ່ຽງ AI ຂອງກະຊວງການເງິນສະຫະລັດ (AI Risk Management Framework) ທີ່ເຜີຍແຜ່ໃນເດືອນກຸມພາ 2026 (ມີ 230 ເປົ້າໝາຍການຄຸ້ມຄອງ) HITL ຍັງຖືກກຳນົດໃຫ້ເປັນ «ຂໍ້ກຳນົດທີ່ຈຳເປັນສຳລັບລະບົບ AI ທີ່ມີຄວາມສ່ຽງສູງ». ໃນດ້ານກົດລະບຽບ HITL ກຳລັງກາຍເປັນການອອກແບບທີ່ «ຕ້ອງມີ» ບໍ່ແມ່ນ «ມີກໍດີ».

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

ການຈັດເສັ້ນທາງຕາມລະດັບຄວາມໜ້າເຊື່ອຖື (Confidence Routing) ແມ່ນການແຍກສາຂາການປະມວນຜົນໂດຍອີງໃສ່ຄະແນນຄວາມໜ້າເຊື່ອຖື (0〜1.0) ທີ່ມອບໃຫ້ກັບຜົນລັບຂອງ AI. ການອອກແບບຄ່າເກນທົ່ວໄປມີ 3 ລະດັບ.

ກໍລະນີທີ່ຄວາມໜ້າເຊື່ອຖື 0.85 ຂຶ້ນໄປ ຖືວ່າ "ອະນຸມັດອັດຕະໂນມັດ". ຜົນລັບຂອງ AI ຈະກາຍເປັນຜົນສຸດທ້າຍໂດຍກົງ. ຕົວຢ່າງໄດ້ແກ່ ການອ່ານລາຍການມາດຕະຖານໃນໃບແຈ້ງໜີ້ ຫຼື ການຈັດໝວດໝູ່ອີເມລ໌ສະແປມທີ່ຊັດເຈນ. ໃນທາງທີ່ດີ ຄວນມີ 70〜85% ຂອງທັງໝົດຢູ່ໃນໂຊນນີ້.

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

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

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

ສິ່ງທີ່ມັກຖືກມອງຂ້າມໃນ confidence-based routing ຄືການ fallback ເມື່ອ AI ຕອບສະໜອງລ່າຊ້າ. ກໍລະນີທີ່ AI ບໍ່ສາມາດສົ່ງຄຳຕອບໄດ້ພາຍໃນເວລາທີ່ກຳນົດ ເນື່ອງຈາກ load ຂອງ model ສູງ ຫຼື ເຄືອຂ່າຍຂັດຂ້ອງ ແມ່ນສິ່ງທີ່ຕ້ອງເກີດຂຶ້ນໃນ production environment ຢ່າງແນ່ນອນ.

ຄ່າ threshold ຂອງ timeout ຈະແຕກຕ່າງກັນໄປຕາມລັກສະນະຂອງວຽກງານ. ສຳລັບ real-time chat ອາດຈະເປັນສອງສາມວິນາທີ, ສ່ວນ batch processing ອາດຈະເປັນສອງສາມນາທີ. ສິ່ງສຳຄັນຄືການອອກແບບລະບົບໃຫ້ສົ່ງຕໍ່ໄປຍັງ queue ຂອງມະນຸດໂດຍອັດຕະໂນມັດທັນທີທີ່ເກີນ threshold. ສຳລັບ chatbot ໃຫ້ສະແດງຂໍ້ຄວາມວ່າ "ກຳລັງໂອນສາຍໄປຫາເຈົ້າໜ້າທີ່" ແລ້ວສ່ຽງໄປ, ສ່ວນ batch processing ໃຫ້ເພີ່ມເຂົ້າໃນ manual review queue.

ການອອກແບບດ້ວຍວິທີນີ້ຊ່ວຍປ້ອງກັນສະຖານະການ "ເມື່ອ AI ຢຸດ, service ກໍຢຸດ". ໂຄງສ້າງທີ່ໃຫ້ມະນຸດທຳໜ້າທີ່ເປັນ backup ຢູ່ສະເໝີ ຄືທີ່ມາຂອງຄວາມເຂັ້ມແຂງໃນການອອກແບບ HITL. ຄວນ monitor ອັດຕາການເກີດ fallback ຢ່າງສະໝ່ຳສະເໝີ, ແລະຫາກເກີດຂຶ້ນຖີ່ເກີນໄປ ໃຫ້ພິຈາລະນາປັບປຸງ model ຫຼືເສີມຂະຫຍາຍ infrastructure.

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

ລະບົບວິເຄາະສັນຍາ COiN (Contract Intelligence) ຂອງ J.P.Morgan ແມ່ນຕົວຢ່າງທີ່ເປັນຕົວແທນຂອງການອອກແບບ HITL. AI ອ່ານສັນຍາສິນເຊື່ອທາງການຄ້າຫຼາຍກວ່າ 12,000 ສະບັບຕໍ່ປີ ແລະ ດຶງເອົາຂໍ້ກຳນົດສຳຄັນໂດຍອັດຕະໂນມັດ. ໃນເມື່ອກ່ອນ ທະນາຍຄວາມ ແລະ ເຈົ້າໜ້າທີ່ສິນເຊື່ອຕ້ອງໃຊ້ເວລາ 360,000 ຊົ່ວໂມງຕໍ່ປີສຳລັບວຽກງານດັ່ງກ່າວ.

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

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

ໃນໂຮງງານຜູ້ຜະລິດຊິ້ນສ່ວນລົດຍົນແຫ່ງໜຶ່ງ, ໄດ້ນຳໃຊ້ HITL ໃນການກວດສອບລັກສະນະພາຍນອກ. ໃນເມື່ອກ່ອນ, ພະນັກງານກວດສອບ 8 ຄົນໄດ້ກວດສອບດ້ວຍສາຍຕາປະມານ 5,000 ຊິ້ນຕໍ່ວັນ. ອັດຕາການພາດສິນຄ້າບົກຜ່ອງຢູ່ທີ່ 0.3%, ສົ່ງຜົນໃຫ້ສິນຄ້າບົກຜ່ອງປະມານ 5,500 ຊິ້ນຖືກສົ່ງອອກໄປໃນແຕ່ລະປີ.

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

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

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

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

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

ມີກໍລະນີທີ່ການນຳໃຊ້ HITL ບໍ່ໄດ້ຜົນຕາມທີ່ຄາດຫວັງ. ຜູ້ຂຽນຂໍນຳສະເໜີ 4 ຮູບແບບຄວາມລົ້ມເຫຼວທີ່ໄດ້ພົບເຫັນໃນພາກສະໜາມ. ທັງໝົດນີ້ລ້ວນແລ້ວແຕ່ສາມາດຫຼີກລ່ຽງໄດ້ໃນຂັ້ນຕອນການອອກແບບ.

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

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

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

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

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

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

ເປັນຕົວຊີ້ວັດ, ຖ້າຫຼັງຈາກນຳໃຊ້ໄດ້ 3 ເດືອນແລ້ວ ອັດຕາການແຊກແຊງຍັງບໍ່ຫຼຸດລົງຕ່ຳກວ່າ 30%, ໝາຍຄວາມວ່າມີບັນຫາຢູ່ທີ່ໂມເດລ ຫຼື threshold ຢ່າງໃດຢ່າງໜຶ່ງ.

ບ່ອນຕົກຢ່າງທີ່ຄາດບໍ່ເຖິງຄື "automation bias" (ອະຄະຕິຈາກລະບົບອັດຕະໂນມັດ). ເມື່ອຜົນການຕັດສິນຂອງ AI ຖືກສະແດງຢູ່ຕະຫຼອດເວລາ, ມະນຸດຈະເລີ່ມຍອມຮັບການຕັດສິນຂອງ AI ໂດຍບໍ່ມີການວິພາກວິຈານ. ໂດຍສະເພາະໃນ "grey zone" ທີ່ມີຄ່າຄວາມໜ້າເຊື່ອຖື 0.70〜0.85, ກໍລະນີທີ່ຄວນກວດສອບຢ່າງລະມັດລະວັງກໍຈະຖືກປ່ອຍຜ່ານໄປດ້ວຍຄວາມຄິດທີ່ວ່າ "AI ບອກວ່າ OK ແລ້ວ ກໍ່ໜ້າຈະບໍ່ເປັນຫຍັງ".

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

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

ກອບການຄຸ້ມຄອງຄວາມສ່ຽງ AI ທີ່ກະຊວງການຄັງສະຫະລັດ (米財務省) ເຜີຍແຜ່ໃນເດືອນກຸມພາ 2026 ໄດ້ກຳນົດເປົ້າໝາຍການຄວບຄຸມໄວ້ 230 ລາຍການ. ໃນນັ້ນ, ຂໍ້ກຳນົດທີ່ກ່ຽວຂ້ອງກັບ HITL ມີ 3 ຢ່າງ ຄື: ການເກັບຮັກສາ audit log, ຄວາມສາມາດອະທິບາຍເຫດຜົນຂອງການຕັດສິນໃຈ (explainability), ແລະ ການກວດຈັບ bias.

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

ໃນຖານະ governance ຂັ້ນຕ່ຳສຸດ, ໃຫ້ຝັງລະບົບທີ່ບັນທຶກ log ຂໍ້ມູນທັງໝົດໄວ້ຕັ້ງແຕ່ຕອນຕິດຕັ້ງ ໄດ້ແກ່: ຂໍ້ມູນ input ຂອງ AI, ຜົນ output, ຄະແນນຄວາມໜ້າເຊື່ອຖື (confidence score), ເນື້ອໃນທີ່ມະນຸດແກ້ໄຂ, ແລະ ການຕັດສິນໃຈສຸດທ້າຍ. ການເພີ່ມຟັງຊັນ log ໃນພາຍຫຼັງຈະມີຄ່າໃຊ້ຈ່າຍສູງໃນການປ່ຽນແປງການອອກແບບ.

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

ກ່ອນອື່ນ, ໃຫ້ລະບຸ "ຈຸດເຂົ້າ" ຂອງຂະບວນການທຸລະກິດທີ່ຕ້ອງການ Automate. ຈຸດເຂົ້າ ໝາຍເຖິງຈຸດທີ່ Input ຈາກພາຍນອກໄຫຼເຂົ້າມາ. ເຊັ່ນ: ການຮັບອີເມລ, ການ Upload ໃບຄຳຮ້ອງ, ການສົ່ງ Form ສອບຖາມ, ການດຶງຂໍ້ມູນ Sensor ເປັນຕົ້ນ.

ການທີ່ຈະວາງ AI ໄວ້ທີ່ຈຸດເຂົ້ານີ້ໄດ້ຫຼືບໍ່ ຈະເປັນຕົວກຳນົດວ່າຈະນຳໃຊ້ HITL ໄດ້ຫຼືບໍ່. ຫາກຂໍ້ມູນທີ່ຈຸດເຂົ້າເປັນ Structured Data (CSV, JSON, Form ມາດຕະຖານ) ກໍ່ຈະນຳໃຊ້ໄດ້ງ່າຍ. ສຳລັບ Unstructured Data (ອີເມລທີ່ຂຽນແບບອິດສະຫຼະ, ຮູບພາບເອກະສານລາຍມືຂຽນ) ກໍ່ມີກໍລະນີທີ່ສາມາດຮອງຮັບໄດ້ຫຼາຍຂຶ້ນດ້ວຍ LLM ລຸ້ນໃໝ່ຫຼືການຮັບຮູ້ຮູບພາບ.

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

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

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

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

ກ່ອນທີ່ຈະນຳໃຊ້ທົ່ວທັງອົງກອນ, ໃຫ້ດຳເນີນການທົດລອງໃຊ້ງານ (パイロット運用) ໃນພະແນກດຽວ ຫຼື ຂະບວນການທຸລະກິດດຽວກ່ອນ. ໄລຍະເວລາທີ່ແນະນຳແມ່ນປະມານ 2〜3 ເດືອນ.

ຕົວຊີ້ວັດທີ່ຕ້ອງກວດສອບໃນຊ່ວງ パイロット ມີ 4 ຢ່າງ, ໄດ້ແກ່: ຄວາມໄວໃນການປະມວນຜົນ (Before/After), ຄວາມຖືກຕ້ອງ (ອັດຕາການຕັດສິນຜິດພາດ), ອັດຕາການແຊກແຊງ (ສັດສ່ວນທີ່ມະນຸດທົບທວນ), ແລະ ຄວາມພໍໃຈຂອງຜູ້ໃຊ້ (ທັງຝ່າຍຜູ້ຮັບຜິດຊອບ ແລະ ລູກຄ້າ). ໃຫ້ວັດແທກຕົວຊີ້ວັດເຫຼົ່ານີ້ເປັນລາຍອາທິດ ແລະ ປັບ threshold ແລະ ກົດລະບຽບຕ່າງໆຕາມຄວາມເໝາະສົມ.

ຈາກປະສົບການຂອງຜູ້ຂຽນ, ໃນຊ່ວງ パイロット ນັ້ນ ປົກກະຕິຈະຕ້ອງປັບ threshold ປະມານ 3〜5 ຄັ້ງ. ເປັນເລື່ອງຫາຍາກທີ່ threshold ທີ່ຕັ້ງໄວ້ໃນຕອນຕົ້ນຈະສາມາດໃຊ້ງານໄດ້ໂດຍກົງໃນລະບົບຕົວຈິງ, ດັ່ງນັ້ນຈຶ່ງຕ້ອງຄ່ອຍໆຫາຄ່າທີ່ດີທີ່ສຸດໂດຍການກວດສອບດ້ວຍຂໍ້ມູນຈິງ. ແນວຄິດທີ່ວ່າ "ບໍ່ຕ້ອງຫວັງຄວາມສົມບູນແບບຕັ້ງແຕ່ຕົ້ນ" ກໍ່ມີຄວາມສຳຄັນຢູ່ທີ່ນີ້ເຊັ່ນກັນ.

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

ໃນທາງປະຕິບັດ, ເນື້ອຫາທີ່ມະນຸດແກ້ໄຂໃນລະຫວ່າງການທົບທວນຈະຖືກເພີ່ມເຂົ້າໃນຊຸດຂໍ້ມູນການຮຽນຮູ້ໂດຍອັດຕະໂນມັດ, ແລະ model ຈະຖືກ re-train ຢ່າງເປັນປົກກະຕິ (ລາຍເດືອນ ຫຼື ລາຍໄຕມາດ). ໃນກໍລະນີຂອງ J.P.Morgan, feedback loop ນີ້ໄດ້ເຮັດໃຫ້ອັດຕາການແຊກແຊງຫຼຸດລົງຈາກ 35% ເປັນ 12% ພາຍໃນ 3 ປີ.

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

ຖ້າຜົນໄດ້ຮັບຈາກ pilot ໄດ້ຮັບການຢືນຢັນແລ້ວ, ໃຫ້ກຽມ governance framework ສຳລັບການນຳໃຊ້ຕົວຈິງ. ອົງປະກອບຂັ້ນຕ່ຳທີ່ຈຳເປັນມີ 4 ຢ່າງດັ່ງນີ້.

audit log: ບັນທຶກ input/output ຂອງ AI, ຄະແນນຄວາມໜ້າເຊື່ອຖື (confidence score), ການແກ້ໄຂຂອງມະນຸດ, ແລະການຕັດສິນໃຈສຸດທ້າຍ. ກຳນົດໄລຍະເວລາການເກັບຮັກສາໃຫ້ສອດຄ່ອງກັບລະບຽບຂໍ້ກຳນົດຂອງອຸດສາຫະກຳ (ສຳລັບການເງິນ ຕ້ອງ 7 ປີຂຶ້ນໄປ).

ຄວາມສາມາດໃນການອະທິບາຍ (Explainability): ກຽມກົນໄກທີ່ສາມາດອະທິບາຍໄດ້ວ່າເປັນຫຍັງ AI ຈຶ່ງຕັດສິນໃຈດັ່ງກ່າວ ແມ່ນແຕ່ຜູ້ທີ່ບໍ່ມີຄວາມຮູ້ດ້ານເຕັກນິກ. ການສະແດງຜົນ feature importance ແລະການສ້າງຂໍ້ຄວາມອ້າງອີງການຕັດສິນໃຈແມ່ນມີປະສິດທິຜົນ.

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

ການຮັບມືກັບ incident (Incident response): ກຳນົດຂັ້ນຕອນການຮັບມືລ່ວງໜ້າໃນກໍລະນີທີ່ການຕັດສິນຜິດພາດຂອງ AI ສົ່ງຜົນກະທົບຮ້າຍແຮງ. ໃຫ້ບັນທຶກເປັນລາຍລັກອັກສອນກ່ຽວກັບ escalation path, ຂັ້ນຕອນການລະບຸຂອບເຂດຜົນກະທົບ, ແລະກະບວນການວາງແຜນມາດຕະການປ້ອງກັນການເກີດຊ້ຳ.

ຕອບຄຳຖາມທີ່ມັກຖືກຖາມເລື້ອຍໆໃນເວລາພິຈາລະນານຳໃຊ້ HITL.

ຈຳເປັນຕ້ອງໄດ້ຮັບການອອກແບບຢ່າງຖືກຕ້ອງ. ຖ້າອອກແບບຢ່າງຖືກຕ້ອງ, ກໍລະນີທີ່ມະນຸດຕ້ອງກວດສອບຈະຖືກຈຳກັດໃຫ້ເຫຼືອພຽງ 15〜30% ຂອງທັງໝົດ. ສ່ວນທີ່ເຫຼືອ 70〜85% ນັ້ນ AI ຈະດຳເນີນການໂດຍອັດຕະໂນມັດ. ກ່າວຄື, ກ່ອນທີ່ຈະນຳໃຊ້ HITL ນັ້ນ ມະນຸດຕ້ອງດຳເນີນການທັງ 100 ກໍລະນີ, ແຕ່ຫຼັງຈາກນຳໃຊ້ແລ້ວ ຈະຕ້ອງກວດສອບພຽງ 15〜30 ກໍລະນີເທົ່ານັ້ນ.

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

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

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

RAG（Retrieval-Augmented Generation）ແມ່ນເທັກໂນໂລຊີທີ່ AI ຄົ້ນຫາ ແລະ ອ້າງອີງຂໍ້ມູນທີ່ກ່ຽວຂ້ອງຈາກຖານຂໍ້ມູນພາຍນອກໃນຂະນະທີ່ສ້າງຄຳຕອບ, ແລະ ມີຄວາມສຳພັນເສີມເຕີມກັນກັບ HITL. ໃນທາງປະຕິບັດ, ການປະສົມປະສານທີ່ພົບເຫັນຫຼາຍຄືການໃຊ້ RAG ເພື່ອເພີ່ມຄວາມຖືກຕ້ອງຂອງຄຳຕອບຂອງ AI, ໃນຂະນະທີ່ໃຊ້ HITL ເພື່ອຮັບປະກັນຄຸນນະພາບຂັ້ນສຸດທ້າຍ.

ຕົວຢ່າງເຊັ່ນ, ໃນກໍລະນີຂອງ chatbot ພາຍໃນອົງກອນທີ່ອ້າງອີງ knowledge base ພາຍໃນໂດຍໃຊ້ RAG, RAG ຈະຄົ້ນຫາເອກະສານທີ່ເໝາະສົມ ແລະ AI ຈະສ້າງຄຳຕອບ. ຖ້າລະດັບຄວາມໜ້າເຊື່ອຖືສູງ, ລະບົບຈະຕອບໂດຍກົງ, ແຕ່ຖ້າຕ່ຳ, ຜູ້ຮັບຜິດຊອບຈະທົບທວນກ່ອນຕອບ. RAG ຊ່ວຍຫຼຸດ hallucination（ການສ້າງຄຳຕອບທີ່ບໍ່ຕົງກັບຄວາມເປັນຈິງ）ໄດ້ 96%, ໃນຂະນະທີ່ HITL ຊ່ວຍໃຫ້ມະນຸດຄຸ້ມຄອງຄຳຕອບທີ່ຍັງບໍ່ແນ່ນອນທີ່ເຫຼືອຢູ່. ມີກໍລະນີສຶກສາທີ່ສາມາດບັນລຸຄວາມຖືກຕ້ອງຂອງຄຳຕອບ 99.8% ດ້ວຍການປ້ອງກັນສອງຊັ້ນນີ້.

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

ສິ່ງທີ່ຄວນເລີ່ມຕົ້ນກ່ອນຄື ການລະບຸ "ຈຸດຮັບ input" ໜຶ່ງຈຸດໃນ process ການເຮັດວຽກຂອງຕົນເອງ ແລ້ວເລີ່ມ PoC ຂະໜາດນ້ອຍໂດຍວາງ AI ໄວ້ທີ່ຈຸດນັ້ນ. ເລີ່ມ threshold ທີ່ 0.85, ໄລຍະ pilot ທີ່ 2 ເດືອນ. ບໍ່ຈຳເປັນຕ້ອງສົມບູນແບບ. ເມື່ອ feedback loop ເລີ່ມໝູນວຽນ, ຄວາມຖືກຕ້ອງກໍ່ຈະດີຂຶ້ນໄປພ້ອມກັບການດຳເນີນງານ.

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