RAG (Retrieval-Augmented Generation) ແມ່ນສະຖາປັດຕະຍະກຳເຕັກໂນໂລຊີທີ່ຄົ້ນຫາເອກະສານພາຍນອກແບບ Real-time ແລະນຳເອົາເນື້ອຫານັ້ນມາລວມເຂົ້າໃນການສ້າງຄຳຕອບຂອງ LLM.

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

ບົດຄວາມນີ້ມີກຸ່ມເປົ້າໝາຍຄື:

• ວິສະວະກອນທີ່ເຮັດ PoC (Proof of Concept) ຂອງ RAG ສຳເລັດແລ້ວ ແຕ່ກຳລັງປະສົບກັບບັນຫາໃນການນຳໄປໃຊ້ງານຈິງ
• ວິສະວະກອນ ML ຫຼື ຫົວໜ້າທີມພັດທະນາທີ່ກຳລັງປະເຊີນກັບບັນຫາຄວາມຖືກຕ້ອງໃນການຄົ້ນຫາ ຫຼື ບັນຫາ Hallucination ແລະ ກຳລັງຊອກຫາທາງອອກໃນການປັບປຸງ
• ສະຖາປະນິກທີ່ກຳລັງຈະອອກແບບ ແລະ ນຳ RAG ມາໃຊ້ງານ ແລະ ຕ້ອງການຮຽນຮູ້ຮູບແບບຄວາມຜິດພາດຕ່າງໆໄວ້ລ່ວງໜ້າ

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

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

ເບື້ອງຫຼັງຂອງບັນຫາດັ່ງກ່າວແມ່ນມາຈາກຂະບວນການ ຫຼື Pipeline ການປະມວນຜົນທີ່ຊັບຊ້ອນສະເພາະຂອງ RAG. ບໍ່ວ່າຈະເປັນການກຽມເອກສານລ່ວງໜ້າ, ການແບ່ງສ່ວນຂໍ້ມູນ (Chunking), ການສ້າງ Embedding, ການຄົ້ນຫາແບບ Vector, ການປະກອບ Prompt, ແລະ ການວິເຄາະຂອງ LLM, ເຊິ່ງລ້ວນແຕ່ເປັນຈຸດທີ່ມີຄວາມສ່ຽງຕໍ່ການເກີດຂໍ້ຜິດພາດໄດ້ຫຼາຍຈຸດ.

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

RAG (Retrieval-Augmented Generation) ໄດ້ຖືກນຳມາໃຊ້ຢ່າງກວ້າງຂວາງໃນຖານະເປັນສະຖາປັດຕະຍະກຳທີ່ຊ່ວຍບັນເທົາ "ບັນຫາຄວາມສົດໃໝ່ຂອງຂໍ້ມູນ" ແລະ "ບັນຫາການສ້າງຂໍ້ມູນທີ່ບໍ່ຖືກຕ້ອງ (Hallucination)" ຂອງ LLM ໄປພ້ອມໆກັນ. ເນື່ອງຈາກໂມເດວຢ່າງ GPT ຫຼື Claude ບໍ່ມີຂໍ້ມູນຫຼັງຈາກວັນທີຕັດຍອດ (Cut-off) ຂອງຂໍ້ມູນທີ່ໃຊ້ຝຶກສອນ, ໃນສະຖານະການທີ່ຕ້ອງການໃຫ້ອ້າງອີງເອກະສານພາຍໃນບໍລິສັດ ຫຼື ມາດຕະຖານ ຫຼື Specification ຜະລິດຕະພັນຫຼ້າສຸດ, ການໃຊ້ໂມເດວພຽງຢ່າງດຽວຈຶ່ງເຮັດວຽກໄດ້ຍາກ. RAG ຈຶ່ງເປັນວິທີການທີ່ມີປະສິດທິພາບໃນການຊົດເຊີຍຈຸດອ່ອນດັ່ງກ່າວ.

ຢ່າງໃດກໍຕາມ, ມັນກໍມີຄວາມຫຍຸ້ງຍາກທາງດ້ານໂຄງສ້າງເຊັ່ນກັນ. ຂະບວນການ ຫຼື Pipeline ຂອງ RAG ປະກອບດ້ວຍອົງປະກອບຫຼັກໆດັ່ງນີ້:

• ການກຽມເອກະສານລ່ວງໜ້າ: ການປັບຮູບແບບເອກະສານທີ່ຫຼາກຫຼາຍເຊັ່ນ PDF, HTML, Markdown ໃຫ້ເປັນມາດຕະຖານ
• ການແບ່ງສ່ວນ (Chunking): ການອອກແບບຂະໜາດ ແລະ ຂອບເຂດເພື່ອແບ່ງຂໍ້ຄວາມໃຫ້ເປັນໜ່ວຍທີ່ສາມາດຄົ້ນຫາໄດ້
• ການຝັງຂໍ້ຄວາມ (Embedding): ການເລືອກໂມເດວເພື່ອປ່ຽນຂໍ້ຄວາມໃຫ້ເປັນ Vector
• Vector Store: ການສ້າງດັດສະນີ (Index) ແລະ ການຕັ້ງຄ່າການຄົ້ນຫາແບບໃກ້ຄຽງ (Approximate Nearest Neighbor Search)
• ການຄົ້ນຫາ (Retrieval): ເຫດຜົນ (Logic) ໃນການດຶງເອົາສ່ວນຂອງຂໍ້ມູນທີ່ກ່ຽວຂ້ອງກັບ Query
• ການສ້າງຄຳຕອບ (Generation): ການນຳຜົນທີ່ໄດ້ຈາກການຄົ້ນຫາໄປໃສ່ໃນ Prompt ເພື່ອໃຫ້ LLM ສ້າງຄຳຕອບ

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

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

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

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

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

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

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

• ຮູບແບບການຝັງ (Embedding model) ແລະ LLM ບໍ່ຮອງຮັບພາສາທີ່ກົງກັນ (ເຊັ່ນ: ການໃຊ້ໂມເດວພາສາອັງກິດເພື່ອປະມວນຜົນເອກະສານພາສາຢີ່ປຸ່ນ)
• ການເພິ່ງພາອາໄສພຽງແຕ່ການຄົ້ນຫາແບບ Vector ເຮັດໃຫ້ພາດການສອບຖາມທີ່ຕ້ອງການການຈັບຄູ່ຄຳສຳຄັນ (Keyword match)
• ການລະເລີຍຂະບວນການຈັດລຳດັບໃໝ່ (Re-ranking), ເຮັດໃຫ້ Chunk ທີ່ມີຄວາມກ່ຽວຂ້ອງຕ່ຳຖືກສົ່ງຕໍ່ໃຫ້ LLM ໂດຍກົງ

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

ໃນ ໄລຍະການດຳເນີນງານ, ການຄຸ້ມຄອງຄວາມທັນສະໄໝຂອງເອກະສານແມ່ນຈຸດບອດທີ່ໃຫຍ່ທີ່ສຸດ.

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

ການສ້າງນິໄສໃນການ ທົບທວນຂ້າມທັງສາມໄລຍະ ຄືບາດກ້າວທຳອິດໃນການປ້ອງກັນຄວາມລົ້ມເຫຼວໃນການສ້າງ RAG.

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

ໄລຍະການອອກແບບ (ຮູບແບບ 1-3)

• ຮູບແບບ 1: ການອອກແບບຂະໜາດ Chunk ຜິດພາດ
• ຮູບແບບ 2: ການຂາດການອອກແບບ Metadata
• ຮູບແບບ 3: ການເລືອກ Embedding Model ທີ່ບໍ່ເໝາະສົມກັບ Use Case

ໄລຍະການຈັດຕັ້ງປະຕິບັດ (ຮູບແບບ 4-7)

• ຮູບແບບ 4: ຄວາມບໍ່ສອດຄ່ອງກັນທາງດ້ານພາສາລະຫວ່າງ Embedding Model ແລະ LLM
• ຮູບແບບ 5: ການກຽມຂໍ້ມູນເບື້ອງຕົ້ນ (Pre-processing) ບໍ່ພຽງພໍສຳລັບເອກະສານທີ່ບໍ່ມີໂຄງສ້າງ ເຊັ່ນ: PDF
• ຮູບແບບ 6: ການໃສ່ Context ເຂົ້າໄປໃນ Prompt ຫຼາຍເກີນໄປ
• ຮູບແບບ 7: ການສົ່ງຂໍ້ມູນຕໍ່ໃຫ້ໂດຍກົງດ້ວຍ k ລຳດັບທຳອິດ ໂດຍບໍ່ມີການຈັດລຳດັບໃໝ່ (Re-ranking)

ໄລຍະການດຳເນີນງານ (ຮູບແບບ 8-10)

• ຮູບແບບ 8: ການຂາດການຈັດການເວລາໃນການສ້າງ Index ຄືນໃໝ່
• ຮູບແບບ 9: ການນຳໃຊ້ເຂົ້າສູ່ລະບົບຈິງໂດຍບໍ່ມີການກຳນົດຕົວຊີ້ວັດການປະເມີນຜົນ
• ຮູບແບບ 10: ຄວາມຖືກຕ້ອງໃນການຄົ້ນຫາຫຼຸດລົງເນື່ອງຈາກມີເອກະສານຫຼາຍພາສາປົນກັນ

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

ຮູບແບບທີ 1: ການອອກແບບຂະໜາດ Chunk ບໍ່ເໝາະສົມ

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

• ໃນກໍລະນີການນຳໃຊ້ທົ່ວໄປ, ມັກຈະເລີ່ມຕົ້ນພິຈາລະນາທີ່ປະມານ 256-512 ໂທເຄັນ (Tokens).
• ໃນກໍລະນີທີ່ເອກະສານມີໂຄງສ້າງຊັບຊ້ອນ ເຊັ່ນ: ເອກະສານກົດໝາຍ ຫຼື ມາດຕະຖານ ຫຼື Specification ທາງເຕັກນິກ, ມີລາຍງານວ່າການແບ່ງ Chunk ແບບປ່ຽນແປງຄວາມຍາວໄດ້ຕາມໜ່ວຍຂອງພາກສ່ວນ (Section) ແມ່ນມີປະສິດທິຜົນ.
• LlamaIndex ແລະ LangChain ມີຟັງຊັນ Semantic Chunking ມາໃຫ້ເປັນມາດຕະຖານ ເຊິ່ງສາມາດເລືອກໃຊ້ການແບ່ງໂດຍພິຈາລະນາຈາກຄວາມໝາຍຂອງປະໂຫຍກໄດ້.

ຮູບແບບທີ 2: ບໍ່ໄດ້ຄາດການເຖິງຄວາມຫຼາກຫຼາຍຂອງ Query ຈາກຜູ້ໃຊ້

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

• ໃນກໍລະນີທີ່ມີທັງຜູ້ໃຊ້ພາຍໃນທີ່ສອບຖາມດ້ວຍຄຳສັບສະເພາະທາງ ແລະ ຜູ້ໃຊ້ທົ່ວໄປທີ່ຖາມດ້ວຍພາສາທີ່ເຂົ້າໃຈງ່າຍ, ຮູບແບບ Embedding ດຽວອາດຈະບໍ່ສາມາດຮອງຮັບໄດ້ທັງໝົດ.
• ຄວນພິຈາລະນາວິທີການປະມວນຜົນເບື້ອງຕົ້ນ ເຊັ່ນ: Query Expansion ຫຼື HyDE (Hypothetical Document Embeddings) ໄວ້ຕັ້ງແຕ່ໄລຍະການອອກແບບ.

ຮູບແບບທີ 3: ການລະເລີຍການປະເມີນຄຸນນະພາບຂອງແຫຼ່ງຂໍ້ມູນ

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

• ເອກະສານທີ່ຊ້ຳກັນ, ຂໍ້ມູນທີ່ລ້າສະໄໝ ແລະ ຮູບແບບທີ່ບໍ່ເປັນເອກະພາບກັນ ມັກຈະເປັນສາເຫດຫຼັກທີ່ເຮັດໃຫ້ Index ປົນເປື້ອນ.
• ຖ້າບໍ່ມີການກຳນົດຂະບວນການ ຫຼື Pipeline ໃນການທຳຄວາມສະອາດຂໍ້ມູນໃນໄລຍະການອອກແບບ, ບັນຫາດ້ານຄຸນນະພາບກໍຈະປາກົດໃຫ້ເຫັນໄດ້ງ່າຍໃນໄລຍະການດຳເນີນງານ.
• ໃນກໍລະນີທີ່ມີການປະສົມປະສານຫຼາຍແຫຼ່ງຂໍ້ມູນ ເຊັ່ນ: PDF ຫຼື Wiki ພາຍໃນອົງກອນ, ການກຳນົດການອອກແບບ Metadata (ວັນທີສ້າງ, ປະເພດແຫຼ່ງຂໍ້ມູນ, ຄະແນນຄວາມໜ້າເຊື່ອຖື, ແລະ ອື່ນໆ) ພ້ອມກັນນັ້ນຖືເປັນສິ່ງສຳຄັນ.

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

ຮູບແບບທີ 4: ຄວາມບໍ່ສອດຄ່ອງກັນທາງພາສາລະຫວ່າງ Embedding Model ແລະ LLM

ການນຳເອົາເອກະສານພາສາຍີ່ປຸ່ນມາເຮັດ Vectorization ດ້ວຍ Embedding Model ທີ່ເນັ້ນສະເພາະພາສາອັງກິດ ມັກຈະເຮັດໃຫ້ພື້ນທີ່ຄວາມໝາຍຂອງຄຳສັບຄາດເຄື່ອນ ແລະ ຄະແນນຄວາມຄ້າຍຄືກັນ (Similarity score) ບໍ່ສາມາດເຊື່ອຖືໄດ້. ເນື່ອງຈາກທາງເລືອກຂອງ Model ທີ່ຮອງຮັບຫຼາຍພາສາມີເພີ່ມຂຶ້ນ ເຊັ່ນ: multilingual-e5-large ຫຼື ກຸ່ມ text-embedding-3, ສະນັ້ນການກວດສອບຄວາມສອດຄ່ອງຂອງພາສາລະຫວ່າງ LLM ທີ່ໃຊ້ ແລະ Embedding Model ລ່ວງໜ້າ ຈຶ່ງເປັນສິ່ງທີ່ສຳຄັນ.

ຮູບແບບທີ 5: ການຕັ້ງຄ່າ Overlap ຂອງ Chunk ຜິດພາດ

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

ຮູບແບບທີ 6: ການຄົ້ນຫາແບບ Flat ໂດຍບໍ່ນຳໃຊ້ Metadata

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

ຮູບແບບທີ 7: ການສົ່ງຂໍ້ມູນ k ອັນດັບທຳອິດໄປໃຫ້ໂດຍບໍ່ມີການ Re-ranking

ຜົນການຄົ້ນຫາອັນດັບຕົ້ນໆຈາກ Vector Search ເຖິງວ່າຈະ "ໃກ້ຄຽງໃນດ້ານຄວາມໝາຍ", ແຕ່ກໍບໍ່ໄດ້ໝາຍຄວາມວ່າຈະ "ມີປະໂຫຍດທີ່ສຸດຕໍ່ການຕອບຄຳຖາມ" ສະເໝີໄປ. ມີລາຍງານວ່າການເພີ່ມ Model ສຳລັບ Re-ranking ທີ່ອີງໃສ່ Cross-Encoder ເຂົ້າໄປໃນຂະບວນການ (Pipeline) ຈະຊ່ວຍປັບປຸງຄຸນນະພາບຂອງບໍລິບົດທີ່ຈະສົ່ງຂໍ້ມູນຕໍ່ໃຫ້ LLM ໄດ້ດີຂຶ້ນ.

ກະລຸນາກວດສອບລາຍການຕໍ່ໄປນີ້ເປັນ Checklist ໃນການຈັດຕັ້ງປະຕິບັດ:

• ໄດ້ກວດສອບຄວາມສອດຄ່ອງຂອງພາສາລະຫວ່າງ Embedding Model ກັບພາສາຂອງເອກະສານແລ້ວຫຼືບໍ່?
• ໄດ້ປະເມີນອັດຕາສ່ວນ Overlap ໃນຫຼາຍຮູບແບບແລ້ວຫຼືບໍ່?
• ການອອກແບບການກັ່ນຕອງ Metadata ໄດ້ສຳເລັດແລ້ວຫຼືບໍ່?
• ໄດ້ຕັດສິນໃຈແລ້ວຫຼືບໍ່ວ່າຈະມີຂັ້ນຕອນ Re-ranking ຫຼືບໍ່?

ຖ້າຫາກເບິ່ງຂ້າມສິ່ງເຫຼົ່ານີ້ແລ້ວນຳໄປໃຊ້ງານຈິງ, ຄ່າໃຊ້ຈ່າຍໃນການແກ້ໄຂໃນໄລຍະການດຳເນີນງານມີແນວໂນ້ມທີ່ຈະເພີ່ມທະວີຂຶ້ນເລື້ອຍໆ.

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

ຮູບແບບທີ 8: ລະເລີຍການສ້າງດັດສະນີ (Index) ຄືນໃໝ່ເມື່ອມີການອັບເດດເອກະສານ

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

ຮູບແບບທີ 9: ບໍ່ມີກົນໄກໃນການປະເມີນຜົນ ແລະ ຕິດຕາມກວດກາ

• ຫຼາຍກໍລະນີດຳເນີນງານໂດຍບໍ່ມີການກຳນົດຕົວຊີ້ວັດປະລິມານ ເຊັ່ນ: Faithfulness ຫຼື Answer Relevancy.
• ເນື່ອງຈາກບໍ່ມີ Feedback Loop, ເຮັດໃຫ້ການຮັບຮູ້ເຖິງຄວາມຊຸດໂຊມຂອງຄວາມຖືກຕ້ອງຊັກຊ້າ.
• ການນຳເອົາ Framework ການປະເມີນຜົນ ເຊັ່ນ: RAGAS ຫຼື TruLens ມາລວມ ຫຼື Merge ເຂົ້າໃນລະບົບກ່ອນການເປີດຕົວ ຫຼື Launch ໄດ້ກາຍເປັນມາດຕະຖານການປະຕິບັດງານທົ່ວໄປ.

ການວັດແທກຄະແນນ RAGAS ດ້ວຍ Batch ແບບປົກກະຕິ ແລະ ການສ້າງກົນໄກແຈ້ງເຕືອນເມື່ອຄະແນນຫຼຸດລົງຕໍ່າກວ່າເກນທີ່ກຳນົດໄວ້ ແມ່ນມີປະສິດທິຜົນ.

ຮູບແບບທີ 10: ບໍ່ໄດ້ພິຈາລະນາເຖິງການປ່ຽນແປງຂອງພຶດຕິກຳເນື່ອງຈາກການອັບເດດ Model Version ຂອງ LLM

ເມື່ອຜູ້ໃຫ້ບໍລິການ API ອັບເດດ Model, ແນວໂນ້ມຂອງຜົນລັອກອາດຈະປ່ຽນແປງເຖິງແມ່ນວ່າຈະໃຊ້ Prompt ເດີມກໍຕາມ. ຖ້າຫາກ Prompt Template ຫຼື Logic ການປະມວນຜົນຫຼັງຈາກນັ້ນ (Post-processing) ຂຶ້ນກັບເວີຊັນເກົ່າ, ມັນອາດຈະນຳໄປສູ່ຄຸນນະພາບທີ່ຫຼຸດລົງຢ່າງກະທັນຫັນ.

• ຄວນກຳນົດ Model Version ໃຫ້ຊັດເຈນ ແລະ ດຳເນີນການທົດສອບ Regression ເມື່ອມີການອັບເດດ.
• ຈັດການ Prompt ດ້ວຍ Git ເຊັ່ນດຽວກັບ Code.
• ແຍກສະພາບແວດລ້ອມການດຳເນີນງານຈິງ (Production) ແລະ ສະພາບແວດລ້ອມການທົດສອບ (Staging) ອອກຈາກກັນ ແລະ ດຳເນີນການ Rollout ແບບເປັນຂັ້ນຕອນ.

ການລວມເອົາການວັດແທກ ແລະ ການຈັດການການອັບເດດຢ່າງຕໍ່ເນື່ອງເຂົ້າໄປຕັ້ງແຕ່ຂັ້ນຕອນການອອກແບບ ຄືກຸນແຈສຳຄັນໃນການຮັກສາຄຸນນະພາບໃນໄລຍະຍາວ.

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

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

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

ເປັນຫຍັງ Chunk ທີ່ໃຫຍ່ເກີນໄປຈຶ່ງກາຍເປັນບັນຫາ?

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

ອາການທີ່ມັກພົບເຫັນ

• ວັກຕອນທີ່ບໍ່ກ່ຽວຂ້ອງກັບເຈດຕະນາຂອງ Query ມັກຈະປົນເຂົ້າມາໄດ້ງ່າຍ
• ຂໍ້ມູນທີ່ "ກ່ຽວຂ້ອງ" ແລະ "ບໍ່ກ່ຽວຂ້ອງ" ປົນເປກັນຢູ່ໃນ Context ທີ່ສົ່ງໃຫ້ LLM, ເຮັດໃຫ້ຄວາມແມ່ນຍຳໃນການຕອບຫຼຸດລົງ
• ເຖິງຈະດຶງຂໍ້ມູນມາໄດ້ k ລາຍການອັນດັບຕົ້ນໆ ແຕ່ຄວາມໜາແໜ້ນຂອງຂໍ້ມູນຕົວຈິງກັບຕໍ່າ

ວິທີການທີ່ແນະນຳ: ການຄົ້ນຫາແບບ Small-to-Big (ຍຸດທະສາດ Parent-Child Chunk)

ໃນປັດຈຸບັນ, ວິທີທີ່ເປັນທີ່ນິຍົມຄືການໃຊ້ Chunk ຂະໜາດນ້ອຍ (ປະມານ 128-256 Token) ໃນຂະນະຄົ້ນຫາເພື່ອໃຫ້ໄດ້ການ Match ທີ່ມີຄວາມແມ່ນຍຳສູງ, ແລະເມື່ອສົ່ງຂໍ້ມູນເຂົ້າ LLM ຈຶ່ງສົ່ງ Parent Chunk (512-1,024 Token) ໄປໃຫ້. ວິທີນີ້ຊ່ວຍປ້ອງກັນການຂາດຫາຍຂອງບໍລິບົດ (Context) ໃນຂະນະທີ່ຍັງຮັກສາຄວາມແມ່ນຍຳໃນການຄົ້ນຫາໄວ້ໄດ້. ໃນ LlamaIndex ແລະ LangChain, ຟັງຊັນສຳລັບການນຳໃຊ້ຍຸດທະສາດນີ້ມີໃຫ້ບໍລິການເປັນມາດຕະຖານ.

ຄຳແນະນຳໃນການນຳໃຊ້ (ຄ່າອ້າງອີງ)

• Chunk ສຳລັບການຄົ້ນຫາ: 128-256 Token (ເນັ້ນຄວາມແມ່ນຍຳ)
• Chunk ສຳລັບການປ້ອນຂໍ້ມູນເຂົ້າ LLM: 512-1,024 Token (ຮັກສາບໍລິບົດ)
• ການຊ້ອນທັບກັນຂອງ Chunk (Overlap): ປະມານ 20-50 Token (ປ້ອງກັນການຂາດຕອນຂອງບໍລິບົດ)

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

ສະພາວະທີ່ໂມເດວ Embedding ແລະ LLM ໃຊ້ພາສາທີ່ບໍ່ສອດຄ່ອງກັນນັ້ນ ຈະຄ່ອຍໆກັດກິນຄວາມແມ່ນຍຳຂອງ RAG ທັງລະບົບຢ່າງງຽບໆ. ເມື່ອຮູ້ສຶກວ່າ "ຜົນການຄົ້ນຫາສະແດງອອກມາ ແຕ່ຄຳຕອບກັບບໍ່ກົງປະເດັນ" — ນັ້ນຄືໜຶ່ງໃນສາເຫດທີ່ຄວນສົງໄສວ່າເກີດຈາກຄວາມບໍ່ສອດຄ່ອງ (Mismatch) ນີ້.

ໂຄງສ້າງຂອງບັນຫາ

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

ຮູບແບບຂອງຄວາມບໍ່ສອດຄ່ອງທີ່ພົບເຫັນໄດ້ທົ່ວໄປມີດັ່ງນີ້:

• ໂມເດວ Embedding ທີ່ເນັ້ນພາສາອັງກິດ × ເອກະສານພາສາຍີ່ປຸ່ນ: ໂມເດວທີ່ຮຽນຮູ້ຈາກ Corpus ພາສາອັງກິດເປັນຫຼັກ ມັກຈະເຮັດໃຫ້ການສະແດງຄວາມໝາຍຂອງເອກະສານພາສາຍີ່ປຸ່ນບໍ່ລະອຽດເທົ່າທີ່ຄວນ
• ໂມເດວ Embedding ຫຼາຍພາສາ × LLM ພາສາອັງກິດໂດຍສະເພາະ: ເຖິງແມ່ນວ່າ Embedding ຈະຮອງຮັບຫຼາຍພາສາ ແຕ່ຖ້າ LLM ບໍ່ສາມາດປະມວນຜົນບໍລິບົດພາສາຍີ່ປຸ່ນໄດ້ຢ່າງຖືກຕ້ອງ ຄຸນນະພາບຂອງຄຳຕອບກໍຈະຫຼຸດລົງ
• ຄວາມບໍ່ສອດຄ່ອງຂອງຄຳສັບສະເພາະດ້ານ (Domain-specific vocabulary): ໃນຂົງເຂດທີ່ມີຄຳສັບສະເພາະທາງດ້ານກົດໝາຍ, ການແພດ, ຫຼື ການເງິນ, ມີລາຍງານວ່າໂມເດວ Embedding ແບບທົ່ວໄປບໍ່ສາມາດປ່ຽນຄວາມໝາຍຂອງຄຳສັບໃຫ້ເປັນ Vector ໄດ້ຢ່າງຖືກຕ້ອງ

ວິທີການຫຼີກລ່ຽງ

1. ເລືອກໃຊ້ໂມເດວ Embedding ແລະ LLM ຈາກຜູ້ໃຫ້ບໍລິການດຽວກັນ ເພື່ອຫຼຸດຜ່ອນຄວາມແຕກຕ່າງຂອງພື້ນທີ່ພາສາໃຫ້ໜ້ອຍທີ່ສຸດ
2. ເພີ່ມໂມເດວທີ່ຮອງຮັບຫຼາຍພາສາ (Multilingual models) ເຂົ້າໃນຕົວເລືອກເພື່ອທົດສອບປຽບທຽບ (ແນະນຳໃຫ້ທົດສອບດ້ວຍສະພາບແວດລ້ອມຈິງຂອງບໍລິສັດ ໂດຍອ້າງອີງຈາກຄະແນນທາງການພຽງບາງສ່ວນ)
3. ໃຊ້ Framework ການປະເມີນຜົນເຊັ່ນ RAGAS ເພື່ອວັດແທກຄະແນນ "Context Relevance" ໂດຍແຍກການປະເມີນຄວາມແມ່ນຍຳໃນການຄົ້ນຫາ ແລະ ຄວາມແມ່ນຍຳໃນການຕີຄວາມໝາຍຂອງ LLM ອອກຈາກກັນ

ການເລືອກໂມເດວມີຕົ້ນທຶນໃນການປ່ຽນແປງທີ່ສູງຫາກຕັດສິນໃຈໄປແລ້ວ. ການສ້າງນິໄສໃນການເຮັດ A/B Testing ຫຼາຍໂມເດວຕັ້ງແຕ່ໄລຍະເລີ່ມຕົ້ນ ຄືກຸນແຈສຳຄັນໃນການປ້ອງກັນການແກ້ໄຂງານຄືນໃໝ່ໃນຂັ້ນຕອນຕໍ່ໄປ.

ທ່ານກຳລັງສົ່ງຂໍ້ມູນ chunk ຈຳນວນ k ລຳດັບທຳອິດທີ່ໄດ້ຈາກການຄົ້ນຫາແບບ Vector ໄປໃຫ້ LLM ໂດຍກົງຢູ່ຫຼືບໍ່? ເຖິງວ່າຈະເປັນການຈັດຕັ້ງປະຕິບັດທີ່ງ່າຍ ແຕ່ກໍເປັນຈຸດຜິດພາດສຳຄັນທີ່ເຮັດໃຫ້ຄຸນນະພາບຂອງຄຳຕອບຫຼຸດລົງຢ່າງຫຼວງຫຼາຍ.

ການຄົ້ນຫາແບບ Vector ຈະວັດແທກຄວາມໃກ້ຄຽງທາງດ້ານຄວາມໝາຍໂດຍໃຊ້ Cosine Similarity ແລະອື່ນໆ ແຕ່ ຄວາມກ່ຽວຂ້ອງກັບ Query ແລະປະລິມານຂໍ້ມູນທີ່ຈຳເປັນຕໍ່ການຕອບຄຳຖາມນັ້ນ ບໍ່ຈຳເປັນຕ້ອງກົງກັນສະເໝີໄປ. ເຖິງແມ່ນວ່າຄະແນນຄວາມຄ້າຍຄືກັນຈະສູງ ແຕ່ກໍມີແນວໂນ້ມທີ່ chunk ເຊິ່ງສາມາດຕອບຄຳຖາມໄດ້ຢ່າງຖືກຕ້ອງນັ້ນ ອາດຈະບໍ່ໄດ້ຢູ່ໃນລຳດັບຕົ້ນໆ.

ເປັນຫຍັງການສົ່ງ chunk ຈຳນວນ k ລຳດັບທຳອິດໄປໂດຍກົງຈຶ່ງກາຍເປັນບັນຫາ

• ມີໂອກາດສູງທີ່ຈະມີ chunk ທີ່ "ກ່ຽວຂ້ອງແຕ່ບໍ່ແມ່ນຄຳຕອບ" ປົນເຂົ້າມາ
• ເຮັດໃຫ້ເສຍພື້ນທີ່ Context Window ໂດຍບໍ່ຈຳເປັນ ແລະ ເຮັດໃຫ້ຂໍ້ມູນທີ່ສຳຄັນແທ້ໆເຈືອຈາງລົງ
• ຍິ່ງມີ Noise ຫຼາຍເທົ່າໃດ LLM ກໍຍິ່ງມີໂອກາດເກັບຂໍ້ມູນທີ່ຜິດພາດໄປໃຊ້ ເຊິ່ງຈະເພີ່ມຄວາມສ່ຽງຕໍ່ການເກີດ Hallucination

ວິທີແກ້ໄຂ: ການນຳໃຊ້ການຈັດລຳດັບໃໝ່ (Re-ranking)

ການແຊກຂັ້ນຕອນການຈັດລຳດັບໃໝ່ໂດຍໃຊ້ແບບຈຳລອງ Cross-Encoder ໄວ້ລະຫວ່າງໄລຍະການດຶງຂໍ້ມູນ (Retrieval) ແລະ ໄລຍະການສ້າງຄຳຕອບ (Generation) ແມ່ນມີປະສິດທິຜົນ. ເນື່ອງຈາກ Cross-Encoder ຈະປ້ອນ Query ແລະ chunk ເຂົ້າໄປພ້ອມກັນເພື່ອປະເມີນຄວາມກ່ຽວຂ້ອງຢ່າງລະອຽດ ຈຶ່ງຄາດຫວັງໄດ້ວ່າຈະມີຄວາມແມ່ນຍຳໃນການຈັດລຳດັບສູງກວ່າການຄົ້ນຫາແບບ Vector ດ້ວຍວິທີ Bi-Encoder.

ໃນປັດຈຸບັນມີການນຳໃຊ້ Rerank endpoint ຂອງ Cohere, ຊຸດ BAAI/bge-reranker ແລະ ແບບຈຳລອງ Local ທີ່ມີນ້ຳໜັກເບົາເຊັ່ນ FlashRank ຢ່າງແຜ່ຫຼາຍ. ການນຳເອົາສິ່ງເຫຼົ່ານີ້ມາປະສົມປະສານກັນ ຈະຊ່ວຍໃຫ້ທ່ານສາມາດຄັດກອງ chunk ທີ່ຈະສົ່ງໃຫ້ LLM ໄດ້ຢ່າງມີປະສິດທິພາບ ແລະ ເພີ່ມຄຸນນະພາບຂອງ Context ໃຫ້ສູງຂຶ້ນ.

ຈຸດສຳຄັນໃນການຈັດຕັ້ງປະຕິບັດ

• ໃນການຄົ້ນຫາຄັ້ງທຳອິດ ໃຫ້ດຶງຂໍ້ມູນມາໃນວົງກວ້າງ (top-20 ຫາ 50 ລາຍການ) ແລ້ວຈຶ່ງຄັດໃຫ້ເຫຼືອ top-3 ຫາ 5 ລາຍການ ຫຼັງຈາກຜ່ານການຈັດລຳດັບໃໝ່ແລ້ວ
• ຕ້ອງກວດສອບກັບເອກະສານທາງການສະເໝີວ່າແບບຈຳລອງການຈັດລຳດັບໃໝ່ນັ້ນຮອງຮັບພາສາຢີ່ປຸ່ນຫຼືບໍ່
• ວັດແທກຜົນກະທົບຕໍ່ Latency ແລະ ໃຊ້ການປະມວນຜົນແບບບໍ່ລໍຖ້າ (Asynchronous) ຫຼື Cache ເຂົ້າມາຊ່ວຍເສີມ

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

ເປັນຫຍັງຈຶ່ງກາຍເປັນບັນຫາ

ສິ່ງທີ່ຖືກຈັດເກັບໄວ້ໃນ Vector Store ເປັນພຽງ Snapshot ໃນເວລາທີ່ສ້າງ Index ເທົ່ານັ້ນ. ໃນກໍລະນີທີ່ຕ້ອງຈັດການກັບເອກະສານທີ່ມີການອັບເດດເລື້ອຍໆ ເຊັ່ນ: ກົດລະບຽບພາຍໃນ, ມາດຕະຖານ ຫຼື Specification ຂອງຜະລິດຕະພັນ, ຫຼືເອກະສານ API, ຖ້າ Index ຍັງເປັນຂໍ້ມູນເກົ່າ ຈະເຮັດໃຫ້ເກີດບັນຫາດັ່ງນີ້:

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

ການຂາດການອອກແບບ "ການອັບເດດສ່ວນຕ່າງ (Differential Update)" ທີ່ມັກຖືກມອງຂ້າມ

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

ໃນ Document Loader ຂອງ LlamaIndex ແລະ LangChain ໄດ້ມີການພັດທະນາຟັງຊັນກວດສອບສ່ວນຕ່າງໃຫ້ມີຄວາມພ້ອມຫຼາຍຂຶ້ນ. ຂໍແນະນຳໃຫ້ອອກແບບໂດຍການຈັດການຄ່າ Hash ຫຼື Timestamp ຂອງເອກະສານ ແລະ ເຮັດການ Embedding ສະເພາະ Chunk ທີ່ມີການປ່ຽນແປງເທົ່ານັ້ນ (ກະລຸນາກວດສອບມາດຕະຖານ ຫຼື Specification ລ່າສຸດໃນເອກະສານທາງການຂອງແຕ່ລະ Framework).

ຈຸດສຳຄັນຂອງວິທີການຫຼີກລ່ຽງບັນຫາ

• ເພີ່ມ Metadata (ວັນທີອັບເດດຫຼ້າສຸດ, ເລກເວີຊັນ) ໃສ່ໃນ Vector Store ສຳລັບເອກະສານແຕ່ລະສະບັບ
• ຝັງວຽກງານການອັບເດດ Index ໄວ້ໃນ CI/CD ຂະບວນການ ຫຼື Pipeline ແລະ ຕັ້ງຄ່າໃຫ້ເຮັດວຽກອັດຕະໂນມັດເມື່ອມີການປ່ຽນແປງເອກະສານ
• ກຳນົດໃຫ້ມີການກວດສອບຄວາມສອດຄ່ອງຂອງ Index ເປັນໄລຍະ ເພື່ອກວດສອບວ່າເອກະສານທີ່ອ້າງອີງນັ້ນຍັງມີຢູ່ຫຼືບໍ່
• ຈັດການ "Flag ການລຶບແບບ Logical" ຜ່ານ Metadata ເພື່ອຮອງຮັບເອກະສານທີ່ຖືກລຶບອອກໄປແລ້ວ

ຄວາມສົດໃໝ່ຂອງ Index ມີຜົນໂດຍກົງຕໍ່ຄຸນນະພາບຄຳຕອບຂອງ RAG. ເມື່ອເຂົ້າສູ່ໄລຍະການດຳເນີນງານແລ້ວ, ຄວນໃຫ້ຄວາມສຳຄັນກັບການເຮັດໃຫ້ຂະບວນການອັບເດດເປັນອັດຕະໂນມັດ ແລະ ການສ້າງລະບົບຕິດຕາມກວດກາ.

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

ການນຳເອົາ PDF ມາປ່ຽນເປັນເວັກເຕີ (Vectorization) ໂດຍກົງ ເປັນໜຶ່ງໃນຕົວຢ່າງທີ່ບໍ່ຄວນເຮັດ (NG) ທີ່ພົບເຫັນເລື້ອຍໃນການສ້າງ RAG. ເຖິງວ່າຈະເບິ່ງຄືວ່າງ່າຍ ແຕ່ຕ້ອງລະວັງ ເພາະມັນເປັນສາເຫດທີ່ເຮັດໃຫ້ຄວາມຖືກຕ້ອງໃນການຄົ້ນຫາຫຼຸດລົງຢ່າງຫຼວງຫຼາຍ.

ເປັນຫຍັງຈຶ່ງບໍ່ຄວນເຮັດ: ບັນຫາດ້ານໂຄງສ້າງທີ່ PDF ມີ

PDF ເປັນຮູບແບບທີ່ໃຫ້ຄວາມສຳຄັນກັບຮູບແບບການພິມ (Layout) ເຮັດໃຫ້ມີສິ່ງລົບກວນ (Noise) ປົນເຂົ້າມາໃນຂັ້ນຕອນການສະກັດຂໍ້ຄວາມ. ບັນຫາຫຼັກໆມີດັ່ງນີ້:

• ການປົນເປື້ອນຂອງ Header ແລະ Footer: ເລກໜ້າ ຫຼື ຊື່ບໍລິສັດຈະຖືກລວມເຂົ້າກັບເນື້ອຫາຫຼັກ ເຮັດໃຫ້ເກີດ Chunk ທີ່ບໍ່ມີຄວາມໝາຍ
• ການອ່ານຮູບແບບການຈັດວາງຜິດພາດ: ໃນ PDF ທີ່ມີການຈັດວາງແບບ 2 ຄໍລຳ, ບາງຄັ້ງຂໍ້ຄວາມອາດຈະຖືກສະກັດອອກມາໂດຍການປະປົນກັນລະຫວ່າງຄໍລຳຊ້າຍ ແລະ ຂວາ
• ຄວາມລົ້ມເຫຼວໃນການປ່ຽນຕາຕະລາງ ແລະ ຮູບພາບເປັນຂໍ້ຄວາມ: ຂໍ້ມູນພາຍໃນເຊລອາດຈະຖືກລວມເຂົ້າກັນ ຫຼື ຕົກຫຼ່ນ ເຮັດໃຫ້ບໍ່ສາມາດດຶງຂໍ້ມູນຕົວເລກທີ່ຖືກຕ້ອງໄດ້
• ຕົວອັກສອນຜິດພ້ຽນ ຫຼື ມີສັນຍາລັກປົນ: ເນື່ອງຈາກບັນຫາການຝັງຟອນ (Font embedding), ຕົວອັກສອນພິເສດ ຫຼື ພາສາອື່ນໆອາດຈະສະແດງຜົນຜິດພາດ

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

ວິທີແກ້ໄຂ: ການສ້າງຂະບວນການ ຫຼື Pipeline ໃນການກຽມຂໍ້ມູນ

ການນຳໃຊ້ Library ຕ່າງໆ ເຊັ່ນ PyMuPDF, pdfplumber ແລະ Unstructured ເພື່ອເຮັດການກຽມຂໍ້ມູນ (Pre-processing) ແມ່ນໄດ້ຮັບຄວາມນິຍົມຢ່າງກວ້າງຂວາງ. ຂັ້ນຕອນພື້ນຖານມີດັ່ງນີ້:

1. ຕັດ Header ແລະ Footer ອອກໂດຍໃຊ້ Regular Expression ຫຼື ການວິເຄາະ Layout
2. ປ່ຽນຕາຕະລາງໃຫ້ເປັນຮູບແບບ Markdown ຫຼື CSV ກ່ອນທີ່ຈະແບ່ງເປັນ Chunk
3. ກວດສອບຕົວຢ່າງຂໍ້ຄວາມທີ່ສະກັດອອກມາດ້ວຍຕາ ເພື່ອເບິ່ງວ່າມີສິ່ງລົບກວນຫຼືບໍ່
4. ສຳລັບ PDF ທີ່ເປັນຮູບພາບ (Scan PDF), ໃຫ້ພິຈາລະນາໃຊ້ Tesseract ຫຼື Azure Document Intelligence

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

ການນຳເອົາ Chunk ທີ່ຄົ້ນຫາພົບມາໃສ່ໃນຊ່ອງ Context ຂອງ Prompt ຈຳນວນຫຼວງຫຼາຍ ໂດຍຄິດວ່າ "ສົ່ງໄປໃຫ້ໝົດທຸກຢ່າງແມ່ນປອດໄພ" ນັ້ນ ເປັນໜຶ່ງໃນຕົວຢ່າງທີ່ບໍ່ຄວນເຮັດ (NG) ເຊິ່ງພົບເຫັນໄດ້ເລື້ອຍໆໃນການເຮັດວຽກຕົວຈິງ.

ເຖິງແມ່ນວ່າຈະເບິ່ງຄືວ່າຂໍ້ມູນຍິ່ງຫຼາຍ ຄວາມຖືກຕ້ອງຂອງຄຳຕອບກໍຍິ່ງເພີ່ມຂຶ້ນ ແຕ່ໃນຄວາມເປັນຈິງແລ້ວ ມັກຈະສົ່ງຜົນກົງກັນຂ້າມ. ມີການລາຍງານກໍລະນີທີ່ວ່າ ເມື່ອ Context ຍາວຂຶ້ນ LLM ຈະຕັດສິນໃຈໄດ້ຍາກຂຶ້ນວ່າ "ຂໍ້ມູນໃດສຳຄັນ" ເຮັດໃຫ້ຄຸນນະພາບຂອງຄຳຕອບຫຼຸດລົງ. ປະກົດການນີ້ເປັນທີ່ຮູ້ຈັກກັນໃນຊື່ບັນຫາ "Lost in the Middle" ເຊິ່ງການຄົ້ນຄວ້າໄດ້ສະແດງໃຫ້ເຫັນວ່າ ຂໍ້ມູນທີ່ຖືກວາງໄວ້ບໍລິເວນກາງຂອງ Prompt ຈະຖືກ Model ອ້າງອີງເຖິງໄດ້ຍາກຂຶ້ນ.

ຂັ້ນຕອນຄວາມຜິດພາດທີ່ພົບເລື້ອຍ

• ນຳເອົາ Chunk ອັນດັບຕົ້ນໆ 20 ລາຍການ ມາເຊື່ອມຕໍ່ໃສ່ System Prompt ໂດຍກົງ
• ຈຳນວນ Token ລວມເກີນ 10,000 - 20,000
• Model ມອງຂ້າມຂໍ້ມູນໃນຊ່ວງກາງ ແລະ ຊ່ວງທ້າຍ ແລ້ວສ້າງຄຳຕອບໂດຍອີງໃສ່ເນື້ອຫາບໍລິເວນຕອນຕົ້ນເທົ່ານັ້ນ
• ສົ່ງຜົນໃຫ້ເກີດ "ຄຳຕອບທີ່ບໍ່ກົງປະເດັນ" ຫຼື "ຄຳຕອບທີ່ບໍ່ຄົບຖ້ວນ" ເລື້ອຍໆ

ປັດໄຈທີ່ເຮັດໃຫ້ບັນຫາຮ້າຍແຮງຂຶ້ນ

• ມີເນື້ອຫາທີ່ຊ້ຳຊ້ອນກັນລະຫວ່າງ Chunk ເຮັດໃຫ້ Model ສັບສົນໄດ້ງ່າຍ
• Chunk ທີ່ມີຄວາມກ່ຽວຂ້ອງຕ່ຳປົນເຂົ້າມາໃນອັນດັບຕົ້ນໆ ເຮັດໜ້າທີ່ເປັນສິ່ງລົບກວນ (Noise)
• Context ຍິ່ງຍາວ ຕົ້ນທຶນການປະມວນຜົນ (Inference cost) ແລະ ຄວາມໜ່ວງຂອງການຕອບສະໜອງ (Latency) ຂອງ API ກໍຍິ່ງເພີ່ມທະວີຂຶ້ນເລື້ອຍໆ

ຈຸດສຳຄັນໃນການແກ້ໄຂ

• ໃຊ້ການຈັດອັນດັບໃໝ່ (Re-ranking) (ເຊັ່ນ: Cross-Encoder) ເຂົ້າມາຊ່ວຍ ເພື່ອຄັດເລືອກອັນດັບ k ໃຫ້ເຫຼືອພຽງ 3-5 ລາຍການ
• ກຳນົດຄ່າ Threshold ສຳລັບຄະແນນຄວາມກ່ຽວຂ້ອງຂອງ Chunk ແລະ ຕັດລາຍການທີ່ຕ່ຳກວ່ານັ້ນອອກ
• ກຳນົດຂີດຈຳກັດຈຳນວນ Token ລວມຂອງ Context ທີ່ຈະສົ່ງໄປ ແລະ ຈັດຕັ້ງ Logic ເພື່ອຕັດສ່ວນທີ່ເກີນອອກ

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

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

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

ຄວາມສ່ຽງຫຼັກທີ່ເກີດຈາກການເປີດຕົວໂດຍບໍ່ມີການປະເມີນຜົນ

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

RAGAS ເປັນກອບການເຮັດວຽກ (Framework) ທີ່ຖືກອ້າງອີງຢ່າງກວ້າງຂວາງສຳລັບການປະເມີນຜົນ RAG ເຊິ່ງສາມາດວັດແທກຄຸນນະພາບຂອງລະບົບໄດ້ຢ່າງຮອບດ້ານໂດຍໃຊ້ຕົວຊີ້ວັດຫຼັກໆ ດັ່ງນີ້:

• Faithfulness (ຄວາມຊື່ສັດ): ຄຳຕອບທີ່ສ້າງຂຶ້ນນັ້ນອີງໃສ່ Context ທີ່ຄົ້ນຫາພົບຫຼືບໍ່
• Answer Relevancy (ຄວາມກ່ຽວຂ້ອງຂອງຄຳຕອບ): ຄຳຕອບມີຄວາມເໝາະສົມກັບຄຳຖາມຫຼືບໍ່
• Context Precision / Recall: Chunk ທີ່ຄົ້ນຫາພົບມີຄວາມຖືກຕ້ອງ ແລະ ຄົບຖ້ວນສົມບູນຫຼືບໍ່

ຂັ້ນຕອນການປະເມີນຜົນຂັ້ນຕອນຕໍ່າສຸດທີ່ຄວນປະຕິບັດກ່ອນການເປີດຕົວ ຫຼື Launch ມີດັ່ງນີ້:

1. ກຽມຊຸດທົດສອບ (Test set) ທີ່ມີ Query ຕົວແທນປະມານ 50-100 ລາຍການ
2. ວັດແທກ Baseline ຂອງແຕ່ລະຕົວຊີ້ວັດດ້ວຍ RAGAS ຫຼື ເຄື່ອງມືອື່ນໆ
3. ກຳນົດຄ່າ Threshold (ຕົວຢ່າງ: Faithfulness 0.8 ຂຶ້ນໄປ) ແລະ ວາງກົດລະບຽບວ່າຖ້າຕໍ່າກວ່ານີ້ໃຫ້ລະງັບການເປີດຕົວໄວ້ກ່ອນ
4. ຫຼັງຈາກເປີດຕົວ ຫຼື Launch ແລ້ວ ໃຫ້ກັບມາປະເມີນຜົນຊໍ້າດ້ວຍຊຸດທົດສອບເດີມຢ່າງສະໝໍ່າສະເໝີ ແລະ ຕິດຕາມການປ່ຽນແປງຂອງຄະແນນ

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

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

ເປັນຫຍັງຄວາມຖືກຕ້ອງຈຶ່ງຫຼຸດລົງ

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

ປັດໄຈຫຼັກທີ່ເຮັດໃຫ້ເກີດການຫຼຸດລົງມີດັ່ງນີ້:

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

ສະຖານະການຕົວຢ່າງ

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

ວິທີແກ້ໄຂ

• ນຳໃຊ້ວິທີ "Query Expansion" ໂດຍການແປຄຳຖາມເປັນຫຼາຍພາສາໂດຍອັດຕະໂນມັດກ່ອນການຄົ້ນຫາ
• ພິຈາລະນາສະຖາປັດຕະຍະກຳທີ່ແບ່ງ Index ຕາມແຕ່ລະພາສາ ແລະ ເຮັດການປັບມາດຕະຖານຄະແນນ (Normalize) ໃນຂັ້ນຕອນການ ລວມ ຫຼື Merge
• ນຳໃຊ້ Model ທີ່ຊ່ຽວຊານຫຼາຍພາສາປະສົມກັບ BM25 ເພື່ອເສີມຄວາມຖືກຕ້ອງໃນການຄົ້ນຫາ
• ວັດແທກຄວາມຖືກຕ້ອງໃນການຄົ້ນຫາແຍກຕາມພາສາດ້ວຍດັດຊະນີການປະເມີນຜົນຢ່າງສະໝໍ່າສະເໝີ ແລະ ກຳນົດຮອບວຽນໃນການເລືອກ Model ໃໝ່

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

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

ໃນການນຳໃຊ້ງານຈິງ, ມັກຈະເກີດຄຳຖາມທີ່ການຄົ້ນຫາແບບ Vector ພຽງຢ່າງດຽວບໍ່ສາມາດກວມເອົາໄດ້ໝົດ. Hybrid Search ເປັນໜຶ່ງໃນວິທີການທີ່ມີຜົນງານດີທີ່ສຸດໃນປັດຈຸບັນ ເພື່ອຊ່ວຍອຸດຊ່ອງວ່າງດັ່ງກ່າວ.

ຈຸດອ່ອນຂອງການຄົ້ນຫາແບບ Vector ແລະ BM25

• ຈຸດອ່ອນຂອງການຄົ້ນຫາແບບ Vector: ຄະແນນຄວາມຄ້າຍຄືກັນມັກຈະຫຼຸດລົງ ຖ້າການຂຽນບໍ່ກົງກັນ ເຊັ່ນ: ຊື່ສະເພາະ, ໝາຍເລກລຸ້ນ (Model number), ຫຼື ຊື່ຄຳສັ່ງ. ຕົວລະບຸຕົວຕົນເຊັ່ນ "AWS Lambda" ຫຼື "CVE-2024-XXXX" ມັກຈະບໍ່ຖືກຝັງໄວ້ໃນບໍລິເວນທີ່ມີຄວາມໝາຍໃກ້ຄຽງກັນ.
• ຈຸດອ່ອນຂອງ BM25: ເນື່ອງຈາກຂຶ້ນກັບການກົງກັນຂອງຮູບແບບຄຳສັບ, ຈຶ່ງຍາກທີ່ຈະຮອງຮັບການປ່ຽນຄຳເວົ້າ ຫຼື ຄຳທີ່ມີຄວາມໝາຍຄ້າຍຄືກັນ. ຕົວຢ່າງເຊັ່ນ "ການຫຼຸດຜ່ອນຕົ້ນທຶນ" ແລະ "ການບີບອັດຄ່າໃຊ້ຈ່າຍ" ຈະຖືກປະຕິບັດເປັນຄຳຖາມທີ່ແຕກຕ່າງກັນ.

ການລວມທັງສອງວິທີເຂົ້າດ້ວຍກັນ ສາມາດກວມເອົາໄດ້ທັງຄວາມໃກ້ຄຽງທາງຄວາມໝາຍ ແລະ ການກົງກັນຂອງຕົວອັກສອນ.

ວິທີການລວມຄະແນນ: RRF ເປັນກະແສຫຼັກ

Reciprocal Rank Fusion (RRF) ໄດ້ຮັບການຍອມຮັບຢ່າງກວ້າງຂວາງໃນການລວມຄະແນນ. ມັນເປັນວິທີທີ່ງ່າຍດາຍໂດຍການໃຫ້ຄ່ານ້ຳໜັກກັບອັນດັບຂອງຜົນການຄົ້ນຫາແຕ່ລະອັນດ້ວຍຄ່າປີ້ນ (Reciprocal) ແລ້ວນຳມາລວມກັນ, ເຊິ່ງມີຂໍ້ດີຄືສາມາດລວມສອງລະບົບທີ່ມີສະເກັດຄະແນນຕ່າງກັນໄດ້ໂດຍບໍ່ຈຳເປັນຕ້ອງເຮັດການ Normalize. ພື້ນຖານການຄົ້ນຫາຫຼັກໆ ເຊັ່ນ Elasticsearch, OpenSearch, ແລະ Weaviate ກຳລັງພັດທະນາການຮອງຮັບ Hybrid Search ທີ່ອີງໃສ່ RRF ໂດຍກົງ (Native support), ເຮັດໃຫ້ຕົ້ນທຶນໃນການຈັດຕັ້ງປະຕິບັດຫຼຸດລົງກວ່າແຕ່ກ່ອນ.

ກໍລະນີທີ່ເຫັນຜົນໄດ້ຊັດເຈນ

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

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

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

Agentic RAG ໝາຍເຖິງສະຖາປັດຕະຍະກຳທີ່ເຮັດໃຫ້ LLM ເຮັດໜ້າທີ່ເປັນຕົວແທນ (Agent) ເພື່ອດຳເນີນການຄົ້ນຫາ, ຕັດສິນໃຈ ແລະ ຄົ້ນຫາຊ້ຳໃນຮູບແບບວົງຈອນຢ່າງອິດສະຫຼະ. ຮູບແບບການອອກແບບຫຼັກໆສາມາດແບ່ງອອກໄດ້ເປັນ 3 ປະເພດດັ່ງນີ້:

• ຮູບແບບ Plan-and-Execute: ເມື່ອ Agent ໄດ້ຮັບຄິວຣີ, ມັນຈະສ້າງ "ລາຍການວຽກຍ່ອຍ" ຂຶ້ນມາກ່ອນ, ຈາກນັ້ນຈຶ່ງດຳເນີນການຄົ້ນຫາ ແລະ ຕອບແຕ່ລະວຽກຢ່າງເປັນອິດສະຫຼະ ແລະ ສຸດທ້າຍຈຶ່ງສ້າງຄຳຕອບແບບລວມຍອດ.
• ຮູບແບບ ReAct (Reasoning + Acting): ເປັນການເຮັດວຽກຊ້ຳໆໃນວົງຈອນ ການຄິດ (Reasoning) → ການກະທຳ (Acting) → ການສັງເກດ (Observing), ຖ້າຜົນການຄົ້ນຫາບໍ່ພຽງພໍ ມັນຈະປັບປ່ຽນຄິວຣີໃໝ່ໂດຍອັດຕະໂນມັດເພື່ອຄົ້ນຫາອີກຄັ້ງ.
• ຮູບແບບ Self-RAG: ຕົວແບບຈະປະເມີນຄຳຕອບທີ່ສ້າງຂຶ້ນດ້ວຍຕົນເອງວ່າ "ຄຳຕອບນີ້ມີເອກະສານອ້າງອີງທີ່ໜ້າເຊື່ອຖືໄດ້ຫຼືບໍ່", ຖ້າບໍ່ແນ່ໃຈມັນຈະດຳເນີນການຄົ້ນຫາໃໝ່.

ຕົວຢ່າງເຊັ່ນ: ຄິວຣີທີ່ວ່າ "ຈົ່ງປຽບທຽບເຫດຜົນທາງເຕັກນິກທີ່ເຮັດໃຫ້ລາຄາຂອງຜະລິດຕະພັນ A ແລະ B ແຕກຕ່າງກັນ" ແມ່ນຍາກທີ່ຈະຕອບໄດ້ດ້ວຍການຄົ້ນຫາພຽງຄັ້ງດຽວ. ຖ້າໃຊ້ຮູບແບບ Plan-and-Execute, ມັນສາມາດແຍກການເຮັດວຽກອອກເປັນ 3 ຂັ້ນຕອນຄື: ຄົ້ນຫາ ມາດຕະຖານ ຫຼື Specification ຂອງຜະລິດຕະພັນ A, ຄົ້ນຫາ ມາດຕະຖານ ຫຼື Specification ຂອງຜະລິດຕະພັນ B, ແລະ ການວິເຄາະປຽບທຽບ.

ໃນການນຳໃຊ້ຄວນລະວັງຈຸດຕ່າງໆດັ່ງນີ້:

• ກຳນົດຂີດຈຳກັດຂອງຈຳນວນຮອບວຽນ (max_iterations) ເພື່ອປ້ອງກັນການເກີດວົງຈອນບໍ່ສິ້ນສຸດ.
• ບັນທຶກ Log ຂອງແຕ່ລະຂັ້ນຕອນ ເພື່ອໃຫ້ສາມາດຕິດຕາມ (Trace) ໄດ້ວ່າການຄົ້ນຫາໃດທີ່ລົ້ມເຫຼວ.
• ເນື່ອງຈາກການຮຽກໃຊ້ເຄື່ອງມືມີການສະສົມເພີ່ມຂຶ້ນ, ການຕິດຕາມກວດກາ Latency ແລະ ການໃຊ້ Token ຈຶ່ງເປັນສິ່ງທີ່ຂາດບໍ່ໄດ້.

Agentic RAG ມີປະສິດທິພາບສູງ ແຕ່ກໍມີຈຸດທີ່ອາດເກີດຂໍ້ຜິດພາດເພີ່ມຂຶ້ນຕາມຄວາມຊັບຊ້ອນ. ດັ່ງນັ້ນ, ການໃຊ້ໂຄງສ້າງແບບປະສົມ (Hybrid) ທີ່ໃຊ້ RAG ແບບປົກກະຕິສຳລັບຄິວຣີທີ່ງ່າຍດາຍ ແລະ ເປີດໃຊ້ Agent ສະເພາະຄິວຣີທີ່ຊັບຊ້ອນເທົ່ານັ້ນ, ຖືເປັນແນວທາງທີ່ມີປະສິດທິຜົນໃນດ້ານຄວາມສະຖຽນຂອງການດຳເນີນງານ.

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

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

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

ຕົວຢ່າງກໍລະນີການນຳໃຊ້ (Use Case) ທີ່ເຫັນຜົນໄດ້ງ່າຍ:

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

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

ສະຫຼຸບປະເດັນສຳຄັນ:

• ເຖິງຈະເປັນຂະໜາດນ້ອຍ ແຕ່ RAG ກໍຍັງມີປະສິດທິພາບ ພຽງແຕ່ຄວາມຖືກຕ້ອງໃນການອອກແບບ Chunk ແລະ Prompt ຈະມີຄວາມສຳຄັນຫຼາຍຂຶ້ນ
• ເພື່ອເພີ່ມອັດຕາການຄົ້ນຫາໃຫ້ພົບ (Hit Rate), ຄວນພິຈາລະນາການນຳໃຊ້ການຂະຫຍາຍ Query (Query Expansion)
• ຍ້ອນມີເອກະສານໜ້ອຍ, ການວັດແທກຄຸນນະພາບດ້ວຍ RAGAS ແລະ ອື່ນໆ ໂດຍການປະເມີນຜົນທັງໝົດ ຈຶ່ງສາມາດເຮັດໄດ້ງ່າຍກວ່າ

ໃນການສ້າງ RAG, ແນວຄິດພື້ນຖານໃນການເລືອກ LLM ບໍ່ແມ່ນການຕັດສິນວ່າ "ຕົວໃດເກັ່ງທີ່ສຸດ" ແຕ່ແມ່ນ "ຕົວໃດທີ່ເໝາະສົມກັບກໍລະນີການນຳໃຊ້ (Use case) ຂອງທ່ານ". GPT, Claude ແລະ Gemini ລ້ວນແຕ່ມີປະສິດທິພາບສູງ ເຊິ່ງຍາກທີ່ຈະຕັດສິນຄວາມດີ-ຄວາມດ້ອຍໄດ້ຢ່າງຊັດເຈນ.

ຄຸນລັກສະນະຂອງແຕ່ລະໂມເດວ ແລະ ກໍລະນີການນຳໃຊ້ທີ່ເໝາະສົມ:

• GPT (OpenAI): ມີຜົນງານທີ່ໂດດເດັ່ນໃນດ້ານການເຊື່ອມຕໍ່ເຄື່ອງມື ແລະ ການຮຽກໃຊ້ຟັງຊັນ (Function calling), ມີຕົວຢ່າງການເຊື່ອມໂຍງກັບ LangChain ແລະ LlamaIndex ຫຼາຍ. ມີການສະສົມຄວາມຮູ້ໃນການສ້າງ ຂະບວນການ ຫຼື Pipeline ຂອງ RAG ໄວ້ຫຼາຍ ແລະ ລະບົບນິເວດ (Ecosystem) ມີຄວາມເຕີບໃຫຍ່ສູງ.
• Claude (Anthropic): ມີ Context window ທີ່ໃຫຍ່ຫຼາຍ, ມີຈຸດແຂງໃນສະຖານະການທີ່ຕ້ອງຈັດການກັບເອກະສານຍາວໆໃນຄັ້ງດຽວ. ມີການລາຍງານວ່າຖືກອອກແບບມາໂດຍເນັ້ນຄວາມຊື່ສັດຕໍ່ຄຳສັ່ງ ແລະ ຄວາມປອດໄພ.
• Gemini (Google): ມີຄວາມເຂົ້າກັນໄດ້ສູງກັບ Google Workspace ແລະ ໂຄງສ້າງພື້ນຖານ ຫຼື Infrastructure ການຄົ້ນຫາ, ມີການຮອງຮັບ Multimodal ທີ່ຄົບຖ້ວນ. ຄຸນນະພາບໃນການປະມວນຜົນພາສາຢີ່ປຸ່ນກໍມີທ່າອ່ຽງດີຂຶ້ນ.

ຈຸດທີ່ຄວນກວດສອບໃນເວລາຄັດເລືອກ:

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

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

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

ການນຳໃຊ້ກອບການປະເມີນຜົນ (Evaluation Framework) ເຊັ່ນ RAGAS ຫຼື TruLens, ພ້ອມທັງການປະເມີນຜົນແບບປະລິມານໂດຍການລວມເອົາຕົວຊີ້ວັດຫຼາຍຢ່າງ ເຊັ່ນ: ຄວາມຖືກຕ້ອງຂອງການດຶງຂໍ້ມູນ (Retrieval accuracy), ຄວາມກ່ຽວຂ້ອງຂອງຄຳຕອບ (Answer Relevancy) ແລະ ຄວາມຊື່ສັດຕໍ່ຂໍ້ມູນ (Faithfulness) ກຳລັງກາຍເປັນມາດຕະຖານ. ການວັດແທກຄ່າພື້ນຖານ (Baseline) ກ່ອນການນຳໃຊ້ຈິງ ຈະຊ່ວຍໃຫ້ການໝູນວຽນຮອບວຽນການປັບປຸງງ່າຍຂຶ້ນ.

ຈຸດສຳຄັນ ຫຼື ແກນຫຼັກ ໃນການນຳໃຊ້ລາຍການກວດສອບມີດັ່ງນີ້:

• ໄລຍະການອອກແບບ: ກວດສອບຂະໜາດຂອງ Chunk, ຄວາມກວ້າງຂອງການຊ້ອນກັນ (Overlap) ແລະ ຄວາມເໝາະສົມດ້ານພາສາຂອງ Embedding model.
• ໄລຍະການຈັດຕັ້ງປະຕິບັດ: ກວດສອບຄວາມເປັນໄປໄດ້ໃນການນຳໃຊ້ Hybrid search, ການມີຢູ່ຂອງການຈັດອັນດັບໃໝ່ (Re-ranking) ແລະ ຂີດຈຳກັດຂອງຄວາມຍາວຂອງ Prompt.
• ໄລຍະການດຳເນີນງານ: ທົບທວນຄືນຄວາມຖີ່ໃນການອັບເດດ Index, ລະບົບການຕິດຕາມຕົວຊີ້ວັດການປະເມີນຜົນ ແລະ ສະຖານະການປະສົມປະສານຂອງເອກະສານຫຼາຍພາສາຢ່າງສະໝໍ່າສະເໝີ.

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

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