ການກວດສອບຄວາມບໍ່ແນ່ນອນ (Non-determinism audit) ຂອງ AI Agent ແມ່ນຂະບວນການບັນທຶກຂະບວນການຕັດສິນໃຈເພື່ອໃຫ້ສາມາດກວດສອບຍ້ອນຫຼັງໄດ້ ໂດຍຕັ້ງຢູ່ບົນພື້ນຖານທີ່ວ່າ Agent ອາດຈະສ້າງຜົນລັດທີ່ແຕກຕ່າງກັນເຖິງແມ່ນວ່າຈະໄດ້ຮັບອິນພຸດ (Input) ດຽວກັນກໍຕາມ.

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

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

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

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

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

ແຫຼ່ງທີ່ມາຫຼັກຂອງຄວາມບໍ່ແນ່ນອນແມ່ນມາຈາກການສຸ່ມໃນເວລາເລືອກ Output token. ພາຣາມິເຕີຕ່າງໆ ເຊັ່ນ: Temperature ແລະ top-p ຈະເປັນຕົວປັບວ່າຈະເລືອກສະເພາະຜູ້ສະໝັກທີ່ມີຄວາມໜ້າຈະເປັນສູງ ຫຼື ເປີດໂອກາດໃຫ້ຜູ້ສະໝັກທີ່ມີຄວາມໜ້າຈະເປັນຕ່ຳນຳ. ຖ້າເພີ່ມ Temperature ຈະເຮັດໃຫ້ການສະແດງອອກມີຄວາມຫຼາກຫຼາຍ ແຕ່ກໍຈະເຮັດໃຫ້ເກີດຄວາມຜັນຜວນໃນ Input ດຽວກັນຫຼາຍຂຶ້ນ.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

ເຖິງແມ່ນວ່າຈະເປັນການປ້ອນຂໍ້ມູນແບບດຽວກັນ, ແຕ່ຜົນລັອກກໍຈະປ່ຽນແປງໄປຕາມຮູບແບບ (Model) ແລະ ພາຣາມິເຕີ (Parameter) ທີ່ໃຊ້ໃນການສອບຖາມ. ດັ່ງນັ້ນ, ຈຶ່ງຄວນບັນທຶກເງື່ອນໄຂການຮຽກໃຊ້ໃນແຕ່ລະຄັ້ງ ເຊັ່ນ: ຊື່ຮູບແບບ (Model name) ແລະ ເວີຊັນ, ການຕັ້ງຄ່າການສຸ່ມ (Sampling settings) ເຊັ່ນ: Temperature ຫຼື top-p, ຄ່າ Seed, ແລະ ຈຳນວນ Token ສູງສຸດ.

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

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

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

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

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

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

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

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

ສຳລັບ Agent ທີ່ມີຫຼາຍຂັ້ນຕອນ, ການກຳນົດ Trace ID (ສຳລັບການປະມວນຜົນທັງໝົດ) ແລະ Span ID (ສຳລັບແຕ່ລະຂັ້ນຕອນ) ແບບເປັນລຳດັບຊັ້ນ ຈະຊ່ວຍໃຫ້ຕິດຕາມໄດ້ງ່າຍຂຶ້ນ. ການນຳໃຊ້ ID ທີ່ເຊື່ອມໂຍງທັງໝົດເຂົ້າດ້ວຍກັນ ບວກກັບ ID ທີ່ລະບຸແຕ່ລະຂັ້ນຕອນ, ຈະເຮັດໃຫ້ສາມາດຕິດຕາມ "ຂັ້ນຕອນໃດທີ່ເກີດການແຍກອອກ" ໄດ້ໃນຮູບແບບໂຄງສ້າງຕົ້ນໄມ້ (Tree structure).

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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