ການແກ້ໄຂແບບຈຳລອງ (Model Editing) ແມ່ນເຕັກນິກໃນການປັບປ່ຽນຄວາມຮູ້ສະເພາະເຈາະຈົງໂດຍບໍ່ຈຳເປັນຕ້ອງຝຶກຝົນແບບຈຳລອງພາສາຂະໜາດໃຫຍ່ (LLM) ໃໝ່. ຈຸດເດັ່ນທີ່ສຳຄັນທີ່ສຸດຄືສາມາດແກ້ໄຂຂໍ້ເທັດຈິງທີ່ຜິດພາດ, ຂໍ້ມູນທີ່ລ້າສະໄໝ ຫຼື ຂໍ້ມູນສ່ວນຕົວທີ່ຄວນລຶບອອກ ໂດຍບໍ່ຕ້ອງສ້າງແບບຈຳລອງຂຶ້ນມາໃໝ່ທັງໝົດ. ບົດຄວາມນີ້ມີຈຸດປະສົງເພື່ອໃຫ້ຜູ້ຮັບຜິດຊອບ ແລະ ວິສະວະກອນໃນບໍລິສັດທີ່ກຳລັງພິຈາລະນາດ້ານການຄຸ້ມຄອງ AI (AI Governance) ແລະ ການປົກປ້ອງຂໍ້ມູນສ່ວນບຸກຄົນ ໄດ້ເຂົ້າໃຈຕັ້ງແຕ່ແນວຄວາມຄິດພື້ນຖານຂອງການແກ້ໄຂແບບຈຳລອງ, ວິທີການທີ່ເປັນຕົວແທນ, ຄວາມແຕກຕ່າງກັບ Machine Unlearning, ໄປຈົນເຖິງການນຳໄປໃຊ້ງານຈິງສຳລັບ PDPA ແລະ "ສິດທີ່ຈະຖືກລືມ" (Right to be forgotten). ເມື່ອອ່ານຈົບ, ທ່ານຈະສາມາດມີເກນໃນການຕັດສິນໃຈໄດ້ວ່າຄວນໃຊ້ຫຍັງໃນສະຖານະການໃດຂອງບໍລິສັດທ່ານ.

ຈຸດສຳຄັນ ຫຼື ແກນຫຼັກຂອງການແກ້ໄຂ Model ແມ່ນບໍ່ແມ່ນການຝຶກຝົນພາຣາມິເຕີຫຼາຍພັນລ້ານຕົວໃໝ່ທັງໝົດ, ແຕ່ແມ່ນການແນເປົ້າໝາຍໄປທີ່ "ນ້ຳໜັກພຽງສ່ວນນ້ອຍ" ທີ່ຮັບຜິດຊອບຕໍ່ຄວາມຮູ້ເປົ້າໝາຍເພື່ອຂຽນທັບໃໝ່. ກ່ອນອື່ນໝົດ, ພວກເຮົາຄວນທຳຄວາມເຂົ້າໃຈກ່ຽວກັບຄວາມແຕກຕ່າງຈາກການຝຶກຝົນໃໝ່ (Retraining), ຄວາມສຳພັນກັບການ Fine-tuning, ແລະ ພື້ນຫຼັງທີ່ເຮັດໃຫ້ເລື່ອງນີ້ໄດ້ຮັບຄວາມສົນໃຈ.

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

Fine-tuning ແລະ LoRA ກໍມີຄວາມຄ້າຍຄືກັນກັບການແກ້ໄຂ Model (Model Editing) ໃນແງ່ຂອງ "ການປັບແຕ່ງ Model ພາຍຫຼັງ", ແຕ່ມີຈຸດປະສົງ ແລະ ລະດັບຄວາມລະອຽດທີ່ແຕກຕ່າງກັນ. Fine-tuning ເປັນວິທີການປັບນ້ຳໜັກ (Weights) ຂອງ Model ທັງໝົດ (ຫຼື ຊັ້ນທີ່ກວ້າງ) ດ້ວຍຊຸດຂໍ້ມູນຈຳນວນໜຶ່ງ ເພື່ອປ່ຽນ "ພຶດຕິກຳໂດຍລວມ" ເຊັ່ນ: ຮູບແບບການຂຽນ, ການປັບຕົວເຂົ້າກັບໂດເມນ ຫຼື ການເຮັດວຽກສະເພາະດ້ານ. ສ່ວນ LoRA ແມ່ນການແຊກ Matrix ຂະໜາດນ້ອຍທີ່ມີ Rank ຕ່ຳເຂົ້າໄປ ເພື່ອເຮັດໃຫ້ການປັບຕົວແບບດຽວກັນນັ້ນສຳເລັດຜົນ ໂດຍທີ່ຫຼຸດຈຳນວນ Parameter ທີ່ຕ້ອງປັບລົງຢ່າງຫຼວງຫຼາຍ. ໃນຂະນະທີ່ວິທີເຫຼົ່ານີ້ເປັນການ "ປ່ຽນແນວໂນ້ມຂອງ Model ໃນລັກສະນະເປັນພື້ນຜິວ", ການແກ້ໄຂ Model ຈະໃຫ້ພາບທີ່ໃກ້ຄຽງກັບ "ການປ່ຽນແປງຈຸດສະເພາະເຈາະຈົງ ເຊັ່ນ: ຂໍ້ເທັດຈິງໃດໜຶ່ງ". ຕົວຢ່າງເຊັ່ນ: ການແກ້ໄຂຄວາມຮູ້ສະເພາະບຸກຄົນ ເຊັ່ນ ຕຳແໜ່ງງານ, ໂດຍພະຍາຍາມຫຼຸດຜົນກະທົບຕໍ່ຄວາມຮູ້ອື່ນໆໃຫ້ໜ້ອຍທີ່ສຸດ. ດັ່ງນັ້ນ, ມັນຈຶ່ງລວມເຖິງວິທີການຄຳນວນ ແລະ ອັບເດດນ້ຳໜັກເປົ້າໝາຍໂດຍກົງ ເຊິ່ງແຕກຕ່າງຈາກ Fine-tuning ທີ່ຕ້ອງກຽມຊຸດຂໍ້ມູນ ແລະ ດຳເນີນການ Gradient Descent. ການຈັດລະບຽບເບື້ອງຕົ້ນແມ່ນ: ຖ້າຕ້ອງການແກ້ໄຂຂໍ້ເທັດຈິງຈຳນວນໜ້ອຍໃຫ້ຖືກຕ້ອງ ແມ່ນໃຊ້ການແກ້ໄຂ Model, ແຕ່ຖ້າຕ້ອງການຍົກລະດັບພຶດຕິກຳໂດຍລວມ ແມ່ນໃຊ້ Fine-tuning.

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

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

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

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

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

"ສິດທີ່ຈະຖືກລືມ" (Right to be forgotten) ໄດ້ຖືກລະບຸໄວ້ຢ່າງຈະແຈ້ງໃນສິດທິໃນການລຶບຂໍ້ມູນ (ມາດຕາ 17) ຂອງ GDPR ເຊິ່ງເປັນສິດໃນການຮ້ອງຂໍໃຫ້ລຶບຂໍ້ມູນສ່ວນບຸກຄົນ. ຂໍ້ກຳນົດໃນລັກສະນະດຽວກັນນີ້ຍັງໄດ້ແຜ່ຂະຫຍາຍໄປສູ່ກົດໝາຍປົກປ້ອງຂໍ້ມູນສ່ວນບຸກຄົນຂອງຫຼາຍປະເທດ ລວມເຖິງ PDPA ຂອງປະເທດໄທ (ຄວາມແຕກຕ່າງຂອງແຕ່ລະປະເທດໄດ້ຖືກຮວບຮວມໄວ້ໃນ ການປຽບທຽບກົດໝາຍປົກປ້ອງຂໍ້ມູນຂອງ 4 ປະເທດໃນອາຊຽນຢ່າງລະອຽດ). ບັນຫາກໍຄື ເຖິງແມ່ນວ່າການລຶບລະບຽບການ (Record) ໃນຖານຂໍ້ມູນຈະເຮັດໄດ້ງ່າຍ, ແຕ່ການລຶບຂໍ້ມູນທີ່ໄດ້ຖືກຫຼອມລວມເຂົ້າໄປໃນນ້ຳໜັກຂອງແບບຈຳລອງ (Model weights) ໃນລະຫວ່າງການຮຽນຮູ້ (Learning) ນັ້ນເປັນເລື່ອງທີ່ຍາກໃນທາງເຕັກນິກ. ນີ້ຄືເຫດຜົນທີ່ Machine Unlearning ຖືກຄາດຫວັງໃຫ້ເປັນທາງອອກໃນທາງເຕັກນິກ. ຍິ່ງໄປກວ່ານັ້ນ, ພາຍໃຕ້ກອບການເຮັດວຽກທີ່ກຳລັງຖືກສ້າງຂຶ້ນ ເຊັ່ນ EU AI Act ທີ່ໄດ້ມີຜົນບັງຄັບໃຊ້ຢ່າງເຕັມຮູບແບບແລ້ວ ເຊິ່ງຮຽກຮ້ອງໃຫ້ບໍລິສັດຕ່າງໆຕ້ອງມີຄວາມໂປ່ງໃສໃນລະບົບ AI ແລະ ມີການບໍລິຫານຈັດການຄວາມສ່ຽງ, ເຮັດໃຫ້ຄວາມສຳຄັນຂອງການສາມາດອະທິບາຍໄດ້ວ່າ "ຂໍ້ມູນທີ່ໃຊ້ໃນການຮຽນຮູ້ມີຫຍັງແດ່ ແລະ ຈະສາມາດຄວບຄຸມມັນໄດ້ແນວໃດ" ນັ້ນ ເພີ່ມທະວີຂຶ້ນເລື້ອຍໆ. ການທີ່ພະແນກກົດໝາຍ ແລະ ພະແນກປະຕິບັດຕາມກົດລະບຽບ (Compliance) ໄດ້ມີການປຶກສາຫາລືກັບພະແນກເຕັກນິກກ່ຽວກັບຄວາມເປັນໄປໄດ້ໃນການຕອບສະໜອງຕໍ່ຄຳຮ້ອງຂໍການລຶບຂໍ້ມູນໄວ້ລ່ວງໜ້າ ຈະເປັນທາງລັດໃນການຫຼຸດຜ່ອນຄວາມສ່ຽງໃນການປະຕິບັດຕາມກົດລະບຽບ.

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

ວິທີການແກ້ໄຂແບບທ້ອງຖິ່ນ (Local editing) ແມ່ນວິທີການທີ່ຊອກຫາວ່າ "ຂໍ້ເທັດຈິງໃດໜຶ່ງຖືກເກັບຮັກສາໄວ້ໃນນ້ຳໜັກ (weights) ໃດຂອງຕົວແບບ" ແລະຂຽນທັບສະເພາະຈຸດນັ້ນ. ROME (Rank-One Model Editing) ເຊິ່ງເປັນຕົວແທນຂອງວິທີນີ້, ຖືວ່າ MLP ໃນຊັ້ນກາງຂອງ Transformer ເປັນໜ່ວຍຄວາມຈຳແບບເຊື່ອມໂຍງ (associative memory) ຊະນິດໜຶ່ງ ໂດຍມີອິນພຸດ (ປະທານ) ເປັນກະແຈ ແລະ ເອົາພຸດ (ຂໍ້ເທັດຈິງ) ເປັນຄ່າ. ໂດຍການລະບຸວ່າຊັ້ນໃດທີ່ຮັບຜິດຊອບຕໍ່ຂໍ້ເທັດຈິງເປົ້າໝາຍຜ່ານການວິເຄາະທາງເຫດຜົນ, ມັນຈະທຳການອັບເດດນ້ຳໜັກຂອງຊັ້ນນັ້ນຢ່າງໜ້ອຍທີ່ສຸດ ເພື່ອໃຫ້ "ເມື່ອໃສ່ກະແຈເຂົ້າໄປ ແລ້ວໄດ້ຄ່າໃໝ່ອອກມາ" ເປັນການຂຽນທັບຄວາມຮູ້. MEMIT (Mass-Editing Memory in a Transformer) ແມ່ນວິທີການທີ່ຂະຫຍາຍແນວຄິດນີ້ໄປສູ່ການແກ້ໄຂຫຼາຍຊັ້ນ ແລະ ຫຼາຍພັນລາຍການພ້ອມກັນ. ມັນມີລັກສະນະໃກ້ຄຽງກັບການປ່ຽນແທນສະເພາະບາງລາຍການໃນໜ່ວຍຄວາມຈຳແບບເຊື່ອມໂຍງ, ເຊິ່ງມີຂໍ້ດີຄືບໍ່ຈຳເປັນຕ້ອງປັບປ່ຽນທັງໝົດຄືກັບການຝຶກຝົນໃໝ່ (re-learning). ໃນທາງກົງກັນຂ້າມ, ຖ້າບໍ່ສາມາດລະບຸຕຳແໜ່ງຂອງຂໍ້ເທັດຈິງເປົ້າໝາຍໄດ້ຢ່າງຖືກຕ້ອງ, ມັນອາດສົ່ງຜົນກະທົບໄປເຖິງຈຸດທີ່ບໍ່ໄດ້ຕັ້ງໃຈ, ດັ່ງນັ້ນຄວາມແມ່ນຍຳໃນການລະບຸຈຸດແກ້ໄຂຈຶ່ງເປັນປັດໄຈສຳຄັນທີ່ກຳນົດຄຸນນະພາບ.

ວິທີການທີ່ອີງໃສ່ Meta-learning ຈະໃຫ້ເຄືອຂ່າຍເສີມຮຽນຮູ້ກົດເກນທີ່ວ່າ "ຈະປັບປ່ຽນນ້ຳໜັກ (weights) ແນວໃດ ເພື່ອໃຫ້ສາມາດແກ້ໄຂຄວາມຮູ້ໄດ້ໂດຍບໍ່ສົ່ງຜົນກະທົບທາງລົບຕໍ່ສ່ວນອື່ນ". ຕົວຢ່າງທີ່ໂດດເດັ່ນຄື MEND ເຊິ່ງຈະມີການຝຶກຝົນເຄືອຂ່າຍຂະໜາດນ້ອຍ (Editor) ໄວ້ລ່ວງໜ້າ ເພື່ອປ່ຽນ Gradient ທີ່ໄດ້ຈາກກໍລະນີທີ່ຕ້ອງການແກ້ໄຂ ໃຫ້ກາຍເປັນການອັບເດດນ້ຳໜັກທີ່ເໝາະສົມສຳລັບຕົວແບບຫຼັກ. ໃນເວລາແກ້ໄຂຕົວຈິງ, Editor ນີ້ຈະສົ່ງຜົນການອັບເດດອອກມາໄດ້ທັນທີ ຈຶ່ງບໍ່ຈຳເປັນຕ້ອງຄຳນວນໃໝ່ຢ່າງໜັກໃນແຕ່ລະກໍລະນີ. MALMEN ເປັນວິທີການທີ່ຂະຫຍາຍແນວຄິດນີ້ໄປສູ່ການແກ້ໄຂຈຳນວນຫຼາຍ ເຮັດໃຫ້ສາມາດນຳໃຊ້ການແກ້ໄຂຈຳນວນຫຼາຍໄດ້ຢ່າງມີປະສິດທິພາບ. ຄວາມແຕກຕ່າງທີ່ສຳຄັນຄື ໃນຂະນະທີ່ການແກ້ໄຂແບບ Local ແມ່ນ "ການອອກແບບວິທີການຂຽນໃໝ່ດ້ວຍມື", ວິທີການທີ່ອີງໃສ່ Meta-learning ແມ່ນ "ການຮຽນຮູ້ວິທີການຂຽນໃໝ່ຈາກຂໍ້ມູນ". ເຖິງວ່າຈະມີຕົ້ນທຶນໃນການຝຶກຝົນລ່ວງໜ້າ, ແຕ່ເມື່ອກຽມພ້ອມແລ້ວ ກໍສາມາດເຮັດການແກ້ໄຂຊ້ຳໄດ້ງ່າຍ ແລະ ຍິ່ງຂະໜາດຂອງການແກ້ໄຂໃຫຍ່ເທົ່າໃດ ກໍຍິ່ງເຫັນຜົນໄດ້ຊັດເຈນເທົ່ານັ້ນ.

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

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

ການແກ້ໄຂແບບຈຳລອງ (Model editing) ແລະ Machine Unlearning ສາມາດກາຍເປັນວິທີການຈັດຕັ້ງປະຕິບັດເພື່ອຕອບສະໜອງຕໍ່ຄຳຮ້ອງຂໍການລຶບຂໍ້ມູນສ່ວນບຸກຄົນ ແລະ ຂໍ້ກຳນົດດ້ານ AI Governance ໂດຍບໍ່ຕ້ອງເພິ່ງພາການຝຶກຝົນໃໝ່ (Retraining) ແລະ ມີຕົ້ນທຶນທີ່ສົມເຫດສົມຜົນ. ຢ່າງໃດກໍຕາມ, ເທັກໂນໂລຢີພຽງຢ່າງດຽວບໍ່ສາມາດເຮັດໃຫ້ສຳເລັດໄດ້, ແຕ່ຈຳເປັນຕ້ອງອອກແບບໃຫ້ສອດຄ່ອງກັບຂະບວນການເຮັດວຽກ ແລະ ລະບົບການປະເມີນຜົນ. ຕໍ່ໄປນີ້ຈະເປັນການພິຈາລະນາຈຸດສຳຄັນໃນການນຳໄປໃຊ້ງານຈິງຈາກສາມມຸມມອງ.

ເພື່ອຮອງຮັບການຮ້ອງຂໍລຶບຂໍ້ມູນສ່ວນບຸກຄົນ, ສິ່ງສຳຄັນແມ່ນຕ້ອງກຳນົດຂະບວນການ ຫຼື Pipeline ທີ່ກວມເອົາທັງກ່ອນ ແລະ ຫຼັງການດຳເນີນການທາງເຕັກນິກ.

1. ການຮັບເລື່ອງ ແລະ ການຢືນຢັນຕົວຕົນ: ເຮັດໃຫ້ເນື້ອໃນການຮ້ອງຂໍ ແລະ ຂອບເຂດທີ່ກ່ຽວຂ້ອງມີຄວາມຊັດເຈນ.
2. ການລະບຸເປົ້າໝາຍ: ກວດສອບວ່າຂໍ້ມູນນັ້ນສົ່ງຂໍ້ມູນຕໍ່ໃຫ້ຂໍ້ມູນການຮຽນຮູ້ (Training Data) ຫຼື ຜົນລວມຂອງ Model ຢ່າງໃດ ແລະ ມີຜົນກະທົບແນວໃດ.
3. ການເລືອກວິທີການ: ຖ້າພຽງແຕ່ແກ້ໄຂຜົນລວມໃຫ້ເປັນຄ່າທີ່ບໍ່ມີອັນຕະລາຍກໍພຽງພໍແລ້ວ ໃຫ້ເລືອກວິທີການແກ້ໄຂ, ແຕ່ຖ້າຕ້ອງການລຶບເຖິງຮ່ອງຮອຍການຮຽນຮູ້ ໃຫ້ພິຈາລະນາໃຊ້ Machine Unlearning.
4. ການນຳໃຊ້: ດຳເນີນການແກ້ໄຂ ຫຼື ລຶບອອກດ້ວຍວິທີການທີ່ເລືອກໄວ້.
5. ການກວດສອບ: ຢືນຢັນວ່າຂໍ້ມູນເປົ້າໝາຍຈະບໍ່ຖືກສະແດງອອກມາອີກ ແລະ ຟັງຊັນອື່ນໆທີ່ບໍ່ກ່ຽວຂ້ອງຈະບໍ່ໄດ້ຮັບຄວາມເສຍຫາຍ.
6. ການບັນທຶກ: ບັນທຶກເນື້ອໃນການດຳເນີນການ ແລະ ຫຼັກຖານການຕັດສິນໃຈ ເພື່ອກຽມພ້ອມສຳລັບການຮັບຜິດຊອບຕໍ່ຄຳອະທິບາຍ.

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

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

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

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

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

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

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

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

ໂດຍພື້ນຖານແລ້ວ, ວິທີການເຫຼົ່ານີ້ສາມາດນຳໃຊ້ໄດ້ກັບ Open-weight models ທີ່ສາມາດດາວໂຫຼດນ້ຳໜັກ (weights) ມາປະມວນຜົນເອງໄດ້ເທົ່ານັ້ນ (ເຊັ່ນ: Llama, Mistral, Qwen, ຫຼື Gemma ເປັນຕົ້ນ, ລວມເຖິງ OpenAI ທີ່ເປີດເຜີຍນ້ຳໜັກບາງໂມເດວ). ສຳລັບໂມເດວທີ່ປິດນ້ຳໜັກໄວ້ ເຊັ່ນ: Claude, GPT ຫຼື Gemini API ນັ້ນ ບໍ່ສາມາດເຂົ້າເຖິງນ້ຳໜັກຈາກພາຍນອກໄດ້ ຈຶ່ງບໍ່ສາມາດນຳມາແກ້ໄຂໄດ້. ໃນໂມເດວແບບປິດເຫຼົ່ານີ້, ການປັບປ່ຽນຄວາມຮູ້ຈະເຮັດໄດ້ຜ່ານການໃຊ້ RAG, System Prompt ຫຼື ຟັງຊັນ Fine-tuning ທີ່ຜູ້ໃຫ້ບໍລິການກຽມໄວ້ໃຫ້. ສຳລັບການເລືອກເຄື່ອງມື, Open-source framework ຢ່າງ EasyEdit ທີ່ສາມາດທົດລອງວິທີການແກ້ໄຂແບບຕ່າງໆໄດ້ນັ້ນ ເປັນຈຸດເລີ່ມຕົ້ນທີ່ເໝາະສົມສຳລັບການກວດສອບຂະໜາດນ້ອຍ ເນື່ອງຈາກສາມາດປຽບທຽບ ROME, MEMIT, MEND ແລະ ອື່ນໆ ໄດ້ໃນກອບວຽກດຽວກັນ. ສິ່ງທີ່ສຳຄັນຍິ່ງກວ່າເຄື່ອງມືຄືການອອກແບບຕົວຊີ້ວັດການປະເມີນຜົນ. ໂດຍພື້ນຖານແລ້ວ, ຄຸນນະພາບຂອງການແກ້ໄຂໂມເດວຈະວັດແທກຈາກ 3 ປັດໄຈຄື: ຄວາມຮູ້ທີ່ຕ້ອງການຖືກປ່ຽນແປງແລ້ວຫຼືບໍ່ (ຄວາມໜ້າເຊື່ອຖື), ສາມາດໃຫ້ຄຳຕອບໃໝ່ໄດ້ຢ່າງສອດຄ່ອງເຖິງແມ່ນວ່າຈະປ່ຽນວິທີການຖາມ (ການແຜ່ຂະຫຍາຍ), ແລະ ຄວາມຮູ້ອື່ນໆທີ່ບໍ່ກ່ຽວຂ້ອງກັບການແກ້ໄຂ ຫຼື ຄວາມສາມາດໃນການສ້າງເນື້ອຫາຍັງຄົງຢູ່ຄົບຖ້ວນຫຼືບໍ່ (ຄວາມສະເພາະເຈາະຈົງ). ການກຽມຊຸດຂໍ້ມູນສຳລັບປະເມີນຜົນທີ່ສອດຄ່ອງກັບໂມເດວເປົ້າໝາຍ ແລະ ກໍລະນີການນຳໃຊ້ຂອງບໍລິສັດ ພ້ອມທັງວັດແທກຜົນເຫຼົ່ານີ້ທຸກຄັ້ງ ແມ່ນເງື່ອນໄຂເບື້ອງຕົ້ນໃນການນຳໄປໃຊ້ງານຢ່າງປອດໄພ.

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

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

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