เอกสาร Word ภาษาไทยที่สร้างด้วย AI พังใน Microsoft Word: ทนายความชาวกรุงเทพฯ สร้างวิธีแก้ไข

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

นี่ไม่ใช่ปัญหาของ Claude ไม่ใช่ปัญหาของ Microsoft Word แต่เป็นช่องว่างระหว่างสิ่งที่เครื่องมือ AI รู้เกี่ยวกับการแสดงผลฟอนต์ไทยกับสิ่งที่ Microsoft Word ต้องการจริงๆ และมันส่งผลกระทบต่อไฟล์ .docx ที่สร้างด้วย AI ทุกไฟล์ที่มีข้อความภาษาไทย

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

ทำไม Preview ถึงไม่แสดงปัญหา

ส่วนที่หลอกลวงที่สุดของปัญหานี้คือที่ที่มันปรากฏขึ้น เมื่อคุณดูไฟล์ .docx ใน LibreOffice, macOS Preview หรือ Google Docs แอปพลิเคชันเหล่านั้นจะเดาข้อมูลฟอนต์ที่ขาดหายไป พวกมันเห็นตัวอักษรไทยและใส่ค่าเริ่มต้นที่สมเหตุสมผล เอกสารจึงดูดี

Microsoft Word ไม่เดา มันปฏิบัติตามข้อกำหนด XML ของเอกสารอย่างเคร่งครัด หากคุณสมบัติใดขาดหายไปจาก XML Word จะใช้ค่า fallback ของตัวเอง และค่า fallback ของ Word สำหรับภาษาไทยในเอกสารที่ระบุคุณสมบัติไม่ถูกต้องจะสร้างอาการที่พร้อมสินอธิบาย: ฟอนต์ที่หดตัวเหลือประมาณ 10pt แม้ว่าจะตั้งค่าเป็น 16pt การจัดรูปแบบตัวหนาที่ใช้กับตัวอักษรละตินแต่ไม่ใช่ตัวอักษรไทย และวรรณยุกต์กับสระที่แยกออกจากพยัญชนะที่ควรเป็นของมัน

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

สาเหตุหลัก: ช่องฟอนต์สองช่อง ใส่ข้อมูลแค่ช่องเดียว

Microsoft Word ประมวลผลฟอนต์ในระดับตัวอักษรมากกว่าในระดับ run ภายใน run ของข้อความแต่ละ run ในไฟล์ .docx มีคุณสมบัติฟอนต์แยกต่างหากสำหรับประเภทสคริปต์ที่แตกต่างกัน ตัวอักษรละติน (ภาษาอังกฤษ ตัวเลข เครื่องหมายวรรคตอน) จัดการโดยชุดคุณสมบัติ XML ชุดหนึ่ง: w:ascii และแอตทริบิวต์ที่เกี่ยวข้อง ภาษาไทยและสคริปต์ที่ซับซ้อนอื่นๆ จัดการโดยชุดแยกต่างหาก: w:cs (ฟอนต์สำหรับสคริปต์ที่ซับซ้อน), w:szCs (ขนาด), w:bCs (ตัวหนา), w:lang พร้อมการตั้งค่าแบบสองทิศทาง และคุณสมบัติที่เกี่ยวข้อง

เมื่อเครื่องมือ AI สร้างไฟล์ Word โดยใช้ python-docx ซึ่งเป็นไลบรารี Python มาตรฐานสำหรับสร้างไฟล์ .docx พวกมันจะตั้งค่าคุณสมบัติฝั่งละตินเท่านั้น ฝั่งสคริปต์ที่ซับซ้อนถูกปล่อยว่างไว้ ตัวอักษรไทยจึงตกไปยัง fallback font ที่ Word ใช้โดยค่าเริ่มต้น ซึ่งไม่ใช่ TH Sarabun New ขนาด 16pt แต่เป็นอะไรบางอย่าง ที่ขนาดต่างกัน และไม่รองรับตัวหนา

นี่ไม่ใช่บั๊กใน python-docx ไลบรารีถูกสร้างขึ้นโดยไม่ได้ให้ความสำคัญกับภาษาสคริปต์ที่ซับซ้อน การอธิบายสถานการณ์ของพร้อมสินถูกต้อง: เครื่องมือ AI ตะวันตกและไลบรารีที่พวกมันพึ่งพาไม่ได้ถูกสร้างขึ้นโดยคำนึงถึงภาษาไทย และผู้ใช้ภาษาไทยต้องจัดการกับชั้นเพิ่มเติมหนึ่งชั้นที่ไม่มีสำหรับผู้ใช้ที่ทำงานกับภาษา Latin-script ทั้งหมด

วิธีแก้ไข: เรียกฟังก์ชันเดียวก่อนบันทึก

พร้อมสินสร้างเครื่องมือชื่อ thai-docx เพื่อปิดช่องว่างนี้ หัวใจของมันคือฟังก์ชันชื่อ enforce_thai(doc) ที่คุณเรียกครั้งเดียว บน Document object ทันทีก่อนบันทึกไฟล์

สิ่งที่มันทำมีระบบ: มันผ่านทุก run ในเอกสาร ทั้งย่อหน้าเนื้อหา เซลล์ตาราง ส่วนหัว ส่วนท้าย styles และการตั้งค่าธีมเอกสาร และตั้งค่าคุณสมบัติฟอนต์สคริปต์ที่ซับซ้อนทุกที่ที่ขาดหายไป สำหรับ run ใดที่ไม่ได้ระบุขนาดฟอนต์เอง มันจะรับค่าจาก style แทนการกำหนดค่าตายตัว ดังนั้นหัวข้อจะยังคงขนาดที่ตั้งใจไว้แทนที่จะถูกแทนที่ด้วยขนาดเนื้อหา

ผลลัพธ์คือเอกสารที่ทุก run มีทั้งคุณสมบัติละตินและสคริปต์ที่ซับซ้อนถูกตั้งค่าไว้อย่างชัดเจน เมื่อ Microsoft Word เปิดไฟล์ ไม่มีอะไรเหลือให้เดาหรือใช้ค่า fallback อีกต่อไป

สิ่งที่เครื่องมือจัดการนอกจากการแสดงผลฟอนต์

พร้อมสินออกแบบ thai-docx รอบชุดปัญหาเต็มที่ปรากฏขึ้นเมื่อสร้างเอกสารกฎหมายไทยผ่าน AI คุณสมบัติฟอนต์เป็นปัญหาหลัก แต่มีปัญหาที่เกี่ยวข้องที่เกิดขึ้นในทางปฏิบัติ

Run ที่มีหลายภาษา เอกสารกฎหมายไทยมักมีประโยคที่ผสมภาษาไทยและอังกฤษ: ชื่อบริษัทในตัวอักษรโรมันภายในย่อหน้าภาษาไทย หรือคำภาษาอังกฤษตามด้วยคำอธิบายภาษาไทย เครื่องมือของพร้อมสินอนุญาตให้ตั้งค่าฟอนต์ละตินและไทยแยกกันอย่างอิสระภายใน run เดียวกัน เช่น Times New Roman สำหรับส่วนภาษาอังกฤษและ TH Sarabun New สำหรับภาษาไทย โดยไม่ต้องแยกข้อความออกเป็น run แยกต่างหากใน XML พื้นฐาน ซึ่งสำคัญสำหรับเอกสารที่ปฏิบัติตามมาตรฐานราชการไทย (TH Sarabun New, 16pt) ที่มีคำภาษาอังกฤษอยู่ในบรรทัด

การจัดข้อความไทยแบบชิดขอบ เมื่อย่อหน้าถูกตั้งค่าให้จัดชิดขอบ Word ต้องรู้ว่าคำภาษาไทยสิ้นสุดตรงไหนเพื่อแบ่งบรรทัดได้ถูกต้อง ข้อความไทยไม่มีช่องว่างระหว่างคำ Word จึงต้องระบุขอบเขตคำเอง เมื่อล้มเหลว มันจะยืดระยะห่างระหว่างตัวอักษรแต่ละตัวเพื่อเติมความกว้างบรรทัดแทนที่จะยืดระหว่างคำ เครื่องมือของพร้อมสินแทรกอักขระ zero-width space ที่ขอบเขตคำโดยใช้ตัวตัดคำภาษาไทย ให้จุดพักบรรทัดที่ Word ต้องการ หากไม่ได้ติดตั้งไลบรารีตัวตัดคำ ฟังก์ชันจะข้ามขั้นตอนนี้และเตือนแทนที่จะพัง

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

QA Scanner พร้อมสินรวม script ตรวจสอบ verify_thai_docx.py ที่ตรวจสอบเอกสารที่บันทึกแล้วและรายงาน run ใดที่ยังขาดคุณสมบัติสคริปต์ที่ซับซ้อนที่จำเป็น โดยระบุว่าขาดอะไรและจะเกิดอาการแสดงผลอะไรใน Word คำแนะนำของเขาตรงไปตรงมา: อย่าเชื่อ preview รัน scanner exit code ศูนย์หมายความว่าเอกสารพร้อมส่ง

บทเรียนที่ใหญ่กว่าสำหรับบริษัทวิชาชีพไทย

ปัญหาที่พร้อมสินค้นพบและแก้ไขเป็นตัวแทนของรูปแบบที่กว้างกว่า ภาษาไทยเป็น complex script language ในความหมายทางเทคนิค: ตัวอักษรเรียงในแนวตั้ง วรรณยุกต์โต้ตอบกับสระและพยัญชนะในลักษณะที่ต้องให้ rendering engine จัดการตำแหน่งอย่างชัดเจน และขอบเขตคำไม่ได้ถูกทำเครื่องหมายในระบบการเขียน โครงสร้างพื้นฐาน AI ส่วนใหญ่ ตั้งแต่โมเดลจนถึงไลบรารีที่สร้าง output ถูกสร้างขึ้นสำหรับภาษา Latin-script ก่อน

สำหรับบริษัทกฎหมายหรือบัญชีไทยที่ใช้เครื่องมือ AI เพื่อร่างเอกสาร นี่หมายความว่าต้องมีชั้นการตรวจสอบเพิ่มเติมที่บริษัท English-language ไม่ต้องเผชิญ สัญญาที่ร่างเป็นภาษาอังกฤษโดย Claude และบันทึกเป็นไฟล์ Word ทำงานตรงตามที่ปรากฏ workflow เดียวกันสำหรับเอกสารภาษาไทยต้องการการตรวจสอบ output ในระดับ rendering ไม่ใช่แค่ระดับเนื้อหา

เครื่องมือของพร้อมสินจัดการสิ่งนี้ที่ต้นทาง: patch ไฟล์ก่อนที่มันจะออกจากบริษัท และใช้ scanner เพื่อยืนยันว่าถูกต้องก่อนที่จะถึงลูกค้า

FirmFlow เกี่ยวข้องอย่างไร

workflow เอกสารของ FirmFlow ทำงานภายในแพลตฟอร์มแทนที่จะสร้างไฟล์ Word แบบ standalone ผ่าน python-docx เมื่อสัญญาถูกวิเคราะห์ผ่าน Document Analyser เมื่อรายงานถูกร่างผ่าน Report Drafting หรือเมื่อบันทึกการประชุมถูกบันทึกผ่าน Meeting Summariser output จะอยู่ในสภาพแวดล้อม rendering ที่ควบคุมแล้ว ซึ่งคุณสมบัติฟอนต์ไทยถูกจัดการอย่างสม่ำเสมอ

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

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

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