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

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

ພາສາລາວຖືກຈັດຢູ່ໃນກຸ່ມພາສາທີ່ມີຊັບພະຍາກອນໜ້ອຍ (Low-resource language) ເຊິ່ງມີປະລິມານຂໍ້ມູນສຳລັບການຮຽນຮູ້ໜ້ອຍກວ່າພາສາອັງກິດ ຫຼື ພາສາຍີ່ປຸ່ນ. ແບບຈຳລອງພາສາຂະໜາດໃຫຍ່ (LLM) ມັກຈະໃຫ້ຄວາມແມ່ນຍຳສູງໃນພາສາທີ່ມີປະລິມານຂໍ້ຄວາມເທິງເວັບຫຼາຍ, ໃນທາງກົງກັນຂ້າມ, ພາສາທີ່ມີຂໍ້ມູນໜ້ອຍມັກຈະມີແນວໂນ້ມທີ່ຄວາມແມ່ນຍຳໃນການເຂົ້າໃຈ ແລະ ການສ້າງຂໍ້ຄວາມບໍ່ຄ່ອຍຄົງທີ່.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Q: ໃນບັນດາອັດຕາການບັນລຸວຽກງານ (Task Achievement Rate), ຄວາມຖືກຕ້ອງຂອງຫຼາຍພາສາ (Multilingual Accuracy) ແລະ ອັດຕາການແຊກແຊງຂອງມະນຸດ (HITL Intervention Rate), ຄວນໃຫ້ຄວາມສຳຄັນກັບອັນໃດກ່ອນ? A: ບໍ່ຄວນເລືອກພຽງອັນໃດອັນໜຶ່ງ, ແຕ່ຄວນພິຈາລະນາໂດຍການປະສົມປະສານທັງ 3 ແກນຫຼັກ. ຖ້າຈະໃຫ້ລະບຸຈຸດເລີ່ມຕົ້ນ, ອັດຕາການບັນລຸວຽກງານທີ່ສະແດງໃຫ້ເຫັນວ່າສາມາດເຮັດວຽກໃຫ້ສຳເລັດໄດ້ຫຼືບໍ່ນັ້ນ ຈະເປັນ ຈຸດສຳຄັນ ຫຼື ແກນຫຼັກ, ແຕ່ຕ້ອງກວດສອບດ້ວຍອັດຕາການແຊກແຊງຂອງມະນຸດ (HITL) ວ່າວຽກງານນັ້ນໄດ້ຮັບການສະໜັບສະໜູນຈາກມະນຸດຫຼາຍເກີນໄປຫຼືບໍ່ ແລະ ໃຊ້ຄວາມຖືກຕ້ອງຂອງຫຼາຍພາສາເພື່ອເບິ່ງວ່າຄວາມຜິດພາດນັ້ນມີສາເຫດມາຈາກພາສາລາວຫຼືບໍ່, ເຊິ່ງທັງໝົດນີ້ມີຄວາມສຳພັນແບບສົ່ງເສີມເຊິ່ງກັນແລະກັນ. ການຈະໃຫ້ຄວາມສຳຄັນກັບແກນໃດນັ້ນ ຄວນປັບປ່ຽນຕາມລະດັບຄວາມສ່ຽງທີ່ຍອມຮັບໄດ້ຂອງວຽກງານນັ້ນໆ.

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

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