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

RAG (Retrieval-Augmented Generation / ການສ້າງເນື້ອຫາໂດຍການດຶງຂໍ້ມູນມາຊ່ວຍ) ແມ່ນວິທີການທີ່ບໍ່ໄດ້ປ່ຽນແປງຕົວແບບ (Model) ໂດຍກົງ, ແຕ່ເປັນການຄົ້ນຫາຄວາມຮູ້ທີ່ຈຳເປັນສຳລັບການຕອບຄຳຖາມຈາກແຫຼ່ງຂໍ້ມູນພາຍນອກ ແລ້ວນຳມາເພີ່ມໃສ່ໃນ Prompt.

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

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

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

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

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

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

ໃນດ້ານຕົ້ນທຶນ, ຈຳເປັນຕ້ອງແຍກພິຈາລະນາລະຫວ່າງການລົງທຶນເບື້ອງຕົ້ນ ແລະ ຄ່າໃຊ້ຈ່າຍໃນການດຳເນີນງານ.

ການລົງທຶນເບື້ອງຕົ້ນຂອງ RAG ແມ່ນເນັ້ນໃສ່ການເຮັດ Chunking ເອກະສານ, ການສ້າງ Vector Database, ແລະ ການຈັດຕັ້ງປະຕິບັດຂະບວນການ ຫຼື Pipeline ການຄົ້ນຫາ. ເນື່ອງຈາກບໍ່ຈຳເປັນຕ້ອງມີການຝຶກຝົນແບບຈຳລອງ (Model) ໃໝ່, ຈຶ່ງສາມາດເລີ່ມຕົ້ນໄດ້ງ່າຍເຖິງແມ່ນວ່າຈະບໍ່ມີຜູ້ຊ່ຽວຊານດ້ານ Machine Learning ກໍຕາມ. ສຳລັບຄ່າໃຊ້ຈ່າຍໃນການດຳເນີນງານນັ້ນ, ຈະມີຄ່າໃຊ້ຈ່າຍທີ່ເກີດຂຶ້ນຢ່າງຕໍ່ເນື່ອງຈາກການຮຽກໃຊ້ Embedding ທຸກຄັ້ງທີ່ມີການຄົ້ນຫາ ແລະ ການເພີ່ມຂຶ້ນຂອງ Input Token ເນື່ອງຈາກ Prompt ທີ່ຍາວຂຶ້ນ.

ການລົງທຶນເບື້ອງຕົ້ນຂອງ Fine-tuning ຈະສຸມໃສ່ການກະກຽມຂໍ້ມູນສອນ (Training Data) ແລະ ຊັບພະຍາກອນຄອມພິວເຕີສຳລັບການຝຶກຝົນ. ພາລະຕົ້ນຕໍແມ່ນແຮງງານໃນການກະກຽມຂໍ້ມູນທີ່ມີຄຸນນະພາບ ແລະ ຄ່າໃຊ້ຈ່າຍຂອງສະພາບແວດລ້ອມ GPU ສຳລັບການຝຶກຝົນ. ໃນທາງກົງກັນຂ້າມ, ໃນຂະນະດຳເນີນງານ, ຍ້ອນວ່າບໍ່ຈຳເປັນຕ້ອງໃສ່ຄວາມຮູ້ພາຍນອກລົງໃນ Prompt ທຸກຄັ້ງ, ຈຶ່ງສາມາດຄວບຄຸມປະລິມານ Token ໃນຂະນະ Inference ໄດ້ງ່າຍກວ່າ. ຢ່າງໃດກໍຕາມ, ທຸກຄັ້ງທີ່ມີການອັບເດດຄວາມຮູ້, ຄ່າໃຊ້ຈ່າຍໃນການຝຶກຝົນໃໝ່ກໍຈະເກີດຂຶ້ນອີກ.

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

ໃນດ້ານຄວາມຖືກຕ້ອງ, ມັກຈະມີຄວາມແຕກຕ່າງກັນໃນເລື່ອງຄວາມສົດໃໝ່ຂອງຂໍ້ມູນ ແລະ ຄວາມງ່າຍໃນການເກີດ Hallucination.

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

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

ໃນຂົງເຂດທີ່ຄວາມຮູ້ມີການປ່ຽນແປງເລື້ອຍໆ, RAG ຈະສາມາດຮັກສາຄວາມສົດໃໝ່ໄດ້ງ່າຍກວ່າ, ສ່ວນໃນຂົງເຂດທີ່ມີການປ່ຽນແປງໜ້ອຍ ແລະ ຄວາມສະໝໍ່າສະເໝີຂອງພຶດຕິກຳມີຄວາມສຳຄັນ, Fine-tuning ຈະເໝາະສົມກວ່າ.

ໃນດ້ານຂໍ້ມູນ, ປະເພດ, ປະລິມານ ແລະ ຄຸນນະພາບຂອງຂໍ້ມູນທີ່ຈຳເປັນໃນທັງສອງວິທີນັ້ນມີຄວາມແຕກຕ່າງກັນຢ່າງຫຼວງຫຼາຍ.

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

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

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

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

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

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

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

ສຳລັບພາສາທີ່ມີຊັບພະຍາກອນການຮຽນຮູ້ໜ້ອຍ ເຊັ່ນ: ພາສາລາວ ຫຼື ພາສາໄທ, RAG ກໍເປັນທາງເລືອກທີ່ມີປະສິດທິພາບ.

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

ໃນພາກພື້ນອາຊີຕາເວັນອອກສຽງໃຕ້ທີ່ບໍລິສັດຂອງພວກເຮົາໄດ້ດຳເນີນທຸລະກິດຢູ່ນັ້ນ, ສະຖານະການທົ່ວໄປຄືມີເອກະສານພາຍໃນເປັນພາສາທ້ອງຖິ່ນ ແຕ່ຍັງຂາດແຄນຂໍ້ມູນຄູ່ຂະໜານ (対訳データ) ທີ່ຖືກຈັດຕຽມໄວ້ສຳລັບການຮຽນຮູ້ຂອງເຄື່ອງ (Machine Learning). ໃນສະພາບແວດລ້ອມດັ່ງກ່າວ, ວິທີການທີ່ເປັນຈິງທີ່ສຸດຄືການນຳເອົາເອກະສານພາສາທ້ອງຖິ່ນທີ່ມີຢູ່ໃນມືມາໃຊ້ເປັນແຫຼ່ງຄວາມຮູ້ຂອງ RAG ແລະ ເລືອກໃຊ້ Embedding model ທີ່ມີຄວາມສາມາດໂດດເດັ່ນໃນດ້ານຄຸນລັກສະນະຂອງພາສານັ້ນໆຕາມຄວາມຈຳເປັນ.

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

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

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

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

ໃນກໍລະນີທີ່ຕ້ອງການຍ້າຍພຶດຕິກຳຂອງໂມເດວຂະໜາດໃຫຍ່ໄປສູ່ໂມເດວຂະໜາດນ້ອຍ ເພື່ອຈຸດປະສົງໃນການຫຼຸດຕົ້ນທຶນການອະນຸມານ (Inference cost), ການເຮັດ Fine-tuning ກໍເປັນທາງເລືອກໜຶ່ງ.

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

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

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

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

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

RAG ແລະ Fine-tuning ບໍ່ແມ່ນທາງເລືອກທີ່ຕ້ອງເລືອກຢ່າງໃດຢ່າງໜຶ່ງ, ແຕ່ສາມາດອອກແບບໃຫ້ໃຊ້ຮ່ວມກັນເພື່ອດຶງເອົາຈຸດແຂງຂອງທັງສອງຝ່າຍມາໃຊ້ໄດ້.

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

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

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

ຂັ້ນຕອນທຳອິດແມ່ນການສຳຫຼວດກໍລະນີການນຳໃຊ້ (Use case) ທີ່ກຳນົດໄວ້ ແລະ ຄວາມຖີ່ໃນການອັບເດດຄວາມຮູ້ດັ່ງກ່າວ.

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

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

ຕໍ່ມາ, ແມ່ນການວັດແທກຕົ້ນທຶນ ແລະ ຄວາມແມ່ນຍຳໃນຂະໜາດຂອງ PoC (ການພິສູດແນວຄວາມຄິດ). ຈຸດປະສົງບໍ່ແມ່ນການປຽບທຽບຕາຕະລາງເທິງເຈ້ຍ, ແຕ່ແມ່ນການເກັບຕົວເລກດ້ວຍຂໍ້ມູນ ແລະ ຄຳສັ່ງ (Query) ຂອງບໍລິສັດເອງ.

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

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

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

ສຳລັບກໍລະນີ RAG, ເນື່ອງຈາກຄວາມຮູ້ຈະຖືກເກັບໄວ້ໃນ Vector Database ພາຍນອກ, ດັ່ງນັ້ນການຄວບຄຸມການເຂົ້າເຖິງ (Access Control) ວ່າໃຜສາມາດຄົ້ນຫາເອກະສານໃດໄດ້ ຈຶ່ງເປັນຈຸດສຳຄັນ ຫຼື ແກນຫຼັກ. ຄວນອອກແບບການຄວບຄຸມໃນລະດັບເອກະສານ ແລະ ລະດັບຜູ້ໃຊ້ ເພື່ອປ້ອງກັນບໍ່ໃຫ້ເນື້ອໃນຂອງເອກະສານລັບຖືກເປີດເຜີຍຜ່ານການຄົ້ນຫາໂດຍຜູ້ໃຊ້ທີ່ບໍ່ມີສິດ. ໃນກໍລະນີຂອງ Fine-tuning, ຕ້ອງລະມັດລະວັງໃນຈຸດທີ່ຂໍ້ມູນການຮຽນຮູ້ຈະຖືກນຳເຂົ້າໄປໄວ້ພາຍໃນຕົວແບບ (Model). ຖ້າຫາກມີການຮຽນຮູ້ຂໍ້ມູນລັບ, ອາດມີຄວາມສ່ຽງທີ່ຂໍ້ມູນນັ້ນຈະຖືກສະແດງອອກມາໂດຍບໍ່ໄດ້ຕັ້ງໃຈຜ່ານຜົນລັພຂອງຕົວແບບ, ດັ່ງນັ້ນການຄັດເລືອກ ແລະ ການປິດບັງຂໍ້ມູນ (Masking) ໃນຂໍ້ມູນການຮຽນຮູ້ຈຶ່ງມີຄວາມສຳຄັນຫຼາຍ.

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

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

ຄວາມຜິດພາດທີ່ພົບເລື້ອຍທີ່ສຸດໃນ RAG ແມ່ນການຫຼຸດລົງຂອງຄວາມຖືກຕ້ອງໃນການຄົ້ນຫາ ເນື່ອງຈາກຄວາມຜິດພາດໃນການອອກແບບ Chunk.

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

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

ສິ່ງທີ່ມັກຈະຖືກມອງຂ້າມໃນການເຮັດ Fine-tuning ຄື Catastrophic Forgetting (ການລືມແບບຫາຍະນະ). ນີ້ແມ່ນປະກົດການທີ່ຕົວແບບສູນເສຍຄວາມສາມາດທົ່ວໄປທີ່ມີມາແຕ່ເດີມ ຫຼັງຈາກໄດ້ຮຽນຮູ້ວຽກງານໃໝ່ເພີ່ມເຕີມ.

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

ວິທີການຫຼີກລ່ຽງຄື ການບໍ່ປັບປ່ຽນ Parameter ທັງໝົດ ແຕ່ໃຫ້ໃຊ້ວິທີເຊັ່ນ LoRA ເພື່ອປັບແຕ່ງພຽງບາງ Parameter ເທົ່ານັ້ນ ເພື່ອຫຼຸດຜ່ອນຜົນກະທົບຕໍ່ຕົວແບບເດີມ. ນອກຈາກນີ້, ການບໍ່ເພີ່ມ Learning Rate ຫຼາຍເກີນໄປ, ບໍ່ຝຶກຝົນຫຼາຍຮອບເກີນໄປ (ບໍ່ໃຫ້ເກີດ Overfitting), ແລະ ການປະສົມຂໍ້ມູນທົ່ວໄປໃນອັດຕາສ່ວນທີ່ເໝາະສົມໃນລະຫວ່າງການຝຶກຝົນ ກໍເປັນວິທີທີ່ມີປະສິດທິຜົນ. ທີ່ສຳຄັນທີ່ສຸດ, ຫຼັງຈາກການຮຽນຮູ້ເພີ່ມເຕີມແລ້ວ ຕ້ອງກວດສອບດ້ວຍຂໍ້ມູນທົດສອບ (Validation Data) ບໍ່ພຽງແຕ່ຄວາມຖືກຕ້ອງຂອງວຽກງານເປົ້າໝາຍເທົ່ານັ້ນ ແຕ່ຕ້ອງກວດສອບນຳວ່າວຽກງານທົ່ວໄປທີ່ເຄີຍເຮັດໄດ້ນັ້ນມີປະສິດທິພາບຫຼຸດລົງຫຼືບໍ່. ການບໍ່ຕັດສິນໃຈວ່າ "ຄວາມຖືກຕ້ອງເພີ່ມຂຶ້ນ" ໂດຍເບິ່ງພຽງແຕ່ຕົວຊີ້ວັດທີ່ແຄບໆ ຄື ຈຸດສຳຄັນ ຫຼື ແກນຫຼັກ ໃນການບໍ່ມອງຂ້າມ Catastrophic Forgetting.