BPE Tokenizer (Byte-Pair Encoding Tokenizer) ແມ່ນ Algorithm ທີ່ຕັດຂໍ້ຄວາມອອກເປັນໜ່ວຍຍ່ອຍລະດັບ Subword ໂດຍອີງໃສ່ຮູບແບບທີ່ປາກົດເລື້ອຍໆ ແລ້ວແປງເປັນລຳດັບ Token ທີ່ LLM ສາມາດປະມວນຜົນໄດ້. ໃນຂະນະທີ່ BPE ເຮັດວຽກໄດ້ຢ່າງມີປະສິດທິພາບສູງສຳລັບພາສາອັງກິດ, ແຕ່ສຳລັບເນື້ອຫາດຽວກັນໃນພາສາທີ່ມີຊັບພະຍາກອນໜ້ອຍ ເຊັ່ນ: ພາສາລາວ, ພາສາມຽນມາ ແລະ ພາສາຂະແມ, ມັນຈະໃຊ້ Token ຫຼາຍກວ່າຫຼາຍເທົ່າ. ຄວາມບໍ່ມີປະສິດທິພາບນີ້ບໍ່ພຽງແຕ່ເຮັດໃຫ້ຄ່າໃຊ້ຈ່າຍ API ເພີ່ມຂຶ້ນເທົ່ານັ້ນ, ແຕ່ຍັງສົ່ງຂໍ້ມູນຕໍ່ໃຫ້ເກີດການ Timeout ຂອງລະບົບແປພາສາ ແລະ ຄວາມລ່າຊ້າໃນການປະມວນຜົນໂດຍກົງອີກດ້ວຍ.

ບົດຄວາມນີ້ມຸ້ງໄປຫາວິສະວະກອນ ແລະ Tech Lead ທີ່ດຳເນີນງານລະບົບແປພາສາຫຼາຍພາສາໂດຍໃຊ້ LLM. ບົດຄວາມອະທິບາຍກົນໄກທີ່ BPE Tokenizer ເກີດຄວາມບໍ່ມີປະສິດທິພາບສຳລັບພາສາທີ່ມີຊັບພະຍາກອນໜ້ອຍ ພ້ອມທັງແບ່ງປັນມາດຕະການຮັບມືດ້ານການອອກແບບທີ່ໃຊ້ໄດ້ຈິງ ໂດຍອີງໃສ່ເຫດການ Timeout ໃນການແປພາສາລາວທີ່ທີມງານຂອງພວກເຮົາໄດ້ພົບໃນຄວາມເປັນຈິງ.

ປະສິດທິພາບຂອງ BPE Tokenizer ຂຶ້ນກັບຄວາມຖີ່ຂອງການປາກົດຂອງພາສານັ້ນໃນ Training Corpus ເປັນຢ່າງຫຼວງຫຼາຍ; ໃນພາສາທີ່ມີຊັບພະຍາກອນໜ້ອຍ, ການແຍກລະດັບ Byte ຈະເກີດຂຶ້ນເລື້ອຍໆ ສົ່ງຜົນໃຫ້ຈຳນວນ Token ພອງໂຕຂຶ້ນຢ່າງຫຼວງຫຼາຍ. ພາກນີ້ຈະເຈາະລຶກເຂົ້າໄປໃນຫຼັກການເຮັດວຽກຂອງ BPE ແລະ ກົນໄກທີ່ກໍ່ໃຫ້ເກີດຄວາມແຕກຕ່າງລະຫວ່າງພາສາຕ່າງໆ.

BPE (Byte-Pair Encoding) ແມ່ນ algorithm ທີ່ພັດທະນາຂຶ້ນໃນເບື້ອງຕົ້ນເພື່ອການບີບອັດຂໍ້ມູນ ແລ້ວຈຶ່ງຖືກດັດແປງມາໃຊ້ໃນການປະມວນຜົນພາສາທຳມະຊາດ (natural language processing). ມັນດຳເນີນງານຜ່ານຂັ້ນຕອນດັ່ງຕໍ່ໄປນີ້:

1. ແຍກຂໍ້ຄວາມອອກເປັນລຳດັບ byte ແບບ UTF-8 (ຫຼື string ຕົວອັກສອນ)
2. ຄົ້ນຫາຄູ່ byte ທີ່ຢູ່ຕິດກັນທີ່ປາກົດຂຶ້ນເລື້ອຍທີ່ສຸດໃນທົ່ວ corpus ທັງໝົດ
3. ລວມ ຫຼື Merge ຄູ່ນັ້ນໃຫ້ກາຍເປັນ token ໃໝ່ອັນດຽວ
4. ເຮັດຊ້ຳຂັ້ນຕອນທີ 2–3 ຈົນກວ່າຂະໜາດ vocabulary ຈະເຖິງຂີດຈຳກັດສູງສຸດ (ເຊັ່ນ: 100,000 tokens)

ໃນພາສາອັງກິດ, ຮູບແບບທີ່ປາກົດເລື້ອຍໆ ເຊັ່ນ "the," "ing," ແລະ "tion" ຈະຖືກ ລວມ ຫຼື Merge ໃນຂັ້ນຕອນຕົ້ນໆ ເຮັດໃຫ້ຄຳໜຶ່ງຄຳສາມາດສະແດງດ້ວຍ 1–2 tokens. ອັກສອນ hiragana ແລະ katakana ຂອງພາສາຍີ່ປຸ່ນກໍ່ຜ່ານການ ລວມ ຫຼື Merge ໃນລະດັບໜຶ່ງເຊັ່ນກັນ. ຢ່າງໃດກໍ່ຕາມ, ພາສາທີ່ປາກົດໜ້ອຍໃນ corpus ສຳລັບການຝຶກສອນ ຈະມີໂອກາດ ລວມ ຫຼື Merge ໜ້ອຍ ແລະລຳດັບ byte ແບບ UTF-8 ຂອງພາສານັ້ນກໍ່ຈະຄົງຢູ່ຕາມເດີມ.

ຕົວຢ່າງເຊັ່ນ: ຄຳວ່າ "the" ໃນພາສາອັງກິດໃຊ້ພຽງ 1 token, ໃນຂະນະທີ່ຄຳຊ່ວຍທີ່ມີຄວາມໝາຍທຽບເທົ່າໃນພາສາລາວ ອາດຖືກແຍກອອກເປັນ 6–9 tokens. ຄວາມແຕກຕ່າງນີ້ສົ່ງຜົນໂດຍກົງຕໍ່ຄວາມແຕກຕ່າງດ້ານເວລາໃນການປະມວນຜົນ ແລະຄ່າໃຊ້ຈ່າຍ.

ປະສິດທິພາບ token ທີ່ຕ່ຳຂອງພາສາລາວ ມາຈາກປັດໄຈໂຄງສ້າງທີ່ຊ້ອນທັບກັນ 4 ຢ່າງ.

1. 3 bytes ຕໍ່ຕົວອັກສອນໃນ UTF-8

ອັກສອນລາວຢູ່ໃນຕຳແໜ່ງ Unicode U+0E80–U+0EFF ໂດຍໃຊ້ 3 bytes ຕໍ່ຕົວອັກສອນໃນ UTF-8. ຫາກການ ລວມ ຫຼື Merge ຂອງ BPE ຍັງບໍ່ທັນດຳເນີນໄປ, ຕົວອັກສອນໜຶ່ງຕົວສາມາດຖືກແຍກອອກໄດ້ເຖິງ 3 tokens. ສິ່ງນີ້ແຕກຕ່າງຢ່າງຊັດເຈນຈາກຕົວອັກສອນ ASCII ຂອງພາສາອັງກິດ ທີ່ຕ້ອງການພຽງ 1 byte ຫຼືໜ້ອຍກວ່າຕໍ່ token.

2. ຄວາມຖີ່ຕ່ຳຢ່າງຫຼວງຫຼາຍໃນ corpus ສຳລັບການຝຶກສອນ

Vocabulary ຂອງ BPE ຖືກສ້າງຂຶ້ນຈາກ corpus ຂະໜາດໃຫຍ່ ເຊັ່ນ Common Crawl ໂດຍຈັດລຳດັບຕາມຄວາມຖີ່. ປະລິມານຂໍ້ຄວາມພາສາລາວທີ່ມີຢູ່ໃນອິນເຕີເນັດນ້ອຍກວ່າພາສາອັງກິດຫຼາຍລ້ານເທົ່າ ໝາຍຄວາມວ່າ tokens ທີ່ຖືກ ລວມ ຫຼື Merge ໂດຍສະເພາະສຳລັບພາສາລາວ ອາດຈະມີໜ້ອຍຫຼືບໍ່ມີເລີຍ. ດ້ວຍເຫດນີ້ ການແຍກຍ່ອຍລົງໄປຮອດລະດັບ byte ຈຶ່ງກາຍເປັນມາດຕະຖານ.

3. ບໍ່ມີຂອບເຂດຄຳທີ່ໝາຍດ້ວຍຊ່ອງຫວ່າງ

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

4. Bytes ເພີ່ມເຕີມຈາກວັນນະຍຸດ ແລະຕົວອັກສອນປະສົມ

ພາສາລາວມີສະຫຼະ ແລະວັນນະຍຸດທີ່ວາງໄວ້ດ້ານເທິງ, ດ້ານລຸ່ມ, ດ້ານໜ້າ ແລະດ້ານຫຼັງຂອງພະຍັນຊະນະ ໂດຍແຕ່ລະຕົວມີ Unicode code point ເປັນຂອງຕົວເອງ. ການສະແດງພະຍາງໜຶ່ງພະຍາງຕ້ອງໃຊ້ຫຼາຍ code points (ຄືຫຼາຍຕົວອັກສອນ 3-byte) ເຮັດໃຫ້ຈຳນວນ token ເພີ່ມທະວີຂຶ້ນເລື້ອຍໆ ຍິ່ງຂຶ້ນໄປອີກ.

ຕໍ່ໄປນີ້ແມ່ນສະຫຼຸບການຄາດຄະເນການໃຊ້ Token ເມື່ອສະແດງເນື້ອຫາດຽວກັນໃນແຕ່ລະພາສາ.

ການສຶກສາຕໍ່ໄປນີ້ໃຫ້ການສະໜັບສະໜູນທາງວິຊາການໂດຍການວັດແທກຄວາມບໍ່ສະເໝີກັນຂອງປະສິດທິພາບ Token ລະຫວ່າງພາສາຕ່າງໆ:

• Ahia et al. (2023) "Do All Languages Cost the Same? Tokenization in the Era of Commercial Language Models" (EMNLP 2023): ລາຍງານວ່າການໃຊ້ Token ຂອງພາສາທີ່ມີຊັບພະຍາກອນໜ້ອຍ ລວມທັງອັກສອນ Burmese ແລະ Bengali ສູງກວ່າພາສາອັງກິດ 4–9 ເທົ່າ
• Petrov et al. (2023) "Language Model Tokenizers Introduce Unfairness Between Languages" (NeurIPS 2023): ຢືນຢັນກໍລະນີທີ່ tokenizer fertility (tokens/word) ຂອງພາສາທີ່ມີຊັບພະຍາກອນໜ້ອຍສູງເຖິງຫຼາຍກວ່າ 15 ເທົ່າຂອງພາສາອັງກິດ. ພາສາຈາກອາຊີຕາເວັນອອກສ່ຽງໃຕ້ ແລະ ອາຟຣິກາໄດ້ຮັບຜົນກະທົບຫຼາຍທີ່ສຸດ
• Typhoon project: ລາຍງານວ່າ GPT-2 tokenizer ໃຊ້ Token ສຳລັບພາສາໄທ (ເຊິ່ງໃຊ້ລະບົບອັກສອນທີ່ກ່ຽວຂ້ອງກັບພາສາລາວ) ຫຼາຍກວ່າພາສາອັງກິດປະມານ 3.8 ເທົ່າ

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

ໃນເວລາທີ່ແປບົດຄວາມ SEO 28 ພາກສ່ວນເປັນພາສາລາວໂດຍໃຊ້ CMS ຫຼາຍພາສາຂອງພວກເຮົາ, ການປະມວນຜົນລົ້ມເຫຼວຫຼັງຈາກເກີນ timeout 480 ວິນາທີ. ບົດຄວາມດຽວກັນສຳເລັດໂດຍບໍ່ມີບັນຫາໃດໃນພາສາອັງກິດ ແລະ ພາສາໄທ, ແຕ່ບໍ່ສາມາດສຳເລັດພາຍໃນຂອບເຂດເວລາໄດ້ໃນພາສາລາວເທົ່ານັ້ນ.

API ການແປພາສາຂອງເຮົາດຳເນີນງານດ້ວຍການຕັ້ງຄ່າດັ່ງຕໍ່ໄປນີ້.

Translation API (maxDuration: 480 seconds)
├── Metadata translation (title, description, keywords): 3 parallel calls
├── Heading translation: all headings processed in a single batch
└── Body translation: 5 sections × 6 batches → sequential processing

ພາລາມິເຕີການແປເນື້ອຫາມີດັ່ງຕໍ່ໄປນີ້.

ໃນພາສາອັງກິດ ແລະ ໄທ, ແຕ່ລະ batch ສຳເລັດພາຍໃນ 30–60 ວິນາທີ, ຊຶ່ງຍັງມີໄລຍະຫ່າງພຽງພໍພາຍໃນຂອບເຂດ 480 ວິນາທີ ແມ່ນແຕ່ຜ່ານທັງ 6 batch. ແຕ່ໃນພາສາລາວ, ການພອງຕົວຂອງ output token ໄດ້ເພີ່ມເວລາປະມວນຜົນຕໍ່ batch ຢ່າງຫຼວງຫຼາຍ, ສົ່ງຜົນໃຫ້ຍອດລວມສະສົມຂ້າມ 6 batch ເກີນຂອບເຂດທີ່ກຳນົດ.

ໂປດສັງເກດວ່າ ໃນຖານະມາດຕະການປັບປຸງຄຸນນະພາບສຳລັບພາສາທີ່ມີຊັບພະຍາກອນໜ້ອຍ, ການແປຜ່ານພາສາກາງ ja→en→lo (ການແປສອງຂັ້ນຕອນໂດຍໃຊ້ພາສາອັງກິດເປັນພາສາກາງ) ໄດ້ຖືກນຳໃຊ້ແລ້ວ. ຂັ້ນຕອນທຳອິດຂອງການແປຜ່ານພາສາກາງ (ja→en) ສຳເລັດໄດ້ໄວ, ແຕ່ຂັ້ນຕອນທີສອງ (en→lo) ໄດ້ຮັບຜົນກະທົບຈາກຄວາມບໍ່ມີປະສິດທິພາບຂອງ token.

ການ timeout ບໍ່ໄດ້ເກີດຈາກປັດໄຈດຽວ, ແຕ່ເກີດຈາກການລວມກັນຂອງສາມປັດໄຈດັ່ງຕໍ່ໄປນີ້.

ປັດໄຈທີ 1: ການພອງຕົວຂອງ output token

ເນື່ອງຈາກ BPE tokenizer ບໍ່ມີ vocabulary ທີ່ພຽງພໍສຳລັບພາສາລາວ, ມັນຈຶ່ງສ້າງ token ຫຼາຍກວ່າພາສາອັງກິດຢ່າງຫຼວງຫຼາຍເພື່ອສະແດງເນື້ອຫາດຽວກັນ. ເນື່ອງຈາກຈຳນວນ token ທີ່ສ້າງຂຶ້ນມີຄວາມສຳພັນໂດຍກົງກັບເວລາປະມວນຜົນ, ນີ້ຈຶ່ງເປັນແຫຼ່ງຫຼັກຂອງຄວາມລ່າຊ້າ.

ປັດໄຈທີ 2: ປະສິດທິພາບການສ້າງຂອງ Model

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

ປັດໄຈທີ 3: ຄວາມລ່າຊ້າສະສົມຈາກການອອກແບບ batch ແບບຕໍ່ເນື່ອງ

ໃນການປະມວນຜົນຕໍ່ເນື່ອງທີລະ 5 section, ຄ່າໃຊ້ຈ່າຍ overhead ຄົງທີ່ເຊັ່ນ: ການເລີ່ມຕົ້ນ request, ການໂຫຼດ context, ແລະ network round trip ຈະສະສົມຂ້າມທັງ 6 batch. ຍິ່ງເວລາປະມວນຜົນຕໍ່ batch ຂອງພາສາໃດໜຶ່ງຍາວນານເທົ່າໃດ, ຈຸດອ່ອນທາງໂຄງສ້າງນີ້ກໍຈະຍິ່ງສະແດງອອກຊັດເຈນຂຶ້ນເທົ່ານັ້ນ.

ໃນກໍລະນີຂອງເຮົາ, ການລວມກັນຂອງສາມປັດໄຈເຫຼົ່ານີ້ເຮັດໃຫ້ຂະບວນການທີ່ໃຊ້ເວລາລວມ 3–4 ນາທີໃນພາສາອັງກິດ ພອງຕົວຂຶ້ນເປັນກວ່າ 8 ນາທີໃນພາສາລາວ.

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

ແນວທາງທີ່ຄຸ້ມຄ່າທີ່ສຸດແມ່ນການເພີ່ມຂະໜາດ batch ສຳລັບພາສາທີ່ມີຊັບພະຍາກອນໜ້ອຍ ແລະ ຫຼຸດຈຳນວນການເອີ້ນໃຊ້ API.

ການປ່ຽນແປງນີ້ຫຼຸດຈຳນວນການເອີ້ນໃຊ້ API ສຳລັບບົດຄວາມທີ່ມີ 28 ພາກສ່ວນຈາກ 6 ຄັ້ງ ເຫຼືອ 2 ຄັ້ງ. ການສ້າງຂໍ້ຄວາມຢ່າງຕໍ່ເນື່ອງພາຍໃນ request ດຽວນັ້ນມີ overhead ໜ້ອຍກວ່າການແຍກໃສ່ຫຼາຍ request ດັ່ງນັ້ນຈຶ່ງຄາດວ່າເວລາປະມວນຜົນລວມຈະຫຼຸດລົງໄດ້.

ຢ່າງໃດກໍຕາມ ເນື່ອງຈາກຈຳນວນ output token ຕໍ່ request ເພີ່ມຂຶ້ນ ຈຶ່ງຕ້ອງໃສ່ໃຈກ່ຽວກັບເພດານຂອງ maxTokens ດ້ວຍ. ສຳລັບພາສາທີ່ມີຊັບພະຍາກອນໜ້ອຍ ແນວທາງທີ່ໃຊ້ໄດ້ຈິງແມ່ນການຄົງຄ່າ maxTokens ໄວ້ທີ່ຂີດຈຳກັດສູງສຸດ (16,000) ແລ້ວຫາຄ່າທີ່ດີທີ່ສຸດໂດຍອ້າງອີງຈາກຂໍ້ມູນທີ່ວັດແທກໄດ້ຈິງ.

ລະບົບ Timeout ຂອງລະບົບແປພາສາປະກອບດ້ວຍຫຼາຍຊັ້ນ ແລະ ທຸກຊັ້ນຕ້ອງໄດ້ຮັບການອອກແບບໃຫ້ສອດຄ່ອງກັນ.

ການຂະຫຍາຍ maxDuration ເປັນມາດຕະການຊົ່ວຄາວ ແລະ ມີຄວາມສ່ຽງທີ່ຈະເກີດຂຶ້ນຄືນໄດ້ ຫາກຈຳນວນ Section ເພີ່ມທະວີຂຶ້ນເລື້ອຍໆໃນອະນາຄົດ. ໂດຍພື້ນຖານແລ້ວ ການປັບປຸງການອອກແບບ Batch (ການຫຼຸດຈຳນວນການເອີ້ນໃຊ້ API) ຖືເປັນມາດຕະການຫຼັກ ແລະ ເໝາະສົມທີ່ຈະກຳນົດໃຫ້ການຂະຫຍາຍ Timeout ເປັນ Safety Net ເສີມ.

ການຂະຫຍາຍຂະໜາດ Batch ແລະ ການປັບ Timeout ຈະຊ່ວຍແກ້ໄຂບັນຫາທີ່ເກີດຂຶ້ນທັນທີ ແຕ່ຄວນພິຈາລະນາການປັບປຸງໃນໄລຍະກາງຫາໄລຍະຍາວດ້ວຍ ເພື່ອຮອງຮັບບົດຄວາມທີ່ຍາວຫຼາຍເຖິງ 40–50 Section ຫຼື ການເພີ່ມພາສາທີ່ມີປະສິດທິພາບ Token ຕ່ຳກວ່ານີ້.

Streaming Translation (ໃນຖານະການປັບປຸງ UX)

ການໃຊ້ InvokeModelWithResponseStreamCommand ຂອງ AWS Bedrock ຊ່ວຍໃຫ້ຮັບຂໍ້ຄວາມເປັນ Chunk ໄດ້ໃນຂະນະທີ່ກຳລັງສ້າງຢູ່. ແຕ່ໃນ Vercel ນັ້ນ ເວລາທີ່ຜ່ານໄປລະຫວ່າງ Streaming ກໍ່ຖືກນັບລວມໃນ maxDuration ເຊັ່ນກັນ ດັ່ງນັ້ນວິທີນີ້ຈຶ່ງບໍ່ສາມາດໃຊ້ເປັນທາງແກ້ Timeout ໄດ້. ບົດບາດທີ່ແທ້ຈິງຂອງມັນຄືການເປັນວິທີສະໜອງ Feedback ຄວາມຄືບໜ້າໃຫ້ Client ໂດຍສະເພາະ (ເຊັ່ນ: ສະແດງ "ກຳລັງແປ: ສຳເລັດ 12/28 Section ແລ້ວ") ແລະ ການປັບປຸງປະສົບການຜູ້ໃຊ້.

ການແປທຸກ Section ໃນ Batch ດຽວ

ວິທີການທີ່ແປທັງ 28 Section ໃນການເອີ້ນໃຊ້ API ຄັ້ງດຽວ ໂດຍໃຊ້ຕົວຄັ່ນ Section (===SECTION_N===) ແລະ ການ Parse Output. ເນື່ອງຈາກມີການເອີ້ນໃຊ້ API ພຽງຄັ້ງດຽວ Overhead ຄົງທີ່ຈຶ່ງຫຼຸດລົງ ແຕ່ມີຄວາມສ່ຽງທີ່ Output ຈະຖືກຕັດທີ່ຂີດຈຳກັດ maxTokens (16,000). ຈຳເປັນຕ້ອງມີການອອກແບບ Fallback ທີ່ກວດຈັບ Output ທີ່ຖືກຕັດ ແລ້ວແປ Section ທີ່ຍັງເຫຼືອໃນ Batch ທີສອງ.

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

ໃນການວາງແຜນຂະຫຍາຍລະບົບຫຼາຍພາສາ, ເປັນສິ່ງທີ່ຄວນອອກແບບລະບົບໃຫ້ສາມາດນຳໃຊ້ມາດຕະການຮັບມືທັງໝົດໄດ້ທັນທີ ພຽງແຕ່ເພີ່ມພາສາເປົ້າໝາຍເຂົ້າໃນຊຸດ LOW_RESOURCE_LANGS. ກ່ອນທີ່ຈະເພີ່ມພາສາໃໝ່, ຄວນວັດແທກການໃຊ້ token ດ້ວຍຂໍ້ຄວາມທົດສອບຕາມຄວາມເປັນຈິງ ແລະ ກວດສອບຄ່າທີ່ເໝາະສົມຂອງ batch size ແລະ maxTokens ລ່ວງໜ້າ.

ບັນຫານີ້ຈະບໍ່ໄດ້ຮັບການແກ້ໄຂຢ່າງສົມບູນ. ມີ algorithm ອື່ນນອກຈາກ BPE ເຊັ່ນ: SentencePiece (Unigram) ແລະ WordPiece, ແຕ່ທຸກ algorithm ລ້ວນມີການອ້າງອີງໃສ່ການແຈກຢາຍຄວາມຖີ່ຂອງ corpus ທີ່ໃຊ້ຝຶກສອນຄືກັນທັງໝົດ. ຫາກພາສາທີ່ມີຊັບພະຍາກອນໜ້ອຍຖືກນຳສະເໜີໃນຂໍ້ມູນຝຶກສອນໃນລະດັບຕ່ຳ, ຄວາມລຳອຽງດ້ານ vocabulary ກໍ່ຈະເກີດຂຶ້ນໂດຍບໍ່ຂຶ້ນກັບ algorithm ທີ່ໃຊ້.

ວິທີການທີ່ສະແດງໃຫ້ເຫັນວ່າມີທ່າແຮງໃນການປັບປຸງ ຄືການຝຶກ tokenizer ແບບກຳນົດເອງໃໝ່ດ້ວຍ corpus ເພີ່ມເຕີມສຳລັບພາສາເປົ້າໝາຍ (ດັ່ງທີ່ Typhoon ໄດ້ນຳໃຊ້ສຳລັບພາສາໄທ), ແຕ່ສິ່ງນີ້ຕ້ອງການການດຳເນີນການຈາກຝ່າຍຜູ້ໃຫ້ບໍລິການ LLM ແລະ ບໍ່ແມ່ນດ້ານທີ່ຜູ້ໃຊ້ API ສາມາດຄວບຄຸມໄດ້ໂດຍກົງ. ສຳລັບຜູ້ໃຊ້ API, ວິທີການທີ່ເປັນໄປໄດ້ຈິງ ຄືການອອກແບບໂດຍຄຳນຶງເຖິງຄວາມແຕກຕ່າງດ້ານປະສິດທິພາບ token ເປັນສິ່ງທີ່ກຳນົດໄວ້ລ່ວງໜ້າ — ຜ່ານການປັບ batch ແລະ ການອອກແບບ timeout.

ປະສິດທິພາບຂອງ Token ໃນດ້ານ Input ຈະດີຂຶ້ນ. ໃນການແປໂດຍກົງແບບ ja→lo ນັ້ນ, Token ຈະຖືກໃຊ້ໄປໃນການອ່ານຂໍ້ຄວາມຕົ້ນສະບັບພາສາຍີ່ປຸ່ນ. ສ່ວນການແປຜ່ານພາສາກາງແບບ ja→en→lo ນັ້ນ, Input ຂອງຂັ້ນຕອນທີສອງຈະກາຍເປັນພາສາອັງກິດ (ເຊິ່ງເປັນພາສາທີ່ມີປະສິດທິພາບດ້ານ Token ສູງທີ່ສຸດ), ຈຶ່ງຊ່ວຍຫຼຸດການໃຊ້ Input Token ລົງໄດ້.

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

ຄ່າໃຊ້ຈ່າຍກໍ່ເພີ່ມທະວີຂຶ້ນເລື້ອຍໆ. LLM API ຫຼາຍຕົວໃຊ້ລາຄາແບບ Pay-as-you-go ໂດຍອ້າງອີງຕາມຈຳນວນ Input ແລະ Output Token, ໝາຍຄວາມວ່າຖ້າເນື້ອຫາດຽວກັນຕ້ອງການ Token ຈຳນວນຕ່າງກັນຂຶ້ນຢູ່ກັບພາສາ, ຄ່າໃຊ້ຈ່າຍກໍ່ຈະເພີ່ມຂຶ້ນຕາມສັດສ່ວນ.

Petrov et al. (2023) ລະບຸວ່ານີ້ຄືບັນຫາ "cross-linguistic inequity" ຫຼື ຄວາມບໍ່ສະເໝີພາບລະຫວ່າງພາສາ. ຕົວຢ່າງ, ຜູ້ໃຊ້ທີ່ເວົ້າພາສາລາວຕ້ອງຈ່າຍຫຼາຍກວ່າຜູ້ໃຊ້ທີ່ເວົ້າພາສາອັງກິດຫຼາຍເທົ່າ ເພື່ອປະມວນຜົນຂໍ້ມູນໃນປະລິມານດຽວກັນ.

ທາງເລືອກທີ່ມີໃຫ້ຜູ້ໃຊ້ API ນັ້ນມີຈຳກັດ, ແຕ່ຕໍ່ໄປນີ້ແມ່ນສິ່ງທີ່ຄວນພິຈາລະນາ:

• ແປສະເພາະສ່ວນທີ່ຈຳເປັນ: ແທນທີ່ຈະແປທຸກສ່ວນພ້ອມກັນ, ໃຫ້ດຳເນີນການແປສ່ວນທີ່ມີການປ່ຽນແປງເທົ່ານັ້ນ.
• ນຳໃຊ້ Caching: ຫຼີກລ່ຽງການແປຂໍ້ຄວາມດຽວກັນຊ້ຳໆ.
• ການແປຜ່ານພາສາກາງ: ຫຼຸດຄ່າ Input ໂດຍຮັກສາ Input Token ໃຫ້ຢູ່ໃນພາສາອັງກິດ.

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

ມີສາມມາດຕະການຕອບໂຕ້ທີ່ສຳຄັນ:

• ການອອກແບບ batch ແບບ Dynamic ຕາມພາສາ: ເພີ່ມຂະໜາດ batch ສຳລັບພາສາທີ່ມີຊັບພະຍາກອນໜ້ອຍ ເພື່ອຫຼຸດຈຳນວນການເອີ້ນໃຊ້ API.
• ການອອກແບບ timeout ແບບຫຼາຍຊັ້ນ: ປັບຕັ້ງຄ່າ timeout ໃຫ້ສອດຄ່ອງກັນທັງໃນ Vercel Functions ແລະ Bedrock HTTP.
• ການປັບແຕ່ງໂດຍອີງໃສ່ຂໍ້ມູນຈາກການທົດລອງຕົວຈິງ: ວັດແທກການໃຊ້ token ແລະ ເວລາໃນການປະມວນຜົນຕາມແຕ່ລະພາສາ, ແລ້ວປັບປຸງ parameter ຢ່າງຕໍ່ເນື່ອງ.

ໃນການຂະຫຍາຍການຮອງຮັບຫຼາຍພາສາ, ແນະນຳໃຫ້ກວດສອບປະສິດທິພາບ token ຂອງພາສາເປົ້າໝາຍລ່ວງໜ້າ ແລະ ລວມເອົາຂະບວນການ ຫຼື Pipeline ດ້ານການດຳເນີນງານສຳລັບການເພີ່ມພາສາເຫຼົ່ານັ້ນເຂົ້າໃນຊຸດ parameter ສຳລັບພາສາທີ່ມີຊັບພະຍາກອນໜ້ອຍ (LOW_RESOURCE_LANGS).