ຕົວຊີ້ວັດການປະເມີນຜົນ AI Agent ແມ່ນລະບົບມາດຕະຖານທີ່ໃຊ້ໃນການວັດແທກຄຸນນະພາບ ແລະ ປະສິດທິພາບຂອງ AI Agent ຫຼື Agentic Workflow ທີ່ປະຕິບັດວຽກງານຢ່າງອິດສະຫຼະໃນຮູບແບບປະລິມານ.

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

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

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

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

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

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

ຄວາມແຕກຕ່າງຫຼັກລະຫວ່າງການປະເມີນແບບດັ້ງເດີມ ແລະ ການປະເມີນ Agent ມີດັ່ງນີ້:

• ໜ່ວຍການປະເມີນ: ແບບດັ້ງເດີມແມ່ນການປະເມີນແບບ "1 Input → 1 Output" ໃນຮອບດຽວ. ສ່ວນ Agent ແມ່ນການປະເມີນຕະຫຼອດທັງເສັ້ນທາງ (Trajectory) ທີ່ປະກອບດ້ວຍ "ການວາງແຜນ → ການຮຽກໃຊ້ Tool → ການອັບເດດສະຖານະ → ການກະທຳຕໍ່ໄປ" ເຊິ່ງເປັນຫຼາຍຮອບ.
• ນິຍາມຂອງຄວາມສຳເລັດ: ແບບດັ້ງເດີມແມ່ນຄວາມຖືກຕ້ອງຂອງຂໍ້ຄວາມຜົນລວມ. ສ່ວນ Agent ຕ້ອງພິຈາລະນາທັງສອງດ້ານ ຄື: ຄວາມສາມາດໃນການບັນລຸເປົ້າໝາຍສຸດທ້າຍ (Agent Goal Accuracy) ແລະ ຄວາມຖືກຕ້ອງໃນການເລືອກໃຊ້ Tool ໃນແຕ່ລະຂັ້ນຕອນ (Tool Call Accuracy).
• ລັກສະນະຂອງຂໍ້ຜິດພາດ: ແບບດັ້ງເດີມແມ່ນຂໍ້ຜິດພາດໃນຜົນລວມພຽງຢ່າງດຽວ. ສ່ວນ Agent ຈະເກີດການສົ່ງຂໍ້ມູນຕໍ່ໃຫ້ (Error Propagation) ໂດຍຂໍ້ຜິດພາດໃນຂັ້ນຕອນກາງທາງຈະສົ່ງຜົນຕໍ່ຂະບວນການຕໍ່ເນື່ອງ, ດັ່ງນັ້ນຈຶ່ງຈຳເປັນຕ້ອງມີການອອກແບບການປະເມີນທີ່ສາມາດຕິດຕາມໄດ້ວ່າ ຂໍ້ຜິດພາດເກີດຂຶ້ນທີ່ຂັ້ນຕອນໃດ ແລະ ເກີດຈາກຫຍັງ.
• ບົດບາດຂອງຜູ້ປະເມີນ: ແບບດັ້ງເດີມມັກຈະຈົບລົງດ້ວຍການກວດສອບໂດຍມະນຸດ ຫຼື ການທຽບກັບຂໍ້ຄວາມອ້າງອີງ. ສ່ວນ Agent, ການປະເມີນແບບອັດຕະໂນມັດໂດຍໃຊ້ LLM-as-a-Judge (NVIDIA ແນະນຳໃຫ້ໃຊ້ 70B Parameter ຂຶ້ນໄປ) ໄດ້ກາຍເປັນທາງເລືອກທີ່ເໝາະສົມໃນຄວາມເປັນຈິງ.

ດ້ວຍເຫດນີ້, "ຄວາມລະອຽດ" ແລະ "ແກນເວລາ" ຂອງການປະເມີນຈຶ່ງມີຄວາມແຕກຕ່າງກັນຢ່າງສິ້ນເຊີງ.

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

ຍົກຕົວຢ່າງ, ໃຫ້ພິຈາລະນາເຖິງການສົ່ງຕໍ່ຂໍ້ຜິດພາດ (Error propagation). ຖ້າການຕັດສິນໃຈຜິດພາດໃນຂັ້ນຕອນທີ 2 ສົ່ງຜົນໃຫ້ຜົນລວມໃນຂັ້ນຕອນທີ 5 ເສຍຫາຍຢ່າງງຽບໆ, ການເບິ່ງພຽງແຕ່ຜົນລວມສຸດທ້າຍກໍຈະບໍ່ສາມາດຊອກຫາສາເຫດໄດ້. ນອກຈາກນີ້, ຖ້າເຮັດຖືກ 9 ໃນ 10 ຂັ້ນຕອນ ແຕ່ລົ້ມເຫຼວໃນຂັ້ນຕອນສຸດທ້າຍ, ການປະເມີນແບບສອງຄ່າ (Binary evaluation) ງ່າຍໆ ກໍຈະບັນທຶກໄວ້ພຽງວ່າ "ລົ້ມເຫຼວ". ການປະເມີນທີ່ບໍ່ສະທ້ອນເຖິງການສະສົມຜົນງານລະຫວ່າງທາງນັ້ນ ແທບຈະບໍ່ໃຫ້ຂໍ້ຄຶດໃນການປັບປຸງເລີຍ. ຍິ່ງໄປກວ່ານັ້ນ, ການກວດສອບວ່າເຄື່ອງມືທີ່ຖືກຕ້ອງຖືກເອີ້ນໃຊ້ດ້ວຍ Argument ທີ່ຖືກຕ້ອງຫຼືບໍ່ນັ້ນ ຈຳເປັນຕ້ອງໄດ້ຮັບການຢືນຢັນຢ່າງເປັນອິດສະຫຼະຈາກຄວາມຖືກຕ້ອງຂອງຄຳຕອບສຸດທ້າຍ. ບວກກັບຄວາມບໍ່ແນ່ນອນ (Non-determinism) ທີ່ເສັ້ນທາງການປະຕິບັດງານອາດປ່ຽນແປງໄດ້ເຖິງແມ່ນວ່າຈະໃຊ້ Prompt ເດີມ, ຈຶ່ງເຮັດໃຫ້ຕ້ອງການການປະເມີນທາງສະຖິຕິຫຼາຍຄັ້ງ ແທນທີ່ຈະສະຫຼຸບຜົນຈາກການປະເມີນພຽງຄັ້ງດຽວ.

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

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

ປະເພດຂອງ Agent ທີ່ເປັນຕົວແທນມີດັ່ງນີ້:

• Single-turn completion agent: ເປັນໂຄງສ້າງແບບງ່າຍໆທີ່ຕອບກັບ 1 ຄຳຕອບຕໍ່ການປ້ອນຂໍ້ມູນ 1 ຄັ້ງ. ຕົວຢ່າງທົ່ວໄປຄື RAG chatbot ຫຼື ບັອດຕອບຄຳຖາມ FAQ, ເຊິ່ງຈະໃຊ້ Answer Accuracy ແລະ Topic Adherence ເປັນແກນຫຼັກໃນການປະເມີນ.
• Multi-step tool-use agent: ເປັນປະເພດທີ່ເຮັດວຽກໃຫ້ສຳເລັດໂດຍການເອີ້ນໃຊ້ External API ຫຼື ຖານຂໍ້ມູນຫຼາຍຄັ້ງ. Tool Call Accuracy ແລະ Trajectory Evaluation ຈະກາຍເປັນສິ່ງທີ່ສຳຄັນ. ນອກຈາກນີ້, Policy Adherence Rate ທີ່ IBM ໄດ້ລະບຸໄວ້ນັ້ນ ກໍມີຄວາມໝາຍໂດຍສະເພາະກັບ Agent ປະເພດນີ້.
• Multi-agent collaboration type: ເປັນໂຄງສ້າງທີ່ Orchestrator ແລະ Sub-agent ຫຼາຍຕົວເຮັດວຽກຮ່ວມກັນ. ເນື່ອງຈາກຄຸນນະພາບຂອງການສົ່ງຂໍ້ມູນຕໍ່ໃຫ້ (Handoff) ລະຫວ່າງ Agent ມີຜົນຕໍ່ຄຸນນະພາບໂດຍລວມ, ຈຶ່ງຈຳເປັນຕ້ອງມີຕົວຊີ້ວັດເຊັ່ນ Agent Handoff F1-Score (HF1).
• Human-in-the-loop type: ເປັນການອອກແບບທີ່ມອບໝາຍການຕັດສິນໃຈບາງສ່ວນໃຫ້ກັບມະນຸດ ເຊິ່ງມັກຖືກນຳໃຊ້ໃນໜ້າວຽກ AI BPO. ຈຳເປັນຕ້ອງລວມເອົາອັດຕາຄວາມເໝາະສົມໃນການສົ່ງຕໍ່ (Escalation) ແລະ ຄວາມຊັກຊ້າໃນການຕອບກັບ ເຊິ່ງບໍ່ສາມາດວັດແທກໄດ້ດ້ວຍການປະເມີນແບບອັດຕະໂນມັດພຽງຢ່າງດຽວ ເຂົ້າໃນເປົ້າໝາຍການປະເມີນນຳອີກ.

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

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

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

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

ມຸມມອງທີ່ຄວນກວດສອບໃນການຕັ້ງຂອບເຂດ (Scope)

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

ສິ່ງທີ່ຕ້ອງກຳນົດໃນການຕັ້ງເປົ້າໝາຍ

• ເກນໃນການຕັດສິນຜ່ານ ຫຼື ບໍ່ຜ່ານ (ຕົວຢ່າງ: ອ້າງອີງຕາມມາດຕະຖານອຸດສາຫະກຳ ເຊັ່ນ: ServiceNow ກຳນົດໃຫ້ Overall task completeness ລະດັບ 90-100% ເປັນ Excellent ແລະ 70-89% ເປັນ Good ເພື່ອກຳນົດມາດຕະຖານຂອງບໍລິສັດຕົນເອງ).
• ຄວາມຖີ່ຂອງວົງຈອນການປະເມີນ (ທຸກຄັ້ງທີ່ມີການ Deploy, ລາຍສັບປະດາ ຫຼື ລາຍເດືອນ).
• ຜູ້ຮັບຜິດຊອບຜົນການປະເມີນ ແລະ ຂະບວນການຕັດສິນໃຈ.

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

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

ໃນການອອກແບບຂໍ້ມູນທົດສອບ, ແນະນຳໃຫ້ກຽມຂໍ້ມູນ 3 ປະເພດດັ່ງນີ້:

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

ການລວມຂໍ້ມູນທັງ 3 ປະເພດນີ້ຢ່າງສົມດູນ ຈະຊ່ວຍປ້ອງກັນການປະເມີນອັດຕາຄວາມສຳເລັດສູງເກີນຄວາມເປັນຈິງ.

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

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

ນອກຈາກນີ້, ມັນຍັງມີຄວາມສຳຄັນທີ່ຂໍ້ມູນທົດສອບຈະຕ້ອງມີການກະຈາຍຕົວທີ່ໃກ້ຄຽງກັບຂໍ້ມູນທີ່ໃຊ້ງານຈິງ.

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

ເນື່ອງຈາກ Agent ມີການຮຽກໃຊ້ Tool ຫຼາຍຢ່າງ ແລະ ມີການເຊື່ອມໂຍງການຄາດຄະເນຂອງ LLM ເຂົ້າດ້ວຍກັນ, ການເບິ່ງພຽງແຕ່ Log ຂອງ Request/Response ທຳມະດາ ຈຶ່ງເຮັດໃຫ້ການຕິດຕາມຫາສາເຫດຂອງຄຸນນະພາບເຮັດໄດ້ຍາກ. ສິ່ງທີ່ຈຳເປັນຄືກົນໄກທີ່ເຊື່ອມໂຍງ Input/Output ຂອງແຕ່ລະຂັ້ນຕອນ, ຜົນການຮຽກໃຊ້ Tool ແລະ ໄລຍະເວລາທີ່ໃຊ້ ໃຫ້ເປັນ "Trace" ດຽວກັນ.

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

• Distributed Tracing: ກຳນົດ Trace ID ທີ່ເປັນເອກະລັກໃຫ້ກັບແຕ່ລະຂັ້ນຕອນຂອງ Agent ແລະ ບັນທຶກຄວາມສຳພັນແບບພໍ່-ລູກລະຫວ່າງຂັ້ນຕອນ
• Tool Call Log: ບັນທຶກຊື່ Tool, ພາຣາມິເຕີຂາເຂົ້າ, ຄ່າທີ່ສົ່ງກັບຄືນ ແລະ ທຸງສະແດງຜົນສຳເລັດ/ລົ້ມເຫຼວ ເປັນ Log ທີ່ມີໂຄງສ້າງ
• LLM Inference Log: ບັນທຶກ Prompt ທັງໝົດ, ຜົນລວມຈາກ Model, ຈຳນວນ Token ແລະ Latency ເພື່ອໃຫ້ສາມາດນຳກັບມາທົດສອບຄືນໃໝ່ໄດ້ໃນພາຍຫຼັງ
• Error Classification Tag: ຈັດປະເພດ Error ເຊັ່ນ: Timeout, Tool ລົ້ມເຫຼວ, ຫຼື ຜົນລວມທີ່ບໍ່ຖືກຕ້ອງ ດ້ວຍ Tag ເພື່ອໃຫ້ງ່າຍຕໍ່ການລວບລວມຂໍ້ມູນ

ຄວາມລະອຽດຂອງ Log ຈະມີ ການແລກປ່ຽນ ຫຼື Trade-off ກັບຕົ້ນທຶນ. ໃນສະພາບແວດລ້ອມການໃຊ້ງານຈິງ (Production), ນະໂຍບາຍທີ່ເໝາະສົມຄືການປັບອັດຕາການ Sampling ໄປພ້ອມກັບການບັນທຶກ Trace ທີ່ລົ້ມເຫຼວທັງໝົດໄວ້.

ສະຫຼຸບ: ການວັດແທກອັດຕາຄວາມສຳເລັດຂອງ Agent ຈຳເປັນຕ້ອງມີການປະສົມປະສານຫຼາຍຕົວຊີ້ວັດເຂົ້າດ້ວຍກັນ ເຊັ່ນ: ອັດຕາການເຮັດວຽກສຳເລັດ, ຄວາມຖືກຕ້ອງຂອງແຕ່ລະຂັ້ນຕອນ ແລະ ຄວາມຄຸ້ມຄ່າຂອງຕົ້ນທຶນ.

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

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

ອັດຕາຄວາມສຳເລັດຂອງວຽກ (Task Success Rate / TSR) ໝາຍເຖິງອັດຕາສ່ວນຂອງສະຖານະການທີ່ Agent ສາມາດບັນລຸເປົ້າໝາຍສຸດທ້າຍໄດ້. ໃນລະບົບການປະເມີນຜົນຂອງ ServiceNow, ຄະແນນ Overall task completeness ຈະຖືກບັນທຶກເປັນ 3 ລະດັບຄື: "3: Successful / 2: Partially successful / 1: Unsuccessful" ແລະ ຈັດການດ້ວຍປ້າຍກຳກັບຕັ້ງແຕ່ Excellent (90-100%) ໄປຈົນເຖິງ Poor (0-49%).

ອັດຕາຄວາມສຳເລັດບາງສ່ວນ ແມ່ນອັດຕາສ່ວນຂອງກໍລະນີທີ່ຈັດຢູ່ໃນ "Partially successful". ຈຸດວັດແທກຫຼັກໆມີດັ່ງນີ້:

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

ການນຳໃຊ້ຕົວຊີ້ວັດທັງສອງຢ່າງນີ້ຮ່ວມກັນ ຈະເຮັດໃຫ້ເຫັນສະພາວະທີ່ວ່າ "ອັດຕາຄວາມສຳເລັດຕໍ່າ ແຕ່ອັດຕາຄວາມສຳເລັດບາງສ່ວນສູງ".

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

ຄວາມຖືກຕ້ອງຂອງຂັ້ນຕອນ ໝາຍເຖິງອັດຕາສ່ວນຂອງຂັ້ນຕອນທີ່ສຳເລັດຕາມຄວາມຄາດຫວັງ ໃນບັນດາການກະທຳແຕ່ລະຢ່າງທີ່ Agent ໄດ້ປະຕິບັດ (ການເອີ້ນໃຊ້ Tool, ການຕັດສິນໃຈແຍກສາຂາ, ການສະກັດຂໍ້ມູນ ແລະ ອື່ນໆ). Trajectory Evaluation ແລະ Tool Call Accuracy ຂອງ NVIDIA NeMo ແມ່ນອີງໃສ່ແນວຄິດນີ້, ໂດຍມີການບັນທຶກຄວາມຖືກຕ້ອງ ຫຼື ຜິດພາດຂອງແຕ່ລະຂັ້ນຕອນດ້ວຍຄະແນນ 0 ຫາ 1.

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

ສຳລັບຫຼັກການໃນການຕັດສິນໃຈ ສາມາດຈັດລຽງໄດ້ດັ່ງນີ້:

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

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

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

ຈຸດວັດແທກຫຼັກຂອງ Latency

• End-to-end Latency: ເວລາລວມທີ່ໃຊ້ຕັ້ງແຕ່ໄດ້ຮັບຄຳຮ້ອງຂໍຈາກຜູ້ໃຊ້ ຈົນເຖິງການສົ່ງຄຳຕອບສຸດທ້າຍກັບຄືນໄປ.
• Latency ແຍກຕາມຂັ້ນຕອນ: ບັນທຶກໂດຍການແຍກສ່ວນການປະມວນຜົນຂອງ LLM, ການເອີ້ນໃຊ້ Tool ແລະ ການລໍຖ້າ API ພາຍນອກ.
• P95 / P99 Percentile: ການຈັບຄ່າທີ່ຜິດປົກກະຕິ (Outliers) ບໍ່ແມ່ນພຽງແຕ່ຄ່າສະເລ່ຍ ເພື່ອໃຫ້ສາມາດເຂົ້າໃຈຄວາມຖີ່ຂອງການເກີດຄວາມໜ່ວງ (Latency spike).

ການແຍກອອກເປັນຂັ້ນຕອນຈະຊ່ວຍໃຫ້ສາມາດແຍກແຍະຄໍຂວດ (Bottleneck) ໄດ້ວ່າ "ການປະມວນຜົນຂອງ LLM ຊ້າ ຫຼື ການລໍຖ້າການຕອບກັບຈາກ Tool ພາຍນອກຊ້າ".

ຈຸດວັດແທກຄວາມຄຸ້ມຄ່າຂອງຕົ້ນທຶນ

• ຕົ້ນທຶນ Token ຕໍ່ໜ້າວຽກ: ລວບລວມຈຳນວນ Token ຂາເຂົ້າແລະຂາອອກທີ່ໃຊ້ໃນການເຮັດວຽກໃຫ້ສຳເລັດ 1 ວຽກ ຈາກ Log.
• ຈຳນວນຄັ້ງໃນການເອີ້ນໃຊ້ Tool: ກວດສອບວ່າບໍ່ມີການ Loop ທີ່ບໍ່ຈຳເປັນ ຫຼື ການເອີ້ນໃຊ້ຊ້ຳຊ້ອນ.
• ອັດຕາສ່ວນຕົ້ນທຶນຕໍ່ຜົນສຳເລັດ (Cost per Successful Task): ສາມາດປະເມີນຄວາມຄຸ້ມຄ່າທາງເສດຖະກິດໄດ້ໂດຍການນຳເອົາ Cost ເຊິ່ງເປັນໜຶ່ງໃນຕົວຊີ້ວັດຫຼັກທີ່ IBM ໄດ້ລະບຸໄວ້ ມາຫານດ້ວຍຈຳນວນວຽກທີ່ເຮັດສຳເລັດ.

ຈຸດປະຕິບັດໃນການວັດແທກ

Latency ແລະຕົ້ນທຶນສາມາດບໍລິຫານຈັດການແບບລວມສູນໄດ້ ໂດຍການບັນທຶກ Timestamp ແລະປະລິມານການໃຊ້ Token ໃນລະດັບ Span ໄວ້ໃນໂຄງສ້າງພື້ນຖານ ຫຼື Infrastructure ຂອງການຕິດຕາມ (Tracing).

ສະຫຼຸບ: ການປະເມີນຄຸນນະພາບສາມາດຈັດເປັນລະບົບໄດ້ດ້ວຍ 3 ຂັ້ນຕອນຄື: "ການທົດສອບຕາມສະຖານະການ (Scenario Test) → ການປະເມີນໂດຍມະນຸດ ແລະ LLM-as-a-Judge → ການຕິດຕາມກວດກາຢ່າງຕໍ່ເນື່ອງ".

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

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

ໃນການທົດສອບແບບສະຖານະການ (Scenario test), ເຮົາຈະກຽມຂະບວນການເຮັດວຽກທີ່ Agent ຕ້ອງຮັບຜິດຊອບຕົວຈິງ ໂດຍແບ່ງອອກເປັນ 3 ໝວດໝູ່ ຄື: "ລະບົບປົກກະຕິ", "ລະບົບຜິດປົກກະຕິ" ແລະ "ລະບົບຄ່າຂອບເຂດ".

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

ສິ່ງສຳຄັນຄືການກຳນົດທັງ "ລຳດັບການຮຽກໃຊ້ Tool ທີ່ຄາດຫວັງ" ແລະ "ຜົນລວມສຸດທ້າຍ" ໄວ້ໃນແຕ່ລະສະຖານະການ. ໃນບັນດາດັດຊະນີຫຼັກທີ່ IBM ໄດ້ລະບຸໄວ້, Success rate / task completion ແລະ Error rate ສາມາດວັດແທກໄດ້ໂດຍກົງໃນຂັ້ນຕອນນີ້.

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

1. ຜົນການທົດສອບແຕ່ລະສະຖານະການ (Pass / Fail)
2. ຄວາມຖືກຕ້ອງຂອງການຮຽກໃຊ້ Tool (ໄດ້ຮຽກໃຊ້ Tool ທີ່ຖືກຕ້ອງຕາມລຳດັບທີ່ຖືກຕ້ອງຫຼືບໍ່)
3. ການມີຢູ່ຂອງການເຮັດວຽກເພື່ອຟື້ນຟູລະບົບ (Recovery) ເມື່ອເກີດຂໍ້ຜິດພາດ

Tool Call Accuracy ແລະ Trajectory Evaluation ຂອງ NVIDIA NeMo ມີຄວາມສອດຄ່ອງກັບການລວມຄະແນນນີ້ ແລະ ສາມາດປຽບທຽບປະລິມານໄດ້ໃນຊ່ວງຄະແນນ 0.0 ຫາ 1.0.

ເມື່ອຢືນຢັນຜົນການທົດສອບດ້ານຟັງຊັນການເຮັດວຽກຜ່ານການທົດສອບຕາມສະຖານະການ (Scenario test) ແລ້ວ, ຂັ້ນຕອນຕໍ່ໄປແມ່ນການປະເມີນດ້ານຄຸນນະພາບວ່າ "ການຕອບໂຕ້ ຫຼື ການກະທຳນັ້ນມີຄວາມເປັນທຳມະຊາດ ແລະ ຖືກຕ້ອງຊັດເຈນພຽງໃດ". ສິ່ງທີ່ໜ້າວຽກມັກຈະພົບເຫັນເລື້ອຍໆໃນຈຸດນີ້ຄື ບັນຫາທີ່ວ່າ "ຕ້ອງການເຮັດໃຫ້ເປັນອັດຕະໂນມັດ ແຕ່ກໍກັງວົນເລື່ອງຄວາມຖືກຕ້ອງ" ເຊິ່ງເປັນ ການແລກປ່ຽນ ຫຼື Trade-off ທີ່ຕ້ອງຮັບມື. ເພື່ອສ້າງຄວາມສົມດຸນດັ່ງກ່າວ, ວິທີການທີ່ນິຍົມໃຊ້ກັນຢ່າງແຜ່ຫຼາຍຄືການປະສົມປະສານລະຫວ່າງ ການປະເມີນໂດຍມະນຸດ ແລະ LLM-as-a-Judge.

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

ເມື່ອນຳໃຊ້ LLM-as-a-Judge, ຕ້ອງລະວັງຈຸດທີ່ວ່າຂະໜາດຂອງຕົວແບບ Judge LLM ມີຜົນໂດຍກົງຕໍ່ຄວາມຖືກຕ້ອງໃນການປະເມີນ. ໃນ Agent Goal Accuracy ຂອງ NVIDIA NeMo, ຄວາມຖືກຕ້ອງມີແນວໂນ້ມທີ່ຈະເພີ່ມຂຶ້ນເມື່ອໃຊ້ຕົວແບບທີ່ມີ 70B ພາຣາມິເຕີຂຶ້ນໄປ ແລະ ແນະນຳໃຫ້ໃຊ້ຕົວແບບທີ່ເກີນ 405B. ຕົວຊີ້ວັດທີ່ສົ່ງຄ່າເປັນຄະແນນ 0.0-1.0 ເຊັ່ນ: Tool Call Accuracy ຫຼື Topic Adherence ນັ້ນເໝາະສົມກັບການໃຫ້ຄະແນນແບບອັດຕະໂນມັດ, ແລະ ການລະບຸມາດຕະຖານການໃຫ້ຄະແນນ (Rubric) ໄວ້ໃນ Prompt ສຳລັບການປະເມີນຢ່າງຊັດເຈນ ກໍສາມາດຮັບປະກັນຄວາມສາມາດໃນການເຮັດຊ້ຳຂອງຄະແນນໄດ້.

ໃນທາງກົງກັນຂ້າມ, ການໃຫ້ມະນຸດປະເມີນທຸກກໍລະນີມັກຈະບໍ່ເປັນຈິງໃນແງ່ຂອງຕົ້ນທຶນ. ດັ່ງນັ້ນ, ໃນການປະຕິບັດງານຕົວຈິງ, ຈຶ່ງມີການນຳໃຊ້ວິທີການທີ່ໃຫ້ບູລິມະສິດແກ່ການນຳເອົາຕົວຢ່າງທີ່ມີຄະແນນຕ່ຳຈາກ LLM-as-a-Judge ຫຼື ຕົວຢ່າງທີ່ຢູ່ໃກ້ກັບຄ່າຂອບເຂດ (Boundary value) ມາໃຫ້ມະນຸດກວດສອບ. ການແບ່ງປັນແກນການປະເມີນ ແລະ ຕົວຢ່າງທີ່ເປັນຮູບປະທຳໃຫ້ແກ່ຜູ້ກວດສອບລ່ວງໜ້າ ຈະຊ່ວຍໃຫ້ສາມາດຫຼຸດຜ່ອນຄວາມແຕກຕ່າງລະຫວ່າງຜູ້ປະເມີນໄດ້ງ່າຍຂຶ້ນ.

ດ້ວຍການວາງໂຄງສ້າງສອງຂັ້ນຕອນນີ້, ຈະເຮັດໃຫ້ສາມາດຮັກສາຄວາມສົມດຸນລະຫວ່າງການຂະຫຍາຍຕົວ (Scalability) ແລະ ຄວາມຖືກຕ້ອງໃນການປະເມີນໄດ້.

"ການທົດສອບຕາມສະຖານະການ (Scenario test) ຜ່ານແລ້ວ ແຕ່ຫຼັງຈາກເປີດຕົວ ຫຼື Launch ຢ່າງເປັນທາງການ ກັບບໍ່ມີໃຜສັງເກດເຫັນຄວາມຜິດປົກກະຕິ" —— ການຕິດຕາມກວດກາຢ່າງຕໍ່ເນື່ອງ (Continuous monitoring) ມີບົດບາດໃນການປ້ອງກັນສະຖານະການດັ່ງກ່າວ.

ການປະເມີນຜົນພຽງຄັ້ງດຽວ ບໍ່ສາມາດກວດຈັບຄວາມເສື່ອມຖອຍທີ່ເກີດຂຶ້ນຕາມເວລາໄດ້ ເຊັ່ນ: ການປ່ຽນແປງພຶດຕິກຳຂອງຕົວແບບ (Model behavior drift) ຫຼື ການປ່ຽນແປງມາດຕະຖານ ຫຼື Specification ຂອງ API ພາຍນອກ. ການສ້າງກົນໄກການສັງເກດການແບບ Real-time ໃນສະພາບແວດລ້ອມການເຮັດວຽກຈິງ ແມ່ນສິ່ງທີ່ຂາດບໍ່ໄດ້ໃນການຮັກສາຄຸນນະພາບຂອງ Agent.

ຕົວຊີ້ວັດຫຼັກທີ່ຄວນຕິດຕາມໃນການກວດກາ (Monitoring)

• ທ່າອ່ຽງອັດຕາການສຳເລັດຂອງວຽກງານ: ໂດຍອ້າງອີງຈາກຄ່າ Threshold ຂອງ ServiceNow, ໃຫ້ກວດສອບເປັນລາຍອາທິດວ່າສາມາດຮັກສາລະດັບ Excellent (90% ຂຶ້ນໄປ) ໄດ້ຫຼືບໍ່.
• ອັດຕາຄວາມສຳເລັດໃນການເອີ້ນໃຊ້ເຄື່ອງມື: ຖ້າ Tool Call Accuracy ເລີ່ມຫຼຸດລົງ ໃຫ້ສົງໄສວ່າອາດມີການປ່ຽນແປງມາດຕະຖານ ຫຼື Specification ຂອງ API ພາຍນອກ ຫຼື ເຄື່ອງມືພາຍໃນ.
• Latency ແລະ ຄ່າໃຊ້ຈ່າຍ: ໃຫ້ແຈ້ງເຕືອນເມື່ອເວລາຕອບສະໜອງສະເລ່ຍ ຫຼື ປະລິມານການໃຊ້ Token ເກີນອັດຕາທີ່ກຳນົດໄວ້.
• ອັດຕາຄວາມຜິດພາດ (Error rate): ຕິດຕາມກວດກາແບບ Real-time ວ່າ ມີຂໍ້ຍົກເວັ້ນທີ່ບໍ່ໄດ້ຄາດຄິດ ຫຼື ການຢຸດສະງັກຂອງວຽກງານເພີ່ມທະວີຂຶ້ນເລື້ອຍໆ ຫຼື ບໍ່.

ແນວຄິດການຕັ້ງຄ່າການແຈ້ງເຕືອນ (Alert)

ການອອກແບບການແຈ້ງເຕືອນໂດຍໃຊ້ 2 ຊັ້ນ ຄື "Static Threshold" ແລະ "Change Rate Threshold" ຈະມີປະສິດທິຜົນຫຼາຍ:

• Static Threshold: ແຈ້ງເຕືອນທັນທີເມື່ອອັດຕາການສຳເລັດຂອງວຽກງານຫຼຸດຕໍ່າກວ່າ 70%.
• Change Rate Threshold: ແຈ້ງເຕືອນເມື່ອອັດຕາຄວາມຜິດພາດແຍ່ລົງກວ່າ 20% ເມື່ອທຽບກັບອາທິດກ່ອນ.

ການນຳໃຊ້ Managed Service ເຊັ່ນ Amazon Bedrock AgentCore Evaluations ຈະຊ່ວຍໃຫ້ທ່ານສາມາດສ້າງຂະບວນການ ຫຼື Pipeline ຕັ້ງແຕ່ການເກັບກຳ Log ຈົນເຖິງການສົ່ງການແຈ້ງເຕືອນໄດ້ໃນໄລຍະເວລາສັ້ນໆ.

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

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

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

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

ໃນກອບການປະເມີນຜົນຂອງ ServiceNow, ມີການແນະນຳໃຫ້ບັນທຶກ Overall task completeness ແລະ Tool performance record ໄວ້ໃນແກນທີ່ແຕກຕ່າງກັນ. ນີ້ແມ່ນເພື່ອແຍກການປະເມີນລະຫວ່າງ "ເຮັດສຳເລັດຫຼືບໍ່" ກັບ "ໄດ້ໃຊ້ Tool ທີ່ຖືກຕ້ອງຫຼືບໍ່" ອອກຈາກກັນ.

ເພື່ອການປັບປຸງໃຫ້ດີຂຶ້ນ, ຄວນຕິດຕາມຢ່າງໜ້ອຍ 3 ແກນດັ່ງຕໍ່ໄປນີ້:

1. ຕົວຊີ້ວັດຜົນສຳເລັດ: ອັດຕາການເຮັດວຽກສຳເລັດ, ອັດຕາການເຮັດວຽກສຳເລັດບາງສ່ວນ
2. ຕົວຊີ້ວັດຂະບວນການ: ຄວາມຖືກຕ້ອງໃນການຮຽກໃຊ້ Tool, ຈຳນວນຂັ້ນຕອນ

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

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

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

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

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

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

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

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

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

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

ຂັ້ນຕອນການລະບຸຄໍຂວດ (Bottleneck)

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

ເມື່ອຕັດສິນໄດ້ວ່າສາເຫດຂອງຄໍຂວດມາຈາກ Prompt, ວິທີການຕໍ່ໄປນີ້ຈະມີປະສິດທິຜົນ:

ວິທີການຫຼັກໃນການປັບປຸງ Prompt

• ປັບລະດັບຄວາມລະອຽດຂອງຄຳສັ່ງ: ການປ່ຽນຄຳສັ່ງທີ່ບໍ່ຊັດເຈນໃຫ້ເປັນການອະທິບາຍຂັ້ນຕອນທີ່ລະອຽດຈະຊ່ວຍຫຼຸດຜ່ອນຄວາມຜິດພາດໃນການເລືອກເຄື່ອງມື.
• ທົບທວນຄວາມຍາວຂອງ Context: ຕັດຂໍ້ມູນທີ່ບໍ່ຈຳເປັນອອກ ແລະ ຄັດເລືອກຂໍ້ມູນທີ່ Agent ຄວນອ້າງອີງ. ສຳລັບລາຍລະອຽດເພີ່ມເຕີມ ສາມາດອ້າງອີງໄດ້ຈາກ ບົດນຳສະເໜີ Context Engineering｜ຂັ້ນຕອນຕໍ່ໄປຂອງການອອກແບບ Prompt
• ເພີ່ມຕົວຢ່າງ Few-shot: ນຳເອົາຕົວຢ່າງທີ່ຖືກຕ້ອງທີ່ສອດຄ່ອງກັບຮູບແບບທີ່ລົ້ມເຫຼວເຂົ້າໄປໃນ Prompt ເພື່ອເພີ່ມຄວາມແມ່ນຍຳໃນການຕັດສິນໃຈ.

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

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

ການເຮັດ Fine-tuning ຈະມີປະສິດທິຜົນກໍຕໍ່ເມື່ອຢູ່ໃນສະຖານະການທີ່ຈຳກັດເທົ່ານັ້ນ ເຊັ່ນ: ເມື່ອເກີດຄວາມຜິດພາດຊ້ຳໆໃນດ້ານຄຳສັບ ຫຼື ຮູບແບບປະໂຫຍກຂອງ Domain ສະເພາະ, ເມື່ອຮູບແບບຜົນລວມ (Output format) ບໍ່ສະຖຽນພຽງແຕ່ການໃຊ້ Prompt, ຫຼື ເມື່ອຄະແນນ Tool Call Accuracy ຕ່ຳຢ່າງຕໍ່ເນື່ອງ.

ໃນທາງກົງກັນຂ້າມ, ຖ້າການກຳນົດ Argument ຂອງການເອີ້ນໃຊ້ Tool ມີຄວາມບໍ່ຊັດເຈນ ຫຼື Schema ຂອງຄ່າທີ່ສົ່ງກັບມາ (Return value) ບໍ່ເປັນເອກະພາບ, ຄວນປັບປຸງມາດຕະຖານຂອງ Tool ກ່ອນການເຮັດ Fine-tuning. ກ່ອນທີ່ຈະດຳເນີນການຮຽນຮູ້ທີ່ມີຕົ້ນທຶນສູງ, ພວກເຮົາຈະມາທົບທວນຈຸດສຳຄັນ ຫຼື ແກນຫຼັກ ໃນການອອກແບບ Tool ໄປເທື່ອລະຈຸດ.

Q1. ຕົວຊີ້ວັດການປະເມີນຜົນຂອງ AI Agent ມີຄວາມແຕກຕ່າງຈາກການປະເມີນ Chatbot ແບບດັ້ງເດີມແນວໃດ?

ການປະເມີນ Chatbot ແບບດັ້ງເດີມຈະເນັ້ນໃສ່ການວັດແທກຄວາມຖືກຕ້ອງຂອງການຕອບໂຕ້ໃນແຕ່ລະຄັ້ງ (ຄວາມຖືກຕ້ອງຂອງຄຳຕອບ, ຄະແນນ BLEU, ແລະອື່ນໆ). ໃນທາງກົງກັນຂ້າມ, ການປະເມີນ AI Agent ແມ່ນຈະປະເມີນຕ່ອງໂສ້ຂອງການກະທຳທີ່ເປັນອິດສະຫຼະ ເຊັ່ນ: ອັດຕາການສຳເລັດຂອງວຽກງານທັງໝົດທີ່ກວມເອົາຫຼາຍຂັ້ນຕອນ, ຄວາມຖືກຕ້ອງຂອງການເອີ້ນໃຊ້ເຄື່ອງມື (Tool Call Accuracy), ແລະ ການບັນລຸເປົ້າໝາຍ (Agent Goal Accuracy). ຄວາມແຕກຕ່າງທີ່ສຳຄັນຄືການຕັ້ງຄຳຖາມເຖິງຄຸນນະພາບຂອງຂະບວນການທັງໝົດ ບໍ່ແມ່ນພຽງແຕ່ການຕອບໂຕ້ໃນຮອບດຽວ.

Q2. ອັດຕາຄວາມສຳເລັດຂອງ Agent (Agentic Success Rate) ແລະ ອັດຕາຄວາມສຳເລັດຂອງວຽກງານ (Task Success Rate) ມີຄວາມແຕກຕ່າງກັນແນວໃດ?

ອັດຕາຄວາມສຳເລັດຂອງວຽກງານ (TSR) ແມ່ນຕົວຊີ້ວັດທີ່ຕັດສິນແບບສອງຄ່າ (Binary) ວ່າ "ວຽກງານສຳເລັດໃນທີ່ສຸດຫຼືບໍ່". ໃນຂະນະທີ່ Agentic Success Rate (ASR) ຈະພິຈາລະນາເຖິງການປ່ຽນແປງສະຖານະ (State Transition) ທີ່ Agent ຜ່ານມາໃນລະຫວ່າງທາງ ແລະ ແຍກອອກເປັນ Transition Recall ແລະ Transition Precision ເພື່ອປະເມີນຜົນ. ເນື່ອງຈາກ TSR ພຽງຢ່າງດຽວອາດເຮັດໃຫ້ພາດກໍລະນີທີ່ "ບັງເອີນເຮັດສຳເລັດ ແຕ່ຂັ້ນຕອນລະຫວ່າງທາງບໍ່ມີປະສິດທິພາບ", ການນຳໃຊ້ ASR ມາປະສົມປະສານຈະຊ່ວຍໃຫ້ສາມາດເຂົ້າໃຈເຖິງຄຸນນະພາບຂອງຂະບວນການໄດ້.

Q3. Judge LLM ທີ່ໃຊ້ໃນການປະເມີນຜົນ ຈຳເປັນຕ້ອງມີຂະໜາດເທົ່າໃດ?

ອີງຕາມເອກະສານທາງການຂອງ NVIDIA NeMo, Judge LLM ຈຳເປັນຕ້ອງມີຕົວແບບທີ່ມີຂະໜາດຢ່າງໜ້ອຍ 70B ພາຣາມິເຕີ ແລະ ແນະນຳໃຫ້ໃຊ້ຕົວແບບທີ່ມີຂະໜາດຫຼາຍກວ່າ 405B ພາຣາມິເຕີ. ການໃຊ້ຕົວແບບຂະໜາດນ້ອຍເປັນ Judge ມັກຈະເຮັດໃຫ້ຄວາມຖືກຕ້ອງໃນການຕັດສິນຄວາມລະອຽດອ່ອນຫຼຸດລົງ ແລະ ສົ່ງຜົນໃຫ້ຄວາມໜ້າເຊື່ອຖືຂອງຜົນການປະເມີນຫຼຸດລົງ. ຖ້າມີຂໍ້ຈຳກັດດ້ານຕົ້ນທຶນ, ການນຳໃຊ້ Judge LLM ຂະໜາດໃຫຍ່ສະເພາະໃນສະຖານະການທີ່ມີຄວາມສຳຄັນສູງ ແລະ ປະສົມປະສານກັບການປະເມີນແບບ Rule-based ໃນສ່ວນອື່ນໆ ແມ່ນວິທີການທີ່ເປັນໄປໄດ້ໃນການປະຕິບັດງານ.

Q4. ຄະແນນ Overall Task Completeness ຂອງ ServiceNow ຄວນຕີຄວາມໝາຍແນວໃດ?

ຕາມນິຍາມຂອງ ServiceNow, ຄະແນນ Overall Task Completeness ຈະຖືກບັນທຶກໄວ້ໃນ 3 ລະດັບ ຄື: 3 (Successful), 2 (Partially successful), ແລະ 1 (Unsuccessful). ນອກຈາກນີ້, ຍັງມີການຕັ້ງປ້າຍກຳກັບອັດຕາຄວາມສຳເລັດໄວ້ເປັນ Excellent (90–100%), Good (70–89%), Moderate (50–69%), ແລະ Poor (0–49%). ໃນການປະຕິບັດງານຈິງ, ໂດຍທົ່ວໄປແລ້ວຈະຕັ້ງລະດັບ Good ຂຶ້ນໄປເປັນມາດຕະຖານຂັ້ນຕ່ຳ ແລະ ໃຫ້ຄວາມສຳຄັນກັບການປັບປຸງສະຖານະການທີ່ຢູ່ໃນລະດັບ Moderate ລົງມາເປັນອັນດັບທຳອິດ.

Q5. ຖ້າຈັດການຕົວຊີ້ວັດການປະເມີນຜົນແລ້ວ ແຕ່ບໍ່ສາມາດນຳໄປສູ່ການປັບປຸງໄດ້ ຄວນກັບໄປກວດສອບບ່ອນໃດ?

ຖ້າວັດແທກຕົວຊີ້ວັດແລ້ວແຕ່ການປັບປຸງບໍ່ຄືບໜ້າ, ໃນຫຼາຍກໍລະນີມີສາເຫດມາຈາກ "ຄວາມລະອຽດຂອງຕົວຊີ້ວັດຫຍາບເກີນໄປ ຈົນບໍ່ສາມາດລະບຸຈຸດຄໍຂວດ (Bottleneck) ໄດ້". ກ່ອນອື່ນ, ຄວນເພີ່ມຕົວຊີ້ວັດທີ່ມີຄວາມລະອຽດສູງ ເຊັ່ນ: ອັດຕາການສົ່ງຂໍ້ມູນຕໍ່ໃຫ້ (Error Propagation) ໃນແຕ່ລະຂັ້ນຕອນ ແລະ ຄວາມຖືກຕ້ອງຂອງການເອີ້ນໃຊ້ເຄື່ອງມື, ບໍ່ແມ່ນພຽງແຕ່ຄ່າສະຫຼຸບລວມຢ່າງອັດຕາຄວາມສຳເລັດຂອງວຽກງານ. ຈາກນັ້ນ, ໃຫ້ກວດສອບ Trace log ຂອງສະຖານະການທີ່ລົ້ມເຫຼວຢ່າງລະອຽດ ເພື່ອແຍກແຍະວ່າບັນຫາເກີດຂຶ້ນຢູ່ບ່ອນໃດ ບໍ່ວ່າຈະເປັນການອອກແບບ Prompt, ການກຳນົດເຄື່ອງມື, ຫຼື ຄຸນນະພາບການຕອບໂຕ້ຂອງ API ພາຍນອກ. ບົດນຳສະເໜີກ່ຽວກັບ Context Engineering | ຂັ້ນຕອນຕໍ່ໄປຂອງການອອກແບບ Prompt ກໍສາມາດໃຊ້ເປັນແນວທາງໃນການປັບປຸງໄດ້ເຊັ່ນກັນ.