ການອອກແບບງົບປະມານ Latency ສຳລັບ AI Agent — ວິທີຄວບຄຸມການແລກປ່ຽນ ຫຼື Trade-off ລະຫວ່າງເວລາຄິດ ແລະ ເວລາຕອບສະໜອງ

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

ບົດຄວາມນີ້ມີຈຸດປະສົງເພື່ອອະທິບາຍເນື້ອຫາຕໍ່ໄປນີ້ຢ່າງເປັນລະບົບ ໂດຍເນັ້ນໃສ່ວິສະວະກອນ ແລະ ຫົວໜ້າຝ່າຍເຕັກນິກທີ່ຮັບຜິດຊອບການອອກແບບ Agent:

ເມື່ອຖືກບອກວ່າ "ການຕອບສະໜອງຊ້າ", ສາເຫດມາຈາກໃສ? ຖ້າເປັນ Chatbot ດ່ຽວ, ການສົງໄສຄວາມໄວໃນການປະມວນຜົນຂອງ Model ກໍເກືອບຈະພຽງພໍແລ້ວ. ແຕ່ໃນກໍລະນີຂອງ AI Agent, ເລື່ອງມັນບໍ່ໄດ້ງ່າຍດາຍແບບນັ້ນ.

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

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

ສຳລັບການເອີ້ນໃຊ້ LLM ແບບດ່ຽວ, ປັດໄຈຫຼັກຂອງຄວາມລ່າຊ້າຈະຖືກຈຳກັດຢູ່ທີ່ 2 ຈຸດ ຄື: Time to First Token (TTFT) ແລະ ຈຳນວນ Token ທີ່ສົ່ງອອກ. ຖ້າທ່ານເຂົ້າໃຈເວລາຕັ້ງແຕ່ສົ່ງຄຳຮ້ອງຂໍໄປຈົນເຖິງ Token ທຳອິດກັບຄືນມາ ແລະ ຄວາມໄວໃນການສ້າງ Token ຫຼັງຈາກນັ້ນ (TPOT), ທ່ານກໍຈະສາມາດເຫັນພາບລວມຂອງ Latency ໄດ້ເກືອບທັງໝົດ.

ໃນທາງກົງກັນຂ້າມ, ສຳລັບ Agent ທີ່ໃຊ້ການອະນຸມານແບບຫຼາຍຂັ້ນຕອນ (Multi-step reasoning agent), ໂຄງສ້າງຈະປ່ຽນແປງໄປຢ່າງຫຼວງຫຼາຍ. ປັດໄຈຂອງຄວາມລ່າຊ້າສາມາດສະຫຼຸບໄດ້ດັ່ງນີ້:

• TTFT ຈະຖືກສະສົມຕາມຈຳນວນຄັ້ງຂອງການເອີ້ນໃຊ້ LLM — ຖ້າມີ 5 ຂັ້ນຕອນ, TTFT ກໍຈະເກີດຂຶ້ນ 5 ຄັ້ງເຊັ່ນກັນ
• ເວລາລໍຖ້າການປະມວນຜົນຂອງເຄື່ອງມື (Tool execution) ແລະ ການເອີ້ນໃຊ້ External API ຈະແຊກຢູ່ໃນແຕ່ລະຂັ້ນຕອນ
• ເນື່ອງຈາກຜົນລວມຂອງຂັ້ນຕອນກ່ອນໜ້າຈະກາຍເປັນຂໍ້ມູນນຳເຂົ້າຂອງຂັ້ນຕອນຖັດໄປ, ຈຶ່ງເຮັດໃຫ້ເກີດຄວາມລ່າຊ້າທີ່ຕໍ່ເນື່ອງກັນຈາກການເພິ່ງພາອາໄສກັນແບບລຳດັບ

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

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

CoT (Chain of Thought) ແລະ ການຂະຫຍາຍຂະໜາດໃນຂະນະປະມວນຜົນ (Test-time Compute) ແມ່ນວິທີການທີ່ມີປະສິດທິພາບໃນການເພີ່ມຄວາມຖືກຕ້ອງຂອງຄຳຕອບຂອງ LLM, ແຕ່ກໍມີ ການແລກປ່ຽນ ຫຼື Trade-off ທີ່ເຮັດໃຫ້ຈຳນວນ Token ຜົນລວມເພີ່ມຂຶ້ນຢ່າງຫຼວງຫຼາຍ.

ຜົນກະທົບຫຼັກຂອງ CoT ຕໍ່ກັບຄວາມຊັກຊ້າ (Latency) ມີດັ່ງນີ້:

• ຈຳນວນ Output Token ເພີ່ມຂຶ້ນ: ເນື່ອງຈາກມີການສ້າງຂັ້ນຕອນການຄິດໄລ່ຂັ້ນກາງແບບລຳດັບ, ຈຳນວນ Token ອາດເພີ່ມຂຶ້ນຫຼາຍເທົ່າເຖິງຫຼາຍສິບເທົ່າເມື່ອທຽບກັບການສົ່ງຄຳຕອບສຸດທ້າຍພຽງຢ່າງດຽວ.
• ການສະສົມຂອງ TPOT: ດັ່ງທີ່ສູດ TPOT (Time Per Output Token) ຄື TPOT(ms) = (request_latency - TTFT) / (total_output_tokens - 1) ໄດ້ລະບຸໄວ້, ຍິ່ງຈຳນວນ Output Token ເພີ່ມຂຶ້ນ ຄວາມຊັກຊ້າໂດຍລວມກໍຈະຍືດຍາວອອກໄປຕາມເສັ້ນຊື່.
• ຂັ້ນຕອນພາຍໃນຂອງຮູບແບບການປະມວນຜົນ: ຮູບແບບການປະມວນຜົນເຊັ່ນ: ກຸ່ມ o1 ຈະສ້າງ "Token ແຫ່ງການຄິດ" ຈຳນວນມະຫາສານຢູ່ພາຍໃນ, ເຮັດໃຫ້ເກີດການສະສົມຂອງຄວາມຊັກຊ້າທີ່ເບິ່ງບໍ່ເຫັນຈາກພາຍນອກ.

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

ໃນຖານະແນວທາງປະຕິບັດຕົວຈິງ, ກະລຸນາອ້າງອີງຂໍ້ມູນຕໍ່ໄປນີ້:

"ເປັນຫຍັງ Agent ທີ່ເອີ້ນໃຊ້ພຽງ 5 ເຄື່ອງມື ຈຶ່ງໃຊ້ເວລາຫຼາຍກວ່າ 30 ວິນາທີ?" — ເຊື່ອວ່າວິສະວະກອນຫຼາຍຄົນຄົງເຄີຍພົບກັບຄຳຖາມນີ້ໃນການເຮັດວຽກຕົວຈິງ.

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

• ຄວາມລ່າຊ້າໃນການປະມວນຜົນຂອງ LLM: ຜົນລວມຂອງ TTFT (Time to First Token) ແລະ TPOT (Time Per Output Token) ທີ່ເກີດຂຶ້ນໃນແຕ່ລະຂັ້ນຕອນ
• ຄວາມລ່າຊ້າໃນການເອີ້ນໃຊ້ເຄື່ອງມື: ເວລາໃນການສົ່ງຂໍ້ມູນໄປ-ກັບ (Round-trip) ຫາ API ພາຍນອກ, ຖານຂໍ້ມູນ ແລະ ເຄື່ອງມືຄົ້ນຫາ
• ຄວາມລ່າຊ້າໃນການຕັດສິນໃຈຂອງ Orchestrator: ການສົ່ງຄຳຖາມກັບໄປຫາ LLM ເພື່ອກຳນົດຂັ້ນຕອນຕໍ່ໄປ
• ຕົ້ນທຶນໃນການສົ່ງຕໍ່ບໍລິບົດ (Context): ຄວາມຍາວຂອງ Prompt ທີ່ເພີ່ມຂຶ້ນທຸກຄັ້ງທີ່ມີການເພີ່ມຜົນລວມຈາກຂັ້ນຕອນກ່ອນໜ້າເຂົ້າໄປໃນ Context window

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

ການຊອກຫາຂັ້ນຕອນທີ່ສາມາດເຮັດວຽກຂະໜານກັນໄດ້ (Parallelization) ແລະ ການອອກແບບ Task graph ຈຶ່ງເປັນວິທີການຮັບມືເບື້ອງຕົ້ນຕໍ່ໂຄງສ້າງທີ່ສະສົມຄວາມລ່າຊ້ານີ້.

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

ບັນຫາກໍຄື ລະດັບຄວາມຊັກຊ້າທີ່ຍອມຮັບໄດ້ນັ້ນ ມີຄວາມແຕກຕ່າງກັນຢ່າງສິ້ນເຊີງຂຶ້ນຢູ່ກັບປະເພດຂອງວຽກງານ ແລະ ບໍລິບົດການນຳໃຊ້. ໃນອິນເຕີເຟດການສົນທະນາແບບ Real-time, ຖ້າຜູ້ໃຊ້ຕ້ອງລໍຖ້າດົນກວ່າ 3 ວິນາທີ ອາດຈະເຮັດໃຫ້ພວກເຂົາອອກຈາກລະບົບໄດ້, ແຕ່ສຳລັບ Data analysis agent ທີ່ເຮັດວຽກຢູ່ເບື້ອງຫຼັງ, ການປະມວນຜົນ 30 ວິນາທີອາດຈະຢູ່ໃນຂອບເຂດທີ່ຍອມຮັບໄດ້. ກ່າວຄື, ການຕັດສິນໃຈ "ເພີ່ມຄວາມແມ່ນຍຳ" ອາດກາຍເປັນຕົ້ນເຫດທີ່ເຮັດໃຫ້ຜູ້ໃຊ້ເລີກໃຊ້ງານ ຫຼື ເກີດລະບົບຂັດຂ້ອງໄດ້ໂດຍກົງ. ຖ້າບໍ່ມີການຄວບຄຸມການແລກປ່ຽນ ຫຼື Trade-off ນີ້ຢ່າງມີສະຕິໃນຂັ້ນຕອນການອອກແບບ, ກໍຈະບໍ່ສາມາດແກ້ໄຂໄດ້ໃນພາຍຫຼັງ.

ການນຳໃຊ້ CoT (Chain of Thought) ກັບແບບຈຳລອງການອະນຸມານ (Inference Model) ມີທ່າອ່ຽງທີ່ຈະຊ່ວຍເພີ່ມຄວາມຖືກຕ້ອງຂອງຄຳຕອບ. ຢ່າງໃດກໍຕາມ, ສິ່ງທີ່ຕ້ອງແລກປ່ຽນຄືຈຳນວນ Token ທີ່ສົ່ງອອກຈະເພີ່ມຂຶ້ນ ແລະ ເຮັດໃຫ້ Latency ຍືດຍາວອອກໄປຕາມລຳດັບ. ນີ້ຄືເນື້ອແທ້ຂອງ "ຄວາມຂັດແຍ່ງລະຫວ່າງຄວາມຖືກຕ້ອງ ແລະ ຄວາມໄວ" (Accuracy-Speed Dilemma).

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

ປັດໄຈຫຼັກທີ່ເຮັດໃຫ້ເກີດຄວາມຂັດແຍ່ງນີ້ ມີດັ່ງນີ້:

• ຕົ້ນທຶນການສ້າງ Token: ຍິ່ງຂັ້ນຕອນການອະນຸມານເພີ່ມຂຶ້ນ, ການສະສົມຂອງ Time Per Output Token (TPOT) ກໍຈະຫຼາຍຂຶ້ນ ເຮັດໃຫ້ Request Latency ໂດຍລວມເພີ່ມທະວີຂຶ້ນເລື້ອຍໆ.
• ຕ່ອງໂສ້ຂອງຂັ້ນຕອນກາງ: ໃນ CoT, ຜົນລວມຂອງຂັ້ນຕອນກາງຈະຖືກປ້ອນເຂົ້າໄປໃນ Prompt ຖັດໄປ ເຮັດໃຫ້ Context Window ຂະຫຍາຍຕົວໃຫຍ່ຂຶ້ນ ແລະ TTFT (ເວລາທີ່ໃຊ້ໃນການສ້າງ Token ທຳອິດ) ກໍມີແນວໂນ້ມທີ່ຈະແຍ່ລົງ.
• ຄວາມບໍ່ເປັນເສັ້ນຊື່ຂອງການຂະຫຍາຍຕົວໃນຂະນະອະນຸມານ: ເຖິງແມ່ນວ່າຈະເພີ່ມ Test-time Compute (ການຄຳນວນໃນຂະນະທົດສອບ) ຫຼາຍຂຶ້ນ, ແຕ່ການເພີ່ມຂຶ້ນຂອງຄວາມຖືກຕ້ອງກໍຈະຫຼຸດໜ້ອຍຖອຍລົງ ໃນຂະນະທີ່ Latency ຍັງຄົງເພີ່ມຂຶ້ນຢ່າງຕໍ່ເນື່ອງ.

ວິທີການແກ້ໄຂຄວາມຂັດແຍ່ງນີ້ທີ່ມີປະສິດທິພາບ ຄືການໃຊ້ "ຍຸດທະສາດການກຳນົດເສັ້ນທາງ" (Routing Strategy) ເພື່ອປັບປ່ຽນແບບຈຳລອງ ຫຼື ລະດັບຄວາມເລິກຂອງການອະນຸມານໃຫ້ເໝາະສົມກັບຄວາມຊັບຊ້ອນຂອງວຽກງານນັ້ນໆ.

ຄວາມຕ້ອງການໃນການດຸ່ນດ່ຽງລະຫວ່າງປະສົບການຂອງຜູ້ໃຊ້ ແລະ ຄຸນນະພາບຂອງວຽກງານນັ້ນ ມີຄວາມແຕກຕ່າງກັນຢ່າງຫຼວງຫຼາຍຕາມຈຸດປະສົງຂອງ AI agent.

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

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

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

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

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

ລະບົບແບບ Real-time ໝາຍເຖິງລະບົບທີ່ຜູ້ໃຊ້ຄາດຫວັງວ່າຈະໄດ້ຮັບການຕອບສະໜອງທັນທີຫຼັງຈາກປ້ອນຂໍ້ມູນ ໂດຍມີ AI Chatbot ແລະ ຜູ້ຊ່ວຍສຽງເປັນຕົວຢ່າງຕົ້ນຕໍ. ໃນກໍລະນີນີ້ ຍິ່ງໃຊ້ເວລາຄິດດົນຂຶ້ນເທົ່າໃດ ຄວາມສ່ຽງທີ່ຜູ້ໃຊ້ຈະອອກຈາກລະບົບກໍ່ຍິ່ງສູງຂຶ້ນ ແລະ ຫາກເພີ່ມຂັ້ນຕອນ CoT (Chain-of-Thought) ເພື່ອໄລ່ຕາມຄວາມຖືກຕ້ອງ ເວລາຕອບສະໜອງກໍ່ຈະສົ່ງຜົນກະທົບໂດຍກົງຕໍ່ປະສົບການຂອງຜູ້ໃຊ້ຕາມໄປດ້ວຍ. ຂີດຈຳກັດສູງສຸດຂອງ Latency ທີ່ຍອມຮັບໄດ້ມັກຈະຕ້ອງຢູ່ພາຍໃນສອງສາມວິນາທີ ແລະ ການຫຼຸດ TTFT (Time to First Token) ໃຫ້ໜ້ອຍທີ່ສຸດຈຶ່ງກາຍເປັນຕົວຊີ້ວັດທີ່ຕ້ອງໃຫ້ຄວາມສຳຄັນສູງສຸດ.

ໃນທາງກົງກັນຂ້າມ ລະບົບແບບ Asynchronous ມີໂຄງສ້າງທີ່ລະບົບສາມາດດູດຊຶມການລໍຖ້າຈົນກວ່າການປະມວນຜົນຈະສຳເລັດໄດ້. ຕົວຢ່າງໄດ້ແກ່ ການສະຫຼຸບເອກະສານໃນ Batch ຕອນກາງຄືນ ແລະ Agent ສ້າງລາຍງານທີ່ເຮັດວຽກຢູ່ເບື້ອງຫຼັງ ໂດຍກົນໄກທີ່ສາມາດຄົງຂໍ້ມູນການຕອບສະໜອງທີ່ກຳລັງສ້າງໄວ້ໄດ້ປະມານ 10 ນາທີ ເຊັ່ນ Background mode ຂອງ OpenAI ນັ້ນເໝາະສົມກັບການໃຊ້ງານປະເພດນີ້. ເນື່ອງຈາກ Throughput ແລະ ຕົ້ນທຶນໄດ້ຮັບຄວາມສຳຄັນກວ່າ Latency ຈຶ່ງງ່າຍຕໍ່ການຕັດສິນໃຈເພີ່ມຂັ້ນຕອນການອະນຸມານເພື່ອຍົກລະດັບຄວາມຖືກຕ້ອງ ແລະ ຍັງສາມາດກຳນົດຄວາມລະອຽດຂອງການຕັ້ງຄ່າ Timeout ໃຫ້ຫຍາບຂຶ້ນ ພ້ອມທັງຜ່ອນຄາຍການອອກແບບ Throttling ໄດ້ອີກດ້ວຍ.

ສິ່ງທີ່ສຳຄັນຄື ກໍລະນີທີ່ Agent ດຽວກັນສາມາດສະລັບໃຊ້ງານທັງສອງ Mode ຄື Real-time ແລະ Asynchronous.

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

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

ເພື່ອເພີ່ມຄວາມໄວໃນການອະນຸມານ (Inference), ໂດຍທົ່ວໄປແລ້ວເຮົາມັກຈະພິຈາລະນາປັບປ່ຽນສະຖາປັດຕະຍະກຳ ຫຼື ນ້ຳໜັກຂອງຕົວແບບ (Model weights) ກ່ອນ. ແຕ່ໃນຄວາມເປັນຈິງແລ້ວ, ມີການລາຍງານຫຼາຍກໍລະນີທີ່ລະບຸວ່າ ການນຳເອົາຍຸດທະສາດການຖອດລະຫັດ (Decoding strategy) ແລະ ການເຮັດ Quantization ມາປະສົມປະສານກັນ ສາມາດຫຼຸດຜ່ອນຄວາມໜ່ວງ (Latency) ໄດ້ໂດຍບໍ່ເຮັດໃຫ້ຄວາມຖືກຕ້ອງຫຼຸດລົງຢ່າງຫຼວງຫຼາຍ.

Speculative Decoding ແມ່ນກົນໄກທີ່ "Draft model" ຂະໜາດນ້ອຍຈະອ່ານລ່ວງໜ້າຫຼາຍ Token, ຈາກນັ້ນຕົວແບບຂະໜາດໃຫຍ່ຈະກວດສອບທັງໝົດໃນຄັ້ງດຽວ.

• Draft model ສ້າງ n tokens ດ້ວຍຄວາມໄວສູງ → ຕົວແບບຂະໜາດໃຫຍ່ຈະຕັດສິນໃຈຍອມຮັບ ຫຼື ປະຕິເສດແບບຂະໜານ (Parallel).
• ອັດຕາການຍອມຮັບຍິ່ງສູງ, ຈຳນວນຄັ້ງໃນການຮຽກໃຊ້ຕົວແບບຂະໜາດໃຫຍ່ກໍຍິ່ງຫຼຸດລົງ ເຮັດໃຫ້ TPOT (ຄວາມໜ່ວງລະຫວ່າງ Token ຜົນລັອກ) ສັ້ນລົງ.
• ຈະເຫັນຜົນໄດ້ດີໃນກໍລະນີທີ່ການກະຈາຍຄຳສັບຂອງວຽກງານສາມາດຄາດເດົາໄດ້ງ່າຍ (ເຊັ່ນ: ການຕອບໂຕ້ແບບເປັນແບບແຜນ ຫຼື ການຕື່ມຂໍ້ຄວາມໃນໂຄ້ດ).

Quantization ແມ່ນການບີບອັດນ້ຳໜັກຂອງຕົວແບບຈາກ FP32 ໄປເປັນ INT8 ຫຼື INT4 ເພື່ອຫຼຸດການໃຊ້ງານ Bandwidth ຂອງໜ່ວຍຄວາມຈຳ GPU ແລະ ເພີ່ມປະສິດທິພາບການອະນຸມານ (Inference throughput).

• ໃນ Inference server ເຊັ່ນ NVIDIA Triton, ແນະນຳໃຫ້ເຮັດ Benchmark ໂດຍອ້າງອີງຈາກທັງຕົວຊີ້ວັດ Time to First Token (TTFT) ແລະ Inter-Token Latency.
• ເຖິງແມ່ນວ່າ Quantization ຈະຊ່ວຍໃຫ້ TTFT ດີຂຶ້ນ, ແຕ່ຕ້ອງກວດສອບກັບຊຸດຂໍ້ມູນປະເມີນຜົນ (Evaluation set) ສະເໝີວ່າຄວາມຖືກຕ້ອງທີ່ຫຼຸດລົງນັ້ນຍັງຢູ່ໃນຂອບເຂດທີ່ຍອມຮັບໄດ້ຫຼືບໍ່.
• ວິທີການທີ່ນຳເອົາການ Fine-tuning ແລະ Quantization ມາປະສົມປະສານກັນ ເຊັ່ນ QLoRA ກໍເປັນທາງເລືອກໜຶ່ງທີ່ສາມາດນຳໃຊ້ໄດ້.

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

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

ປັດໄຈໃນການຕັດສິນໃຈມອບໝາຍວຽກງານແມ່ນຂຶ້ນກັບຄວາມຊັບຊ້ອນຂອງວຽກ ແລະ ຄວາມຕ້ອງການດ້ານຄວາມໄວໃນການຕອບສະໜອງ.

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

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

ແບບຈຳລອງ MoE (Mixture of Experts) ມີແນວຄິດການອອກແບບທີ່ເຮັດໃຫ້ການແບ່ງການນຳໃຊ້ແບບນີ້ເກີດຂຶ້ນໄດ້ພາຍໃນແບບຈຳລອງດຽວ. ເນື່ອງຈາກມີການປ່ຽນ Expert Sub-network ທີ່ເຮັດວຽກຕາມ Input Token, ຈຶ່ງບໍ່ຈຳເປັນຕ້ອງໃຊ້ Parameter ທັງໝົດໃນທຸກຄັ້ງ. ຜົນທີ່ໄດ້ຄື ມີແນວໂນ້ມທີ່ຈະຫຼຸດຕົ້ນທຶນໃນການອະນຸມານໄດ້ຫຼາຍກວ່າເມື່ອທຽບກັບ Dense Model (ແບບຈຳລອງທີ່ມີການເຊື່ອມຕໍ່ໜາແໜ້ນ) ທີ່ມີຄວາມຖືກຕ້ອງໃນລະດັບດຽວກັນ.

ຕໍ່ໄປນີ້ແມ່ນຂໍ້ຄວນລະວັງໃນການຈັດຕັ້ງປະຕິບັດ:

ຖ້າທ່ານເຄີຍນຳໃຊ້ RAG ໃນສະພາບແວດລ້ອມການເຮັດວຽກຈິງ (Production), ທ່ານອາດຈະເຄີຍພົບກັບປະສົບການທີ່ວ່າ "ການຄົ້ນຫາຊ້າ ຈົນເຮັດໃຫ້ການຕອບສະໜອງຂອງ Agent ທັງໝົດເກີດການຕິດຂັດ".

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

ໃນທາງກົງກັນຂ້າມ, ສຳລັບ Agentic RAG ສະຖານະການຈະແຕກຕ່າງອອກໄປ. ເນື່ອງຈາກມີການຄົ້ນຫາເພີ່ມເຕີມໃນແຕ່ລະຂັ້ນຕອນຂອງການຄິດວິເຄາະແບບຫຼາຍຂັ້ນຕອນ (Multi-step reasoning), ເຮັດໃຫ້ຄວາມຊ້າໃນການຄົ້ນຫາສະສົມຢູ່ໃນ Loop. ຈຸດທີ່ເກີດຄວາມຊ້າຫຼັກໆມີດັ່ງນີ້:

• ການສ້າງ Embedding: ຂະບວນການປ່ຽນ Query ໃຫ້ເປັນ Vector ຈະເກີດຂຶ້ນໃນທຸກໆຂັ້ນຕອນ
• ການຄົ້ນຫາໃກ້ຄຽງໃນ Vector Database: ຍິ່ງຂະໜາດຂອງ Index ໃຫຍ່ເທົ່າໃດ, ເວລາໃນການຄົ້ນຫາກໍຈະເພີ່ມທະວີຂຶ້ນເລື້ອຍໆ
• ຂະບວນການລວມຜົນການຄົ້ນຫາແບບ Hybrid: ເກີດຕົ້ນທຶນການຄຳນວນເພີ່ມເຕີມ ເມື່ອຕ້ອງລວມຜົນລັພຈາກ Semantic Search ແລະ BM25 ໂດຍໃຊ້ RRF ຫຼື ວິທີອື່ນໆ

ວິທີການປະຕິບັດເພື່ອຈັດການກັບຄວາມຊ້າໃນການຄົ້ນຫາມີດັ່ງນີ້:

• ການນຳໃຊ້ Prefix Cache: ການອ້າງອີງເຖິງເອກະສານດຽວກັນຊ້ຳໆ ຈະຖືກຈັດການດ້ວຍ Cache.

ສະຫຼຸບ: ການອອກແບບງົບປະມານດ້ານ Latency ແມ່ນມີພື້ນຖານມາຈາກສາມຂັ້ນຕອນ ຄື: ການຈັດສັນເວລາໃຫ້ກັບ Task Graph, ການດຳເນີນງານດ້ວຍການຄວບຄຸມ (Throttling) ແລະ ການຕິດຕາມກວດກາ.

ຫຼັງຈາກເຂົ້າໃຈແນວຄວາມຄິດແລ້ວ, ຈະເຂົ້າສູ່ຂັ້ນຕອນການອອກແບບ ແລະ ການຈັດສັນຕົວຈິງ. ໂດຍມີສາມເສົາຫຼັກໃນການຈັດຕັ້ງປະຕິບັດ ຄື: ການຈັດສັນເວລາຕາມຄວາມຊັບຊ້ອນຂອງວຽກ, ການຕັ້ງຄ່າ Policy ຂອງ Timeout, ແລະ ການຕິດຕາມກວດກາແບບ Real-time ດ້ວຍ AI Observability.

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

Task Graph ແມ່ນການສະແດງຊຸດຂອງຂະບວນການທີ່ Agent ປະຕິບັດໃນຮູບແບບ Directed Acyclic Graph (DAG). ແຕ່ລະ Node ຈະກົງກັບຂັ້ນຕອນການປະມວນຜົນ ເຊັ່ນ: "ການເອີ້ນໃຊ້ເຄື່ອງມື (Tool Call)", "ການອະນຸມານຂອງ LLM (LLM Inference)", ຫຼື "ການຄົ້ນຫາ RAG" ແລະ Edge ຈະສະແດງເຖິງຄວາມສຳພັນທີ່ຕ້ອງອາໄສກັນ.

ຂັ້ນຕອນພື້ນຖານໃນການຈັດສັນເວລາ ມີດັ່ງນີ້:

• ການລະບຸ Critical Path: ຄົ້ນຫາຕ່ອງໂສ້ການເພິ່ງພາອາໄສທີ່ຍາວທີ່ສຸດໃນກຣາຟ ແລະ ເນັ້ນງົບປະມານສ່ວນໃຫຍ່ໄປໄວ້ທີ່ນັ້ນ
• ການຈັດປະເພດຂັ້ນຕອນ: ແບ່ງອອກເປັນຂັ້ນຕອນແບບ Synchronous ທີ່ຜູ້ໃຊ້ຕ້ອງລໍຖ້າ ແລະ ຂັ້ນຕອນແບບ Asynchronous ທີ່ສາມາດປະຕິບັດໃນເບື້ອງຫຼັງໄດ້ ໂດຍໃຫ້ບຸລິມະສິດງົບປະມານແກ່ກຸ່ມທຳອິດ
• ການກຳນົດຕົວເລກງົບປະມານ: ຕົວຢ່າງເຊັ່ນ: ຖ້າຕັ້ງງົບປະມານລວມໄວ້ທີ່ 10 ວິນາທີ, ໃຫ້ລະບຸຂີດຈຳກັດສູງສຸດໃນແຕ່ລະ Node ເຊັ່ນ: ການຕີຄວາມໝາຍ (LLM Inference) 2 ວິນາທີ, ການຄົ້ນຫາ RAG 1.5 ວິນາທີ, ການປະຕິບັດງານຂອງເຄື່ອງມື 4 ວິນາທີ ແລະ ການສ້າງຄຳຕອບ 2.5 ວິນາທີ
• ການສຳຮອງ Buffer: ເພື່ອຮອງຮັບການສົ່ງຂໍ້ມູນໄປ-ກັບຂອງເຄືອຂ່າຍ ຫຼື ຄວາມຜັນຜວນຂອງ API ພາຍນອກ ຄວນບວກ Buffer ເພີ່ມປະມານ 10-15% ໃນແຕ່ລະຂັ້ນຕອນ

ການກຳນົດ Task Graph ຈະຊ່ວຍໃຫ້ທ່ານສາມາດຕິດຕາມໄດ້ຢ່າງຊັດເຈນວ່າຂັ້ນຕອນໃດເປັນສາເຫດຂອງຄວາມລ່າຊ້າ ໂດຍໃຊ້ເຄື່ອງມື AI Observability.

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

ແນວທາງການຕັ້ງຄ່າການຈຳກັດອັດຕາ (Throttling)

ການຈຳກັດອັດຕາຄືວິທີການຄວບຄຸມຈຳນວນຄຳຮ້ອງຂໍ (Request) ພ້ອມກັນ ຫຼື ອັດຕາການສ້າງ Token ບໍ່ໃຫ້ເກີນຂີດຈຳກັດ. ຫຼັກການໃນການຕັດສິນໃຈຕັ້ງຄ່າແມ່ນມີດັ່ງນີ້:

• ສຳລັບ User Interface ທີ່ຕ້ອງການການຕອບສະໜອງ ແບບ Real-time, ໃຫ້ຈຳກັດຈຳນວນ Output Token ສູງສຸດຕໍ່ 1 Request ຢ່າງເຂັ້ມງວດ ເພື່ອໃຫ້ຄວາມສຳຄັນກັບຄວາມໄວໃນການຕອບສະໜອງ.
• ສຳລັບ Batch processing ຫຼື ວຽກງານແບບບໍ່ປະສານເວລາ (Asynchronous task), ໃຫ້ຄວາມສຳຄັນກັບການເພີ່ມ Throughput ໃຫ້ສູງສຸດ ແລະ ຕັ້ງຂີດຈຳກັດຈຳນວນການປະມວນຜົນພ້ອມກັນໃຫ້ຍືດຫຍຸ່ນຂຶ້ນ.

ຕ້ອງລະວັງວ່າການຈຳກັດອັດຕາທີ່ເຂັ້ມງວດເກີນໄປ ອາດສົ່ງຜົນໃຫ້ຄຸນນະພາບຂອງວຽກງານທີ່ມີຄວາມຊັບຊ້ອນຫຼຸດລົງ.

ການອອກແບບລຳດັບຊັ້ນຂອງນະໂຍບາຍ Timeout

ການກຳນົດ Timeout ບໍ່ຄວນຕັ້ງຄ່າພຽງຄ່າດຽວ, ແຕ່ສິ່ງສຳຄັນແມ່ນຕ້ອງຈັດລຳດັບຊັ້ນໃຫ້ສອດຄ່ອງກັບຄວາມລະອຽດຂອງການປະມວນຜົນ:

• Step timeout: Timeout ໄລຍະສັ້ນທີ່ຕັ້ງໄວ້ສຳລັບການຮຽກໃຊ້ LLM ແຕ່ລະຄັ້ງ ຫຼື ການຮຽກໃຊ້ເຄື່ອງມືພາຍນອກ (ຕົວຢ່າງ: ບໍ່ເທົ່າໃດວິນາທີ ຫາ ສິບກວ່າວິນາທີ).
• Agent task timeout: ເວລາສູງສຸດສຳລັບວຽກງານທັງໝົດ 1 ວຽກ, ຄວນກຳນົດໃຫ້ມີຊ່ອງວ່າງຫຼາຍກວ່າຜົນລວມຂອງ Step timeout.
• Session timeout: ເວລາຈຳກັດສຳລັບການສົນທະນາແບບຫຼາຍຮອບ (Multi-turn) ທັງໝົດ.

ນອກຈາກນີ້, ຍັງຕ້ອງກຳນົດພຶດຕິກຳເມື່ອເກີດເຫດການ Timeout ໄວ້ລ່ວງໜ້າອີກດ້ວຍ.

"ການຕັ້ງງົບປະມານດ້ານ Latency ໄວ້ກໍເປັນເລື່ອງດີ ແຕ່ທ່ານສາມາດຮັບຮູ້ໄດ້ແທ້ໆຫຼືບໍ່ວ່າໃນສະພາບແວດລ້ອມການໃຊ້ງານຈິງ (Production) ແຕ່ລະຂັ້ນຕອນໃຊ້ເວລາໄປເທົ່າໃດແບບ Real-time?" — ຖ້າການດຳເນີນງານຍັງສືບຕໍ່ໄປໂດຍທີ່ບໍ່ສາມາດຕອບຄຳຖາມນີ້ໄດ້ ການລະບຸສາເຫດຂອງການໃຊ້ງົບປະມານເກີນກຳນົດກໍຈະຊັກຊ້າ.

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

• TTFT (Time to First Token): ເວລາທີ່ໂມເດວໃຊ້ໃນການສົ່ງ Output Token ທຳອິດອອກມາ.
• TPOT (Time Per Output Token): ຄວາມຊັກຊ້າຂອງການສົ່ງອອກລະຫວ່າງ Token, ຄຳນວນໂດຍສູດ (request_latency - TTFT) / (total_output_tokens - 1).
• Latency ສະສົມແຍກຕາມຂັ້ນຕອນ: ຜົນລວມຂອງເວລາທີ່ໃຊ້ໃນແຕ່ລະ Node ຂອງ Task Graph.

ຈຸດສຳຄັນໃນການຈັດຕັ້ງປະຕິບັດຄື ການລວມເອົາການວັດແທກເຂົ້າໄປໃນຊັ້ນ Orchestration ຂອງ Agent ແລະ ການກຳນົດ Trace ID ໃນແຕ່ລະຂັ້ນຕອນ. ສິ່ງນີ້ຈະຊ່ວຍໃຫ້ທ່ານສາມາດລະບຸໄດ້ທັນທີວ່າການຮຽກໃຊ້ Tool ໃດ ຫຼື LLM Hop ໃດທີ່ກຳລັງກົດດັນງົບປະມານຂອງທ່ານ.

ສຳລັບການອອກແບບລະບົບແຈ້ງເຕືອນ (Alert), ການຕັ້ງຄ່າໃຫ້ມີການເຕືອນເມື່ອງົບປະມານຖືກໃຊ້ໄປແລ້ວ 80% ແລະ ມີການເລີ່ມຕົ້ນຂະບວນການ Fallback (ເຊັ່ນ: ການປ່ຽນໄປໃຊ້ການຕອບກັບແບບງ່າຍໆ ຫຼື ການສົ່ງຄ່າຈາກ Cache) ໂດຍອັດຕະໂນມັດກ່ອນທີ່ຈະຮອດ 100% ແມ່ນວິທີທີ່ມີປະສິດທິພາບ.

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

ການຄວບຄຸມຄວາມຊັກຊ້າ (Latency) ໃນລະບົບຫຼາຍຕົວແທນ (Multi-agent system) ຈຳເປັນຕ້ອງມີການອອກແບບທີ່ແບ່ງປັນງົບປະມານເວລາ ໂດຍບໍ່ແມ່ນ "ທັງລະບົບໃຊ້ເວລາເທົ່າໃດ" ແຕ່ເປັນ "ແຕ່ລະຕົວແທນໃຊ້ເວລາເທົ່າໃດ". ໃນຈຸດນີ້ ສິ່ງທີ່ມີຜົນຢ່າງຍິ່ງຄື ຄວາມຊັກຊ້າຂອງການສື່ສານແບບ A2A (Agent-to-Agent) ແລະ ການເລືອກວິທີການປະມວນຜົນວ່າຈະໃຫ້ຕົວແທນເຮັດວຽກແບບຂະໜານ (Parallel) ຫຼື ແບບຕໍ່ເນື່ອງ (Sequential). ການປະມວນຜົນແບບຕໍ່ເນື່ອງຈະເຮັດໃຫ້ຄວາມຊັກຊ້າຂອງແຕ່ລະຕົວແທນຖືກນຳມາບວກກັນໂດຍກົງ, ໃນຂະນະທີ່ການປະມວນຜົນແບບຂະໜານ ຕົວແທນທີ່ຊ້າທີ່ສຸດຈະກາຍເປັນຄໍຂວດ (Bottleneck). ວິທີໃດຈະໄດ້ປຽບກວ່ານັ້ນ ແມ່ນຂຶ້ນຢູ່ກັບຄວາມສຳພັນຂອງໜ້າວຽກ (Task dependency) ເຊິ່ງບໍ່ສາມາດຕັດສິນໄດ້ຢ່າງຕາຍຕົວ.

ທຸກຄັ້ງທີ່ມີການສື່ສານເກີດຂຶ້ນລະຫວ່າງ Agent, ຈະມີ 3 ຂັ້ນຕອນທີ່ຊ້ອນທັບກັນຄື: ການເຮັດ Serialization, ການສົ່ງຂໍ້ມູນຜ່ານເຄືອຂ່າຍ ແລະ ການເຮັດ Deserialization. ຄວາມລ່າຊ້ານີ້ທີ່ບໍ່ເຄີຍເຫັນໃນ Agent ດ່ຽວ ຈະປາກົດໃຫ້ເຫັນໄດ້ງ່າຍຂຶ້ນໃນໂຄງສ້າງແບບ Multi-agent ທີ່ຜ່ານ A2A (Agent-to-Agent Protocol).

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

ປັດໄຈຫຼັກທີ່ເຮັດໃຫ້ການສື່ສານ A2A ເພີ່ມຄວາມລ່າຊ້າ:

• Payload Size ທີ່ໃຫຍ່ຂຶ້ນ: ການສົ່ງ Context Window ທັງໝົດລະຫວ່າງ Agent ຈະເຮັດໃຫ້ປະລິມານການໂອນຍ້າຍຂໍ້ມູນເພີ່ມທະວີຂຶ້ນເລື້ອຍໆ
• ການລໍຖ້າແບບ Synchronous: ຖ້າການເພິ່ງພາອາໄສກັນແບບລຳດັບທີ່ Agent ປາຍທາງຕ້ອງລໍຖ້າ Agent ຕົ້ນທາງເຮັດວຽກໃຫ້ສຳເລັດນັ້ນເກີດຂຶ້ນຕໍ່ເນື່ອງກັນ ຄວາມລ່າຊ້າກໍຈະສະສົມເພີ່ມຂຶ້ນເປັນທະວີຄູນ
• ການຢືນຢັນຕົວຕົນ ແລະ ການກວດສອບ Token: ໃນໂຄງສ້າງທີ່ຕ້ອງມີການກວດສອບ OIDC Token ໃນທຸກໆການຮຽກໃຊ້ ຈະເຮັດໃຫ້ເກີດຄວາມລ່າຊ້າໃນການສົ່ງຂໍ້ມູນໄປ-ກັບເພີ່ມຂຶ້ນອີກ

ວິທີການແກ້ໄຂທີ່ມີປະສິດທິພາບ:

• ການບີບອັດ Context ແລະ ການສົ່ງຂໍ້ມູນແບບສະຫຼຸບ: ແທນທີ່ຈະສົ່ງປະຫວັດທັງໝົດ, ໃຫ້ສົ່ງສະເພາະຜົນລວມຍອດຂອງຜົນລັບຂັ້ນກາງໃຫ້ກັບ Agent ທີ່ຢູ່ໃກ້ຄຽງເທົ່ານັ້ນ
• ການນຳໃຊ້ Prefix Cache: ການ Cache ສ່ວນຄຳສັ່ງທີ່ໃຊ້ຮ່ວມກັນໄວ້ ຈະສາມາດຫຼຸດ TTFT (Time to First Token) ໄດ້ຢ່າງຫຼວງຫຼາຍ

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

ກໍລະນີທີ່ການປະມວນຜົນແບບຂະໜານມີປະສິດທິຜົນ

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

ວຽກງານເຫຼົ່ານີ້ຈະຊ່ວຍຫຼຸດ Latency ລວມລົງໄດ້ຢ່າງຫຼວງຫຼາຍ ເນື່ອງຈາກເວລາໃນການສຳເລັດຂອງທຸກວຽກງານຈະຖືກລວມເຂົ້າເປັນຄໍຂວດ (Bottleneck) ພຽງຈຸດດຽວ.

ກໍລະນີທີ່ຈຳເປັນຕ້ອງປະມວນຜົນແບບລຳດັບ

• ການໃຫ້ເຫດຜົນແບບຫຼາຍຂັ້ນຕອນ (Multi-step reasoning) ທີ່ຕ້ອງນຳຜົນລັດຈາກຂັ້ນຕອນກ່ອນໜ້າໄປຕັດສິນໃຈໃນຂັ້ນຕອນຖັດໄປ
• ການປະມວນຜົນທີ່ຕ້ອງນຳຜົນລັດຈາກການໂທຫາເຄື່ອງມືໄປລວມເຂົ້າໃນ CoT (Chain of Thought)
• ເວີກໂຟລ (Workflow) ທີ່ມີການຈັດການຂໍ້ຜິດພາດ ຫຼື ການແຍກເງື່ອນໄຂແບບຕໍ່ເນື່ອງ

ໃນການປະມວນຜົນແບບລຳດັບ, ຄວາມລ່າຊ້າຈະສະສົມເພີ່ມຂຶ້ນຕາມຈຳນວນຂັ້ນຕອນ ດັ່ງນັ້ນການຕັ້ງຄ່າ Time-out ໃຫ້ກັບແຕ່ລະຂັ້ນຕອນຈຶ່ງເປັນສິ່ງທີ່ຂາດບໍ່ໄດ້.

ແນວທາງປະຕິບັດໃນການເລືອກ

ການແຕ້ມ Task Graph ເພື່ອໃຫ້ເຫັນພາບການເຊື່ອມຕໍ່ (Dependency edges) ຢ່າງຊັດເຈນ ແລະ ການຈັດກຸ່ມ Node ທີ່ບໍ່ມີຄວາມຂຶ້ນຕໍ່ກັນໃຫ້ເປັນ Parallel batch ແມ່ນວິທີທີ່ມີປະສິດທິຜົນ. ການແຍກສ່ວນທີ່ສາມາດເຮັດຂະໜານໄດ້ ແລະ ສ່ວນທີ່ຈຳເປັນຕ້ອງເຮັດແບບລຳດັບອອກຈາກກັນຢ່າງຊັດເຈນ ຈະຊ່ວຍໃຫ້ທ່ານສາມາດໃຊ້ງົບປະມານດ້ານ Latency ໄດ້ຢ່າງມີປະສິດທິພາບສູງສຸດ.

ທັງນີ້, ຄວນລະວັງວ່າການປະມວນຜົນແບບຂະໜານຈະໃຊ້ຊັບພະຍາກອນຂອງ Thread ຫຼື Coroutine ພ້ອມກັນ, ດັ່ງນັ້ນຖ້າຈຳນວນການປະມວນຜົນຂອງ Agent ເພີ່ມຂຶ້ນ, GPU ຫຼື Bandwidth ຂອງເຄືອຂ່າຍອາດຈະກາຍເປັນຄໍຂວດໄດ້. ສຳລັບການອອກແບບລະບົບ Multi-agent ໂດຍລວມ, ກະລຸນາເບິ່ງທີ່ [Multi-agent AI ແມ່ນຫຍັງ?

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

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

ການປ່ອຍນ້ຳໃສ່ອ່າງໂດຍບໍ່ປິດກ໊ອກນ້ຳ ຈະເຮັດໃຫ້ນ້ຳລົ້ນອອກມາໂດຍທີ່ບໍ່ຮູ້ວ່າຈະຢຸດເມື່ອໃດ. ການບໍລິໂພກຊັບພະຍາກອນແບບບໍ່ຈຳກັດ (Unbounded Consumption) ກໍຄືສະຖານະດຽວກັນນັ້ນ. ເມື່ອ Agent ເຮັດວຽກໃນ Loop ທີ່ບໍ່ມີເງື່ອນໄຂຢຸດ ຫຼື ມີເຫດຜົນໃນການລອງໃໝ່ (Retry logic) ຊ້ຳໆ, ງົບປະມານດ້ານ Latency ກໍຈະໝົດໄປຢ່າງວ່ອງໄວ.

ຮູບແບບການໃຊ້ງານເກີນຂອບເຂດທີ່ພົບເລື້ອຍມີດັ່ງນີ້:

• ການຂາດເງື່ອນໄຂໃນການຢຸດ Loop: ເມື່ອການຮຽກໃຊ້ Tool ຜິດພາດ ແລ້ວເກີດການ Retry ແບບບໍ່ມີທີ່ສິ້ນສຸດ ເຮັດໃຫ້ສິ້ນເປືອງ Token ແລະ ເວລາຫຼາຍກວ່າງົບປະມານທີ່ຕັ້ງໄວ້ຫຼາຍເທົ່າ
• ການຮຽກໃຊ້ Sub-agent ແບບຕໍ່ເນື່ອງ: Orchestrator ເປີດໃຊ້ງານ Sub-agent ຫຼາຍຕົວແບບລຽງລຳດັບ ເຮັດໃຫ້ຄວາມຊັກຊ້າໃນແຕ່ລະຂັ້ນຕອນສະສົມເພີ່ມຂຶ້ນ
• ການລໍຖ້າ Time-out ຂອງ External API: ການລໍຖ້າການຕອບກັບຈາກບໍລິການພາຍນອກກາຍເປັນຂະບວນການ Blocking ເຮັດໃຫ້ Latency ໂດຍລວມຢຸດສະງັກເປັນເວລາດົນ

ການກວດສອບຈຳເປັນຕ້ອງມີການວັດແທກແບບ Real-time ໂດຍໃຊ້ເຄື່ອງມື AI Observability. ໂດຍສະເພາະແມ່ນການຕິດຕາມຕົວຊີ້ວັດຕໍ່ໄປນີ້:

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

ເສັ້ນທາງຫຼັກທີ່ເຮັດໃຫ້ການຂະຫຍາຍຕົວດັ່ງກ່າວສົ່ງຜົນໃຫ້ເກີດຄວາມລ່າຊ້າ ມີດັ່ງນີ້:

• TTFT (Time to First Token) ເພີ່ມຂຶ້ນ: ຍິ່ງຈຳນວນ Input Token ເພີ່ມຂຶ້ນຫຼາຍເທົ່າໃດ, ເວລາທີ່ Model ໃຊ້ໃນການຄຳນວນ Attention ກໍຈະເພີ່ມຂຶ້ນຫຼາຍກວ່າເສັ້ນຊື່
• ອັດຕາການ Hit ຂອງ Prefix Cache ຫຼຸດລົງ: ຖ້າສົ່ງປະຫວັດການສົນທະນາທີ່ຍາວ ແລະ ແຕກຕ່າງກັນໃນທຸກຄັ້ງ, Cache ຈະບໍ່ຖືກນຳກັບມາໃຊ້ໃໝ່ ເຮັດໃຫ້ບໍ່ສາມາດໄດ້ຮັບປະສິດທິພາບໃນການຫຼຸດ TTFT ສູງສຸດເຖິງ 96% ຕາມທີ່ໄດ້ສະແດງໃຫ້ເຫັນໃນຕົວຢ່າງການວັດແທກຕົວຈິງຂອງ Vertex
• ການສົ່ງຂໍ້ມູນຕໍ່ໃຫ້ Orchestration Layer: ໃນການອະນຸມານ (Inference) ແບບຫຼາຍຂັ້ນຕອນ, ໂຄງສ້າງທີ່ Output ຂອງຂັ້ນຕອນທີ 1 ຈະຖືກເພີ່ມເຂົ້າໄປໃນ Input ຂອງຂັ້ນຕອນຕໍ່ໄປນັ້ນ ຈະເຮັດໃຫ້ Input ໃນຂັ້ນຕອນຫຼັງໆມີຂະໜາດໃຫຍ່ຂຶ້ນ ແລະ ເກີດຄວາມລ່າຊ້າສະສົມ

ວິທີການແກ້ໄຂທີ່ມີປະສິດທິພາບມີ 3 ປະການດັ່ງນີ້:

• Context Compression: ແທນທີ່ປະຫວັດການສົນທະນາເກົ່າດ້ວຍ Token ທີ່ສະຫຼຸບຫຍໍ້ ແລະ ລຶບລາຍລະອຽດທີ່ບໍ່ຈຳເປັນອອກ
• Sliding Window: ຮັກສາໄວ້ພຽງແຕ່ N ເທື່ອຫຼ້າສຸດ ແລະ ຕັດປະຫວັດເກົ່າອອກເປັນໄລຍະ
• ການແຍກ Context ຕາມ Task Graph: ສົ່ງສະເພາະຂໍ້ມູນທີ່ຈຳເປັນສຳລັບແຕ່ລະ Sub-task ເພື່ອປ້ອງກັນບໍ່ໃຫ້ Shared Context ມີຂະໜາດໃຫຍ່ເກີນໄປ

ສິ່ງທີ່ຄວນລະວັງເປັນພິເສດຄື ກໍລະນີທີ່ Agent ຕັດສິນໃຈເກັບສະສົມຜົນລວມຂອງການຮຽກໃຊ້ Tool ທັງໝົດໄວ້ "ເພື່ອຄວາມປອດໄພ".

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

ເນື້ອໃນທີ່ໄດ້ອະທິບາຍໃນບົດຄວາມນີ້ ສາມາດສະຫຼຸບເປັນຈຸດຕ່າງໆໄດ້ດັ່ງນີ້:

ການເຂົ້າໃຈໂຄງສ້າງຂອງຄວາມຊັກຊ້າ (Latency) ແມ່ນຈຸດເລີ່ມຕົ້ນ ການແຍກລະຫວ່າງ TTFT (ເວລາຈົນກວ່າ Token ທຳອິດຈະອອກ) ແລະ TPOT (ຄວາມຊັກຊ້າລະຫວ່າງ Token) ແລະ ການເຮັດໃຫ້ເຫັນພາບວ່າຄວາມຊັກຊ້າເກີດຂຶ້ນໃນຂັ້ນຕອນໃດ ແມ່ນບາດກ້າວທຳອິດຂອງການອອກແບບ. ໃນການອະນຸມານແບບຫຼາຍຂັ້ນຕອນ (Multi-step reasoning), ຄວາມຊັກຊ້າຂອງແຕ່ລະຂັ້ນຕອນຈະສະສົມກັນ, ດັ່ງນັ້ນການຈັດສັນເວລາໂດຍໃຊ້ Task Graph ຈຶ່ງມີປະສິດທິຜົນ.

ການປັບປ່ຽນຍຸດທະສາດຕາມຮູບແບບການປະມວນຜົນ ສຳລັບລະບົບ ແບບ Real-time ແມ່ນການໃຊ້ Streaming ແລະ ການມອບໝາຍວຽກໃຫ້ SLM (Small Language Model) ເພື່ອຮັບປະກັນຄວາມໄວໃນການຮັບຮູ້ຂອງຜູ້ໃຊ້, ສ່ວນລະບົບທີ່ບໍ່ແມ່ນແບບ Real-time ແມ່ນການນຳໃຊ້ການປະມວນຜົນເບື້ອງຫຼັງ (Background execution) ແລະ ການຂະຫຍາຍການປະມວນຜົນໃນຂະນະອະນຸມານ (Test-time Compute) ມາປະສົມປະສານກັນເພື່ອໃຫ້ຄວາມສຳຄັນກັບຄວາມຖືກຕ້ອງ, ເຊິ່ງນີ້ແມ່ນແນວທາງພື້ນຖານໃນການເລືອກໃຊ້.

ການນຳໃຊ້ວິທີການຫຼຸດຜ່ອນຄວາມຊັກຊ້າແບບປະສົມປະສານ Speculative Decoding, ການເຮັດ Quantization, Prefix Caching ແລະ MoE (Mixture of Experts) ລ້ວນແຕ່ມີສະຖານະການທີ່ສາມາດນຳໄປໃຊ້ໄດ້ແຕກຕ່າງກັນ. ການບໍ່ເພິ່ງພາວິທີໃດວິທີໜຶ່ງພຽງຢ່າງດຽວ ແຕ່ຫາກນຳມາປະສົມປະສານກັນຕາມຈຸດທີ່ເປັນຄໍຂວດ (Bottleneck) ຈະສາມາດເຮັດໃຫ້ເກີດປະສິດທິພາບສູງສຸດໄດ້.