Synthetic Test (ການທົດສອບແບບສັງເຄາະ) ແມ່ນວິທີການປະເມີນຜົນລະບົບ AI ໂດຍອັດຕະໂນມັດ ໂດຍໃຊ້ກໍລະນີທົດສອບທີ່ສ້າງຂຶ້ນຈາກຂໍ້ມູນສັງເຄາະ (synthetic data). ການນຳໃຊ້ພຽງແຕ່ບັນທຶກການໃຊ້ງານຈິງອາດບໍ່ສາມາດກວມເອົາກໍລະນີທີ່ຫາຍາກ (Edge cases), ການປ້ອນຂໍ້ມູນທີ່ເປັນອັນຕະລາຍ (Adversarial inputs) ແລະ ຂໍ້ກຳນົດດ້ານກົດລະບຽບຕ່າງໆໄດ້, ສະນັ້ນຈຶ່ງມີການ "ສັງເຄາະ" ຂໍ້ມູນເຫຼົ່ານີ້ເພື່ອໃຊ້ເປັນຂໍ້ມູນນຳເຂົ້າໃນການທົດສອບ ເພື່ອນຳໄປສູ່ການກວດຫາການຖົດຖອຍ (Regression detection) ແລະ ການຮັບປະກັນຄຸນນະພາບ.

ບົດຄວາມນີ້ມີຈຸດປະສົງເພື່ອໃຫ້ QA, PM ແລະ ວິສະວະກອນໃນບໍລິສັດທີ່ນຳໃຊ້ AI ໄດ້ເຂົ້າໃຈເຖິງນິຍາມຂອງ Synthetic Test, ຄວາມແຕກຕ່າງຈາກ LLM-as-a-Judge, ມຸມມອງດ້ານຄຸນນະພາບທີ່ສາມາດປະເມີນໄດ້, 4 ຂັ້ນຕອນໃນການເລີ່ມຕົ້ນນຳໃຊ້ ແລະ ຂໍ້ຜິດພາດທີ່ມັກພົບເຫັນ. ເມື່ອອ່ານຈົບ, ທ່ານຈະສາມາດອອກແບບຂັ້ນຕອນການເລີ່ມຕົ້ນເພື່ອລວມເອົາ Synthetic Test ເຂົ້າໃນໂຄງການ AI ຂອງບໍລິສັດທ່ານໄດ້.

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

Synthetic Test ແມ່ນວິທີການທົດສອບທີ່ນຳເອົາ "ຂໍ້ມູນສັງເຄາະ (synthetic data)" ໄຫຼເຂົ້າສູ່ຝັ່ງ Input ຂອງລະບົບ AI ເພື່ອຕັດສິນໂດຍອັດຕະໂນມັດວ່າຈະໄດ້ Output ຕາມທີ່ຄາດໄວ້ຫຼືບໍ່. ໃນການທົດສອບຊອບແວແບບດັ້ງເດີມ (unit test ຫຼື e2e test ແລະ ອື່ນໆ), ຜູ້ພັດທະນາຈະຕ້ອງກຽມຄ່າ Input ແລະ ຄ່າທີ່ຄາດຫວັງໄວ້ດ້ວຍຕົນເອງ. ໃນທາງກົງກັນຂ້າມ, ຈຸດເດັ່ນຂອງ Synthetic Test ແມ່ນການສ້າງ ແລະ ປັບປ່ຽນ Input ທີ່ໃຊ້ໃນການທົດສອບເປັນຈຳນວນຫຼາຍເພື່ອເພີ່ມຄວາມຄົບຖ້ວນ.

ຂໍ້ມູນສັງເຄາະ (synthetic data) ໝາຍເຖິງຂໍ້ມູນທີ່ສ້າງຂຶ້ນມາຢ່າງປອມໂດຍໃຊ້ກົດເກນ, ແບບຈຳລອງທາງສະຖິຕິ ຫຼື Generative AI ເປັນຕົ້ນ, ໂດຍບໍ່ໄດ້ກັອບປີ້ຂໍ້ມູນຈິງໂດຍກົງ. ບົດບາດຫຼັກຂອງຂໍ້ມູນສັງເຄາະໃນ Synthetic Test ສາມາດສະຫຼຸບໄດ້ 3 ຢ່າງດັ່ງນີ້:

• ເພີ່ມຈຳນວນການທົດສອບໃນໂດເມນທີ່ມີຂໍ້ມູນຈິງໜ້ອຍ
• ທຳການກວດສອບທີ່ໃກ້ຄຽງກັບການໃຊ້ງານຈິງໂດຍໃຊ້ຂໍ້ມູນທົດແທນທີ່ບໍ່ມີຂໍ້ມູນສ່ວນຕົວ
• ສ້າງ Edge case ຫຼື ຄວາມຜິດປົກກະຕິທີ່ເກີດຂຶ້ນໄດ້ຍາກໃນການດຳເນີນງານປົກກະຕິຂຶ້ນມາໂດຍເຈດຕະນາ

ກ່າວຄື: Synthetic Test ແມ່ນການປະສົມປະສານລະຫວ່າງ "ຂໍ້ມູນສັງເຄາະ × ການປະເມີນຜົນອັດຕະໂນມັດ" ໂດຍມີຂໍ້ມູນສັງເຄາະເປັນເຊື້ອເພີງນັ້ນເອງ.

ສິ່ງທີ່ມັກຈະສັບສົນກັບ Synthetic Test ຄື LLM-as-a-Judge. ທັງສອງຢ່າງນີ້ມີບົດບາດທີ່ແຕກຕ່າງກັນຢ່າງຊັດເຈນໃນການປະເມີນຜົນ AI.

ໃນທາງປະຕິບັດ ຈະມີການນຳທັງສອງຢ່າງມາປະສົມປະສານກັນ. ຂະບວນການທີ່ເປັນທົ່ວໄປຄືການໃຊ້ Synthetic Test ເພື່ອ "ສ້າງກໍລະນີການທົດສອບ 100 ລາຍການ" ແລະ ໃຊ້ LLM-as-a-Judge ເພື່ອ "ໃຫ້ຄະແນນການຕອບໂຕ້ທັງ 100 ລາຍການນັ້ນ". ສຳລັບການອອກແບບຕົວ Judge ເອງ ແລະ ວິທີການສ້າງ Judge Prompt ນັ້ນ ໄດ້ມີການອະທິບາຍຢ່າງລະອຽດໃນບົດຄວາມອື່ນທີ່ຊື່ວ່າ "LLM-as-a-Judge ແມ່ນຫຍັງ? ເຕັກນິກການປະເມີນຜົນ AI ດ້ວຍ AI ແລະ ການຈັດການກັບ Hallucination".

Generative AI ມັກຈະໃຫ້ຄຳຕອບທີ່ແຕກຕ່າງກັນເຖິງແມ່ນວ່າຈະມີການປ້ອນຂໍ້ມູນເຂົ້າແບບດຽວກັນກໍຕາມ. ດັ່ງນັ້ນ, ຈຶ່ງມີຄວາມຈຳເປັນທີ່ຈະຕ້ອງໃຊ້ຂໍ້ມູນສັງເຄາະ (Synthetic data) ເພື່ອຄາດການ ແລະ ກວດຫາການຫຼຸດລົງຂອງຄຸນນະພາບທີ່ບໍ່ສາມາດກວດພົບໄດ້ດ້ວຍຂໍ້ມູນຈິງພຽງຢ່າງດຽວ. ນອກຈາກນີ້, ດ້ວຍການເຄື່ອນໄຫວດ້ານກົດລະບຽບຕ່າງໆ ເຊັ່ນ: EU AI Act ທີ່ໄດ້ມີການບັງຄັບໃຊ້ຢ່າງເຕັມຮູບແບບແລ້ວ, ຂອບເຂດທີ່ກຳນົດໃຫ້ມີ "ການຍື່ນບັນທຶກການປະເມີນຜົນ" ກໍໄດ້ຂະຫຍາຍຕົວອອກໄປ ເຮັດໃຫ້ຄວາມຄົບຖ້ວນຂອງການທົດສອບດ້ວຍຂໍ້ມູນສັງເຄາະ (Synthetic test) ກາຍເປັນເງື່ອນໄຂເບື້ອງຕົ້ນທີ່ສຳຄັນສຳລັບນັກພັດທະນາ AI ໃນການຮອງຮັບການກວດສອບ.

ໃນຊອບແວແບບດັ້ງເດີມ, ການເກັບລວບລວມບັນທຶກການໃຊ້ງານຈິງ (Production logs) ສາມາດກວມເອົາຮູບແບບການປ້ອນຂໍ້ມູນທີ່ເປັນຕົວແທນໄດ້ເກືອບທັງໝົດ. ແຕ່ສຳລັບລະບົບ Generative AI, ມີ 3 ເຫດຜົນທີ່ວິທີດັ່ງກ່າວບໍ່ພຽງພໍ:

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

ປະການທີສອງ, ການປ້ອນຂໍ້ມູນແບບບໍ່ຫວັງດີ (Adversarial input) ເຊັ່ນ: Prompt injection, ຄວາມເສຍຫາຍໄດ້ເກີດຂຶ້ນແລ້ວໃນເວລາທີ່ຜູ້ໃຊ້ "ໄດ້ທົດລອງໃຊ້ງານຈິງ ແລະ ບັນທຶກໄວ້ໃນ Log". ການລໍຖ້າຂໍ້ມູນຈິງຈະເຮັດໃຫ້ແກ້ໄຂບໍ່ທັນການ, ຈຶ່ງຈຳເປັນຕ້ອງທົດລອງສະຖານະການໂຈມຕີລ່ວງໜ້າດ້ວຍຂໍ້ມູນສັງເຄາະ (ເຊິ່ງເປັນການຂະຫຍາຍແນວຄິດຂອງ Penetration testing ມາໃຊ້ກັບ AI).

ປະການທີສາມ, AI Agent ມີການສົນທະນາທີ່ຍາວນານ ເຊິ່ງລວມເຖິງການຮຽກໃຊ້ External API ແລະ ເຄື່ອງມືຕ່າງໆ. ການປະສົມປະສານຂອງກໍລະນີທີ່ຫາຍາກ (Edge cases) ຈະເພີ່ມທະວີຂຶ້ນເລື້ອຍໆ ເຮັດໃຫ້ອັດຕາການກວມເອົາຂໍ້ມູນຈາກບັນທຶກການໃຊ້ງານຈິງພຽງຢ່າງດຽວນັ້ນບໍ່ພຽງພໍສະເໝີ.

ການໃຊ້ຂໍ້ມູນສັງເຄາະ (Synthetic data) ຊ່ວຍໃຫ້ເຮົາສາມາດສ້າງການປ້ອນຂໍ້ມູນເຫຼົ່ານີ້ ເຊິ່ງເປັນ "ຂໍ້ມູນທີ່ບໍ່ປາກົດໃນຂໍ້ມູນຈິງ ຫຼື ບໍ່ສາມາດລໍຖ້າໃຫ້ມັນເກີດຂຶ້ນໄດ້" ມາເປັນການທົດສອບແບບສັງເຄາະ (Synthetic test) ໄດ້ຢ່າງອິດສະຫຼະ.

EU AI Act ທີ່ໄດ້ມີການບັງຄັບໃຊ້ຢ່າງເຕັມຮູບແບບນັ້ນ ໄດ້ກຳນົດໃຫ້ມີການບັນທຶກເອກະສານການທົດສອບ ແລະ ການປະເມີນຜົນສຳລັບລະບົບ AI ທີ່ມີຄວາມສ່ຽງສູງ. ໃນປະເທດຍີ່ປຸ່ນເອງ, ແນວທາງປະຕິບັດສຳລັບຜູ້ປະກອບການ AI ຂອງສຳນັກງານຄະນະລັດຖະມົນຕີ ລວມເຖິງຄຳແນະນຳຈາກກະຊວງເສດຖະກິດ, ການຄ້າ ແລະ ອຸດສາຫະກຳ (METI) ແລະ ກະຊວງພາຍໃນ ແລະ ການສື່ສານ (MIC) ກໍມີທິດທາງໃນການແນະນຳໃຫ້ມີການປະເມີນຜົນໂດຍອີງໃສ່ຄວາມສ່ຽງ (Risk-based approach).

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

ການທົດສອບແບບ Synthetic ບໍ່ແມ່ນການວັດແທກຕົວຊີ້ວັດຄຸນນະພາບພຽງຢ່າງດຽວ, ແຕ່ສາມາດຈັດການກັບ 3 ມຸມມອງຢ່າງປະສົມປະສານ ຄື: ຄຸນນະພາບດ້ານຟັງຊັນ, ຄວາມປອດໄພ ແລະ ຄວາມທົນທານ (Robustness). ການຈະໃຫ້ຄວາມສຳຄັນກັບມຸມມອງໃດນັ້ນ ແມ່ນຂຶ້ນຢູ່ກັບ Use case ຂອງລະບົບ AI, ແຕ່ຖ້າບໍ່ອອກແບບ Test case ໂດຍອີງໃສ່ 3 ແກນນີ້ເປັນຢ່າງໜ້ອຍ ກໍມີໂອກາດສູງທີ່ຈະກາຍເປັນ AI ທີ່ "ເບິ່ງຄືວ່າເຮັດວຽກໄດ້ ແຕ່ກັບພັງທະລາຍເມື່ອໃຊ້ງານຈິງ".

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

ເມື່ອວັດແທກຄຸນນະພາບຂອງການເຮັດວຽກດ້ວຍ Synthetic Test, ໃຫ້ສ້າງຮູບແບບຄຳຕອບທີ່ຖືກຕ້ອງ ແລະ ຮູບແບບຄຳຕອບທີ່ຜິດພາດທົ່ວໄປຂອງວຽກນັ້ນໆດ້ວຍຂໍ້ມູນສັງເຄາະ (Synthetic Data), ຈາກນັ້ນໃຫ້ກວດສອບວ່າ Judge ສາມາດແຍກແຍະທັງສອງຢ່າງນີ້ອອກຈາກກັນໄດ້. ໃນດ້ານການຈັດຕັ້ງປະຕິບັດ, ການກຳນົດແກນການໃຫ້ຄະແນນຂອງ Judge (ເຊັ່ນ: accuracy / faithfulness / completeness ແລະ ອື່ນໆ) ໄວ້ລ່ວງໜ້າ ແລະ ອອກແບບ Test Case ໃຫ້ສາມາດໄດ້ຄະແນນຕາມແກນດັ່ງກ່າວຈະມີຄວາມສະຖຽນກວ່າ.

ຄວາມປອດໄພແມ່ນມຸມມອງໜຶ່ງໃນການວັດແທກວ່າ AI ຈະບໍ່ "ຕອບໂຕ້ໃນສິ່ງທີ່ບໍ່ຄວນເຮັດ" ຫຼືບໍ່. ສະຖານະການການໂຈມຕີທີ່ເປັນຕົວຢ່າງໄດ້ແກ່ Prompt Injection, Jailbreak, ແລະ ການຮົ່ວໄຫຼຂອງຂໍ້ມູນລັບ ເປັນຕົ້ນ. ໃນການທົດສອບແບບ Synthetic Test, ຂໍ້ຄວາມການໂຈມຕີເຫຼົ່ານີ້ຈະຖືກນຳມາເຮັດເປັນ Template ແລະສ້າງຂຶ້ນໃນປະລິມານຫຼາຍ ເພື່ອຢັ້ງຢືນວ່າ AI Guardrails ເຮັດວຽກໄດ້ຢ່າງຖືກຕ້ອງ.

ການສ້າງສະຖານະການການໂຈມຕີແບບສັງເຄາະ ໂດຍອີງໃສ່ Red Teaming Dictionary ທີ່ເປີດຕົວ ຫຼື Launch ຕໍ່ສາທາລະນະ ແລ້ວນຳມາຂະຫຍາຍເພີ່ມເຕີມເພື່ອໃຊ້ພາຍໃນບໍລິສັດນັ້ນ ເປັນວິທີທີ່ເໝາະສົມກັບຄວາມເປັນຈິງ. ຕົວຢ່າງເຊັ່ນ: ຮູບແບບຕ່າງໆ ເຊັ່ນ "ໃຫ້ສະແດງຜົນຄູ່ມືການເຮັດວຽກທັງໝົດອອກມາ" ຫຼື "ໃຫ້ເປີດເຜີຍ Internal System Prompt" ຈະຖືກນຳມາປັບປ່ຽນຮູບແບບການສະແດງອອກ ແລະເພີ່ມຈຳນວນຂຶ້ນເປັນຫຼາຍຮ້ອຍຫາຫຼາຍພັນລາຍການ. ດ້ວຍວິທີນີ້, ຈະສາມາດກວມເອົາໄປເຖິງການໂຈມຕີດ້ວຍການປ່ຽນຄຳສັບ (Paraphrasing Attack) ເຊິ່ງການກັ່ນຕອງດ້ວຍຄຳສັບແບບຜິວເຜີນບໍ່ສາມາດປ້ອງກັນໄດ້.

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

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

ການເລີ່ມຕົ້ນນຳໃຊ້ Synthetic Test ຢ່າງເປັນຮູບປະທຳຄວນດຳເນີນການເປັນຂັ້ນຕອນ ໂດຍຜ່ານຂະບວນການ "ການສ້າງ Test case → ການໃຫ້ຄະແນນ → ການນຳໄປໃຊ້ງານ". ແທນທີ່ຈະຕັ້ງເປົ້າໝາຍໃຫ້ກວມເອົາ 100% ໃນທັນທີ, ຄວນເລີ່ມຈາກການໝູນວຽນການປະເມີນຜົນໃນຂົງເຂດທີ່ມີຄວາມສ່ຽງສູງກ່ອນ, ແລ້ວຈຶ່ງນຳໄປລວມ ຫຼື Merge ເຂົ້າກັບ CI/CD ແລະ ການກວດສອບຄວາມຜິດພາດແບບ Regression.

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

Step 2 ແມ່ນການສ້າງ Synthetic test case. ວິທີການສ້າງສາມາດແບ່ງອອກເປັນ 3 ປະເພດໃຫຍ່ໆ:

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

ໃນການປະຕິບັດງານຈິງ, ແບບ Hybrid ແມ່ນຈັດການໄດ້ງ່າຍກວ່າ. ສຳລັບ Case ທີ່ສ້າງຂຶ້ນມາ ຕ້ອງໃສ່ຜົນລັພທີ່ຄາດຫວັງ (ຫຼື ເກນການຕັດສິນຜ່ານ/ບໍ່ຜ່ານ) ໄວ້ສະເໝີ ເພື່ອໃຫ້ Judge ໃນຂັ້ນຕອນຕໍ່ໄປສາມາດໃຫ້ຄະແນນໄດ້.

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

Step 4 ແມ່ນການນຳເຂົ້າສູ່ການດຳເນີນງານຢ່າງຕໍ່ເນື່ອງ. Synthetic Test ບໍ່ແມ່ນການເຮັດພຽງຄັ້ງດຽວແລ້ວຈົບ, ແຕ່ຕ້ອງນຳມາເປັນ Regression Test ທີ່ເຮັດທຸກຄັ້ງທີ່ມີການປ່ຽນແປງ Prompt, ອັບເດດ Model, ຫຼື ອັບເດດ Knowledge Base. ຖ້າການດຳເນີນງານທີ່ວ່າ "ຖ້າຄະແນນບໍ່ຮອດເກນທີ່ກຳນົດ ຈະບລັອກການ Deploy ຂຶ້ນລະບົບຈິງ" ຖືກນຳມາໃຊ້ຢ່າງເປັນທາງການໃນ CI, ກໍຈະສາມາດຫຼຸດຜ່ອນການຕັດສິນຄຸນນະພາບໂດຍອີງໃສ່ບຸກຄົນໄດ້. ນອກຈາກນີ້, ຕ້ອງມີການເພີ່ມ Test Case ຢ່າງສະໝໍ່າສະເໝີ ແລະ ບັນຫາທີ່ພົບໃນລະບົບຈິງຈະຕ້ອງຖືກນຳມາລວມເຂົ້າໃນ Synthetic Test ຢ່າງແນ່ນອນ (ການເພີ່ມອັດຕາການກວມລວມໂດຍອີງໃສ່ເຫດການທີ່ເກີດຂຶ້ນຈິງ).

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

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

ມາດຕະການແກ້ໄຂຄື ຕ້ອງປະເມີນຜົນດ້ວຍທັງຂໍ້ມູນສັງເຄາະແລະຂໍ້ມູນຈິງສະເໝີ ພ້ອມທັງຕິດຕາມກວດກາຄວາມແຕກຕ່າງຂອງຄະແນນ. ຖ້າຫາກຄວາມແຕກຕ່າງນັ້ນຫ່າງກັນເກີນກຳນົດ, ໃຫ້ຖືວ່າເປັນສັນຍານບອກວ່າການກະຈາຍຕົວຂອງຂໍ້ມູນສັງເຄາະໄດ້ເບี่ยงເບນໄປຈາກຂໍ້ມູນຈິງ ແລະ ໃຫ້ດຳເນີນການສ້າງໃໝ່. ໃນທາງປະຕິບັດ, ການສຸ່ມຕົວຢ່າງຂໍ້ມູນຈາກ Log ການໃຊ້ງານຈິງປະມານ 50-100 ລາຍການໃນທຸກໆໄຕມາດ ເພື່ອນຳມາໃຫ້ຄະແນນຄູ່ຂະໜານກັບ Synthetic test ແມ່ນວິທີທີ່ເໝາະສົມທີ່ສຸດ.

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

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

Q1: ການທົດສອບແບບ Synthetic ແລະ unit test / e2e test ແບບດັ້ງເດີມ ຄວນນຳມາໃຊ້ແຕກຕ່າງກັນແນວໃດ?

unit test ແລະ e2e test ແມ່ນວິທີການຮັບປະກັນຄວາມຖືກຕ້ອງຂອງຊອບແວຢ່າງເດັດຂາດ ໂດຍທີ່ຂໍ້ມູນຂາເຂົ້າ ແລະ ຄ່າທີ່ຄາດຫວັງຈະມີຄວາມຄົງທີ່. ການທົດສອບແບບ Synthetic ແມ່ນການປະເມີນ "ການກະຈາຍ" ຂອງຄຸນນະພາບ ໂດຍອີງໃສ່ຄວາມບໍ່ແນ່ນອນຂອງ AI, ເຊິ່ງການຜ່ານການທົດສອບຈະຕັດສິນຈາກ "ອັດຕາສ່ວນການບັນລຸຄະແນນທີ່ຄາດຫວັງ". ໂດຍພື້ນຖານແລ້ວ ຄວນໃຊ້ຮ່ວມກັນໃນໂຄງການດຽວກັນ, ເຊິ່ງການແບ່ງໜ້າທີ່ໂດຍໃຊ້ການທົດສອບແບບ Synthetic ສະເພາະສ່ວນ AI ແລະ ໃຊ້ການທົດສອບແບບດັ້ງເດີມກັບ API ທີ່ຢູ່ອ້ອມຂ້າງນັ້ນ ແມ່ນວິທີທີ່ຈັດການໄດ້ງ່າຍກວ່າ.

Q2: LLM ທີ່ໃຊ້ສ້າງຂໍ້ມູນສັງເຄາະ (Synthetic data) ຄວນເປັນໂມເດວ (Model) ດຽວກັນກັບ AI ທີ່ຖືກປະເມີນຫຼືບໍ່?

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

Q3: ການທົດສອບແບບ Synthetic ຄວນກຽມກໍລະນີທົດສອບປະມານຈັກກໍລະນີ?

ຂຶ້ນຢູ່ກັບຄວາມກວ້າງຂອງ Use case, ແຕ່ໃນຊ່ວງເລີ່ມຕົ້ນ ຄວນຕັ້ງເປົ້າໝາຍໄວ້ທີ່ 300 ກໍລະນີ ເຊິ່ງປະກອບດ້ວຍ ຄຸນນະພາບການເຮັດວຽກ 100 ກໍລະນີ, ຄວາມປອດໄພ 100 ກໍລະນີ ແລະ ຄວາມທົນທານ (Robustness) 100 ກໍລະນີ. ສຳລັບການທົດສອບແບບ Smoke test ທີ່ໃຊ້ໃນ CI ທຸກຄັ້ງຄວນມີ 30-50 ກໍລະນີ, ແລະ ຄວນຕັ້ງເປົ້າໝາຍການປະເມີນຜົນແບບເຕັມຮູບແບບໃຫ້ໄດ້ເຖິງລະດັບ 1,000 ກໍລະນີ ພາຍໃນໄລຍະເວລາ 6 ເດືອນ ຫາ 1 ປີ ເຊິ່ງເປັນຄວາມຮູ້ສຶກທີ່ເໝາະສົມກັບການເຮັດວຽກຕົວຈິງ.

Q4: ສຳລັບການບໍລິການຫຼາຍພາສາ ຄວນສ້າງການທົດສອບແບບ Synthetic ແຍກຕາມແຕ່ລະພາສາຫຼືບໍ່?

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

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

ການນຳໃຊ້ມີ 4 ຂັ້ນຕອນພື້ນຖານຄື: "ການກຳນົດເປົ້າໝາຍການປະເມີນ → ການສ້າງກໍລະນີທົດສອບແບບສັງເຄາະ → ການໃຫ້ຄະແນນດ້ວຍ Judge → ການລວມເຂົ້າໃນ CI/CD". ຖ້າຫາກເອົາໃຈໃສ່ໃນເລື່ອງຄວາມລຳອຽງຂອງຂໍ້ມູນສັງເຄາະ ແລະ ຄວາມຕໍ່ເນື່ອງໃນການດຳເນີນງານ, ທ່ານກໍຈະສາມາດນຳໄປສູ່ການຮັບປະກັນຄຸນນະພາບໃນລະດັບການນຳໃຊ້ຈິງໄດ້ ໂດຍບໍ່ຢຸດຢູ່ພຽງແຕ່ຂັ້ນຕອນ PoC. ສຳລັບການອອກແບບ Judge ແລະ ວິທີການສ້າງ Prompt ໃຫ້ Judge, ກະລຸນາເບິ່ງຂໍ້ມູນເພີ່ມເຕີມໄດ້ທີ່ "LLM-as-a-Judge ແມ່ນຫຍັງ? ວິທີການປະເມີນຜົນລວມຂອງ AI ດ້ວຍ AI ແລະ ການຈັດຕັ້ງປະຕິບັດການກວດຫາ Hallucination".

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