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

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

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

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

ໃນທີ່ນີ້, ກ່ອນອື່ນໝົດພວກເຮົາຈະມາທຳຄວາມເຂົ້າໃຈກ່ຽວກັບນິຍາມ ແລະ ກົນໄກທາງຈິດວິທະຍາ, ພ້ອມທັງຈັດລະບຽບຄວາມແຕກຕ່າງລະຫວ່າງອະຄະຕິດ້ານອັດຕະໂນມັດກັບຄວາມເພິ່ງພໍໃຈໃນລະບົບອັດຕະໂນມັດ (automation complacency) ແລະ ອະຄະຕິຢືນຢັນ (confirmation bias) ທີ່ມັກຈະຖືກນຳມາປົນກັນເລື້ອຍໆ.

ອະຄະຕິດ້ານການອັດຕະໂນມັດ (Automation bias) ແມ່ນຄຳສັບທີ່ Mosier ແລະ ຄະນະ ໄດ້ນຳມາສ້າງເປັນແນວຄວາມຄິດໃນບົດວິໄຈຊ່ວງປີ 1990 ເຊິ່ງໝາຍເຖິງການທີ່ມະນຸດມອງຂ້າມການຕັດສິນໃຈຂອງລະບົບອັດຕະໂນມັດທັງໃນສອງທິດທາງ ຄື: "Commission error" (ການຍອມຮັບຄຳແນະນຳທີ່ຜິດພາດ) ແລະ "Omission error" (ການບໍ່ສັງເກດເຫັນບັນຫາທີ່ລະບົບພາດໄປ).

ປັດໄຈຫຼັກທີ່ເຮັດໃຫ້ເກີດຄວາມເຊື່ອໝັ້ນຫຼາຍເກີນໄປມີ 3 ປະການດັ່ງນີ້:

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

ສະຫຼຸບກໍຄື ອະຄະຕິດ້ານການອັດຕະໂນມັດ ບໍ່ແມ່ນ "ບັນຫາດ້ານຄວາມແມ່ນຍຳຂອງ AI", ແຕ່ຄວນເບິ່ງວ່າເປັນບັນຫາລະຫວ່າງມະນຸດກັບອິນເຕີເຟດຂອງ AI (ອ້າງອີງ: CSET: AI Safety and Automation Bias).

ເນື່ອງຈາກຄຳສັບເຫຼົ່ານີ້ມັກຈະຖືກນຳໄປໃຊ້ປົນກັນ, ດັ່ງນັ້ນຈຶ່ງຂໍນຳມາຈັດໝວດໝູ່ໄວ້ໃນທີ່ນີ້.

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

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

ໃນສະໄໝທີ່ AI Chat ແລະ RAG ຍັງເປັນພຽງ "ເຄື່ອງມືຊ່ວຍເຫຼືອ", ການຕັດສິນໃຈຂັ້ນສຸດທ້າຍຂອງມະນຸດແມ່ນສິ່ງທີ່ຂາດບໍ່ໄດ້. ແຕ່ເມື່ອ AI Agent ເລີ່ມປະຕິບັດວຽກງານໄດ້ດ້ວຍຕົນເອງ, ໃຜຈະເປັນຜູ້ກວດສອບໃນຂັ້ນຕອນໃດນັ້ນ ຈຶ່ງກາຍເປັນບັນຫາດ້ານການອອກແບບ. ຫາກປ່ອຍໃຫ້ເລື່ອງນີ້ບໍ່ຈະແຈ້ງໃນຂະນະທີ່ນຳໄປໃຊ້ງານຈິງ, ຄວາມລຳອຽງຈາກການອັດຕະໂນມັດ (Automation Bias) ຈະກາຍເປັນບັນຫາທັງໃນດ້ານການປະຕິບັດຕາມກົດລະບຽບ (Compliance) ແລະ ການກວດສອບ (Audit).

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

ໃນກໍລະນີນີ້, ຮູບແບບທີ່ມັກຈະເກີດຂຶ້ນມີດັ່ງນີ້:

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

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

ກົດລະບຽບດ້ານ AI Governance ເຊັ່ນ EU AI Act ແລະ ISO/IEC 42001 ຕ່າງກໍ່ກຳນົດໃຫ້ມີ "ການກວດກາໂດຍມະນຸດຢ່າງມີຄວາມໝາຍ (meaningful human oversight)" ຮ່ວມກັນ. ການດຳເນີນງານທີ່ພຽງແຕ່ກົດປຸ່ມອະນຸມັດຢ່າງເປັນທາງການ ອາດຈະບໍ່ຖືວ່າເປັນການຕອບສະໜອງ "ການກວດກາຢ່າງມີຄວາມໝາຍ" ດັ່ງກ່າວ.

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

ຫາກທ່ານກຳລັງດຳເນີນການຈັດຕັ້ງ AI Governance ພາຍໃນອົງກອນ ສາມາດກວດສອບພາບລວມໄດ້ທີ່ AI Governance ແມ່ນຫຍັງ? ຄູ່ມືປະຕິບັດຕັ້ງແຕ່ການຮັບມືກັບ EU AI Act ຈົນເຖິງການຈັດລະບຽບກົດລະບຽບພາຍໃນ ກ່ອນ ແລ້ວຈຶ່ງນຳໄປຈັດລຽງໃສ່ໃນຊັ້ນມາດຕະການຂອງບົດຄວາມນີ້ ຈະຊ່ວຍໃຫ້ຈັດລະບຽບໄດ້ງ່າຍຂຶ້ນ.

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

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

ຕົວຢ່າງທີ່ພົບເຫັນໄດ້ທົ່ວໄປ:

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

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

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

ສັນຍານຂອງການສູນເສຍຄວາມໝາຍ:

• ປຸ່ມອະນຸມັດໃຊ້ຄຳສັບທີ່ເປັນກາງ ເຊັ່ນ "ຕໍ່ໄປ" ໂດຍບໍ່ໄດ້ກະຕຸ້ນໃຫ້ມີການກວດສອບ.
• ເວລາທົບທວນຕໍ່ 1 ລາຍການ ໜ້ອຍກວ່າ 5 ວິນາທີ ແລະ ການດຳເນີນງານກາຍເປັນການຄລິກໂດຍບໍ່ໄດ້ເບິ່ງ.
• ອັດຕາການປະຕິເສດຕໍ່າກວ່າ 1% ຢ່າງຕໍ່ເນື່ອງ ສະແດງໃຫ້ເຫັນວ່າຜູ້ທົບທວນເຂົ້າສູ່ໂໝດ "ຜ່ານໄປກ່ອນ".

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

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

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

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

ສຳລັບການປະສົມປະສານລະຫວ່າງການປັບແຕ່ງແຈ້ງເຕືອນ ແລະ ການຕິດຕາມກວດກາ AI, ທ່ານສາມາດອ້າງອີງເພີ່ມເຕີມໄດ້ທີ່ AI ອອບເຊີເວບິລິຕີ້ (AI Observability) ແມ່ນຫຍັງ? ກົນໄກ ແລະ ຄູ່ມືການປະຕິບັດຕົວຈິງໃນການຕິດຕາມກວດກາ LLM ໃນການນຳໃຊ້ງານຈິງ.

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

ໃນຊັ້ນການກຳກັບດູແລ (Governance layer), ຈະຕ້ອງມີການລະບຸໃຫ້ຊັດເຈນວ່າ ໃຜ, ການຕັດສິນໃຈໃດ, ແລະ ຄວນມອບໝາຍໃຫ້ AI ຫຼາຍໜ້ອຍພຽງໃດ.

ລາຍການທີ່ຄວນກຳນົດໄວ້ເປັນຢ່າງໜ້ອຍ:

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

ເພື່ອບໍ່ໃຫ້ເອກະສານທີ່ຂຽນໄວ້ນີ້ຖືກເກັບໄວ້ໃນລິ້ນຊັກໂດຍບໍ່ໄດ້ນຳໃຊ້, ຈຳເປັນຕ້ອງມີການເຊື່ອມໂຍງເຂົ້າກັບຊັ້ນການດຳເນີນງານ (Operational layer) ແລະ UI ທີ່ຈະກ່າວເຖິງຕໍ່ໄປ.

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

ມັນຈະງ່າຍຂຶ້ນຖ້າຈັດລະບຽບ confidence ທີ່ຄວນຈັດການໃນ UI ອອກເປັນ 2 ປະເພດດັ່ງນີ້:

• Model confidence: ການປະເມີນຕົນເອງຂອງຕົວແບບ ໂດຍອີງໃສ່ຄວາມໜ້າຈະເປັນຂອງຜົນລວມ ຫຼື ຄ່າ Log-likelihood.
• Verification confidence: ການປະເມີນໂດຍຂະບວນການ ຫຼື Pipeline ການກວດສອບໃນຂັ້ນຕອນຫຼັງ ເຊັ່ນ: ຜົນລວມນັ້ນໄດ້ຮັບການຢືນຢັນຈາກແຫຼ່ງຂໍ້ມູນຕົ້ນສະບັບ ຫຼື ພົບໃນການຄົ້ນຫາແບບ Vector ຫຼື ບໍ່.

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

ໃນກໍລະນີທີ່ປະສົມປະສານກັບການປະຕິບັດງານດ້ານ Guardrail, ກະລຸນາອ້າງອີງ AI Guardrail Implementation Guide — ວິທີການອອກແບບຮົ້ວກັ້ນຄວາມປອດໄພໃຫ້ກັບແອັບພລິເຄຊັນ LLM ຄວບຄູ່ກັນໄປ.

ໃນຊັ້ນການດຳເນີນງານ (Operation layer), ຄວນມີກົນໄກໃນການກວດສອບຍ້ອນຫຼັງວ່າເກີດອະຄະຕິຈາກລະບົບອັດຕະໂນມັດ (Automation bias) ຫຼືບໍ່. ຖ້າບໍ່ສາມາດກວດສອບໄດ້, ອະຄະຕິດັ່ງກ່າວຈະຖືກປ່ອຍປະລະເລີຍໂດຍຖືວ່າເປັນ "ຄວາມຮູ້ສຶກໄປເອງ".

ສິ່ງທີ່ຄວນກຽມພ້ອມໃນມຸມມອງຂອງການຈັດຕັ້ງປະຕິບັດ:

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

ເນື່ອງຈາກສິ່ງເຫຼົ່ານີ້ເບິ່ງເຫັນໄດ້ຍາກໃນເຄື່ອງມື BI ມາດຕະຖານ, ການສ້າງແຜງຄວບຄຸມ (Dashboard) ສະເພາະສຳລັບ AI ຕັ້ງແຕ່ຕົ້ນຈະຊ່ວຍຫຼຸດພາລະໃນການດຳເນີນງານໄດ້. ສຳລັບການຕິດຕາມກວດສອບຜົນລວມຂອງ LLM ໂດຍລວມ, ກະລຸນາເບິ່ງທີ່ AI ອອບເຊີເວບິລິຕີ້ (AI Observability) ແມ່ນຫຍັງ? ກົນໄກການຕິດຕາມກວດສອບ LLM ໃນການດຳເນີນງານຈິງ ແລະ ຄູ່ມືການປະຕິບັດ.

ການສະແດງຄ່າ confidence ເປັນຕົວເລກເຊັ່ນ "78%" ໂດຍກົງນັ້ນ ຜູ້ໃຊ້ຈະບໍ່ສາມາດເຂົ້າໃຈຄວາມໝາຍຂອງຕົວເລກດັ່ງກ່າວໄດ້. ສິ່ງທີ່ສຳຄັນແມ່ນ UI ຕ້ອງແນະນຳວ່າ "ຄວນນຳໄປໃຊ້ໃນການຕັດສິນໃຈແນວໃດ". ໃນທີ່ນີ້ ຈະຂໍແນະນຳ 2 ຮູບແບບການຈັດຕັ້ງປະຕິບັດທີ່ນຳໃຊ້ໄດ້ຈິງໃນໜ້າວຽກ.

ຄ່າຄວາມເຊື່ອໝັ້ນ (confidence) ທີ່ເປັນຄ່າຕໍ່ເນື່ອງນັ້ນຍາກທີ່ມະນຸດຈະເຂົ້າໃຈໄດ້ຢ່າງເປັນທຳມະຊາດ. ການປ່ຽນມາໃຊ້ປ້າຍກຳກັບ (label) 3 ລະດັບແທນ ຈະຊ່ວຍໃຫ້ການຕັດສິນໃຈມີຄວາມໝັ້ນຄົງຫຼາຍຂຶ້ນ.

ໂຄງສ້າງ 3 ລະດັບທີ່ແນະນຳ:

ກົດເກນການຕັດສິນໃຈເມື່ອປັບໃຫ້ເຫຼືອ 3 ລະດັບ ແມ່ນນິຍົມໃຊ້ຮ່ວມກັບຕົວປະເມີນຜົນໃນຂັ້ນຕອນຕໍ່ໄປ (ເຊັ່ນ: LLM-as-a-Judge ຫຼື ການກວດສອບດ້ວຍກົດເກນ). ລາຍລະອຽດຂອງເຫດຜົນໃນການຕັດສິນໃຈໄດ້ກ່າວໄວ້ໃນ LLM-as-a-Judge ແມ່ນຫຍັງ? ວິທີການປະເມີນຜົນ AI ດ້ວຍ AI ແລະ ການຈັດຕັ້ງປະຕິບັດການກວດຫາ Hallucination.

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

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

ຕົວຢ່າງການ implement ສະເພາະ:

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

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

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

ນີ້ແມ່ນການລວບລວມຄຳຖາມທີ່ພົບເລື້ອຍຈາກໜ້າວຽກຕົວຈິງ ໃນຂະນະທີ່ດຳເນີນການຮັບມືກັບບັນຫາ AI Automation Bias.

Q1: ຖ້າໃສ່ການສະແດງຜົນ Confidence ຂອງ AI ເຂົ້າໄປ, ຈະບໍ່ເຮັດໃຫ້ຜູ້ໃຊ້ບໍ່ເຊື່ອຖື AI ຫຼາຍກວ່າເກົ່າບໍ?

ໃນໄລຍະສັ້ນ ອາດຈະມີປະຕິກິລິຍາແບບນັ້ນເກີດຂຶ້ນ. ແຕ່ການບອກວ່າ "ສິ່ງໃດທີ່ບໍ່ແນ່ນອນ ກໍຄືບໍ່ແນ່ນອນ" ຈະສົ່ງຜົນໃນໄລຍະຍາວໃຫ້ຜູ້ໃຊ້ມີຄວາມເຊື່ອໝັ້ນຫຼາຍຂຶ້ນ. ໃນທາງກົງກັນຂ້າມ, UI ທີ່ສະແດງວ່າ "ໝັ້ນໃຈ 100% ທຸກຢ່າງ" ຈະເຮັດໃຫ້ສູນເສຍຄວາມເຊື່ອໝັ້ນຢ່າງກະທັນຫັນໃນທັນທີທີ່ພົບຂໍ້ຜິດພາດ. UI ທີ່ລະບຸຊັດເຈນວ່າ "ຄວນສົງໄສ AI ເມື່ອໃດ" ເຊັ່ນ: ການໃຊ້ປ້າຍກຳກັບ 3 ລະດັບ ຈະຊ່ວຍຮັກສາຄວາມປອດໄພທາງຈິດໃຈຂອງຜູ້ໃຊ້ ພ້ອມທັງຍັບຍັ້ງການເຊື່ອໝັ້ນຫຼາຍເກີນໄປ (Over-reliance).

Q2: ຈະວັດແທກ Automation Bias ໄດ້ແນວໃດ?

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

Q3: ຟັງຊັນ AI ຂະໜາດນ້ອຍ ຈຳເປັນຕ້ອງມີມາດຕະການຮັບມືນຳບໍ່?

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

Q4: ການເພີ່ມການສະແດງຜົນ Confidence ເຂົ້າໄປໃນລະບົບທີ່ມີຢູ່ແລ້ວ ເປັນເລື່ອງທີ່ເປັນໄປໄດ້ໃນທາງປະຕິບັດບໍ່?

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

Q5: ການຝາກຄວາມຫວັງໄວ້ກັບ AI Vendor ຢ່າງດຽວບໍ່ພຽງພໍບໍ?

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

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

ຂໍສະຫຼຸບຂັ້ນຕອນຂັ້ນຕໍ່າສຸດໃນການເລີ່ມຕົ້ນຈັດຕັ້ງປະຕິບັດດັ່ງນີ້:

• ຊັ້ນການບໍລິຫານ (Governance): ຈັດແບ່ງລະດັບການຕັດສິນໃຈ ແລະ ບັນທຶກລາຍຊື່ຜູ້ຮັບຜິດຊອບໃນການກຳກັບດູແລ.
• ຊັ້ນ UI: ເພີ່ມປ້າຍກຳກັບລະດັບຄວາມໝັ້ນໃຈ (Confidence) 3 ລະດັບ ພ້ອມກັບການລະບຸແຫຼ່ງອ້າງອີງ (Grounding) ຄວບຄູ່ກັນໄປ.
• ຊັ້ນການດຳເນີນງານ: ຕິດຕາມກວດກາເວລາໃນການອະນຸມັດ, ອັດຕາການປະຕິເສດ ແລະ ຄວາມແຕກຕ່າງລະຫວ່າງການຕັດສິນໃຈຂອງ AI ກັບມະນຸດ.

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

ຫາກທ່ານຕ້ອງການການສະໜັບສະໜູນໃນການນຳ AI ໄປໃຊ້ງານ, ກະລຸນາປຶກສາຫາລືກັບບໍລິສັດຂອງພວກເຮົາ.