Knowledge Graph × RAG ແມ່ນສະຖາປັດຕະຍະກຳການຄົ້ນຫາ ແລະ ສ້າງຂໍ້ມູນຂັ້ນສູງ ທີ່ສາມາດຕອບຄຳຖາມແບບຫຼາຍຂັ້ນຕອນ (Multi-hop query) ທີ່ RAG ແບບດັ້ງເດີມບໍ່ສາມາດຕອບໄດ້ ໂດຍການປະສົມປະສານຄວາມສຳພັນທາງໂຄງສ້າງຂອງ Knowledge Graph ເຂົ້າກັບການຄົ້ນຫາແບບ Vector.

ຄຳຖາມທີ່ເປັນຕ່ອງໂສ້ເຊັ່ນ: "A ກ່ຽວຂ້ອງກັບ B, B ເປັນເຈົ້າຂອງ C, ແລະ C ຕອບສະໜອງເງື່ອນໄຂຂອງ D ຫຼືບໍ່?" ນັ້ນ ບໍ່ສາມາດຕອບໄດ້ຢ່າງຖືກຕ້ອງດ້ວຍພຽງແຕ່ຄວາມຄ້າຍຄືກັນຂອງ Vector ເທົ່ານັ້ນ. ການນຳໃຊ້ໂຄງສ້າງກຣາຟຈະຊ່ວຍໃຫ້ສາມາດເກັບກຳບໍລິບົດທີ່ຈຳເປັນໃນຂະນະທີ່ຕິດຕາມຄວາມສຳພັນລະຫວ່າງ Entity ຕ່າງໆໄດ້.

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

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

ພວກເຮົາຈະມາສະຫຼຸບຂໍ້ຈຳກັດຂອງ RAG ແບບດັ້ງເດີມ ແລະ ບັນຫາທີ່ສາມາດແກ້ໄຂໄດ້ດ້ວຍການນຳເອົາ Knowledge Graph ມາປະສົມປະສານ. ມາເບິ່ງໄປພ້ອມກັນວ່າ ເປັນຫຍັງ GraphRAG ຈຶ່ງໄດ້ຮັບຄວາມສົນໃຈໃນປັດຈຸບັນ ໂດຍເລີ່ມຈາກພື້ນຖານຄວາມເປັນມາ.

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

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

• Query ທີ່ຕ້ອງການການອະນຸມານຫຼາຍຂັ້ນ (Multi-hop reasoning): ຄຳຖາມປະເພດ "ບໍລິສັດອື່ນທີ່ CEO ຂອງບໍລິສັດແມ່ຂອງບໍລິສັດ A ດຳລົງຕຳແໜ່ງຮ່ວມນຳແມ່ນບໍລິສັດໃດ" ເຊິ່ງຕ້ອງຕິດຕາມຄວາມສຳພັນຂ້າມຫຼາຍ Entity, ສ່ວນຫຼາຍແລ້ວຄຳຕອບຈະບໍ່ມີຢູ່ໃນ Chunk ດຽວທີ່ມີຄະແນນຄວາມຄ້າຍຄືກັນສູງ.
• Query ປະເພດປະຕິເສດ, ປຽບທຽບ, ຫຼື ສະຫຼຸບລວມ: ຄຳຖາມທີ່ກ່ຽວຂ້ອງກັບການດຳເນີນການແບບກຸ່ມ (Set operation) ເຊັ່ນ "ຜະລິດຕະພັນທີ່ບໍ່ແມ່ນ...", "ບຸກຄົນທີ່ປາກົດຕົວຫຼາຍທີ່ສຸດ" ບໍ່ສາມາດສ້າງຄຳຕອບໄດ້ດ້ວຍການຄົ້ນຫາ Vector ໃກ້ຄຽງພຽງຢ່າງດຽວ.
• ການຂາດຕອນຂອງບໍລິບົດເນື່ອງຈາກການແບ່ງ Chunk: ເມື່ອແບ່ງເອກະສານດ້ວຍຄວາມຍາວຄົງທີ່, ຂໍ້ມູນທີ່ກ່ຽວຂ້ອງກັນອາດຈະຖືກແຍກໄປຢູ່ຄົນລະ Chunk ເຮັດໃຫ້ເກີດການດຶງຂໍ້ມູນບໍ່ຄົບຖ້ວນໄດ້ງ່າຍ.

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

ການອະນຸມານແບບຫຼາຍຂັ້ນ (Multi-hop reasoning) ແມ່ນຮູບແບບການອະນຸມານທີ່ບໍ່ສາມາດຕອບໄດ້ດ້ວຍຂັ້ນຕອນການຄົ້ນຫາພຽງຂັ້ນຕອນດຽວ ແຕ່ຕ້ອງຕິດຕາມຄວາມສຳພັນຫຼາຍຢ່າງແບບຕໍ່ເນື່ອງຈຶ່ງຈະພົບຄຳຕອບ. ຕົວຢ່າງທີ່ຊັດເຈນຄືການສອບຖາມວ່າ "ກຸ່ມຜະລິດຕະພັນຂອງບໍລິສັດທີ່ CEO ຂອງບໍລິສັດແມ່ຂອງບໍລິສັດ A ເຄີຍເຮັດວຽກມາກ່ອນ".

ໂຄງສ້າງກຣາຟ (Graph structure) ແກ້ໄຂບັນຫານີ້ດ້ວຍກົນໄກດັ່ງນີ້:

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

ການຕັດສິນໃຈເລືອກໃຊ້ໃຫ້ເໝາະສົມກັບລັກສະນະຂອງ Query ກໍມີຄວາມສຳຄັນ. ໃນກໍລະນີການສອບຖາມຂໍ້ເທັດຈິງແບບງ່າຍໆ (ເຊັ່ນ: "ນິຍາມຂອງ X ແມ່ນຫຍັງ") ການຄົ້ນຫາດ້ວຍ Vector ພຽງຢ່າງດຽວກໍພຽງພໍແລ້ວ, ແຕ່ໃນກໍລະນີ Query ທີ່ມີຄວາມສຳພັນຂ້າມຫຼາຍ Entity (ເຊັ່ນ: "ຈົ່ງອະທິບາຍ Z ໂດຍຜ່ານຈຸດຮ່ວມຂອງ X ແລະ Y") ການທ່ອງໄປຕາມກຣາຟ (Graph traversal) ແມ່ນສິ່ງທີ່ຂາດບໍ່ໄດ້.

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

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

ບົດຄວາມວິໄຈທີ່ເປີດຕົວ ຫຼື Launch ໂດຍ Microsoft Research ໃນຫົວຂໍ້ "GraphRAG: Unlocking LLM discovery on narrative private data" ໄດ້ສະແດງໃຫ້ເຫັນວ່າ ການນໍາໂຄງສ້າງກຣາຟ (Graph structure) ມາລວມເຂົ້າກັບ RAG ຈະຊ່ວຍເພີ່ມຄວາມຖືກຕ້ອງໃນການສະຫຼຸບພາບລວມ ແລະ ການຕອບຄໍາຖາມແບບຂ້າມເອກະສານ ເຊິ່ງວິທີການແບບເກົ່າເຮັດໄດ້ຍາກ. ຣີໂປຊິທໍຣີ (Repository) ດັ່ງກ່າວໄດ້ຮັບການອັບເດດຢ່າງຕໍ່ເນື່ອງພາຍໃຕ້ໃບອະນຸຍາດ MIT ແລະ ໄດ້ກ້າວເຂົ້າສູ່ຂັ້ນຕອນການນໍາໃຊ້ຈິງແລ້ວ.

ກໍລະນີການນໍາໃຊ້ (Use case) ທີ່ GraphRAG ສະແດງໃຫ້ເຫັນເຖິງປະສິດທິພາບຢ່າງເດັ່ນຊັດ ມີດັ່ງນີ້:

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

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

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

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

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

ເມື່ອມີການລວມກຣາຟເຂົ້າມາ ກ່ຽວຂ້ອງ, ການໃຊ້ພຽງແຕ່ໄລບຣາຣີຂອງ Chain ແບບທົ່ວໄປອາດຈະເຮັດໃຫ້ການຈັດການການປະມວນຜົນ Cypher ແລະການຈັດການ Node Embedding ບໍ່ມີປະສິດທິພາບ. ໃນການປະຕິບັດງານ Knowledge Graph × RAG, ຖ້າເລືອກເຄື່ອງມືໂດຍຄຳນຶງເຖິງ 3 ຊັ້ນຄື: "ການຈັດການກຣາຟ", "ການຄົ້ນຫາແບບ Vector" ແລະ "ການຈັດການ LLM Orchestration" ຕັ້ງແຕ່ຕົ້ນ ຈະຊ່ວຍຫຼຸດຜ່ອນການປ່ຽນແປງການອອກແບບໃນພາຍຫຼັງໄດ້.

ຊັ້ນການຈັດການກຣາຟ (Graph Operation Layer)

• neo4j (Python driver): ການປະມວນຜົນ Cypher query ແລະການເຊື່ອມຕໍ່ກັບ Graph DB
• langchain-community ຂອງ Neo4j integration: ຕົວເຊື່ອມຕໍ່ໃນການນຳເອົາການຄົ້ນຫາກຣາຟເຂົ້າໄປໃນ LLM chain

ຊັ້ນການຄົ້ນຫາແບບ Vector (Vector Search Layer)

• sentence-transformers ຫຼື Embedding API: ການສ້າງ Embedding ສຳລັບ Node ແລະ Chunk
• faiss-cpu ຫຼື chromadb: Vector store ແບບນ້ຳໜັກເບົາສຳລັບສະພາບແວດລ້ອມ Local

ຊັ້ນການຈັດການ LLM Orchestration (LLM Orchestration Layer)

• langchain / llama-index: ການລວມຜົນການຄົ້ນຫາ, ການສ້າງ Prompt ແລະການເຮັດໃຫ້ເປັນຂະບວນການ ຫຼື Pipeline ໃນການສ້າງຄຳຕອບ
• ເພີ່ມໂມດູນ Query routing ຫຼື Reranking ຕາມຄວາມຈຳເປັນ

ໃນຂັ້ນຕອນການກວດສອບ, Stack ທີ່ເຮັດວຽກພາຍໃນ Local (ເຊັ່ນ: NetworkX + FAISS) ແມ່ນພຽງພໍແລ້ວ, ແຕ່ຖ້າຫາກເບິ່ງໄປເຖິງການນຳໃຊ້ຈິງ (Production) ການເລືອກໃຊ້ Neo4j ຮ່ວມກັບ Managed Vector DB ເພື່ອເຮັດ PoC ຕັ້ງແຕ່ຕົ້ນ ຈະຊ່ວຍຫຼຸດຜ່ອນຕົ້ນທຶນໃນການຍົກຍ້າຍລະບົບໄດ້.

ການເລືອກລະຫວ່າງ Graph DB ແລະ Vector DB ແມ່ນຂຶ້ນຢູ່ກັບຂະໜາດຂອງຂໍ້ມູນທີ່ຈັດການ ແລະ ຮູບແບບການ Query. ຖ້າເປັນໂປຣໂຕໄທ (Prototype) ຂະໜາດນ້ອຍ, ການເລືອກໃຊ້ແບບເບົາບາງກໍພຽງພໍແລ້ວ, ແຕ່ຖ້າຫາກວາງແຜນເພື່ອການນຳໃຊ້ຈິງໃນການຜະລິດ (Production), ຈຳເປັນຕ້ອງເລືອກໂດຍໃຫ້ຄວາມສຳຄັນກັບຄວາມສາມາດໃນການຂະຫຍາຍຕົວ (Scalability) ແລະ ຄວາມງ່າຍໃນການເຊື່ອມໂຍງ.

ຈຸດສຳຄັນ ຫຼື ແກນຫຼັກ ໃນການເລືອກ Graph DB

• Neo4j: ມີຄວາມສາມາດໃນການສະແດງອອກຂອງ Cypher query ທີ່ສູງ ແລະ ມີຜົນງານການເຊື່ອມຕໍ່ກັບ LLM Knowledge Graph Builder, ຈຶ່ງເໝາະສົມກັບການນຳໃຊ້ໃນລະດັບອົງກອນ (Enterprise).
• Amazon Neptune / ArangoDB: ຄວນພິຈາລະນາໃນກໍລະນີທີ່ຕ້ອງການຮອງຮັບຫຼາຍຮູບແບບ (Multi-model) ຫຼື ໃຫ້ຄວາມສຳຄັນກັບຄວາມເຂົ້າກັນໄດ້ກັບ ໂຄງສ້າງພື້ນຖານ ຫຼື Infrastructure ຂອງ Cloud ທີ່ມີຢູ່.
• NetworkX (In-memory): ສຳລັບການກວດສອບຂະໜາດນ້ອຍທີ່ມີຈຳນວນ Node ບໍ່ເກີນຫຼັກໝື່ນ, ສາມາດເຮັດໃຫ້ສຳເລັດໄດ້ດ້ວຍ Python library ພຽງຢ່າງດຽວ.

ຈຸດສຳຄັນ ຫຼື ແກນຫຼັກ ໃນການເລືອກ Vector DB

• Pinecone / Weaviate: ເໝາະສົມໃນກໍລະນີທີ່ຕ້ອງການຫຼຸດພາລະໃນການດຳເນີນງານດ້ວຍລະບົບ Full-managed.
• pgvector (PostgreSQL extension): ໃນກໍລະນີທີ່ຕ້ອງການນຳໃຊ້ຊັບສິນ RDB ທີ່ມີຢູ່ໃຫ້ເກີດປະໂຫຍດ, ສາມາດຫຼຸດຜ່ອນການເພີ່ມ ໂຄງສ້າງພື້ນຖານ ຫຼື Infrastructure ໃຫ້ໜ້ອຍທີ່ສຸດໄດ້.
• Chroma / FAISS: ເໝາະສົມກັບການກວດສອບຢ່າງວ່ອງໄວໃນສະພາບແວດລ້ອມ Local ແລະ ມີປະສິດທິຜົນສຳລັບໂປຣໂຕໄທກ່ອນການຍ້າຍໄປສູ່ລະບົບການຜະລິດຈິງ.

ຈຸດຕັດສິນໃຈ

ໃນກໍລະນີທີ່ການອ້າງອີງແບບຫຼາຍຮອບ (Multi-hop reasoning) ຂອງຄວາມສຳພັນເປັນກໍລະນີການນຳໃຊ້ຫຼັກ, ການອອກແບບໂດຍມີ Neo4j ເປັນ ຈຸດສຳຄັນ ຫຼື ແກນຫຼັກ ແລະ ເພີ່ມການຄົ້ນຫາແບບ Vector ເປັນຟັງຊັນຍ່ອຍ ຈະເປັນໂຄງສ້າງທີ່ມີຄວາມສະຖຽນກວ່າ.

ປະສົບການທີ່ວ່າ "ເມື່ອພະຍາຍາມສ້າງກຣາຟ ແຕ່ຂໍ້ມູນກັບບໍ່ມີຄຸນນະພາບຈົນບໍ່ສາມາດເລີ່ມຕົ້ນຫຍັງໄດ້ເລີຍ" ແມ່ນສິ່ງທີ່ມັກຈະຖືກລາຍງານຢູ່ໃນໜ້າວຽກການຈັດຕັ້ງປະຕິບັດ GraphRAG. ເນື່ອງຈາກຄຸນນະພາບຂອງ Knowledge Graph ມີຄວາມກ່ຽວຂ້ອງໂດຍກົງກັບຄຸນນະພາບຂອງຂໍ້ມູນທີ່ປ້ອນເຂົ້າໄປ, ການອອກແບບການປະມວນຜົນເບື້ອງຕົ້ນ (Pre-processing) ຈຶ່ງຈຳເປັນຕ້ອງໄດ້ກຳນົດໃຫ້ແນ່ນອນກ່ອນຈະເຂົ້າສູ່ໄລຍະການສ້າງ.

ຂໍ້ກຳນົດດ້ານຄຸນນະພາບຂໍ້ມູນທີ່ຄວນກວດສອບ

• ຄວາມບໍ່ສະໝ່ຳສະເໝີຂອງການຂຽນ Entity: ໃນກໍລະນີທີ່ "ບໍລິສັດ ABC ຈຳກັດ", "ບໍລິສັດ ABC", ແລະ "ABC" ຊີ້ເຖິງ Entity ດຽວກັນ, ຖ້າບໍ່ມີການກຳນົດກົດລະບຽບການເຮັດ Normalization ໄວ້ລ່ວງໜ້າ ຈະເຮັດໃຫ້ເກີດ Node ຊ້ຳຊ້ອນໃນກຣາຟ.
• ຂໍ້ມູນຄວາມສຳພັນທີ່ຂາດຫາຍ ຫຼື ບໍ່ສົມບູນ: ບັນທຶກທີ່ບໍ່ຮູ້ຈຸດເລີ່ມຕົ້ນ ຫຼື ຈຸດສິ້ນສຸດຂອງຄວາມສຳພັນ (Edge) ຈະສົ່ງຜົນເສຍໂດຍກົງຕໍ່ຄວາມຖືກຕ້ອງຂອງການທ່ອງກຣາຟ (Graph Traversal), ດັ່ງນັ້ນຈຶ່ງຄວນກຳນົດນະໂຍບາຍໃນການຕັດອອກ ຫຼື ເຕີມເຕັມຂໍ້ມູນໃຫ້ຄົບຖ້ວນ.
• ຄວາມລະອຽດຂອງຂໍ້ຄວາມ: ຖ້າ Chunk ຍາວເກີນໄປ ຄວາມຖືກຕ້ອງໃນການສະກັດ Entity ໂດຍ LLM ຈະຫຼຸດລົງ, ແລະຖ້າສັ້ນເກີນໄປກໍຈະເຮັດໃຫ້ບໍລິບົດ (Context) ສູນເສຍໄປ. ຈຳນວນ Token ທີ່ເໝາະສົມຈະແຕກຕ່າງກັນໄປຕາມລັກສະນະຂອງຂໍ້ມູນ ແລະ ຈຸດປະສົງການນຳໃຊ້, ຈຶ່ງຈຳເປັນຕ້ອງມີການກວດສອບພາຍໃນສະພາບແວດລ້ອມຂອງບໍລິສັດເອງ.

ຂັ້ນຕອນຫຼັກທີ່ຄວນປະຕິບັດໃນຂະບວນການ ຫຼື Pipeline ການປະມວນຜົນເບື້ອງຕົ້ນ

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

ສະຫຼຸບ: ການສ້າງ Knowledge Graph ຈະດຳເນີນໄປຕາມ 3 ຂັ້ນຕອນ ຄື: "ການສະກັດເອົາ Entity → ການກຳນົດຄວາມສຳພັນ → ການຈັດເກັບຂໍ້ມູນລົງໃນ Graph DB".

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

ໃນການສະກັດເອົາ Entity, ຫຼາຍຄົນມັກຄິດວ່າ "ຍິ່ງສະກັດໄດ້ຫຼາຍເທົ່າໃດ ຄວາມແມ່ນຍຳກໍຍິ່ງສູງຂຶ້ນ" ແຕ່ໃນຄວາມເປັນຈິງແລ້ວ, ການອອກແບບໂດຍການຈຳກັດຂອບເຂດ (Scope) ຈະຊ່ວຍເພີ່ມຄຸນນະພາບຂອງກຣາຟ ແລະ ຄວາມແມ່ນຍຳໃນການຄົ້ນຫາໄດ້ດີກວ່າ.

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

ໃນການກຳນົດຄວາມສຳພັນ (Relationship), ໃຫ້ຈັດລະບຽບຈຸດຕ່າງໆຕໍ່ໄປນີ້ໄວ້ລ່ວງໜ້າ:

• ທິດທາງຂອງຄວາມສຳພັນ: ກຳນົດເປັນ Directed Graph ເຊັ່ນ (A)-[:DEPENDS_ON]->(B) ເພື່ອໃຫ້ທິດທາງໃນການອະນຸມານມີຄວາມຊັດເຈນ
• ຄວາມຫຼາກຫຼາຍຂອງຄວາມສຳພັນ (Multiplicity): ລະບຸໃຫ້ຊັດເຈນວ່າເປັນແບບ 1 ຕໍ່ຫຼາຍ ຫຼື ຫຼາຍຕໍ່ຫຼາຍ ເພື່ອນຳໄປໃຊ້ໃນການອອກແບບການທ່ອງເວັບ (Traversal) ໃນພາຍຫຼັງ
• ຄຸນລັກສະນະຂອງຄວາມສຳພັນ: ກຳນົດນ້ຳໜັກ ຫຼື ຄະແນນຄວາມເຊື່ອໝັ້ນ (Confidence Score) ໃຫ້ເປັນ Edge Property ເພື່ອນຳໄປໃຊ້ໃນການຈັດອັນດັບໃນຂັ້ນຕອນຕໍ່ໄປ

ສຳລັບ Schema, ການບໍ່ຕັ້ງເປົ້າໝາຍໃຫ້ສົມບູນແບບຕັ້ງແຕ່ຕົ້ນ, ແຕ່ໃຫ້ເລືອກກໍລະນີການໃຊ້ງານ (Use Case) ພຽງ 3-5 ຢ່າງເພື່ອສ້າງ MVP Schema ແລະ ຂະຫຍາຍອອກຫຼັງຈາກການກວດສອບແລ້ວ ແມ່ນວິທີການແບບ Iterative ທີ່ໄດ້ຜົນດີໃນການປະຕິບັດງານຕົວຈິງ. ການຄວບຄຸມໃຫ້ປະເພດຂອງ Entity ບໍ່ເກີນ 10 ປະເພດ ແລະ ປະເພດຂອງຄວາມສຳພັນບໍ່ເກີນ 15 ປະເພດ ຈະຊ່ວຍປ້ອງກັນບໍ່ໃຫ້ກຣາຟມີຂະໜາດໃຫຍ່ເກີນໄປໄດ້ງ່າຍຂຶ້ນ.

ກ່ອນທີ່ຈະກ້າວໄປສູ່ການສະກັດຂໍ້ມູນອັດຕະໂນມັດໂດຍ LLM ເຊິ່ງຈະອະທິບາຍໃນພາກຕໍ່ໄປ, ການບັນທຶກຄຳນິຍາມຂອງ Schema ນີ້ໄວ້ຈະຊ່ວຍໃຫ້ການອອກແບບ Prompt ສຳລັບການສະກັດຂໍ້ມູນ ແລະ ເກນການປະເມີນຄຸນນະພາບມີຄວາມຊັດເຈນຍິ່ງຂຶ້ນ.

ການສ້າງກຣາຟໂດຍໃຊ້ LLM ມີຂັ້ນຕອນພື້ນຖານຄື: ການແບ່ງເອກະສານອອກເປັນສ່ວນໆ (Chunking), ຈາກນັ້ນສົ່ງຄຳສັ່ງ (Prompt) ເພື່ອສະກັດເອົາ Entity ແລະ ຄວາມສຳພັນຂອງ Entity ອອກມາພ້ອມກັນໃນແຕ່ລະສ່ວນ.

ສະຫຼຸບຂັ້ນຕອນ

1. ການແບ່ງສ່ວນ (Chunking): ແບ່ງເອກະສານອອກເປັນສ່ວນຍ່ອຍປະມານ 512–1,024 Token.
2. ຄຳສັ່ງສະກັດ Entity (Entity Extraction Prompt): ກຳນົດຮູບແບບຜົນລັອກໃຫ້ເປັນ JSON ເຊັ່ນ: "ຈົ່ງລະບຸລາຍຊື່ບຸກຄົນ, ອົງກອນ, ແລະ ແນວຄວາມຄິດທີ່ປາກົດໃນຂໍ້ຄວາມນີ້".
3. ຄຳສັ່ງສະກັດຄວາມສຳພັນ (Relationship Extraction Prompt): ຫຼັງຈາກໄດ້ Entity ແລ້ວ, ໃຫ້ສັ່ງວ່າ "ຈົ່ງລະບຸຄວາມສຳພັນລະຫວ່າງແຕ່ລະ Entity ໃນຮູບແບບ Triple ຄື (ປະທານ, ກິລິຍາ, ກຳ)".
4. ການປັບໃຫ້ເປັນມາດຕະຖານ ແລະ ການກຳຈັດຂໍ້ມູນຊ້ຳ (Normalization & Deduplication): ໃນກໍລະນີທີ່ Entity ດຽວກັນມີການຂຽນຫຼາຍຮູບແບບ, ໃຫ້ໃຊ້ການປັບຮູບແບບຂໍ້ຄວາມ ຫຼື ໃຊ້ Vector Similarity ເພື່ອລວມຂໍ້ມູນເຂົ້າດ້ວຍກັນ.
5. ການນຳເຂົ້າກຣາຟ (Graph Insertion): ຂຽນ Triple ທີ່ຈັດຮູບແບບແລ້ວລົງໃນ Graph DB (ຈະອະທິບາຍລະອຽດໃນພາກຕໍ່ໄປ).

ສຳລັບຫຼັກການຕັດສິນໃຈໃນການອອກແບບ Prompt, ຖ້າຫາກມີຄຳສັບສະເພາະທາງ (Domain Vocabulary) ຫຼາຍ ແລະ ມີຄວາມສ່ຽງສູງທີ່ຈະສະກັດຂໍ້ມູນຜິດພາດ, ການໃຊ້ວິທີ Few-shot ໂດຍການກຳນົດ Schema ໄວ້ລ່ວງໜ້າແລ້ວຝັງລົງໃນ Prompt ຈະມີປະສິດທິພາບຫຼາຍກວ່າ. ໃນທາງກົງກັນຂ້າມ, ຖ້າຫາກ Domain ມີຄວາມກວ້າງຂວາງ ແລະ ຍາກທີ່ຈະກຳນົດໄວ້ລ່ວງໜ້າ, ການໃຊ້ Zero-shot ເພື່ອສະກັດ Entity ຢ່າງອິດສະຫຼະ ແລ້ວຈຶ່ງນຳມາຈັດກຸ່ມ (Clustering) ໃນຂັ້ນຕອນຫຼັງຈະສາມາດຕອບສະໜອງໄດ້ຢ່າງຍືດຫຍຸ່ນກວ່າ.

ຫຼັງຈາກການສະກັດເອັນທິຕີ (Entity Extraction) ແລະ ການກຳນົດຄວາມສຳພັນສຳເລັດແລ້ວ, ຫຼາຍໜ້າວຽກມັກຈະເກີດຄວາມສັບສົນວ່າ "ຄວນຈະຕັດສິນໃຈເລືອກ Node Label ຫຼື Relation Type ແນວໃດຈຶ່ງຈະເໝາະສົມ".

ໃນການນຳຂໍ້ມູນເຂົ້າສູ່ Neo4j, ການກຳນົດການອອກແບບ Schema ໄວ້ລ່ວງໜ້າຈະສົ່ງຜົນຕໍ່ຄວາມຖືກຕ້ອງໃນການຄົ້ນຫາໃນຂັ້ນຕອນຕໍ່ໄປ. ຈຸດສຳຄັນໃນການອອກແບບມີດັ່ງນີ້:

• Node Label: ໃຫ້ກຳນົດປະເພດຂອງເອັນທິຕີ (ເຊັ່ນ: Person, Organization, Concept ແລະ ອື່ນໆ) ເປັນ Label ແລະ ໃຫ້ບັນຈຸ Chunk ID ຂອງຂໍ້ຄວາມຕົ້ນສະບັບ ຫຼື Embedding Vector ໄວ້ໃນ Property.
• Relation Type: ໃຫ້ໃຊ້ຊື່ທີ່ມີຄວາມໝາຍເຊິ່ງສະກັດມາຈາກວະລີກຳມະ (ເຊັ່ນ: WORKS_AT, RELATED_TO ແລະ ອື່ນໆ) ແລະ ຫຼີກເວັ້ນການໃຊ້ CONNECTED ທີ່ເປັນແບບທົ່ວໄປ.
• Property Design: ໃນ Node ຕ້ອງປະກອບດ້ວຍ source (URI ຂອງເອກະສານຕົ້ນສະບັບ), chunk_id, ແລະ embedding (Float Array) ເພື່ອໃຫ້ສາມາດອ້າງອີງໃນການຄົ້ນຫາແບບ Hybrid Search ໃນຂັ້ນຕອນຕໍ່ໄປໄດ້.

ສຳລັບການນຳຂໍ້ມູນເຂົ້າ, ຍັງມີວິທີການນຳໃຊ້ LLM Knowledge Graph Builder ທີ່ Neo4j ໄດ້ເປີດຕົວ ຫຼື Launch ໄວ້. ເຄື່ອງມືນີ້ໃຫ້ບໍລິການຕັ້ງແຕ່ການເຮັດ Chunking ເອກະສານ, ການສ້າງ Embedding, ການສະກັດເອັນທິຕີ/ຄວາມສຳພັນ, ການຈັດເກັບຂໍ້ມູນລົງໃນກຣາຟ, ໄປຈົນເຖິງການສະຫຼຸບຂໍ້ມູນຊຸມຊົນ ເຊິ່ງທັງໝົດນີ້ເປັນຂະບວນການ ຫຼື Pipeline ດຽວກັນ, ຊ່ວຍໃຫ້ສາມາດຫຼຸດຕົ້ນທຶນໃນການສ້າງລະບົບເບື້ອງຕົ້ນໄດ້.

ຕົວຢ່າງການນຳຂໍ້ມູນເຂົ້າໂດຍໃຊ້ Cypher ມີດັ່ງນີ້:

ການໃຊ້ MERGE ຈະຊ່ວຍປ້ອງກັນການສ້າງ Node ທີ່ມີຊື່ຊ້ຳກັນ ແລະ ສາມາດນຳຂໍ້ມູນເຂົ້າໄດ້ຢ່າງມີປະສິດທິພາບ (Idempotent). ໃນກໍລະນີທີ່ມີການນຳຂໍ້ມູນເຂົ້າຈຳນວນຫຼາຍ, ການໃຊ້ UNWIND ເພື່ອປະມວນຜົນ Array ຂອງ Triple ພ້ອມກັນຈະມີປະສິດທິພາບຫຼາຍກວ່າ.

ສະຫຼຸບ: ການເຊື່ອມຕໍ່ Knowledge Graph ເຂົ້າກັບ Vector Index ຈະຊ່ວຍໃຫ້ສາມາດນຳໃຊ້ການຄົ້ນຫາຄວາມຄ້າຍຄືກັນທາງຄວາມໝາຍ ແລະ ການຄົ້ນຫາຄວາມສຳພັນທາງໂຄງສ້າງໄປພ້ອມໆກັນໄດ້.

ເມື່ອການສ້າງ Graph ສຳເລັດແລ້ວ, ສິ່ງທີ່ເປັນຈຸດສຳຄັນ ຫຼື ແກນຫຼັກ ຕໍ່ໄປຄືການສ້າງ Node Embedding ແລະ ການອອກແບບຂະບວນການ ຫຼື Pipeline ການຄົ້ນຫາແບບປະສົມ (Hybrid Search). ນອກຈາກນີ້, ຕັກກະການ Routing ເພື່ອເລືອກໃຊ້ລະຫວ່າງການຄົ້ນຫາແບບ Vector ແລະ ການຄົ້ນຫາແບບ Graph Traversal ຕາມປະເພດຂອງ Query ກໍມີຄວາມສຳຄັນເຊັ່ນດຽວກັນ.

ການຝັງໂນດ (Node embedding) ຈະໃຫ້ຄວາມແມ່ນຍຳໃນການຄົ້ນຫາທີ່ສະຖຽນກວ່າ ເມື່ອສ້າງຂຶ້ນໂດຍການປັບລະດັບຄວາມລະອຽດໃຫ້ເທົ່າກັນໃນລະດັບໂນດ ແທນທີ່ຈະຝັງທັງເອກະສານລວມກັນ. ນີ້ແມ່ນຍ້ອນວ່າການຝັງເອກະສານມີຫຼາຍບໍລິບົດປະປົນກັນ ເຮັດໃຫ້ຍາກຕໍ່ການຈັບຄູ່ກັບໂນດໃນກຣາຟທາງດ້ານຄວາມໝາຍ.

ຂັ້ນຕອນການສ້າງການຝັງໂນດ

• ການປ່ຽນເປັນຂໍ້ຄວາມ (Textualization): ໃນກໍລະນີຂອງ Entity node ໃຫ້ລວມຊື່ໂນດ, ປະເພດ, ແລະ ຄຸນສົມບັດ (ຄຳອະທິບາຍ, ຊື່ຮອງ, ແລະ ອື່ນໆ) ເຂົ້າດ້ວຍກັນເພື່ອສ້າງເປັນສະຕຣິງຂໍ້ຄວາມດຽວ.
• ການເລືອກແບບຈຳລອງການຝັງ (Embedding model): ເລືອກແບບຈຳລອງການຝັງທີ່ເໝາະສົມກັບໂດເມນຂອງວຽກງານ. ຖ້າຕ້ອງການຮອງຮັບຫຼາຍພາສາ ໃຫ້ບູລິມະສິດແບບຈຳລອງທີ່ຮອງຮັບຫຼາຍພາສາ.
• ການປະມວນຜົນແບບ Batch: ໃນກໍລະນີທີ່ຈຳນວນໂນດມີຂະໜາດໃຫຍ່ ໃຫ້ໃຊ້ Batch API ເພື່ອຈັດການກັບການຈຳກັດອັດຕາ (Rate limit) ແລະ ຕົ້ນທຶນ.

ການຈັດເກັບໃນ Vector Store

• ເວັກເຕີການຝັງທີ່ສ້າງຂຶ້ນຈະຖືກຈັດເກັບໄວ້ໃນ Vector store (ເຊັ່ນ: Pinecone, Weaviate, pgvector, ແລະ ອື່ນໆ) ໂດຍໃຊ້ Node ID ເປັນຄີ (Key).
• ຕ້ອງເພີ່ມ ປະເພດໂນດ, ID ຂອງໂນດທີ່ຢູ່ໃກ້ຄຽງໃນກຣາຟ, ແລະ ການອ້າງອີງເຖິງເອກະສານຕົ້ນສະບັບ ເປັນເມຕາເດຕາ (Metadata) ສະເໝີ.

ຖ້າອອກແບບການຈັບຄູ່ນີ້ຢ່າງລະອຽດ ຈະຊ່ວຍໃຫ້ການຄົ້ນຫາແບບປະສົມ (Hybrid search) ໃນພາຍຫຼັງສາມາດນຳຜົນລັດຈາກຝັ່ງກຣາຟ ແລະ ຝັ່ງເວັກເຕີມາປຽບທຽບກັນໄດ້ງ່າຍຂຶ້ນ.

ການຄົ້ນຫາແບບ Vector ແລະ ການຄົ້ນຫາແບບ Graph ມີຂອບເຂດຄວາມຊຳນານທີ່ແຕກຕ່າງກັນ. ການອອກແບບ "ຂະບວນການ ຫຼື Pipeline ການຄົ້ນຫາແບບປະສົມ (Hybrid Search Pipeline)" ໂດຍການດຳເນີນການທັງສອງຢ່າງໄປພ້ອມໆກັນ ແລະ ລວມ ຫຼື Merge ຜົນລັອກນັ້ນ ຈະຊ່ວຍໃຫ້ສາມາດຕື່ມເຕັມບໍລິບົດທີ່ອາດຈະຕົກຫຼົ່ນໄປຫາກໃຊ້ພຽງວິທີດຽວໄດ້.

ໂຄງສ້າງພື້ນຖານຂອງຂະບວນການ ຫຼື Pipeline ມີ 3 ຂັ້ນຕອນດັ່ງນີ້:

• ຂັ້ນຕອນການດຶງຂໍ້ມູນ (Retrieval Phase): ຮັບ Query, ພ້ອມທັງສົ່ງຄຳສັ່ງຄົ້ນຫາຄວາມຄ້າຍຄືກັນໄປຍັງ Vector Store ແລະ ສົ່ງຄຳສັ່ງ Traversal Query ໄປຍັງ Graph DB ໃນເວລາດຽວກັນ
• ຂັ້ນຕອນການໃຫ້ຄະແນນ (Scoring Phase): ໃຫ້ຄະແນນແບບມີນ້ຳໜັກແກ່ຜົນລັອກແຕ່ລະລາຍການ, ພ້ອມທັງສ້າງລາຍການລວມໂດຍການກຳຈັດ Node ທີ່ຊ້ຳກັນອອກ
• ຂັ້ນຕອນການຈັດອັນດັບ (Ranking Phase): ເລືອກເອົາ N ລາຍການອັນດັບຕົ້ນໆຕາມຄະແນນ ແລະ ຈັດຮູບແບບເພື່ອເປັນບໍລິບົດສຳລັບສົ່ງຕໍ່ໃຫ້ LLM

ໃນການໃຫ້ຄະແນນແບບມີນ້ຳໜັກ, ມຸມມອງຂອງການແບ່ງເງື່ອນໄຂແມ່ນມີຄວາມສຳຄັນ. ສຳລັບ Query ປະເພດນິຍາມ ຫຼື ແນວຄິດ ເຊັ່ນ "ແມ່ນຫຍັງຄື...", ຄວນເພີ່ມຄະແນນຂອງການຄົ້ນຫາແບບ Vector, ສ່ວນ Query ປະເພດຄວາມສຳພັນ ຫຼື ເຫດຜົນ ເຊັ່ນ "A ສົ່ງຂໍ້ມູນຕໍ່ໃຫ້ C ຜ່ານ B ໄດ້ແນວໃດ" ຄວນໃຫ້ຄວາມສຳຄັນກັບຜົນລັອກຂອງການເຮັດ Graph Traversal. ການກຳນົດເງື່ອນໄຂການຕັດສິນໃຈເຫຼົ່ານີ້ໃຫ້ຊັດເຈນໃນຂັ້ນຕອນການ Implement ຈະຊ່ວຍໃຫ້ສາມາດເຊື່ອມຕໍ່ກັບ Logic ການ Routing ໃນພາຍຫຼັງໄດ້ງ່າຍຂຶ້ນ.

ຂໍ້ຄວນລະວັງໃນການ Implement ມີດັ່ງນີ້:

• ການກຳຈັດຂໍ້ມູນຊ້ຳ (Deduplication): ການຄົ້ນຫາແບບ Vector ແລະ Graph ມັກຈະສົ່ງຄືນ Node ຫຼື ເອກະສານດຽວກັນເລື້ອຍໆ, ດັ່ງນັ້ນຈຶ່ງຄວນລວມຂໍ້ມູນໂດຍໃຊ້ Node ID ເປັນ Key ໃນການກວດສອບຄວາມຊ້ຳກ່ອນ
• ການປັບມາດຕະຖານຄະແນນ (Score Normalization): ເນື່ອງຈາກ Cosine Similarity ແລະ ນ້ຳໜັກຂອງ Path ໃນ Graph ມີ Scale ທີ່ແຕກຕ່າງກັນ, ຈຶ່ງຄວນປັບໃຫ້ເທົ່າກັນດ້ວຍວິທີເຊັ່ນ Min-max Normalization ກ່ອນຈະນຳມາລວມຄະແນນແບບມີນ້ຳໜັກ
• ການອອກແບບ Timeout: ການເຮັດ Graph Traversal ອາດຈະຊ້າຂຶ້ນຢູ່ກັບຄວາມເລິກ, ດັ່ງນັ້ນຄວນກຳນົດຈຳນວນ Hop ແລະ ຂີດຈຳກັດຂອງ Timeout ເພື່ອຮັກສາ Latency ໂດຍລວມຂອງລະບົບ

「ຄວນສົ່ງ Query ນີ້ໄປທີ່ການຄົ້ນຫາແບບ Vector ຫຼື Graph?」—— ເມື່ອດຳເນີນການພັດທະນາ, ທ່ານຈະຕ້ອງປະເຊີນກັບການຕັດສິນໃຈໃນຈຸດນີ້ຢ່າງຫຼີກລ່ຽງບໍ່ໄດ້.

Query Routing ແມ່ນເຫດຜົນ (Logic) ໃນການວິເຄາະ Query ທີ່ໄດ້ຮັບຈາກຜູ້ໃຊ້ ແລະ ແບ່ງເສັ້ນທາງການຄົ້ນຫາທີ່ເໝາະສົມທີ່ສຸດ. ຖ້າສົ່ງ Query ທັງໝົດໄປທັງສອງເສັ້ນທາງ, ມັນຈະເຮັດໃຫ້ Latency ແລະ Token cost ຂອງ LLM ເພີ່ມທະວີຂຶ້ນເລື້ອຍໆ ໂດຍບໍ່ຈຳເປັນ, ດັ່ງນັ້ນການແບ່ງເສັ້ນທາງທີ່ເໝາະສົມຈຶ່ງເປັນສິ່ງທີ່ຂາດບໍ່ໄດ້.

ແກນຫຼັກໃນການຕັດສິນໃຈ Routing

ການຈັດປະເພດລັກສະນະຂອງ Query ໂດຍໃຊ້ 2 ແກນຕໍ່ໄປນີ້ແມ່ນວິທີທີ່ນຳໄປໃຊ້ໄດ້ຈິງ:

• ເໝາະສຳລັບການຄົ້ນຫາແບບ Graph: Query ທີ່ຕ້ອງການຄວາມສຳພັນລະຫວ່າງ Entity ຫຼື ການຄາດຄະເນຫຼາຍຂັ້ນ (Multi-hop reasoning) ເຊັ່ນ: 「ຄວາມສຳພັນລະຫວ່າງ A ແລະ B ແມ່ນຫຍັງ?」, 「ສິ່ງທີ່ເຊື່ອມຕໍ່ກັບ D ໂດຍຜ່ານ C ແມ່ນຫຍັງ?」
• ເໝາະສຳລັບການຄົ້ນຫາແບບ Vector: Query ທີ່ພຽງແຕ່ຕ້ອງການດຶງຂໍ້ມູນເອກະສານໂດຍອີງໃສ່ຄວາມຄ້າຍຄືກັນທາງຄວາມໝາຍ (Semantic similarity) ເຊັ່ນ: 「ອະທິບາຍກ່ຽວກັບ...」, 「ຊອກຫາເອກະສານທີ່ກ່ຽວຂ້ອງກັບ...」

ຮູບແບບການຈັດຕັ້ງປະຕິບັດ (Implementation Patterns)

ການຈັດຕັ້ງປະຕິບັດ Logic ຂອງ Routing ມີ 2 ແນວທາງຫຼັກດັ່ງນີ້:

1. ການຈັດປະເພດ Query ໂດຍ LLM: ສົ່ງ Query ໄປໃຫ້ LLM ເພື່ອໃຫ້ມັນສົ່ງຄືນ Label ຢ່າງໃດຢ່າງໜຶ່ງລະຫວ່າງ graph / vector / hybrid. ມີຄວາມແມ່ນຍຳສູງ ແຕ່ຈະເກີດ Latency ໃນຂັ້ນຕອນການຈັດປະເພດເອງ.
2. ການຈັດປະເພດແບບ Rule-based: ກຳນົດເສັ້ນທາງ Routing ໂດຍໃຊ້ຮູບແບບ Keyword ຫຼື Regular expression ເຊັ່ນ: 「ໃຜ」, 「ເສັ້ນທາງໃດ」, 「ຄວາມສຳພັນລະຫວ່າງ... ແລະ...」. ມີຄວາມໄວສູງ ແຕ່ບໍ່ສາມາດຮອງຮັບການປ່ຽນແປງຂອງຮູບແບບພາສາໄດ້ດີ.

ໃນການເຮັດວຽກຕົວຈິງ, ການອອກແບບທີ່ມີຄວາມສົມດຸນລະຫວ່າງຄວາມແມ່ນຍຳ ແລະ ຕົ້ນທຶນ ຄືການໃຊ້ໂຄງສ້າງ 2 ຂັ້ນຕອນ: ເລີ່ມຈາກການໃຊ້ Rule-based ເພື່ອຈັດການກັບຮູບແບບທີ່ຊັດເຈນ, ແລະໃຊ້ LLM ເປັນທາງເລືອກສຳຮອງ (Fallback) ສະເພາະກັບ Query ທີ່ການຕັດສິນໃຈຍັງບໍ່ຊັດເຈນ. ສຳລັບ Query ທີ່ບໍ່ແນ່ໃຈ, ໃຫ້ສົ່ງໄປເປັນ hybrid ເພື່ອໃຫ້ຜ່ານທັງສອງເສັ້ນທາງ ແລ້ວລວມ ຫຼື Merge ຜົນລັອກທີ່ໄດ້ຮັບ ເພື່ອປ້ອງກັນບໍ່ໃຫ້ຂໍ້ມູນຕົກຫຼົ່ນ.

ສະຫຼຸບ: ການນຳເອົາບໍລິບົດ (Context) ທີ່ເກັບກຳໄດ້ຈາກການເຮັດ Graph Traversal ມາຈັດໂຄງສ້າງເພື່ອສົ່ງຕໍ່ໃຫ້ LLM ຈະຊ່ວຍເພີ່ມຄວາມຖືກຕ້ອງໃນການຕອບຄຳຖາມທີ່ຊັບຊ້ອນໄດ້ຢ່າງຫຼວງຫຼາຍ.

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

ໃນການເກັບກຳບໍລິບົດ (Context), ມັກຈະມີການດຶງຂໍ້ມູນພຽງແຕ່ໂນດ (Node) ໃນໄລຍະ 1 ຮອບເທົ່ານັ້ນ, ແຕ່ການຕິດຕາມໄປເຖິງ 2-3 ຮອບຈະຊ່ວຍໃຫ້ສາມາດນຳເອົາຕ່ອງໂສ້ຄວາມສຳພັນທີ່ການຄົ້ນຫາແບບ Vector ປົກກະຕິບໍ່ສາມາດກວດພົບໄດ້ ມາໃຊ້ໃນການຕອບຄຳຖາມ.

ຂັ້ນຕອນພື້ນຖານຂອງການເຮັດ Traversal ມີດັ່ງນີ້:

• ການລະບຸໂນດຕົ້ນທາງ: ໃຊ້ໂນດທີ່ມີຄວາມຄ້າຍຄືກັນທີ່ໄດ້ຈາກການຄົ້ນຫາແບບ Vector ເປັນຈຸດເລີ່ມຕົ້ນ
• ການຄວບຄຸມຄວາມເລິກ: ກຳນົດຂີດຈຳກັດຂອງຄວາມເລິກ ເຊັ່ນ: MATCH (n)-[r*1..3]->(m) ເພື່ອປ້ອງກັນການຂະຫຍາຍຕົວແບບບໍ່ສິ້ນສຸດ
• ການກັ່ນຕອງປະເພດຄວາມສຳພັນ: ແທນທີ່ຈະຕິດຕາມທຸກ Edge, ໃຫ້ຈຳກັດສະເພາະປະເພດຄວາມສຳພັນທີ່ກ່ຽວຂ້ອງກັບ Query (ຕົວຢ່າງ: AUTHORED_BY, BELONGS_TO, REFERENCES)
• ການໃຫ້ຄະແນນ ແລະ ການຕັດອອກ (Pruning): ເນື່ອງຈາກຄວາມກ່ຽວຂ້ອງມີແນວໂນ້ມຫຼຸດລົງເມື່ອຈຳນວນຮອບເພີ່ມຂຶ້ນ, ໃຫ້ໃຊ້ການຫຼຸດຄະແນນຕາມໄລຍະຫ່າງເພື່ອຄວບຄຸມປະລິມານຂອງບໍລິບົດ

ຕົວຢ່າງ Cypher Query ມີດັ່ງນີ້:

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

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

ໂດຍທົ່ວໄປແລ້ວ, Prompt Template ຈະປະກອບດ້ວຍ 3 ພາກສ່ວນຫຼັກ ດັ່ງນີ້:

• [Graph Context]: ຂໍ້ມູນ Entity ແລະ Relation ທີ່ໄດ້ຈາກການເຮັດ Graph Traversal (ເຊັ່ນ: ຜົນລວມຈາກ Cypher Query)
• [Vector Search Results]: ຂໍ້ຄວາມໃນ Chunk ທີ່ມີຄວາມຄ້າຍຄືກັນສູງສຸດ
• [User Query]: ຄຳຖາມຕົ້ນສະບັບ

ການຈັດລຽງຕາມລຳດັບນີ້ ຈະຊ່ວຍໃຫ້ LLM ອ່ານຂໍ້ມູນຄວາມສຳພັນທີ່ມີໂຄງສ້າງກ່ອນ, ຈາກນັ້ນຈຶ່ງອ້າງອີງຂໍ້ມູນພື້ນຖານຈາກຂໍ້ຄວາມມາເປັນສ່ວນເສີມ.

ນອກຈາກນີ້, ຍັງຈຳເປັນຕ້ອງເລືອກໃຊ້ໃຫ້ເໝາະສົມກັບປະລິມານຂອງບໍລິບົດ. ຄວນມີຫຼັກການຕັດສິນໃຈຄື: ຖ້າຜົນລວມຈາກ Graph ມີຫຼາຍ ໃຫ້ປ່ຽນຂໍ້ມູນ Relation ເປັນລາຍການແບບ Bullet point ເພື່ອສະຫຼຸບ, ແລະຖ້າຜົນລວມຈາກ Vector Search ມີໜ້ອຍ ໃຫ້ຂະຫຍາຍຂໍ້ມູນ Property ຈາກຝັ່ງ Graph ເພື່ອເປັນຂໍ້ຄວາມເສີມ.

ຕົວຢ່າງຂອງ Template ມີດັ່ງນີ້:

ເຖິງແມ່ນວ່າຈະສາມາດເກັບກຳບໍລິບົດ (Context) ຈຳນວນມະຫາສານໄດ້ດ້ວຍການເຮັດ Graph Traversal ແລະ Vector Search, ແຕ່ວິສະວະກອນຫຼາຍຄົນກໍຄົງເຄີຍມີປະສົບການທີ່ຮູ້ສຶກວ່າ "ຖ້າບໍ່ປັບປຸງໃຫ້ເໝາະສົມວ່າຈະສົ່ງຫຍັງໃຫ້ LLM ແລະສົ່ງໃນລຳດັບໃດ" ຄຸນນະພາບຂອງຄຳຕອບກໍຈະບໍ່ເພີ່ມຂຶ້ນຕາມທີ່ຄາດຫວັງໄວ້.

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

• ການຈັດລຳດັບຄວາມສຳຄັນຂອງບໍລິບົດ: ຂໍ້ມູນ Node ແລະ Edge ທີ່ໄດ້ມາຈາກ Graph Traversal ຄວນຖືກຈັດລຽງຕາມຄະແນນຄວາມກ່ຽວຂ້ອງກັບ Query ຈາກຫຼາຍໄປຫາໜ້ອຍ (Descending order) ແລະ ໃຫ້ລວມເອົາສະເພາະຂໍ້ມູນສ່ວນເທິງເຂົ້າໄປໃນ Prompt ເທົ່ານັ້ນ.
• ການລະບຸການແບ່ງສ່ວນໂຄງສ້າງໃຫ້ຊັດເຈນ: ຜົນການຄົ້ນຫາແບບ Vector ແລະ ຂໍ້ມູນຄວາມສຳພັນທີ່ມາຈາກ Graph ຄວນຖືກນຳສະເໜີໂດຍການແບ່ງສ່ວນພາຍໃນ Prompt (ຕົວຢ່າງ: ## ເອກະສານທີ່ກ່ຽວຂ້ອງ / ## ຄວາມສຳພັນຂອງ Entity)
• ການຈັດການງົບປະມານ Token: ເພື່ອບໍ່ໃຫ້ເກີນຂີດຈຳກັດຂອງ Context Window, ຄວນກຳນົດຂີດຈຳກັດການຈັດສັນ Token ໃຫ້ແຕ່ລະແຫຼ່ງຂໍ້ມູນໄວ້ລ່ວງໜ້າ.

ເພື່ອຍົກລະດັບຄຸນນະພາບຂອງຄຳຕອບໃຫ້ສູງຂຶ້ນໄປອີກ, ການນຳໃຊ້ Chain-of-Thought (CoT) Prompting ແມ່ນມີປະສິດທິຜົນຫຼາຍ. ການເພີ່ມຄຳສັ່ງທີ່ວ່າ "ໃຫ້ລະບຸ Entity ທີ່ກ່ຽວຂ້ອງກ່ອນ, ຈາກນັ້ນສະແດງຂັ້ນຕອນການຄິດວິເຄາະ ແລ້ວຈຶ່ງສະແດງຄຳຕອບສຸດທ້າຍ" ມັກຈະເຮັດໃຫ້ຄວາມຖືກຕ້ອງຂອງການຄິດວິເຄາະແບບຫຼາຍຂັ້ນຕອນ (Multi-hop reasoning) ດີຂຶ້ນ.

ນອກຈາກນີ້, ການນຳໃຊ້ ຮູບແບບການຕອບແບບມີການອ້າງອີງ ໂດຍການລວມເອົາ Graph Path ຫຼື Source Node ທີ່ໃຊ້ໃນການຕອບເຂົ້າໄປໃນຜົນລັອບນັ້ນ ຈະຊ່ວຍໃຫ້ການກວດສອບ Hallucination ແລະ ການຢືນຢັນຄວາມໜ້າເຊື່ອຖືເຮັດໄດ້ງ່າຍຂຶ້ນ.

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

ການຂະຫຍາຍຕົວຂອງກຣາຟ (Graph) ແລະ ຄວາມຂັດແຍ່ງຂອງຜົນລັອກຈາກການຄົ້ນຫາແບບ Vector-Graph ແມ່ນສອງບັນຫາໃຫຍ່ທີ່ມັກຈະປະກົດໃຫ້ເຫັນໄດ້ຊັດເຈນໂດຍສະເພາະໃນສະພາບແວດລ້ອມການໃຊ້ງານຈິງ (Production). ບົດຄວາມນີ້ຈະອະທິບາຍເຖິງສາເຫດ ແລະ ວິທີການຫຼີກລ່ຽງບັນຫາດັ່ງກ່າວ.

ການຂະຫຍາຍຕົວຂອງກຣາຟ (Graph) ທີ່ຫຼາຍເກີນໄປ ເກີດຂຶ້ນຈາກການສະກັດເອົາ Entity ໂດຍບໍ່ມີການຄັດກອງ. ເມື່ອຈຳນວນ Node ແລະ Relation ເພີ່ມຂຶ້ນຢ່າງບໍ່ມີທິດທາງ ຈະເຮັດໃຫ້ພື້ນທີ່ການຄົ້ນຫາຂອງ Graph Traversal ຂະຫຍາຍຕົວ ແລະ ມີ Context ທີ່ບໍ່ກ່ຽວຂ້ອງປົນເຂົ້າມາເປັນຈຳນວນຫຼາຍ ຈົນສົ່ງຜົນໃຫ້ຄຸນນະພາບຂອງຄຳຕອບຫຼຸດລົງ.

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

ເມື່ອກຣາຟຂະຫຍາຍຕົວຫຼາຍເກີນໄປ ບໍ່ພຽງແຕ່ຈະເຮັດໃຫ້ຕົ້ນທຶນການປະມວນຜົນ Cypher Query ເພີ່ມຂຶ້ນເທົ່ານັ້ນ ແຕ່ການຄົ້ນຫາ Node ໃກ້ຄຽງຈາກ Seed Node ທີ່ໄດ້ມາຈາກການຄົ້ນຫາແບບ Vector ຍັງຈະດຶງເອົາ Node ທີ່ບໍ່ກ່ຽວຂ້ອງເຂົ້າມາເປັນຈຳນວນຫຼາຍ. ສົ່ງຜົນໃຫ້ Context ທີ່ສົ່ງຂໍ້ມູນຕໍ່ໃຫ້ LLM ເຕັມໄປດ້ວຍສິ່ງລົບກວນ (Noise) ແລະ ເຮັດໃຫ້ຄວາມສອດຄ່ອງຂອງຄຳຕອບຫຼຸດລົງ.

ວິທີການຫຼີກລ່ຽງແມ່ນ ໃນຂັ້ນຕອນການອອກແບບ Schema ຄວນຈຳກັດປະເພດຂອງ Entity ໃຫ້ເຫຼືອພຽງແຕ່ສິ່ງທີ່ຈຳເປັນຕໍ່ Domain ເທົ່ານັ້ນ ແລະ ຫຼີກລ່ຽງການໃຊ້ປະເພດທົ່ວໄປໃຫ້ຫຼາຍທີ່ສຸດ. ພ້ອມກັນນັ້ນ, ການສ້າງຂະບວນການ ຫຼື Pipeline ຂອງການແກ້ໄຂບັນຫາ Entity (Entity Resolution) ເພື່ອລວມ ຫຼື Merge ຊື່ທີ່ຂຽນຕ່າງກັນໃຫ້ເປັນອັນດຽວຕັ້ງແຕ່ຂັ້ນຕອນການສ້າງ ແມ່ນມີຄວາມສຳຄັນຫຼາຍ. ສຳລັບ Node ທີ່ຕ້ອງການຄວາມທັນສະໄໝ ຄວນກຳນົດນະໂຍບາຍ TTL (Time To Live) ເພື່ອລຶບຂໍ້ມູນທີ່ບໍ່ຈຳເປັນອອກເປັນໄລຍະ (Pruning) ແລະ ການນຳໃຊ້ Community Detection ເພື່ອຈຳກັດຂອບເຂດການຄົ້ນຫາໃຫ້ຢູ່ໃນລະດັບ Subgraph ທີ່ມີຄວາມໜາແໜ້ນສູງ ຈະຊ່ວຍຫຼຸດຜ່ອນການປົນເປື້ອນຂອງສິ່ງລົບກວນໄດ້.

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

ສະຖານະການທີ່ເກີດຄວາມຂັດແຍ່ງນີ້ສາມາດແບ່ງອອກໄດ້ເປັນ 3 ປະເພດໃຫຍ່ໆ: ປະເພດທີໜຶ່ງ ຄືຄວາມບໍ່ສອດຄ່ອງຂອງຄວາມສົດໃໝ່ (Freshness), ເຊິ່ງເກີດຈາກຄວາມຖີ່ໃນການອັບເດດ Vector Index ຕ່ຳກວ່າ Graph ເຮັດໃຫ້ມີຂໍ້ມູນເກົ່າປົນເຂົ້າມາ. ປະເພດທີສອງ ຄືຄວາມບໍ່ສອດຄ່ອງຂອງລະດັບຄວາມລະອຽດ (Granularity), ເນື່ອງຈາກການຄົ້ນຫາແບບ Vector ໃຫ້ຜົນລັພເປັນໜ່ວຍ Chunk ແລະ ການຄົ້ນຫາແບບ Graph ໃຫ້ຜົນລັພເປັນໜ່ວຍ Entity ເຮັດໃຫ້ລະດັບຄວາມເປັນນາມມະທຳບໍ່ສອດຄ່ອງກັນ. ປະເພດທີສາມ ຄືຄວາມບໍ່ເຂົ້າກັນຂອງຄະແນນ (Score), ເນື່ອງຈາກ Cosine Similarity ແລະ ນ້ຳໜັກຂອງເສັ້ນທາງໃນ Graph ບໍ່ສາມາດນຳມາປຽບທຽບກັນໂດຍກົງໄດ້ ເຮັດໃຫ້ການລວມອັນດັບ (Ranking) ເປັນເລື່ອງຍາກ.

ແນວທາງພື້ນຖານໃນການແກ້ໄຂຄື ການລະບຸ "ລຳດັບຄວາມສຳຄັນຂອງຄວາມໜ້າເຊື່ອຖື" ໃຫ້ຊັດເຈນກ່ອນທີ່ຈະ ລວມ ຫຼື Merge ຜົນລັພ. ສຳລັບຄຳຖາມທີ່ຖາມເຖິງຊື່ສະເພາະ, ຕົວເລກ, ຫຼື ຄວາມສຳພັນລະຫວ່າງ Entity ຄວນໃຫ້ຄວາມສຳຄັນກັບຜົນລັພຈາກການຄົ້ນຫາແບບ Graph, ແລະ ສຳລັບຄຳຖາມທີ່ຄວາມຄ້າຍຄືກັນທາງຄວາມໝາຍ ແລະ ຄວາມເຂົ້າໃຈໃນບໍລິບົດມີຄວາມສຳຄັນ ຄວນໃຫ້ຄວາມສຳຄັນກັບການຄົ້ນຫາແບບ Vector; ການກຳນົດເງື່ອນໄຂແຍກ (Conditional Branching) ໄວ້ໃນຊັ້ນ Query Routing ຈະຊ່ວຍຫຼຸດຜ່ອນຄວາມຂັດແຍ່ງລົງໄດ້ຢ່າງຫຼວງຫຼາຍ.

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

ສະຫຼຸບ: Knowledge Graph × RAG ແມ່ນສະຖາປັດຕະຍະກຳທີ່ລວມເອົາການຄົ້ນຫາແບບ Vector ເຊິ່ງຈັບເອົາ "ຄວາມໃກ້ຄຽງທາງຄວາມໝາຍ" ເຂົ້າກັບໂຄງສ້າງກຣາຟທີ່ຈັບເອົາ "ຕ່ອງໂສ້ຂອງຄວາມສຳພັນ" ເພື່ອຕອບຄຳຖາມທີ່ຊັບຊ້ອນແບບຫຼາຍຂັ້ນຕອນ (Multi-hop).

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

• ການນຳໃຊ້ທີ່ແຕກຕ່າງກັນແມ່ນພື້ນຖານ: ແບ່ງການເຮັດວຽກໂດຍໃຊ້ Vector Search ສຳລັບຄຳຖາມປະເພດນິຍາມ ຫຼື ແນວຄວາມຄິດ, ແລະໃຊ້ Graph Traversal ສຳລັບຄຳຖາມປະເພດຄວາມສຳພັນ ຫຼື ຫຼາຍຂັ້ນຕອນ.
• ຄຸນນະພາບຂຶ້ນຢູ່ກັບຂໍ້ມູນ ແລະ ການອອກແບບ: ຈຳກັດປະເພດຂອງ Entity, ເຮັດໃຫ້ຮູບແບບການຂຽນທີ່ແຕກຕ່າງກັນເປັນມາດຕະຖານ (Normalize), ແລະ ສ້າງ Schema ໃຫ້ມີຂະໜາດນ້ອຍເພື່ອເຮັດຊ້ຳ (Iterate).
• ການເຊື່ອມໂຍງມີ Routing ແລະ ການເຮັດໃຫ້ເປັນມາດຕະຖານເປັນກຸນແຈສຳຄັນ: ປັບຄະແນນໃຫ້ເທົ່າກັນ, ລະບຸແຫຼ່ງທີ່ມາໃຫ້ຊັດເຈນ, ແລະ ກຳນົດລຳດັບຄວາມສຳຄັນໃນກໍລະນີທີ່ຂໍ້ມູນຂັດແຍ່ງກັນໄວ້ລ່ວງໜ້າ.

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

ນີ້ແມ່ນບົດສະຫຼຸບຄຳຖາມທີ່ພົບເລື້ອຍໃນການນຳ Knowledge Graph × RAG ມາໃຊ້ງານ.

Q1. ຄວນເລືອກໃຊ້ Knowledge Graph × RAG ກັບ RAG ທົ່ວໄປແນວໃດ?

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

Q2. ຈຳເປັນຕ້ອງໃຊ້ທັງ Graph DB ແລະ Vector DB ບໍ? ສາມາດລວມໄວ້ໃນບ່ອນດຽວໄດ້ຫຼືບໍ່?

ໂດຍຫຼັກການແລ້ວແມ່ນໃຫ້ໃຊ້ຄູ່ກັນ, ເນື່ອງຈາກ Graph DB ມີຄວາມໂດດເດັ່ນໃນການຄົ້ນຫາຄວາມສຳພັນ, ສ່ວນ Vector DB ມີຄວາມໂດດເດັ່ນໃນການຄົ້ນຫາຄວາມໃກ້ຄຽງທາງຄວາມໝາຍ (Semantic Search). ຢ່າງໃດກໍຕາມ, ຍັງມີທາງເລືອກໃນການໃຊ້ໂຄງສ້າງພື້ນຖານ ຫຼື Infrastructure ທີ່ອີງໃສ່ RDB ເຊັ່ນ pgvector, ຫຼືການໃຊ້ຟັງຊັນ Vector Index ຂອງຝັ່ງ Graph DB ເພື່ອລວມເຂົ້າເປັນຖານດຽວກັນ. ຖ້າຕ້ອງການຫຼຸດພາລະໃນການດຳເນີນງານ, ການເລີ່ມຕົ້ນຈາກແບບລວມສູນກ່ອນ ແລ້ວຈຶ່ງຕັດສິນໃຈແຍກອອກເມື່ອຄວາມຕ້ອງການດ້ານປະສິດທິພາບເພີ່ມສູງຂຶ້ນ ກໍເປັນທາງເລືອກທີ່ເປັນໄປໄດ້.

Q3. ສາມາດເພີ່ມ Knowledge Graph ເຂົ້າໃນລະບົບ RAG ທີ່ມີຢູ່ແລ້ວໃນພາຍຫຼັງໄດ້ບໍ?

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