BPE Tokenizer (Byte-Pair Encoding Tokenizer) คืออัลกอริทึมที่แบ่งข้อความออกเป็นหน่วยย่อย (subword) ตามรูปแบบที่พบบ่อย แล้วแปลงเป็นลำดับ token ที่ LLM สามารถประมวลผลได้ BPE ทำงานได้อย่างมีประสิทธิภาพสูงสำหรับภาษาอังกฤษ แต่สำหรับภาษาที่มีทรัพยากรน้อย (low-resource languages) อย่างภาษาลาว ภาษาพม่า และภาษาเขมร กลับบริโภค token มากกว่าภาษาอังกฤษหลายเท่าสำหรับเนื้อหาที่มีความหมายเดียวกัน ความไม่มีประสิทธิภาพนี้ไม่เพียงแต่ทำให้ต้นทุน API เพิ่มสูงขึ้น แต่ยังส่งผลโดยตรงต่อการ timeout และความล่าช้าในการประมวลผลของระบบแปลภาษาอีกด้วย

บทความนี้มุ่งเป้าไปที่วิศวกรและ Tech Lead ที่ดูแลระบบแปลภาษาหลายภาษาด้วย LLM โดยจะอธิบายกลไกที่ทำให้ BPE Tokenizer ทำงานได้ไม่มีประสิทธิภาพกับภาษาที่มีทรัพยากรน้อย พร้อมแบ่งปันแนวทางการออกแบบเชิงปฏิบัติ โดยอ้างอิงจากกรณี timeout ของการแปลภาษาลาวที่บริษัทของเราพบเจอจริง

ประสิทธิภาพของ BPE Tokenizer ขึ้นอยู่กับความถี่ในการปรากฏของภาษานั้นในคอร์ปัสที่ใช้ฝึกอย่างมาก และสำหรับภาษาที่มีทรัพยากรน้อย การแตกย่อยระดับ byte จะเกิดขึ้นบ่อยครั้งจนทำให้จำนวน token พองตัวขึ้น ในส่วนนี้จะเจาะลึกถึงหลักการทำงานของ BPE และกลไกที่ก่อให้เกิดความเหลื่อมล้ำระหว่างภาษา

BPE (Byte-Pair Encoding) คืออัลกอริทึมที่พัฒนาขึ้นเพื่อการบีบอัดข้อมูลในตอนแรก แล้วนำมาประยุกต์ใช้กับการประมวลผลภาษาธรรมชาติ (NLP) การทำงานดำเนินไปตามขั้นตอนดังนี้

1. แตกข้อความออกเป็นลำดับ byte ของ UTF-8 (หรือสตริงอักขระ)
2. ค้นหาคู่ byte ที่อยู่ติดกันและพบบ่อยที่สุดในคอร์ปัสทั้งหมด
3. รวมคู่นั้นเข้าเป็น token ใหม่หนึ่งตัว
4. ทำซ้ำขั้นตอนที่ 2-3 จนกว่าขนาด vocabulary จะถึงขีดจำกัดที่กำหนด (เช่น 100,000 token)

สำหรับภาษาอังกฤษ รูปแบบที่พบบ่อยอย่าง "the", "ing", "tion" จะถูกรวมเข้าด้วยกันในระยะแรก ทำให้สามารถแทน 1 คำด้วย 1-2 token ได้ ภาษาญี่ปุ่นทั้งฮิรางานะและคาตากานะก็มีการรวมในระดับหนึ่งเช่นกัน อย่างไรก็ตาม ภาษาที่ปรากฏในคอร์ปัสฝึกน้อยจะมีโอกาสถูกรวมน้อย ทำให้ลำดับ byte ของ UTF-8 ยังคงอยู่ในสภาพเดิม

ตัวอย่างเช่น คำว่า "the" ในภาษาอังกฤษใช้เพียง 1 token แต่คำฟังก์ชัน (function word) ที่มีความหมายเทียบเท่าในภาษาลาวอาจถูกแตกย่อยออกเป็น 6-9 token ความแตกต่างนี้ส่งผลโดยตรงต่อเวลาในการประมวลผลและต้นทุน

เบื้องหลังประสิทธิภาพ token ที่ต่ำของภาษาลาวมีปัจจัยเชิงโครงสร้าง 4 ประการที่ซ้อนทับกันอยู่

1. 1 ตัวอักษรใช้ 3 byte ใน UTF-8

อักษรลาวอยู่ใน Unicode ช่วง U+0E80–U+0EFF และใช้ 3 byte ต่อ 1 ตัวอักษรใน UTF-8 หากการรวม BPE ยังไม่ก้าวหน้าเพียงพอ 1 ตัวอักษรอาจถูกแตกย่อยออกเป็นสูงสุด 3 token ซึ่งตรงข้ามกับอักขระ ASCII ของภาษาอังกฤษที่ใช้เพียง 1 byte และไม่เกิน 1 token

2. ความถี่ในการปรากฏในคอร์ปัสฝึกต่ำมาก

Vocabulary ของ BPE ถูกสร้างขึ้นจากคอร์ปัสขนาดใหญ่อย่าง Common Crawl โดยเรียงตามความถี่ ปริมาณข้อความภาษาลาวบนอินเทอร์เน็ตน้อยกว่าภาษาอังกฤษอย่างมาก จึงมีความเป็นไปได้สูงที่แทบจะไม่มี token ที่ถูกรวมไว้เฉพาะสำหรับภาษาลาว ส่งผลให้การแตกย่อยแบบ fallback ระดับ byte กลายเป็นเรื่องปกติ

3. ไม่มีการใช้ช่องว่างแบ่งคำ

ภาษาลาวเช่นเดียวกับภาษาไทย ไม่ใช้ช่องว่างในการแบ่งคำภายในประโยค เนื่องจาก pre-tokenization (การประมวลผลเบื้องต้น) ของ BPE ใช้ช่องว่างเป็นจุดแบ่ง ประโยคภาษาลาวทั้งประโยคจึงถูกจัดการเป็น pre-token ขนาดใหญ่เพียงตัวเดียว ทำให้การแบ่งอย่างมีประสิทธิภาพเป็นเรื่องยาก

4. byte เพิ่มเติมจากวรรณยุกต์และอักขระรวม

ภาษาลาวมีสระและวรรณยุกต์ที่วางอยู่รอบพยัญชนะทั้งด้านบน ด้านล่าง ด้านหน้า และด้านหลัง โดยแต่ละตัวมี Unicode code point เป็นของตัวเอง การแทน "1 พยางค์" จึงต้องใช้หลาย code point (= หลายตัวอักษรขนาด 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 มากกว่าภาษาอังกฤษ 4-9 เท่าสำหรับภาษาที่มีทรัพยากรน้อย เช่น อักษรพม่าและภาษาเบงกาลี
• Petrov et al. (2023) "Language Model Tokenizers Introduce Unfairness Between Languages" (NeurIPS 2023): ยืนยันกรณีที่ tokenizer fertility (token/คำ) ของภาษาที่มีทรัพยากรน้อยสูงกว่าภาษาอังกฤษถึง 15 เท่าขึ้นไป โดยภาษาในเอเชียตะวันออกเฉียงใต้และแอฟริกาได้รับผลกระทบมากที่สุด
• โครงการ Typhoon: รายงานว่า GPT-2 tokenizer บริโภค token สำหรับภาษาไทย (ซึ่งมีระบบอักษรในตระกูลเดียวกับภาษาลาว) มากกว่าภาษาอังกฤษประมาณ 3.8 เท่า

แม้ว่า benchmark สาธารณะสำหรับภาษาลาวโดยเฉพาะจะมีอยู่อย่างจำกัด แต่เมื่อพิจารณาถึงเงื่อนไขที่เสียเปรียบกว่าภาษาไทย (ข้อมูลฝึกที่น้อยกว่า) มีความเป็นไปได้สูงที่อัตราส่วนการบริโภค token จะสูงกว่าภาษาไทยด้วย

เมื่อแปล บทความ SEO จำนวน 28 ส่วนเป็นภาษาลาวผ่าน CMS หลายภาษาของบริษัท การประมวลผลล้มเหลวเนื่องจากเกินเวลา timeout ที่กำหนดไว้ 480 วินาที บทความเดียวกันที่แปลเป็นภาษาอังกฤษและภาษาไทยสำเร็จโดยไม่มีปัญหา แต่กลับไม่สามารถเสร็จสิ้นภายในเวลาที่กำหนดเมื่อแปลเป็นภาษาลาวเท่านั้น

Translation API ของบริษัทดำเนินงานด้วยโครงสร้างดังต่อไปนี้

Translation API（maxDuration: 480 วินาที）
├── แปล meta ข้อมูล（title, description, keywords）: เรียกใช้งานแบบ parallel 3 ครั้ง
├── แปลหัวข้อ: ประมวลผลหัวข้อทั้งหมดใน 1 batch
└── แปลเนื้อหา: 5 ส่วน × 6 batch → ประมวลผลแบบ sequential

พารามิเตอร์สำหรับการแปลเนื้อหามีดังนี้

สำหรับภาษาอังกฤษและภาษาไทย แต่ละ batch เสร็จสิ้นภายใน 30–60 วินาที และรวม 6 batch ก็ยังมีเวลาเหลือเพียงพอภายใน 480 วินาที อย่างไรก็ตาม สำหรับภาษาลาว จำนวน output token ที่เพิ่มขึ้นอย่างมากทำให้เวลาประมวลผลต่อ batch เพิ่มขึ้นอย่างมีนัยสำคัญ และการสะสมของ 6 batch ทำให้เกินขีดจำกัดที่กำหนด

นอกจากนี้ บริษัทได้นำ pivot translation แบบ ja→en→lo มาใช้แล้ว (การแปลสองขั้นตอนโดยใช้ภาษาอังกฤษเป็นภาษากลาง) เพื่อปรับปรุงคุณภาพสำหรับ low-resource language ขั้นตอนแรกของ pivot (ja→en) เสร็จสิ้นอย่างรวดเร็ว แต่ขั้นตอนที่สอง (en→lo) ได้รับผลกระทบจากความไม่มีประสิทธิภาพของ token

การเกิน timeout ไม่ได้มีสาเหตุเดียว แต่เกิดจากการรวมกันของ 3 ปัจจัยดังต่อไปนี้

ปัจจัยที่ 1: การขยายตัวของ output token

เนื่องจาก BPE tokenizer ไม่มีคลังคำศัพท์ที่เพียงพอสำหรับภาษาลาว จึงสร้าง token จำนวนมากกว่าภาษาอังกฤษอย่างมีนัยสำคัญแม้จะมีเนื้อหาความหมายเดียวกัน เนื่องจากจำนวน token ที่สร้างขึ้นมีความสัมพันธ์โดยตรงกับเวลาประมวลผล นี่จึงเป็นปัจจัยหลักที่ทำให้เกิดความล่าช้า

ปัจจัยที่ 2: ประสิทธิภาพการสร้างของโมเดล

นอกเหนือจากจำนวน token ที่เพิ่มขึ้น ประสิทธิภาพการประมวลผลภายในของโมเดลในการสร้าง low-resource language ก็อาจมีผลกระทบด้วย อย่างไรก็ตาม ปัจจัยนี้ยากที่จะแยกออกจากการเพิ่มขึ้นของจำนวน token โดยอิสระ และจำเป็นต้องตรวจสอบด้วย log จากการวัดจริง

ปัจจัยที่ 3: การสะสมความล่าช้าจากการออกแบบ sequential batch

ในการประมวลผลแบบ sequential ทีละ 5 ส่วน overhead คงที่ต่างๆ เช่น การเริ่มต้น request, การโหลด context และ network round-trip จะสะสมรวม 6 ครั้ง ยิ่งภาษาที่ใช้เวลาประมวลผลต่อ batch นานขึ้น จุดอ่อนเชิงโครงสร้างนี้ก็ยิ่งปรากฏชัดเจนมากขึ้น

ในกรณีของบริษัท การรวมกันของ 3 ปัจจัยเหล่านี้ทำให้การประมวลผลที่ใช้เวลารวม 3–4 นาทีสำหรับภาษาอังกฤษ พองตัวเป็นกว่า 8 นาทีสำหรับภาษาลาว

แก่นของมาตรการแก้ไขคือ 2 แนวทาง ได้แก่ "การลดจำนวนครั้งในการเรียก API" และ "การออกแบบพารามิเตอร์แบบ dynamic ตามลักษณะเฉพาะของภาษา" ต่อไปนี้จะอธิบายตามลำดับความสำคัญ ตั้งแต่มาตรการที่เห็นผลทันทีไปจนถึงการปรับปรุงระยะกลางและระยะยาว

วิธีที่มีความคุ้มค่าสูงสุดคือการขยายขนาด batch สำหรับ low-resource language เพื่อลดจำนวนครั้งในการเรียก API

การเปลี่ยนแปลงนี้จะลดจำนวนครั้งในการเรียก API สำหรับบทความ 28 ส่วนจาก 6 ครั้งเหลือ 2 ครั้ง การสร้างแบบต่อเนื่องภายใน 1 request มี overhead น้อยกว่าการแบ่งเป็นหลาย request จึงคาดว่าจะช่วยลดเวลาประมวลผลรวมได้

อย่างไรก็ตาม เนื่องจากจำนวน output token ต่อ request จะเพิ่มขึ้น จึงต้องระวังขีดจำกัดของ maxTokens ด้วย สำหรับ low-resource language แนวทางที่เป็นจริงคือการกำหนด maxTokens ให้คงที่ที่ค่าสูงสุด (16,000) และหาค่าที่เหมาะสมที่สุดจากข้อมูลการวัดจริง

ระบบ timeout ของระบบแปลภาษาประกอบด้วยหลายชั้น และจำเป็นต้องออกแบบทุกชั้นให้สอดคล้องกัน

การขยาย maxDuration เป็นมาตรการชั่วคราว และมีความเสี่ยงที่ปัญหาจะเกิดซ้ำหากจำนวน section เพิ่มขึ้นในอนาคต โดยหลักการแล้ว การปรับปรุงการออกแบบ batch (การลดจำนวนครั้งที่เรียกใช้) คือมาตรการหลัก และการขยาย timeout ควรถูกจัดวางเป็นมาตรการเสริมความปลอดภัยที่สนับสนุนมาตรการหลักนั้น

การขยาย batch size และการปรับ timeout สามารถแก้ปัญหาเฉพาะหน้าได้ แต่ควรพิจารณามาตรการปรับปรุงระยะกลางถึงระยะยาวด้วย เพื่อรองรับบทความขนาดยาวที่มี section ถึง 40–50 section หรือกรณีที่มีการเพิ่มภาษาที่มีประสิทธิภาพ token ต่ำกว่านี้

Streaming Translation（สำหรับการปรับปรุง UX）

การใช้ InvokeModelWithResponseStreamCommand ของ AWS Bedrock ช่วยให้รับข้อความที่กำลังสร้างเป็น chunk ได้ระหว่างการประมวลผล อย่างไรก็ตาม บน Vercel เวลาที่ผ่านไประหว่าง streaming ก็นับรวมใน maxDuration ด้วย จึงไม่ใช่วิธีหลีกเลี่ยง timeout การใช้งานที่เหมาะสมคือการนำไปใช้เพื่อแสดง progress feedback ให้ client (เช่น การแสดงผล "กำลังแปล: เสร็จแล้ว 12/28 section") และปรับปรุงประสบการณ์ผู้ใช้เท่านั้น

การแปลทุก section พร้อมกันในครั้งเดียว

แนวทางการแปล 28 section ด้วยการเรียก API เพียงครั้งเดียว โดยใช้ delimiter คั่น section (===SECTION_N===) และ parse ผลลัพธ์ที่ได้ วิธีนี้ช่วยลด fixed overhead ได้สูงสุดเนื่องจากเรียก API เพียงครั้งเดียว แต่มีความเสี่ยงที่ผลลัพธ์จะถูกตัดที่ขีดจำกัด maxTokens (16,000) จึงจำเป็นต้องออกแบบ fallback สำหรับการตรวจจับผลลัพธ์ที่ถูกตัด → แปล section ที่เหลือใน batch ที่สอง

ปัญหาที่คล้ายกับภาษาลาวมีแนวโน้มสูงที่จะเกิดขึ้นกับภาษาพม่า ภาษาเขมร และภาษาทิเบตด้วย ภาษาไทยอยู่ในระดับความเสี่ยงปานกลาง แต่ยังไม่พบปัญหาที่ชัดเจนภายใต้การตั้งค่า timeout ปัจจุบัน

เมื่อวางแผนการรองรับหลายภาษา ควรออกแบบระบบให้สามารถเพิ่มภาษาเป้าหมายลงใน set LOW_RESOURCE_LANGS เพียงครั้งเดียวเพื่อให้มาตรการต่างๆ ถูกนำไปใช้พร้อมกันทั้งหมด ก่อนเพิ่มภาษาใหม่ ควรวัดปริมาณการใช้ token จริงด้วยข้อความทดสอบ และตรวจสอบค่าที่เหมาะสมของ batch size และ maxTokens ล่วงหน้า

ไม่สามารถแก้ปัญหาได้อย่างสมบูรณ์ มีอัลกอริทึมอื่นนอกจาก BPE เช่น SentencePiece（Unigram）และ WordPiece แต่ทุกอัลกอริทึมล้วนขึ้นอยู่กับการกระจายความถี่ของ corpus ที่ใช้ฝึก หากข้อความในภาษา low-resource มีน้อยในข้อมูลการเรียนรู้ ความลำเอียงของ vocabulary ก็จะเกิดขึ้นไม่ว่าจะใช้อัลกอริทึมใด

วิธีที่คาดว่าจะช่วยปรับปรุงได้คือการเพิ่ม corpus ของภาษาเป้าหมายและฝึก tokenizer ใหม่เป็นของตัวเอง (วิธีที่ Typhoon ใช้สำหรับภาษาไทย) แต่วิธีนี้ต้องอาศัยการดำเนินการจากฝั่ง LLM provider และไม่ใช่สิ่งที่ผู้ใช้ API สามารถควบคุมได้โดยตรง สำหรับผู้ใช้ API แนวทางที่เป็นจริงคือการออกแบบโดยคำนึงถึงความแตกต่างของประสิทธิภาพ token เป็นเงื่อนไขตั้งต้น (การปรับ batch และการออกแบบ timeout)

ประสิทธิภาพ token ในฝั่ง input จะดีขึ้น ในการแปลตรงจาก ja→lo นั้น token จะถูกใช้ไปกับการอ่าน source text ภาษาญี่ปุ่นด้วย หากใช้การแปลแบบ pivot จาก ja→en→lo input ของขั้นตอนที่ 2 จะเป็นภาษาอังกฤษ (ภาษาที่มีประสิทธิภาพ token ดีที่สุด) ทำให้ input token ลดลง

อย่างไรก็ตาม ความไม่มีประสิทธิภาพของ token ในฝั่ง output (การสร้างข้อความภาษาลาว) ไม่เปลี่ยนแปลงแม้จะใช้การแปลแบบ pivot เนื่องจากจำนวน output token เป็นสาเหตุหลักของเวลาในการประมวลผล การแปลแบบ pivot เพียงอย่างเดียวจึงไม่ใช่การแก้ปัญหา timeout อย่างถึงรากถึงโคน ในแง่คุณภาพ การแปลแบบ pivot มีข้อดีมาก (การแปลผ่านภาษาอังกฤษมีแนวโน้มให้คุณภาพที่สม่ำเสมอกว่าการแปลตรงไปยังภาษา low-resource) ดังนั้นแนวทางที่แนะนำคือการใช้ pivot เพื่อสมดุลระหว่างคุณภาพและความเร็ว พร้อมควบคุมเวลาในการประมวลผลด้วยการออกแบบ batch

เพิ่มขึ้น LLM API ส่วนใหญ่คิดค่าบริการแบบ pay-as-you-go ตามจำนวน input/output token ดังนั้นหากภาษาที่ใช้มีจำนวน token แตกต่างกันแม้จะมีเนื้อหาความหมายเดียวกัน ค่าใช้จ่ายก็จะแปรผันตามไปด้วย

Petrov et al. (2023) ได้ชี้ให้เห็นปัญหานี้ในฐานะ "ความไม่เท่าเทียมระหว่างภาษา" ตัวอย่างเช่น ผู้ใช้ภาษาลาวจะต้องจ่ายค่าบริการมากกว่าผู้ใช้ภาษาอังกฤษหลายเท่าเพื่อประมวลผลข้อมูลในปริมาณเท่ากัน

มาตรการที่ผู้ใช้ API สามารถดำเนินการได้มีจำกัด แต่สิ่งต่อไปนี้ควรพิจารณา

• แปลเฉพาะส่วนที่จำเป็น: แทนที่จะแปลทุก section พร้อมกัน ให้แปลเฉพาะ section ที่มีการเปลี่ยนแปลงแบบ differential translation
• การใช้ cache: หลีกเลี่ยงการแปลข้อความเดิมซ้ำ
• Pivot translation: ลดต้นทุน input โดยจำกัด input token ให้อยู่ในภาษาอังกฤษ

BPE tokenizer มีประสิทธิภาพสูงสำหรับภาษาที่มีทรัพยากรมาก (high-resource language) โดยเฉพาะภาษาอังกฤษ ในขณะที่ภาษาที่มีทรัพยากรน้อย (low-resource language) อย่างภาษาลาวนั้นหลีกเลี่ยงความไม่มีประสิทธิภาพเชิงโครงสร้างไม่ได้ ความไม่มีประสิทธิภาพนี้จะปรากฏในระบบแปลภาษาของ LLM ในรูปแบบของ timeout, ค่าใช้จ่ายที่เพิ่มขึ้น และความล่าช้าในการประมวลผล

ประเด็นสำคัญของมาตรการมี 3 ข้อ

• การออกแบบ batch แบบ dynamic ตามภาษา: สำหรับภาษาที่มีทรัพยากรน้อย ให้ขยาย batch size เพื่อลดจำนวนการเรียก API
• การออกแบบ timeout แบบหลายชั้น: ปรับ timeout ของทั้ง Vercel Function และ Bedrock HTTP ให้สอดคล้องกัน
• การปรับแต่งโดยอิงข้อมูลจากการวัดจริง: วัดปริมาณการใช้ token และเวลาในการประมวลผลแยกตามภาษา และปรับ parameter อย่างต่อเนื่อง

เมื่อดำเนินการรองรับหลายภาษา แนะนำให้ตรวจสอบประสิทธิภาพ token ของภาษาเป้าหมายล่วงหน้า และผนวกขั้นตอนการเพิ่มภาษาเหล่านั้นลงใน parameter set สำหรับภาษาที่มีทรัพยากรน้อย (LOW_RESOURCE_LANGS) เข้าไว้ในกระบวนการดำเนินงาน