ການຂະຫຍາຍຕົວໃນຂະນະປະມວນຜົນ (Inference Scaling) ແມ່ນຫຍັງ? ວິທີປັບປຸງການແລກປ່ຽນ ຫຼື Trade-off ລະຫວ່າງຕົ້ນທຶນ ແລະ ຄວາມແມ່ນຍຳຂອງ AI Inference

ການຂະຫຍາຍຕົວໃນຂະນະປະມວນຜົນ (Test-Time Compute) ແມ່ນຄຳສັບລວມຂອງກຸ່ມວິທີການທີ່ເພີ່ມປະລິມານການຄຳນວນຢ່າງຕັ້ງໃຈໃນຂັ້ນຕອນທີ່ LLM ກຳລັງໃຫ້ຄຳຕອບ ເພື່ອຍົກລະດັບຄວາມຖືກຕ້ອງໃນການອະນຸມານ. ເມື່ອປຽບທຽບກັບກົດການຂະຫຍາຍຕົວ (Scaling Laws) ແບບດັ້ງເດີມທີ່ເນັ້ນການປ້ອນຂໍ້ມູນ ແລະ ການຄຳນວນຈຳນວນຫຼາຍໃນຂັ້ນຕອນການຝຶກຝົນ, ແນວຄວາມຄິດທີ່ວ່າການເພີ່ມການຄຳນວນໃນຂະນະອະນຸມານຈະຊ່ວຍເພີ່ມປະສິດທິພາບໄດ້ນັ້ນ ໄດ້ແຜ່ຂະຫຍາຍຢ່າງວ່ອງໄວພ້ອມກັບການປະກົດຕົວຂອງແບບຈຳລອງການອະນຸມານ (Inference Models).

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

ການຂະຫຍາຍຕົວໃນຂະນະປະມວນຜົນ (Inference Scaling) ບໍ່ແມ່ນວິທີການ "ເພີ່ມການຮຽນຮູ້" ແຕ່ເປັນການ "ເພີ່ມເວລາໃນການຄິດ". ໂດຍສະເພາະ, ມັນໝາຍເຖິງກຸ່ມວິທີການທີ່ຊ່ວຍຍົກລະດັບຄຸນນະພາບຂອງຄຳຕອບໂດຍການເພີ່ມປະລິມານການຄິດໄລ່ໃນການປະມວນຜົນ ເຊັ່ນ: ການຄິດແບບເປັນຂັ້ນຕອນ (Step-by-step), ການສຸ່ມຕົວຢ່າງຫຼາຍຄັ້ງ, ແລະ ການປຽບທຽບວິທີແກ້ໄຂແບບສຳຫຼວດ.

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

ການຂະຫຍາຍຂະໜາດໃນຂັ້ນຕອນການອະນຸມານ (Inference-time scaling) ແມ່ນຄຳສັບລວມຂອງວິທີການທີ່ຊ່ວຍປັບປຸງປະສິດທິພາບຂອງແບບຈຳລອງໂດຍການເພີ່ມປະລິມານການຄຳນວນໃນຂັ້ນຕອນການອະນຸມານ (ຈຳນວນ Token ທີ່ສ້າງຂຶ້ນ, ຈຳນວນຄັ້ງຂອງການສຸ່ມຕົວຢ່າງ, ແລະ ຄວາມເລິກໃນການຄົ້ນຫາ). ວິທີການຕ່າງໆເຊັ່ນ: Chain-of-Thought (CoT), Self-consistency, Best-of-N, Tree-of-Thoughts, ແລະ Reflection ລ້ວນແຕ່ຖືກລວມຢູ່ໃນຂອບເຂດນີ້.

ການຂະຫຍາຍຂະໜາດໃນຂັ້ນຕອນການຮຽນຮູ້ (Pre-training Scaling) ເຊິ່ງເປັນກະແສຫຼັກໃນການພັດທະນາ LLM ແບບດັ້ງເດີມນັ້ນ ແມ່ນອີງໃສ່ Scaling Law ທີ່ວ່າ ຖ້າເພີ່ມຈຳນວນພາຣາມິເຕີ, ປະລິມານຂໍ້ມູນການຮຽນຮູ້, ແລະ ປະລິມານການຄຳນວນໃນການຮຽນຮູ້ໃຫ້ຫຼາຍຂຶ້ນ ປະສິດທິພາບກໍຈະເພີ່ມຂຶ້ນ. ຢ່າງໃດກໍຕາມ, ການຮຽນຮູ້ຂະໜາດໃຫຍ່ມັກຈະປະເຊີນກັບຂໍ້ຈຳກັດດ້ານຕົ້ນທຶນ, ຂໍ້ມູນ, ແລະ ພະລັງງານໄຟຟ້າ, ອີກທັງຍັງມີການຊີ້ໃຫ້ເຫັນວ່າເສັ້ນສະແດງປະສິດທິພາບກໍເລີ່ມຊ້າລົງ.

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

→ ທີ່ກ່ຽວຂ້ອງ: ຄູ່ມືການປັບຕົ້ນທຶນ LLM, ວິທີການເລືອກລະຫວ່າງ Fine-tuning ແລະ RAG

ການຂະຫຍາຍຕົວໃນຂະນະປະມວນຜົນ (Inference Scaling) ເລີ່ມໄດ້ຮັບຄວາມສົນໃຈຢ່າງຈິງຈັງ ເນື່ອງມາຈາກການທີ່ OpenAI ໄດ້ນຳໃຊ້ລະບົບໂມເດວການປະມວນຜົນ, DeepSeek ໄດ້ນຳໃຊ້ໂມເດວທີ່ເສີມຄວາມສາມາດໃນການປະມວນຜົນ, ແລະ Google ໄດ້ນຳໃຊ້ໂມເດວການປະມວນຜົນ ເຊິ່ງທັງໝົດນີ້ໄດ້ນຳໃຊ້ສະຖາປັດຕະຍະກຳທີ່ໃຊ້ Token ຈຳນວນມະຫາສານໃນຂະບວນການຄິດພາຍໃນ. ໂມເດວເຫຼົ່ານີ້ຈະສ້າງ Token ເພື່ອ "ຄິດ" ຢູ່ພາຍໃນເປັນເວລາດົນ ກ່ອນທີ່ຈະໃຫ້ຄຳຕອບສຸດທ້າຍ.

ຜົນກະທົບຕໍ່ອຸດສາຫະກຳນັ້ນມີຫຼາຍ ແລະ ກຳລັງເກີດການຖົກຖຽງກັນໃນສອງທິດທາງ:

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

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

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

ໃນຂະນະທີ່ມີການຊີ້ໃຫ້ເຫັນວ່າ Scaling Law ຝ່າຍການຮຽນຮູ້ (Learning) ເລີ່ມຮອດຂີດຈຳກັດ ແຕ່ຝ່າຍການອະນຸມານ (Inference) ຍັງມີຊ່ອງວ່າງໃຫ້ພັດທະນາໄດ້ອີກຫຼາຍ. ຍິ່ງໄປກວ່ານັ້ນ, ການນຳໃຊ້ AI ໃນວຽກງານໄດ້ຂະຫຍາຍຈາກ "ການຕອບໂຕ້ແບບຮູບແບບເດີມ" ໄປສູ່ "ການປະມວນຜົນທີ່ຕ້ອງໃຊ້ການຕັດສິນໃຈ", ເຮັດໃຫ້ຄວາມຕ້ອງການດ້ານຄວາມແມ່ນຍຳເພີ່ມທະວີຂຶ້ນເລື້ອຍໆ. ສອງປັດໄຈນີ້ໄດ້ຍົກລະດັບໃຫ້ການຂະຫຍາຍຕົວໃນຂະນະອະນຸມານ (Inference-time scaling) ກາຍເປັນຫົວຂໍ້ຫຼັກໃນການປະຕິບັດງານ.

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

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

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

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

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

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

→ ທີ່ກ່ຽວຂ້ອງ: Context Engineering, Hybrid LLM × SLM Routing

ການຂະຫຍາຍຂະໜາດໃນຂະນະປະມວນຜົນ (Inference-time scaling) ຈະມີປະສິດທິຜົນໂດຍສະເພາະກັບ "ບັນຫາທີ່ບໍ່ສາມາດຫາຄຳຕອບໄດ້ໃນຄັ້ງດຽວ". ຕົວຢ່າງທີ່ເປັນຮູບປະທຳມີດັ່ງນີ້:

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

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

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

ການຂະຫຍາຍຕົວໃນຂະນະປະມວນຜົນ (Inference Scaling) ສາມາດແບ່ງອອກເປັນ 3 ສາຍຫຼັກ ຄື: ການຂະຫຍາຍຕົວພາຍໃນ (Internal Scaling), ການຂະຫຍາຍຕົວແບບຂະໜານ (Parallel Scaling) ແລະ ການຂະຫຍາຍຕົວແບບຄົ້ນຫາ (Search Scaling). ເນື່ອງຈາກວິທີການຕ່າງໆມີວິທີການເພີ່ມທະວີຂຶ້ນເລື້ອຍໆ ຂອງຕົ້ນທຶນການຄຳນວນ ແລະ ວຽກງານທີ່ເໝາະສົມແຕກຕ່າງກັນ, ການເລືອກໃຫ້ເໝາະສົມກັບກໍລະນີການນຳໃຊ້ (Use case) ຈຶ່ງມີຄວາມສຳຄັນຫຼາຍ.

ໃນທີ່ນີ້, ຈະຂໍສະຫຼຸບກົນໄກ, ວຽກງານທີ່ເໝາະສົມ ແລະ ລະດັບຕົ້ນທຶນຂອງ 3 ສາຍຫຼັກທີ່ເປັນຕົວແທນດັ່ງກ່າວ.

ການຂະຫຍາຍຕົວພາຍໃນ (Internal Scaling) ແມ່ນວິທີການທີ່ເຮັດໃຫ້ໂມເດວໃຊ້ເວລາຄິດດົນຂຶ້ນພາຍໃນການຮ້ອງຂໍ (Request) ດຽວ. ຕົວຢ່າງທີ່ເຫັນໄດ້ຊັດເຈນມີດັ່ງນີ້:

• Chain-of-Thought (CoT): ການກະຕຸ້ນດ້ວຍຄຳສັ່ງ "ໃຫ້ຄິດແບບເປັນຂັ້ນເປັນຕອນ" ເພື່ອສ້າງຂະບວນການຫາເຫດຜົນກ່ອນຈະສະຫຼຸບຜົນ.
• Reflection / Self-correction: ຫຼັງຈາກສ້າງຄຳຕອບແລ້ວ, ໃຫ້ໂມເດວທົບທວນຄືນດ້ວຍຕົນເອງວ່າ "ມີຂໍ້ຜິດພາດຫຼືບໍ່" ແລ້ວຈຶ່ງແກ້ໄຂ.
• ການຄິດພາຍໃນຂອງໂມເດວການຫາເຫດຜົນ (Reasoning Model): ໂມເດວການຫາເຫດຜົນຂອງຜູ້ໃຫ້ບໍລິການຫຼັກໆ ຈະຄິດຢ່າງເລິກເຊິ່ງຜ່ານ Token ພາຍໃນທີ່ຜູ້ໃຊ້ເບິ່ງບໍ່ເຫັນ ກ່ອນທີ່ຈະສະແດງຄຳຕອບອອກມາ.

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

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

ການຂະຫຍາຍຕົວແບບຂະໜານ (Parallel Scaling) ແມ່ນວິທີການທີ່ໃຫ້ໂມເດວຕອບຄຳຖາມດຽວກັນຫຼາຍໆຄັ້ງຢ່າງເປັນອິດສະຫຼະ ແລ້ວຈຶ່ງນຳຜົນລັອກມາລວມ ຫຼື Merge ເຂົ້າກັນ.

• Self-consistency: ເພີ່ມຄ່າ Temperature parameter ເພື່ອສ້າງຄຳຕອບທີ່ຫຼາກຫຼາຍ ແລະ ເລືອກເອົາຂໍ້ສະຫຼຸບທີ່ພົບເລື້ອຍທີ່ສຸດເປັນຄຳຕອບສຸດທ້າຍ
• Best-of-N: ສ້າງຄຳຕອບ N ຄັ້ງ ແລ້ວເລືອກເອົາອັນທີ່ດີທີ່ສຸດໂດຍໃຊ້ໂມເດວປະເມີນຜົນ ຫຼື ຟັງຊັນການໃຫ້ຄະແນນ
• Majority voting: ຕັດສິນຂໍ້ສະຫຼຸບດ້ວຍການລົງຄະແນນສຽງສ່ວນຫຼາຍ ເຊິ່ງມີປະສິດທິຜົນສູງໃນວຽກງານດ້ານເລກຄະນິດ ແລະ ການຈັດໝວດໝູ່

ໃນການປະຕິບັດງານຕົວຈິງ, ການໃຊ້ຂະໜານ 3-5 ເທົ່າ ມັກຈະເຫັນການປັບປຸງທີ່ພຽງພໍ ແລະ ເຖິງແມ່ນວ່າຈະເພີ່ມລະດັບການຂະໜານຂຶ້ນໄປອີກ ຄວາມແມ່ນຍຳກໍຈະອີ່ມຕົວ. ເງື່ອນໄຂເບື້ອງຕົ້ນຂອງການປະມວນຜົນແບບຂະໜານແມ່ນຕ້ອງກວດສອບຂີດຈຳກັດການຮຽກໃຊ້ໂມເດວ API (Rate Limit / Concurrency Limit) ໄວ້ກ່ອນ.

→ ທີ່ກ່ຽວຂ້ອງ: ການປະເມີນຜົນລັອກ AI ໂດຍໃຊ້ LLM-as-a-Judge

ການຂະຫຍາຍຂອບເຂດການຄົ້ນຫາ (Exploration Scaling) ແມ່ນວິທີການທີ່ຂະຫຍາຍຕົວເລືອກຄຳຕອບໃນຮູບແບບໂຄງສ້າງຕົ້ນໄມ້ (Tree Structure) ແລ້ວຄ່ອຍໆປະເມີນ ແລະ ຂຸດເລິກລົງໃນສາຂາທີ່ມີທ່າແຮງ.

• Tree-of-Thoughts（ToT）: ຂະຫຍາຍຂະບວນການຄິດໃນຮູບແບບໂຄງສ້າງຕົ້ນໄມ້ ແລ້ວປະເມີນແຕ່ລະ Node ເພື່ອເລືອກສາຂາທີ່ມີທ່າແຮງ
• MCTS（Monte Carlo Tree Search）: ນຳໃຊ້ Algorithm ການຄົ້ນຫາທີ່ໃຊ້ໃນ Game AI ມາປະຍຸກໃຊ້ກັບການໃຊ້ເຫດຜົນ ໂດຍອາໄສການຈຳລອງ ແລະ ການປະເມີນຊ້ຳໆ
• Beam Search ຂະຫຍາຍ: ຮັກສາຕົວເລືອກ k ອັນດັບຕົ້ນໄວ້ໃນແຕ່ລະຂັ້ນຕອນ ແລ້ວເລືອກເສັ້ນທາງທີ່ດີທີ່ສຸດໃນທ້າຍສຸດ

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

→ ທີ່ກ່ຽວຂ້ອງ: Multi-Agent AI

ການຂະຫຍາຍຕົວໃນຂະນະປະມວນຜົນ (Inference-time scaling) ບໍ່ແມ່ນສິ່ງທີ່ "ໃຊ້ແລ້ວຈະດີຂຶ້ນສະເໝີໄປ", ແຕ່ຈຳເປັນຕ້ອງມີການຕັດສິນໃຈດ້ານການອອກແບບໂດຍອີງໃສ່ລະດັບຄວາມຍາກຂອງວຽກ, ຄວາມໜ່ວງ (Latency) ທີ່ຍອມຮັບໄດ້, ແລະ ຂີດຈຳກັດຂອງຕົ້ນທຶນ. ການກຳນົດຕົວຊີ້ວັດການປະເມີນຜົນ ແລະ ຮູບແບບການດຳເນີນງານໃຫ້ສອດຄ່ອງກັນກ່ອນການນຳໃຊ້ ແມ່ນກຸນແຈສຳຄັນໃນການນຳ PoC ໄປສູ່ການໃຊ້ງານຈິງ.

ໃນພາກນີ້, ພວກເຮົາຈະມາຈັດລະບຽບວິທີການເລືອກທາງເລືອກຕາມລະດັບຄວາມຍາກຂອງວຽກ, ການອອກແບບການແລກປ່ຽນ ຫຼື Trade-off, ແລະ ວິທີການກຳນົດຕົວຊີ້ວັດການປະເມີນຜົນ PoC.

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

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

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

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

→ ເບິ່ງເພີ່ມເຕີມ: AI Agent ROI Measurement Guide

ການຂະຫຍາຍຕົວໃນຂະນະປະມວນຜົນ (Inference-time scaling) ແມ່ນການອອກແບບທີ່ຕ້ອງຍອມເສຍຄ່າໃຊ້ຈ່າຍ ແລະ ຄວາມໜ່ວງ (Latency) ເພື່ອແລກກັບຄວາມແມ່ນຍຳ. ຈຳເປັນຕ້ອງຕັດສິນໃຈເລືອກຄວາມສົມດຸນຂອງ 3 ແກນຫຼັກຢ່າງຕັ້ງໃຈ.

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

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

→ ທີ່ກ່ຽວຂ້ອງ: ຄູ່ມືການປັບຄ່າໃຊ້ຈ່າຍ LLM ໃຫ້ເໝາະສົມ

ເພື່ອເຮັດໃຫ້ PoC ຢູ່ໃນສະຖານະທີ່ສາມາດຕັດສິນໃຈນຳໃຊ້ໃນການຜະລິດຈິງໄດ້, ການອອກແບບການປະເມີນຜົນທີ່ສາມາດ "ອະທິບາຍດ້ວຍຕົວເລກ" ໄດ້ສຳລັບການຂະຫຍາຍຂະໜາດໃນຂະນະປະມວນຜົນ (Inference-time scaling) ແມ່ນມີຄວາມສຳຄັນຫຼາຍ. ຢ່າງໜ້ອຍທີ່ສຸດ, ຕ້ອງມີ 4 ແກນຫຼັກດັ່ງນີ້:

1. ຄວາມຖືກຕ້ອງຂອງວຽກງານ (Task Accuracy): ອັດຕາຄວາມສຳເລັດທີ່ມີຄວາມໝາຍໃນທາງທຸລະກິດ (ຕົວຢ່າງ: F1 score ຂອງວຽກງານການສະກັດຂໍ້ມູນ, ອັດຕາຄວາມຖືກຕ້ອງຂອງຄຳຕອບ, ອັດຕາການພາດການຊີ້ແນະໃນການກວດສອບ).
2. ຕົ້ນທຶນຕໍ່ລາຍການ (Cost per item): ວັດແທກຕົ້ນທຶນການປະມວນຜົນຕໍ່ 1 ລາຍການ (Input/Output + Thinking tokens + ການປະມວນຜົນຂະໜານ).
3. P50 / P95 Latency: ໃຊ້ເປີເຊັນໄທລ໌ (Percentile) ແທນຄ່າສະເລ່ຍ ເພື່ອເບິ່ງວ່າສາມາດຮອງຮັບ SLA ຂອງທຸລະກິດໄດ້ຫຼາຍໜ້ອຍພຽງໃດ.
4. ການກະຈາຍຕົວຂອງຮູບແບບຄວາມຜິດພາດ (Failure mode distribution): ຄວາມຜິດພາດປະເພດໃດທີ່ຍັງຄົງຢູ່ (ການສະກັດຂໍ້ມູນຜິດ, ພາບຫຼອນ ຫຼື Hallucination, ຄວາມໝັ້ນໃຈເກີນຈິງ). ຕັດສິນໃຈວ່າສາມາດຮັບມືໄດ້ດ້ວຍຂະບວນການ ຫຼື Pipeline ການປ້ອງກັນໃນຂັ້ນຕອນຕໍ່ໄປຫຼືບໍ່.

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

ຂໍ້ມູນທີ່ໃຊ້ໃນການປະເມີນຄວນມີຢ່າງໜ້ອຍ 100 ລາຍການ, ຖ້າເປັນໄປໄດ້ຄວນມີ 500 ລາຍການຂຶ້ນໄປ. ເພື່ອບໍ່ໃຫ້ຄວາມຍາກ, ໝວດໝູ່ ແລະ ຮູບແບບຂໍ້ຍົກເວັ້ນມີຄວາມລຳອຽງ, ແນະນຳໃຫ້ໃຊ້ການສຸ່ມແບບແບ່ງຊັ້ນ (Stratified sampling) ຈາກບັນທຶກການດຳເນີນງານທີ່ມີຢູ່.

→ ທີ່ກ່ຽວຂ້ອງ: AI Observability, ຄູ່ມືການປະເມີນຜົນ LLM-as-a-Judge

「ຖ້າເພີ່ມປະລິມານການຄຳນວນແລ້ວ ຄວາມແມ້ນຍຳຈະເພີ່ມຂຶ້ນຢ່າງແນ່ນອນ」「ຖ້ານຳໄປຕິດຕັ້ງເພີ່ມເຕີມໃນແອັບ LLM ທີ່ມີຢູ່ແລ້ວ ກໍຈະສາມາດຍົກລະດັບຂຶ້ນໄດ້」—— ຄວາມຄາດຫວັງທີ່ກ່ຽວຂ້ອງກັບການຂະຫຍາຍຂະໜາດໃນຂະນະປະມວນຜົນ (Inference-time scaling) ນັ້ນ ມັກຈະມີຄວາມເຂົ້າໃຈຜິດທີ່ອາດນຳໄປສູ່ບັນຫາໃນການນຳໃຊ້ຕົວຈິງແຝງຢູ່.

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

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

ແນວໂນ້ມທີ່ເຫັນໄດ້ຈາກບົດລາຍງານການວິໄຈ ແລະ ການກວດສອບຂອງຊຸມຊົນມີດັ່ງນີ້:

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

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

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

→ ທີ່ກ່ຽວຂ້ອງ: ຮູບແບບຄວາມລົ້ມເຫຼວໃນການສ້າງ RAG

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

• ການທຳລາຍ Latency SLA: ໃນ Chat UI, ການເພີ່ມ Token ທີ່ໃຊ້ໃນການຄິດອາດເຮັດໃຫ້ການຕອບໂຕ້ຊ້າລົງຫຼາຍວິນາທີ ເຊິ່ງສົ່ງຜົນໃຫ້ຜູ້ໃຊ້ງານຫຼຸດລົງ
• ໂຄງສ້າງຕົ້ນທຶນພັງທະລາຍ: ການຄາດຄະເນຕົ້ນທຶນລາຍເດືອນຜິດພາດ ເຊິ່ງຫຼາຍກໍລະນີມັກຈະຮູ້ຕົວເມື່ອເຫັນໃບແຈ້ງໜີ້ເທົ່ານັ້ນ
• ການສູນເສຍຄວາມເຂົ້າກັນໄດ້ຂອງ Prompt: Prompt ທີ່ມີຢູ່ບໍ່ໄດ້ຖືກປັບໃຫ້ເໝາະສົມກັບຮູບແບບການປະມວນຜົນ (Inference model) ເຮັດໃຫ້ຮູບແບບຜົນລວມ ຫຼື Merge ຜິດພາດ
• ຊັບສິນການທົດສອບເສື່ອມສະພາບ: ການທົດສອບອັດຕະໂນມັດທີ່ຕັ້ງຄ່າໄວ້ສຳລັບການສ້າງຜົນລວມແບບຄັ້ງດຽວບໍ່ສາມາດຜ່ານໄດ້

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

ໃນຂັ້ນຕອນການນຳໃຊ້, ກົດເຫຼັກແມ່ນ ຄວນທົດສອບລ່ວງໜ້າໃນກຸ່ມຍ່ອຍ (ຜູ້ໃຊ້ສະເພາະ ຫຼື ປະເພດວຽກສະເພາະ) ກ່ອນທີ່ຈະຂະຫຍາຍໄປສູ່ທຸກ Request. ຄວນມີການຕິດຕັ້ງ Feature flag ຫຼື Routing layer ເພື່ອໃຫ້ສາມາດປ່ຽນກັບຄືນໄດ້ທັນທີ.

→ ເບິ່ງເພີ່ມເຕີມ: ຄູ່ມືການຈັດຕັ້ງປະຕິບັດ AI Guardrails

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

ຕໍ່ໄປນີ້ແມ່ນຈຸດສຳຄັນທີ່ຄວນຮັກສາໄວ້ໃນການນຳໃຊ້ຈິງ:

1. ຄວາມຕ້ອງການຂັ້ນຕໍ່າໃນການຕິດຕາມກວດກາ

• ບັນທຶກ Log ຂອງ Input/Output Token, Thinking Token ແລະ ລະດັບການປະມວນຜົນຂະໜານ (Parallelism) ໃນແຕ່ລະຄຳຮ້ອງຂໍ (Request)
• ຕິດຕາມກວດກາ P50 / P95 / P99 Latency ແບບ Real-time ແລະ ເຮັດໃຫ້ເຫັນພາບເງື່ອນໄຂການເກີດຄ່າທີ່ຜິດປົກກະຕິ (Outliers)
• ວັດແທກ ດັດຊະນີຄວາມແມ່ນຍຳແຍກຕາມປະເພດວຽກ ຢ່າງຕໍ່ເນື່ອງ ໂດຍການປະສົມປະສານລະຫວ່າງການສຸ່ມຕົວຢ່າງ + ການກວດສອບໂດຍມະນຸດ, ຫຼື ການໃຊ້ LLM-as-a-Judge

2. ການອອກແບບລະບົບແຈ້ງເຕືອນ (Alert)

• ກວດຈັບທັນທີເມື່ອຕົ້ນທຶນເກີນລາຄາທີ່ຄາດການໄວ້ 1.5 - 2 ເທົ່າ
• ຕິດຕາມກວດກາຄວາມຜິດພາດ ຫຼື ຄວາມໜ່ວງທີ່ເພີ່ມຂຶ້ນຂອງຕົວແບບການປະມວນຜົນ (ທີ່ເກີດຈາກຜູ້ໃຫ້ບໍລິການ) ຜ່ານລະບົບແຍກຕ່າງຫາກ
• ກວດຈັບການເພີ່ມຂຶ້ນຢ່າງກະທັນຫັນຂອງອັດຕາການຜິດພາດຂອງຮູບແບບຜົນລັດ (ເຊັ່ນ: JSON ລົ້ມເຫຼວ ຫຼື ໂຄງສ້າງຂໍ້ມູນເສຍຫາຍ)

3. ການອອກແບບປຸ່ມປັບແຕ່ງການດຳເນີນງານ (Operation Knobs)

ໃນຂັ້ນຕອນການອອກແບບ, ຄວນກຳນົດ ພາຣາມິເຕີທີ່ສາມາດປັບປ່ຽນໄດ້ໂດຍບໍ່ຕ້ອງຂຽນ Code ໃໝ່ ໃນລະຫວ່າງການດຳເນີນງານ. ໂດຍສະເພາະແມ່ນ:

• ຈຳນວນການສຸ່ມຕົວຢ່າງແບບຂະໜານ (N)
• ອັດຕາການໃຊ້ງານຕົວແບບການປະມວນຜົນ (ການ Routing ທີ່ສາມາດສະຫຼັບໄດ້ຄືກັບການເຮັດ A/B Testing)
• ເກນການຈັດປະເພດຄວາມຍາກງ່າຍຂອງວຽກ
• ຕົວແບບສຳຮອງ (Fallback model) ໃນກໍລະນີທີ່ຕົວແບບຫຼັກມີບັນຫາ

ການຈັດໂຄງສ້າງໃຫ້ສາມາດປ່ຽນແປງສິ່ງເຫຼົ່ານີ້ໄດ້ຈາກໄຟລ໌ຕັ້ງຄ່າ (Configuration file) ຫຼື ໜ້າຈໍການຈັດການ ຈະຊ່ວຍໃຫ້ສາມາດຮັບມືກັບບັນຫາ ຫຼື ການໃຊ້ຈ່າຍເກີນງົບປະມານໄດ້ຢ່າງວ່ອງໄວ.

4. ຮອບວຽນການປັບປຸງ

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

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

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

→ ທີ່ກ່ຽວຂ້ອງ: AI Observability, ຄູ່ມືການວັດແທກ ROI ຂອງ AI Agent

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

ຈຸດສຳຄັນຂອງບົດຄວາມນີ້ມີດັ່ງນີ້:

• ການຂະຫຍາຍຂະໜາດໃນຂະນະປະມວນຜົນມີ 3 ສາຍຫຼັກ ຄື: ພາຍໃນ (Internal), ຂະໜານ (Parallel), ແລະ ການຄົ້ນຫາ (Search) ເຊິ່ງຕ້ອງເລືອກໃຊ້ໃຫ້ເໝາະສົມກັບວຽກແລະຄວາມໜ່ວງທີ່ຍອມຮັບໄດ້
• ການຊ້າລົງຂອງ Scaling Law ໃນດ້ານການຮຽນຮູ້ ແລະ ການປະກົດຕົວຂອງຮູບແບບການປະມວນຜົນ (Inference model) ເຮັດໃຫ້ຄຸນຄ່າປ່ຽນໄປສູ່ການສ້າງຂະບວນການໃນດ້ານການປະມວນຜົນ
• ໃນການເຮັດ PoC, ການອອກແບບເພື່ອປຽບທຽບປະລິມານລະຫວ່າງ ຄວາມຖືກຕ້ອງ, ຕົ້ນທຶນ, ແລະ ຄວາມໜ່ວງ ໂດຍທຽບກັບ Baseline ແມ່ນສິ່ງທີ່ຂາດບໍ່ໄດ້
• ແນວຄິດທີ່ວ່າ "ຍິ່ງເພີ່ມການຄຳນວນ ຄວາມຖືກຕ້ອງກໍຍິ່ງເພີ່ມຂຶ້ນ" ນັ້ນມີເງື່ອນໄຂກຳກັບ ຕ້ອງພິຈາລະນາຈຸດອີ່ມຕົວ ແລະ ວຽກທີ່ເໝາະສົມໃຫ້ດີ
• ການເພີ່ມເຂົ້າໄປໃນແອັບພລິເຄຊັນ LLM ທີ່ມີຢູ່ແລ້ວມັກຈະສົ່ງຜົນຂ້າງຄຽງໄດ້ງ່າຍ ຄວນທົດສອບໃນສ່ວນຍ່ອຍໆກ່ອນ
• ໃນການນຳໃຊ້ຈິງ, ຕ້ອງອອກແບບການຕິດຕາມກວດກາ (Observation), ການແຈ້ງເຕືອນ (Alert), ປຸ່ມຄວບຄຸມການເຮັດວຽກ (Operation knob), ແລະ ຮອບວຽນການປັບປຸງໃຫ້ເປັນສ່ວນໜຶ່ງຂອງການອອກແບບ

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