ການປະເມີນຄວາມຖືກຕ້ອງຂອງ LLM ທີ່ຮອງຮັບພາສາລາວ ແມ່ນຂະບວນການວັດແທກຄວາມສາມາດຂອງຕົວແບບ (Model) ດ້ວຍ 3 ແກນຫຼັກ ຄື: ຄຸນນະພາບການແປ, ອັດຕາການເກີດຮາລູຊິເນຊັນ (Hallucination) ແລະ ຕົ້ນທຶນຂອງໂທເຄັນ (Token cost) ກ່ອນທີ່ຈະນຳໄປໃຊ້ງານຈິງ ເພື່ອຕັດສິນຄວາມເໝາະສົມກັບກໍລະນີການນຳໃຊ້ (Use case) ຂອງບໍລິສັດ.

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

ບົດຄວາມນີ້ມີຈຸດປະສົງເພື່ອແນະນຳກອບການປະເມີນຜົນທີ່ສາມາດເຮັດຊ້ຳໄດ້ (Reproducible evaluation framework) ເປັນຂັ້ນເປັນຕອນ ສຳລັບຜູ້ຮັບຜິດຊອບລະບົບ, ຜູ້ຈັດການຜະລິດຕະພັນ (Product Manager) ແລະ ຜູ້ຮັບຜິດຊອບດ້ານການວາງແຜນທຸລະກິດທີ່ກຳລັງພິຈາລະນານຳເອົາ LLM ພາສາລາວມາໃຊ້ງານ. ຫຼັງຈາກອ່ານຈົບ, ທ່ານຈະສາມາດດຳເນີນການປະເມີນຜົນໂດຍໃຊ້ຂໍ້ມູນທົດສອບຂອງບໍລິສັດເອງ ແລະ ສາມາດສ້າງບັດຄະແນນ (Scorecard) ເພື່ອປະກອບການຕັດສິນໃຈທາງທຸລະກິດໄດ້.

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

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

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

ປັດໄຈຫຼັກທີ່ເຮັດໃຫ້ການປະເມີນຜົນພາສາລາວມີຄວາມຫຍຸ້ງຍາກ

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

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

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

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

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

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

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

ລາຍການບັນຫາທົ່ວໄປ

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

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

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

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

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

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

ແນວທາງການແບ່ງໝວດໝູ່ (ຕົວຢ່າງການແບ່ງ 100 ລາຍການ)

• ການສົນທະນາທົ່ວໄປ/FAQ: 30 ລາຍການ
• ເອກະສານທຸລະກິດ/ທີ່ກ່ຽວຂ້ອງກັບສັນຍາ: 25 ລາຍການ
• ປະໂຫຍກທີ່ມີຄຳສຸພາບ/ຮູບແບບທາງການ: 20 ລາຍການ
• ປະໂຫຍກທີ່ມີຄຳສັບສະເພາະທ້ອງຖິ່ນ/ພາສາຖິ່ນ: 15 ລາຍການ
• ປະໂຫຍກທີ່ມີຕົວເລກ/ຄຳນາມສະເພາະຫຼາຍ (ທີ່ຢູ່, ຊື່ຄົນ, ເລກທີກົດໝາຍ, ແລະ ອື່ນໆ): 10 ລາຍການ

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

3 ຫຼັກການທີ່ຄວນຍຶດຖືໃນການເກັບຂໍ້ມູນ

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

ໃນກໍລະນີທີ່ໃຊ້ຂໍ້ມູນຈິງທີ່ມີຂໍ້ມູນສ່ວນບຸກຄົນ, ຕ້ອງມີການປະມວນຜົນແບບ Masking (ປິດບັງຂໍ້ມູນ) ກ່ອນນຳໄປໃຊ້ໃນການປະເມີນເປັນເງື່ອນໄຂເບື້ອງຕົ້ນ.

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

ທາງເລືອກຫຼັກຂອງເຄື່ອງມືຟຣີ

• Hugging Face Evaluate: ສາມາດເອີ້ນໃຊ້ຕົວຊີ້ວັດການປະເມີນຜົນແບບອັດຕະໂນມັດທີ່ສຳຄັນ ເຊັ່ນ: BLEU ຫຼື ROUGE ໄດ້ຈາກ Python. ເຖິງວ່າການຕັດຄຳພາສາລາວຈະຕ້ອງມີການຮອງຮັບເພີ່ມເຕີມ ແຕ່ກໍສາມາດເລີ່ມຕົ້ນໄດ້ໂດຍບໍ່ມີຄ່າໃຊ້ຈ່າຍ.
• LangChain + Local LLM: ມີປະສິດທິພາບໃນກໍລະນີທີ່ຕ້ອງການສ້າງ ຂະບວນການ ຫຼື Pipeline ການປະເມີນຜົນດ້ວຍຕົນເອງ. ສາມາດດຳເນີນການປະເມີນຜົນຊ້ຳໆໄດ້ໃນຂະນະທີ່ຄວບຄຸມຄ່າໃຊ້ຈ່າຍ API.
• Google Colab: ສາມາດໃຊ້ GPU ໃນໂຄຕ້າຟຣີເພື່ອປະມວນຜົນ Model Inference ຂະໜາດນ້ອຍ ຫຼື ຄຳນວນຕົວຊີ້ວັດຕ່າງໆໄດ້.

ທາງເລືອກຫຼັກຂອງເຄື່ອງມືເສຍຄ່າໃຊ້ຈ່າຍ

• Weights & Biases (W&B): ສາມາດລວມສູນການຈັດການການທົດລອງ ແລະ ການບັນທຶກ Log ໄດ້, ເຮັດໃຫ້ເຫັນພາບຜົນການປຽບທຽບຂອງຫຼາຍ Model ໄດ້ງ່າຍ.
• Arize AI / Fiddler AI: ສາມາດກວດຈັບ Hallucination ແລະ ຕິດຕາມການປ່ຽນແປງຂອງຄຸນນະພາບ (Quality Drift) ໄດ້. ມັກຖືກຍົກມາເປັນທາງເລືອກສຳລັບລະດັບອົງກອນ (Enterprise).
• Cloud AI Evaluation Service: ຍັງມີວິທີການນຳໃຊ້ຟັງຊັນການປະເມີນຜົນທີ່ AWS, GCP ແລະ Azure ໃຫ້ບໍລິການ (ຂໍ້ມູນນີ້ເປັນຂໍ້ມູນອ້າງອີງໃນເວລາຂຽນ, ກະລຸນາກວດສອບໜ້າເວັບລາຄາຫຼ້າສຸດ).

ປັດໄຈໃນການຕັດສິນໃຈເລືອກສະພາບແວດລ້ອມ

• ໄລຍະເລີ່ມຕົ້ນທີ່ຄວາມຖີ່ໃນການປະເມີນຜົນຍັງຕ່ຳ → ເຄື່ອງມືຟຣີກໍພຽງພໍແລ້ວ.
• ໄລຍະທີ່ຕ້ອງປຽບທຽບຫຼາຍ Model ໄປພ້ອມກັນ ແລະ ຕິດຕາມຜົນຢ່າງຕໍ່ເນື່ອງ → ຄວນພິຈາລະນາປ່ຽນໄປໃຊ້ເຄື່ອງມືເສຍຄ່າໃຊ້ຈ່າຍ.
• ໃນກໍລະນີທີ່ມີວິສະວະກອນພາຍໃນໜ້ອຍ → ເຄື່ອງມືເສຍຄ່າໃຊ້ຈ່າຍແບບ SaaS ຈະຊ່ວຍຫຼຸດພາລະໃນການດຳເນີນງານໄດ້ງ່າຍກວ່າ.

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

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

ການປະເມີນຄຸນນະພາບການແປມີ 2 ລະບົບ ຄື "ການປະເມີນແບບອັດຕະໂນມັດ" ແລະ "ການປະເມີນໂດຍມະນຸດ". ເນື່ອງຈາກແຕ່ລະວິທີມີຈຸດແຂງ ແລະ ຂໍ້ຈຳກັດທີ່ແຕກຕ່າງກັນ, ການນຳມາປະສົມປະສານກັນຕາມຈຸດປະສົງຈຶ່ງເປັນວິທີທີ່ເໝາະສົມທີ່ສຸດ.

ຄຸນລັກສະນະ ແລະ ຂໍ້ຈຳກັດຂອງຄະແນນ BLEU (ການປະເມີນແບບອັດຕະໂນມັດ)

ຄະແນນ BLEU ເປັນດັດຊະນີທີ່ໃຊ້ໃນການຄິດໄລ່ຄ່າຄວາມສອດຄ່ອງຂອງ n-gram ລະຫວ່າງຜົນລວມທີ່ໄດ້ກັບຄຳແປອ້າງອີງ ເຊິ່ງສາມາດໃຫ້ຄະແນນຂໍ້ຄວາມຈຳນວນຫຼາຍໄດ້ໃນເວລາອັນສັ້ນ. ມັນມີປະສິດທິພາບໃນການປຽບທຽບຂ້າມຮຸ່ນຂອງຫຼາຍໂມເດວ ແລະ ການກວດສອບວົງຈອນການປັບປຸງ.

ຢ່າງໃດກໍຕາມ, ການນຳມາໃຊ້ກັບພາສາລາວຕ້ອງມີຄວາມລະມັດລະວັງ, ໂດຍມີຂໍ້ຈຳກັດຫຼັກໆດັ່ງນີ້:

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

ດ້ວຍເຫດນີ້, ຈຶ່ງແນະນຳໃຫ້ໃຊ້ຄະແນນ BLEU ເປັນ "ດັດຊະນີສຳລັບການປຽບທຽບແບບສຳພັດ" ເທົ່ານັ້ນ ແລະ ບໍ່ຄວນນຳມາໃຊ້ເພື່ອຮັບປະກັນຄຸນນະພາບແບບເດັດຂາດ.

ສະຖານະການທີ່ຈຳເປັນຕ້ອງໃຊ້ການປະເມີນໂດຍມະນຸດ

ເຖິງວ່າຈະຕ້ອງໃຊ້ແຮງງານຫຼາຍ ແຕ່ໃນສະຖານະການຕໍ່ໄປນີ້ ການປະເມີນໂດຍມະນຸດແມ່ນສິ່ງທີ່ຂາດບໍ່ໄດ້:

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

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

ມາດຕະຖານໃນການແບ່ງການນຳໃຊ້ໃນທາງປະຕິບັດ

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

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

ຂັ້ນຕອນການນຳເຂົ້າໃນການປະເມີນຜົນ

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

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

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

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

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

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

ສະຫຼຸບຂັ້ນຕອນການປຽບທຽບ

1. ກະກຽມຊຸດທົດສອບ (Test set) — ເລືອກຄຳຖາມສະເພາະດ້ານພາສາລາວທີ່ສາມາດກວດສອບຂໍ້ເທັດຈິງໄດ້ 50-100 ຂໍ້ ເຊັ່ນ: ເອກະສານທີ່ຈຳເປັນສຳລັບຂັ້ນຕອນທາງລັດຖະການ ຫຼື ພະແນກການແພດຂອງສະຖານພະຍາບານ.
2. ສ້າງຄຳຕອບໃນເງື່ອນໄຂທີ່ບໍ່ມີ RAG — ໃຫ້ Model ຕອບຄຳຖາມທັງໝົດດ້ວຍຕົວມັນເອງ ໂດຍບໍ່ຕ້ອງເຊື່ອມຕໍ່ກັບຖານຄວາມຮູ້ພາຍນອກ.
3. ສ້າງຄຳຕອບໃນເງື່ອນໄຂທີ່ມີ RAG — ເຊື່ອມຕໍ່ເອກະສານຂອງບໍລິສັດ ຫຼື ຄໍພັສ (Corpus) ພາສາລາວທີ່ເຊື່ອຖືໄດ້ເປັນແຫຼ່ງຂໍ້ມູນໃນການຄົ້ນຫາ ເພື່ອໃຫ້ຕອບຄຳຖາມດຽວກັນ.
4. ຕັດສິນຄວາມຖືກຕ້ອງຂອງແຕ່ລະຄຳຕອບ — ໃຫ້ເຈົ້າຂອງພາສາ ຫຼື ຜູ້ຊ່ຽວຊານສະເພາະດ້ານປະເມີນຜົນໃນ 3 ລະດັບ ຄື: "ຖືກຕ້ອງ", "ຖືກຕ້ອງບາງສ່ວນ" ແລະ "ຜິດ".
5. ຄິດໄລ່ອັດຕາການເກີດ Hallucination — ປຽບທຽບລະຫວ່າງກໍລະນີທີ່ມີ RAG ແລະ ບໍ່ມີ RAG ໂດຍໃຊ້ສູດ: ຈຳນວນຄຳຕອບທີ່ "ຜິດ" ÷ ຈຳນວນຄຳຖາມທັງໝົດ × 100 (%).

ຂໍ້ຄວນລະວັງໃນການຕັດສິນ

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

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

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

ລາຍການກວດສອບແຍກຕາມຂົງເຂດ

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

ວິທີການດຳເນີນການກວດສອບທີ່ມີປະສິດທິຜົນ ຄືການນຳໃຊ້ວິທີການກວດສອບຊ້ຳໂດຍເຈົ້າຂອງພາສາ (Native speaker) ປະສານກັບການກວດສອບກັບຂໍ້ມູນປະຖົມພູມຈາກອົງການຈັດຕັ້ງຂອງລັດ.

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

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

ການຈັດການຕົ້ນທຶນ Token ມີຜົນຕໍ່ຄວາມຍືນຍົງໃນການນຳ LLM ມາໃຊ້ງານ. ສູດພື້ນຖານມີດັ່ງນີ້:

ງົບປະມານປະຈຳເດືອນ ÷ ລາຄາຕໍ່ 1 Token = ຂີດຈຳກັດ Token ປະຈຳເດືອນ

ຂັ້ນຕອນພື້ນຖານໃນການຄິດໄລ່ຍ້ອນກັບ

1. ກຳນົດງົບປະມານປະຈຳເດືອນ — ຕັດສິນໃຈກຳນົດສັດສ່ວນຂອງຄ່າໃຊ້ຈ່າຍ API ຈາກຍອດລວມຂອງຄ່າໃຊ້ຈ່າຍ API, ໂຄງສ້າງພື້ນຖານ ຫຼື Infrastructure, ແລະ ຄ່າແຮງງານ.
2. ກວດສອບລາຄາຕໍ່ 1 Token — ຫຼາຍໂມເດວມີລາຄາຕໍ່ໜ່ວຍທີ່ແຕກຕ່າງກັນລະຫວ່າງ Input ແລະ Output. ຕ້ອງກວດສອບຄ່າອ້າງອີງໃນເວລາທີ່ຂຽນນີ້ຈາກໜ້າລາຄາທາງການຂອງແຕ່ລະບໍລິສັດສະເໝີ.
3. ຄາດຄະເນອັດຕາສ່ວນ Input/Output — ພາສາລາວມີແນວໂນ້ມທີ່ຈະໃຊ້ Token ຫຼາຍກວ່າພາສາອັງກິດເນື່ອງຈາກຄຸນລັກສະນະຂອງລະຫັດຕົວອັກສອນ. ອັດຕາສ່ວນຕົວຈິງຈຳເປັນຕ້ອງມີການກວດສອບພາຍໃນບໍລິສັດເອງ.
4. ປະເມີນຈຳນວນ Token ສະເລ່ຍຕໍ່ 1 Request — ໃຫ້ໃຊ້ຄ່າສະເລ່ຍຈາກຂໍ້ມູນການທົດສອບ.

ການຕັ້ງຄ່າ Buffer ແມ່ນສິ່ງສຳຄັນ

ການນຳເອົາຂີດຈຳກັດທີ່ຄິດໄລ່ໄດ້ມາໃຊ້ເປັນຂີດຈຳກັດໃນການດຳເນີນງານໂດຍກົງແມ່ນມີຄວາມສ່ຽງ. ຄວນຕັ້ງຄ່າ Buffer ໂດຍພິຈາລະນາ 2 ຈຸດດັ່ງນີ້:

• ຄວາມສ່ຽງດ້ານການຂະຫຍາຍຕົວຂອງ Token ໃນພາສາລາວ: ມີກໍລະນີທີ່ຂໍ້ມູນໃນການນຳໃຊ້ຈິງອາດຈະຍາວຂຶ້ນກວ່າຕອນທົດສອບ.
• ການເພີ່ມຂຶ້ນຢ່າງກະທັນຫັນເນື່ອງຈາກການເຂົ້າໃຊ້ງານໜາແໜ້ນ: ມີແນວໂນ້ມທີ່ຈຳນວນ Request ຈະເພີ່ມຂຶ້ນຢ່າງວ່ອງໄວໃນຊ່ວງເວລາທີ່ມີວຽກຫຼາຍ.

ວິທີການທີ່ຈັດການໄດ້ງ່າຍຄືການຕັ້ງຄ່າອັດຕາສ່ວນໜຶ່ງຂອງຂີດຈຳກັດໃຫ້ເປັນ Alert line ແລະ 100% ເປັນ Hard limit. ຄວນປັບປ່ຽນຄ່າ Threshold ໃຫ້ເໝາະສົມກັບຂະໜາດການດຳເນີນງານ ແລະ ລັກສະນະຂອງວຽກງານພາຍໃນບໍລິສັດເອງ.

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

ໂຄງສ້າງພື້ນຖານຂອງແມ່ແບບການຈຳລອງ

ພາສາລາວມີທ່າອ່ຽງທີ່ຈະມີການແບ່ງ Token ລະອຽດກວ່າເມື່ອທຽບກັບພາສາອັງກິດ. ດັ່ງນັ້ນ, ຕ້ອງລະວັງບໍ່ໃຫ້ໃຊ້ການປະເມີນລາຄາທີ່ອີງໃສ່ພາສາອັງກິດໂດຍກົງ.

3 ຈຸດສຳຄັນ ຫຼື ແກນຫຼັກ ໃນການເພີ່ມຄວາມຖືກຕ້ອງ

• ເພີ່ມ Buffer: ຄິດໄລ່ໂດຍໃຊ້ 1.2-1.5 ເທົ່າຂອງຈຳນວນຄຳຮ້ອງຂໍທີ່ຄາດໄວ້ ເພື່ອກຽມພ້ອມສຳລັບການເພີ່ມຂຶ້ນຢ່າງກະທັນຫັນ
• ແຍກການຄິດໄລ່ຂາເຂົ້າ ແລະ ຂາອອກ: ສຳລັບ Model ທີ່ມີລາຄາຕໍ່ໜ່ວຍແຕກຕ່າງກັນ ຈຳເປັນຕ້ອງຄິດໄລ່ແຍກກັນກ່ອນນຳມາລວມກັນ
• ປຽບທຽບຫຼາຍ Model ຄຽງຄູ່ກັນ: ນຳເອົາຕົ້ນທຶນມາປຽບທຽບກັນໂດຍໃຊ້ຂໍ້ມູນທົດສອບດຽວກັນ ເພື່ອໃຊ້ເປັນຫຼັກຖານໃນການຕັດສິນໃຈ

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

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

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

ລາຍການທີ່ຄວນມີໃນເອກະສານການປະເມີນຜົນ

• ຂໍ້ມູນພື້ນຖານ: ວັນເວລາທີ່ປະເມີນ, ຊື່ຜູ້ປະເມີນ, ຊື່ໂມເດວທີ່ໃຊ້, ເວີຊັນຂອງ Prompt
• ຂໍ້ມູນຂາເຂົ້າ (Input): ID ຂອງກໍລະນີທົດສອບ, ຂໍ້ຄວາມພາສາລາວທີ່ປ້ອນເຂົ້າ, ຄຳຕອບທີ່ຄາດຫວັງ (Gold Label)
• ຂໍ້ມູນຂາອອກ (Output): ຂໍ້ຄວາມທີ່ສ້າງຂຶ້ນ, ເວລາໃນການຕອບສະໜອງ (ວິນາທີ), ຈຳນວນ Token ທີ່ໃຊ້
• ຄໍລຳຄະແນນ: ຄະແນນ BLEU (ຄຳນວນອັດຕະໂນມັດ), ການປະເມີນໂດຍມະນຸດ (1-5 ຄະແນນ), ການມີຢູ່ຂອງ Hallucination (Flag 0/1), ຄວາມເໝາະສົມຂອງຄຳສຸພາບ (ສະເພາະກໍລະນີທີ່ກ່ຽວຂ້ອງ)
• ຊ່ອງຄຳເຫັນ: ປະເພດຂອງຄວາມຜິດພາດ, ຂໍ້ຜິດພາດທາງໄວຍາກອນ, ຄວາມບໍ່ເປັນທຳມະຊາດທາງວັດທະນະທຳ ແລະ ອື່ນໆທີ່ເປັນບັນທຶກທາງຄຸນນະພາບ

ການຈັດການຜ່ານ Spreadsheet ແມ່ນມີຄວາມເປັນໄປໄດ້ຫຼາຍທີ່ສຸດ ແຕ່ການກຳນົດຊື່ຄໍລຳໃຫ້ຄົງທີ່ ແລະ ຕັ້ງກົດການປ້ອນຂໍ້ມູນແບບ Pull-down ຈະຊ່ວຍຫຼຸດຜ່ອນຄວາມຜິດພາດໃນການບັນທຶກໄດ້. ການປະເມີນໂດຍມະນຸດຄວນເຮັດໂດຍຜູ້ປະເມີນ 2 ຄົນຂຶ້ນໄປ ແລະ ຄວນຄຳນວນອັດຕາຄວາມສອດຄ່ອງ (Consistency) ໄວ້ໃນ Sheet ອື່ນໂດຍໃຊ້ Cohen's Kappa coefficient ເພື່ອເຮັດໃຫ້ຄວາມໜ້າເຊື່ອຖືສາມາດເບິ່ງເຫັນໄດ້ຢ່າງຊັດເຈນ.

ຂໍ້ຄວນລະວັງໃນການບັນທຶກ

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

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

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

4 ກົດລະບຽບການນຳໃຊ້ທີ່ຈຳເປັນເພື່ອໃຫ້ເກີດຄວາມຍືນຍົງ

• ກຳນົດຜູ້ຮັບຜິດຊອບການປະເມີນໃຫ້ຄົງທີ່: ໃຊ້ລະບົບ 2 ຄົນ ຄື ຜູ້ຮັບຜິດຊອບຫຼັກ 1 ຄົນ ແລະ ຜູ້ກວດສອບ 1 ຄົນ ເພື່ອປ້ອງກັນຄວາມຜິດພາດໃນເກນການຕັດສິນໃຈ.
• ກຳນົດຮອບວຽນການປະເມີນ: ໃນຊ່ວງເລີ່ມຕົ້ນໃຫ້ກຳນົດທຸກໆ 2 ອາທິດ ແລະ ເມື່ອລະບົບເຮັດວຽກໄດ້ຢ່າງໝັ້ນຄົງແລ້ວ ໃຫ້ກຳນົດເປັນເດືອນລະ 1 ຄັ້ງ.
• ບັນທຶກ ແລະ ເຮັດໃຫ້ການປ່ຽນແປງຂອງຄະແນນເຫັນພາບໄດ້: ສະສົມຂໍ້ມູນໄວ້ໃນ Spreadsheet ຫຼື Dashboard ແລະ ຕ້ອງມີການປຽບທຽບກັບຄັ້ງກ່ອນສະເໝີ.
• ກຳນົດຂະບວນການແຈ້ງເຕືອນ (Escalation flow): ກຳນົດການປະຕິບັດງານໃຫ້ຊັດເຈນ ເຊັ່ນ: "ຖ້າຄະແນນ BLEU ຫຼຸດຕ່ຳກວ່າເກນທີ່ກຳນົດໄວ້ ໃຫ້ຕິດຕໍ່ຫາວິສະວະກອນທັນທີ".

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

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

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

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

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

ລາຍການທີ່ແນະນຳໃຫ້ລວມຢູ່ໃນ Scorecard ມີດັ່ງນີ້:

• ຄະແນນຄຸນນະພາບການແປ: ຄະແນນ BLEU ແລະ ຄະແນນສະເລ່ຍຈາກການປະເມີນໂດຍມະນຸດ (5 ລະດັບ)
• ອັດຕາການເກີດ Hallucination: ອັດຕາສ່ວນຂອງຂໍ້ມູນທີ່ຜິດພາດ ຫຼື ຄວາມເຂົ້າໃຈຜິດທາງຂໍ້ເທັດຈິງເມື່ອທຽບກັບຊຸດທົດສອບທັງໝົດ
• Latency: ເວລາຕອບສະໜອງສະເລ່ຍ ແລະ ຄ່າ 95th percentile
• ຄ່າໃຊ້ຈ່າຍປະມານການລາຍເດືອນ: ຄ່າໃຊ້ຈ່າຍ Token ທີ່ຄິດໄລ່ຈາກຈຳນວນ Request ທີ່ຄາດໄວ້ ຄູນກັບລາຄາຕໍ່ໜ່ວຍ
• ການຕັດສິນໃຈລວມ: 3 ລະດັບ ຄື Go / Go ແບບມີເງື່ອນໄຂ / No-Go

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

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

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

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

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

ມາດຕະຖານສຳລັບວິສາຫະກິດ (Enterprise)

• ຄຸນນະພາບການແປ: ຄະແນນຈາກມະນຸດ (Human score) ໂດຍຜູ້ປະເມີນທີ່ເປັນເຈົ້າຂອງພາສາຕ້ອງໄດ້ 4.0/5.0 ຂຶ້ນໄປ.
• ອັດຕາການເກີດ Hallucination: ໃນຂະແໜງການເງິນ, ກົດໝາຍ ແລະ ການແພດ ມີແນວໂນ້ມທີ່ຈະຕ້ອງການມາດຕະຖານທີ່ເຂັ້ມງວດເປັນພິເສດ, ເຊິ່ງມີການລາຍງານເຖິງການດຳເນີນງານທີ່ຄວບຄຸມຂໍ້ມູນທີ່ຜິດພາດໃຫ້ໜ້ອຍທີ່ສຸດ ເຖິງແມ່ນວ່າຈະເປັນການຕັ້ງຄ່າແບບ RAG ກໍຕາມ.
• Latency (ຄວາມໜ່ວງ): ສຳລັບການນຳໃຊ້ໃນດ້ານການບໍລິການລູກຄ້າ, ມັກຈະມີການລະບຸຂີດຈຳກັດຂອງຄວາມໄວໃນການຕອບສະໜອງ ແລະ ບັນຈຸເຂົ້າໃນ SLA.
• ການປະຕິບັດຕາມກົດລະບຽບ (Compliance): ເພີ່ມການກວດສອບຄວາມສອດຄ່ອງຂອງພື້ນທີ່ການປະມວນຜົນຂໍ້ມູນ ແລະ ນະໂຍບາຍການເກັບຮັກສາບັນທຶກ (Log) ເຂົ້າເປັນເງື່ອນໄຂໃນການຜ່ານເກນ.

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

ມາດຕະຖານສຳລັບ SMB

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

ເນື່ອງຈາກ SMB ມີຊັບພະຍາກອນໃນການປະເມີນທີ່ຈຳກັດ, ຈຶ່ງມີແນວໂນ້ມທີ່ຈະໃຊ້ວິທີການແບບ Agile ຄື "ເລີ່ມເປີດໃຊ້ງານກ່ອນ ແລ້ວຈຶ່ງປັບປຸງໃນລະຫວ່າງການດຳເນີນງານ".

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

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

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

ຮູບແບບທົ່ວໄປທີ່ມັກເຮັດໃຫ້ເກີດຄວາມແຕກຕ່າງ ມີດັ່ງນີ້:

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

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

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

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

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

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

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

ຕົວຊີ້ວັດທີ່ມັກຖືກມອງຂ້າມມີດັ່ງນີ້:

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

ສິ່ງທີ່ຄວນລະວັງເປັນພິເສດຄືຮູບແບບການເລືອກ "ແບບຈໍາລອງທີ່ມີຄວາມແມ່ນຍໍາສູງ ແຕ່ຕອບສະໜອງຊ້າ". ຖ້າເກີດ Time-out ເລື້ອຍໆ, ລະບົບຈະເຮັດການ Retry ໂດຍອັດຕະໂນມັດ ເຊິ່ງມັກຈະເຮັດໃຫ້ເກີດການຄິດໄລ່ຄ່າໃຊ້ຈ່າຍຫຼາຍຄັ້ງຕໍ່ກັບ Query ດຽວກັນ.

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

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

ໄລຍະເວລາ ແລະ ຄ່າໃຊ້ຈ່າຍໃນໄລຍະການປະເມີນຜົນຈະແຕກຕ່າງກັນໄປຕາມຂະໜາດຂອງໂຄງການ, ແຕ່ການເຂົ້າໃຈເຖິງມາດຕະຖານເບື້ອງຕົ້ນຈະຊ່ວຍໃຫ້ການວາງແຜນງ່າຍຂຶ້ນ.

ມາດຕະຖານໄລຍະເວລາ

ໃນກໍລະນີທີ່ມີໂຄງສ້າງຂັ້ນຕໍ່າສຸດ (ວິສະວະກອນ 1-2 ຄົນ, ຂໍ້ມູນທົດສອບ 100 ລາຍການ), ຕາຕະລາງເວລາທີ່ເປັນຈິງມີດັ່ງນີ້:

• ການເກັບກຳ ແລະ ປັບປຸງຂໍ້ມູນທົດສອບ: 3-5 ວັນເຮັດວຽກ
• ການສ້າງສະພາບແວດລ້ອມການປະເມີນຜົນ ແລະ ການເຊື່ອມຕໍ່ໂມເດວ: 1-2 ວັນເຮັດວຽກ
• ການວັດແທກຄຸນນະພາບການແປພາສາ ແລະ ອັດຕາການເກີດ Hallucination: 2-3 ວັນເຮັດວຽກ
• ການລວບລວມຜົນລວມ ແລະ ການສ້າງ Scorecard: 1-2 ວັນເຮັດວຽກ

ລວມແລ້ວ, ໄລຍະເວລາສັ້ນທີ່ສຸດແມ່ນ 2 ອາທິດ, ແລະ ຖ້າເຜື່ອເວລາໄວ້ກໍຈະຢູ່ທີ່ປະມານ 3-4 ອາທິດ. ໃນກໍລະນີທີ່ມີການເພີ່ມການປະເມີນຜົນໂດຍມະນຸດທີ່ເປັນເຈົ້າຂອງພາສາລາວ, ມັກຈະຕ້ອງໃຊ້ເວລາເພີ່ມອີກ 1-2 ອາທິດໃນການປະສານງານກັບຜູ້ກວດສອບ.

ມາດຕະຖານຄ່າໃຊ້ຈ່າຍ

ຄ່າໃຊ້ຈ່າຍຄວນພິຈາລະນາຈາກ 2 ແກນຫຼັກ ຄື "ຄ່າບໍລິການ API" ແລະ "ຄ່າແຮງງານ".

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

ຄ່າໃຊ້ຈ່າຍທາງອ້ອມທີ່ມັກຖືກມອງຂ້າມ

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

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

ການນຳໃຊ້ເຄື່ອງມືທີ່ອີງໃສ່ GUI

LangSmith ແລະ Langfuse ສາມາດບັນທຶກ ແລະ ປຽບທຽບຜົນລັພຂອງ Prompt ໄດ້ໂດຍບໍ່ຕ້ອງຂຽນ Code. ໃນຫຼາຍກໍລະນີ, ພຽງແຕ່ຈັດລຽງຂໍ້ມູນ Input ທີ່ຕ້ອງການທົດສອບ ແລະ Output ທີ່ຄາດຫວັງໄວ້ໃນ Spreadsheet, ຈາກນັ້ນຕັ້ງຄ່າ API Key ກໍສາມາດເກັບກຳ Log ການປະເມີນຜົນໄດ້ໂດຍອັດຕະໂນມັດ.

ການປະສົມປະສານຊັບພະຍາກອນພາຍນອກ

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

Spreadsheet ກໍພຽງພໍສຳລັບໃບປະເມີນຜົນ

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

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

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

• ໄລຍະກຽມຄວາມພ້ອມ: ຈັດຕຽມຊຸດທົດສອບ (Test set) ຫຼາຍກວ່າ 100 ລາຍການ ທີ່ສະທ້ອນເຖິງຂໍ້ມູນການນຳໃຊ້ຈິງ.
• ຂັ້ນຕອນທີ 1: ວັດແທກຄຸນນະພາບການແປພາສາ ໂດຍການປະສົມປະສານລະຫວ່າງຄະແນນ BLEU ແລະ ການປະເມີນໂດຍມະນຸດ.
• ຂັ້ນຕອນທີ 2: ເຮັດໃຫ້ອັດຕາການເກີດ Hallucination ເຫັນພາບໄດ້ຊັດເຈນ ໂດຍການປຽບທຽບລະຫວ່າງການມີ ແລະ ບໍ່ມີ RAG.
• ຂັ້ນຕອນທີ 3: ຄິດໄລ່ຂີດຈຳກັດຂອງ Token ຈາກງົບປະມານລາຍເດືອນ ເພື່ອອອກແບບເກນຄ່າໃຊ້ຈ່າຍ (Cost threshold).
• ຂັ້ນຕອນທີ 4: ຈັດຕຽມໃບປະເມີນຜົນ ແລະ ໂປຣໂຕຄອນ ເພື່ອເຮັດໃຫ້ເປັນຊັບສິນຂອງອົງກອນທີ່ສາມາດນຳມາໃຊ້ຊ້ຳໄດ້.

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

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

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