Unlimited OCR — โมเดลพาร์สเอกสารยาวแบบช็อตเดียวของ Baidu

 (github.com/baidu)
1 คะแนน โดย GN⁺ 4 시간 전 | 1 ความคิดเห็น | แชร์ทาง WhatsApp
  • โมเดล OCR แบบ E2E ที่พัฒนาบนพื้นฐานของ DeepSeek OCR โดยแทนที่ attention ทั้งหมดในดีโคเดอร์ เพื่อถอดข้อความจากเอกสารหลายสิบหน้าได้ด้วย การทำ forward pass เพียงครั้งเดียว
  • หัวใจสำคัญคือ Reference Sliding Window Attention (R-SWA) ซึ่งทำให้ KV cache คงที่ แม้ความยาวในการดีโค้ดจะเพิ่มขึ้น จึงป้องกันการเพิ่มขึ้นของต้นทุนหน่วยความจำและการคำนวณ
  • เลียนแบบ working memory ของมนุษย์เวลาคัดลอกหนังสือ โดยค่อย ๆ ลืมเอาต์พุตที่อยู่ไกลออกไปและอ้างอิงเฉพาะบริบทใกล้เคียง
  • บน OmniDocBench v1.5 ทำได้ 93% เหนือกว่า DeepSeek OCR อยู่ 6% และบน v1.6 ได้ 93.92% ทำสถิติ SOTA แบบ end-to-end
  • R-SWA เป็นกลไก attention สำหรับการพาร์สทั่วไปที่นำไปใช้ได้ไกลกว่า OCR เช่นงาน ASR·การแปล ที่อิงข้อมูลอ้างอิงในงานข้อความยาว

พื้นหลังและการนิยามปัญหา

  • มนุษย์สามารถทำงานข้อความยาว เช่น ถอดความเอกสารหลายร้อยหน้า หรือแปลเสียงหลายชั่วโมง ได้โดยประสิทธิภาพแทบไม่ลดลง แต่โมเดล OCR เดิมยังพาร์สได้ไม่ถึง 10 หน้าในการทำ forward pass ครั้งเดียว
    • โมเดลปัจจุบันประมวลผลแบบแยกทีละหน้า (for-loop) และรีเซ็ตหน่วยความจำทุกขั้นตอน
    • วิธีนี้เป็นเพียง ทางอ้อมเชิงวิศวกรรม ที่แบ่งกระบวนการข้อความยาวที่ต่อเนื่องออกเป็นงานระยะสั้นที่แยกจากกัน ไม่ใช่ความก้าวหน้าไปสู่อินเทลลิเจนซ์แบบมุ่ง AGI
  • เมื่อใช้ LLM เป็นดีโคเดอร์ จะอาศัย prior distribution ของภาษาเพื่อเพิ่มประสิทธิภาพได้ แต่เมื่อเอาต์พุตยาวขึ้น KV cache ที่สะสมจะเพิ่มการใช้หน่วยความจำและทำให้ความเร็วในการสร้างลดลงทีละน้อย
  • พฤติกรรมการถอดความของมนุษย์ไม่เหมือนทั้ง full attention มาตรฐานและ linear attention
    • มนุษย์ไม่ไล่อ่านข้อความทั้งหมดที่เขียนไปแล้วซ้ำ แต่จะ อ้างอิงเฉพาะบริบทใกล้เคียง เพื่อรักษาทิศทาง
    • visual/reference token ไม่ได้รับการอัปเดตสถานะแบบวนซ้ำ — หากอัปเดตต่อเนื่อง คุณลักษณะเชิงภาพจะค่อย ๆ เลือนลงและทำให้ความแม่นยำในการรู้จำลดลง

Reference Sliding Window Attention (R-SWA)

  • แต่ละโทเค็นเข้าถึง reference token ทั้งหมดได้ (visual token + prompt) ขณะที่ attention ของเอาต์พุตถูกจำกัดไว้แค่ n โทเค็นก่อนหน้า (ค่าเริ่มต้น 128)
    • ทำให้แต่ละโทเค็นรับรู้ภาพทั้งหมดได้ ขณะเดียวกันก็ติดตามความคืบหน้าของ OCR ได้เองผ่านการเปลี่ยนสถานะภายใน sliding window เชิงเหตุเป็นผล
    • ระหว่างการอนุมาน KV cache จะคงที่ ช่วยลดแรงกดดันด้านหน่วยความจำและต้นทุนการคำนวณ
  • จำกัด attention ไว้ในหน้าต่าง 2 ช่วงขนาด m+n
    • m คือ prefix window ที่รวม visual token และ prompt ซึ่งคงที่ตลอดการอนุมานหนึ่งครั้ง และขึ้นอยู่กับจำนวนหน้า/ความละเอียดเท่านั้น ไม่ขึ้นกับความยาวในการดีโค้ด
    • n คือหน้าต่างของส่วนดีโค้ด ซึ่งมีขนาดคงที่และเลื่อนไปแบบเชิงเหตุเป็นผล

  • การจัดการ KV cache

    • เบสไลน์ DeepSeek OCR ใช้ MHA มาตรฐาน ทำให้ขนาด KV cache เพิ่มขึ้นไม่สิ้นสุดเป็น Lm + T
    • R-SWA เก็บ prefix cache ทั้งหมด Lm ไว้ แต่สำหรับส่วนที่สร้างขึ้นใหม่จะเก็บแค่ n รายการล่าสุด ทำให้ขนาดแคชเป็น Lm + min(n,T) ≤ Lm + n ซึ่งมีขอบบนคงที่
    • เมื่อความยาวเอาต์พุตมากพอ อัตราส่วนแคช ρ(T) จะลู่เข้าเป็น 0 → ลดการเติบโตแบบเชิงเส้นให้กลายเป็นค่าคงที่

  • การวิเคราะห์เคอร์เนล

    • จากการวัดเคอร์เนล Flash Attention v3 พบว่า MHA มาตรฐานของ DeepSeek OCR มี latency เพิ่มขึ้นทุกขั้นของการดีโค้ด ส่วน Unlimited OCR รักษาระยะเวลาให้คงที่ได้ด้วย R-SWA
    • DeepSeek OCR มีสไปก์เมื่อความยาว KV cache ข้ามขอบเขตการจัดแนวบางจุดเพราะประสิทธิภาพการส่งข้อมูลตกลงอย่างมาก ขณะที่ R-SWA ไม่เกิดปัญหานี้
    • หน่วยความจำ GPU ระหว่างอนุมานของโมเดลเดิมเพิ่มขึ้นแบบเชิงเส้น แต่ Unlimited OCR คงที่ — ความเสถียรทั้งด้านคำนวณและหน่วยความจำนี้เองที่ทำให้พาร์สข้อความยาวได้

สถาปัตยกรรมโมเดล

  • ใช้ DeepSeek OCR เป็นเบสไลน์ โดยผสาน DeepEncoder กับ MoE decoder (รวม 3B, active 500M พารามิเตอร์)
    • แทนที่ MHA เดิมด้วย R-SWA และเพิ่ม output KV buffer ความจุคงที่ n เข้ากับ reference KV cache m เพื่อรองรับการพาร์สข้อความยาว
    • KV cache ถูกทำเป็นคิวความจุ m+n โดยทุกครั้งที่สร้างโทเค็นใหม่ จะไล่ KV ของโทเค็นลำดับที่ (m+1) ออก เพื่อรับประกันว่าต้นทุนและหน่วยความจำจะไม่เพิ่มขึ้น

  • DeepEncoder

    • นำ SAM-ViT และ CLIP-ViT มาต่อแบบ cascade และใช้การบีบอัดโทเค็น 16 เท่าที่ bridge — ช่วงต้นประมวลผลโทเค็นภาพต้นฉบับด้วย window attention ส่วน global attention ใช้เฉพาะโทเค็นที่บีบอัดแล้ว
    • คง activation ให้ต่ำเมื่อเข้ารหัสภาพความละเอียดสูงเพื่อประหยัดหน่วยความจำ GPU และบีบอัดภาพ PDF ขนาด 1024×1024 ให้เหลือเพียง 256 โทเค็น
    • ใช้สองโหมดคือ "Base" สำหรับหลายหน้า (1024×1024) และ "Gundam" สำหรับหน้าเดียว (ความละเอียดแบบไดนามิก)
    • visual token ถูกเข้ารหัสครั้งเดียวและคงสภาพแบบสแตติกตลอดกระบวนการ โดยไม่เกิด state transition ร่วมกับเอาต์พุต

การตั้งค่าการฝึก

  • ฝึกด้วยข้อมูลเอกสาร OCR ราว 2 ล้านรายการ โดยมีสัดส่วนหน้าเดียวต่อหลายหน้า 9:1
    • PDF หน้าเดียวถูกทำ annotation ด้วย Paddle OCR แล้วเชื่อมพิกัดและเนื้อหาของแต่ละบล็อกเพื่อสร้าง ground truth โดยปรับพิกัดให้อยู่ในช่วง 0–1000
    • ข้อมูลหลายหน้าถูกสังเคราะห์จากการเชื่อมข้อมูลหน้าเดียว ใช้ <page> เป็นตัวคั่นในราว 2 แสนตัวอย่าง (2~50 หน้า) และแพ็กรวมเป็นลำดับโทเค็น 32K
  • ฝึกต่อจากเช็กพอยต์ DeepSeek OCR อีก 4,000 สเต็ป ด้วย global batch 256, ลำดับสูงสุด 32K, และใช้ 8×16 A800 GPU
    • ระหว่างฝึกจะตรึง DeepEncoder ไว้และฝึกเฉพาะพารามิเตอร์ของ LLM
    • ใช้ AdamW optimizer, cosine annealing scheduler, อัตราเรียนรู้เริ่มต้น 1e-4, DeepEP(EP=4), และอิงเฟรมเวิร์ก Megatron-LM
    • การอนุมานมีการติดตั้งการจัดการ KV cache สำหรับ R-SWA ในไลบรารี Transformers และรองรับการปรับให้เหมาะกับเอนจิน SGLang — ทั้งสองเฟรมเวิร์กทำงานด้วย TPS และหน่วยความจำ GPU แบบคงที่

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

  • เบนช์มาร์กหลักคือ OmniDocBench(v1.5/v1.6) ซึ่งประเมินความสามารถในการพาร์สหลายมิติ เช่น ข้อความ สมการ โครงสร้างตาราง และลำดับการอ่าน
    • v1.6 เป็นเวอร์ชันล่าสุดที่เพิ่มภาพทดสอบ 296 ภาพจาก v1.5 ส่วน v1.5 มีผลเทียบกับโมเดลคลาสสิก รวมถึง DeepSeek OCR
    • มีการสร้างชุดทดสอบภายในสำหรับประเมิน OCR ข้อความยาว โดยแบ่งนวนิยาย เอกสาร และงานวิชาการเป็น 2/5/10/20/40+ หน้า (แต่ละหมวดมากกว่า 10 เล่ม)

  • ประสิทธิภาพหลัก

    • ฝึกเพิ่มด้วยข้อมูลเพียง 2M ก็ทำสถิติ end-to-end SOTA ได้ โดยบน v1.5 ระยะห่างการแก้ไขข้อความลดลง 0.035 และ TEDS ของตารางเพิ่มขึ้น 5.96%
    • ค่าชี้วัดรวมบน v1.6 อยู่ที่ 93.92% ทำสถิติ end-to-end SOTA — แสดงให้เห็นว่าการแทนที่ standard attention ทั้งหมดด้วย R-SWA ความกว้าง 128 นั้นมีประสิทธิภาพและไม่สูญเสียคุณภาพ
    • อนุมานได้อย่างมีประสิทธิภาพสูงด้วย MoE active 0.5B พารามิเตอร์ โดยในโหมด "Base" ทำได้ 5580 TPS (เร็วกว่า DeepSeek OCR ที่ 4951 TPS อยู่ 12.7%)

  • การวิเคราะห์หมวดย่อย

    • ดีขึ้นอย่างสม่ำเสมอในทุกตัวชี้วัดเมื่อเทียบกับ DeepSeek OCR จนเรียกได้ว่าเป็นการปรับปรุงระดับ "free lunch"
    • เมื่อเทียบกับ DeepSeek OCR 2 เหนือกว่าใน 7 จาก 9 รายการ ทั้งด้านระยะห่างการแก้ไขข้อความและลำดับการอ่าน
    • ไม่เสียเปรียบแม้ในเลย์เอาต์ซับซ้อน เช่น PPT หนังสือพิมพ์ นิตยสาร และโน้ต

  • การพาร์สข้อความยาว

    • ด้วย R-SWA สามารถ prefill หลายสิบถึงหลายร้อยหน้าได้ในพาสเดียว และพาร์สต่อเนื่องตั้งแต่หน้าแรกถึงหน้าสุดท้ายโดยรักษา KV cache ให้คงที่ ทำให้ latency ของเอาต์พุตสม่ำเสมอ
    • ให้ผลลัพธ์ที่แข็งแกร่งแม้ป้อนพร้อมกัน 20 หน้า และยังคง edit distance ต่ำกว่า 0.11, Distinct-35 ที่ 97% ในกรณี 40+ หน้า
    • ข้อผิดพลาดแบบวนซ้ำมีสาเหตุมาจากความยากในการแยกแยะตัวอักษรขนาดเล็กในโหมดหลายหน้า "Base" (1024×1024) ไม่ใช่เพราะ R-SWA หลงทิศทาง

การวิเคราะห์ประสิทธิภาพ

  • เปรียบเทียบ TPS เอาต์พุตภายใต้เงื่อนไข concurrency เชิงอุดมคติ (ตรึงความยาว prefill ไว้ที่ 10)
    • ที่ 256 โทเค็น ความเร็วอนุมานของทั้งสองโมเดลแทบไม่ต่างกัน
    • เมื่อความยาวเอาต์พุตเพิ่มขึ้น TPS ของ DeepSeek OCR จะลดลงต่อเนื่อง และที่ 6,000 โทเค็น ช้ากว่า Unlimited OCR อยู่ 35%
    • ยืนยันอีกครั้งว่าความเร็วในการสร้างที่สม่ำเสมอคือข้อกำหนดสำคัญของงาน OCR ข้อความยาว

ข้อจำกัดและงานในอนาคต

  • ภายใต้ความยาวคอนเท็กซ์ที่มีขีดจำกัด (เช่น 32K) ยังไม่สามารถพาร์สแบบไร้ขีดจำกัดได้จริง เพราะความยาว prefill มีข้อจำกัด และแม้ DeepEncoder จะบีบอัดได้สูง แต่เมื่อจำนวนหน้าสะสมมากขึ้น prefill ก็จะยาวขึ้น
  • ระยะสั้นมีแผนฝึกโมเดลคอนเท็กซ์ที่ยาวขึ้น เช่น 128K เพื่อรองรับการ prefill ได้มากขึ้น
  • ระยะยาวมีเป้าหมายสร้าง prefill pool และฝึกให้โมเดลดึง chunk ของ prefill KV มา fetch อัตโนมัติ เพื่อเลียนแบบผลของการที่มนุษย์พลิกหน้าเอกสาร และไปสู่ OCR แบบไร้ขีดจำกัดอย่างแท้จริง
  • มีแผนนำ R-SWA ไปใช้กับงานที่อิงข้อมูลอ้างอิง เช่น ASR·การแปล
  • โมเดลมีให้ใช้งานบน Hugging Face และ ModelScope ส่วนงานวิจัยเผยแพร่บน arXiv

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

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

 
GN⁺ 4 시간 전
ความคิดเห็นจาก Hacker News

  • ค่อนข้างน่าสนใจ จากที่เข้าใจ ดูเหมือนนักวิจัยจะพบ การแฮ็กสถาปัตยกรรม ที่ทำให้ AI ไม่ต้องสะสมหน่วยความจำไปเรื่อย ๆ เวลาที่อ่านเอกสารยาว
    ปกติแล้วเวลา AI ถอดข้อความจาก PDF 100 หน้า มันจะพยายามจำทุกคำที่เคยอ่านมา และหน่วยความจำระยะสั้นนี้หรือ KV cache จะเพิ่มขึ้นแบบเชิงเส้น O(N) จน VRAM หมดหรือชนข้อจำกัด ดังนั้นนักพัฒนาจึงต้องเขียนโค้ดแบบเฉพาะหน้าเพื่อแยก PDF เป็นรายหน้าแล้วค่อยเอากลับมารวมกัน
    Unlimited OCR แยกโฟกัสออกเป็นสองเส้นทางด้วย Reference Sliding Window Attention (R-SWA) เส้นทางหนึ่งคือการอ้างอิงแบบโกลบอลที่มองภาพเอกสารต้นฉบับทั้งหมด ส่วนอีกเส้นทางคือการสร้างแบบโลคัลที่จำกัดความจำของข้อความที่โมเดลสร้างเองไว้ในหน้าต่างเลื่อนแคบ ๆ เช่น 128 คำ ฟังดูน่าสนใจมากสำหรับ AI แบบรันในเครื่อง และอยากเห็นว่าคอมมูนิตี้จะเอาไปสร้างและต่อยอดอะไรบ้าง

    • ดูเหมือนว่าจะเหมาะกับบทสนทนาด้วยเหมือนกัน ผมลองทำ การสรุปห่อหุ้มบทสนทนายาว มานานพอสมควร โดยมีทั้งบริบทระดับบนและข้อเท็จจริงที่แทบไม่เปลี่ยน เช่น ชื่อผู้เข้าร่วม หรือข้อมูลพื้นหลัง ซึ่งเข้ากับส่วนนี้
      ในทางกลับกัน ข้อเท็จจริงละเอียดมาก ๆ อย่างเช่นเช้านี้กินอะไร อาจมีประโยชน์ตอนนี้ แต่ในระยะยาวแทบไม่มีความหมาย นอกจากแนวโน้มทั่วไป การสร้างบทสนทนาขึ้นมาใหม่ต้องหาสมดุลที่เหมาะสมโดยไม่ต้องดึงทุกอย่างที่คุยกันมาจนถึงตอนนี้กลับมาใช้ วิธีนี้เลยดูคุ้มค่าที่จะศึกษาเพิ่ม
    • ยังไม่ได้อ่านทั้งเปเปอร์ แต่ หน้าต่างการสร้างแบบโลคัล ดูเล็กไปหน่อย โดยเฉพาะเมื่ออินพุตเป็นภาพที่ใช้โทเคนเยอะ ดังนั้นขึ้นอยู่กับว่าชั้น local attention อยู่ตรงไหน อย่างน้อยก็น่าจะขยายเป็นราว 4096 คำ
    • ตอนทำ OCR จากภาพ ผมทำแบบนี้เป๊ะ ๆ เลย ถ้าตัดภาพใหญ่ภาพเดียวออกเป็นภาพเล็กหลายภาพแล้วส่งให้ LLM ผลออกมาสมบูรณ์ทุกครั้ง แต่พอใส่ทั้งภาพเดียวกลับได้ผลลัพธ์แย่มาก
    • นึกว่าเครื่องมือ LLM หลัก ๆ รองรับ sliding window attention กันอยู่แล้ว
    • นี่แหละว่าทำไม LeetCode ถึงมีประโยชน์ พอทำ LeetCode ต่อเนื่องก็เริ่มเห็นว่าทำไมเทคนิคพวกนี้ถึงมีอยู่ และในโลกจริงเขาเอาไปใช้กันอย่างไร มีอะไรน่าสนใจเยอะมาก

  • ไม่นานมานี้ฉันซื้อแท็บเล็ตสำหรับโน้ตเพลงมา จุดประสงค์หลักคือจะใช้แทนชุดหนังสือแจ๊ส Real Book เวลาไป jam session การสแกนด้วยกล้องมือถือก็พอใช้ได้ แต่ขนาดถูกล็อกตายและมีจุดรบกวนเยอะ
    ถ้าสามารถทรานสโพสทันทีสำหรับเครื่องดนตรีคีย์ Bb หรือ Eb ได้ก็คงดี แต่พอเป็นไฟล์สแกนก็แน่นอนว่าเป็นไปไม่ได้ พอลองไปขุดดูสถานะของ การรู้จำโน้ตเพลงด้วยแสง ก็ได้ข้อสรุปว่าดนตรีแทบจะเป็นพื้นที่ที่ AI ยังไม่ได้บุกเบิกเลยจากมุมมองของ AI การรู้จำโน้ตเพลงด้วยแสงค่อนข้างแย่ และความเข้าใจทฤษฎีดนตรีของ AI ในด้านการอ่านโน้ตจริง ๆ ก็แย่มาก LLM พอทำได้โอเคกับคำอธิบายเชิงข้อความของแนวคิดทางทฤษฎีที่น่าจะมีอยู่ในข้อความออนไลน์ซึ่งถูกใช้ฝึกโมเดล
    ปัญหาดูเหมือนจะอยู่ที่เรายังขาดรูปแบบดิจิทัลที่เข้ารหัสจุดบนกระดาษที่นักดนตรีอ่านกันได้อย่างเหมาะสม ระบบโน้ตเพลงมีรายละเอียดค่อนข้างมาก MIDI ถูกสร้างมาเพื่อเก็บแง่มุมที่จำเป็นต่อการเล่นกลับหรือการบรรเลงเป็นหลัก จึงเก็บทุกอย่างที่จำเป็นต่อความเข้าใจเชิงสัญลักษณ์ไม่ได้ MusicXML ดูจะเป็นรูปแบบดิจิทัลที่ใกล้เคียงที่สุดกับข้อมูลที่นักดนตรีต้องการ แต่ยังขาดคอร์ปัสการฝึกที่ดีซึ่งเชื่อมโยงการแทนค่าแบบ MusicXML เข้ากับภาพโน้ตหรือเสียง น่าจะเป็นเพราะ MusicXML เพียงอย่างเดียวให้ข้อมูลไม่พอสำหรับการจัดวางโน้ตเพลง
    เครื่องมืออย่าง MuseScore ต้องติดตามข้อมูลเลย์เอาต์จำนวนมากที่ MusicXML แทนค่าไม่ได้ ฟอร์แมต LilyPond เขียนย่อได้มากกว่า MusicXML และเก็บข้อมูลที่มีประโยชน์กับผู้ทำโน้ตเพลงได้มากกว่าเล็กน้อย แต่คนส่วนใหญ่ก็ไม่ได้ทำโน้ตเพลงด้วย LilyPond อีกอย่างคือสภาพฟอนต์แจ๊สของ LilyPond ยังน่าผิดหวัง ในบริบทแจ๊ส ฉันไม่ชอบดูโน้ตแบบ “คลาสสิก” ทุกครั้งที่เห็น OCR ดีขึ้นแบบ incremental ก็นึกถึง ความย่ำแย่ของ OMR ขึ้นมา

    • ฟอร์แมตที่นักดนตรีวิทยาและนักวิจัยดนตรีใช้คือ MEI: https://music-encoding.org/ และเอนจินจัดพิมพ์มาตรฐานคือ verovio: https://www.verovio.org/index.xhtml
      verovio สามารถจัดพิมพ์เป็น SVG โดยคงข้อมูลจากโน้ต MEI ต้นฉบับไว้ได้มากที่สุด ทำให้ดึงเมตาดาต้าออกมาสร้างชุดข้อมูลตรวจจับจริงสำหรับโมเดลดีปเลิร์นนิงได้ ถึงขั้นมีสคริปต์แฮ็ก ๆ สำหรับสร้างชุดข้อมูล COCO จากชุดโน้ตที่จัดพิมพ์ด้วย verovio: https://github.com/kwon-young/music/blob/main/svg2pl.py
      ยังมีการเปิดเผยชุดข้อมูลโน้ตสังเคราะห์ที่ทำขึ้นที่นี่ด้วย: https://www.kaggle.com/datasets/kwonyoungchoi/trompa-coco/da... ใครอยากลองฝึกตัวตรวจจับบนข้อมูลนี้ก็ยินดีเลย ที่ OMR ถูกปล่อยทิ้งไว้แบบนี้ ส่วนใหญ่เป็นเพราะคนมักประเมินความยากของงานนี้ต่ำเกินไปมาก มันเป็นงานเฉพาะทางที่มีรูปแบบหลากหลายสุดขั้วและไวยากรณ์เชิงกราฟิกที่ซับซ้อนมากปะปนกันอยู่
    • คำว่า “ดนตรีแทบจะเป็นพื้นที่ที่ AI ยังไม่ได้บุกเบิกเลย” นั้นจริงมาก แฟนฉันเรียนดนตรีวิทยา และเพราะมีความพิการทางร่างกายเลยบางครั้งจดโน้ตได้ยาก ฉันจึงค่อย ๆ ทำแอปอย่าง TTS/OCR ที่ใช้ AI เพื่อช่วยเธอ
      พอทำไปเรื่อย ๆ จะเห็นชัดอย่างเจ็บปวดว่าดนตรีไม่เคยถูกมองเป็นส่วนสำคัญในชุดข้อมูลฝึก AI ไหนเลย ทุกวันนี้ Opus 4.8 มีความสามารถในการเข้าใจและอธิบายทฤษฎีดนตรีที่น่าทึ่งพอสมควร แต่พอให้ถอดโน้ตหรือทำ OCR/OMR จากแผ่นโน้ต มันกลับมั่นใจแล้วส่งผลลัพธ์แบบ MusicXML/LilyPond เวอร์ชันของ “2 + 2 = ม้า” ออกมา ฉันหวังว่าพื้นที่ที่ถูกมองข้ามนี้จะโดนคลื่น AI ที่กำลังเติบโตพัดผ่านบ้าง แต่ตอนนี้มันยังถูกประเมินค่าต่ำเกินไปอย่างไม่ยุติธรรม
    • ถ้าต้องการแค่วิเคราะห์คอร์ด ก็มี สัญกรณ์ Harte สำหรับแทนเสียงให้ไม่กำกวม: https://ismir2005.ismir.net/proceedings/1080.pdf
      แน่นอนว่ามันไม่ได้ให้ข้อมูลเพิ่มเติมทั้งหมดที่จำเป็นต่อการจัดพิมพ์หรือการแทนค่าดนตรีทั้งชิ้น แต่ก็มีชุดข้อมูลวิจัยอย่าง https://github.com/smashub/choco สำหรับงานวิเคราะห์ ฉันก็เคยใช้ชุดข้อมูล https://github.com/MarkGotham/When-in-Rome ด้วย แต่ก็ยังไม่ตรงกับสิ่งที่ตามหา 100% ถ้าจุดประสงค์คือใช้บนแท็บเล็ตแทนแจ๊สมาตรฐานและทรานสโพส แอป “iReal Pro” อาจจะถูกใจคุณ มันเหมาะกับ use case นั้นมากกว่าการสแกนด้วยกล้องพอสมควร
    • แล้ว ฟอร์แมตจัดพิมพ์โน้ตเพลง อย่าง https://abcnotation.com/ ล่ะ?
    • ถ้าตามดูวงการ music OCR มา จนถึงตอนนี้เหมือนว่าทางออกที่ดีจริง ๆ มีแค่ soundslice สแกนแล้วค่อยตรวจแค่ edge case บางส่วนก็ได้ผลลัพธ์ที่ดีมาก เป็นบริการเสียเงินของบริษัทเล็ก ๆ ที่คุ้มค่าแก่การสนับสนุนมาก

  • ข้อความที่ว่า “ขอขอบคุณโมเดลและไอเดียที่มีคุณค่าจาก Deepseek-OCR, Deepseek-OCR-2 และ PaddleOCR” เป็น ท่าทีที่มีระดับ

    • ไม่เข้าใจว่าทำไมถึงประชดกัน

  • อนึ่ง “Unlimited OCR Works” เป็นการล้อ Unlimited Blade Works จาก Fate/stay night โดยต้นฉบับ Unlimited Blade Works มีคอนเซปต์ว่าเป็นเวทมนตร์ที่คัดลอกอาวุธที่คนอื่นสร้างขึ้น

  • ตัวบทความอยู่ที่ https://arxiv.org/abs/2606.23050
    เผื่อบอกไว้ ฉันกำลังทำ OCR แบบรันในเครื่องสำหรับ use case RAG เล็ก ๆ เพื่อเก็บคำคมที่อ่านจากหนังสือ และฉันเองก็แบ่งอินพุตเป็นชังก์เพื่อประหยัด RAM ด้วย เลยรู้สึกน่าสนใจที่แนวทางธรรมชาติแบบนี้ใช้ได้กับโมเดลสตรีมมิงเช่นกัน

  • ดูมีอนาคตกว่าสิ่งที่ Mistral เพิ่งปล่อยออกมาเสียอีก บังเอิญเหรอ? ฉันว่าไม่
    แนวทางนี้น่าจะเอาไปใช้ผสมกับการสร้างภาพได้ด้วยบางแบบ เช่น หลังจากอ่านหรือดูภาพแล้วก็เริ่มวาดด้วยเครื่องมืออย่าง Illustrator/Inkscape หรือเป็น SVG ไปก่อน แล้วค่อยเติมส่วนที่ขาดทีหลัง ก็ดูเป็นไปได้

  • สงสัยว่ามันเทียบกับ infinty parser 2 ที่ดูเหมือนจะชนะเครื่องมือ OCR อื่น ๆ ได้ขาดลอยได้อย่างไร: https://huggingface.co/datasets/allenai/olmOCR-bench
    พูดอย่างเป็นธรรมคือยังไม่มี benchmark OCR แบบผู้ชนะหนึ่งเดียว และเครื่องมือนี้ก็ยังไม่ได้ถูกนำไปใส่ไว้ที่ไหนเลย

  • ฉันอาจจะฟังดูเหมือนคนไม่รู้เรื่องโลกนัก แต่เหตุผลจริง ๆ ที่บริษัทต่าง ๆ ปล่อยซอฟต์แวร์ที่ดีมาก ๆ ออกมาเป็น โอเพนซอร์ส คืออะไร?
    ถ้าเป็น Baidu หรือ Google ไม่ควรเก็บไว้ใช้เองเพื่อรีดมูลค่า โดยไม่ให้คู่แข่งตามทันไม่ใช่หรือ?

    • แม้แต่ในบริษัทใหญ่ก็มีคนที่เชื่อใน อุดมคติของโอเพนซอร์ส และโน้มน้าวนายจ้างให้ยอมเปิดโปรเจกต์ออกมาได้
      บริษัทก็ได้ชื่อเสียงกลับมา ซึ่งช่วยเรื่องการสรรหาคนได้ด้วย บางครั้งก็อาจใช้เป็นกลยุทธ์เพื่อปั่นป่วนคู่แข่งได้ อย่างที่ Meta ปล่อย Ollama ออกมา
    • การปล่อยโมเดลโอเพนซอร์สอาจแย่งรายได้จากสถาบันวิจัย AI ของสหรัฐฯ ได้ ถ้าทำให้สถาบันเหล่านั้นมีเงินสำหรับนำกลับไปลงทุนเพื่อต่อสู้ระยะยาวน้อยลง ก็อาจเป็นประโยชน์ต่อจีน

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

    • พอเป็นการเรียนรู้ของเครื่องในระดับที่ใหญ่กว่าคำเดี่ยว ๆ มาก ๆ ก็เริ่มไม่เป็นที่ต้องการ เช่น ระดับคู่คำ วลี ประโยค เอกสาร หรือคอร์ปัส
      ในงานถอดความ เราต้องการผลลัพธ์ที่เกือบจะแน่นอน หรือไม่ก็ต้องการให้ระบุชัดว่าอ่านไม่ออก แม้จะเดาจากบริบทได้ แต่ก็ต้องรู้ว่ามันเดาโดยอาศัยหลักฐานเกินกว่าการที่ตัวอักษรเรียงกันเป็นคำนั้นหรือไม่
      ตัวอย่างเช่น ในเอกสารสำมะโนประชากรของ familysearch.com ผู้ถอดความคนหนึ่ง “แก้” ชื่อเป็น Joseph ทั้งที่ตัวอักษรจริงในเอกสารลายมือคือ Josepth ซึ่งเป็นการสะกดแบบท้องถิ่นจริง ๆ ในเอกสารอีกฉบับ ผู้เขียนใช้ “Joh” เป็นตัวย่อ และผู้ถอดความที่เป็นมนุษย์ก็น่าจะถอดเป็น John ซึ่งแม้จะดูสมเหตุสมผลที่สุด แต่ก็ผิดจากต้นฉบับจริง บางครั้งการรู้ว่านั่นเป็นแค่การคาดเดาสำคัญมาก และบางครั้งก็แค่ต้องการการเดาที่ดีที่สุด
    • ถ้าต้องการผลการรู้จำ 100% ฉันจะจับวิธีนี้คู่กับ โมเดลภาพสำหรับสร้างเอกสารต้นฉบับขึ้นใหม่ โดยให้มันสร้างเอกสารเดิมกลับมาจากข้อความถอดและเลย์เอาต์
      ถ้าใช้ทั้งเอกสารยกเว้นหน้าหรือย่อหน้าที่ต้องการทดสอบ ก็จะเลี่ยงไม่ให้ระบบสร้างวลีที่กำลังทดสอบซ้ำตรง ๆ จากอาร์ติแฟกต์ในภาพได้ หลังการสร้างกลับมาแล้ว ก็ทำการเปรียบเทียบเชิงแสงเพื่อตรวจหาตัวอักษรที่ไม่ตรงกันแล้ววนแก้ต่อไป วิธีนี้แพง แต่สามารถรับประกันการรู้จำได้ 100%
    • ฉันกำลังลองใช้โมเดลนี้ถอด PDF ไวยากรณ์ภาษาญี่ปุ่นบน 4090 เป็นเอกสารที่เขียนเป็นอังกฤษและมีตัวอย่างภาษาญี่ปุ่นจำนวนมาก และเท่าที่ฉันตรวจเทียบด้วยตัวเองบางส่วน มันทำงานได้ค่อนข้างดี
      เอาต์พุตคงคันจิ/ฮิรางานะและภาษาอังกฤษไว้ได้อย่างเหมาะสมในจุดที่ควรคงไว้ และไม่ได้พยายามแปลมัน แปลงได้ประมาณ 200 หน้าต่อชั่วโมง
    • อยากรู้ว่าเคยใช้โมเดลหรือเครื่องมือตัวไหนมาบ้าง

  • ไม่รู้ว่า Reducto ไปถึงไหนแล้ว เมื่อ 12~15 เดือนก่อนมันดูมีอนาคตทีเดียว