- การดึงข้อความจากไฟล์ PDF ยากกว่าที่คาดไว้มาก และ PDF โดยเนื้อแท้แล้วเป็น ไฟล์ฟอร์แมตที่อิงกราฟิก
- ภายใน PDF มีเพียง ข้อมูลตำแหน่งของ glyph และแทบไม่มีสัญญาณเชิงความหมาย จึงทำให้ การระบุและประกอบข้อความกลับขึ้นมาใหม่ เป็นเรื่องยาก
- เสิร์ชเอนจินต้องการ อินพุต HTML ที่สะอาด แต่เครื่องมือโอเพนซอร์สที่มีอยู่เดิมมี ข้อจำกัดในการดึงข้อมูลเชิงโครงสร้าง เช่น หัวข้อหรือย่อหน้า
- แนวทางวิชันที่อิงแมชชีนเลิร์นนิง ให้ความแม่นยำดีที่สุด แต่มีข้อจำกัดด้านทรัพยากรและประสิทธิภาพในการนำไปใช้ในวงกว้าง
- แนวทางปรับปรุงหลักคือการนำ อัลกอริทึมระบุหัวข้อและย่อหน้าที่อิงขนาดฟอนต์และสถิติ มาใช้เพื่อเพิ่มความแม่นยำในการดึงข้อมูล
ความท้าทายของการดึงข้อความจาก PDF
- เสิร์ชเอนจินสมัยใหม่มีความสามารถในการ ทำดัชนี ไฟล์ PDF แล้ว
- การดึงข้อมูลจาก PDF ไม่ใช่ปัญหาที่ง่าย เพราะ PDF เดิมทีเป็น ฟอร์แมตกราฟิก ไม่ใช่ฟอร์แมตข้อความ
- แทนที่จะเก็บข้อความจริงไว้ มันเป็น รูปแบบที่จัดวาง glyph ตามพิกัด จึงเกิดปัญหาอย่างการหมุน การซ้อนทับ ลำดับสลับกัน และการขาดข้อมูลเชิงความหมาย
- ข้อมูลในฐานะข้อความ ที่เรามักนึกถึงนั้นไม่ได้มีอยู่โดยตรงในไฟล์
- การที่สามารถค้นหาข้อความใน PDF viewer ด้วย ctrl+f ได้ จริง ๆ แล้วเป็นเรื่องน่าทึ่งมาก
ความต้องการของเสิร์ชเอนจินและข้อจำกัดของแนวทางพื้นฐาน
- อินพุตที่เสิร์ชเอนจินชอบมากที่สุดคือ HTML ที่สะอาด
- โมเดล computer vision สมัยใหม่ที่อิงแมชชีนเลิร์นนิงให้ประสิทธิภาพดีที่สุด แต่
- การประมวลผลไฟล์ PDF ปริมาณมหาศาล (หลายร้อย GB) บนเซิร์ฟเวอร์เครื่องเดียวโดยไม่มี GPU นั้น ไม่มีประสิทธิภาพ
- โชคดีที่สาขานี้ไม่ได้เป็นดินแดนที่ไม่เคยมีใครสำรวจมาก่อน ดังนั้น
- สามารถใช้คลาส PDFTextStripper ของ PDFBox เป็นจุดเริ่มต้นได้
- แต่ แทบไม่สามารถเข้าใจโครงสร้างเชิงความหมาย เช่น หัวข้อได้เลย—ดึงออกมาได้เพียงสตริงข้อความ
อัลกอริทึมระบุหัวข้อ
หลักการพื้นฐานของการระบุหัวข้อ
- โดยทั่วไปสามารถอาศัยลักษณะที่หัวข้อมักเป็น ตัวอักษรกึ่งหนาหรือหนากว่า และแยกตัวออกมาได้
- แต่หัวข้อที่ไม่ได้ทำตัวหนาก็พบได้บ่อย จึงใช้วิธีนี้อย่างเดียวไม่ได้
- ในหลายกรณี ขนาดฟอนต์ เป็นเกณฑ์ในการแยกหัวข้อ
- อย่างไรก็ตาม ขนาดฟอนต์แตกต่างกันอย่างมากในแต่ละเอกสาร จึง ไม่สามารถใช้ threshold แบบ global ได้
การใช้สถิติของขนาดฟอนต์
- แต่ละหน้ามักมี ขนาดฟอนต์หลัก (เนื้อความ) ที่เด่นอยู่
- หน้าแรก (ปก) มักมีข้อความเชิงบรรยายและข้อมูลผู้เขียน ทำให้การกระจายของขนาดฟอนต์แตกต่างออกไป
- เนื่องจาก การกระจายของขนาดฟอนต์ ต่างกันในแต่ละหน้า การใช้สถิติ รายหน้าแทนทั้งเอกสาร จึงได้ผลกว่า
- สามารถระบุหัวข้อได้ค่อนข้างแม่นยำด้วยการใช้ ค่ามัธยฐานของขนาดฟอนต์ในแต่ละหน้า แล้วเพิ่มขึ้นราว 20%
ปัญหาการรวมหัวข้อหลายบรรทัด
- ด้วยเหตุผลด้านสไตล์ หัวข้ออาจถูกแบ่งเป็นหลายบรรทัด
- การตัดสินว่าควรรวมหัวข้อเมื่อใดไม่ใช่เรื่องง่าย เพราะอาจมีหัวข้อสองบรรทัดขึ้นไป ชื่อผู้เขียน หรือข้อความเน้นแยกต่างหากปะปนกันอยู่
- กฎการรวม:
- การรวมบรรทัดที่ต่อเนื่องกันซึ่งมี ขนาดฟอนต์และน้ำหนักตัวอักษรเหมือนกัน มักใช้ได้ผลดีพอสมควร
- แต่มีกรณียกเว้นจำนวนมาก—การรวมแบบไม่ระวังอาจทำให้ได้ผลลัพธ์ผิดเพี้ยน
การปรับปรุงการระบุย่อหน้า
- PDFTextStripper ใช้ ระยะห่างระหว่างบรรทัดและการเยื้อง ในการระบุย่อหน้า
- เนื่องจากใช้ threshold คงที่ในการแยกแต่ละบรรทัด จึงมีข้อจำกัดเมื่อต้องรับมือกับระยะห่างบรรทัดที่ต่างกันในแต่ละเอกสาร
- โดยเฉพาะในฉบับร่างงานวิจัยหรือ preprint ระยะห่างบรรทัด 1.5~2 เท่าก็พบได้บ่อย
- ถ้า threshold ใหญ่เกินไป จะเกิดข้อผิดพลาดที่ หัวข้อถูกนับรวมเข้าไปในเนื้อความ
การแบ่งย่อหน้าด้วยสถิติ
- เช่นเดียวกับขนาดฟอนต์ มีการใช้ การประมวลผลเชิงสถิติกับระยะห่างระหว่างบรรทัด
- โดยใช้ค่ากลาง (ค่ามัธยฐาน) ของระยะห่างระหว่างบรรทัด ทำให้ แยกย่อหน้าได้อย่างทนทานไม่ว่าระยะห่างบรรทัดจะเป็นแบบใด
บทสรุป
- การดึงข้อความจาก PDF นั้นโดยพื้นฐานแล้ว หลีกเลี่ยงไม่ได้ที่จะไม่สมบูรณ์แบบ
- เพราะตัวฟอร์แมต PDF เองไม่ได้ถูกออกแบบมาเพื่อจุดประสงค์นั้น
- ในการนำไปใช้งานจริง การประนีประนอมเป็นสิ่งจำเป็น และกลยุทธ์ที่สำคัญคือการให้ได้ผลลัพธ์ระดับ “ดีพอใช้”
- สำหรับเสิร์ชเอนจิน การมุ่งเน้นการดึง สัญญาณที่มีความหมาย เช่น หัวข้อ บทคัดย่อ และเบาะแสเชิงโครงสร้างหลัก มีประสิทธิภาพกว่า
ตัวอย่างข้อความอ้างอิง
- Can Education be Standardized? Evidence from Kenya (2022) - Working Paper
: Guthrie Gray-Lobe, Anthony Keats, Michael Kremer, Isaac Mbiti, Owen W. Ozier
- The theory of ideas and Plato’s philosophy of mathematics (2019)
: Dembiński, B.
- The role of phronesis in Knowledge-Based Economy (2024)
: Anna Ceglarska, Cymbranowicz Katarzyna
1 ความคิดเห็น
ความคิดเห็นจาก Hacker News
เคยมีประสบการณ์ไหมที่คิดว่าบางอย่างในชีวิตทั้งใหม่และน่าสนใจ แต่แล้วความทรงจำลาง ๆ ก็ผุดขึ้นมาว่าเมื่อก่อนเคยเป็นผู้เชี่ยวชาญเรื่องนั้นอยู่นานหลายเดือนหรือหลายปี แม้แต่ช่วงที่เคยทำเรื่องเจ๋ง ๆ มาก ๆ ก็ดูเหมือนจะหายไปจากหัวหมด จนรู้สึกเหมือนต้องเริ่มใหม่ตั้งแต่ต้น จำได้ลาง ๆ ว่าเมื่อราว 6~7 ปีก่อนเคยทำอะไรสุดยอดกับ PDF และ OCR มาก่อน พอลองค้นใน Google ก็รู้สึกคุ้นกับชื่อ “tesseract”
ราวปี 2006 ตอนหงุดหงิดที่ e-reader แบบแฮ็กได้ยุคแรกอย่าง iRex ไม่สามารถคัดลอกข้อความจากงานวิจัยวิทยาศาสตร์แบบหลายคอลัมน์ได้ ตอนนั้นตัวดู PDF ใช้ poppler เลยไปแก้ poppler ให้เดาลำดับการอ่านของเอกสารหลายคอลัมน์ โดยอ้างอิงอัลกอริทึม OCR ของ Thomas Breuel ผู้เขียน tesseract มันเป็นการแฮ็กเชิง heuristic แบบหนึ่ง และเข้ากับ accessibility API ได้ไม่ดีนัก แม้จะมีฟีเจอร์เลือกข้อความหลายคอลัมน์เพิ่มเข้ามา แต่ก็เจอปัญหาในการโน้มน้าวผู้ดูแลโครงการอยู่ดี อย่างไรก็ทำให้ kpdf มีฟีเจอร์เลือกหลายคอลัมน์ได้ ทุกวันนี้กลับรู้สึกว่าถ้าจะใช้เพื่อจุดประสงค์นี้ ใช้ tesseract ตรง ๆ น่าจะสมเหตุสมผลกว่ามาก
เวลาหลายสิบปีของมนุษยชาติที่สูญเสียไปเพราะฟอร์แมต PDF นั้นเอาคืนไม่ได้ อยากรู้จริง ๆ ว่าความบ้าคลั่งนี้จะจบเมื่อไร
ช่วงหนึ่ง Tesseract เคยเป็น OCR โอเพนซอร์สที่ดีที่สุด แต่ทุกวันนี้คิดว่า docTR เหนือกว่าในด้านความแม่นยำและการเร่งด้วย GPU docTR เป็นโครงสร้างแบบ pipeline ที่สามารถผสมโมเดลตรวจจับและรู้จำข้อความได้หลายแบบ และยังฝึกกับ PyTorch หรือ TensorFlow รวมถึงจูนให้เหมาะกับโดเมนเฉพาะได้ จึงดึงประสิทธิภาพที่เหมาะกับงานเฉพาะทางได้ดีกว่ามาก
ชีวิตก็เป็นแบบนี้แหละ ทุกครั้งที่จบโปรเจกต์ก็มักจะคิดว่า “ตอนนี้ฉันกลายเป็นผู้เชี่ยวชาญในเรื่องนี้แล้ว แต่คงไม่ได้ทำมันอีกแล้วมั้ง” เพราะครั้งต่อไปก็มักจะต้องไปเริ่มหัวข้อใหม่แบบนับหนึ่งอีกครั้ง
ไม่นานมานี้มีคนถามเรื่อง C++ แล้วฉันตอบไปว่า “ไม่เคยทำงานจริงจังกับมัน” จากนั้นค่อยนึกออกทีหลังว่าเมื่อราว 20 ปีก่อนเคยเขียนโค้ดไคลเอนต์ของ private instant messenger ด้วย Borland C++ และมีคนใช้นับพัน เรื่องแบบนี้เกิดขึ้นบ่อยเหมือนกัน
ฉันไม่รู้หมดหรอกว่าในหัวคุณมีอะไรบ้าง แต่ดูแล้วน่าจะเป็น tesseract จริง ๆ ฉันเองก็มีประสบการณ์คล้ายกัน ของฉันคือเมื่อประมาณ 12 ปีก่อน
ตอนที่ HQ กำลังฮิต เคยทำตัวแก้โจทย์ HQ อัตโนมัติด้วย tesseract โดยแคปหน้าจอคำถามจากแอปแล้วส่งไปยัง API เล็ก ๆ จากนั้นเอาข้อความคำถามไปค้นใน Google แล้วนับจำนวนครั้งที่แต่ละคำตอบปรากฏเพื่อนำมาจัดอันดับตามความน่าจะเป็น มันไม่ค่อยแม่นและเป็นวิธีที่ง่ายมาก แต่ทำสนุกดี
มันก็ไม่ต่างจากมดคันไฟที่พอใบไม้ปลิวไปกับลม ก็แค่หาใบใหม่
ถ้าเป็นเรื่องเมื่อ 7~8 ปีก่อนตอนยังอายุยี่สิบกว่า ๆ ก็น่าจะยังจำได้ชัดอยู่ เลยสงสัยว่าอาจจะต่างวัยกันพอสมควรหรือเปล่า ไม่งั้นก็แนะนำให้ลองตรวจสุขภาพดูด้วย
อยากให้มีเครื่องมือที่ทำกับ PDF ได้เหมือน developer tools ของเบราว์เซอร์ (“Inspect Element”) คือสามารถ “ดู” content stream ของ PDF ในระดับซอร์สได้—เช่น BT…ET ที่ครอบข้อความ รวมถึงโอเปอเรเตอร์ต่าง ๆ ที่กำหนดฟอนต์และพิกัด—แล้วเทียบวิเคราะห์แบบขนาบกับผลลัพธ์ที่เรนเดอร์อยู่ข้างกัน มันต่างจากแนวทางที่โมเดล vision ประมวลผล PDF แบบ “มองดู” แล้วอ่านข้อความ เพราะสิ่งที่อยากได้จริง ๆ คือความเข้าใจลึก ๆ ว่าข้างใน PDF มีข้อมูลอะไรอยู่บ้าง แม้จะมีเครื่องมือบางตัว แต่ส่วนใหญ่แสดงได้แค่ระดับ object และไม่ได้ลงไปใน content stream ภายใน อยากได้สภาพแวดล้อมที่เอา source stream จริงของ PDF ตัวอย่างมาเทียบกับผลเรนเดอร์แบบเคียงข้างกันเหมือน HTML เพื่อดูว่าตรงไหนถูกแสดงอย่างไร
คิดว่าถ้าใช้ Mozilla PDF.js เพื่อเรนเดอร์ PDF เป็น DOM ก็น่าจะได้ประสบการณ์ที่ใกล้เคียงมาก ตัวอย่างเช่นโอเปอเรเตอร์อย่าง Tj หรือ TJ จะถูกแปลงเป็น <span> หรือกลุ่มของมัน น่าจะเพราะต้องรักษาความตรงกับเอกสารต้นฉบับ
แนะนำให้ลองใช้เครื่องมือ cpdf (ฉันเป็นคนทำเอง) โดยใช้ตัวเลือก
-output-jsonและ-output-json-parse-content-streamsของ cpdf เพื่อแปลง PDF เป็น JSON แล้วทดลองอะไรต่าง ๆ ได้ และก็แปลงจาก JSON กลับเป็น PDF ได้ด้วย เพียงแต่ยังไม่มีความโต้ตอบแบบเรียลไทม์ดูเหมือนคุณจะกำลังหาเครื่องมือฟรีหรือโอเพนซอร์ส แต่เมื่อก่อน Acrobat Pro เคยมีฟีเจอร์ที่ใกล้เคียงมากพอสมควร เพียงแต่มันเป็นการไล่ดู content tree มากกว่าจะ inspect หน้าโดยตรง และแสดงได้แค่ระดับ object/stream ไม่ได้ลงไปถึงคำสั่งแต่ละตัว
“การผสานระหว่างการที่โมเดล vision ‘มอง PDF เหมือนคน’ กับ ‘รู้ว่าข้างใน PDF มีข้อมูลอะไรจริง ๆ’ คือสิ่งที่พวกเรากำลังสร้างที่ Tensorlake (ฉันทำงานอยู่ที่นั่น) ไม่ใช่แค่อ่านข้อความ แต่เข้าใจตาราง รูปภาพ สมการ ลายมือ ฯลฯ จริง ๆ แล้วดึงข้อมูลออกมาเป็น markdown/JSON เพื่อใช้กับแอป AI, LLM และอื่น ๆ ได้” https://tensorlake.ai
แม้จะยังไม่ถึงระดับที่ต้องการทั้งหมด แต่ขอแนะนำโน้ตบุ๊กนี้ที่มี inspector สำหรับแสดงโอเปอเรชันวาดภาพต่าง ๆ ภายใน PDF แบบ ‘สด ๆ’ https://observablehq.com/@player1537/pdf-utilities
เคยโฟกัสปัญหานี้อยู่หลายปีที่ Apple แก่นสำคัญคือยอมรับว่า “ทั้งหมดเป็นเรื่องเรขาคณิต” และใช้อัลกอริทึมที่แยกความต่างของระยะห่างระหว่างคำกับระยะห่างระหว่างตัวอักษรด้วยการทำ clustering วิธีนี้ใช้ได้ผลกับ PDF ส่วนใหญ่ แต่พอดูใกล้ ๆ จะพบว่าความหลากหลายมีมากจนบางกรณีก็น่าผิดหวัง ถ้าจะทำใหม่ทุกวันนี้ ฉันคงตัด OCR ออกทั้งหมด ใช้ข้อมูลเชิงเรขาคณิตเป็นฐาน แต่ผสาน machine learning เข้าไป ถ้าสร้าง PDF จากข้อความที่รู้อยู่ล่วงหน้าแล้วนำมาใช้กับ machine learning ก็จะสร้างข้อมูลฝึกได้แบบอัตโนมัติด้วย (มีวิดีโองานนำเสนอของ Bertrand Serlet ใน WWDC 2009)
มองว่าไม่ใช่ปัญหาเดียวชื่อ ‘PDF to Text’ แต่จริง ๆ แบ่งได้เป็น 3 หมวด: (1) OCR ที่เชื่อถือได้ (เช่น สำหรับค้นหา หรือป้อนเข้า vector DB), (2) การดึงข้อมูลแบบมีโครงสร้าง (ดึงเฉพาะค่าที่ต้องการ), (3) การทำ pipeline เอกสารทั้งชุดให้เป็นอัตโนมัติ (เช่น mortgage automation) Marginalia เน้นข้อ (1) และทุกวันนี้ด้วย Gemini Flash เป็นต้น ทำให้ OCR มีต้นทุนต่ำลงและใช้ได้ทั่วไปมากขึ้น แต่ข้อ (2) และ (3) ยังยากกว่าเยอะ และการทำให้เป็นอัตโนมัติเต็มรูปแบบก็ยังต้องใช้แรงงานมนุษย์อีกมาก ทั้งการสร้าง dataset, ออกแบบ pipeline, ตรวจจับความไม่แน่นอนและให้คนเข้ามาแทรกแซง, fine-tuning ฯลฯ อนาคตอยู่ทางนี้ (ฉันทำบริษัทด้านประมวลผลเอกสารด้วย LLM) https://extend.ai
คิดว่าควรมีข้อ (4) ด้วย คือ OCR ที่เชื่อถือได้พร้อมการสกัดความหมายจากเอกสารหลายรูปแบบ เพื่อใช้ด้าน accessibility ด้วย ที่มันยากก็เพราะต่างจาก workflow ทั่วไป ตรงที่คาดเดาประเภทเอกสารของผู้ใช้ไม่ได้ ต้องดึงองค์ประกอบที่ไม่ใช่ข้อความด้วย เช่น ตาราง header/footer หมายเหตุ สมการ ฯลฯ ต้องลดความผิดพลาดให้ต่ำมากจนไม่ควรใช้ OCR เกินจำเป็น อาจมีกรณีที่ข้อความฝังอยู่กับสิ่งที่เรนเดอร์ไม่ตรงกัน (เช่น hidden text หรือการประกอบแบบผิดปกติ) มักรันในแอปโลคัลจึงใช้เซิร์ฟเวอร์ช่วยได้ยาก และยังต้องรองรับ Form ของเอกสารประเภท imprinter อีกด้วย ตอนนี้ยังไม่มีโซลูชันที่แก้ทั้งหมดนี้ได้ครบจริง
แม้จะมีคนบอกว่าใช้ VLM แล้วทำให้ OCR pipeline ง่ายขึ้น แต่ขอเตือนว่าในเอกสารซับซ้อนจริง ๆ มันยากมาก มันยอดเยี่ยมกับฉลากภาพธรรมดา ๆ และพอใช้ได้กับเอกสารง่ายมาก ๆ แต่พอเป็นเอกสารที่มีตาราง header บทสรุป ฯลฯ จะเกิดอาการหลอน (hallucinate) หนักมาก จนแทบใช้จริงไม่ได้เลย
ระหว่างแปลงเป็น Markdown ฉันก็เจอปัญหาหลากหลายอย่าง เช่น การตรวจจับ header ทุกวันนี้ OCR นั้นยอดเยี่ยมมาก แต่การรักษาโครงสร้างของเอกสารทั้งชุดให้คงอยู่ยากกว่ามาก ตอนนี้ผลที่ค่อนข้างใช้ได้มาจากการให้ LLM ผ่านหลายรอบเพื่อดึงโครงสร้าง และใส่ context รายหน้าเข้าไป
ทางออกที่ดีกว่าคือแนบเอกสารต้นฉบับที่แก้ไขได้ไว้ใน PDF เลย ซึ่ง LibreOffice ทำได้ง่าย โดยทั่วไปกินพื้นที่เพิ่มไม่มาก และช่วยให้เข้าใจความหมายของข้อความได้ชัดเจน ทั้งยังใช้งานได้ตามปกติกับ PDF reader เดิม
เวลาปัญหาคือการดึงข้อความจาก PDF ที่มีอยู่แล้ว ก็สงสัยว่าคำแนะนำเกี่ยวกับวิธีสร้าง PDF จะช่วยอะไรได้จริงแค่ไหน อยากรู้ว่าทางแก้แบบนี้จะเริ่มเห็นผลอย่างจริงจังเมื่อไร
มันก็จริง แต่จะมีความเสี่ยงที่เอกสารต้นฉบับกับ PDF ที่เรนเดอร์ออกมาจะมีเนื้อหาไม่ตรงกันเลย
เห็นด้วย แต่จะใช้ได้ก็ต่อเมื่อผลประโยชน์ของคนสร้าง PDF กับคนใช้ PDF ตรงกันเท่านั้น ในวงการ e-Discovery มีธรรมเนียมที่ทนายฝั่งตรงข้ามจงใจแปลงเอกสารเป็น PDF เพื่อให้ใช้งานยาก ผลคือ public defender ที่ทรัพยากรน้อยกว่าต้องใช้เวลาจัดการเอกสารมากขึ้นและเสียเปรียบจริง ๆ ถ้าจะป้องกันเรื่องนี้ คิดว่าควรมีกฎหมายบังคับให้ส่งข้อมูลบางประเภทในฟอร์แมตมาตรฐานที่เครื่องอ่านได้
ถ้าเข้าถึงเอกสารต้นฉบับได้ การแนบไว้ใน PDF ก็ยอดเยี่ยมมาก แต่ส่วนใหญ่แล้วเราไม่ได้มีอำนาจควบคุมแบบนั้น
ปัญหาจริงส่วนใหญ่คือ PDF แบบ legacy บริษัทเราก็มีเป็นพันไฟล์ และบางส่วนก็เป็นสแกนคุณภาพแย่ บางไฟล์มี Adobe OCR ฝังมาให้ แต่ส่วนใหญ่ไม่มีเลย
PDF ด้านล่างนี้จริง ๆ แล้วเป็นไฟล์
.txtแค่เปลี่ยนนามสกุลเป็น.pdfก็เปิดด้วย PDF viewer ได้ และยังแก้ด้วย text editor ได้โดยตรง เพื่อควบคุมสิ่งที่จะแสดงบนหน้าจอ ฟอนต์ ขนาดฟอนต์ ระยะบรรทัด จำนวนตัวอักษรต่อหน้า จำนวนบรรทัด ขนาดกระดาษ ฯลฯ ได้หลากหลาย (มีตัวอย่างข้อความ PDF จริงประกอบ)PDF สามารถฝังสตรีมแบบไบนารีได้ด้วย PDF ไม่ใช่ฟอร์แมตข้อความ แต่เป็นฟอร์แมตที่สร้างมาเพื่อ layout และกราฟิก แบบในตัวอย่างอาจแสดงทีละบรรทัดได้ แต่ในความเป็นจริงมันอาจแทนทีละตัวอักษร ทีละคำ หรือแม้แต่ไม่เรียงลำดับก็ได้
PDF ย่อมาจาก “Portable Document Format” มันเข้ารหัสเป็นไฟล์ 7-bit ASCII จึงมีความพกพาสูงระหว่างอุปกรณ์และระบบปฏิบัติการต่าง ๆ (อ้างอิง: ลิงก์เอกสารทางการของ Adobe)
ตัวอย่างนี้คือ ‘Hello World’ ของ PDF ส่วน PDF รุ่นใหม่ ๆ ส่วนใหญ่จะบีบอัด object (
obj) ด้วย deflate และจัดกลุ่ม object เหล่านั้นไว้ในสตรีม ทำให้ซับซ้อนขึ้นมาก จึงวิเคราะห์ด้วยการค้นหาอย่าง "6 0 Obj" ในข้อความธรรมดาได้ยากมากการดึงข้อความจาก PDF โดยเฉพาะข้อความที่มีโครงสร้าง ไม่ใช่เรื่องง่ายเลย ตารางใน HTML มักยังพอดึงออกมาได้ค่อนข้างง่าย แต่ PDF แค่ “ดูเหมือน” ตารางจากพิกัดของสิ่งที่เรนเดอร์ ทั้งที่จริงแล้วข้อความกับกราฟิกกระจัดกระจายอยู่ข้างใน ฉันเองก็ใช้วิธีแปลง PDF เป็น HTML ด้วย Poppler PDF utils ก่อน จากนั้นหาหัวตาราง แล้วดูคอลัมน์จากพิกัด x ของแต่ละค่าเพื่อดึงข้อมูลรายแถวออกมา แม้จะดูหยาบ ๆ แต่ให้ผลที่เชื่อถือได้กว่าการทำกับ txt ที่จัดแนว
เพราะหงุดหงิดที่ดึงข้อมูลจาก PDF ไม่ได้ง่ายเหมือนเว็บเพจที่ใช้ BeautifulSoup เลยลงมือสร้างไลบรารีที่มีอินเทอร์เฟซแบบนั้นขึ้นมาเอง (มีตัวอย่างรูปแบบ
page.find) เพราะแต่ละ PDF มีเคสประหลาดต่างกันราวนรก เลยกำลังรวบรวมทั้งเทคนิคการดึงข้อมูลและตัวอย่าง PDF แปลก ๆ มาใส่ในไลบรารี https://jsoma.github.io/natural-pdf/ , https://badpdfs.com/สักวันหนึ่งอยากดึงข้อมูลตารางจาก PDF เข้าไปในซอฟต์แวร์ประมวลผลข้อมูลของตัวเอง ใครรู้จักไลบรารีที่ใช้กับแอป C++ ได้ และฟรีหรือราคาถูกมาก ช่วยแนะนำที
มีเอกสารบางชุด (เช่นจากหน่วยงานรัฐ) ที่ข้อความที่พิมพ์ออกมาได้กับข้อความที่ดึงออกมาจริงนั้นคนละเรื่องกันเลย เคสแบบนี้มีอยู่เรื่อย ๆ
PDF โดยแก่นแล้วเป็นฟอร์แมตมาร์กอัป/XML แบบหนึ่ง PDF เดียวกันก็สร้างได้หลากหลายวิธีมาก ถ้าส่งออกจากเครื่องมือกราฟิกก็จะได้ PDF ที่กราฟิกกับข้อความปนกัน ถ้าส่งออกจากเวิร์ดโปรเซสเซอร์ก็จะได้ PDF ที่เน้นข้อความมากกว่า ผลลัพธ์มีหลายมิติขึ้นกับว่าแอปที่ใช้สร้างจัดการข้อมูลอย่างไร สำหรับยูทิลิตีสำเร็จรูป ก็มีผลิตภัณฑ์หลายตัวอย่าง cisdem ที่พอใช้ดึงข้อมูลแบบมีโครงสร้างได้ระดับหนึ่ง แต่สุดท้ายก็ต้องเลือกเครื่องมือให้เหมาะกับงาน
หนึ่งในตัวอย่างที่ฉันชอบคือ PDF ของงานวิจัยชิ้นนี้ (มีลิงก์แนบ) หน้าแรกมีครบทั้งข้อความสองคอลัมน์แบบมาตรฐาน, header ตรงกลาง, ข้อความที่แทรกระหว่างสองคอลัมน์, องค์ประกอบที่เปลี่ยนความยาวบรรทัดและการเยื้องหน้า header ของหน้าก็ยังต่างกันระหว่างหน้าคี่กับหน้าคู่ และกฎของ section header ก็ไม่สม่ำเสมอ ย่อหน้าก็ไม่ได้เยื้องทุกครั้งและระยะบรรทัดก็เปลี่ยนไปมา เป็นชุดรวมปัญหาหลากหลายแบบอย่างแท้จริง
ตอนที่ลองเขียน parser PDF แบบง่าย ๆ เอง เคยตกใจมากกับวิธีทำงานของฟอร์แมตนี้ เลยยิ่งสงสัยเสมอว่าทำไมมันถึงถูกใช้กับงานที่เน้นข้อความบ่อยขนาดนี้ เช่น ถ้าเป็น invoice ระบบดิจิทัลควรดึงข้อมูลได้ง่าย ขณะเดียวกันรูปแบบที่จัดวางแล้วก็ควรเหมาะกับคนอ่านด้วย จึงหวังว่าวงการเทคโนโลยีจะค่อย ๆ ย้ายไปสู่ฟอร์แมตที่ดีกว่า
การดึง ‘ข้อมูลที่ใช้ประโยชน์ได้’ จาก PDF คือสิ่งที่ Tensorlake ทำอยู่ (https://tensorlake.ai) เพราะ PDF ไม่ได้มีแค่ข้อความ แต่ยังมีตาราง รูปภาพ สมการ ลายมือ ข้อความขีดฆ่า และข้อมูลอีกหลายแบบ ในฐานะนักพัฒนา เราจึงต้องไม่ใช่แค่ “อ่าน” ข้อความ แต่ต้อง “เข้าใจ” มันด้วย (ขอเปิดเผยว่าเป็นพนักงาน)