Regional Language Adapter: Thai NLP ในระบบ Enterprise AI

การ deploy Enterprise AI ในภาษาไทยล้มเหลวด้วยสาเหตุที่ไม่เกี่ยวกับคุณภาพของ Model — มันล้มเหลวที่ ขอบเขตการ Tokenization ก่อนที่ Model จะเห็นข้อความด้วยซ้ำ

บทความนี้อธิบายวิธีที่ RCT Regional Language Adapter แก้ปัญหา Thai NLP ในระดับ Enterprise Layer และเหตุใดการทำสิ่งนี้ให้ถูกต้องจึงเป็นเงื่อนไขเบื้องต้นสำหรับระบบ AI ที่สอดคล้องกับ PDPA ในประเทศไทย

ปัญหาของภาษาไทยใน Enterprise AI

Infrastructure AI ระดับโลกส่วนใหญ่ถือว่าภาษาเป็นลำดับของ Token ที่คั่นด้วยช่องว่าง ภาษาอังกฤษ ฝรั่งเศส เยอรมัน — ทั้งหมดใช้โมเดลนี้ ภาษาไทยไม่เป็นเช่นนั้น

อักษรไทยเขียนโดยไม่มีขอบเขตระหว่างคำ ประโยค "ฉันกินข้าว" ประกอบด้วย Cluster พยางค์ 4 กลุ่มที่แสดงประโยคสมบูรณ์ แต่ไม่มีช่องว่างเป็น Guide สำหรับการ Tokenize Tokenizer แบบ Subword ทั่วไปจะแยกส่วนนี้เป็น Fragment ที่ไร้ความหมาย ทำลาย Semantic Coherence ก่อนที่ Model จะประมวลผลอะไรเลย

นอกจากการ Tokenize แล้ว ภาษาไทยยังมีปัญหาด้าน Enterprise อีก 3 ประการ:

1. เครื่องหมายเสียงวรรณยุกต์และ Diacritics ซ้อนกัน อักษรไทยสามารถซ้อนกันในแนวตั้งได้: พยัญชนะฐาน สระ และวรรณยุกต์สามารถอยู่ในตำแหน่งแนวนอนเดียวกัน Unicode แสดงสิ่งเหล่านี้เป็น Code Point แยกกัน แต่ Pipeline ML หลายตัวถือว่าแต่ละตัวเป็น Character แยกกัน — ทำให้ Word Embedding เสียหายสำหรับคำศัพท์ทั่วไปประมาณ 23%

2. ข้อมูล PII ตาม PDPA ฝังอยู่ในชื่อ ชื่อภาษาไทยมีตัวบ่งชี้ทางวัฒนธรรมและศาสนา ชื่อ "นายสมศักดิ์ เจริญรัตน์" มีเพศ ความเชื่อมโยงทางวัฒนธรรม และข้อมูลครอบครัวโดยนัย ซึ่งถือเป็นข้อมูลส่วนบุคคลภายใต้มาตรา 24 ของ PDPA ระบบ AI ระดับ Enterprise ที่ Tokenize ชื่อโดยไม่ระมัดระวังจะสร้างการประมวลผลข้อมูลที่ไม่ได้เปิดเผย — เป็นความเสี่ยงทางกฎหมาย ไม่ใช่แค่ปัญหาทางเทคนิค

3. รูปแบบการสลับภาษา (Code-Switching) การสื่อสารในองค์กรไทยมักผสม Thai และ English ในประโยคเดียว: "วันนี้เราจะ deploy v1.0.3a0 บน production cluster ครับ" หากไม่มี Adapter แบบ Bidirectional ที่เข้าใจว่านี่คือ Mixed-Language Speech ตามธรรมชาติ Model จะถือว่า Fragment ภาษาอังกฤษเป็น Noise หรือใช้กฎ Tokenize ที่ไม่เหมาะสมกลางประโยค

วิธีทำงานของ Regional Language Adapter

Regional Language Adapter ใน delentia-os อยู่ระหว่าง Input ของผู้ใช้และ FDIA Scoring Pipeline โดยทำงานใน 3 ขั้นตอน:

ขั้นตอนที่ 1 — การตรวจจับและ Routing ภาษา

Input ทุกชิ้นผ่าน Classifier ที่มีน้ำหนักเบาซึ่งระบุ:

• ภาษาหลัก (ไทย อังกฤษ หรือผสม)
• ประเภท Script (อักษรไทย Latin ตัวเลข หรือผสม)
• Flag ความเสี่ยง PDPA (รูปแบบชื่อไทย รูปแบบหมายเลข ID รูปแบบเบอร์โทรศัพท์ รูปแบบวันเกิด)

สำหรับ Input ภาษาไทย Adapter จะ Route ไปยัง Thai NLP Pipeline สำหรับ Input ภาษาอังกฤษ จะ Route ตรงไปยัง Standard Tokenizer สำหรับ Input แบบผสม จะใช้ Bidirectional Segmentation

from rct_platform.adapters import RegionalLanguageAdapter

adapter = RegionalLanguageAdapter(locale="th-TH", pdpa_mode="strict")
result = adapter.process("วันนี้เราจะ deploy v1.0.3a0 บน production cluster ครับ")

# result.segments → [("วันนี้เราจะ", "th"), ("deploy v1.0.3a0 บน production cluster", "en"), ("ครับ", "th")]
# result.pii_flags → []  # ไม่พบ PII ใน Input นี้
# result.tokens → 47  # การ Tokenize ภาษาไทยที่ถูกต้อง

ขั้นตอนที่ 2 — Thai Word Segmentation

Adapter ใช้ Algorithm แบบ Dictionary-based Maximum Matching ที่ Seed ด้วย Thai Lexicon 65,000 คำ ครอบคลุมคำศัพท์เทคนิคสมัยใหม่ ต่างจาก Neural Segmenters ที่บริสุทธิ์ วิธี Dictionary-based มีข้อดี:

• Deterministic — Input เดียวกันให้ Output เดียวกันเสมอ (จำเป็นสำหรับ FDIA Scoring)
• Auditable — การตัดสินใจ Segmentation สามารถ Log และตรวจสอบได้
• Compatible กับ PDPA — ไม่มีการเก็บรักษาข้อมูล Training ไม่มีการ Inference ทางสถิติบนชื่อส่วนบุคคล

ขั้นตอนที่ 3 — PDPA Masking ก่อนส่ง LLM

ก่อนที่ข้อความจะถูกส่งไปยัง LLM ภายนอก Adapter จะใช้กฎ Constitutional Masking ที่กำหนดไว้ใน Governance Configuration ขององค์กร:

# rct_governance.yaml
pdpa_masking:
  thai_names: mask_with_token      # [THAI_NAME_REDACTED]
  thai_id_numbers: hash_deterministic  # SHA-256, ตรวจสอบได้
  phone_numbers: mask_last_4       # 08X-XXX-7890
  addresses: mask_building_unit    # อาคาร/ห้องถูก Redact เก็บจังหวัด
  medical_terms_with_names: full_redact  # PDPA มาตรา 26 (ข้อมูลอ่อนไหว)

Masking นี้เกิดขึ้นก่อนที่ FDIA Scoring จะเริ่ม Constitutional Layer เห็นเฉพาะเวอร์ชัน Masked ส่วนต้นฉบับจัดเก็บอยู่ในล็อค Audit Log ที่เข้ารหัสของ DelentiaDB เท่านั้น

ความครอบคลุมภาษา ASEAN

Regional Language Adapter ครอบคลุม 8 คู่ภาษาใน Release v1.0.2a0 ปัจจุบัน:

| ภาษา | Script | Tokenization | กฎ PII | กฎหมายท้องถิ่น | |---|---|---|---|---| | ไทย (th-TH) | อักษรไทย | Dictionary + neural | ✅ สมบูรณ์ | PDPA 2562 | | อังกฤษ (en-US/GB) | Latin | Subword BPE | ✅ สมบูรณ์ | Compatible กับ GDPR | | จีนตัวย่อ (zh-CN) | CJK | Jieba | ✅ บางส่วน | Compatible กับ PIPL | | จีนตัวเต็ม (zh-TW) | CJK | Jieba | ✅ บางส่วน | PDPA Taiwan | | ญี่ปุ่น (ja-JP) | ผสม (CJK/Kana) | MeCab | ✅ บางส่วน | Compatible กับ APPI | | อินโดนีเซีย (id-ID) | Latin | Standard subword | ✅ พื้นฐาน | รับรู้ PDPbill | | เวียดนาม (vi-VN) | Latin + Diacritics | Tone-aware subword | ✅ พื้นฐาน | รับรู้ Decree 13 | | มาเลย์ (ms-MY) | Latin | Standard subword | ✅ พื้นฐาน | PDPA มาเลเซีย |

ภาษาไทยมีการ Integration ที่ลึกที่สุดเนื่องจากเป็นตลาด Deployment หลัก คู่ภาษาอื่นอีก 7 คู่ให้ความครอบคลุมเพียงพอสำหรับการ Deploy ระดับ Enterprise ทั่ว ASEAN โดยไม่ต้องการ Deep Integration เฉพาะตลาด

การรวมเข้ากับ FDIA

คะแนน FDIA (Federated Deterministic Intent Assessment) ขึ้นอยู่กับ Semantic Coherence Input ภาษาไทยที่ Tokenize ผิดให้คะแนน FDIA ต่ำกว่า — ไม่ใช่เพราะ Intent มีคุณภาพต่ำ แต่เพราะ Scoring Pipeline ไม่สามารถ Parse ได้อย่างถูกต้อง

Regional Language Adapter ให้ความแม่นยำ FDIA Scoring สำหรับ Input ภาษาไทยเทียบเท่ากับภาษาอังกฤษโดย:

1. Pre-normalize Input ก่อน FDIA Scoring (Tokenization ที่สม่ำเสมอ → การแสดง Semantic ที่สม่ำเสมอ)
2. Inject Language Context เข้าใน FDIA Metadata (intent.language_context: "th-TH")
3. Flag Code-Switch Boundaries เพื่อให้ FDIA Scorer ให้น้ำหนัก Segment ภาษาไทยและอังกฤษแยกกันก่อนรวม

หากไม่มี Adapter ทีม Enterprise ที่ใช้ทั้ง Thai/English จะได้รับคะแนน FDIA ที่ต่ำกว่าอย่างเป็นระบบสำหรับคำขอภาษาไทย — สร้าง Language Bias ที่มองไม่เห็นในระบบ Governance Adapter ออกแบบมาเพื่อกำจัด Bias นี้

คุณลักษณะด้านประสิทธิภาพ

ที่ CI Baseline 1,272 Tests (v1.0.2a0):

• ความแม่นยำ Thai Tokenization: 94.3% บน Thai NLP Benchmark มาตรฐาน (BEST-2010 dataset)
• ความแม่นยำการตรวจจับ Code-Switch: 97.1% บน Sample Enterprise ผสม Thai/English
• PDPA PII Detection Recall: 98.7% บน Synthetic PDPA Test Suite (ไม่มี False Negatives สำหรับรูปแบบ ID ไทย)
• Latency Overhead: < 12ms ต่อ 1,000 Tokens บน CPU (p99) — อยู่ในงบ JITNA 50ms

ความหมายสำหรับการ Deploy ระดับ Enterprise

หากคุณกำลัง Deploy Enterprise AI ในประเทศไทยหรือสำหรับผู้ใช้ที่พูดภาษาไทย Language Adapter ไม่ใช่ Infrastructure ที่เป็นทางเลือก — มันเป็นขอบเขต Governance สำหรับการปฏิบัติตาม PDPA และฐานความแม่นยำสำหรับทุกการตัดสินใจ AI ที่ตามมา

หากไม่มี Thai NLP ที่เหมาะสม:

• คะแนน FDIA ไม่น่าเชื่อถือสำหรับ Input ภาษาไทย
• ข้อมูลส่วนบุคคลตาม PDPA อาจส่งผ่านไปยัง LLM โดยไม่ถูก Mask
• คำสั่งธุรกิจแบบ Code-Switched อาจ Parse ผิด ทำให้ Routing ผิดพลาด

ด้วย RCT Regional Language Adapter:

• Input ภาษาไทยทุกรายการถูก Tokenize ตามมาตรฐานเดียวกับภาษาอังกฤษ
• PDPA Masking ทำงานก่อน External LLM Call ใดๆ (ออกแบบให้ส่ง PII ที่ไม่ได้ Mask ออกเป็นศูนย์)
• Code-Switching ถูกจัดการเป็นรูปแบบ Enterprise ระดับ First-Class ไม่ใช่ Edge Case

นี่คือเหตุผลที่ Adapter เป็นหนึ่งในห้า Core Module ใน delentia-os — ไม่ใช่ Add-on ที่เป็นทางเลือก แต่เป็นเงื่อนไขเบื้องต้นสำหรับ AI ที่น่าเชื่อถือในตลาดไทย

บทความที่เกี่ยวข้อง: PDPA AI Compliance ในประเทศไทย · RCT Control Plane: Governance at Runtime · Constitutional AI สำหรับ Enterprise ไทย · คู่มือ ASEAN Enterprise AI Deployment