Machine translation

Machine translation คือการให้คอมพิวเตอร์แปลข้อความจากภาษาหนึ่งไปเป็นอีกภาษาหนึ่งโดยอัตโนมัติ คือรับข้อความต้นทางเข้าไปแล้วคืนข้อความปลายทางออกมาโดยไม่ต้องมีคนนั่งแปลทีละประโยค เป็นงานพื้นฐานงานหนึ่งของ nlp ที่คนทำงานไทยเจอทุกวันตั้งแต่ปุ่มแปลหน้าเว็บ ไปจนถึงระบบหลังบ้านที่บริษัทเรียกใช้ผ่าน API เพื่อแปลเอกสารทีละพันหน้า ชื่อเรียกของแต่ละวิธีติดมากับเทคนิคที่ใช้ วิธีที่เขียนกฎไวยากรณ์และพจนานุกรมไว้ล่วงหน้าเรียกว่า rule-based วิธีที่อาศัยสถิติจากคลังข้อความคู่ภาษาเรียกว่า statistical machine translation ส่วนวิธีที่ใช้โครงข่ายประสาทเทียมแบบ deep-learning เรียกว่า neural machine translation หรือย่อว่า NMT

เอกสารของ Google Cloud Translation ให้ภาพที่จับต้องได้ของยุค neural โดยระบุว่า NMT รุ่นมาตรฐานของ Google พัฒนาต่อยอดมาจากระบบแปลด้วย neural network ที่ Google เปิดตัวในเดือนพฤศจิกายน 2016 พร้อมการปรับปรุงอีกหลายอย่าง model ตัวนี้มี model ID ว่า general/nmt และเรียกใช้แบบไม่ปรับแต่งได้ทั้งผ่าน Cloud Translation - Basic API และ Cloud Translation - Advanced API โดยเอกสารเขียนกำกับไว้ว่า Cloud Translation - Basic ไม่รองรับ model ที่ปรับแต่งแล้ว จุดที่ระบบแปลเฉพาะทางลงแรงเป็นพิเศษคือการคุมศัพท์ให้ออกมาเหมือนกันทุกครั้ง เอกสารอีกหน้าของบริการเดียวกันอธิบายว่า glossary คือ dictionary ที่ลูกค้าทำขึ้นเอง ซึ่ง Cloud Translation API ใช้แปลศัพท์เฉพาะทางของลูกค้าให้ตรงกันอย่างสม่ำเสมอ แล้วยกกรณีใช้งานไว้ เช่น ชื่อผลิตภัณฑ์อย่าง Google Home ที่ต้องแปลออกมาเป็น Google Home คำกำกวมอย่างคำว่า bat ที่หมายถึงอุปกรณ์กีฬาหรือสัตว์ก็ได้ และคำยืมอย่าง bouillabaisse ในภาษาฝรั่งเศสที่แปลเป็นภาษาอังกฤษแล้วยังเป็น bouillabaisse เหมือนเดิม เอกสารหน้านั้นยังระบุอีกสองข้อว่าโดยค่าเริ่มต้นการจับคู่คำใน glossary จะแยกตัวพิมพ์เล็กพิมพ์ใหญ่ ซึ่งตอนใช้งานสั่งให้ไม่สนตัวพิมพ์สำหรับทุกรายการก็ได้ และ Cloud Translation จะข้ามคำบางคำที่ใส่ไว้ใน glossary ซึ่งคำกลุ่มนั้นเรียกว่า stopwords โดยเอกสารอธิบายต่อว่าเวลาแปลคำกลุ่มนี้ ระบบยังแปลตามปกติแต่จะไม่หยิบรายการใน glossary ที่ตรงกันมาบังคับคำแปล ส่วนยุคที่ llm เข้ามาอยู่ในภาพนั้นเห็นได้ชัดจากงานประเมินกลางอย่าง WMT รายงาน Findings of the WMT24 General Machine Translation Shared Task ที่เผยแพร่ในการประชุม WMT เดือนพฤศจิกายน 2024 ใช้ชื่อรองว่า The LLM Era Is Here but MT Is Not Solved Yet บทคัดย่อระบุว่าผู้เข้าร่วมถูกขอให้สร้างระบบแปลสำหรับคู่ภาษาใดก็ได้ใน 11 คู่ภาษา เพื่อประเมินบนชุดทดสอบที่ประกอบด้วยโดเมนต่างกันสามถึงห้าโดเมน นอกจากระบบของผู้เข้าร่วมแล้ว คณะผู้จัดยังเก็บผลแปลจาก LLM 8 ตัวและผู้ให้บริการแปลออนไลน์ 4 ราย แล้วประเมินผลด้วยผู้ตรวจมืออาชีพผ่านโพรโทคอลใหม่ชื่อ Error Span Annotations หรือ ESA งานรุ่นถัดมาคือ WMT25 ที่เผยแพร่เดือนพฤศจิกายน 2025 เปิดให้ผู้เข้าร่วมสร้างระบบสำหรับคู่ภาษาใดก็ได้ใน 30 คู่ภาษา แล้วจัดประเมินด้วยผู้ตรวจมืออาชีพบนครึ่งหนึ่งของคู่ภาษาเหล่านั้น บนชุดทดสอบที่ครอบคลุมสี่ถึงห้าโดเมน รวมระบบที่ประเมินทั้งหมด 60 ระบบ แบ่งเป็นระบบที่ผู้เข้าร่วมส่งเข้ามา 36 ระบบ และอีก 24 ระบบที่คณะผู้จัดเก็บผลแปลจาก LLM และผู้ให้บริการแปลออนไลน์ยอดนิยม ปีนั้นเน้นทำชุดทดสอบให้ยากขึ้นด้วยเทคนิคสุ่มตามระดับความยากและใช้ต้นฉบับที่ซับซ้อนกว่าเดิม จนใช้ชื่อรองว่า Time to Stop Evaluating on Easy Test Sets

สำหรับคนทำงานไทย คำถามที่ตอบยากที่สุดคือควรใช้บริการแปลเฉพาะทางหรือสั่ง LLM ให้แปล และคำตอบขึ้นกับเงื่อนไขหน้างานมากกว่าที่หลายคนคิด เปเปอร์ชื่อ Can General-Purpose Large Language Models Generalize to English-Thai Machine Translation? ที่ส่งขึ้น arXiv เมื่อ 22 ตุลาคม 2024 ทดสอบเรื่องนี้กับคู่ภาษาอังกฤษไทยโดยตรง บทคัดย่อเขียนว่า LLM ทำได้ดีในงานทั่วไปแต่มีปัญหาเรื่องการ generalize ในสภาพที่ทรัพยากรน้อยและกำลังประมวลผลน้อย และสรุปผลไว้ว่าภายใต้ข้อจำกัดด้านการคำนวณที่เข้มงวดขึ้น เช่น การทำ 4-bit quantization นั้น LLM แปลได้ไม่ดีพอ ในทางกลับกัน model เฉพาะทางที่ใช้ทรัพยากรพอกันหรือน้อยกว่ากลับทำได้ดีกว่า LLM อย่างสม่ำเสมอ ข้อควรระวังคือ LLM ที่เปเปอร์นี้ทดสอบจริงมีตัวเดียว ข้อสรุปนี้จึงยังไม่ครอบคลุม LLM ทุกตัวในตลาด ฝั่งการทดลองใช้ Llama-3 8B ที่ระดับ quantization ต่างกันเทียบกับ model แปลเฉพาะทาง NLLB-600M และ NLLB-3.3B บนชุดข้อมูล scb-mt-en-th-2020 ซึ่งมีคู่ประโยคอังกฤษไทย 1,001,752 คู่ และสุ่มมาใช้ 63,982 คู่เพื่อให้ขนาดตัวอย่างเท่ากับชุดข้อมูล code-switching กับชุดข้อมูลแปลทางการแพทย์แบบ code-switching ที่เป็นข้อมูลปิดจำนวน 63,982 คู่ประโยคซึ่งคงศัพท์แพทย์ภาษาอังกฤษไว้ วัดด้วยตัววัดมาตรฐานของงานแปล เช่น BLEU METEOR และ CER พร้อมวัด CS boundary F1 score เพิ่ม สิ่งที่เปเปอร์เขียนไว้ตรงๆ และควรอ่านคู่กันคือ model ที่ทำคะแนนดีที่สุดสองตัวคือ NLLB-3.3B และ NLLB-600M กลับเป็นตัวที่มี error ประเภทลืมคงคำเดิมไว้มากที่สุด แปลว่าคะแนนรวมที่ดีกว่าไม่ได้การันตีว่าจะไม่พลาดในจุดที่เอกสารไทยแคร์ที่สุด ซึ่งก็คือศัพท์เทคนิคภาษาอังกฤษที่ตั้งใจปล่อยไว้ไม่แปล ข้อควรระวังในงานจริงจึงมีสามชั้น ชั้นแรกคือผลแปลที่อ่านลื่นไม่ได้แปลว่าตรงกับต้นฉบับ ความเสี่ยงที่ระบบเติมเนื้อหาที่ไม่มีในต้นทางเข้ามาเองหรือ hallucination ยังต้องมีคนอ่านเทียบ โดยเฉพาะสัญญาและเอกสารทางการแพทย์ที่คำเดียวเปลี่ยนความหมายทั้งฉบับ ชั้นที่สองคือแนวโน้มที่คนจะเชื่อผลของระบบอัตโนมัติมากเกินไปหรือ automation-bias ซึ่งทำให้ขั้นตรวจกลายเป็นพิธีกรรม ชั้นที่สามคือคุณภาพที่ไม่เท่ากันระหว่างภาษา เพราะผลที่ดีในคู่ภาษาใหญ่ไม่ได้ย้ายมาลงคู่ที่มีข้อมูลน้อยกว่าเสมอไป ซึ่งเกี่ยวเนื่องกับเรื่องที่หน้า cross-lingual-consistency-gap บันทึกไว้ คือโมเดลตัวเดียวกันทำงานไม่เหมือนกันเมื่อเปลี่ยนภาษาของคำสั่ง ทางที่ปลอดภัยกว่าคือทดลองแปลเอกสารจริงของเราเองสักชุด แล้วเทียบผลก่อนตัดสินใจย้ายงานทั้งกองไปทางใดทางหนึ่ง

ตัวอย่างจากบทสนทนาจริง

ผู้จัดการฝ่ายส่งออก: คู่มือสินค้าสามร้อยหน้าที่ต้องส่งลูกค้าญี่ปุ่นสิ้นเดือนนี้ ผมโยนเข้าระบบแปลรวดเดียวเลยได้ไหมครับ จะได้ไม่ต้องจ้างนักแปล

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

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

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

ฝ่ายการตลาด: งั้นผมเลือกเอกสารที่เราเคยแปลแล้วมาสิบไฟล์ให้ลองเทียบกันดูนะครับ จะได้รู้ว่าดีกว่าจริงหรือแค่รู้สึกไปเอง

ระวังสับสนกับ

• whisper : speech-to-text คือการถอดเสียงพูดออกมาเป็นตัวหนังสือในภาษาเดิม ส่วน machine translation คือการเปลี่ยนข้อความจากภาษาหนึ่งไปเป็นอีกภาษาหนึ่ง ข้อควรรู้คือเอกสารของ Whisper ระบุว่าตัวมันเองมีโหมด translate ที่แปลเสียงพูดภาษาอื่นออกมาเป็นข้อความภาษาอังกฤษได้ในตัว แต่แปลได้ทางเดียวคือปลายทางเป็นภาษาอังกฤษเท่านั้น งานประชุมข้ามชาติที่ต้องได้ผลเป็นภาษาไทยจึงยังต้องต่อสองอย่างนี้เข้าด้วยกัน คือถอดเสียงก่อนแล้วค่อยแปล ซึ่งแปลว่าถ้าขั้นถอดเสียงฟังผิด ขั้นแปลจะผิดตามโดยที่ผลลัพธ์ยังอ่านลื่นเหมือนเดิม
• prompt : การสั่ง LLM ให้แปลผ่าน prompt กับการเรียกใช้บริการแปลเฉพาะทางต่างกันที่ช่องทางป้อนข้อมูลกำกับ ฝั่งบริการแปลมีที่ให้ยื่นรายการศัพท์เข้าไปคุมคำตอบอย่าง glossary ซึ่งเอกสารของ Google อธิบายว่าเป็น dictionary ที่ลูกค้าทำขึ้นเองเพื่อให้ศัพท์เฉพาะทางถูกแปลตรงกันอย่างสม่ำเสมอ โดยมีคำบางกลุ่มที่เรียกว่า stopwords ซึ่งระบบจะไม่ใช้รายการใน glossary มาจับคู่ให้ ส่วนฝั่ง LLM เราพิมพ์บริบทและน้ำเสียงที่ต้องการลงไปได้อิสระกว่า แต่ความคงเส้นคงวาข้ามไฟล์ต้องมาจากวินัยที่เราวางเอง
• Post-editing : post-editing คือขั้นที่คนเข้ามาเกลาผลแปลของเครื่องให้ถูกต้องและอ่านลื่นก่อนนำไปใช้จริง เป็นแรงงานคน ไม่ใช่ตัวการแปลของเครื่อง เวลาตั้งงบและตั้งกำหนดส่งจึงควรนับสองขั้นนี้แยกกัน เพราะเอกสารที่เครื่องแปลจบในไม่กี่นาที อาจยังกินเวลาคนอีกหลายวันในขั้นเกลา
• ocr : OCR คือการอ่านตัวอักษรออกจากภาพหรือไฟล์สแกนให้กลายเป็นข้อความที่แก้ไขได้ โดยยังอยู่ในภาษาเดิม ส่วน machine translation รับข้อความที่อ่านออกมาแล้วไปแปลต่อ เอกสารราชการไทยที่ส่งมาเป็นไฟล์สแกนจึงต้องผ่าน OCR ก่อน และความผิดพลาดจากขั้นนั้นจะไหลต่อเข้าไปอยู่ในผลแปลด้วย