Token Trap ແມ່ນຫຍັງ? ການຈັດການການບໍລິໂພກເພື່ອປ້ອງກັນຕົ້ນທຶນທີ່ເພີ່ມທະວີຂຶ້ນເລື້ອຍໆຂອງ AI Agent

Token Trap (ໂທເຄັນແທຣັບ) ແມ່ນກັບດັກທີ່ເກີດຈາກການທີ່ AI agent ບໍລິໂພກໂທເຄັນຫຼາຍເກີນໄປ ຈົນເຮັດໃຫ້ຄ່າໃຊ້ຈ່າຍໃນການໃຊ້ງານ LLM ແບບຈ່າຍຕາມຈິງເພີ່ມຂຶ້ນຢ່າງຄວບຄຸມບໍ່ໄດ້. ຂີດຈຳກັດອັດຕາ (Rate Limit) ຂອງ Cloud LLM ເຊັ່ນ: ຈຳນວນໂທເຄັນທີ່ສາມາດປະມວນຜົນໄດ້ຕໍ່ນາທີ ມັກຈະຖືກຕັ້ງໄວ້ສູງຫຼາຍ, ແລະ ຍິ່ງຂີດຈຳກັດສູງເທົ່າໃດ ການບໍລິໂພກຈຳນວນມະຫາສານໂດຍບໍ່ໄດ້ຕັ້ງໃຈກໍຍິ່ງເຫັນໄດ້ຍາກຂຶ້ນເທົ່ານັ້ນ. ມີການລາຍງານກໍລະນີທີ່ຍອດບິນເພີ່ມຂຶ້ນຫຼາຍສິບເທົ່າຈາກທີ່ຄາດໄວ້ ພຽງແຕ່ຍ້ອນເງື່ອນໄຂການຢຸດເຮັດວຽກຂອງ Agent loop ບໍ່ຊັດເຈນ ຫຼື ມີການສະສົມຂໍ້ມູນທີ່ບໍ່ຈຳເປັນໄວ້ໃນ Context window.

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

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

Agent ບໍ່ໄດ້ເຮັດວຽກພຽງແຕ່ການຄາດເດົາຄັ້ງດຽວເທົ່ານັ້ນ, ແຕ່ຈະເຮັດວຽກໂດຍການເຮັດຊ້ຳຫຼາຍຂັ້ນຕອນ. ໃນຂະບວນການດັ່ງກ່າວ, ມັນຈະມີການນຳເອົາການສົນທະນາໃນອະດີດມາເປັນບໍລິບົດ (Context) ຫຼື ມີການຝັງຜົນລວມ ຫຼື Merge ຜົນການເອີ້ນໃຊ້ເຄື່ອງມືລົງໃນ Prompt ຊ້ຳແລ້ວຊ້ຳອີກ. ພຽງແຕ່ມີຈຸດບອດໃນການອອກແບບພຽງຈຸດດຽວ ກໍອາດເຮັດໃຫ້ການປະຕິບັດວຽກງານພຽງຄັ້ງດຽວໃຊ້ Token ຫຼາຍກວ່າທີ່ຄາດຄະເນໄວ້ຫຼາຍເທົ່າ. ຕໍ່ຈາກນີ້ໄປ, ພວກເຮົາຈະມາເບິ່ງກົນໄກດັ່ງກ່າວໄປຕາມແຕ່ລະຂັ້ນຕອນ.

ຄ່າບໍລິການ API ຂອງ LLM ຈະຖືກຄິດໄລ່ແບບ "ຈ່າຍຕາມການໃຊ້ງານຈິງໂດຍອີງໃສ່ຈຳນວນ Token". Token ຄືຫົວໜ່ວຍນ້ອຍທີ່ສຸດທີ່ BPE Tokenizer (Byte-Pair Encoding Tokenizer) ແບ່ງອອກຈາກຂໍ້ຄວາມ, ເຊິ່ງໃນພາສາອັງກິດ 1 Token ≈ 4 ຕົວອັກສອນ ຫຼື 0.75 ຄຳ, ສ່ວນໃນພາສາຢີ່ປຸ່ນ 1 ຕົວອັກສອນຈະມີຄ່າເທົ່າກັບ 1-2 Token.

ໂຄງສ້າງພື້ນຖານຂອງການຄິດໄລ່ຄ່າບໍລິການປະກອບດ້ວຍ 3 ອົງປະກອບດັ່ງນີ້:

• Input Token: ຜົນລວມຂອງ Prompt, System Prompt ແລະ ປະຫວັດການສົນທະນາ
• Output Token: ຄວາມຍາວຂອງຂໍ້ຄວາມທີ່ Model ສ້າງຂຶ້ນ
• Rate Limit: ຂີດຈຳກັດຈະຖືກຕັ້ງໄວ້ໃນຫຼາຍແກນ ເຊັ່ນ RPM, TPM, TPD ແລະ ເມື່ອເກີນຂີດຈຳກັດ ກໍຈະໄດ້ຮັບ Error 429

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

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

ເມື່ອຈຳນວນຮອບການສົນທະນາເພີ່ມຂຶ້ນ, Context Window ກໍຈະຂະຫຍາຍຕົວຢ່າງບໍ່ມີຂີດຈຳກັດ. ໃນການນຳໃຊ້ API ສ່ວນໃຫຍ່, ປະຫວັດຂໍ້ຄວາມທັງໝົດທີ່ຜ່ານມາຈະຖືກນຳມາເຊື່ອມຕໍ່ກັນໂດຍກົງໃນການຮ້ອງຂໍຄັ້ງຕໍ່ໄປ, ເຮັດໃຫ້ໂຄງສ້າງຂອງຈຳນວນ Token ຕໍ່ຮອບເພີ່ມທະວີຂຶ້ນເລື້ອຍໆຕາມຈຳນວນຮອບທີ່ເພີ່ມຂຶ້ນ.

ກົນໄກການຂະຫຍາຍຕົວແບບຕໍ່ເນື່ອງ

• ຮອບທີ 1: System Prompt + ຂໍ້ມູນນຳເຂົ້າຈາກຜູ້ໃຊ້ = ຫຼາຍຮ້ອຍ Token
• ຮອບທີ 5: ຂໍ້ມູນຂ້າງເທິງ + ເນື້ອຫາເຕັມຂອງການສົນທະນາ 4 ຮອບທີ່ຜ່ານມາ = ຫຼາຍພັນ Token
• ຮອບທີ 20: ຜົນລວມຂອງການຮຽກໃຊ້ Tool ແລະ ຂໍ້ມູນຂັ້ນກາງກໍຈະສະສົມຂຶ້ນ ຈົນໃນບາງກໍລະນີອາດສູງເຖິງຫຼາຍໝື່ນ Token

Model ສ່ວນຫຼາຍຈະມີຄ່າເລີ່ມຕົ້ນຂອງຈຳນວນ Output Token ສູງສຸດທີ່ກຳນົດໄວ້, ເຊິ່ງຖ້າສົ່ງປະຫວັດການສົນທະນາທີ່ຍາວນານໄປທັງໝົດ ຈະເຮັດໃຫ້ພື້ນທີ່ສຳລັບການສະແດງຜົນ (Output) ຖືກບີບອັດຢ່າງວ່ອງໄວ. ຂີດຈຳກັດຂອງ Output ບາງເທື່ອກໍສາມາດປັບໄດ້ຜ່ານ Parameter, ແຕ່ໃນທາງ Input ນັ້ນ Rate Limit (ເຊັ່ນ TPM) ມັກຈະຖືກຕັ້ງໄວ້ສູງຫຼາຍ, ແລະ ຍິ່ງຂີດຈຳກັດສູງເທົ່າໃດ ກໍຍິ່ງເກີດການບໍລິໂພກຈຳນວນມະຫາສານໂດຍບໍ່ໄດ້ຕັ້ງໃຈໄດ້ງ່າຍຂຶ້ນເທົ່ານັ້ນ ຈຶ່ງຕ້ອງລະວັງ.

ເມື່ອ Context ເຂົ້າໃກ້ຂີດຈຳກັດ, ຄວາມສ່ຽງທີ່ຈະເກີດ Hallucination ທີ່ເຮັດໃຫ້ Model "ຫຼົງລືມ" ຂໍ້ມູນພື້ນຖານທີ່ສຳຄັນກໍຈະສູງຂຶ້ນ.

ຜົນກະທົບໂດຍກົງຕໍ່ຕົ້ນທຶນ

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

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

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

ເສັ້ນທາງຫຼັກທີ່ເຮັດໃຫ້ເກີດການຂະຫຍາຍຕົວຂອງຂໍ້ມູນມີດັ່ງນີ້:

• ການສົ່ງຄຳສັ່ງຈາກ Orchestrator ໄປຍັງ Sub-agent: ຖ້າ Agent ຫຼັກສົ່ງ Context ທັງໝົດທີ່ມີໃຫ້ກັບ Sub-agent ໂດຍກົງ, ຂໍ້ມູນດຽວກັນນັ້ນຈະຖືກຊ້ອນທັບຢູ່ໃນ Prompt ຂອງຫຼາຍ Agent.
• ການແບ່ງປັນຜົນລັດລະຫວ່າງກາງຜ່ານ A2A (Agent-to-Agent Protocol): ເມື່ອເກີດວົງຈອນທີ່ Agent ອ້າງອີງຜົນລັດລະຫວ່າງກາງຂອງກັນແລະກັນ, ຈຳນວນການຮຽກໃຊ້ API ເພື່ອເຮັດວຽກໃຫ້ສຳເລັດໃນແຕ່ລະຄັ້ງຈະເພີ່ມຂຶ້ນຢ່າງວ່ອງໄວ.
• Context ຊ້ອນທັບໃນຂະນະປະມວນຜົນຂະໜານ: ເນື່ອງຈາກ Agent ແຕ່ລະຕົວເກັບຮັກສາ System Prompt ຫຼື ຜົນລັດຈາກການຄົ້ນຫາ RAG ໄວ້ແຍກກັນ, ຈຶ່ງເຮັດໃຫ້ເກີດການສະສົມຂອງ Token ທີ່ຊ້ອນທັບກັນຢ່າງງຽບໆ.

ສິ່ງທີ່ຕ້ອງລະວັງຕໍ່ການຕັ້ງຄ່າຂີດຈຳກັດທີ່ຝັ່ງ Platform ກໍສຳຄັນເຊັ່ນກັນ. ໃນ Cloud LLM, Rate Limit ຈະຖືກຈັດການເປັນຫົວໜ່ວຍ TPM (Tokens Per Minute) ເຊິ່ງຂີດຈຳກັດດັ່ງກ່າວມັກຈະຖືກຕັ້ງໄວ້ສູງຫຼາຍ, ຈຶ່ງເຮັດໃຫ້ການເພີ່ມຂຶ້ນຂອງການບໍລິໂພກຈາກ Context ທີ່ຊ້ອນທັບກັນຖືກເບິ່ງຂ້າມໄດ້ງ່າຍ.

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

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

ສະພາວະນີ້ເອີ້ນວ່າ "ການບໍລິໂພກຊັບພະຍາກອນແບບບໍ່ຈຳກັດ (Unbounded Consumption)". AI Agent ຈະເຮັດການເອີ້ນໃຊ້ Tool ຫຼື ສົ່ງຂໍ້ມູນຕໍ່ໃຫ້ LLM ຢ່າງຕໍ່ເນື່ອງຈົນກວ່າຈະບັນລຸເປົ້າໝາຍ. ຖ້າການອອກແບບເງື່ອນໄຂການຢຸດເຮັດວຽກຍັງບໍ່ຊັດເຈນ ກໍຈະເກີດຕ່ອງໂສ້ເຫດການດັ່ງນີ້:

• Agent ຕັດສິນໃຈວ່າ "ຍັງມີຂໍ້ມູນບໍ່ພຽງພໍ" ຈຶ່ງເຮັດການຄົ້ນຫາ ແລະ ສະຫຼຸບຂໍ້ມູນຊ້ຳໆ
• ຜົນລັອບຂອງແຕ່ລະຂັ້ນຕອນຈະຖືກສະສົມເຂົ້າໄປເປັນ Input ຂອງຂັ້ນຕອນຕໍ່ໄປ ເຮັດໃຫ້ Context Window ຂະຫຍາຍຕົວຂຶ້ນ
• ເມື່ອຈຳນວນ Token ເພີ່ມຂຶ້ນ ຄ່າໃຊ້ຈ່າຍຕໍ່ການເອີ້ນໃຊ້ API 1 ຄັ້ງກໍຈະສູງຂຶ້ນ ແລະ ເມື່ອຄູນກັບຈຳນວນຮອບທີ່ວົນລູບ ກໍຈະເຮັດໃຫ້ຄ່າໃຊ້ຈ່າຍບວມຂຶ້ນຢ່າງມະຫາສານ

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

ຈຸດສຳຄັນ ຫຼື ແກນຫຼັກ ໃນການຮັບມືມີ 3 ປະການດັ່ງນີ້.

CoT (Chain of Thought) ຫຼື ແບບຈຳລອງການອະນຸມານ (Reasoning models) ໃນຂະນະທີ່ຊ່ວຍເພີ່ມຄວາມຖືກຕ້ອງຂອງຄຳຕອບ ແຕ່ກໍມີໂຄງສ້າງຕົ້ນທຶນທີ່ມັກຖືກມອງຂ້າມ ຄືຂະບວນການຄິດເອງກໍຖືກຄິດໄລ່ເປັນຄ່າໃຊ້ຈ່າຍໃນຮູບແບບຂອງ Token ເຊັ່ນກັນ.

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

ການເລືອກ Model ທີ່ເໝາະສົມຈະແຕກຕ່າງກັນຢ່າງຫຼວງຫຼາຍຕາມລັກສະນະຂອງວຽກງານ:

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

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

ເມື່ອເລີ່ມນຳໃຊ້ RAG (Retrieval-Augmented Generation) ເຂົ້າໃນການເຮັດວຽກ, ຫຼາຍໜ້າວຽກມັກຈະພົບກັບບັນຫາທີ່ວ່າ "ເປັນຫຍັງປະລິມານການໃຊ້ Token ຈຶ່ງເພີ່ມຂຶ້ນຫຼາຍກວ່າທີ່ຄາດໄວ້ເຖິງສອງເທົ່າ".

ຕົ້ນທຶນຂອງ Token ໃນ RAG ເກີດມາຈາກໂຄງສ້າງທີ່ນຳເອົາຜົນການຄົ້ນຫາໄປໃສ່ໃນ Context Window ໂດຍກົງ. ຂະບວນການທົ່ວໄປມີດັ່ງນີ້:

• ແປງຄຳຖາມຂອງຜູ້ໃຊ້ໃຫ້ເປັນ Embedding ເພື່ອຄົ້ນຫາໃນ Vector Database
• ນຳເອົາ Chunk ຈຳນວນ K ລຳດັບທຳອິດມາເຊື່ອມຕໍ່ເຂົ້າກັບ System Prompt
• ສົ່ງ Prompt ທັງໝົດທີ່ເຊື່ອມຕໍ່ກັນນັ້ນໄປໃຫ້ LLM (Large Language Model)

ບັນຫາຢູ່ທີ່ການຕັ້ງຄ່າ "K ລຳດັບທຳອິດ". ຖ້າ K=5 ແລະ Chunk size ເທົ່າກັບ 512 Token, ສະເພາະຜົນການຄົ້ນຫາກໍຈະໃຊ້ Token ໄປແລ້ວ 2,560 Token ໃນທຸກໆຄັ້ງ. ເມື່ອລວມກັບ System Prompt ເດີມ ແລະ ປະຫວັດການສົນທະນາ, ຈຳນວນ Token ຕໍ່ 1 Request ກໍຈະເກີນ 5,000 - 8,000 Token ໄດ້ຢ່າງງ່າຍດາຍ.

ຕົ້ນທຶນໃນການສ້າງ Embedding ກໍມັກຈະຖືກມອງຂ້າມເຊັ່ນກັນ. ຖ້າປ່ອຍໃຫ້ມີການສ້າງ Embedding ແບບ Real-time ໃນທຸກໆ Query ໂດຍບໍ່ມີການຈຳກັດ, ມັນກໍຈະກາຍເປັນການໃຊ້ Token ເພີ່ມເຕີມທີ່ສະສົມຂຶ້ນ ນອກເໜືອໄປຈາກຕົ້ນທຶນການ Inference ຫຼັກ.

ຈຸດສຳຄັນ ຫຼື ແກນຫຼັກ ໃນການຫຼຸດຕົ້ນທຶນມີ 3 ປະການດັ່ງນີ້:

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

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

ເຄື່ອງມື AI Observability ຈະສະໜອງກົນໄກໃນການລວມຍອດຈຳນວນ Token ທີ່ໃຊ້, Latency ແລະຕົ້ນທຶນໃນແຕ່ລະຄຳຮ້ອງຂໍ (Request) ທີ່ສົ່ງໄປຍັງ LLM ໂດຍອັດຕະໂນມັດ ເພື່ອໃຫ້ສາມາດກວດສອບຜ່ານ Dashboard ໄດ້. ເກນການຄັດເລືອກທີ່ສຳຄັນມີດັ່ງນີ້:

• ຮອງຮັບຫຼາຍໂມເດວ (Multi-model): ສາມາດວັດແທກຂ້າມຫຼາຍຜູ້ໃຫ້ບໍລິການໄດ້ຫຼືບໍ່.
• ການຕິດຕາມ Agent Loop: ສາມາດເຊື່ອມໂຍງການໂທຫາແບບຫຼາຍຂັ້ນຕອນ (Multi-step reasoning) ຫຼື ການໂທຫາແບບຕໍ່ເນື່ອງຂອງລະບົບ Multi-agent ດ້ວຍ Trace ID ໄດ້ຫຼືບໍ່.
• ການເຊື່ອມຕໍ່ລະບົບແຈ້ງເຕືອນ (Alert): ສາມາດສົ່ງການແຈ້ງເຕືອນໄປຍັງ Slack ຫຼື ບ່ອນອື່ນ ເມື່ອການໃຊ້ Token ເກີນຂີດຈຳກັດທີ່ກຳນົດໄວ້ໄດ້ຫຼືບໍ່.
• ການປ່ຽນເປັນມູນຄ່າຕົ້ນທຶນອັດຕະໂນມັດ: ສາມາດປ່ຽນຈຳນວນ Token ເປັນລາຄາຕໍ່ໜ່ວຍໂດຍອັດຕະໂນມັດ ແລະ ສະແດງໃຫ້ເຫັນເຖິງການປ່ຽນແປງຂອງຕົ້ນທຶນໃນແຕ່ລະວັນ ຫຼື ແຕ່ລະເດືອນໄດ້ຫຼືບໍ່.

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

ສຳລັບຂັ້ນຕອນການນຳໃຊ້, ອັນດັບທຳອິດແມ່ນການຝັງ Tracing Library ເຂົ້າໄປໃນ SDK ຫຼື Middleware Layer ແລະເພີ່ມ Span ໃຫ້ກັບແຕ່ລະ API Call.

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

ຂັ້ນຕອນການວັດແທກມີດັ່ງນີ້:

• ເລືອກຮູບແບບການໃຊ້ງານ (Use Case) ທີ່ເປັນຕົວແທນ 3-5 ຮູບແບບ: ໃຫ້ເລືອກ Flow ທີ່ເກີດຂຶ້ນເລື້ອຍໆໃນການໃຊ້ງານຈິງ ເຊັ່ນ: ການຕອບໂຕ້ຜ່ານ Chat, ການຄົ້ນຫາແບບ RAG, ຫຼື ການເອີ້ນໃຊ້ Tool.
• ແຍກບັນທຶກ Input Token, Output Token ແລະ ຈຳນວນ Token ລວມ: ອັດຕາສ່ວນລະຫວ່າງ Input ແລະ Output ເປັນດັດຊະນີສຳຄັນໃນການກຳນົດທິດທາງການປັບປຸງໃຫ້ເໝາະສົມ (Optimization).
• ຄຳນວນຄ່າສະເລ່ຍ, ຄ່າສູງສຸດ ແລະ ຄ່າ P95 ຕໍ່ 1 Request: ເພື່ອບໍ່ໃຫ້ຖືກຜົນກະທົບຈາກຄ່າທີ່ຜິດປົກກະຕິ (Outlier), ໃຫ້ປະເມີນຜົນດ້ວຍຄ່າ Percentile.
• ສ້າງກຣາຟສະແດງປະລິມານການໃຊ້ງານສະສົມແບບລາຍວັນ ແລະ ລາຍສັບປະດາ: ຈຸດປະສົງແມ່ນເພື່ອເຂົ້າໃຈການປ່ຽນແປງຕາມລຳດັບເວລາ ບໍ່ແມ່ນການວັດແທກພຽງຄັ້ງດຽວ.

ການເລືອກເຄື່ອງມືວັດແທກມີເງື່ອນໄຂການແຍກປະເພດ. ຖ້າຫາກທ່ານໃຊ້ Cloud API ຂອງ Model ດຽວ, ເສັ້ນທາງທີ່ສັ້ນທີ່ສຸດຄືການບັນທຶກ Field usage (prompt_tokens, completion_tokens) ທີ່ລວມຢູ່ໃນ API Response ລົງໃນ Log ໂດຍກົງ. ໃນທາງກົງກັນຂ້າມ, ຖ້າເປັນລະບົບ Multi-agent ທີ່ໃຊ້ຫຼາຍ Model ຮ່ວມກັນ, ການລວມສູນຂໍ້ມູນຜ່ານເຄື່ອງມື AI Observability ຈະຊ່ວຍຫຼຸດຕົ້ນທຶນໃນການບໍລິຫານຈັດການໄດ້ດີກວ່າ.

ຖ້າຫາກນຳໃຊ້ Cloud LLM, ການກວດສອບຄ່າຕັ້ງຂອງຂີດຈຳກັດອັດຕາ ເຊັ່ນ TPM (Tokens Per Minute) ໄປພ້ອມໆກັນ ຈະຊ່ວຍໃຫ້ພື້ນຖານຂອງການວັດແທກມີຄວາມຊັດເຈນຂຶ້ນ.

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

ການແຈ້ງເຕືອນຂີດຈຳກັດຂອງຄ່າໃຊ້ຈ່າຍ ແລະ Throttling ແມ່ນແນວປ້ອງກັນດ່ານທຳອິດສຳລັບ Token trap. ລາຍການທີ່ຄວນຕັ້ງຄ່າສາມາດແບ່ງອອກເປັນສາມສ່ວນໃຫຍ່ໆ.

ສະຫຼຸບ: ການຫຼຸດຜ່ອນການໃຊ້ງານ Token ຢ່າງມີປະສິດທິພາບນັ້ນ ຄວນດຳເນີນການຢ່າງເປັນລະບົບຜ່ານ 3 ຂັ້ນຕອນ ຄື: ການບີບອັດ Prompt, ການປັບແຕ່ງ Context ໃຫ້ເໝາະສົມ ແລະ ການແຍກ Model ອອກຈາກກັນ.

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

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

ການຫຼຸດຈຳນວນ Input Token ແມ່ນມາດຕະການຫຼຸດຕົ້ນທຶນທີ່ມີປະສິດທິຜົນສູງສຸດ. ກະລຸນາທົບທວນຄືນໂດຍອີງໃສ່ທັດສະນະດັ່ງຕໍ່ໄປນີ້:

• ກຳຈັດການເກີດຄຳຊ້ຳຊ້ອນທີ່ບໍ່ຈຳເປັນ: ຂໍ້ຄວາມແບບຟອມເຊັ່ນ "ເຈົ້າເປັນຜູ້ຊ່ວຍທີ່ດີເລີດ" ແມ່ນການສິ້ນເປືອງ Token ທີ່ບໍ່ໄດ້ຊ່ວຍໃຫ້ວຽກສຳເລັດ. ຄວນຈຳກັດ System Prompt ໃຫ້ມີພຽງແຕ່ການກຳນົດບົດບາດ ແລະ ເງື່ອນໄຂຂໍ້ບັງຄັບເທົ່ານັ້ນ.
• ຫຼຸດຈຳນວນຕົວຢ່າງ Few-shot ໃຫ້ໜ້ອຍທີ່ສຸດ: ການຍົກຕົວຢ່າງມີປະສິດທິຜົນໃນການປັບປຸງຄຸນນະພາບ, ແຕ່ການບໍລິໂພກ Token ຕໍ່ຕົວຢ່າງມັກຈະຖືກມອງຂ້າມ. ຄວນຫຼີກລ່ຽງການເພີ່ມຕົວຢ່າງໃຫ້ກັບວຽກທີ່ສາມາດຈັດການໄດ້ດ້ວຍ Zero-shot.
• ໃຊ້ຮູບແບບໂຄງສ້າງເພື່ອທົດແທນການອະທິບາຍທີ່ຍືດຍາວ: ການສົ່ງຂໍ້ມູນດ້ວຍ JSON ຫຼື ຫົວຂໍ້ຍ່ອຍ (Bullet points) ຈະມີປະສິດທິພາບດ້ານ Token ສູງກວ່າການອະທິບາຍດ້ວຍຂໍ້ຄວາມຍາວໆ.
• ອອກແບບໃຫ້ປ່ຽນແປງສະເພາະສ່ວນຕົວແປ (Variable) ແບບເຄື່ອນໄຫວເທົ່ານັ້ນ: ເຮັດໃຫ້ສ່ວນທີ່ຄົງທີ່ຂອງ Prompt ທີ່ເປັນ Template ສັ້ນລົງ ແລະ ປ່ຽນແປງສະເພາະຕົວແປທີ່ໃສ່ເຂົ້າໄປໃນເວລາປະຕິບັດງານເທົ່ານັ້ນ.

ມຸມມອງໃນການເລືອກ Model ກໍສຳຄັນເຊັ່ນກັນ. ຂີດຈຳກັດອັດຕາ (Rate Limit) ຂອງ Cloud LLM ມັກຈະຖືກຕັ້ງໄວ້ສູງຫຼາຍ, ແລະ Model ທີ່ມີຂີດຈຳກັດສູງເທົ່າໃດ ຫາກບໍ່ບີບອັດ Prompt ຢ່າງເຄັ່ງຄັດ ກໍຍິ່ງນຳໄປສູ່ການບໍລິໂພກຈຳນວນມະຫາສານໂດຍບໍ່ໄດ້ຕັ້ງໃຈ.

ໃນ RAG ຂະບວນການ ຫຼື Pipeline, ການຕັ້ງຄ່າຂະໜາດຂອງ Chunk ມີຜົນໂດຍກົງຕໍ່ປະລິມານການໃຊ້ງານ Token. ຖ້າ Chunk ໃຫຍ່ເກີນໄປ, ບໍລິບົດທີ່ບໍ່ຈຳເປັນຈະຖືກສົ່ງໄປໃຫ້ LLM, ແລະຖ້າຫາກນ້ອຍເກີນໄປ, ຄວາມໝາຍຈະຖືກຕັດຂາດ ເຮັດໃຫ້ຄວາມຖືກຕ້ອງໃນການຄົ້ນຫາຫຼຸດລົງ—ເຊິ່ງການແກ້ໄຂບັນຫາ ການແລກປ່ຽນ ຫຼື Trade-off ນີ້ຄື ຈຸດສຳຄັນ ຫຼື ແກນຫຼັກ ຂອງ Context Engineering.

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

ໃນມຸມມອງຂອງ Context Engineering, ການນຳເອົາ Chunk ທີ່ໄດ້ມາເຊື່ອມຕໍ່ກັນແລ້ວສົ່ງໄປເລີຍນັ້ນບໍ່ແມ່ນວິທີທີ່ດີທີ່ສຸດ, ແຕ່ການ ກັ່ນຕອງດ້ວຍຄະແນນຄວາມກ່ຽວຂ້ອງ (Relevance Score) ແມ່ນມີຄວາມສຳຄັນຫຼາຍ. ມີລາຍງານວ່າພຽງແຕ່ການກັ່ນຕອງ Chunk ທີ່ມີຄະແນນຄວາມຄ້າຍຄືກັນຕໍ່າກວ່າເກນທີ່ກຳນົດໄວ້ ກໍສາມາດຫຼຸດຈຳນວນ Input Token ຕໍ່ 1 Request ໄດ້ຢ່າງຫຼວງຫຼາຍ.

ຖ້າການອອກແບບ Chunk ທີ່ດຶງມາບໍ່ດີ, ມັນກໍຈະສົ່ງຜົນໂດຍກົງຕໍ່ປະລິມານ Input Token. ຂີດຈຳກັດອັດຕາ (Rate Limit) ຂອງ Cloud LLM ມັກຈະຖືກຕັ້ງໄວ້ສູງຫຼາຍ, ດ້ວຍເຫດນີ້ຈຶ່ງບໍ່ຄວນເພິ່ງພາຂີດຈຳກັດ ແຕ່ຄວນຄວບຄຸມປະລິມານ Input ດ້ວຍກົນລະຍຸດທາງດ້ານ Chunk ແທນ.

ນອກຈາກນີ້, ການທີ່ System Prompt ໃຫຍ່ເກີນໄປກໍເປັນປັດໄຈດ້ານຕົ້ນທຶນທີ່ມັກຖືກມອງຂ້າມເຊັ່ນກັນ.

"ວຽກນີ້, ຈຳເປັນຕ້ອງສົ່ງໃຫ້ LLM ຂະໜາດໃຫຍ່ທຸກຄັ້ງເລີຍບໍ?" —— ນີ້ຄືສັນຍານທີ່ບອກວ່າເຖິງເວລາທີ່ຕ້ອງທົບທວນການແບ່ງແຍກວຽກງານ (Task separation) ຂອງທ່ານແລ້ວ.

ເຖິງແມ່ນວ່າ LLM ແບບທົ່ວໄປຈະສາມາດຕອບໄດ້ທຸກຄຳຖາມ, ແຕ່ມັນກໍສິ້ນເປືອງ Context Window ຢ່າງຫຼວງຫຼາຍ ເຖິງແມ່ນຈະເປັນພຽງວຽກງານການ Routing ຫຼື ການຈັດໝວດໝູ່ແບບງ່າຍໆກໍຕາມ. ສິ່ງທີ່ມີປະສິດທິພາບໃນກໍລະນີນີ້ ຄືການນຳໃຊ້ວິທີ ແຍກວຽກງານສະເພາະອອກໄປໃຫ້ SLM (Small Language Model) ທີ່ຜ່ານການ Fine-tuning ແລ້ວ.

ມາດຖານໃນການຕັດສິນໃຈແບ່ງແຍກ ຄື "ຄວາມເປັນແບບແຜນຂອງວຽກງານ (Task standardization)".

• ວຽກງານທີ່ມີຄວາມເປັນແບບແຜນສູງ (ການຈັດໝວດໝູ່ທາງອາລົມ, ການຈັດປະເພດ, ການສະກັດຂໍ້ຄວາມສັ້ນ) → ມອບໝາຍໃຫ້ SLM ຫຼື Model ທີ່ຜ່ານການ Fine-tuning.
• ວຽກງານການວິເຄາະລະດັບກາງ (ການສະຫຼຸບຄວາມ, ການແປພາສາ, ການສະກັດຂໍ້ມູນທີ່ມີໂຄງສ້າງ) → ຫຼາຍກໍລະນີສາມາດຮອງຮັບໄດ້ດ້ວຍ Model ທີ່ມີນ້ຳໜັກເບົາ.
• ວຽກງານການວິເຄາະ ແລະ ການສ້າງສັນທີ່ຊັບຊ້ອນ (ການວາງແຜນຫຼາຍຂັ້ນຕອນ, ການສ້າງ Code) → ຮັກສາການໃຊ້ງານ LLM ຂະໜາດໃຫຍ່ໄວ້.

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

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

ການປະສົມປະສານລະຫວ່າງ AI Guardrails ແລະການອອກແບບ Orchestration ຈະຊ່ວຍໃຫ້ສາມາດຄວບຄຸມ Token Traps ໄດ້ຢ່າງມີໂຄງສ້າງ. ຕໍ່ໄປນີ້ຈະອະທິບາຍວິທີການນຳໄປໃຊ້ງານຕົວຈິງໂດຍແບ່ງອອກເປັນ 3 ຊັ້ນ ຄື: ການບໍລິຫານຈັດການງົບປະມານ, ມາດຕະການປ້ອງກັນ Injection ແລະ HITL (Human-in-the-Loop).

ຊັ້ນການຈັດການ Agent (Agent Orchestration Layer) ແມ່ນຈຸດສຳຄັນ ຫຼື ແກນຫຼັກ ດຽວທີ່ສາມາດຄວບຄຸມການໃຊ້ງານ Token ຂອງລະບົບທັງໝົດທີ່ Sub-agent ຫຼາຍຕົວເຮັດວຽກຮ່ວມກັນໄດ້.

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

ມາດຕະການຫຼັກທີ່ຄວນນຳໄປປະຕິບັດໃນຊັ້ນ Orchestration ມີດັ່ງນີ້:

• ການຈັດສັນງົບປະມານ Token ລ່ວງໜ້າ: ກຳນົດຂີດຈຳກັດຂອງ Token ໃຫ້ແຕ່ລະ Node ໃນ Task Graph ກ່ອນການປະຕິບັດງານ. ຖ້າປະລິມານທີ່ເຫຼືອຫຼຸດລົງຕໍ່າກວ່າເກນທີ່ກຳນົດໄວ້, ໃຫ້ຢຸດການເຮັດວຽກຂອງ Sub-task ນັ້ນ ຫຼື ປ່ຽນໄປໃຊ້ SLM (Small Language Model) ແທນ.
• ການຕິດຕາມການໃຊ້ງານສະສົມແບບ Real-time: ລວມຍອດການໃຊ້ງານທີ່ຢູ່ໃນຊ່ອງຂໍ້ມູນຂອງ API Response, ໂດຍໃຫ້ Orchestrator ຮັກສາຂໍ້ມູນປະລິມານການໃຊ້ງານຕໍ່ Session ແລະ ຕໍ່ Agent ໄວ້ຕະຫຼອດເວລາ.
• ການຄວບຄຸມ Throttling ແລະ ລຳດັບຄວາມສຳຄັນ: ຈັດສັນງົບປະມານໃຫ້ກັບ Task ທີ່ມີຄວາມສຳຄັນສູງກ່ອນ, ສ່ວນ Task ທີ່ມີຄວາມສຳຄັນຕໍ່າໃຫ້ຈັດການດ້ວຍການເຂົ້າຄິວ (Queuing) ຫຼື ການຫຼຸດຈຳນວນລົງ.

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

Prompt Injection ເປັນທັງຄວາມສ່ຽງດ້ານຄວາມປອດໄພ ແລະ ເປັນປັດໄຈແຝງທີ່ເຮັດໃຫ້ການບໍລິໂພກ Token ເພີ່ມຂຶ້ນຢ່າງກະທັນຫັນ.

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

ການເລືອກມາດຕະການປ້ອງກັນຂຶ້ນຢູ່ກັບສະຖານະການ. ຫາກຈັດການກັບແຫຼ່ງຂໍ້ມູນພາຍນອກ (ການດຶງຂໍ້ມູນຈາກເວັບ, ການປ້ອນຂໍ້ມູນຈາກຜູ້ໃຊ້, ຖານຂໍ້ມູນ) ຄວນໃຫ້ຄວາມສຳຄັນກັບ Prompt Firewall ແລະ ການກວດສອບຄວາມຖືກຕ້ອງຂອງຂໍ້ມູນ (Input Sanitization), ສ່ວນໃນສະພາບແວດລ້ອມປິດທີ່ຈັດການກັບຂໍ້ມູນພາຍໃນເທົ່ານັ້ນ ການຈັດໂຄງສ້າງ System Prompt ແລະ ການຈຳກັດຂອບເຂດສິດທິ (Permission Scope) ຈະມີປະສິດທິຜົນຫຼາຍກວ່າ.

ມາດຕະການທີ່ມີປະສິດທິຜົນໂດຍລະອຽດມີດັ່ງນີ້:

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

HITL (Human-in-the-Loop) ແມ່ນວິທີການອອກແບບທີ່ກຳນົດຈຸດກວດສອບໃຫ້ມະນຸດເປັນຜູ້ກວດສອບ ແລະ ອະນຸມັດການກະທຳຂອງ Agent. ໃນບໍລິບົດຂອງ Token Trap, ມັນຈະເຮັດໜ້າທີ່ເປັນ "ປະຕູ" (Gate) ທີ່ບໍ່ສາມາດດຳເນີນການຂັ້ນຕອນຕໍ່ໄປໄດ້ຫາກບໍ່ໄດ້ຮັບການອະນຸມັດ.

ຈຸດກວດສອບ (Gate Points) ທີ່ຄວນຕິດຕັ້ງ:

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

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

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

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

ຮູບແບບຄວາມຜິດພາດທົ່ວໄປທີ່ເກີດຈາກການຂາດບັນທຶກ (Log) ສາມາດແບ່ງອອກໄດ້ເປັນ 3 ປະການໃຫຍ່ໆ:

• ບໍ່ມີການສະຫຼຸບຍອດແຍກຕາມ Model ຫຼື Endpoint: ບໍ່ສາມາດລະບຸໄດ້ວ່າ Agent ໃດເປັນຜູ້ໃຊ້ງານ ເຮັດໃຫ້ເສຍເວລາໃນການກວດສອບສາເຫດ.
• ບໍ່ມີການແຍກ Input ແລະ Output Token: Model ສ່ວນຫຼາຍມີລາຄາຕໍ່ໜ່ວຍຂອງ Output Token ສູງກວ່າ Input, ດ້ວຍເຫດນີ້ການເບິ່ງຂ້າມການເພີ່ມຂຶ້ນຂອງປະລິມານ Output ຈະເຮັດໃຫ້ການສູນເສຍຂະຫຍາຍຕົວໄດ້ງ່າຍ.
• ການຂາດບັນທຶກການ Retry ເມື່ອເກີດຂໍ້ຜິດພາດ: ຫາກມີການ Retry ອັດຕະໂນມັດເນື່ອງຈາກ Timeout ຫຼື API Error, ການໃຊ້ງານ Token ຂອງວຽກດຽວກັນອາດເພີ່ມຂຶ້ນສອງເທົ່າໂດຍທີ່ບໍ່ຮູ້ຕົວ.

ນອກຈາກນີ້, Model ສ່ວນຫຼາຍຈະມີຄ່າເລີ່ມຕົ້ນຂອງຈຳນວນ Output Token ສູງສຸດທີ່ກຳນົດໄວ້ ໃນຂະນະທີ່ທາງ Input ນັ້ນ Rate Limit (ເຊັ່ນ TPM) ມັກຈະຖືກຕັ້ງໄວ້ສູງຫຼາຍ, ແລະ ຍິ່ງຂີດຈຳກັດສູງເທົ່າໃດ ກໍຍິ່ງເກີດການບໍລິໂພກຈຳນວນມະຫາສານໂດຍບໍ່ໄດ້ຕັ້ງໃຈໄດ້ງ່າຍຂຶ້ນ. ຫາກບໍ່ມີ Log ແບບ Real-time, ກໍຈະບໍ່ສາມາດສັງເກດເຫັນຄວາມຜິດປົກກະຕິເຫຼົ່ານີ້ໄດ້.

ສິ່ງທີ່ທັງໝົດນີ້ມີຮ່ວມກັນຄື ການຕັດສິນໃຈໃນການອອກແບບທີ່ເຫັນວ່າການເກັບ Log ເປັນ "ຟັງຊັນທີ່ເພີ່ມເຂົ້າມາພາຍຫຼັງ" ຈຶ່ງປ່ອຍປະລະເລີຍໄວ້.

ມີການລາຍງານກໍລະນີທີ່ຄ່າໃຊ້ຈ່າຍເພີ່ມທະວີຂຶ້ນຫຼາຍສິບເທົ່າໃນເວລາອັນສັ້ນ ຫາກມີການນຳໃຊ້ການຮຽກຊ້ຳ (Recursive call) ໂດຍທີ່ເງື່ອນໄຂໃນການຢຸດເຮັດວຽກຍັງບໍ່ຊັດເຈນ.

ຮູບແບບທີ່ພົບເຫັນເລື້ອຍໆມີດັ່ງນີ້:

• ເອເຈນ (Agent) ຮຽກໃຊ້ງານຕົນເອງຄືນໃໝ່ທຸກຄັ້ງທີ່ຕັດສິນວ່າ "ວຽກຍັງບໍ່ສຳເລັດ"
• ໃນແຕ່ລະການຮຽກໃຊ້ງານ ຈະນຳເອົາຜົນລວມຂອງຮອບກ່ອນໜ້າທັງໝົດມາໃສ່ໃນບໍລິບົດ (Context)
• ເມື່ອໜ້າຕ່າງບໍລິບົດ (Context window) ສະສົມຫຼາຍຂຶ້ນ ຈຳນວນ Token ຕໍ່ຄັ້ງກໍຈະເພີ່ມຂຶ້ນແບບທະວີຄູນ

ຂີດຈຳກັດອັດຕາ (Rate Limit) ຂອງ Cloud LLM ມັກຈະຖືກຕັ້ງໄວ້ສູງຫຼາຍ, ແລະ ຍິ່ງຂີດຈຳກັດສູງເທົ່າໃດ ກໍຍິ່ງເກີດການບໍລິໂພກຈຳນວນມະຫາສານໂດຍບໍ່ໄດ້ຕັ້ງໃຈໄດ້ງ່າຍຂຶ້ນ. ໃນກໍລະນີທີ່ການຈັດການຂໍ້ຜິດພາດ (Error handling) ບໍ່ພຽງພໍ, ຕົວຢ່າງທີ່ພົບເລື້ອຍຄື ເອເຈນເຂົ້າໃຈຜິດວ່າການໝົດເວລາ (Timeout) ຂອງ API ພາຍນອກຄື "ວຽກລົ້ມເຫຼວ" ຈຶ່ງເຮັດໃຫ້ມັນສົ່ງຄຳຮ້ອງຂໍເດີມຊ້ຳໆ. ພຽງແຕ່ loop ໝູນວຽນຄົບ 10 ຮອບ, ການບໍລິໂພກ Token ກໍອາດຈະສູງເຖິງຫຼາຍສິບເທົ່າຂອງຈຳນວນເດີມເນື່ອງຈາກການສະສົມຂອງບໍລິບົດ.

ມາດຕະຖານໃນການຕັດສິນໃຈແກ້ໄຂບັນຫານັ້ນຂຶ້ນຢູ່ກັບສະຖານະການ. ຫາກສາມາດຄາດຄະເນຈຳນວນຮອບຂອງ loop ໄດ້, ການກຳນົດຂີດຈຳກັດຈຳນວນຮອບສູງສຸດ (max_iterations) ໄວ້ໃນໂຄ້ດ (Hardcode) ແມ່ນວິທີທີ່ແນ່ນອນທີ່ສຸດ. ໃນທາງກົງກັນຂ້າມ, ຫາກເປັນວຽກທີ່ມີລັກສະນະເຄື່ອນໄຫວ (Dynamic task) ເຊິ່ງບໍ່ສາມາດກຳນົດຈຳນວນຮອບໄດ້, ການອອກແບບໃຫ້ລະບົບຢຸດເຮັດວຽກທັນທີເມື່ອຈຳນວນ Token ສະສົມເກີນຂີດຈຳກັດທີ່ກຳນົດໄວ້ ແລ້ວສົ່ງຕໍ່ໃຫ້ HITL (Human-in-the-Loop) ແມ່ນວິທີທີ່ເໝາະສົມທີ່ສຸດ.

ຕໍ່ໄປນີ້ແມ່ນມາດຕະການທີ່ມີປະສິດທິພາບເພື່ອປ້ອງກັນບໍ່ໃຫ້ເກີດບັນຫາຊ້ຳອີກ: