เทคโนโลยีแปลง PDF เป็น Markdown ได้รวดเร็วและแม่นยำสูง

 (github.com/VikParuchuri)
2 คะแนน โดย GN⁺ 2023-12-02 | 1 ความคิดเห็น | แชร์ทาง WhatsApp
  • Marker เป็นเครื่องมือ document intelligence ที่แปลงเอกสาร PDF รวมถึงรูปภาพ, PPTX, DOCX, XLSX, HTML, EPUB เป็น Markdown, JSON, chunks และ HTML ได้อย่างรวดเร็วและแม่นยำ
  • รองรับการจัดรูปแบบตาราง, แบบฟอร์ม, สูตร, คณิตศาสตร์แบบ inline, ลิงก์, การอ้างอิง, code block รวมถึงการดึงและบันทึกรูปภาพ และการ ลบ artifact เช่น header/footer
  • หากต้องการเพิ่มความแม่นยำ สามารถใช้ LLM ร่วมด้วยผ่าน --use_llm โดยค่าเริ่มต้นคือ gemini-2.0-flash และเลือกใช้ Gemini, Ollama, Claude, OpenAI, Azure OpenAI เป็นต้นได้
  • ใน benchmark Marker ทำเวลาเฉลี่ย 2.83837 วินาทีต่อ PDF หน้าเดียว ได้คะแนน heuristic 95.6709 และคะแนน LLM 4.23916 ส่วนในโหมด batch บน H100 คาดว่าจะได้ throughput 25 pages/second
  • ต้องใช้ Python 3.10+ และ PyTorch โดยโค้ดใช้ไลเซนส์ GPL ส่วน model weights ใช้ไลเซนส์ AI Pubs OpenRAIL-M แบบแก้ไข ซึ่งให้ใช้งานฟรีสำหรับงานวิจัย, การใช้ส่วนบุคคล และสตาร์ทอัพที่มี funding/revenue ต่ำกว่า $2M

เอกสารที่ Marker แปลงได้และรูปแบบผลลัพธ์

  • Marker แปลงเอกสารเป็น Markdown, JSON, chunks และ HTML
  • รูปแบบอินพุตรวมถึง PDF, รูปภาพ, PPTX, DOCX, XLSX, HTML, EPUB และประมวลผลเอกสารได้ทุกภาษา
  • ขอบเขตการประมวลผลองค์ประกอบของเอกสาร:
    • ตาราง, แบบฟอร์ม, สูตร, คณิตศาสตร์แบบ inline
    • ลิงก์, การอ้างอิง, code block
    • การดึงและบันทึกรูปภาพ
    • การลบ header, footer และ artifact อื่นๆ
  • สามารถขยายได้ด้วย formatting และ logic ของตัวเอง
  • หากให้ JSON schema จะสามารถทำ structured extraction ได้ โดยฟีเจอร์นี้อยู่ในสถานะ beta
  • ทำงานได้บน GPU, CPU และ MPS

แพลตฟอร์ม managed ของ Datalab

  • แพลตฟอร์ม managed ของ Datalab รันโมเดลโอเพนซอร์สล่าสุด Chandra
  • Chandra ถูกแนะนำว่าให้ความแม่นยำสูงกว่า Marker โดยค่าเริ่มต้นไม่มีการเก็บรักษาข้อมูล และมี SOC 2 Type 2 กับ custom BAA ให้บริการ
  • บริการ batch processing สำหรับ workload ปริมาณสูงเคยประมวลผลมากกว่า 200M+ หน้าต่อสัปดาห์
  • เมื่อสมัครจะได้รับ เครดิตฟรี $5 และมี playground สาธารณะ ให้ใช้งานด้วย
  • การ self-hosting เชิงพาณิชย์ต้องมีไลเซนส์ และไลเซนส์แบบ on-premises ต้องติดต่อสอบถามแยกต่างหาก

ประสิทธิภาพและโหมด hybrid LLM

  • Marker นำเสนอผล benchmark ที่ดีกว่าเมื่อเทียบกับบริการคลาวด์อย่าง Llamaparse, Mathpix และเครื่องมือโอเพนซอร์สอื่นๆ
  • ผลประสิทธิภาพทั้งหมดใน README วัดจากการรันแบบ serial บน PDF หน้าเดียว
  • ในโหมด batch จะเร็วกว่า และบน H100 คาดว่าจะได้ throughput 25 pages/second
  • เพื่อความแม่นยำสูงสุด สามารถใช้ LLM ร่วมด้วยผ่าน flag --use_llm
    • รวมตารางที่ข้ามหลายหน้า
    • ประมวลผลคณิตศาสตร์แบบ inline
    • ปรับปรุงการจัดรูปแบบตาราง
    • ดึงค่าออกจากแบบฟอร์ม
  • โหมด hybrid LLM มีความแม่นยำใน benchmark ตารางสูงกว่า Marker แบบล้วนหรือ Gemini Flash แบบล้วน

การติดตั้งและการใช้งานพื้นฐาน

  • ต้องใช้ Python 3.10+ และ PyTorch
  • การติดตั้งสำหรับ PDF เป็นหลัก: 
    pip install marker-pdf
  • หากต้องการประมวลผลรูปแบบเอกสารอื่นนอกจาก PDF ให้ติดตั้ง dependency เพิ่มเติม 
    pip install marker-pdf[full]
  • แปลงไฟล์เดียว: 
    marker_single /path/to/file.pdf
  • แปลงหลายไฟล์เป็นรายโฟลเดอร์: 
    marker /path/to/input/folder
  • แปลงด้วย GPU หลายตัว: 
    NUM_DEVICES=4 NUM_WORKERS=15 marker_chunk_convert ../pdf_in ../md_out
    • NUM_DEVICES คือจำนวน GPU ที่จะใช้ และต้องเป็น 2 ขึ้นไป
    • NUM_WORKERS คือจำนวน process แบบ parallel ต่อ GPU

ตัวเลือก CLI สำคัญ

  • --page_range TEXT: ระบุหมายเลขหน้าและช่วงหน้าที่จะประมวลผล
  • --output_format [markdown|json|html|chunks]: ระบุรูปแบบผลลัพธ์
  • --output_dir PATH: ระบุไดเรกทอรีสำหรับบันทึกไฟล์ผลลัพธ์
  • --paginate_output: ใส่หมายเลขหน้าและเส้นคั่นในผลลัพธ์
  • --use_llm: เพิ่มความแม่นยำด้วย LLM
  • --force_ocr: บังคับใช้ OCR กับทั้งเอกสาร และจัดรูปแบบคณิตศาสตร์แบบ inline อย่างเหมาะสมด้วย
  • --block_correction_prompt: ระบุ prompt สำหรับแก้ไขผลลัพธ์ของ Marker ในโหมด LLM
  • --strip_existing_ocr: ลบข้อความ OCR เดิมและทำ OCR ใหม่ด้วย surya
  • --redo_inline_math: เพิ่มคุณภาพการแปลงคณิตศาสตร์แบบ inline เมื่อใช้ร่วมกับ --use_llm
  • --disable_image_extraction: ไม่ดึงรูปภาพจาก PDF
  • --converter_cls: เลือก marker.converters.pdf.PdfConverter ซึ่งเป็นค่าเริ่มต้น หรือ marker.converters.table.TableConverter สำหรับตารางโดยเฉพาะ
  • --llm_service: ระบุบริการ LLM เมื่อใช้ --use_llm โดยค่าเริ่มต้นคือ marker.services.gemini.GoogleGeminiService
  • --workers: ระบุจำนวน worker สำหรับการแปลงพร้อมกัน
    • ใช้ VRAM สูงสุด 5GB ต่อ worker และเฉลี่ย 3.5GB VRAM

Python API และการจัดการ block ภายใน

  • สามารถแปลงโดยตรงจาก Python ด้วย PdfConverter 
    from marker.converters.pdf import PdfConverter
from marker.models import create_model_dict
from marker.output import text_from_rendered

converter = PdfConverter(
    artifact_dict=create_model_dict(),
)
rendered = converter("FILEPATH")
text, _, images = text_from_rendered(rendered)
  • rendered ของผลลัพธ์ Markdown มี property markdown, metadata, images
  • rendered ของผลลัพธ์ JSON มี children, block_type, metadata
  • สามารถใช้ ConfigParser เพื่อกำหนดรูปแบบผลลัพธ์, processor, renderer, บริการ LLM ฯลฯ
  • เอกสารถูกประกอบเป็น tree ของหน้าและ block และหน้าสามารถมี block ซ้อนอยู่ได้อีก
  • สามารถใช้ contained_blocks เพื่อดึงเฉพาะ block บางประเภท เช่น แบบฟอร์ม ออกมาแบบ programmatic ได้

ประเภท converter

  • PdfConverter: converter ค่าเริ่มต้นสำหรับแปลง PDF ทั้งหมด
  • TableConverter: ดึงและแปลงเฉพาะตาราง
    • หากระบุ force_layout_block=Table จะหลีกเลี่ยง layout detection และถือว่าทุกหน้าเป็นตาราง
    • หากใช้ output_format=json จะได้ bounding box ของ cell ด้วย
  • OCRConverter: รันเฉพาะ OCR
    • หากตั้งค่า --keep_chars จะเก็บตัวอักษรแต่ละตัวและ bounding box ไว้
  • ExtractionConverter: converter สำหรับ structured extraction ซึ่งอยู่ในสถานะ beta
    • ต้องตั้งค่าบริการ LLM ก่อน
    • คืนค่าที่ดึงออกมาเป็น JSON output
    • หากส่ง original_markdown จากการรันครั้งก่อนเป็น existing_markdown จะข้ามการ parse เอกสารใหม่ได้

รูปแบบผลลัพธ์

  • ผลลัพธ์ Markdown:
    • ลิงก์รูปภาพ
    • ตารางที่จัดรูปแบบแล้ว
    • สูตร LaTeX ที่ครอบด้วย $$
    • code block แบบ triple backticks
    • superscript สำหรับ footnote
  • ผลลัพธ์ HTML:
    • รูปภาพด้วยแท็ก img
    • สูตรด้วยแท็ก <math>
    • โค้ดด้วยแท็ก pre
  • ผลลัพธ์ JSON:
    • แสดงหน้าเป็น list และแต่ละหน้าเป็น block ตาม schema ภายในของ Marker
    • มี key id, block_type, html, polygon, children
    • block ลูกมี section_hierarchy, images เพิ่มเติม
    • โครงสร้าง block เป็นรูปแบบ tree
  • ผลลัพธ์ Chunks:
    • คล้าย JSON แต่ flatten ทุกอย่างเป็น list เดียว
    • มี HTML ทั้งหมดของแต่ละ block จึงใช้ทำ chunking สำหรับ RAG ได้อย่างยืดหยุ่น
  • ผลลัพธ์ทุกรูปแบบคืนค่า metadata
    • table_of_contents ซึ่งเป็นสารบัญ PDF ที่คำนวณได้
    • page_stats ที่มีวิธีดึงข้อความและจำนวน block รายหน้า

บริการ LLM ที่รองรับ

  • บริการที่เลือกได้เมื่อใช้ --use_llm:
    • Gemini: ใช้ Gemini developer API เป็นค่าเริ่มต้น และต้องมี --gemini_api_key
    • Google Vertex: ต้องมี --vertex_project_id และระบุ marker.services.vertex.GoogleVertexService
    • Ollama: ใช้โมเดล local และตั้งค่า --ollama_base_url, --ollama_model
    • Claude: ตั้งค่า --claude_api_key, --claude_model_name
    • OpenAI: รองรับ endpoint ที่เข้ากันได้กับ OpenAI และตั้งค่า --openai_api_key, --openai_model, --openai_base_url
    • Azure OpenAI: ตั้งค่า --azure_endpoint, --azure_api_key, --deployment_name

โครงสร้างภายในและจุดสำหรับขยาย

  • Marker ทำงานเป็น deep learning model pipeline
    • ดึงข้อความ และทำ OCR เมื่อจำเป็น
    • ตรวจจับ layout ของหน้าและลำดับการอ่าน
    • จัดระเบียบและจัดรูปแบบแต่ละ block
    • ปรับปรุงคุณภาพด้วย LLM เมื่อจำเป็น
    • รวม block และ post-process ข้อความทั้งหมด
  • ขั้นตอนที่เกี่ยวกับ OCR และ layout ใช้ surya
  • การจัดรูปแบบที่เกี่ยวกับสูตรใช้ texify
  • องค์ประกอบหลัก:
    • Providers: ให้ข้อมูลจากไฟล์ต้นทาง เช่น PDF
    • Builders: สร้าง block เริ่มต้นของเอกสารและเติมข้อความ
    • Processors: ประมวลผล block เฉพาะ เช่น table formatter
    • Renderers: render block เป็นรูปแบบผลลัพธ์
    • Schema: class ของ block ทุกประเภท
    • Converters: รัน pipeline แบบ end-to-end ทั้งหมด
  • หากต้องการเปลี่ยนพฤติกรรมการประมวลผล ให้ override processors
  • เพิ่มรูปแบบผลลัพธ์ใหม่ได้ด้วยการเขียน renderer ใหม่
  • เพิ่มรูปแบบอินพุตใหม่ได้ด้วยการเขียน provider ใหม่

API server และการ deploy

  • สามารถรัน FastAPI server แบบง่ายได้ 
    pip install -U uvicorn fastapi python-multipart
marker_server --port 8001
  • server เข้าถึงได้ที่ localhost:8001 และดูตัวเลือก endpoint ได้ที่ localhost:8001/docs
  • API server นี้ไม่ใช่ API ที่ robust และตั้งใจให้ใช้สำหรับ การใช้งานขนาดเล็ก เท่านั้น
  • หากต้องการตัวเลือกการแปลงที่ robust กว่า สามารถใช้ Datalab API ที่โฮสต์ไว้ได้
  • ตัวอย่างการ deploy รวมถึงการ deploy web endpoint ผ่าน Modal

การแก้ปัญหา

  • หากมีปัญหาด้านความแม่นยำ ให้ใช้ LLM ด้วย --use_llm
    • ในกรณีนี้ต้องตั้งค่า Gemini API key เป็น GOOGLE_API_KEY
  • หากเห็นข้อความเพี้ยน ให้ทำ OCR เอกสารใหม่ด้วย force_ocr
  • สามารถบังคับระบุ torch device ที่จะใช้ด้วย TORCH_DEVICE
  • หากเกิดข้อผิดพลาดหน่วยความจำไม่พอ ให้ลดจำนวน worker หรือแบ่ง PDF ยาวๆ เป็นหลายไฟล์
  • ตัวเลือก debug จะบันทึกรูปภาพหน้าที่มี layout และข้อความที่ตรวจพบ รวมถึงไฟล์ JSON ที่มีข้อมูล bounding box

ผล benchmark

  • benchmark การแปลง PDF ทั้งหมดใช้ benchmark set ที่สร้างจากการดึงหน้า PDF เดี่ยวจาก common crawl
  • คะแนนคำนวณด้วย heuristic ที่ align กับ ground truth text segment และวิธี LLM-as-judge
  • ผลการแปลง PDF ทั้งหมด:
    • marker: เวลาเฉลี่ย 2.83837, heuristic 95.6709, LLM 4.23916
    • llamaparse: เวลาเฉลี่ย 23.348, heuristic 84.2442, LLM 3.97619
    • mathpix: เวลาเฉลี่ย 6.36223, heuristic 86.4281, LLM 4.15626
    • docling: เวลาเฉลี่ย 3.69949, heuristic 86.7073, LLM 3.70429
  • marker และ docling รันบน H100 ส่วน llamaparse และ mathpix ใช้บริการคลาวด์
  • benchmark throughput สำหรับ PDF ยาวใช้ Think Python
    • marker: 0.18 วินาทีต่อหน้า
    • 43.42 วินาทีต่อเอกสาร
    • VRAM 3.17GB
    • บน H100 สามารถรัน process แยกได้ 22 process จึงคาดว่าจะได้ throughput 122 pages/second
  • benchmark การแปลงตารางเปรียบเทียบกับ HTML representation ของ test split จาก FinTabNet
    • marker: คะแนนเฉลี่ย 0.816, รวม 99 tables
    • marker w/use_llm: คะแนนเฉลี่ย 0.907, รวม 99 tables
    • gemini: คะแนนเฉลี่ย 0.829, รวม 99 tables
  • ตารางที่ไม่สามารถ align กับ ground truth ได้เนื่องจากความแตกต่างของวิธีตรวจจับระหว่าง FinTabNet และ layout model จะถูกกรองออก

ข้อจำกัดและไลเซนส์

  • PDF เป็นรูปแบบที่จัดการได้ยาก Marker จึงอาจไม่ได้ทำงานสมบูรณ์แบบเสมอไป
  • ข้อจำกัดที่ทราบ:
    • layout ที่ซับซ้อนมากซึ่งมีตารางซ้อนและแบบฟอร์มอาจไม่ทำงาน
    • การ render แบบฟอร์มอาจทำได้ไม่ดี
  • การส่ง flag --use_llm และ --force_ocr สามารถแก้ปัญหาเหล่านี้ส่วนใหญ่ได้
  • model weights ใช้ไลเซนส์ AI Pubs OpenRAIL-M แบบแก้ไข
    • ฟรีสำหรับงานวิจัย, การใช้ส่วนบุคคล และสตาร์ทอัพที่มี funding/revenue ต่ำกว่า $2M
  • โค้ดใช้ไลเซนส์ GPL
  • ไลเซนส์เชิงพาณิชย์ที่ครอบคลุมกว่า หรือการนำข้อกำหนด GPL ออก อยู่ใน pricing page

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

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

 
GN⁺ 2023-12-02
ความคิดเห็นจาก Hacker News

  • วิธีที่ repo โดยรวม เปรียบเทียบกับ Nougat นั้นชวนสับสนนิดหน่อย
    Nougat เป็นโมเดลที่ฝึกมาเฉพาะสำหรับเอกสารวิชาการ และผมไม่คิดว่าเคยมีการอ้างว่า Nougat เป็นโมเดล OCR ที่ดีที่สุด ใน benchmark ก็ระบุว่าในเอกสาร arXiv ความแม่นยำของ Nougat สูงกว่า อีกอย่าง การที่บอกว่า marker แปลงสมการน้อยกว่า Nougat แต่กลับเทียบความเร็วกับ Nougat ก็รู้สึกน่าเสียดาย เพราะ Nougat เป็นโมเดลสำหรับเอกสารวิชาการ
    ถ้าจะทำ OCR กับ PDF ที่มีคณิตศาสตร์ Nougat เป็นสิ่งที่ควรลองแน่นอน ติดตั้งเป็นแพ็กเกจ Python ได้ง่าย และสั่งคำสั่งเดียวก็แยกสมการ ข้อความ ตาราง ฯลฯ ออกมาเป็นไฟล์ .mmd ได้ สำหรับการใช้งานส่วนตัว ความเร็วก็ใช้ได้ โดยบนแล็ปท็อป i5 อายุ 4 ปี ใช้แค่ CPU แปลงเอกสาร 6 หน้าใช้เวลาประมาณ 30 วินาที

    • การเปรียบเทียบสองสิ่งไม่ได้หมายความว่าสิ่งเดิมถูกโปรโมตว่าเป็นตัวที่ดีที่สุด
      เป็นเพียงวิธีวางเครื่องมือใหม่ไว้เคียงข้างสิ่งที่คุ้นเคยเพื่อให้เห็นภาพเท่านั้น อย่างที่บอก Nougat ติดตั้งและรันได้ง่าย จึงเป็นเรื่องธรรมชาติที่จะใช้เป็นตัวเทียบ ถ้ามีไลบรารีเข้ามาในการเปรียบเทียบมากขึ้น แน่นอนว่าจะยิ่งดีและมีประโยชน์มากขึ้น
    • อยากรู้ว่า Nougat จะจัดการ PDF หนังสือกฎ RPG ได้ดีแค่ไหน
      กำลังมองหาโมเดล OCR ที่ช่วยย้ายบางส่วนของหนังสือ RPG ไปเป็น Markdown อยู่ ถ้าเป็นไปได้ก็อยากให้คงการเน้นอย่างตัวหนาหรือตัวเอียงไว้ด้วย
      การผสมกันของข้อความ ตัวเลข และสัญลักษณ์คณิตศาสตร์ดูคล้ายเอกสารเทคนิค/วิชาการ แต่ก็มักมีรูปแบบแปลก ๆ กล่องข้อความตรงขอบหน้า และแผนภูมิจำนวนมากปะปนอยู่
    • ผมเป็นผู้เขียน กรณีใช้งานของผมคือ การแปลง PDF วิทยาศาสตร์จำนวนมาก ดังนั้น Nougat จึงเป็นทางออกที่ดีที่สุด และผมจึงใช้เป็นตัวเทียบหลัก
      ด้านล่างยังมีการเปรียบเทียบกับการดึงข้อความแบบธรรมดาไว้ด้วย Nougat เป็นโมเดลที่ยอดเยี่ยมและแปลง PDF ได้ดีจำนวนมาก แต่ผมต้องการสิ่งที่เร็วกว่าและ generalize ได้มากกว่า
    • อยากทำ การดึงงบการเงิน ที่อยู่ในรูปตารางภายใน PDF; Nougat เหมาะกับงานแบบนั้นด้วยไหม?

  • ไม่ควรประเมินผลกระทบของเครื่องมือแบบนี้ต่ำไป เพราะนี่คือการปลดล็อกความรู้อันมหาศาลที่ถูกขังอยู่ในฟอร์แมตที่ “อ่านดี แต่ไม่ดีต่อการเผยแพร่ต่อ”
    น่าตื่นเต้นมาก อยากให้มี pipeline แบบนี้: PDF ทั้งหมด → แปลงทั้งหมดเป็น Markdown → เก็บทั้งหมดไว้ใน archive.org

    • ถ้าเพื่อการเก็บถาวร pipeline นั้นดูไม่เหมาะนัก ลำดับที่ดีกว่าคือ PDF ทั้งหมด → เก็บต้นฉบับ → แปลงเป็น Markdown
      แบบนี้เมื่อมีการแก้บั๊กและปรับปรุง ก็สามารถรันการแปลงใหม่ได้ โดยทั่วไปในการอนุรักษ์บันทึก จะนิยมเก็บในรูปแบบที่ใกล้เคียงกับวัสดุต้นฉบับที่สุด เพราะการแปลงทั้งหมดหลังจากนั้นมีแต่จะทำให้ข้อมูลสูญหาย
    • จริง ๆ แล้ว PDF เป็น ฟอร์แมตสำหรับการเผยแพร่ ที่ยอดเยี่ยม
      สามารถฝังข้อมูลดิบที่ใช้สร้างเอกสารที่ผู้ใช้ปลายทางเห็นไว้แบบไม่แสดงผล ในรูปแบบใดก็ได้ ตัวอย่างเช่น ถ้าใช้ PrinceXML เรนเดอร์ HTML เพื่อสร้าง PDF ก็สามารถใส่ JSON ต้นฉบับที่ใช้สร้างข้อความ กราฟ แผนภูมิ ฯลฯ ทั้งหมดไว้ใน PDF ได้ แน่นอนว่าส่วนใหญ่ไม่ได้ทำแบบนั้นจริง ๆ แต่นั่นไม่ใช่ความผิดของสเปก
    • ผมเป็นผู้เขียน นี่เป็นหนึ่งในเหตุผลที่ผมสร้างเครื่องมือนี้
      https://github.com/VikParuchuri/libgen_to_txt ก็น่าดูเช่นกัน ยังไม่ได้ผสานกับ marker และตอนนี้ใช้การดึงข้อความแบบธรรมดาอยู่
    • เครื่องมือประเภทนี้มีความต้องการสูงมาก โดยเฉพาะใน องค์กรขนาดใหญ่ ที่มีเอกสาร PDF หลากหลายรูปแบบจำนวนมาก ย่อมต้องสนใจมากเป็นพิเศษ
      ต่อให้ครอบคลุมความต้องการหรือ use case ได้แค่บางส่วน หากทำงานได้ดี ก็จะมีประโยชน์มาก
    • ในแง่ accessibility ก็มีประโยชน์มาก
      การทำให้ PDF มี accessibility อย่างถูกต้องเป็นงานมหาศาล และต่อให้ทำได้ ก็มีโอกาสสูงที่ PDF viewer ที่ผู้ใช้ใช้อยู่จะไม่รองรับมาตรฐานที่จำเป็น

  • สุดสัปดาห์นี้ต้องลองใช้เองดู
    ผมมักคัดลอกด้วยมือจาก ไฟล์สแกน PDF RPG แหล่งที่มาไม่แน่ชัด ที่ไม่ได้ทำ OCR จึงไม่มีข้อความให้เลือก หรือถึงทำ OCR แล้วคุณภาพก็ไม่ดี
    บางครั้งการพิมพ์เองตรง ๆ เร็วกว่าการแก้ข้อผิดพลาดจาก copy-paste หรือการทำ OCR แล้วค่อยแก้ข้อผิดพลาดแบบแท้จริง
    แม้จะเป็น PDF ทางการ รูปแบบก็มักพัง ทำให้มีช่องว่างสองสามช่องหรือแท็บแทรกระหว่างคำ ถ้าใช้ได้จริง น่าจะช่วยประหยัดเวลาได้มากจริง ๆ

    • ผมก็คิดถึง use case นี้อยู่เหมือนกัน ลองกับหนังสือหนึ่งเล่มแล้ว แต่ผลลัพธ์ไม่ค่อยดีนัก
      ตารางและกล่องข้อความพังไปเยอะ ถ้าจับภาพหน้าจอตารางแล้ววางลงใน ChatGPT ให้ แปลงเป็นตาราง Markdown ผลออกมาค่อนข้างดี หาก prompt เพิ่มเล็กน้อย เช่น “อ่านทีละแถว หัวคอลัมน์คือ X, Y, Z โดย X เป็นข้อความ, Y เป็นตัวเลข, Z เป็นคำ” ก็จัดการตารางที่ไม่สม่ำเสมอได้
    • ในบรรดาสื่อเกี่ยวกับ RPG มีเนื้อหาจำนวนมากที่ไม่เคยออกเป็นสื่อกายภาพ และกลายเป็น ผลงานกำพร้าด้านทรัพย์สินทางปัญญา อยู่มากจริง ๆ เลยคิดถึงเรื่องนี้ทันที

  • ทุกวันนี้ Tesseract OCR พอใช้ได้แค่ไหนแล้ว? ตอนเคยลองเมื่อก่อน ยังห่างชั้นจาก OCR ออนไลน์ของ AWS, Azure, GCP มาก

    • ช่วงหลังมีอัปเดตค่อนข้างเยอะ และใน git ก็ระบุ Tesseract 5 เป็น dependency มีความเป็นไปได้สูงว่ามันดีขึ้นมากเมื่อเทียบกับครั้งสุดท้ายที่ลอง
      https://github.com/tesseract-ocr/tesseract/releases
      สุดท้ายคงขึ้นอยู่กับ use case สำหรับงานส่วนตัวแบบนี้น่าจะเพียงพอ และไม่ต้องใช้ข้อมูลผู้ใช้หรือบัตรเครดิตด้วย
    • ดีเกินคาด และ ประสิทธิภาพในเบราว์เซอร์ ก็น่าประทับใจ
      แต่ไวต่อความละเอียดมาก หากภาพเล็กลงต่ำกว่าขนาดหนึ่ง แม้มนุษย์จะยังอ่านได้ชัดเจนเพียงพอ ผลลัพธ์จาก Tesseract ก็เละเทะ
    • ต้องทำ preprocessing ค่อนข้างเยอะ ผมเคยใช้แค่โซลูชันของ GCP และจากประสบการณ์ ฝั่งนั้นดีกว่า
    • เพิ่งลองใช้เมื่อไม่นานมานี้ และล้มเหลวแม้กับรูปภาพพื้นฐานมาก ๆ
      ลอง iOS Vision API ด้วย แต่ก็ล้มเหลวเช่นกัน เคสทดสอบคือภาพถ่ายหน้าหนังสือที่ถ่ายชัดเจน

  • คำถามถึงผู้เขียน: ทำไมต้องเป็น Markdown? ส่วนที่ยากของเครื่องมือนี้น่าจะเป็นการพาร์ส PDF ให้ได้ความแม่นยำสูง ไม่ใช่ว่าหลังจากนั้นจะส่งออกเป็นรูปแบบอะไร
    ดังนั้นถ้าผู้ใช้เลือกฟอร์แมตผลลัพธ์ได้ก็น่าจะดี ถ้ามีตัวพาร์ส PDF ที่แม่นยำสูง ผมอยากใช้มันกับ การสร้าง EPUB

    • จำเป็นต้องมีมาร์กอัปบางประเภทที่คงมาร์กอัปเชิงโครงสร้างไว้ให้ได้มากที่สุด
      ผมดูแลอีบุ๊กให้สำนักพิมพ์มหาวิทยาลัย มีรายการเก่า ๆ จำนวนมากที่รอการแปลง และในนั้นจำนวนไม่น้อยเหลืออยู่แค่สแกนหน้าจากฉบับพิมพ์เก่าเท่านั้น ถ้าจะให้บริการเป็น EPUB ก็ต้องรู้ว่าการแบ่งบท ชื่อเรื่อง ตาราง แผนภูมิ สูตร และข้อความอ้างอิงอยู่ตรงไหน บริษัทเอาต์ซอร์สช่วยทำได้ก็จริง แต่หนังสือบางเล่มมีต้นทุนแปลงสูงกว่ารายได้จากการขาย ถ้าทำเองได้บ้างก็คงดี
    • เห็นด้วยว่ารูปแบบกลางควรใกล้เคียงกับ ข้อความธรรมดา ที่สามารถเลือกแปลงเป็นรูปแบบอื่นได้
      แต่ในกรณีนี้ดูเหมือน Markdown ถูกใช้เป็นรูปแบบกลาง มันใกล้เคียงข้อความธรรมดา แต่ยังรักษาข้อมูลเลย์เอาต์แบบง่าย ๆ ไว้ได้ ในทางปฏิบัติผมน่าจะรับเอาต์พุต Markdown แล้วนำไปต่อกับเครื่องมือที่แปลงเป็นรูปแบบผลลัพธ์สุดท้ายที่ต้องการ
    • เหตุผลที่เลือก Markdown คืออยากเก็บ สูตรคณิตศาสตร์, ตาราง, ข้อมูลตัวหนา/ตัวเอียง และหัวข้อไว้
      สูตรสามารถครอบด้วย $/$$ ได้ ยังไม่ได้ดูเรื่องเอาต์พุต EPUB แต่เพราะความต้องการแบบนี้ ข้อความธรรมดาจึงถูกตัดออกไป

  • มีกรณีใช้งานเฉพาะทางที่ยังหาวิธีแก้ดี ๆ ไม่ได้: คือ การอ่านเอกสารก่อสร้าง
    แบบแปลนมักมาเป็น PDF เสมอ แต่ตอนพาร์สไฟล์ DXF(AutoCAD) ทำได้ดีกว่ามาก อย่างไรก็ตาม ถึงผมจะเป็นผู้รับเหมาหลักที่หน้างาน ก็ไม่ได้ขอให้สถาปนิกส่ง DXF มาให้ได้ง่ายเสมอไป

  • ผมอ่านบทความยาว ๆ ส่วนใหญ่ด้วย เครื่องอ่านอีบุ๊ก
    PDF โดยเฉพาะเลย์เอาต์หลายคอลัมน์ แทบจะเป็นฝันร้ายเมื่อใช้ฟังก์ชันพื้นฐานของ Amazon Kindle หรือ Pocketbook เครื่องมือนี้น่าจะช่วยปรับปรุงประสบการณ์การอ่านได้พอสมควร

  • งานดีมาก
    เคยสงสัยว่า ภาพหลอน ที่เห็นในเอาต์พุตของ Nougat มาจากไหน ถ้าลองไล่อ่านเอาต์พุต Nougat ของตัวอย่าง Think Python จะเข้าใจว่าหมายถึงอะไร
    พอกลับมาดูอีกทีเห็นว่าเอาผ่าน LLM ด้วย ดังนั้นภาพหลอนก็เป็นสิ่งที่คาดได้

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

  • ดูเหมือนเป็นเครื่องมือที่อาจช่วยย้ายโน้ตของผมออกจาก OneNote ได้

  • น่าสนใจทีเดียว ถ้าเพิ่ม ตัวอย่างก่อนและหลังการแปลง สักสองสามตัวอย่างใน repo ก็น่าจะดี
    อยากรู้ว่ากำลังปรับให้เหมาะกับ PDF ประเภทไหนอยู่ แล้วคำอธิบายประกอบแบบลายมือจัดการอย่างไร?