ການປະສົມປະສານລະຫວ່າງ On-premises LLM ແລະ ການກັ່ນກອງແບບຈໍາລອງ (Model Distillation) ແມ່ນວິທີການບີບອັດຄວາມຮູ້ທີ່ LLM ຂະໜາດໃຫຍ່ (ຄູສອນ) ມີ ໃຫ້ໄປຢູ່ໃນແບບຈໍາລອງຂະໜາດນ້ອຍ (ນັກຮຽນ) ເພື່ອດໍາເນີນການພາຍໃນເຊີບເວີຂອງບໍລິສັດໂດຍບໍ່ຕ້ອງເພິ່ງພາ Cloud ພາຍນອກ. ສໍາລັບຜູ້ຮັບຜິດຊອບລະບົບຂໍ້ມູນຂ່າວສານ ແລະ ວິສະວະກອນ AI ທີ່ບໍ່ສາມາດສົ່ງຂໍ້ມູນໄປໃຫ້ Cloud API ໄດ້, ໃນບົດຄວາມນີ້ຈະອະທິບາຍຕັ້ງແຕ່ການສ້າງສະພາບແວດລ້ອມ ຈົນເຖິງການນໍາໃຊ້ແບບຈໍາລອງທີ່ຜ່ານການກັ່ນກອງໄປໃຊ້ງານຈິງ ໂດຍລຽງລໍາດັບຈາກການຄັດເລືອກແບບຈໍາລອງ, ການສ້າງຂໍ້ມູນ, ການຝຶກຝົນ (Training) ແລະ ການຫຼີກລ່ຽງຄວາມຜິດພາດ. ເນື່ອງຈາກມີການອະທິບາຍຄໍາສັບສະເພາະທາງໄປພ້ອມໆກັນ, ໂຄງສ້າງຂອງບົດຄວາມນີ້ຈຶ່ງຖືກອອກແບບມາໃຫ້ຜູ້ທີ່ບໍ່ແມ່ນຊ່ຽວຊານດ້ານການຮຽນຮູ້ຂອງເຄື່ອງຈັກ (Machine Learning) ກໍສາມາດເຂົ້າໃຈພາບລວມໄດ້.

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

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

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

ຖ້າຄິດວ່າ "ຖ້າຕ້ອງການເກັບຂໍ້ມູນໄວ້ພາຍໃນບໍລິສັດ ກໍພຽງແຕ່ໃຊ້ໂມເດວຂະໜາດໃຫຍ່ໃນລະບົບ On-premise ກໍພໍແລ້ວ" ກໍຈະຕ້ອງປະເຊີນກັບບັນຫາດ້ານຕົ້ນທຶນ. ການນຳໃຊ້ໂມເດວຂະໜາດໃຫຍ່ລະດັບແຖວໜ້າໃນລະບົບ On-premise ໂດຍກົງນັ້ນ ຈຳເປັນຕ້ອງມີ GPU ລາຄາແພງທີ່ມີ VRAM ຂະໜາດຫຼາຍຮ້ອຍ GB ຫຼາຍເຄື່ອງ ເຊິ່ງບໍ່ແມ່ນເລື່ອງທີ່ເປັນໄປໄດ້ສຳລັບຫຼາຍບໍລິສັດ.

ການກັ່ນກອງໂມເດວ (Model Distillation) ຈະຊ່ວຍຫຼຸດຂະໜາດຮາດແວທີ່ຈຳເປັນລົງຢ່າງຫຼວງຫຼາຍ ໂດຍການບີບອັດຄວາມຮູ້ຈາກໂມເດວຂະໜາດໃຫຍ່ (ຄູສອນ) ໃຫ້ກາຍເປັນໂມເດວຂະໜາດນ້ອຍ (ນັກຮຽນ) ທີ່ມີຂະໜາດພຽງຫຼັກພັນລ້ານພາຣາມິເຕີ. ເຖິງວ່າຈະມີ ການແລກປ່ຽນ ຫຼື Trade-off ທີ່ເຮັດໃຫ້ປະສິດທິພາບໂດຍລວມຫຼຸດລົງເມື່ອທຽບກັບໂມເດວຄູສອນ ແຕ່ຖ້າຫາກເນັ້ນສະເພາະວຽກງານທີ່ບໍລິສັດຕ້ອງການນຳໃຊ້ ກໍສາມາດຮັກສາຄວາມແມ່ນຍຳທີ່ນຳໄປໃຊ້ງານໄດ້ຈິງ. ເຖິງຈະມີຄ່າໃຊ້ຈ່າຍຄົງທີ່ໃນການຊື້ GPU ແຕ່ເນື່ອງຈາກບໍ່ມີຄ່າໃຊ້ຈ່າຍແບບຈ່າຍຕາມການໃຊ້ງານ (Pay-as-you-go) ຕໍ່ Token, ຍິ່ງມີຄວາມຖີ່ໃນການນຳໃຊ້ສູງເທົ່າໃດ ກໍຍິ່ງໄດ້ປຽບໃນດ້ານຕົ້ນທຶນລວມ (TCO) ຫຼາຍເທົ່ານັ້ນ. ຈຸດຄຸ້ມທຶນຈະຂຶ້ນຢູ່ກັບໂມເດວທີ່ເລືອກ ແລະ ປະລິມານການນຳໃຊ້ ດັ່ງນັ້ນ ການຄິດໄລ່ຄາດຄະເນຕາມປະລິມານການນຳໃຊ້ຂອງບໍລິສັດຕົນເອງຈຶ່ງເປັນສິ່ງສຳຄັນ.

ແບບຈຳລອງພາສາຂະໜາດນ້ອຍ (SLM: Small Language Model, ຂະໜາດຫຼັກຮ້ອຍລ້ານເຖິງສິບກວ່າຕື້ພາຣາມິເຕີ) ມີພາຣາມິເຕີໜ້ອຍ ຈຶ່ງເຮັດໃຫ້ການປະມວນຜົນໄວ ແລະ ມີຄວາມໜ່ວງ (Latency) ຕ່ຳ. ສາມາດຈັດການກັບການປະມວນຜົນແບບ Batch ຫຼື ການຮ້ອງຂໍພ້ອມກັນໃນສະພາບແວດລ້ອມ On-premise ໄດ້ງ່າຍ ແລະ ຖ້າໃຊ້ຮ່ວມກັບການເຮັດ Quantization ກໍຈະຍິ່ງເຮັດໃຫ້ຕົວແບບມີນ້ຳໜັກເບົາຂຶ້ນ.

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

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

ໃນການຝຶກອົບຮົມແບບ Distillation, GPU ຈະຖືກນຳໃຊ້ທັງໃນການອະນຸມານຂອງຕົວແບບຄູ (ການສ້າງ Soft label) ແລະ ການຮຽນຮູ້ຂອງຕົວແບບນັກຮຽນ. ການນຳໃຊ້ງານຈິງ (ສະເພາະການອະນຸມານ) ຈະມີພາລະໜັກໜ່ວງໜ້ອຍກວ່າການຝຶກອົບຮົມ ແລະ ສາມາດຫຼຸດຄວາມຕ້ອງການລົງໄດ້ຕື່ມອີກດ້ວຍການເຮັດ Quantization.

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

ການເລືອກ Teacher Model ພຽງຢ່າງດຽວ ກໍສາມາດຕັດສິນໄດ້ວ່າຈະມີຄວາມສ່ຽງທາງກົດໝາຍຫຼືບໍ່. ກັບດັກທຳອິດທີ່ຄວນລະວັງຄື ການນຳເອົາຜົນລວມ (Output) ຈາກ Model ທີ່ໃຫ້ບໍລິການຜ່ານ Commercial API ມາໃຊ້ເປັນ Teacher Signal ເພື່ອຝຶກຝົນ Model ຂອງບໍລິສັດຕົນເອງໂດຍກົງ. ຜູ້ໃຫ້ບໍລິການຫຼັກໆໄດ້ລະບຸໄວ້ຢ່າງຊັດເຈນໃນເງື່ອນໄຂການໃຊ້ງານວ່າ ຫ້າມນຳເອົາຜົນລວມໄປໃຊ້ໃນ "ການພັດທະນາ Model ທີ່ເປັນຄູ່ແຂ່ງ" ເຊິ່ງຫາກເຂົ້າຂ່າຍນີ້ ອາດຖືວ່າເປັນການລະເມີດຂໍ້ຕົກລົງ (ທັງ OpenAI ແລະ Anthropic ລ້ວນແຕ່ຫ້າມບໍ່ໃຫ້ໃຊ້ຜົນລວມໃນການຝຶກຝົນ Model ທີ່ເປັນຄູ່ແຂ່ງ ຫຼື ລອກແບບ). ໃນຄວາມເປັນຈິງ, ກໍມີລາຍງານກ່ຽວກັບກໍລະນີທີ່ກາຍເປັນບັນຫາໃຫຍ່ເນື່ອງຈາກການລະເມີດຂໍ້ຕົກລົງດັ່ງກ່າວ.

ວິທີທີ່ເປັນຈິງໃນການຫຼີກລ່ຽງຄວາມສ່ຽງນີ້ ຄືການໃຊ້ Open-source Model ທີ່ມີໃບອະນຸຍາດອະນຸຍາດໃຫ້ເຮັດ Commercial Distillation ມາເປັນ Teacher. ຢ່າງໃດກໍຕາມ, ເຖິງຈະເປັນ Open-source ແຕ່ໃບອະນຸຍາດກໍບໍ່ໄດ້ຄືກັນໝົດ. MIT ຫຼື Apache 2.0 (ເຊັ່ນ DeepSeek, Qwen, Mistral, Phi, ແລະອື່ນໆ) ມີຄວາມຍືດຫຍຸ່ນຂ້ອນຂ້າງສູງ ແລະ ນຳໃຊ້ທາງການຄ້າໄດ້ງ່າຍ, ໃນຂະນະທີ່ Llama ໃຊ້ໃບອະນຸຍາດຊຸມຊົນສະເພາະຂອງ Meta ເຊິ່ງຜູ້ໃຫ້ບໍລິການທີ່ມີຜູ້ໃຊ້ງານປະຈຳຕໍ່ເດືອນ (MAU) ຈຳນວນຫຼາຍຫຼາຍຈຳເປັນຕ້ອງຂໍອະນຸຍາດແຍກຕ່າງຫາກ ແລະ ຍັງມີຂໍ້ຈຳກັດດ້ານພູມິສາດອີກດ້ວຍ. ສ່ວນ Gemma ແມ່ນມີເງື່ອນໄຂວ່າຕ້ອງຍອມຮັບເງື່ອນໄຂການໃຊ້ງານຂອງ Google. ໃນການຄັດເລືອກ, ຕ້ອງກວດສອບໜ້າໃບອະນຸຍາດຂອງແຕ່ລະ Model (ຈາກ Repository ທາງການ ຫຼື ແຫຼ່ງແຈກຢາຍ) ເປັນແຫຼ່ງຂໍ້ມູນຫຼັກສະເໝີ ແລະ ຕ້ອງຜ່ານການກວດສອບທາງກົດໝາຍ. ເນື່ອງຈາກເງື່ອນໄຂໃບອະນຸຍາດມີການອັບເດດຢູ່ສະເໝີ, ຫ້າມນຳຂໍ້ມູນເກົ່າມາໃຊ້ໂດຍບໍ່ໄດ້ກວດສອບ.

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

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

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

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

※ ເນື່ອງຈາກໃບອະນຸຍາດ ແລະ ເງື່ອນໄຂຕ່າງໆມີການອັບເດດຢູ່ສະເໝີ, ຄວນກວດສອບຂໍ້ມູນຫຼັກຫຼ້າສຸດທຸກຄັ້ງໃນເວລາເລືອກໃຊ້.

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

ສຳລັບນັກຮຽນແບບຈຳລອງ (Student model), ການປັບແຕ່ງໃຫ້ເປັນແບບຈຳລອງຂະໜາດນ້ອຍທີ່ເນັ້ນສະເພາະດ້ານ ຈະເໝາະສົມກວ່າການຫຍໍ້ຂະໜາດແບບຈຳລອງຂະໜາດໃຫຍ່ແບບທົ່ວໄປລົງທັງໝົດ. ຄວາມສຳພັນລະຫວ່າງການນຳໃຊ້ທີ່ເປັນຕົວຢ່າງ ແລະ ຂະໜາດມີດັ່ງນີ້: ສຳລັບການຈັດປະເພດເອກະສານ ຫຼື ການສະກັດຂໍ້ມູນສຳຄັນ, ຂະໜາດລະດັບຫຼາຍຮ້ອຍລ້ານຫາຫຼາຍພັນລ້ານ (B) ພາຣາມິເຕີກໍພຽງພໍແລ້ວ. ສຳລັບການຖາມ-ຕອບເອກະສານພາຍໃນບໍລິສັດ, ການນຳໃຊ້ຮ່ວມກັບ RAG (Retrieval-Augmented Generation) ໂດຍໃຫ້ສ່ວນການສ້າງເນື້ອຫາເປັນໜ້າທີ່ຂອງນັກຮຽນແບບຈຳລອງຂະໜາດກາງ ແມ່ນໂຄງສ້າງທີ່ເປັນໄປໄດ້ຫຼາຍທີ່ສຸດ. ການສະຫຼຸບເນື້ອຫາຄວນໃຊ້ຂະໜາດກາງ, ສ່ວນການຕື່ມລະຫັດ (Code completion) ຄວນໃຊ້ແບບຈຳລອງທີ່ຜ່ານການຝຶກຝົນລ່ວງໜ້າ (Pre-trained model) ທີ່ເນັ້ນດ້ານລະຫັດໂດຍສະເພາະເປັນພື້ນຖານ.

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

ສະຫຼຸບກໍຄື, ການເລືອກຂະໜາດທີ່ນ້ອຍທີ່ສຸດທີ່ຕອບໂຈດຄວາມຕ້ອງການ ໂດຍອີງໃສ່ 2 ແກນຫຼັກ ຄື "Latency ທີ່ຍອມຮັບໄດ້" ແລະ "ຄວາມແມ່ນຍຳທີ່ຕ້ອງການ" ແມ່ນວິທີການທີ່ເປັນມາດຕະຖານ.

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

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

Soft Label ແມ່ນການແຈກຢາຍຄວາມໜ້າຈະເປັນທີ່ຕົວແບບຄູ (Teacher model) ມອບໃຫ້ແຕ່ລະຄລາສ ຫຼື ໂທເຄັນ. ເມື່ອປຽບທຽບກັບ Hard label ທີ່ຕັດສິນວ່າ "ມີຄຳຕອບທີ່ຖືກຕ້ອງພຽງໜຶ່ງດຽວ", Soft label ຈະມີຂໍ້ມູນກ່ຽວກັບວ່າຄູເບິ່ງແຕ່ລະທາງເລືອກດ້ວຍລະດັບຄວາມໝັ້ນໃຈຫຼາຍໜ້ອຍພຽງໃດ.

ຂັ້ນຕອນການສ້າງມີດັ່ງນີ້: ① ກຽມຂໍ້ມູນນຳເຂົ້າທີ່ເປັນຕົວແທນ. ② ໃຊ້ຕົວແບບຄູໃນການອະນຸມານ (Inference) ແລະ ບັນທຶກຄ່າ Logits ຫຼື ການແຈກຢາຍຄວາມໜ້າຈະເປັນ (ໃນຂັ້ນຕອນນີ້ ໃຫ້ເພີ່ມ Temperature parameter ທີ່ກ່າວເຖິງໃນພາຍຫຼັງ ເພື່ອເຮັດໃຫ້ການແຈກຢາຍມີຄວາມລຽບງ່າຍຂຶ້ນ). ③ ໃຊ້ສິ່ງນີ້ເປັນເປົ້າໝາຍໃນການຮຽນຮູ້ຂອງນັກຮຽນ (Student model). ເນື່ອງຈາກ Soft label ມີຂໍ້ມູນທີ່ໃກ້ຄຽງກັບ "ເຫດຜົນທີ່ຄູຕັດສິນໃຈແບບນັ້ນ", ມັນຈຶ່ງຊ່ວຍໃຫ້ປະສິດທິພາບການປັບໃຊ້ທົ່ວໄປ (Generalization performance) ຂອງນັກຮຽນສູງຂຶ້ນຫຼາຍກວ່າການຮຽນຮູ້ດ້ວຍ Hard label ພຽງຢ່າງດຽວ. ຢ່າງໃດກໍຕາມ, ການສ້າງ Soft label ຕ້ອງມີຕົ້ນທຶນໃນການອະນຸມານຂອງຄູ, ສະນັ້ນ ຄວນດຳເນີນການໂດຍພິຈາລະນາຄວາມສົມດຸນລະຫວ່າງປະລິມານຂໍ້ມູນທີ່ຈຳເປັນ ແລະ ຊັບພະຍາກອນການຄຳນວນ.

ເພື່ອປ່ຽນເອກະສານທີ່ກະຈັດກະຈາຍຢູ່ໃນບໍລິສັດ (PDF, Office, Wiki ພາຍໃນ, ປີ້ສອບຖາມຂໍ້ມູນ, ແລະອື່ນໆ) ໃຫ້ກາຍເປັນຂໍ້ມູນສຳລັບການຮຽນຮູ້, ຕ້ອງສ້າງ ຂະບວນການ ຫຼື Pipeline ເປັນຂັ້ນຕອນດັ່ງນີ້: ① ການສະກັດຂໍ້ມູນ: ປ່ຽນໃຫ້ເປັນຂໍ້ຄວາມໂດຍໃຊ້ Parser ຫຼື OCR (ວິທີການໃຊ້ LLM ເພື່ອປ່ຽນ PDF ທີ່ບັນທຶກເປັນຮູບພາບໃຫ້ເປັນຂໍ້ຄວາມແມ່ນມີປະສິດທິພາບ). ② ການທຳຄວາມສະອາດຂໍ້ມູນ: ລຶບສ່ວນຫົວ, ສ່ວນທ້າຍ ແລະ ຂໍ້ມູນທີ່ຊ້ຳຊ້ອນອອກ. ③ ການຈັດໂຄງສ້າງ: ປັບຮູບແບບໃຫ້ເປັນຮູບແບບ QA ຫຼື ຮູບແບບ "ຄຳສັ່ງ—ການຕອບໂຕ້". ④ ການຕິດປ້າຍກຳກັບລະດັບຄວາມລັບ: ກຳນົດປະເພດຂອງຂໍ້ມູນ. ⑤ ການແບ່ງຂໍ້ມູນ: ແບ່ງອອກເປັນຂໍ້ມູນສຳລັບການຮຽນຮູ້ ແລະ ຂໍ້ມູນສຳລັບການກວດສອບ.

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

ເຖິງແມ່ນວ່າຈະດຳເນີນການຢູ່ເທິງ On-premise ແລ້ວ, ແຕ່ຖ້າຫາກຂໍ້ມູນທີ່ໃຊ້ໃນການຝຶກຝົນ (Training data) ມີຂໍ້ມູນສ່ວນບຸກຄົນ ຫຼື ຂໍ້ມູນລັບລວມຢູ່, ກໍຍັງມີຄວາມສ່ຽງທີ່ໂມເດວຈະຈົດຈຳຂໍ້ມູນເຫຼົ່ານັ້ນໄວ້ ແລະ ນຳອອກມາສະແດງຜົນໃນພາຍຫຼັງ. ການຮັບມືກັບບັນຫານີ້ຄວນພິຈາລະນາເປັນ 3 ຂັ້ນຕອນ: ① ກວດຫາ PII (ຊື່-ນາມສະກຸນ, ຂໍ້ມູນຕິດຕໍ່, ເລກບັນຊີ, ແລະ ອື່ນໆ) ແລ້ວທຳການປິດບັງ (Masking) ຫຼື ເຮັດໃຫ້ເປັນນາມແຝງ. ② ພິຈາລະນາຄັດເລືອກວ່າຄວນນຳຂໍ້ມູນນັ້ນມາເປັນສ່ວນໜຶ່ງຂອງການຝຶກຝົນຫຼືບໍ່ ໂດຍອີງຕາມລະດັບຄວາມລັບຂອງຂໍ້ມູນ. ③ ຫຼັງຈາກຝຶກຝົນສຳເລັດແລ້ວ, ໃຫ້ທຳການທົດສອບແບບ Red teaming ເພື່ອກວດສອບວ່າໂມເດວຈະບໍ່ເປີດເຜີຍຂໍ້ມູນລັບອອກມາ.

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

ຈຸດສຳຄັນ ຫຼື ແກນຫຼັກ ຂອງການຝຶກຝົນແມ່ນຢູ່ທີ່ການອອກແບບ Distillation Loss (ການສູນເສຍທີ່ເກີດຈາກການຮຽນແບບຄູຝຶກ) ແລະ ການຕິດຕາມກວດກາເພື່ອຢຸດການ Overfitting. ການອອກແບບໃນສ່ວນນີ້ແມ່ນມີຄວາມສຳຄັນກວ່າການສັ່ງງານຄຳສັ່ງດ້ວຍຕົນເອງ ເພາະມັນເປັນຕົວຕັດສິນຄວາມຖືກຕ້ອງໃນຂັ້ນສຸດທ້າຍ.

ຟັງຊັນການສູນເສຍ (Loss function) ຂອງການກັ່ນຕອງ (Distillation) ໂດຍທົ່ວໄປແລ້ວຈະຖືກອອກແບບໂດຍການລວມເອົາ 2 ສ່ວນເຂົ້າດ້ວຍກັນ. ສ່ວນທຳອິດແມ່ນສ່ວນທີ່ເຮັດໃຫ້ຜົນລວມຂອງນັກຮຽນ (Student) ເຂົ້າໃກ້ກັບ Soft label ຂອງຄູ (Teacher), ເຊິ່ງມັກຈະໃຊ້ KL Divergence ເພື່ອວັດແທກໄລຍະຫ່າງລະຫວ່າງການກະຈາຍຄວາມໜ້າຈະເປັນ (Probability distribution). ສ່ວນທີສອງແມ່ນ Cross-entropy ແບບປົກກະຕິທີ່ເຮັດໃຫ້ຜົນລວມຂອງນັກຮຽນເຂົ້າໃກ້ກັບຄຳຕອບທີ່ຖືກຕ້ອງ (Hard label).

ໃນຈຸດນີ້, ພາຣາມິເຕີອຸນຫະພູມ T ຈະມີບົດບາດສຳຄັນ. T ເປັນຕົວປັບຄວາມລຽບຂອງ Softmax, ຍິ່ງເພີ່ມຄ່າ T ຫຼາຍເທົ່າໃດ ການກະຈາຍຄວາມໜ້າຈະເປັນຂອງຄູກໍຈະຍິ່ງລຽບຂຶ້ນ, ເຮັດໃຫ້ "ຄວາມຮູ້ໂດຍນິໄສ" (Implicit knowledge) ເຊິ່ງເປັນຄວາມສຳພັນລະຫວ່າງຄລາສຕ່າງໆ ສົ່ງຕໍ່ໄປໃຫ້ນັກຮຽນໄດ້ງ່າຍຂຶ້ນ. ໃນການປະຕິບັດງານຕົວຈິງ, ເຮົາຈະປັບຄ່າ T ນີ້ ແລະ ຄ່າສຳປະສິດນ້ຳໜັກຂອງ 2 ສ່ວນດັ່ງກ່າວ (ເຊັ່ນ α) ໂດຍຜ່ານການຄົ້ນຫາ Hyperparameter. ຖ້າ T ສູງເກີນໄປ ຂໍ້ມູນຈະເຈືອຈາງລົງ, ແລະຖ້າຕ່ຳເກີນໄປ ມັນຈະເຂົ້າໃກ້ກັບ Hard label, ດັ່ງນັ້ນຈຶ່ງຕ້ອງຊອກຫາຈຸດທີ່ເໝາະສົມທີ່ສຸດໂດຍການເບິ່ງຄວາມຖືກຕ້ອງໃນຊຸດຂໍ້ມູນກວດສອບ (Validation set). ເຖິງແມ່ນວ່າຈະບໍ່ເຂົ້າໃຈທິດສະດີຢ່າງຖ່ອງແທ້, ແຕ່ຖ້າຈື່ໄວ້ວ່າ "T ແລະ ນ້ຳໜັກແມ່ນສິ່ງທີ່ຕ້ອງປັບແຕ່ງ", ກໍສາມາດເລີ່ມຕົ້ນການປະຕິບັດງານ (Implementation) ໄດ້.

ການຝຶກຝົນແບບ On-premise ໂດຍທົ່ວໄປແລ້ວມັກຈະສ້າງຂຶ້ນໂດຍອີງໃສ່ PyTorch ແລະ ກຸ່ມຫໍສະໝຸດ Hugging Face. ສຳລັບການຮຽນຮູ້ແບບກະຈາຍ (Distributed Learning) ຈະໃຊ້ເຄື່ອງມືຕ່າງໆເຊັ່ນ accelerate ຫຼື DeepSpeed ຄວບຄູ່ກັນໄປ. ໂຄງຮ່າງຫຼັກຂອງການປະມວນຜົນມີດັ່ງນີ້:

1. ໂຫຼດ Teacher model ແລະ Student model
2. ສ້າງ Soft label ລ່ວງໜ້າ (ຫຼື ກັ່ນກອງແບບ On-the-fly)
3. ກຳນົດ Custom distillation loss ຂອງ KL divergence + Cross entropy
4. ດຳເນີນການຝຶກຝົນ (Training loop) ແລະ ບັນທຶກ Checkpoint ດ້ວຍຕົວຊີ້ວັດການກວດສອບ

ສຳລັບແນວຄິດໃນການຕັ້ງຄ່າ, ຄວນເລີ່ມຕົ້ນຈາກ Learning rate ທີ່ນ້ອຍ, ສ່ວນ Batch size ໃຫ້ປັບຕາມ VRAM ໂດຍໃຊ້ Gradient accumulation ເພື່ອໃຫ້ໄດ້ Batch ທີ່ມີປະສິດທິພາບ ແລະ ໃຊ້ Mixed precision (fp16/bf16) ເພື່ອປະຢັດໜ່ວຍຄວາມຈຳ. ຖ້າຕ້ອງການຫຼຸດຕົ້ນທຶນໃນການປັບແຕ່ງ (Fine-tuning) ຂອງ Student model, ໃຫ້ໃຊ້ວິທີ PEFT ເຊັ່ນ LoRA ຄວບຄູ່ກັນໄປ. ໃນສະພາບແວດລ້ອມແບບ Offline ຢ່າງສົມບູນ, ຈຳເປັນຕ້ອງດາວໂຫຼດ Model ແລະ Package ທີ່ກ່ຽວຂ້ອງໄວ້ທີ່ Mirror ພາຍໃນບໍລິສັດລ່ວງໜ້າ. ເນື່ອງຈາກຄຳສັ່ງ ແລະ Argument ທີ່ລະອຽດຈະປ່ຽນແປງໄປຕາມເວີຊັນຂອງ Framework, ດັ່ງນັ້ນໃນເວລາປະຕິບັດງານຈິງ ຕ້ອງອ້າງອີງເອກະສານທາງການຂອງເວີຊັນນັ້ນໆສະເໝີ.

ໃນລະຫວ່າງການຝຶກຝົນ (Training), ໃຫ້ຕິດຕາມຫຼາຍຕົວຊີ້ວັດໄປພ້ອມໆກັນ ເຊັ່ນ: ຄ່າ Loss ຂອງການຮຽນຮູ້ ແລະ ການກວດສອບ, ລາຍລະອຽດຂອງ Distillation Loss ແລະ Task Loss, ລວມເຖິງຄວາມຖືກຕ້ອງຂອງວຽກງານ (ເຊັ່ນ: accuracy ຫຼື F1) ໂດຍອີງໃສ່ຂໍ້ມູນການປະເມີນຜົນຂອງບໍລິສັດ.

ການຕັດສິນໃຈໃນການຢຸດການຝຶກຝົນໄວ (Early stopping) ໂດຍພື້ນຖານແລ້ວແມ່ນໃຫ້ຢຸດກ່ອນທີ່ຄ່າ Validation Loss ຈະຢຸດຫຼຸດລົງ ແລະ ເລີ່ມປັບຕົວສູງຂຶ້ນ ເພາະການທີ່ຄ່າ Loss ສູງຂຶ້ນນັ້ນເປັນສັນຍານຂອງການເກີດ Overfitting. ຢ່າງໃດກໍຕາມ, ການເບິ່ງພຽງແຕ່ຄ່າ Loss ອາດມີຄວາມສ່ຽງ ເນື່ອງຈາກບາງຄັ້ງເຖິງແມ່ນວ່າຄ່າ Loss ຈະຫຼຸດລົງ ແຕ່ເມື່ອເບິ່ງຕົວຢ່າງຜົນລັພທີ່ອອກມາແທ້ໆ ຄຸນນະພາບອາດຈະຫຼຸດລົງໄດ້. ດັ່ງນັ້ນ, ຄວນສ້າງນິໄສໃນການກວດສອບຕົວຊີ້ວັດຂອງວຽກງານຕົວຈິງ ແລະ ຕົວຢ່າງຜົນລັພດ້ວຍຕາໃນທຸກໆ Epoch. ຄວນເກັບຮັກສາ Checkpoint ໄວ້ຫຼາຍອັນ ແລະ ໃນທີ່ສຸດໃຫ້ເລືອກອັນທີ່ມີຕົວຊີ້ວັດການກວດສອບດີທີ່ສຸດ. ຈຸດທີ່ວ່າ "Epoch ສຸດທ້າຍອາດຈະບໍ່ແມ່ນອັນທີ່ດີທີ່ສຸດສະເໝີໄປ" ເປັນເລື່ອງທີ່ເບິ່ງຄືງ່າຍດາຍ ແຕ່ມັກຈະເຂົ້າໃຈຜິດກັນໄດ້ງ່າຍ.

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

ຖ້ານັກຮຽນ (Student) ມີຂະໜາດນ້ອຍເກີນໄປ ຫຼື ຄູ (Teacher) ມີຂະໜາດໃຫຍ່ເກີນໄປ, ນັກຮຽນອາດຈະບໍ່ສາມາດຮັບຄວາມຮູ້ໄດ້ຢ່າງຄົບຖ້ວນ ເຮັດໃຫ້ຄວາມຖືກຕ້ອງຫຼຸດລົງຢ່າງຫຼວງຫຼາຍ. ປະກົດການນີ້ເອີ້ນວ່າ "ຊ່ອງຫວ່າງດ້ານຄວາມຈຸ" (Capacity Gap). ທາງເລືອກໃນການແກ້ໄຂມີຫຼາຍວິທີຄື: ① ເພີ່ມຂະໜາດຂອງນັກຮຽນຂຶ້ນອີກຂັ້ນໜຶ່ງ. ② ຈຳກັດຂອບເຂດຂອງວຽກງານ (Task) ໂດຍຍອມປະລະຄວາມສາມາດໃນການນຳໃຊ້ທີ່ຫຼາກຫຼາຍ ແລ້ວຫັນມາເນັ້ນສະເພາະທາງ. ③ ນຳໃຊ້ການກັ່ນຕອງແບບເປັນຂັ້ນຕອນ (Teacher Assistant) ໂດຍການນຳແບບຈຳລອງຂະໜາດກາງມາຂັ້ນກາງໄວ້. ④ ເພີ່ມປະລິມານຂໍ້ມູນໃນການກັ່ນຕອງ ຫຼື ຍົກລະດັບຄຸນນະພາບຂອງຂໍ້ມູນ. ⑤ ນຳໃຊ້ວິທີການທີ່ບໍ່ພຽງແຕ່ປັບຜົນລວມ (Output) ເທົ່ານັ້ນ ແຕ່ຍັງປັບຄຸນລັກສະນະຂອງຊັ້ນກາງ (Intermediate layer) ໃຫ້ສອດຄ່ອງກັນອີກດ້ວຍ.

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

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

ວິທີການຫຼີກລ່ຽງມີດັ່ງນີ້: (1) ຮັບປະກັນຄວາມຫຼາກຫຼາຍຂອງຂໍ້ມູນ (ກວມເອົາການແຈກຢາຍຂອງຂໍ້ມູນນຳເຂົ້າໃນການເຮັດວຽກຕົວຈິງໃຫ້ກວ້າງຂວາງ), (2) ນຳໃຊ້ການ Regularization (ເຊັ່ນ: dropout, weight decay, early stopping), (3) ປະສົມຂໍ້ມູນທົ່ວໄປກັບຂໍ້ມູນພາຍໃນບໍລິສັດເພື່ອຝຶກສອນ ເພື່ອຮັກສາຄວາມສາມາດທາງພາສາຂັ້ນພື້ນຖານ, (4) ເຮັດການປະເມີນຜົນຄືນໃໝ່ເປັນໄລຍະ ແລະ ເຮັດການຝຶກສອນໃໝ່ຫາກຈຳເປັນ. ຫຼັງຈາກເປີດຕົວ ຫຼື Launch ໃຊ້ງານຈິງແລ້ວ ຕ້ອງຕິດຕາມກວດກາ "Drift" ເຊິ່ງເປັນພາວະທີ່ຄວາມຖືກຕ້ອງຫຼຸດລົງເນື່ອງຈາກການປ່ຽນແປງຂອງແນວໂນ້ມຂໍ້ມູນນຳເຂົ້າ. ສຸດທ້າຍ, ຂໍ້ແນະນຳດ້ານການດຳເນີນງານໜຶ່ງຢ່າງຄື: ໂມເດວ Distillation ບໍ່ແມ່ນສ້າງແລ້ວຈົບໄປ ແຕ່ການວາງໂຄງສ້າງໂດຍມີເງື່ອນໄຂວ່າຕ້ອງມີການອັບເດດຂໍ້ມູນປະເມີນຜົນ ແລະ ເຮັດການ Distillation ຊ້ຳຢ່າງຕໍ່ເນື່ອງ ຄືເງື່ອນໄຂສຳຄັນຂອງການໃຊ້ງານ On-premise AI ໃຫ້ຍາວນານ.