รีวิว Docling: ตัวแปลงเอกสารเป็น Markdown ของ IBM ทำอะไรกับไฟล์ PDF ของคุณกันแน่

Docling มักถูกโยนไปอยู่หมวดเดียวกับเว็บสครัปเปอร์บ่อย ๆ ทั้งที่จริงแล้วไม่ใช่เลย มันคือชุดเครื่องมือแปลงเอกสารจาก IBM Research — ปัจจุบันเป็นโปรเจกต์ของ LF AI & Data Foundation — ที่รับไฟล์ที่คุณมีอยู่แล้ว (PDF, DOCX, PPTX, XLSX, HTML, รูปภาพ) แล้วแปลงออกมาเป็น Markdown หรือ JSON สโลแกนของมันพูดตรงตัวเลยว่า “เตรียมเอกสารของคุณให้พร้อมสำหรับ gen AI”

ดังนั้นนี่คือรีวิวแบบลองใช้จริงของตัวแปลงเอกสาร ไม่ใช่ตัวครอว์ลเว็บ ทุกอย่างด้านล่างทดสอบบนเครื่อง CPU-only เครื่องเดียว (macOS arm64, Python 3.14.2, Docling 2.111.0) ให้คะแนนจากสคริปต์ และบันทึกข้อผิดพลาดเป็นข้อผิดพลาดจริง ๆ โปรเจกต์นี้ใหญ่มากและอัปเดตแทบทุกวัน — 63,069 stars, 4,449 forks และมีการ push ในวันเดียวกับที่ผมดึงเมตาดาต้ามา — ดังนั้นตัวเลขเวอร์ชันหรือจำนวนปัญหาที่เห็นตรงนี้ให้มองเป็นภาพ ณ ตอนนั้น ไม่ใช่ค่าตายตัว

Docling คืออะไร และไม่ใช่อะไร

แกนหลักของทุกอย่างใน Docling คือ DoclingDocument: แปลงไฟล์ให้อยู่ในโครงสร้างนี้ก่อน แล้วค่อย export ออกเป็น Markdown, HTML, DocTags หรือ JSON แบบไม่สูญเสียข้อมูล โค้ดนี้อยู่ภายใต้สัญญาอนุญาตแบบ MIT (แม้โมเดลแต่ละตัวอาจมีไลเซนส์ต่างกัน) จุดเริ่มต้นมาจาก IBM Research Zurich และ ณ ตอนเขียนนี้รีลีสล่าสุดคือ v2.112.0 ซึ่งปล่อยออกมาก่อนผมทดสอบสองวัน

ความสามารถเด่นที่สุดคือเส้นทางสำหรับ PDF และรูปภาพ และเส้นทางนี้ไม่ได้อาศัยการอ่านสตริงธรรมดา ๆ แต่วางอยู่บนชุดโมเดลแมชชีนเลิร์นนิง: โมเดลจัดวางหน้าแบบ RT-DETR, โมเดลโครงสร้างตาราง TableFormer, โมเดล vision-language แบบเลือกใช้ได้ และ RapidOCR สำหรับไฟล์สแกน โมเดลเหล่านี้ใช้กู้คืนเลย์เอาต์ของหน้า ลำดับการอ่าน และโครงสร้างตาราง นี่แหละคือส่วนที่ควรรีวิว และเป็นส่วนที่การทดสอบ HTML ล้วน ๆ จะไม่เห็นเลย

มีความต่างอยู่อย่างหนึ่งที่ช่วยประหยัดเวลางงไปได้เป็นสัปดาห์ Docling ไม่ได้ไปดึงข้อมูลจากที่ไหนเอง มันไม่เรนเดอร์ JavaScript ไม่ทะลุกำแพง anti-bot และไม่ครอว์ลเว็บ คุณต้องส่งไฟล์ให้มัน แล้วมันจะทำหน้าที่ทำความเข้าใจไฟล์นั้น การครอว์ลเป็นงานของเครื่องมืออีกประเภท ซึ่งสำคัญมากเวลามีคนถามว่า Docling แทน Firecrawl ได้ไหม (คำตอบคือไม่ได้ — แต่เป็นเครื่องมือเสริมกัน และผมจะอธิบายต่อ)

การรันครั้งแรกที่ไม่มีใครเตือนคุณไว้

pip install docling ติดตั้งผ่านได้เรียบร้อยบน Python 3.14.2 จากนั้นพอเปิดดูใน virtualenv จะพบว่ามันกินพื้นที่ถึง 1.3 GB เพราะ Docling ดึงสแตก ML ทั้งชุดมาเป็น dependency หลัก แม้คุณจะ convert แค่ไฟล์ HTML ก็ตาม:

Dependency	On-disk size (MiB, du)
torch (2.13.0)	536
opencv (cv2)	119
transformers (5.8.1)	101
scipy	99
sympy	76
pandas	72
rapidocr (+ bundled models)	75.6
docling_parse	30

และนี่คือขนาดก่อนที่คุณจะ convert PDF สักไฟล์เดียว การแปลง PDF ครั้งแรกคือจุดที่เจอแรงเสียดทานจริง เพราะเป็นตอนที่โมเดลต้องดาวน์โหลดเข้ามา บน HuggingFace cache ที่เพิ่งเริ่มใหม่ การแปลง PDF ครั้งแรกใช้เวลาประมาณ 224 วินาที — และเกือบทั้งหมดเป็นเวลาในการดาวน์โหลด ไม่ใช่เวลาในการประมวลผล ตัวโมเดล layout กับ TableFormer รวมกันกินพื้นที่บนดิสก์ประมาณ 506 MiB (TableFormer 342 MiB + layout 164 MiB, ตรวจด้วย du) ส่วน RapidOCR จะดึงน้ำหนัก PP-OCRv4 ราว 40 MB ไปไว้ใน site-packages การแปลงไฟล์เดิมรอบที่สองล่ะ? 0.55 วินาที โมเดลถูกแคชไว้แล้ว จ่ายค่าผ่านทางแค่ครั้งเดียว

มีตัวเลขหนึ่งที่ควรมองข้าม: สคริปต์ตอน cold start แสดง model_download_mb เป็น 1060.2 อย่าเอาตัวเลขนี้ไปอ้างว่าเป็น footprint จริง เพราะมันมาจาก os.walk ที่ตาม symlink และ HuggingFace cache เก็บไฟล์โมเดลแต่ละไฟล์ไว้ครั้งเดียวใน blobs/ แล้วเปิดซ้ำผ่าน snapshots/ แบบ symlink ดังนั้นการไล่เดินไฟล์จึงนับไฟล์โมเดล 14 ไฟล์ซ้ำสองครั้ง ตัวเลขที่ตรงกับ du และตัดการนับซ้ำของ symlink แล้วคือ ประมาณ 506 MiB (ถ้านับเฉพาะ blobs คือ 505.4 MiB) ข้อสรุปสำหรับคนที่ benchmark Docling คือ ต้องรายงาน “ขนาดที่ดาวน์โหลด” กับ “ขนาดบนดิสก์” แยกกัน เพราะมันคนละเรื่อง

ยังมีอีกจุดที่คนทำ container กับ Docling มักเจอ น้ำหนักโมเดลถูกแยกเก็บสองที่และดาวน์โหลดคนละจังหวะ โมเดล layout กับ TableFormer จะเคารพ HF_HOME และโหลดตอนแปลง PDF ครั้งแรก แต่โมเดลของ RapidOCR ไม่ทำแบบนั้น — มันลงไปอยู่ใน …/site-packages/rapidocr/models/ เลย โดยไม่สนคอนฟิก cache ของคุณ หากคุณกำลังเตรียม image ไว้ล่วงหน้าหรือทำ air-gap คุณต้องจัดการทั้งสอง cache และการตั้ง HF_HOME อย่างเดียวไม่ครอบคลุมส่วนหลังนี้

อย่างไรก็ตาม ต้องพูดอย่างเป็นธรรม ตั้งแต่ Docling รุ่นก่อนหน้า โปรเจกต์นี้ก็ปล่อย docling-slim ออกมาแล้ว — ตัว core ขนาดราว 50 MB ที่ให้คุณ pip install docling-slim[format-html] สำหรับ HTML ได้โดยไม่ต้องลาก torch เข้ามา ดังนั้นน้ำหนัก 1.3 GB สำหรับเมตาแพ็กเกจ docling แบบค่าเริ่มต้นนั้นเป็นเรื่องจริง แต่ตอนนี้เป็นสิ่งที่เลือกไม่ใช้ได้แล้ว ผมทดสอบแพ็กเกจเริ่มต้นเพราะนั่นคือสิ่งที่ pip install docling ให้มา แต่ความหนักนี้ไม่ใช่บั๊กที่ยังไม่ได้แก้ — มีทางออกแบบโมดูลาร์อยู่แล้ว และถูกติดตามไว้ใน issue #2393

ระหว่างตั้งค่าผมเจอจุดสะดุดเล็ก ๆ ที่ควรบอกไว้: import docling; docling.__version__ จะโยน AttributeError: module 'docling' has no attribute '__version__' เพราะโมดูลไม่ได้ expose ค่าเวอร์ชันตรงนั้น วิธีเช็กที่ใช้ได้จริงคือ importlib.metadata.version("docling") ซึ่งจะได้ '2.111.0' กลายเป็นความรำคาญเล็ก ๆ ใน DX และ เปิด issue ฝั่ง upstream ตั้งแต่กรกฎาคม 2026 เป็น issue #3733

ความแม่นยำของตาราง: จุดที่ TableFormer คุ้มค่าจริง

ตารางคือเหตุผลหลักที่คนจะเลือก Docling แทนการ dump PDF เป็นข้อความธรรมดา ๆ ผมจึงสร้าง PDF ตาราง 7 แบบพร้อม ground truth ที่อ่านด้วยเครื่องได้ แล้วให้คะแนนผลลัพธ์ทีละเซลล์ มีสองเมตริกที่สำคัญ และมันไม่ใช่เรื่องเดียวกัน: cell recall คือสัดส่วนของค่าจริงที่ยังปรากฏอยู่ที่ไหนสักแห่งในตารางที่ตรวจพบ ส่วน in-row rate คือสัดส่วนที่อยู่ในแถวที่ถูกต้อง ถ้าเอาสองอย่างนี้มาปนกันจะทำให้เครื่องมือดูดีเกินจริง ดังนั้นนี่คือทั้งคู่:

Table (stress)	Detected	Cell recall	In-row rate	Note
T1 simple bordered grid (5×8), alone on page	No	0.0	—	classified as <!-- image -->, all cells dropped
T2 borderless (only a header rule)	Yes	1.00	1.00	perfect, exact grid
T3 merged 2-level colspan header	Yes	1.00	0.97	all values found; one header value shifts a row
T4 merged rowspan row-label, alone on page	No	0.0	—	classified as <!-- image -->
T5 colspan header + borderless	Yes	1.00	0.97	all values found; same header-row shift as T3
T6 financials, blank column, right-aligned	Yes	1.00	1.00	blank column preserved, not shifted
T7 wide 12-column grid	Yes	1.00	1.00	no column shift on a wide table

ใน 5 ตารางที่ Docling ตรวจพบ ค่าทุกตัวจาก ground truth ถูกดึงออกมาครบ — cell recall 1.00 ทุกกรณี จากทั้งห้าตารางนั้น มีถึงสามตารางที่ค่าทุกตัวอยู่ในแถวที่ถูกต้องด้วย ส่วนกรณีหัวตารางแบบหลายชั้นสองอัน (T3 และ T5) ค่าหัวตารางหนึ่งตัวจะเลื่อนหลุดจากแถวเดิม ทำให้ in-row ลดลงเหลือ 0.97 — ข้อมูลยังอยู่ครบ เพียงแต่การจัดแถวแกว่งไปหนึ่งบรรทัดในหัวตารางที่ซ้อนกัน

กรณีโครงสร้างยาก ๆ กลับทำได้ดีกว่าที่คาดไว้ หัวตาราง colspan สองชั้น flatten ออกมาเป็น GitHub-flavored Markdown ได้ถูกต้อง (ป้าย "Q1 2026" ถูกทำซ้ำเหนือสองคอลัมน์ที่ span อยู่ ซึ่งเป็นวิธี collapse colspan เป็น GFM ที่ถูกต้อง) ตารางแบบไม่มีเส้นขอบและมีแค่เส้นหัวตาราง (T2) ออกมาพอดี ตารางกว้าง 12 คอลัมน์ (T7) ก็ไม่หลุดคอลัมน์ และคอลัมน์การเงินที่ว่างเปล่าทั้งคอลัมน์ (T6) ก็ถูกเก็บไว้เป็นช่องว่าง ไม่ได้ถูกตัดทิ้งหรือยุบรวม ซึ่งสอดคล้องกับ คะแนน TableFormer TEDS อย่างเป็นทางการ — 95.4 สำหรับ simple, 90.1 สำหรับ complex, 93.6 รวมทั้งหมด — และหน้า model card ก็ทดสอบสูงกว่า Camelot (73.0) และ EDD (88.3)

ขอเตือนเรื่อง merged cells ไว้สักนิด เพราะมี issue เปิดไว้อีกตัวที่เล่าอีกแบบหนึ่ง issue #3698 รายงานว่า V1 และ V2 จัดการแถวและคอลัมน์ที่ merge ไม่ค่อยถูกต้อง ในชุดทดสอบของผม ค่า colspan แบบง่าย (T3/T5) และ rowspan ถูก flatten ได้ถูกต้อง มีเพียงการเลื่อนหนึ่งแถวของหัวตารางหลายชั้นตามที่บอกไว้ข้างต้น แต่เคสที่พังใน #3698 เป็นการ merge หลายแถวหลายคอลัมน์แบบไม่สม่ำเสมอ และ ตารางหลายหน้า ซึ่งเป็นปลายทางที่พังยากกว่า ชุดของผมอยู่ฝั่งง่าย ดังนั้นคำพูดที่แม่นคือ: colspan และ rowspan แบบง่ายดึงกลับมาได้ในชุดนี้ (แต่หัวตารางหลายชั้นอาจเลื่อนหนึ่งแถว) ส่วนการ merge ซับซ้อนและไม่สม่ำเสมอยังเป็นปัญหาที่เปิดค้างอยู่ ไม่ใช่ “merged cells ใช้ได้ทั้งหมด” และก็ไม่ใช่ “merged cells พังหมด” เช่นกัน

กับดัก: ตารางที่อยู่โดด ๆ บนหน้าเดียวอาจหายไป

ย้อนดูตาราง T1 และ T4 จะเห็นว่ามันไม่ถูกตรวจพบเลย Docling ส่งออก <!-- image --> แล้วทิ้งทุกเซลล์ไปโดยไม่มี error T1 เป็นกริดมีเส้นขอบขนาด 5×8 แบบธรรมดามาก เรื่องนี้น่ากังวลพอจนผมไม่อยากเรียกมันว่าเป็นแค่จุดอ่อนของ table parsing จนกว่าจะหาสาเหตุที่แท้จริงได้ จึงทำ A/B แบบสคริปต์ขึ้นมา

ก่อนอื่น ผมตัดคำอธิบายที่ชัดเจนเกินไปออกไปก่อน text layer ยังอยู่ครบ — pypdfium2 อ่านได้ 327 ตัวอักษรจาก T1 และ 221 จาก T4 แปลว่านี่คือ PDF ดิจิทัลจริง ไม่ใช่ภาพสแกน การปิด OCR (do_ocr=False) ก็ไม่ช่วย ตารางยังหายเหมือนเดิม และเมื่อดู DoclingDocument โดยตรงจะเห็นว่า len(doc.tables) == 0 ขณะที่ len(doc.pictures) == 1 — โมเดลเลย์เอาต์ตีบริเวณทั้งก้อนเป็น Picture

จากนั้นก็ถึงการทดสอบที่ชี้ขาด ผมเรนเดอร์ T1 และ T4 เดิมอีกครั้ง แต่คราวนี้ใส่ย่อหน้าบทความธรรมดา ๆ ล้อมรอบ แล้ว convert ใหม่ ทั้งคู่กลับมาอย่างสมบูรณ์ len(doc.tables) == 1, มีตาราง GFM ถูกต้องออกมา และ label rowspan “North” ของ T4b ถูกทำซ้ำครอบคลุมทั้งสามแถวได้ถูกต้อง ตารางเดิมเป๊ะ ตัวแปรเดียวที่เปลี่ยนคือมันยืนอยู่คนเดียวบนหน้าที่โล่ง หรืออยู่ในบริบทของข้อความ

ดังนั้นข้อควรระวังที่แท้จริงไม่ใช่ว่า TableFormer เปราะบาง แต่คือโมเดลเลย์เอาต์ RT-DETR ของ Docling ใช้บริบทของหน้า และตารางขนาดเล็กที่อยู่โดด ๆ บนหน้าที่แทบว่างเปล่ามีโอกาสสูงจะถูกอ่านเป็น Picture แล้วหายไปเงียบ ๆ เรื่องนี้เจอง่ายในงานจริง เพราะมันคล้ายเอกสารใบแจ้งหนี้ ใบสเปก หรือ export ที่ถูก crop มาเป๊ะ ๆ: หนึ่งหน้าหนึ่งตาราง ไม่มีข้อความรอบข้าง วิธีแก้ที่ตรงไปตรงมาและได้ผลคือ ให้ context แก่โมเดลเลย์เอาต์มากขึ้น หรือเช็ก doc.tables หลัง convert แล้ว flag หน้าใดก็ตามที่มีจำนวนเป็นศูนย์ เรื่องนี้ใกล้เคียงกับ issue #3495 (ตารางถูกตรวจเจอทั้งเป็น Table และ Picture) แต่ตัวทริกเกอร์จากความ sparse ของหน้า — ตารางเดียวกัน ถ้าอยู่โดด ๆ จะหาย ถ้าอยู่ในข้อความจะผ่าน — ผมหาไม่เจอว่ามีใครบันทึกไว้ที่ไหนมาก่อน วัดมาแล้ว ไม่ได้เพิ่งมีคนรู้เป็นครั้งแรก

OCR บนสแกนจริง: RapidOCR ไม่ใช่ EasyOCR

PDF ที่สแกนมาเป็นจุดที่ตัวแปลงหลายตัวพลาดกันแบบเงียบ ๆ ผมเลยป้อน Docling ด้วยไฟล์สแกนจริงสองไฟล์ที่วัดได้ว่า มี text layer เป็น 0 ตัวอักษร — pypdfium2 รายงานว่าไม่สามารถกู้คืนตัวอักษรได้เลย ยืนยันว่าผลลัพธ์ที่ออกมาคือ OCR จริง ไม่ใช่ text layer ที่ซ่อนอยู่ข้างใต้

ไฟล์หน้าเดียว ocr_test.pdf ถูกคืนข้อความอย่างสะอาดใน 14.3 วินาทีบน CPU: “Docling bundles PDF document conversion to JSON and Markdown in an easy self contained package,” ถูกดึงกลับมาแบบตรงตัว ส่วนไฟล์สี่หน้า nemotron_multipage.pdf รัน OCR ครบทั้งสี่หน้า ใช้เวลารวม 70.1 วินาที (17.5 วินาที/หน้า) และพิมพ์ประโยคทดสอบซ้ำในแต่ละหน้า OCR เริ่มอัตโนมัติ — ไม่ต้องตั้ง flag ไม่ต้อง config เพิ่ม

รายละเอียดที่บทความหลายชิ้นมักพูดผิดคือ เอนจิน OCR ค่าเริ่มต้นคือ RapidOCR ไม่ใช่ EasyOCR ผมยืนยันเรื่องนี้ด้วยการดูไฟล์น้ำหนัก PP-OCRv4 .pth ถูกดาวน์โหลดตั้งแต่รันแรก หลายบล็อกที่มีอยู่และ FAQ เก่าของ Docling ยังบอกว่า default คือ EasyOCR ซึ่งล้าสมัยไปแล้ว ตอนนี้ EasyOCR เป็นส่วนเสริมที่ต้องเลือกเปิดเอง ข้อจำกัดที่ยังจริงอยู่คือ OCR เป็นเส้นทางที่ช้าที่สุดเมื่อใช้งานในสเกลใหญ่ และตัวเลขทั้งหมดที่เห็นตรงนี้เป็นเพดานของ CPU-only ถ้ามี GPU เวลาเหล่านี้จะลดลงได้มาก

PDF จริง ลำดับการอ่าน และเวลาต่อหน้า

ไฟล์ทดสอบสังเคราะห์ช่วยพิสูจน์พฤติกรรมเฉพาะจุด ส่วน PDF จริงช่วยพิสูจน์ว่าของใช้งานได้จริง ผมทดสอบกับบทความวิชาการจริงสองไฟล์ที่สร้างจากดิจิทัล — รายงานเทคนิคของ Docling ขนาด 9 หน้า และ “Attention Is All You Need” ขนาด 15 หน้า ทั้งคู่เป็นสองคอลัมน์พร้อมตารางและสูตร

ในบทความ Attention ขนาด 15 หน้า เครื่องหมายของแต่ละส่วนทั้งห้า — Abstract, Introduction, Background, Conclusion, References — ปรากฏ ตามลำดับในเอกสาร บน Markdown ที่ถูก linearize แม้จะเป็นเลย์เอาต์สองคอลัมน์ก็ตาม โพรบเนื้อหาทุกตัว (Transformer, encoder, BLEU, multi-head) อยู่ครบ และตารางผลลัพธ์หลายคอลัมน์ชื่อดังถูกตรวจจับเป็นตาราง 4 อัน นี่คือการกู้คืนลำดับการอ่านและการรวมคอลัมน์ที่ได้ผลจริง ซึ่งเป็นคุณค่าหลักสำหรับ RAG chunking — คุณไม่สามารถแบ่ง chunk เอกสารได้ดีถ้าตัว linearizer ทำให้หน้าสองคอลัมน์กลายเป็นข้อความสลับกันมั่ว ๆ

เรื่องเวลาให้บทเรียนที่ชวนแปลกใจ เวลาต่อหน้าไม่ได้ขึ้นกับจำนวนหน้า แต่ขึ้นกับความหนาแน่นของโครงสร้างในแต่ละหน้า รายงาน 9 หน้าแต่หนาแน่นกว่ารันที่ 14.95 วินาทีต่อหน้า — ช้ากว่าเอกสาร 15 หน้าที่ 5.99 วินาทีต่อหน้า — เพราะมันมีตารางและรูปจำนวนมากกว่า และแต่ละอย่างก็ดึง inference ของ layout กับ TableFormer เพิ่มขึ้น ดังนั้น “วินาทีต่อหน้า” บน CPU จึงเป็นฟังก์ชันของความหนาแน่นของโครงสร้าง ไม่ใช่ความยาวของเอกสาร นี่ยังเป็นการรันครั้งเดียวบน CPU-only จึงเป็นเพดาน ไม่ใช่ตัวเลขการใช้งานจริงใน production

หลายฟอร์แมต และคำว่า JSON แบบไม่สูญเสียข้อมูล

Docling โฆษณาว่าสามารถ parse หลายฟอร์แมตได้แบบรวมศูนย์ ผมจึงสร้าง DOCX, XLSX และ PPTX ที่มีเนื้อหาที่รู้ล่วงหน้าและมีโพรบที่ตรวจได้ แล้วเช็กสองอย่าง: โพรบปรากฏใน Markdown ไหม และรอดกลับออกมาผ่าน JSON round-trip ด้วย export_to_dict() ไหม

File	Convert s	MD probes found	Tables in MD	Probes survive JSON
report.docx (headings + merged-"Total" table + bullets)	0.137	7/7	1	Yes
workbook.xlsx (2 sheets, blank column)	0.016	6/6	2	Yes
deck.pptx (3 slides, bullets + table)	0.038	6/6	1	Yes

โพรบเนื้อหาทั้งหมดโผล่ใน Markdown ครบ ตารางถูกกู้คืนมาได้ (รวมแถว “Total” ที่ merge ใน DOCX และทั้งสองชีตของ XLSX) และทุกโพรบก็รอดออกมาผ่าน JSON ของ export_to_dict() ด้วย ซึ่งเป็นหลักฐานที่มีน้ำหนักสำหรับคำเคลมว่า DoclingDocument แบบ lossless ใช้งานได้จริง อย่างน้อยกับอินพุตที่สะอาด ฟอร์แมตเหล่านี้วิ่งผ่าน backend เฉพาะของแต่ละชนิด ไม่ได้ใช้โมเดล ML จึงทำงานในระดับสิบมิลลิวินาทีและใช้ได้แบบออฟไลน์เต็มที่ ขอบเขตของคำพูดนี้ก็ตรงไปตรงมา: ไฟล์สะอาดอย่างละหนึ่งไฟล์ช่วยยืนยันว่าสนับสนุนกว้าง แต่ยังไม่ใช่ stress test ของไฟล์ Office ที่มีปัญหา

HTML: ซื่อสัตย์ แต่ยังไม่สะอาด

นี่คือข้อควรระวังที่เป็นตัวตัดสินว่า Docling เหมาะกับ RAG pipeline ของคุณไหม ดังนั้นอ่านดี ๆ Docling แปลง HTML ทั้งหน้า มันไม่ได้ทำ main-content extraction แบบ readability ผมวัดว่าขอบเว็บยังหลุดรอดมาแค่ไหน โดยนับบรรทัดเมนูนำทาง สารบัญ คุกกี้ และ footer ที่อยู่ใน output ของ Docling เอง

Page	Non-blank MD lines	Boilerplate lines	% boilerplate	Article starts at line
Wikipedia "Web scraping"	255	34	13.3%	28
scrapethissite/forms	63	1	1.6%	—
books.toscrape	65	0	0.0%	—
quotes.toscrape	35	0	0.0%	—

บนหน้าที่มี chrome เยอะอย่าง Wikipedia ประมาณ 13% ของบรรทัด Markdown เป็น boilerplate อย่าง nav/TOC/footer และบทความจริงไม่เริ่มจนถึงบรรทัด 28 — output เปิดมาด้วย “move to sidebar / Contents / Toggle the table of contents” และปิดด้วย “CS1 maint… / Search Wikipedia” สำหรับหน้าที่คอนเทนต์สะอาด (books, quotes) ตัวเลขก็แทบเป็น 0% ดังนั้นนี่คือปัญหาเรื่อง template chrome ไม่ใช่ภาษีรายหน้า Docling ให้ Markdown แบบ faithful ทั้งเอกสาร ไม่ใช่การแยกเฉพาะบทความหลักแบบสะอาด ปัญหาของ HTML furniture นี้ถูกติดตามไว้ใน upstream ใน issue #1865 (ปิดแล้ว) และ #1930 (ยังเปิดอยู่)

มีสองอย่างที่ทำให้การประเมินนี้ยุติธรรมขึ้น อย่างแรก เฉพาะ HTML เท่านั้นที่ Docling ไม่ได้ใช้โมเดล ML ใด ๆ เลย — มันใช้ backend แบบ BeautifulSoup บน pipeline ง่าย ๆ เรื่อง “vision models อ่านหน้าเว็บของคุณ” ใช้กับ PDF และรูปภาพเท่านั้น ถ้าส่ง HTML ให้ Docling กลไก layout หรือ TableFormer จะไม่ทำงาน อย่างที่สอง เส้นทาง PDF ยังพยายามจัดหมวด header และ footer furniture อยู่บ้าง ดังนั้นจะพูดว่า “ไม่มีการลบ boilerplate เลย” ก็แรงเกินไป สิ่งที่ได้ boilerplate กลับมาคือ backend ของ HTML โดยเฉพาะ

เทียบยังไง และ Thunderbit อยู่ตรงไหน

ลองใช้ Thunderbit สำหรับดึงข้อมูลเว็บ

เครื่องมือหลักที่คนชอบเอา Docling ไปเทียบคือ Firecrawl ดังนั้นนี่คือตารางวางตำแหน่งให้เห็นภาพ ก่อนอื่นต้องบอกชัด ๆ ว่านี่คือการเทียบระดับเอกสาร ไม่ใช่ benchmark บนเครื่องเดียวกัน ผมไม่ได้รัน Firecrawl กับชุดไฟล์เหล่านี้ คอลัมน์ของ Docling เท่านั้นที่วัดจริงในที่นี้ ส่วนคอลัมน์ Firecrawl มาจากเอกสารสาธารณะของมัน

Axis	Firecrawl (per its docs)	Docling (measured here)
Core job	Crawl + scrape the live web → Markdown	Convert a document you already have → Markdown/JSON
Fetching / JS render / anti-bot	Yes (hosted browser)	No — you supply the file
Main-content extraction	Yes	No — faithful full-document (~13% chrome on Wikipedia)
PDF table structure (ML)	limited	Yes — TableFormer (TEDS 93.6 official; cell recall 1.00, in-row 0.97–1.00 on detected fixtures)
Scanned PDF / OCR	limited	Yes — RapidOCR by default (recovered a 0-text-layer scan)
Format breadth	web pages	PDF/DOCX/PPTX/XLSX/HTML/EPUB/images
Deployment	hosted API (+ self-host)	local pip library, offline, no API key
Setup weight	API key / light client	1.3 GB default install + ~506 MiB models (or docling-slim)
License	commercial / source-available	MIT

สรุปสั้น ๆ คือ Firecrawl เหมาะเมื่อข้อมูลของคุณอยู่บนเว็บจริงและต้องการการครอว์ล การเรนเดอร์ JS และการเก็บเฉพาะเนื้อหาหลัก ส่วน Docling เหมาะเมื่อคุณมีเอกสารอยู่ในมือแล้ว — โดยเฉพาะ PDF, ไฟล์สแกน และไฟล์ Office ที่มีตารางเยอะ — และต้องการการแปลงแบบออฟไลน์ที่รักษาโครงสร้างจริง รวมทั้งเข้าใจตารางและ OCR ได้ดี ทั้งสองตัวเสริมกัน ไพพ์ไลน์ที่ใช้งานจริงมักจะใช้ตัวหนึ่งครอว์ล แล้วใช้อีกตัวแปลงเอกสาร

และตรงนี้ผมขอพูดให้ชัดเรื่อง Thunderbit ด้วย เพราะผมทำงานที่นี่ ถ้าจะทำเป็นไม่เกี่ยวข้องเลยก็คงไม่ซื่อสัตย์ Thunderbit กับ Docling ไม่ได้ทำงานเดียวกัน และผมจะไม่ฝืนบอกว่ามันเท่ากัน สำหรับนักพัฒนา Thunderbit คือ AI scraping API บวก MCP server บวก CLI และหน่วยงานของมันคือ หน้าเว็บจริง POST /distill แปลง URL ให้เป็น Markdown ที่สะอาดพร้อมใช้งานกับ LLM (รับมือทั้ง JS rendering, anti-bot และ CAPTCHA ซึ่ง Docling ไม่ได้แตะ) ส่วน POST /extract จะคืน JSON แบบ structured ที่แมตช์กับ schema ซึ่งคุณกำหนดเอง นี่คือฝั่ง fetch-and-clean ของ RAG pipeline ส่วน Docling คือฝั่งเอกสารที่อยู่ในเครื่อง — PDF, ไฟล์สแกน, สเปรดชีตที่นอนอยู่บนดิสก์ของคุณ ถ้าคอร์ปัสของคุณคือหน้าเว็บ ให้ใช้ Thunderbit API, เครื่องมือ MCP (thunderbit_suggest_fields, thunderbit_distill, thunderbit_extract) หรือ CLI (npx @thunderbit/thunderbit-cli) ถ้าเป็น PDF และสแกน ให้ใช้ Docling ถ้าเป็นทั้งสองอย่าง — ซึ่งเป็นงานส่วนใหญ่ในโลกจริง — ก็ใช้คู่กัน และไม่มีใครพยายามเป็นอีกฝ่าย

คำตัดสิน: ยังชั่วคราว และยังมีการบ้าน

ผมจะไม่ให้คะแนนรวม 0–100 แบบเดียว เพราะถ้าเอาคะแนนถ่วงน้ำหนักมาใช้ มันจะหักแต้มจากสิ่งที่ Docling ไม่เคยอ้างว่าทำอยู่แล้ว (เช่น การครอว์ล) แล้วทำเหมือนเทียบกันได้ ในแต่ละมิติ จากชุดทดสอบที่ผมลอง:

• การตั้งค่า / การรันครั้งแรก: หนัก — virtualenv 1.3 GB, โมเดล ~506 MiB, PDF แรก ~224 วินาที, warm run ~0.55 วินาที — แต่ docling-slim มีทางเลือกให้หนีความหนักนี้ได้
• ความแม่นยำของตาราง: แข็งแรงเมื่อมีการตรวจพบตาราง (cell recall 1.00 ใน 5/5, in-row 0.97–1.00) สอดคล้องกับเรื่อง TEDS ทางการบนชุดนี้
• ความทนทานต่อการตรวจจับตาราง: มีกับดักหน้าที่ sparse — ตารางที่อยู่โดด ๆ อาจถูกมองเป็น Picture แล้วหายไป ควร post-check doc.tables
• สแกน / OCR: ใช้ได้, ค่าเริ่มต้นคือ RapidOCR; แต่ช้าเมื่อใช้งานหนัก
• หลายฟอร์แมต: ดี และ JSON round-trip ยังอยู่ครบ
• HTML: ซื่อสัตย์ แต่ยังไม่สะอาด — ไม่ได้แยก main content
• ประสบการณ์นักพัฒนา: API สั้น ๆ แค่ 3 บรรทัดและ DoclingDocument จัดระเบียบดี ยกเว้นเรื่องไม่มี __version__

เหมาะกับใคร: ทีมที่ทำ RAG หรือ data pipeline บน PDF, สแกน, และไฟล์ Office ที่ต้องการการแปลงแบบออฟไลน์ รักษาโครงสร้าง และเข้าใจตารางกับ OCR จริง ๆ ส่วนใครที่ไม่เหมาะ: คนที่ต้องการการครอว์ลเว็บสด หรือการดึงเฉพาะเนื้อหาหลักของ HTML แบบสะอาด ๆ — นั่นเป็นงานของเครื่องมือคนละแบบ

และเพราะนี่คือรีวิว ไม่ใช่ข่าวประชาสัมพันธ์ ข้อจำกัดก็ต้องอยู่บนป้ายเหมือนเดิม นี่คือการเจาะทดสอบแบบเจาะจง — ตารางสังเคราะห์ 7 ชุดกับ PDF จริง 2 ไฟล์ บนเครื่อง CPU-only เครื่องเดียว — ไม่ใช่ benchmark ความแม่นยำระดับ TEDS ทั้งหมด สิ่งหลายอย่างที่ผมไม่ได้ทดสอบ และคุณควรทดสอบเองก่อนฝาก pipeline ไว้กับ Docling ได้แก่ เส้นทาง VLM แบบเลือกใช้ได้ (GraniteDocling), footprint จริงของ docling-slim, การรันบน GPU, merged cells แบบซับซ้อนและไม่สม่ำเสมอรวมถึงตารางหลายหน้า, ความแม่นยำของสูตรเป็น LaTeX, และ — จุดที่มีโอกาสเซอร์ไพรส์คุณที่สุดในโปรดักชัน — ความทนทานของการใช้หน่วยความจำแบบ batch, การสเกลของเธรด/GIL, และ lifecycle ของ object เมื่อแปลงหลายพันไฟล์ Docling แข็งแรงในสิ่งที่มันอ้างว่าทำ โดยวัดได้จริงมากกว่าทำการตลาด และมันก็มีขอบเขตจริงที่คุณควรทำแผนที่ไว้ก่อนจะไว้ใจมันกับคอร์ปัสของคุณ รู้ข้อควรระวังเรื่องหน้าที่ sparse, เตรียมงบสำหรับการดาวน์โหลดรอบแรก และตรวจพฤติกรรมตอนใช้งานจริงของคุณเอง

ลองใช้ Thunderbit สำหรับดึงข้อมูลเว็บ Get Started Free

คำถามที่พบบ่อย

Docling เป็นเว็บสครัปเปอร์หรือเว็บครอว์ลเลอร์ไหม? ไม่ใช่เลย Docling แปลงเอกสารที่คุณมีอยู่แล้ว — PDF, DOCX, PPTX, XLSX, HTML, รูปภาพ — ให้เป็น Markdown หรือ JSON มันไม่ดึง URL ไม่เรนเดอร์ JavaScript และไม่จัดการ anti-bot การครอว์ลเว็บสดเป็นงานอีกประเภทหนึ่งที่ใช้เครื่องมืออย่าง Firecrawl หรือ Thunderbit web API ส่วน Docling เริ่มจากไฟล์ที่คุณส่งให้มัน

ติดตั้ง Docling หนักแค่ไหน และดาวน์โหลดตอนรันครั้งแรกกี่มากน้อย? เมตาแพ็กเกจ docling แบบค่าเริ่มต้นทำให้ virtualenv โตขึ้นราว 1.3 GB เพราะดึงสแตก ML ทั้งชุดเข้ามาเป็น dependency หลัก (torch อย่างเดียวก็ 536 MiB) การแปลง PDF ครั้งแรกจะดาวน์โหลดโมเดล layout และ TableFormer ลงดิสก์ราว 506 MiB บวกน้ำหนัก RapidOCR ราว 40 MB และใช้เวลาประมาณ 224 วินาที — เกือบทั้งหมดคือเวลาดาวน์โหลด การแปลงครั้งที่สองเหลือราว 0.55 วินาที ถ้าคุณต้องการแค่ฟอร์แมตเบา ๆ docling-slim (core ราว 50 MB) จะตัดเส้นทางหนักนี้ออกไป

Docling ทำ OCR ไหม และใช้อะไรเป็นเอนจิน? ทำครับ บน PDF ที่สแกนและไม่มี text layer Docling จะเรียก OCR อัตโนมัติ และในเทสต์ของผมกู้ข้อความกลับมาได้สะอาด เอนจินค่าเริ่มต้นคือ RapidOCR ไม่ใช่ EasyOCR — เป็นความเข้าใจผิดที่เจอบ่อยในบทความเก่า ๆ ตอนนี้ EasyOCR เป็นของเสริมที่ต้องเปิดเอง OCR คือเส้นทางที่ช้าที่สุดเมื่อใช้ในสเกลใหญ่ โดยเฉพาะบน CPU

ทำไม Docling ถึงแปลงตารางของฉันเป็นรูปภาพ หรือทิ้งมันไป? สาเหตุที่เป็นไปได้มากที่สุดคือเอฟเฟกต์ของหน้า sparse โมเดลเลย์เอาต์ RT-DETR ของ Docling ใช้บริบทของหน้า และตารางเล็ก ๆ ที่อยู่โดด ๆ บนหน้าซึ่งแทบไม่มีอะไรเลยอาจถูกจัดเป็น Picture แล้วหายไปแบบไม่มี error ตารางเดิมถ้าอยู่ท่ามกลางข้อความประกอบจะ convert ได้ดี วิธีแก้คือเพิ่มบริบทให้โมเดลเลย์เอาต์ หรือ post-check doc.tables หลัง convert แล้ว flag ทุกหน้าที่จำนวนเป็นศูนย์

Docling กับ Firecrawl — ควรใช้ตัวไหน? งานคนละแบบ จึงมักไม่ใช่คำถามแบบเลือกอย่างใดอย่างหนึ่ง Firecrawl ครอว์ลเว็บสด เรนเดอร์ JavaScript และดึงเนื้อหาหลัก ส่วน Docling แปลงเอกสารที่คุณถืออยู่แล้ว พร้อมโครงสร้างตาราง PDF และ OCR จริง และทำงานออฟไลน์ทั้งหมด ถ้าแหล่งข้อมูลของคุณคือหน้าเว็บ ให้ใช้เครื่องมือสำหรับเว็บ (Firecrawl หรือ Thunderbit API/MCP/CLI) ถ้าเป็น PDF, สแกน หรือไฟล์ Office ให้ใช้ Docling ในงานจริงส่วนใหญ่จะใช้ทั้งคู่ร่วมกัน