AI ภาษาจีน ทำไมความแม่นยำถึงตก และโมเดล 4 ชั้นที่ใช้แยกสาเหตุ

ปัญหาที่คนค้นหาด้วยคำว่า “AI ภาษาจีน” ส่วนใหญ่ไม่ใช่เรื่อง “โมเดลไม่รู้จักภาษาจีน” เพราะ generative AI รายหลักล้วนมีข้อมูลฝึกภาษาจีนอยู่มหาศาล แต่ที่ความแม่นยำยังตกเมื่อใช้งานจริงหน้างาน เป็นเพราะภาษาจีนพังในจุดที่ต่างจากภาษาญี่ปุ่นหรือภาษาอังกฤษ นั่นคือ การใช้อักษรตัวย่อกับตัวเต็มสลับกัน อักษรจีนที่ใช้รหัสเดียวกันแต่รูปร่างต่างกัน การที่ไม่มีช่องว่างจึงไม่มีใครกำหนดขอบเขตของคำ และการที่กระบวนการแปลงเป็นโทเคนสร้าง “คำ” ที่ไม่มีอยู่จริงขึ้นมาเอง ทั้งหมดนี้ไม่หายไปเพียงเพราะเปลี่ยนโมเดล

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

เมื่อมีคนบอกว่า generative AI ภาษาจีนแม่นยำน้อยลง จริงๆ แล้วเกิดอะไรขึ้น

อาการที่ถูกหยิบยกขึ้นมาหน้างาน มักตกอยู่ในกลุ่มใดกลุ่มหนึ่งต่อไปนี้

• ให้แปลคู่มือเครื่องจักรจากจีน แล้วชิ้นส่วนเดียวกันกลับได้คำแปลคนละคำในแต่ละย่อหน้า
• เอาสเปกจากไต้หวันกับสเปกจากจีนแผ่นดินใหญ่ไว้โฟลเดอร์เดียวกันแล้วค้นหา ปรากฏว่าเจอแค่ฝั่งเดียว
• เอาแบบฟอร์มภาษาจีนเข้า OCR ตัวเลขถูกหมดแต่ชื่อสินค้ากลายเป็นอักษรตัวอื่น
• ให้สร้างข้อความตอบกลับซัพพลายเออร์ ความหมายสื่อได้แต่มีศัพท์ที่บริษัทปลายทางไม่ได้ใช้ปนเข้ามา
• ลองป้อนสเปกทางเทคนิคยาวๆ ทั้งฉบับ กลับชนขีดจำกัดเร็วกว่าที่คาดไว้มาก

ทั้งหมดนี้มักถูกสรุปรวมด้วยคำเดียวว่า “ความแม่นยำไม่ดี” แต่ชั้นของสาเหตุนั้นคนละเรื่องกัน ข้อแรกกับข้อที่สี่เป็นปัญหาของการตัดคำและศัพท์เฉพาะ ข้อที่สองกับข้อที่สามเป็นปัญหาของตัวอักษร ส่วนข้อที่ห้าเป็นปัญหาของโทเคน ถ้ายังปนชั้นกันอยู่แล้วคิดว่า “เปลี่ยนไปใช้โมเดลที่ดีกว่าก็หาย” ผลที่ได้คือค่ารายเดือนเพิ่มขึ้นแต่อาการยังอยู่เหมือนเดิม

ภาษาไทยและภาษาเวียดนามก็อธิบายด้วยโครงสร้างเดียวกันนี้ แต่ละภาษาพังคนละจุด ทว่าลำดับของการแยกสาเหตุนั้นเหมือนกัน อ่านประกอบได้ที่ โมเดล 4 ชั้นของ generative AI ภาษาไทย และ โมเดล 4 ชั้นของ generative AI ภาษาเวียดนาม

อนึ่ง บทความนี้จำกัดขอบเขตไว้ที่ “ทำไมภาษาจีนจึงจัดการยากใน generative AI” ส่วนภาพรวมของการทำงานแปลให้เป็นอัตโนมัติทั้งกระบวนการ อยู่ในบทความ การทำงานแปลให้เป็นอัตโนมัติในองค์กร

ทำไมโรงงานญี่ปุ่นในไทยต้องสนใจ AI ภาษาจีน

คำตอบที่ว่า “บริษัทเราไม่มีฐานในจีน เลยไม่เกี่ยว” ใช้ไม่ได้อีกต่อไปในประเทศไทย และมีเหตุผลอยู่ 3 ข้อ

ภาษาจีนไหลเข้ามาทางห่วงโซ่อุปทาน

ตามประกาศของสำนักงานคณะกรรมการส่งเสริมการลงทุน (BOI) ห่วงโซ่อุปทาน EV ของไทยมีการแสดงเจตจำนงลงทุนเกิน 4.1 พันล้านดอลลาร์ ณ ปี 2026 โดยมีโครงการที่เดินอยู่รวม 198 โครงการ ครอบคลุมทั้ง BEV ไฮบริด แบตเตอรี่ ชิ้นส่วน และโครงสร้างพื้นฐานสถานีชาร์จ ในจำนวนนี้ เฉพาะการผลิต BEV มี 18 โครงการ มูลค่า 1.18 พันล้านดอลลาร์ รวมถึงผู้ผลิตจีนอย่าง BYD, SAIC Motor, Aion, Changan Auto และ Omoda and Jaecoo โดยวางแผนกำลังการผลิตไว้เกิน 370,000 คันต่อปี นอกจากนี้ ก่อนหน้านั้นในเดือนมีนาคม 2025 คณะกรรมการนโยบายเพิ่มขีดความสามารถในการแข่งขันของประเทศได้อนุมัติการลงทุนของ Sunwoda Electronic จากจีน มูลค่ากว่า 1 พันล้านดอลลาร์ ในการผลิตเซลล์แบตเตอรี่

ฝั่งซัพพลายเออร์ก็เคลื่อนไปในทิศทางเดียวกัน บทวิเคราะห์ของ THAIBIZ ระบุว่าการเข้ามาตั้งกิจการในไทยของซัพพลายเออร์จีนมีจำนวนถึง 183 ราย ณ เดือนมิถุนายน 2025 โดยกลุ่มแปรรูป (ภาคการผลิต) มีมากที่สุดที่ 125 ราย และเฉพาะช่วง 2 ปีครึ่งตั้งแต่ปี 2023 ถึงมิถุนายน 2025 มีรายใหม่เข้ามา 90 ราย ซึ่งมองกันว่านโยบายส่งเสริม EV ของไทย (EV3.0 และ EV3.5) เป็นปัจจัยเร่ง

พูดง่ายๆ คือ ต่อให้บริษัทของคุณไม่ได้ตัดสินใจใช้ภาษาจีนเอง ความน่าจะเป็นที่บริษัทจีนจะเข้ามาเป็นซัพพลายเออร์ระดับที่สองหรือสามก็สูงขึ้นเรื่อยๆ และสถานการณ์ที่แบบงาน การแจ้งเปลี่ยนแปลง หรือรายงานปัญหาคุณภาพในรูปข้อมูลปฐมภูมิมาเป็นภาษาจีน จะเกิดถี่ขึ้น

คู่มือและสเปกของเครื่องจักรจากจีน

อีกด้านหนึ่งคือฝั่งเครื่องจักร โรงงานในไทยที่ติดตั้งอุปกรณ์จากจีนในกลุ่มเครื่องฉีดพลาสติก เครื่องตรวจสอบ ไลน์ลำเลียง หุ่นยนต์อุตสาหกรรม และอุปกรณ์ไฟฟ้ากำลัง ไม่ใช่เรื่องแปลกอีกต่อไป จุดที่เป็นปัญหาคือ ถึงจะมีคู่มือฉบับภาษาอังกฤษ แต่เนื้อหาก็ไม่ตรงกับฉบับภาษาจีน เพราะการแก้ไขปรับปรุงจะเข้าที่ฉบับภาษาจีนก่อน แล้วฉบับภาษาอังกฤษตามไม่ทัน ตารางรหัสข้อผิดพลาดและรายการพารามิเตอร์ก็แนบมาเป็นภาษาจีนอยู่อย่างนั้น คำตอบ FAQ จากผู้รับเหมาซ่อมบำรุงก็มาทางแชตภาษาจีน ผลลัพธ์คือเกิดสภาพที่ว่าข้อมูลที่ถูกต้องมีอยู่แค่ฝั่งภาษาจีนเท่านั้น

การสื่อสารกับพนักงานและผู้รับจ้างช่วงที่พูดภาษาจีน

ข้อที่สามคือคน รูปแบบที่วิศวกรซึ่งพูดภาษาจีนประจำอยู่ที่ฐานในไทย หรือการส่งบางกระบวนการให้ผู้รับจ้างช่วงสัญชาติจีน กำลังเพิ่มขึ้น ถึงงานประจำวันจะเดินด้วยภาษาอังกฤษหรือภาษาไทยได้ แต่พอถึงจังหวะที่ต้องเคาะรายละเอียดทางเทคนิค ภาษาจีนย่อมเร็วกว่า ผลคือบันทึกการประชุม คำสั่งงาน และรายละเอียดปลีกย่อยของเกณฑ์การตรวจสอบ จะถูกเก็บไว้เป็นภาษาจีน เมื่ออีกไม่กี่ปีข้างหน้ามีการตรวจสอบย้อนกลับ คำถามที่มีน้ำหนักคือ ในองค์กรยังมีใครอ่านบันทึกภาษาจีนเหล่านั้นได้หรือไม่

ทั้ง 3 ข้อนี้ ไม่ใช่ “ผลจากการเลือกภาษาจีนเป็นภาษาทำงาน” แต่เป็น “ผลจากการที่มันไหลเข้ามาเอง” ด้วยเหตุนี้เอง จึงคุ้มค่าที่จะคิดในทิศทางของการทำให้ผู้รับผิดชอบที่มีอยู่เดิมจัดการข้อมูลปฐมภูมิภาษาจีนได้ มากกว่าทิศทางของการเพิ่มบุคลากรที่เชี่ยวชาญภาษาจีนโดยเฉพาะ

การประมวลผลภาษาจีนแบ่งเป็น 4 ชั้น — ชั้นอักษร ชั้นคำ ชั้นโทเคน ชั้นความหมาย

กว่าข้อความภาษาจีนจะไปถึงโมเดล มันต้องผ่าน 4 ชั้นที่มีคุณสมบัติต่างกันโดยสิ้นเชิง และแต่ละชั้นก็พังคนละแบบ แก้คนละวิธี

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

ชั้นที่ 1 ชั้นอักษร — อักษรจีนตัวย่อ ตัวเต็ม AI พังตรงนี้ก่อนเป็นอันดับแรก

อักษรตัวย่อกับตัวเต็มไม่ได้จับคู่กันแบบหนึ่งต่อหนึ่ง

สมมติฐานที่ว่า “ตัวย่อกับตัวเต็มแค่แปลงก็จบ” ใช้ไม่ได้ในงานจริง เพราะระหว่างกระบวนการรวบให้เป็นอักษรตัวย่อ มีหลายกรณีที่อักษรตัวเต็มหลายตัวถูกยุบรวมเป็นตัวย่อตัวเดียว

เวลาแปลงจากตัวย่อกลับไปเป็นตัวเต็ม ต้องอาศัยบริบทตัดสินว่าจะเลือกตัวเต็มตัวไหน ถ้าจัดการตรงนี้ด้วยการแทนที่อักษรแบบตรงไปตรงมา จะเกิดความผิดพลาดแบบที่ “理发” กลายเป็น “理發” ทั้งที่ที่ถูกต้องคือ “理髮” ส่วนทิศทางกลับกัน (จากตัวเต็มไปตัวย่อ) โดยพื้นฐานเป็นการจับคู่แบบหลายต่อหนึ่ง จึงปลอดภัยกว่าโดยเปรียบเทียบ แต่ถึงอย่างนั้นก็ยังมีข้อยกเว้นในชื่อเฉพาะและชื่อบุคคล

สรุปคือ ถ้าไม่กำหนดไว้ก่อนว่าเอกสารฉบับจริงภายในองค์กรจะใช้อักษรแบบไหน ทั้งการค้นหาและการรวมยอดจะแตกออกเป็นสองทาง

รหัส Unicode เดียวกันแต่รูปอักษรต่างกัน

อีกเรื่องที่คนซึ่งใช้ภาษาญี่ปุ่นมักมองข้ามคือ อักษรจีนรวมของ Unicode (CJK Unified Ideographs) อักษรจีนที่ใช้ในจีนแผ่นดินใหญ่ ไต้หวัน ฮ่องกง ญี่ปุ่น และเกาหลี ถึงรูปร่างจะต่างกัน แต่โดยหลักการก็ถือเป็น “อักษรตัวเดียวกัน” และถูกรวมไว้ที่โค้ดพอยต์เดียว (ยกเว้นกรณีที่ในชุดอักขระต้นทางของแต่ละประเทศได้เข้ารหัสแยกกันไว้อยู่แล้ว จะไม่ถูกรวม) ส่วนจะแสดงผลออกมาเป็นรูปไหนนั้น ขึ้นกับฟอนต์และแท็กภาษา

ตัวอย่างเช่น 骨 直 次 令 者 จะมีรูปร่างต่างกันเมื่อแสดงด้วยฟอนต์ภาษาจีนกับฟอนต์ภาษาญี่ปุ่น เนื่องจากลำดับไบต์เหมือนกัน การค้นหาจึงยังเจอ แต่หน้าตาของสิ่งพิมพ์และไฟล์ PDF จะเปลี่ยนไป และเมื่อมองจากฝั่ง OCR เรื่องนี้ร้ายแรง เพราะการนำเอกสารที่พิมพ์ด้วยรูปอักษรของฟอนต์ภาษาจีนไปให้โมเดลที่ฝึกด้วยรูปอักษรฝั่งญี่ปุ่นอ่าน จะทำให้อัตราการรู้จำลดลง

ยิ่งไปกว่านั้น อักษรที่มีตัวเลือกรูปแปร (IVS) กำกับ ถ้าไม่มีฟอนต์รองรับก็แทบแยกไม่ออกด้วยตาเปล่า ทว่าลำดับไบต์ต่างจากกรณีที่มีเฉพาะอักษรฐาน หากคอลัมน์ชื่อสินค้าใน Excel ที่ได้รับจากคู่ค้ามีอักษรที่มี IVS ปนอยู่ การจับคู่แบบตรงกันทุกตัวอักษรจะล้มเหลวอย่างเงียบๆ

จีนแผ่นดินใหญ่ ฮ่องกง ไต้หวัน และสิงคโปร์ ใช้ศัพท์ต่างกัน

ไม่ใช่แค่รูปอักษร คำศัพท์ก็แยกสายด้วย ต่อไปนี้คือคำที่พบบ่อยในภาคการผลิต

สิงคโปร์ใช้อักษรตัวย่อในแง่รูปอักษร แต่มีคำศัพท์เฉพาะของตัวเอง ส่วนฮ่องกงใช้อักษรตัวเต็ม ขณะที่คำศัพท์บางครั้งมีคำสายจีนแผ่นดินใหญ่ปนเข้ามา

ความหมายในทางปฏิบัติคือ เวลาค้นหาสเปกของ “การเชื่อมด้วยเลเซอร์” เอกสารของซัพพลายเออร์สายจีนแผ่นดินใหญ่จะเขียนว่า 激光焊接 ส่วนเอกสารสายไต้หวันจะเขียนว่า 雷射焊接 ถ้าค้นด้วยคำใดคำหนึ่งโดยไม่มีพจนานุกรมคำพ้องความหมาย อีกฝั่งจะไม่มีวันโผล่ขึ้นมา นี่คือปัญหาที่อยู่ตรงรอยต่อระหว่างชั้นที่ 1 กับชั้นที่ 2 และเปลี่ยนโมเดลก็ไม่หาย

เครื่องหมายวรรคตอนและสัญลักษณ์

ภาษาจีนใช้เครื่องหมายวรรคตอนแบบเต็มความกว้าง (，。；：) และใช้จุดคั่นรายการ (、) สำหรับการเรียงคำขนานกัน หากมีคอมมาหรือจุดแบบครึ่งความกว้างปนเข้ามาตรงนี้ ทั้งการตัดคำและการแบ่งประโยคจะรวนพร้อมกัน และเวลานำเอกสารภาษาจีนเข้าจาก Excel หรืออีเมล การมีสัญลักษณ์ครึ่งความกว้างปนมาเป็นเรื่องที่เกิดขึ้นทุกวัน การทำให้ชั้นอักษรเป็นมาตรฐานเดียว จึงต้องรวมการจัดสัญลักษณ์เหล่านี้ให้เป็นแบบเดียวกันด้วย

ชั้นที่ 2 ชั้นคำ — ภาษาที่ไม่มีช่องว่าง และไม่มีใครกำหนดว่าจะตัดคำตรงไหน

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

ความกำกวมไม่ใช่เรื่องบังเอิญ แต่เป็นเรื่องเชิงโครงสร้าง

ตัวอย่างที่มักถูกยกมาคือ 部分居民生活水平 ซึ่งโดยเจตนาเดิมต้องตัดเป็น 部分 / 居民 / 生活 / 水平 (ระดับความเป็นอยู่ของประชาชนบางส่วน) แต่ในสายอักษรนี้กลับมีคำที่ถูกต้องในตัวเองอย่าง 分居 (แยกกันอยู่) และ 民生 (ความเป็นอยู่ของประชาชน) ซ่อนอยู่พร้อมกัน นั่นแปลว่า ลำพังการเปิดพจนานุกรมอย่างเดียว จะได้วิธีตัดหลายแบบที่เป็นไปได้พร้อมกัน

ความกำกวมประเภทนี้เป็นที่รู้กันมานานในงานวิจัยการประมวลผลภาษาจีน และแบ่งใหญ่ๆ เป็นแบบไขว้ ซึ่งตัวเลือกของการตัดคำซ้อนทับกัน กับแบบผสม ซึ่งจะรวมเป็นคำเดียวหรือแยกก็อ่านได้ความทั้งคู่ ตัวอย่างตัวแทนของแบบหลังคือ 才能 ถ้าอ่านเป็นคำเดียวแปลว่า “ความสามารถ” ถ้าแยกเป็นสองคำเป็น 才 / 能 จะแปลว่า “ทำอย่างนั้นแล้วจึงจะทำได้” ว่าแบบไหนถูก ตัดสินได้จากบริบทหน้าหลังเท่านั้น

เครื่องมือวิเคราะห์หน่วยคำทำอะไรอยู่

เครื่องมือตัดคำภาษาจีนอย่าง jieba ตอบโจทย์ความกำกวมนี้ด้วยการผสมการเทียบพจนานุกรมกับแบบจำลองเชิงสถิติ โดยคร่าวๆ คือ ขั้นแรกใช้พจนานุกรมคำนำหน้า (prefix dictionary) เก็บคำที่เป็นไปได้ทั้งหมดจากสายอักษรมาสร้างเป็นกราฟระบุทิศทางแบบไม่มีวงวน (DAG) แล้วใช้การโปรแกรมเชิงพลวัตเลือกเส้นทางการตัดคำที่มีความน่าจะเป็นสูงสุด ส่วนคำที่ไม่มีในพจนานุกรม (คำที่ไม่ได้ลงทะเบียน) จะใช้แบบจำลองมาร์คอฟซ่อนเร้น (HMM) ร่วมกับอัลกอริทึม Viterbi ประมาณบทบาทของอักษรในแต่ละตำแหน่งเพื่อตัดออกมาเป็นคำ

ตรงนี้คือหัวใจในทางปฏิบัติ การที่ การจัดการคำที่ไม่ได้ลงทะเบียนถูกปล่อยให้ขึ้นกับสถิติ หมายความว่า รหัสรุ่น ชื่อชิ้นส่วน ชื่อเครื่องจักร และคำย่อภายในองค์กรของคุณ ถ้าปล่อยไว้เฉยๆ จะถูกตัดผิดด้วยความน่าจะเป็นสูง สายอักษรอย่าง MX-3200型伺服压机 ไม่มีอะไรรับประกันว่าจะคงอยู่เป็นหน่วยที่มีความหมาย หากไม่ใส่ไว้ในพจนานุกรมผู้ใช้

jieba มีกลไกให้โหลดพจนานุกรมผู้ใช้ โดยลงทะเบียนคำ ชนิดของคำ และความถี่ได้ เครื่องมืออื่นอย่าง pkuseg, HanLP และ LTP ก็มีกลไกทำนองเดียวกัน สิ่งที่ต้องทำนั้นง่ายมาก คือทำรายการชื่อเฉพาะที่บริษัทใช้แล้วลงทะเบียนไว้ เท่านั้นเอง ส่วนที่ยากไม่ใช่เทคโนโลยี แต่คือการตัดสินใจว่าใครจะเป็นคนทำรายการนั้น และใครจะเป็นคนอัปเดตต่อไปเรื่อยๆ

ถ้าชั้นคำพัง จะเกิดผลลูกโซ่อะไรบ้าง

วิธีตัดคำคือฐานรากของทั้งการค้นหา การแบ่งชิ้นข้อความ การจับคู่คำสำคัญ การจัดหมวด และการรวมยอด ถ้าตรงนี้พัง ทุกอย่างที่วางอยู่ข้างบนจะเคลื่อนตามหมด กรณีที่สร้าง RAG จะได้รับผลกระทบหนักเป็นพิเศษ เพราะถ้าขอบเขตของชิ้นข้อความตกลงไปกลางคำ คำนั้นจะไม่ถูกดึงขึ้นมาในการค้นหาอีกเลย เรื่องการสร้าง RAG โดยตรงอยู่ใน ค่าใช้จ่ายและวิธีเริ่มสร้าง RAG

ชั้นที่ 3 ชั้นโทเคน — เกิดอะไรขึ้นตอนแปลงภาษาจีนเป็นโทเคน

ทำไมอักษรจีน 1 ตัวจึงไม่จำเป็นต้องเท่ากับ 1 โทเคน

LLM รายหลักในปัจจุบันใช้โทเคไนเซอร์ตระกูล BPE (Byte Pair Encoding) ระดับไบต์ ซึ่ง BPE จะทยอยรวมคู่ของลำดับไบต์ที่อยู่ติดกันบ่อยๆ ในข้อมูลฝึก แล้วตรึงกฎการรวมนั้นเอาไว้

ตรงนี้เองที่เงื่อนไขเฉพาะของภาษาจีนเข้ามามีผล ใน UTF-8 อักษรจีนทั่วไป 1 ตัวกินพื้นที่ 3 ไบต์ ดังนั้นถ้ากฎการรวมสำหรับอักษรตัวนั้นถูกเรียนรู้มาไม่มากพอ อักษรจีนตัวเดียวจะถูกแตกออกเป็นหลายโทเคน ในทางกลับกัน คำ 2 อักษรที่พบบ่อยจะมีกฎการรวมอยู่ และอาจนับเป็น 1 โทเคนสำหรับ 2 อักษรก็ได้ พูดอีกอย่างคือ เอกสารภาษาจีนที่มีจำนวนอักษรเท่ากัน จำนวนโทเคนก็ยังเปลี่ยนไปตามโทเคไนเซอร์

โทเคไนเซอร์รุ่นตั้งแต่ cl100k_base เป็นต้นมา ถือกันว่ามีคลังคำภาษาจีนมากกว่ารุ่นก่อนหน้า แต่ก็ยังไม่มีประสิทธิภาพเท่าภาษาอังกฤษ ส่วนโทเคไนเซอร์ของโมเดลที่ประกาศชัดว่าเสริมความสามารถภาษาจีน มีแนวโน้มว่าคลังคำภาษาจีนจะหนากว่า เนื่องจากอัตราส่วนที่แน่ชัดเปลี่ยนไปตามสาขาของเอกสารและรูปอักษร วิธีเดียวที่แน่นอนคือนับจากเอกสารจริงของบริษัทตัวเอง เริ่มจากเลือกเอกสารภายในที่เป็นตัวแทนมาสักไม่กี่ฉบับ ป้อนเข้าโทเคไนเซอร์ของโมเดลที่เป็นตัวเลือกแล้วนับจำนวนโทเคน เพียงเท่านี้ความแม่นยำของการประเมินค่าใช้จ่ายรายเดือนและการออกแบบความยาวบริบทก็ต่างไปมาก

เกิดการรวมที่ผิดพลาด

ยังมีอีกปรากฏการณ์หนึ่งที่มีการรายงานในภาษาจีน บทความ “To Merge or Not to Merge – The Pitfalls of Chinese Tokenization in General-Purpose LLMs” ของ The Digital Orientalist ได้นำประโยคตัวอย่าง 他是学科技的，他不相信神秘和超自然的事物 ไปผ่านโทเคไนเซอร์ของหลายโมเดล แล้วพบว่ามีการรวมคำที่จริงๆ ไม่มีอยู่ให้กลายเป็นโทเคนเดียว (การรวมผิดของ 的事 ที่รายงานในโมเดลตระกูล LLaMA) และมีการรวมที่ไม่สนใจบริบท (การรวมผิดของ 他不 และ 的事物 ใน DeepSeek) โดยพบในหลายโมเดล

สาเหตุอยู่ที่กลไกของ BPE เอง เนื่องจาก BPE ตรึงกฎการรวมตามลำดับความถี่ที่ปรากฏในข้อมูลฝึก ตอนอนุมานจึงไม่ได้ดูบริบท มันจะนำการรวมที่ผิดในเชิงบริบทมาใช้ก่อน เพียงเพราะเหตุผลว่าความถี่สูง และเพราะ 的 เป็นหนึ่งในอักษรที่พบบ่อยที่สุดในภาษาจีน โครงสร้างจึงเอื้อให้กฎที่รวมมันกับอักษรตัวหลังขึ้นไปอยู่อันดับต้นๆ ได้ง่าย

นัยในทางปฏิบัติมีจำกัด แต่ก็มองข้ามไม่ได้ เมื่อขอบเขตของโทเคนเคลื่อนไปจากขอบเขตเชิงความหมายของคำ โมเดลจะจัดการคำนั้นเป็นหน่วยความหมายเดียวได้ยากขึ้น โดยเฉพาะการใช้งานที่ต้องประมวลผลชิ้นข้อความสั้นจำนวนมาก (การรวมชื่อสินค้าให้เป็นหนึ่งเดียว การจัดหมวดข้อความสั้น การสกัดคำสำคัญ) ผลกระทบนี้จะปรากฏง่ายกว่า ไม่ควรตัดสินใจเลือกโมเดลด้วยเหตุผลข้อนี้เพียงข้อเดียว แต่ก็คุ้มที่จะจำไว้ในฐานะสาเหตุที่เป็นไปได้ เมื่อการประมวลผลข้อความสั้นเกิดข้อผิดพลาดที่อธิบายไม่ได้ต่อเนื่อง

ชั้นที่ 4 ชั้นความหมาย — เพิ่งจะมาเลือก LLM ภาษาจีน ตรงนี้

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

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

สิ่งที่ควรดูในการคัดเลือกไม่ใช่คะแนนรวมของเบนช์มาร์ก แต่เป็นประเด็นต่อไปนี้

• ในเอกสารของบริษัทเราเอง ทั้งอักษรตัวย่อและตัวเต็มให้คุณภาพเท่ากันหรือไม่
• เมื่อส่งอภิธานศัพท์ให้แล้ว โมเดลรักษาศัพท์นั้นไว้จนจบหรือไม่ (ในเอกสารยาวๆ จะเริ่มเพี้ยนกลางทางหรือเปล่า)
• โมเดลทำตามรูปแบบเอาต์พุตที่กำหนด (ตาราง JSON โครงสร้างหัวข้อที่ตายตัว) หรือไม่
• เมื่อแปลจากภาษาจีนเป็นภาษาญี่ปุ่นแล้ว ฝั่งภาษาญี่ปุ่นเป็นธรรมชาติในฐานะศัพท์ภาคการผลิตหรือไม่
• ข้อมูลถูกประมวลผลที่ไหน (เชื่อมโดยตรงกับประเด็น PDPA ที่จะกล่าวต่อไป)

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

มองตามการใช้งาน — งานแปล OCR ภาษาจีน และการรวมชื่อ ต้องแก้ชั้นไหนถึงจะได้ผล

เรื่องชั้นมักจะฟังดูเป็นนามธรรม จึงขอแปลงลงมาเป็นการใช้งานจริง

วิธีอ่านตารางนี้ง่ายมาก หาการใช้งานที่กำลังมีอาการ แล้วลงมือจาก “ชั้นที่มีอิทธิพลหลัก” ในแถวนั้น ส่วนคอลัมน์ขวาสุดคือมาตรการที่คนมักลองทำแต่ไม่ค่อยได้ผล

หากต้องการสร้างกลไกรับคำถามภาษาจีนจากภายในองค์กร ดูเพิ่มที่ การทำระบบตอบคำถามภายในองค์กรให้เป็นอัตโนมัติ และหากจะออกไปเป็นแชตบอทหลายภาษาสำหรับภายนอก ดูประกอบที่ ค่าใช้จ่ายและวิธีเริ่มนำแชตบอทมาใช้

การประมาณการเอง — ต้นทุนและผลลัพธ์เปลี่ยนไปอย่างไรตามรูปแบบการรับมือ

จากนี้เป็นการประมาณการบนพื้นฐานของโรงงานจำลอง มูลค่าการลงทุน EV และจำนวนซัพพลายเออร์ที่อ้างถึงในหัวข้อก่อนหน้าเป็นข้อมูลเผยแพร่จริง แต่ตัวเลขต่อจากนี้ทั้งหมดเป็นค่าที่กำหนดขึ้นเพื่อประกอบคำอธิบาย ไม่ใช่ผลประกอบการของบริษัทที่มีอยู่จริง เราเขียนขั้นตอนการคำนวณทั้งหมดไว้ เพื่อให้คุณแทนค่าด้วยตัวเลขของบริษัทตัวเองแล้วตรวจทานตามได้

การตั้งค่าโรงงานจำลอง

ปริมาณงานที่ต้องใช้ภาษาจีน และเวลาที่ใช้ในปัจจุบัน (ใช้คนล้วน) เป็นดังนี้

ต้นทุนต่อเดือนในปัจจุบันคือ 220 ชั่วโมง × 600 THB = 132,000 THB

3 รูปแบบการจัดโครงสร้าง

รูปแบบ A — ใช้ generative AI ทั่วไปตามที่เป็นอยู่ (ไม่แก้ชั้นใดเลย)

ใช้งานด้วยไลเซนส์ generative AI ทั่วไปที่มีอยู่แล้ว (เดือนละ 3,000 THB) เพียงอย่างเดียว ไม่ใส่ทั้งอภิธานศัพท์และการทำให้เป็นมาตรฐาน จำนวนองค์ประกอบคือ 1 อย่าง

รูปแบบ B — แก้ชั้นอักษรและชั้นคำ

เพิ่มจากรูปแบบ A ด้วยการทำพจนานุกรมคำแปลศัพท์เครื่องจักร 1,200 คำ ที่ครอบคลุมตัวย่อ ตัวเต็ม และภาษาญี่ปุ่น พร้อมกับติดตั้งกฎการทำให้ตัวย่อตัวเต็มเป็นมาตรฐานเดียว จำนวนองค์ประกอบคือ 3 อย่าง (AI ทั่วไป พจนานุกรมคำแปล กฎการทำให้เป็นมาตรฐาน)

รูปแบบ C — ลงมือทั้ง 4 ชั้น

เพิ่มจากรูปแบบ B ด้วยการจัดทำเทมเพลต OCR สำหรับแบบฟอร์มภาษาจีน และคัดเลือก LLM ที่รองรับภาษาจีนหลังจากวัดจำนวนโทเคนของโมเดลที่เป็นตัวเลือกจริงแล้ว จำนวนองค์ประกอบคือ 5 อย่าง (กฎการทำให้เป็นมาตรฐาน พจนานุกรมคำแปล OCR แบบฟอร์ม การออกแบบโทเคน และ LLM ที่รองรับภาษาจีนพร้อมชุดข้อมูลประเมินผล) ในรูปแบบ C ไลเซนส์ AI ทั่วไป 3,000 THB จะถูกแทนที่ด้วยค่าใช้จ่ายของ LLM ที่รองรับภาษาจีน จึงไม่ได้นับซ้ำสองต่อ

การเปลี่ยนแปลงของเวลาที่ใช้

เหตุที่การอ่านแบบฟอร์มไม่เปลี่ยนแปลงในรูปแบบ A และ B เพราะงานนี้ขึ้นอยู่กับการติดตั้งฝั่ง OCR ซึ่งเป็นชั้นที่ 1 จึงไม่ได้ถูกย่นเวลาด้วยการใช้ AI ทั่วไปหรือพจนานุกรมศัพท์ ในทางกลับกัน ที่ลดจาก 9 นาทีเหลือ 3 นาทีได้ในรูปแบบ C ก็เพราะการใส่เทมเพลต OCR และการประมวลผลภายหลังสำหรับตัวย่อตัวเต็ม ทำให้จำกัดขอบเขตของการตรวจสอบด้วยสายตาให้แคบลงได้

ค่าใช้จ่ายและผลลัพธ์

เราจับรายละเอียดของค่าใช้จ่ายเริ่มต้นให้ตรงกับแต่ละชั้น และจัดสรรว่าค่าใช้จ่ายก้อนไหนสร้างการย่นเวลาได้เท่าไร ลงลึกถึงระดับนาที

เวลาที่ลดได้ 56 ชั่วโมงของรูปแบบ A คือส่วนที่เกิดจากไลเซนส์ AI ทั่วไปที่มีค่าใช้จ่ายเริ่มต้นเป็น 0 เพียงอย่างเดียว (แปล 25 นาที → 16 นาที อีเมล 12 นาที → 8 นาที) มาตรวจสอบว่าการจัดสรรในตารางข้างต้นตรงกับเวลาที่ลดได้ที่ระบุไว้ก่อนหน้าหรือไม่ ส่วนที่รูปแบบ B เพิ่มขึ้นจากรูปแบบ A คือ 17 + 17 = 34 ชั่วโมง ซึ่งตรงกับ 90 − 56 = 34 ชั่วโมง ส่วนที่รูปแบบ C เพิ่มขึ้นจากรูปแบบ B คือ 40 + 8 + 9 = 57 ชั่วโมง ซึ่งตรงกับ 147 − 90 = 57 ชั่วโมง นั่นแปลว่า ตัดแถวค่าใช้จ่ายแถวไหนออก การย่นเวลาที่เขียนไว้ในแถวนั้นก็หายไปตรงๆ

รายละเอียดค่าใช้จ่ายรายเดือนเป็นดังนี้

แปลงเวลาที่ลดได้เป็นจำนวนเงิน แล้วคำนวณผลประโยชน์สุทธิ

จุดที่ควรอ่านจากตารางนี้คือ เมื่อมองที่ 12 เดือน ความต่างของทั้ง 3 รูปแบบเล็กกว่าที่คิด (367,200 กับ 403,200 กับ 439,200 THB) ช่องว่างจะถ่างออกตั้งแต่ปีที่สองเป็นต้นไป โดยที่ 24 เดือน รูปแบบ C จะเป็นประมาณ 1.7 เท่าของรูปแบบ A ถ้าเสนอรูปแบบ C เข้าที่ประชุมอนุมัติที่ตั้งเงื่อนไขว่าต้องคืนทุนภายใน 1 ปี ตัวเลขจะดูอ่อน การแจ้งให้ทราบล่วงหน้าว่าข้อสรุปเปลี่ยนไปตามการกำหนดระยะเวลาประเมิน จะปลอดภัยกว่า

การวิเคราะห์ความอ่อนไหว — กรณีที่เวลาที่ลดได้อยู่เพียง 70% ของที่คาด

การประมาณเวลาที่ลดได้เป็นส่วนที่ไม่แน่นอนที่สุดในบรรดาสมมติฐานทั้งหมด เราจึงลดเฉพาะจุดนี้ลงเหลือ 70% โดยตรึงค่าใช้จ่ายไว้เท่าเดิมแล้วคำนวณใหม่ ต้นทุนต่อหน่วย 600 THB และค่าใช้จ่ายแต่ละรายการยังคงเป็นสมมติฐานเดิมไม่เปลี่ยน

ลำดับที่จุด 12 เดือนสลับกัน หากผลลัพธ์อยู่เพียง 70% ของที่คาด ที่ 12 เดือน รูปแบบ A จะได้เปรียบที่สุด และรูปแบบ C อยู่อันดับสุดท้าย ต้องมองไปถึง 24 เดือน รูปแบบ C จึงจะแซงรูปแบบ B ได้เพียงเล็กน้อย (603,360 เทียบกับ 597,600 THB)

ผลลัพธ์นี้ไม่ได้แปลว่า “ควรเลิกทำรูปแบบ C” แต่แปลว่า ควรตรวจสอบแบบเล็กๆ ก่อนว่าเวลาที่ลดได้จะออกมาจริงหรือไม่ ก่อนที่จะตัดสินใจลงทุนจริง แผน 90 วันที่จะกล่าวถึงต่อไป จัดลำดับให้การตรวจสอบนี้มาก่อน

ประเด็นเพิ่มเติมสำหรับฐานในไทยและอาเซียน

PDPA และการโอนข้อมูลข้ามพรมแดน

พระราชบัญญัติคุ้มครองข้อมูลส่วนบุคคลของไทย (PDPA) กำหนดเงื่อนไขเมื่อมีการโอนข้อมูลส่วนบุคคลออกนอกประเทศ แบบฟอร์มภาษาจีนและอีเมลกับคู่ค้าตามปกติจะมีข้อมูลส่วนบุคคลอย่างชื่อผู้รับผิดชอบ ข้อมูลติดต่อ และลายเซ็นรวมอยู่ด้วย หากจะส่งสิ่งเหล่านี้ไปยัง API ในต่างประเทศ จำเป็นต้องรู้ว่าถูกประมวลผลโดยผู้ให้บริการรายใดในประเทศใด และหากเลือกใช้บริการภายในประเทศจีนเพื่อรองรับภาษาจีน จะมีกฎหมายเกี่ยวกับข้อมูลของฝั่งจีนเข้ามาเกี่ยวข้องเพิ่มจาก PDPA ของไทย ดังนั้นการเลือกสถานที่ประมวลผลจึงควรถือเป็นการตัดสินใจทางกฎหมาย ไม่ใช่การตัดสินใจทางเทคนิค

มาตรการหลีกเลี่ยงในทางปฏิบัติคือ การใส่การประมวลผลก่อนส่ง ที่ตัดข้อมูลส่วนบุคคลออก (แทนที่ชื่อบุคคลและข้อมูลติดต่อด้วยเครื่องหมายปิดบัง) ในทางเทคนิคไม่ยาก แต่มีเงื่อนไขว่าต้องตกลงนิยามของรายการที่ต้องตัดออกกับฝ่ายกฎหมายไว้ก่อน

ข้อกำหนดลำดับความสำคัญของภาษาในสัญญาและสเปก

ในสัญญากับซัพพลายเออร์จีน มักมีการจัดทำทั้งฉบับภาษาจีนและฉบับภาษาอังกฤษ ตรงนี้ควรตรวจสอบว่ามีข้อกำหนดที่ระบุว่าฉบับใดมีผลเหนือกว่า (ข้อกำหนดลำดับความสำคัญของภาษา) อยู่หรือไม่ หากไม่มี เมื่อเกิดการตีความที่แตกต่างกันก็จะไม่มีสิ่งที่ยึดถือได้

สิ่งนี้มีผลในบริบทของ generative AI ตรงเส้นแบ่งว่า จะถือเอกสารที่แปลแล้วเป็นเอกสารอ้างอิงอย่างเป็นทางการภายในองค์กรหรือไม่ ฉบับที่ AI แปล ตามสัญญาแล้วเป็นเพียงคำแปลเพื่อการอ้างอิงเท่านั้น หากจะใช้เป็นคำสั่งงานหรือเกณฑ์การตรวจสอบ จำเป็นต้องวางระบบการทำงานให้มีบันทึกว่าใครเป็นผู้ตรวจสอบเนื้อหาและอนุมัติ

จะให้อักษรตัวย่อหรือตัวเต็มเป็นฉบับจริง

เรื่องนี้ไม่ใช่ปัญหาทางเทคนิคแต่เป็นเรื่องของข้อตกลง ทว่าผลกระทบแผ่ไปทั่วทั้งชั้นอักษร ถ้าซัพพลายเออร์สายจีนแผ่นดินใหญ่เยอะก็เลือกอักษรตัวย่อ ถ้าสายไต้หวันเยอะก็เลือกอักษรตัวเต็มเป็นธรรมชาติ แต่สิ่งสำคัญคือการตัดสินใจเลือกอย่างใดอย่างหนึ่ง เมื่อตัดสินใจแล้วก็ทำให้เป็นรูปอักษรของฉบับจริงตั้งแต่ตอนนำเข้า และเก็บต้นฉบับไว้ต่างหากในฐานะต้นฉบับ วางระบบแบบนี้แล้ว ทั้งการค้นหาและการรวมยอดจะไม่แตกออกเป็นสองทาง

หากไม่ตัดสินใจแล้วปล่อยให้ปนกันทั้งสองแบบมาหลายปี ต้นทุนของการมาทำให้เป็นมาตรฐานทีหลังจะเพิ่มขึ้นตามสัดส่วนของปริมาณเอกสาร นี่คือประเภทของการตัดสินใจที่ยิ่งทำเร็วยิ่งถูก

การจัดเก็บเอกสารภาษาจีนและการตรวจสอบย้อนกลับ

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

90 วันแรกต้องทำอะไร

วันที่ 1 ถึง 30 — ทุ่มเทกับการนับ

ช่วงนี้ยังไม่ต้องติดตั้งอะไร ให้นับสถานการณ์ปัจจุบัน

• รวบรวมเอกสารที่เข้ามาเป็นภาษาจีนแยกตามประเภท แล้วนับจำนวนรายการและจำนวนหน้าต่อเดือน
• จัดหมวดว่าผู้ส่งเป็นสายจีนแผ่นดินใหญ่ ไต้หวัน หรือฮ่องกง เพื่อให้เห็นสถานการณ์การปนกันของรูปอักษร
• วัดเวลาที่ใช้ในการประมวลผลปัจจุบันแยกตามงานจริงๆ (ไม่ใช่การประมาณ แต่เป็นการวัดจริง)
• ดึงศัพท์ที่พบบ่อยออกมาสัก 50 ถึง 100 คำ แล้วทำร่างตารางเทียบอักษรตัวย่อ ตัวเต็ม และภาษาญี่ปุ่น
• นำเอกสารที่เป็นตัวแทน 3 ถึง 5 ฉบับ ผ่านโทเคไนเซอร์ของโมเดลที่เป็นตัวเลือก แล้วนับจำนวนโทเคน

ผลงานส่งมอบของ 30 วันนี้ คือการเติม “ปริมาณต่อเดือน” และ “เวลาต่อ 1 ชิ้น” ในตารางประมาณการของหัวข้อก่อนหน้าด้วยตัวเลขของบริษัทตัวเอง ถ้าตรงนี้ยังเติมไม่เต็มแล้วเดินหน้าต่อ จะไม่มีหลักฐานสำหรับการตัดสินใจลงทุน

วันที่ 31 ถึง 60 — ตรวจสอบแบบเล็กๆ

ยืนยันด้วยการลงทุนน้อยที่สุดว่าเวลาที่ลดได้จะออกมาจริงหรือไม่

• ทำพจนานุกรมชั่วคราวประมาณ 50 คำ นำไปใช้กับการแปลร่างแรก แล้ววัดเวลาที่ใช้ใหม่
• ใช้การทำตัวย่อตัวเต็มให้เป็นมาตรฐานกับเอกสารเพียงประเภทเดียว แล้วดูว่าผลการค้นหาเปลี่ยนไปหรือไม่
• สำหรับ OCR ให้ทดลองทำเทมเพลตกับแบบฟอร์ม 1 ประเภท ประมาณ 20 แผ่น แล้ววัดเวลาที่ใช้ตรวจสอบด้วยสายตา
• ในฐานะต้นแบบของชุดข้อมูลประเมินผล ให้เลือกเอกสารจริง 30 ชิ้น แล้วสร้างคำตอบที่ถูกต้องด้วยมือ

ณ จุดวันที่ 60 นี้ คุณจะรู้ว่าตัวเลข “70%” ในการวิเคราะห์ความอ่อนไหวเป็นตัวเลขที่สมจริงหรือไม่ จะได้มากกว่าหรือน้อยกว่านั้น หากตัวเลขไม่ออกตรงนี้ ก็ตัดสินใจได้ว่าจะลดขอบเขตลง หรือจำกัดงานเป้าหมายให้แคบลง

วันที่ 61 ถึง 90 — กำหนดขอบเขตแล้วตรึงไว้

• ตัดสินใจว่าจะใช้รูปอักษรใดเป็นฉบับจริง แล้วเขียนลงในระเบียบการจัดการเอกสาร
• กำหนดผู้รับผิดชอบการอัปเดตพจนานุกรมศัพท์และความถี่ในการอัปเดต
• ตกลงขอบเขตการประมวลผลข้อมูลส่วนบุคคลก่อนส่งกับฝ่ายกฎหมาย
• ตัดสินใจว่าจะเดินหน้าด้วยรูปแบบ A B หรือ C จากผลการตรวจสอบ
• ตัดเวอร์ชันของชุดข้อมูลประเมินผล แล้วกำหนดว่าการเปลี่ยนโมเดลต่อจากนี้จะเทียบด้วยเวอร์ชันนี้

ผลงานส่งมอบของวันที่ 90 ไม่ใช่ระบบที่เดินได้ แต่คือ “สมมติฐานที่ตัดสินใจแล้ว” การรับมือภาษาจีนนั้น ยิ่งมีเรื่องที่ยังไม่ตัดสินใจมากเท่าไร ก็ยิ่งแพงขึ้นในภายหลัง

ข้อผิดพลาดที่พบบ่อยและวิธีเลี่ยง

เริ่มต้นจากการเลือกโมเดล

นี่คือข้อผิดพลาดที่พบมากที่สุด ถ้าเริ่มจากการค้นหาว่า “LLM ตัวไหนเก่งภาษาจีน” ผลคือการเปลี่ยนเฉพาะชั้นที่ 4 ทั้งที่ชั้นอักษรและชั้นคำยังพังอยู่ อาการอย่างศัพท์ไม่นิ่งหรือค้นหาไม่เจอจะยังคงอยู่แม้เปลี่ยนโมเดล จึงต้องเปลี่ยนไปเปลี่ยนมาหลายรอบและเสียเวลา วิธีเลี่ยงคือ นำอาการไปเทียบกับตารางแยกตามการใช้งานข้างต้น เพื่อระบุชั้นที่มีอิทธิพลหลักก่อน

ติดตั้งการแปลงตัวย่อตัวเต็มด้วยการแทนที่อักษรแบบตรงไปตรงมา

ถ้าเขียนการแปลงจากตัวย่อไปตัวเต็มด้วยตารางแทนที่แบบหนึ่งต่อหนึ่ง จะตรึง 发 ให้เป็น 發 เสมอ แล้วคำที่เกี่ยวกับเส้นผมจะพังหมด วิธีเลี่ยงคือ รวมทิศทางการแปลงให้เป็นทางเดียวไปทางฝั่งอักษรตัวย่อ หรือใช้ไลบรารีแปลงที่ดูบริบท พร้อมกับยกเว้นชื่อเฉพาะออกจากเป้าหมายการแปลง

ทำพจนานุกรมศัพท์แล้วเลิกอัปเดต

ต่อให้ทำพจนานุกรม 1,200 คำในช่วงแรก เมื่อมีเครื่องจักรใหม่เข้ามาและมีซัพพลายเออร์รายใหม่เพิ่ม พจนานุกรมก็จะล้าสมัย เนื่องจากพจนานุกรมเป็นกลไกที่บังคับคำแปล พจนานุกรมที่ไม่ถูกอัปเดตจะบังคับคำแปลเก่าต่อไปเรื่อยๆ วิธีเลี่ยงคือ กำหนดผู้รับผิดชอบและความถี่ของการอัปเดตไว้ตั้งแต่จุดวันที่ 90 ในการประมาณการเราเผื่อชั่วโมงงานดูแลไว้เดือนละ 4 ถึง 6 ชั่วโมง ซึ่งเป็นค่าใช้จ่ายที่ตัดออกไม่ได้

เดินหน้าต่อด้วยความรู้สึกว่า “น่าจะแม่นขึ้น” โดยไม่ทำชุดข้อมูลประเมินผล

ถ้าไม่มีชุดข้อมูลประเมินผล ก็ถกกันไม่ได้ว่าการเปลี่ยนโมเดลนั้นดีขึ้นหรือแย่ลง ความรู้สึกของผู้รับผิดชอบจะกลายเป็นหลักฐาน และส่งต่อให้ผู้รับผิดชอบคนถัดไปไม่ได้ วิธีเลี่ยงคือ สร้างคำตอบที่ถูกต้องจากเอกสารจริงสัก 30 ชิ้นก็เพียงพอ แล้วตรึงเวอร์ชันไว้ แค่ 30 ชิ้นก็ต่างจากการไม่มีเลยอย่างชี้ขาด

ประมวลผลเอกสารจากไต้หวันและฮ่องกงด้วยการตั้งค่าของจีนแผ่นดินใหญ่

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

เริ่มส่งเข้า API โดยยังไม่ตัดสินใจเรื่องการจัดการข้อมูลส่วนบุคคล

บางครั้งเกิดการใช้งานที่โยนอีเมลของคู่ค้าจริงเข้า API ภายนอกตรงๆ ด้วยเหตุผลว่าเป็นแค่ PoC วิธีเลี่ยงคือ ใส่การประมวลผลข้อมูลส่วนบุคคลก่อนส่งตั้งแต่ขั้นตรวจสอบ หรือใช้เฉพาะเอกสารที่ไม่มีข้อมูลส่วนบุคคลในการตรวจสอบ

คำถามที่พบบ่อย

AI ภาษาจีนหมายถึงอะไร

หมายถึงการใช้ generative AI ที่มีข้อความภาษาจีนอยู่ในอินพุตหรือเอาต์พุตโดยรวมทั้งหมด ไม่ได้มีความหมายเดียวกับการใช้โมเดลที่ผลิตในจีน กรณีที่ใช้โมเดลแนวหน้าจากฝั่งตะวันตกจัดการภาษาจีนก็นับรวมอยู่ด้วย บทความนี้จัดระเบียบเรื่องนี้จากมุมมองว่าภาษาจีนพังที่ชั้นไหนของการประมวลผล ไม่ใช่จากมุมมองว่าโมเดลมาจากที่ใด

ความแม่นยำของ OCR ภาษาจีนอยู่ที่ประมาณเท่าไร

OCR ภาษาจีนพัฒนาความแม่นยำไปมากทั้งอักษรตัวย่อและตัวเต็ม โดยบทวิเคราะห์ทางเทคนิคหลายแหล่งรายงานว่ามีระบบที่ทำอัตราการรู้จำได้เกิน 95% แล้ว อย่างไรก็ตาม อักษรตัวเต็มมีรูปร่างซับซ้อนกว่าอักษรตัวย่อ ความเสี่ยงของการรู้จำผิดจึงถือว่าสูงกว่าโดยเปรียบเทียบ นอกจากนี้ ตัวเลขประเภทนี้ยังขึ้นกับคุณภาพการพิมพ์ ฟอนต์ เลย์เอาต์ และความละเอียดของการสแกนอย่างมาก จึงแนะนำให้วัดจริงด้วยแบบฟอร์มของบริษัทเอง ในทางปฏิบัติ การออกแบบว่าจะตรวจจับความผิดพลาดได้ตรงจุดไหนเมื่อมันเกิดขึ้น มีผลมากกว่าตัวอัตราการรู้จำเสียอีก

อักษรตัวย่อกับตัวเต็มแค่แปลงด้วย AI ก็จบหรือไม่

ไม่จบ เพราะอักษรตัวย่อ 1 ตัวอาจตรงกับอักษรตัวเต็มหลายตัว และการเลือกว่าจะใช้ตัวไหนขึ้นกับบริบท การแปลงจากตัวย่อไปตัวเต็มเกิดข้อผิดพลาดง่าย ทิศทางตรงกันข้ามปลอดภัยกว่า ในทางปฏิบัติ การกำหนดรูปอักษรของฉบับจริงไว้แบบเดียว แล้วทำให้เป็นรูปนั้นตั้งแต่ตอนนำเข้า เป็นวิธีที่เสถียรที่สุด

LLM ภาษาจีนควรเลือกโมเดลที่ผลิตในจีนหรือไม่

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

แบบฟอร์มภาษาจีนของเรามีทั้งตัวย่อและตัวเต็มปนกัน ควรเริ่มจากอะไร

อันดับแรก ให้ตัดสินใจว่าจะใช้แบบไหนเป็นฉบับจริง จากนั้นใส่การประมวลผลที่แปลงให้เป็นรูปอักษรของฉบับจริงตั้งแต่ตอนนำเข้า เพียง 2 ข้อนี้ ปัญหาการค้นหาตกหล่นและการนับยอดซ้ำจะลดลงไปมาก ส่วนการจัดทำเทมเพลต OCR ค่อยทำเป็นลำดับถัดไปก็ได้

สรุป

การปรึกษาที่ว่า generative AI ให้ความแม่นยำไม่ออกกับภาษาจีน ส่วนใหญ่ไม่ใช่ปัญหาของโมเดล การที่อักษรตัวย่อกับตัวเต็มไม่ได้จับคู่กันแบบหนึ่งต่อหนึ่ง การที่รหัส Unicode เดียวกันแต่รูปอักษรต่างกันตามภูมิภาค การที่ไม่มีช่องว่างจึงทำให้การตัดคำกำกวมโดยโครงสร้าง และการที่ BPE ตรึงกฎการรวมโดยไม่ดูบริบท ทั้งหมดนี้เกิดขึ้นที่ชั้นอักษร ชั้นคำ และชั้นโทเคน และไม่หายไปแม้จะเปลี่ยนโมเดลที่ชั้นที่ 4

สำหรับโรงงานญี่ปุ่นในไทย ภาษาจีนไม่ใช่ภาษาที่เลือกจะนำเข้ามา แต่เป็นภาษาที่ไหลเข้ามาผ่านห่วงโซ่อุปทาน EV และเครื่องจักรจากจีน ด้วยเหตุนี้เอง จึงคุ้มค่าที่จะออกแบบไปในทิศทางของการทำให้ผู้รับผิดชอบที่มีอยู่เดิมจัดการข้อมูลปฐมภูมิภาษาจีนได้ มากกว่าทิศทางของการเพิ่มบุคลากรเฉพาะทาง

อย่างที่เห็นในการประมาณการ รูปแบบที่ลงมือทั้ง 4 ชั้นให้ผลลัพธ์มากที่สุด แต่ความต่างในปีแรกนั้นน้อย และถ้าผลลัพธ์ต่ำกว่าที่คาด ลำดับจะกลับหัวกลับหาง ดังนั้น 90 วันแรกขอให้ใช้ไปกับการนับและการตรวจสอบแบบเล็กๆ ไม่ใช่การติดตั้ง สิ่งที่ต้องตัดสินใจคือ รูปอักษรของฉบับจริง ผู้รับผิดชอบการอัปเดตพจนานุกรม ขอบเขตการประมวลผลข้อมูลส่วนบุคคลก่อนส่ง และเวอร์ชันของชุดข้อมูลประเมินผล ถ้า 4 ข้อนี้ตัดสินใจแล้ว ที่เหลือจะเดินด้วยรูปแบบไหนก็ไม่พลาดไปไกลนัก

เรื่องปรึกษาในขั้นตอนพิจารณา

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

ข้อมูลอ้างอิง

• Thailand Secures $4.1 Billion in EV Chain Investments as Southeast Asia Auto Hub Pivots to Next-Gen Tech – Thailand Board of Investment — ประกาศอย่างเป็นทางการเกี่ยวกับมูลค่าเจตจำนงลงทุนในห่วงโซ่อุปทาน EV ของไทย 4.1 พันล้านดอลลาร์ จำนวน 198 โครงการ และการผลิต BEV 18 โครงการ มูลค่า 1.18 พันล้านดอลลาร์ กำลังผลิตเกิน 370,000 คันต่อปี (3 กรกฎาคม 2026)
• Thailand approves Sunwoda to invest $1B in EV battery cell plants – TechNode Global — รายงานข่าวการอนุมัติการลงทุนผลิตเซลล์แบตเตอรี่ของ Sunwoda Electronic (17 มีนาคม 2025)
• สถานการณ์การเข้าสู่ตลาดไทยและอาเซียนของซัพพลายเออร์จีน – THAIBIZ — บทวิเคราะห์รายละเอียดการเข้ามาตั้งกิจการในไทยของซัพพลายเออร์จีน 183 ราย กลุ่มแปรรูป 125 ราย และรายใหม่ 90 รายในช่วงปี 2023 ถึงมิถุนายน 2025 (เครือ Nomura Research Institute กุมภาพันธ์ 2026)
• To Merge or Not to Merge – The Pitfalls of Chinese Tokenization in General-Purpose LLMs – The Digital Orientalist — ตัวอย่างจริงของการรวมโทเคนภาษาจีนที่ผิดพลาดในโทเคไนเซอร์ของ LLM ทั่วไป พร้อมคำอธิบายสาเหตุที่มาจาก BPE (4 กุมภาพันธ์ 2025)
• jieba – Chinese text segmentation — การติดตั้งพจนานุกรมคำนำหน้า กราฟระบุทิศทางแบบไม่มีวงวน (DAG) การโปรแกรมเชิงพลวัต การจัดการคำที่ไม่ได้ลงทะเบียนด้วย HMM และ Viterbi พร้อมวิธีลงทะเบียนพจนานุกรมผู้ใช้
• China LLM Guide 2026 – Top Chinese LLMs Compared – Swift Horse AI — การเปรียบเทียบแนวโน้มตามการใช้งานของ LLM ที่ผลิตในจีน โดยเน้นที่ DeepSeek, Qwen, Kimi และ GLM (มิถุนายน 2026)
• Parsing Through Boundaries in Chinese Word Segmentation – arXiv — งานวิจัยเกี่ยวกับผลกระทบของวิธีกำหนดขอบเขตการตัดคำภาษาจีนต่อการวิเคราะห์ในขั้นถัดไป (มีนาคม 2025)
• ชุดข้อมูล Maximum Overlapping Ambiguous String – กลุ่มประมวลผลภาษาธรรมชาติ มหาวิทยาลัยชิงหัว — ชุดข้อมูลประเมินผลการตัดคำภาษาจีนที่รวบรวมความกำกวมแบบไขว้
• Personal Data Protection Act B.E. 2562 – Office of the Personal Data Protection Committee Thailand — ตัวบทพระราชบัญญัติคุ้มครองข้อมูลส่วนบุคคลของไทย
• Cross-border personal data transfer under Section 29 – Office of the Personal Data Protection Committee Thailand — ข้อกำหนดของการโอนข้อมูลข้ามพรมแดนด้วยมาตรการคุ้มครองที่เหมาะสม