ຄູ່ມືການອອກແບບການປະເມີນຜົນ AI Agent — ການຮຽກໃຊ້ເຄື່ອງມື, ເສັ້ນທາງການປະຕິບັດງານ ແລະ ການກວດຫາການຖົດຖອຍ

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

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

ບົດຄວາມນີ້ຈະອະທິບາຍຢ່າງເປັນລະບົບກ່ຽວກັບທຸກຂັ້ນຕອນຂອງການປະເມີນ Agent, ຕັ້ງແຕ່ການອອກແບບ Golden Dataset, ການກວດສອບການເອີ້ນໃຊ້ເຄື່ອງມື, ການໃຫ້ຄະແນນເສັ້ນທາງການປະຕິບັດງານ, ການກວດຫາ Regression ພາຍໃຕ້ສະພາບທີ່ບໍ່ສາມາດກຳນົດໄດ້ (Non-deterministic), ຈົນເຖິງການເຊື່ອມຕໍ່ກັບ CI. ເນື້ອຫານີ້ຈະຊ່ວຍໃຫ້ວິສະວະກອນ ແລະ ຜູ້ຮັບຜິດຊອບດ້ານ MLOps ທີ່ກຳລັງພິຈາລະນາສ້າງພື້ນຖານການປະເມີນຜົນ ໄດ້ຮັບຂັ້ນຕອນທີ່ຊັດເຈນເພື່ອເລີ່ມຕົ້ນລົງມືເຮັດໄດ້ໃນມື້ຕໍ່ໄປ.

ສະຫຼຸບ: ການປະເມີນຜົນ AI agent ບໍ່ພຽງແຕ່ຕ້ອງກວດສອບຄວາມຖືກຕ້ອງຂອງຜົນລັດສຸດທ້າຍເທົ່ານັ້ນ, ແຕ່ຍັງຕ້ອງກວດສອບເຖິງຄວາມເໝາະສົມຂອງການເອີ້ນໃຊ້ເຄື່ອງມື (Tool calling) ແລະ ຄວາມສົມເຫດສົມຜົນຂອງເສັ້ນທາງການປະຕິບັດງານ (Execution trajectory) ອີກດ້ວຍ.

ວິທີການນີ້ຮຽກຮ້ອງໃຫ້ມີແນວທາງທີ່ແຕກຕ່າງຈາກການປະເມີນຜົນ LLM ແບບປົກກະຕິຢ່າງສິ້ນເຊີງ. ໃນຫົວຂໍ້ H3 ຕໍ່ໄປນີ້, ຈະອະທິບາຍເຖິງເຫດຜົນ ແລະ ມຸມມອງການປະເມີນຜົນທີ່ລະອຽດ.

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

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

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

ເຫດຜົນທີ່ຄວນປະເມີນຜົນເສັ້ນທາງການປະຕິບັດງານ (Trajectory) ມີ 3 ປະການຫຼັກໆ ດັ່ງນີ້:

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

ດັ່ງທີ່ໄດ້ອະທິບາຍຢ່າງລະອຽດໃນ Harness Engineering ແມ່ນຫຍັງ? ວິທີການອອກແບບເພື່ອປ້ອງກັນຄວາມຜິດພາດຂອງ AI Agent ດ້ວຍໂຄງສ້າງ, ການຄວບຄຸມພຶດຕິກຳຂອງ Agent ຢ່າງມີໂຄງສ້າງນັ້ນ ຈຳເປັນຕ້ອງມີການເບິ່ງເຫັນພາບ (Visualization) ໃນລະດັບຂອງເສັ້ນທາງການປະຕິບັດງານເປັນພື້ນຖານ.

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

ເມື່ອມີການໃຊ້ເຫດຜົນຫຼາຍຂັ້ນຕອນ (Multi-step reasoning) ເຂົ້າມາ ກໍຍິ່ງເພີ່ມຄວາມຊັບຊ້ອນຫຼາຍຂຶ້ນ:

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

ມຸມມອງດ້ານການແຍກເງື່ອນໄຂ (Conditional branching) ກໍມີຄວາມສຳຄັນ. ຖ້າເປັນ Agent ທີ່ມີຈຳນວນຂັ້ນຕອນໜ້ອຍ ແລະ ມີເສັ້ນທາງທີ່ຈຳກັດ, ການກວດສອບກັບເສັ້ນທາງທີ່ຄາດຫວັງແບບ Deterministic ກໍຍັງມີປະສິດທິພາບ, ແຕ່ຖ້າເປັນ Agent ທີ່ມີຂັ້ນຕອນຫຼາຍ ແລະ ມີເສັ້ນທາງທີ່ຫຼາກຫຼາຍ, ການປະເມີນຜົນເສັ້ນທາງໂດຍ LLM ຫຼື ການອອກແບບເກນຜ່ານ-ຕົກທາງສະຖິຕິຈະເປັນທາງເລືອກທີ່ເປັນໄປໄດ້ຫຼາຍກວ່າ.

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

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

ໂດຍການແບ່ງເປົ້າໝາຍການປະເມີນຜົນອອກເປັນແບບ Offline ແລະ Online, ພ້ອມທັງອອກແບບໃນແຕ່ລະຊັ້ນ (Layer) ບໍ່ວ່າຈະເປັນ ຄຳຕອບສຸດທ້າຍ, ການຮຽກໃຊ້ Tool, ບັນທຶກການເຮັດວຽກ (Trajectory) ແລະ ຕົ້ນທຶນ (Cost), ຈະເຮັດໃຫ້ສາມາດສ້າງລະບົບການກວດສອບທີ່ຄົບຖ້ວນສົມບູນໄດ້.

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

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

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

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

ການແບ່ງໜ້າທີ່ຂອງທັງສອງຢ່າງສາມາດສະຫຼຸບໄດ້ດັ່ງນີ້:

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

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

ການປະເມີນ AI Agent ນັ້ນ, ມີປະສິດທິພາບຫຼາຍຂຶ້ນເມື່ອອອກແບບໂດຍແບ່ງອອກເປັນ 4 ຊັ້ນດັ່ງຕໍ່ໄປນີ້:

• ຊັ້ນຄຳຕອບສຸດທ້າຍ: ກວດສອບວ່າຜົນລັບທີ່ສົ່ງຂໍ້ມູນຕໍ່ໃຫ້ຜູ້ໃຊ້ນັ້ນຖືກຕ້ອງ ແລະ ບໍ່ມີ Hallucination. ສາມາດໃຊ້ວິທີການດຽວກັນກັບການປະເມີນ LLM ແບບດັ້ງເດີມ (ເຊັ່ນ: ການຈັບຄູ່ຄຳຕອບ, LLM-as-Judge ແລະ ອື່ນໆ) ແຕ່ການໃຊ້ພຽງຊັ້ນນີ້ຢ່າງດຽວຍັງບໍ່ພຽງພໍ
• ຊັ້ນການເອີ້ນໃຊ້ເຄື່ອງມື: ກວດສອບວ່າໃຊ້ເຄື່ອງມືໃດ, ດ້ວຍ Argument ໃດ, ແລະ ເອີ້ນໃຊ້ຈຳນວນຈັ່ງໃດ. ຕົວຢ່າງ, ຮູບແບບທີ່ບໍ່ມີປະສິດທິພາບ ເຊັ່ນ "ເອີ້ນໃຊ້ເຄື່ອງມືຄົ້ນຫາ 5 ຄັ້ງ ແລ້ວຊ້ຳ Query ດຽວກັນ" ຖືວ່າເປັນບັນຫາ ເຖິງແມ່ນວ່າຄຳຕອບສຸດທ້າຍຈະຖືກຕ້ອງກໍ່ຕາມ
• ຊັ້ນເສັ້ນທາງ (Trajectory): ໃຫ້ຄະແນນວ່າລຳດັບຂັ້ນຕອນ, ການແຕກສາຂາ, ແລະ ການຕັດສິນໃຈຢຸດດຳເນີນງານນັ້ນເປັນໄປຕາມທີ່ຄາດຫວັງຫຼືບໍ່. ໂດຍການນຳ Golden Set ໄປທຽບກັບ Log ການດຳເນີນງານ ແລ້ວໃຫ້ຄະແນນໃນລະດັບຂັ້ນຕອນ
• ຊັ້ນຕົ້ນທຶນ ແລະ ຊັບພະຍາກອນ: ວັດແທກການໃຊ້ Token, ຈຳນວນການເອີ້ນໃຊ້ API, ແລະ Latency. ເນື່ອງຈາກ Agent ທີ່ມີຕົ້ນທຶນເກີນງົບປະມານບໍ່ສາມາດນຳໄປໃຊ້ງານຈິງໄດ້, ຈຶ່ງມີຄວາມສຳຄັນທີ່ຕ້ອງຕິດຕາມຮ່ວມກັນກັບການຈັດການການໃຊ້ງານທີ່ແນະນຳໃນ Token Trap ຄືຫຍັງ? ການຈັດການການໃຊ້ງານເພື່ອປ້ອງກັນການລະເບີດຂອງຕົ້ນທຶນທີ່ເຊື່ອງຢູ່ຂອງ AI Agent

ເຫດຜົນທີ່ຕ້ອງປະເມີນທັງ 4 ຊັ້ນພ້ອມກັນ ກໍ່ຍ້ອນວ່າແຕ່ລະຊັ້ນສາມາດເສື່ອມລົງໄດ້ຢ່າງເປັນເອກະລາດຈາກກັນ.

ສະຫຼຸບ: ຄຸນນະພາບຂອງການປະເມີນຜົນແມ່ນຂຶ້ນຢູ່ກັບການອອກແບບ Golden Dataset. ການກຽມຊຸດຂໍ້ມູນ 3 ຢ່າງ ຄື: ຂໍ້ມູນນຳເຂົ້າ (Input), ລຳດັບເຄື່ອງມືທີ່ຄາດຫວັງ (Expected Tool Sequence), ແລະ ຜົນລັອບທີ່ຄາດຫວັງ (Expected Result) ແມ່ນຈຸດເລີ່ມຕົ້ນທີ່ສຳຄັນ.

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

ທີມງານໃນຂັ້ນຕອນ PoC ມັກຈະພົບກັບອຸປະສັກທີ່ວ່າ "ຢາກສ້າງ Golden Dataset ແຕ່ບໍ່ຮູ້ວ່າຄວນກຳນົດຫຍັງ ແລະ ຫຼາຍໜ້ອຍພຽງໃດ".

ກໍລະນີການປະເມີນຜົນ Agent ນັ້ນ, ຕ່າງຈາກການທົດສອບ LLM ທົ່ວໄປ ເພາະຈຳເປັນຕ້ອງ ກຳນົດ 3 ອົງປະກອບຮ່ວມກັນ ດັ່ງນີ້:

• Input: ຄຳເວົ້າຂອງຜູ້ໃຊ້, ບໍລິບົດ (Context), ແລະ ລາຍການເຄື່ອງມືທີ່ສາມາດນຳໃຊ້ໄດ້
• Expected Tool Sequence: ຊື່ເຄື່ອງມືທີ່ຄວນເອີ້ນໃຊ້ ແລະ ລຳດັບ, ລວມເຖິງ Schema ຂອງ Argument ໃນແຕ່ລະຂັ້ນຕອນ
• Expected Output: ຂໍ້ກຳນົດຂອງຄຳຕອບສຸດທ້າຍ (ມັກຈະກຳນົດເປັນ "ຂໍ້ມູນທີ່ຄວນມີ" ຫຼາຍກວ່າການກຳນົດໃຫ້ກົງກັນທຸກປະການ)

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

ຕົວຢ່າງທີ່ເປັນຮູບປະທຳ, ຖ້າເປັນ Agent ສອບຖາມສິນຄ້າຄົງຄັງ ສາມາດກຳນົດໄດ້ດັ່ງນີ້:

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

ເມື່ອປ່ຽນບັນທຶກການດຳເນີນງານໃຫ້ເປັນກໍລະນີການປະເມີນຜົນ, ຂະບວນການຕໍ່ໄປນີ້ແມ່ນມີປະສິດທິຜົນ:

• ການເກັບຮວບຮວມບັນທຶກ (Log Collection): ສຳລັບແຕ່ລະຄຳຮ້ອງຂໍ (Request), ໃຫ້ບັນທຶກຂໍ້ມູນອິນພຸດ, ລຳດັບການເອີ້ນໃຊ້ເຄື່ອງມື, ອາຄິວເມັນ (Arguments) ແລະ ຜົນລັດສຸດທ້າຍໄວ້ເປັນຊຸດ.
• ການກັ່ນຕອງ (Filtering): ໃຫ້ບຸລິມະສິດໃນການສະກັດເອົາກໍລະນີທີ່ຜູ້ໃຊ້ສະແດງຄຳຕິຊົມທາງລົບຢ່າງຈະແຈ້ງ, ກໍລະນີທີ່ເກີດຂໍ້ຜິດພາດໃນການເອີ້ນໃຊ້ເຄື່ອງມື ແລະ ກໍລະນີທີ່ມີຈຳນວນຂັ້ນຕອນຫຼາຍຜິດປົກກະຕິ.
• ການຕິດປ້າຍກຳກັບ (Labeling): ສຳລັບບັນທຶກທີ່ສະກັດອອກມາ, ໃຫ້ເຮັດການອະໂນເທຊັນ (Annotation) ລຳດັບເຄື່ອງມືທີ່ຄາດຫວັງ ແລະ ຜົນລັດທີ່ຄາດຫວັງ ໂດຍໃຊ້ແຮງງານຄົນ ຫຼື ໃຊ້ LLM ຊ່ວຍ, ຈາກນັ້ນຈຶ່ງເພີ່ມເຂົ້າໃນຊຸດຂໍ້ມູນມາດຕະຖານ (Golden Set).

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

ຈຸດທີ່ຄວນລະວັງໃນການນຳໃຊ້ບັນທຶກມີດັ່ງນີ້:

ສະຫຼຸບ: ການປະເມີນການຮຽກໃຊ້ເຄື່ອງມື (Tool calling) ແມ່ນມີພື້ນຖານການຮັບປະກັນຄຸນນະພາບຢູ່ທີ່ການກວດສອບ 3 ແກນຫຼັກ ຄື: ການເລືອກ, ອາຄິວເມັນ (Arguments) ແລະ ລຳດັບ.

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

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

ການກວດສອບການເລືອກເຄື່ອງມື (Tool selection) ແມ່ນການປຽບທຽບຊື່ເຄື່ອງມືທີ່ຄາດຫວັງກັບຊື່ເຄື່ອງມືທີ່ເອີ້ນໃຊ້ຈິງ ໂດຍໃຊ້ການກວດສອບຄວາມຖືກຕ້ອງແບບສົມບູນ (Exact match) ຫຼື ການປັບໃຫ້ເປັນມາດຕະຖານ (Normalized match).

• ຄາດຫວັງ: search_db → ຕົວຈິງ: search_db ✓
• ຄາດຫວັງ: search_db → ຕົວຈິງ: search_web (ເລືອກເຄື່ອງມືທົດແທນ) ✗

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

ການກວດສອບອາກິວເມັນ (Arguments) ຕ້ອງການການປະເມີນທີ່ມີຄວາມລະອຽດສູງກວ່າການເລືອກເຄື່ອງມື. ໃນກໍລະນີທີ່ອາກິວເມັນເປັນຂໍ້ມູນທີ່ມີໂຄງສ້າງ (JSON), ວິທີທີ່ມີປະສິດທິພາບແມ່ນການກວດສອບປະເພດ (Type) ແລະ ຂອບເຂດຂອງຄ່າ (Range) ຂອງ Key ແທນທີ່ຈະໃຊ້ການກວດສອບຄວາມຖືກຕ້ອງແບບສົມບູນ. ສຳລັບອາກິວເມັນໃນຮູບແບບການຂຽນອິດສະຫຼະ (ເຊັ່ນ: ຄຳຄົ້ນຫາ), ໃຫ້ໃຊ້ຄະແນນຄວາມຄ້າຍຄືກັນທາງດ້ານຄວາມໝາຍ (Semantic similarity score) ແທນການກວດສອບຄວາມຖືກຕ້ອງແບບສົມບູນ ໂດຍມີການກຳນົດຄ່າ Threshold ເພື່ອຕັດສິນຜົນຜ່ານ ຫຼື ບໍ່ຜ່ານ.

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

ຄວາມເຂັ້ມງວດໃນການປະເມີນຜົນຈຳເປັນຕ້ອງໄດ້ປັບໃຊ້ໃຫ້ເໝາະສົມກັບແຕ່ລະກໍລະນີ.

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

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

ການກວດຫາບັນຫາດັ່ງກ່າວ ຈະໃຊ້ຕົວຊີ້ວັດຕໍ່ໄປນີ້:

• ການກວດສອບຂີດຈຳກັດຈຳນວນຄັ້ງໃນການຮຽກໃຊ້: ຫາກຈຳນວນການຮຽກໃຊ້ຕົວຈິງເກີນອັດຕາທີ່ກຳນົດໄວ້ ເມື່ອທຽບກັບຈຳນວນການຮຽກໃຊ້ທີ່ຄາດຫວັງໃນ Golden Set ໃຫ້ສະແດງການແຈ້ງເຕືອນ.
• ການກວດຫາການຮຽກໃຊ້ຊ້ຳຊ້ອນ: ກວດຫາການຮຽກໃຊ້ເຄື່ອງມືດຽວກັນ ແລະ ອາຄິວເມນດຽວກັນຢ່າງຕໍ່ເນື່ອງຈາກ Log.
• ການກວດຫາການປ່ຽນແປງທີ່ບໍ່ມີປະສິດທິຜົນ: ລະບຸຮູບແບບການວົນຊ້ຳເຊັ່ນ: ເຄື່ອງມື A → ເຄື່ອງມື B → ເຄື່ອງມື A ໂດຍໃຊ້ກຣາຟເສັ້ນທາງ (Trajectory Graph).

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

ຈຸດສຳຄັນໃນການນຳໄປປະຕິບັດມີ 2 ຢ່າງ:

• ກຳນົດຈຳນວນຂັ້ນຕອນສູງສຸດ (ຕົວຢ່າງ: 20 ຂັ້ນຕອນ) ໄວ້ໃນ Evaluation Harness ແລະ ໃຫ້ຖືວ່າກໍລະນີທີ່ເກີນກຳນົດເປັນຄວາມລົ້ມເຫຼວໂດຍອັດຕະໂນມັດ.
• ຝັງເຫດຜົນໃນການຕັດສິນລູບ (Loop Judgment Logic) ໃຫ້ຊັດເຈນໃນຖານະເປັນ Assertion ຂອງ Golden Set.

[Token Trap ແມ່ນຫຍັງ?

ສະຫຼຸບ: ການໃຫ້ຄະແນນເສັ້ນທາງການປະຕິບັດງານ (Execution Trajectory) ແມ່ນອີງໃສ່ການປະສົມປະສານລະຫວ່າງວິທີການວັດແທກຄວາມສອດຄ່ອງກັບເສັ້ນທາງທີ່ຖືກຕ້ອງໃນແຕ່ລະຂັ້ນຕອນ ກັບການໃຊ້ LLM ເປັນຜູ້ຕັດສິນເພື່ອການປະເມີນຜົນທີ່ມີຄວາມຍືດຫຍຸ່ນ.

ບົດບາດຂອງການໃຫ້ຄະແນນເສັ້ນທາງຄືການປະເມີນ "ຄວາມເຊື່ອມໂຍງລະຫວ່າງຂັ້ນຕອນ" ເຊິ່ງບໍ່ສາມາດກວດສອບໄດ້ດ້ວຍການກວດສອບການຮຽກໃຊ້ເຄື່ອງມື (Tool calling) ແຕ່ລະອັນເທົ່ານັ້ນ. ພວກເຮົາຈະອະທິບາຍລາຍລະອຽດກ່ຽວກັບການເລືອກໃຊ້ລະຫວ່າງການຈັບຄູ່ເສັ້ນທາງ (Trajectory matching) ແລະ LLM ຜູ້ຕັດສິນໃນຫົວຂໍ້ H3 ຕໍ່ໄປນີ້.

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

ການຈັບຄູ່ເສັ້ນທາງ (Trajectory Matching) ແມ່ນວິທີການປຽບທຽບລຳດັບຂັ້ນຕອນທີ່ Agent ໄດ້ປະຕິບັດຕົວຈິງ ກັບລຳດັບຂັ້ນຕອນທີ່ຄາດຫວັງໄວ້ໃນຊຸດຂໍ້ມູນ Golden Dataset. ຄວາມລະອຽດໃນການປຽບທຽບສາມາດແບ່ງອອກໄດ້ເປັນ 2 ລະດັບໃຫຍ່ໆ:

ການຈັບຄູ່ແບບສົມບູນ (Exact Match)

• ຕັດສິນແບບ Binary ວ່າຊື່ເຄື່ອງມື, ພາລາມິເຕີ (Arguments) ແລະ ລຳດັບການເອີ້ນໃຊ້ ທັງໝົດນັ້ນກົງກັນຫຼືບໍ່
• ມີຕົ້ນທຶນໃນການຈັດຕັ້ງປະຕິບັດຕໍ່າ ແລະ ເໝາະສົມກັບການກວດສອບຄວາມຜິດພາດ (Regression Detection) ເຊິ່ງທຽບເທົ່າກັບການທົດສອບແບບ Unit Test
• ມັກເກີດການກວດພົບຜິດພາດໄດ້ງ່າຍ ຈາກຄວາມແຕກຕ່າງເລັກໆນ້ອຍໆຂອງພາລາມິເຕີ (ເຊັ່ນ: ຄວາມແຕກຕ່າງໃນການປັບຮູບແບບຂໍ້ຄວາມໃຫ້ເປັນມາດຕະຖານ)

ການໃຫ້ຄະແນນລາຍຂັ້ນຕອນ (Step-Level Scoring)

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

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

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

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

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

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

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

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

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

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

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

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

ການຮັບປະກັນຄວາມສະຖຽນດ້ວຍການທົດສອບຫຼາຍຄັ້ງ

ວິທີການທີ່ມີປະສິດທິພາບຄືການດຳເນີນການ Test Case ດຽວກັນຫຼາຍຄັ້ງ ແລະ ຄິດໄລ່ຄະແນນຈາກອັດຕາການຜ່ານ.

• ຈຳນວນຄັ້ງທີ່ແນະນຳໃນການທົດສອບ: ສຳລັບການທົດສອບທີ່ຄ້າຍຄືກັບ Unit Test ທີ່ມີນ້ຳໜັກເບົາ ໃຫ້ທົດສອບຈຳນວນໜ້ອຍຄັ້ງ, ສ່ວນສະຖານະການທີ່ສຳຄັນໃຫ້ເພີ່ມຈຳນວນຄັ້ງໃຫ້ຫຼາຍຂຶ້ນ
• ການອອກແບບເກນອັດຕາການຜ່ານ: ປັບປ່ຽນເກນຕາມຄວາມສຳຄັນຂອງ Case ເຊັ່ນ: "PASS ເມື່ອສຳເລັດໃນອັດຕາສ່ວນທີ່ສູງພາຍໃນຈຳນວນຄັ້ງທີ່ກຳນົດ"
• ການຕັດສິນ Flaky: ສຳລັບ Case ທີ່ມີອັດຕາການຜ່ານກ້ຳກິ່ງ ໃຫ້ຕັ້ງ Flag ແຍກໄວ້ວ່າເປັນ "Flaky" ໂດຍບໍ່ຕ້ອງຕັດສິນວ່າລົ້ມເຫຼວທັນທີ ແຕ່ໃຫ້ສົ່ງເຂົ້າຄິວເພື່ອດຳເນີນການກວດສອບ

ແນວທາງການອອກແບບເກນການຕັດສິນຜົນສຳເລັດ ຫຼື ຄວາມລົ້ມເຫຼວ

ຄວນເລືອກໃຊ້ເກນໃຫ້ເໝາະສົມກັບປະເພດຂອງ Case.

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

ໃນຕອນທຳອິດ ຫຼາຍຄົນມັກຄິດວ່າ "ການດຳເນີນການປະເມີນຜົນສະຄຣິບດ້ວຍຕົນເອງໃນເຄື່ອງທ້ອງຖິ່ນ (Local) ກໍພຽງພໍແລ້ວ" ແຕ່ໃນຄວາມເປັນຈິງ ການນຳເອົາໄປລວມເຂົ້າໃນຂະບວນການ ຫຼື Pipeline ຂອງ CI (Continuous Integration) ແລະ ດຳເນີນການອັດຕະໂນມັດໃນທຸກໆ Pull Request ຈະຊ່ວຍໃຫ້ກວດພົບການຖົດຖອຍ (Regression) ໄດ້ໄວຂຶ້ນ.

ຈຸດສຳຄັນທີ່ຄວນຈື່ໃນການນຳເອົາໄປລວມເຂົ້າກັບ CI ມີດັ່ງນີ້:

• ການແຍກ Fast Lane/Slow Lane: ຖ້າຫາກດຳເນີນການທຸກກໍລະນີໃນທຸກຄັ້ງ ຈະເຮັດໃຫ້ຕົ້ນທຶນ ແລະ ເວລາເພີ່ມທະວີຂຶ້ນເລື້ອຍໆ. ດັ່ງນັ້ນ ການດຳເນີນການ "Smoke Test" ທີ່ເນັ້ນສະເພາະ Core Scenario ໃນຊ່ວງ Pull Request ແລະ ດຳເນີນການ Full Suite ໃນຊ່ວງ Nightly Build ຈຶ່ງເປັນທາງເລືອກທີ່ເໝາະສົມກວ່າ.
• ການຝັງຄ່າ Threshold ສຳລັບການຕັດສິນ Flaky ໄວ້ໃນການຕັ້ງຄ່າ CI: ໃຫ້ລະບຸເງື່ອນໄຂການຜ່ານ ຫຼື ບໍ່ຜ່ານຂອງ CI ໂດຍອີງຕາມຄ່າ Threshold ທີ່ອອກແບບໄວ້ໃນພາກກ່ອນໜ້ານີ້ ຄື "ຜ່ານຢ່າງໜ້ອຍ M ຄັ້ງ ໃນຈຳນວນ N ຄັ້ງ". ການກຳນົດໃຫ້ Build ລົ້ມເຫຼວສະເພາະໃນກໍລະນີທີ່ເກີນຄ່າ Threshold ເທົ່ານັ້ນ ຈະຊ່ວຍຫຼຸດຜ່ອນການກວດພົບຂໍ້ຜິດພາດທີ່ເກີດຈາກສຽງລົບກວນ (Noise) ໄດ້.
• ການຕັ້ງຄ່າ Regression Budget: ໃຫ້ກຳນົດຂີດຈຳກັດຂອງການໃຊ້ງານ Token, ຈຳນວນຄັ້ງໃນການຮຽກໃຊ້ API ແລະ ເວລາໃນການດຳເນີນການຕໍ່ການຮັນ CI ໜຶ່ງຄັ້ງ ເປັນ "Regression Budget". ໃນກໍລະນີທີ່ມີກໍລະນີທີ່ເກີນ Budget ເພີ່ມຂຶ້ນ ໃຫ້ຖືວ່ານັ້ນເປັນສັນຍານທີ່ບົ່ງບອກວ່າເຖິງເວລາທີ່ຕ້ອງທົບທວນ Golden Set ຄືນໃໝ່.

ເຫດຜົນທີ່ຕ້ອງມີການກຳນົດ Regression Budget ແມ່ນເພື່ອປ້ອງກັນບໍ່ໃຫ້ຕົ້ນທຶນໃນການປະເມີນຜົນເພີ່ມຂຶ້ນຢ່າງບໍ່ມີຂອບເຂດ. ການປະເມີນຜົນດ້ວຍການຮຽກໃຊ້ Tool ແລະ ການໃຫ້ຄະແນນ Trajectory ບາງຄັ້ງອາດມີການໃຊ້ LLM ເປັນຕົວປະເມີນຜົນ ເຊິ່ງເຮັດໃຫ້ໄລຍະການປະເມີນຜົນເອງກໍມີຄວາມສ່ຽງທີ່ຈະເກີດຕົ້ນທຶນມະຫາສານ (Cost Explosion) ຄືກັບທີ່ໄດ້ອະທິບາຍໄວ້ໃນ Token Trap ແມ່ນຫຍັງ? ການຈັດການການບໍລິໂພກເພື່ອປ້ອງກັນຕົ້ນທຶນມະຫາສານທີ່ຊ່ອນຢູ່ໃນ AI Agent.

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

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

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

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

ສາເຫດຂອງການເສື່ອມສະພາບສາມາດແບ່ງອອກໄດ້ເປັນ 3 ປະການໃຫຍ່ໆ. ຢ່າງທຳອິດແມ່ນການປ່ຽນແປງຂອງການກະຈາຍຕົວຂອງຂໍ້ມູນທີ່ປ້ອນເຂົ້າ (Input distribution), ເຊິ່ງໃນໄລຍະທຳອິດຈະເນັ້ນຮູບແບບຄຳຖາມທີ່ຄາດຄະເນໄວ້ ແຕ່ເມື່ອການດຳເນີນງານກ້າວໜ້າໄປ ກໍຈະມີການໃຊ້ຄຳຫຍໍ້, ພາສາປາກເວົ້າ ແລະ ວຽກງານທີ່ຊັບຊ້ອນເພີ່ມຂຶ້ນ. ຢ່າງທີສອງແມ່ນການປ່ຽນແປງ ມາດຕະຖານ ຫຼື Specification ຂອງເຄື່ອງມື ເຊິ່ງບາງຄັ້ງຮູບແບບການຕອບສະໜອງຂອງ API ພາຍນອກປ່ຽນໄປ ແຕ່ຄ່າທີ່ຄາດຫວັງໃນກໍລະນີການປະເມີນຜົນກັບບໍ່ໄດ້ຮັບການອັບເດດ ແລະ ຖືກປ່ອຍປະລະເລີຍ. ແລະຢ່າງທີສາມແມ່ນການບໍ່ສະທ້ອນເຖິງຟີເຈີໃໝ່ໆ, ເຊິ່ງກໍຄືສະຖານະການທີ່ຍັງສືບຕໍ່ໃຊ້ພຽງແຕ່ Golden Set ອັນເກົ່າໃນການທົດສອບ Regression ຫຼັງຈາກທີ່ມີການເພີ່ມເຄື່ອງມືໃໝ່ໃຫ້ກັບ Agent ແລ້ວ.

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

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

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

ແລ້ວຈະກວດພົບໄດ້ແນວໃດ? ສິ່ງທີ່ມີປະສິດທິພາບຄືການເພີ່ມຂັ້ນຕອນການກວດສອບ Log ການເອີ້ນໃຊ້ເຄື່ອງມືເຂົ້າໄປໃນ Evaluation Harness. ການກວດສອບສາມຢ່າງນີ້ໂດຍອັດຕະໂນມັດ: ອັດຕາການກົງກັນລະຫວ່າງລຳດັບເຄື່ອງມືທີ່ຄາດຫວັງກັບລຳດັບການເອີ້ນໃຊ້ຕົວຈິງ, ຄວາມສອດຄ່ອງຂອງ Argument Schema ໃນແຕ່ລະການເອີ້ນໃຊ້, ແລະ ການເກີນຂີດຈຳກັດຈຳນວນຄັ້ງໃນການເອີ້ນໃຊ້—ພຽງເທົ່ານີ້ກໍສາມາດປ້ອງກັນການພາດເຫຼົ່ານີ້ໄດ້ສ່ວນໃຫຍ່.

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

Q1. ໂກລເດັນດາຕ້າເຊັດ (Golden Dataset) ຄວນເລີ່ມຕົ້ນຈາກຂະໜາດໃດ?

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

---

Q2. ຈະຕັດສິນ "ຜ່ານ ຫຼື ບໍ່ຜ່ານ" (Pass/Fail) ສຳລັບເອເຈນທີ່ມີຄວາມບໍ່ແນ່ນອນສູງໄດ້ແນວໃດ?

ວິທີການທີ່ນິຍົມໃຊ້ກັນທົ່ວໄປຄື ການດຳເນີນການໃນກໍລະນີດຽວກັນຫຼາຍໆຄັ້ງ ແລ້ວຕັດສິນຈາກອັດຕາຄວາມສຳເລັດວ່າເກີນຄ່າທີ່ກຳນົດໄວ້ (Threshold) ຫຼື ບໍ່ (ຕົວຢ່າງ: ສຳເລັດ 4 ໃນ 5 ຄັ້ງ). ຄ່າ Threshold ຄວນຕັ້ງໄວ້ຕາມຄວາມສ່ຽງຂອງວຽກງານ, ແລະ ໃນ CI ຄວນກຳນົດງົບປະມານການຖົດຖອຍ (Regression budget) ເປັນຂັ້ນຕອນ ເຊັ່ນ: "ຖ້າຕ່ຳກວ່າ Threshold ໃຫ້ແຈ້ງເຕືອນ, ຖ້າຕ່ຳກວ່າ 2 ຄັ້ງຕິດຕໍ່ກັນໃຫ້ຖືວ່າລົ້ມເຫຼວ" ເຊິ່ງຈະຊ່ວຍຫຼຸດຜ່ອນການກວດພົບຂໍ້ຜິດພາດທີ່ບໍ່ຖືກຕ້ອງ (False positive) ຈາກຄວາມບໍ່ສະຖຽນຂອງລະບົບໄດ້.

---

Q3. ຄວນໃຊ້ LLM ໃນການປະເມີນການຮຽກໃຊ້ເຄື່ອງມື (Tool calling) ຫຼືບໍ່? ແລະ ມັນແຕກຕ່າງຈາກການໃຊ້ກົດເກນ (Rule-based) ແນວໃດ?

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

---

Q4. ມີມາດຕະຖານ ຫຼື ຂໍ້ບັງຄັບທີ່ກ່ຽວຂ້ອງກັບການອອກແບບການປະເມີນຜົນບໍ?

NIST AI RMF 1.

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

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

• Golden Dataset: ອອກແບບໂດຍໃຊ້ຊຸດຂໍ້ມູນ 3 ຢ່າງຄື: ຂໍ້ມູນນຳເຂົ້າ (Input), ລຳດັບເຄື່ອງມືທີ່ຄາດຫວັງ, ແລະ ຜົນລັອບທີ່ຄາດຫວັງ ພ້ອມທັງອັບເດດຢ່າງຕໍ່ເນື່ອງຈາກບັນທຶກການໃຊ້ງານ (Operation logs).
• ການປະເມີນການຮຽກໃຊ້ເຄື່ອງມື: ກວດສອບຄວາມຖືກຕ້ອງຂອງການເລືອກເຄື່ອງມື, ຕົວປ່ຽນ (Arguments), ແລະ ລຳດັບການເຮັດວຽກ ລວມເຖິງການກວດຈັບການຮຽກໃຊ້ທີ່ບໍ່ຈຳເປັນ ຫຼື ການວົນລູບ (Loop).
• ການໃຫ້ຄະແນນເສັ້ນທາງ (Trajectory): ປະສົມປະສານການໃຫ້ຄະແນນໃນແຕ່ລະຂັ້ນຕອນ (Step-level scoring) ເຂົ້າກັບການປະເມີນຄວາມໝາຍໂດຍ LLM.
• ການກວດຈັບ Regression: ຄວບຄຸມຜົນກະທົບຈາກຄວາມບໍ່ແນ່ນອນ (Non-determinism) ດ້ວຍການທົດສອບຫຼາຍຄັ້ງເພື່ອປ້ອງກັນບັນຫາ Flaky tests ແລະ ການອອກແບບເກນການຜ່ານ (Pass/Fail threshold).
• ການເຊື່ອມຕໍ່ກັບ CI: ກຳນົດງົບປະມານ Regression ເພື່ອອັດຕະໂນມັດໃນການຕັດສິນໃຈປ່ອຍເວີຊັນ (Release) ແລະ ຮັບປະກັນຄຸນນະພາບດ້ວຍແນວທາງ Shift-left.

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

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