DeepSeek OCR - โมเดล OCR ประสิทธิภาพสูงพิเศษผ่านการบีบอัดบริบทเชิงภาพ

 (github.com/deepseek-ai)
16 คะแนน โดย GN⁺ 2025-10-21 | 1 ความคิดเห็น | แชร์ทาง WhatsApp
  • เริ่มต้นจากข้อสังเกตว่า “หากแสดงข้อความเป็นภาพ ก็สามารถบรรจุข้อมูลเดียวกันได้ด้วยโทเคนน้อยกว่ามาก”
  • เป็นโมเดลที่เสนอแนวทางใหม่ในการ บีบอัดข้อมูลข้อความเป็นการแทนค่าเชิงภาพแบบ 2D และตรวจสอบเชิงทดลองแนวคิด การบีบอัดด้วยวิชัน (Optical Compression) เพื่อจัดการบริบทยาวได้อย่างมีประสิทธิภาพ
  • โมเดลประกอบด้วย DeepEncoder (ตัวเข้ารหัส) และ DeepSeek3B-MoE-A570M (ตัวถอดรหัส) โดยทำได้ทั้งการใช้หน่วยความจำที่แอ็กทีฟต่ำกับอินพุตความละเอียดสูง และ อัตราการบีบอัดโทเคนระดับ 10~20 เท่า
  • ยังคงรักษา ความแม่นยำ OCR 97% ที่การบีบอัด 10 เท่า และ ความแม่นยำมากกว่า 60% ที่การบีบอัด 20 เท่า ซึ่งชี้ให้เห็นความเป็นไปได้เชิงปฏิบัติสำหรับ งานวิจัยด้านการบีบอัดบริบทยาวและกลไกการลืมของความจำ
  • บน OmniDocBench ให้ผลเหนือกว่า GOT-OCR2.0 (256 โทเคน/หน้า) ด้วย vision token เพียง 100 โทเคน และเหนือกว่า MinerU2.0 (เฉลี่ย 6000+ โทเคน/หน้า) ด้วย ไม่เกิน 800 โทเคน
  • ใช้ GPU A100-40G เพียงตัวเดียวก็สามารถ สร้างข้อมูลได้มากกว่า 200,000 หน้าต่อวัน และมีคุณค่าเชิงปฏิบัติสูงในฐานะ เอนจินข้อมูลสำหรับการฝึก LLM/VLM ขนาดใหญ่

1. ภูมิหลังของงานวิจัย

  • LLM แบบเดิมมีข้อจำกัดเชิงโครงสร้างที่ ปริมาณการคำนวณเพิ่มขึ้นแบบกำลังสองตามความยาวของลำดับ
  • งานวิจัยนี้เริ่มจากข้อสังเกตว่า “หากแสดงข้อความเป็นภาพ ก็สามารถบรรจุข้อมูลเดียวกันได้ด้วยโทเคนน้อยกว่ามาก”
  • ผู้วิจัยนิยามสิ่งนี้ว่าเป็น การบีบอัดบริบทยาวด้วยวิชันโทเคน (Context Optical Compression) และใช้ OCR เป็นสนามทดลอง
  • ผลลัพธ์แสดงให้เห็นว่า การแทนค่าเชิงภาพอาจเป็นเส้นทางใหม่ในการเพิ่มประสิทธิภาพการจัดการบริบทของ LLM

2. โครงสร้างโมเดล

  • DeepSeek-OCR = DeepEncoder + ตัวถอดรหัส DeepSeek3B-MoE
    • DeepEncoder: SAM(Window Attention) + CLIP(Global Attention) + ตัวบีบอัดโทเคน 16 เท่า
    • DeepSeek3B-MoE: กระตุ้นใช้งาน 6 ผู้เชี่ยวชาญจากทั้งหมด 64 คน รวมเป็น พารามิเตอร์ที่แอ็กทีฟ 570M
  • รองรับ โหมดหลายความละเอียด (Tiny~Gundam)
    • รองรับอินพุตความละเอียด 512~1280 และประมวลผลแบบผสานได้สูงสุด 9 ไทล์
    • โหมด Gundam รองรับเอกสารความละเอียดสูงมาก (เช่น หนังสือพิมพ์) โดยใช้ vision token ได้สูงสุด 800 โทเคน

3. เอนจินข้อมูล

  • การผสมข้อมูลทั้งหมด 3 ประเภท:
    • ข้อมูล OCR 1.0: เอกสาร 30M หน้า (100 ภาษา) พร้อม annotation รายละเอียดด้านเลย์เอาต์และข้อความ
    • ข้อมูล OCR 2.0: ข้อมูล 16M สำหรับการรู้จำแบบซับซ้อน เช่น แผนภูมิ สูตรเคมี (SMILES) และรูปทรงเรขาคณิต
    • ข้อมูลวิชันทั่วไป: สำหรับคงความสามารถด้านความเข้าใจภาพแบบ CLIP คิดเป็น 20% ของทั้งหมด
    • ข้อมูลข้อความล้วน: สัดส่วน 10% เพื่อเสริมความสามารถทางภาษา
  • สัดส่วนองค์ประกอบของข้อมูลฝึกทั้งหมด
    • OCR 70% / วิชัน 20% / ข้อความ 10%

4. ไปป์ไลน์การฝึก

  • ฝึกแบบสองขั้นตอน: DeepEncoder → DeepSeek-OCR
  • ใช้ทั้งหมด 20 โหนด (8×A100 GPU) ที่ data parallelism DP=40 และ global batch 640
  • ความเร็วการฝึก: ข้อมูลข้อความ 90B โทเคน/วัน, ข้อมูลมัลติโหมด 70B โทเคน/วัน

5. ผลการประเมิน

(1) การทดลองการบีบอัด (Fox benchmark)

  • ที่การบีบอัด 10 เท่าได้ ความแม่นยำ 97% และที่ 20 เท่ายังคง มากกว่า 60%
  • ยิ่งเอกสารยาวหรือซับซ้อนมาก ประสิทธิภาพจะยิ่งลดลง แต่ตีความได้ว่าเป็นความเป็นไปได้ในการจำลอง “กลไกการลืม”
  • เมื่ออัตราการบีบอัดไม่เกิน 10× สามารถ กู้คืนบริบทได้แทบไม่สูญเสียข้อมูล

(2) การรู้จำเอกสารจริง (OmniDocBench)

  • เปรียบเทียบโหมด Tiny(64 โทเคน)~Gundam(800 โทเคน)
    • เหนือกว่า GOT-OCR2.0(256 โทเคน) ในโหมด Small(100 โทเคน)
    • เหนือกว่า MinerU2.0(7,000 โทเคน) ด้วย Gundam(800 โทเคน)
  • เอกสารแต่ละประเภทต้องการจำนวนโทเคนต่างกัน
    • สไลด์, รายงาน: 64~100 โทเคนก็เพียงพอ
    • หนังสือพิมพ์, งานวิจัย: ต้องใช้ 400~800 โทเคน

6. การวิเคราะห์เชิงคุณภาพ (Qualitative Study)

  • โหมด Deep Parsing
    • สามารถ ดึงโครงสร้างออกมาได้ด้วยพรอมป์ต์เดียว ตั้งแต่แผนภูมิ รูปทรง สูตรเคมี ไปจนถึงภาพธรรมชาติ
  • การรู้จำหลายภาษา
    • รองรับ PDF ราว 100 ภาษา รวมถึงภาษาที่ใช้น้อยอย่างอาหรับและสิงหล
  • ความเข้าใจภาพทั่วไป
    • ทำได้ทั้งการอธิบายภาพ การตรวจจับวัตถุ และ grounding
    • เมื่อเชื่อมกับ LLM สามารถใช้เป็น โมเดลฐานสำหรับการให้เหตุผลแบบผสมวิชัน-ภาษา

7. การอภิปรายและนัยสำคัญ

  • DeepSeek-OCR เป็น การทดลองแรกที่สำรวจขอบเขตของการบีบอัดข้อความยาวด้วย vision token
    และทำให้แนวคิด “หนึ่งภาพแทนได้พันคำ” ถูกวัดเชิงปริมาณได้
  • แม้ที่อัตราการบีบอัด 10× ก็ยังสามารถกู้คืนได้แทบไม่สูญเสียข้อมูล → ขยายไปสู่ การบีบอัดประวัติการสนทนา การเพิ่มประสิทธิภาพหน่วยความจำระยะยาว ได้
  • เสนอการจำลอง การเสื่อมของโทเคนคล้ายเส้นโค้งการลืมเชิงชีวภาพ ผ่านแนวทาง “ลดความละเอียดของภาพลงเมื่อเวลาผ่านไป”

8. บทสรุป

  • DeepSeek-OCR เป็น โมเดลพิสูจน์เชิงประจักษ์ของการแมปการบีบอัด 10~20 เท่าระหว่างข้อความกับภาพ
    และนำเสนอพาราไดม์ใหม่เพื่อ ก้าวข้ามข้อจำกัดของ LLM ในการจัดการบริบทยาว
  • นอกเหนือจาก OCR แล้ว ในอนาคตยังมีแนวโน้มขยายไปสู่ digital-optical mixed pretraining และ
    โมเดลบริบทยาวมากที่อิงกับ ‘Optical Context Memory’
  • มีการเผยแพร่โค้ดแล้ว และสามารถนำไปใช้ได้ทั้งในการวิจัยและเป็นเอนจินข้อมูลเชิงพาณิชย์

สรุปเนื้อหาใน Repo : https://github.com/deepseek-ai/DeepSeek-OCR

  • DeepSeek-OCR ได้รับความสนใจในฐานะสถาปัตยกรรมที่อิง LLM ซึ่ง เข้ารหัสข้อมูลเชิงภาพได้อย่างมีประสิทธิภาพ เมื่อเทียบกับโอเพนซอร์ส OCR แบบเดิม
  • รองรับ ความละเอียดหลากหลาย (512×512~1280×1280) และมีโหมด Gundam สำหรับความละเอียดแบบไดนามิก จึงตอบโจทย์สภาพแวดล้อมที่หลากหลายได้ดี
  • ด้วยการออกแบบพรอมป์ต์ที่ชัดเจน จึง รองรับโหมดงานหลากหลาย เช่น การอธิบายภาพทั่วไป การแปลงเป็น Markdown, OCR แบบไม่สนใจเลย์เอาต์, การแยกวิเคราะห์แผนภูมิ
  • มีการยืนยันประสิทธิภาพผ่านการทำงานร่วมกับเบนช์มาร์กในอุตสาหกรรมอย่าง Fox, OminiDocBench และการทดลองประมวลผลเอกสารจริง
  • มีการนำ จุดแข็งและแนวคิดของโปรเจ็กต์ยอดนิยมอื่น ๆ เช่น GOT-OCR2.0, PaddleOCR มาปรับใช้ในการพัฒนา
  • ความละเอียดที่รองรับ
    • Tiny: 512×512 (64 vision tokens)
    • Small: 640×640 (100 vision tokens)
    • Base: 1024×1024 (256 vision tokens)
    • Large: 1280×1280 (400 vision tokens)
    • Dynamic mode(=Gundam): ความละเอียดอิสระ (n×640×640 + 1×1024×1024)
  • การอนุมานแบบขนานสำหรับ PDF และภาพ พร้อมความเร็วการประมวลผลสูง
    • อ้างอิงจาก A100 GPU สามารถประมวลผล PDF ได้ราว 2,500 โทเคน/วินาที
  • ภูมิหลังทางเทคนิคและความเชื่อมโยงกับระบบนิเวศ
    • พัฒนาใน Python 100%
    • รองรับทั้งสองสภาพแวดล้อมอนุมานหลักคือ vLLM และ Transformers
    • ใช้เบนช์มาร์กและเฟรมเวิร์กประเมินผลหลัก เช่น OpenChart, Fox, OminiDocBench
    • เชื่อมต่อกับโมเดลก่อนหน้าอย่าง GOT-OCR2.0, PaddleOCR, Vary รวมถึงนำแนวคิดมาใช้และเสริมประสิทธิภาพ

บทความที่เกี่ยวข้อง

1 ความคิดเห็น

 
GN⁺ 2025-10-21
ความเห็นจาก Hacker News

  • งานวิจัยนี้ไม่ได้เป็นแค่ VLM สำหรับ OCR อีกตัวหนึ่งเท่านั้น แต่ยังขยับไปสู่ประเด็นที่น่าสนใจกว่าอย่างการบีบอัดด้วย
    ตัวอย่างเช่น มีข้อความอ้างว่า "เราได้ทำการศึกษาระยะแรกเพื่อสำรวจขอบเขตของการบีบอัดวิชัน-ข้อความ โดยดูว่าต้องใช้ vision token กี่ตัวในการถอดรหัส text token ผลลัพธ์เบื้องต้นคือ DeepSeek-OCR ทำ OCR compression แบบแทบไม่สูญเสียข้อมูลได้ที่อัตราประมาณ 10 เท่า และแม้บีบอัด 20 เท่าก็ยังรักษาความแม่นยำได้ 60%"
    ถ้ามองแบบสัญชาตญาณ ก็เหมือน vision token หนึ่งตัวเก็บข้อมูลได้พอ ๆ กับ text token 10 ตัว
    อยากให้มีคนอธิบายว่าทำไมในเชิงทฤษฎีสารสนเทศถึงได้ผลแบบนี้ โดยให้มือใหม่พอเข้าใจได้
    สงสัยว่าเป็นเพราะ text token ยังละเอียดเกินไปอยู่มาก (หรือมีความซ้ำซ้อน) และยังไปไม่ถึง entropy coding หรือเป็นเพราะพอย้ายไปใช้ vision token แล้วหลุดพ้นจากข้อจำกัดแบบ 'ระดับคำ' จนเข้าใกล้ entropy ได้มากกว่า (คล้ายความต่างระหว่าง arithmetic encoding กับ Huffman code)
    และในตัวงานวิจัยก็ยังพูดถึงการลดขนาดภาพจริง ๆ เมื่อจัดการกับคอนเท็กซ์ขนาดใหญ่ รวมถึงความสัมพันธ์ของการสูญเสียข้อมูลระหว่างโดเมนข้อความกับโดเมนภาพด้วย

    • text token เป็นหน่วยย่อยแบบ quantized (subword) ส่วน vision token มีอยู่ใน embedding space เท่านั้น
      ใน LLM วิธี tokenize ข้อความคือโครงสร้างตาราง lookup ระหว่าง token ID (ขนาดเล็ก) กับ vector embedding (ขนาดใหญ่)
      เวลาเอาข้อความเข้า LLM ก็จะตัดสตริงตามขอบเขต token แปลงเป็น token ID แล้วดึงเวกเตอร์จากตาราง lookup มาสร้างเป็นเมทริกซ์ (context matrix)
      การส่งลำดับ text token จริง ๆ มีประสิทธิภาพ เพราะส่งแค่อาร์เรย์ของตัวเลข (ID) ก็พอ (โดยทั่วไปมี token ID ไม่ซ้ำกันราว ~100k)
      ในทางกลับกัน ถ้าจะส่ง embedding matrix เองจะไม่มีประสิทธิภาพ เพราะ embedding ประกอบด้วยเลข float หลายพันค่า
      ภาพถูกเข้ารหัสต่างออกไป โดย preprocess ข้อมูลภาพแล้วป้อนเข้า image encoder แบบโครงข่ายประสาทโดยตรง เพื่อแปลงเป็นเวกเตอร์และรวมเข้าไปในคอนเท็กซ์
      กล่าวคือ image token ไม่มีทั้ง token ID และไม่มี lookup table แต่ไปจากข้อมูลสู่ embedding โดยตรง
      ผลคือถ้าจะส่ง image token ก็ต้องส่ง embedding เอง จึงไม่มีประสิทธิภาพ
      แม้ภาพจะถูกเข้ารหัสด้วย token น้อยกว่า แต่ความจุของแต่ละ token ใหญ่มาก
      สรุปคือ text token เป็นจำนวนเต็ม (0~n) ที่มีการแมปไปยังเวกเตอร์อย่างชัดเจน จึงมีตัวเลือกอยู่ 'n' แบบ
      ขณะที่ image token เป็นอาร์เรย์ float m มิติ (เวกเตอร์) จึงมี token space ที่ใหญ่กว่ามาก
      ในแง่แพตเทิร์น text token ตรงกับไบต์ UTF-8 ที่ต่อเนื่องกันโดยตรง และส่วนใหญ่ไม่ข้ามพรมแดนของคำ ดังนั้นแพตเทิร์นระดับโกลบอล (เช่น “ประโยคนี้มาจาก Hamlet”, “ส่วนนี้เป็นภาษาสเปน”) จึงไม่สามารถแทนได้ด้วย token เดียว

    • ไม่แน่ใจนักว่าใน multimodal LLM ฝังภาพอินพุตเป็น embedding อย่างไร แต่เข้าใจพื้นฐานว่าคือตัดภาพเป็นกริดแล้วเข้ารหัสแต่ละบริเวณ
      ในการทดลองของ DeepSeek แก่นสำคัญดูไม่ใช่คุณสมบัติเชิงทฤษฎีสารสนเทศ แต่เป็นการดูว่าสามารถลดความละเอียดหรือทำให้กริด (patch) ใหญ่ขึ้นได้แค่ไหน โดยยังเก็บรายละเอียดพอสำหรับทำ OCR ให้แม่นยำอยู่
      อยากให้ Karpathy ขยาย NanoChat เป็น multimodal แล้วมาแชร์เคล็ดลับของกระบวนการเข้ารหัสแบบนี้

    • อัตราการบีบอัดที่เหมาะสมสุดท้ายก็หลีกไม่พ้นที่จะขึ้นกับความละเอียดของตัวอักษรแต่ละตัว และขนาดสัมพัทธ์ของแต่ละ vision token patch
      เพราะมีเพียงแบบนี้เท่านั้นที่จำนวน text token ที่ดึงออกมาด้วย OCR จะคงอยู่โดยไม่ขึ้นกับความละเอียดของภาพ

    • text token แต่ละตัวส่วนใหญ่เป็นระดับ subword แต่ vision token ของ VLM อยู่ใน semantic space
      semantic space สามารถบีบอัดข้อมูลได้ทรงพลังกว่าการแบ่งย่อยแบบ subword มาก
      หมายเหตุ: ไม่ใช่ผู้เชี่ยวชาญ แค่คิดสด ๆ

    • LLM มีโครงสร้างที่ปริมาณการคำนวณเพิ่มขึ้นเป็นกำลังสองตามจำนวน token
      ดังนั้นใน VLM จึงพยายามบีบ text token ให้เป็น vision token
      เดาว่าเขาพยายามเรนเดอร์ข้อความเป็นภาพก่อน แล้วค่อย tokenize เพื่อลดต้นทุนการคำนวณ

  • บน NVIDIA Spark (ARM64) การใช้ PyTorch ค่อนข้างจุกจิก แต่พอรัน Claude Code ใน Docker container ใหม่ด้วยสิทธิ์ root ก็ทำให้ใช้งานได้
    ดูบันทึกละเอียดได้ที่นี่
    ผลลัพธ์จริงดูได้ที่ลิงก์นี้ โดยทดสอบกับภาพ OCR ต้นฉบับ(ที่นี่)

    • ผล OCR โดยรวมแข็งแรงมาก
      แต่ในย่อหน้าถัดจากคำพูดอ้างอิงทันที มันเติมเนื้อหาที่ไม่จำเป็นเข้าไปจนเกิด hallucination และยังลากไปเชื่อมกับคอลัมน์ถัดไปด้วย
      ขอบคุณที่ช่วยทดสอบอย่างรวดเร็ว

    • พอเข้าใจได้ที่พลาดตัว "A" ตอนต้นข้อความ (เดาว่าสัดส่วนบทความข่าวใน dataset คงไม่มาก)
      แต่ที่น่าสนใจกว่าคือมันพลาดทั้ง "Hallucination is a risk and..." ทั้งหมด หัวข้อข้างชื่อผู้เขียน ("theme") และส่วนอีเมลท้ายสุดไปทั้งหมด

    • แค่การทดลองนี้อย่างเดียวก็มีคุณค่าพอจะเขียนเป็นโพสต์แยกได้แล้ว

    • "รัน Claude Code เป็น root ใน Docker container ใหม่"
      อยากรู้รายละเอียดว่าตั้งค่าให้รันด้วยสิทธิ์ root อย่างไร
      (ถ้ามีอธิบายไว้ก็จะไปอ่านในต้นฉบับ)

  • ในงานวิจัยไม่มีการพูดถึง Anna’s Archive
    คิดว่าเป็นไปได้ว่า DeepSeek อาจใช้ข้อเสนอจาก Anna ที่อนุญาตให้นักวิจัย OCR เข้าถึงคอลเลกชันหนังสือสารคดีภาษาจีน 7.5 ล้านเล่ม (350TB) จริง
    ปริมาณนี้ใหญ่กว่า Library Genesis เสียอีก
    บล็อกอ้างอิง

    • งานวิจัยก่อนหน้าของ DeepSeek อ้างถึง Anna’s Archive โดยตรง
      "คัดชุดข้อมูลจากหนังสืออิเล็กทรอนิกส์ภาษาอังกฤษ 860K เล่ม ภาษา Chinese 180K เล่มจาก Anna’s Archive และข้อสอบการศึกษาระดับ K-12 หลายล้านข้อ"
      ดู งานวิจัย DeepSeek-VL

    • สงสัยว่าถ้าเขาเก็บหนังสือของคนอื่นไว้เฉย ๆ ทำไมต้องไปรับสิทธิ์เข้าถึงด้วย

    • ฉันเองก็นึกถึง Anna’s Archive ทันทีเหมือนกัน และสงสัยว่าเมื่อไร dataset ที่ผ่าน OCR แล้วจะถูกปล่อยออกมา

    • มันก็หมายความว่าชุดข้อมูลอาจไม่มีวันถูกเปิดเผยเลย

    • ถ้าเป็นแบบนี้ก็กังวลว่า Anna’s Archive สุดท้ายอาจถูกบริษัท LLM ใช้งานเกินขอบเขตจนหายไป
      แค่ META ไปดูด 70TB จาก library genesis ผ่าน torrent ก็หนักพอแล้ว

  • ขอแชร์ประสบการณ์เกี่ยวกับระดับความสามารถจริงของ benchmark ต่าง ๆ ในปัจจุบัน

    • OmniAI benchmark ไม่ค่อยดี

    • แนะนำ OmniDocBench แทน

    • Mistral OCR ด้อยกว่าทั้งโมเดล OCR แบบโอเพนซอร์สและ Gemini อย่างชัดเจน

    • E2E OCR ยังยากมากอยู่

    • วิธีแบบ pipeline (ตรวจจับเลย์เอาต์ → หาลำดับการอ่าน → OCR แต่ละองค์ประกอบ) ทำงานได้ดีกว่า

    • การ parse ตารางซับซ้อนยังเป็นโจทย์ใหญ่

    • อยากรู้เหมือนกันว่า Apple Vision Framework ถ้าเอาไป benchmark เทียบกับโมเดลพวกนี้จะเป็นอย่างไร
      มันมากับอุปกรณ์ Apple แทบทุกเครื่อง และในทางปฏิบัติก็ให้ OCR ที่ทั้งเร็วและคุณภาพดี (โดยเฉพาะใช้แปลง PDF) แต่คนดูจะไม่ค่อยพูดถึง
      อยากรู้มากว่าอยู่ระดับไหนใน benchmark

    • ตาม OmniAI benchmark, Omni OCR ทำผลงานดีที่สุด
      ดูเหมือนทุกคนคงเชื่อตามผลนี้แบบไม่ตั้งคำถาม

  • สงสัยว่า OCR แบบอาศัย LLM มีข้อดีและความต่างอะไรเมื่อเทียบกับบริการอย่าง Azure AI Document Intelligence(ลิงก์) หรือ Google Vision API(ลิงก์)

    • OmniAI ทำ benchmark เปรียบเทียบ LLM ของตัวเองกับ cloud OCR
      Benchmark ในบล็อก OmniAI (ณ กุมภาพันธ์ 2025)
      หลังจากนั้น LLM ก็พัฒนาเร็วมาก
      ช่วงหลังนี้ผลลัพธ์ดีที่สุดดูจะเป็นสาย Qwen3-VL โดยเฉพาะ Qwen3-VL-235B-A22B-Instruct

    • เดาว่าโมเดล OCR เชิงพาณิชย์/ปิดซอร์สยังคงเหนือกว่าในเอกสารใช้งานจริง
      เพราะมีชุดข้อมูลฝึก private คุณภาพสูงจำนวนมาก
      LLM สาธารณะถูกฝึกจากข้อมูลแนวบทความ arxiv, อีบุ๊ก ฯลฯ เป็นหลัก จึงย่อมด้อยกว่าในเอกสารธุรกิจจริง
      วิธีแบบ LLM ลดข้อผิดพลาดจากการแทนตัวอักษรผิด (พิมพ์ผิด/แปรรูปผิด) ได้ แต่ความสม่ำเสมอระดับทั้งหน้าอาจกลับแย่ลง
      และยังอาจให้ผลลัพธ์เพี้ยนไปคนละเรื่องเหมือน LLM ที่ไม่ใช่ OCR ได้ด้วย

    • สำหรับอักษร CJK วิธี OCR แบบเดิมยังสร้างการแทนที่ผิด ๆ จำนวนมากอยู่
      เพราะมีอักขระที่หน้าตาคล้ายกันมากจนบางครั้งต้องดูระดับกล้องจุลทรรศน์หรือระดับไบนารีถึงจะแยกได้
      LLM บังคับลำดับอักขระที่เป็นไปได้ให้แคบลงได้มากกว่า จึงน่าจะให้ผลแม่นยำกว่า
      อย่างน้อยข้อกังวลนี้ก็เป็นแรงผลักให้คนอยากใช้ OCR แบบ LLM

    • ไม่รู้โมเดลอื่น แต่บริษัทเรารันระบบ parse เรซูเม่ด้วย Azure AI Document Intelligence และค่อนข้างพอใจมาก
      ตอนแรกแค่ต้องตั้ง tuning ดี ๆ หน่อย แล้วตลอดปีที่ผ่านมาก็แทบไม่ต้องไปแตะอะไรอีก

  • ฉันทดสอบ VLM หลายตัวแล้ว ตั้งแต่โมเดลเล็กถึงใหญ่ (Granite, Qwen ฯลฯ) และข้อสรุปคือมันยังน่าผิดหวังถ้าจะใช้แทน OCR แบบเดิมทั้งหมด
    ระบบของเรารับเอกสารจากลูกค้า แล้วส่งคืนเป็นเอกสารมาตรฐานที่มีมาร์กอัปตามที่ขอ (multi-page bitmap แบบ raster)
    สำหรับเรา ความแม่นยำในการดึงพิกัดระดับตัวอักษรหรือคำจากข้อมูลสำคัญมาก แต่ในทางปฏิบัติข้อมูลตำแหน่งจาก VLM แกว่งมากเกินไป หรือ hallucinate ไปเลย หรือกำกวมเกินกว่าจะรับประกันความแม่นยำ/ความละเอียดที่ต้องการ
    ตอนนี้เรายังใช้ Tesseract-based ร่วมกับรูทีน clean-up และใช้เอาต์พุตข้อความจาก VLM เป็นตัวช่วยเสริมเป็นครั้งคราวเฉพาะตอนที่ไม่มี structured dataset
    เคสของเราอาจเป็นความต้องการเฉพาะทางมาก และสำหรับคนส่วนใหญ่แค่ได้ text dump หรือแปลงเป็น Markdown/HTML ได้ก็คงพอแล้ว
    แต่รู้สึกว่ามีช่องว่างค่อนข้างมากระหว่างคำกล่าวอ้างว่าโมเดลเหล่านี้ 'แก้ OCR ได้หมดแล้ว' กับประสบการณ์ใช้งานจริง

    • ขอเสนอให้ลอง moondream 3 preview
      ในบล็อกเขาบอกว่ามันเหนือกว่า VLM หลายตัว และเป็นโมเดลที่เบา
      ดู หน้าหลัก, โมเดล, บล็อก

    • เอกสารลูกค้ามีข้อความเขียนด้วยลายมือด้วยหรือเปล่า

    • วิธีหนึ่งคือใช้ CNN หา bounding box ของข้อความก่อน แล้วค่อยรัน VLM ทีละกล่องก็ได้

  • โดยส่วนตัวรู้สึกว่า OCR น่าจะเป็นปัญหาที่แก้ได้พอสมควรแล้ว
    OmniAI benchmark ก็ไม่ได้อัปเดตด้วยโมเดลใหม่ ๆ ซึ่งคิดว่าน่าจะเพราะ LLM ทั่วไปทำได้ดีกว่า OCR ใน benchmark นั้นเสียแล้ว
    ในทางปฏิบัติ แค่ป้อนภาพแต่ละหน้าให้ Gemini 2.5 Flash Lite แล้วให้ดึงออกมาเป็น Markdown ก็เสียค่าใช้จ่ายราว 20 เซ็นต์ต่อ 1000 หน้า และผลลัพธ์ก็ดีมาก
    เลยสงสัยว่าตอนนี้อะไรคือส่วนที่ยังยากของ OCR

    • OCR/LLM ส่วนใหญ่ (โดยเฉพาะ Gemini Pro 2.5) ก็ยังลำบากกับการแปลงตารางซับซ้อนเป็น Markdown/HTML
      เจอปัญหาอย่างหลาย header, cell ที่ merge กัน, คอลัมน์ที่มี checkbox บ่อยมาก และยังไม่เข้าใจตารางที่ลากยาวหลายหน้าได้ดี
      Llamaindex ก็พังหนักเหมือนกัน
      อยากรู้ว่า OCR/LLM ตัวไหนจัดการปัญหาแบบนี้ได้ดีกว่า
      ตัวอย่างตารางซับซ้อน, ตัวอย่าง ICAO checklist แบบเต็ม

    • จริง ๆ แล้วไม่ใช่ OCR แต่ HTR (การถอด/รู้จำลายมือ) ต่างหากที่ยังยาก
      LLM ช่วยให้ความแม่นยำดีขึ้นมาก แต่ข้อผิดพลาดกลับยิ่งหาคนตรวจเจอยาก (เพราะส่วนที่อ่านไม่ออกมันจะมั่วเติมเองทั้งดุ้น)

    • ถ้ายอมรับได้ที่มันไม่บอกว่า "ไม่รู้" ในส่วนที่อ่านไม่ออก แต่กลับจินตนาการเติมเอาเองทั้งหมด ก็ถือว่าแก้ปัญหาได้แล้วล่ะ
      (ไม่ได้ประชดนะ ในบางสถานการณ์มันก็โอเคจริง ๆ)

    • ฉันเป็นคนเขียน OmniAI benchmark เอง
      สาเหตุที่ไม่มีอัปเดตโมเดลใหม่ เพราะเราลดความสำคัญของ OCR API ในตัวผลิตภัณฑ์
      ภายในยังใช้อยู่ แต่ benchmark ไม่ได้อัปเดตเพราะขี้เกียจ
      Gemini เก่ง OCR ที่สุด
      แต่ถ้าผลลัพธ์ไปใกล้กับข้อมูลฝึกมากเกินไป จะเกิดข้อผิดพลาดแบบ 'recitation' บ่อย คือเอาต์พุตจะขาดหายไปกะทันหันราว 10%
      และถ้าในชุด PDF มีหน้าว่างปนอยู่ มันก็มี hallucination ตลก ๆ โดยแต่งเนื้อหาแปลก ๆ ขึ้นมา
      OpenAI ก็ไม่ได้แย่ แต่ GPT5 ไม่ได้ต่างจาก GPT-4o หรือ 4.1 มากนัก
      เนื้อหาบางส่วนอย่าง header/footer มักหาย และถ้าหน้ากระดาษหมุนข้างจะรวนหนัก
      บางครั้งยังปฏิเสธเองเมื่อเป็นบัตรประชาชน เอกสารทางการแพทย์ หรือข้อมูลที่มีความเสี่ยงด้าน PII สูง

    • รู้สึกว่าไกลจากคำว่าแก้ได้แล้วมาก
      ลองเอานิตยสารที่มีเลย์เอาต์ประหลาด ๆ มาทำ OCR ดูสิ แทบเป็นไปไม่ได้
      ฉันสะสมนิตยสารวินเทจและลอง OCR ด้วยเทคโนโลยีใหม่สุดอยู่เสมอ แต่สุดท้ายก็ยังต้องใช้แรงคนเยอะมากทุกที

  • อยากรู้ว่ามี 'โมเดล OCR' ตัวเล็ก ๆ ไหม
    งานคือดึงแค่ serial number จากภาพถ่ายหน้างานในโรงงาน ไม่ต้อง parse เอกสารทั้งฉบับ
    ใช้โมเดล 3B พารามิเตอร์กับงานแค่นี้มันเกินจำเป็นไปมาก

  • อยากรู้ว่า DeepSeek-OCR เทียบกับ Tesseract(ลิงก์) เป็นอย่างไร
    ฉันใช้ ocrmypdf(ลิงก์) เป็นประจำ และมันทำงานบนเครื่องตัวเองได้ดีมาก

    • ทุกวันนี้ benchmark ส่วนใหญ่พูดถึงทางเลือกแบบ LLM/VLM เป็นหลัก
      แต่ถ้าในความเป็นจริง tesseract ทำได้ 80% แล้วโมเดลล่าสุดขึ้นไปถึง 95%
      แต่ต้องแลกกับความต้องการโครงสร้างพื้นฐานอย่างพื้นที่ดิสก์ 100 เท่า, Kubernetes/Docker, GPU VRAM 16GB ฯลฯ แบบนั้นก็ควรเอามาชั่งน้ำหนักจริงจัง

  • สำหรับคนที่ตามงานวิจัยล่าสุดไม่ทัน อยากให้มีคนช่วยอธิบายง่าย ๆ แบบ ELI5 ว่านี่คืออะไร และสำคัญอย่างไร
    ทั้งชื่อใน GitHub และงานวิจัยบอกว่าเป็น OCR แต่ในสรุปกับ readme.md กลับพูดเรื่อง LLM context compression เลยงง
    อยากได้คำอธิบายในภาพใหญ่ ว่าทั้งสองเรื่องนี้เชื่อมกันอย่างไร

    • ยกตัวอย่างเช่น สมมติภาพหนึ่งมี 1000 คำ (แต่ละคำคือ 1 token)
      ภาพนั้นก็เท่ากับบรรจุข้อมูลระดับ '1000 token'
      ในทางปฏิบัติเราต้องแปลงภาพเป็น feature/embedding (ถอดรหัส) ก่อน
      ถ้าภาพนั้นถูกประมวลผลเป็น 'image token' 100 ตัว แล้ว image token เหล่านั้นถูกแปลงเป็น 'text token' 1000 ตัว
      ถ้ามองจากมุมการถอดรหัสอย่างเดียว เท่ากับเราส่งข้อมูลเอาต์พุตแบบบีบอัดมา 10 เท่า
      ในมุมของ LLM นี่หมายความว่าถ้าเราบีบอัดล่วงหน้าให้เป็น latent representation ที่เล็กลง 10 เท่าได้ ก็อาจสร้างผลลัพธ์ได้เท่าเดิมหรือมากกว่า โดยไม่ต้องใช้ token/embedding 1000 ตัว