ຄູ່ມືການປະຕິບັດງານອັດຕະໂນມັດໃນການປະເມີນຜົນ RAG ດ້ວຍ LLM-as-a-Judge
LLM-as-a-Judge ແມ່ນຫຍັງ?
LLM-as-a-Judge ແມ່ນຫຍັງ? ຄວາມແຕກຕ່າງຈາກການປະເມີນ RAG ແບບດັ້ງເດີມ
ຄຸນນະພາບຂອງລະບົບ RAG ຖືກຕັດສິນດ້ວຍ 2 ແກນຫຼັກ ຄື: ການຄົ້ນຫາສາມາດດຶງເອກະສານທີ່ເໝາະສົມມາໄດ້ຫຼືບໍ່ ແລະ ຄຳຕອບທີ່ສ້າງຂຶ້ນນັ້ນມີຄວາມຊື່ສັດຕໍ່ບໍລິບົດດັ່ງກ່າວພຽງໃດ. LLM-as-a-Judge ແມ່ນວິທີການທີ່ມອບໝາຍການຕັດສິນຄຸນນະພາບນີ້ໃຫ້ກັບແບບຈຳລອງພາສາຂະໜາດໃຫຍ່ (Large Language Model) ໂດຍກົງ. ກ່ອນອື່ນໝົດ, ພວກເຮົາຈະມາສະຫຼຸບຂໍ້ຈຳກັດຂອງວິທີການປະເມີນຜົນແບບດັ້ງເດີມ ແລະ ເຫດຜົນທີ່ແນວຄວາມຄິດໃນການນຳໃຊ້ LLM ມາເປັນຜູ້ຕັດສິນໄດ້ກຳເນີດຂຶ້ນ.
ຂໍ້ຈຳກັດຂອງການປະເມີນໂດຍມະນຸດ ແລະ ການປະເມີນແບບໃຊ້ກົດເກນ
ວິທີການແບບດັ້ງເດີມໃນການວັດແທກຄຸນນະພາບຄຳຕອບຂອງ RAG ສາມາດແບ່ງອອກເປັນ 2 ປະເພດໃຫຍ່ໆ ຄື: ການປະເມີນໂດຍມະນຸດ ແລະ ການປະເມີນໂດຍອີງໃສ່ກົດເກນ (Rule-based). ເຊິ່ງທັງສອງວິທີນີ້ຈະປະສົບກັບທາງຕັນເມື່ອ RAG ຖືກນຳໄປໃຊ້ໃນລະດັບການຜະລິດຈິງ (Production scale).
ການປະເມີນໂດຍມະນຸດ ແມ່ນວິທີທີ່ໃຫ້ຄົນອ່ານຄຳຕອບແລ້ວໃຫ້ຄະແນນຄວາມຖືກຕ້ອງ ແລະ ຄວາມເປັນປະໂຫຍດ. ເຖິງວ່າຄຸນນະພາບຂອງການຕັດສິນໃຈຈະສູງ, ແຕ່ເມື່ອຈຳນວນຂໍ້ມູນທີ່ຕ້ອງປະເມີນເພີ່ມຂຶ້ນເຖິງຫຼາຍຮ້ອຍ ຫຼື ຫຼາຍພັນລາຍການ, ເວລາ ແລະ ຄ່າໃຊ້ຈ່າຍກໍຈະເພີ່ມທະວີຂຶ້ນເລື້ອຍໆ, ອີກທັງມາດຕະຖານຍັງມີຄວາມແຕກຕ່າງກັນໄປຕາມຜູ້ປະເມີນແຕ່ລະຄົນ. ການກັບມາໃຫ້ຄະແນນໃໝ່ທັງໝົດໃນທຸກຄັ້ງທີ່ມີການເປີດຕົວ ຫຼື Launch ຈຶ່ງບໍ່ແມ່ນວິທີທີ່ເປັນໄປໄດ້ໃນຄວາມເປັນຈິງ.
ການປະເມີນໂດຍອີງໃສ່ກົດເກນ ແມ່ນວິທີການວັດແທກຄວາມສອດຄ່ອງທາງດ້ານຮູບແບບກັບປະໂຫຍກທີ່ຖືກຕ້ອງໂດຍອັດຕະໂນມັດ ເຊັ່ນ: BLEU ຫຼື ROUGE. ເຖິງວ່າຈະມີຄວາມໄວ ແລະ ສາມາດເຮັດຊ້ຳໄດ້, ແຕ່ມັນມັກຈະໃຫ້ຄະແນນຕ່ຳແກ່ຄຳຕອບທີ່ມີຄວາມໝາຍຖືກຕ້ອງແຕ່ໃຊ້ສຳນວນທີ່ແຕກຕ່າງ, ຫຼື ໃຫ້ຄະແນນສູງແກ່ຄຳຕອບທີ່ຜິດແຕ່ມີຕົວອັກສອນຄ້າຍຄືກັນ. ດັ່ງນັ້ນ, ວິທີນີ້ຈຶ່ງບໍ່ເໝາະສົມສຳລັບການປະເມີນ RAG ທີ່ເນັ້ນຄວາມຖືກຕ້ອງທາງດ້ານຄວາມໝາຍ.
ສະຫຼຸບກໍຄື, ການປະເມີນໂດຍມະນຸດບໍ່ສາມາດຂະຫຍາຍຂະໜາດໄດ້ (Scale), ສ່ວນການປະເມີນໂດຍອີງໃສ່ກົດເກນກໍບໍ່ສາມາດເຂົ້າໃຈຄວາມໝາຍໄດ້. ສິ່ງທີ່ຈະມາຕື່ມເຕັມຊ່ອງວ່າງນີ້ກໍຄື LLM-as-a-Judge.
ບັນຫາດ້ານຕົ້ນທຶນ ແລະ ຂະໜາດທີ່ LLM-as-a-Judge ສາມາດແກ້ໄຂໄດ້
LLM-as-a-Judge ແມ່ນວິທີການທີ່ນຳໃຊ້ແບບຈຳລອງພາສາຂະໜາດໃຫຍ່ (Large Language Model) ທີ່ສາມາດເຂົ້າໃຈຄວາມໝາຍຂອງຄຳຕອບມາເປັນຜູ້ປະເມີນ (Judge) ເພື່ອຕັດສິນຜົນແບບອັດຕະໂນມັດໃນປະລິມານຫຼາຍ ເຊິ່ງມີຄວາມໃກ້ຄຽງກັບການປະເມີນໂດຍມະນຸດ.
ໂດຍການສົ່ງ "ຄຳຖາມ, ບໍລິບົດທີ່ດຶງມາໄດ້, ແລະ ຄຳຕອບທີ່ສ້າງຂຶ້ນ" ໃຫ້ກັບ LLM ທີ່ເຮັດໜ້າທີ່ເປັນ Judge, ຈາກນັ້ນໃຫ້ມັນສົ່ງຄະແນນ ຫຼື ຜົນຜ່ານ/ບໍ່ຜ່ານ ຕາມມາດຕະຖານທີ່ກຳນົດໄວ້ລ່ວງໜ້າ (ຕົວຢ່າງ: ມີຄວາມຊື່ສັດຕໍ່ບໍລິບົດຫຼືບໍ່, ຕອບຄຳຖາມຫຼືບໍ່). ວິທີນີ້ເຮັດໃຫ້ສາມາດປະເມີນຈຳນວນຫຼາຍທີ່ມະນຸດບໍ່ສາມາດເຮັດທັນໄດ້ໃນເວລາອັນສັ້ນ ແລະ ຍັງສາມາດຄວບຄຸມຄວາມແຕກຕ່າງລະຫວ່າງຜູ້ປະເມີນໄດ້ ເນື່ອງຈາກມາດຕະຖານຖືກກຳນົດໄວ້ຢ່າງຄົງທີ່ຜ່ານ Prompt.
ຄວາມແຕກຕ່າງທີ່ສຳຄັນຈາກການປະເມີນແບບ Rule-based ແມ່ນມັນສາມາດໃຫ້ຄະແນນໄດ້ຢ່າງຖືກຕ້ອງເຖິງແມ່ນວ່າການສະແດງອອກຈະແຕກຕ່າງກັນ ແຕ່ຖ້າຄວາມໝາຍຖືກຕ້ອງກໍຖືວ່າໃຊ້ໄດ້. ໃນທາງກັບກັນ, ເນື່ອງຈາກຕົວ Judge ເອງກໍເປັນ LLM, ມັນຈຶ່ງມີຈຸດອ່ອນສະເພາະຕົວຄືບັນຫາອະຄະຕິ (Bias) ແລະ ຄວາມບໍ່ສະໝໍ່າສະເໝີໃນການຕັດສິນ ເຊິ່ງຈະກ່າວເຖິງໃນພາຍຫຼັງ. ດ້ວຍເຫດນີ້, ການອອກແບບ ແລະ ການກວດສອບມາດຕະຖານການປະເມີນຈຶ່ງເປັນປັດໄຈທີ່ກຳນົດຄຸນນະພາບ.
ບົດບາດຂອງ Framework ຫຼັກໆ ເຊັ່ນ RAGAS
ທ່ານສາມາດສ້າງ LLM-as-a-Judge ຂຶ້ນມາເອງໄດ້ ແຕ່ໃນການເຮັດວຽກຕົວຈິງ ການໃຊ້ເຟຣມເວີກການປະເມີນຜົນແມ່ນເປັນເລື່ອງທົ່ວໄປ. ຕົວຢ່າງທີ່ໂດດເດັ່ນຄື RAGAS ເຊິ່ງໄດ້ລວບລວມຕົວຊີ້ວັດການປະເມີນຜົນສະເພາະສຳລັບ RAG ແລະ ກົນໄກໃນການວັດແທກຜົນດ້ວຍ LLM-as-a-Judge ມາໃຫ້ພ້ອມ.
RAGAS ມີຕົວຊີ້ວັດທີ່ເໝາະສົມກັບ RAG ມາໃຫ້ເປັນມາດຕະຖານ ເຊັ່ນ: "ຄວາມຊື່ສັດ (Faithfulness)", "ຄວາມກ່ຽວຂ້ອງຂອງຄຳຕອບ (Answer Relevance)" ແລະ "ຄວາມເໝາະສົມຂອງບໍລິບົດ (Context Precision)" ໂດຍຈະມີການເອີ້ນໃຊ້ LLM ເພື່ອເຮັດໜ້າທີ່ເປັນຜູ້ຕັດສິນ (Judge) ຢູ່ພາຍໃນເພື່ອຄິດໄລ່ຄະແນນ. ການນຳໃຊ້ວິທີນີ້ຈະຊ່ວຍໃຫ້ເລີ່ມຕົ້ນໄດ້ໄວຂຶ້ນເມື່ອທຽບກັບການສ້າງ Prompt ແລະ ຕັກກະການໃຫ້ຄະແນນດ້ວຍຕົນເອງ, ອີກທັງຍັງເຮັດໃຫ້ການກຳນົດຕົວຊີ້ວັດມີມາດຕະຖານດຽວກັນ.
ນອກຈາກນີ້ ຍັງມີຫໍສະໝຸດ (Library) ການປະເມີນຜົນແບບທົ່ວໄປອີກຫຼາຍແຫ່ງ ແຕ່ໃນບົດຄວາມນີ້ຈະເນັ້ນອະທິບາຍຂັ້ນຕອນການຈັດຕັ້ງປະຕິບັດ LLM-as-a-Judge ໂດຍຍຶດເອົາ RAGAS ເຊິ່ງເປັນທີ່ນິຍົມຢ່າງກວ້າງຂວາງໃນການປະເມີນຜົນ RAG ເປັນແກນຫຼັກ. ທັງນີ້, ຄວາມໝາຍຂອງແຕ່ລະຕົວຊີ້ວັດ ແລະ ວິທີການນຳໄປໃຊ້ເພື່ອປັບປຸງຄວາມຖືກຕ້ອງຂອງ RAG ໄດ້ຖືກກ່າວເຖິງຢ່າງລະອຽດໃນ ວິທີການເພີ່ມຄວາມຖືກຕ້ອງຂອງ RAG ແລ້ວ, ດັ່ງນັ້ນບົດຄວາມນີ້ຈຶ່ງຈະສຸມໃສ່ການເຮັດໃຫ້ການປະເມີນຜົນເປັນແບບອັດຕະໂນມັດເທົ່ານັ້ນ.
ເງື່ອນໄຂເບື້ອງຕົ້ນທີ່ຄວນກວດສອບກ່ອນສ້າງຂະບວນການ ຫຼື Pipeline ການປະເມີນ
ຄວາມຖືກຕ້ອງແລະຄວາມສາມາດໃນການເຮັດຊ້ຳຂອງຂະບວນການ ຫຼື Pipeline ການປະເມີນຜົນ ຈະຖືກຕັດສິນດ້ວຍການວາງຮາກຖານໃຫ້ພ້ອມກ່ອນທີ່ຈະເລີ່ມດຳເນີນການວັດແທກຕົວຊີ້ວັດ. ໃນທີ່ນີ້, ພວກເຮົາຈະມາທົບທວນ 3 ເງື່ອນໄຂເບື້ອງຕົ້ນ ຄື: ການຈັດລະບຽບເປົ້າໝາຍການປະເມີນຜົນ, ການຄັດເລືອກ Judge LLM, ແລະ ການກຽມຊຸດຂໍ້ມູນທົດສອບ (Test set).
ການຈັດລະບຽບສະຖາປັດຕະຍະກຳ RAG ແລະ ຮູບແບບຜົນລວມທີ່ຕ້ອງການປະເມີນ
ສິ່ງທຳອິດທີ່ຕ້ອງເຮັດຄືການກຳນົດໃຫ້ຊັດເຈນວ່າຈະປະເມີນຫຍັງ. RAG ຂະບວນການ ຫຼື Pipeline ຈະແບ່ງອອກເປັນ 2 ຂັ້ນຕອນຄື: "ການຄົ້ນຫາ (Retrieval)" ແລະ "ການສ້າງ (Generation)" ເຊິ່ງຕົວຊີ້ວັດການປະເມີນກໍຈະແຍກຕາມແຕ່ລະຂັ້ນຕອນ. ຖ້າບໍ່ຕັດສິນໃຈໃຫ້ແນ່ນອນວ່າຈະວັດຜົນຈາກຜົນລັດໃດ, ເຖິງຈະເລືອກຕົວຊີ້ວັດມາໄດ້ກໍຈະບໍ່ສາມາດນຳໄປປັບໃຊ້ໄດ້.
ໂດຍສະເພາະແລ້ວ, ເພື່ອການປະເມີນຜົນ ຢ່າງໜ້ອຍຕ້ອງຢູ່ໃນສະຖານະທີ່ສາມາດບັນທຶກ 3 ຢ່າງນີ້ໄດ້ຄື: ຄຳຖາມຂອງຜູ້ໃຊ້, ບໍລິບົດ (Chunk) ທີ່ໄດ້ຈາກການຄົ້ນຫາ, ແລະ ຄຳຕອບທີ່ຖືກສ້າງຂຶ້ນໃນທີ່ສຸດ. ຂຶ້ນຢູ່ກັບຕົວຊີ້ວັດ, ໃນບາງກໍລະນີອາດຈະຕ້ອງມີຄຳຕອບທີ່ຖືກຕ້ອງ (Reference) ເພີ່ມຕື່ມນຳ.
ໃນກໍລະນີທີ່ RAG ທີ່ມີຢູ່ແລ້ວບັນທຶກໄວ້ພຽງແຕ່ຄຳຕອບ, ຈຳເປັນຕ້ອງມີການປັບປຸງເພື່ອໃຫ້ບັນທຶກບໍລິບົດທີ່ໄດ້ມາໄວ້ໃນ Log. ເພາະຖ້າບໍ່ສາມາດດຶງບໍລິບົດອອກມາໄດ້ ກໍຈະບໍ່ສາມາດຄຳນວນຕົວຊີ້ວັດເພື່ອວັດແທກຄຸນນະພາບການຄົ້ນຫາໄດ້. ການອອກແບບການປະເມີນຜົນຈະເລີ່ມຕົ້ນຈາກການຈັດລະບຽບຮູບແບບຜົນລັດເຫຼົ່ານີ້.
ເກນການຄັດເລືອກ LLM ສຳລັບການຕັດສິນ ແລະ ຂໍ້ກຳນົດໃນການເຂົ້າເຖິງ
ໂດຍພື້ນຖານແລ້ວ, LLM ທີ່ໃຊ້ໃນການຕັດສິນຄວນເລືອກຕົວທີ່ມີຄວາມສາມາດໃນການຕັດສິນໃຈທຽບເທົ່າ ຫຼື ສູງກວ່າຕົວແບບທີ່ສ້າງຄຳຕອບທີ່ຕ້ອງການປະເມີນ. ຖ້າໃຊ້ຕົວແບບທີ່ມີຄວາມສາມາດໃນການຕັດສິນໃຈຕໍ່າກວ່າ, ການປະເມີນຜົນນັ້ນກໍຈະບໍ່ສາມາດເຊື່ອຖືໄດ້. ຕົວແບບລະດັບແຖວໜ້າ (Frontier models) ເຊັ່ນ: GPT, Claude, ແລະ Gemini ແມ່ນຕົວເລືອກທີ່ເໝາະສົມ.
ໃນການຄັດເລືອກ, ໃຫ້ກວດສອບ 3 ປະເດັນດັ່ງນີ້: ປະການທຳອິດ, ມີຄວາມຍາວຂອງບໍລິບົດ (Context length) ພຽງພໍທີ່ຈະຈັດການກັບບໍລິບົດທີ່ຍາວນານ (ເຊັ່ນ: ການສົ່ງຄຳຖາມ, ບໍລິບົດທີ່ດຶງມາ, ແລະ ຄຳຕອບລວມກັນ) ໄດ້ຫຼືບໍ່. ປະການທີສອງ, ສາມາດສົ່ງຜົນລັພອອກມາເປັນຄະແນນ ຫຼື ໂຄງສ້າງ JSON ເພື່ອເຮັດໃຫ້ການປະເມີນມີຄວາມສະຖຽນໄດ້ຫຼືບໍ່. ປະການທີສາມ, ສາມາດຮອງຮັບອັດຕາ API ແລະ ຄ່າໃຊ້ຈ່າຍຕາມຈຳນວນການປະເມີນໄດ້ຫຼືບໍ່.
ໃນກໍລະນີທີ່ນຳຂໍ້ມູນພາຍໃນບໍລິສັດມາໃຊ້ໃນການປະເມີນ, ຕ້ອງລະມັດລະວັງໃນການຈັດການຂໍ້ມູນນຳ. ຖ້າເປັນຂໍ້ມູນທີ່ມີຄວາມລັບສູງ, ຄວນພິຈາລະນາທາງເລືອກໃນການໃຊ້ Local LLM ທີ່ເຮັດວຽກຢູ່ເທິງ On-premise ຫຼື ສະພາບແວດລ້ອມສ່ວນຕົວ ແທນທີ່ຈະໃຊ້ API ພາຍນອກ.
ວິທີການກຽມຊຸດທົດສອບ (Golden Dataset)
ຄວາມໜ້າເຊື່ອຖືຂອງການປະເມີນຜົນແມ່ນຂຶ້ນຢູ່ກັບຄຸນນະພາບຂອງຊຸດທົດສອບ (Golden Dataset) ເປັນຫຼັກ. ນີ້ແມ່ນຂໍ້ມູນສຳລັບການປະເມີນຜົນທີ່ລວບລວມເອົາ "ຄຳຖາມທີ່ຄາດວ່າຈະມີ" ແລະ "ຄຳຕອບທີ່ຄາດຫວັງ ຫຼື ບໍລິບົດທີ່ເປັນຫຼັກຖານ" ຕາມຄວາມຈຳເປັນໄວ້ນຳກັນ.
ເງື່ອນໄຂຂອງຊຸດທົດສອບທີ່ດີມີ 3 ປະການຄື: ຕ້ອງສະທ້ອນເຖິງການກະຈາຍຕົວຂອງຄຳຖາມທີ່ຜູ້ໃຊ້ຕົວຈິງຖາມ, ຕ້ອງລວມເອົາຄຳຖາມທີ່ບໍ່ຊັດເຈນ, ຄຳຖາມທີ່ຊັບຊ້ອນ ແລະ ຄຳຖາມທີ່ທ້າທາຍ ບໍ່ແມ່ນພຽງແຕ່ຄຳຖາມງ່າຍໆເທົ່ານັ້ນ, ແລະ ຕ້ອງມີການອັບເດດຢ່າງຕໍ່ເນື່ອງຈາກຂໍ້ມູນການໃຊ້ງານຈິງ. ຖ້າສ້າງຂຶ້ນໂດຍອີງໃສ່ພຽງແຕ່ຄຳຖາມທີ່ນັກພັດທະນາຄິດອອກເທົ່ານັ້ນ, ຈະບໍ່ສາມາດກວດຈັບຄວາມຜິດພາດທີ່ເກີດຂຶ້ນໃນການໃຊ້ງານຈິງໄດ້.
ຈຳນວນລາຍການຍິ່ງຫຼາຍກໍຍິ່ງມີຄວາມສະຖຽນ, ແຕ່ໃນເບື້ອງຕົ້ນຄວນເລີ່ມຈາກການກວມເອົາກໍລະນີການໃຊ້ງານ (Use case) ທີ່ເປັນຕົວແທນປະມານຫຼາຍສິບຫາຫຼາຍຮ້ອຍລາຍການ, ແລ້ວຈຶ່ງເພີ່ມຕົວຢ່າງຄວາມຜິດພາດທີ່ພົບໃນການໃຊ້ງານຈິງເຂົ້າໄປຢ່າງຕໍ່ເນື່ອງ ເຊິ່ງເປັນວິທີທີ່ເໝາະສົມກັບຄວາມເປັນຈິງ. ທັງນີ້, ຖ້າວິທີການສ້າງຊຸດທົດສອບຜິດພາດ ຈະເຮັດໃຫ້ຜົນການປະເມີນບໍ່ສາມາດເຊື່ອຖືໄດ້. ຄວາມຜິດພາດແບບປົກກະຕິເຫຼົ່ານັ້ນຈະຖືກກ່າວເຖິງຢ່າງລະອຽດໃນພາກຕໍ່ໄປ.
ຄວນໃຊ້ຕົວຊີ້ວັດໃດ? ວິທີການເລືອກຕົວຊີ້ວັດທີ່ເໝາະສົມກັບ RAG
ມີຕົວຊີ້ວັດການປະເມີນຜົນ RAG ຫຼາຍຢ່າງ, ແຕ່ການວັດແທກທັງໝົດຢ່າງບໍ່ມີທິດທາງຈະເຮັດໃຫ້ເກີດຄວາມຫຍຸ້ງຍາກໃນການຕີຄວາມໝາຍ. ໃນທີ່ນີ້, ພວກເຮົາຈະມາເບິ່ງຕົວຊີ້ວັດຫຼັກທີ່ Judge ໃຊ້ໃນການໃຫ້ຄະແນນ, ການເຊື່ອມໂຍງກັບ RAGAS, ແລະ ວິທີການກຳນົດລຳດັບຄວາມສຳຄັນຕາມແຕ່ລະກໍລະນີການນຳໃຊ້ (Use case) ໄປຕາມລຳດັບ.
ຕົວຊີ້ວັດຫຼັກທີ່ LLM Judge ໃຊ້ໃນການໃຫ້ຄະແນນ ແລະ ມຸມມອງການຕັດສິນ
ເມື່ອໃຊ້ LLM-as-a-Judge ໃນການປະເມີນ RAG, ຕົວຊີ້ວັດທີ່ເປັນ ຈຸດສຳຄັນ ຫຼື ແກນຫຼັກ ມີ 3 ຢ່າງດັ່ງນີ້. ແຕ່ລະຢ່າງມີມຸມມອງການຕັດສິນທີ່ແຕກຕ່າງກັນໃນເລື່ອງ "ສິ່ງທີ່ Judge ຈະພິຈາລະນາເພື່ອໃຫ້ຄະແນນ".
ຄວາມຊື່ສັດ (Faithfulness): ຄຳຕອບທີ່ສ້າງຂຶ້ນນັ້ນ ມີຂໍ້ມູນອ້າງອີງມາຈາກບໍລິບົດ (Context) ທີ່ດຶງມາໄດ້ຫຼືບໍ່. Judge ຈະກວດສອບວ່າແຕ່ລະຂໍ້ສະຫຼຸບໃນຄຳຕອບສາມາດສະຫຼຸບມາຈາກບໍລິບົດໄດ້ຫຼືບໍ່, ຖ້າຄຳຕອບມີການກ່າວເຖິງຂໍ້ມູນທີ່ບໍ່ມີຢູ່ໃນບໍລິບົດ (= Hallucination), ມັນຈະຖືກໃຫ້ຄະແນນຕໍ່າ.
ຄວາມກ່ຽວຂ້ອງຂອງຄຳຕອບ (Answer Relevancy): ຄຳຕອບໄດ້ຕອບສະໜອງຕາມເຈດຕະນາຂອງຄຳຖາມຢ່າງຖືກຕ້ອງຫຼືບໍ່. Judge ຈະຫັກຄະແນນຄຳຕອບທີ່ເຖິງຈະຖືກຕ້ອງແຕ່ບໍ່ກົງປະເດັນ ຫຼື ຄຳຕອບທີ່ຍືດຍາວຈົນເຮັດໃຫ້ຈຸດສຳຄັນມົວໝອງ.
ຄວາມຊັດເຈນຂອງບໍລິບົດ (Context Precision): ໃນບັນດາບໍລິບົດທີ່ດຶງມາໄດ້ຈາກການຄົ້ນຫາ, ມີຂໍ້ມູນທີ່ຈຳເປັນຕໍ່ການຕອບຄຳຖາມລວມຢູ່ຫຼາຍໜ້ອຍພຽງໃດ. ນີ້ແມ່ນຕົວຊີ້ວັດທີ່ວັດແທກຄຸນນະພາບໃນຂັ້ນຕອນການຄົ້ນຫາ ບໍ່ແມ່ນຂັ້ນຕອນການສ້າງຄຳຕອບ.
ຄວາມຊື່ສັດ ແລະ ຄວາມກ່ຽວຂ້ອງຂອງຄຳຕອບແມ່ນໃຊ້ວັດແທກຄຸນນະພາບຂອງການສ້າງຄຳຕອບ, ສ່ວນຄວາມຊັດເຈນຂອງບໍລິບົດແມ່ນໃຊ້ວັດແທກຄຸນນະພາບຂອງການຄົ້ນຫາ. ການທີ່ສາມາດແຍກໄດ້ວ່າບັນຫາເກີດຂຶ້ນໃນຂັ້ນຕອນໃດ ຄືຄຸນຄ່າຂອງການແຍກວັດແທກດ້ວຍຕົວຊີ້ວັດເຫຼົ່ານີ້.
ການປັບຕົວຊີ້ວັດ RAGAS ໃຫ້ສອດຄ່ອງກັບການໃຫ້ຄະແນນຂອງ LLM Judge
ຕົວຊີ້ວັດໃນຫົວຂໍ້ກ່ອນໜ້ານີ້ ໄດ້ຖືກນຳໄປປະຕິບັດເປັນມາດຕະຖານໃນ RAGAS ເຊິ່ງຈະມີການເອີ້ນໃຊ້ LLM-as-a-Judge ຢູ່ພາຍໃນເພື່ອຄຳນວນໂດຍອັດຕະໂນມັດ. ຄວາມຊື່ສັດຕໍ່ຂໍ້ມູນ (Faithfulness) ສອດຄ່ອງກັບ faithfulness, ຄວາມກ່ຽວຂ້ອງຂອງຄຳຕອບ (Answer Relevancy) ສອດຄ່ອງກັບ answer relevancy, ແລະ ຄຸນນະພາບການຄົ້ນຫາ (Search Quality) ສອດຄ່ອງກັບ context precision / context recall.
ໃນກໍລະນີທີ່ຕ້ອງພັດທະນາ LLM-as-a-Judge ດ້ວຍຕົນເອງ, ການເຂົ້າໃຈຄວາມສຳພັນເຫຼົ່ານີ້ຈະເປັນແນວທາງໃນການອອກແບບຕົວຊີ້ວັດ. ຖ້າຫາກໃຊ້ RAGAS, ຄວນກວດສອບວ່າແຕ່ລະຕົວຊີ້ວັດຕ້ອງການຂໍ້ມູນໃດແດ່ (ຄຳຖາມ, ບໍລິບົດ, ຄຳຕອບ, ຫຼື ຄຳຕອບທີ່ຖືກຕ້ອງ) ແລະ ຈັດກຽມຊຸດທົດສອບ (Test set) ໃຫ້ຄົບຖ້ວນຕາມຂໍ້ມູນນຳເຂົ້າເຫຼົ່ານັ້ນ.
ສຳລັບຄວາມໝາຍຂອງຕົວເລກໃນແຕ່ລະຕົວຊີ້ວັດ ແລະ ວິທີການນຳໃຊ້ຄະແນນທີ່ຕໍ່າໄປສູ່ການປັບປຸງ RAG (ເຊັ່ນ: ການເຮັດ Re-ranking ຫຼື Hybrid Search) ແມ່ນໄດ້ອະທິບາຍໄວ້ຢ່າງເປັນລະບົບໃນ ວິທີການເພີ່ມຄວາມຖືກຕ້ອງຂອງ RAG: ການຫຼຸດຜ່ອນ Hallucination ແລະ Hybrid Search. ໃນບົດຄວາມນີ້, ພວກເຮົາຈະສຸມໃສ່ "ວິທີການໃຫ້ຄະແນນອັດຕະໂນມັດດ້ວຍ Judge ແລະ ການນຳໄປໃຊ້ງານຈິງ".
ວິທີການກຳນົດລຳດັບຄວາມສຳຄັນຂອງຕົວຊີ້ວັດຕາມກໍລະນີການນຳໃຊ້ (Use Case)
ບໍ່ຈຳເປັນຕ້ອງໃຫ້ຄວາມສຳຄັນກັບທຸກຕົວຊີ້ວັດຢ່າງເທົ່າທຽມກັນ. ຕົວຊີ້ວັດທີ່ຄວນຮັກສາໄວ້ກ່ອນຈະປ່ຽນແປງໄປຕາມການນຳໃຊ້ RAG.
ສຳລັບການນຳໃຊ້ທີ່ຄວາມຖືກຕ້ອງມີຄວາມສຳຄັນເຖິງຊີວິດ ເຊັ່ນ: ກົດລະບຽບພາຍໃນ, ກົດໝາຍ, ການແພດ ຫຼື ການເງິນ, ໃຫ້ຖືເອົາຄວາມຊື່ສັດ (Faithfulness) ເປັນບຸລິມະສິດສູງສຸດ. ເນື່ອງຈາກການຕອບຂໍ້ມູນທີ່ບໍ່ມີຢູ່ໃນບໍລິບົດ (Hallucination) ແມ່ນຄວາມສ່ຽງທີ່ໃຫຍ່ທີ່ສຸດ. ໃນທາງກົງກັນຂ້າມ, ສຳລັບການນຳໃຊ້ທີ່ຄວາມເຂົ້າໃຈງ່າຍຂອງຄຳຕອບມີຜົນ ເຊັ່ນ: ການບໍລິການລູກຄ້າ ຫຼື ຝ່າຍຊ່ວຍເຫຼືອພາຍໃນ, ໃຫ້ເພີ່ມນ້ຳໜັກຂອງຄວາມກ່ຽວຂ້ອງຂອງຄຳຕອບ (Answer Relevance).
ໃນຖານຂໍ້ມູນຄວາມຮູ້ (Knowledge Base) ທີ່ມີເອກະສານຄົ້ນຫາຈຳນວນຫຼາຍ ແລະ ມີສິ່ງລົບກວນປົນເຂົ້າມາໄດ້ງ່າຍ, ໃຫ້ຕິດຕາມຄຸນນະພາບໃນຂັ້ນຕອນການຄົ້ນຫາຢ່າງຕໍ່ເນື່ອງໂດຍການເບິ່ງອັດຕາຄວາມເໝາະສົມຂອງບໍລິບົດ (Context Precision).
ເມື່ອກຳນົດລຳດັບຄວາມສຳຄັນໄດ້ແລ້ວ, ໃຫ້ສະທ້ອນສິ່ງນັ້ນໄປສູ່ເສັ້ນຜ່ານ-ບໍ່ຜ່ານ (Threshold). ຕົວຢ່າງເຊັ່ນ: "ຖ້າຄວາມຊື່ສັດຕ່ຳກວ່າຄ່າທີ່ກຳນົດໄວ້ ຖືວ່າບໍ່ຜ່ານ", ການປ່ຽນແປງມາດຕະຖານໃນແຕ່ລະຕົວຊີ້ວັດຕາມຄວາມສ່ຽງຂອງການນຳໃຊ້ແມ່ນວິທີການທີ່ໃຊ້ໄດ້ຈິງ. ຖ້າຕ້ອງການໃຫ້ທຸກຢ່າງຢູ່ໃນລະດັບສູງ, ຈຸດສຳຄັນ ຫຼື ແກນຫຼັກ ຂອງການປັບປຸງຈະມົວໝອງລົງ.
ຂັ້ນຕອນທີ 1-4: ຂັ້ນຕອນການຈັດຕັ້ງປະຕິບັດຂະບວນການ ຫຼື Pipeline ການປະເມີນ LLM-as-a-Judge
ຕໍ່ໄປນີ້ແມ່ນຂັ້ນຕອນການຈັດຕັ້ງປະຕິບັດຂະບວນການ ຫຼື Pipeline ການປະເມີນຜົນແບບ LLM-as-a-Judge ໂດຍໃຊ້ RAGAS ໃນ 4 ຂັ້ນຕອນ. ເລີ່ມຕັ້ງແຕ່ການສ້າງສະພາບແວດລ້ອມ, ການອອກແບບຄຳສັ່ງ (Prompt) ສຳລັບການຕັດສິນ, ໄປຈົນເຖິງການລວມຄະແນນ ແລະ ການສະແດງຜົນ.
ຂັ້ນຕອນທີ 1-2: ການຕັ້ງຄ່າ RAGAS ແລະ ການກຳນົດຮູບແບບຂໍ້ມູນນຳເຂົ້າສຳລັບການປະເມີນ
ກ່ອນອື່ນໝົດ ແມ່ນການກຽມສະພາບແວດລ້ອມໃນການປະເມີນຜົນ. ໃຫ້ກຽມ Python environment ພ້ອມກັບ RAGAS ແລະ Client ຂອງ LLM ທີ່ໃຊ້ສຳລັບການຕັດສິນ (SDK ຂອງ Model ທີ່ນຳມາໃຊ້).
ຕໍ່ມາ, ໃຫ້ຈັດຮູບແບບຂໍ້ມູນການປະເມີນຜົນໃຫ້ຢູ່ໃນຮູບແບບທີ່ RAGAS ສາມາດຮັບໄດ້. ພື້ນຖານຫຼັກຈະປະກອບດ້ວຍ 4 ອົງປະກອບຄື: ຄຳຖາມ, ບໍລິບົດ (Context) ທີ່ດຶງຂໍ້ມູນມາໄດ້, ຄຳຕອບທີ່ສ້າງຂຶ້ນ, ແລະ (ຖ້າຈຳເປັນ) ຄຳຕອບທີ່ຖືກຕ້ອງ (Ground Truth). ໃນ RAGAS, ພວກເຮົາຈະສົ່ງຂໍ້ມູນເຫຼົ່ານີ້ໃນຮູບແບບຂອງ Dataset ທີ່ມີຄໍລຳເຫຼົ່ານີ້ຢູ່.
python
1from datasets import Dataset
2
3data = {
4 "question": ["ຈຳນວນວັນລາພັກປະຈຳປີຕາມກົດລະບຽບການເຮັດວຽກແມ່ນເທົ່າໃດ?"],
5 "contexts": [["ຫຼັງຈາກເຂົ້າເຮັດວຽກໄດ້ 6 ເດືອນ ຈະໄດ້ຮັບວັນລາພັກ 10 ວັນ..."]],
6 "answer": ["ຫຼັງຈາກເຂົ້າເຮັດວຽກໄດ້ 6 ເດືອນ ຈະໄດ້ຮັບວັນລາພັກ 10 ວັນ."],
7 "ground_truth": ["ໄດ້ຮັບ 10 ວັນ ຫຼັງຈາກເຮັດວຽກຕໍ່ເນື່ອງຄົບ 6 ເດືອນ."],
8}
9dataset = Dataset.from_dict(data)ສິ່ງທີ່ສຳຄັນໃນບ່ອນນີ້ຄື ການໃສ່ "ບໍລິບົດທີ່ໄດ້ຈາກການຄົ້ນຫາຕົວຈິງ" ລົງໃນ contexts. ຖ້າບໍ່ສົ່ງຜົນການຄົ້ນຫາທີ່ຄືກັນກັບການໃຊ້ງານຈິງ (Production) ແທນທີ່ຈະເປັນບໍລິບົດໃນອຸດົມຄະຕິ, ມັນກໍຈະບໍ່ສາມາດປະເມີນຜົນລວມເຖິງຄຸນນະພາບຂອງການຄົ້ນຫາໄດ້. ເມື່ອກຳນົດຮູບແບບການປ້ອນຂໍ້ມູນຮຽບຮ້ອຍແລ້ວ, ຂັ້ນຕອນຕໍ່ໄປແມ່ນການອອກແບບເນື້ອໃນຂອງການຕັດສິນ (Judge).
ຂັ້ນຕອນທີ 3: ການອອກແບບ Prompt ສຳລັບການຕັດສິນ ແລະ ການຈັດຕັ້ງປະຕິບັດເຫດຜົນໃນການໃຫ້ຄະແນນ
ຄຸນນະພາບຂອງ LLM-as-a-Judge ແມ່ນຖືກກຳນົດໂດຍການອອກແບບ Prompt ທີ່ສົ່ງໃຫ້ຕົວຕັດສິນເປັນຫຼັກ. ໃນກໍລະນີທີ່ໃຊ້ Metric ມາດຕະຖານຂອງ RAGAS, ທ່ານສາມາດປ່ອຍໃຫ້ເປັນໜ້າທີ່ຂອງ Prompt ພາຍໃນໄດ້, ແຕ່ຖ້າຕ້ອງການໃຫ້ຄະແນນຕາມມາດຕະຖານຂອງຕົນເອງ, ທ່ານຈຳເປັນຕ້ອງອອກແບບ Prompt ສຳລັບການຕັດສິນດ້ວຍຕົນເອງ.
ຈຸດສຳຄັນ ຫຼື ແກນຫຼັກ ໃນການອອກແບບມີ 3 ປະການ. ປະການທຳອິດ, ໃຫ້ຂຽນມາດຕະຖານການໃຫ້ຄະແນນດ້ວຍມຸມມອງທີ່ລະອຽດຊັດເຈນ ແທນທີ່ຈະໃຊ້ຄຳຄຸນນາມທີ່ບໍ່ຊັດເຈນ. ຕົວຢ່າງເຊັ່ນ: ບໍ່ຄວນຖາມວ່າ "ເປັນຄຳຕອບທີ່ດີຫຼືບໍ່" ແຕ່ໃຫ້ຖາມວ່າ "ແຕ່ລະຂໍ້ໂຕ້ແຍ້ງໃນຄຳຕອບນັ້ນ ມີເນື້ອໃນສະໜັບສະໜູນຢ່າງຖືກຕ້ອງຫຼືບໍ່". ປະການທີສອງ, ໃຫ້ກຳນົດຮູບແບບຜົນລວມໃຫ້ເປັນໂຄງສ້າງເຊັ່ນ: ຄະແນນ ຫຼື JSON ເພື່ອໃຫ້ສາມາດລວບລວມຂໍ້ມູນໄດ້ໂດຍອັດຕະໂນມັດໃນຂັ້ນຕອນຕໍ່ໄປ. ປະການທີສາມ, ການໃຫ້ລະບຸເຫດຜົນໃນການຕັດສິນໄປພ້ອມກັນ ຈະຊ່ວຍໃຫ້ສາມາດຕິດຕາມສາເຫດຂອງຄະແນນທີ່ຕໍ່າໄດ້ໃນພາຍຫຼັງ.
text
1ທ່ານຄືຜູ້ປະເມີນທີ່ເຂັ້ມງວດ. ກະລຸນາຕັດສິນວ່າຄຳຕອບລຸ່ມນີ້ ອີງໃສ່ພຽງແຕ່ເນື້ອໃນທີ່ໃຫ້ມາເທົ່ານັ້ນຫຼືບໍ່.
2ຖ້າມີຂໍ້ມູນທີ່ບໍ່ໄດ້ຢູ່ໃນເນື້ອໃນ, ໃຫ້ກຳນົດເປັນ faithful=false.
3ຜົນລວມໃຫ້ສະແດງໃນຮູບແບບ JSON ເທົ່ານັ້ນ ຄື {"faithful": true/false, "reason": "..."}ການເລືອກລະຫວ່າງການໃຫ້ຄະແນນເປັນລະດັບເຊັ່ນ 1-5 ຫຼື ການຕັດສິນແບບຜ່ານ/ບໍ່ຜ່ານ (Binary) ແມ່ນຂຶ້ນຢູ່ກັບຈຸດປະສົງການນຳໃຊ້. ການປະເມີນແບບເປັນລະດັບຈະເຮັດໃຫ້ຕິດຕາມທ່າອ່ຽງໄດ້ງ່າຍກວ່າ, ສ່ວນການຕັດສິນແບບຜ່ານ/ບໍ່ຜ່ານ ຈະເຮັດໃຫ້ການຕັດສິນຜົນໄດ້ງ່າຍຂຶ້ນໂດຍອັດຕະໂນມັດ.
ຂັ້ນຕອນທີ 4: ການເຮັດໃຫ້ການລວບລວມຄະແນນ ແລະ ການອອກລາຍງານເປັນອັດຕະໂນມັດ
ເມື່ອໃຫ້ຄະແນນແຕ່ລະລາຍການແລ້ວ, ໃຫ້ລວມຍອດຜົນລວມທັງໝົດຂອງຊຸດທົດສອບ (Test set) ແລະ ສະຫຼຸບອອກມາເປັນລາຍງານທີ່ມະນຸດສາມາດອ່ານ ແລະ ຕັດສິນໃຈໄດ້. ໃນ RAGAS, ເມື່ອເອີ້ນໃຊ້ evaluate, ທ່ານສາມາດຄິດໄລ່ຄະແນນຂອງແຕ່ລະຕົວຊີ້ວັດສຳລັບຊຸດຂໍ້ມູນທັງໝົດໄດ້ພ້ອມກັນ.
python
1from ragas import evaluate
2from ragas.metrics import faithfulness, answer_relevancy, context_precision
3
4result = evaluate(
5 dataset,
6 metrics=[faithfulness, answer_relevancy, context_precision],
7)
8print(result)ຜົນລວມທີ່ໄດ້ຮັບນັ້ນ ບໍ່ຄວນມີພຽງແຕ່ຄະແນນສະເລ່ຍຂອງແຕ່ລະຕົວຊີ້ວັດເທົ່ານັ້ນ, ແຕ່ຄວນກຽມໄວ້ໃຫ້ສາມາດສະກັດເອົາກໍລະນີທີ່ມີຄະແນນຕໍ່າອອກມາໄດ້ນຳ. ເນື່ອງຈາກການເບິ່ງພຽງແຕ່ຄ່າສະເລ່ຍຈະເຮັດໃຫ້ບໍ່ຮູ້ວ່າຄຳຖາມໃດທີ່ຜິດພາດ ແລະ ຜິດພາດຍ້ອນຫຍັງ.
ການຈັດໂຄງສ້າງລາຍງານໃຫ້ປະກອບດ້ວຍ ຄ່າສະເລ່ຍຂອງແຕ່ລະຕົວຊີ້ວັດ, ການປຽບທຽບກັບຄ່າ Threshold, ແລະ ລາຍການກໍລະນີທີ່ບໍ່ຜ່ານເກນ ຈະຊ່ວຍໃຫ້ສາມາດເຊື່ອມໂຍງໄປສູ່ການດຳເນີນການປັບປຸງໄດ້ງ່າຍຂຶ້ນ. ການນຳເອົາຜົນລວມນີ້ໄປລວມ ຫຼື Merge ເຂົ້າກັບ CI/CD ທີ່ກ່າວເຖິງໃນພາຍຫຼັງ ຈະຊ່ວຍໃຫ້ການປະເມີນຜົນບໍ່ແມ່ນພຽງແຕ່ການເຮັດຄັ້ງດຽວ ແຕ່ເປັນຂະບວນການ ຫຼື Pipeline ທີ່ດຳເນີນໄປຢ່າງຕໍ່ເນື່ອງ.
ຂໍ້ຜິດພາດທີ່ພົບເລື້ອຍໃນຂະບວນການ ຫຼື Pipeline ການປະເມີນ ແລະ ວິທີປ້ອງກັນ
LLM-as-a-Judge ມີຄວາມຊົງພະລັງ, ແຕ່ຍ້ອນວ່າຕົວຜູ້ຕັດສິນເອງກໍເປັນ LLM ຈຶ່ງມີຂໍ້ຜິດພາດສະເພາະຕົວ. ໃນທີ່ນີ້, ພວກເຮົາຈະກ່າວເຖິງ 3 ຄວາມຜິດພາດທົ່ວໄປທີ່ເຮັດໃຫ້ຜົນການປະເມີນບໍ່ໜ້າເຊື່ອຖື ແລະ ວິທີການຫຼີກລ່ຽງ. ສິ່ງເຫຼົ່ານີ້ແມ່ນສະເພາະເຈາະຈົງຕໍ່ວິທີການນີ້, ຖ້າຫາກເບິ່ງຂ້າມໄປ ອາດຈະເຮັດໃຫ້ຕົກຢູ່ໃນສະພາວະທີ່ວ່າ "ເຖິງຈະມີການປະເມີນແລ້ວ ແຕ່ຄຸນນະພາບກໍບໍ່ເພີ່ມຂຶ້ນ".
ການຮັບມືກັບບັນຫາອະຄະຕິ ແລະ ການປະເມີນຕົນເອງຂອງ LLM Judge
ມີການລາຍງານວ່າ LLM ທີ່ໃຊ້ໃນການຕັດສິນມີຄວາມລຳອຽງບາງຢ່າງທີ່ຮູ້ຈັກກັນດີ. ຕົວຢ່າງທີ່ເດັ່ນຊັດຄື ແນວໂນ້ມທີ່ຈະໃຫ້ຄະແນນຄຳຕອບທີ່ຍາວສູງກວ່າ, ແນວໂນ້ມທີ່ຈະມັກທາງເລືອກທີ່ຖືກສະເໜີມາໃນຕອນຕົ້ນ, ແລະ ຄວາມລຳອຽງໃນການປະເມີນຕົນເອງ (Self-evaluation bias) ເຊິ່ງມັກຈະໃຫ້ຄະແນນຄຳຕອບທີ່ຕົນເອງ (ແບບຈຳລອງດຽວກັນ) ສ້າງຂຶ້ນມາຢ່າງຜ່ອນປົນ.
ສິ່ງທີ່ຄວນລະວັງເປັນພິເສດຄື ບັນຫາການປະເມີນຕົນເອງ. ຖ້າໃຊ້ແບບຈຳລອງດຽວກັນໃນການສ້າງຄຳຕອບ ແລະ ເປັນຜູ້ຕັດສິນໃນການໃຫ້ຄະແນນ, ອາດຈະເກີດຄວາມສ່ຽງທີ່ການປະເມີນຈະຜ່ອນປົນເກີນໄປ. ວິທີແກ້ໄຂທີ່ມີປະສິດທິຜົນຄື ການໃຊ້ແບບຈຳລອງຈາກລະບົບອື່ນທີ່ບໍ່ແມ່ນລະບົບດຽວກັນກັບທີ່ສ້າງຄຳຕອບມາເປັນຜູ້ຕັດສິນ, ຫຼື ການໃຊ້ຫຼາຍແບບຈຳລອງໃນການໃຫ້ຄະແນນແລ້ວເອົາຜົນມາປຽບທຽບກັນ.
ເຖິງຈະບໍ່ສາມາດກຳຈັດຄວາມລຳອຽງໃຫ້ໝົດໄປໄດ້ຢ່າງສິ້ນເຊີງ, ແຕ່ກໍສາມາດຫຼຸດຜ່ອນຜົນກະທົບລົງໄດ້. ວິທີການຄື ການເຮັດໃຫ້ມາດຕະຖານການໃຫ້ຄະແນນມີຄວາມຊັດເຈນເພື່ອຈຳກັດການໃຊ້ດຸນພິນິດຂອງຜູ້ຕັດສິນ, ການກວດສອບຢ່າງສະໝໍ່າສະເໝີວ່າຄວາມຍາວຫຼືລຳດັບຂອງຄຳຕອບມີຜົນຕໍ່ຜົນລັອກຫຼືບໍ່, ແລະ ໃນຈຸດສຳຄັນ ຫຼື ແກນຫຼັກ ຄວນມີການກວດສອບຄວາມຖືກຕ້ອງຂອງຜູ້ຕັດສິນໂດຍການປຽບທຽບກັບການປະເມີນໂດຍມະນຸດ. ການບໍ່ເຊື່ອໝັ້ນໃນຜູ້ຕັດສິນຢ່າງຕາບອດ ແລະ ການມີທັດສະນະຄະຕິທີ່ລວມເອົາຕົວຜູ້ຕັດສິນເອງເຂົ້າເປັນເປົ້າໝາຍໃນການປະເມີນນັ້ນຖືເປັນສິ່ງສຳຄັນ.
ຄວາມຜັນຜວນຂອງຄະແນນທີ່ເກີດຈາກການອອກແບບ Prompt ທີ່ບໍ່ສົມບູນ
ໃນກໍລະນີທີ່ປະເມີນຄຳຕອບດຽວກັນແລ້ວຄະແນນບໍ່ຄົງທີ່, ສາເຫດສ່ວນໃຫຍ່ມັກຈະມາຈາກຄວາມບໍ່ຊັດເຈນຂອງ Judge Prompt.
ຄຳສັ່ງເຊັ່ນ "ຈົ່ງໃຫ້ຄະແນນຄຸນນະພາບຂອງຄຳຕອບເຕັມ 10 ຄະແນນ" ແມ່ນປ່ອຍໃຫ້ Judge ເປັນຜູ້ຕັດສິນເອງວ່າອັນໃດຄືມາດຕະຖານຂອງຄະແນນສູງ, ເຮັດໃຫ້ຜົນລັພບໍ່ຄົງທີ່ໃນແຕ່ລະຄັ້ງທີ່ປະຕິບັດງານ. ການແຍກມາດຕະຖານການໃຫ້ຄະແນນອອກເປັນແງ່ມຸມທີ່ລະອຽດ ແລະ ໃຫ້ຕັດສິນແຍກແຕ່ລະສ່ວນຈະຊ່ວຍຫຼຸດຜ່ອນຄວາມຜັນຜວນໄດ້ຢ່າງຫຼວງຫຼາຍ.
ສຳລັບວິທີການປະຕິບັດຕົວຈິງເພື່ອຄວບຄຸມຄວາມຜັນຜວນນັ້ນ ມີວິທີຕ່າງໆ ເຊັ່ນ: ການຕັ້ງຄ່າ Temperature ໃຫ້ຕ່ຳເພື່ອເຮັດໃຫ້ຜົນລັພມີຄວາມສະຖຽນ, ການສະແດງຕົວຢ່າງ (Few-shot) ຂອງມາດຕະຖານການຕັດສິນ ແລະ ຮູບແບບຜົນລັພໃຫ້ Judge ເຫັນ, ຫຼື ການໃຫ້ຄະແນນກໍລະນີດຽວກັນຫຼາຍໆຄັ້ງເພື່ອຢືນຢັນຄວາມສອດຄ່ອງກັນ.
ກ່ອນທີ່ຈະເລີ່ມການປະເມີນ, ຄວນກວດສອບໃຫ້ແນ່ໃຈໃນກໍລະນີຈຳນວນໜ້ອຍກ່ອນວ່າ "ຜົນລັພຈະມີຄວາມສະຖຽນຫຼືບໍ່ ຫາກໃຫ້ຄະແນນການປ້ອນຂໍ້ມູນດຽວກັນຊ້ຳໆ". ຫາກປ່ອຍໃຫ້ສ່ວນນີ້ບໍ່ສະຖຽນແລ້ວໄປດຳເນີນການປະເມີນຈຳນວນຫຼາຍ, ຈະເຮັດໃຫ້ບໍ່ສາມາດແຍກອອກໄດ້ວ່າຄວາມແຕກຕ່າງຂອງຄະແນນທີ່ໄດ້ມາຈາກຄຸນນະພາບທີ່ແຕກຕ່າງກັນ ຫຼື ເກີດຈາກຄວາມບໍ່ສະຖຽນຂອງ Judge.
ການປົນເປື້ອນຂອງຊຸດທົດສອບ ແລະ ການຫຼຸດລົງຂອງຄວາມໜ້າເຊື່ອຖືໃນຜົນການປະເມີນ
ການປົນເປື້ອນຂອງຊຸດທົດສອບ (Data Contamination) ໝາຍເຖິງສະພາວະທີ່ຂໍ້ມູນທີ່ໃຊ້ໃນການປະເມີນຜົນ ເຮັດໃຫ້ຜົນການປະເມີນເບິ່ງດີເກີນຄວາມເປັນຈິງ. ໃນ LLM-as-a-Judge, ປະກົດການນີ້ເກີດຂຶ້ນໄດ້ຫຼັກໆໃນ 2 ຮູບແບບ.
ຮູບແບບທຳອິດ ຄືກໍລະນີທີ່ຄຳຖາມ ຫຼື ຄຳຕອບທີ່ຖືກຕ້ອງຂອງຊຸດທົດສອບ ປົນເຂົ້າໄປໃນເອກະສານເປົ້າໝາຍຂອງ RAG ຫຼື ຕົວຢ່າງໃນ Prompt. ເຊິ່ງຈະກາຍເປັນການໃຫ້ AI ແກ້ໄຂ "ໂຈດທີ່ມັນຮູ້ຄຳຕອບຢູ່ແລ້ວ" ເຮັດໃຫ້ບໍ່ສາມາດວັດລະດັບຄວາມສາມາດທີ່ແທ້ຈິງໃນການນຳໃຊ້ງານຈິງໄດ້. ດັ່ງນັ້ນ, ຕ້ອງແຍກຂໍ້ມູນການປະເມີນອອກຈາກຄວາມຮູ້ ຫຼື ຕົວຢ່າງທີ່ໃຫ້ແກ່ RAG ຢ່າງຊັດເຈນ.
ຮູບແບບທີສອງ ຄືກໍລະນີທີ່ຊຸດທົດສອບເກົ່າເກີນໄປ ແລະ ເລີ່ມແຕກຕ່າງຈາກຂໍ້ມູນໃນການນຳໃຊ້ງານຈິງ. ເຖິງແມ່ນວ່າຄຳຖາມໃນການນຳໃຊ້ງານຈິງຈະປ່ຽນແປງໄປແລ້ວ, ແຕ່ຖ້າຫາກຍັງປະເມີນດ້ວຍຄຳຖາມເກົ່າໆຢູ່, ຄະແນນທີ່ໄດ້ອາດຈະສູງ ແຕ່ໃນໜ້າວຽກຈິງອາດຈະເກີດຄວາມຜິດພາດໄດ້.
ວິທີການປ້ອງກັນ ຄືການແຍກຂໍ້ມູນການປະເມີນອອກຈາກຖານຄວາມຮູ້ຂອງ RAG ຢ່າງເດັດຂາດໃນທາງກາຍະພາບ, ລວມເຖິງການນຳເອົາຕົວຢ່າງຄວາມຜິດພາດທີ່ພົບໃນການນຳໃຊ້ງານຈິງມາອັບເດດໃສ່ຊຸດທົດສອບຢ່າງສະໝ່ຳສະເໝີ ເພື່ອຮັກສາຄວາມທັນສະໄໝຂອງການປະເມີນ. ການປະເມີນທີ່ປົນເປື້ອນນັ້ນ ບາງຄັ້ງອາດອັນຕະລາຍຍິ່ງກວ່າການບໍ່ມີການປະເມີນເລີຍ ເພາະຕົວເລກທີ່ດີອາດເຮັດໃຫ້ເກີດຄວາມປະໝາດໄດ້.
ການລວມເຂົ້າກັບ CI/CD ແລະ ວິທີການດຳເນີນການປະເມີນຢ່າງຕໍ່ເນື່ອງ
ການປະເມີນຜົນພຽງຄັ້ງດຽວແມ່ນມີຄວາມໝາຍໜ້ອຍ. ເນື່ອງຈາກຄຸນນະພາບຂອງ RAG ມີການປ່ຽນແປງຕາມການອັບເດດຂໍ້ມູນ ຫຼື ຕົວແບບ (Model), ຈຶ່ງຈຳເປັນຕ້ອງມີກົນໄກທີ່ປະເມີນຜົນໂດຍອັດຕະໂນມັດທຸກຄັ້ງທີ່ມີການປ່ຽນແປງ. ການອອກແບບໂດຍລວມເພື່ອລວມເອົາຂະບວນການ ຫຼື Pipeline ການປະເມີນຜົນເຂົ້າໃນ CI/CD ເພື່ອໃຫ້ເປັນການປະເມີນຜົນຢ່າງຕໍ່ເນື່ອງນັ້ນ ໄດ້ຖືກກ່າວເຖິງໃນ ຄູ່ມືການຈັດຕັ້ງປະຕິບັດ Enterprise RAG ສູ່ການນຳໃຊ້ຈິງ ແລ້ວ. ໃນທີ່ນີ້, ພວກເຮົາຈະສະແດງຈຸດສຳຄັນ ຫຼື ແກນຫຼັກ ໃນການນຳໃຊ້ LLM-as-a-Judge ເພື່ອດຳເນີນການປະເມີນຜົນແບບອັດຕະໂນມັດ.
ການຕັ້ງຄ່າ Trigger ການປະເມີນອັດຕະໂນມັດໂດຍໃຊ້ GitHub Actions
ການປະເມີນຜົນຢ່າງຕໍ່ເນື່ອງໂດຍທົ່ວໄປແລ້ວແມ່ນການຕັ້ງຄ່າທີ່ດຳເນີນການປະເມີນຜົນໂດຍອັດຕະໂນມັດ ເມື່ອມີການປ່ຽນແປງລະຫັດ (Code), ພຣອມ (Prompt) ຫຼື ຂໍ້ມູນ. ຖ້າໃຊ້ GitHub, ໃຫ້ໃຊ້ Pull Request ຫຼື ການ ລວມ ຫຼື Merge ເຂົ້າກັບສາຂາ (Branch) ສະເພາະເປັນຕົວກະຕຸ້ນ (Trigger) ເພື່ອໃຫ້ສະຄຣິບການປະເມີນຜົນເຮັດວຽກ.
yaml
1name: rag-eval
2on:
3 pull_request:
4 branches: [main]
5jobs:
6 evaluate:
7 runs-on: ubuntu-latest
8 steps:
9 - uses: actions/checkout@v4
10 - run: pip install ragas datasets
11 - run: python eval/run_ragas.py
12 env:
13 LLM_API_KEY: ${{ secrets.LLM_API_KEY }}API Key ຂອງ LLM ທີ່ໃຊ້ສຳລັບການຕັດສິນ (Judge) ຈະຖືກສົ່ງຜ່ານຢ່າງປອດໄພໃນຖານະ Secret ຂອງ Repository. ເນື່ອງຈາກການປະເມີນຜົນມີຕົ້ນທຶນດ້ານ API, ການຄວບຄຸມຄວາມຖີ່ເຊັ່ນ: ການປະເມີນໃນລະດັບ Pull Request ແທນທີ່ຈະເຮັດທຸກຄັ້ງທີ່ມີການ Commit ຈຶ່ງເປັນທາງເລືອກທີ່ເໝາະສົມໃນພາກປະຕິບັດ. ໃນກໍລະນີທີ່ຊຸດທົດສອບ (Test set) ມີຂະໜາດໃຫຍ່, ການແຍກລະຫວ່າງການປະເມີນຜົນແບບເບົາ (Lightweight evaluation) ທີ່ກວດສອບສະເພາະສ່ວນທີ່ກ່ຽວຂ້ອງກັບການປ່ຽນແປງ ກັບການປະເມີນຜົນທັງໝົດຕາມໄລຍະເວລາ ຈະຊ່ວຍໃຫ້ສາມາດຮັກສາຄວາມສົມດຸນລະຫວ່າງຕົ້ນທຶນ ແລະ ຄວາມຄົບຖ້ວນໄດ້.
ການຈັດການເກນຄະແນນ (Threshold) ແລະ ແນວທາງປະຕິບັດທີ່ດີທີ່ສຸດໃນການອອກແບບການແຈ້ງເຕືອນ
ກຸນແຈສຳຄັນສຸດທ້າຍທີ່ຈະເຮັດໃຫ້ການປະເມີນຜົນແບບອັດຕະໂນມັດມີຄຸນຄ່າ ຄືການຈັດການກັບຄ່າ Threshold (ເສັ້ນແບ່ງຜ່ານ/ບໍ່ຜ່ານ) ແລະ ການແຈ້ງເຕືອນ. ຖ້າພຽງແຕ່ບັນທຶກຄະແນນໄວ້ໂດຍບໍ່ເຮັດຫຍັງ, ເຮົາກໍຈະບໍ່ຮູ້ເລີຍເມື່ອຄຸນນະພາບຫຼຸດລົງ.
ກ່ອນອື່ນ, ຕ້ອງກຳນົດຄ່າ Threshold ຂອງການຜ່ານຫຼືບໍ່ຜ່ານໃນແຕ່ລະຕົວຊີ້ວັດ, ຖ້າຄະແນນຫຼຸດຕ່ຳກວ່າເກນທີ່ກຳນົດໄວ້ ໃຫ້ສັ່ງ CI ໃຫ້ລົ້ມເຫຼວ. ຕົວຢ່າງເຊັ່ນ: ການກຳນົດໃຫ້ບລັອກການ ລວມ ຫຼື Merge Pull Request ທີ່ຄ່າຄວາມຖືກຕ້ອງ (Fidelity) ຕ່ຳກວ່າເກນທີ່ກຳນົດໄວ້. ວິທີນີ້ຈະຊ່ວຍຢຸດການປ່ຽນແປງທີ່ເຮັດໃຫ້ຄຸນນະພາບຫຼຸດລົງກ່ອນທີ່ຈະຖືກນຳໄປໃຊ້ງານຈິງ.
ການນຳໃຊ້ຄ່າ Threshold ຄວນເລີ່ມຕົ້ນຈາກການກຳນົດຄ່າຄົງທີ່ໄວ້ກ່ອນ ແລ້ວຈຶ່ງປັບປ່ຽນໃຫ້ເໝາະສົມກັບສະຖານະການຕົວຈິງໃນການເຮັດວຽກ. ຖ້າຕັ້ງເກນເຂັ້ມງວດເກີນໄປ ກໍຈະເຮັດໃຫ້ການປ່ຽນແປງທີ່ຈຳເປັນຖືກຢຸດໄວ້, ແຕ່ຖ້າຫາກວ່າງເກີນໄປ ກໍຈະເຮັດໃຫ້ບໍ່ສາມາດກວດພົບການເສື່ອມສະພາບຂອງຄຸນນະພາບໄດ້. ຄວນພິຈາລະນາເບິ່ງແນວໂນ້ມຂອງຄະແນນໃນອະດີດ ພ້ອມກັບປັບລະດັບໃຫ້ເໝາະສົມກັບຄວາມສ່ຽງຂອງການນຳໄປໃຊ້ງານ.
ສຳລັບການແຈ້ງເຕືອນ, ນອກຈາກການແຈ້ງເຕືອນເມື່ອ CI ລົ້ມເຫຼວແລ້ວ, ຄວນມີກົນໄກໃນການສຸ່ມກວດສອບຄະແນນໃນລະຫວ່າງການນຳໃຊ້ງານຈິງຢ່າງສະໝ່ຳສະເໝີ ເພື່ອກວດຫາການເສື່ອມສະພາບຂອງຄຸນນະພາບ. ການດຳເນີນການປະເມີນຜົນໂດຍໃຊ້ທັງ "ປະຕູກ່ອນການປ່ອຍງານ (Release Gate)" ແລະ "ການຕິດຕາມກວດກາລະຫວ່າງການນຳໃຊ້ງານ" ຈະຊ່ວຍໃຫ້ສາມາດຮັກສາຄຸນນະພາບຂອງ RAG ໄດ້ຢ່າງຕໍ່ເນື່ອງ. LLM-as-a-Judge ແມ່ນວິທີການທີ່ເປັນ ຈຸດສຳຄັນ ຫຼື ແກນຫຼັກ ໃນການສະໜັບສະໜູນລະບົບອັດຕະໂນມັດດັ່ງກ່າວ.
ຜູ້ຂຽນ · ຜູ້ກວດທານ
Chi
ສຳເລັດການສຶກສາສາຂາວິທະຍາສາດຄອມພິວເຕີ (Information Science) ຈາກມະຫາວິທະຍາໄລແຫ່ງຊາດລາວ ໂດຍໃນລະຫວ່າງການສຶກສາມີສ່ວນຮ່ວມໃນການພັດທະນາຊອບແວສະຖິຕິ (Statistical Software) ຈາກປະສົບການຕົວຈິງ ຈຶ່ງໄດ້ສ້າງພື້ນຖານດ້ານການວິເຄາະຂໍ້ມູນ (Data Analysis) ແລະ ການໂປຣແກຣມມິງ (Programming) ຢ່າງເຂັ້ມແຂງ. ຕັ້ງແຕ່ປີ 2021 ໄດ້ກ້າວເຂົ້າສູ່ເສັ້ນທາງການພັດທະນາ Web ແລະ ແອັບພລິເຄຊັນ (Application) ແລະ ຕັ້ງແຕ່ປີ 2023 ເປັນຕົ້ນມາ ໄດ້ສັ່ງສົມປະສົບການພັດທະນາຢ່າງເຕັມຮູບແບບທັງໃນດ້ານ Frontend ແລະ Backend. ໃນບໍລິສັດ ຮັບຜິດຊອບການອອກແບບ ແລະ ພັດທະນາ Web Service ທີ່ນຳໃຊ້ AI ພ້ອມທັງມີສ່ວນຮ່ວມໃນໂຄງການທີ່ປະສົມປະສານ ການປະມວນຜົນພາສາທຳມະຊາດ (NLP: Natural Language Processing), ການຮຽນຮູ້ຂອງເຄື່ອງ (Machine Learning), Generative AI ແລະ ໂມເດນພາສາຂະໜາດໃຫຍ່ (LLM: Large Language Model) ເຂົ້າກັບລະບົບທຸລະກິດ. ມີຄວາມກະຕືລືລົ້ນໃນການຕິດຕາມເທັກໂນໂລຊີໃໝ່ລ່າສຸດຢູ່ສະເໝີ ແລະ ໃຫ້ຄວາມສຳຄັນກັບຄວາມວ່ອງໄວໃນທຸກຂັ້ນຕອນ ຕັ້ງແຕ່ການທົດສອບດ້ານເທັກນິກ ຈົນເຖິງການນຳໄປໃຊ້ງານຈິງໃນລະບົບ Production.
