LLM Model Routing ແມ່ນວິທີການທາງສະຖາປັດຕະຍະກຳທີ່ໃຊ້ໃນການຈັດສັນຮູບແບບ (Model) ທີ່ຫຼາກຫຼາຍ ເຊັ່ນ: GPT, Claude, Gemini ໃຫ້ເຮັດວຽກຢ່າງຄ່ອງຕົວຕາມຄວາມຊັບຊ້ອນຂອງວຽກງານ ແລະ ຄວາມຕ້ອງການດ້ານຕົ້ນທຶນ.

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

ໃນບົດຄວາມນີ້, ພວກເຮົາຈະອະທິບາຍເນື້ອໃນຕໍ່ໄປນີ້ຕາມລຳດັບ.

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

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

ຫຼາຍຄົນມັກຄິດວ່າ "ພຽງແຕ່ໃຊ້ GPT ກັບທຸກຢ່າງກໍພໍແລ້ວ" ແຕ່ໃນຄວາມເປັນຈິງແລ້ວ, ແບບຈຳລອງ (Model) ທີ່ເໝາະສົມຈະແຕກຕ່າງກັນໄປຕາມແຕ່ລະໜ້າວຽກ, ດັ່ງນັ້ນການເພິ່ງພາແບບຈຳລອງດຽວຈຶ່ງສ້າງຄວາມສ່ຽງທັງໃນດ້ານຕົ້ນທຶນການດຳເນີນງານ ແລະ ຄຸນນະພາບ.

ການໃຊ້ງານແບບ Single Model ມັກຈະເຮັດໃຫ້ເກີດ 3 ບັນຫາຫຼັກດັ່ງນີ້:

• ຄວາມບໍ່ມີປະສິດທິພາບດ້ານຕົ້ນທຶນ: ການເອີ້ນໃຊ້ແບບຈຳລອງທີ່ມີປະສິດທິພາບສູງກັບວຽກງ່າຍໆ ເຊັ່ນ: ການຕອບ FAQ ຫຼື ວຽກງານການຈັດໝວດໝູ່ ຈະເຮັດໃຫ້ຕົ້ນທຶນ API ທີ່ມີລາຄາຕໍ່ Token ສູງສະສົມເພີ່ມຂຶ້ນ. ໃນກໍລະນີສຶກສາຂອງ AWS, ມີການລາຍງານວ່າການປະມວນຜົນ Token ຈຳນວນເທົ່າກັນລະຫວ່າງວຽກງານ History ແລະ Math ສົ່ງຜົນໃຫ້ຕົ້ນທຶນການສ້າງຄຳຕອບແຕກຕ່າງກັນຢ່າງຫຼວງຫຼາຍ, ເຊິ່ງສະແດງໃຫ້ເຫັນວ່າການ Routing ໂດຍບໍ່ສົນໃຈຄວາມຍາກງ່າຍຂອງວຽກງານນັ້ນສົ່ງຜົນໃຫ້ຕົ້ນທຶນເພີ່ມທະວີຂຶ້ນເລື້ອຍໆ.
• ຄວາມຊັກຊ້າຂອງ Latency: ແບບຈຳລອງຂະໜາດໃຫຍ່ໃຊ້ເວລາໃນການອະນຸມານ (Inference) ດົນ, ເຮັດໃຫ້ຄວາມໄວໃນການຕອບສະໜອງຊ້າລົງເຖິງແມ່ນວ່າຈະເປັນການຮ້ອງຂໍແບບງ່າຍໆກໍຕາມ. ເຊິ່ງເປັນບັນຫາຮ້າຍແຮງສຳລັບການນຳໃຊ້ແບບ Real-time ທີ່ສົ່ງຜົນໂດຍກົງຕໍ່ປະສົບການຂອງຜູ້ໃຊ້.
• ຄຸນນະພາບທີ່ບໍ່ພັດທະນາ: ໃນທາງກົງກັນຂ້າມ, ຖ້າພະຍາຍາມຈັດການວຽກງານການອະນຸມານທີ່ຊັບຊ້ອນດ້ວຍແບບຈຳລອງຂະໜາດນ້ອຍພຽງຢ່າງດຽວ, ຄວາມຖືກຕ້ອງຂອງຄຳຕອບກໍຈະຫຼຸດລົງ. ນີ້ຄືບັນຫາທາງໂຄງສ້າງທີ່ວ່າ ຫາກປັບແຕ່ງໃຫ້ເໝາະສົມກັບແບບຈຳລອງໜຶ່ງ ກໍຈະບໍ່ສາມາດຕອບສະໜອງຄວາມຕ້ອງການຂອງອີກແບບຈຳລອງໜຶ່ງໄດ້, ເຊິ່ງເປັນ ການແລກປ່ຽນ ຫຼື Trade-off ຢ່າງໜຶ່ງ.

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

ໃນບົດວິໄຈຂອງ HyDRA, ໄດ້ມີການລາຍງານຜົນວ່າຄ່າກາງຂອງ Latency ໃນການອະນຸມານຜ່ານ CPU ຂອງຕົວຄາດການ (Predictor) ຢູ່ທີ່ 86 ms ໃນຂະນະທີ່ສາມາດຫຼຸດຕົ້ນທຶນໄດ້ເຖິງ 54.1% ພາຍໃຕ້ເງື່ອນໄຂ iso-quality.

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

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

Model Routing ເຮັດໜ້າທີ່ເປັນວິທີການໃນການປິດຊ່ອງຫວ່າງນີ້. ໂດຍສະເພາະ, ມັນສາມາດແກ້ໄຂ ການແລກປ່ຽນ ຫຼື Trade-off ໄດ້ 3 ປະການດັ່ງນີ້:

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

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

ໃນ Intelligent Prompt Routing ຂອງ Amazon Bedrock, ໄດ້ມີການລາຍງານວ່າວິທີການນີ້ສາມາດຫຼຸດຕົ້ນທຶນໄດ້ສູງສຸດເຖິງ 30%. ນອກຈາກນີ້, ໃນການຄົ້ນຄວ້າຂອງ HyDRA ຍັງໄດ້ສະແດງໃຫ້ເຫັນຜົນລັບທີ່ສາມາດຫຼຸດຕົ້ນທຶນໄດ້ເຖິງ 54.1% ໂດຍຍັງຮັກສາຄຸນນະພາບໄວ້ໄດ້, ແລະ ໃນການຕັ້ງຄ່າແບບຮຸກຮານ (Aggressive setting) ສາມາດຫຼຸດໄດ້ເຖິງ 72.5% (ໂດຍມີຄວາມແຕກຕ່າງຂອງຄຸນນະພາບພຽງ 3.2 ຈຸດ).

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

ຮູບແບບ Routing ສາມາດແບ່ງອອກເປັນ 3 ປະເພດໃຫຍ່ໆ ດັ່ງນີ້:

• Rule-based Routing: ແບ່ງຕາມເງື່ອນໄຂຄົງທີ່ ເຊັ່ນ: ຄວາມຍາວຂອງ Query, ຄຳສຳຄັນ (Keywords), ຫຼື ປະເພດຂອງ Task. ການປະຕິບັດງານມີຄວາມລຽບງ່າຍທີ່ສຸດ ແລະ ມີ Latency overhead ເກືອບເປັນສູນ. ແນວໃດກໍຕາມ, ຖ້າເງື່ອນໄຂການແບ່ງແຍກມີຄວາມຊັບຊ້ອນຫຼາຍຂຶ້ນ ກໍມີທ່າອ່ຽງທີ່ຄ່າໃຊ້ຈ່າຍໃນການບຳລຸງຮັກສາຈະເພີ່ມທະວີຂຶ້ນເລື້ອຍໆ.
• Dynamic Routing ໂດຍໃຊ້ຮູບແບບການຈັດໝວດໝູ່ (Classification Model): ຕົວຈັດໝວດໝູ່ທີ່ມີນ້ຳໜັກເບົາຈະຄາດຄະເນຄວາມຍາກງ່າຍ ຫຼື ເຈດຕະນາຂອງ Query ແລ້ວສົ່ງຂໍ້ມູນຕໍ່ໃຫ້ Model ທີ່ເໝາະສົມ. ໃນງານວິໄຈຢ່າງ HyDRA ໄດ້ສະແດງໃຫ້ເຫັນວ່າ ຄ່າກາງ (Median) ຂອງ CPU inference latency ຂອງຕົວຄາດຄະເນຖືກຄວບຄຸມໄວ້ທີ່ 86 ms, ເຊິ່ງສາມາດຫຼຸດຜ່ອນຜົນກະທົບຕໍ່ Throughput ໃຫ້ເຫຼືອໜ້ອຍທີ່ສຸດໄດ້.
• Cascaded Routing: ເລີ່ມຕົ້ນດ້ວຍການສ້າງຄຳຕອບໂດຍໃຊ້ Model ທີ່ມີນ້ຳໜັກເບົາ ແລະ ມີຕົ້ນທຶນຕ່ຳ, ແລະ ຈະ Escalation ໄປຍັງ Model ທີ່ມີປະສິດທິພາບສູງກໍຕໍ່ເມື່ອຄະແນນຄວາມເຊື່ອໝັ້ນ (Confidence score) ຕ່ຳກວ່າເກນທີ່ກຳນົດໄວ້ເທົ່ານັ້ນ. ໃນງານວິໄຈຂອງ TRIM ໄດ້ລາຍງານວ່າ ຍຸດທະສາດນີ້ສາມາດຫຼຸດປະລິມານການໃຊ້ Token ຂອງ Model ທີ່ມີຕົ້ນທຶນສູງລົງໄດ້ຢ່າງຫຼວງຫຼາຍ.

ຮູບແບບເຫຼົ່ານີ້ບໍ່ໄດ້ແຍກອອກຈາກກັນຢ່າງເດັດຂາດ ແຕ່ມັກຈະຖືກນຳມາໃຊ້ຮ່ວມກັນໃນຫຼາຍກໍລະນີ. ຕົວຢ່າງເຊັ່ນ: ການວາງໂຄງສ້າງສອງຂັ້ນຕອນຄື "ໃຊ້ Rule-based ໃນການຈັດໝວດໝູ່ Task ໂດຍລວມ, ແລະ ມອບໝາຍສະເພາະ Query ທີ່ມີຄວາມກຳກວມໃຫ້ກັບ Classification Model" ເປັນໂຄງສ້າງທີ່ງ່າຍຕໍ່ການສ້າງຄວາມສົມດຸນລະຫວ່າງຄວາມແມ່ນຍຳ ແລະ Overhead.

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

ສະຫຼຸບ: ຄວາມສຳເລັດ ຫຼື ຄວາມລົ້ມເຫຼວຂອງການອອກແບບ Routing ແມ່ນຖືກກຳນົດໄວ້ເຖິງ 80% ຕັ້ງແຕ່ຂັ້ນຕອນການກະກຽມກ່ອນການລົງມືປະຕິບັດ.

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

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

ສິ່ງທີ່ຄວນເຮັດເປັນອັນດັບທຳອິດຄື ການແຈກແຈງ Use case ຂອງບໍລິສັດ ແລະ ຈຳແນກປະເພດຂອງ Query. ເກນການຈຳແນກທີ່ສຳຄັນມີດັ່ງນີ້:

• ຄວາມຊັບຊ້ອນ: ການຕອບ FAQ ແບບງ່າຍໆ / ຄຳຖາມທີ່ຕ້ອງການການອະນຸມານຫຼາຍຂັ້ນຕອນ / ການສ້າງ Code ຫຼື ການປະມວນຜົນທາງຄະນິດສາດ
• Domain: ຄວາມຮູ້ທົ່ວໄປ / ຂະແໜງການສະເພາະທາງ (ກົດໝາຍ, ການແພດ, ການເງິນ) / ຂໍ້ມູນສະເພາະຂອງບໍລິສັດ
• ຮູບແບບຜົນລັດ: ຄຳຕອບສັ້ນ / ການສະຫຼຸບຄວາມຍາວ / ຂໍ້ມູນທີ່ມີໂຄງສ້າງ (JSON, ຕາຕະລາງ)
• ຄວາມຕ້ອງການດ້ານ Latency: ຕ້ອງການການຕອບສະໜອງແບບ Real-time / ສາມາດຍອມຮັບການປະມວນຜົນແບບ Batch ໄດ້

ຈາກນັ້ນ, ໃຫ້ທົດລອງ Mapping ວ່າ "Model ໃດເໝາະສົມ" ສຳລັບແຕ່ລະປະເພດ. ຕົວຢ່າງເຊັ່ນ: ການມອບໝາຍ Model ຂະໜາດນ້ອຍໃຫ້ກັບ FAQ ແບບງ່າຍໆ ແລະ ໃຊ້ Model ປະສິດທິພາບສູງສຳລັບ Query ທີ່ຕ້ອງການການອະນຸມານຫຼາຍຂັ້ນຕອນ.

ສິ່ງທີ່ສຳຄັນໃນການເຮັດ Mapping ນີ້ຄື ການເຂົ້າໃຈການກະຈາຍຕົວຂອງ Query ໂດຍໃຊ້ຂໍ້ມູນ Traffic ຕົວຈິງ. ຖ້າອັດຕາສ່ວນຂອງ Query ທີ່ຊັບຊ້ອນໃນການສອບຖາມທັງໝົດຕ່ຳກວ່າທີ່ຄາດໄວ້, ໂອກາດໃນການຫຼຸດຕົ້ນທຶນກໍຈະມີຫຼາຍຂຶ້ນ.

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

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

ມຸມມອງທີ່ຄວນກວດສອບໃນເວລາຄັດເລືອກ

• ຄວາມເໝາະສົມກັບວຽກ (Task Suitability): ຕົວແບບທີ່ມີຄວາມຊຳນານຈະແຕກຕ່າງກັນໄປຕາມປະເພດຂອງວຽກ ເຊັ່ນ: ການສະຫຼຸບຄວາມຍາວ, ການສ້າງ Code, ຫຼື ການໃຫ້ເຫດຜົນທາງຄະນິດສາດ.
• ລະດັບຕົ້ນທຶນ (Cost Range): ປຽບທຽບລາຄາຕໍ່ Token ຂອງ Input ແລະ Output ລະຫວ່າງຕົວແບບທີ່ມີນ້ຳໜັກເບົາ ແລະ ຕົວແບບທີ່ມີປະສິດທິພາບສູງ ເພື່ອໃຫ້ເຂົ້າໃຈສ່ວນຕ່າງຂອງຕົ້ນທຶນເປັນຕົວເລກ.
• ຄວາມຍາວຂອງບໍລິບົດ (Context Length): ໃນກໍລະນີທີ່ຈັດການກັບເອກະສານຍາວໆ, ຄວາມຍາວຂອງບໍລິບົດສູງສຸດຈະກາຍເປັນເງື່ອນໄຂເບື້ອງຕົ້ນໃນການຄັດເລືອກຜູ້ສະໝັກ.
• ຄຸນລັກສະນະດ້ານ Latency: ຄວນຕັດສິນໃຈໄວ້ລ່ວງໜ້າວ່າ ຖ້າຕ້ອງການການຕອບສະໜອງແບບ Real-time ໃຫ້ເລືອກຕົວແບບທີ່ມີນ້ຳໜັກເບົາ, ແຕ່ຖ້າເປັນການປະມວນຜົນແບບ Batch ທີ່ເນັ້ນຄວາມແມ່ນຍຳໃຫ້ເລືອກຕົວແບບທີ່ມີປະສິດທິພາບສູງ.

ການກຳນົດຕົວຊີ້ວັດການປະເມີນ

ໃນເວລາປຽບທຽບຕົວແບບທີ່ເປັນຜູ້ສະໝັກ, ສິ່ງສຳຄັນຄືການກຽມຕົວຊີ້ວັດທາງປະລິມານ ບໍ່ແມ່ນພຽງແຕ່ການປະເມີນທາງຄຸນນະພາບເທົ່ານັ້ນ. ຕົວຊີ້ວັດທີ່ເປັນຕົວແທນມີດັ່ງນີ້:

• ຄະແນນຄວາມແມ່ນຍຳ (Accuracy Score): ອັດຕາການຕອບຖືກໃນ Benchmark ສະເພາະຂອງວຽກນັ້ນໆ (ຕົວຢ່າງ: MATH-500 ຫຼື AIME ສຳລັບການໃຫ້ເຫດຜົນທາງຄະນິດສາດ).
• ຄວາມຄຸ້ມຄ່າຂອງຕົ້ນທຶນ (Cost Efficiency): ອັດຕາສ່ວນຂອງຕົ້ນທຶນ Token ທີ່ຈຳເປັນເພື່ອໃຫ້ໄດ້ລະດັບຄຸນນະພາບດຽວກັນ.
• Latency (P50/P95): ປະເມີນໂດຍລວມເຖິງການກະຈາຍຕົວຂອງຄ່າທີ່ຜິດປົກກະຕິ (Outliers) ບໍ່ແມ່ນພຽງແຕ່ຄ່າກາງເທົ່ານັ້ນ.
• ອັດຕາການສຳຮອງ (Fallback Rate): ອັດຕາສ່ວນທີ່ Router ບໍ່ສາມາດແບ່ງງານໄປຍັງຕົວແບບທີ່ຕັ້ງໃຈໄວ້ໄດ້.

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

"ການເພີ່ມ Routing layer ເຂົ້າໄປ ແລ້ວເຮັດໃຫ້ການຕອບສະໜອງຊ້າລົງ" ເປັນສິ່ງທີ່ມັກໄດ້ຍິນເລື້ອຍໆໃນການເຮັດວຽກຕົວຈິງ. ຖ້າບໍ່ກຳນົດການອອກແບບ ໂຄງສ້າງພື້ນຖານ ຫຼື Infrastructure ແລະ ຄ່າຄວາມໜ່ວງ (Latency) ທີ່ຍອມຮັບໄດ້ໄວ້ລ່ວງໜ້າ, ກໍມີຄວາມສ່ຽງທີ່ການ Routing ເອງຈະກາຍເປັນຄໍຂວດ (Bottleneck).

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

ຕໍ່ມາ, ຈຳເປັນຕ້ອງປະເມີນຕົ້ນທຶນການປະມວນຜົນຂອງ Router ເອງ. ໃນເອກະສານຂອງ Microsoft Azure Foundry ໄດ້ລະບຸຕົວຢ່າງຄວາມຊັກຊ້າເມື່ອມີການຈັດສັນໄປຍັງແຕ່ລະ Model ຜ່ານ model-router ໄວ້ວ່າ: ປະມານ 0.59 ວິນາທີສຳລັບ Model ຂະໜາດນ້ອຍ ແລະ ປະມານ 1.14 ວິນາທີສຳລັບ Model ຂະໜາດໃຫຍ່. ກະລຸນາອອກແບບໂດຍຕັ້ງສົມມຸດຕິຖານວ່າ ການເພີ່ມຂະບວນການຂອງ Router ເຂົ້າໄປ ຈະເຮັດໃຫ້ End-to-end latency ຍາວນານກວ່າເວລາໃນການອະນຸມານ (Inference) ຂອງ Model ພຽງຢ່າງດຽວ.

ສິ່ງທຳອິດທີ່ມັກຈະເປັນອຸປະສັກໃນການອອກແບບ Routing logic ຄືຄຳຖາມທີ່ວ່າ "ຄວນເລີ່ມຈາກບ່ອນໃດ". ຖ້າຫາກນຳເອົາແບບຈຳລອງການຈັດປະເພດ (Classification model) ມາໃຊ້ໃນທັນທີ, ຄວາມຊັບຊ້ອນຂອງ Logic ອາດຈະເຮັດໃຫ້ຜົນປະໂຫຍດຈາກການຫຼຸດຕົ້ນທຶນໝົດໄປ. ດັ່ງນັ້ນ, ການເລີ່ມຕົ້ນຈາກ Rule-based ຈຶ່ງເປັນທາງເລືອກທີ່ເປັນຈິງຫຼາຍກວ່າ ເຊິ່ງພຽງແຕ່ການແຍກປະເພດດ້ວຍເງື່ອນໄຂງ່າຍໆ ເຊັ່ນ: ຈຳນວນ Token ຫຼື ການມີຢູ່ຂອງ Keyword ສະເພາະ ກໍສາມາດຄາດຫວັງການຫຼຸດຕົ້ນທຶນໄດ້ຢ່າງມະຫາສານ.

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

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

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

ການຈັດຕັ້ງປະຕິບັດໂດຍທົ່ວໄປແມ່ນໃຫ້ດຳເນີນການຕາມລຳດັບດັ່ງນີ້:

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

ການແຍກກົດເກນອອກຈາກໂຄ້ດໄປໄວ້ໃນໄຟລ໌ຕັ້ງຄ່າ (YAML ຫຼື JSON) ຈະຊ່ວຍໃຫ້ສາມາດອັບເດດເງື່ອນໄຂຕ່າງໆໄດ້ໂດຍບໍ່ຈຳເປັນຕ້ອງ Deploy ໃໝ່. ໃນກໍລະນີສຶກສາຂອງ AWS, ມີການລາຍງານວ່າເມື່ອປຽບທຽບກັບ Semantic routing ແລ້ວ, ແບບ Rule-based ມີຕົ້ນທຶນໃນການຈັດຕັ້ງປະຕິບັດທີ່ຕໍ່າກວ່າ ແລະ ສາມາດຫຼຸດຕົ້ນທຶນລາຍເດືອນໃນວຽກງານທີ່ຄ້າຍຄືກັນໄດ້.

ເພື່ອຮອງຮັບຄຳຖາມທີ່ຫຼາກຫຼາຍເຊິ່ງກົດເກນພື້ນຖານ (Rule-based) ບໍ່ສາມາດຈັດການໄດ້, ການໃຊ້ແບບຈຳລອງການຈັດປະເພດ (Classification model) ເພື່ອເຮັດ Dynamic Routing ແມ່ນມີປະສິດທິພາບ. ໂດຍການຈັດປະເພດຂໍ້ຄວາມທີ່ປ້ອນເຂົ້າຕາມແກນຕ່າງໆ ເຊັ່ນ: "ຄວາມຊັບຊ້ອນ", "ໂດເມນ" ແລະ "ເຈດຕະນາ" ແບບ Real-time, ແລ້ວສົ່ງຂໍ້ມູນຕໍ່ໃຫ້ແບບຈຳລອງທີ່ເໝາະສົມທີ່ສຸດຕາມຜົນລັດທີ່ໄດ້.

ໂຄງສ້າງພື້ນຖານຂອງ Dynamic Routing

• ການເລືອກຕົວຈັດປະເພດ (Classifier): ແບບຈຳລອງຂະໜາດນ້ອຍໃນຕະກູນ BERT ຫຼື ຕົວໃຫ້ຄະແນນຄວາມຄ້າຍຄືກັນໂດຍອີງໃສ່ Embedding ຖືກນຳໃຊ້ຢ່າງກວ້າງຂວາງ. ໃນບົດວິໄຈ HyDRA ໄດ້ລະບຸວ່າຄ່າ CPU Inference Latency ປານກາງໃນການຜະລິດຈິງຖືກຄວບຄຸມໄວ້ທີ່ 86 ms, ເຊິ່ງສະແດງໃຫ້ເຫັນວ່າ Overhead ຂອງຕົວ Router ເອງສາມາດຮັກສາໄວ້ໃນລະດັບທີ່ເປັນຈິງໄດ້.
• ການອອກແບບ Feature: ການນຳເອົາຈຳນວນ Token, ໂຄງສ້າງຂອງຄຳຖາມ (ລາຍການ, ການມີຢູ່ຂອງໂຄດ) ແລະ ຄະແນນຄຸນນະພາບການຕອບກັບໃນອະດີດມາປະສົມປະສານກັນເປັນ Feature ຈະຊ່ວຍເພີ່ມຄວາມຖືກຕ້ອງໃນການຈັດປະເພດ.
• Output Label: ການຈຳກັດໄວ້ທີ່ປະມານ 3 ຄລາສ ເຊັ່ນ: "ແບບຈຳລອງຂະໜາດນ້ອຍ", "ແບບຈຳລອງປະສິດທິພາບສູງ" ແລະ "ແບບຈຳລອງສະເພາະທາງ" ຈະເຮັດໃຫ້ການດຳເນີນງານງ່າຍຂຶ້ນ.

ແກນຫຼັກໃນການຕັດສິນໃຈຕາມກໍລະນີ

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

ຂໍ້ຄວນລະວັງໃນການນຳໄປໃຊ້ງານ

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

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

ໃນການຕັ້ງຄ່າຂີດຈຳກັດຂອງຕົ້ນທຶນ, ໂດຍທົ່ວໄປແລ້ວຈະມີການບໍລິຫານຈັດການ 2 ຊັ້ນ ຄື: ຂີດຈຳກັດຂອງຈຳນວນ Token ສູງສຸດຕໍ່ 1 ຄຳຮ້ອງຂໍ (Request) ແລະ ງົບປະມານລາຍເດືອນ (Monthly Budget Cap). ຕົວຢ່າງເຊັ່ນ: ໃນກໍລະນີຂອງ AWS, ການສອບຖາມກ່ຽວກັບ History ແລະ Math ຈະມີຕົ້ນທຶນໃນການສ້າງຄຳຕອບທີ່ແຕກຕ່າງກັນຫຼາຍ ເຖິງແມ່ນວ່າຈະໃຊ້ຈຳນວນ Token ເທົ່າກັນກໍຕາມ. ການກຳນົດຂີດຈຳກັດແຍກຕ່າງຫາກຕາມປະເພດຂອງວຽກ ຈະຊ່ວຍປ້ອງກັນການຈັດສັນ Model ທີ່ເກີນຄວາມຈຳເປັນໄດ້.

ຂັ້ນຕອນພື້ນຖານໃນການອອກແບບຂີດຈຳກັດມີດັ່ງນີ້:

• ຂັ້ນຕອນທີ 1: ກຳນົດ "ຕົ້ນທຶນສູງສຸດທີ່ຍອມຮັບໄດ້" ແລະ "ຄະແນນຄຸນນະພາບຂັ້ນຕ່ຳທີ່ຈຳເປັນ" ສຳລັບແຕ່ລະປະເພດວຽກ
• ຂັ້ນຕອນທີ 2: ວັດແທກອັດຕາສ່ວນທີ່ສາມາດປະມວນຜົນໄດ້ດ້ວຍ Model ຂະໜາດນ້ອຍ (Lightweight Model) ແລະ ຄາດຄະເນຂີດຈຳກັດສູງສຸດໃນການຫຼຸດຕົ້ນທຶນ
• ຂັ້ນຕອນທີ 3: ຕັ້ງຄ່າກົດການສຳຮອງ (Fallback Rule) ເພື່ອຍົກລະດັບໄປໃຊ້ Model ທີ່ສູງກວ່າໂດຍອັດຕະໂນມັດ ເມື່ອເກີນຂີດຈຳກັດທີ່ກຳນົດໄວ້

ສຳລັບເງື່ອນໄຂການສຳຮອງ (Fallback) ຈະມີການນຳໃຊ້ Trigger 2 ປະເພດຫຼັກໆມາປະສົມປະສານກັນ:

• Trigger ດ້ານຄຸນນະພາບ: ສົ່ງຂໍ້ມູນຕໍ່ໃຫ້ Model ທີ່ສູງກວ່າອີກຄັ້ງ ໃນກໍລະນີທີ່ຄະແນນຄວາມໜ້າເຊື່ອຖືຂອງຜົນລັດຈາກ Model ຂະໜາດນ້ອຍຕ່ຳກວ່າຄ່າທີ່ກຳນົດໄວ້
• Trigger ດ້ານຕົ້ນທຶນ: ປັບອັດຕາສ່ວນການ Routing ເມື່ອການໃຊ້ງານລາຍເດືອນຮອດ 80% ຂອງງົບປະມານທີ່ຕັ້ງໄວ້ ແລະ ເພີ່ມການແບ່ງວຽກໄປໃຫ້ Model ຂະໜາດນ້ອຍຫຼາຍຂຶ້ນ

ແນະນຳໃຫ້ມີການກຽມ Model ສຳຮອງໄວ້ຢ່າງໜ້ອຍ 2 Model ຂຶ້ນໄປ.

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

ການເລືອກວິທີການປະສົມປະສານລະຫວ່າງໂມເດວຂະໜາດນ້ອຍ (Lightweight model) ແລະ ໂມເດວປະສິດທິພາບສູງ, ການເລືອກລະຫວ່າງຮູບແບບ Cascade ຫຼື Parallel, ແລະ ການຕັດສິນໃຈວ່າຈະນຳເອົາໂມເດວທີ່ຜ່ານການ Fine-tuning ມາປະກອບເຂົ້າໃນສ່ວນໃດ — ການຕັດສິນໃຈທັງສາມຢ່າງນີ້ ຄືຈຸດສຳຄັນ ຫຼື ແກນຫຼັກ ຂອງການອອກແບບທີ່ມີຜົນຕໍ່ການສ້າງຄວາມສົມດຸນລະຫວ່າງຕົ້ນທຶນ ແລະ ຄຸນນະພາບ.

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

ແນວຄວາມຄິດພື້ນຖານໃນການແບ່ງໜ້າທີ່ວຽກງານມີດັ່ງນີ້:

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

ໃນກໍລະນີສຶກສາຂອງ AWS, ເຖິງແມ່ນວ່າຈະມີປະລິມານ Token ໃນການສອບຖາມເທົ່າກັນ ແຕ່ກໍມີຄວາມແຕກຕ່າງກັນຢ່າງຫຼວງຫຼາຍລະຫວ່າງບັນຫາ History (ຕົ້ນທຶນການສ້າງຄຳຕອບປະມານ $619 ຕໍ່ເດືອນ) ແລະ ບັນຫາ Math (ປະມານ $7,425 ຕໍ່ເດືອນ) ເຊິ່ງສະແດງໃຫ້ເຫັນວ່າການປະມວນຜົນວຽກທີ່ມີຄວາມຍາກງ່າຍຕ່າງກັນດ້ວຍໂມເດວອັນດຽວກັນນັ້ນ ມັກຈະເຮັດໃຫ້ເກີດຕົ້ນທຶນທີ່ເກີນຄວາມຈຳເປັນ.

ຈຸດສຳຄັນໃນການຈັດຕັ້ງປະຕິບັດມີ 3 ປະການດັ່ງນີ້:

1. ການໃຫ້ຄະແນນຄວາມຍາກງ່າຍ (Scoring): ໃຫ້ຄະແນນຄວາມຊັບຊ້ອນຂອງຄຳຖາມລ່ວງໜ້າ ໂດຍພິຈາລະນາຈາກຈຳນວນ Token, ຄຳສັບ, ຄວາມສຳພັນ ແລະ ອື່ນໆ ແລ້ວສົ່ງວຽກທີ່ຕໍ່າກວ່າເກນມາດຕະຖານໄປໃຫ້ໂມເດວຂະໜາດນ້ອຍ.
2. ການກັ່ນຕອງຄວາມໜ້າເຊື່ອຖື (Confidence Filter): ໃນກໍລະນີທີ່ຄະແນນຄວາມໜ້າເຊື່ອຖືທີ່ຕິດມາກັບຜົນລັດຂອງໂມເດວຂະໜາດນ້ອຍນັ້ນຕໍ່າ, ໃຫ້ສົ່ງວຽກຕໍ່ໃຫ້ໂມເດວທີ່ມີປະສິດທິພາບສູງໂດຍອັດຕະໂນມັດ.
3. ກົດລະບຽບຕາມແຕ່ລະໂດເມນ: ໃຫ້ຕິດປ້າຍກຳກັບ (Labeling) ໝວດໝູ່ຂອງຄຳຖາມວ່າເປັນ "ຂໍ້ມູນທົ່ວໄປ" ຫຼື "ການຕັດສິນໃຈແບບຊ່ຽວຊານ" ແລ້ວລັອກໂມເດວໃຫ້ໃຊ້ສະເພາະຕາມໝວດໝູ່ນັ້ນໆ.

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

ຮູບແບບ Cascade ແລະ Parallel ລ້ວນແຕ່ເປັນວິທີການນຳເອົາຫຼາຍໂມເດວມາປະສົມປະສານກັນ ແຕ່ເໝາະສົມກັບສະຖານະການທີ່ແຕກຕ່າງກັນ. ຖ້າຕ້ອງການບຸລິມະສິດໃນການຫຼຸດຕົ້ນທຶນຫຼາຍກວ່າ Latency ໃຫ້ເລືອກຮູບແບບ Cascade, ແຕ່ຖ້າຕ້ອງການບຸລິມະສິດໃນດ້ານຄວາມແມ່ນຍຳ ແລະ ຄວາມໜ້າເຊື່ອຖືເປັນຫຼັກ ໃຫ້ເລືອກຮູບແບບ Parallel.

ຮູບແບບ Cascade ແມ່ນໂຄງສ້າງທີ່ເລີ່ມຈາກການໃຫ້ໂມເດວຂະໜາດນ້ອຍ (Lightweight model) ປະມວນຜົນກ່ອນ ແລະ ຈະສົ່ງຂໍ້ມູນຕໍ່ໃຫ້ໂມເດວລະດັບສູງກວ່າກໍຕໍ່ເມື່ອຄະແນນຄວາມໜ້າເຊື່ອຖື (Confidence score) ຕ່ຳກວ່າເກນທີ່ກຳນົດໄວ້ເທົ່ານັ້ນ.

• ຂະບວນການ ຫຼື Pipeline: ໂມເດວຂະໜາດນ້ອຍ → ການຕັດສິນຄະແນນຄວາມໜ້າເຊື່ອຖື → ໂມເດວປະສິດທິພາບສູງ (ມີເງື່ອນໄຂ)
• Amazon Bedrock Intelligent Prompt Routing ຂອງ AWS ມີແນວຄິດທີ່ໃກ້ຄຽງກັບເລື່ອງນີ້ ເຊິ່ງມີລາຍງານວ່າສາມາດຫຼຸດຕົ້ນທຶນໄດ້ສູງສຸດເຖິງ 30%
• ການຕອບ FAQ ແບບງ່າຍໆ ຫຼື ການຕອບໂຕ້ຕາມຮູບແບບທີ່ກຳນົດໄວ້ຈະສຳເລັດໄດ້ດ້ວຍໂມເດວຂະໜາດນ້ອຍ ແລະ ຈະຍົກລະດັບໄປຫາໂມເດວລະດັບສູງກໍຕໍ່ເມື່ອຕ້ອງການການວິເຄາະທີ່ຊັບຊ້ອນເທົ່ານັ້ນ

ຮູບແບບ Parallel ແມ່ນໂຄງສ້າງທີ່ສົ່ງ Query ດຽວກັນໄປຍັງຫຼາຍໂມເດວພ້ອມກັນ ແລ້ວລວມ ຫຼື Merge ຜົນລັດ ຫຼື ໃຊ້ການລົງຄະແນນສຽງສ່ວນຫຼາຍເພື່ອຕັດສິນຜົນລັດສຸດທ້າຍ.

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

ເພື່ອເປັນມາດຕະຖານ ຫຼື Specification ໃນການຕັດສິນໃຈ: ຖ້າເນັ້ນຄວາມຄຸ້ມຄ່າຂອງຕົ້ນທຶນໃຫ້ເລືອກຮູບແບບ Cascade, ແຕ່ຖ້າການຮັບປະກັນຄວາມໜ້າເຊື່ອຖືຂອງຄຳຕອບແມ່ນບຸລິມະສິດສູງສຸດ ໃຫ້ເລືອກຮູບແບບ Parallel.

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

ຫຼາຍໜ້າວຽກມັກຈະເກີດຄວາມລັງເລວ່າ "ໃນເມື່ອມີໂມເດວທີ່ຜ່ານການ Fine-tuning ແລ້ວ, ຄວນຈະປະຕິບັດຕໍ່ມັນຄືກັນກັບໂມເດວທົ່ວໄປ (General-purpose model) ຫຼືບໍ່?"

ໂມເດວທີ່ຜ່ານການ Fine-tuning ສາມາດສະແດງປະສິດທິພາບທີ່ທຽບເທົ່າ ຫຼື ເໜືອກວ່າໂມເດວປະສິດທິພາບສູງແບບທົ່ວໄປໃນວຽກງານສະເພາະດ້ານ ດ້ວຍຕົ້ນທຶນທີ່ຕໍ່າກວ່າ. ໃນການອອກແບບ Routing, ການກຳນົດຕຳແໜ່ງຂອງໂມເດວນີ້ໃຫ້ເປັນ "Domain-specific route" ຢ່າງຊັດເຈນແມ່ນມີຄວາມສຳຄັນ.

ຂັ້ນຕອນພື້ນຖານໃນການນຳໄປໃຊ້ ມີດັ່ງນີ້:

• ການກຳນົດຂອບເຂດໂດເມນໃຫ້ຊັດເຈນ: ກຳນົດວຽກງານທີ່ໂມເດວນັ້ນມີຄວາມຊຳນານ (ຕົວຢ່າງ: ການສະຫຼຸບເອກະສານທາງກົດໝາຍ, ການຕອບ FAQ ຂອງຜະລິດຕະພັນສະເພາະ) ເປັນປ້າຍກຳກັບ (Classification label).
• ການຕັ້ງຄ່າຄະແນນຄວາມເຊື່ອໝັ້ນ (Confidence score): ໃຫ້ເຮັດການ Routing ກໍຕໍ່ເມື່ອຄວາມເປັນໄປໄດ້ທີ່ Input query ຈະຕົກຢູ່ໃນໂດເມນຂອງໂມເດວທີ່ Fine-tuning ມາ ເກີນກວ່າເກນທີ່ກຳນົດໄວ້ (ຕົວຢ່າງ: 0.8 ຂຶ້ນໄປ).
• ການກຽມທາງເລືອກສຳຮອງ (Fallback): ໃນກໍລະນີທີ່ຄະແນນຕໍ່າກວ່າເກນ ຫຼື ໂມເດວສົ່ງສັນຍານວ່າ "ບໍ່ຮູ້", ໃຫ້ສົ່ງຂໍ້ມູນຕໍ່ໃຫ້ໂມເດວແບບທົ່ວໄປໂດຍອັດຕະໂນມັດ.

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

ອີກຈຸດໜຶ່ງທີ່ມັກຖືກມອງຂ້າມຄື ການເຊື່ອມໂຍງວົງຈອນການຝຶກຝົນໂມເດວຄືນໃໝ່ (Re-training cycle) ເຂົ້າກັບການບໍລິຫານຈັດການເວີຊັນຂອງ Routing logic. ເມື່ອມີການອັບເດດໂມເດວ, ການອອກແບບຂະບວນການທີ່ຕ້ອງມີການກວດສອບປ້າຍກຳກັບ ແລະ ເກນຄະແນນຄືນໃໝ່ໄປພ້ອມກັນນັ້ນ ຈະຊ່ວຍປ້ອງກັນການຫຼຸດລົງຂອງຄຸນນະພາບໃນສະພາບແວດລ້ອມການໃຊ້ງານຈິງໄດ້ງ່າຍຂຶ້ນ.

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

ນັບຕັ້ງແຕ່ການເບິ່ງເຫັນປະລິມານການໃຊ້ງານ Token ໄປຈົນເຖິງການກວດສອບຄວາມຖືກຕ້ອງຂອງ Routing ຜ່ານ A/B Test, ພວກເຮົາຈະອະທິບາຍຂັ້ນຕອນການວັດແທກ ແລະ ການປັບປຸງທີ່ຄວນປະຕິບັດໃນໄລຍະການດຳເນີນງານ.

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

ຕົວຊີ້ວັດຫຼັກທີ່ຄວນວັດແທກມີ 4 ຢ່າງດັ່ງນີ້:

• ປະລິມານການໃຊ້ Token ແຍກຕາມ Model (ບັນທຶກແຍກລະຫວ່າງ Input ແລະ Output)
• ຄ່າໃຊ້ຈ່າຍ API ແຍກຕາມ Route (ລາຄາຕໍ່ Request × ຈຳນວນຄັ້ງ)
• ຄວາມໜ່ວງ (Latency) ໃນການຕັດສິນໃຈ Routing (ແຍກເວລາການປະມວນຜົນຂອງ Router ອອກຈາກການເອີ້ນໃຊ້ Model)
• ອັດຕາການເກີດ Fallback (ເພື່ອໃຫ້ຮູ້ເຖິງການໄຫຼເຂົ້າໄປຫາ Model ທີ່ມີຄ່າໃຊ້ຈ່າຍສູງໂດຍບໍ່ໄດ້ຕັ້ງໃຈ)

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

ຈຸດສຳຄັນໃນການຈັດຕັ້ງປະຕິບັດມີ 3 ຢ່າງ:

1. ຮູບແບບ Log ທີ່ມີໂຄງສ້າງເປັນເອກະພາບ: ລວມ Request ID, ຊື່ Model, ຈຳນວນ Token ທີ່ເຂົ້າ-ອອກ, ຄ່າໃຊ້ຈ່າຍ ແລະ ຄວາມໜ່ວງ ໄວ້ໃນ Record ດຽວ.
2. ການອອກແບບຄວາມລະອຽດໃນການລວມຍອດຂໍ້ມູນ: ຄວນອອກແບບໃຫ້ສາມາດລວມຍອດຂໍ້ມູນແຍກຕາມຊ່ວງເວລາ, ປະເພດຂອງ Task ແລະ ກຸ່ມຜູ້ໃຊ້ໄດ້.
3. ການຕັ້ງຄ່າ Threshold ສຳລັບການແຈ້ງເຕືອນ: ສ້າງກົນໄກການແຈ້ງເຕືອນເມື່ອອັດຕາການໄຫຼເຂົ້າໄປຫາ Model ທີ່ມີຄ່າໃຊ້ຈ່າຍສູງເກີນອັດຕາສ່ວນທີ່ກຳນົດໄວ້.

ແນະນຳໃຫ້ສະແດງຜົນຂໍ້ມູນທີ່ລວມຍອດໄດ້ຜ່ານ Dashboard ແລະ ນຳເຂົ້າສູ່ຮອບວຽນການທົບທວນກົດລະບຽບ Routing ເປັນລາຍອາທິດ.

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

ຕົວຊີ້ວັດທີ່ຄວນວັດແທກມີ 3 ຢ່າງດັ່ງນີ້:

• ອັດຕາຄວາມຖືກຕ້ອງຂອງການ Routing: ອັດຕາສ່ວນທີ່ຖືກແບ່ງໄປຍັງໂມເດວທີ່ຕັ້ງໃຈໄວ້ ໂດຍໃຊ້ຊຸດທົດສອບທີ່ມີການຕິດປ້າຍກຳກັບ (Label) ໄວ້ລ່ວງໜ້າ
• ຄະແນນຄຸນນະພາບ: ຄ່າທີ່ໄດ້ຈາກການໃຫ້ຄະແນນຜົນລວມຂອງແຕ່ລະໂມເດວໂດຍມະນຸດ ຫຼື LLM-as-a-Judge
• ຄຸນນະພາບຕໍ່ຕົ້ນທຶນ (ອັດຕາສ່ວນ Quality/Cost): ປຽບທຽບດ້ວຍປະສິດທິພາບດ້ານຕົ້ນທຶນ ແທນທີ່ຈະເບິ່ງພຽງແຕ່ຄວາມຖືກຕ້ອງເທົ່ານັ້ນ

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

ການອອກແບບ A/B Test ຈະມີແນວທາງປ່ຽນໄປຕາມຈຸດປະສົງ. ຖ້າຕ້ອງການກວດສອບປະສິດທິຜົນຂອງເຫດຜົນ (Logic) ໃນການ Routing ທັງໝົດ ໃຫ້ແບ່ງ Traffic ອອກເປັນ "ກຸ່ມທີ່ມີການ Routing" ແລະ "ກຸ່ມທີ່ໃຊ້ໂມເດວດຽວຄົງທີ່" ແລ້ວປຽບທຽບທັງໃນດ້ານຕົ້ນທຶນແລະຄຸນນະພາບ. ໃນທາງກົງກັນຂ້າມ, ຖ້າຕ້ອງການເບິ່ງພຽງແຕ່ຜົນກະທົບຈາກການປັບປຸງກົດເກນສະເພາະໃດໜຶ່ງ ການເຮັດ Split Test ໂດຍສະຫຼັບສະເພາະໝວດໝູ່ Query ທີ່ກ່ຽວຂ້ອງຈະເໝາະສົມກວ່າ.

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

ຄວາມຜິດພາດທີ່ພົບເຫັນເລື້ອຍໆມີ 2 ປະການ ຄື: ການເພີ່ມຂຶ້ນຂອງຄວາມໜ່ວງ (Latency) ຂອງຕົວ Router ເອງ ແລະ ຄຸນນະພາບທີ່ຫຼຸດລົງເນື່ອງຈາກຄວາມລະອຽດໃນການຈັດປະເພດ (Classification) ຕ່ຳ. ຕໍ່ໄປນີ້ຈະເປັນການອະທິບາຍເຖິງສາເຫດ ແລະ ວິທີການຫຼີກລ່ຽງຂອງແຕ່ລະປະການ.

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

ສາເຫດທີ່ເຮັດໃຫ້ເກີດຄໍຂວດ (Bottleneck) ທີ່ພົບເຫັນໄດ້ເລື້ອຍໆ ຄືການນຳເອົາການຕັດສິນໃຈດ້ານ Routing ໄປປະຕິບັດໃນຮູບແບບການປະມວນຜົນແບບ Synchronous. ເນື່ອງຈາກການຮຽກໃຊ້ Model ທີ່ຕາມມາຈະບໍ່ສາມາດເລີ່ມຕົ້ນໄດ້ຈົນກວ່າການຕັດສິນໃຈຈະສຳເລັດ ເວລາທີ່ລໍຖ້ານັ້ນຈຶ່ງສົ່ງຜົນກະທົບໂດຍກົງຕໍ່ປະສົບການຂອງຜູ້ໃຊ້. ຕໍ່ມາ, ຖ້າເລືອກໂຄງສ້າງທີ່ຕ້ອງຮຽກໃຊ້ LLM ຂະໜາດໃຫຍ່ໃນການຕັດສິນໃຈ ກໍອາດເຮັດໃຫ້ Latency ຂອງເຣົາເຕີເອງສູງເຖິງຫຼາຍວິນາທີ ເຊິ່ງເປັນປະກົດການປີ້ນກັບກັນທີ່ເຣົາເຕີເຊິ່ງຄວນຈະຖືກນຳມາໃຊ້ເພື່ອຫຼຸດນ້ຳໜັກຂອງລະບົບ ກັບກາຍເປັນສ່ວນທີ່ປະມວນຜົນໜັກທີ່ສຸດ. ຍິ່ງໄປກວ່ານັ້ນ, ໃນໂຄງສ້າງທີ່ບໍ່ມີການ Cache ເຊິ່ງຕ້ອງດຳເນີນການຈັດປະເພດ (Classification) ສຳລັບຮູບແບບ Query ດຽວກັນໃນທຸກຄັ້ງ ກໍຈະເຮັດໃຫ້ເກີດ Overhead ທີ່ບໍ່ຈຳເປັນສະສົມຂຶ້ນຢ່າງງຽບໆ.

ໃນການຄົ້ນຄວ້າຂອງ HyDRA, ການຄວບຄຸມຄ່າ Median CPU Inference Latency ຂອງຕົວພະຍາກອນ (Predictor) ໃນສະພາບແວດລ້ອມການໃຊ້ງານຈິງໃຫ້ຢູ່ທີ່ 86 ms ຊ່ວຍໃຫ້ຄວາມຊັກຊ້າທີ່ເກີດຈາກເຣົາເຕີຢູ່ໃນຂອບເຂດທີ່ນຳໄປໃຊ້ງານໄດ້ຈິງ. ຕົວເລກນີ້ສະແດງໃຫ້ເຫັນຢ່າງຊັດເຈນວ່າ ແນວຄິດການອອກແບບທີ່ເນັ້ນໃຫ້ເຣົາເຕີມີນ້ຳໜັກເບົານັ້ນມີຄວາມສຳຄັນພຽງໃດ.

ດັ່ງນັ້ນ, ເຮົາຈະຫຼີກລ່ຽງບັນຫາເຫຼົ່ານີ້ໄດ້ແນວໃດ? ວິທີການທີ່ມີປະສິດທິພາບຈະຖືກສະຫຼຸບໄວ້ໃນຫົວຂໍ້ຕໍ່ໄປນີ້.

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

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

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

ເພື່ອເປັນມາດຕະການປ້ອງກັນການຫຼຸດລົງຂອງຄຸນນະພາບ, ຄວນພິຈາລະນາດັ່ງນີ້:

• ການຂະຫຍາຍຊຸດການປະເມີນຜົນຢ່າງຕໍ່ເນື່ອງ: ສ້າງຮອບວຽນການດຳເນີນງານໂດຍການເກັບກຳຕົວຢ່າງການຈັດປະເພດທີ່ຜິດພາດຈາກ Log ການໃຊ້ງານຈິງ ແລ້ວນຳມາລວມເຂົ້າໃນຂໍ້ມູນສຳລັບການຝຶກຝົນ Model ການຈັດປະເພດໃໝ່.
• ການນຳໃຊ້ຄະແນນຄວາມເຊື່ອໝັ້ນ (Confidence Score): ກຳນົດຄະແນນຄວາມເຊື່ອໝັ້ນໃຫ້ກັບຜົນການຈັດປະເພດ ແລະ ສ້າງກົນໄກທີ່ອັດຕະໂນມັດໃນການຍົກລະດັບ Query ທີ່ມີຄະແນນຕ່ຳໄປຫາ Model ທີ່ມີປະສິດທິພາບສູງ.
• ການກຳນົດຂອບເຂດຂອງວຽກງານໃຫ້ຊັດເຈນ: ເນື່ອງຈາກການກຳນົດໝວດໝູ່ເຊັ່ນ "ການຄາດຄະເນທີ່ຊັບຊ້ອນ" ຫຼື "Q&A ທີ່ງ່າຍດາຍ" ຫາກບໍ່ຊັດເຈນຈະເຮັດໃຫ້ການຝຶກຝົນຕົວຈັດປະເພດ (Classifier) ເປັນໄປໄດ້ຍາກ, ດັ່ງນັ້ນຄວນມີການບັນທຶກມາດຕະຖານຂອງ Label ເປັນເອກະສານ ແລະ ແບ່ງປັນໃຫ້ຜູ້ທີ່ກ່ຽວຂ້ອງຮັບຊາບ.

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

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

ສຳລັບການເລືອກ Logic ໃນການ Routing, ວິທີການທີ່ເປັນໄປໄດ້ໃນທາງປະຕິບັດຄື ການເລີ່ມຕົ້ນຈາກກົດເກນແບບງ່າຍໆ (Rule-based) ແລະ ປ່ຽນໄປໃຊ້ Model ການຈັດປະເພດເມື່ອຄວາມຫຼາກຫຼາຍຂອງ Query ເພີ່ມທະວີຂຶ້ນເລື້ອຍໆ. ໃນກໍລະນີຂອງ HyDRA ໄດ້ສະແດງໃຫ້ເຫັນວ່າສາມາດຫຼຸດຕົ້ນທຶນໄດ້ 54.1% ພາຍໃຕ້ເງື່ອນໄຂ iso-quality, ສ່ວນ TRIM ສາມາດຫຼຸດການໃຊ້ Token ຂອງ Model ທີ່ມີຕົ້ນທຶນສູງໄດ້ເຖິງ 80% ໃນ MATH-500, ເຊິ່ງສະແດງໃຫ້ເຫັນວ່າຄຸນນະພາບຂອງການອອກແບບສົ່ງຜົນໂດຍກົງຕໍ່ຕົວເລກດັ່ງກ່າວ.

ໃນດ້ານໂຄງສ້າງ Architecture, ການກຳນົດບົດບາດລະຫວ່າງ Model ຂະໜາດນ້ອຍ ແລະ Model ປະສິດທິພາບສູງໃຫ້ຊັດເຈນ ພ້ອມກັບການໃຊ້ໂຄງສ້າງແບບ Cascade ເພື່ອຍົກລະດັບຂຶ້ນເປັນຂັ້ນຕອນ ຈະນຳໄປສູ່ການດຳເນີນງານທີ່ໝັ້ນຄົງ. ໃນກໍລະນີຂອງ AWS, ມີລາຍງານວ່າ Amazon Bedrock Intelligent Prompt Routing ສາມາດຫຼຸດຕົ້ນທຶນໄດ້ສູງສຸດເຖິງ 30%, ສະນັ້ນການນຳໃຊ້ Managed Service ຈຶ່ງເປັນສິ່ງທີ່ຄວນພິຈາລະນາຢ່າງເຕັມທີ່.

ເພື່ອໃຫ້ການອອກແບບເຫຼົ່ານີ້ສາມາດໃຊ້ງານໄດ້ໃນໄລຍະຍາວ, ຈຳເປັນຕ້ອງມີລະບົບການດຳເນີນງານທີ່ຕິດຕາມກວດກາ 3 ປັດໄຈຫຼັກຄື: ປະລິມານການບໍລິໂພກ Token, ຄວາມແມ່ນຍຳໃນການ Routing ແລະ ຄຸນນະພາບສຳລັບ End-user, ລວມເຖິງການທົບທວນຄ່າ Threshold ຢ່າງສະໝໍ່າສະເໝີຜ່ານການເຮັດ A/B Test. ການຈັດສັນແບບ Dynamic ຕາມລັກສະນະຂອງ Task ບໍ່ແມ່ນສິ່ງທີ່ເຮັດຄັ້ງດຽວແລ້ວຈົບ, ແຕ່ເປັນສິ່ງທີ່ຕ້ອງພັດທະນາໄປພ້ອມກັບການສະສົມຂໍ້ມູນຈາກການໃຊ້ງານຈິງ.