ทำ OCR ภาษาไทยให้แม่นจริง — สูตร RAG ที่เราใช้กับเอกสารราชการ

OCR ภาษาไทยขึ้นชื่อว่ายากมาก — ตัวอักษรซ้อนกัน, ไม่มี space ระหว่างคำ, font ราชการที่ใช้กันมาตั้งแต่ปี 2540 ยังคงอยู่ในเอกสารวันนี้ บทความนี้สรุปสิ่งที่เราเรียนรู้ตอนทำ AIDA Document ระบบที่ process เอกสารราชการกว่า 12,000 ฉบับ/เดือน

ทำไม OCR ภาษาไทยยาก

1. ตัวอักษรซ้อนตามแนวตั้ง

สระบน (ิ ี ึ ื) + สระล่าง (ุ ู) + วรรณยุกต์ (่ ้ ๊ ๋) อาจซ้อนกัน 3 ชั้น ทำให้ bounding box ของอักษรพื้นฐานเล็กมาก

2. ไม่มี word boundary

ภาษาไทยเขียนติดกันหมด — engine ต้องเดาว่า “ไปไหนมา” คือ “ไป-ไหน-มา” หรือ “ไ-ป-ไห-น-มา” การ tokenize ผิด = ข้อมูลใช้ไม่ได้

3. Font หลากหลาย

ราชการใช้ TH SarabunPSK, AngsanaUPC, CordiaUPC, JasmineUPC, Browallia — แต่ละ font มี kerning ต่างกัน เอกสารที่สแกนจากเครื่อง fax ก็คุณภาพยิ่งต่ำ

4. Layout ซับซ้อน

เอกสารราชการมีตาราง, ลายเซ็น, ตราประทับ, ตัวเลขไทย-อารบิกผสม — model ทั่วไปสับสนเรื่องลำดับการอ่าน

OCR engine ที่ใช้ได้กับภาษาไทย (เปรียบเทียบจริง)

Engine	Accuracy (text ไทย)	ราคา	จุดเด่น	จุดอ่อน
Google Cloud Vision	94–97%	$1.5/1k pages	ดีกับ font ปัจจุบัน	แพง, ไม่รองรับ layout ซับซ้อน
Azure Document Intelligence	95–98%	$1.5–10/1k	จัดการ layout/table ดี	setup ซับซ้อน
Tesseract 5 + Thai trained data	80–90%	ฟรี (self-host)	เป็น open source ปรับได้	accuracy ขึ้นกับการ fine-tune
Typhoon-OCR (SCB 10X)	92–96%	ฟรี	สำหรับเอกสารไทยโดยเฉพาะ	ใหม่ community เล็ก
PaddleOCR + Thai model	90–94%	ฟรี	เร็ว ใช้ GPU ดี	preprocessing ต้องทำเอง

จากประสบการณ์ — production แนะนำ Azure Document Intelligence + custom post-processing สำหรับเคสที่ accuracy critical

Pre-processing ที่ขาดไม่ได้

ก่อนส่งเข้า OCR engine ต้องทำ:

1. Deskew — ปรับเอียง (เอกสารสแกนมือมักเอียง 1–5°)
2. Binarization — แปลง grayscale → ขาวดำ ใช้ adaptive threshold (Sauvola)
3. Noise removal — ลบจุดดำเล็ก ๆ จากการสแกน
4. DPI normalize — resample ให้ทุกหน้า 300 DPI
5. Layout detection — แยกเขตข้อความ ตาราง รูป ก่อนส่ง OCR

ขั้นตอนนี้คือต่างของ accuracy 85% กับ 95%

Post-processing สำคัญที่สุด

OCR raw output ไม่พอ — ต้องมี:

Thai word segmentation

ใช้ PyThaiNLP หรือ ICU library แยกคำให้ถูก ถ้า OCR ออก “การประชุมสภา” แต่ tokenize ผิดเป็น “ก-ารประ-ชุมสภา” RAG search จะหาไม่เจอ

Confidence filtering

ทุก token มี confidence score — ตั้ง threshold (เช่น 0.7) แล้ว flag คำที่ต่ำกว่าให้คนตรวจ

Domain dictionary

ถ้าเป็นเอกสารราชการ inject dictionary คำเฉพาะ (“พระราชบัญญัติ”, “ประกาศ”, “ระเบียบ”) เพื่อให้ OCR เลือกคำที่ถูกเมื่อสองคำคล้ายกัน

Regex fix

แก้ pattern ที่ผิดบ่อย เช่น OCR อ่าน “พ.ศ. ๒๕๖๗” เป็น “พ.ศ. 2567” — สำหรับเอกสารราชการให้คงตัวเลขไทย

RAG ทำต่อยังไง

หลังจากได้ text ที่สะอาดแล้ว เข้าสู่ pipeline RAG (อ่าน RAG vs Fine-tuning เลือกอะไร ถ้าสับสนว่าควรใช้แนวทางไหน):

[Document] 
   ↓ chunking (semantic, ไม่ใช่ fixed-size)
[Chunks ~300-500 tokens each]
   ↓ embed
[Vectors in Qdrant/PGVector]
   ↓ user query
[Top-K retrieval + re-rank]
   ↓ context
[LLM generate answer + cite source]

Chunking strategy

อย่าใช้ fixed-size chunking กับเอกสารไทย — แบ่งตาม section heading หรือ paragraph จะให้ context ที่สมบูรณ์กว่า

Embedding model

• BGE-M3 (BAAI) — รองรับภาษาไทยดี multilingual + ฟรี
• OpenAI text-embedding-3 — ดีแต่เสียเงิน
• Multilingual-E5-large — ฟรี เหมาะกับ semantic search

Hybrid search

รวม dense (vector) + sparse (BM25) ดีกว่า dense อย่างเดียวประมาณ 8–15% recall — โดยเฉพาะเอกสารที่มีคำเฉพาะเช่น เลข พ.ร.บ.

Re-ranking

หลัง retrieve top-100 ให้ re-rank ด้วย cross-encoder (bge-reranker-v2-m3) แล้วเลือก top-5 ส่งเข้า LLM

Citation = key สำหรับ AI ราชการ

เอกสารราชการต้องอ้างอิงได้ — ทุกคำตอบของ LLM ต้องบอกว่ามาจาก “เอกสารชื่อ X หน้า Y” ถ้าไม่มี citation ผู้ใช้จะไม่เชื่อ และอันตรายตามกฎหมาย

วิธีทำ:

1. เก็บ metadata (doc_id, page, section) คู่กับ chunk
2. Prompt LLM บังคับให้ใช้ format [doc_id:page] ทุกครั้งที่อ้าง
3. หลัง generate ใส่ link จริงให้ user click ดูต้นฉบับ

วัด accuracy ยังไง

ไม่ใช่แค่ character-level accuracy — ต้องดู:

• Field-level accuracy — extract field สำคัญถูกหรือเปล่า (เลขที่หนังสือ, วันที่)
• RAG accuracy — ถามคำถาม 100 ข้อ บอทตอบถูกกี่ %
• Faithfulness — คำตอบมาจาก context จริงไหม (ไม่ hallucinate)
• Citation accuracy — link ที่ refer ไปถูกหน้าจริงไหม

ข้อผิดพลาดที่เราเคยทำ

ใช้ fixed-size chunking ตอนแรก — ผลคือ context ขาดกลางย่อหน้า บอทตอบไม่ครบ แก้โดยใช้ semantic chunking ตาม heading

Embed ทุก chunk รวมกัน — ทำให้ batch ใหญ่ memory ระเบิด ควรทำ batch ละ 32–64 chunks

ไม่ทำ deskew — ผลคือ accuracy drop 8% โดยเฉพาะเอกสารที่สแกนมาจากปลายม้วน

Trust OCR confidence อย่างเดียว — มี case ที่ confidence 0.9 แต่อ่านผิดเพราะ font หายาก ต้องมี dictionary check เสริม

เริ่มที่ไหน

ถ้าธุรกิจคุณมีเอกสารยาว ๆ และอยากให้ AI ตอบจากเอกสารได้ ติดต่อเรา /#contact หรือดู วิธีทำ AI Chatbot บน LINE OA ที่ใช้ pipeline แบบเดียวกัน — เราช่วย audit ฟรีว่าเอกสารแบบไหนเหมาะกับ RAG และ accuracy realistic คือเท่าไร