Fine-tuning ແມ່ນວິທີການປັບແຕ່ງນ້ຳໜັກພາຣາມິເຕີ (Weight parameters) ຂອງແບບຈຳລອງພາສາຂະໜາດໃຫຍ່ (LLM) ທີ່ມີຢູ່ແລ້ວ ໂດຍຜ່ານການຮຽນຮູ້ເພີ່ມເຕີມ ເພື່ອໃຫ້ເໝາະສົມກັບວຽກງານ ຫຼື ໂດເມນສະເພາະ. ໃນບົດຄວາມນີ້, ພວກເຮົາຈະມາຈັດລະບຽບເງື່ອນໄຂໃນການຕັດສິນໃຈວ່າບໍລິສັດ B2B ຄວນພັດທະນາແບບຈຳລອງຂອງຕົນເອງຫຼືບໍ່ ໂດຍພິຈາລະນາຈາກຄວາມສຳພັນລະຫວ່າງ Prompt Engineering, RAG ແລະ PEFT.

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

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

Fine-tuning ແມ່ນເຕັກນິກທີ່ເປັນຕົວແທນໃນການປັບແຕ່ງ LLM ແບບທົ່ວໄປໃຫ້ເຂົ້າກັບບໍລິບົດວຽກງານສະເພາະຂອງບໍລິສັດ. ກ່ອນອື່ນໝົດ, ພວກເຮົາຈະມາຈັດລະບຽບຄໍານິຍາມ ແລະ ຄວາມສຳພັນກັບເຕັກນິກທີ່ກ່ຽວຂ້ອງຢ່າງ Prompt Engineering ແລະ RAG, ພ້ອມທັງເບິ່ງເຫດຜົນທາງໂຄງສ້າງທີ່ເຮັດໃຫ້ບໍລິສັດ B2B ໃຫ້ຄວາມສົນໃຈ.

Fine-tuning (ການປັບແຕ່ງລະອຽດ) ແມ່ນເຕັກນິກການນຳເອົາຂໍ້ມູນຂອງບໍລິສັດມາຝຶກຝົນເພີ່ມເຕີມໃຫ້ກັບຕົວແບບພາສາທີ່ຜ່ານການຮຽນຮູ້ມາກ່ອນ (Pre-trained language model) ເພື່ອປັບຮູບແບບການສະແດງຜົນ ແລະ ການໃຊ້ຄຳສັບສະເພາະທາງໃຫ້ກົງກັບຈຸດປະສົງ. ຖ້າການຮຽນຮູ້ມາກ່ອນ (Pre-training) ເປັນຂະບວນການສ້າງ "ຕົວແບບທີ່ມີຄວາມຮູ້ທົ່ວໄປ", Fine-tuning ກໍປຽບເໝືອນ "ການຝຶກຝົນເພື່ອເປັນຜູ້ຊ່ຽວຊານ".

ໃນທາງເຕັກນິກ, ມັນຄືການອັບເດດຄ່ານ້ຳໜັກ (weights) ຂອງຕົວແບບໃຫ້ໄປໃນທິດທາງທີ່ເຮັດໃຫ້ຄວາມຜິດພາດຕໍ່ຂໍ້ມູນນຳເຂົ້າຫຼຸດໜ້ອຍລົງ. ໂດຍແບ່ງອອກເປັນສອງປະເພດໃຫຍ່ໆຕາມຂອບເຂດຂອງພາຣາມິເຕີທີ່ອັບເດດ ຄື: Full Fine-tuning ທີ່ກວມເອົາທຸກຊັ້ນຂອງຕົວແບບ ແລະ PEFT (Parameter-Efficient Fine-Tuning) ທີ່ຮຽນຮູ້ພຽງບາງສ່ວນເທົ່ານັ້ນ.

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

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

ວິທີການເຮັດໃຫ້ LLM ມີຄວາມຮູ້ສະເພາະທາງ ສາມາດແບ່ງອອກໄດ້ເປັນ 3 ວິທີຫຼັກ ຄື: Prompt Engineering, RAG (Retrieval-Augmented Generation) ແລະ Fine-tuning. ທັງ 3 ວິທີນີ້ບໍ່ໄດ້ເປັນຄູ່ແຂ່ງກັນ ແຕ່ເປັນເທັກໂນໂລຍີທີ່ເສີມກັນໂດຍມີຈຸດປະສົງທີ່ແຕກຕ່າງກັນ.

Prompt Engineering ແມ່ນວິທີການຄວບຄຸມພຶດຕິກຳໂດຍການປັບປ່ຽນພຽງແຕ່ຄຳສັ່ງ (Instruction) ໂດຍບໍ່ຕ້ອງປ່ຽນແປງນ້ຳໜັກ (Weight) ຂອງຕົວແບບ. ຄ່າໃຊ້ຈ່າຍໃນການຈັດຕັ້ງປະຕິບັດເກືອບເປັນສູນ ແລະ ສາມາດກວດສອບຜົນໄດ້ທັນທີ ແຕ່ເນື່ອງຈາກຕ້ອງສົ່ງຄຳສັ່ງຍາວໆໄປທຸກຄັ້ງ ຈຶ່ງເຮັດໃຫ້ມີຄ່າໃຊ້ຈ່າຍດ້ານ Token ແລະ ເກີດຄວາມຊັກຊ້າ.

RAG ແມ່ນວິທີການຄົ້ນຫາຂໍ້ມູນທີ່ກ່ຽວຂ້ອງຈາກ Document DB ຫຼື Vector Store ພາຍນອກ ແລ້ວນຳເນື້ອຫານັ້ນມາໃສ່ໃນ Prompt ເພື່ອໃຫ້ຕົວແບບສ້າງຜົນລັດອອກມາ. ວິທີນີ້ເໝາະສົມສຳລັບການໃຫ້ຂໍ້ມູນໃໝ່ໆ ຫຼື ຄວາມຮູ້ພາຍໃນອົງກອນໃນຖານະ "ຄວາມຮູ້" (Knowledge) ແລະ ເປັນທາງເລືອກທຳອິດໃນຂອບເຂດທີ່ຕ້ອງຈັດການກັບຄວາມຮູ້ທີ່ເປັນຂໍ້ເທັດຈິງ.

Fine-tuning ແມ່ນການຂຽນທັບພຶດຕິກຳຂອງຕົວແບບເອງ. ວິທີນີ້ມີປະສິດທິຜົນໃນເວລາທີ່ຕ້ອງການປູກຝັງ "ທັກສະ" (Skill) ບໍ່ແມ່ນຄວາມຮູ້ ເຊັ່ນ: ຮູບແບບການຂຽນສະເພາະ, ຮູບແບບ JSON, ຫຼື ການຕີຄວາມໝາຍຄຳສັບສະເພາະວົງການ.

ຈຸດເລີ່ມຕົ້ນໃນການຕັດສິນໃຈຄື "ຖ້າຂາດຂໍ້ເທັດຈິງ (Fact) ໃຫ້ໃຊ້ RAG, ຖ້າຂາດທັກສະ (Skill) ໃຫ້ໃຊ້ FT, ແລະ ຖ້າຄຳສັ່ງງ່າຍໆພຽງພໍແລ້ວ ໃຫ້ໃຊ້ Prompt". ສຳລັບການເລືອກຢ່າງລະອຽດ ໃຫ້ເບິ່ງທີ່ 『ファインチューニングと RAG の選び方』(slug: fine-tuning-vs-rag-comparison).

ໃນຂະແໜງ B2B, ການທີ່ການປັບແຕ່ງແບບ Fine-tuning ກາຍເປັນທາງເລືອກທີ່ເປັນຈິງນັ້ນ ມີທີ່ມາຈາກການປ່ຽນແປງທາງໂຄງສ້າງ 3 ປະການ:

ປະການທີ 1 ແມ່ນການປະກົດຕົວຂອງ PEFT/LoRA ເຊິ່ງເຮັດໃຫ້ຕົ້ນທຶນໃນການຮຽນຮູ້ຫຼຸດລົງຢ່າງຫຼວງຫຼາຍ. ໃນຂະນະທີ່ການເຮັດ Full Fine-tuning ແບບເດີມມີຄ່າໃຊ້ຈ່າຍສູງເຖິງຫຼັກສິບລ້ານເຢນ, ການໃຊ້ LoRA ເຮັດໃຫ້ຄ່າໃຊ້ຈ່າຍໃນການໃຊ້ Cloud GPU ຫຼຸດລົງເຫຼືອພຽງຫຼັກໝື່ນເຖິງຫຼັກແສນເຢນເທົ່ານັ້ນ, ເຊິ່ງເຮັດໃຫ້ສາມາດທົດລອງໄດ້ພາຍໃນງົບປະມານຂອງ PoC.

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

ປະການທີ 3 ແມ່ນບໍລິບົດດ້ານອະທິປະໄຕຂອງຂໍ້ມູນ (Data Sovereignty). ພາຍໃຕ້ກົດໝາຍ PDPA ຂອງໄທ ແລະ ກົດໝາຍປົກປ້ອງຂໍ້ມູນສ່ວນບຸກຄົນສະບັບປັບປຸງຂອງຍີ່ປຸ່ນ, ການດຳເນີນງານທີ່ຕ້ອງສົ່ງຂໍ້ມູນລະອຽດອ່ອນໄປຍັງ API ພາຍນອກ ກຳລັງກາຍເປັນປະເດັນໃນການກວດສອບ, ເຮັດໃຫ້ທາງເລືອກໃນການໃຊ້ Custom Model ທີ່ເຮັດວຽກຢູ່ເທິງ On-premise ຫຼື ພາຍໃນ VPC ເລີ່ມມີຄວາມສຳຄັນຫຼາຍຂຶ້ນ.

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

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

Full Fine-tuning ແມ່ນວິທີການແບບດັ້ງເດີມທີ່ນຳເອົາພາຣາມິເຕີທັງໝົດທີ່ໂມເດລມີມາເປັນເປົ້າໝາຍໃນການຮຽນຮູ້. ເຖິງວ່າຈະໄດ້ຮັບຄວາມສາມາດໃນການສະແດງອອກສູງສຸດ, ແຕ່ກໍຕ້ອງແລກມາດ້ວຍການໃຊ້ໜ່ວຍຄວາມຈຳ GPU, ເວລາໃນການຄຳນວນ ແລະ ຄ່າໃຊ້ຈ່າຍດ້ານພະລັງງານທີ່ມະຫາສານ.

ສຳລັບມາດຕະຖານໃນການປະຕິບັດງານຕົວຈິງ, ການເຮັດ Full FT ໃຫ້ກັບໂມເດລເປີດ (Open model) ໃນລະດັບ 7B ຈຳເປັນຕ້ອງມີການຈັດຫາ GPU ລະດັບສູງຫຼາຍເຄື່ອງ ແລະ ໃຊ້ເວລາຫຼາຍສິບຊົ່ວໂມງ. ຖ້າຄິດໄລ່ເປັນລາຄາ GPU ຂອງ Cloud, ການຮຽນຮູ້ໃນແຕ່ລະຄັ້ງຈະມີມູນຄ່າຕັ້ງແຕ່ຫຼັກສິບໝື່ນເຖິງຫຼັກຫຼາຍລ້ານເຢນ.

ນອກຈາກນີ້, Full FT ຍັງມີຄວາມສ່ຽງຕໍ່ "ການລືມແບບຫາຍະນະ (catastrophic forgetting)". ເຊິ່ງເປັນປະກົດການທີ່ຄວາມສາມາດທົ່ວໄປທີ່ເຄີຍໄດ້ຮັບມາຈາກການຮຽນຮູ້ລ່ວງໜ້າ (Pre-training) ເສື່ອມຖອຍລົງ ໃນຂະນະທີ່ພະຍາຍາມຈົດຈຳໜ້າວຽກໃໝ່. ການຮັກສາຄວາມສາມາດໃນການນຳໃຊ້ທີ່ຫຼາກຫຼາຍ (Versatility) ຈຳເປັນຕ້ອງມີການອອກແບບຊຸດຂໍ້ມູນແບບປະສົມ ແລະ ການຄວບຄຸມອັດຕາການຮຽນຮູ້ (Learning rate) ຢ່າງລະອຽດ ເຊິ່ງເຮັດໃຫ້ຕົ້ນທຶນດ້ານວິສະວະກຳເພີ່ມທະວີຂຶ້ນເລື້ອຍໆ.

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

PEFT (Parameter-Efficient Fine-Tuning) ແມ່ນຄຳສັບລວມຂອງວິທີການປັບແຕ່ງພາຣາມິເຕີແບບປະຢັດ ເຊິ່ງຈະຝຶກສອນພຽງແຕ່ບໍ່ເທົ່າໃດເປີເຊັນຂອງພາຣາມິເຕີທັງໝົດໃນໂມເດວ. ວິທີນີ້ສາມາດຫຼຸດຕົ້ນທຶນການຝຶກສອນ ແລະ ຕົ້ນທຶນການດຳເນີນງານໃຫ້ຕ່ຳກວ່າ Full FT ໄດ້ເຖິງ 1 ຫາ 2 ຫຼັກ ໃນຂະນະທີ່ຍັງສາມາດຮັກສາຄວາມແມ່ນຍຳໃຫ້ພຽງພໍສຳລັບການນຳໃຊ້ໃນວຽກງານທຸລະກິດຕ່າງໆ.

ວິທີການທີ່ເປັນຕົວແທນໄດ້ແກ່ LoRA (Low-Rank Adaptation) ແລະ ລຸ້ນທີ່ຜ່ານການ Quantization ຄື QLoRA. ສຳລັບ LoRA ນັ້ນ ຈະເຮັດການ ຄົງຄ່າໄວ້ ທີ່ຕົວໂມເດວຫຼັກ ແລ້ວເພີ່ມເມທຣິກອັນດັບຕ່ຳ (Low-rank matrix) ຂະໜາດນ້ອຍເຂົ້າໄປໃນແຕ່ລະຊັ້ນເພື່ອຝຶກສອນສະເພາະສ່ວນນັ້ນ. ຂໍ້ດີຂອງມັນຄືສາມາດປັບແຕ່ງໂມເດວລະດັບ 7B ໄດ້ດ້ວຍ GPU ສຳລັບຜູ້ໃຊ້ທົ່ວໄປພຽງໃບດຽວ.

QLoRA ແມ່ນວິທີການທີ່ນຳເອົາໂມເດວພື້ນຖານມາເຮັດການ Quantization ໃຫ້ເຫຼືອ 4bit ກ່ອນຈະນຳ LoRA ມາໃສ່ ເຊິ່ງສາມາດຫຼຸດການໃຊ້ງານໜ່ວຍຄວາມຈຳລົງໄດ້ອີກເຄິ່ງໜຶ່ງ. ວິທີນີ້ຖືກນຳໃຊ້ຢ່າງກວ້າງຂວາງໃນຖານະທາງອອກທີ່ເປັນຈິງສຳລັບສະພາບແວດລ້ອມ On-premise ໃນປະເທດໄທ ເມື່ອງົບປະມານດ້ານ GPU ມີຈຳກັດ.

ຜົນການຝຶກສອນຂອງ LoRA ສາມາດບັນທຶກແຍກອອກມາເປັນໄຟລ໌ ອາແດັບເຕີ ຫຼື ສ່ວນເສີມ ຂະໜາດຫຼັກສິບ MB ເຖິງຫຼັກຮ້ອຍ MB ແລະ ສາມາດຈັດການເປັນ "ຊຸດຂອງໄຟລ໌" ທີ່ສາມາດສະຫຼັບໄປມາໄດ້ຕາມຈຸດປະສົງການນຳໃຊ້ (ເຊັ່ນ: ສຳລັບເອກະສານຝ່າຍຂາຍ, ສຳລັບການແປພາສາທາງເຕັກນິກ ແລະ ອື່ນໆ). ລາຍລະອຽດເພີ່ມເຕີມສາມາດເບິ່ງໄດ້ທີ່ 『PEFT 入門』(slug: peft-introduction).

ການປັບແຕ່ງແບບ Fine-tuning ຈະມີລັກສະນະທີ່ປ່ຽນແປງໄປຕາມວິທີການໃຫ້ສັນຍານໃນການຮຽນຮູ້. ການແບ່ງປະເພດທີ່ເປັນຕົວແທນໄດ້ດີທີ່ສຸດຄື: ການຮຽນຮູ້ແບບມີຜູ້ສອນ (Supervised Fine-Tuning: SFT) ແລະ ລະບົບການຮຽນຮູ້ແບບເສີມກຳລັງ (Reinforcement Learning) ຢ່າງ RLHF ຫຼື DPO.

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

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

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

ສຳລັບລຳດັບການເລືອກໃຊ້, ແຜນງານທີ່ເປັນຈິງທີ່ສຸດຄືການໃຊ້ SFT ເພື່ອໃຫ້ໄດ້ຜົນລັພເຖິງ 80% ກ່ອນ, ຈາກນັ້ນຈຶ່ງໃຊ້ DPO ຫຼື RLHF ເພື່ອຍົກລະດັບຄຸນນະພາບຂອງອີກ 20% ທີ່ເຫຼືອຕາມຄວາມຈຳເປັນ.

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

ການປັບແຕ່ງແບບ Fine-tuning ຈະມີປະສິດທິພາບສູງສຸດໃນຂົງເຂດທີ່ LLM ແບບທົ່ວໄປ "ຮູ້ຈັກຄຳສັບ ແຕ່ເຂົ້າໃຈບໍລິບົດຜິດ". ໃນສະພາບແວດລ້ອມ B2B ຂອງໄທ, ການລົງທຶນມີຄວາມຄຸ້ມຄ່າສູງໃນ 3 ປະເພດບັນຫາຕໍ່ໄປນີ້:

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

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

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

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

ຕົວຢ່າງທີ່ເຫັນໄດ້ຊັດເຈນທີ່ສຸດທີ່ການ Fine-tuning ບໍ່ເໝາະສົມ ຄືຂົງເຂດທີ່ມີການປ່ຽນແປງຄວາມຮູ້ເລື້ອຍໆ. ເນື່ອງຈາກຄວາມຮູ້ທີ່ໄດ້ຈາກການຮຽນຮູ້ຜ່ານ FT ຈະຖືກຝັງໄວ້ໃນນ້ຳໜັກຂອງຕົວແບບ (Model weights), ການອັບເດດຂໍ້ມູນຈຶ່ງຈຳເປັນຕ້ອງມີການຮຽນຮູ້ໃໝ່. ເວລາທີ່ໃຊ້ໃນການອັບເດດ (Lead time) ທີ່ບໍ່ສອດຄ່ອງກັບຄວາມໄວຂອງການເຮັດວຽກຖືເປັນຈຸດອ່ອນທີ່ສຳຄັນ.

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

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

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

RAG ແລະ FT ບໍ່ແມ່ນເທັກໂນໂລຢີທີ່ຂັດແຍ່ງກັນ, ແຕ່ເປັນວິທີການທີ່ທັນສະໄໝໃນການອອກແບບ Roadmap ໂດຍຄາດຫວັງໃຫ້ໃຊ້ຮ່ວມກັນ. ການຕັດສິນໃຈສາມາດຈັດແບ່ງໄດ້ຕາມ 3 ແກນຫຼັກ ດັ່ງນີ້:

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

ແກນທີ 2, ຄວາມຖີ່ໃນການອັບເດດ. ຖ້າເນື້ອຫາປ່ຽນແປງແບບລາຍວັນ ຫຼື ລາຍອາທິດແມ່ນ RAG, ຖ້າການອັບເດດໃນຮອບ 10 ປີ ຫຼື ປີຕໍ່ປີພຽງພໍແລ້ວ FT ກໍເປັນທາງເລືອກໜຶ່ງ. ສຳລັບການອອກແບບໂຄງສ້າງພື້ນຖານ ຫຼື Infrastructure ທີ່ອີງໃສ່ RAG, ໃຫ້ອ້າງອີງຈາກ 『ベクトルデータベース入門』(slug: vector-database-guide).

ແກນທີ 3, ຄວາມຮູ້ສຶກດ້ານ Latency ແລະ ຕົ້ນທຶນ. RAG ຈະມີການຄົ້ນຫາເກີດຂຶ້ນໃນຂະນະທີ່ Inference ເຮັດໃຫ້ Response ຊ້າລົງ ແລະ ມີຕົ້ນທຶນ Token ເພີ່ມຂຶ້ນ. ໃນກໍລະນີທີ່ມີຄວາມຖີ່ສູງ, ການໃຊ້ Model ທີ່ຜ່ານ FT ແລ້ວມາເຮັດ Lightweight Inference ຈະຊະນະໃນດ້ານ TCO. ແຕ່ຖ້າເປັນກໍລະນີຄວາມຖີ່ຕ່ຳ ແລະ ຕ້ອງການຄວາມແມ່ນຍຳສູງ, ຄວາມຍືດຫຍຸ່ນຂອງ RAG ຈະມີປະສິດທິພາບຫຼາຍກວ່າ.

ໃນການປະຕິບັດງານຕົວຈິງ, ມັກຈະລົງຕົວທີ່ການອອກແບບແບບ Hybrid ຄື "ໃຊ້ FT ເພື່ອກຳນົດພຶດຕິກຳ ແລະ ໃຊ້ RAG ເພື່ອສົ່ງຂໍ້ມູນຂໍ້ເທັດຈິງ". ສຳລັບການ Routing ທີ່ລະອຽດ, ໃຫ້ອ້າງອີງຈາກ 『ハイブリッド LLM × SLM 設計ガイド』(slug: hybrid-llm-slm-routing-design-guide).

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

ຜົນຂອງການ Fine-tuning ສ່ວນໃຫຍ່ແມ່ນຂຶ້ນຢູ່ກັບຄຸນນະພາບຂອງ Dataset. ສາເຫດສ່ວນໃຫຍ່ທີ່ເຮັດໃຫ້ຫຼາຍ PoC ສະຫຼຸບວ່າ "ບໍ່ໄດ້ຜົນດີເທົ່າທີ່ຄວນ" ບໍ່ແມ່ນຢູ່ທີ່ການເລືອກ Model ແຕ່ແມ່ນຢູ່ທີ່ຝັ່ງຂອງຂໍ້ມູນ.

ສິ່ງທີ່ຕ້ອງຕັດສິນໃຈເປັນອັນດັບທຳອິດຄື ຮູບແບບຂອງຂໍ້ມູນ. ໃນກໍລະນີຂອງການຮຽນຮູ້ແບບມີຜູ້ສອນ (Supervised Learning), JSON Lines ທີ່ຈັບຄູ່ລະຫວ່າງ Input ແລະ Output ທີ່ເໝາະສົມແມ່ນເປັນທີ່ນິຍົມ, ໂດຍຈະຕ້ອງມີການສຸ່ມແບບແບ່ງຊັ້ນ (Stratified Sampling) ເພື່ອບໍ່ໃຫ້ຄວາມຫຼາກຫຼາຍຂອງໂຈດ (ປະເພດລູກຄ້າ, ໝວດໝູ່ການສອບຖາມ, ພາສາ) ໃນແຕ່ລະຄູ່ມີຄວາມລຳອຽງ.

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

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

ຢ່າລືມເລື່ອງການຈັດການຂໍ້ມູນທີ່ມີຄວາມລະອຽດອ່ອນ. PII ເຊັ່ນ: ຊື່ລູກຄ້າ, ຊື່ຄູ່ຄ້າ, ເງື່ອນໄຂສັນຍາ ແລະ ອື່ນໆ ຕ້ອງຖືກ Masking ກ່ອນການຮຽນຮູ້. ຫາກລະເລີຍ, ຈະມີຄວາມສ່ຽງທີ່ Model ຈະປ່ອຍຂໍ້ມູນບາງສ່ວນທີ່ໄດ້ຮຽນຮູ້ອອກມາໂດຍກົງໃນຂະນະທີ່ Inference, ເຊິ່ງຈະກາຍເປັນບັນຫາໃນດ້ານການປະຕິບັດຕາມ PDPA ອີກດ້ວຍ.

ການເລືອກ Base Model ໃຫ້ພິຈາລະນາຈາກ 3 ເງື່ອນໄຂຄື: ໃບອະນຸຍາດ (License), ຂະໜາດ (Size), ແລະ ສະຖານທີ່ນຳໃຊ້ (Deployment).

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

ຂະໜາດຂອງ Model ໃຫ້ຍຶດເອົາ "ຂີດຈຳກັດຄວາມສາມາດຂັ້ນຕ່ຳທີ່ຈຳເປັນສຳລັບວຽກງານ" ເປັນມາດຕະຖານ. ຖ້າເປັນວຽກງານທີ່ຂ້ອນຂ້າງງ່າຍ ເຊັ່ນ: ການສະຫຼຸບເນື້ອຫາ ຫຼື ການຈັດໝວດໝູ່, Model ຂະໜາດ 3B-7B ກໍພຽງພໍ ແລະ ຊ່ວຍປະຢັດຕົ້ນທຶນໃນການປະມວນຜົນ. ຖ້າຕ້ອງການການສົນທະນາຂັ້ນສູງໃນຫຼາຍພາສາ ຫຼື ການໃຊ້ເຫດຜົນທີ່ຊັບຊ້ອນ, Model ຂະໜາດ 13B-70B ຈະເປັນທາງເລືອກທີ່ເໝາະສົມ. ເຖິງວ່າຂະໜາດໃຫຍ່ຈະໃຫ້ຄວາມແມ່ນຍຳສູງກວ່າ, ແຕ່ກໍເຮັດໃຫ້ Latency ໃນການປະມວນຜົນ ແລະ ການໃຊ້ງານ GPU Memory ເພີ່ມທະວີຂຶ້ນເລື້ອຍໆ.

ການຕັດສິນໃຈເລືອກສະຖານທີ່ນຳໃຊ້ (Cloud API vs On-premise Self-host) ກ່ອນ ຈະຊ່ວຍໃຫ້ຈຳກັດທາງເລືອກໃຫ້ແຄບລົງ. ໃນພາກສ່ວນການຜະລິດທີ່ປະເທດໄທ, ມີການເລືອກໃຊ້ Open Model ສຳລັບ On-premise ເພີ່ມຂຶ້ນ ເນື່ອງຈາກຄວາມຕ້ອງການທີ່ບໍ່ຕ້ອງການໃຫ້ຂໍ້ມູນທີ່ມີຄວາມລະອຽດອ່ອນອອກສູ່ພາຍນອກ.

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

ການຮຽນຮູ້ບໍ່ແມ່ນການເຮັດພຽງຄັ້ງດຽວແລ້ວຈົບ ແຕ່ຄວນອອກແບບໃຫ້ເປັນວົງຈອນທີ່ລວມເອົາການປະເມີນຜົນ ແລະ ການຕິຊົມ (Feedback) ເຂົ້າໄວ້ດ້ວຍກັນ. ໂດຍໃຫ້ໝູນວຽນຫຼາຍຮອບໃນຮູບແບບ: ການກຽມຂໍ້ມູນ → ການຮຽນຮູ້ → ການປະເມີນຜົນແບບອັດຕະໂນມັດ → ການກວດສອບໂດຍມະນຸດ → ການເພີ່ມເຕີມຂໍ້ມູນໃນສ່ວນທີ່ຂາດຫາຍ → ການຮຽນຮູ້ໃໝ່.

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

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

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

ສຳລັບວິທີການຫຼຸດຜ່ອນຕົ້ນທຶນ, ກະລຸນາເບິ່ງທີ່ 『LLM ຄູ່ມືການປັບຕົ້ນທຶນໃຫ້ເໝາະສົມ』(slug: llm-cost-optimization-guide).

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

ຈຸດເລີ່ມຕົ້ນຂອງການຄິດໄລ່ຕົ້ນທຶນແມ່ນມາຈາກ 3 ປັດໄຈຄື: ຂະໜາດຂອງ Base Model, ຮູບແບບການຮຽນຮູ້ ແລະ ປະລິມານຂໍ້ມູນທີ່ໃຊ້ໃນການຮຽນຮູ້. ໃນກໍລະນີທີ່ຮຽນຮູ້ຂໍ້ມູນ 5,000 ຄູ່ດ້ວຍ LoRA ສໍາລັບ Model ລະດັບ 7B, ການຄາດຄະເນມາດຕະຖານຈະໃຊ້ GPU ລະດັບ High-end 1-2 ເຄື່ອງ ເປັນເວລາປະມານ 6-12 ຊົ່ວໂມງ, ເຊິ່ງມັກຈະມີຕົ້ນທຶນຢູ່ໃນລະດັບຫຼັກສິບໝື່ນເຖິງຫຼັກແສນເຢນຕໍ່ການຮຽນຮູ້ 1 ຄັ້ງ.

ໃນທາງກົງກັນຂ້າມ, ຖ້າໃຊ້ Full Fine-tuning ກັບ Model ຂະໜາດ 13B ຂຶ້ນໄປ, ຈໍານວນ GPU ທີ່ຕ້ອງການ ແລະ ເວລາໃນການຮຽນຮູ້ຈະເພີ່ມຂຶ້ນ ເຮັດໃຫ້ຕົ້ນທຶນສູງຂຶ້ນເຖິງ 1 ຫາ 2 ເທົ່າ. ເນື່ອງຈາກຄວາມແຕກຕ່າງຂອງຕົ້ນທຶນມີຜົນຫຼາຍກວ່າຄວາມແຕກຕ່າງຂອງຄວາມແມ່ນຍໍາ, ກົດເຫຼັກຄືຕ້ອງກວດສອບກ່ອນວ່າ PEFT ສາມາດຕອບໂຈດຄວາມຕ້ອງການໄດ້ຫຼືບໍ່.

ສິ່ງທີ່ມັກຈະຖືກມອງຂ້າມຫຼາຍກວ່າຕົ້ນທຶນການຮຽນຮູ້ ຄືຕົ້ນທຶນການອະນຸມານ (Inference cost). ຄ່າໃຊ້ຈ່າຍລາຍເດືອນຈະແຕກຕ່າງກັນຢ່າງຫຼວງຫຼາຍລະຫວ່າງການຈອງ GPU ໄວ້ຕະຫຼອດ 24 ຊົ່ວໂມງ ກັບການເປີດໃຊ້ງານແບບ Serverless ເປັນຄັ້ງຄາວ. ຖ້າເປັນການອະນຸມານແບບ Batch ທີ່ມີຄວາມຖີ່ຕໍ່າ ການໃຊ້ Serverless ແມ່ນເໝາະສົມກວ່າ, ແຕ່ຖ້າມີຄວາມຖີ່ສູງ ການເປີດ Container ໄວ້ຕະຫຼອດເວລານັ້ນເໝາະສົມກວ່າໃນຄວາມເປັນຈິງ.

ຖ້າອອກແບບການເລືອກໃຊ້ Model ທີ່ຫຼາກຫຼາຍ ແລະ ການກຳນົດເສັ້ນທາງການອະນຸມານ (Inference routing), ກໍຈະສາມາດຫຼຸດເວລາການເຮັດວຽກຂອງ FT Model ໃຫ້ໜ້ອຍທີ່ສຸດໄດ້. ແນວຄວາມຄິດໃນການປະສົມປະສານດັ່ງກ່າວ ໄດ້ກ່າວໄວ້ໃນ "ຄູ່ມືການອອກແບບ Hybrid LLM × SLM" (slug: hybrid-llm-slm-routing-design-guide).

FT ບໍ່ແມ່ນ "ສ້າງແລ້ວຈົບເລີຍ". ການຮຽນຮູ້ຄືນໃໝ່ (Re-training) ຈະເກີດຂຶ້ນເປັນໄລຍະຕາມການປ່ຽນແປງຂອງເນື້ອໃນວຽກ, ການອັບເດດກົດລະບຽບ ແລະ ການເພີ່ມບໍລິການໃໝ່. ຖ້າບໍ່ລວມຮອບວຽນການອັບເດດນີ້ເຂົ້າໃນການປະເມີນລາຄາ, ງົບປະມານຈະເກີນໃນໄລຍະການດຳເນີນງານ.

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

ບໍ່ຈຳເປັນຕ້ອງຮຽນຮູ້ຊຸດຂໍ້ມູນເຕັມທຸກຄັ້ງທີ່ມີການຮຽນຮູ້ຄືນໃໝ່. ການນຳເອົາ "ການຮຽນຮູ້ຢ່າງຕໍ່ເນື່ອງ" (Continual Learning) ທີ່ໃຊ້ພຽງການຮຽນຮູ້ເພີ່ມເຕີມຈາກຂໍ້ມູນສ່ວນທີ່ແຕກຕ່າງມາໃຊ້ ຈະສາມາດຫຼຸດຕົ້ນທຶນການຄຳນວນລົງໄດ້ເຖິງປະມານ 1/3. ຢ່າງໃດກໍຕາມ, ການຮຽນຮູ້ຢ່າງຕໍ່ເນື່ອງມີຄວາມສ່ຽງສູງທີ່ຈະເກີດການລືມແບບຖອນຮາກຖອນໂຄນ (Catastrophic Forgetting), ຈຶ່ງຈຳເປັນຕ້ອງມີວິທີການປະສົມຂໍ້ມູນເກົ່າບາງສ່ວນເຂົ້າໄປໃນການຮຽນຮູ້ດ້ວຍ.

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

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

ມາດຕະການປ້ອງກັນມີ 3 ດ້ານຫຼັກ: ຢ່າງທຳອິດ, ຕ້ອງທຳການ Masking ຂໍ້ມູນ PII ໃນຂໍ້ມູນທີ່ໃຊ້ຮຽນຮູ້ລ່ວງໜ້າ. ຊື່ລູກຄ້າ, ມູນຄ່າການເຮັດທຸລະກຳ, ເງື່ອນໄຂສັນຍາ ແລະ ອື່ນໆ ຈະຖືກປ່ຽນເປັນ Token ຫຼື ID ນາມແຝງ ກ່ອນຈະນຳເຂົ້າສູ່ຂະບວນການຮຽນຮູ້. ຢ່າງທີສອງ, ຕ້ອງດຳເນີນການ Red Teaming ຕໍ່ໂມເດວທີ່ຜ່ານການຮຽນຮູ້ແລ້ວ ໂດຍການໃຊ້ Prompt ເພື່ອດຶງຂໍ້ມູນທີ່ລະອຽດອ່ອນອອກມາໂດຍເຈດຕະນາ. ຢ່າງທີສາມ, ຖ້າຍັງມີຄວາມສ່ຽງຕໍ່ການຮົ່ວໄຫຼຂອງຂໍ້ມູນ ໃຫ້ທຳການຍົກເວັ້ນຂໍ້ມູນດັ່ງກ່າວອອກແລ້ວທຳການຮຽນຮູ້ໃໝ່.

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

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

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

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

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

ອັນທີສາມ, ງົບປະມານສຳລັບ PoC. ສາມາດວາງແຜນງົບປະມານປະມານສິບກວ່າໝື່ນເຖິງຫຼາຍສິບໝື່ນເຢນສຳລັບ PoC ໂດຍອີງໃສ່ LoRA ໄດ້ຫຼືບໍ່? ສຳລັບການຂະຫຍາຍໄປສູ່ Full FT, ສາມາດຄາດການງົບປະມານທີ່ສູງກວ່ານັ້ນອີກ 1 ຫຼັກໄດ້ຫຼືບໍ່?

ອັນທີສີ່, ລະບົບການດຳເນີນງານ. ສາມາດຮັບປະກັນຊັບພະຍາກອນດ້ານວິສະວະກຳທັງພາຍໃນບໍລິສັດ ຫຼື ຈາກຄູ່ຮ່ວມງານພາຍນອກ ເພື່ອດຳເນີນການຝຶກຝົນໃໝ່ (Re-training), ການປະເມີນຜົນ, ແລະ ການກູ້ຄືນຂໍ້ມູນ (Rollback) ໄດ້ຢ່າງເປັນປົກກະຕິຫຼືບໍ່?

ອັນທີຫ້າ, ຄວາມຕ້ອງການດ້ານການປົກປ້ອງຂໍ້ມູນ ແລະ ການປະຕິບັດຕາມກົດລະບຽບ (Compliance). ໄດ້ມີການປັບໃຫ້ສອດຄ່ອງກັບ PDPA ແລະ ກົດລະບຽບພາຍໃນບໍລິສັດ, ລວມທັງໄດ້ຕົກລົງກັບຝ່າຍກົດໝາຍກ່ຽວກັບນະໂຍບາຍການຈັດການຂໍ້ມູນທີ່ມີຄວາມລະອຽດອ່ອນແລ້ວຫຼືບໍ່?

ໂຄງການທີ່ສາມາດຕອບ Yes ໄດ້ຄົບທັງ 5 ຫົວຂໍ້ ແມ່ນມີຄຸນຄ່າສູງທີ່ຈະລົງທຶນໃນ FT. ຖ້າມີຂໍ້ໃດໜຶ່ງທີ່ຕອບ No, ຄວນໃຫ້ບຸລິມະສິດໃນການກຽມຄວາມພ້ອມເພື່ອຕື່ມເຕັມໃນຫົວຂໍ້ນັ້ນກ່ອນ.

ນີ້ຄືບົດສະຫຼຸບຄຳຕອບສຳລັບຄຳຖາມທີ່ພົບເລື້ອຍ ເມື່ອພິຈາລະນາເລື່ອງການເຮັດ Fine-tuning ໃນໜ້າວຽກ B2B:

Q1: ງົບປະມານຂັ້ນຕໍ່າທີ່ຕ້ອງໃຊ້ໃນການເລີ່ມຕົ້ນແມ່ນເທົ່າໃດ? ສຳລັບການເຮັດ PoC ໂດຍໃຊ້ LoRA, ໃນຫຼາຍກໍລະນີສາມາດເລີ່ມຕົ້ນໄດ້ຕັ້ງແຕ່ຫຼັກສິບໝື່ນເຢນ ເຊິ່ງລວມທັງການກຽມຂໍ້ມູນ, ການຮຽນຮູ້ (Training) ແລະ ການປະເມີນຜົນ. ຖ້າຫາກກ້າວໄປສູ່ການເຮັດ Full FT, ຈະຕ້ອງໃຊ້ງົບປະມານເພີ່ມຂຶ້ນອີກ 1 ເທົ່າຕົວ.

Q2: ຕ້ອງມີຂໍ້ມູນຈັກລາຍການຈຶ່ງຈະເຫັນຜົນ? ໂດຍປະມານແລ້ວ 500–1,000 ລາຍການສຳລັບການກຳນົດຮູບແບບໃຫ້ຄົງທີ່, ແລະ 3,000 ລາຍການຂຶ້ນໄປສຳລັບການຮຽນຮູ້ພຶດຕິກຳທີ່ຊັບຊ້ອນ. ການຮັບປະກັນຄຸນນະພາບຂອງຂໍ້ມູນຄູ່ (Pair) ຈະສົ່ງຜົນໂດຍກົງຕໍ່ຜົນລັດຫຼາຍກວ່າການເພີ່ມຈຳນວນຂໍ້ມູນ.

Q3: ຖ້າບໍລິສັດບໍ່ມີວິສະວະກອນ, ຈະສາມາດເຮັດໄດ້ຫຼືບໍ່? ປັດຈຸບັນ LoRA/QLoRA ໄດ້ພັດທະນາໄປສູ່ການເປັນ Managed Service ຫຼາຍຂຶ້ນ, ຖ້າຫາກກຽມຂໍ້ມູນໄດ້ແລ້ວ ການຮຽນຮູ້ກໍສາມາດຈ້າງພາຍນອກເຮັດໄດ້ງ່າຍ. ໃນທາງກັບກັນ, ການອອກແບບການປະເມີນຜົນ, ການຄວບຄຸມຄຸນນະພາບຂໍ້ມູນ ແລະ ການດຳເນີນງານຢ່າງຕໍ່ເນື່ອງ ຈຳເປັນຕ້ອງມີຄວາມຮູ້ພາຍໃນອົງກອນ.

Q4: ມີຄວາມສ່ຽງທີ່ຄວາມສາມາດທົ່ວໄປຈະຫຼຸດລົງຫຼັງຈາກເຮັດ FT ຫຼືບໍ່? ໃນການເຮັດ Full FT, ຄວາມສ່ຽງທີ່ຈະເກີດ Catastrophic Forgetting (ການລືມຄວາມຮູ້ເດີມ) ແມ່ນສູງ, ແຕ່ສຳລັບ LoRA ເນື່ອງຈາກບໍ່ໄດ້ໄປປັບປ່ຽນນ້ຳໜັກ (Weight) ຂອງ Base Model ຜົນກະທົບຈຶ່ງມີຈຳກັດ. ການນຳເອົາການປະເມີນຜົນດ້ວຍ General Benchmark ມາເປັນສ່ວນໜຶ່ງຂອງ Regression Test ຈະຊ່ວຍໃຫ້ປອດໄພຂຶ້ນ.

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

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

ການຕັດສິນໃຈຂອງບໍລິສັດ B2B ຈະງ່າຍຂຶ້ນເມື່ອຄິດເປັນ 3 ຂັ້ນຕອນ. ຂັ້ນຕອນທຳອິດ, ໃຫ້ເຮັດ RAG + Prompt Engineering ຢ່າງລະອຽດເພື່ອຈັດການກັບຂອບເຂດຂອງຄວາມຮູ້ທີ່ເປັນຂໍ້ເທັດຈິງ. ຂັ້ນຕອນທີສອງ, ຖ້າຫາກບັນຫາທີ່ຍັງເຫຼືອສຸມໃສ່ "ຄວາມບໍ່ສະຖຽນຂອງພຶດຕິກຳ", "ຄວາມຜັນຜວນຂອງຮູບແບບ" ແລະ "ການຈັດການກັບຄຳສັບໃນອຸດສາຫະກຳ", ໃຫ້ເລີ່ມຕົ້ນເຮັດ PoC ຂະໜາດນ້ອຍໂດຍໃຊ້ PEFT/LoRA. ຂັ້ນຕອນທີສາມ, ເມື່ອ PoC ໄດ້ຜົນລັບ ແລະ ເງື່ອນໄຂ 3 ຢ່າງຄື: ຂໍ້ມູນ, ລະບົບການດຳເນີນງານ ແລະ ງົບປະມານ ຄົບຖ້ວນແລ້ວ, ຈຶ່ງພິຈາລະນາລົງທຶນຢ່າງຈິງຈັງໃນ Full FT ຫຼື ການພັດທະນາໂມເດວສະເພາະຂອງຕົນເອງ.

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

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