ການອອກແບບໜ່ວຍຄວາມຈຳໄລຍະຍາວສຳລັບ AI Agent — ຄູ່ມືການປະຕິບັດງານດ້ານ Persistent Memory, Memory Store ແລະ ການຄົ້ນຫາ

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

ບົດຄວາມນີ້ໄດ້ຮວບຮວມຂັ້ນຕອນການອອກແບບໜ່ວຍຄວາມຈຳຖາວອນ (Long-term memory) ຈາກມຸມມອງຂອງການນຳໄປໃຊ້ງານ, ເພື່ອແນໃສ່ກຸ່ມວິສະວະກອນ ແລະ ຜູ້ຮັບຜິດຊອບດ້ານຜະລິດຕະພັນທີ່ກຳລັງອອກແບບ ແລະ ດຳເນີນງານ AI Agent ທີ່ເຮັດວຽກແບບອັດຕະໂນມັດ. ເນື້ອໃນຈະກວມເອົາຕັ້ງແຕ່ການເລືອກ Memory Store, ຂັ້ນຕອນການຂຽນ-ຄົ້ນຫາ-ອັບເດດ, ມາດຕະການຮັບມືກັບຂໍ້ມູນທີ່ລ້າສະໄໝ ຫຼື ບັນຫາໜ່ວຍຄວາມຈຳເປິເປື້ອນ (Memory pollution), ໄປຈົນເຖິງການອອກແບບເພື່ອແບ່ງປັນຂໍ້ມູນໃນລະບົບ Multi-agent. ທັງນີ້, ການອອກແບບ Context Engineering ທີ່ກ່ຽວຂ້ອງກັບການເລືອກຂໍ້ມູນໃສ່ໃນການປະມວນຜົນແຕ່ລະຄັ້ງນັ້ນ ຈະຖືກຍົກໄປອະທິບາຍໃນບົດຄວາມອື່ນ, ໂດຍບົດຄວາມນີ້ຈະເນັ້ນໄປທີ່ "ຊັ້ນຂໍ້ມູນຖາວອນ" (Persistent layer) ທີ່ເກັບຮັກສາໄວ້ຂ້າມຜ່ານເຊສຊັນເທົ່ານັ້ນ.

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

ຕົວແທນ (Agent) ຈຳເປັນຕ້ອງມີໜ່ວຍຄວາມຈຳ ເມື່ອການປະມວນຜົນບໍ່ໄດ້ຈົບລົງພາຍໃນ "ການຖາມ-ຕອບພຽງຄັ້ງດຽວ". ເຊິ່ງມີ 3 ສະຖານະການຫຼັກໆ ດັ່ງນີ້:

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

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

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

ໃນທາງກັບກັນ, ສຳລັບການນຳໃຊ້ທີ່ບໍ່ຈຳເປັນຕ້ອງມີການສົ່ງຕໍ່ສະຖານະ ເຊັ່ນ: ການຖາມ-ຕອບແບບຄັ້ງດຽວ ຫຼື FAQ Bot ທີ່ຖາມ-ຕອບແບບໂຕ້ຕອບກັນ, ການບໍ່ສ້າງຊັ້ນໜ່ວຍຄວາມຈຳ (Memory layer) ຈະເຮັດໃຫ້ໂຄງສ້າງມີຄວາມລຽບງ່າຍກວ່າ.

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

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

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

ໜ່ວຍຄວາມຈຳຂອງ Agent ສາມາດອອກແບບໄດ້ງ່າຍຂຶ້ນ ຖ້າແບ່ງອອກເປັນ 3 ປະເພດ ຕາມໄລຍະເວລາການເກັບຮັກສາ ແລະ ຈຸດປະສົງການນຳໃຊ້.

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

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

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

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

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

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

• ຄວາມສາມາດໃນການນຳມາໃຊ້ໃໝ່ (Reusability): ຂໍ້ມູນນັ້ນຖືກອ້າງອີງຊ້ຳໆໂດຍຜູ້ໃຊ້ຄົນດຽວກັນ ຫຼື ໃນວຽກງານດຽວກັນຫຼືບໍ່? ຂໍ້ມູນທີ່ໃຊ້ພຽງຄັ້ງດຽວບໍ່ຄວນຖືກເກັບຮັກສາໄວ້.
• ຕົ້ນທຶນໃນການຊອກຫາຄືນ (Re-acquisition cost): ຂໍ້ມູນທີ່ສາມາດດຶງມາໃໝ່ໄດ້ຈາກລະບົບພາຍນອກ ຫຼື ຖານຂໍ້ມູນໃນແຕ່ລະຄັ້ງ (ເຊັ່ນ: ຈຳນວນສິນຄ້າຄົງເຫຼືອຫຼ້າສຸດ, ລາຄາ ແລະ ອື່ນໆ) ບໍ່ຄວນຖືກຄົງຄ່າໄວ້ໃນໜ່ວຍຄວາມຈຳ, ຄວນຍຶດຖືແຫຼ່ງຂໍ້ມູນຕົ້ນທາງເປັນຫຼັກ. ຖ້າຫາກນຳມາຄົງຄ່າໄວ້ ຂໍ້ມູນນັ້ນອາດຈະກາຍເປັນຂໍ້ມູນທີ່ລ້າສະໄໝ.
• ບັນທຶກການຕັດສິນໃຈ ແລະ ການແກ້ໄຂ: ຄວາມມັກຂອງຜູ້ໃຊ້, ມາດຕະຖານ ຫຼື Specification ທີ່ກຳນົດແລ້ວ, ການແກ້ໄຂໃນອະດີດ ແລະ ອື່ນໆ ເຊິ່ງເປັນ "ຜົນລວມຂອງການຕົກລົງເຫັນດີ" ແມ່ນສິ່ງທີ່ຍາກຕໍ່ການສ້າງຂຶ້ນໃໝ່ ຈຶ່ງມີຄຸນຄ່າສູງໃນການເກັບຮັກສາໄວ້.
• ຄວາມສາມາດໃນການສະຫຼຸບ: ເຫດການທີ່ຍາວນານບໍ່ຄວນຖືກບັນທຶກໄວ້ເປັນ Raw log ທັງໝົດ, ແຕ່ຄວນສະຫຼຸບປະເດັນສຳຄັນເພື່ອເກັບຮັກສາໄວ້ ເຊິ່ງຈະຊ່ວຍຫຼຸດຜ່ອນສິ່ງລົບກວນ (Noise) ແລະ ປະຢັດພື້ນທີ່ຈັດເກັບ.

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

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

ໃນການອອກແບບ ຄວນລວມເອົາສິ່ງເຫຼົ່ານີ້ເຂົ້າໄປນຳ:

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

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

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

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

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

Key-Value Store (KVS): ເໝາະສຳລັບຂໍ້ມູນທີ່ຮູ້ຄີ (Key) ແນ່ນອນ ແລະ ສາມາດດຶງຂໍ້ມູນໄດ້ດ້ວຍການຈັບຄູ່ທີ່ສົມບູນແບບ ເຊັ່ນ: "ການຕັ້ງຄ່າຂອງ User ID ແຕ່ລະຄົນ" ຫຼື "ສະຖານະຂອງ Project ID ແຕ່ລະອັນ". ມີຄວາມໜ່ວງຕ່ຳ (Low latency) ແລະ ງ່າຍຕໍ່ການຈັດການໃນຖານະບ່ອນເກັບຂໍ້ມູນທີ່ມີໂຄງສ້າງງ່າຍດາຍ.

Relational / Document DB: ເໝາະສຳລັບຄວາມຈຳທີ່ມີຄວາມສຳພັນ ຫຼື ເງື່ອນໄຂການກັ່ນຕອງທີ່ຊັບຊ້ອນ (ການຄົ້ນຫາຕາມເງື່ອນໄຂຂອງປະຫວັດ, ການລວມຍອດຂໍ້ມູນ).

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

ເມື່ອຕັດສິນໃຈເລືອກ Store ແລ້ວ, ໃຫ້ກຳນົດ Lifecycle.

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

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

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

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

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

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

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

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

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

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

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

ຂອບເຂດທີ່ເປັນຕົວຢ່າງຫຼັກມີລຳດັບຊັ້ນດັ່ງນີ້:

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

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

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

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

ພື້ນຖານຂອງການປ້ອງກັນແມ່ນ "ກວດສອບກ່ອນບັນທຶກ ແລະ ຢ່າເຊື່ອໝົດໃຈເມື່ອດຶງຂໍ້ມູນອອກມາໃຊ້".

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

ຄວາມໜ້າຢ້ານຂອງການປົນເປື້ອນຄື "ມັນສົ່ງຜົນໂດຍທີ່ເຮົາບໍ່ຮູ້ຕົວ". ຈຸດສຳຄັນ ຫຼື ແກນຫຼັກ ຄືການເຮັດວຽກແບບສອງຊັ້ນ (Double-check) ໂດຍການກວດສອບທັງຂາເຂົ້າ (ບັນທຶກ) ແລະ ຂາອອກ (ອ່ານຂໍ້ມູນ).

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

ມາດຕະການແກ້ໄຂແມ່ນລວມສູນຢູ່ທີ່ການອອກແບບຄວາມຖືກຕ້ອງໃນການຄົ້ນຫາ:

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

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

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

ໃນການອອກແບບ Multi-agent ລະບົບ, ຕ້ອງຕັດສິນໃຈວ່າຄວາມຊົງຈຳໃດທີ່ຄວນແບ່ງປັນລະຫວ່າງເອເຈນ (Agent) ແລະຄວາມຊົງຈຳໃດທີ່ຄວນເກັບໄວ້ສະເພາະຕົວ.

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

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

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

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

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

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

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

ການອອກແບບໜ່ວຍຄວາມຈຳ (Memory) ຂອງ AI Agent ເລີ່ມຕົ້ນຈາກການຈັດການ "ຊັ້ນຂໍ້ມູນທີ່ຄົງຢູ່ຂ້າມເຊສຊັນ (Persistent Layer)" ໃຫ້ເປັນຊັ້ນທີ່ແຍກຕ່າງຫາກຈາກການອອກແບບບໍລິບົດ (Context Design). ສະຫຼຸບປະເດັນສຳຄັນໄດ້ດັ່ງນີ້:

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

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