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

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

ບົດຄວາມນີ້ມີຈຸດປະສົງສຳລັບວິສະວະກອນ, ຜູ້ຮັບຜິດຊອບດ້ານ LLMOps, ແລະ ຜູ້ຮັບຜິດຊອບດ້ານການຮັບປະກັນຄຸນນະພາບທີ່ນຳ LLM ໄປໃຊ້ງານຈິງ ໂດຍຈະຈັດລະບຽບພາບລວມຂອງ LLM-as-a-Judge (ຫຼື ຂຽນອີກຢ່າງວ່າ LLM as a Judge), ໂປຣໂຕຄອນການປະເມີນຜົນທີ່ເປັນຕົວແທນ (Pointwise / Pairwise / Reference-based), ຄວາມລຳອຽງຫຼັກ ແລະ ວິທີການແກ້ໄຂ, 4 ຂັ້ນຕອນການນຳໃຊ້, ຈົນເຖິງຮູບແບບການດຳເນີນງານຢ່າງເປັນລະບົບ. ນອກຈາກນີ້ ຍັງຈະອະທິບາຍເຖິງການແບ່ງຂອບເຂດການເຮັດວຽກກັບ AI Observability ແລະ Guardrails ລວມເຖິງການອອກແບບການປະເມີນຜົນແບບ Regression ເພື່ອລວມເຂົ້າໃນ CI/CD ອີກດ້ວຍ.

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

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

ໂຄງສ້າງພື້ນຖານ ຫຼື Infrastructure ພື້ນຖານຂອງ LLM-as-a-Judge ແມ່ນງ່າຍດາຍ ແລະ ປະກອບດ້ວຍ 3 ອົງປະກອບດັ່ງນີ້:

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

Judge ຈະອ່ານ Rubric ແລ້ວເຮັດການໃຫ້ຄະແນນຜົນລວມ (Pointwise), ເລືອກຄຳຕອບທີ່ດີກວ່າລະຫວ່າງ 2 ຄຳຕອບ (Pairwise), ຫຼື ຕັດສິນຄວາມສອດຄ່ອງກັບຄຳຕອບອ້າງອີງ (Reference-based). ຜົນການໃຫ້ຄະແນນຈະຖືກສະສົມໄວ້ໃນຖານຂໍ້ມູນ Log ແລະ ເຊື່ອມຕໍ່ກັບ Dashboard ທີ່ສາມາດສັງເກດການໄດ້, ການກວດຫາ Regression ໃນ CI/CD, ຫຼື ການຕັດສິນຜົນ A/B Test.

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

LLM-as-a-Judge ຈະຢູ່ຮ່ວມກັບວິທີການປະເມີນຜົນແບບດັ້ງເດີມໂດຍມີການແບ່ງໜ້າທີ່ກັນ. ການເຂົ້າໃຈລັກສະນະຂອງແຕ່ລະວິທີເພື່ອເລືອກໃຊ້ໃຫ້ເໝາະສົມຄືວິທີການປະຕິບັດງານຕົວຈິງ.

• ການປະເມີນໂດຍມະນຸດ (Human Review): ມີຄວາມໜ້າເຊື່ອຖືສູງທີ່ສຸດ ແຕ່ມີຂໍ້ຈຳກັດດ້ານຕົ້ນທຶນ, ຄວາມໄວ ແລະ ການຂະຫຍາຍຕົວ (Scalability). ເປັນບ່ອນອີງສຳລັບກໍລະນີທີ່ຄາບກ່ຽວ ແລະ ການຕັດສິນຂັ້ນສຸດທ້າຍ.
• ຕົວຊີ້ວັດອັດຕະໂນມັດ (BLEU / ROUGE / Embedding Similarity): ມີຄວາມໄວ, ຕົ້ນທຶນຕ່ຳ ແລະ ມີຄວາມສາມາດໃນການເຮັດຊ້ຳໄດ້ສູງ ແຕ່ບໍ່ສາມາດວັດແທກຄວາມເໝາະສົມຂອງບໍລິບົດ ຫຼື ຄວາມຖືກຕ້ອງຂອງການໃຫ້ເຫດຜົນໄດ້. ເຮັດໜ້າທີ່ເປັນພື້ນຖານ (Baseline) ໃນການກວດຫາການຖົດຖອຍ (Regression).
• LLM-as-a-Judge: ສາມາດກຳນົດແກນການປະເມີນໄດ້ຢ່າງຍືດຫຍຸ່ນດ້ວຍ Rubric ພາສາທຳມະຊາດ ແລະ ສາມາດປະມວນຜົນຄຳຕອບຈຳນວນຫຼາຍໄດ້ຢ່າງວ່ອງໄວ. ໃນທາງກົງກັນຂ້າມ, ມັນຍັງມີບັນຫາເລື່ອງອະຄະຕິ (Bias) ແລະ ຄວາມບໍ່ແນ່ນອນ (Determinism).

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

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

ເມື່ອເລີ່ມນຳໃຊ້ LLM ໃນການຜະລິດແລ້ວ, ບັນຫາດ້ານຄຸນນະພາບຈະປາກົດອອກມາໃນຮູບແບບດັ່ງຕໍ່ໄປນີ້:

• ອັດຕາການເກີດ Hallucination ທີ່ບໍ່ໄດ້ວັດແທກ: ຄວາມເຂົ້າໃຈຜິດກ່ຽວກັບຂໍ້ເທັດຈິງຈະຖືກຄົ້ນພົບກໍຕໍ່ເມື່ອມີການຮ້ອງຮຽນຈາກຜູ້ໃຊ້ເທົ່ານັ້ນ
• ການຖົດຖອຍເນື່ອງຈາກການອັບເດດ Prompt ຫຼື Model: ການປ່ຽນແປງພຽງແຖວດຽວໃນ Prompt ເຮັດໃຫ້ຄວາມຖືກຕ້ອງຂອງວຽກອື່ນຫຼຸດລົງໂດຍທີ່ບໍ່ຮູ້ຕົວ
• ບໍ່ສາມາດປຽບທຽບຜົນການທົດສອບ A/B ໄດ້: ບໍ່ສາມາດຕັດສິນດ້ວຍຕົວເລກໄດ້ນອກເໜືອໄປຈາກຄວາມຮູ້ສຶກທີ່ວ່າ "ເວີຊັນໃໝ່ເບິ່ງຄືວ່າດີກວ່າ"
• ການຕົກຫຼົ່ນຂອງກໍລະນີພິເສດທີ່ຫາຍາກ (Rare edge cases): 99% ຂອງການຕອບໂຕ້ບໍ່ມີບັນຫາ ແຕ່ເກີດຂໍ້ຜິດພາດຮ້າຍແຮງໃນ 1% ທີ່ເຫຼືອ
• ການປ່ຽນແປງ (Drift) ຈາກປັດໄຈພາຍນອກ: ບໍ່ສາມາດກວດຈັບໄດ້ເມື່ອພຶດຕິກຳປ່ຽນໄປເນື່ອງຈາກການອັບເດດ Model ຈາກຝັ່ງ Vendor

LLM-as-a-Judge ໃຫ້ທາງອອກສຳລັບບັນຫາເຫຼົ່ານີ້ດ້ວຍ "ຄະແນນປະລິມານ × ຕົວຢ່າງຈຳນວນຫຼາຍ × ການຕິດຕາມຢ່າງຕໍ່ເນື່ອງ". ຖ້ານຳເອົາ Judge ໄປລວມ ຫຼື Merge ເຂົ້າໃນ CI/CD, ການທົດສອບການຖົດຖອຍຈະເຮັດວຽກໂດຍອັດຕະໂນມັດທຸກຄັ້ງທີ່ມີການປ່ຽນແປງ Prompt ແລະສາມາດກວດຈັບບັນຫາກ່ອນນຳໄປໃຊ້ງານຈິງໄດ້. ຖ້າເພີ່ມການປະເມີນຜົນຈາກການສຸ່ມຕົວຢ່າງບັນທຶກການໃຊ້ງານ (Operation logs), ກໍຈະສາມາດກວດຈັບການປ່ຽນແປງ (Drift) ຫຼັງຈາກເປີດໃຊ້ງານຈິງໄດ້ຢ່າງວ່ອງໄວ.

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

• AI Observability: ເກັບກຳຂໍ້ມູນຂາເຂົ້າ-ຂາອອກ, ຄວາມໜ່ວງ (Latency), ຕົ້ນທຶນ ແລະ ອັດຕາຄວາມຜິດພາດຂອງ LLM ເພື່ອຮັບປະກັນຄວາມສາມາດໃນການສັງເກດການ (ລາຍລະອຽດເພີ່ມເຕີມສາມາດອ່ານໄດ້ທີ່ AI オブザーバビリティとは？)
• AI Guardrails: ຮົ້ວປ້ອງກັນເພື່ອຕວດສອບຂໍ້ມູນຂາເຂົ້າ-ຂາອອກໃນຂະນະປະມວນຜົນ (ໃນລະຫວ່າງການປະມວນຜົນຄຳຮ້ອງຂໍ) ເພື່ອສະກັດກັ້ນ ຫຼື ປັບປ່ຽນຄຳຕອບທີ່ເປັນອັນຕະລາຍ (ລາຍລະອຽດເພີ່ມເຕີມສາມາດອ່ານໄດ້ທີ່ AI Guardrails 実装ガイド)
• LLM-as-a-Judge: ໃຊ້ໃນການໃຫ້ຄະແນນ "ຄຸນນະພາບ" ຂອງຄຳຕອບແບບຍ້ອນຫຼັງ ຫຼື ແບບ Real-time ເພື່ອໃຊ້ໃນການວິເຄາະແນວໂນ້ມ ແລະ ກວດຫາການຖົດຖອຍຂອງປະສິດທິພາບ

Observability ແມ່ນການວັດແທກ, Guardrails ແມ່ນການສະກັດກັ້ນ, ແລະ Judge ແມ່ນການໃຫ້ຄະແນນ. ທັງ 3 ຢ່າງນີ້ບໍ່ໄດ້ແຂ່ງຂັນກັນ, ແຕ່ເປັນ Stack ທີ່ເໝາະສົມທີ່ສຸດຄື: ການໃຊ້ Observability ເພື່ອເກັບ Log, ໃຊ້ Guardrails ເພື່ອຢຸດຄວາມສ່ຽງ, ແລະ ໃຊ້ Judge ເພື່ອປະເມີນຜົນຢ່າງຕໍ່ເນື່ອງ. ສຳລັບການກວດສອບຄວາມທົນທານຕໍ່ການໂຈມຕີ, AI レッドチーミング ຈະເຮັດໜ້າທີ່ເສີມ. ຖ້າຫາກມີຄົບທັງ 4 ຊັ້ນນີ້ ກໍຈະໄດ້ໂຄງສ້າງທີ່ຕອບໂຈດຄວາມຕ້ອງການພື້ນຖານດ້ານຄຸນນະພາບ, ຄວາມປອດໄພ ແລະ ຄວາມສາມາດໃນການສັງເກດການທີ່ຈຳເປັນສຳລັບການນຳໃຊ້ງານຈິງ.

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

3 ໂປຣໂຕຄອນຫຼັກມີລັກສະນະເດັ່ນແຕກຕ່າງກັນດັ່ງນີ້:

ການຄົ້ນຄວ້າຫຼ້າສຸດລາຍງານວ່າ ການປະເມີນແບບ Pairwise ມີອັດຕາການປີ້ນກັບຂອງຜົນການຕັດສິນປະມານ 35% ແລະຄະແນນສົມບູນຂອງ Pointwise ຢູ່ທີ່ປະມານ 9% ເຊິ່ງເປັນການຢືນຢັນທາງປະລິມານເຖິງ ການແລກປ່ຽນ ຫຼື Trade-off ທີ່ວ່າ "Pairwise ສາມາດກວດຈັບຄວາມແຕກຕ່າງທີ່ລະອຽດອ່ອນໄດ້ແຕ່ບໍ່ໝັ້ນຄົງ, ສ່ວນ Pointwise ມີຄວາມໝັ້ນຄົງແຕ່ຄວາມລະອຽດຕ່ຳ".

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

ປະສິດທິພາບຂອງ Judge ແມ່ນຂຶ້ນກັບ Prompt ແລະ Rubric ເປັນຫຼັກ. ອົງປະກອບທີ່ຄວນມີຢ່າງໜ້ອຍມີດັ່ງນີ້:

• ການກຳນົດມຸມມອງການປະເມີນ: ຕົວຢ່າງ — 4 ແກນຫຼັກ ຄື ຄວາມຖືກຕ້ອງ, ຄວາມກ່ຽວຂ້ອງ, ຄວາມກະທັດຮັດ, ແລະ ຄວາມເປັນອັນຕະລາຍ. ຖ້າມີມຸມມອງຫຼາຍເກີນໄປຈະເຮັດໃຫ້ການຕັດສິນຂອງ Judge ຊ້າລົງ, ສະນັ້ນ 3-5 ແກນແມ່ນມີປະໂຫຍດໃນການນຳໃຊ້ຕົວຈິງ.
• ສະເກລຄະແນນ ແລະ ເກນການຕັດສິນ: ລະບຸຢ່າງລະອຽດວ່າແຕ່ລະຄະແນນໝາຍເຖິງຫຍັງ (ຕົວຢ່າງ: 5 ຄະແນນ = ສົມບູນແບບ, 3 ຄະແນນ = ຖືກຕ້ອງບາງສ່ວນ, 1 ຄະແນນ = ຄຳຕອບຜິດ) ພ້ອມຕົວຢ່າງປະກອບ.
• ຕົວຢ່າງ Few-shot: ເພື່ອບໍ່ໃຫ້ການກະຈາຍຂອງຄະແນນເໜັງຕີງ, ໃຫ້ສະເໜີຕົວຢ່າງທີ່ເປັນຕົວແທນຂອງແຕ່ລະຄະແນນປະມານ 2-3 ຕົວຢ່າງ.
• ການລະບຸຄວາມກະທັດຮັດ: ຖ້າບໍ່ຂຽນວ່າ "ຈະຫັກຄະແນນຖ້າຄຳຕອບຍາວເກີນຄວາມຈຳເປັນ", Judge ມັກຈະມັກຄຳຕອບທີ່ເຍີ່ນຍໍ້.
• ຮູບແບບຜົນລັອກ (Output format): ໃຫ້ສົ່ງຄ່າເປັນ JSON ໃນຮູບແບບ {score, reasoning, evidence} ເພື່ອໃຫ້ສາມາດນຳໄປປະມວນຜົນ (Parse) ໄດ້.

Rubric ຄື "ເອກະສານສະເພາະດ້ານພາສາທຳມະຊາດ" (Natural Language Specification), ຄວນມີການບໍລິຫານຈັດການເວີຊັນ ແລະ ເກັບບັນທຶກປະຫວັດການປ່ຽນແປງໄວ້. ເນື່ອງຈາກການປ່ຽນ Prompt ຈະເຮັດໃຫ້ພຶດຕິກຳຂອງ Judge ປ່ຽນໄປ, ເມື່ອມີການອັບເດດ Rubric ຕ້ອງດຳເນີນການວັດແທກຄວາມສຳພັນກັບການປະເມີນໂດຍມະນຸດຄືນໃໝ່ສະເໝີ. ຖ້າຂ້າມຂັ້ນຕອນນີ້ໄປ, ຄະແນນຂອງ Judge ກໍຈະເປັນພຽງຕົວເລກທີ່ປາດສະຈາກຄວາມໝາຍ.

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

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

• ການສຸ່ມລຳດັບ: ປະເມີນຄູ່ດຽວກັນທັງໃນລຳດັບ A-B ແລະ B-A, ຈາກນັ້ນນຳມາຫາຄ່າສະເລ່ຍ.
• ການກວດສອບຄວາມສອດຄ່ອງ: ຖືເອົາຄະແນນຢ່າງເປັນທາງການກໍຕໍ່ເມື່ອການຕັດສິນໃນທັງສອງລຳດັບກົງກັນ, ຫາກບໍ່ກົງກັນໃຫ້ສົ່ງຂໍ້ມູນຕໍ່ໃຫ້ການກວດສອບໂດຍມະນຸດ (Human Review).

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

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

ມາດຕະການແກ້ໄຂຄື ການປະເມີນຜົນແບບຂ້າມໂມເດວ (Cross-model evaluation) ໂດຍໃຊ້ຕະກູນໂມເດວທີ່ແຕກຕ່າງກັນລະຫວ່າງໂມເດວທີ່ສ້າງຄຳຕອບ ແລະ ໂມເດວທີ່ເປັນຜູ້ຕັດສິນ (Judge).

• ໂມເດວທີ່ສ້າງຄຳຕອບ: ຕະກູນ Claude
• ໂມເດວທີ່ເປັນຜູ້ຕັດສິນ (Judge): ຕະກູນ GPT ຫຼື ຕະກູນ Gemini
• ວຽກງານທີ່ສຳຄັນ: ໃຊ້ການລົງຄະແນນສຽງສ່ວນຫຼາຍຈາກຜູ້ຕັດສິນຫຼາຍຝ່າຍ ຫຼື ໃຊ້ຄະແນນແບບ Ensemble

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

ປະກົດການທີ່ຄະແນນມີການເໜັງຕີງເມື່ອສົ່ງ Input ດຽວກັນເຂົ້າໄປໃນ Judge ຫຼາຍຄັ້ງແມ່ນເປັນສິ່ງທີ່ພົບເຫັນໄດ້ທົ່ວໄປ. ເນື່ອງຈາກການຕັ້ງຄ່າ temperature=0 ກໍບໍ່ສາມາດຮັບປະກັນຄວາມສາມາດໃນການເຮັດຊ້ຳ (Reproducibility) ໄດ້ຢ່າງສົມບູນ, ຈຶ່ງຕ້ອງອອກແບບໂດຍອີງໃສ່ເງື່ອນໄຂດັ່ງຕໍ່ໄປນີ້:

• ການສຸ່ມຕົວຢ່າງຫຼາຍຄັ້ງເພື່ອຫາຄ່າສະເລ່ຍ: ໃນວຽກງານທີ່ສຳຄັນ ໃຫ້ປະເມີນ 3-5 ຄັ້ງແລ້ວເອົາມາຫາຄ່າສະເລ່ຍເພື່ອເປັນຄະແນນ.
• ການຕິດຕາມການກະຈາຍຂອງຄະແນນ: ກວດສອບການຂະຫຍາຍຕົວຂອງຄ່າຄວາມຜັນຜວນ (Variance) ເພື່ອເປັນການແຈ້ງເຕືອນ.
• ການກຳນົດເວີຊັນໃຫ້ຄົງທີ່: ລະບຸ Model Identifier ທີ່ໃຊ້ໃນ Judge ໃຫ້ຊັດເຈນ ແລະ ເມື່ອມີການອັບເດດ ຕ້ອງມີການກວດສອບຄວາມສຳພັນກັບຂໍ້ມູນເກົ່າຄືນໃໝ່.
• ການອອກແບບສະເກວ: ການໃຊ້ສະເກວ 1-10 ຈະມີຄວາມລະອຽດສູງກວ່າສະເກວ 1-5 ແຕ່ກໍມີແນວໂນ້ມທີ່ Judge ຈະໃຫ້ຄະແນນໄປໃນທາງ ຈຸດສຳຄັນ ຫຼື ແກນຫຼັກ (ຄ່າກາງ) ຫຼາຍຂຶ້ນ. ຄວນເລືອກໃຊ້ລະຫວ່າງສະເກວແບບ 2 ຄ່າ (ຜ່ານ / ບໍ່ຜ່ານ) ກັບສະເກວທີ່ມີຄວາມລະອຽດສູງຕາມຄວາມເໝາະສົມຂອງວຽກງານ.

ຄະແນນຂອງ Judge ມີຄວາມໝາຍໃນແງ່ຂອງ "ການປ່ຽນແປງຕາມໄລຍະເວລາ" ຫຼາຍກວ່າຄ່າຕົວເລກທີ່ແນ່ນອນ. ການກຳນົດ Baseline ໃຫ້ຄົງທີ່ ແລະ ຕິດຕາມການປ່ຽນແປງແບບສຳພັດ (Relative change) ຄືຫົວໃຈສຳຄັນຂອງການດຳເນີນງານ. ຄວນອອກແບບ Dashboard ເພື່ອຕິດຕາມທັງຄ່າຄວາມຜັນຜວນ (Variance) ແລະ ການເໜັງຕີງ (Drift) ໄປພ້ອມກັນ.

Judge LLM ຕົວມັນເອງອາດເກີດອາການຮາລູຊິເນຊັນ (Hallucination), ເຊັ່ນ: ການຫັກຄະແນນດ້ວຍເຫດຜົນທີ່ບໍ່ມີຢູ່ຈິງ ຫຼື ການໃຫ້ຄະແນນສູງໂດຍອີງໃສ່ຂໍ້ມູນທີ່ບໍ່ມີໃນເອກະສານອ້າງອີງ. ການໃຫ້ LLM ສະແດງຜົນ reasoning (ເຫດຜົນໃນການຕັດສິນ) ແລະ evidence (ສ່ວນທີ່ອ້າງອີງ) ອອກມາເປັນຮູບແບບ JSON ພ້ອມກັບການໃຫ້ຄະແນນ, ແລ້ວປະຕິບັດການກວດສອບຫຼັງຈາກນັ້ນ (Post-check) ຈະຊ່ວຍເພີ່ມຄວາມຖືກຕ້ອງໃນການກວດຈັບໄດ້:

• reasoning ມີການອ້າງອີງສ່ວນທີ່ກ່ຽວຂ້ອງຢ່າງຈະແຈ້ງຫຼືບໍ່
• ຄວາມສອດຄ່ອງລະຫວ່າງ reasoning ແລະ score (ບໍ່ມີກໍລະນີທີ່ໃຫ້ຄະແນນສູງແຕ່ໃຫ້ເຫດຜົນໃນທາງລົບ ຫຼື ບໍ່)
• ບໍ່ມີການໂຕ້ແຍ້ງທີ່ຂັດກັບຄຳຕອບອ້າງອີງ
• ບໍ່ມີການນຳເອົາປັດໄຈທີ່ບໍ່ມີຢູ່ຈິງໃນສິ່ງທີ່ຖືກປະເມີນມາເປັນເຫດຜົນ

ເນື່ອງຈາກ Judge ກໍເປັນ LLM ເຊັ່ນກັນ, ຈຶ່ງບໍ່ສາມາດເຊື່ອຖືໄດ້ຢ່າງສົມບູນ. ການນຳໃຊ້ກົນໄກການສຸ່ມກວດສອບ reasoning ໂດຍມະນຸດຢ່າງສະໝໍ່າສະເໝີຄວບຄູ່ກັນໄປ ຈະຊ່ວຍໃຫ້ສາມາດກວດຈັບການເໜັງຕີງ (Drift) ຫຼື ຂໍ້ຜິດພາດຂອງຕົວ Judge ເອງໄດ້ຢ່າງວ່ອງໄວ.

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

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

• ການແບ່ງຊັ້ນ (Layering): ເຮັດການສຸ່ມຕົວຢ່າງໂດຍແບ່ງອອກເປັນ 3 ຊັ້ນ ຄື: "ກໍລະນີທົ່ວໄປ", "ກໍລະນີຂອບເຂດ (Boundary cases)", ແລະ "ກໍລະນີທີ່ເຄີຍຜິດພາດມາກ່ອນ".
• ການໃຫ້ Gold Label: ຢ່າງໜ້ອຍ 20-30 ລາຍການ ຕ້ອງໄດ້ຮັບການຕິດປ້າຍກຳກັບຄຳຕອບທີ່ຖືກຕ້ອງ ຫຼື ຄຳຕອບທີ່ເໝາະສົມດ້ວຍຕົນເອງ.
• ການຈັດການເວີຊັນ (Version control): ຊຸດຂໍ້ມູນຄວນຖືກຈັດການເວີຊັນດ້ວຍ Git ຫຼື ເຄື່ອງມືອື່ນໆ ເພື່ອໃຫ້ສາມາດກວດສອບຄວາມແຕກຕ່າງໄດ້.
• ການປິດບັງຂໍ້ມູນ (Anonymization): ຖ້າຫາກມີຂໍ້ມູນສ່ວນບຸກຄົນລວມຢູ່, ຕ້ອງເຮັດການປິດບັງຂໍ້ມູນກ່ອນນຳເຂົ້າສູ່ລະບົບການປະເມີນຜົນສະເໝີ.

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

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

• ໃຫ້ຄະແນນຕົວຢ່າງປະມານ 30-50 ລາຍການ ໂດຍໃຊ້ທັງ Judge ແລະ ຄົນ
• ວັດແທກຄວາມສອດຄ່ອງດ້ວຍ Pearson correlation coefficient ຫຼື Cohen's κ ໂດຍໃຫ້ 0.6 ຂຶ້ນໄປເປັນມາດຕະຖານເບື້ອງຕົ້ນ
• ຊອກຫາກໍລະນີຕົວຢ່າງທີ່ບໍ່ກົງກັນ ແລະ ເພີ່ມຕົວຢ່າງ Few-shot ເຂົ້າໃນ Rubric
• ແບ່ງຍ່ອຍມຸມມອງການປະເມີນຖ້າຈຳເປັນ (ເຊັ່ນ: ແບ່ງ "ຄວາມຖືກຕ້ອງ" ອອກເປັນ "ຄວາມເປັນຈິງ" ແລະ "ຄວາມສອດຄ່ອງທາງເຫດຜົນ")

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

Judge ທີ່ຜ່ານການກວດສອບແລ້ວຈະເຊື່ອມຕໍ່ກັບທັງຂະບວນການ ຫຼື Pipeline ການພັດທະນາ ແລະ ການດຳເນີນງານ.

• ການປະເມີນຜົນ Regression ໃນ CI/CD: ເມື່ອມີການປ່ຽນແປງ Prompt ຫຼື ອັບເດດ Model, ໃຫ້ໃຊ້ Judge ປະເມີນຜົນກັບຊຸດຂໍ້ມູນການປະເມີນທັງໝົດເພື່ອຊອກຫາຄະແນນທີ່ຫຼຸດລົງ. ສໍາລັບແນວຄິດການອອກແບບ Harness ການປະເມີນຜົນ, ສາມາດອ້າງອີງໄດ້ຈາກ Harness Engineering
• ການປະເມີນຜົນແບບຕໍ່ເນື່ອງໃນ Batch Inference: ໃຫ້ Judge ປະເມີນຜົນຄຳຕອບທີ່ສຸ່ມມາຈາກ Log ການໃຊ້ງານຈິງໃນຊ່ວງ Batch ຕອນກາງຄືນ
• ຂີດຈຳກັດການແຈ້ງເຕືອນ (Alert Threshold): ແຈ້ງເຕືອນຜ່ານ Slack ຫຼື ຊ່ອງທາງອື່ນໆ ເມື່ອຄະແນນສະເລ່ຍຫຼຸດລົງຕໍ່າກວ່າເກນທີ່ກຳນົດໄວ້ X%
• ປະຕູການຕັດສິນໃຈປ່ອຍ Release: ການປ່ຽນແປງໃດທີ່ເຮັດໃຫ້ຄະແນນຂອງຕົວຊີ້ວັດສຳຄັນຫຼຸດຕໍ່າກວ່າເກນ ຈະບໍ່ສາມາດ ລວມ ຫຼື Merge ໄດ້ໂດຍອັດຕະໂນມັດ

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

Judge ແມ່ນບໍ່ໄດ້ສິ້ນສຸດພຽງແຕ່ການນຳໃຊ້ເທົ່ານັ້ນ, ແຕ່ຍັງຈຳເປັນຕ້ອງມີການດຳເນີນງານຢ່າງຕໍ່ເນື່ອງດັ່ງຕໍ່ໄປນີ້:

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

ຂະບວນການ ຫຼື Pipeline ຂອງ Judge ຍັງສາມາດນຳໃຊ້ເພື່ອການປະເມີນຄືນໃໝ່ຫຼັງຈາກການ Fine-tune ໄດ້ອີກດ້ວຍ. ຖ້າສົມທົບລາຍລະອຽດຂອງວິທີການກັບ ການແນະນຳການ Fine-tuning ດ້ວຍ PEFT, ຂັ້ນຕອນຕັ້ງແຕ່ການ Fine-tune ໄປຈົນເຖິງການກວດສອບການຖົດຖອຍ (Regression) ໂດຍ Judge ຈະເຊື່ອມຕໍ່ກັນເປັນວົງຈອນການຮັບປະກັນຄຸນນະພາບທີ່ສອດຄ່ອງ.

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

ອອບລາຍ (Offline) ແມ່ນວິທີການປະເມີນຜົນດ້ວຍຊຸດຂໍ້ມູນລ່ວງໜ້າ, ສ່ວນອອນລາຍ (Online) ແມ່ນວິທີການປະເມີນຜົນການຕອບໂຕ້ຂອງຜູ້ໃຊ້ງານຈິງໃນແບບ Real-time.

• ການປະເມີນຜົນແບບອອບລາຍ (Offline Evaluation)
  • ຊ່ວງເວລາປະຕິບັດງານ: CI/CD, ການກວດສອບກ່ອນການເປີດຕົວ ຫຼື Launch, ການທົດສອບການກັບມາໃຊ້ງານ (Regression) ປະຈຳອາທິດ
  • ຄຸນລັກສະນະ: ມີຄວາມສາມາດໃນການເຮັດຊ້ຳໄດ້ດ້ວຍຊຸດຂໍ້ມູນທີ່ຄົງທີ່, ສາມາດຄາດຄະເນຕົ້ນທຶນໄດ້, ແລະຍັງໃຊ້ສຳລັບການກວດສອບຄວາມສຳພັນກັບການປະເມີນໂດຍມະນຸດ
  • ວຽກທີ່ເໝາະສົມ: ການປັບປຸງ Prompt ໃຫ້ດີທີ່ສຸດ, ການຕັດສິນໃຈປ່ຽນແທນ Model, ການປຽບທຽບລະຫວ່າງເວີຊັນ
• ການປະເມີນຜົນແບບອອນລາຍ (Online Evaluation)
  • ຊ່ວງເວລາປະຕິບັດງານ: ການສຸ່ມຕົວຢ່າງບັນທຶກການໃຊ້ງານຈິງ (1–5%) ເພື່ອປະເມີນໃນແບບ Real-time
  • ຄຸນລັກສະນະ: ສາມາດກວດພົບການແຈກຢາຍຂໍ້ມູນທີ່ບໍ່ຮູ້ມາກ່ອນເຊິ່ງຂຶ້ນກັບການຈະລາຈອນຕົວຈິງ, ແຕ່ການຄວບຄຸມຕົ້ນທຶນແມ່ນມີຄວາມສຳຄັນ
  • ວຽກທີ່ເໝາະສົມ: ການແຈ້ງເຕືອນຄຸນນະພາບຫຼຸດລົງ, ການກວດສອບ Drift, ການຄົ້ນພົບບັນຫາກ່ອນຜູ້ໃຊ້ງານຈະລາຍງານ

ໂຄງສ້າງທົ່ວໄປແມ່ນການແບ່ງເປັນສອງຊັ້ນຄື: "ປ້ອງກັນການຖົດຖອຍດ້ວຍອອບລາຍ, ກວດສອບ Drift ດ້ວຍອອນລາຍ". ເນື່ອງຈາກຕົ້ນທຶນຂອງຝັ່ງ Judge ກໍບໍ່ສາມາດລະເລີຍໄດ້, ໃຫ້ປະຍຸກໃຊ້ແນວຄິດຈາກ ຄູ່ມືການປັບປຸງຕົ້ນທຶນ LLM (ອັດຕາການສຸ່ມ, ການເລືອກ Model, Prompt Cache) ມາໃຊ້ກັບຝັ່ງການປະເມີນຜົນນຳ.

ຂໍ້ມູນທີ່ຂະບວນການ ຫຼື Pipeline ການປະເມີນຜົນຈັດການນັ້ນມັກຈະມີຂໍ້ມູນສ່ວນບຸກຄົນລວມຢູ່ດ້ວຍ, ສະນັ້ນຢ່າລືມການເຮັດໃຫ້ຂໍ້ມູນເປັນນິລະນາມ (Anonymization) ແລະການຄວບຄຸມການເຂົ້າເຖິງ. ຂໍ້ຄວນລະວັງໃນການດຳເນີນງານໃນປະເທດໄທໄດ້ສະຫຼຸບໄວ້ໃນ ລາຍການກວດສອບການປະຕິບັດຕາມ PDPA ຂອງໄທສຳລັບ AI. ສ່ວນການກວດສອບການປ້ອນຂໍ້ມູນ ແລະຜົນລວມຂອງ Prompt ໃນມຸມມອງຄວາມປອດໄພ, ຂໍໃຫ້ອ່ານຄູ່ມືນີ້ຄວບຄູ່ໄປກັບ ຄູ່ມືການຈັດຕັ້ງປະຕິບັດຄວາມປອດໄພ LLM (OWASP × TypeScript).

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

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

ບໍ່ແນະນຳ. ແບບຈຳລອງດຽວກັນມີຄວາມລຳອຽງໃນການເລືອກຕົນເອງ (Self-preference bias) ໂດຍການໃຫ້ຄະແນນຜົນລວມຂອງຕົນເອງສູງ ເຊິ່ງເຮັດໃຫ້ຄວາມເປັນອິດສະຫຼະໃນການປະເມີນຜົນເສຍຫາຍ. ຄວນໃຊ້ແບບຈຳລອງທີ່ຕ່າງກັນລະຫວ່າງການສ້າງ (Generation) ແລະ ການຕັດສິນ (Judge), ແລະ ສຳລັບວຽກງານທີ່ສຳຄັນ ຄວນພິຈາລະນາໃຊ້ການປະສົມປະສານ (Ensemble) ຂອງຫຼາຍ Judge. ການໃຊ້ໂຄງສ້າງແບບຂ້າມແບບຈຳລອງ (Cross-model) ຍັງມີຂໍ້ດີຄື ການຫຼຸດຜ່ອນຜົນກະທົບຈາກການປ່ຽນແປງ ມາດຕະຖານ ຫຼື Specification ຫຼື ການຫຼຸດລົງຂອງຄຸນນະພາບຈາກຜູ້ໃຫ້ບໍລິການດຽວໃນຝ່າຍປະເມີນຜົນອີກດ້ວຍ.

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

ເຖິງວ່າຈະມີການປ່ຽນແປງຫຼາຍຕາມຄວາມຖີ່ຂອງການປະເມີນຜົນ ແລະ ປະລິມານຂອງຂໍ້ມູນ, ແຕ່ຖ້າຫາກໃຊ້ການຕັ້ງຄ່າແບບສຸ່ມຕົວຢ່າງ (Sampling) 1-5% ຂອງທຣາຟິກໃນການໃຊ້ງານຈິງ, ໂດຍສ່ວນຫຼາຍແລ້ວຄ່າໃຊ້ຈ່າຍຈະຢູ່ທີ່ປະມານ 5-15% ຂອງຄ່າໃຊ້ຈ່າຍ LLM ຫຼັກຂອງແອັບພລິເຄຊັນ. ທ່ານສາມາດຫຼຸດຕົ້ນທຶນລົງໄດ້ຕື່ມອີກໂດຍການໃຊ້ວິທີຕ່າງໆ ເຊັ່ນ: ການໃຊ້ໂມເດວຂະໜາດນ້ອຍ (Lightweight model) ເປັນ Judge, ການນຳໃຊ້ Prompt caching, ການໃຫ້ຄວາມສຳຄັນກັບ Pointwise ຫຼາຍກວ່າ Pairwise, ຫຼື ການເພີ່ມອັດຕາການປະເມີນຜົນສະເພາະຈຸດສຳຄັນ ຫຼື ແກນຫຼັກ ຂອງ Endpoint ເທົ່ານັ້ນ. ສຳລັບລາຍລະອຽດກ່ຽວກັບການບໍລິຫານຈັດການງົບປະມານ, ກະລຸນາເບິ່ງທີ່ຄູ່ມືການເພີ່ມປະສິດທິພາບຄ່າໃຊ້ຈ່າຍ LLM.

ການແບ່ງໜ້າທີ່ຮັບຜິດຊອບຈະຊ່ວຍຫຼີກລ່ຽງການລົງທຶນຊໍ້າຊ້ອນ. Observability ຮັບຜິດຊອບໃນດ້ານ "ການເກັບກຳບັນທຶກຂໍ້ມູນ ແລະ ການສະແດງຜົນ", Guardrails ຮັບຜິດຊອບ "ການສະກັດກັ້ນໃນຂະນະປະຕິບັດງານ", ແລະ LLM-as-a-Judge ຮັບຜິດຊອບ "ການໃຫ້ຄະແນນຄຸນນະພາບຢ່າງຕໍ່ເນື່ອງ". ລະບົບການດຳເນີນງານທີ່ເໝາະສົມທີ່ສຸດຄືການເຊື່ອມຕໍ່ທັງ 3 ສ່ວນເຂົ້າກັບໂຄງສ້າງພື້ນຖານ ຫຼື Infrastructure ດຽວກັນ ເພື່ອໃຫ້ສາມາດເບິ່ງຈຳນວນການບລັອກຂອງ Guardrails, ທິດທາງຄະແນນຂອງ Judge, ແລະ ຄ່າ Latency ຂອງ Observability ໄດ້ໃນໜ້າຈໍດຽວ. ເນື່ອງຈາກຄວາມຜິດປົກກະຕິຂອງແຕ່ລະຊັ້ນມັກຈະເກີດຂຶ້ນຢ່າງສຳພັນກັນ, ການເຮັດ Dashboard ແບບລວມສູນຈຶ່ງຊ່ວຍເພີ່ມຄວາມໄວໃນການກວດສອບບັນຫາເບື້ອງຕົ້ນໄດ້.

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

Judge ບໍ່ສາມາດເຮັດວຽກໄດ້ຢ່າງສົມບູນໂດຍລຳພັງ. ທ່ານສາມາດເສີມຄວາມແຂງແກ່ນໃຫ້ກັບ AI Operation Stack ທັງໝົດໄດ້ໂດຍການນຳໃຊ້ຮ່ວມກັບບົດຄວາມທີ່ກ່ຽວຂ້ອງດັ່ງລຸ່ມນີ້:

• AI Observability ແມ່ນຫຍັງ? ກົນໄກການຕິດຕາມ LLM ໃນການນຳໃຊ້ງານຈິງ — ການອອກແບບ Log Infrastructure ຫຼື Infrastructure ແລະ ຄວາມສາມາດໃນການສັງເກດການ (Observability)
• ຄູ່ມືການນຳໃຊ້ AI Guardrails — ການອອກແບບຮົ້ວປ້ອງກັນຄວາມປອດໄພໃນຂະນະປະຕິບັດງານ (ກຳລັງກຽມເປີດຕົວ ຫຼື Launch)
• AI Red Teaming ແມ່ນຫຍັງ? — ການກວດສອບຄວາມທົນທານຕໍ່ການໂຈມຕີ
• ຄູ່ມືການປັບຕົ້ນທຶນ LLM ໃຫ້ເໝາະສົມ — ສາມາດນຳໄປປະຍຸກໃຊ້ເພື່ອຫຼຸດຕົ້ນທຶນຝັ່ງ Judge ໄດ້
• Harness Engineering — ແນວຄິດການລວມ ຫຼື Merge ການປະເມີນເຂົ້າໃນ CI/CD
• ແນະນຳການ Fine-tuning ດ້ວຍ PEFT — Judge loop ຫຼັງຈາກການ Fine-tune
• ຄູ່ມືການນຳໃຊ້ຄວາມປອດໄພ LLM (OWASP × TypeScript) — ການນຳໃຊ້ຮ່ວມກັບການກວດສອບ Input/Output
• ລາຍການກວດສອບການປະຕິບັດຕາມ PDPA ຂອງໄທ — ຂໍ້ກຳນົດດ້ານການປິດບັງຕົວຕົນຂອງຂໍ້ມູນທີ່ໃຊ້ປະເມີນ

ທາງບໍລິສັດຂອງພວກເຮົາໄດ້ສ້າງຂະບວນການ ຫຼື Pipeline ແບບ LLM-as-a-Judge ໃຫ້ກັບລູກຄ້າຫຼາຍລາຍ ແລະ ໄດ້ສະສົມຄວາມຮູ້ໃນດ້ານການອອກແບບຊຸດຂໍ້ມູນປະເມີນ, ການກຳນົດ Rubric, ແລະ ການກວດສອບຄວາມສຳພັນກັບການປະເມີນໂດຍມະນຸດ. ສຳລັບທີມງານທີ່ຕ້ອງການຍົກລະດັບລະບົບຮັບປະກັນຄຸນນະພາບໄປສູ່ອີກຂັ້ນໜຶ່ງ, ຂໍໃຫ້ອ້າງອີງບົດຄວາມທີ່ກ່ຽວຂ້ອງຂ້າງເທິງນີ້ຄວບຄູ່ກັນໄປ.