เทียบ OCR ภาษาไทย Open Source 5 ตัว — เลือกใช้จริงจัง

ผมเคยต้องเลือกระบบ OCR ให้ลูกค้าหลายโปรเจกต์ — ตั้งแต่สแกนเอกสารราชการ, ใบเสร็จ, เอกสารการเงิน, ไปจนถึงฟอร์มเขียนด้วยลายมือ เลยรู้ดีว่า "OCR ภาษาไทย" ไม่ใช่เรื่องง่ายเหมือนภาษาอังกฤษ เพราะภาษาไทยไม่มีเว้นวรรคระหว่างคำ มีสระบน-ล่าง วรรณยุกต์ซ้อน และฟอนต์หลากหลาย

บทความนี้เทียบ open source OCR 5 ตัวที่ใช้ได้จริงกับภาษาไทยในทุก use case ที่พบบ่อย — ข้อมูลทั้งหมดมาจาก documentation จริง, benchmark ที่ publish แล้ว และประสบการณ์ใช้งานจริง พร้อมลิงก์ repo ให้ไปดูต่อได้

หมายเหตุ: ผลลัพธ์ OCR ขึ้นกับคุณภาพรูป, ฟอนต์, ภาษา, และ preprocessing มาก — ตัวเลขในบทความนี้เป็นค่าประมาณ สำหรับเปรียบเทียบภาพรวม ไม่ใช่ค่าที่การันตีสำหรับเอกสารของคุณ ควรทดสอบกับเอกสารจริง 50–100 ชิ้นก่อนตัดสินใจเสมอ

TL;DR — เลือกตัวไหนดี

• สแกนสะอาด เอกสารพิมพ์ ปริมาณมาก CPU อย่างเดียว→ Tesseract
• Prototype เร็ว, Python ง่ายๆ, ภาษาอื่นด้วย→ EasyOCR
• Production จริง, เอกสารหลากหลาย, ภาษาไทย+อังกฤษผสม→ PaddleOCR
• เอกสารซับซ้อน, ตาราง, layout, PDF→Markdown→ Surya OCR
• เอกสารไทยเฉพาะทาง, ฟอร์ม, ลายมือ, output เป็น Markdown→ Typhoon OCR

1. Tesseract — ตัวเก๋าที่ยังไม่ตาย

Tesseractคือ OCR open source ที่เก่าแก่ที่สุด (เริ่มปี 2005, ปัจจุบัน v5.x) รองรับภาษาไทยผ่าน tha.traineddataLicense: Apache-2.0 — ใช้เชิงพาณิชย์ได้เต็มที่

จุดแข็ง

• เบาที่สุด — CPU ล้วน ไม่ต้อง GPU ติดตั้งง่าย มี binary พร้อมใช้ทุก platform
• Output format ครบ — text, hOCR, ALTO, TSV, searchable PDF — เหมาะกับ archive/ห้องสมุด
• เสถียรและ proven — ใช้กันมาสิบกว่าปี bug ที่เจอมีคนเจอและแก้แล้ว
• Community ใหญ่สุด — ภาษาไทยมี traineddata และกระบวนการ train เสริมเองได้

จุดอ่อน

• ไม่เก่งกับรูปคุณภาพต่ำ — เอกสาร acknowledge เองว่าต้อง improve image quality ก่อน scan เบลอ/เอียง/แสงน้อย → accuracy ตกเร็วมาก
• ไม่มี layout analysis — เอกสารหลายคอลัมน์/ตาราง จะออกมาเป็น text ยาวไม่เป็นระเบียบ
• ภาษาไทยไม่มี word segmentation — output เป็นตัวอักษรติดกัน ต้องมาแยกคำเอง (ใช้ newmm/maxcut ของ PyThaiNLP ช่วยได้)
• Table/form ไม่เก่ง — เซลล์ตาราง ออกมาเรียงบรรทัด ไม่ใช่ structure

เหมาะกับ: scan สะอาด ปริมาณมาก งบ infra ต่ำ, archive digitization, searchable PDF

2. EasyOCR — ติดตั้งง่ายที่สุด

EasyOCRเป็น Python library ที่ wrap deep learning models (CRAFT detector + CRNN) รองรับ 80+ ภาษา รวมไทย License: Apache-2.0 จุดเด่นคือ pip install easyocr แล้วใช้ได้เลย — เหมาะมากสำหรับ prototype และ proof of concept

จุดแข็ง

• Setup ง่ายสุดในกลุ่ม — ไม่ต้อง config model เอง
• รองรับหลายภาษาพร้อมกัน — ไทย+อังกฤษ+จีน ในเอกสารเดียวได้
• Detector ดีพอสมควร — หา text region ในรูปได้ดี รองรับ text ที่เอียง/หมุนได้ระดับหนึ่ง
• Python-native — integrate เข้า data pipeline ง่าย

จุดอ่อน

• Release ช้า — version ล่าสุด 1.7.2 (ก.ย. 2024) แทบไม่มี update ใหญ่ในรอบปี
• Accuracy ceiling ต่ำกว่า — เทียบ production-grade engines แล้วต่ำกว่าในงานยาก
• ไม่มี layout/table understanding — ได้ text + bounding box แต่ไม่มี reading order หรือ table structure
• ไม่มี traineddata ภาษาไทยแบบเฉพาะทาง — ใช้ generic multilingual model

เหมาะกับ: prototype, PoC, เอกสารไม่ซับซ้อน, ทีมที่อยากเริ่มเร็ว

3. PaddleOCR — ตัวเต็งสำหรับ production

PaddleOCRจาก Baidu — toolkit OCR deep learning ที่ครบสุดในกลุ่ม open source License: Apache-2.0 ทั้ง code และ weights เวอร์ชันล่าสุด v3.7.0 (มิ.ย. 2026) ใช้ PP-OCRv6 models รองรับ 50 ภาษาใน model เดียว รวมไทย (th)

จุดแข็ง

• Accuracy สูงสุดในกลุ่ม open source ทั่วไป — PP-OCRv5/v6 ชนะ benchmark หลายตัว เช่น OmniDocBench (หมายเหตุ: benchmark ไทยเฉพาะทางยังมีจำกัด — ควรวัดกับเอกสารของตัวเองเสมอ)
• Detections + recognition ดีมากกับรูปจริง — รูปถ่าย, สกรีนช็อต, เอกสารเอียง, ข้อความหมุน
• PP-StructureV3 — layout analysis + table recognition + document parsing เป็น pipeline เดียว
• Multilingual ครบ — ไทย อังกฤษ จีน ฯลฯ model เดียว
• Community ใหญ่ — อัปเดตถี่ มี pre-trained weights

จุดอ่อน

• หนักกว่า — ต้องลง PaddlePaddle framework หรือใช้ ONNX runtime (ผ่าน RapidOCR)
• GPU แนะนำ — CPU ได้แต่ช้ากว่า Tesseract มาก สำหรับปริมาณมาก
• Learning curve สูงกว่า — config เยอะกว่า EasyOCR
• ภาษาไทยยังต้อง word segmentation — เหมือน engine อื่น ไม่มี in-model word breaking

เหมาะกับ: production จริง, เอกสารหลากหลาย, รูปถ่าย/สแกนคุณภาพกลาง, ต้องการ table extraction

4. Surya OCR — document understanding ระดับ VLM

Suryaจาก Datalab — ไม่ใช่ OCR ธรรมดา แต่เป็น vision-language model689M params ที่ทำ OCR + layout analysis + reading order + table recognition ใน model เดียว รองรับ 91 ภาษา รวมไทย (th) Code: Apache-2.0, Weights: OpenRAIL-M (ฟรีสำหรับ research/personal/startup <$5M)

จุดแข็ง

• เข้าใจ layout ดีสุด — รู้ว่าอันไหนเป็นหัวข้อ ตาราง รูป caption reading order ถูกต้อง
• Table → HTML พร้อม merged cells — output structure สมบูรณ์กว่า engine อื่นมาก
• คะแนน benchmark สูง — olmOCR-bench 83.3% (ดีที่สุดในกลุ่ม open model <3B params ตามทีม Surya)
• ผลลัพธ์เป็น structured document — เหมาะกับ RAG, document AI pipeline
• 91 ภาษา — multilingua documents ทำได้ดี

จุดอ่อน

• ต้องการ GPU หรือ inference backend — vLLM/llama.cpp (CPU ได้แต่ช้ามากสำหรับปริมาณมาก)
• Weights license OpenRAIL-M — ไม่ใช่ Apache เต็มรูปแบบ ต้องเช็คเงื่อนไขสำหรับ use case บริษัทใหญ่
• เน้น document ไม่ใช่ photo/scene — รูปธรรมชาติหรือ scene text ไม่ใช่จุดแข็ง
• Setup ซับซ้อนกว่า — ต้อง inference server

เหมาะกับ: RAG pipeline, document AI, เอกสารที่ต้องการ structure สมบูรณ์, ทีมที่มี GPU infra

5. Typhoon OCR — เกิดมาเพื่อภาษาไทยโดยเฉพาะ

Typhoon OCRจาก SCB 10X (ไทย) — VLM ที่เทรนมาเฉพาะภาษาไทย+อังกฤษ สำหรับเอกสารจริงในบริบทไทย License: Apache-2.0 (code) + weights เปิดสำหรับใช้ รุ่นล่าสุด Typhoon OCR 1.5 (2B params, base Qwen3-VL) — เล็กลง แต่เก่งขึ้น โดยเฉพาะลายมือและฟอร์ม

จุดแข็ง

• เข้าใจเอกสารไทยจริงๆ — เทรนบนเอกสารราชการ ฟอร์ม ใบเสร็จ ลายมือไทย
• Output เป็น Markdown/HTML structured — layout, table, hierarchy ถูกต้องเกือบพร้อมใช้
• ฟอร์มและลายมือดีกว่า engine ทั่วไป — จุดที่ Tesseract/EasyOCR มักพลาด
• Prompt-based — สั่งให้ extract field เฉพาะได้ เช่น "ดึงเลขที่เอกสาร, วันที่, จำนวนเงิน"
• ไทยล้วน — ไม่มีปัญหา multilingual model ที่เทรนไทยน้อย

จุดอ่อน

• ต้องการ GPU หรือ vLLM server — 2B–7B params รัน local ต้อง GPU ดีๆ หรือเช่า API
• Project ยังใหม่ (เริ่ม 2025) — community เล็กกว่า engine ตะวันตก
• Windows ไม่ support (ตอนนี้ Linux/Mac)
• ไม่มี batch pipeline สำเร็จรูป — ต้องเขียน wrapper เองสำหรับปริมาณมาก
• English-only fallback ไม่ดี — เก่งไทย+อังกฤษปน แต่ภาษาอื่นไม่ใช่จุดแข็ง

เหมาะกับ: เอกสารไทยจริงจัง — ราชการ, ฟอร์ม, ลายมือ, ใบเสร็จ, ที่ต้องการ structured output

6. เปรียบเทียบเชิงลึกตาม Use Case จริง

6.1 สแกนเอกสารพิมพ์สะอาด ปริมาณมาก (archive)

• Tesseract ชนะ — ถูกสุด เบาสุด stable สุด ถ้า scan สะอาดไม่มีปัญหา
• PaddleOCR เร็วกว่าแต่ต้อง GPU ถ้าปริมาณมากคุ้มกว่า
• Surya/Typhoon overkill สำหรับงานนี้

6.2 ใบเสร็จ/ใบแจ้งหนี้/เอกสารการเงิน

• PaddleOCR หรือ Typhoon OCR — รูปถ่ายคุณภาพกลาง, ตัวเลข+ไทยปน, ต้องการ field extraction
• Tesseract พอได้แต่ต้อง preprocess หนัก
• EasyOCR เร็วแต่ accuracy ไม่พอสำหรับตัวเลขสำคัญ

6.3 ฟอร์มราชการ/เอกสารทางการ

• Typhoon OCR เด่นสุด — เทรนบนเอกสารไทยจริง layout + field extraction + ลายมือ
• Surya รองลงมา — layout ดีแต่ลายมือไทยอาจไม่เท่า
• Tesseract/EasyOCR พอใช้ถ้าเป็นพิมพ์สะอาดเท่านั้น

6.4 เอกสารหลายภาษา (ไทย+อังกฤษ+จีน)

• PaddleOCR — multilingual model เดียวรองรับ 50 ภาษา
• Surya รองรับ 91 ภาษา
• Typhoon เก่งแค่ไทย+อังกฤษ
• Tesseract ต้อง pack หลาย traineddata เอง

6.5 ตาราง/สัญญา/เอกสารโครงสร้างซับซ้อน

• Surya OCR — table → HTML พร้อม merged cells, reading order ถูกต้อง
• Typhoon OCR รองลงมา — output Markdown/HTML ดีมาก
• PaddleOCR PP-StructureV3 ก็ทำได้แต่ต้อง config เพิ่ม
• Tesseract/EasyOCR ไม่เหมาะกับงานนี้

6.6 Handwriting ไทย (ลายมือ)

• Typhoon OCR — จุดเด่นจริง เก่งฟอร์ม+ลายมือ
• Surya รองลงมา — handwriting benchmark ยังไม่เท่า Typhoon
• Engine อื่นๆ แทบไม่ไหวกับลายมือไทย

6.7 RAG / Document AI pipeline

• Surya OCR — output เป็น structured document พร้อม layout + reading order + table HTML — เหมาะกับ RAG ที่สุด
• Typhoon OCR รองลงมา — Markdown output ดีสำหรับ ingestion
• Engine อื่นต้องเขียน post-processing เองมาก

7. ปัญหาเฉพาะภาษาไทยที่ต้องรู้

ไม่ว่าคุณจะใช้ engine ไหน ปัญหาเหล่านี้มีเหมือนกัน:

• ไม่มีเว้นวรรคระหว่างคำ — OCR ออกมาเป็น ตัวอักษรติดกัน ต้องใช้ word segmentation แนะนำ PyThaiNLP (newmm dictionary หรือ newmm-safe ที่ไม่แตกคำเฉพาะ) — หรือ LLM ช่วยตัดคำภายหลัง
• สระบน/ล่างและวรรณยุกต์ — OCR อาจอ่านผิดตำแหน่ง โดยเฉพาะฟอนต์ที่มีสระซ้อนกัน — ควร normalize output
• ฟอนต์ไทยหลากหลาย — TH Sarabun, Angsana, Cordia, Adobe Thai — แต่ละแบบมี style ต่างกันมาก ทดสอบกับฟอนต์ที่ใช้จริงเสมอ
• ตัวเลขไทย vs อารบิก — เอกสารไทยมักใช้ ๐-๙ แต่ระบบคอมพิวเตอร์เป็น 0-9 — ต้อง normalize เอง
• ตัวย่อ/คำราชาศัพท์ — OCR อาจอ่านผิด เช่น "ท่าน" "พระ" — ต้องมี dictionary correction

วิธีแก้ที่ได้ผลจริง: LLM post-processing — เอา OCR output ไปให้ LLM (Claude/GPT) ช่วยตรวจและแก้ ลด error rate ได้มากสำหรับเอกสารสำคัญ แต่ต้องระวังเรื่อง data privacy ถ้าเอกสารลับ

8. License — เช็คก่อนใช้จริง

*OpenRAIL-M ของ Surya — ใช้ฟรีสำหรับ research/personal/startup <$5M revenue บริษัทใหญ่ต้องเช็คเงื่อนไขเพิ่มเติมที่ repo

9. วิธีทดสอบก่อนเลือก (สำคัญที่สุด)

อย่าเชื่อ benchmark ของใคร — ทดสอบกับเอกสารจริงของคุณ:

1. เก็บตัวอย่างจริง 50–100 ชิ้น — ครอบคลุมทุกประเภทเอกสารที่คุณจะใช้จริง (อย่าเลือกแต่ตัวที่สวย)
2. รันแต่ละ engine แล้ววัด CER/WER — Character Error Rate หรือ Word Error Rate เทียบกับ ground truth ที่พิมพ์เอง
3. วัด field-level accuracy — สำหรับเอกสารการเงิน วัดว่า "เลขที่เอกสารถูกกี่ %" ไม่ใช่แค่ "ตัวอักษรถูกกี่ %"
4. ทดสอบ edge cases — ฟอนต์แปลก, เอกสารเอียง, รูปถ่ายจากมือถือ, ลายมือ, ตารางซับซ้อน, เอกสารหลายหน้า
5. วัดเวลาและต้นทุน — pages/sec บน hardware จริงของคุณ + ค่า GPU ถ้ามี
6. ทดสอบ post-processing — word segmentation, LLM correction, validation rules

ผมเคยเห็นหลายโปรเจกต์เลือก engine จาก benchmark แล้วเจอปัญหา ตอนเจอเอกสารจริง — เพราะ benchmark ใช้เอกสาร clean แต่ของจริงสกปรกกว่าเสมอ

10. ผลเทสจริงที่ผมรันเอง (13 พ.ย. 2026)

เพื่อให้บทความนี้ไม่ใช่แค่ทฤษฎี ผม generate รูปทดสอบภาษาไทยจริง 7 ภาพ (เรนเดอร์ด้วยฟอนต์ไทยจริงของ macOS: Thonburi, Ayuthaya, Krungthep, Sathu) ครอบคลุม: เอกสารบริษัทสะอาด, ใบเสร็จ, ฟอนต์ต่างๆ, รูปคุณภาพต่ำ, เอกสารเอียง 3 องศา, และเอกสารไทย+อังกฤษผสม แล้วรัน OCR จริงบนเครื่อง Mac (Apple Silicon, CPU)

Environment: Tesseract 5.5.3 (tha+eng, psm 6), EasyOCR 1.7.2 (th,en, CPU), RapidOCR ONNX (default models) — วัดผลด้วย CER (Character Error Rate = อัตราความผิดพลาด ต่ออักขระ) เทียบ ground truth ที่ผมพิมพ์เอง (normalize ช่องว่าง + เลขไทยก่อนคำนวณ)ตัวเลขนี้คือ % ที่ผิด — ยิ่งต่ำยิ่งแม่นเช่น CER 2% ≈ อ่านถูก ~98%, CER 25% ≈ ผิด ~1 ใน 4 ตัวอักษร

สิ่งที่ผลเทลจริงบอกเรา:

• Tesseract ชนะในชุดเทสนี้อย่างชัดเจน — โดยเฉพาะเอกสารเอียงและเอกสารผสมภาษา EasyOCR ออกมาเป็นตัวอักษรปนสัญลักษณ์แปลกๆ เยอะ (เช่น ::: แทรกกลางคำไทย)
• ฟอนต์สำคัญมาก — Thonburi (ฟอนต์บางสวย ที่ใช้ในงานพิมพ์จริง) ทำ Tesseract พลาดหนัก (24%) ขณะที่ Ayuthaya/Sathu (ฟอนต์หนา อ่านง่าย) ได้ 2–4% → ทดสอบกับฟอนต์ที่ใช้จริงเสมอ
• RapidOCR default ใช้กับไทยไม่ได้เลย — model ONNX ดีฟอลต์รองรับแค่จีน+อังกฤษ (ต้องใช้ PaddleOCR multilingual weights ถึงจะอ่านไทยได้)
• EasyOCR ช้ากว่าและแผง paragraph รวมบรรทัดเพี้ยน — ~10–22 วินาที/ภาพ บน CPU vs Tesseract ~1 วินาที/ภาพ

ข้อจำกัดของเทสนี้ (ต้องบอกตรงๆ):รูปทดสอบเป็น synthetic render ไม่ใช่ scan จริงจากเครื่องถ่ายเอกสาร — scan จริงมักมี noise, เงา, กระดาษเหลือง ที่ทดสอบยากกว่านี้ และเครื่องมืออย่าง PaddleOCR, Surya, Typhoon OCR ต้องการ GPU หรือ PaddlePaddle framework ที่ไม่ได้ลงในเครื่องนี้ จึงไม่ได้วัดจริง ผลนี้ใช้เป็น "สัญญาณเบื้องต้น" ไม่ใช่ benchmark ที่การันตี — เอกสารจริงของคุณอาจให้ผลต่างออกไปมาก

สรุปคือ: สำหรับงานจริง อย่าเชื่อผลเทสเล็กๆ ชุดเดียว — แต่ถ้าต้องเริ่มเลยโดยไม่มีเวลา ทดสอบของผมชี้ว่าTesseract + tha traineddata ยังเป็น baseline ที่แข็งแรงโดยเฉพาะถ้า preprocess รูปดีๆ ก่อน

11. สรุป: Decision Guide

• เริ่มเร็ว prototype → EasyOCR
• สแกนสะอาด ปริมาณมาก ประหยัดสุด → Tesseract
• Production ทั่วไป เอกสารหลากหลาย → PaddleOCR
• Document AI, RAG, structure สมบูรณ์ → Surya OCR
• เอกสารไทยจริงจัง ฟอร์ม ลายมือ → Typhoon OCR

คำแนะนำสุดท้ายจากประสบการณ์จริง:สำหรับงานจริงจังในไทย ผมแนะนำ hybrid approach — ใช้ PaddleOCR หรือ Tesseract เป็น base OCR (เร็ว ถูก stable) แล้วใช้ Typhoon OCR หรือ LLM เป็น post-processor สำหรับเอกสารที่ยาก — ได้ accuracy สูงโดยไม่ต้องจ่าย GPU แพงตลอด และสำหรับ RAG/document AI — Surya คุ้มค่าที่จะเรียนรู้เพิ่ม

อย่าลืมว่า OCR ภาษาไทยยังเป็น "ปัญหาที่ยังไม่ solve สมบูรณ์" — ไม่มี engine ไหน perfect 100% สำหรับทุกเคส สิ่งที่สำคัญคือเลือก engine ที่ "พอ" สำหรับ use case ของคุณ แล้ว invest ใน preprocessing + post-processing ที่ดี มากกว่าการหา engine ที่ "ดีที่สุด"

ลิงก์ repo ทั้งหมดอยู่ในบทความนี้ — ลอง clone มาทดสอบกับเอกสารจริงของคุณได้เลยครับ