AI Observability (ການສັງເກດການ AI)
ການປະຕິບັດງານເພື່ອຕິດຕາມ ແລະ ສະແດງຜົນການເຮັດວຽກຂອງລະບົບ AI ທີ່ກຳລັງໃຊ້ງານຈິງຢ່າງຕໍ່ເນື່ອງ, ລວມທັງການປ້ອນຂໍ້ມູນ/ຜົນລັດ, ຄວາມໜ່ວງ (Latency), ຕົ້ນທຶນ ແລະ ຄຸນນະພາບ. ເປັນສິ່ງຈຳເປັນສຳລັບການກວດຫາອາການ Hallucination ແລະ Drift ໄດ້ຢ່າງວ່ອງໄວ.
AI Observability (ການສັງເກດການ AI) ແມ່ນການປະຕິບັດງານເພື່ອຕິດຕາມ ແລະ ເຮັດໃຫ້ເຫັນພາບລວມຂອງການປ້ອນຂໍ້ມູນ/ຜົນລວມ, ຄວາມໜ່ວງ (latency), ຕົ້ນທຶນ ແລະ ຄຸນນະພາບຂອງລະບົບ AI ທີ່ກຳລັງເຮັດວຽກຢູ່ໃນສະພາບແວດລ້ອມຈິງ. ມັນເປັນພື້ນຖານທີ່ຂາດບໍ່ໄດ້ໃນການດຳເນີນງານລະບົບ AI ຢ່າງປອດໄພ ແລະ ໝັ້ນຄົງ ເຊິ່ງຊ່ວຍໃຫ້ສາມາດກວດພົບ [hallucination](ການຫຼອນຂອງ AI) ໄດ້ໄວ ແລະ ຮັບມືກັບ model drift ໄດ້.
ເປັນຫຍັງການສັງເກດການ (Observability) ຈຶ່ງຈຳເປັນໃນຕອນນີ້?
ການຕິດຕາມຊອບແວແບບດັ້ງເດີມຈະເນັ້ນໃສ່ຕົວຊີ້ວັດທີ່ຂ້ອນຂ້າງຊັດເຈນ ເຊັ່ນ: ບັນທຶກຂໍ້ຜິດພາດ (error logs) ຫຼື ເວລາຕອບສະໜອງ (response time). ແຕ່ສຳລັບລະບົບທີ່ລວມເອົາ [generative-ai](AI ສ້າງສັນ) ແລະ llm ເຂົ້າໄປນັ້ນ, ຜົນລວມຈະແຕກຕ່າງກັນໃນທຸກໆຄັ້ງທີ່ມີການປ້ອນຂໍ້ມູນແບບດຽວກັນ ແລະ ນິຍາມຂອງ "ຄຳຕອບທີ່ຖືກຕ້ອງ" ກໍມີຄວາມຄຸມເຄືອ. ນີ້ຄືຄວາມແຕກຕ່າງພື້ນຖານຈາກວິທີການຕິດຕາມແບບເກົ່າ.
ນອກຈາກນີ້, ໃນ [compound-ai-system](ລະບົບ AI ແບບປະສົມ) ທີ່ມີຫຼາຍອົງປະກອບເຊື່ອມໂຍງກັນ ເຊັ່ນ: rag ຫຼື multi-agent-system, ການລະບຸວ່າຄຸນນະພາບຫຼຸດລົງໃນຂັ້ນຕອນໃດນັ້ນແມ່ນເຮັດໄດ້ຍາກ. ການສັງເກດການ (Observability) ຈຶ່ງມີຄວາມສຳຄັນເພີ່ມຂຶ້ນຢ່າງວ່ອງໄວໃນຊຸມປີມໍ່ໆມານີ້ ໃນຖານະເປັນວິທີການຮັບມືກັບ "ຄວາມບໍ່ໂປ່ງໃສທີ່ເປັນເອກະລັກຂອງລະບົບ AI".
4 ມິຕິທີ່ຄວນຕິດຕາມ
AI Observability ສາມາດຈັດກຸ່ມເປົ້າໝາຍອອກເປັນ 4 ຂົງເຂດໃຫຍ່ໆດັ່ງນີ້:
- ຄຸນນະພາບຂອງການປ້ອນຂໍ້ມູນ ແລະ ຜົນລວມ: ບັນທຶກຄູ່ຂອງ prompt ແລະ ຄຳຕອບ ເພື່ອຊອກຫາການຫຼອນ (hallucination), ເນື້ອຫາທີ່ເປັນອັນຕະລາຍ ແລະ ການລະເມີດນະໂຍບາຍ.
- ຄວາມໜ່ວງ (Latency) ແລະ ປະລິມານງານ (Throughput): ວັດແທກຄວາມໄວໃນການສ້າງ token ແລະ ເວລາຕອບສະໜອງ ເພື່ອຈັບສັນຍານເຕືອນໄພກ່ອນການລະເມີດ SLA.
- ຕົ້ນທຶນ: ຕິດຕາມປະລິມານການໃຊ້ token ໃນແຕ່ລະການໂທ API ເພື່ອໃຊ້ໃນການຄິດໄລ່ [ai-roi](ຜົນຕອບແທນຈາກການລົງທຶນໃນ AI) ແລະ ປ້ອງກັນການໃຊ້ງົບປະມານເກີນ.
- ການກວດຫາ Drift: ກວດສອບການປ່ຽນແປງຂອງການກະຈາຍຂໍ້ມູນທີ່ປ້ອນເຂົ້າ ແລະ ການປ່ຽນແປງຂອງພຶດຕິກຳແບບຈຳລອງຢ່າງຕໍ່ເນື່ອງ.
ສິ່ງເຫຼົ່ານີ້ບໍ່ໄດ້ເຮັດວຽກຢ່າງເປັນອິດສະຫຼະ ແຕ່ມີຄວາມກ່ຽວພັນກັນ. ຕົວຢ່າງ: ເມື່ອຄວາມໜ່ວງເພີ່ມຂຶ້ນຢ່າງກະທັນຫັນ, ການຈະແຍກໃຫ້ອອກວ່າສາເຫດມາຈາກ context-window ທີ່ໃຫຍ່ເກີນໄປ ຫຼື ມາຈາກພາລະຂອງລະບົບຫຼັງບ້ານ (backend) ນັ້ນ ຈຳເປັນຕ້ອງມີການວິເຄາະໂດຍລວມຫຼາຍຕົວຊີ້ວັດເຂົ້າດ້ວຍກັນ.
ຄວາມສຳພັນກັບ MLOps ແລະ ການລວມເຂົ້າໃນການດຳເນີນງານ
AI Observability ຖືເປັນສ່ວນຂະຫຍາຍຂອງ mlops, ແຕ່ເປັນແນວຄິດທີ່ເນັ້ນໃສ່ການດຳເນີນງານໃນສະພາບແວດລ້ອມຈິງຫຼາຍກວ່າ. ໃນຂະນະທີ່ MLOps ຈັດການກັບທໍ່ສົ່ງ (pipeline) ຂອງການຮຽນຮູ້ ແລະ ການນຳໃຊ້ແບບຈຳລອງທັງໝົດ, Observability ຈະເນັ້ນໃສ່ການຕິດຕາມຢ່າງຕໍ່ເນື່ອງຫຼັງຈາກການນຳໃຊ້ (deploy).
ຖ້ານຳໃຊ້ແນວຄິດ shift-left, ການລວມກົນໄກການປະເມີນຄຸນນະພາບເຂົ້າໄປຕັ້ງແຕ່ຂັ້ນຕອນການພັດທະນານັ້ນຖືເປັນສິ່ງທີ່ເໝາະສົມທີ່ສຸດ. ແທນທີ່ຈະແກ້ໄຂບັນຫາຫຼັງຈາກທີ່ມັນເກີດຂຶ້ນໃນສະພາບແວດລ້ອມຈິງ, ການນຳໃຊ້ຮ່ວມກັບ [ai-guardrails](ກົນໄກປ້ອງກັນ AI) ຈະສາມາດຍັບຍັ້ງການເກີດບັນຫາຕັ້ງແຕ່ຕົ້ນ.
ນອກຈາກນີ້, ການເຊື່ອມໂຍງກັບ hitl ກໍເປັນການຕັດສິນໃຈອອກແບບທີ່ສຳຄັນ. ການມີກົນໄກສົ່ງຕໍ່ໃຫ້ມະນຸດກວດສອບໂດຍອັດຕະໂນມັດເມື່ອ Observability ກວດພົບຄວາມຜິດປົກກະຕິ ຈະຊ່ວຍເພີ່ມປະສິດທິຜົນຂອງ [ai-governance](ການຄຸ້ມຄອງ AI).
ຂໍ້ຄວນລະວັງໃນການນຳໃຊ້
ສິ່ງທີ່ມັກຈະຖືກມອງຂ້າມໃນການຈັດຕັ້ງປະຕິບັດ Observability ຄື ການແລກປ່ຽນກັບຄວາມເປັນສ່ວນຕົວ (Privacy trade-off). ຍິ່ງບັນທຶກຂໍ້ມູນການປ້ອນເຂົ້າ-ອອກລະອຽດເທົ່າໃດ, ຄວາມຖືກຕ້ອງໃນການຕິດຕາມກໍຍິ່ງສູງຂຶ້ນ, ແຕ່ການເກັບຮັກສາຂໍ້ມູນທີ່ມີຂໍ້ມູນສ່ວນຕົວ ຫຼື ຂໍ້ມູນລັບຢ່າງບໍ່ຈຳກັດຈະກາຍເປັນຄວາມສ່ຽງດ້ານການປະຕິບັດຕາມກົດລະບຽບ (compliance). ດັ່ງທີ່ໄດ້ມີການເຕືອນໃນບໍລິບົດຂອງ [shadow-ai](AI ທີ່ບໍ່ໄດ້ຮັບອະນຸຍາດ), ຂອບເຂດ ແລະ ໄລຍະເວລາໃນການເກັບຮັກສາບັນທຶກຂໍ້ມູນຕ້ອງຖືກກຳນົດພາຍໃຕ້ນະໂຍບາຍທີ່ຊັດເຈນ.
ຍິ່ງໄປກວ່ານັ້ນ, ໃນ [agentic-ai](AI ຕົວແທນ) ທີ່ມີການປັບປຸງຕົນເອງຢ່າງຕໍ່ເນື່ອງ ເຊັ່ນ: [agentic-flywheel](ວົງຈອນການພັດທະນາຂອງ AI ຕົວແທນ), ພື້ນທີ່ການເຄື່ອນໄຫວທີ່ຖືກຕິດຕາມຈະຂະຫຍາຍຕົວແບບເຄື່ອນໄຫວ, ເຮັດໃຫ້ບາງຄັ້ງການຕິດຕາມດ້ວຍກົດເກນຄົງທີ່ (rule-based) ອາດຈະຕາມບໍ່ທັນ. ມັນເປັນສິ່ງສຳຄັນທີ່ຈະຕ້ອງເຂົ້າໃຈວ່າ AI Observability ບໍ່ແມ່ນສິ່ງທີ່ເຮັດຄັ້ງດຽວແລ້ວຈົບ, ແຕ່ເປັນສິ່ງທີ່ຕ້ອງທົບທວນຢ່າງຕໍ່ເນື່ອງຕາມວິວັດທະນາການຂອງລະບົບ.
