ດັດຊະນີການປະເມີນຜົນ ແລະ ວິທີການຈັດຕັ້ງປະຕິບັດເພື່ອວັດແທກຄຸນນະພາບຜົນລວມຂອງແບບຈຳລອງ Generative AI

ເມື່ອດຳເນີນການ Generative AI ໃນສະພາບແວດລ້ອມການຜະລິດ (Production), ບາງຄັ້ງອາດມີສຽງສະທ້ອນຈາກໜ້າວຽກວ່າ "ຄຸນນະພາບຂອງຜົນລັດຫຼຸດລົງ". ຢ່າງໃດກໍຕາມ, ການລະບຸວ່າຄຸນນະພາບເລີ່ມຫຼຸດລົງຕັ້ງແຕ່ເມື່ອໃດ ແລະ ມີຂອບເຂດຜົນກະທົບຫຼາຍໜ້ອຍພຽງໃດນັ້ນ ບໍ່ແມ່ນເລື່ອງງ່າຍຫາກອາໄສພຽງການປະເມີນດ້ວຍມະນຸດ. ໃນບົດຄວາມນີ້, ພວກເຮົາຈະອະທິບາຍວິທີການກວດສອບການຫຼຸດລົງຂອງຜົນລັດດັ່ງກ່າວຢ່າງຕໍ່ເນື່ອງໂດຍບໍ່ຕ້ອງເພິ່ງພາການປະເມີນດ້ວຍມະນຸດ, ໂດຍການນຳໃຊ້ຕົວຊີ້ວັດການປະເມີນແບບອັດຕະໂນມັດ ເຊັ່ນ: BLEU, ROUGE, ແລະ BERTScore ມາປະສົມປະສານກັບເຄື່ອງມືຕິດຕາມກວດສອບຄຸນນະພາບ. ກຸ່ມເປົ້າໝາຍຂອງບົດຄວາມນີ້ແມ່ນ ML Engineers, ຜູ້ຮັບຜິດຊອບດ້ານ QA, ແລະ Data Scientists ທີ່ກຳລັງດຳເນີນການ Generative AI ໃນສະພາບແວດລ້ອມການຜະລິດ. ພວກເຮົາຈະແນະນຳຕັ້ງແຕ່ວິທີການເລືອກຕົວຊີ້ວັດການປະເມີນແບບອັດຕະໂນມັດ, ຂັ້ນຕອນການນຳໃຊ້ເຄື່ອງມືຕິດຕາມກວດສອບ, ຈົນເຖິງການຕັ້ງຄ່າ Alert Threshold ພ້ອມກັບຕົວຢ່າງການປະຕິບັດຕົວຈິງ, ເພື່ອສະແດງໃຫ້ເຫັນວິທີການສ້າງລະບົບການປະເມີນແບບອັດຕະໂນມັດທີ່ສາມາດຫຼຸດຜ່ອນເວລາໃນການກວດສອບການຫຼຸດລົງຂອງຄຸນນະພາບໄດ້ຢ່າງຫຼວງຫຼາຍເມື່ອທຽບກັບການປະເມີນດ້ວຍມະນຸດ. ຫວັງວ່າບົດຄວາມນີ້ຈະເປັນແນວທາງໃນການນຳເອົາກົນໄກການຮັບປະກັນຄຸນນະພາບຢ່າງຕໍ່ເນື່ອງໄປປັບໃຊ້ໃນຂະບວນການດຳເນີນງານຂອງບໍລິສັດທ່ານ.

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

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

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

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

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

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

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

ຕົວຊີ້ວັດໃນການວັດແທກຄຸນນະພາບຜົນລວມຂອງ Generative AI ສາມາດແບ່ງອອກເປັນ 3 ກຸ່ມໃຫຍ່ຄື: ກຸ່ມວັດແທກຄວາມສອດຄ່ອງຂອງຮູບແບບພາສາ (Surface-level matching) ເຊັ່ນ BLEU ຫຼື ROUGE ເຊິ່ງວັດແທກຄວາມຊໍ້າຊ້ອນຂອງຄຳສັບ ແລະ ສຳນວນໂດຍໃຊ້ກົນໄກທາງຄະນິດສາດ, ກຸ່ມວັດແທກຄວາມສອດຄ່ອງທາງຄວາມໝາຍ (Semantic matching) ເຊັ່ນ BERTScore ເຊິ່ງຈັບຄວາມໃກ້ຄຽງທາງຄວາມໝາຍຂອງປະໂຫຍກໃນພື້ນທີ່ Vector, ແລະ ກຸ່ມຕົວຊີ້ວັດສະເພາະທີ່ອອກແບບມາສຳລັບແຕ່ລະ Task ເຊັ່ນ: ການສະຫຼຸບຄວາມ, ການແປພາສາ ແລະ ການຕອບຄຳຖາມ.

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

BLEU, ROUGE, ແລະ BERTScore ມີບົດບາດແຕກຕ່າງກັນໂດຍອີງໃສ່ວ່າພວກມັນກວດສອບຄວາມສອດຄ່ອງຂອງຮູບແບບພາສາ (Surface match) ຫຼື ຄວາມສອດຄ່ອງທາງຄວາມໝາຍ (Semantic match). ການເຂົ້າໃຈຄວາມແຕກຕ່າງນີ້ຈະຊ່ວຍໃຫ້ທ່ານເລືອກຕົວຊີ້ວັດທີ່ເໝາະສົມກັບວຽກງານໄດ້ຢ່າງຖືກຕ້ອງ.

BLEU ເປັນຕົວຊີ້ວັດທີ່ສະເໜີໂດຍ Papineni ແລະ ຄະນະ ໃນປີ 2002, ເຊິ່ງວັດແທກອັດຕາການກົງກັນຂອງ N-gram ລະຫວ່າງຂໍ້ຄວາມທີ່ສ້າງຂຶ້ນກັບຂໍ້ຄວາມອ້າງອີງ. ມັນຖືກໃຊ້ເປັນມາດຕະຖານໃນການປະເມີນຜົນການແປພາສາ, ແລະ sacreBLEU ມັກຈະຖືກນຳມາໃຊ້ໃນການປະຕິບັດງານເພື່ອເນັ້ນຄວາມສາມາດໃນການເຮັດຊ້ຳ (Reproducibility). ຢ່າງໃດກໍຕາມ, ເນື່ອງຈາກມັນບໍ່ຖືວ່າການປ່ຽນຄຳສັບ (Paraphrasing) ເປັນການກົງກັນ, ມັນຈຶ່ງມີທ່າອ່ຽງທີ່ຈະໃຫ້ຄະແນນຕ່ຳຫາກການສະແດງອອກຕ່າງກັນເຖິງວ່າຈະມີຄວາມໝາຍດຽວກັນກໍຕາມ.

ROUGE ເປັນຕົວຊີ້ວັດສຳລັບການປະເມີນການສະຫຼຸບຄວາມທີ່ Lin ໄດ້ເປີດຕົວໃນປີ 2004, ເຊິ່ງວັດແທກວ່າຂໍ້ຄວາມທີ່ສ້າງຂຶ້ນສາມາດຖອດແບບ N-gram ທີ່ຢູ່ໃນຂໍ້ຄວາມອ້າງອີງໄດ້ຫຼາຍໜ້ອຍພຽງໃດ. ມັນມີຫຼາຍຮູບແບບເຊັ່ນ: ROUGE-1, ROUGE-2, ແລະ ROUGE-L, ເຊິ່ງຖືກນຳໃຊ້ຢ່າງກວ້າງຂວາງໃນການກວດສອບຄຸນນະພາບຂອງວຽກງານການສະຫຼຸບຄວາມ.

BERTScore ເປັນຕົວຊີ້ວັດທີ່ຄຳນວນຄວາມຄ້າຍຄືກັນທາງຄວາມໝາຍໃນລະດັບ Token ໂດຍໃຊ້ Embedding ຂອງ BERT, ເຊິ່ງຖືກສະເໜີໃນບົດຄວາມວິໄຈຂອງ Zhang ແລະ ຄະນະ. ເນື່ອງຈາກບໍ່ໄດ້ຂຶ້ນກັບການກົງກັນຂອງຮູບແບບພາສາ, ຈຸດທີ່ແຕກຕ່າງຢ່າງຊັດເຈນຈາກ BLEU ແລະ ROUGE ຄືຄວາມສາມາດໃນການຮອງຮັບການປ່ຽນຄຳສັບ ແລະ ການໃຊ້ຄຳສັບທີ່ມີຄວາມໝາຍດຽວກັນ (Synonyms).

ໃນການກວດສອບການເຮັດວຽກຈິງຂອງ Generative AI, ການນຳໃຊ້ ROUGE ແລະ BLEU ສຳລັບວຽກງານການສະຫຼຸບຄວາມ ຫຼື ການແປພາສາທີ່ມີຂໍ້ຄວາມອ້າງອີງ, ຄວບຄູ່ກັບການໃຊ້ BERTScore ສຳລັບການປະເມີນການຕອບໂຕ້ໃນວຽກງານການສ້າງບົດສົນທະນາ ຫຼື RAG (Retrieval-Augmented Generation) ທີ່ຕ້ອງການກວດສອບຄວາມຖືກຕ້ອງທາງຄວາມໝາຍຫຼາຍກວ່ານັ້ນ ແມ່ນວິທີການທີ່ນຳໄປໃຊ້ໄດ້ຈິງ. ການບໍ່ເພິ່ງພາຕົວຊີ້ວັດດຽວ ແຕ່ຫັນມາບັນທຶກ Log ຂອງຫຼາຍຕົວຊີ້ວັດເພື່ອຕິດຕາມທ່າອ່ຽງ ຈະຊ່ວຍໃຫ້ຄົ້ນພົບຄວາມເສື່ອມຖອຍຂອງຄຸນນະພາບໄດ້ໄວຂຶ້ນ.

ຖ້າທ່ານຕ້ອງການກວດສອບການປ່ຽນແປງຮູບແບບການສະແດງອອກ (Paraphrase), ການໃຊ້ຄ່າຄວາມຄ້າຍຄືກັນແບບໂຄຊາຍ (Cosine Similarity) ເພື່ອວັດແທກຄວາມສອດຄ່ອງທາງຄວາມໝາຍແມ່ນມີປະສິດທິພາບ, ສ່ວນການປະເມີນລຳດັບຂອງຄຳສັບໂດຍກົງແມ່ນເໝາະສົມກັບຕົວຊີ້ວັດການຈັບຄູ່ທາງຮູບແບບເຊັ່ນ BLEU ຫຼື ROUGE. ໃນການວັດແທກຄວາມສອດຄ່ອງທາງຄວາມໝາຍ, ຂໍ້ຄວາມຜົນລວມ (Output) ແລະ ຂໍ້ຄວາມອ້າງອີງ (Reference) ຈະຖືກປ່ຽນເປັນເວັກເຕີດ້ວຍ Embedding, ຈາກນັ້ນນຳມາຄຳນວນເປັນຕົວເລກດ້ວຍ Cosine Similarity ເພື່ອເບິ່ງວ່າທິດທາງຂອງທັງສອງໃກ້ຄຽງກັນຫຼາຍພຽງໃດ. ນີ້ບໍ່ແມ່ນວິທີການໃຫ້ຄະແນນທີ່ເນັ້ນ "ການຈັບຄູ່ຄຳສັບທີ່ສົມບູນແບບ", ແຕ່ເປັນວິທີການປະເມີນທີ່ວັດແທກວ່າ "ເຖິງວ່າສຳນວນຈະຕ່າງກັນ ແຕ່ທິດທາງຂອງຄວາມໝາຍຄືກັນຫຼືບໍ່".

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

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

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

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

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

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

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

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

ໂດຍສະເພາະ, ຜົນການອະນຸມານ (Inference) ແລະ ຂໍ້ຄວາມອ້າງອີງ (ຂໍ້ມູນຄຳຕອບທີ່ຖືກຕ້ອງ ຫຼື ບົດສະຫຼຸບອ້າງອີງ) ຈະຖືກບັນທຶກໄວ້ເປັນຄູ່, ຈາກນັ້ນຈະຄຳນວນ BLEU, ROUGE, BERTScore ແລະ ອື່ນໆ ດ້ວຍການປະມວນຜົນແບບ Batch. ເຫດຜົນທີ່ເລືອກການປະມວນຜົນແບບ Batch ແມ່ນຍ້ອນວ່າຫາກຄຳນວນແບບ Real-time, ຕົ້ນທຶນໃນການປະເມີນຜົນຈະຖືກເພີ່ມເຂົ້າໄປໃນ Latency ຂອງການອະນຸມານ ເຊິ່ງຈະເຮັດໃຫ້ການຕອບສະໜອງຂອງລະບົບຈິງຊ້າລົງ. ໃນຫຼາຍໜ້າວຽກ, ຈະນິຍົມໃຊ້ໂຄງສ້າງທີ່ເກັບບັນທຶກ Log ການອະນຸມານໄວ້ໃນ Queue ຫຼື Storage ກ່ອນ, ແລ້ວຈຶ່ງສັ່ງໃຫ້ວຽກງານການປະເມີນຜົນເຮັດວຽກແບບບໍ່ປະສານເວລາ (Asynchronous) ທຸກໆສອງສາມນາທີ ຫຼື ທຸກໆສອງສາມຊົ່ວໂມງ.

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

Log ເຫຼົ່ານີ້ຈະຖືກສົ່ງຂໍ້ມູນຕໍ່ໃຫ້ຖານຂໍ້ມູນແບບ Time-series ຫຼື ໂຄງສ້າງພື້ນຖານ ຫຼື Infrastructure ໃນການເກັບກຳ Metrics (ເຊັ່ນ: Prometheus) ເພື່ອໃຊ້ໃນການເບິ່ງພາບລວມ (Visualization) ແລະ ກວດຈັບຄວາມຜິດປົກກະຕິໃນເຄື່ອງມືຕິດຕາມກວດກາ (Monitoring tool) ທີ່ຈະກ່າວເຖິງໃນຫົວຂໍ້ຕໍ່ໄປ.

ຖ້າເປົ້າໝາຍການຕິດຕາມກວດກາແມ່ນການກວດຫາການປ່ຽນແປງ (Drift) ຂອງຄຸນນະພາບການສ້າງຂໍ້ຄວາມ, OSS ເຊັ່ນ Evidently ຫຼື NannyML ແມ່ນເໝາະສົມ, ສ່ວນການປະຍຸກໃຊ້ດ້ວຍຕົນເອງຜ່ານ Prometheus ແມ່ນເໝາະສົມໃນກໍລະນີທີ່ຕ້ອງການລວມເມຕຣິກເຂົ້າກັບໂຄງສ້າງພື້ນຖານ ຫຼື Infrastructure ດ້ານອະນຸກົມເວລາທີ່ມີຢູ່ແລ້ວ. Evidently ເປັນເຟຣມເວີກການຕິດຕາມກວດກາແບບໂອເພນຊອດສຳລັບ ML/LLM ເຊິ່ງສາມາດສ້າງລະບົບກວດຫາ Data Drift ຫຼື ການປ່ຽນແປງຂອງການກະຈາຍຜົນລວມ (Output distribution) ໄດ້ໃນໄລຍະເວລາອັນສັ້ນ ໂດຍປະຕິບັດຕາມເອກະສານທາງການ. NannyML ມີຈຸດແຂງໃນການຄາດຄະເນປະສິດທິພາບໂດຍບໍ່ຕ້ອງມີປ້າຍກຳກັບ (Label), ເຊິ່ງເໝາະສົມກັບການນຳໃຊ້ໃນສະພາບແວດລ້ອມການຜະລິດ (Production) ທີ່ການໄດ້ມາເຊິ່ງຂໍ້ມູນທີ່ຖືກຕ້ອງ (Ground truth) ມີຄວາມຊັກຊ້າ ເພື່ອໃຫ້ສາມາດກວດຈັບສັນຍານການຫຼຸດລົງຂອງຄຸນນະພາບໄດ້ລ່ວງໜ້າ.

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

ແກນຫຼັກ ຫຼື ຈຸດສຳຄັນ ໃນການຄັດເລືອກແມ່ນຕົ້ນທຶນໃນການເຊື່ອມໂຍງກັບໂຄງສ້າງພື້ນຖານ ຫຼື Infrastructure ດ້ານ MLOps ທີ່ມີຢູ່ ແລະ ການເຊື່ອມຕໍ່ກັບຂະບວນການ ຫຼື Pipeline ທີ່ໃຊ້ຄຳນວນຕົວຊີ້ວັດທີ່ຈຳເປັນ (ເຊັ່ນ: BLEU, ROUGE, BERTScore). ສຳລັບອົງກອນທີ່ເກັບກຳເມຕຣິກຂອງລະບົບດ້ວຍ Prometheus ຢູ່ແລ້ວ, ການຕັ້ງຄ່າໂດຍການສົ່ງອອກ (Export) ຕົວຊີ້ວັດການປະເມີນຜົນ ແລະ ຕິດຕາມກວດກາຄ່າ Threshold ດ້ວຍ PromQL ແມ່ນເໝາະສົມກັບການລວມສູນການດຳເນີນງານ. ໃນທາງກົງກັນຂ້າມ, ຖ້າຕ້ອງການຈັດການຕັ້ງແຕ່ການຄຳນວນຕົວຊີ້ວັດໄປຈົນເຖິງການກວດຫາ Drift ພາຍໃນບ່ອນດຽວ, ການໃຫ້ຄວາມສຳຄັນກັບເຄື່ອງມືທີ່ເນັ້ນສະເພາະດ້ານ ML ເຊັ່ນ Evidently ຫຼື NannyML ຈະຊ່ວຍຫຼຸດພາລະໃນການນຳໃຊ້ໄດ້ຫຼາຍກວ່າ.

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

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

ການກວດສອບຄວາມຜິດປົກກະຕິທາງສະຖິຕິ (Statistical Anomaly Detection) ແມ່ນວິທີການທີ່ມອບໝາຍການຕັດສິນໃຈນີ້ໃຫ້ເປັນມາດຕະຖານຕົວເລກ ແທນທີ່ຈະໃຊ້ຄວາມຮູ້ສຶກຂອງຄົນ. ວິທີການທີ່ເປັນຕົວແທນມີ 3 ຢ່າງດັ່ງນີ້:

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

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

ການຕັດສິນໃຈ: ຄ່າ Threshold ບໍ່ແມ່ນຄ່າຄົງທີ່ ແຕ່ຈະກຳນົດໂດຍອີງໃສ່ຄ່າບ່ຽງເບນຈາກ Baseline ທີ່ໄດ້ມາຈາກການກວດຈັບຄວາມຜິດປົກກະຕິທາງສະຖິຕິ.

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

ກົດລະບຽບການດຳເນີນງານຈະຖືກບັນທຶກໄວ້ໂດຍອີງໃສ່ທັດສະນະດັ່ງຕໍ່ໄປນີ້:

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

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

ທາງເລືອກຈະແຕກຕ່າງກັນໄປຕາມການມີຢູ່ຂອງໂຄງສ້າງພື້ນຖານ ຫຼື Infrastructure ດ້ານ MLOps ທີ່ມີຢູ່ແລ້ວ. ຖ້າທ່ານຕ້ອງການພຽງແຕ່ການກວດຫາ Drift ທາງສະຖິຕິແບບເບົາບາງ ກໍເໝາະກັບ OSS, ຖ້າຕ້ອງການເຖິງຂັ້ນການຕິດຕາມຄວາມສາມາດໃນການກວດສອບ (Traceability) ຂອງຜົນລັພ LLM ແລະ ການຮ່ວມມືລະຫວ່າງທີມ ກໍເໝາະກັບແພລດຟອມແບບປະສົມປະສານ, ແລະ ຖ້າຕ້ອງການເຮັດໃຫ້ສຳເລັດພາຍໃນສະພາບແວດລ້ອມ AWS ກໍເໝາະກັບປະເພດ Cloud-native.

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

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

ຖ້າຫາກເຮົາໃຊ້ພຽງແຕ່ຕົວຊີ້ວັດການປະເມີນຜົນແບບອັດຕະໂນມັດ (Automatic evaluation metrics) ຢ່າງຕໍ່ເນື່ອງ, ຄຸນນະພາບຈະຖືກຮັກສາໄວ້ໄດ້ແທ້ໆຫຼືບໍ່?

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

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

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

ເກນການຕັດສິນ: ຕົວຊີ້ວັດທີ່ຄວນໃຫ້ຄວາມສຳຄັນຈະແຕກຕ່າງກັນໄປຕາມປະເພດຂອງວຽກ ແລະ ລະດັບຄວາມອິດສະຫຼະຂອງຜົນລັພ.

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

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

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

ແນວທາງໃນການກຳນົດລຳດັບຄວາມສຳຄັນມີດັ່ງນີ້:

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

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

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

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

ລຳດັບຄວາມສຳຄັນໃນການແກ້ໄຂແມ່ນການກວດສອບ ຄວາມສາມາດໃນການເຮັດຊ້ຳ (Reproducibility) ເປັນອັນດັບທຳອິດ. ຖ້າຫາກການປ້ອນຂໍ້ມູນດຽວກັນເຂົ້າໄປໃໝ່ແລ້ວຄະແນນຍັງຕໍ່າຢູ່ ໃຫ້ສົງໄສວ່າເກີດຈາກການປ່ຽນແປງທາງດ້ານຕົວແບບ ຫຼື Prompt Template, ແຕ່ຖ້າຜົນລັອກມີຄວາມສະຖຽນເມື່ອປ່ຽນຂໍ້ມູນຂາເຂົ້າ ໃຫ້ສົງໄສວ່າເກີດຈາກການປ່ຽນແປງທາງດ້ານຂໍ້ມູນ. ຖ້າເປັນໂຄງສ້າງ RAG, ຍັງມີຄວາມເປັນໄປໄດ້ທີ່ຜົນການຄົ້ນຫາຂອງ Vector Database ຈະຫຼຸດຄຸນນະພາບລົງ, ດັ່ງນັ້ນການກວດສອບຄວາມຖືກຕ້ອງຂອງການຄົ້ນຫາ (Search Accuracy) ແຍກຕ່າງຫາກດ້ວຍ Grounding Check ຈຶ່ງມີປະສິດທິຜົນ. ເມື່ອລະບຸສາເຫດໄດ້ແລ້ວ, ການເລີ່ມຕົ້ນຈາກການແກ້ໄຂໃນຂອບເຂດທີ່ໄດ້ຮັບຜົນກະທົບ ເຊັ່ນ: ການ Rollback Prompt ຫຼື ການສ້າງ Search Index ຄືນໃໝ່ ຈະຊ່ວຍຫຼຸດເວລາໃນການກູ້ຄືນລະບົບໃຫ້ສັ້ນລົງໄດ້.

ການສ້າງລະບົບການວັດແທກແບບອັດຕະໂນມັດ

ການສ້າງລະບົບການວັດແທກແບບອັດຕະໂນມັດ ຈະມີຄວາມຜິດພາດໜ້ອຍລົງ ຫາກດຳເນີນໄປແບບເປັນຂັ້ນເປັນຕອນ ຕັ້ງແຕ່