ວິທີເລືອກລະຫວ່າງ Fine-tuning ແລະ RAG: ຄູ່ມືພາກປະຕິບັດໃນການປຽບທຽບດ້ານຕົ້ນທຶນ, ຄວາມແມ່ນຍຳ ແລະ ການນຳໃຊ້

ເມື່ອຈະນຳເອົາ Generative AI ມາໃຊ້ໃນວຽກງານ, ຄຳຖາມທີ່ວ່າ "ຈະນຳເອົາຂໍ້ມູນພາຍໃນອົງກອນມາລວມເຂົ້າກັນໄດ້ແນວໃດ" ນັ້ນ, Fine-tuning ແລະ RAG (Retrieval-Augmented Generation) ແມ່ນ 2 ແນວທາງທີ່ເປັນຕົວແທນຫຼັກ. ແນວທາງທຳອິດແມ່ນການອັບເດດນ້ຳໜັກຂອງ LLM (Large Language Model) ໂດຍກົງເພື່ອຝັງຄວາມຮູ້ລົງໄປ, ສ່ວນແນວທາງຫຼັງແມ່ນການຄົ້ນຫາເອກະສານພາຍນອກແບບ Real-time ເພື່ອສ້າງຄຳຕອບ.

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

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

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

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

ກ່ອນອື່ນ, ມາຈັດລະບຽບກົນໄກພື້ນຖານຂອງແຕ່ລະວິທີ ເພື່ອສ້າງພື້ນຖານໃນການເລືອກໃຊ້ກັນ.

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

ຂັ້ນຕອນການຮຽນຮູ້

• ກຽມຂໍ້ມູນສຳລັບການສອນ (ຄູ່ຂໍ້ມູນ Input ແລະ Output)
• ອັບເດດ Parameter ໃນຂະນະທີ່ຫຼຸດຜ່ອນ Loss function ໃຫ້ໜ້ອຍທີ່ສຸດ
• ນຳເອົາແບບຈຳລອງທີ່ອັບເດດແລ້ວໄປ Deploy ເພື່ອໃຊ້ໃນການອະນຸມານ

ຜົນກະທົບຕໍ່ແບບຈຳລອງຈະປາກົດໃຫ້ເຫັນໃນ 2 ຈຸດຫຼັກ. ຢ່າງທຳອິດແມ່ນ ການກຳນົດຮູບແບບ Output ໃຫ້ຄົງທີ່ (Output style fixation). ເຮັດໃຫ້ສາມາດຮັກສາຮູບແບບການຂຽນ ຫຼື Format ທີ່ສະເພາະເຈາະຈົງໄດ້ຢ່າງສະໝ່ຳສະເໝີ ເຊັ່ນ: ສຳນວນທີ່ເປັນທາງການໃນເອກະສານກົດໝາຍ ຫຼື ຮູບແບບການບັນທຶກໃນບັດຄົນເຈັບ. ຢ່າງທີສອງແມ່ນ ການເສີມສ້າງຄຳສັບໃນໂດເມນນັ້ນໆ (Domain vocabulary enhancement). ຄຳສັບສະເພາະທາງອຸດສາຫະກຳ ຫຼື ສຳນວນທີ່ບໍ່ມີຢູ່ໃນຄຳສັບຂອງ BPE tokenizer (Byte-Pair Encoding Tokenizer) ກໍມີແນວໂນ້ມທີ່ແບບຈຳລອງຈະສາມາດຈັດການໄດ້ງ່າຍຂຶ້ນຜ່ານການຮຽນຮູ້.

ໃນທາງກົງກັນຂ້າມ, ຍັງມີຂໍ້ຈຳກັດທີ່ຄວນລະວັງ:

• ຕົ້ນທຶນການຮຽນຮູ້ສູງ: ການເຮັດ Full fine-tuning ຈະໃຊ້ຊັບພະຍາກອນ GPU (Graphics Processing Unit) ຢ່າງມະຫາສານ
• ຄວາມສົດໃໝ່ຂອງຄວາມຮູ້ຫຼຸດລົງງ່າຍ: ຂໍ້ມູນທີ່ເກີດຂຶ້ນຫຼັງຈາກການຮຽນຮູ້ຈະບໍ່ຖືກສະທ້ອນຢູ່ໃນແບບຈຳລອງ
• ຄວາມສ່ຽງຕໍ່ການເກີດ Hallucination: ອາດມີກໍລະນີທີ່ແບບຈຳລອງພະຍາຍາມຕື່ມຂໍ້ມູນທີ່ບໍ່ມີຢູ່ຈິງໃນຂໍ້ມູນທີ່ໃຊ້ຮຽນຮູ້

ສຳລັບວິທີການຫຼຸດຕົ້ນທຶນ, PEFT (Parameter-Efficient Fine-Tuning) ແລະ LoRA ໄດ້ຮັບຄວາມນິຍົມຢ່າງແຜ່ຫຼາຍ, ເຊິ່ງສາມາດຫຼຸດຕົ້ນທຶນການຮຽນຮູ້ລົງໄດ້ຢ່າງຫຼວງຫຼາຍໂດຍການອັບເດດພຽງແຕ່ບາງສ່ວນຂອງ Low-rank matrix ແທນທີ່ຈະເປັນທຸກ Parameter. ຢ່າງໃດກໍຕາມ, ເນື່ອງຈາກເປັນການປ່ຽນແປງນ້ຳໜັກ (Weight) ຂອງແບບຈຳລອງ, ຈຶ່ງບໍ່ສາມາດຫຼີກລ່ຽງການທີ່ຕ້ອງຮຽນຮູ້ໃໝ່ ແລະ Deploy ໃໝ່ທຸກຄັ້ງທີ່ມີການອັບເດດໄດ້. ຄວາມແຕກຕ່າງທີ່ໃຫຍ່ທີ່ສຸດເມື່ອທຽບກັບ RAG ທີ່ຈະກ່າວເຖິງໃນພາກຕໍ່ໄປ ແມ່ນຄຸນລັກສະນະຂອງ "ຄວາມຮູ້ທີ່ຖືກຄົງຄ່າໄວ້ພາຍໃນແບບຈຳລອງ" ນີ້ເອງ.

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

ຂະບວນການພື້ນຖານໃນການປະມວນຜົນ

1. ແປງຄຳຖາມຂອງຜູ້ໃຊ້ໃຫ້ເປັນ Embedding
2. ດຳເນີນການຄົ້ນຫາຄວາມຄ້າຍຄືກັນ (Similarity Search) ຕໍ່ກັບຖານຂໍ້ມູນ Vector ເພື່ອດຶງ Chunk ທີ່ກ່ຽວຂ້ອງອອກມາ
3. ແຊກເອກະສານທີ່ດຶງມາໄດ້ນັ້ນເຂົ້າໄປໃນ System Prompt ຫຼື Context Window
4. LLM ສ້າງຄຳຕອບໂດຍອີງໃສ່ບໍລິບົດທີ່ຖືກຕື່ມຂໍ້ມູນເຂົ້າໄປ

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

ວິທີການຫຼັກໃນການເພີ່ມຄວາມຖືກຕ້ອງໃນການຄົ້ນຫາ

• Hybrid Search: ປະສົມປະສານລະຫວ່າງ Vector Search ແລະ BM25 (Keyword Search) ໂດຍໃຊ້ RRF ເພື່ອໃຫ້ໄດ້ທັງອັດຕາການດຶງຂໍ້ມູນຄືນ (Recall) ແລະ ຄວາມຖືກຕ້ອງ (Precision)
• ການປັບຂະໜາດ Chunk: ຖ້າຄວາມລະອຽດຂອງເອກະສານຫຍາບເກີນໄປ ຂໍ້ມູນທີ່ບໍ່ຈຳເປັນອາດຈະປົນເຂົ້າມາ, ແຕ່ຖ້າລະອຽດເກີນໄປ ບໍລິບົດອາດຈະສູນເສຍໄປ
• Agentic RAG: ໃຊ້ການຫາເຫດຜົນແບບຫຼາຍຂັ້ນຕອນ (Multi-step reasoning) ເພື່ອຄົ້ນຫາຊ້ຳຫຼາຍຄັ້ງ ເຮັດໃຫ້ສາມາດຕອບຄຳຖາມທີ່ຊັບຊ້ອນໄດ້

ໃນທາງກັບກັນ, RAG ມີຂໍ້ຈຳກັດດ້ານປະລິມານຂໍ້ມູນທີ່ສາມາດບັນຈຸໄດ້ໃນ Context Window ແລະ ຄວາມຮູ້ທີ່ບໍ່ຖືກຄົ້ນຫາພົບຈະບໍ່ຖືກນຳມາໃຊ້ໃນການຕອບ. ນອກຈາກນັ້ນ, ຄຸນນະພາບຂອງການອ້າງອີງ (Grounding) ຍັງຂຶ້ນກັບການອອກແບບ Search Engine ເປັນຢ່າງຫຼາຍ, ດັ່ງນັ້ນການອອກແບບ Index ແລະ ຄວາມຖືກຕ້ອງຂອງການປະມວນຜົນເບື້ອງຕົ້ນ (Pre-processing) ຈຶ່ງເປັນປັດໄຈສຳຄັນທີ່ສົ່ງຜົນຕໍ່ຄຸນນະພາບຂອງຜົນລວມທັງໝົດ.

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

ເບື້ອງຫຼັງຂອງຄວາມເຂົ້າໃຈຜິດນີ້ ມີປັດໄຈດັ່ງຕໍ່ໄປນີ້:

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

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

ກ່າວຄື, ທັງສອງຢ່າງນີ້ບໍ່ໄດ້ແຂ່ງຂັນກັນ ແຕ່ເປັນ ຄວາມສຳພັນແບບເສີມກັນ.

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

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

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

ມາດຕະຖານທີ່ໃຊ້ໃນການປຽບທຽບມີ 4 ຢ່າງຫຼັກໆ ຄື: ຕົ້ນທຶນ, ຄວາມຖືກຕ້ອງ, ຄວາມຖີ່ໃນການອັບເດດ ແລະ ຄວາມປອດໄພ. ນອກຈາກນີ້, ການຈັດປະເພດກໍລະນີການນຳໃຊ້ (Use case) ອອກເປັນ "ປະເພດໃສ່ຄວາມຮູ້ເພີ່ມເຕີມ (Knowledge Injection)" ແລະ "ປະເພດປັບແຕ່ງຮູບແບບ (Style Adaptation)" ຈະເຮັດໃຫ້ເຫັນໄດ້ຊັດເຈນວ່າວິທີການໃດທີ່ເໝາະສົມກວ່າໃນທາງປະຕິບັດ.

ໃນຫົວຂໍ້ H3 ຕໍ່ໄປນີ້, ຈະອະທິບາຍຄຳນິຍາມຂອງແຕ່ລະມາດຕະຖານ ແລະ ເກນການຕັດສິນໃຈທີ່ລະອຽດຕາມລຳດັບ.

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

① ຄ່າໃຊ້ຈ່າຍ (Cost)

• Fine-tuning ຕ້ອງການຊັບພະຍາກອນ GPU ສຳລັບການຮຽນຮູ້ເບື້ອງຕົ້ນ ແລະ ມີຄ່າໃຊ້ຈ່າຍໃນການຮຽນຮູ້ໃໝ່ທຸກຄັ້ງທີ່ມີການອັບເດດໂມເດວ
• RAG ມີຄ່າໃຊ້ຈ່າຍຫຼັກໃນການສ້າງ ແລະ ດຳເນີນງານ Vector Database ໂດຍບໍ່ຈຳເປັນຕ້ອງຮຽນຮູ້ໂມເດວໃໝ່
• ສຳລັບການປັບຕົວຂະໜາດນ້ອຍ, ການໃຊ້ PEFT ເຊັ່ນ LoRA ຫຼື QLoRA ມີແນວໂນ້ມທີ່ຈະຊ່ວຍຫຼຸດຄ່າໃຊ້ຈ່າຍໃນການຮຽນຮູ້ລົງໄດ້ຢ່າງຫຼວງຫຼາຍ

② ຄວາມຖືກຕ້ອງ (Accuracy)

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

③ ຄວາມຖີ່ໃນການອັບເດດ (Update Frequency)

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

④ ຄວາມປອດໄພ (Security)

• ໃນກໍລະນີທີ່ບໍ່ຕ້ອງການສົ່ງຂໍ້ມູນລັບໄປຍັງ Cloud API, ການໃຊ້ໂຄງສ້າງ RAG ທີ່ປະສົມປະສານລະຫວ່າງ Local LLM ແລະ On-premise Vector Database ຈະມີປະສິດທິຜົນ
• ການຕັ້ງຄ່າໂມເດວທີ່ຜ່ານການ Fine-tuning ໄວ້ໃນສະພາບແວດລ້ອມ Offline ກໍເປັນທາງເລືອກໜຶ່ງ, ແຕ່ຈະເຮັດໃຫ້ພາລະໃນການດຳເນີນງານເພື່ອອັບເດດໂມເດວເພີ່ມທະວີຂຶ້ນເລື້ອຍໆ

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

ກ່ອນທີ່ຈະເລືອກວິທີການປັບແຕ່ງ LLM, ສິ່ງສຳຄັນແມ່ນຕ້ອງຈັດປະເພດ "ສິ່ງທີ່ຕ້ອງການແກ້ໄຂ" ຕາມລັກສະນະຂອງ Use Case ເສຍກ່ອນ. ໂດຍສາມາດແບ່ງອອກເປັນ 2 ປະເພດໃຫຍ່ໆ ຄື: ປະເພດເນັ້ນການໃສ່ຄວາມຮູ້ (Knowledge Injection) ແລະ ປະເພດເນັ້ນການປັບຮູບແບບ (Style Adaptation).

ປະເພດເນັ້ນການໃສ່ຄວາມຮູ້ (Knowledge Injection) ແມ່ນກໍລະນີທີ່ຕ້ອງການໃຫ້ໂມເດວສາມາດຈັດການກັບຂໍ້ມູນທີ່ເດີມບໍ່ມີຢູ່ໃນຕົວໂມເດວໄດ້.

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

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

ປະເພດເນັ້ນການປັບຮູບແບບ (Style Adaptation) ແມ່ນກໍລະນີທີ່ຕ້ອງການໃຫ້ຮູບແບບການສະແດງຜົນ, ສຳນວນການຂຽນ ຫຼື ຮູບແບບການຕອບໂຕ້ຂອງໂມເດວສອດຄ່ອງກັບມາດຕະຖານທີ່ກຳນົດໄວ້.

• ຕ້ອງການໃຫ້ສະແດງຜົນໃນຮູບແບບມາດຕະຖານ ເຊັ່ນ: ລາຍງານທາງການແພດ ຫຼື ເອກະສານທາງກົດໝາຍ.
• ການສ້າງເນື້ອຫາໃຫ້ສອດຄ່ອງກັບ Tone of Voice ຂອງແບຣນ.
• ຕ້ອງການເພີ່ມຄວາມຖືກຕ້ອງໃນການສະແດງອອກຢ່າງເປັນທຳມະຊາດໃນພາສາສະເພາະ (ພາສາໄທ, ພາສາຍີ່ປຸ່ນ ແລະ ອື່ນໆ).

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

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

ອີງຕາມມາດຕະຖານການປະເມີນທີ່ໄດ້ກຳນົດໄວ້ໃນພາກກ່ອນໜ້ານີ້, ພວກເຮົາຈະມາປຽບທຽບທາງເລືອກທັງ 3 ຢ່າງ ຄື: Fine-tuning, RAG ແລະ ແນວທາງການປະສົມປະສານ (Combination approach) ໂດຍແບ່ງອອກເປັນ 3 ຈຸດສຳຄັນດັ່ງນີ້:

• ຕົ້ນທຶນ (Cost): ພາລະຄ່າໃຊ້ຈ່າຍລວມທັງຄ່າຝຶກຝົນ (Training), ຄ່າການອະນຸມານ (Inference) ແລະ ຄ່າດຳເນີນງານ.
• ຄວາມແມ່ນຍຳ ແລະ ອາການຫຼອນ (Accuracy and Hallucination): ຄຸນນະພາບຂອງຄຳຕອບ ແລະ ແນວໂນ້ມຂອງຄວາມສ່ຽງຕໍ່ຂໍ້ມູນທີ່ຜິດພາດ.
• ຄວາມງ່າຍໃນການອັບເດດຂໍ້ມູນ (Ease of data updates): ຕົ້ນທຶນໃນການດຳເນີນງານເພື່ອຮັກສາຄວາມສົດໃໝ່ຂອງຂໍ້ມູນ.

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

ການປັບແຕ່ງແບບລະອຽດ (Fine-tuning) ແລະ RAG ມີໂຄງສ້າງຕົ້ນທຶນທີ່ແຕກຕ່າງກັນຢ່າງສິ້ນເຊີງ. ການແບ່ງອອກເປັນ 3 ໄລຍະຈະຊ່ວຍໃຫ້ຕັດສິນໃຈໄດ້ງ່າຍຂຶ້ນ.

ຄ່າໃຊ້ຈ່າຍໃນການຮຽນຮູ້ (ການລົງທຶນເບື້ອງຕົ້ນ)

• Fine-tuning: ເວລາຂອງ GPU ແມ່ນຕົ້ນທຶນຫຼັກ. ການເຮັດ Full fine-tuning ມັກຈະມີລາຄາສູງ, ແຕ່ຖ້າໃຊ້ວິທີ PEFT ເຊັ່ນ LoRA ຫຼື QLoRA ເພື່ອຈຳກັດພາຣາມິເຕີໃນການຮຽນຮູ້, ມີລາຍງານວ່າສາມາດຫຼຸດຕົ້ນທຶນລົງໄດ້ຢ່າງຫຼວງຫຼາຍ.
• RAG: ບໍ່ຈຳເປັນຕ້ອງຮຽນຮູ້ຕົວແບບ (Model) ໃໝ່. ຢ່າງໃດກໍຕາມ, ຈະມີຕົ້ນທຶນໃນການສ້າງ Embedding ຂອງເອກະສານ ແລະ ການສ້າງໂຄງສ້າງພື້ນຖານ ຫຼື Infrastructure ຂອງ Vector Database ໃນເບື້ອງຕົ້ນ.

ຄ່າໃຊ້ຈ່າຍໃນການອະນຸມານ (ຕົ້ນທຶນໃນຂະນະປະຕິບັດງານ)

• ແບບຈຳລອງທີ່ຜ່ານການ Fine-tuning: ບໍ່ຈຳເປັນຕ້ອງໃສ່ເອກະສານຈຳນວນຫຼາຍລົງໃນ Context Window, ເຮັດໃຫ້ການບໍລິໂພກ Token ຕໍ່ 1 ຄຳຮ້ອງຂໍ (Request) ມີແນວໂນ້ມໜ້ອຍລົງ.
• RAG: ເນື່ອງຈາກຕ້ອງມີການສົ່ງ Query ຄົ້ນຫາ + ການໃສ່ Context ຂອງຂໍ້ມູນທີ່ດຶງມາໄດ້, ເຮັດໃຫ້ຈຳນວນ Token ໃນການອະນຸມານ 1 ຄັ້ງເພີ່ມຂຶ້ນໄດ້ງ່າຍ. ໂດຍສະເພາະເມື່ອຕ້ອງອ້າງອີງເອກະສານຫຼາຍສະບັບ, ຕ້ອງໃຊ້ຄວາມລະມັດລະວັງ.

ຄ່າໃຊ້ຈ່າຍໃນການດຳເນີນງານ (ຕົ້ນທຶນຕໍ່ເນື່ອງ)

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

ສະຫຼຸບແນວໂນ້ມໂດຍລວມດ້ານຕົ້ນທຶນ

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

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

ຄຸນລັກສະນະຄວາມແມ່ນຍຳຂອງ Fine-tuning

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

ຄຸນລັກສະນະຄວາມແມ່ນຍຳຂອງ RAG

• ເນື່ອງຈາກເປັນການສ້າງຄຳຕອບໂດຍອີງໃສ່ເອກະສານທີ່ໄດ້ມາຈາກການຄົ້ນຫາ, ແຫຼ່ງທີ່ມາຂອງຂໍ້ມູນຈຶ່ງມີຄວາມຊັດເຈນໄດ້ງ່າຍ
• ຢ່າງໃດກໍຕາມ, ໃນກໍລະນີທີ່ຄວາມແມ່ນຍຳໃນການຄົ້ນຫາຕໍ່າ (ເມື່ອໄດ້ຮັບ Chunk ທີ່ມີຄວາມກ່ຽວຂ້ອງຕໍ່າ), ມັນມັກຈະເກີດ "ການລົ້ມເຫຼວຂອງການອ້າງອີງ (Grounding failure)" ເຊິ່ງເປັນການສ້າງຄຳຕອບທີ່ອີງໃສ່ບໍລິບົດທີ່ຜິດພາດ
• ມີລາຍງານວ່າ ການໃຊ້ການຄົ້ນຫາແບບປະສົມ (Hybrid search) ທີ່ລວມເອົາ BM25 ແລະ Vector database ເຂົ້າດ້ວຍກັນ ສາມາດຊ່ວຍປັບປຸງຄວາມແມ່ນຍຳໃນການຄົ້ນຫາໃຫ້ດີຂຶ້ນໄດ້

ສະຫຼຸບແນວໂນ້ມຂອງອັດຕາການເກີດຮາລູຊິເນຊັນ

ທັງສອງວິທີການບໍ່ສາມາດເຮັດໃຫ້ຮາລູຊິເນຊັນເປັນສູນໄດ້. ສິ່ງທີ່ສຳຄັນຄືການເຂົ້າໃຈສາເຫດທີ່ເຮັດໃຫ້ເກີດຂໍ້ຜິດພາດ ແລະ ນຳໃຊ້ວິທີປ້ອງກັນໂດຍການລວມເອົາ Guardrails ຫຼື ການກວດສອບໂດຍມະນຸດ (Human-in-the-Loop: HITL) ເຂົ້າໄປໃນຂະບວນການ.

ຄວາມງ່າຍໃນການອັບເດດຂໍ້ມູນແມ່ນໜຶ່ງໃນປັດໄຈການປະເມີນຜົນທີ່ເຫັນຄວາມແຕກຕ່າງໄດ້ຊັດເຈນທີ່ສຸດລະຫວ່າງ Fine-tuning ແລະ RAG.

Fine-tuning: ຄ່າໃຊ້ຈ່າຍໃນການອັບເດດສູງ ແລະ ມີບັນຫາເລື່ອງຄວາມທັນສະໄໝ

Fine-tuning ຈຳເປັນຕ້ອງມີການຝຶກຝົນໃໝ່ (Re-training) ທຸກຄັ້ງທີ່ມີການສະທ້ອນຄວາມຮູ້ໃໝ່ໆ. ຂໍ້ທ້າທາຍຫຼັກມີດັ່ງນີ້:

• ການຝຶກຝົນໃໝ່ຕ້ອງໃຊ້ຊັບພະຍາກອນ GPU ແລະ ເວລາເພີ່ມເຕີມ
• ມີໄລຍະເວລາ (Lead time) ຍາວນານຕັ້ງແຕ່ການກຽມຂໍ້ມູນ, ການກວດສອບ, ຈົນເຖິງການ Deploy
• ຍິ່ງມີຄວາມຖີ່ໃນການອັບເດດສູງ, ຄ່າໃຊ້ຈ່າຍໃນການດຳເນີນງານກໍຈະເພີ່ມທະວີຂຶ້ນເລື້ອຍໆ

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

RAG: ສະທ້ອນຂໍ້ມູນໄດ້ທັນທີພຽງແຕ່ປ່ຽນເອກະສານ

ເນື່ອງຈາກ RAG ຈະຄົ້ນຫາເອກະສານທີ່ເກັບໄວ້ໃນ Vector Database ເພື່ອນຳມາສ້າງຄຳຕອບ, ການອັບເດດຂໍ້ມູນຈຶ່ງສຳເລັດໄດ້ດ້ວຍການສ້າງ Index ໃໝ່ເທົ່ານັ້ນ.

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

RAG ເໝາະສົມກັບຄວາມຕ້ອງການທີ່ວ່າ "ອັບເດດມື້ນີ້ ແລະ ຢາກໃຊ້ງານໃນມື້ອື່ນ" ເຊັ່ນ: ການປັບປ່ຽນຄູ່ມືພາຍໃນບໍລິສັດ ຫຼື ການຮອງຮັບການປ່ຽນແປງທາງດ້ານກົດໝາຍ.

ແນວຄິດໃນການນຳມາປະສົມປະສານກັນ

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

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

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

ຕົວຢ່າງກໍລະນີທີ່ລາຍງານວ່າການປັບແຕ່ງແບບລະອຽດມີຄວາມໄດ້ປຽບ ມີດັ່ງນີ້:

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

ສິ່ງເຫຼົ່ານີ້ມັກຈະບໍ່ມີຄວາມສະຖຽນຫາກສັ່ງການຜ່ານ System Prompt ພຽງຢ່າງດຽວ ເນື່ອງຈາກຍິ່ງ Prompt ຍາວເທົ່າໃດ ກໍຍິ່ງໃຊ້ Context Window ຫຼາຍຂຶ້ນ ແລະ ເຮັດໃຫ້ຕົ້ນທຶນໃນການອະນຸມານ (Inference cost) ເພີ່ມຂຶ້ນ.

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

ຢ່າງໃດກໍຕາມ, ຍັງມີຂໍ້ຄວນລະວັງ:

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

ສຳລັບ ວຽກງານທີ່ໃຫ້ຄວາມສຳຄັນກັບ "ຄວາມສອດຄ່ອງຂອງຮູບແບບ" ເປັນອັນດັບໜຶ່ງ, ການເລືອກໃຊ້ການປັບແຕ່ງແບບລະອຽດຖືເປັນທາງເລືອກທີ່ສົມເຫດສົມຜົນທີ່ສຸດ.

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

ກົນໄກ ແລະ ຂໍ້ດີຂອງ LoRA

LoRA ເປັນວິທີການທີ່ຄົງຄ່າໄວ້ (ແຊ່ແຂງໄວ້) ພາຣາມິເຕີເດີມຂອງໂມເດວ, ໂດຍການເພີ່ມເມທຣິກ (Matrix) ທີ່ມີລະດັບຕ່ຳ (Low-rank) ເຂົ້າໄປເພື່ອຮຽນຮູ້ສະເພາະສ່ວນທີ່ແຕກຕ່າງເທົ່ານັ້ນ. ເນື່ອງຈາກເປົ້າໝາຍໃນການອັບເດດຖືກຈຳກັດໄວ້ພຽງ 1-5% ຂອງທັງໝົດ, ຈຶ່ງເຮັດໃຫ້ເກີດຂໍ້ດີດັ່ງນີ້:

• ສາມາດຫຼຸດໜ່ວຍຄວາມຈຳ GPU ທີ່ຈຳເປັນໃນການຮຽນຮູ້ໄດ້ຢ່າງຫຼວງຫຼາຍ
• ເວລາໃນການຮຽນຮູ້ສັ້ນລົງ ແລະ ຊ່ວຍໃຫ້ຄວບຄຸມຄ່າໃຊ້ຈ່າຍໃນ Cloud ໄດ້ງ່າຍຂຶ້ນ
• ສາມາດປ່ຽນແທນ ອາແດັບເຕີ ຫຼື ສ່ວນເສີມ (Adapter) ຂອງ LoRA ໄດ້ຫຼາຍອັນ ໃນຂະນະທີ່ຍັງຮັກສາ Base Model ເດີມໄວ້ໄດ້

ການເພີ່ມປະສິດທິພາບໃຫ້ເບົາບາງລົງດ້ວຍ QLoRA

QLoRA ເປັນວິທີການທີ່ນຳເອົາ LoRA ມາລວມກັບການເຮັດ Quantization ເຊິ່ງສາມາດໂຫຼດໂມເດວໃນຄວາມລະອຽດ 4-bit ເພື່ອຮຽນຮູ້ໄດ້. ມີລາຍງານວ່າໃນກໍລະນີທີ່ໃຊ້ GPU ສຳລັບຜູ້ບໍລິໂພກພຽງໃບດຽວ ກໍສາມາດປັບແຕ່ງໂມເດວທີ່ມີຂະໜາດຫຼາຍພັນລ້ານພາຣາມິເຕີໄດ້, ເຊິ່ງເປັນທາງເລືອກທີ່ມີປະສິດທິພາບສຳລັບການນຳໄປໃຊ້ໃນສະພາບແວດລ້ອມ On-premise ຫຼື Local LLM.

ຂໍ້ຄວນລະວັງໃນການປະຕິບັດງານ

• ປະລິມານຂໍ້ມູນທີ່ແນະນຳ: ມີແນວໂນ້ມທີ່ຈະເຫັນຜົນໄດ້ດີຈາກຕົວຢ່າງການຮຽນຮູ້ທີ່ມີຄຸນນະພາບສູງປະມານ ຫຼາຍຮ້ອຍ ຫາ ຫຼາຍພັນລາຍການ
• ການຕັ້ງຄ່າ Rank (r): ຍິ່ງ r ມີຄ່ານ້ອຍ ໂມເດວກໍຍິ່ງເບົາບາງ ແຕ່ຄວາມສາມາດໃນການສະແດງອອກກໍຈະຫຼຸດລົງ, ດັ່ງນັ້ນຈຶ່ງຈຳເປັນຕ້ອງປັບຕາມຄວາມຊັບຊ້ອນຂອງວຽກ
• ຄວາມສ່ຽງຕໍ່ການເກີດ Overfitting: ໃນກໍລະນີທີ່ມີຂໍ້ມູນໜ້ອຍ ຫ້າມລະເລີຍການປະເມີນຜົນດ້ວຍ Validation Set ເດັດຂາດ

PEFT ແລະ LoRA ເປັນທາງເຂົ້າທີ່ເປັນຈິງສຳລັບອົງກອນທີ່ເຫັນວ່າ "ການເຮັດ Full Fine-tuning ມີຄ່າໃຊ້ຈ່າຍສູງເກີນໄປ" ເພື່ອໃຫ້ສາມາດປັບແຕ່ງຮູບແບບ (Style) ຫຼື ເຮັດໃຫ້ຄຳສັບສະເພາະທາງມີຄວາມຊັດເຈນຂຶ້ນໄດ້. ວິທີການທີ່ໝັ້ນຄົງທີ່ສຸດຄືການທົດລອງໃນຂະໜາດ PoC ກ່ອນ, ຈາກນັ້ນຈຶ່ງກວດສອບ ການແລກປ່ຽນ ຫຼື Trade-off ລະຫວ່າງຄວາມແມ່ນຍຳ ແລະ ຄ່າໃຊ້ຈ່າຍ ກ່ອນທີ່ຈະຕັດສິນໃຈນຳໄປໃຊ້ງານຈິງ.

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

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

ເຫດຜົນຫຼັກທີ່ RAG ມີຄວາມເໝາະສົມ

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

ຮູບແບບການນຳໃຊ້ຕົວຈິງ

ຕົວຢ່າງເຊັ່ນ: ໃນໜ້າວຽກຂອງອຸດສາຫະກຳການຜະລິດ, ຄູ່ມືຜະລິດຕະພັນມັກຈະມີການອັບເດດເວີຊັນຢູ່ເລື້ອຍໆ. ພຽງແຕ່ແບ່ງ PDF ເວີຊັນໃໝ່ອອກເປັນ Chunk ແລ້ວລົງທະບຽນເຂົ້າໃນ Vector Database ໃໝ່, AI Chatbot ກໍຈະສາມາດແນະນຳຂັ້ນຕອນການເຮັດວຽກທີ່ທັນສະໄໝໄດ້. ສຳລັບການນຳໃຊ້ກົດລະບຽບພາຍໃນຂອງພະແນກບຸກຄະລາກອນກໍເຊັ່ນກັນ, ຫາກເພີ່ມເນື້ອຫາການແກ້ໄຂກົດລະບຽບການເຮັດວຽກເຂົ້າໄປໃນ Index, ກໍສາມາດອັບເດດການຕອບຄຳຖາມຂອງພະນັກງານໃຫ້ເປັນປັດຈຸບັນໄດ້ທັນທີ.

ຂໍ້ຄວນລະວັງ

ຢ່າງໃດກໍຕາມ, ຄວາມຖືກຕ້ອງໃນການຄົ້ນຫາຈະຂຶ້ນຢູ່ກັບຂະໜາດຂອງ Chunk ແລະ ຄຸນນະພາບຂອງ Embedding Model. ໃນກໍລະນີທີ່ໂຄງສ້າງຂອງເອກະສານມີຄວາມຊັບຊ້ອນ, ມີລາຍງານວ່າການນຳໃຊ້ Hybrid Search (BM25 + Dense Model) ມາປະສົມປະສານກັນຈະຊ່ວຍເພີ່ມຄວາມຖືກຕ້ອງໃຫ້ສູງຂຶ້ນ. ໃນການນຳໃຊ້ດ້ານກົດໝາຍ ແລະ ການປະຕິບັດຕາມກົດລະບຽບ (Compliance) ທີ່ຈະກ່າວເຖິງໃນພາກຕໍ່ໄປ, ຄຸນລັກສະນະການລະບຸແຫຼ່ງທີ່ມາຂອງຂໍ້ມູນນີ້ຈະມີບົດບາດສຳຄັນຍິ່ງຂຶ້ນ.

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

ເຫດຜົນທີ່ RAG ມີຄວາມໂດດເດັ່ນໃນການຈັດການການອ້າງອີງ ແລະ ແຫຼ່ງທີ່ມາ

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

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

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

ສຳລັບການນຳໃຊ້ໃນດ້ານ Compliance, ມີລາຍງານວ່າການອັບເດດ Index ຂອງເອກະສານກົດລະບຽບຕ່າງໆ ເຊັ່ນ EU AI Act ຫຼື PDPA ຢ່າງສະໝໍ່າສະເໝີ ສາມາດຊ່ວຍຫຼຸດຕົ້ນທຶນໃນການຮັບມືກັບການປ່ຽນແປງຂອງກົດໝາຍໄດ້.

ການແບ່ງໜ້າທີ່ກັບ Fine-tuning

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

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

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

ໂຄງສ້າງພື້ນຖານຂອງສະຖາປັດຕະຍະກຳ

• ຊັ້ນ Fine-tuning: ເຮັດໃຫ້ແບບຈໍາລອງໄດ້ຮຽນຮູ້ກ່ຽວກັບນໍ້າສຽງສະເພາະຂອງອຸດສາຫະກຳ, ຮູບແບບການສະແດງຜົນ ແລະ ການນຳໃຊ້ຄຳສັບສະເພາະທາງດ້ານເຕັກນິກ.
• ຊັ້ນ RAG: ດຶງຂໍ້ມູນລະບຽບການພາຍໃນບໍລິສັດ ຫຼື ຂໍ້ມູນຜະລິດຕະພັນຫຼ້າສຸດຈາກ Vector Database ແບບ Real-time ເພື່ອໃສ່ເຂົ້າໄປໃນ Context Window.
• ຊັ້ນ System Prompt: ເຮັດໜ້າທີ່ເປັນຕົວເຊື່ອມຕໍ່ລະຫວ່າງທັງສອງສ່ວນ ໂດຍລະບຸຄຳສັ່ງວ່າຈະນຳໃຊ້ຜົນການຄົ້ນຫາແນວໃດ.

ໃນໂຄງສ້າງນີ້, ການ Fine-tuning ຈະຮັບຜິດຊອບໃນສ່ວນຂອງ "ວິທີການຕອບ", ສ່ວນ RAG ຈະຮັບຜິດຊອບໃນສ່ວນຂອງ "ເນື້ອຫາທີ່ຈະຕອບ", ເຮັດໃຫ້ການແບ່ງໜ້າທີ່ຮັບຜິດຊອບມີຄວາມຊັດເຈນ.

ຂໍ້ຄວນລະວັງໃນການອອກແບບ

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

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

ໃນຂັ້ນຕອນ PoC, ລຳດັບທີ່ສົມເຫດສົມຜົນໃນດ້ານການຄຸ້ມຄອງຕົ້ນທຶນຄື: ການກວດສອບຄວາມຖືກຕ້ອງດ້ວຍ Base model + RAG ກ່ອນ, ແລະ ຖ້າຄຸນນະພາບຂອງຜົນລວມຍັງບໍ່ພຽງພໍ ຈຶ່ງຄ່ອຍເພີ່ມການ Fine-tuning ດ້ວຍ PEFT ຫຼື LoRA ເຂົ້າໄປ.

Agentic RAG ແມ່ນສະຖາປັດຕະຍະກຳທີ່ AI agent ຄວບຄຸມຂັ້ນຕອນການຄົ້ນຫາຂອງ RAG ຢ່າງເປັນອິດສະຫຼະ. ໃນຂະນະທີ່ RAG ແບບຄົງທີ່ແບບດັ້ງເດີມມີຂັ້ນຕອນທີ່ຕາຍຕົວຄື "ການຄົ້ນຫາ 1 ຄັ້ງ → ການສ້າງຄຳຕອບ", ໃນ Agentic RAG ນັ້ນ, agent ຈະເຮັດຊ້ຳການ ຄົ້ນຫາ, ການຕັດສິນໃຈ, ແລະ ການຄົ້ນຫາໃໝ່ ຫຼາຍຄັ້ງຢ່າງມີພະລັງ (dynamically).

ການນຳເອົາໂມເດວທີ່ຜ່ານການ Fine-tuning ມາປະສົມປະສານກັບ Agentic RAG ຈະເຮັດໃຫ້ເກີດການແບ່ງໜ້າທີ່ດັ່ງນີ້:

• ໂມເດວທີ່ຜ່ານການ Fine-tuning: ຮັບຜິດຊອບດ້ານຮູບແບບການຂຽນ, ຮູບແບບຜົນລວມ (Output format), ແລະ ຄຳສັບສະເພາະທາງດ້ານອຸດສາຫະກຳ.
• ຊັ້ນຂອງ Agent (Agent layer): ຮັບຜິດຊອບການແຍກ Query, ການຕັດສິນໃຈລຳດັບການເອີ້ນໃຊ້ເຄື່ອງມືຄົ້ນຫາ, ແລະ ການປະເມີນຜົນລວມ.
• Vector Database: ຮັບຜິດຊອບການຈັດເກັບເອກະສານຫຼ້າສຸດ ແລະ ການຄົ້ນຫາຄວາມຄ້າຍຄືກັນ.

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

ຂໍ້ດີຫຼັກຂອງການອອກແບບນີ້ມີດັ່ງນີ້:

• ສາມາດຮອງຮັບການຫາເຫດຜົນແບບຫຼາຍຂັ້ນຕອນ (Multi-step reasoning) ຈຶ່ງມີທ່າອ່ຽງທີ່ຈະເພີ່ມຄວາມຖືກຕ້ອງໃນການຕອບຄຳຖາມທີ່ຊັບຊ້ອນ.
• ເນື່ອງຈາກມີການຄົ້ນຫາໃໝ່ໂດຍອັດຕະໂນມັດໃນກໍລະນີທີ່ຜົນການຄົ້ນຫາບໍ່ພຽງພໍ, ຈຶ່ງສາມາດຄວບຄຸມການເກີດ Hallucination ໄດ້ງ່າຍຂຶ້ນ.
• ເຖິງແມ່ນວ່າເອກະສານຈະມີການອັບເດດ, ກໍບໍ່ຈຳເປັນຕ້ອງອອກແບບຊັ້ນຂອງ Agent ໃໝ່, ສາມາດຮອງຮັບໄດ້ພຽງແຕ່ການອັບເດດ Vector Database ເທົ່ານັ້ນ.

ໃນທາງກົງກັນຂ້າມ, ຕ້ອງລະມັດລະວັງໃນຈຸດທີ່ຕົ້ນທຶນໃນການອອກແບບ ແລະ ທົດສອບ Agent orchestration ຈະເພີ່ມຂຶ້ນ. ໃນຂັ້ນຕອນ PoC, ການເລີ່ມຕົ້ນຈາກ RAG ແບບຄົງທີ່ ແລະ ຄ່ອຍໆປັບປ່ຽນໄປສູ່ Agentic RAG ເມື່ອມີຄວາມຈຳເປັນຕ້ອງຮອງຮັບ Query ທີ່ຊັບຊ້ອນນັ້ນ ເປັນວິທີທີ່ເໝາະສົມໃນຄວາມເປັນຈິງ.

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

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

ເມື່ອທ່ານລັງເລໃນການເລືອກວິທີການ, ການຕັດສິນໃຈໂດຍໃຊ້ 3 ຂັ້ນຕອນຕໍ່ໄປນີ້ຈະຊ່ວຍໃຫ້ຈັດລະບຽບໄດ້ງ່າຍຂຶ້ນ.

ຂັ້ນຕອນທີ 1: ກວດສອບງົບປະມານ

ແຍກການປະເມີນລະຫວ່າງການລົງທຶນເບື້ອງຕົ້ນ ແລະ ຄ່າໃຊ້ຈ່າຍໃນການດຳເນີນງານ ເຊັ່ນ: ຄ່າບໍລິການ GPU Cloud ຫຼື ຄ່າທຳນຽມ API.

• ການ Fine-tuning ຈະມີຄ່າໃຊ້ຈ່າຍ GPU ເກີດຂຶ້ນໃນລະຫວ່າງການຮຽນຮູ້, ແຕ່ການອະນຸມານ (Inference) ຈະມີຄ່າໃຊ້ຈ່າຍເທົ່າກັບ LLM ທົ່ວໄປ
• RAG ມີຄ່າໃຊ້ຈ່າຍຫຼັກຄື ຄ່າບຳລຸງຮັກສາ Vector Database ແລະ ຄ່າທຳນຽມ Search API
• ໃນກໍລະນີທີ່ງົບປະມານຈຳກັດ, ສາມາດພິຈາລະນາທາງເລືອກໃນການໃຊ້ PEFT ໂດຍຜ່ານ LoRA ຫຼື QLoRA ເພື່ອຄວບຄຸມຕົ້ນທຶນການຮຽນຮູ້ໄດ້

ຂັ້ນຕອນທີ 2: ກວດສອບປະລິມານຂໍ້ມູນທີ່ມີຢູ່

ປະເມີນທັງ "ປະລິມານ" ແລະ "ຄຸນນະພາບ" ຂອງຂໍ້ມູນທີ່ມີຢູ່ໃນມື.

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

ຂັ້ນຕອນທີ 3: ກວດສອບຄວາມຖີ່ໃນການອັບເດດ

ຄວາມຕ້ອງການດ້ານຄວາມສົດໃໝ່ຂອງຂໍ້ມູນມີຜົນໂດຍກົງຕໍ່ການເລືອກວິທີການ.

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

ຖ້າຫາກຍັງຕັດສິນໃຈໄດ້ຍາກຫຼັງຈາກຜ່ານ 3 ຂັ້ນຕອນແລ້ວ, ຂໍໃຫ້ກວດສອບຈຸດພິຈາລະນາເພີ່ມເຕີມກ່ຽວກັບສະພາບແວດລ້ອມຫຼາຍພາສາທີ່ຈະອະທິບາຍໃນພາກຕໍ່ໄປ.

ໃນສະພາບແວດລ້ອມທີ່ຈັດການກັບພາສາໄທ ແລະ ພາສາຍີ່ປຸ່ນໄປພ້ອມກັນ, ນອກເໜືອໄປຈາກການເລືອກລະຫວ່າງການ Fine-tuning ແບບງ່າຍໆ ກັບ RAG ແລ້ວ, ຍັງຈຳເປັນຕ້ອງພິຈາລະນາເຖິງອຸປະສັກທາງດ້ານເຕັກນິກສະເພາະຂອງແຕ່ລະພາສາ.

ບັນຫາດ້ານ Tokenizer

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

ຂໍ້ຄວນລະວັງໃນການ Fine-tuning

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

ຂໍ້ຄວນລະວັງໃນການອອກແບບ RAG

• ຄຸນນະພາບການຮອງຮັບຫຼາຍພາສາຂອງ Embedding Model ມີຄວາມແຕກຕ່າງກັນຢ່າງຫຼວງຫຼາຍໃນແຕ່ລະ Model. ເພື່ອຮັບປະກັນຄວາມຖືກຕ້ອງໃນການຄົ້ນຫາຄວາມໝາຍຂອງພາສາໄທ, ຄວນເລືອກ Model ທີ່ຮອງຮັບ Multilingual NLP ແລະ ຄວນກວດສອບຄວາມຖືກຕ້ອງດ້ວຍການວັດແທກຕົວຈິງ.
• ໃນກໍລະນີທີ່ນຳໃຊ້ Hybrid Search (BM25 + Vector Search), ຕ້ອງກວດສອບໃຫ້ແນ່ໃຈວ່າ Morphological Analyzer ຂອງ BM25 ຮອງຮັບພາສາໄທ ແລະ ພາສາຍີ່ປຸ່ນ.

ມາດຕະຖານໃນການຕັດສິນໃຈທາງປະຕິບັດ

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

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

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

ໃນກໍລະນີຂອງ Full Fine-tuning

• ໂດຍທົ່ວໄປແລ້ວ ຕົວຢ່າງການຮຽນຮູ້ທີ່ມີຄຸນນະພາບສູງປະມານພັນຫາໝື່ນລາຍການແມ່ນຖືເປັນມາດຕະຖານ
• ຍິ່ງຂໍ້ມູນໜ້ອຍເທົ່າໃດ ກໍຍິ່ງມີຄວາມສ່ຽງຕໍ່ການເກີດ Overfitting ສູງຂຶ້ນ ແລະ ມີແນວໂນ້ມທີ່ຄວາມສາມາດໃນການນຳໄປໃຊ້ງານທົ່ວໄປຈະຫຼຸດລົງ
• ຍິ່ງ Model ມີຂະໜາດໃຫຍ່ເທົ່າໃດ ປະລິມານຂໍ້ມູນທີ່ຕ້ອງການກໍຍິ່ງເພີ່ມທະວີຂຶ້ນເລື້ອຍໆ ຈຶ່ງຈຳເປັນຕ້ອງພິຈາລະນາເຖິງ ການແລກປ່ຽນ ຫຼື Trade-off ກັບຕົ້ນທຶນ GPU

ໃນກໍລະນີທີ່ໃຊ້ PEFT / LoRA

• ມີລາຍງານວ່າໃນບາງກໍລະນີ ພຽງແຕ່ຫຼັກຮ້ອຍຫາຫຼັກພັນລາຍການກໍໃຫ້ຜົນລັພທີ່ດີໃນລະດັບໜຶ່ງ
• ເນື່ອງຈາກ LoRA ອັບເດດພຽງແຕ່ບາງສ່ວນຂອງນ້ຳໜັກ (Weights) ໃນ Model ຈຶ່ງເຮັດໃຫ້ສາມາດຄວບຄຸມການເກີດ Overfitting ໄດ້ງ່າຍຂຶ້ນເຖິງແມ່ນວ່າຂໍ້ມູນຈະໜ້ອຍ
• ຖ້າໃຊ້ QLoRA ຈະສາມາດຫຼຸດການໃຊ້ງານໜ່ວຍຄວາມຈຳລົງໄດ້ອີກ ເຮັດໃຫ້ສາມາດທົດລອງເທິງ GPU ທີ່ມີຢູ່ໄດ້ງ່າຍຂຶ້ນ

ນອກຈາກນີ້ ຍັງບໍ່ຄວນເບິ່ງຂ້າມຈຸດທີ່ວ່າ ຄຸນນະພາບຂອງຂໍ້ມູນມີຄວາມສຳຄັນຫຼາຍກວ່າປະລິມານຂອງຂໍ້ມູນ. ມັນບໍ່ແມ່ນເລື່ອງແປກທີ່ຂໍ້ມູນ 500 ລາຍການທີ່ມີການຕິດປ້າຍກຳກັບ (Labeling) ຢ່າງລະອຽດ ຈະໃຫ້ຜົນລັພທີ່ດີກວ່າຂໍ້ມູນ 10,000 ລາຍການທີ່ມີສຽງລົບກວນ (Noise) ຫຼາຍ.

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

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

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

ຕົວຢ່າງໂຄງສ້າງຫຼັກໃນການປະສົມປະສານໃນສະພາບແວດລ້ອມ Local

• Base Model: Fine-tuning ດ້ວຍ QLoRA ໂດຍໃຊ້ Open-weight models ເຊັ່ນ: Llama ຫຼື Mistral
• Vector Database: ສ້າງ Chroma ຫຼື Weaviate ແບບ On-premise
• Embedding Model: ປ່ຽນເອກະສານໃຫ້ເປັນ Vector ດ້ວຍ Model ທີ່ເຮັດວຽກໃນ Local ເຊັ່ນ: BGE ຫຼື E5
• Inference Server: ສ້າງ API endpoint ດ້ວຍ Ollama ຫຼື vLLM

ດ້ວຍໂຄງສ້າງນີ້, ຈະເຮັດໃຫ້ເກີດ ຂະບວນການ ຫຼື Pipeline ຂອງ RAG ທີ່ສຳເລັດສົມບູນພາຍໃນເຄືອຂ່າຍຂອງບໍລິສັດ.

ຈຸດທີ່ຄວນລະວັງ

• ມີຂໍ້ຈຳກັດດ້ານ GPU memory ຫຼາຍ, ເຮັດໃຫ້ Model ທີ່ມີປະມານ 7B parameters ເປັນທາງເລືອກທີ່ເປັນໄປໄດ້ຫຼາຍທີ່ສຸດໃນຫຼາຍກໍລະນີ
• ຖ້າບໍ່ເຮັດໃຫ້ການຮອງຮັບພາສາຂອງ Model ຫຼັງຈາກ Fine-tuning ແລະ Embedding model ໃຫ້ກົງກັນ, ຄວາມຖືກຕ້ອງໃນການຄົ້ນຫາພາສາຢີ່ປຸ່ນ ຫຼື ພາສາໄທມີແນວໂນ້ມທີ່ຈະຫຼຸດລົງ
• ສາມາດບີບອັດຂະໜາດ Model ດ້ວຍການ Quantization ໄດ້, ແຕ່ຈຳເປັນຕ້ອງມີການກວດສອບ ການແລກປ່ຽນ ຫຼື Trade-off ກັບຄວາມຖືກຕ້ອງ

ຄວາມເປັນຈິງດ້ານຕົ້ນທຶນ

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

ໂຄງສ້າງການປະສົມປະສານດ້ວຍ Local LLM ມີຄວາມທ້າທາຍທາງດ້ານເຕັກນິກສູງ, ແຕ່ກໍເປັນທາງເລືອກທີ່ສຳຄັນໃນສະພາບແວດລ້ອມທີ່ມີຄວາມຕ້ອງການດ້ານອະທິປະໄຕຂອງຂໍ້ມູນ (Data Sovereignty) ແລະ ຄວາມປອດໄພທີ່ເຂັ້ມງວດ. ແນະນຳໃຫ້ເລີ່ມກວດສອບໃນລະດັບ PoC ເພື່ອພິຈາລະນາຄວາມສົມດຸນລະຫວ່າງຕົ້ນທຶນການດຳເນີນງານ ແລະ ຄວາມຖືກຕ້ອງ.

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

ກໍລະນີທີ່ເໝາະສົມກັບ Fine-tuning:

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

ກໍລະນີທີ່ເໝາະສົມກັບ RAG:

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

ກໍລະນີທີ່ການນຳມາປະສົມປະສານກັນມີປະສິດທິຜົນ:

• ຕ້ອງການທັງຄວາມສາມາດໃນການສະແດງອອກສະເພາະດ້ານ (Domain-specific) ແລະ ການຄົ້ນຫາຂໍ້ມູນ ແບບ Real-time
• ຂະບວນການເຮັດວຽກທີ່ຕ້ອງການການຄາດເດົາຫຼາຍຂັ້ນຕອນແບບເຄື່ອນໄຫວດ້ວຍ Agentic RAG

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

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