AI Observersability (ການສັງເກດການ AI) ແມ່ນກົນໄກໃນການເຮັດໃຫ້ຂະບວນການປ້ອນຂໍ້ມູນ, ການປະມວນຜົນ ແລະ ການສະແດງຜົນຂອງແອັບພລິເຄຊັນ LLM ສາມາດເບິ່ງເຫັນໄດ້ ເພື່ອຕິດຕາມ ແລະ ປັບປຸງຄຸນນະພາບ, ຕົ້ນທຶນ ແລະ Latency ຢ່າງຕໍ່ເນື່ອງ.

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

ບົດຄວາມນີ້ມີຈຸດປະສົງເພື່ອໃຫ້ຜູ້ຮັບຜິດຊອບການດຳເນີນງານ LLM App, MLOps Engineers, ແລະ Product Managers ໄດ້ເຂົ້າໃຈຢ່າງເປັນລະບົບ ຕັ້ງແຕ່ແນວຄວາມຄິດພື້ນຖານຂອງ AI Observability, ຂັ້ນຕອນການນຳໃຊ້, ໄປຈົນເຖິງຈຸດສຳຄັນໃນການເລືອກເຄື່ອງມື. ເມື່ອອ່ານຈົບ, ທ່ານຈະມີຄວາມຊັດເຈນວ່າຄວນວັດແທກຫຍັງແດ່ສຳລັບການດຳເນີນງານ LLM ຂອງບໍລິສັດທ່ານ.

AI Observability (AI ການສັງເກດການ) ໝາຍເຖິງກົນໄກໃນການເບິ່ງເຫັນ ແລະ ວັດແທກສະຖານະພາຍໃນຂອງແອັບພລິເຄຊັນທີ່ໃຊ້ LLM (Large Language Model) ຢ່າງຕໍ່ເນື່ອງ. ຈຸດເດັ່ນຂອງມັນບໍ່ແມ່ນພຽງແຕ່ການຕິດຕາມສະຖານະການເຮັດວຽກເທົ່ານັ້ນ, ແຕ່ຍັງສາມາດເຂົ້າໃຈເຖິງການໂຕ້ຕອບລະຫວ່າງ Prompt ແລະ ຄຳຕອບ, ປະລິມານການໃຊ້ Token, ລວມໄປເຖິງແນວໂນ້ມການເກີດ Hallucination ໄດ້ຢ່າງຮອບດ້ານ.

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

APM (Application Performance Management) ແບບດັ້ງເດີມຈະຕິດຕາມກວດກາໂດຍອີງໃສ່ ຕົວຊີ້ວັດທາງຕົວເລກ ເປັນຫຼັກ ເຊັ່ນ: ຄວາມໜ່ວງ (Latency), ອັດຕາຄວາມຜິດພາດ (Error rate), ແລະ ປະລິມານການປະມວນຜົນ (Throughput). ສ່ວນ MLOps ຈະຕິດຕາມການປ່ຽນແປງຂອງຄຸນລັກສະນະ (Feature drift) ແລະ ການຫຼຸດລົງຂອງຄວາມແມ່ນຍຳຂອງຕົວແບບ (Model degradation). ທັງສອງຢ່າງນີ້ຖືກອອກແບບມາໂດຍມີເງື່ອນໄຂເບື້ອງຕົ້ນວ່າ "ສາມາດກຳນົດຄຳຕອບທີ່ຖືກຕ້ອງໄດ້".

ແອັບພລິເຄຊັນທີ່ໃຊ້ LLM (Large Language Model) ເຮັດໃຫ້ເງື່ອນໄຂເບື້ອງຕົ້ນນີ້ບໍ່ສາມາດນຳໃຊ້ໄດ້.

ຄວາມແຕກຕ່າງຫຼັກຈາກ APM ແລະ MLOps

• ຜົນລັພມີລັກສະນະເປັນຄວາມໜ້າຈະເປັນ (Probabilistic): ເຖິງແມ່ນວ່າຈະເປັນ Input ດຽວກັນ ແຕ່ກໍຈະໄດ້ຂໍ້ຄວາມທີ່ແຕກຕ່າງກັນໃນທຸກຄັ້ງ ເຮັດໃຫ້ຍາກທີ່ຈະຕັດສິນໂດຍອັດຕະໂນມັດວ່າເປັນຄວາມຜິດພາດ ຫຼື ເປັນປົກກະຕິ
• ຄຸນນະພາບມີລັກສະນະເປັນອັດຕະວິໄສ (Subjective): "ຄຳຕອບຖືກຕ້ອງຫຼືບໍ່" ຫຼື "ນ້ຳສຽງເໝາະສົມຫຼືບໍ່" ບໍ່ສາມາດວັດແທກໄດ້ດ້ວຍຕົວເລກພຽງຢ່າງດຽວ
• Input ມີລັກສະນະບໍ່ມີໂຄງສ້າງ (Unstructured): Prompt ທີ່ຂຽນໄດ້ຢ່າງອິດສະຫຼະນັ້ນ ແຕກຕ່າງຈາກ API Request ແບບມີຮູບແບບ (Typed) ໃນສະໄໝກ່ອນ ເຊິ່ງມີຮູບແບບທີ່ບໍ່ຄາດຄິດເກີດຂຶ້ນໄດ້ຢ່າງບໍ່ມີຂີດຈຳກັດ
• ຕົ້ນທຶນມີລັກສະນະເຄື່ອນໄຫວ (Dynamic): ຕົ້ນທຶນການອະນຸມານ (Inference cost) ຈະປ່ຽນແປງໄປຕາມຈຳນວນ Token ເຮັດໃຫ້ບໍ່ສາມາດບໍລິຫານຈັດການດ້ວຍຈຳນວນ Request ແບບງ່າຍໆໄດ້

ການກວດຈັບ Data drift ທີ່ໃຊ້ໃນ MLOps ເປັນວິທີການຈັບການປ່ຽນແປງທາງສະຖິຕິຂອງ Vector ຄຸນລັກສະນະ. ແຕ່ສຳລັບ LLM, ຈຳເປັນຕ້ອງຕິດຕາມ ການຫຼຸດລົງໃນລະດັບຄວາມໝາຍ ເຊັ່ນ: ຄວາມຄາດເຄື່ອນທາງຄວາມໝາຍຂອງ Prompt ຫຼື ການເພີ່ມຂຶ້ນຂອງ Hallucination.

AI Observability ເປັນແນວຄິດທີ່ປະກົດຂຶ້ນມາເພື່ອອັດຊ່ອງຫວ່າງເຫຼົ່ານີ້. ມັນເປັນການລວມເອົາການຕິດຕາມ (Trace), ການປະເມີນຜົນ (Evaluation), ແລະ ການບໍລິຫານຈັດການຕົ້ນທຶນເຂົ້າດ້ວຍກັນ ເພື່ອຮັບມືກັບຄວາມຊັບຊ້ອນສະເພາະຕົວຂອງ LLM. ມັນຈະເຂົ້າໃຈໄດ້ງ່າຍຂຶ້ນຫາກເບິ່ງວ່າມັນບໍ່ແມ່ນການຂະຫຍາຍຕົວຈາກໂຄງສ້າງພື້ນຖານ ຫຼື Infrastructure ຂອງ Observability ທີ່ມີຢູ່ແລ້ວ ແຕ່ເປັນ ກອບການຕິດຕາມກວດກາທີ່ຖືກອອກແບບໃໝ່ໃຫ້ສອດຄ່ອງກັບຄຸນລັກສະນະຂອງ LLM.

ແອັບພລິເຄຊັນທີ່ຝັງ LLM (Large Language Model) ເຂົ້າມານັ້ນ ມີຄວາມຫຍຸ້ງຍາກໃນການຕິດຕາມກວດກາທີ່ແຕກຕ່າງຈາກຊອບແວແບບດັ້ງເດີມຢ່າງສິ້ນເຊີງ. ພຶດຕິກຳຂອງໂຄ້ດແມ່ນມີລັກສະນະກຳນົດໄດ້ (Deterministic) ແຕ່ຜົນລັດຂອງ LLM ແມ່ນມີລັກສະນະເປັນຄວາມໜ້າຈະເປັນ (Probabilistic) ເຊິ່ງການປ້ອນຂໍ້ມູນແບບດຽວກັນກໍອາດຈະໄດ້ຮັບຄຳຕອບທີ່ແຕກຕ່າງກັນໃນທຸກໆຄັ້ງ. ນີ້ຄືປັດໄຈທີ່ໃຫຍ່ທີ່ສຸດທີ່ເຮັດໃຫ້ການອອກແບບການຕິດຕາມກວດກາມີຄວາມຊັບຊ້ອນ.

ເມື່ອສະຫຼຸບປະເດັນສຳຄັນຕ່າງໆ ສາມາດຍົກມາໄດ້ 4 ຂໍ້ ດັ່ງນີ້:

• ການວັດແທກຄຸນນະພາບຂອງຜົນລັດແມ່ນເຮັດໄດ້ຍາກ: ເຖິງແມ່ນວ່າລະຫັດການຕອບສະໜອງຂອງ API ຈະເປັນ 200 ແຕ່ກໍອາດຈະເກີດ Hallucination ທີ່ຄຳຕອບບໍ່ກົງກັບຄວາມເປັນຈິງໄດ້. "ການເຮັດວຽກໄດ້" ແລະ "ການຕອບຢ່າງຖືກຕ້ອງ" ແມ່ນຄົນລະບັນຫາກັນ.
• ການຈັດການ Context Window: ເມື່ອຈຳນວນ Token ທັງໝົດຂອງ Prompt ລວມເຖິງປະຫວັດການສົນທະນາ ແລະ ຜົນການຄົ້ນຫາຈາກ RAG ເພີ່ມຂຶ້ນ ກໍຈະນຳໄປສູ່ການເພີ່ມຂຶ້ນຂອງຕົ້ນທຶນຢ່າງກະທັນຫັນ ແລະ ການຕອບສະໜອງທີ່ຊ້າລົງ. ຈຶ່ງມີຄວາມຈຳເປັນຕ້ອງມີກົນໄກໃນການຕິດຕາມການປ່ຽນແປງນັ້ນແບບ Real-time.
• ຄວາມຊັບຊ້ອນຂອງ Chain ແລະ Agent: ໃນລະບົບ Compound AI System ຫຼື AI Agent ຈະມີການເອີ້ນໃຊ້ LLM ຫຼາຍຄັ້ງ ແລະ ການປະຕິບັດງານຂອງເຄື່ອງມືຕ່າງໆທີ່ເຊື່ອມໂຍງກັນ. ເພື່ອລະບຸໃຫ້ໄດ້ວ່າຄຸນນະພາບຫຼຸດລົງໃນຂັ້ນຕອນໃດນັ້ນ, ການເຮັດ End-to-end trace ແມ່ນສິ່ງທີ່ຂາດບໍ່ໄດ້.
• ຄວາມສ່ຽງດ້ານຄວາມປອດໄພ ເຊັ່ນ: Prompt Injection: ໃນ RAG ຫຼື Agent ທີ່ຈັດການກັບຂໍ້ມູນພາຍນອກ, ການປ້ອນຂໍ້ມູນທີ່ບໍ່ຫວັງດີອາດເຮັດໃຫ້ພຶດຕິກຳປ່ຽນແປງໄປ. ເຊິ່ງສິ່ງນີ້ບໍ່ສາມາດກວດຫາໄດ້ດ້ວຍການສະແກນຫາຊ່ອງໂຫວ່ຂອງໂຄ້ດແບບທົ່ວໄປ.

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

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

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

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

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

ຄວາມສ່ຽງຫຼັກສາມາດແບ່ງອອກໄດ້ເປັນ 3 ປະການດັ່ງນີ້:

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

ຍິ່ງໄປກວ່ານັ້ນ, ເມື່ອການຈັດການ AI agent ມີຄວາມຊັບຊ້ອນຫຼາຍຂຶ້ນ, ການລະບຸວ່າການເອີ້ນໃຊ້ LLM ໃດທີ່ກາຍເປັນຄໍຂວດ (Bottleneck) ໂດຍເບິ່ງພຽງແຕ່ Log ນັ້ນກໍເປັນເລື່ອງຍາກ. ເຖິງແມ່ນວ່າ Latency ຈະເພີ່ມຂຶ້ນຢ່າງກະທັນຫັນ, ແຕ່ການແຍກແຍະວ່າສາເຫດມາຈາກຝັ່ງ Model ຫຼື ຝັ່ງການເອີ້ນໃຊ້ເຄື່ອງມືນັ້ນ, ການເຮັດ Tracing ທີ່ມີຄວາມລະອຽດສູງຈຶ່ງເປັນສິ່ງທີ່ຂາດບໍ່ໄດ້.

ສຳລັບ agent ທີ່ເຮັດວຽກແບບອັດຕະໂນມັດເຕັມຮູບແບບໂດຍບໍ່ມີກົນໄກ HITL (Human-in-the-Loop), ຄວາມສ່ຽງທີ່ບໍ່ມີໃຜສັງເກດເຫັນບັນຫາຈົນກວ່າບັນຫານັ້ນຈະປາກົດອອກມາຈະເພີ່ມສູງຂຶ້ນ. AI Observability ເຮັດໜ້າທີ່ເປັນພື້ນຖານໃນການກວດຫາຄວາມສ່ຽງເຫຼົ່ານີ້ແຕ່ຫົວທີ ແລະ ສະໜັບສະໜູນການດຳເນີນງານໃນລະບົບຈິງໃຫ້ມີຄວາມປອດໄພ.

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

ປັດໄຈທີ່ຊຸກຍູ້ໃຫ້ເກີດການປ່ຽນແປງນີ້ມີຫຼາຍປະການ:

• ການເພີ່ມຂຶ້ນຂອງບັນຫາໃນລະບົບການຜະລິດ: ມີບໍລິສັດຫຼາຍຂຶ້ນທີ່ນຳເອົາ LLM ມາລວມເຂົ້າກັບ Chatbot ຫຼື ລະບົບຄົ້ນຫາພາຍໃນ, ເຊິ່ງມີການລາຍງານກໍລະນີທີ່ Hallucination ແລະ ການຫຼຸດລົງຂອງຄຸນນະພາບການຕອບໂຕ້ສົ່ງຜົນກະທົບຕໍ່ການດຳເນີນງານ
• ຄວາມຈຳເປັນໃນການຄວບຄຸມຕົ້ນທຶນ: ສຳລັບ LLM ທີ່ມີການຄິດໄລ່ຄ່າໃຊ້ຈ່າຍຕາມຈຳນວນ Token, ມັກຈະມີທ່າອ່ຽງທີ່ຄ່າໃຊ້ຈ່າຍ API ເພີ່ມຂຶ້ນຫາກບໍ່ມີການຕິດຕາມກວດກາ
• ການເພີ່ມຄວາມເຂັ້ມງວດຂອງຂໍ້ກຳນົດດ້ານການປະຕິບັດຕາມກົດລະບຽບ: ເລີ່ມຈາກການບັງຄັບໃຊ້ EU AI Act, ການວາງລະບຽບກົດໝາຍດ້ານ AI Governance ກຳລັງມີຄວາມຄືບໜ້າໃນຫຼາຍປະເທດ, ເຮັດໃຫ້ມີຄວາມຕ້ອງການລະບົບທີ່ສາມາດຮັກສາ ແລະ ອະທິບາຍບັນທຶກການເຮັດວຽກຂອງ Model ໄດ້

ໃນດ້ານເຄື່ອງມືກໍມີທາງເລືອກທີ່ຫຼາກຫຼາຍຂຶ້ນ. ແພລດຟອມສະເພາະທາງເຊັ່ນ LangSmith, Langfuse ແລະ Arize ໄດ້ເປີດຕົວ ຫຼື Launch ຢ່າງຕໍ່ເນື່ອງ ແລະ ຍັງມີຜະລິດຕະພັນທີ່ສາມາດລວມ ຫຼື Merge ເຂົ້າກັບ MLOps Stack ທີ່ມີຢູ່ໄດ້. ຜູ້ໃຫ້ບໍລິການ Cloud ກໍເລີ່ມສະເໜີຟັງຊັນການຕິດຕາມກວດກາ LLM ໃນຮູບແບບ Managed Service ເຮັດໃຫ້ອຸປະສັກໃນການນຳໃຊ້ຫຼຸດລົງ.

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

ເພື່ອໃຫ້ AI Observability ສາມາດເຮັດວຽກໄດ້ຢ່າງມີປະສິດທິພາບ, ຈຳເປັນຕ້ອງແຍກແຍະເປົ້າໝາຍໃນການຕິດຕາມກວດກາອອກເປັນສ່ວນໆຢ່າງເໝາະສົມ. ໃນການດຳເນີນງານຂອງແອັບພລິເຄຊັນ LLM (Large Language Model), 4 ເສົາຫຼັກທີ່ປະກອບສ່ວນເຊິ່ງກັນແລະກັນໄດ້ແກ່: ການຕິດຕາມ (Tracing), ການປະເມີນຜົນ (Evaluation), ການຈັດການຕົ້ນທຶນ (Cost Management) ແລະ ການປັບແຕ່ງ Latency ໃຫ້ເໝາະສົມ.

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

Tracing ແມ່ນກົນໄກໃນການບັນທຶກ ແລະ ເຮັດໃຫ້ເຫັນພາບລວມຂອງຂະບວນການເຮັດວຽກທັງໝົດ ຕັ້ງແຕ່ການປ້ອນຂໍ້ມູນຂອງຜູ້ໃຊ້ໄປຈົນເຖິງຜົນລວມຂອງ LLM. ມັນທຽບເທົ່າກັບ Distributed Tracing ຂອງ Web App ແຕ່ມີຄວາມແຕກຕ່າງກັນຢ່າງຫຼວງຫຼາຍກົງທີ່ມີອົງປະກອບສະເພາະຂອງ LLM ເພີ່ມເຂົ້າມາ.

ອົງປະກອບຫຼັກທີ່ຄວນບັນທຶກໃນ LLM Trace

• System Prompt ແລະ ການປ້ອນຂໍ້ມູນຕົວຈິງຂອງຜູ້ໃຊ້
• ຈຳນວນ Token, Latency ແລະ ຊື່ Model ຂອງການຮຽກໃຊ້ LLM ແຕ່ລະຄັ້ງ
• ໃນກໍລະນີທີ່ໃຊ້ RAG ໃຫ້ບັນທຶກ Search Query ແລະ ເນື້ອໃນຂອງ Chunk ທີ່ດຶງມາໄດ້
• Argument ແລະ ຄ່າທີ່ສົ່ງກັບຄືນມາຈາກການຮຽກໃຊ້ Tool
• ຈັງຫວະການເກີດ Error ແລະ ການ Retry

ໃນໂຄງສ້າງທີ່ມີການຮຽກໃຊ້ LLM ຫຼາຍຄັ້ງເຊັ່ນ: Multi-agent System ຫຼື Agentic RAG, ການລະບຸວ່າຄຸນນະພາບຫຼຸດລົງໃນຂັ້ນຕອນໃດນັ້ນແມ່ນມີຄວາມຫຍຸ້ງຍາກເປັນພິເສດ. ການກຳນົດ Trace ID ໃຫ້ກັບແຕ່ລະ Span ເພື່ອຮັກສາຄວາມສຳພັນແບບພໍ່-ລູກ (Parent-child relationship) ຈະຊ່ວຍໃຫ້ສາມາດນຳກັບມາສ້າງໃໝ່ (Reproduce) ໄດ້ໃນພາຍຫຼັງວ່າ "Sub-agent ໃດ ໄດ້ຮັບຂໍ້ມູນນຳເຂົ້າໃດ".

ຕົວຢ່າງທົ່ວໄປຂອງ Before/After

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

ຖ້າຫາກມີ Trace: ສາມາດລະບຸ ID ຂອງການຮຽກໃຊ້ທີ່ມີບັນຫາ ແລະ ສາມາດນຳຂໍ້ມູນ Input, Output ແລະ ເນື້ອໃນຂອງ Context Window ມາສ້າງໃໝ່ໄດ້ພາຍໃນເວລາບໍ່ເທົ່າໃດນາທີ.

ໃນດ້ານການຈັດຕັ້ງປະຕິບັດ, ເຄື່ອງມືຫຼາຍຢ່າງໄດ້ນຳໃຊ້ SDK ທີ່ອີງໃສ່ OpenTelemetry ເຊິ່ງງ່າຍຕໍ່ການເຊື່ອມໂຍງກັບໂຄງສ້າງພື້ນຖານ ຫຼື Infrastructure ຂອງ APM ທີ່ມີຢູ່ແລ້ວ. ຢ່າງໃດກໍຕາມ, ໃນກໍລະນີທີ່ພາຍໃນ Prompt ມີຂໍ້ມູນສ່ວນຕົວ, ຈຳເປັນຕ້ອງໄດ້ອອກແບບຂະບວນການ Masking ຂໍ້ມູນ Trace ໄວ້ລ່ວງໜ້າ. "ການປະເມີນຜົນ" (Evaluation) ທີ່ຈະກ່າວເຖິງໃນພາກຕໍ່ໄປນັ້ນ ຈະເຮັດວຽກໂດຍໃຊ້ຂໍ້ມູນ Trace ນີ້ເປັນ Input, ດັ່ງນັ້ນ ຄວາມລະອຽດຂອງ Tracing ຈຶ່ງມີຜົນຕໍ່ຄວາມຖືກຕ້ອງຂອງການປະເມີນຜົນ.

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

ໃນການວັດແທກຄຸນນະພາບໂດຍອັດຕະໂນມັດ, ຕົວຊີ້ວັດຕໍ່ໄປນີ້ຖືກນຳມາໃຊ້ເປັນຫຼັກ:

• ຄວາມຖືກຕ້ອງ (Correctness): ກວດສອບວ່າຄຳຕອບສອດຄ່ອງກັບຄວາມເປັນຈິງຫຼືບໍ່ ໂດຍການທຽບກັບແຫຼ່ງອ້າງອີງຂອງ RAG (Retrieval-Augmented Generation)
• ຄວາມຊື່ສັດ (Faithfulness): ວັດແທກວ່າມີການສ້າງຂໍ້ມູນທີ່ບໍ່ໄດ້ລວມຢູ່ໃນຜົນການຄົ້ນຫາ ຫຼື ມີການເກີດ Hallucination ຫຼືບໍ່
• ຄວາມກ່ຽວຂ້ອງ (Relevance): ຄຳນວນລະດັບຄວາມສອດຄ່ອງທາງຄວາມໝາຍລະຫວ່າງຄຳຖາມຂອງຜູ້ໃຊ້ກັບຄຳຕອບ ໂດຍໃຊ້ຄະແນນຄວາມຄ້າຍຄືກັນຂອງການຄົ້ນຫາແບບ Semantic
• ຄວາມເປັນພິດ/ຄວາມປອດໄພ (Toxicity/Safety): ກວດຫາການສະແດງອອກທີ່ບໍ່ເໝາະສົມ ຫຼື ເນື້ອຫາທີ່ຈຳແນກປະຕິບັດ ໂດຍໃຊ້ AI Guardrails

ການກວດສອບສິ່ງເຫຼົ່ານີ້ດ້ວຍຕົນເອງຈະໃຊ້ແຮງງານຢ່າງມະຫາສານ. ດັ່ງນັ້ນ, ຈຶ່ງມີການນຳໃຊ້ວິທີການທີ່ເອີ້ນວ່າ "LLM-as-a-Judge" ຢ່າງແຜ່ຫຼາຍ. ໂດຍ LLM ອີກຕົວໜຶ່ງຈະເຮັດໜ້າທີ່ເປັນຜູ້ປະເມີນເພື່ອໃຫ້ຄະແນນ ເຊິ່ງເຮັດໜ້າທີ່ແທນການກວດສອບ Grounding Check ໂດຍມະນຸດ.

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

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

ໃນການນຳໃຊ້ LLM ໃນລະບົບຕົວຈິງ, ການຈັດການດ້ານຕົ້ນທຶນ ແລະ ຄວາມໜ່ວງ (Latency) ຖືເປັນສິ່ງທ້າທາຍຢ່າງຕໍ່ເນື່ອງຄຽງຄູ່ກັບຄຸນນະພາບ. ເນື່ອງຈາກຕົ້ນທຶນມີການປ່ຽນແປງຢ່າງຫຼວງຫຼາຍຕາມຈຳນວນ Token ໃນການໂທ API ແຕ່ລະຄັ້ງ ແລະ ການເລືອກໃຊ້ Model, ການປັບໃຫ້ເໝາະສົມໂດຍບໍ່ມີການເບິ່ງເຫັນພາບລວມ (Visualization) ຈຶ່ງເປັນເລື່ອງທີ່ຍາກ.

AI Observability ຈະເຮັດການວັດແທກ ແລະ ບັນທຶກຕົວຊີ້ວັດຕໍ່ໄປນີ້ແບບ Real-time:

• ປະລິມານການໃຊ້ Token: ຈຳນວນ Token ຂາເຂົ້າ/ຂາອອກ ຂອງ Prompt ແລະ ຜົນລວມທີ່ໄດ້ຮັບ
• ລາຍລະອຽດຄວາມໜ່ວງ (Latency): Time to First Token (TTFT) ແລະ ເວລາຕອບສະໜອງທັງໝົດ
• ຕົ້ນທຶນແຍກຕາມ Model: ຕົ້ນທຶນປຽບທຽບໃນກໍລະນີທີ່ມີການໃຊ້ຫຼາຍ Model ສະຫຼັບກັນ
• ອັດຕາການໃຊ້ Cache (Cache Hit Rate): ສະຖານະການນຳໃຊ້ Prompt ເດີມ ຫຼື Prompt ທີ່ຄ້າຍຄືກັນກັບມາໃຊ້ໃໝ່

ການບັນທຶກຂໍ້ມູນເຫຼົ່ານີ້ຢ່າງຕໍ່ເນື່ອງ ຈະຊ່ວຍໃຫ້ສາມາດລະບຸໄດ້ວ່າ "Prompt ໃດມີຕົ້ນທຶນສູງ" ຫຼື "ຂັ້ນຕອນໃດເປັນຄໍຂວດ (Bottleneck)". ຕົວຢ່າງເຊັ່ນ: ໃນກໍລະນີທີ່ມີການໃສ່ຂໍ້ມູນທີ່ບໍ່ຈຳເປັນລົງໃນ Context Window, ມັກຈະສາມາດຫຼຸດຈຳນວນ Token ໄດ້ດ້ວຍການບີບອັດ Prompt.

ສຳລັບຄວາມໜ່ວງ, ໃນການອະນຸມານຫຼາຍຂັ້ນຕອນ (Multi-step inference) ໂດຍໃຊ້ Agent Orchestration, ຄວາມຊັກຊ້າໃນແຕ່ລະຂັ້ນຕອນມັກຈະສະສົມເພີ່ມທະວີຂຶ້ນເລື້ອຍໆ. ມີລາຍງານວ່າ ການເບິ່ງເຫັນພາບລວມຂອງເວລາທີ່ໃຊ້ໃນແຕ່ລະຂັ້ນຕອນຜ່ານຂໍ້ມູນ Trace ຈະຊ່ວຍໃຫ້ພົບເຫັນຂະບວນການທີ່ສາມາດເຮັດວຽກແບບຂະໜານໄດ້ ຫຼື ຂັ້ນຕອນທີ່ສາມາດປ່ຽນໄປໃຊ້ SLM (Small Language Model) ທີ່ມີນ້ຳໜັກເບົາກວ່າໄດ້.

ແນວຄິດພື້ນຖານໃນການປັບໃຫ້ເໝາະສົມມີດັ່ງນີ້:

• Routing ໄປຫາ Model ທີ່ມີລາຄາຖືກ ແລະ ໄວສຳລັບວຽກທີ່ມີຄວາມສຳຄັນຕໍ່າ
• ນຳໃຊ້ຍຸດທະສາດການໃຊ້ Cache ສຳລັບ Prompt ທີ່ມີການໂທຊ້ຳໆ
• ກວດສອບຕົ້ນທຶນເປັນໄລຍະເພື່ອໃຫ້ສາມາດກວດພົບການໃຊ້ງານທີ່ຜິດປົກກະຕິໄດ້ຢ່າງວ່ອງໄວ

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

ຕະຫຼາດເຄື່ອງມື AI Observability ກຳລັງຂະຫຍາຍຕົວຢ່າງວ່ອງໄວ, ໂດຍມີທາງເລືອກຫຼາກຫຼາຍຕັ້ງແຕ່ OSS ໄປຈົນເຖິງແພລດຟອມທາງການຄ້າ. ຖ້າເລືອກເຄື່ອງມືທີ່ບໍ່ເໝາະສົມກັບກໍລະນີການນຳໃຊ້ (Use case) ຫຼື ໂຄງສ້າງການພັດທະນາຂອງບໍລິສັດ, ກໍມີຄວາມສ່ຽງທີ່ຕົ້ນທຶນການດຳເນີນງານຈະເພີ່ມທະວີຂຶ້ນເລື້ອຍໆ ຫຼັງຈາກການນຳໃຊ້.

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

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

ທາງເລືອກຫຼັກຂອງ OSS (Open Source Software)

• Langfuse: OSS ພາຍໃຕ້ໃບອະນຸຍາດ MIT ທີ່ໃຫ້ບໍລິການດ້ານການຕິດຕາມ (Trace), ການປະເມີນຜົນ ແລະ ການຈັດການ Prompt ໄວ້ໃນບ່ອນດຽວ. ຮອງຮັບການ Self-host ຢ່າງເຕັມຮູບແບບ ແລະ ສາມາດໃຊ້ງານເວີຊັນ Cloud ໄດ້.
• Phoenix (ຜະລິດໂດຍ Arize AI): ເລີ່ມຕົ້ນໃຊ້ງານໃນເຄື່ອງ (Local) ໄດ້ງ່າຍ, ເໝາະສົມສຳລັບການກວດສອບໃນຂັ້ນຕອນ PoC.
• OpenLLMetry (ຜະລິດໂດຍ Traceloop): ອີງຕາມ OpenTelemetry ເຊິ່ງງ່າຍຕໍ່ການລວມເຂົ້າກັບ Stack ການຕິດຕາມກວດກາທີ່ມີຢູ່ແລ້ວ.

ຈຸດແຂງຂອງ OSS ແມ່ນຄວາມສາມາດໃນການປັບແຕ່ງ ແລະ ການຄວບຄຸມຕົ້ນທຶນ. ໃນທາງກົງກັນຂ້າມ, ຕ້ອງລະວັງເລື່ອງການຈັດການ ໂຄງສ້າງພື້ນຖານ ຫຼື Infrastructure ແລະ ການອັບເດດ Security Patch ເມື່ອມີການຂະຫຍາຍລະບົບ (Scale-out) ເຊິ່ງບໍລິສັດຕ້ອງຮັບຜິດຊອບເອງ.

ທາງເລືອກຫຼັກຂອງແພລັດຟອມທາງການຄ້າ

• LangSmith (ຜະລິດໂດຍ LangChain): ມີການເຊື່ອມໂຍງກັບລະບົບນິເວດຂອງ LangChain ຢ່າງເລິກເຊິ່ງ, ໃຫ້ບໍລິການດ້ານການຕິດຕາມ (Trace), ການປະເມີນຜົນ ແລະ ການຈັດການຊຸດຂໍ້ມູນໄວ້ໃນບ່ອນດຽວ. ຮອງຮັບການ Self-host ຜ່ານສັນຍາ Enterprise.
• Arize AI: ຮອງຮັບການກວດຫາ Drift ຂອງ Traffic ໃນການຜະລິດຈິງ ແລະ ການເຮັດ A/B Testing.
• Datadog LLM Observability: ງ່າຍຕໍ່ການລວມເຂົ້າກັບ APM ແລະ ພື້ນຖານ Log ທີ່ມີຢູ່ແລ້ວ.

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

ມາດຕະຖານໃນການຕັດສິນໃຈ

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

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

ການເຊື່ອມໂຍງ ແລະ ຄວາມເຂົ້າກັນໄດ້

• ຮອງຮັບ SDK ຂອງຜູ້ໃຫ້ບໍລິການ LLM ທີ່ກຳລັງໃຊ້ງານຢູ່ (OpenAI, Anthropic, Google ແລະ ອື່ນໆ) ຫຼືບໍ່?
• ມີການເຊື່ອມໂຍງແບບ Native ກັບ Framework ຕ່າງໆ ເຊັ່ນ LangChain, LlamaIndex ຫຼືບໍ່?
• ສາມາດເຊື່ອມຕໍ່ກັບ Stack ການຕິດຕາມກວດກາທີ່ມີຢູ່ແລ້ວ ເຊັ່ນ Datadog, Grafana ຫຼືບໍ່?

ຟັງຊັນການຕິດຕາມ (Tracing)

• ສາມາດບັນທຶກ Prompt, Completion ແລະ ການຮຽກໃຊ້ Tool ເປັນລາຍ Span ໄດ້ຫຼືບໍ່?
• ຮອງຮັບການຕິດຕາມແບບກະຈາຍ (Distributed Trace) ທີ່ກວມເອົາຫຼາຍ Hop ຂອງລະບົບ Multi-agent ຫຼືບໍ່?
• ສາມາດເຂົ້າໃຈສະຖານະການໃຊ້ງານ Context Window ໄດ້ແບບ Real-time ຫຼືບໍ່?

ການປະເມີນ ແລະ ການຄວບຄຸມຄຸນນະພາບ

• ມີການຝັງລະບົບກວດຈັບ Hallucination ແລະ ການກວດສອບ Grounding ໄວ້ພາຍໃນຫຼືບໍ່?
• ມີຄວາມສາມາດໃນການຂະຫຍາຍເພື່ອເພີ່ມການກຳນົດຕົວຊີ້ວັດການປະເມີນແບບກຳນົດເອງ (Custom) ໄດ້ຫຼືບໍ່?
• ສາມາດນຳເອົາການຕິຊົມຈາກມະນຸດ (HITL) ເຂົ້າໄປໃນວົງຈອນການປະເມີນໄດ້ຫຼືບໍ່?

ຕົ້ນທຶນ ແລະ ຄວາມປອດໄພ

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

ການດຳເນີນງານ ແລະ ການຂະຫຍາຍລະບົບ

• ຮອງຮັບການປັບອັດຕາການສຸ່ມຕົວຢ່າງ (Sampling rate) ໃນເວລາທີ່ມີ Traffic ສູງຫຼືບໍ່?
• ມີ Dashboard ສຳລັບການແບ່ງປັນ ແລະ ຈັດການເກນການແຈ້ງເຕືອນ (Alert threshold) ພາຍໃນທີມຫຼືບໍ່?

ໃນເວລາເລືອກ, ແນະນຳໃຫ້ເລີ່ມຈາກຂັ້ນຕອນ PoC ໂດຍໃຊ້ໂຄຕ້າຟຣີ ຫຼື OSS ເພື່ອທົດສອບລາຍການຂ້າງເທິງກັບ Workload ຕົວຈິງ. ເນື່ອງຈາກມີຫຼາຍກໍລະນີທີ່ຕົ້ນທຶນການເຊື່ອມໂຍງເພີ່ມທະວີຂຶ້ນເລື້ອຍໆ ຫຼັງຈາກຍ້າຍເຂົ້າສູ່ລະບົບການຜະລິດຈິງ, ດັ່ງນັ້ນ ຂໍໃຫ້ກວດສອບຄວາມສ່ຽງດ້ານ Vendor lock-in ໃຫ້ແນ່ໃຈສະເໝີ.

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

ໄລຍະການນຳໃຊ້ສາມາດແບ່ງອອກເປັນ 3 ຂັ້ນຕອນໃຫຍ່ໆ ດັ່ງນີ້:

• Step 1: ການໃສ່ Trace ເຂົ້າໄປໃນເສັ້ນທາງທີ່ສຳຄັນ
• Step 2: ການສ້າງຂະບວນການ ຫຼື Pipeline ການປະເມີນຜົນ
• Step 3: ການຈັດຕັ້ງລະບົບແຈ້ງເຕືອນ ແລະ Dashboard

ລາຍລະອຽດຂອງແຕ່ລະຂັ້ນຕອນຈະຖືກອະທິບາຍໃນຫົວຂໍ້ H3 ຕໍ່ໄປນີ້.

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

ວິທີການເລືອກເສັ້ນທາງສຳຄັນ

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

ຮູບແບບພື້ນຖານໃນການຈັດຕັ້ງປະຕິບັດ

ເຄື່ອງມື Observability ສ່ວນໃຫຍ່ສາມາດເຮັດການ Instrumentation ໄດ້ດ້ວຍ Decorator ຫຼື Context Manager. ຕົວຢ່າງ: ຖ້າເປັນ Python, ພຽງແຕ່ເພີ່ມໂຄ້ດສອງສາມແຖວໃສ່ໃນຟັງຊັນ ກໍສາມາດເຮັດໃຫ້ການເລີ່ມຕົ້ນ, ການສິ້ນສຸດ ແລະ ການກຳນົດ Attribute ຂອງ Span ສຳເລັດໄດ້. ຊຸດຂໍ້ມູນຂັ້ນຕໍ່າທີ່ຄວນບັນທຶກໄວ້ມີ 4 ລາຍການດັ່ງນີ້:

1. ເນື້ອຫາ Input Prompt ທັງໝົດ (ລວມເຖິງ System Prompt)
2. ຜົນລວມທີ່ໄດ້ຈາກການສ້າງຂອງ LLM
3. ຈຳນວນ Token ແລະ Latency
4. ຊື່ Model, ເວີຊັນ ແລະ ຄ່າ Temperature Parameter

ການຂະຫຍາຍຂອບເຂດແບບເປັນຂັ້ນຕອນ

ໃນໄລຍະ 1-2 ອາທິດທຳອິດ ໃຫ້ເປີດໃຊ້ງານ Trace ສະເພາະເສັ້ນທາງສຳຄັນເທົ່ານັ້ນ ເພື່ອກວດສອບວ່າ Log ມີການສົ່ງຂໍ້ມູນຕໍ່ໃຫ້ ຢ່າງປົກກະຕິ. ຫຼັງຈາກນັ້ນ, ຈຶ່ງຄ່ອຍໆຂະຫຍາຍໄປສູ່ຂັ້ນຕອນອື່ນໆທີ່ກ່ຽວຂ້ອງ ເຊັ່ນ: ການດຶງ Chunk ຂອງ RAG ຫຼື ການຮຽກໃຊ້ Tool. ການເລີ່ມຕົ້ນດ້ວຍຂະໜາດນ້ອຍ ແລະ ດຳເນີນການເພື່ອຄົ້ນຫາບັນຫາໃຫ້ພົບໂດຍໄວ ຈະຊ່ວຍຫຼຸດຜ່ອນການກັບມາແກ້ໄຂງານ (Rework) ໄດ້ດີກວ່າການເຮັດ Instrumentation ທັງໝົດໃນຄັ້ງດຽວ.

ທັງນີ້, ຖ້າຂໍ້ມູນ Input ມີຂໍ້ມູນສ່ວນບຸກຄົນລວມຢູ່ດ້ວຍ, ຈຳເປັນຕ້ອງມີຂະບວນການ Masking ກ່ອນທີ່ຈະບັນທຶກ Trace. ຄວນພິຈາລະນາເລື່ອງຂໍ້ກຳນົດດ້ານ Governance ແລະ ການອອກແບບ Instrumentation ໄປພ້ອມໆກັນ.

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

ໂຄງສ້າງພື້ນຖານຂອງ ຂະບວນການ ຫຼື Pipeline ການປະເມີນຜົນ ສາມາດແບ່ງອອກເປັນ 3 ຊັ້ນ ເພື່ອໃຫ້ງ່າຍຕໍ່ການຈັດການ:

• ການປະເມີນຜົນແບບອອນລາຍ (Online Evaluation): ສຸ່ມຕົວຢ່າງຄຳຮ້ອງຂໍຈາກລະບົບຈິງ ແບບ Real-time ແລະ ໃຫ້ LLM Judge ຊ່ວຍໃຫ້ຄະແນນໂດຍອັດຕະໂນມັດ ເພື່ອກວດສອບການເກີດ Hallucination ຫຼື ຜົນລັດທີ່ເປັນອັນຕະລາຍ.
• ການປະເມີນຜົນແບບອອບລາຍ (Offline Evaluation): ກວດສອບແບບ Batch ໂດຍໃຊ້ Golden Dataset ກ່ອນທີ່ຈະມີການປ່ຽນແປງ Prompt ຫຼື ປ່ຽນ Model.
• ການກວດສອບໂດຍມະນຸດ (Human-in-the-loop: HITL): ໃຫ້ມະນຸດເປັນຜູ້ກວດສອບ ແລະ ຕິດປ້າຍກຳກັບ (Labeling) ຕົວຢ່າງທີ່ໄດ້ຄະແນນຕ່ຳກວ່າເກນ ເພື່ອປັບປຸງມາດຕະຖານການປະເມີນຜົນໃຫ້ດີຂຶ້ນຢ່າງຕໍ່ເນື່ອງ.

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

ຂັ້ນຕອນການຈັດຕັ້ງປະຕິບັດໂດຍປະມານມີດັ່ງນີ້:

1. ຈຳກັດຂອບເຂດດ້ານຄຸນນະພາບທີ່ຕ້ອງການປະເມີນໃຫ້ເຫຼືອພຽງ 2-3 ຫົວຂໍ້.
2. ກຳນົດເຫດຜົນໃນການໃຫ້ຄະແນນ (Scoring logic) ຂອງແຕ່ລະດ້ານ (ໃຊ້ LLM Judge ຫຼື Rule-based).
3. ເອົາການປະເມີນຜົນແບບອອບລາຍເຂົ້າໄປໃນ CI/CD ຂະບວນການ ຫຼື Pipeline.
4. ສຸ່ມຕົວຢ່າງຈາກລະບົບຈິງໃນອັດຕາສ່ວນທີ່ກຳນົດໄວ້ ເພື່ອນຳໄປປະເມີນຜົນແບບອອນລາຍ.

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

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

ຕົວຊີ້ວັດຫຼັກທີ່ຄວນສະແດງຜົນໃນ Dashboard

• ການກະຈາຍຂອງ Latency: ສະແດງຄ່າ P50, P95, P99 ຕາມລຳດັບເວລາ ເພື່ອໃຫ້ສາມາດກວດຈັບການເພີ່ມຂຶ້ນຢ່າງກະທັນຫັນ (Spike) ໄດ້ທັນທີ
• ອັດຕາຄວາມຜິດພາດ (Error Rate): ຈຳນວນຄັ້ງຂອງ API Timeout, ການເກີນຂອບເຂດ Context Window ແລະ ການເຮັດວຽກຂອງ Guardrail
• ປະລິມານການໃຊ້ Token: ແນວໂນ້ມຕົ້ນທຶນແຍກຕາມ Model ແລະ Endpoint
• ຄະແນນຄຸນນະພາບ: ແນວໂນ້ມອັດຕາການເກີດ Hallucination ຫຼື ຄະແນນຄວາມກ່ຽວຂ້ອງທີ່ໄດ້ຈາກການປະເມີນຜົນແບບອັດຕະໂນມັດ

ການລວມຂໍ້ມູນເຫຼົ່ານີ້ໄວ້ໃນໜ້າຈໍດຽວຈະຊ່ວຍໃຫ້ຜູ້ຮັບຜິດຊອບ On-call ສາມາດເຂົ້າໃຈສະຖານະການໄດ້ພາຍໃນ 30 ວິນາທີ.

ແນວທາງການອອກແບບລະບົບແຈ້ງເຕືອນ (Alerts)

ມີແນວໂນ້ມໃນການເຮັດວຽກຕົວຈິງທີ່ວ່າ "ຖ້າແຈ້ງເຕືອນຫຼາຍເກີນໄປ ມັນກໍຈະຖືກລະເລີຍ". ການອອກແບບໂດຍແບ່ງເປັນ 3 ລະດັບຕໍ່ໄປນີ້ຈະມີປະສິດທິຜົນຫຼາຍກວ່າ:

1. ສຸກເສີນ (ຕອບສະໜອງທັນທີ): ເມື່ອອັດຕາຄວາມຜິດພາດເກີນເກນທີ່ກຳນົດໄວ້ໃນ 5 ນາທີຫຼ້າສຸດ. ແຈ້ງເຕືອນຜ່ານ PagerDuty ຫຼື Slack
2. ເຕືອນໄພ (ຕອບສະໜອງໃນມື້ເຮັດວຽກຖັດໄປ): ເມື່ອຄ່າ P95 Latency ແຍ່ລົງຢ່າງຫຼວງຫຼາຍເມື່ອທຽບກັບມື້ກ່ອນໜ້າ
3. ຂໍ້ມູນ (ທົບທວນປະຈຳອາທິດ): ແນວໂນ້ມຕົ້ນທຶນທີ່ເພີ່ມຂຶ້ນ ຫຼື ສັນຍານຂອງ Model Drift

ເຄັດລັບໃນການເຮັດໃຫ້ການດຳເນີນງານມີປະສິດທິພາບ

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

Q1. AI Observability ແລະ LLM Monitoring ແຕກຕ່າງກັນແນວໃດ?

LLM Monitoring ແມ່ນເນັ້ນໃສ່ການກວດສອບສະຖານະການເຮັດວຽກ (Health check) ເພື່ອເບິ່ງວ່າ "ລະບົບຍັງເຮັດວຽກຢູ່ບໍ່" ຫຼື "ມີຂໍ້ຜິດພາດເກີດຂຶ້ນຫຼືບໍ່". ໃນຂະນະທີ່ AI Observability ແມ່ນກົນໄກທີ່ລວມເອົາການຕິດຕາມ (Trace), ການປະເມີນຜົນ ແລະ ການວິເຄາະຕົ້ນທຶນເຂົ້າດ້ວຍກັນ ເພື່ອໃຫ້ສາມາດຍ້ອນກັບໄປເບິ່ງໄດ້ວ່າ ເປັນຫຍັງຜົນລັພນັ້ນຈຶ່ງຖືກສ້າງຂຶ້ນມາ. ເປົ້າໝາຍແມ່ນການປ່ຽນຜ່ານຈາກການຕິດຕາມກວດສອບແບບທົ່ວໄປ ໄປສູ່ "ການດຳເນີນງານທີ່ສາມາດອະທິບາຍທີ່ມາທີ່ໄປໄດ້".

---

Q2. ທີມງານຂະໜາດນ້ອຍສາມາດນຳມາໃຊ້ງານໄດ້ບໍ?

ການນຳມາໃຊ້ງານສາມາດດຳເນີນການເປັນຂັ້ນຕອນໄດ້. ພຽງແຕ່ເລີ່ມຕົ້ນຈາກການຕິດຕັ້ງລະບົບ Trace ໃສ່ໃນເສັ້ນທາງທີ່ສຳຄັນ (Critical path) 1-2 ຈຸດ ກໍສາມາດລະບຸຈຸດທີ່ເກີດ Hallucination ຫຼື ຈຸດທີ່ເກີດຄວາມລ່າຊ້າໄດ້. ຖ້າຫາກນຳໃຊ້ເຄື່ອງມື OSS ມາຊ່ວຍ ກໍຈະສາມາດຄວບຄຸມຕົ້ນທຶນໃນໄລຍະເລີ່ມຕົ້ນໄດ້ງ່າຍຂຶ້ນ, ເຊິ່ງວິທີການທີ່ເໝາະສົມແມ່ນເລີ່ມຈາກຂະໜາດ PoC (Proof of Concept) ແລ້ວຄ່ອຍໆຂະຫຍາຍອອກໄປ.

---

Q3. ການບໍລິຫານຈັດການຕົ້ນທຶນສາມາດເບິ່ງໄດ້ລະອຽດຮອດຂັ້ນໃດ?

ໂດຍການບັນທຶກປະລິມານການໃຊ້ງານໃນລະດັບ Token ຕໍ່ການຮ້ອງຂໍ (Request) ໜຶ່ງຄັ້ງ, ທ່ານຈະສາມາດເຂົ້າໃຈລາຍລະອຽດຂອງຕົ້ນທຶນແຍກຕາມ Model ແລະ ຕາມຟັງຊັນການເຮັດວຽກໄດ້. ເນື່ອງຈາກວິທີການນຳໃຊ້ Context Window ແລະ ຄວາມຍາວຂອງ Prompt ມີຜົນໂດຍກົງຕໍ່ຄ່າໃຊ້ຈ່າຍ, ການມີຂໍ້ມູນ Trace ຈະຊ່ວຍໃຫ້ການຈັດລຳດັບຄວາມສຳຄັນໃນການປັບປຸງໃຫ້ເໝາະສົມ (Optimization) ເຮັດໄດ້ງ່າຍຂຶ້ນ. ເນື່ອງຈາກລາຄາມີການປ່ຽນແປງຢູ່ສະເໝີ, ຈຶ່ງແນະນຳໃຫ້ກວດສອບໜ້າລາຄາຫຼ້າສຸດຢູ່ສະເໝີ.

---

Q4. ການຕິດຕາມ AI Agent ແຕກຕ່າງຈາກ LLM ທົ່ວໄປແນວໃດ?

ເນື່ອງຈາກ AI Agent ມີການຮຽກໃຊ້ Tool ຫຼື ເຊື່ອມຕໍ່ກັບ API ພາຍນອກຫຼາຍຂັ້ນຕອນ, ການຕິດຕາມການຫາເຫດຜົນແບບຫຼາຍຂັ້ນຕອນ (Multi-step reasoning trace) ເພື່ອຕິດຕາມວ່າການຕັດສິນໃຈຜິດພາດໃນຂັ້ນຕອນໃດ ຈຶ່ງເປັນສິ່ງທີ່ຂາດບໍ່ໄດ້. ຖ້າບໍ່ສາມາດເຮັດໃຫ້ການຈັດການ Orchestration ຂອງ Agent ທັງໝົດເຫັນພາບໄດ້ຊັດເຈນ, ມັນກໍຈະເປັນການຍາກທີ່ຈະລະບຸສາເຫດທີ່ແທ້ຈິງຂອງບັນຫາ.

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

ຈຸດສຳຄັນທີ່ຄວນຈື່ໃນບົດຄວາມນີ້ມີດັ່ງນີ້:

• Tracing: ບັນທຶກທຸກຂັ້ນຕອນຕັ້ງແຕ່ Input ຈົນເຖິງ Output ເພື່ອກຳນົດຈຸດທີ່ເກີດ Hallucination ຫຼື ຄວາມລ່າຊ້າ.
• ການປະເມີນຜົນ: ວັດແທກຄຸນນະພາບ Metrics ໂດຍອັດຕະໂນມັດ ແລະ ເຂົ້າໃຈເຖິງການປ່ຽນແປງກ່ອນ ແລະ ຫຼັງການເປີດຕົວ ຫຼື Launch ຢ່າງເປັນປະລິມານ.
• ການຈັດການຕົ້ນທຶນ ແລະ Latency: ຕິດຕາມການໃຊ້ງານ Token ແລະ ເວລາໃນການຕອບສະໜອງຢ່າງຕໍ່ເນື່ອງ ເພື່ອປ້ອງກັນການໃຊ້ຈ່າຍເກີນຄວາມຈຳເປັນ ແລະ ການເສື່ອມສະພາບ.
• ການແຈ້ງເຕືອນ ແລະ Dashboard: ກຽມຄວາມພ້ອມໃນການກວດຈັບຄວາມຜິດປົກກະຕິໄດ້ທັນທີ ແລະ ແບ່ງປັນສະຖານະການໃຫ້ທົ່ວທັງທີມ.

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

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

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