Eval-Driven Development (EDD) ແມ່ນຫຍັງ? ຂະບວນການພັດທະນາ AI ທີ່ເນັ້ນການປະເມີນຜົນເປັນຫຼັກ

Eval-Driven Development (EDD) ແມ່ນວິທີການພັດທະນາທີ່ວາງການອອກແບບຕົວຊີ້ວັດການປະເມີນຜົນໄວ້ເປັນຈຸດເລີ່ມຕົ້ນຂອງການພັດທະນາ AI, ໂດຍຮັບປະກັນຄຸນນະພາບຂອງໂມເດວ ແລະ ຜະລິດຕະພັນຜ່ານວົງຈອນການປະເມີນຜົນຢ່າງຕໍ່ເນື່ອງ.

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

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

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

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

TDD (Test-Driven Development) ແລະ EDD ລ້ວນແຕ່ມີແນວຄິດຮ່ວມກັນຄື "ການກຳນົດມາດຕະຖານຄຸນນະພາບກ່ອນການລົງມືພັດທະນາ". ເຊັ່ນດຽວກັບທີ່ TDD ໃຫ້ຂຽນ Unit Test ກ່ອນຂຽນ Code, EDD ກໍໃຫ້ກຽມຕົວຊີ້ວັດການປະເມີນຜົນ ແລະ ຊຸດຂໍ້ມູນການປະເມີນຜົນກ່ອນການສ້າງແອັບພລິເຄຊັນ LLM.

ການສະຫຼຸບຈຸດຮ່ວມ:

• ກຳນົດມາດຕະຖານຄຸນນະພາບໄວ້ກ່ອນ ແລະ ເຮັດຊ້ຳການປັບປຸງຈົນກວ່າການພັດທະນາຈະບັນລຸມາດຕະຖານນັ້ນ
• ໃຊ້ກໍລະນີທີ່ລົ້ມເຫຼວ (Test ລົ້ມເຫຼວ / ຄະແນນການປະເມີນຫຼຸດລົງ) ເປັນຈຸດເລີ່ມຕົ້ນຂອງວົງຈອນການພັດທະນາ
• ສາມາດກວດພົບການຖົດຖອຍ (Regression) ໄດ້ໄວໂດຍການນຳໄປລວມກັບ Continuous Integration

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

ຈຸດສຳຄັນ ຫຼື ແກນຫຼັກ ຂອງຄວາມແຕກຕ່າງ:

ໃນ TDD ຈະຖາມວ່າ "Test ຜ່ານຫຼືບໍ່", ແຕ່ໃນ EDD ຈະຖາມວ່າ "ຄວາມຖືກຕ້ອງຂອງຄຳຕອບເກີນເກນທີ່ກຳນົດໄວ້ຫຼືບໍ່". ໃນຕົວຢ່າງການປະເມີນຜົນຂອງ MLflow, correctness/mean ຈະຢູ່ທີ່ 0.

ໃນການພັດທະນາຊອບແວແບບດັ້ງເດີມ, ການທົດສອບແບບກຳນົດຜົນໄດ້ (Deterministic testing) ທີ່ວ່າ "ຖ້າປ້ອນຂໍ້ມູນ A ເຂົ້າໄປ ຈະໄດ້ຜົນລັພ B ກັບຄືນມາ" ແມ່ນສາມາດນຳໃຊ້ໄດ້. ແຕ່ສຳລັບແອັບພລິເຄຊັນທີ່ໃຊ້ LLM, ຂໍ້ສົມມຸດຕິຖານນີ້ໄດ້ພັງທະລາຍລົງຕັ້ງແຕ່ຕົ້ນ. ເຖິງແມ່ນວ່າຈະປ້ອນ Prompt ດຽວກັນ, ແຕ່ເນື່ອງຈາກ Parameter ຂອງອຸນຫະພູມ (Temperature) ຫຼື ການສຸ່ມຕົວຢ່າງພາຍໃນ (Internal sampling) ເຮັດໃຫ້ເກີດຂໍ້ຄວາມທີ່ແຕກຕ່າງກັນໃນທຸກຄັ້ງ, ການຕັດສິນຜ່ານ ຫຼື ບໍ່ຜ່ານດ້ວຍການກວດສອບຄວາມຖືກຕ້ອງແບບສົມບູນ (Perfect match) ຈຶ່ງບໍ່ສາມາດນຳໃຊ້ໄດ້. ຖ້າພະຍາຍາມນຳເອົາໂຄງຮ່າງຂອງ Unit test ຫຼື E2E test ມາໃຊ້ໂດຍກົງ, ທ່ານຈະພົບກັບອຸປະສັກໃນທັນທີ.

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

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

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

ເບື້ອງຫຼັງຂອງຄວາມຈຳເປັນໃນການພັດທະນາແບບ Evaluation-driven development (EDD) ແມ່ນຄວາມສ່ຽງທີ່ຈະມີການເປີດຕົວສູ່ລະບົບຈິງ (Production) ທັງທີ່ຍັງຢູ່ໃນສະພາວະທີ່ "ບໍ່ສາມາດທົດສອບໄດ້" ເຊັ່ນນີ້.

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

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

EDD ຈະຈັດການກັບບັນຫາເຫຼົ່ານີ້ໂດຍການວາງດັດຊະນີການປະເມີນຜົນໄວ້ທີ່ຈຸດເລີ່ມຕົ້ນຂອງວົງຈອນການພັດທະນາ. ໂດຍສະເພາະແມ່ນການກຳນົດມາດຕະຖານວ່າ "ຈະຖືເອົາຫຍັງເປັນຄວາມສຳເລັດ" ກ່ອນເລີ່ມພັດທະນາ ແລະ ຝັງຂະບວນການ (Pipeline) ທີ່ວັດແທກການປ່ຽນແປງທຸກຢ່າງດ້ວຍມາດຕະຖານນັ້ນ. ໃນຂະບວນການປະເມີນຜົນຂອງ MLflow, ທ່ານສາມາດຢືນຢັນຜົນກະທົບຂອງການປ່ຽນແປງໄດ້ຢ່າງເປັນຕົວເລກ ໂດຍການປຽບທຽບຄ່າການວັດແທກພື້ນຖານ (ຕົວຢ່າງ: correctness/mean = 0.2) ກັບຄ່າການວັດແທກຫຼັງຈາກປັບປຸງແລ້ວ (ຕົວຢ່າງ: correctness/mean = 1.0).

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

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

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

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

ປະເພດຂອງແອັບພລິເຄຊັນ LLM ຫຼັກໆ ແລະ ຄຸນລັກສະນະໃນການປະເມີນຂອງແຕ່ລະປະເພດ ມີດັ່ງນີ້:

• Q&A/Chatbot: ຄວາມຖືກຕ້ອງຂອງຄຳຕອບ, ອັດຕາການເກີດ Hallucination ແລະ ຄວາມໄວໃນການຕອບໂຕ້ ແມ່ນຕົວຊີ້ວັດຫຼັກ. ສາມາດປະເມີນປະລິມານຄວາມສອດຄ່ອງກັບ Golden Dataset ໄດ້ງ່າຍ.
• RAG (Retrieval-Augmented Generation) ຂະບວນການ ຫຼື Pipeline: ຈຳເປັນຕ້ອງແຍກການປະເມີນລະຫວ່າງ ຄຸນນະພາບການຄົ້ນຫາ (Retrieval) ແລະ ຄຸນນະພາບການສ້າງເນື້ອຫາ (Generation).

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

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

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

ຂໍ້ຄວນລະວັງໃນການສ້າງຂໍ້ມູນສັງເຄາະມີດັ່ງນີ້:

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

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

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

ອົງປະກອບທີ່ຄວນຈັດຕຽມມີ 3 ຢ່າງຫຼັກໆດັ່ງນີ້:

① ການຕິດຕາມການທົດລອງ (Experiment Tracking) ນຳໃຊ້ເຄື່ອງມືຈັດການການທົດລອງເຊັ່ນ MLflow ເພື່ອຈັດການເວີຊັນຂອງ Prompt, ພາຣາມິເຕີ ແລະ ຄະແນນການປະເມີນໄວ້ໃນບ່ອນດຽວ. ເນື່ອງຈາກຟັງຊັນ Evaluation Datasets ຂອງ MLflow ຈຳເປັນຕ້ອງໃຊ້ SQL backend ຢ່າງໃດຢ່າງໜຶ່ງລະຫວ່າງ PostgreSQL, MySQL, SQLite ຫຼື MSSQL, ກະລຸນາກວດສອບສະພາບແວດລ້ອມຖານຂໍ້ມູນລ່ວງໜ້າ.

② ການຈັດການເວີຊັນຂອງຂະບວນການ ຫຼື Pipeline ຈັດການ Prompt, ຂະໜາດຂອງ Chunk ໃນ RAG (Retrieval-Augmented Generation) ແລະ ການຕັ້ງຄ່າ Model ດ້ວຍ Git ເຊັ່ນດຽວກັບການຈັດການ Code. ຈຸດປະສົງແມ່ນເພື່ອຮັກສາສະຖານະທີ່ສາມາດຕິດຕາມໄດ້ວ່າ "ການປ່ຽນແປງໃດທີ່ສົ່ງຜົນຕໍ່ຄະແນນການປະເມີນ".

③ ການນຳເອົາລະບົບ Observability ມາໃຊ້ ໃນສະພາບແວດລ້ອມການໃຊ້ງານຈິງ (Production), ໃຫ້ເກັບຂໍ້ມູນ Latency, ປະລິມານການໃຊ້ Token ແລະ ອັດຕາການເກີດ Hallucination ໄວ້ ແບບ Real-time. ການມີກົນໄກທີ່ສາມາດສົ່ງຂໍ້ມູນລັອກທີ່ເກັບໄດ້ກັບຄືນໄປຫາຊຸດຂໍ້ມູນການປະເມີນ (Evaluation Datasets) ຈະຊ່ວຍໃຫ້ການປະເມີນຜົນ ແລະ ການດຳເນີນງານເຊື່ອມໂຍງກັນໄດ້ໂດຍບໍ່ຂາດຕອນ.

ສະຫຼຸບ: EDD ແມ່ນການດຳເນີນງານຕາມ 6 ຂັ້ນຕອນຄື: "ກຳນົດຕົວຊີ້ວັດການປະເມີນຜົນ → ສ້າງກໍລະນີທົດສອບ (Test case) → ຈັດຕັ້ງປະຕິບັດ Harness → ວັດແທກ Baseline → ປັບປຸງ → ວົງຈອນຕໍ່ເນື່ອງ".

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

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

ຂັ້ນຕອນທີ 1: ການກຳນົດຕົວຊີ້ວັດການປະເມີນຜົນ

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

• ຄວາມຖືກຕ້ອງ (Correctness): ຄຳຕອບສອດຄ່ອງກັບຄວາມເປັນຈິງຫຼືບໍ່. ມີຄວາມສຳຄັນຫຼາຍໃນລະບົບ RAG (Retrieval-Augmented Generation)
• ການອ້າງອີງຂໍ້ມູນ (Grounding): ຄຳຕອບມີພື້ນຖານມາຈາກແຫຼ່ງຂໍ້ມູນອ້າງອີງຫຼືບໍ່
• ຄວາມປອດໄພ: ມີຜົນລັອບທີ່ເປັນອັນຕະລາຍ ຫຼື ບໍ່ເໝາະສົມລວມຢູ່ຫຼືບໍ່
• ຄວາມໜ່ວງ (Latency): ເວລາໃນການຕອບສະໜອງຢູ່ໃນຂອບເຂດທີ່ປະສົບການຂອງຜູ້ໃຊ້ຍອມຮັບໄດ້ຫຼືບໍ່

ແນະນຳໃຫ້ຈຳກັດຕົວຊີ້ວັດໄວ້ທີ່ 3-5 ຢ່າງ. ຖ້າຫຼາຍເກີນໄປຈະເຮັດໃຫ້ບູລິມະສິດກະຈັດກະຈາຍ ແລະ ເຮັດໃຫ້ການຕັດສິນໃຈໃນການປັບປຸງຊ້າລົງ. ໃນຕົວຢ່າງການປະເມີນຜົນຂອງ MLflow ໄດ້ສະແດງໃຫ້ເຫັນວິທີການຈັດການແບບລວມສູນໂດຍໃຊ້ correctness/mean ເປັນຕົວຊີ້ວັດພື້ນຖານ (Baseline), ເຊິ່ງການກຳນົດຕົວຊີ້ວັດຫຼັກ 1 ຢ່າງກ່ອນຖືເປັນຈຸດເລີ່ມຕົ້ນທີ່ມີປະສິດທິພາບ.

ຂັ້ນຕອນທີ 2: ການສ້າງກໍລະນີທົດສອບ (Test cases)

ເມື່ອກຳນົດຕົວຊີ້ວັດໄດ້ແລ້ວ, ໃຫ້ກຽມກໍລະນີທົດສອບເພື່ອໃຊ້ໃນການກວດສອບຕົວຊີ້ວັດເຫຼົ່ານັ້ນ.

• ຊຸດຂໍ້ມູນທອງ (Golden dataset): ສ້າງຄູ່ຂອງຂໍ້ມູນນຳເຂົ້າທີ່ຄາດຫວັງ ແລະ ຜົນລັອບທີ່ຖືກຕ້ອງດ້ວຍຕົນເອງ.

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

ໂຄງສ້າງພື້ນຖານຂອງການຈັດຕັ້ງປະຕິບັດ Harness

• Input Loader: ອ່ານ Golden Dataset ແລະ ລວມເຂົ້າກັບ Prompt Template
• Execution Layer: ເອີ້ນໃຊ້ LLM API ແລະ ບັນທຶກ Response ໄວ້ເປັນ Log
• Evaluation Layer: ຄຳນວນຄະແນນດ້ວຍຕົວຊີ້ວັດທີ່ກຳນົດໄວ້ (ຄວາມຖືກຕ້ອງ, ຄວາມປອດໄພ ແລະ ອື່ນໆ)
• Aggregation/Visualization: ສະແດງຜົນຄ່າສະເລ່ຍ ຫຼື Pass Rate ຂອງແຕ່ລະຕົວຊີ້ວັດອອກທາງ Dashboard

ຖ້າຍົກຕົວຢ່າງ MLflow, ທ່ານສາມາດປະຕິບັດ Flow ນີ້ໄດ້ພຽງແຕ່ເອີ້ນໃຊ້ mlflow.evaluate(). ໃນຂໍ້ມູນການວັດແທກຕົວຈິງທີ່ສະແດງໃນ Research Note, ມີລາຍງານກໍລະນີທີ່ correctness/mean ໃນຈຸດເລີ່ມຕົ້ນຂອງ Baseline ມີຄ່າຕ່ຳເຖິງ 0.2, ເຊິ່ງສະແດງໃຫ້ເຫັນວ່າການເຂົ້າໃຈສະຖານະປັດຈຸບັນກ່ອນການປັບປຸງດ້ວຍຕົວເລກນັ້ນມີຄວາມສຳຄັນພຽງໃດ.

ຫຼັກການຕັດສິນໃຈໃນການວັດແທກ Baseline

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

"ຄະແນນບໍ່ເພີ່ມຂຶ້ນຍ້ອນ Prompt ບໍ່ດີ ຫຼື ເປັນຍ້ອນບັນຫາຂໍ້ມູນກັນແນ່?" —— ນີ້ແມ່ນຄຳຖາມທີ່ມັກພົບເຫັນເລື້ອຍໆໃນການເຮັດວຽກຕົວຈິງ ເຊິ່ງ EDD ຈະໃຫ້ຄຳຕອບຜ່ານການປະເມີນຜົນແບບ Loop.

ໃນຂັ້ນຕອນທີ 5, ພວກເຮົາຈະດຳເນີນການ Prompt Engineering ໂດຍອີງໃສ່ຜົນການວັດແທກ Baseline. ໂດຍທົ່ວໄປແລ້ວ, ການພິຈາລະນາລຳດັບຄວາມສຳຄັນໃນການປັບປຸງມີດັ່ງນີ້:

• ການຈັດໂຄງສ້າງ System Prompt: ລະບຸບົດບາດ, ຂໍ້ຈຳກັດ ແລະ ຮູບແບບຜົນລວມໃຫ້ຊັດເຈນ ເພື່ອຫຼຸດອັດຕາການເກີດ Hallucination.
• ການປ່ຽນແທນຕົວຢ່າງ Few-shot: ເລືອກຕົວຢ່າງທີ່ເປັນຕົວແທນຈາກ Golden Dataset ແລະ ນຳສະເໜີໃນຮູບແບບ CoT (Chain of Thought).
• ການແບ່ງ Chain: ແຍກວຽກງານທີ່ຊັບຊ້ອນອອກເປັນຫຼາຍຂັ້ນຕອນ ແລະ ວັດແທກຄະແນນການປະເມີນໃນແຕ່ລະຂັ້ນຕອນ.

ທຸກຄັ້ງທີ່ມີການປ່ຽນແປງ Prompt ໃຫ້ດຳເນີນການ Evaluation Harness ແລະ ບັນທຶກການປ່ຽນແປງຂອງຄະແນນໄວ້ໃນເຄື່ອງມື Tracking ເຊັ່ນ MLflow. ໃນຕົວຢ່າງການປະເມີນຂອງ MLflow, ໄດ້ສະແດງໃຫ້ເຫັນກໍລະນີທີ່ຕົວຊີ້ວັດ correctness/mean ຂອງ Baseline ເຊິ່ງເຄີຍຢູ່ທີ່ 0.2 ໄດ້ປັບປຸງຂຶ້ນເປັນ 1.0 ຫຼັງຈາກການປັບປຸງ Prompt.

ໃນກໍລະນີທີ່ການປັບປຸງ Prompt ບໍ່ສາມາດພັດທະນາຄະແນນໄດ້ອີກແລ້ວ ຈຶ່ງຄ່ອຍພິຈາລະນາການເຮັດ Fine-tuning ໃນຂັ້ນຕອນທີ 6. ການນຳໃຊ້ PEFT (Parameter-Efficient Fine-Tuning) ໂດຍໃຊ້ LoRA ຫຼື QLoRA ຈະຊ່ວຍໃຫ້ສາມາດປັບຕົວແບບຈຳລອງໃຫ້ເຂົ້າກັບວຽກງານໄດ້ ໃນຂະນະທີ່ຍັງສາມາດຄວບຄຸມຕົ້ນທຶນການຄຳນວນໄດ້ (ລາຍລະອຽດເພີ່ມເຕີມແມ່ນ...

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

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

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

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

ຕົວຊີ້ວັດດ້ານຄວາມປອດໄພທີ່ສຳຄັນມີດັ່ງນີ້:

• ການກວດຫາການສ້າງຂໍ້ມູນທີ່ບໍ່ຖືກຕ້ອງ (Hallucination Detection): ຕັດສິນວ່າຜົນລວມຂອງຕົວແບບມີຄວາມຂັດແຍ່ງກັບບໍລິບົດທີ່ໃຫ້ມາ ຫຼື ຂໍ້ເທັດຈິງທີ່ຮູ້ຈັກຫຼືບໍ່. ໃນໂຄງສ້າງ RAG (Retrieval-Augmented Generation), ຈະກວດສອບວ່າໄດ້ມີການກ່າວເຖິງຂໍ້ມູນທີ່ບໍ່ໄດ້ລວມຢູ່ໃນຜົນການຄົ້ນຫາຢ່າງໜັກແໜ້ນຫຼືບໍ່.
• ການກວດສອບພື້ນຖານຂໍ້ມູນ (Grounding Check): ໃຫ້ຄະແນນວ່າແຕ່ລະຂໍ້ຄວາມທີ່ສະແດງອອກມາ ມີພື້ນຖານອ້າງອີງມາຈາກເອກະສານຕົ້ນສະບັບຫຼືບໍ່.

BLEU ແລະ ROUGE ແມ່ນຕົວຊີ້ວັດທາງປະລິມານແບບອີງໃສ່ການອ້າງອີງທີ່ຖືກນຳໃຊ້ໃນວຽກງານການແປພາສາດ້ວຍເຄື່ອງຈັກ ແລະ ການສະຫຼຸບຄວາມມາເປັນເວລາດົນນານ. ເນື່ອງຈາກເປັນການຄຳນວນອັດຕາການກົງກັນຂອງ n-gram ກັບຂໍ້ຄວາມທີ່ຖືກຕ້ອງ (ຂໍ້ຄວາມອ້າງອີງ), ຈຶ່ງມີຂໍ້ດີຄືການຄຳນວນຄະແນນທີ່ວ່ອງໄວ, ມີຄວາມສາມາດໃນການເຮັດຊ້ຳໄດ້ ແລະ ງ່າຍຕໍ່ການນຳໄປລວມເຂົ້າໃນ ຂະບວນການ ຫຼື Pipeline ຂອງ CI/CD.

ຄຸນລັກສະນະຂອງຕົວຊີ້ວັດຫຼັກໆມີດັ່ງນີ້:

• BLEU (Bilingual Evaluation Understudy): ວັດແທກວ່າຂໍ້ຄວາມທີ່ສ້າງຂຶ້ນມີ n-gram ຂອງຂໍ້ຄວາມອ້າງອີງຫຼາຍປານໃດຈາກຝ່າຍຄວາມຖືກຕ້ອງ (Precision). ເໝາະສົມສຳລັບການປະເມີນຄຸນນະພາບການແປ.
• ROUGE-N: ວັດແທກອັດຕາສ່ວນທີ່ n-gram ຂອງຂໍ້ຄວາມອ້າງອີງຖືກສະແດງອອກມາໃນຂໍ້ຄວາມທີ່ສ້າງຂຶ້ນ (Recall). ເໝາະສົມສຳລັບການປະເມີນຄວາມຄົບຖ້ວນຂອງການສະຫຼຸບຄວາມ.
• ROUGE-L: ເນື່ອງຈາກອີງໃສ່ລຳດັບຍ່ອຍທີ່ຍາວທີ່ສຸດ (LCS), ຈຶ່ງສາມາດຮອງຮັບການເຫຼື່ອມລ້ຳຂອງລຳດັບຄຳສັບໄດ້.

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

ສິ່ງທີ່ສຳຄັນໃນຖານະເປັນແກນຫຼັກໃນການຕັດສິນໃຈ ຄືລັກສະນະຂອງວຽກງານ. ໃນວຽກງານເຊັ່ນ: ການແປພາສາ ແລະ ການສະຫຼຸບຄວາມ ເຊິ່ງ "ຂໍ້ຄວາມທີ່ຖືກຕ້ອງສາມາດກຳນົດໄດ້ຢ່າງຊັດເຈນ", BLEU/ROUGE ຈະເປັນມາດຕະຖານທີ່ມີປະສິດທິຜົນ. ໃນທາງກົງກັນຂ້າມ, ໃນວຽກງານທີ່ມີ "ການສະແດງອອກຂອງຄຳຕອບທີ່ຫຼາກຫຼາຍ" ເຊັ່ນ: ການສ້າງຄຳຕອບຂອງ Chatbot ຫຼື ການສັງເຄາະຄຳຕອບຂອງ RAG, ແນະນຳໃຫ້ໃຊ້ຮ່ວມກັບການປະເມີນທາງຄຸນນະພາບ ເຊັ່ນ: LLM-as-a-Judge ທີ່ຈະອະທິບາຍໃນພາກຕໍ່ໄປ.

"ວິທີການໃຫ້ຄະແນນຄວາມເໝາະສົມຂອງນ້ຳສຽງ ແລະ ບໍລິບົດໃນຄຳຕອບຄວນເຮັດແນວໃດ?" —— ຄຳຖາມນີ້ມັກຈະຖືກຖາມຊ້ຳໆໃນການພັດທະນາແອັບພລິເຄຊັນ LLM. LLM-as-a-Judge ເປັນວິທີການທີ່ກຳລັງໄດ້ຮັບຄວາມສົນໃຈໃນຖານະເຄື່ອງມືປະເມີນຄຸນນະພາບດ້ານຄຸນນະພາບທີ່ຕົວຊີ້ວັດການຈັບຄູ່ຄຳສັບແບບ BLEU ຫຼື ROUGE ບໍ່ສາມາດກວດສອບໄດ້ ໂດຍບໍ່ຈຳເປັນຕ້ອງໃຫ້ຄົນມາທົບທວນ.

LLM-as-a-Judge ແມ່ນວິທີການທີ່ LLM ອີກຕົວໜຶ່ງ (ຕົວແບບການປະເມີນ) ເປັນຜູ້ໃຫ້ຄະແນນຜົນລັດທີ່ສ້າງຂຶ້ນ. ໂດຍການສົ່ງ Rubric (ເກນການໃຫ້ຄະແນນ) ແລະ ຂໍ້ຄວາມທີ່ຕ້ອງການປະເມີນໃຫ້ກັບຕົວແບບການປະເມີນ ເພື່ອໃຫ້ມັນສົ່ງຄະແນນ ແລະ ເຫດຜົນກັບຄືນມາ. ແກນຫຼັກໃນການປະເມີນມີດັ່ງນີ້:

• ຄວາມຖືກຕ້ອງ (Correctness): ກົງກັບຄວາມເປັນຈິງຫຼືບໍ່
• ຄວາມກ່ຽວຂ້ອງ (Relevance): ກົງກັບເຈດຕະນາຂອງຜູ້ໃຊ້ຫຼືບໍ່
• ຄວາມສະຫຼາດ (Fluency): ຂຽນດ້ວຍຮູບແບບພາສາທີ່ເປັນທຳມະຊາດຫຼືບໍ່
• ຄວາມປອດໄພ (Safety): ມີເນື້ອຫາທີ່ເປັນອັນຕະລາຍ ຫຼື ບໍ່ເໝາະສົມຫຼືບໍ່

ໃນໂຄງຮ່າງການປະເມີນຂອງ MLflow, ກົນໄກນີ້ສາມາດນຳໃຊ້ເປັນ Metric ການປະເມີນທີ່ຕິດຕັ້ງມາພ້ອມກັບລະບົບໄດ້ ແລະ ສາມາດເຊື່ອມຕໍ່ຄ່າສະຫຼຸບຕ່າງໆ ເຊັ່ນ: correctness/mean ເຂົ້າກັບການຕິດຕາມການທົດລອງ (Experiment Tracking) ໄດ້.

ຂໍ້ຄວນລະວັງໃນການປະຕິບັດຕົວຈິງມີ 2 ປະການຄື:

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

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

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

ວິທີແກ້ໄຂທີ່ມີປະສິດທິພາບຄື ການແບ່ງຕົວຊີ້ວັດອອກເປັນ 2 ຊັ້ນ ຄື "North Star Metric" ແລະ "ຕົວຊີ້ວັດການວິນິດໄສ". North Star Metric ຄວນຈຳກັດໄວ້ພຽງ 1-2 ຕົວທີ່ເປັນມາດຕະຖານສຸດທ້າຍໃນການຕັດສິນໃຈພັດທະນາ ເຊິ່ງຄະແນນ correctness ແລະ ອັດຕາການເຮັດວຽກສຳເລັດ (Task completion rate) ແມ່ນຕົວຢ່າງທີ່ຊັດເຈນ. ສ່ວນຕົວຊີ້ວັດການວິນິດໄສແມ່ນມີໄວ້ເພື່ອຊ່ວຍໃນການລະບຸສາເຫດເທົ່ານັ້ນ ໂດຍຄວນຈຳກັດໄວ້ພຽງ 3-5 ຕົວ ເຊັ່ນ: ອັດຕາການເກີດ Hallucination, Latency, ແລະ ອັດຕາການຜ່ານ Grounding check.

ໃນຕົວຢ່າງການປະເມີນຜົນຂອງ MLflow ກໍໄດ້ສະແດງໂຄງສ້າງທີ່ໃຊ້ correctness/mean ເປັນຕົວຊີ້ວັດຫຼັກໃນການວັດແທກ ແລະ ໃຊ້ຕົວຊີ້ວັດອື່ນໆເປັນສ່ວນຊ່ວຍໃນການເຈາະເລິກຫາສາເຫດທີ່ເຮັດໃຫ້ຄ່າຫຼຸດລົງ.

ການປ່ອຍໃຫ້ຊຸດຂໍ້ມູນ Golden Dataset ທີ່ສ້າງຂຶ້ນແລ້ວເປັນ "ສິນຄ້າສຳເລັດຮູບ" ໂດຍບໍ່ໄດ້ດູແລ ແມ່ນຮູບແບບຄວາມຜິດພາດທີ່ເກີດຂຶ້ນຊ້ຳໆໃນໜ້າວຽກຂອງ EDD.

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

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

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

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

ການຄິດວ່າ Golden Dataset ບໍ່ແມ່ນສິ່ງທີ່ເຮັດແລ້ວຈົບໄປ, ແຕ່ເປັນສິ່ງທີ່ຕ້ອງສືບຕໍ່ພັດທະນາໄປພ້ອມກັບຜະລິດຕະພັນ ຈຶ່ງເປັນແນວຄິດທີ່ເໝາະສົມທີ່ສຸດ.

"ຄະແນນການປະເມີນຜົນມີຢູ່ໃນບົດລາຍງານທຸກອາທິດ ແຕ່ຜະລິດຕະພັນກັບບໍ່ໄດ້ຮັບການປັບປຸງເລີຍ" — ທ່ານເຄີຍພົບກັບສະຖານະການແບບນີ້ບໍ່?

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

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

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

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

ສະຫຼຸບ: RAG ແລະ ລະບົບ Multi-agent ມີການປະເມີນຜົນທີ່ຫຼາກຫຼາຍຊັ້ນ, ສະນັ້ນຈຶ່ງຈຳເປັນຕ້ອງອອກແບບວິທີການນຳໃຊ້ EDD ໃໝ່ໃຫ້ສອດຄ່ອງກັບໂຄງສ້າງ.

ແຕກຕ່າງຈາກການຮຽກໃຊ້ LLM ແບບດ່ຽວ, ສະຖາປັດຕະຍະກຳເຫຼົ່ານີ້ຕ້ອງການມາດຕະຖານການປະເມີນຜົນທີ່ເປັນເອກະລາດສຳລັບການຄົ້ນຫາ (Search), ການສ້າງ (Generation) ແລະ ການປະສານງານລະຫວ່າງ Agent. ຕໍ່ໄປນີ້ຈະເປັນການອະທິບາຍກ່ຽວກັບການອອກແບບການປະເມີນຜົນໃນແຕ່ລະ Layer ແລະ ວິທີການລວມ ຫຼື Merge ເຂົ້າດ້ວຍກັນ.

ໃນການປະເມີນຜົນ ຂະບວນການ ຫຼື Pipeline ຂອງ RAG (Retrieval-Augmented Generation), ໃນຕອນທຳອິດເຮົາມັກຈະຄິດວ່າ "ເບິ່ງພຽງແຕ່ຄຸນນະພາບຂອງຄຳຕອບສຸດທ້າຍກໍພຽງພໍແລ້ວ". ແຕ່ໃນຄວາມເປັນຈິງ, ການແຍກການປະເມີນຜົນລະຫວ່າງໄລຍະການຄົ້ນຫາ (Retrieval phase) ແລະ ໄລຍະການສ້າງຄຳຕອບ (Generation phase) ຈະຊ່ວຍໃຫ້ລະບຸສາເຫດທີ່ແທ້ຈິງຂອງບັນຫາໄດ້ໄວຂຶ້ນ.

ຕົວຊີ້ວັດຄຸນນະພາບການຄົ້ນຫາ

ໃນໄລຍະການຄົ້ນຫາ, ເຮົາຈະວັດແທກວ່າສາມາດດຶງຂໍ້ມູນ (Chunk) ທີ່ເໝາະສົມກັບຄຳຖາມ (Query) ໄດ້ຫຼືບໍ່. ຕົວຊີ້ວັດທີ່ສຳຄັນມີດັ່ງນີ້:

• Recall@K: ອັດຕາສ່ວນທີ່ Chunk ທີ່ຖືກຕ້ອງລວມຢູ່ໃນ K ອັນດັບທຳອິດ
• MRR (Mean Reciprocal Rank): ຄ່າສະເລ່ຍຂອງສ່ວນກັບຂອງອັນດັບ Chunk ທີ່ຖືກຕ້ອງອັນທຳອິດ
• Context Precision: ອັດຕາສ່ວນຂອງ Chunk ທີ່ດຶງມາໄດ້ ເຊິ່ງຖືກນຳໃຊ້ເຂົ້າໃນການຕອບຄຳຖາມແທ້ໆ

ການວັດແທກສິ່ງເຫຼົ່ານີ້ຈະຊ່ວຍໃຫ້ຕັດສິນໃຈໄດ້ວ່າ ຈຳເປັນຕ້ອງປັບປ່ຽນການຕັ້ງຄ່າຂອງ Vector Database ຫຼື ຂະໜາດຂອງ Chunk ຫຼືບໍ່.

ຕົວຊີ້ວັດຄຸນນະພາບການສ້າງຄຳຕອບ

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

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

ເມື່ອນຳໃຊ້ EDD ເຂົ້າກັບໂຄງສ້າງ Multi-agent, ການອອກແບບໂດຍແບ່ງຄວາມລະອຽດຂອງການປະເມີນອອກເປັນ 3 ຊັ້ນຕໍ່ໄປນີ້ຈະມີປະສິດທິຜົນ:

• ຊັ້ນ Agent ດຽວ (Agent single layer): Agent ແຕ່ລະຕົວສົ່ງຜົນລັອກທີ່ຖືກຕ້ອງຕາມໜ້າວຽກທີ່ໄດ້ຮັບມາຫຼືບໍ່
• ຊັ້ນການສື່ສານລະຫວ່າງ Agent (Agent-to-agent communication layer): ຂໍ້ຄວາມໃນ A2A (Agent-to-Agent Protocol) ຖືກຕີຄວາມໝາຍ ແລະ ສົ່ງຂໍ້ມູນຕໍ່ໃຫ້ຕາມເຈດຕະນາຫຼືບໍ່
• ຊັ້ນ End-to-end (End-to-end layer): ລະບົບໂດຍລວມສາມາດສົ່ງຜົນລັອກທີ່ຄາດຫວັງໄວ້ຕໍ່ເປົ້າໝາຍສຸດທ້າຍຂອງຜູ້ໃຊ້ໄດ້ຫຼືບໍ່

ໃນກໍລະນີທີ່ເປົ້າໝາຍການປະເມີນມີຄວາມຊັບຊ້ອນ, ການເຮັດ "ການປະເມີນແບບ Bottom-up" ໂດຍການເຮັດໃຫ້ການທົດສອບ Agent ດຽວມີຄວາມສະຖຽນກ່ອນ ແລ້ວຈຶ່ງດຳເນີນການປະເມີນໃນຊັ້ນທີ່ສູງຂຶ້ນໄປນັ້ນຖືວ່າມີປະສິດທິຜົນ. ໃນທາງກົງກັນຂ້າມ, ຖ້າຫາກມີຄວາມຈຳເປັນຕ້ອງຮີບຮ້ອນກວດສອບຄວາມຕ້ອງການທາງທຸລະກິດ, "ການປະເມີນແບບ Top-down" ໂດຍການເຮັດການປະເມີນແບບ End-to-end ກ່ອນ ເພື່ອຈຳກັດຂອບເຂດຂອງຊັ້ນທີ່ມີບັນຫາກໍຖືວ່າມີຄວາມເໝາະສົມ.