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

ສາເຫດຫຼັກທີ່ເຮັດໃຫ້ RAG ເຊິ່ງມີຄວາມແມ່ນຍຳສູງໃນຂັ້ນຕອນ PoC ເກີດຄວາມຜິດພາດໃນການນຳໃຊ້ຈິງນັ້ນ ບໍ່ແມ່ນຍ້ອນຄວາມສະຫຼາດຂອງຕົວແບບ (Model) ແຕ່ເປັນຍ້ອນ "ບໍ່ສາມາດດຶງເອົາເອກະສານທີ່ຈຳເປັນຕ້ອງໃຊ້ໃນການຄົ້ນຫາ (Retrieval) ອອກມາໄດ້". ໃນທີ່ນີ້, ກ່ອນອື່ນໝົດຈະຂໍສະຫຼຸບເຫດຜົນທາງໂຄງສ້າງທີ່ເຮັດໃຫ້ຄວາມແມ່ນຍຳບໍ່ພັດທະນາຂຶ້ນ ໂດຍແບ່ງອອກເປັນ 2 ມຸມມອງ ຄື: ຂີດຈຳກັດຂອງການຄົ້ນຫາແບບ Vector ແລະ ແຫຼ່ງທີ່ມາຂອງການເກີດ Hallucination.

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

ອີກໜຶ່ງຈຸດຜິດພາດຄື ກໍລະນີທີ່ຄຳສັບລະຫວ່າງຄຳຖາມ ແລະ ເອກະສານບໍ່ກົງກັນ. ຖ້າຜູ້ໃຊ້ພິມຄຳວ່າ "ເງິນຊົດເຊີຍການລາອອກ" ແຕ່ໃນກົດລະບຽບພາຍໃນບໍລິສັດໃຊ້ຄຳວ່າ "ຜົນປະໂຫຍດຫຼັງການລາອອກ", ເຖິງວ່າຄວາມໝາຍຈະຄືກັນແຕ່ພຽງແຕ່ການຂຽນຕ່າງກັນ ກໍອາດເຮັດໃຫ້ຄະແນນບໍ່ສູງຂຶ້ນ ຂຶ້ນຢູ່ກັບຂໍ້ມູນທີ່ໃຊ້ຝຶກຝົນ (Training data) ຂອງຕົວແບບ Embedding. ຄວາມບໍ່ສອດຄ່ອງຂອງຄຳສັບ (lexical gap) ເຫຼົ່ານີ້ ສາມາດປັບປຸງໃຫ້ດີຂຶ້ນໄດ້ຢ່າງຫຼວງຫຼາຍໂດຍການໃຊ້ການຄົ້ນຫາແບບເຕັມຮູບແບບ (Full-text search) ເຊັ່ນ BM25 ທີ່ກ່າວເຖິງໃນພາຍຫຼັງ. ການຄົ້ນຫາທາງຄວາມໝາຍ ແລະ ການຄົ້ນຫາດ້ວຍຄຳສັບ (Keyword search) ບໍ່ແມ່ນວ່າອັນໃດອັນໜຶ່ງດີກວ່າກັນ ແຕ່ມັນມີຄວາມສຳພັນໃນການຕື່ມເຕັມເຊິ່ງກັນແລະກັນ ເນື່ອງຈາກປະເພດຂອງຂໍ້ມູນທີ່ອາດຈະຕົກຫຼົ່ນນັ້ນແຕກຕ່າງກັນ—ນີ້ຄືມຸມມອງໃນທາງປະຕິບັດ.

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

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

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

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

ໃນການປະເມີນຜົນ RAG, ວິທີການທີ່ເປັນມາດຕະຖານແມ່ນການແຍກວັດແທກລະຫວ່າງການສ້າງເນື້ອຫາ (Generation) ແລະ ການຄົ້ນຫາ (Retrieval). ຕົວຊີ້ວັດຫຼັກມີ 3 ຢ່າງຕໍ່ໄປນີ້ ເຊິ່ງແຕ່ລະຢ່າງຈະກວດຫາບັນຫາທີ່ແຕກຕ່າງກັນ:

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

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

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

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

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

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

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

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

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

BM25 (ການຄົ້ນຫາຂໍ້ຄວາມເຕັມແບບຄລາສສິກໂດຍອີງໃສ່ຄວາມສອດຄ່ອງຂອງຄຳສຳຄັນ) ແລະ ການຄົ້ນຫາແບບ Vector ມີມາດຕະຖານຄະແນນທີ່ແຕກຕ່າງກັນຢ່າງສິ້ນເຊີງ. ຄະແນນຂອງ BM25 ບໍ່ມີຂີດຈຳກັດທາງທິດສະດີ, ໃນຂະນະທີ່ຄ່າ Cosine Similarity ຂອງການຄົ້ນຫາແບບ Vector ຈະຢູ່ໃນລະຫວ່າງ 0 ຫາ 1. ຖ້າເອົາທັງສອງຢ່າງນີ້ມາບວກກັນແບບງ່າຍໆ, ມັນຈະບໍ່ມີຄວາມໝາຍເນື່ອງຈາກຖືກດຶງໂດຍສະເກັດຂອງຝ່າຍໃດຝ່າຍໜຶ່ງ.

ດັ່ງນັ້ນ, ສິ່ງທີ່ຖືກນຳໃຊ້ຢ່າງແຜ່ຫຼາຍຄື RRF (Reciprocal Rank Fusion / ການລວມອັນດັບແບບປີ້ນກັບ). RRF ຈະປະຖິ້ມຄ່າຄະແນນທີ່ແທ້ຈິງ ແລະ ໃຊ້ພຽງແຕ່ "ອັນດັບ" ຂອງແຕ່ລະວິທີການຄົ້ນຫາເທົ່ານັ້ນ. ໂດຍສະເພາະ, ສຳລັບແຕ່ລະເອກະສານ ຈະມີການຄຳນວນ 1 / (k + ອັນດັບ) ໃນແຕ່ລະວິທີການຄົ້ນຫາ, ຈາກນັ້ນນຳມາລວມກັນເພື່ອຕັດສິນອັນດັບສຸດທ້າຍ (k ແມ່ນຄ່າຄົງທີ່ເພື່ອຫຼຸດຜ່ອນຜົນກະທົບຂອງອັນດັບຕົ້ນໆ, ເຊິ່ງມັກຈະໃຊ້ຄ່າປະມານ 60).

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

ຂີດຈຳກັດຂອງການຄົ້ນຫາຈະຖືກກຳນົດໂດຍການອອກແບບ Chunk (ໜ່ວຍຍ່ອຍຂອງເອກະສານ). ຖ້າ Chunk ໃຫຍ່ເກີນໄປ ຂໍ້ມູນທີ່ບໍ່ກ່ຽວຂ້ອງຈະປົນເຂົ້າມາຈົນກາຍເປັນ Noise, ແລະຖ້າ Chunk ນ້ອຍເກີນໄປ ບໍລິບົດຈະຂາດຫາຍໄປເຮັດໃຫ້ບໍ່ສາມາດສື່ຄວາມໝາຍໄດ້. ບໍ່ມີຕົວເລກໃດທີ່ໃຊ້ໄດ້ກັບທຸກກໍລະນີ, ແຕ່ໃນເບື້ອງຕົ້ນຄວນເລີ່ມຕົ້ນທີ່ 1 Chunk ປະມານ 300-800 Token ແລ້ວຈຶ່ງປັບປ່ຽນໂດຍອີງຕາມຊຸດຂໍ້ມູນການປະເມີນຜົນ (Evaluation Dataset) ເຊິ່ງເປັນວິທີທີ່ເໝາະສົມທີ່ສຸດ.

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

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

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

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

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

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

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

Graph RAG ຈະສະກັດເອົາ Entity ແລະ ຄວາມສຳພັນຈາກເອກະສານເພື່ອສ້າງເປັນ Knowledge Graph, ແລະ ໃນເວລາຄົ້ນຫາ ມັນຈະຕິດຕາມກຣາຟດັ່ງກ່າວ ເພື່ອດຶງເອົາຂໍ້ມູນທີ່ກະແຈກກະຈາຍມາລວມເຂົ້າກັນຕາມຄວາມສຳພັນ. ຜົນທີ່ໄດ້ຄື ຄຸນນະພາບຂອງຄຳຕອບສຳລັບຄຳຖາມທີ່ມີລັກສະນະກວມລວມ ຫຼື ການເບິ່ງພາບລວມ ເຊັ່ນ: "ຈົ່ງສະຫຼຸບພາບລວມ" ຫຼື "ຈົ່ງອະທິບາຍຄວາມກ່ຽວຂ້ອງລະຫວ່າງ A ແລະ B" ຈະມີປະສິດທິພາບສູງຂຶ້ນ.

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

ຂໍ້ເສຍປຽບຂອງ Graph RAG ແມ່ນເລື່ອງຂອງຕົ້ນທຶນ. ຂະບວນການສະກັດເອົາ Entity ແລະ ຄວາມສຳພັນຈາກເອກະສານຢ່າງຖືກຕ້ອງ (ສ່ວນຫຼາຍແມ່ນດຳເນີນການໂດຍ LLM) ແມ່ນມີຄວາມຈຳເປັນເພີ່ມເຕີມ, ເຊິ່ງຕົ້ນທຶນໃນການສະກັດຂໍ້ມູນ ແລະ ເວລາໃນການສ້າງຈະເພີ່ມທະວີຂຶ້ນເລື້ອຍໆ ຕາມປະລິມານຂອງເອກະສານ. ການອອກແບບ Schema ຂອງກຣາຟ ແລະ ຂະບວນການ ຫຼື Pipeline ໃນການສ້າງກຣາຟຄືນໃໝ່ເມື່ອມີການອັບເດດເອກະສານ ກໍກາຍເປັນພາລະໃນການດຳເນີນງານເຊັ່ນກັນ.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

• ວັດແທກກ່ອນ: ສ້າງຊຸດຂໍ້ມູນການປະເມີນຜົນໂດຍອີງໃສ່ Faithfulness, Answer Relevancy ແລະ Context Recall ເພື່ອແຍກໃຫ້ເຫັນວ່າລະຫວ່າງການຄົ້ນຫາ (Retrieval) ແລະ ການສ້າງຄຳຕອບ (Generation) ສ່ວນໃດທີ່ຍັງອ່ອນ.
• ປັບປຸງການຄົ້ນຫາ: ໃຊ້ການຄົ້ນຫາແບບປະສົມ (Hybrid Search: BM25 + Vector, ລວມ ຫຼື Merge ດ້ວຍ RRF) ແລະ ການຈັດລຳດັບໃໝ່ (Reranking) ເພື່ອຍົກລະດັບຄຸນນະພາບຂອງບໍລິບົດທີ່ຈະ ສົ່ງຂໍ້ມູນຕໍ່ໃຫ້ ການສ້າງຄຳຕອບ. ການອອກແບບ Chunk ແລະ ຄວາມທັນສະໄໝຂອງ Index ກໍເປັນສ່ວນໜຶ່ງຂອງຄຸນນະພາບການຄົ້ນຫາເຊັ່ນກັນ.
• ສ້າງໂຄງສ້າງຕາມຄວາມຈຳເປັນ: ຖ້າມີຄຳຖາມທີ່ຕ້ອງຕິດຕາມຄວາມສຳພັນຫຼາຍ ໃຫ້ພິຈາລະນາໃຊ້ Graph RAG ແຕ່ຕ້ອງຕັດສິນໃຈຫຼັງຈາກໄດ້ທົດສອບຜ່ານ PoC ຂະໜາດນ້ອຍແລ້ວວ່າຄຸ້ມຄ່າກັບ ການແລກປ່ຽນ ຫຼື Trade-off ດ້ານຕົ້ນທຶນຫຼືບໍ່.
• ຄວບຄຸມການສ້າງຄຳຕອບໃນຂັ້ນຕອນສຸດທ້າຍ: ໃຊ້ຄຳສັ່ງ Grounding ແລະ ການລະບຸແຫຼ່ງທີ່ມາ ເພື່ອຫຼຸດຜ່ອນການຕອບແບບບໍ່ມີຫຼັກຖານ.

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