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) ຈະຮຽກໃຊ້ເຄື່ອງມືຫຼາຍຢ່າງ ແລະ ເຮັດວຽກໃຫ້ສຳເລັດດ້ວຍລະບົບຕ່ອງໂສ້ການຕັດສິນໃຈ. ເນື່ອງຈາກມະນຸດບໍ່ໄດ້ກວດສອບການຕັດສິນໃຈໃນແຕ່ລະຂັ້ນຕອນ, ຈຶ່ງມັກຈະເກີດການດຳເນີນງານແບບ "ເບິ່ງພຽງແຕ່ຜົນລວມສຸດທ້າຍແລ້ວອະນຸມັດ".

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

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

ສິ່ງສຳຄັນໃນຂັ້ນຕອນການນຳເອເຈນໄປໃຊ້ງານຈິງ ຄືການອອກແບບທີ່ບໍ່ແມ່ນເບິ່ງ "ພຽງແຕ່ຜົນລວມສຸດທ້າຍ" ເທົ່ານັ້ນ, ແຕ່ຕ້ອງເຮັດໃຫ້ "ລະບົບຕ່ອງໂສ້ການຕັດສິນໃຈລະຫວ່າງທາງ" ສາມາດເບິ່ງເຫັນໄດ້ ແລະ ບັງຄັບໃຫ້ມີການກວດສອບໂດຍມະນຸດໃນຈຸດທີ່ຈຳເປັນ. ສຳລັບລາຍລະອຽດເພີ່ມເຕີມ, ກະລຸນາເບິ່ງທີ່ AIエージェントを本番運用に乗せるには？パイロットから量産化への実践ステップ ເພີ່ມເຕີມ.

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

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

ໃນກໍລະນີທີ່ທ່ານກຳລັງດຳເນີນການສ້າງ AI Governance ພາຍໃນອົງກອນ, ຂໍແນະນຳໃຫ້ກວດສອບພາບລວມຈາກ AIガバナンスとは？EU AI Act対応から社内ルール整備まで実務ガイド ກ່ອນ, ຈາກນັ້ນຈຶ່ງນຳມາປັບໃຊ້ເຂົ້າກັບຊັ້ນມາດຕະການໃນບົດຄວາມນີ້ ເຊິ່ງຈະຊ່ວຍໃຫ້ຈັດລະບຽບໄດ້ງ່າຍຂຶ້ນ.

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

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

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

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

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

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

ສັນຍານທີ່ບົ່ງບອກວ່າ HITL ກາຍເປັນພຽງຮູບແບບທີ່ບໍ່ມີປະສິດທິພາບ:

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

ສິ່ງທີ່ສຳຄັນຂອງ HITL ບໍ່ແມ່ນຂໍ້ເທັດຈິງທີ່ວ່າ "ມີມະນຸດເຂົ້າມາຂັ້ນກາງ", ແຕ່ແມ່ນຂໍ້ເທັດຈິງທີ່ວ່າ "ມີພື້ນທີ່ໃຫ້ມະນຸດສາມາດໂຕ້ແຍ້ງໄດ້". ສຳລັບການອອກແບບໜ້າຈໍການກວດສອບ ແລະ ກົນໄກການສົ່ງຄືນຂໍ້ມູນການປະຕິເສດນັ້ນ ສາມາດອ່ານລາຍລະອຽດເພີ່ມເຕີມໄດ້ທີ່ ヒューマン・イン・ザ・ループ(HITL)とは？AIで業務自動化を定着させる「人間参加型」設計の基礎

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

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

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

ສຳລັບການປະສົມປະສານລະຫວ່າງການປັບແຕ່ງແຈ້ງເຕືອນ ແລະ ການຕິດຕາມກວດກາ AI, ສາມາດອ້າງອີງເພີ່ມເຕີມໄດ້ທີ່ AIオブザーバビリティとは？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 ガードレール 実装ガイド — 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) ໄດ້.

ຕົວຢ່າງການປະຕິບັດຕົວຈິງ:

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

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

ການອອກແບບການດຳເນີນງານທີ່ປະສົມປະສານລະຫວ່າງ "ການເຮັດໃຫ້ເຫັນແຫຼ່ງທີ່ມາຂອງຂໍ້ມູນ" ແລະ "ການກວດສອບໂດຍມະນຸດ" ແມ່ນມີຄວາມກ່ຽວຂ້ອງໂດຍກົງກັບເລື່ອງ HITL, ເຊິ່ງທ່ານສາມາດອ່ານ ヒューマン・イン・ザ・ループ(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 ໄປໃຊ້ງານ, ກະລຸນາປຶກສາຫາລືກັບບໍລິສັດຂອງພວກເຮົາ.