ການອອກແບບທີ່ປະສົມປະສານລະຫວ່າງ Cloud LLM ແລະ On-device SLM ໂດຍມີການສະຫຼັບການປະມວນຜົນຕາມລັກສະນະຂອງວຽກງານນັ້ນ ເອີ້ນວ່າ "Hybrid LLM Design".

ການເພິ່ງພາອາໄສໂມເດວພຽງຢ່າງດຽວຈະເຮັດໃຫ້ເກີດ ການແລກປ່ຽນ ຫຼື Trade-off ໃນ 3 ດ້ານ ຄື: ຕົ້ນທຶນ, ຄວາມໜ່ວງ (Latency) ແລະ ການປົກປ້ອງຂໍ້ມູນ. Cloud LLM ມີຄວາມແມ່ນຍຳສູງ ແຕ່ມີຕົ້ນທຶນດ້ານການສື່ສານ ແລະ ຄວາມໜ່ວງເຂົ້າມາຮ່ວມດ້ວຍ, ລວມທັງໃນບາງກໍລະນີຍັງມີບັນຫາເລື່ອງການ ສົ່ງຂໍ້ມູນຕໍ່ໃຫ້ ຂໍ້ມູນທີ່ເປັນຄວາມລັບອອກໄປພາຍນອກ. ໃນທາງກົງກັນຂ້າມ, On-device SLM ມີຄວາມໂດດເດັ່ນໃນດ້ານຄວາມເປັນສ່ວນຕົວ ແລະ ຄວາມໄວໃນການຕອບສະໜອງ ແຕ່ມັກຈະບໍ່ພຽງພໍສຳລັບການອະນຸມານ (Inference) ທີ່ຊັບຊ້ອນ.

ໃນບົດຄວາມນີ້, ພວກເຮົາຈະອະທິບາຍກົນລະຍຸດທີ່ເປັນຮູບປະທຳໃນການ Routing ວຽກງານໂດຍພິຈາລະນາຈາກມຸມມອງດ້ານຕົ້ນທຶນ, ຄວາມໜ່ວງ ແລະ ການປະຕິບັດຕາມກົດລະບຽບ (Compliance) ສຳລັບວິສະວະກອນ AI ແລະ System Architect. ເມື່ອອ່ານຈົບ, ທ່ານຈະສາມາດເຂົ້າໃຈວິທີການເລືອກໂຄງສ້າງແບບ Hybrid ທີ່ເໝາະສົມກັບລະບົບຂອງບໍລິສັດທ່ານ ແລະ ຂໍ້ຄວນລະວັງໃນການນຳໄປປະຕິບັດຕົວຈິງ.

ແນວຄິດການອອກແບບທີ່ນຳເອົາ Cloud LLM ແລະ On-device SLM ມາໃຊ້ຮ່ວມກັນ ເອີ້ນວ່າ ການອອກແບບ Hybrid LLM. ແນວຄິດຫຼັກຄືການບໍ່ມອບໝາຍທຸກວຽກໃຫ້ກັບໂມເດວພຽງຕົວດຽວ, ແຕ່ເປັນການແບ່ງວຽກໄປຍັງໂມເດວທີ່ເໝາະສົມທີ່ສຸດຕາມລັກສະນະຂອງການປະມວນຜົນ.

ການຕອບໂຈດທັງສາມດ້ານຄື: ຕົ້ນທຶນ, ຄວາມໜ່ວງ (Latency), ແລະ ການປົກປ້ອງຂໍ້ມູນ ໃຫ້ໄດ້ພ້ອມກັນນັ້ນ ເປັນເລື່ອງຍາກທັງໃນການໃຊ້ Cloud ພຽງຢ່າງດຽວ ຫຼື On-device ພຽງຢ່າງດຽວ. ຄວາມເປັນຈິງນີ້ເອງທີ່ເຮັດໃຫ້ໂຄງສ້າງແບບ Hybrid ກາຍເປັນທາງເລືອກທີ່ນຳມາໃຊ້ງານໄດ້ຈິງ.

ໃນພາກຕໍ່ໄປ, ພວກເຮົາຈະມາຈັດລຽງຄວາມແຕກຕ່າງຈາກການດຳເນີນງານແບບດ່ຽວ, ປັດໄຈໃນການຕັດສິນໃຈ Routing, ແລະ ຮູບແບບການຈັດຕັ້ງປະຕິບັດທີ່ເປັນຕົວແທນຕາມລຳດັບ.

"ການອອກແບບແບບປະສົມ" (Hybrid Design) ທີ່ລວມເອົາ Cloud LLM ແລະ On-device SLM (Small Language Model) ເຂົ້າດ້ວຍກັນນັ້ນ ມີຄວາມແຕກຕ່າງຢ່າງສິ້ນເຊີງຈາກການເລືອກແບບງ່າຍໆວ່າ "ຈະໃຊ້ໂຕໃດ". ຄວາມແຕກຕ່າງທີ່ໃຫຍ່ທີ່ສຸດເມື່ອທຽບກັບການໃຊ້ງານແບບດ່ຽວ ກໍຄືການມີ "ຊັ້ນການກຳນົດເສັ້ນທາງ" (Routing Layer) ເຊິ່ງເຮັດໜ້າທີ່ສົ່ງຂໍ້ມູນຕໍ່ໃຫ້ ບ່ອນປະມວນຜົນຢ່າງມີພະລັງຕາມລັກສະນະຂອງວຽກງານ.

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

ຄວາມແຕກຕ່າງຫຼັກໆສາມາດສະຫຼຸບໄດ້ດັ່ງນີ້:

• ຄວາມຫຼາກຫຼາຍຂອງບ່ອນປະມວນຜົນ: ວຽກງານທີ່ມີນ້ຳໜັກເບົາຈະຖືກຈັດການໃຫ້ສຳເລັດດ້ວຍ SLM ທີ່ຢູ່ເທິງອຸປະກອນ, ສ່ວນການວິເຄາະທີ່ຊັບຊ້ອນ ຫຼື ການສ້າງຂໍ້ຄວາມຍາວໆຈະຖືກມອບໝາຍໃຫ້ Cloud LLM.
• ການຄວບຄຸມການໄຫຼວຽນຂອງຂໍ້ມູນ: ຂໍ້ມູນທີ່ມີຄວາມລັບສູງສາມາດຈັດການໃຫ້ສຳເລັດໄດ້ພາຍໃນອຸປະກອນ (On-device), ເຮັດໃຫ້ສາມາດຮັບປະກັນເສັ້ນທາງທີ່ບໍ່ຕ້ອງສົ່ງຂໍ້ມູນອອກໄປຍັງເຄືອຂ່າຍພາຍນອກ.
• ການກະຈາຍໂຄງສ້າງຕົ້ນທຶນ: ສາມາດລວມສະເພາະຄຳຮ້ອງຂໍທີ່ມີການໃຊ້ Token ປະລິມານຫຼາຍໄປໄວ້ທີ່ Cloud, ເຮັດໃຫ້ສາມາດຄວບຄຸມຄ່າໃຊ້ຈ່າຍ API ໂດຍລວມໄດ້.

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

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

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

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

ໃນທາງກົງກັນຂ້າມ, ຖ້າເພິ່ງພາພຽງ On-device SLM ຢ່າງດຽວ ກໍຈະພົບກັບ ຂີດຈຳກັດດ້ານຄວາມສາມາດ.

• ການວິເຄາະທີ່ຊັບຊ້ອນ ແລະ ການສ້າງຂໍ້ຄວາມຍາວ: ຫຼາຍໂຄງສ້າງມີ Context Window ທີ່ແຄບ ເຮັດໃຫ້ຄວາມແມ່ນຍຳຫຼຸດລົງໃນວຽກງານທີ່ຕ້ອງໃຊ້ການວິເຄາະຫຼາຍຂັ້ນຕອນ.
• ການຮອງຮັບຫຼາຍພາສາ: ຄຸນນະພາບຂອງ Multilingual NLP ມັກຈະໄດ້ຮັບຜົນກະທົບຈາກຂະໜາດຂອງ Model ແລະ ປະລິມານຂໍ້ມູນທີ່ໃຊ້ຝຶກສອນ ເຊິ່ງ SLM ມັກຈະມີຂີດຈຳກັດໃນດ້ານນີ້.
• ຕົ້ນທຶນໃນການອັບເດດ Model: ການຮັກສາ Model ໃນຝັ່ງອຸປະກອນໃຫ້ທັນສະໄໝຢູ່ສະເໝີ ຕ້ອງແບກຮັບພາລະໃນການແຈກຢາຍ ແລະ ການຈັດການ.

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

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

ໃນພາກນີ້, ພວກເຮົາຈະມາຈັດລະບຽບ 3 ແກນຫຼັກ ຄື: ຕົ້ນທຶນ, Latency ແລະ Compliance (ລວມເຖິງການປົກປ້ອງຂໍ້ມູນ). ແຕ່ລະແກນບໍ່ໄດ້ແຍກອອກຈາກກັນຢ່າງເດັດຂາດ, ໃນການອອກແບບ Routing ຕົວຈິງ ຈຳເປັນຕ້ອງພິຈາລະນາຫຼາຍແກນໄປພ້ອມໆກັນ. ລາຍລະອຽດຂອງແຕ່ລະແກນຈະຖືກເຈາະເລິກໃນຫົວຂໍ້ H3 ຕໍ່ໄປ.

ການເພີ່ມປະສິດທິພາບດ້ານຕົ້ນທຶນແມ່ນໜຶ່ງໃນແຮງຈູງໃຈໂດຍກົງທີ່ສຸດຂອງການອອກແບບແບບ Hybrid. Cloud LLM ມີລາຄາຕໍ່ Token ສູງ, ເຊິ່ງມີແນວໂນ້ມທີ່ຕົ້ນທຶນລາຍເດືອນຈະເພີ່ມທະວີຂຶ້ນເລື້ອຍໆເມື່ອມີການຮ້ອງຂໍຈຳນວນຫຼາຍສະສົມ. ໃນທາງກົງກັນຂ້າມ, On-device SLM ມີຕົ້ນທຶນໃນການປະມວນຜົນເກືອບເປັນສູນ, ດັ່ງນັ້ນການມອບໝາຍວຽກທີ່ມີປະລິມານ Token ສູງ ຫຼື ວຽກທີ່ມີຄວາມຖີ່ໃນການເຮັດຊ້ຳສູງໃຫ້ກັບ SLM ຈຶ່ງສາມາດຫຼຸດຜ່ອນຄ່າໃຊ້ຈ່າຍໄດ້ຢ່າງຫຼວງຫຼາຍ.

ຕົວຊີ້ວັດພື້ນຖານໃນການແບ່ງວຽກ

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

ແນວທາງໃນການປະຕິບັດ

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

ຄວາມໜ່ວງ (Latency) ແລະ ການຮອງຮັບແບບອອບລາຍ ແມ່ນປັດໄຈທີ່ຊັດເຈນທີ່ສຸດໃນການຕັດສິນໃຈເລືອກລະຫວ່າງ Cloud LLM ແລະ On-device SLM. ໃນຂະນະທີ່ Cloud ມີຄວາມໜ່ວງເກີດຂຶ້ນຫຼາຍຮ້ອຍມິນລິວິນາທີຈາກການສົ່ງຂໍ້ມູນໄປ-ກັບຜ່ານເຄືອຂ່າຍ, SLM ສາມາດປະມວນຜົນແບບທັນທີໃນເຄື່ອງ (Local inference) ເຊິ່ງໃນບາງກໍລະນີຈະເຮັດໃຫ້ປະສົບການຂອງຜູ້ໃຊ້ແຕກຕ່າງກັນຢ່າງເຫັນໄດ້ຊັດ.

ມາດຕະຖານການຕັດສິນໃຈຕາມຄວາມຕ້ອງການດ້ານຄວາມໜ່ວງ (Latency)

• ສະຖານະການທີ່ຕ້ອງການການຕອບສະໜອງພາຍໃນ 200ms (ເຊັ່ນ: ຜູ້ຊ່ວຍສຽງ, ຄຳບັນຍາຍແບບ Real-time, NPC ໃນເກມ) → ໃຫ້ຄວາມສຳຄັນກັບ On-device SLM
• ສະຖານະການທີ່ຍອມຮັບການຕອບສະໜອງໄດ້ປະມານ 1-3 ວິນາທີ (ເຊັ່ນ: ການສະຫຼຸບເອກະສານ, ການແນະນຳ Code completion) → Cloud LLM ກໍເປັນທາງເລືອກໜຶ່ງ
• ການປະມວນຜົນແບບ Batch / ວຽກງານທີ່ບໍ່ແມ່ນແບບ Real-time (ເຊັ່ນ: ການສ້າງລາຍງານໃນຕອນກາງຄືນ, ການແປພາສາຈຳນວນຫຼາຍ) → ໃຫ້ຄວາມສຳຄັນກັບຄວາມຖືກຕ້ອງ ແລະ ຕົ້ນທຶນຫຼາຍກວ່າຄວາມໜ່ວງ, ຈຶ່ງເລືອກໃຊ້ Cloud LLM

ຄວາມຕ້ອງການໃນສະພາບແວດລ້ອມແບບອອບລາຍ ຫຼື ເຄືອຂ່າຍບໍ່ສະຖຽນ

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

ຂໍ້ຄວນລະວັງໃນການອອກແບບ

ສິ່ງສຳຄັນຄືການປະເມີນຄວາມຕ້ອງການດ້ານຄວາມໜ່ວງ ບໍ່ແມ່ນເບິ່ງທີ່ "ຄ່າສະເລ່ຍ" ແຕ່ໃຫ້ເບິ່ງທີ່ "ຄ່າ Outlier ລະດັບ P95-P99". ເນື່ອງຈາກ Cloud API ມີທ່າອ່ຽງທີ່ເວລາໃນການຕອບສະໜອງຈະເພີ່ມສູງຂຶ້ນໃນຊ່ວງທີ່ມີການໃຊ້ງານໜາແໜ້ນ, ດັ່ງນັ້ນໃນສະຖານະການທີ່ຕ້ອງການ SLA ເຂັ້ມງວດ ການນຳໃຊ້ On-device SLM ເປັນລະບົບສຳຮອງ (Fallback) ຈະຊ່ວຍໃຫ້ຄຸນນະພາບການບໍລິການມີຄວາມສະຖຽນຫຼາຍຂຶ້ນ.

ສຳລັບການແບ່ງສ່ວນໃນດ້ານການປະຕິບັດຕາມກົດລະບຽບ (Compliance) ຈະໄດ້ກ່າວເຖິງຢ່າງລະອຽດໃນພາກຕໍ່ໄປ.

ລະດັບຄວາມລັບຂອງຂໍ້ມູນ ແລະ ຂໍ້ກຳນົດດ້ານກົດລະບຽບ ມັກຈະເປັນປັດໄຈການຕັດສິນໃຈທີ່ມີຄວາມສຳຄັນສູງສຸດ ໃນການແບ່ງແຍກລະຫວ່າງ Cloud LLM ແລະ On-device SLM.

ປະເພດຂໍ້ມູນທີ່ຄວນຫຼີກລ່ຽງການສົ່ງຂຶ້ນ Cloud

• ຂໍ້ມູນທີ່ສາມາດລະບຸຕົວຕົນໄດ້ (ຊື່, ທີ່ຢູ່, ເລກປະຈຳຕົວ, ແລະ ອື່ນໆ)
• ເອກະສານລັບທີ່ກ່ຽວຂ້ອງກັບການແພດ, ການເງິນ ແລະ ກົດໝາຍ
• ຂໍ້ມູນພາຍໃນທີ່ຍັງບໍ່ທັນໄດ້ເປີດຕົວ ຫຼື Launch ແລະ ຄວາມລັບທາງການຄ້າ
• ຂໍ້ມູນທີ່ຢູ່ພາຍໃຕ້ການບັງຄັບໃຊ້ຂອງ EU AI Act, GDPR ແລະ ກົດໝາຍປົກປ້ອງຂໍ້ມູນສ່ວນບຸກຄົນພາຍໃນປະເທດ

ການສົ່ງຂໍ້ມູນເຫຼົ່ານີ້ໄປຍັງ Cloud LLM ຈະເຮັດໃຫ້ເກີດຄວາມສ່ຽງທີ່ຂໍ້ມູນຈະຜ່ານ ໂຄງສ້າງພື້ນຖານ ຫຼື Infrastructure ຂອງພາກສ່ວນທີສາມ. ໃນກໍລະນີທີ່ຕ້ອງການການຄວບຄຸມສະຖານທີ່ປະມວນຜົນຢ່າງຊັດເຈນເພື່ອຄວາມສອດຄ່ອງກັບກົດລະບຽບ (Compliance), ການປະມວນຜົນໃນເຄື່ອງ (Local processing) ດ້ວຍ On-device SLM ຈະເປັນຫຼັກການພື້ນຖານ.

ແນວທາງການແບ່ງແຍກຕາມກົດລະບຽບ ແລະ ນະໂຍບາຍ

ແນະນຳໃຫ້ໃຊ້ແນວຄິດ Privacy-by-Isolation ໂດຍອອກແບບໃຫ້ຂໍ້ມູນລັບບໍ່ອອກໄປນອກຂອບເຂດຂອງອຸປະກອນ.

ໃນທາງກົງກັນຂ້າມ, ເຖິງແມ່ນວ່າຈະໃຊ້ Cloud LLM, ການກວດສອບເງື່ອນໄຂການປະມວນຜົນຂໍ້ມູນໃນສັນຍາ (DPA) ແລະ ການຕັ້ງຄ່າ Opt-out ຈາກການນຳຂໍ້ມູນໄປຝຶກຝົນ Model ແມ່ນສິ່ງທີ່ຂາດບໍ່ໄດ້. ນອກຈາກການຕັ້ງຄ່າ Guardrails ແລ້ວ, ການນຳເອົາ ຂະບວນການ ຫຼື Pipeline ທີ່ກວດຫາ ແລະ ປິດບັງຂໍ້ມູນ PII ກ່ອນການສົ່ງຂໍ້ມູນ ຈະຊ່ວຍໃຫ້ສາມາດຂະຫຍາຍການນຳໃຊ້ Cloud ໄດ້ຢ່າງປອດໄພຍິ່ງຂຶ້ນ.

ຍຸດທະສາດການ Routing ມີຫຼາຍວິທີການຂຶ້ນຢູ່ກັບການແລກປ່ຽນ ຫຼື Trade-off ລະຫວ່າງຄວາມຊັບຊ້ອນຂອງການອອກແບບ ແລະ ຄ່າໃຊ້ຈ່າຍໃນການດຳເນີນງານ. ໂດຍແບ່ງອອກເປັນ 3 ຮູບແບບຫຼັກໆຄື: "Static Routing" ທີ່ກຳນົດ ແລະ ແບ່ງປະເພດວຽກໄວ້ລ່ວງໜ້າ, "Cascade" ທີ່ປັບປ່ຽນແບບໄດນາມິກໂດຍອີງຕາມລະດັບຄວາມເຊື່ອໝັ້ນຂອງຜົນລັພຈາກ Model, ແລະ "SLM Draft + Cloud Verification" ທີ່ SLM ສ້າງຮ່າງຂຶ້ນມາແລ້ວໃຫ້ Cloud LLM ເປັນຜູ້ກວດສອບ. ເນື່ອງຈາກແຕ່ລະຮູບແບບມີກໍລະນີການນຳໃຊ້ (Use case) ແລະ ຄວາມຍາກງ່າຍໃນການຈັດຕັ້ງປະຕິບັດທີ່ແຕກຕ່າງກັນ, ການເລືອກຮູບແບບທີ່ເໝາະສົມກັບຄວາມຕ້ອງການຂອງບໍລິສັດຈຶ່ງເປັນຈຸດເລີ່ມຕົ້ນຂອງການອອກແບບ.

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

ເຫດຜົນພື້ນຖານໃນການແບ່ງວຽກ

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

ໂດຍທົ່ວໄປແລ້ວ, ມັກຈະໃຊ້ການປະສົມປະສານລະຫວ່າງ 3 ແກນການຈັດປະເພດ ຄື: "ຈຳນວນ Input Token", "ID ປະເພດວຽກງານ" ແລະ "ບົດບາດຂອງຜູ້ໃຊ້". ຕົວຢ່າງເຊັ່ນ: ສາມາດຂຽນກົດເກນໄດ້ວ່າ ຖ້າ Input ມີ 256 Token ຫຼື ໜ້ອຍກວ່າ ແລະ ປະເພດແມ່ນ "FAQ" ໃຫ້ສົ່ງໄປ SLM, ສ່ວນອື່ນໆໃຫ້ສົ່ງໄປ Cloud LLM.

ຂໍ້ຄວນລະວັງໃນການຈັດຕັ້ງປະຕິບັດ

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

ຫຼັງຈາກເລີ່ມການດຳເນີນງານແລ້ວ, ຄວນວັດແທກ Latency ແລະ ຄະແນນຄຸນນະພາບຕາມແຕ່ລະເສັ້ນທາງຢ່າງຕໍ່ເນື່ອງດ້ວຍເຄື່ອງມື AI Observability ແລະ ຄວນທົບທວນກົດເກນການຈັດປະເພດເປັນໄລຍະ.

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

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

ພາບລວມຂອງກົນໄກ

1. SLM ດຳເນີນການອະນຸມານ ແລະ ຄຳນວນຄະແນນຄວາມໜ້າເຊື່ອຖືຈາກການກະຈາຍຄວາມໜ້າຈະເປັນຂອງ Token
2. ຖ້າຄະແນນເກີນເກນທີ່ກຳນົດໄວ້ (ຕົວຢ່າງ: 0.85) ໃຫ້ສົ່ງຄຳຕອບຂອງ SLM ກັບຄືນໄປທັນທີ
3. ໃນກໍລະນີທີ່ຕ່ຳກວ່າເກນເທົ່ານັ້ນ ຈຶ່ງຈະສົ່ງ Prompt ດຽວກັນໄປຫາ Cloud LLM
4. ສົ່ງຄຳຕອບຂອງ Cloud LLM ກັບຄືນເປັນຜົນລັດສຸດທ້າຍ

ຂໍ້ດີ ແລະ ຂໍ້ຄວນລະວັງ

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

ຈຸດສຳຄັນໃນການນຳໄປໃຊ້ງານ

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

ຮູບແບບ "SLM ຮ່າງ → Cloud LLM ກວດສອບ" ທີ່ຈະແນະນຳໃນພາກຕໍ່ໄປ ຖືເປັນໂຄງສ້າງທີ່ພັດທະນາຕໍ່ຍອດມາຈາກ Cascade ນີ້.

ເປັນຮູບແບບການເຮັດວຽກສອງຂັ້ນຕອນ ທີ່ SLM ໃນອຸປະກອນ (On-device) ເຮັດໜ້າທີ່ສ້າງຮ່າງເນື້ອຫາຢ່າງວ່ອງໄວ ແລະ Cloud LLM ເຮັດໜ້າທີ່ກວດສອບ ແລະ ເພີ່ມເຕີມເນື້ອຫານັ້ນ. ຮູບແບບນີ້ມີປະສິດທິພາບໂດຍສະເພາະໃນສະຖານະການທີ່ຕ້ອງການປັບໃຫ້ເໝາະສົມທັງດ້ານ Latency, ຕົ້ນທຶນ ແລະ ຄຸນນະພາບໄປພ້ອມໆກັນ.

ພາບລວມຂອງກົນໄກ

1. SLM ຮັບຂໍ້ມູນຈາກຜູ້ໃຊ້ ແລະ ສ້າງຮ່າງຕົ້ນສະບັບພາຍໃນເວລາບໍ່ເທົ່າໃດຮ້ອຍມິນລີວິນາທີ
2. ຕັດສິນໃຈວ່າຈຳເປັນຕ້ອງສົ່ງຂໍ້ມູນຕໍ່ໃຫ້ Cloud LLM ຫຼືບໍ່ ໂດຍອີງໃສ່ຄະແນນຄວາມໜ້າເຊື່ອຖື, ຈຳນວນຕົວອັກສອນ ຫຼື ຄວາມຊັບຊ້ອນຂອງຮ່າງຕົ້ນສະບັບ
3. ໃນກໍລະນີທີ່ຕັດສິນໃຈວ່າຈຳເປັນຕ້ອງສົ່ງຂໍ້ມູນຕໍ່ໃຫ້, ຈະສົ່ງຮ່າງຕົ້ນສະບັບນັ້ນໄປເປັນບໍລິບົດ (Context) ໃຫ້ Cloud LLM ເພື່ອກວດສອບ ແລະ ເພີ່ມເຕີມເນື້ອຫາ

ສະຖານະການທີ່ເໝາະສົມກັບຮູບແບບນີ້

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

ຜົນກະທົບດ້ານຕົ້ນທຶນ

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

ຂໍ້ຄວນລະວັງໃນການອອກແບບ

• ຖ້າຄຸນນະພາບຮ່າງຂອງ SLM ຕ່ຳເກີນໄປ ອັດຕາການສົ່ງຕໍ່ໄປຍັງ Cloud LLM ຈະສູງຂຶ້ນ ເຮັດໃຫ້ປະສິດທິພາບໃນການຫຼຸດຕົ້ນທຶນຫຼຸດລົງ
• ການນຳຮ່າງຕົ້ນສະບັບໄປໃສ່ໃນ Prompt ໂດຍກົງຈະເຮັດໃຫ້ສິ້ນເປືອງ Context Window ດັ່ງນັ້ນ ການເຮັດ Pre-processing ເພື່ອສະຫຼຸບ ຫຼື ບີບອັດຂໍ້ມູນຈຶ່ງມີປະໂຫຍດ
• ຄວນອອກແບບໂດຍການຝັງ Logic ການກວດຈັບ Hallucination ໄວ້ເປັນ Guardrail ເພື່ອປ້ອງກັນບໍ່ໃຫ້ຂໍ້ມູນທີ່ຜິດພາດໄຫຼໄປສູ່ຂະບວນການຖັດໄປ

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

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

Static Routing ແມ່ນວິທີການຈັດປະເພດປະເພດຂອງວຽກງານໄວ້ລ່ວງໜ້າດ້ວຍກົດເກນ ແລະ ກຳນົດປາຍທາງການປະມວນຜົນ (SLM ຫຼື Cloud LLM) ໃຫ້ຄົງທີ່. ເນື່ອງຈາກເຫດຜົນໃນການແຍກສາຂາມີຄວາມລຽບງ່າຍ, ຈຸດແຂງທີ່ໃຫຍ່ທີ່ສຸດຂອງມັນຄືຕົ້ນທຶນໃນການຈັດຕັ້ງປະຕິບັດທີ່ຕໍ່າ ແລະ ຄວາມສາມາດໃນການຄາດຄະເນການເຮັດວຽກທີ່ສູງ.

ໂຄງສ້າງພື້ນຖານໃນການຈັດຕັ້ງປະຕິບັດ

• ກຳນົດ Task Label ໃນເວລາປ້ອນຂໍ້ມູນ (ຕົວຢ່າງ: task_type: summarize / translate / reason)
• ຈັດການຕາຕະລາງການຈັບຄູ່ລະຫວ່າງ Label ແລະ Model ຜ່ານທາງ Code ຫຼື ໄຟລ໌ຕັ້ງຄ່າ
• Router ຈະເຮັດໜ້າທີ່ພຽງແຕ່ແຍກເງື່ອນໄຂເທົ່ານັ້ນ. ເນື່ອງຈາກບໍ່ໄດ້ໃຊ້ LLM ຈຶ່ງເກືອບບໍ່ມີ Latency ເພີ່ມເຕີມ

ສະຖານະການທີ່ເໝາະສົມ

Static Routing ຈະສະແດງປະສິດທິພາບໄດ້ດີທີ່ສຸດໃນກໍລະນີທີ່ປະເພດຂອງວຽກງານຖືກກຳນົດໄວ້ລ່ວງໜ້າໃນ Workflow ການເຮັດວຽກ.

• ແອັບພລິເຄຊັນດ້ານການຜະລິດ ແລະ ພາກສະໜາມ: ການວິເຄາະເບື້ອງຕົ້ນຂອງການແຈ້ງເຕືອນອຸປະກອນຈະຖືກປະມວນຜົນແບບ Offline ດ້ວຍ SLM ແລະ ສົ່ງຂໍ້ມູນຕໍ່ໃຫ້ Cloud ສະເພາະການຍົກລະດັບການຕັດສິນຄວາມຜິດປົກກະຕິເທົ່ານັ້ນ
• ການບໍລິການລູກຄ້າ (Customer Support): ມອບໝາຍການຕອບ FAQ ໃຫ້ SLM ແລະ Routing ສະເພາະການຈັດການກັບຄຳຮ້ອງຮຽນ ຫຼື ການສອບຖາມທີ່ຊັບຊ້ອນໄປຍັງ Cloud LLM
• ອຸດສາຫະກຳທີ່ມີຂໍ້ກຳນົດດ້ານການປະຕິບັດຕາມກົດລະບຽບ (Compliance) ທີ່ຊັດເຈນ: ການປ້ອນຂໍ້ມູນທີ່ມີຂໍ້ມູນສ່ວນບຸກຄົນຈະຖືກກຳນົດໄວ້ທີ່ On-device ສະເໝີ ເພື່ອປ້ອງກັນການສົ່ງຂໍ້ມູນອອກໄປພາຍນອກຕາມໂຄງສ້າງພື້ນຖານ ຫຼື Infrastructure

ຂໍ້ຄວນລະວັງ

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

Dynamic Routing ແມ່ນກົນໄກການປະເມີນຄະແນນຄວາມເຊື່ອໝັ້ນຂອງ SLM ແບບ Real-time ແລະຈະສົ່ງຂໍ້ມູນຕໍ່ໃຫ້ Cloud LLM ກໍຕໍ່ເມື່ອຄະແນນບໍ່ຜ່ານເກນທີ່ກຳນົດໄວ້ເທົ່ານັ້ນ. ຈຸດສຳຄັນ ຫຼື ແກນຫຼັກ ຂອງການນຳໄປໃຊ້ງານມີ 2 ຢ່າງຄື: "ເຫດຜົນໃນການຕັດສິນຄວາມເຊື່ອໝັ້ນ" ແລະ "ຕົວກະຕຸ້ນການສຳຮອງ (Fallback trigger)".

ຂັ້ນຕອນພື້ນຖານໃນການນຳໄປໃຊ້ງານ

1. SLM ດຳເນີນການອະນຸມານ (Inference) ແລະ ຄຳນວນຄະແນນຄວາມເຊື່ອໝັ້ນຈາກຜົນລວມຂອງ Softmax ຫຼື Log probability.
2. ໃນກໍລະນີທີ່ຄະແນນຕ່ຳກວ່າເກນທີ່ຕັ້ງໄວ້ (ຕົວຢ່າງ: 0.85), ລະບົບຈະສົ່ງ Prompt ດຽວກັນນັ້ນໄປໃຫ້ Cloud LLM.
3. ເກັບຂໍ້ມູນການຕອບກັບຂອງ Cloud LLM ໄວ້ໃນ Cache ເພື່ອຫຼຸດຜ່ອນການສົ່ງຂໍ້ມູນຕໍ່ໃຫ້ຊ້ຳໃນຄຳຖາມທີ່ມີລັກສະນະຄ້າຍຄືກັນ.

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

ຕົວຊີ້ວັດຫຼັກທີ່ຄວນຕິດຕາມ

• ອັດຕາການສົ່ງຂໍ້ມູນຕໍ່ (Escalation rate): ສັດສ່ວນທີ່ຖືກສົ່ງໄປຍັງ Cloud. ການເພີ່ມທະວີຂຶ້ນເລື້ອຍໆ ອາດເປັນສັນຍານຂອງການເສື່ອມສະພາບຂອງ SLM ຫຼື Data drift.
• ການກະຈາຍຂອງ Latency: ແຍກການວັດແທກລະຫວ່າງເວລາການປະມວນຜົນຂອງ SLM ພຽງຢ່າງດຽວ ແລະ ເວລາການຕອບກັບຫຼັງຈາກສົ່ງຂໍ້ມູນຕໍ່ໄປແລ້ວ.
• ການແລກປ່ຽນ ຫຼື Trade-off ລະຫວ່າງຕົ້ນທຶນກັບຄວາມແມ່ນຍຳ: ໃຫ້ກວດສອບ AI ROI ເປັນລາຍອາທິດ ໂດຍການນຳອັດຕາການສົ່ງຂໍ້ມູນຕໍ່ມາຄູນກັບປະລິມານການໃຊ້ Token.
• ອັດຕາການກວດພົບ Hallucination: ໃຫ້ລວມເອົາການກວດສອບ Grounding ເພື່ອປຽບທຽບຄຸນນະພາບຜົນລັດລະຫວ່າງ SLM ແລະ Cloud LLM.

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

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

ເມື່ອເລີ່ມນຳໃຊ້ການອອກແບບແບບ Hybrid, ຖ້າບໍ່ໄດ້ກວດສອບຄວາມສອດຄ່ອງກັບ Guardrails ແລະ ລະບົບການບໍລິຫານຈັດການ (Governance) ທີ່ມີຢູ່ແລ້ວລ່ວງໜ້າ, ບັນຫາດ້ານ Compliance ທີ່ຮ້າຍແຮງອາດຈະເກີດຂຶ້ນໄດ້ຫຼັງຈາກການນຳໃຊ້ງານ. ເນື່ອງຈາກຂອບເຂດຂອງນະໂຍບາຍທີ່ຕ້ອງນຳໃຊ້ລະຫວ່າງ Cloud LLM ແລະ On-device SLM ມີຄວາມແຕກຕ່າງກັນ, ກົນໄກການບໍລິຫານຈັດການແບບສູນກາງ (Centralized management) ຈຶ່ງເປັນສິ່ງທີ່ຂາດບໍ່ໄດ້.

ຈຸດສຳຄັນ ຫຼື ແກນຫຼັກ ທີ່ຄວນກວດສອບ

• ຄວາມສອດຄ່ອງກັບນະໂຍບາຍການຈັດປະເພດຂໍ້ມູນ: ຕ້ອງມີການຂຽນກົດລະບຽບການ Routing ໃຫ້ຊັດເຈນ ເພື່ອຮອງຮັບລະດັບຄວາມລັບທີ່ກຳນົດໄວ້ພາຍໃນບໍລິສັດ (ຕົວຢ່າງ: ລັບສຸດຍອດ, ລັບສະເພາະພາຍໃນ, ເປີດເຜີຍຕໍ່ສາທາລະນະ). ຕ້ອງມີການຕັ້ງຄ່າ Router ເພື່ອໃຫ້ແນ່ໃຈວ່າຂໍ້ມູນທີ່ມີລະດັບຄວາມລັບສູງຈະຖືກສົ່ງຂໍ້ມູນຕໍ່ໃຫ້ On-device SLM ເທົ່ານັ້ນ.
• ການຮອງຮັບ EU AI Act ແລະ ແນວທາງປະຕິບັດຂອງ NIST (NIST AI RMF): ໃນກໍລະນີທີ່ວຽກງານຖືກຕັດສິນວ່າເປັນວຽກທີ່ມີຄວາມສ່ຽງສູງ, ອາດຈະມີຄວາມຈຳເປັນຕ້ອງເກັບຮັກສາ Audit log ເຖິງແມ່ນວ່າຈະຜ່ານ Cloud LLM ກໍຕາມ. ຕ້ອງອອກແບບສະຖານທີ່ຈັດເກັບ Log ແລະ ສິດທິໃນການເຂົ້າເຖິງໄວ້ລ່ວງໜ້າ.
• ສາຍການລາຍງານຕໍ່ຄະນະກຳມະການ AI Governance: ການປ່ຽນແປງເກນການຕັດສິນໃຈໃນການ Routing ຕ້ອງຖືກລວມເຂົ້າໃນຂະບວນການອະນຸມັດຂອງຄະນະກຳມະການ Governance. ຖ້າລະເລີຍການບໍລິຫານຈັດການການປ່ຽນແປງ (Change management), ອາດຈະເກີດຄວາມສ່ຽງທີ່ນຳໄປສູ່ສະພາວະທີ່ຄ້າຍຄືກັບ Shadow AI.
• ການນຳໃຊ້ Guardrails ແບບຊ້ຳຊ້ອນ: ການຕັ້ງ Prompt firewall ຫຼື Grounding check ໄວ້ທັງໃນ SLM ແລະ LLM ຈະເຮັດໃຫ້ຕົ້ນທຶນໃນການປະມວນຜົນເພີ່ມທະວີຂຶ້ນເລື້ອຍໆ. ການອອກແບບໂດຍວາງຊັ້ນ Guardrails ສ່ວນກາງໄວ້ກ່ອນໜ້າ Router ເພື່ອຫຼຸດຜ່ອນຄວາມຊ້ຳຊ້ອນຖືວ່າເປັນວິທີທີ່ມີປະສິດທິຜົນ.

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

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

ວິທີການຈັດຕັ້ງປະຕິບັດ Router ໂດຍພື້ນຖານແລ້ວຈະແບ່ງອອກເປັນ 2 ປະເພດຄື: "Rule-based" ແລະ "LLM-based". ເນື່ອງຈາກແຕ່ລະປະເພດມີສະຖານະການທີ່ເໝາະສົມກັບມັນ, ຈຶ່ງບໍ່ຈຳເປັນຕ້ອງຕັດສິນໃຈເລືອກພຽງຢ່າງໃດຢ່າງໜຶ່ງ.

Rule-based Router

• ແບ່ງການເຮັດວຽກໂດຍໃຊ້ເງື່ອນໄຂຕ່າງໆ ເຊັ່ນ: ຈຳນວນ Token, Endpoint, ຫຼື Keyword.
• ການຈັດຕັ້ງປະຕິບັດມີຄວາມເບົາບາງ ແລະ Latency ຂອງຕົວ Router ເອງເກືອບຈະເປັນສູນ.
• ເງື່ອນໄຂຕ່າງໆຖືກກຳນົດໄວ້ຕາຍຕົວ, ຈຶ່ງຈຳເປັນຕ້ອງມີການອັບເດດດ້ວຍຕົນເອງເພື່ອຮອງຮັບປະເພດວຽກໃໝ່ໆ.

LLM-based Router

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

ໃນການອອກແບບຕົວຈິງ, ການໃຊ້ "ໂຄງສ້າງສອງຂັ້ນ" ໂດຍເລີ່ມຈາກການແບ່ງວຽກແບບຫຍາບໆດ້ວຍ Rule-based ແລະ ສົ່ງຂໍ້ມູນຕໍ່ໃຫ້ SLM ສະເພາະກໍລະນີທີ່ຕັດສິນໃຈໄດ້ຍາກເທົ່ານັ້ນ ຖືວ່າມີປະສິດທິຜົນ. ຕົວຢ່າງເຊັ່ນ: ຖ້າເງື່ອນໄຂ "ຈຳນວນ Token ຕ່ຳກວ່າທີ່ກຳນົດ ແລະ ບໍ່ມີທຸງຄວາມລັບ" ເປັນຈິງ, ໃຫ້ສົ່ງໄປຍັງ On-device SLM ທັນທີ, ສ່ວນກໍລະນີອື່ນໆໃຫ້ຕົວຈັດປະເພດແບບ SLM-based ປະເມີນເຈດຕະນາກ່ອນຈະສົ່ງຂໍ້ມູນຕໍ່ໃຫ້ Cloud LLM.

ສະຫຼຸບມາດຖານໃນການເລືອກມີດັ່ງນີ້:

ນອກຈາກນີ້, ມັນຍັງມີຄວາມສຳຄັນທີ່ຈະຕ້ອງລວມເອົາຕົວ Router ເຂົ້າເປັນສ່ວນໜຶ່ງຂອງການຕິດຕາມກວດກາ AI Observability. ເນື່ອງຈາກການຈັດປະເພດຜິດພາດທີ່ສະສົມໄວ້ອາດສົ່ງຜົນໃຫ້ຕົ້ນທຶນເພີ່ມຂຶ້ນ ແລະ ຄຸນນະພາບຫຼຸດລົງ, ດັ່ງນັ້ນຄວນລວມເອົາການກວດສອບ Routing log ເປັນປະຈຳເຂົ້າໃນຂະບວນການດຳເນີນງານ (Operation flow).

ການອອກແບບແບບ Hybrid ລະຫວ່າງ Cloud LLM ແລະ On-device SLM ແມ່ນວິທີການທີ່ເປັນຈິງເພື່ອເພີ່ມປະສິດທິພາບໃນສາມດ້ານພ້ອມກັນ ຄື: ຕົ້ນທຶນ, ຄວາມໜ່ວງ (Latency) ແລະ ການປະຕິບັດຕາມກົດລະບຽບ (Compliance). ການເລືອກໃຊ້ພຽງຢ່າງໃດຢ່າງໜຶ່ງຈະເຮັດໃຫ້ເກີດ ການແລກປ່ຽນ ຫຼື Trade-off ໃນດ້ານໃດດ້ານໜຶ່ງສະເໝີ.

ຖ້າຫາກທົບທວນຄືນກ່ຽວກັບຍຸດທະສາດການ Routing ທີ່ໄດ້ອະທິບາຍໃນບົດຄວາມນີ້, ສາມາດແບ່ງທາງເລືອກອອກເປັນ 3 ປະເພດໃຫຍ່ໆດັ່ງນີ້:

• Static Routing: ກຳນົດການໃຊ້ງານ Cloud/On-device ໄວ້ລ່ວງໜ້າຕາມປະເພດຂອງວຽກ. ມີຄວາມງ່າຍໃນການດຳເນີນງານ ແລະ ມີຕົ້ນທຶນໃນການນຳໃຊ້ຕ່ຳ.
• Dynamic Routing (Cascade): ພິຈາລະນາຈາກຄະແນນຄວາມໜ້າເຊື່ອຖືຂອງ SLM ເພື່ອຍົກລະດັບ (Escalation) ໄປຫາ Cloud LLM. ສາມາດປັບສົມດຸນລະຫວ່າງຄວາມຖືກຕ້ອງ ແລະ ຕົ້ນທຶນໄດ້ໂດຍອັດຕະໂນມັດ.
• SLM Draft → Cloud LLM Verification: ເໝາະສຳລັບວຽກງານການສ້າງເນື້ອຫາ (Generation Task) ທີ່ຕ້ອງການທັງຄວາມໄວ ແລະ ການຮັບປະກັນຄຸນນະພາບ.

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

ຕໍ່ມາ, ໃຫ້ລວມເອົາ Guardrails ແລະ ນະໂຍບາຍ AI Governance ໄວ້ໃນສ່ວນຕົ້ນນ້ຳ (Upstream) ຂອງ Router. ເນື່ອງຈາກການຕັດສິນໃຈ Routing ເອງກໍອາດກາຍເປັນຈຸດສ່ຽງໃໝ່, ສະນັ້ນການມີລະບົບ AI Observability ເພື່ອຕິດຕາມກວດສອບບັນທຶກການຕັດສິນໃຈ ແບບ Real-time ຈຶ່ງເປັນສິ່ງທີ່ຂາດບໍ່ໄດ້.

ໂຄງສ້າງແບບ Hybrid ບໍ່ແມ່ນສິ່ງທີ່ "ສ້າງສຳເລັດແລ້ວຈົບໄປ". ການອອກແບບວົງຈອນການດຳເນີນງານເພື່ອທົບທວນກົດລະບຽບການ Routing ຢ່າງຕໍ່ເນື່ອງ ໃຫ້ສອດຄ່ອງກັບການອັບເດດ Model ແລະ ການປ່ຽນແປງຂອງຄວາມຕ້ອງການທາງທຸລະກິດ ຕັ້ງແຕ່ຂັ້ນຕອນການອອກແບບ ຈະຊ່ວຍໃຫ້ການເພີ່ມ ROI ຂອງ AI ເພີ່ມທະວີຂຶ້ນເລື້ອຍໆ ໃນໄລຍະຍາວ.