ระบบแปลภาษาอัตโนมัติในองค์กร 2026 — แบ่งเอกสาร 4 คลาส หยุดคำแปลไม่นิ่ง

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

ทำไมระบบแปลภาษาอัตโนมัติในองค์กรถึงไปไม่รอด

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

ความเข้าใจผิดที่ว่า “เปลี่ยนเอนจินแล้วจบ”

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

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

การประเมิน ณ ปี 2026 ก็ยังระบุว่า แม้ขอบเขตที่เครื่องแปลภาษารับมือได้จะขยายกว้างขึ้นอย่างชัดเจน แต่ก็ยังไปไม่ถึงระดับที่จะถอดการตัดสินใจของมนุษย์ออกจากงานโลคัลไลเซชันขององค์กรได้ มีผลการเปรียบเทียบระบุว่า การแปลด้วย LLM ในสภาวะที่ไม่ได้รับข้อมูลบริบท ได้รับการประเมินว่า “ดี” ในสัดส่วน 55.7-80% แล้วแต่คู่ภาษา อย่างไรก็ตาม ตัวเลขนี้มาจากคู่ภาษายุโรป เช่น อังกฤษไปเยอรมัน โปแลนด์ และรัสเซีย ส่วนคู่ภาษาที่บทความนี้พูดถึงคือญี่ปุ่นไปไทยและเวียดนามนั้น ควรตั้งสมมติฐานว่าผลจะออกมาเข้มงวดกว่านี้ เพราะปริมาณข้อมูลฝึกต่างกันมาก และต่อให้ใช้ตัวเลขของคู่ภาษายุโรป ก็ยังหมายความว่า 20-40% ไม่อาจเรียกได้ว่าดี ที่สำคัญคือเราไม่รู้ล่วงหน้าว่า 20% ที่หลุดออกมานั้นคือส่วนไหน

ความพังที่เกิดจาก “ไปป์ไลน์เส้นเดียว”

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

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

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

ย้ายหน่วยของการตัดสินใจไปที่ “คลาสของเอกสาร”

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

แบ่งเอกสารภายในออกเป็น 4 คลาส

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

คลาส A เอกสารควบคุม — AI ทำได้แค่ร่างคำแปล

คือกลุ่มเอกสารที่อยู่ภายใต้การควบคุมของ ISO 9001 ข้อ 7.5 “เอกสารสารสนเทศ” กำหนดให้เอกสารต้องพร้อมใช้งานและอยู่ในสภาพเหมาะสมต่อการใช้เมื่อจำเป็น ต้องระบุตัวตนได้ และได้รับการปกป้องอย่างเพียงพอจากการเปลี่ยนแปลงที่ไม่ตั้งใจ เอกสารควบคุมต้องผ่านการทบทวนและอนุมัติอย่างเป็นทางการก่อนออกใช้ พร้อมทั้งควบคุมการแจกจ่ายและการจัดเก็บ

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

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

คลาส B เอกสารปฏิบัติการ — อัตโนมัติเต็มรูปแบบได้

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

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

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

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

คลาส C เอกสารสู่ภายนอก — ใช้ AI ตรวจความสอดคล้อง ไม่ใช่ให้แปล

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

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

คลาส D ข้อความ UI หน้างาน — นี่ไม่ใช่การแปล แต่คือการออกแบบ

คลาสที่ถูกมองข้ามบ่อยที่สุดคือคลาสนี้ ป้ายกำกับปุ่มบนหน้าจอ HMI ข้อความบนอันดง หัวคอลัมน์ของแบบฟอร์ม ป้ายเตือนของอุปกรณ์โพคะโยเกะ ทั้งหมดนี้มีข้อจำกัดเข้มงวดเรื่องจำนวนตัวอักษรและความกว้างของพื้นที่แสดงผล

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

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

โครงสร้าง 3 ชั้นที่หยุดความไม่สม่ำเสมอของคำแปล

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

ชั้นที่ 1 ชั้นคำศัพท์ — คลังคำศัพท์และหน่วยความจำการแปล

สิ่งที่วางไว้ชั้นล่างสุดคือคลังคำศัพท์ (Term Base) และหน่วยความจำการแปล (Translation Memory) คลังคำศัพท์คือพจนานุกรมที่ตรึงไว้ในระดับคำว่า “คำนี้ให้แปลแบบนี้” ส่วนหน่วยความจำการแปลคือบันทึกที่สะสมไว้ในระดับประโยคว่า “ประโยคนี้เคยแปลแบบนี้และได้รับอนุมัติแล้ว”

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

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

ชั้นที่ 2 ชั้นสร้างคำแปล — LLM และการฉีดบริบทภายในองค์กร

ชั้นกลางคือส่วนที่สร้างคำแปลจริง ตรงนี้ใช้ LLM แต่ไม่ใช่การโยนเข้า LLM เปล่า ๆ ต้องส่งคลังคำศัพท์ คำแปลที่ผ่านการอนุมัติในอดีต และบริบทของกระบวนการที่เอกสารนั้นสังกัดอยู่ไปพร้อมกัน รูปแบบพื้นฐานคือการใช้โครงสร้างแบบ Retrieval-Augmented Generation (RAG) เพื่อให้อ้างอิงคำแปลที่เคยได้รับอนุมัติมาก่อน

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

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

ชั้นที่ 3 ชั้นอนุมัติ — การจัดการเวอร์ชันและการลงนามอนุมัติ

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

สิ่งที่ต้องตัดสินให้ชัดในชั้นอนุมัติมี 4 ข้อ

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

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

ความหมายของการมีแผนภาพ 3 ชั้น

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

เปลี่ยน KPI จาก “ความแม่นยำ 99%” เป็น TTE

รูปแบบคลาสสิกที่ทำให้โครงการระบบแปลภาษาอัตโนมัติหลงทาง คือการตั้ง KPI เป็นเปอร์เซ็นต์ความแม่นยำของการแปล

เปอร์เซ็นต์ความแม่นยำไม่ได้สะท้อนภาระของกระบวนการ

ได้ยินว่าความแม่นยำ 95% ก็รู้สึกว่าเพียงพอ แต่ในทางปฏิบัติแล้วมันไม่มีความหมาย ถ้าเอกสารหนึ่งมี 100 ประโยคและผิด 5 ประโยค คนก็ต้องอ่านครบทั้ง 100 ประโยคเพื่อหา 5 ประโยคนั้น เวลาที่ใช้อ่านแทบไม่ลดลงแม้ความแม่นยำจะสูงขึ้น ต่อให้ความแม่นยำเป็น 99% ตราบใดที่ยังไม่รู้ว่าประโยคไหนคือประโยคที่ผิด ก็ยังต้องตรวจทั้งฉบับอยู่ดี

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

TTE (Time to Edit) คืออะไร

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

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

ข้อควรระวังเมื่อวัด TTE

TTE ต้องแยกวัดตามคลาสของเอกสาร ต่อให้ TTE ของคลาส B ทั้งหมดลดลง 80% แต่ถ้าคลาส A ลดลงเป็นศูนย์ ก็ต้องถอดคลาส A ออกจากขอบเขตของระบบอัตโนมัติ หรือไม่ก็แปลว่าการจัดทำชั้นคำศัพท์ยังไม่พอ ถ้าดูเป็นค่าเฉลี่ยรวม จะตัดสินแบบนี้ไม่ได้

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

จุดที่พังในภาษาไทยและภาษาเวียดนาม

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

ภาษาไทย — การตัดคำผิดทำให้คำแปลพังทั้งชุด

ภาษาไทยไม่เว้นวรรคระหว่างคำกับคำ ดังนั้นเมื่อเครื่องประมวลผล จะต้องตัดสินก่อนว่าจะแบ่งสายอักขระออกเป็นคำตรงจุดไหน (word segmentation) ถ้าพลาดตรงนี้ คำแปลหลังจากนั้นจะพังยกชุด

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

ความไม่สมมาตรระหว่างจำนวนโทเคนกับค่า API

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

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

อนึ่ง การประเมิน LLM สำหรับภาษาไทยและภาษาอื่นในเอเชียตะวันออกเฉียงใต้ได้รับการจัดระบบมากขึ้นในช่วงหลัง นอกจากความริเริ่มระดับภูมิภาคอย่าง SEACrowd และ SEA-HELM แล้ว ในฝั่งภาษาไทยยังมีชุดข้อมูลการทำตามคำสั่งอย่าง WangchanThaiInstruct และเบนช์มาร์กที่วัดความสามารถพื้นฐานและความเข้าใจเชิงวัฒนธรรมเผยแพร่ออกมาแล้ว ในการเลือกโมเดล จึงคุ้มค่าที่จะอ้างอิงการประเมินภาษาในภูมิภาคเหล่านี้ ไม่ใช่แค่เบนช์มาร์กที่เน้นภาษาอังกฤษ

ภาษาเวียดนาม — วรรณยุกต์ที่หลุดหาย

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

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

จะรับคำถามภายในองค์กรที่มีหลายภาษาอย่างไร

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

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

งานที่ยังเหลืออยู่แม้จะทำอัตโนมัติแล้ว

เหตุผลใหญ่ที่สุดที่ทำให้การตัดสินใจลงทุนในระบบแปลอัตโนมัติผิดพลาด คือการไม่ได้นับพื้นที่ที่ทำอัตโนมัติไม่ได้

ตัวอักษรในภาพ — อยู่นอกระยะยิงของการแปลข้อความ

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

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

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

ปัญหา “อ่านออกแต่ไม่ทำตาม”

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

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

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

การออกแบบฝั่งที่ทำให้เกิดการใช้จริง

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

สาเหตุคลาสสิกที่ทำให้การอบรมด้าน Generative AI ไม่ยั่งยืน ได้สรุปไว้ใน4 สาเหตุที่การอบรม Generative AI ไม่ติดในองค์กร เพราะไม่ใช่แค่ระบบแปลอัตโนมัติ แต่ความริเริ่มที่ใช้ AI ผลักดันงานอัตโนมัติทั้งหมดล้วนชนกำแพงเดียวกัน จึงควรกันโควตาสำหรับการอบรมไว้ในแผนการนำระบบมาใช้ตั้งแต่ต้น

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

ประมาณการต้นทุนสำหรับโรงงานญี่ปุ่นขนาดกลางในไทย

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

เงื่อนไขตั้งต้น

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

เปรียบเทียบ 3 สถานการณ์

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

ชั่วโมงงานตรวจสอบของผู้อนุมัติถูกคิดในจำนวนเท่ากันทั้งในกรณีจ้างแปลภายนอก 100% และกรณีแบ่งตามคลาส เพราะการลงนามอนุมัติของคลาส A และคลาส C เกิดขึ้นไม่ว่าใครจะเป็นคนแปล และไม่ได้หายไปเพียงเพราะส่งออกไปให้ภายนอก คอลัมน์ AI อัตโนมัติ 100% ว่างเปล่าเพียงคอลัมน์เดียว ก็เพราะสถานการณ์นี้ไม่ได้จัดที่นั่งสำหรับการอนุมัติไว้ตั้งแต่แรก ไม่ใช่ว่าถูกกว่า แต่คือการข้ามขั้นตอน อนึ่ง กรณีจ้างแปลภายนอก 100% นั้นคำนวณบนสมมติฐานว่าส่งข้อความ UI หน้างานของคลาส D ออกไปให้ภายนอกด้วยเพื่อความสะดวกในการเปรียบเทียบ และรวมข้อจำกัดด้านความกว้างของการแสดงผลไว้ในข้อกำหนดการสั่งงาน คอลัมน์นี้จึงไม่ได้ลงค่าใช้จ่ายแก้ไขการแสดงผลล้นกรอบไว้

วิธีอ่านตาราง

กรณีจ้างแปลภายนอก 100% ค่าใช้จ่ายโดยตรงโดดสูงกว่าอย่างเห็นได้ชัด ราว 89% ของยอดรวมคือเงินที่จ่ายให้บริษัทแปล ที่เหลือคือชั่วโมงงานภายใน การบริหารจัดการง่าย แต่โครงสร้างเป็นแบบที่ปริมาณเพิ่มแล้วค่าใช้จ่ายเพิ่มตาม

กรณี AI อัตโนมัติ 100% ค่าใช้จ่ายโดยตรงลดลงอย่างมหาศาล แต่การตรวจเทียบคำศัพท์และการแก้ย้อนกลับกลับพองขึ้นถึง 950,000 THB ตรงนี้รวมชั่วโมงงานในการแก้เอกสารคลาส A ที่คำศัพท์ไม่นิ่งย้อนหลัง ออกฉบับใหม่ และแจกจ่ายใหม่ ค่าแก้ไขการแสดงผล UI ที่ล้นกรอบ 250,000 THB ปรากฏในคอลัมน์นี้เพียงคอลัมน์เดียวจาก 3 สถานการณ์ ก็เพราะไม่มีคู่สัญญาที่จะรับข้อจำกัดด้านความกว้างของการแสดงผลไปเป็นข้อกำหนด

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

กรณีแบ่งตามคลาส คงชั่วโมงงานอนุมัติ 252,000 THB ไว้เท่ากับสถานการณ์จ้างภายนอก ขณะที่ลดทั้งค่าใช้จ่ายโดยตรงและการแก้ย้อนกลับ การอนุมัติไม่ใช่เป้าหมายของการลดทอน แต่เป็นต้นทุนที่ตั้งใจคงไว้ เพราะคลังคำศัพท์ทำงานได้ผล การแก้ย้อนกลับจากการตรวจเทียบคำศัพท์จึงลดลงเหลือ 154,600 THB และชั่วโมงงานอธิบายตอนตรวจประเมินก็อยู่ที่ 20,000 THB เพราะมีประวัติการอนุมัติเหลือไว้

สิ่งที่ไม่ได้เขียนไว้ในประมาณการนี้

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

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

ขั้นตอนการนำไปใช้ให้ครบรอบใน 90 วัน

การหมุนให้ครบ 1 รอบใน 90 วันเพื่อให้ได้ค่าที่วัดจริง เร็วกว่าการวางแผนใหญ่โต ต่อไปนี้คือแนวทางดำเนินการแบบโครงสร้างขั้นต่ำ

วันที่ 1-30 สำรวจสถานะปัจจุบันและแบ่งคลาส

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

จากนั้นจัดเอกสารที่เขียนออกมาลงใน 4 คลาส งานนี้ให้ทำร่วมกัน 3 ฝ่าย คือประกันคุณภาพ ฝ่ายผลิต และฝ่ายบริหาร ถ้าทำคนเดียวจะเกิดความลังเลตรงเส้นแบ่งระหว่างคลาส A กับคลาส C เสมอ และในเวลาเดียวกัน ให้นับสัดส่วนของเอกสารที่มีตัวอักษรในภาพไว้ตรงนี้ด้วย

วันที่ 31-60 สร้างคลังคำศัพท์และนำร่องคลาส B

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

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

วันที่ 61-90 วัด TTE และทดลองคลาส A

เดือนที่ 3 ให้ทดลองรูปแบบร่างคำแปลบวกการอนุมัติโดยมนุษย์ในคลาส A จำกัดเป้าหมายไว้ที่เอกสารมาตรฐานการทำงานที่มีการแก้ไขบ่อยเพียงไม่กี่ฉบับ แล้ววัด TTE จริงตรงนี้ เทียบกับกรณีแปลจากกระดาษเปล่า

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

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

ระบบแปลภาษาอัตโนมัติในองค์กรมอบหมายให้เครื่องทำได้ถึงไหน

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

ค่าใช้จ่ายของ AI แปลภาษาอยู่ที่ประมาณเท่าไร

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

AI สรุปการประชุมใช้กับที่ประชุมที่ปนภาษาญี่ปุ่นกับภาษาไทยได้ไหม

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

ทำไมเฉพาะภาษาไทยที่คุณภาพคำแปลไม่นิ่ง

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

ควรสร้างคลังคำศัพท์อย่างไร

มีหลักการ 3 ข้อ ข้อแรก เริ่มจากคำที่พบบ่อยราว 200 คำ ถ้าเล็งความครบถ้วนจะไม่มีวันจบ ข้อที่สอง คำแปลให้ตัดสินโดยถามหัวหน้างานในสายการผลิต ไม่ใช่เปิดพจนานุกรม (เหตุผลเขียนไว้แล้วในหัวข้อ “อ่านออกแต่ไม่ทำตาม” ด้านบน) ข้อที่สาม สร้างกลไกที่ดึงคำจากคำแปลที่ได้รับอนุมัติมาเพิ่มเข้าคลังโดยอัตโนมัติ ถ้าพยายามดูแลด้วยแรงคนอย่างเดียว ครึ่งปีการอัปเดตก็จะหยุด

ควรทำอย่างไรกับสัญญาที่มีอยู่กับบริษัทแปล

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

การตรวจประเมิน ISO 9001 จะเรียกร้องอะไรบ้าง

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

สรุป

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

หมัดที่ใช้ได้สรุปเป็น 3 ข้อ ข้อแรก แบ่งเอกสารออกเป็น 4 คลาส คือเอกสารควบคุม เอกสารปฏิบัติการ เอกสารสู่ภายนอก และข้อความ UI หน้างาน แล้วเปลี่ยนการแบ่งงานระหว่างเครื่องกับคนตามแต่ละคลาส ข้อที่สอง ประกอบด้วย 3 ชั้น คือชั้นคำศัพท์ ชั้นสร้างคำแปล และชั้นอนุมัติ แล้วสร้างวงจรที่คำแปลซึ่งได้รับอนุมัติไหลกลับสู่ชั้นคำศัพท์ ข้อที่สาม เปลี่ยน KPI จากเปอร์เซ็นต์ความแม่นยำเป็น TTE (Time to Edit) แล้ววัดจริงว่างานลดลงจริงหรือไม่

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

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

แหล่งอ้างอิง

• Machine Translation 2026 Assessment (Translated)
• Best LLM for Translation 2026 (Alconost)
• What is the Best LLM for Translation (Lokalise)
• Compliance Best Practices for Translation: 2026 Guide (Adverbum)
• Assuring Quality Through Document Control (QualityWeb360)
• WangchanThaiInstruct: ชุดข้อมูลและการประเมินการทำตามคำสั่งภาษาไทย (arXiv:2508.15239)
• เบนช์มาร์กด้านวัฒนธรรมและความสามารถพื้นฐานสำหรับการพัฒนา LLM ภาษาไทย (arXiv:2410.04795)
• งานวิจัยเชิงประจักษ์ว่าด้วยตัวตัดโทเคนของ LLM หลายภาษา (arXiv:2606.15044)
• บริการแปลภาษาไทย (Kawamura International)