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

ການໃຊ້ພຽງແຕ່ RAG ມາດຕະຖານ ຫຼື Context Window ຢ່າງດຽວນັ້ນ ເປັນເລື່ອງຍາກທີ່ຈະຈື່ຈຳກະແສວຽກງານທີ່ດຳເນີນໄປຕະຫຼອດຫຼາຍອາທິດ ຫຼື ຫຼາຍເດືອນ. ໃນບົດຄວາມນີ້, ພວກເຮົາຈະອະທິບາຍຮູບແບບການອອກແບບທີ່ເຮັດໃຫ້ສາມາດຮັກສາບໍລິບົດໃນໄລຍະຍາວໄດ້ ໂດຍການນຳເອົາ MemGPT ຈາກ UC Berkeley ແລະ GraphRAG ຈາກ Microsoft Research ມາປະສົມປະສານກັນ.

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

ເມື່ອເຊດຊັນສິ້ນສຸດລົງ, AI agent ຈະລືມທຸກຢ່າງ—ທ່ານເຄີຍຮູ້ສຶກກັງວົນກ່ຽວກັບການນຳໄປໃຊ້ໃນວຽກງານເມື່ອໄດ້ຍິນແບບນັ້ນບໍ?

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

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

Context Window ແມ່ນຂີດຈຳກັດຂອງຂໍ້ຄວາມທີ່ LLM ສາມາດອ້າງອີງໄດ້ໃນການອະນຸມານຄັ້ງດຽວ. ອີງຕາມເອກະສານ MemGPT (ຕາຕະລາງທີ 1), llama-2 ມີຂີດຈຳກັດຢູ່ທີ່ 4,000 token ແລະ GPT ມີຂີດຈຳກັດຢູ່ທີ່ປະມານ 8,000 token ໃນເວລານັ້ນ, ເຊິ່ງຂໍ້ມູນທີ່ເກີນກວ່ານີ້ຈະບໍ່ສາມາດອ້າງອີງໄດ້ພາຍໃນເຊສຊັນນັ້ນ.

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

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

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

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

ໃນສະຖານະການດັ່ງຕໍ່ໄປນີ້, ການອອກແບບຄວາມຈຳໄລຍະຍາວຈະມີຄວາມສຳຄັນເປັນພິເສດ:

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

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

ສິ່ງທີ່ຄືກັນໃນສະຖານະການວຽກງານເຫຼົ່ານີ້ຄື: "ບໍລິບົດໃນອະດີດສົ່ງຜົນໂດຍກົງຕໍ່ຄຸນນະພາບຂອງການຕັດສິນໃຈໃນປັດຈຸບັນ".

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

ຄວາມຈຳທີ່ Agent ຄວນຮັກສາໄວ້ ສາມາດແບ່ງອອກໄດ້ເປັນ 3 ປະເພດໃຫຍ່ໆ:

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

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

• ຄວາມຈຳຂັ້ນຕອນ (Procedural Memory): ຮູບແບບຂອງຂັ້ນຕອນການປະຕິບັດວຽກງານ ຫຼື Workflow. ເປັນຄວາມຮູ້ທີ່ເປັນແບບແຜນຂອງການປະຕິບັດງານທີ່ເຮັດຊ້ຳໆ ເຊັ່ນ "ຂັ້ນຕອນການອະນຸມັດແມ່ນ ຫົວໜ້າ → ຝ່າຍກົດໝາຍ → ຝ່າຍບັນຊີ" ຫຼື "ເມື່ອເກີດຂໍ້ຜິດພາດ ໃຫ້ກວດສອບ Log ກ່ອນແລ້ວຈຶ່ງລອງໃໝ່".

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

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

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

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

ບັນຫາ ຈຸດສຳຄັນ ຫຼື ແກນຫຼັກ ຂອງ RAG ມາດຕະຖານ ຄືການທີ່ການໃຫ້ຄະແນນ (Scoring) ເບິ່ງພຽງແຕ່ "ຄວາມຄ້າຍຄືກັນໃນລະດັບ Chunk" ເທົ່ານັ້ນ. ເນື່ອງຈາກແຕ່ລະ Chunk ຖືກປະເມີນຢ່າງເປັນອິດສະຫຼະ ຈຶ່ງບໍ່ສາມາດສະແດງເຖິງຄວາມສຳພັນທາງເຫດຜົນ ຫຼື ລຳດັບເວລາທີ່ກວມເອົາຫຼາຍ Session ໄດ້. ຄວາມສຳພັນທາງເວລາ ເຊັ່ນ "ແນວທາງທີ່ຕົກລົງກັນໃນການປະຊຸມອາທິດແລ້ວນີ້" ຫຼື "ຂັ້ນຕອນການອະນຸມັດທີ່ປ່ຽນແປງໄປເມື່ອຫຼາຍເດືອນກ່ອນ" ມັກຈະບໍ່ປາກົດຢູ່ໃນບໍລິເວນໃກ້ຄຽງກັນໃນ Vector Space ເຮັດໃຫ້ເກີດການຂາດຕອນຂອງບໍລິບົດ (Context). ນອກຈາກນີ້, ຖ້າພະຍາຍາມດຶງເອົາ Chunk ທີ່ກ່ຽວຂ້ອງມາຈຳນວນຫຼາຍ ກໍຈະເຮັດໃຫ້ Context Window ຂອງ LLM ເຕັມຢ່າງວ່ອງໄວ. ດັ່ງທີ່ບົດຄວາມວິໄຈ MemGPT (arXiv: 2310.08560) ໄດ້ຊີ້ໃຫ້ເຫັນວ່າ ຄວາມຍາວຂອງ Context ໃນໂມເດວຫຼັກໆໃນເວລານັ້ນມີຈຳກັດພຽງແຕ່ຫຼັກພັນ Token ເທົ່ານັ້ນ (ຕົວຢ່າງ: llama‑1 = 2,000 tokens, llama‑2 = 4,000 tokens, gpt‑3.5‑turbo = 4,000 tokens, gpt‑4 = 8,000 tokens) ເຮັດໃຫ້ການອອກແບບທີ່ສົ່ງ Chunk ຈຳນວນຫຼາຍໄປພ້ອມກັນນັ້ນບໍ່ສາມາດປະຕິບັດໄດ້ຈິງ.

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

ເມື່ອບັນທຶກການເຮັດວຽກ (Business log) ມີຈຳນວນຫຼາຍເຖິງຫຼາຍໝື່ນລາຍການ, ຄວາມແມ່ນຍຳຂອງການຄົ້ນຫາແບບ Vector ມັກຈະຫຼຸດລົງໄວກວ່າທີ່ຄາດໄວ້.

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

ເມື່ອຈັດລະບຽບແຫຼ່ງທີ່ມາຂອງສິ່ງລົບກວນ (Noise) ທີ່ເປັນເອກະລັກຂອງບັນທຶກຂະໜາດໃຫຍ່, ສາມາດສະຫຼຸບໄດ້ດັ່ງນີ້:

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

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

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

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

ທັງສອງຢ່າງນີ້ຕ່າງກໍຊ່ວຍເສີມຈຸດອ່ອນຂອງກັນແລະກັນ.

ຂອບເຂດທີ່ MemGPT ເຂົ້າມາເສີມ:

• ສະໜອງກົນໄກໃນການຍົກຍ້າຍ ແລະ ເອີ້ນຂໍ້ມູນທີ່ເກີນຂີດຈຳກັດທາງກາຍະພາບຂອງ Context Window (ໃນຕາຕະລາງທີ 1 ຂອງບົດວິໄຈລະບຸວ່າ GPT-4 ມີ 8,000 tokens) ໄປໄວ້ໃນບ່ອນຈັດເກັບຂໍ້ມູນພາຍນອກ.
• ມີຈຸດແຂງໃນການຮັກສາ "ຄວາມຊົງຈຳແບບເຫດການ (Episodic Memory)" ຂ້າມເຊດຊັນ.
• Agent ສາມາດຄວບຄຸມຈັງຫວະການອ່ານ ແລະ ຂຽນຄວາມຊົງຈຳໄດ້ດ້ວຍຕົນເອງຜ່ານ Function Call.

ຂອບເຂດທີ່ GraphRAG ເຂົ້າມາເສີມ:

• ຮັກສາ Entity ແລະ Relation ຈາກເອກະສານທຸລະກິດຈຳນວນມະຫາສານ ໄວ້ໃນຮູບແບບໂຄງສ້າງກຣາຟ ເພື່ອໃຫ້ຮູ້ວ່າ "ໃຜ, ເຮັດຫຍັງ, ກ່ຽວຂ້ອງກັບໂຄງການໃດ".
• ສາມາດຄົ້ນຫາແບບຂ້າມເອກະສານທີ່ Vector Search ບໍ່ສາມາດກວດຈັບໄດ້ ໂດຍຜ່ານການສອບຖາມແບບກຣາຟ (Graph Query).
• GraphRAG ເຊິ່ງ Microsoft Research ໄດ້ເປີດຕົວ ຫຼື Launch ໃນເດືອນກຸມພາ 2024, ມີລາຍງານວ່າເຖິງແມ່ນວ່າການສະກັດກຣາຟຈະກິນຕົ້ນທຶນໃນການສ້າງດັດຊະນີໄປເຖິງ 75%, ແຕ່ມັນກໍຊ່ວຍເພີ່ມຄວາມຖືກຕ້ອງໃນການຕອບຄຳຖາມທີ່ມີການອະນຸມານທີ່ຊັບຊ້ອນໄດ້ຢ່າງຫຼວງຫຼາຍ.

ຜົນປະໂຫຍດທີ່ເກີດຈາກການນຳມາປະສົມປະສານກັນ:

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

ສະຫຼຸບ: MemGPT ມີການອອກແບບທີ່ຈຳລອງລຳດັບຊັ້ນຂອງໜ່ວຍຄວາມຈຳໃນ OS ເພື່ອບັນລຸການມີໜ່ວຍຄວາມຈຳໄລຍະຍາວທີ່ເກີນກວ່າຂໍ້ຈຳກັດດ້ານບໍລິບົດ (Context) ຂອງ LLM.

MemGPT ແມ່ນເຟຣມເວີກທີ່ທີມວິໄຈຈາກ UC Berkeley ແລະ ອື່ນໆ ໄດ້ ເປີດຕົວ ຫຼື Launch ໃນປີ 2023 ໂດຍມີການຈັດການໜ່ວຍຄວາມຈຳດ້ວຍການແຍກບໍລິບົດຫຼັກ (Main context) ແລະ ບ່ອນຈັດເກັບຂໍ້ມູນພາຍນອກ (External storage) ອອກຈາກກັນ. ໃນຫົວຂໍ້ H3 ຕໍ່ໄປນີ້, ພວກເຮົາຈະອະທິບາຍກ່ຽວກັບໂຄງສ້າງຂອງສະຖາປັດຕະຍະກຳ, ການຕັ້ງຄ່າເບື້ອງຕົ້ນ ແລະ ຂັ້ນຕອນການຄວບຄຸມການຮຽກໃຊ້ຟັງຊັນ (Function call) ຕາມລຳດັບ.

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

ໃນບົດວິໄຈຂອງ MemGPT (UC Berkeley ແລະຄະນະ, ເດືອນຕຸລາ 2023) ໄດ້ສະເໜີໂຄງສ້າງທີ່ປຽບທຽບ LLM ໃຫ້ເປັນຄືກັບ OS, ໂດຍຖືເອົາ Context Window ເປັນ "ໜ່ວຍຄວາມຈຳຫຼັກ (RAM)" ແລະ ບ່ອນຈັດເກັບຂໍ້ມູນພາຍນອກເປັນ "ດິດ (Disk)". ອີງຕາມຕາຕະລາງປຽບທຽບໃນບົດວິໄຈ, ຄວາມຍາວຂອງ Context ໃນໂມເດວຫຼັກໆໃນເວລານັ້ນມີພຽງແຕ່ 2,000 tokens ສຳລັບ llama-1 ແລະ 8,000 tokens ສຳລັບ GPT-4 ເທົ່ານັ້ນ, ເຊິ່ງການບັນຈຸບໍລິບົດຂອງວຽກງານໄລຍະຍາວໃຫ້ຢູ່ໃນ Window ດຽວແມ່ນມີຄວາມຫຍຸ້ງຍາກໃນດ້ານໂຄງສ້າງ.

ອົງປະກອບຫຼັກຂອງສະຖາປັດຕະຍະກຳມີ 3 ຊັ້ນ ດັ່ງນີ້:

• Main Context (In-Context Storage): ພື້ນທີ່ເຮັດວຽກທີ່ LLM ສາມາດອ້າງອີງໄດ້ໂດຍກົງ. ເຮັດໜ້າທີ່ຮັກສາ System Prompt, ການສົນທະນາຫຼ້າສຸດ ແລະ ບົດສະຫຼຸບທີ່ສຳຄັນ.
• External Storage: ໜ່ວຍຄວາມຈຳໄລຍະຍາວທີ່ຈັດເກັບໄວ້ໃນ Vector DB ຫຼື KV Store.

ການຕັ້ງຄ່າ MemGPT ຕ້ອງລະວັງວ່າຂັ້ນຕອນຈະແຕກຕ່າງກັນລະຫວ່າງສະພາບແວດລ້ອມແບບ Local ຫຼື Cloud API. ຖ້າໃຊ້ Local LLM (ເຊັ່ນ: LM Studio) ຈະຕ້ອງມີການດາວໂຫຼດ Model ແລະ ຕັ້ງຄ່າ API endpoint ເພີ່ມເຕີມ, ສ່ວນການໃຊ້ OpenAI API key ແມ່ນສາມາດຕັ້ງຄ່າ Environment variable ເພື່ອດຳເນີນການກວດສອບການເຮັດວຽກໄດ້ຢ່າງວ່ອງໄວ.

ຂັ້ນຕອນການຕິດຕັ້ງ (ກໍລະນີໃຊ້ OpenAI API)

ກ່ອນອື່ນ, ກະລຸນາກຽມສະພາບແວດລ້ອມ Python 3.10 ຂຶ້ນໄປ.

ຫຼັງຈາກຕິດຕັ້ງແລ້ວ, ໃຫ້ໃຊ້ຄຳສັ່ງລຸ່ມນີ້ເພື່ອເປີດຕົວ Wizard ການຕັ້ງຄ່າເບື້ອງຕົ້ນແບບໂຕ້ຕອບ:

ໃນ Wizard ໃຫ້ຕັ້ງຄ່າຫົວຂໍ້ຕໍ່ໄປນີ້ຕາມລຳດັບ:

• LLM Provider: ເລືອກ openai (ຖ້າເປັນ Local LLM ໃຫ້ເລືອກ local)
• Model Name: ລະບຸ Model ທີ່ຕ້ອງການໃຊ້
• Embedding Model: ແນະນຳໃຫ້ໃຊ້ Model ຂອງ OpenAI ຕາມຄ່າເລີ່ມຕົ້ນ
• External Storage Backend: ເລືອກ chroma (Local) ຫຼື postgres

ການສ້າງ Agent ເບື້ອງຕົ້ນ

ຫຼັງຈາກຕັ້ງຄ່າສຳເລັດແລ້ວ, ໃຫ້ສ້າງ Agent ດ້ວຍຄຳສັ່ງລຸ່ມນີ້:

ໃນການເປີດໃຊ້ງານຄັ້ງທຳອິດ, ລະບົບຈະຮຽກຮ້ອງໃຫ້ທ່ານປ້ອນ System Prompt (Persona/ການຕັ້ງຄ່າຕົວຕົນ) ແລະ ຄ່າເລີ່ມຕົ້ນຂອງຄວາມຊົງຈຳຂອງບຸກຄົນ.

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

ເອເຈນຂອງ MemGPT ຈະຈັດການກັບຄວາມຈຳໂດຍການຮຽກໃຊ້ຟັງຊັນສະເພາະດັ່ງຕໍ່ໄປນີ້ ຄວບຄູ່ໄປກັບການຕອບໂຕ້ດ້ວຍຂໍ້ຄວາມປົກກະຕິທີ່ເປັນຜົນລວມຈາກ LLM:

• core_memory_append: ເພີ່ມຂໍ້ມູນເຂົ້າໄປໃນພື້ນທີ່ຄວາມຈຳຫຼັກພາຍໃນ Main Context
• core_memory_replace: ຂຽນທັບ ແລະ ອັບເດດລາຍການຄວາມຈຳທີ່ມີຢູ່ແລ້ວ
• archival_memory_insert: ບັນທຶກຂໍ້ມູນໄວ້ໃນບ່ອນຈັດເກັບຂໍ້ມູນພາຍນອກໄລຍະຍາວ
• archival_memory_search: ດຶງຂໍ້ມູນຈາກບ່ອນຈັດເກັບຂໍ້ມູນພາຍນອກໂດຍໃຊ້ຄຳສຳຄັນ ຫຼື ຄວາມຄ້າຍຄືກັນທາງຄວາມໝາຍ

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

ມີ 3 ຈຸດທີ່ຄວນລະວັງໃນເວລາປະຕິບັດງານ:

ສະຫຼຸບ: GraphRAG ສະກັດເອົາ Entity ແລະ Relation ຈາກເອກະສານການເຮັດວຽກ ແລ້ວເຮັດດັດຊະນີເປັນ Knowledge Graph ເຊິ່ງຊ່ວຍໃຫ້ສາມາດຄົ້ນຫາຂໍ້ມູນໃນລະດັບເລິກທີ່ຂ້າມຜ່ານບໍລິບົດຕ່າງໆໄດ້.

GraphRAG ແມ່ນໂຄງການທີ່ Microsoft Research ໄດ້ເປີດຕົວ ຫຼື Launch ໃນເດືອນກຸມພາ 2024. ຈຸດເດັ່ນຂອງມັນຄືການປ່ຽນຂໍ້ຄວາມໃຫ້ເປັນໂຄງສ້າງກຣາຟ ແລະ ສາມາດຄົ້ນຫາໂດຍທີ່ຍັງຮັກສາຄວາມສຳພັນລະຫວ່າງ Entity ໄວ້ໄດ້.

ໃນຕອນທຳອິດ ເຮົາມັກຈະຄິດວ່າ "ການສະກັດເອົາ Entity ໃຫ້ໄດ້ຫຼາຍທີ່ສຸດຈະຊ່ວຍເພີ່ມຄວາມຖືກຕ້ອງ" ແຕ່ໃນຄວາມເປັນຈິງແລ້ວ ການກຳນົດຂອບເຂດຄວາມລະອຽດຂອງ Entity ໃຫ້ແຄບລົງ ແລະ ຈຳກັດໄວ້ສະເພາະໜ່ວຍທີ່ມີຄວາມໝາຍທາງທຸລະກິດ ຈະຊ່ວຍໃຫ້ຄຸນນະພາບການຄົ້ນຫາດີຂຶ້ນ. ການສະກັດເອົາຫຼາຍເກີນໄປຈະເພີ່ມ Noise ໃຫ້ກັບກຣາຟ ແລະ ເປັນສາເຫດທີ່ເຮັດໃຫ້ຕົ້ນທຶນໃນການຄົ້ນຫາເສັ້ນທາງ (Path search) ໃນຂະນະ Query ເພີ່ມທະວີຂຶ້ນເລື້ອຍໆ.

ນະໂຍບາຍພື້ນຖານໃນການອອກແບບ Entity

ເມື່ອອອກແບບການສະກັດເອົາ Entity ສຳລັບເອກະສານທາງທຸລະກິດ ການຕັດສິນໃຈ 3 ຢ່າງຕໍ່ໄປນີ້ໄວ້ກ່ອນຈະຊ່ວຍໃຫ້ຂະບວນການຕໍ່ໄປດຳເນີນໄປຢ່າງສະດວກ:

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

ຈຸດສຳຄັນໃນການກຳນົດ Relation

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

ໃນເອກະສານຂອງ GraphRAG ໄດ້ສະແດງຕົວຢ່າງການຕັ້ງຄ່າ Text chunk size ໄວ້ທີ່ 50-100 tokens ເຊິ່ງຕ້ອງລະວັງວ່າ ຍິ່ງ Chunk ມີຂະໜາດນ້ອຍເທົ່າໃດ ກໍຍິ່ງຈັບຄວາມສຳພັນແບບ Co-occurrence ໃນລະດັບທ້ອງຖິ່ນຂອງ Entity ໄດ້ງ່າຍຂຶ້ນ ແຕ່ໃນທາງກັບກັນ ກໍຈະເຮັດໃຫ້ຕົ້ນທຶນໃນການສະກັດເອົາກຣາຟເພີ່ມທະວີຂຶ້ນເລື້ອຍໆ.

ການກຳນົດ Relation ຄວນລະບຸໃຫ້ຊັດເຈນວ່າເປັນ "ແບບສອງທິດທາງ ຫຼື ທິດທາງດຽວ" ເພື່ອຮັກສາຄວາມສອດຄ່ອງໃນການອອກແບບ Query.

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

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

1. ການປະມວນຜົນເບື້ອງຕົ້ນ (ການແບ່ງສ່ວນ - Chunking): ໃນເອກະສານຂອງ GraphRAG, ໄດ້ມີການລະບຸຕົວຢ່າງການຕັ້ງຄ່າຂະໜາດຂອງ Text Chunk ໄວ້ທີ່ 50-100 tokens. ສຳລັບເອກະສານທີ່ມີການແບ່ງແຍກເນື້ອໃນຊັດເຈນ ເຊັ່ນ: ບົດບັນທຶກການປະຊຸມ ຫຼື ເອກະສານ ມາດຕະຖານ ຫຼື Specification, ການໃຊ້ Chunk ຂະໜາດນ້ອຍຈະມີປະສິດທິຜົນ, ສ່ວນເອກະສານທີ່ມີຄວາມເຊື່ອມໂຍງລະຫວ່າງວັກສູງ ເຊັ່ນ: ລາຍງານຍາວໆ ຫຼື ສັນຍາຕ່າງໆ ການຕັ້ງຄ່າ Chunk ໃຫ້ໃຫຍ່ຂຶ້ນເລັກນ້ອຍຈະມີແນວໂນ້ມເຮັດໃຫ້ຄວາມຖືກຕ້ອງໃນການສະກັດເອົາ Entity ສູງຂຶ້ນ.
2. ການສະກັດເອົາ Entity ແລະ ຄວາມສຳພັນ: ໃຊ້ LLM ເພື່ອສະກັດເອົາ Entity ແລະ ຄວາມສຳພັນອອກຈາກ Chunk. ເອກະສານໄດ້ລະບຸວ່າຂັ້ນຕອນນີ້ກວມເອົາປະມານ 75% ຂອງຕົ້ນທຶນໃນການສ້າງ Graph Index, ດັ່ງນັ້ນການປະເມີນຄວາມສົມດຸນລະຫວ່າງປະລິມານການປະມວນຜົນ ແລະ ຕົ້ນທຶນລ່ວງໜ້າຈຶ່ງເປັນສິ່ງສຳຄັນ.
3. ການສ້າງ ແລະ ຈັດເກັບກຣາຟ: ຈັດເກັບຜົນລວມທີ່ສະກັດໄດ້ລົງໃນ Graph DB (ເຊັ່ນ: Neo4j) ຫຼື ບ່ອນຈັດເກັບຂໍ້ມູນພາຍໃນຂອງ GraphRAG.

ສຳລັບຫຼັກການຕັດສິນໃຈຕາມປະເພດເອກະສານ, ໃນກໍລະນີທີ່ເປັນຄວາມຮູ້ພາຍໃນອົງກອນ (FAQ, ຄູ່ມືການປະຕິບັດງານ) ເຊິ່ງມີຄວາມຖີ່ໃນການອັບເດດຕໍ່າ, ການອອກແບບໃຫ້ມີການ Re-index ເປັນໄລຍະດ້ວຍ Batch Processing ແມ່ນມີຄວາມສົມເຫດສົມຜົນ. ໃນທາງກົງກັນຂ້າມ, ຖ້າເປັນຂໍ້ມູນທີ່ມີການປ່ຽນແປງໄວ ເຊັ່ນ: ບັນທຶກການເຮັດວຽກປະຈຳວັນ ຫຼື ບັນທຶກ CRM, ການກຽມ ຂະບວນການ ຫຼື Pipeline ສຳລັບການສະກັດເອົາສ່ວນຕ່າງ (Differential Extraction) ເພື່ອອັບເດດກຣາຟແບບເພີ່ມເຕີມ (Incremental) ຈະເປັນໂຄງສ້າງທີ່ເໝາະສົມກວ່າ.

"ການສ້າງກຣາຟໄດ້ແລ້ວ ແຕ່ຈະສົ່ງຄຳຖາມ (Query) ແນວໃດເພື່ອໃຫ້ໄດ້ບໍລິບົດຂອງວຽກງານ?" —— ນີ້ແມ່ນຄຳຖາມທີ່ມັກຖືກຖາມຢູ່ສະເໝີໃນໜ້າວຽກຕົວຈິງ.

ໃນ GraphRAG, ພວກເຮົາຈະເລືອກໃຊ້ໂໝດການຄົ້ນຫາ 2 ຮູບແບບຫຼັກສຳລັບກຣາຟຄວາມຮູ້ທີ່ສ້າງຂຶ້ນ:

• Local Search: ການຄົ້ນຫາແບບສະເພາະເຈາະຈົງໂດຍເລີ່ມຈາກ Entity ຫຼື ຄວາມສຳພັນໃດໜຶ່ງ ແລ້ວຕິດຕາມ Node ທີ່ຢູ່ໃກ້ຄຽງ. ເໝາະສົມສຳລັບການດຶງຂໍ້ມູນບໍລິບົດທີ່ລະອຽດ ເຊັ່ນ: "ປະຫວັດການສອບຖາມຂອງລູກຄ້າຄົນນີ້".
• Global Search: ການຄົ້ນຫາເພື່ອເຂົ້າໃຈແນວໂນ້ມໃນວົງກວ້າງໂດຍການລວມເອົາບົດສະຫຼຸບຂອງ Community. ເໝາະສົມສຳລັບຄຳຖາມໃນມຸມມອງກວ້າງ ເຊັ່ນ: "ບັນຫາຫຼັກຂອງວຽກງານໃນເດືອນຜ່ານມາແມ່ນຫຍັງ".

ຂະບວນການ (Pipeline) ພື້ນຖານໃນການນຳໄປໃຊ້ງານມີດັ່ງນີ້:

1. ປ່ຽນຂໍ້ຄວາມ Query ໃຫ້ເປັນ Entity ທີ່ກ່ຽວຂ້ອງ ແລ້ວລະບຸ Node ທີ່ກົງກັນພາຍໃນກຣາຟ
2. ຂະຫຍາຍ Edge ທີ່ຢູ່ໃກ້ຄຽງ ແລະ Community ທີ່ກ່ຽວຂ້ອງຈາກ Node ເພື່ອດຶງເອົາ Subgraph
3. ນຳເອົາຂໍ້ຄວາມທີ່ສະແດງເຖິງ Subgraph ໄປໃສ່ໃນບໍລິບົດຂອງ LLM ເພື່ອສ້າງຄຳຕອບ

ສຳລັບ Chunk size, ຕົວຢ່າງການຕັ້ງຄ່າຢ່າງເປັນທາງການຂອງເອກະສານໄດ້ລະບຸໄວ້ທີ່ 50-100 tokens. ການແບ່ງຍ່ອຍຫຼາຍເທົ່າໃດ ຄວາມລະອຽດຂອງ Node ກໍຈະສູງຂຶ້ນ ແລະ ຄວາມແມ່ນຍຳກໍມີແນວໂນ້ມທີ່ຈະດີຂຶ້ນ, ແຕ່ໃນຂະນະດຽວກັນ ຕົ້ນທຶນໃນການສະກັດກຣາຟກໍຈະເພີ່ມຂຶ້ນເຊັ່ນກັນ. ນອກຈາກນີ້, ເອກະສານຍັງໄດ້ລະບຸວ່າການສະກັດກຣາຟກວມເອົາປະມານ 75% ຂອງຕົ້ນທຶນການສ້າງ Index ທັງໝົດ, ດັ່ງນັ້ນການຕັ້ງຄ່າ Chunk size ຈຶ່ງຈຳເປັນຕ້ອງຄຳນຶງເຖິງການແລກປ່ຽນ ຫຼື Trade-off ລະຫວ່າງຕົ້ນທຶນແລະຄວາມແມ່ນຍຳ.

ສະຫຼຸບ: ການລວມ ຫຼື Merge MemGPT ແລະ GraphRAG ເຂົ້າດ້ວຍກັນ ສາມາດສ້າງໂຄງສ້າງພື້ນຖານ ຫຼື Infrastructure ຄວາມຈຳໄລຍະຍາວທີ່ແຂງແກ່ນ ໂດຍການປະສົມປະສານການຈັດການຄວາມຈຳຂ້າມເຊສຊັນ (Session) ແລະ ການຄົ້ນຫາຄວາມຮູ້ແບບກຣາຟ (Knowledge Graph).

ການກຳນົດບົດບາດຂອງທັງສອງຢ່າງໃຫ້ຊັດເຈນ ພ້ອມທັງຕັ້ງຄ່າຕົວກະຕຸ້ນການຂຽນ (Write trigger) ແລະ ການໃຫ້ຄະແນນການຄົ້ນຫາ (Search scoring) ຢ່າງເໝາະສົມ ຄືກຸນແຈສູ່ຄວາມສຳເລັດໃນການລວມ ຫຼື Merge ລະບົບດັ່ງກ່າວ.

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

ໃນສະຖາປັດຕະຍະກຳແບບປະສົມປະສານ, ເຮົາຈະມອບໝາຍຄວາມຮັບຜິດຊອບໃຫ້ແຕ່ລະອົງປະກອບດັ່ງນີ້:

• MemGPT (ຊັ້ນຄວາມຈຳຂອງເຊສຊັນ): ຈັດການປະຫວັດການສົນທະນາຫຼ້າສຸດ, ສະຖານະການເຮັດວຽກຂອງຜູ້ໃຊ້ ແລະ ຄຳສັ່ງໄລຍະສັ້ນໃນບໍລິບົດຫຼັກ (Main Context), ແລະ ຈະຍ້າຍຂໍ້ມູນໄປໄວ້ໃນບ່ອນຈັດເກັບຂໍ້ມູນພາຍນອກເມື່ອຄວາມຈຸເຕັມ.
• GraphRAG (ຊັ້ນກຣາຟຄວາມຮູ້): ຮັກສາຂໍ້ມູນຄວາມສຳພັນລະຫວ່າງເອນທິຕີ (Entity), ກົດລະບຽບການເຮັດວຽກ ແລະ ຂໍ້ມູນທີ່ມີໂຄງສ້າງຂອງໂຄງການໃນອະດີດ ເພື່ອໃຫ້ສາມາດຄົ້ນຫາໄດ້ໂດຍອີງຕາມຄວາມໝາຍທີ່ເຊື່ອມໂຍງກັນ.
• Orchestrator: ຮັບຂໍ້ມູນເຂົ້າຈາກຜູ້ໃຊ້, ຫຼັງຈາກອ້າງອີງບໍລິບົດຈາກ MemGPT ແລ້ວ ຈະສົ່ງຄຳສັ່ງ (Query) ໄປຫາ GraphRAG ຕາມຄວາມຈຳເປັນ ເພື່ອລວມຜົນລັອກທີ່ໄດ້.

ການໄຫຼວຽນຂອງຂໍ້ມູນຈະຖືກປະມວນຜົນຕາມລຳດັບດັ່ງນີ້:

1. ຂໍ້ມູນເຂົ້າຈາກຜູ້ໃຊ້ → Orchestrator ເຮັດການຈັດປະເພດເຈດຕະນາ
2. ກວດສອບບໍລິບົດຫຼັກຂອງ MemGPT ແລະ ຕັດສິນໃຈວ່າສາມາດແກ້ໄຂພາຍໃນເຊສຊັນໄດ້ຫຼືບໍ່
3. ຖ້າບໍ່ສາມາດແກ້ໄຂໄດ້, ໃຫ້ສົ່ງຄຳສັ່ງຄົ້ນຫາເອນທິຕີໄປຫາ GraphRAG
4. ນຳຄວາມຮູ້ທີ່ໄດ້ຮັບມາໃສ່ໃນບໍລິບົດຫຼັກ ເພື່ອໃຫ້ LLM ສ້າງຄຳຕອບ
5. ຂໍ້ມູນທີ່ສຳຄັນຈະຖືກຂຽນລົງໃນບ່ອນຈັດເກັບຂໍ້ມູນພາຍນອກຂອງ MemGPT ເພື່ອສົ່ງຂໍ້ມູນຕໍ່ໃຫ້ໃນເຊສຊັນຖັດໄປ

ສິ່ງທີ່ສຳຄັນເປັນພິເສດໃນການອອກແບບນີ້ຄື ການຈຳກັດການສອບຖາມໄປຍັງ GraphRAG ໃຫ້ "ສະເພາະໃນກໍລະນີທີ່ຈຳເປັນເທົ່ານັ້ນ".

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

ຕົວກະຕຸ້ນໃນການຂຽນຂໍ້ມູນ (Write triggers) ສາມາດແບ່ງອອກເປັນ 3 ປະເພດໃຫຍ່ໆ ດັ່ງນີ້:

• ແບບອີງຕາມເຫດການ (Event-driven): ຂຽນຂໍ້ມູນເມື່ອຜູ້ໃຊ້ສັ່ງການຢ່າງຈະແຈ້ງວ່າ "ໃຫ້ຈື່ໄວ້" ຫຼື ເມື່ອເກີດເຫດການທາງທຸລະກິດ ເຊັ່ນ: ການເຮັດວຽກສຳເລັດ ຫຼື ການອະນຸມັດຕ່າງໆ.
• ແບບອີງຕາມການວິເຄາະ (Inference-based): ເອເຈນ (Agent) ຈະປະເມີນເນື້ອໃນການສົນທະນາ ແລະ ຂຽນຂໍ້ມູນດ້ວຍຕົນເອງເມື່ອຄະແນນຄວາມສຳຄັນເກີນກວ່າຄ່າທີ່ກຳນົດໄວ້ (Threshold).
• ແບບຮອບວຽນ (Periodic batch): ສ້າງ ແລະ ບັນທຶກບົດສະຫຼຸບຂອງໄລຍະເວລານັ້ນໆ ເມື່ອສິ້ນສຸດເຊສຊັນ (Session) ຫຼື ໃນທຸກໆໄລຍະເວລາທີ່ກຳນົດ.

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

ທ່ານເຄີຍຮູ້ສຶກບໍ່ວ່າ "ເຖິງຈະດຶງຂໍ້ມູນ Node ທີ່ກ່ຽວຂ້ອງມາໄດ້ດ້ວຍ GraphRAG ແລ້ວ, ແຕ່ຄຳຕອບຂອງ Agent ກັບບໍ່ກົງປະເດັນ"? ສາເຫດສ່ວນໃຫຍ່ມັກມາຈາກການອອກແບບການໃຫ້ຄະແນນການຄົ້ນຫາ (Search Scoring) ທີ່ບໍ່ສອດຄ່ອງກັບຄວາມສຳຄັນຂອງວຽກງານຕົວຈິງ.

ໃນສະພາບແວດລ້ອມທີ່ລວມ MemGPT ແລະ GraphRAG ເຂົ້າດ້ວຍກັນ, ການນຳເອົາອົງປະກອບຕໍ່ໄປນີ້ມາປະສົມປະສານເຂົ້າໃນການໃຫ້ຄະແນນຜົນການຄົ້ນຫາແມ່ນມີປະສິດທິຜົນ:

• ຄວາມຄ້າຍຄືກັນທາງຄວາມໝາຍ (Semantic Similarity): ຄະແນນພື້ນຖານໂດຍອີງໃສ່ໄລຍະຫ່າງຂອງ Vector
• ຄວາມໃກ້ຊິດຂອງກຣາຟ (Graph Proximity): ຈຳນວນ Hop ຈາກ Node ເປົ້າໝາຍໄປຫາ Entity ທີ່ອ້າງອີງ (ຍິ່ງໃກ້ ຄະແນນຍິ່ງສູງ)
• ນ້ຳໜັກຄວາມສົດໃໝ່ (Recency Weight): ການຫຼຸດຄະແນນຂອງຂໍ້ມູນຄວາມຈຳເກົ່າລົງເທື່ອລະຂັ້ນໂດຍອີງໃສ່ Timestamp
• ຄວາມຖີ່ໃນການເຂົ້າເຖິງ (Access Frequency): ການບວກເພີ່ມຈຳນວນຄັ້ງທີ່ເຄີຍຖືກອ້າງອີງໃນອະດີດ ເພື່ອໃຫ້ຄວາມສຳຄັນກັບຄວາມຈຳທີ່ມີຜົນງານຜ່ານມາ

ການນຳເອົາ 4 ປັດໄຈນີ້ມາລວມກັນແບບເສັ້ນ (Linear Combination) ແລະ ປັບນ້ຳໜັກຕາມປະເພດຂອງວຽກງານ ຈະຊ່ວຍໃຫ້ສາມາດຈັດອັນດັບການຄົ້ນຫາທີ່ສອດຄ່ອງກັບບໍລິບົດຂອງວຽກງານໄດ້.

ຍຸດທະສາດການສຳຮອງ (Fallback Strategy) ກໍມີຄວາມສຳຄັນບໍ່ແພ້ກັນ. ຖ້າການສອບຖາມກຣາຟ (Graph Query) ຂອງ GraphRAG ບໍ່ໄດ້ຜົນລັດໃດໆ, ການສົ່ງຂໍ້ມູນຕໍ່ໃຫ້ Agent ໂດຍກົງຈະເຮັດໃຫ້ຄຸນນະພາບຂອງຄຳຕອບຫຼຸດລົງຢ່າງຮຸນແຮງ. ຂັ້ນຕອນການສຳຮອງ 3 ລະດັບທີ່ແນະນຳມີດັ່ງນີ້:

1. Graph Query — ຄົ້ນຫາໂດຍໃຫ້ຄວາມສຳຄັນກັບຄວາມສຳພັນຂອງ Entity
2. Vector Search (Standard RAG) — ດຳເນີນການໃນກໍລະນີທີ່ບໍ່ພົບຂໍ້ມູນໃນກຣາຟ
3. MemGPT Summary Memory — ອ້າງອີງໃນກໍລະນີທີ່ 2 ວິທີທຳອິດໄດ້ຄະແນນຕໍ່າ

ເມື່ອມີການໃຊ້ງານລະບົບສຳຮອງ, ຄວນມີການຕັ້ງ Flag ໄວ້ໃນ Log ເພື່ອນຳໄປໃຊ້ເປັນ Trigger ໃນການອັບເດດກຣາຟໃນຂັ້ນຕອນຕໍ່ໄປ, ເຊິ່ງຈະຊ່ວຍໃຫ້ສາມາດຕື່ມເຕັມຊ່ອງວ່າງຂອງຄວາມຈຳໄດ້ຢ່າງຕໍ່ເນື່ອງ.

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

ທັນທີທີ່ນຳເອົາຄວາມຈຳໄລຍະຍາວ (Long-term memory) ມາໃຊ້, ຫຼາຍທີມມັກຈະເລືອກໃຊ້ນະໂຍບາຍທີ່ວ່າ "ບັນທຶກທຸກຢ່າງທີ່ສາມາດບັນທຶກໄດ້". ແຕ່ໃນຄວາມເປັນຈິງແລ້ວ, ມີການລາຍງານກໍລະນີທີ່ວ່າເມື່ອຈຳນວນລາຍການ (Entry) ເພີ່ມຂຶ້ນ, ຄວາມໜ່ວງໃນການຄົ້ນຫາ (Search latency) ຈະແຍ່ລົງຫຼາຍກວ່າເສັ້ນຊື່ ແລະ ຄວາມໄວໃນການຕອບສະໜອງຈະກາຍເປັນຄໍຂວດ (Bottleneck). ການອອກແບບທີ່ຈຳກັດປະລິມານການຈັດເກັບຂໍ້ມູນຄື ຈຸດສຳຄັນ ຫຼື ແກນຫຼັກ ໃນການຮັກສາປະສິດທິພາບໃນໄລຍະຍາວ.

ມາດຕະການຫຼັກໃນການປ້ອງກັນບໍ່ໃຫ້ຂໍ້ມູນບວມມີດັ່ງນີ້:

• ການຕັ້ງຄ່າ TTL (Time To Live): ກຳນົດວັນໝົດອາຍຸໃຫ້ກັບຄວາມຈຳແບບເຫດການ (Episodic memory) ແລະ ເຮັດການ Archive ຫຼື ລຶບລາຍການທີ່ບໍ່ໄດ້ຖືກອ້າງອີງໃນໄລຍະເວລາໃດໜຶ່ງອອກໂດຍອັດຕະໂນມັດ. ສຳລັບຂໍ້ມູນທີ່ຄວາມສົດໃໝ່ມີຄວາມສຳຄັນເຊັ່ນ: ບັນທຶກການເຮັດວຽກ (Business log), ຄວນອອກແບບໂດຍອ້າງອີງ TTL ປະມານ 30-90 ວັນ.
• ການຈັດການບຸລິມະສິດດ້ວຍຄະແນນຄວາມສຳຄັນ: ໃຊ້ Function call ຂອງ MemGPT ເພື່ອກຳນົດຄະແນນຄວາມສຳຄັນໃນຂະນະຂຽນຂໍ້ມູນ, ແລະ ບີບອັດ ຫຼື ສະຫຼຸບຫຍໍ້ລາຍການທີ່ມີຄະແນນຕໍ່າກ່ອນຈັດເກັບ. ການປ່ຽນຈາກການສະສົມເນື້ອຫາຕົ້ນສະບັບຢ່າງລະອຽດມາເປັນການສະຫຼຸບຫຍໍ້ແທນ ຈະຊ່ວຍຫຼຸດຜ່ອນທັງພື້ນທີ່ຈັດເກັບຂໍ້ມູນ ແລະ ຕົ້ນທຶນໃນການຄົ້ນຫາໄປພ້ອມກັນ.
• ການປັບແຕ່ງ Chunk size ຂອງ GraphRAG: ອີງຕາມເອກະສານ, ຕົວຢ່າງການຕັ້ງຄ່າຂະໜາດ Text chunk ແມ່ນ 50-100 tokens. ການແບ່ງ Chunk ທີ່ລະອຽດເກີນໄປຈະເຮັດໃຫ້ຈຳນວນ Node ເພີ່ມຂຶ້ນຢ່າງມະຫາສານ, ດັ່ງນັ້ນຈຶ່ງຈຳເປັນຕ້ອງມີການປັບແຕ່ງໃຫ້ເໝາະສົມກັບຄວາມລະອຽດຂອງເອກະສານໃນວຽກງານ.
• ການຕັດແຕ່ງກຣາຟ (Graph pruning) ເປັນໄລຍະ: ລຶບ Node ທີ່ໂດດດ່ຽວ ຫຼື Edge ທີ່ມີການອ້າງອີງຕໍ່າອອກດ້ວຍ Batch ວຽກງານເປັນໄລຍະ ເພື່ອຮັກສາຄວາມໜາແໜ້ນຂອງກຣາຟໃຫ້ຢູ່ໃນຂອບເຂດທີ່ກຳນົດ.

ການປະສົມປະສານວິທີການເຫຼົ່ານີ້ຈະຊ່ວຍໃຫ້ສາມາດຮັກສາຄວາມສົມດຸນລະຫວ່າງຄວາມສົດໃໝ່ຂອງຄວາມຈຳ ແລະ ຄວາມໄວໃນການຄົ້ນຫາໄດ້.

ຄວາມຂັດແຍ່ງຂອງລາຍການຄວາມຈຳ (Memory entry) ຈະເກີດຂຶ້ນເມື່ອຂໍ້ມູນຂອງເອນຕິຕີ້ (Entity) ດຽວກັນທີ່ມາຈາກຊ່ວງເວລາທີ່ແຕກຕ່າງກັນຖືກບັນທຶກໄວ້ແຍກກັນ. ຕົວຢ່າງເຊັ່ນ: ການມີບັນທຶກທີ່ວ່າ "ຜູ້ຮັບຜິດຊອບແມ່ນທ່ານ Tanaka" ແລະ "ຜູ້ຮັບຜິດຊອບແມ່ນທ່ານ Suzuki" ຢູ່ຮ່ວມກັນ ຈະເຮັດໃຫ້ Agent ບໍ່ສາມາດຕັດສິນໃຈໄດ້ວ່າຄວນອ້າງອີງອັນໃດ.

ການກວດສອບຄວາມຂັດແຍ່ງ, ວິທີການຕໍ່ໄປນີ້ແມ່ນມີປະສິດທິພາບ:

• ການປຽບທຽບ Time stamp: ໃນກໍລະນີທີ່ມີຫຼາຍລາຍການສຳລັບເອນຕິຕີ້ດຽວກັນ ແລະ ຄຸນລັກສະນະດຽວກັນ, ໃຫ້ຖືເອົາລາຍການທີ່ມີ Time stamp ຫຼ້າສຸດເປັນຂໍ້ມູນທີ່ຖືກຕ້ອງ ແລະ ໃສ່ແທັກ "obsolete" ໃຫ້ກັບລາຍການເກົ່າ.
• ການກວດສອບຄວາມຄ້າຍຄືກັນໂດຍອີງໃສ່ Embedding: ເມື່ອມີການບັນທຶກລາຍການໃໝ່, ໃຫ້ສະກັດເອົາລາຍການທີ່ມີຢູ່ເດີມທີ່ມີຄ່າ Cosine similarity ເກີນກວ່າຄ່າ Threshold (ຕົວຢ່າງ: 0.90 ຂຶ້ນໄປ) ອອກມາເປັນຕົວເລືອກ ແລະ ມອບໝາຍໃຫ້ LLM ເປັນຜູ້ຕັດສິນຄວາມຂັດແຍ່ງ.

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

ໃນກໍລະນີທີ່ໃຊ້ GraphRAG, ການອອກແບບໃຫ້ບັນທຶກປະຫວັດການປ່ຽນແປງຄຸນລັກສະນະຂອງ Node ໄວ້ເປັນ Edge ຈະຊ່ວຍໃນການຕິດຕາມຄວາມຂັດແຍ່ງໄດ້. ສຳລັບຝັ່ງ MemGPT, ແນະນຳໃຫ້ມີການຈັດຕັ້ງປະຕິບັດໂດຍການໃສ່ເຫດຜົນໃນການກວດສອບຄວາມຊ້ຳຊ້ອນ (Duplicate check logic) ລົງໃນຟັງຊັນການຂຽນຂໍ້ມູນລົງໃນ Archival storage ແລະ ເມື່ອກວດພົບຄວາມຂັດແຍ່ງທີ່ອາດຈະເກີດຂຶ້ນ ໃຫ້ມີຂັ້ນຕອນການຢືນຢັນໂດຍຕົວ Agent ເອງ.