Air Waybill ตามธรรมเนียม IATA เป็นเอกสารภาษาอังกฤษ รูปแบบข้อความ Cargo-IMP มาตรฐานใช้ข้อความ ASCII และแบบฟอร์ม AWB ที่พิมพ์มีป้ายกำกับฟิลด์เป็นภาษาอังกฤษ แต่ในทางปฏิบัติ เอกสารขนส่งทางอากาศของไทยมีอักษรไทยเป็นประจำ ชื่อผู้ส่งสินค้าเขียนเป็นภาษาไทย ที่อยู่ผู้รับสินค้าผสมภาษาไทยและอังกฤษ คำอธิบายลักษณะสินค้ารวมชื่อสินค้าภาษาไทย และเอกสารเสริมที่แนบกับ AWB เช่น รายการบรรจุ ใบแจ้งหนี้ ใบรับรองสุขอนามัยพืช มักเป็นภาษาไทยทั้งหมด
จนถึงตอนนี้ เครื่องมือแยกวิเคราะห์ AWB ถือว่าข้อความภาษาไทยเป็นสัญญาณรบกวน โดยอาจข้ามไป แทนที่ด้วยอักขระที่อ่านไม่ออก หรือไม่สามารถประมวลผลเอกสารได้เลย วันนี้เราประกาศการรองรับภาษาไทยแบบเต็มรูปแบบใน AWB Intelligence API ของ KabyTech อักขระไทยถูกรู้จำ ดึงข้อมูล และส่งคืนเป็นข้อความ UTF-8 ที่เข้ารหัสถูกต้องใน JSON response ด้วยความถูกต้องระดับฟิลด์เท่ากับที่เราบรรลุได้กับเอกสารภาษาอังกฤษล้วน
แม้จะเป็นธรรมเนียมของ IATA แต่ข้อความภาษาไทยปรากฏบนเอกสารขนส่งทางอากาศด้วยเหตุผลเชิงปฏิบัติหลายประการ:
การแยกวิเคราะห์เอกสารที่มีทั้งข้อความภาษาไทยและอังกฤษยากกว่าการแยกวิเคราะห์ภาษาใดภาษาหนึ่งอย่างมาก นี่คือเหตุผล:
ภาษาไทยและอังกฤษใช้ระบบการเขียนที่แตกต่างกันโดยสิ้นเชิง ภาษาอังกฤษใช้ตัวอักษรละตินที่มีขอบเขตคำชัดเจน (ช่องว่าง) ภาษาไทยใช้อักษรไทย ซึ่งเป็น abugida — พยัญชนะมีสระในตัวที่ถูกเปลี่ยนโดยเครื่องหมายกำกับเสียงที่วางอยู่เหนือ ใต้ ก่อน หรือหลังพยัญชนะฐาน ที่สำคัญคือภาษาไทยไม่ใช้ช่องว่างระหว่างคำ ช่องว่างในข้อความภาษาไทยบ่งชี้ขอบเขตประโยคหรือวลี ไม่ใช่ขอบเขตคำ
เมื่อข้อความภาษาไทยและอังกฤษปรากฏในบรรทัดเดียวกัน เช่น ชื่อผู้ส่งสินค้า "บริษัท Thai Silk Export จำกัด" ตัวแยกวิเคราะห์ต้องสลับระหว่างโมเดลการรู้จำสองตัวที่แตกต่างกันโดยสิ้นเชิงในระดับตัวอักษร โมเดลที่ฝึกมาสำหรับภาษาอังกฤษเท่านั้นจะพยายามตีความอักขระไทยเป็นอักขระละตินที่บิดเบี้ยว ทำให้ได้ผลลัพธ์ที่ไม่มีความหมาย
อักษรไทยมีเครื่องหมายกำกับเสียง (วรรณยุกต์ สระ) ที่วางอยู่เหนือหรือใต้พยัญชนะฐาน ในเอกสารที่สแกน โดยเฉพาะที่ความละเอียดต่ำ เครื่องหมายเหล่านี้อาจถูกสับสนกับสัญญาณรบกวนของเอกสาร (ฝุ่น ร่องรอยการพิมพ์ การเสื่อมจากแฟกซ์) เอนจิน OCR ทั่วไปอาจตัดเครื่องหมายเหล่านี้ออกเพราะคิดว่าเป็นสัญญาณรบกวน ซึ่งเปลี่ยนความหมายของคำอย่างรุนแรง ตัวอย่างเช่น ตัวอักษรไทยสำหรับ "ข้าว" กับ "ข่าว" แตกต่างกันเพียงวรรณยุกต์
ที่อยู่ภาษาไทยบน AWB มักสลับภาษาภายในฟิลด์เดียว ที่อยู่อาจอ่านว่า: "123/45 ซอยสุขุมวิท 55 Sukhumvit Rd, Watthana, Bangkok 10110" ตัวแยกวิเคราะห์ต้องจัดการกับการเปลี่ยนจากชื่อซอยภาษาไทยเป็นชื่อถนนภาษาอังกฤษภายในบรรทัดที่อยู่เดียว โดยรักษาลำดับการอ่านและการแบ่งส่วนฟิลด์ที่ถูกต้อง
วิธีการของเราใช้ท่อส่ง 3 ขั้นตอนที่ออกแบบมาเฉพาะสำหรับการประมวลผลเอกสารหลายภาษา:
ก่อนพยายามรู้จำข้อความ เราวิเคราะห์เค้าโครงเอกสารเพื่อระบุพื้นที่ข้อความและภาษาที่น่าจะเป็น ใช้คุณสมบัติทางสายตา: อักษรไทยมีโปรไฟล์แนวตั้งที่โดดเด่น (ตัวขึ้นสูงจากเครื่องหมายสระ ตัวลงจากพยัญชนะบางตัว) ที่แตกต่างจากข้อความภาษาละติน เราจำแนกแต่ละพื้นที่ข้อความเป็น ภาษาไทยเป็นหลัก ภาษาอังกฤษเป็นหลัก หรือผสม และส่งไปยังโมเดลรู้จำที่เหมาะสม
เรารันโมเดล OCR เฉพาะทาง 2 ตัวแบบขนาน: ตัวหนึ่งปรับแต่งสำหรับอักษรไทย (รวมถึงพยัญชนะ 44 ตัว รูปสระ 32 แบบ วรรณยุกต์ 4 ตัว และตัวเลขไทย) และอีกตัวปรับแต่งสำหรับข้อความภาษาอังกฤษและตัวเลขละติน สำหรับพื้นที่ผสม เราใช้โมเดลหลอมรวมที่จัดการการสลับภาษาในระดับตัวอักษร โมเดลหลอมรวมถูกฝึกบนชุดข้อมูลเอกสารขนส่งทางอากาศของไทยจริงกว่า 50,000 ฉบับ จึงเข้าใจรูปแบบเฉพาะของการผสมภาษาไทย-อังกฤษที่เกิดขึ้นในบริบท AWB
หลังจากรู้จำข้อความ เราใช้กฎการทำให้เป็นมาตรฐานระดับฟิลด์ ตัวอย่างเช่น หมายเลข AWB เป็นตัวเลขเสมอไม่ว่าข้อความโดยรอบจะเป็นภาษาอะไร รหัสสนามบิน IATA เป็นอักขระละตินสามตัวเสมอ ค่าน้ำหนักใช้ตัวเลขละตินเสมอ ข้อความภาษาไทยมักปรากฏเฉพาะในฟิลด์ชื่อ ที่อยู่ และลักษณะสินค้า การใช้ข้อจำกัดระดับฟิลด์เหล่านี้ช่วยแก้ไขข้อผิดพลาดในการรู้จำที่คลุมเครือในระดับตัวอักษร
เราทดสอบการรองรับภาษาไทยกับชุดทดสอบ AWB 500 ฉบับ: เอกสารภาษาอังกฤษล้วน 250 ฉบับ และเอกสารที่มีข้อความภาษาไทย 250 ฉบับ (ตั้งแต่มีอักขระไทยเพียงเล็กน้อยจนถึงเอกสารสองภาษาเต็มรูปแบบ)
| ตัวชี้วัด | AWB ภาษาอังกฤษล้วน | AWB ภาษาไทย/ผสม |
|---|---|---|
| ความถูกต้องฟิลด์โดยรวม | 97.8% | 96.9% |
| ความถูกต้องหมายเลข AWB | 99.9% | 99.9% |
| ความถูกต้องชื่อผู้ส่ง | 96.2% | 95.1% |
| ความถูกต้องชื่อผู้รับ | 96.5% | 95.4% |
| ความถูกต้องที่อยู่ | 94.8% | 93.2% |
| ความถูกต้องเส้นทาง | 99.7% | 99.7% |
| ความถูกต้องน้ำหนัก/จำนวนชิ้น | 99.4% | 99.3% |
| ความถูกต้อง Rate Description | 97.1% | 96.5% |
| ความถูกต้องลักษณะสินค้า | 95.8% | 94.6% |
| เวลาประมวลผล (มัธยฐาน) | 1.4 วินาที | 1.7 วินาที |
ช่องว่างความถูกต้องระหว่างเอกสารภาษาอังกฤษกับเอกสารภาษาไทย/ผสมน้อยกว่า 1 เปอร์เซ็นต์ในฟิลด์ส่วนใหญ่ ช่องว่างที่ใหญ่ที่สุดอยู่ที่ความถูกต้องของที่อยู่ (1.6 เปอร์เซ็นต์) ซึ่งสะท้อนความซับซ้อนโดยธรรมชาติของรูปแบบที่อยู่ไทยมากกว่าข้อจำกัดในการรู้จำภาษา ฟิลด์ที่มีโครงสร้างอย่างหมายเลข AWB เส้นทาง และค่าน้ำหนักแสดงความถูกต้องที่แทบจะเหมือนกันไม่ว่าเอกสารจะเป็นภาษาอะไร
เวลาประมวลผลเพิ่มขึ้นประมาณ 300 มิลลิวินาทีสำหรับเอกสารภาษาไทย/ผสม เนื่องจากท่อส่งการรู้จำด้วยโมเดลคู่ ที่ 1.7 วินาทีเวลาประมวลผลมัธยฐาน ยังคงอยู่ภายใน SLA ที่น้อยกว่า 2 วินาที
การรองรับภาษาไทยมีผลกระทบเชิงปฏิบัติหลายประการสำหรับลูกค้าของเรา:
การรองรับภาษาไทยเปิดใช้งานโดยค่าเริ่มต้นสำหรับทุกบัญชี KabyTech ไม่ต้องเปลี่ยนแปลงการกำหนดค่า เมื่อคุณส่งเอกสารที่มีข้อความภาษาไทย API จะตรวจจับส่วนผสมภาษาโดยอัตโนมัติและใช้ท่อส่งการรู้จำที่เหมาะสม JSON response จะมีฟิลด์ language_detected ที่ระบุว่าพบข้อความภาษาไทยในเอกสารหรือไม่
หากคุณต้องการบังคับการประมวลผลภาษาอังกฤษเท่านั้น (เช่น เพื่อการทดสอบเปรียบเทียบ) คุณสามารถส่งพารามิเตอร์ language_hint: "en" ใน API request แต่สำหรับการใช้งานจริง เราแนะนำให้เปิดการตรวจจับอัตโนมัติไว้
ภาษาไทยและอังกฤษเป็นสองภาษาแรกที่เรารองรับอย่างสมบูรณ์ สะท้อนการมุ่งเน้นตลาดขนส่งทางอากาศของไทย ขณะนี้เรากำลังพัฒนาการรองรับอักขระจีน (ตัวย่อและตัวเต็ม) ซึ่งปรากฏบ่อยบน AWB สำหรับเส้นทางไทย-จีน — เส้นทางขนส่งสินค้าทางอากาศที่ใหญ่ที่สุดสำหรับสินค้าเน่าเสียง่ายของไทย คาดว่าการรองรับภาษาจีนจะพร้อมใน Q3 2026
นอกเหนือจากนั้น แผนงานของเรารวมถึงภาษาญี่ปุ่น เกาหลี และเวียดนาม ซึ่งครอบคลุมเส้นทางขนส่งทางอากาศหลักที่เข้าออกประเทศไทย แต่ละภาษาต้องการโมเดลรู้จำเฉพาะทางที่ฝึกบนข้อความเฉพาะด้านขนส่งทางอากาศ ดังนั้นการเพิ่มเติมเหล่านี้ต้องใช้เวลาในการพัฒนาและตรวจสอบให้ได้มาตรฐานความถูกต้องของเรา
อัปโหลด AWB ภาษาไทยหรือผสมไทย-อังกฤษและดูผลลัพธ์ ทดลองฟรี 30 วัน