Dynamic Prompt Routing ແມ່ນຫຍັງ? ການອອກແບບເພື່ອເລືອກ LLM ທີ່ເໝາະສົມທີ່ສຸດຕາມ Query

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

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

Dynamic Prompt Routing ແມ່ນກົນໄກສຳລັບການ "ເລືອກໃຊ້" ຫຼາຍໂມເດວ ຫຼື ຫຼາຍ Prompt ໃຫ້ເໝາະສົມ. ກ່ອນອື່ນໝົດ, ໃຫ້ທຳຄວາມເຂົ້າໃຈກ່ຽວກັບຄວາມແຕກຕ່າງຈາກການເລືອກແບບຄົງທີ່ (Static selection) ແລະ ເຕັກນິກນີ້ມີໄວ້ເພື່ອແກ້ໄຂບັນຫາຫຍັງ.

ການເລືອກແບບຈຳລອງແບບຄົງທີ່ (Static model selection) ແມ່ນວິທີການກຳນົດໄວ້ໃນແອັບພລິເຄຊັນວ່າ "Endpoint ນີ້ຈະໃຊ້ແບບຈຳລອງນີ້ສະເໝີ". ເຖິງວ່າການຈັດຕັ້ງປະຕິບັດຈະງ່າຍດາຍ, ແຕ່ເນື່ອງຈາກທຸກຄຳຖາມ (Query) ຕ້ອງຜ່ານແບບຈຳລອງດຽວກັນ, ມັນຈຶ່ງເຮັດໃຫ້ເກີດຄ່າໃຊ້ຈ່າຍສູງສຳລັບຄຳຖາມທີ່ງ່າຍດາຍ ແລະ ເກີດບັນຫາຄວາມສາມາດບໍ່ພຽງພໍສຳລັບຄຳຖາມທີ່ມີຄວາມຊ່ຽວຊານ.

ສຳລັບການຈັດເສັ້ນທາງແບບເຄື່ອນໄຫວ (Dynamic routing), ລະບົບຈະຕັດສິນໃຈວ່າ "ແບບຈຳລອງໃດ ຫຼື Prompt ໃດທີ່ເໝາະສົມທີ່ສຸດສຳລັບຄຳຖາມນີ້" ທຸກຄັ້ງທີ່ມີການສົ່ງຄຳຖາມເຂົ້າມາ ກ່ອນທີ່ຈະດຳເນີນການ. ຕົວຢ່າງເຊັ່ນ: ຄຳຖາມສັ້ນໆປະເພດ FAQ ຈະຖືກສົ່ງໄປຍັງແບບຈຳລອງຂະໜາດນ້ອຍ, ສ່ວນການວິເຄາະຂໍ້ຄວາມຍາວໆ ຫຼື ການສ້າງໂຄ້ດຈະຖືກສົ່ງໄປຍັງແບບຈຳລອງທີ່ມີປະສິດທິພາບສູງ.

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

ການຈັດເສັ້ນທາງ (Routing) ມີເປົ້າໝາຍເພື່ອປັບໃຫ້ເໝາະສົມພ້ອມກັນໃນ 3 ຕົວຊີ້ວັດທີ່ມີຄວາມສຳພັນແບບ ການແລກປ່ຽນ ຫຼື Trade-off:

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

ຈຸດສຳຄັນ ຫຼື ແກນຫຼັກ ແມ່ນ 3 ປັດໄຈນີ້ມີຄວາມສຳພັນແບບ ການແລກປ່ຽນ ຫຼື Trade-off ເຊິ່ງແບບຈຳລອງດຽວບໍ່ສາມາດຕອບໂຈດໄດ້ພ້ອມກັນ. ການຈັດເສັ້ນທາງ (Routing) ຈະເຮັດໃຫ້ ການແລກປ່ຽນ ຫຼື Trade-off ນີ້ປ່ຽນແປງໄປໃນພາບລວມ ໂດຍການ "ເລືອກຈຸດທີ່ເໝາະສົມທີ່ສຸດສຳລັບແຕ່ລະຄິວຣີ".

ການ Routing ຍັງເຮັດໜ້າທີ່ເປັນທາງເຂົ້າຂອງໂຄງສ້າງແບບ Multi-agent ອີກດ້ວຍ.

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

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

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

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

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

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

ຈຸດສຳຄັນ ຫຼື ແກນຫຼັກ ຂອງການຫຼຸດຜ່ອນຕົ້ນທຶນແມ່ນການເລືອກໃຊ້ SLM (Small Language Models) ແລະ LLM ໃຫ້ເໝາະສົມ.

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

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

ສຳລັບການນຳໃຊ້ໃນລະດັບອົງກອນ, ນອກຈາກເລື່ອງຕົ້ນທຶນ ແລະ ຄວາມແມ່ນຍຳແລ້ວ, ຄວາມສາມາດໃນການສັງເກດການ (Observability) ແລະ ການກຳກັບດູແລ (Governance) ຍັງກາຍເປັນຂໍ້ກຳນົດທີ່ສຳຄັນໃນການອອກແບບລະບົບ Routing ອີກດ້ວຍ.

ຖ້າບໍ່ສາມາດບັນທຶກ ແລະ ຕິດຕາມໄດ້ວ່າ Query ໃດຖືກສົ່ງໄປຫາ Model ໃດ, ມີຄ່າໃຊ້ຈ່າຍເທົ່າໃດ ແລະ ໄດ້ຜົນລັອບແບບໃດ ກໍຈະບໍ່ສາມາດຄວບຄຸມຕົ້ນທຶນ, ປັບປຸງຄຸນນະພາບ ຫຼື ແກ້ໄຂບັນຫາຕ່າງໆໄດ້. ເນື່ອງຈາກຊັ້ນ Routing ເປັນດ່ານກວດທີ່ທຸກ Request ຕ້ອງຜ່ານ, ການເກັບ Log, Metrics ແລະ Trace ໄວ້ທີ່ຈຸດນີ້ຈຶ່ງເປັນເລື່ອງທີ່ສົມເຫດສົມຜົນ.

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

ວິທີການຈັດຕັ້ງປະຕິບັດການ Routing ສາມາດແບ່ງອອກໄດ້ເປັນ 3 ປະເພດໃຫຍ່. ຄວາມສະຫຼາດໃນການຕັດສິນໃຈ ແລະ ຕົ້ນທຶນໃນການຈັດຕັ້ງປະຕິບັດມີຄວາມສຳພັນແບບ ການແລກປ່ຽນ ຫຼື Trade-off, ຄວນເລືອກສິ່ງທີ່ເໝາະສົມກັບການນຳໃຊ້.

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

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

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

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

ວິທີການແບບ Embedding-based ແມ່ນວິທີການທີ່ປ່ຽນ Query ໃຫ້ເປັນ Vector ແລ້ວຈັດແບ່ງຕາມຄວາມໃກ້ຄຽງທາງຄວາມໝາຍກັບໝວດໝູ່ (Representative Vector) ທີ່ກຽມໄວ້ລ່ວງໜ້າ.

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

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

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

ວິທີທີ່ມີຄວາມຍືດຫຍຸ່ນທີ່ສຸດແມ່ນ Meta LLM Routing. ໂດຍໃຫ້ LLM ຂະໜາດນ້ອຍເປັນຜູ້ຕັດສິນໃຈວ່າ "ຄວຣີ (Query) ນີ້ຄວນປະມວນຜົນດ້ວຍໂມເດວໃດ" ແລ້ວສົ່ງຂໍ້ມູນຕໍ່ໃຫ້ຕາມຜົນລັພນັ້ນ.

ຈຸດແຂງຂອງມັນແມ່ນສາມາດຕັດສິນໃຈໄດ້ຢ່າງຮອບດ້ານ ລວມເຖິງບໍລິບົດ ແລະ ລະດັບຄວາມຍາກງ່າຍ ໂດຍທີ່ມະນຸດບໍ່ຈຳເປັນຕ້ອງກຳນົດແກນການຈັດປະເພດເອງ. ມັນຍັງສາມາດຮອງຮັບຄວຣີປະເພດໃໝ່ໆໄດ້ໃນລະດັບໜຶ່ງໂດຍບໍ່ຕ້ອງເພີ່ມກົດເກນໃດໆ.

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

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

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

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

ເມື່ອເບິ່ງຜ່ານ 3 ແກນຫຼັກ, ລັກສະນະຂອງແຕ່ລະຍຸດທະສາດຈະມີຄວາມຊັດເຈນຂຶ້ນ.

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

ຄວາມໜ່ວງ (Latency): ເຊັ່ນດຽວກັນ, ເວລາໃນການຕັດສິນໃຈຈະເພີ່ມຂຶ້ນຕາມລຳດັບຄື: ກົດເກນ < Embedding < Meta-LLM. ແຕ່ເນື່ອງຈາກ "ເວລາໃນການຕັດສິນໃຈແຍກປະເພດ" ມັກຈະມີຜົນໜ້ອຍກວ່າ "ເວລາໃນການປະມວນຜົນຂອງ Model ປາຍທາງ", ດັ່ງນັ້ນການແຍກປະເພດໄປຍັງ Model ທີ່ເໝາະສົມຈຶ່ງມີຜົນຕໍ່ປະສົບການການໃຊ້ງານຫຼາຍກວ່າ.

ຄວາມຖືກຕ້ອງ (Accuracy): ຄວາມຖືກຕ້ອງໃນການແຍກປະເພດມັກຈະເພີ່ມຂຶ້ນຕາມລຳດັບຄື: ກົດເກນ < Embedding < Meta-LLM, ແຕ່ Meta-LLM ກໍມີຄວາມສ່ຽງທີ່ຈະເກີດຂໍ້ຜິດພາດໃນການຕັດສິນໃຈໄດ້ເຊັ່ນກັນ. ທັງ 3 ແກນນີ້ແມ່ນ ການແລກປ່ຽນ ຫຼື Trade-off, ເຊິ່ງມີເງື່ອນໄຂເບື້ອງຕົ້ນຄືຕ້ອງມີການວັດແທກ ແລະ ປະເມີນຜົນຕົວຈິງຈາກການແຈກຢາຍ Query ຂອງບໍລິສັດຕົນເອງ.

ຈາກມຸມມອງຂອງການດຳເນີນງານຢ່າງຕໍ່ເນື່ອງ, ຄ່າໃຊ້ຈ່າຍໃນການບຳລຸງຮັກສາຈະມີຜົນຫຼາຍກວ່າການຕິດຕັ້ງໃນເບື້ອງຕົ້ນ.

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

ການໃຊ້ Embedding-based, ຖ້າຫາກມີການຈັດກຽມໝວດໝູ່ ແລະ ຕົວຢ່າງຫຼັກໄວ້ດີແລ້ວ ກໍຈະສາມາດຮອງຮັບຮູບແບບໃໝ່ໆໄດ້ໂດຍອັດຕະໂນມັດ. ຢ່າງໃດກໍຕາມ, ເມື່ອຕ້ອງການເພີ່ມ ຫຼື ທົບທວນໝວດໝູ່ເອງ ກໍຈຳເປັນຕ້ອງມີການອອກແບບຕົວຢ່າງຫຼັກໃໝ່ ແລະ ປັບຄ່າ Threshold ຄືນໃໝ່.

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

ໃນຄວາມເປັນຈິງແລ້ວ, ການໃຊ້ລະບົບ Hybrid ໂດຍຮັກສາໂຄງຮ່າງຫຼັກໃຫ້ເປັນ Rule-based ຢ່າງເດັດຂາດ ແລ້ວເສີມສ່ວນທີ່ບໍ່ຊັດເຈນດ້ວຍ Embedding ຫຼື Meta LLM ແມ່ນວິທີທີ່ສາມາດຮັກສາຄວາມສົມດຸນກັບຄວາມສາມາດໃນການບຳລຸງຮັກສາໄດ້ດີທີ່ສຸດ.

ການ Routing ຈະຖືກນຳໄປໃຊ້ຮ່ວມກັບວິທີການອື່ນໆ ເຊັ່ນ: RAG ແລະ Chain-of-Thought (CoT).

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

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

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

ຈາກນີ້ໄປ, ຈະຂໍລົງລາຍລະອຽດກ່ຽວກັບວິທີການຈັດຕັ້ງປະຕິບັດໂດຍແບ່ງອອກເປັນ 3 ຂັ້ນຕອນຄື: ການອອກແບບຕົວຈັດປະເພດ Query (Query Classifier), ການຈັດສັນ Model, ແລະ ການເຮັດ Fallback. ນະໂຍບາຍພື້ນຖານແມ່ນເລີ່ມຕົ້ນຈາກຈຸດນ້ອຍໆ ແລະ ພັດທະນາໄປພ້ອມກັບການວັດແທກຜົນ.

ຈຸດສຳຄັນ ຫຼື ແກນຫຼັກ ຂອງການເຮັດ Routing ແມ່ນກົນໄກໃນການຈັດປະເພດ Query.

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

ຕົວຈັດປະເພດ (Classifier) ຈະຖືກນຳໄປໃຊ້ງານໂດຍອີງຕາມວິທີການ: ຖ້າເປັນ Rule-based ໃຫ້ໃຊ້ເງື່ອນໄຂ, ຖ້າເປັນ Embedding-based ໃຫ້ໃຊ້ Vector ຕົວແທນຂອງໝວດໝູ່, ແລະ ຖ້າເປັນ Meta-LLM ໃຫ້ໃຊ້ Prompt ໃນການຕັດສິນ. ບໍ່ວ່າຈະໃຊ້ວິທີໃດ, ບໍ່ຈຳເປັນຕ້ອງເຮັດໃຫ້ສົມບູນແບບຕັ້ງແຕ່ຕົ້ນ, ສາມາດເລີ່ມຕົ້ນດ້ວຍໝວດໝູ່ຫຼັກໆກ່ອນໄດ້.

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

ເຖິງແມ່ນວ່າຈະກຳນົດໝວດໝູ່ໄດ້ແລ້ວ, ແຕ່ການເລືອກຮູບແບບ (Model) ປາຍທາງນັ້ນ ບໍ່ພຽງແຕ່ຕ້ອງພິຈາລະນາເຖິງ "ຄວາມສາມາດ" ເທົ່ານັ້ນ ແຕ່ຍັງຕ້ອງເລືອກຈາກ "ຂະໜາດຂອງການນຳເຂົ້າ ແລະ ສົ່ງອອກ (Input/Output size)" ອີກດ້ວຍ.

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

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

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

ໃນການນຳໃຊ້ງານຈິງ, ບັນຫາຕ່າງໆເຊັ່ນ: ແບບຈຳລອງປາຍທາງສົ່ງຄ່າຜິດພາດ (Error), ໝົດເວລາ (Timeout), ຫຼື ຖືກຈຳກັດອັດຕາການໃຊ້ງານ (Rate limit) ແມ່ນສິ່ງທີ່ຈະຕ້ອງເກີດຂຶ້ນຢ່າງແນ່ນອນ. ການກຽມພ້ອມຮັບມືກັບສິ່ງເຫຼົ່ານີ້ຄືການໃຊ້ Fallback ແລະ Circuit Breaker.

Fallback: ຖ້າແບບຈຳລອງທາງເລືອກທຳອິດລົ້ມເຫຼວ, ໃຫ້ປ່ຽນໄປໃຊ້ແບບຈຳລອງສຳຮອງໂດຍອັດຕະໂນມັດ. ຄວນກຽມເສັ້ນທາງສຳຮອງໄວ້ເປັນຂັ້ນຕອນ ເຊັ່ນ: ຖ້າແບບຈຳລອງປະສິດທິພາບສູງໃຊ້ງານບໍ່ໄດ້ ກໍໃຫ້ປ່ຽນໄປໃຊ້ແບບຈຳລອງລະບົບອື່ນ, ຫຼື ຖ້າ API ພາຍນອກບໍ່ສາມາດເຊື່ອມຕໍ່ໄດ້ ກໍໃຫ້ປ່ຽນໄປໃຊ້ແບບຈຳລອງພາຍໃນ (Local model).

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

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

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

ຄວາມຜິດພາດທີ່ພົບເລື້ອຍຄື ການເຊື່ອໝັ້ນໃນການຕັດສິນໃຈຂອງ Routing ຫຼາຍເກີນໄປ.

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

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

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

ອີກຈຸດໜຶ່ງທີ່ມັກຖືກມອງຂ້າມຄື ເລື່ອງຄວາມປອດໄພ. ຊັ້ນການຈັດເສັ້ນທາງ (Routing layer) ເປັນດ່ານກວດທີ່ທຸກອິນພຸດຕ້ອງຜ່ານ, ເຊິ່ງເປັນໂອກາດດີທີ່ຈະໃຊ້ເປັນຈຸດປ້ອງກັນການໂຈມຕີ.

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

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

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