การแปลง PDF เป็นข้อความเป็นปัญหาที่ยาก

 (marginalia.nu)
4 คะแนน โดย GN⁺ 2025-05-15 | 1 ความคิดเห็น | แชร์ทาง WhatsApp
  • แม้เสิร์ชเอนจินจะเพิ่มการ ทำดัชนี PDF แล้ว แต่การดึงข้อความเชิงโครงสร้างที่ใช้ค้นหาได้จาก PDF นั้นยุ่งยากกว่าการประมวลผล HTML มาก
  • PDF ใกล้เคียงกับ รูปแบบกราฟิกแบบอิงพิกัด มากกว่าเอกสารข้อความ จึงอาจวาง glyph ในสภาพที่หมุน ซ้อนทับกัน หรือลำดับสลับไปมาได้
  • PDFTextStripper ของ PDFBox เป็นจุดเริ่มต้นได้ แต่ยังคงรักษาโครงสร้างเชิงความหมายอย่างหัวข้อหรือย่อหน้าได้ไม่เพียงพอ ทำให้มีข้อจำกัดในการประเมินความเกี่ยวข้องสำหรับการค้นหา
  • หากต้องการแยกหัวข้อกับย่อหน้า ฮิวริสติกอย่าง สถิติขนาดฟอนต์รายหน้า และค่ามัธยฐานของระยะห่างบรรทัด มีประโยชน์กว่าการอิงทั้งเอกสาร
  • เพราะการดึงข้อความจาก PDF ให้สมบูรณ์แบบทำได้ยาก เป้าหมายที่เป็นจริงสำหรับเสิร์ชเอนจินคือ วิธีแก้ที่ดีพอ ซึ่งดึงโครงสร้างของหัวข้อ บทคัดย่อ และเนื้อหาได้อย่างเสถียร

ปัญหาที่เผยให้เห็นเมื่อเพิ่มการทำดัชนี PDF

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

เหตุผลที่ PDF ดึงข้อความได้ยาก

  • PDF ไม่ใช่รูปแบบข้อความทั่วไป แต่ใกล้เคียงกับ รูปแบบกราฟิก มากกว่า
  • การแทนข้อมูลภายในใกล้เคียงกับการวาง glyph ลงบนพิกัดบน “กระดาษ” มากกว่าประโยคหรือย่อหน้า
  • glyph อาจอยู่ในสภาพต่อไปนี้ได้
    • ถูกหมุน
    • ซ้อนทับกัน
    • ปรากฏไม่ตรงกับลำดับการอ่าน
    • มีข้อมูลเชิงความหมายที่แนบมาน้อยมาก
  • การที่โปรแกรมดู PDF หรือเบราว์เซอร์สามารถค้นหาด้วย ctrl+f ได้ จึงเป็นผลลัพธ์ที่น่าทึ่งพอสมควร
  • โมเดลแมชชีนเลิร์นนิงแบบอิงวิชันอาจเป็นแนวทางที่ดีในตอนนี้ แต่ไม่เหมาะกับสเกลการประมวลผล PDF หลายร้อย GB บนเซิร์ฟเวอร์เดี่ยวที่ไม่มี GPU

เริ่มจาก PDFBox ได้ แต่ยังไม่พอ

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

ฮิวริสติกสำหรับค้นหาหัวข้อ

  • วิธีตรวจหาหัวข้อที่ง่ายที่สุดคือการหา บรรทัดที่มีความหนาระดับ semibold ขึ้นไป และแยกออกจากข้อความอื่น
  • แต่ไม่ใช่หัวข้อทั้งหมดจะเป็นตัวหนา และเอกสารจำนวนมากใช้ ขนาดฟอนต์ เพื่อแยกหัวข้อ
  • เกณฑ์ขนาดฟอนต์แบบทั่วทั้งเอกสารมีความผันผวนตามเอกสาร
    • เอกสารหนึ่งอาจใช้เนื้อหา 10pt และหัวข้อ 16pt
    • อีกเอกสารหนึ่งอาจใช้เนื้อหา 14pt และหัวข้อ 20pt
  • สถิติรายหน้า อาจเหมาะกว่าการดูทั้งเอกสาร
    • หน้าแรกอาจเลือกใช้ฟอนต์แตกต่างจากหน้าที่เหลืออย่างมาก เพราะมีบทคัดย่อและรายชื่อผู้เขียน
    • ในเอกสารตัวอย่าง ชื่อเอกสารใช้ฟอนต์ขนาด 17 ส่วนหัวข้อถัด ๆ ไปใช้ฟอนต์ขนาด 14
  • โดยทั่วไปแต่ละหน้าจะมี ขนาดฟอนต์หลัก ที่สอดคล้องกับเนื้อหา
  • หากนำค่าสัมประสิทธิ์ประมาณ 20% ไปคูณกับค่ามัธยฐานของขนาดฟอนต์รายหน้า จะสามารถระบุหัวข้อได้ค่อนข้างเสถียร
  • ยังมีข้อยกเว้นอยู่ แต่สามารถจับกรณีสำคัญส่วนใหญ่ได้

รวมหัวข้อหลายบรรทัดให้เป็นหนึ่งเดียว

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

กับดักที่ระยะห่างบรรทัดสร้างขึ้นในการระบุย่อหน้า

  • PDFTextStripper ทำ การระบุย่อหน้า ได้ค่อนข้างดี
  • มันพิจารณาระยะห่างบรรทัดร่วมกับการย่อหน้า เพื่อ判断ตำแหน่งที่จะแบ่งย่อหน้า
  • ยังมีช่องให้ปรับปรุง โดยเฉพาะใน ตรรกะของระยะห่างบรรทัด
  • ปัญหาใหญ่ของ PDFTextStripper คือใช้เกณฑ์คงที่ในการแยกบรรทัด
    • หากระยะห่างบรรทัดมากกว่าเกณฑ์ จะตัดสินว่าไม่ใช่ย่อหน้าเดียวกัน
    • ไม่ได้สะท้อนอย่างเพียงพอว่าแต่ละเอกสารมีระยะห่างบรรทัดแตกต่างกัน
  • ในร่างบทความวิชาการและ preprint มักพบ ระยะห่างบรรทัด 1.5~2 เท่า ค่อนข้างบ่อย
  • หากตั้งค่าเกณฑ์สูงเกินไป หัวข้อบางส่วนอาจถูกดูดเข้าไปในย่อหน้าเนื้อหา และขัดขวางการระบุหัวข้อได้

ปรับแก้ด้วยสถิติระยะห่างบรรทัด

  • คล้ายกับการจัดการขนาดฟอนต์ สามารถนำ เทคนิคเชิงสถิติ มาใช้กับระยะห่างระหว่างบรรทัดได้
  • เมื่อสร้างฮิสโตแกรมของระยะห่างระหว่างบรรทัดในหน้าข้อความ มักมี outlier ขนาดใหญ่ปรากฏ
  • ค่าเฉลี่ยมีแนวโน้มถูก outlier ทำให้แกว่งง่าย แต่ ค่ามัธยฐาน อาจตรงกับระยะห่างบรรทัดที่ใช้ในเนื้อหาได้อย่างแม่นยำ
  • หากคูณค่ามัธยฐานด้วยค่าสัมประสิทธิ์หนึ่ง ก็สามารถสร้างฮิวริสติกการแยกย่อหน้าที่ทนต่อระยะห่างบรรทัดหลากหลายรูปแบบได้

เป้าหมายที่เป็นจริงคือความเสถียรมากกว่าความสมบูรณ์แบบ

  • งานดึงข้อความจาก PDF นั้นยากที่จะทำให้สมบูรณ์แบบ
  • ตัวรูปแบบ PDF เองไม่ได้ถูกออกแบบมาเพื่อภารกิจเช่นนั้น และเมื่อต้องเลือกวิธีแก้ที่ “ดีพอ” ก็จะเกิด trade-off หลายอย่าง
  • เสิร์ชเอนจินสนใจข้อมูลต่อไปนี้เป็นพิเศษ
    • สัญญาณความเกี่ยวข้องอย่างหัวข้อ
    • การระบุบทคัดย่อ
    • โครงสร้างของข้อความที่เหลือซึ่งสม่ำเสมอในระดับหนึ่ง
  • หากเป็นเป้าหมายเหล่านี้ ก็สามารถเข้าใกล้วิธีแก้ที่ประมวลผลเอกสารที่เกี่ยวข้องส่วนใหญ่ได้โดยไม่ฝืนมากนัก

ข้อความตัวอย่างที่ใช้

  • 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 ความคิดเห็น

 
GN⁺ 2025-05-15
ความคิดเห็นจาก Hacker News

  • บางครั้งเคยเจาะลึกเรื่องอะไรอยู่หลายเดือนหรือหลายปีจนถึงระดับผู้เชี่ยวชาญ แล้วลืมไปสนิท ก่อนมารู้สึกทีหลังว่า “อันนี้ใหม่และน่าสนใจดีนะ”
    ทั้งที่เคยทำเรื่องน่าสนใจไว้ค่อนข้างเยอะ แต่มันหายไปจากความทรงจำ จนกว่าจะมีอะไรบางอย่างมากระตุ้น ก็รู้สึกเหมือนเป็นคนที่เริ่มชีวิตใหม่
    จำได้ราง ๆ ว่าเมื่อประมาณ 6–7 ปีก่อนเคยทำงานที่ค่อนข้างเจ๋งเกี่ยวกับ PDF และ OCR และพอลองค้นดูก็น่าจะเป็น Tesseract

    • ราวปี 2006 ผมเคยขุดหาสาเหตุที่อุปกรณ์อ่านอีบุ๊กยุคแรกชื่อ iRex คัดลอกข้อความจากบทความวิทยาศาสตร์แบบหลายคอลัมน์ไม่ได้ และพอรู้ว่า PDF reader ใช้ Poppler อยู่ภายใน จึงแก้ Poppler ให้อนุมานลำดับการอ่านของเอกสารหลายคอลัมน์ โดยอ้างอิงอัลกอริทึม OCR ที่ Thomas Breuel ผู้เขียน Tesseract เคยนำเสนอไว้
      มันเป็นการแฮ็กที่ใกล้เคียงกับ heuristic และ API เก่า ๆ ของ Poppler ในตอนนั้นก็ดูเหมือนไม่ได้แสดง text run ในแบบที่เหมาะกับ accessibility API
      ฟีเจอร์เลือกข้อความหลายคอลัมน์ถูกใส่เข้าไปได้ในระดับหนึ่ง แต่ข้อเสนอปรับปรุงประสิทธิภาพหลังจากนั้นโน้มน้าว maintainer ได้ยาก เพราะ heuristic ต่างกันเล็กน้อย ทำให้ผลลัพธ์การเลือกข้อความเปลี่ยนไปในบางสถานการณ์
      ตั้งแต่แรกก็ไม่มี “คำตอบที่ถูกต้อง” เพียงคำตอบเดียวอยู่แล้ว ดังนั้นการเรียกร้องให้ผลลัพธ์ตรงกันจึงไม่สมเหตุสมผล และนั่นทำให้ การเลือกข้อความหลายคอลัมน์ของ kpdf เกิดขึ้นมาพอสมควร
      ทุกวันนี้สำหรับงานแบบนี้ การใช้ Tesseract โดยตรงอาจสมเหตุสมผลกว่า
    • เวลาคนทำงานระดับหลายสิบปี ที่ถูกเผาทิ้งร่วมกันเพราะฟอร์แมตนี้ ไม่มีทางเอากลับคืนมาได้เลย
      ไม่รู้ว่าความบ้าคลั่งนี้จะจบลงเมื่อไร
    • Tesseract เคยเป็น OCR โอเพนซอร์สที่ดีที่สุดมาเป็นเวลานาน แต่ตอนนี้ผมมองว่า docTR ดีกว่า
      ความแม่นยำเริ่มต้นสูงกว่า รองรับ GPU acceleration และทำ pipeline ที่ผสมโครงสร้างโมเดลตรวจจับและรู้จำข้อความหลายแบบได้
      สามารถเทรนหรือ fine-tune ด้วย PyTorch หรือ TensorFlow เพื่อดันประสิทธิภาพในโดเมนเฉพาะให้สูงขึ้นได้ด้วย
    • เคยมีคนถามเรื่อง C++ แล้วผมตอบไปว่า “ไม่เคยทำงานจริงจังด้วย C++” ก่อนจะนึกขึ้นได้ว่าเมื่อราว 20 ปีก่อนผมเคยเขียนโค้ดไคลเอนต์เมสเซนเจอร์ส่วนตัวที่มีคนใช้หลายพันคนด้วย Borland C++
      เพราะฉะนั้นเรื่องแบบนี้เกิดขึ้นจริง
    • ทุกครั้งที่จบโปรเจกต์ มักรู้สึกว่า “ตอนนี้กลายเป็นผู้เชี่ยวชาญในการทำสิ่งนี้แล้วนะ แต่ก็คงจะไม่ได้ทำอีกแล้วละ”
      งานถัดไปเป็นคนละสาขาโดยสิ้นเชิง เลยต้องเริ่มจากพื้นฐานใหม่อีกครั้ง

  • อยากให้มีใครทำเครื่องมือสำหรับ PDF แบบเดียวกับ browser developer tools
    อยากให้ดู content stream ของ PDF เป็นซอร์สได้เหมือน “Inspect element” และตรวจสอบได้ว่า text operator อย่าง BT … ET หรือ text placement operator อย่าง Tj ระบุและสร้างพิกเซลแต่ละจุดอย่างไร
    มันตรงข้ามกับกระแสตอนนี้ที่ใช้โมเดลด้านภาพ “ดู” และอ่าน PDF เหมือนมนุษย์ แต่ถ้าเข้าใจได้ว่าจริง ๆ แล้วในไฟล์ PDF มีอะไรอยู่ข้างใน จะดีกว่ามาก
    มีเครื่องมือตรวจสอบเนื้อหา PDF อยู่บ้าง(https://news.ycombinator.com/item?id=41379101) แต่หยุดอยู่ที่ระดับอ็อบเจ็กต์ของ PDF ทำให้ content stream ทั้งหมดถูกมองเป็นอ็อบเจ็กต์เดียว
    ตัวอย่างเช่น หน้า PDF หมายเลข 8 หรือหน้าที่ 6 ของ https://bfi.uchicago.edu/wp-content/uploads/2022/06/BFI_WP_2... ที่กล่าวถึงในบทความ วางข้อความด้วย operator อย่าง BT, การตั้งค่าฟอนต์, Td, TJ
    ถ้าสามารถดู “ซอร์ส” แบบนี้คู่กับ PDF ที่เรนเดอร์แล้วแบบวางข้างกัน และเมื่อเอาเมาส์ชี้ฝั่งหนึ่ง อีกฝั่งก็ไฮไลต์บริเวณที่สอดคล้องกันได้ ก็น่าจะดีบักได้เหมือนหน้า HTML

    • ถ้าเรนเดอร์ PDF เป็น DOM ด้วย PDF.js ของ Mozilla ก็น่าจะได้ผลลัพธ์ที่ใกล้เคียงมาก
      เช่น Tj แต่ละตัวอาจกลายเป็น DOM element หนึ่งตัว และ TJ อาจเป็นกลุ่มของหลาย element
      เพราะต้องสะท้อนเอกสารต้นฉบับให้ถูกต้องถึงจะทำงานได้ จึงมีแนวโน้มจะแปลงได้ค่อนข้างซื่อตรง
    • ใช้ cpdf ทำได้ในระดับหนึ่ง
      สร้าง JSON ด้วย cpdf -output-json -output-json-parse-content-streams in.pdf -o out.json แล้วแก้ JSON นั้น จากนั้นแปลงกลับเป็น PDF ด้วย cpdf -j out.json -o out.pdf ได้
      เพียงแต่ไม่มีการเชื่อมโยงสองทางแบบเรียลไทม์
    • คงหมายถึงโอเพนซอร์สหรือของฟรี แต่ Acrobat Pro ที่เคยใช้เมื่อหลายปีก่อนก็มีฟีเจอร์เกือบคล้ายกัน
      เพียงแต่ไม่ใช่วิธีตรวจสอบหน้าเอกสาร แต่เป็นการไล่ดู content tree และมันจะไฮไลต์อ็อบเจ็กต์บนหน้าให้
      ยังไม่ถึงระดับคำสั่ง ทำได้แค่ระดับอ็อบเจ็กต์หรือ stream เท่านั้น
    • โน้ตบุ๊กนี้อาจไม่ใช่สิ่งที่ต้องการตรง ๆ แต่มีฟีเจอร์สำหรับตรวจสอบ drawing operations หลายอย่างใน PDF แบบ “เรียลไทม์”
      https://observablehq.com/@player1537/pdf-utilities
    • สิ่งที่ Tensorlake กำลังทำก็ใกล้เคียงกับชุดผสมนี้
      ไม่ใช่แค่ “ดู” PDF เหมือนมนุษย์แล้วอ่านข้อความเท่านั้น แต่เป็นแนวทางที่พยายาม เข้าใจ เนื้อหาซึ่งรวมถึงตาราง รูปภาพ ข้อความ สมการ และลายมือ
      ดังนั้นจึง parse PDF และรันหลายโมเดลเพื่อดึงชิ้นส่วน Markdown หรือ JSON ออกมา ทำให้สามารถป้อนข้อมูลจริงเข้าไปใน AI agent, LLM และแอปพลิเคชันอื่น ๆ ได้
      https://tensorlake.ai

  • “PDF เป็นข้อความ” เป็นคำอธิบายที่ทำให้เรียบง่ายเกินไป
    ภายในหมวดนี้มี 1) OCR ที่เชื่อถือได้สำหรับทำดัชนีค้นหาหรือป้อนเข้า vector DB, 2) การสกัดข้อมูลแบบมีโครงสร้าง เพื่อดึงค่าบางอย่างออกมา, 3) ไปป์ไลน์เอกสารแบบครบวงจร เช่น การทำระบบอัตโนมัติสำหรับใบสมัครจำนอง
    สิ่งที่ Marginalia ต้องแก้คือ OCR ในข้อ 1 และมันกำลังกลายเป็นของใช้งานทั่วไปอย่างรวดเร็วด้วยโมเดลอย่าง Gemini Flash
    ผมเห็นหลายบริษัทแทนที่ไปป์ไลน์ OCR เดิมด้วย Flash แล้วลดต้นทุนได้มาก ซึ่งค่อนข้างน่าทึ่ง
    แต่ข้อ 2 และ 3 ยากกว่ามาก และยังมีช่องว่างใหญ่อยู่ระหว่างเอาต์พุต OCR ดิบกับไปป์ไลน์เอกสารที่เป็น mission-critical ในสภาพแวดล้อมใช้งานจริง
    LLM และโมเดล vision-language ไม่ใช่เวทมนตร์ และถ้าคาดหวังระบบอัตโนมัติ 100% ก็จะต้องประหลาดใจ
    ยังต้องมีการสร้างและติดป้ายกำกับชุดข้อมูล, การออร์เคสเตรตไปป์ไลน์ จำแนก -> แบ่งส่วน -> สกัด, การตรวจจับความไม่แน่นอนและให้มนุษย์ตรวจทาน, การ fine-tuning ฯลฯ
    ในระยะยาวอาจเข้าใกล้การทำงานอัตโนมัติเกือบสมบูรณ์ได้ แต่ต้องใช้เวลาและความพยายาม และดูชัดเจนว่าอนาคตกำลังไปในทิศทางนี้
    เกี่ยวกับเรื่องนี้ ผมได้เริ่มบริษัทประมวลผลเอกสารด้วย LLM ชื่อ https://extend.ai

    • จากมุมมองด้านการเข้าถึง ยังต้องมีข้อ 4 คือ OCR และการสกัดความหมายที่เชื่อถือได้ ซึ่งทำงานได้กับเอกสารหลากหลายประเภท
      เวิร์กโฟลว์ธุรกิจมักจัดการกับเอกสารที่กำหนดไว้ไม่กี่แบบ แต่ตัวอ่าน PDF ทั่วไปไม่รู้ว่าผู้ใช้จะเปิดเอกสารอะไร
      ต้องรู้จำไม่ใช่แค่ข้อความ แต่รวมถึงตาราง หัวกระดาษ·ท้ายกระดาษ เชิงอรรถ ชื่อเรื่อง สมการคณิตศาสตร์ ฯลฯ
      เนื่องจากเป็นสิ่งที่มนุษย์ใช้บริโภค จึงต้องลดข้อผิดพลาดให้น้อยที่สุด จึงไม่ควรใช้ OCR เมื่อไม่จำเป็น และต้องใช้ข้อความพื้นฐานที่ฝังอยู่ใน PDF พร้อมกับสกัดโครงสร้างเชิงความหมายด้วย
      สุดท้ายแล้วจึงต้องมีสองเส้นทาง: สำหรับ PDF ที่เป็นรูปภาพล้วน และสำหรับ PDF ที่ดึงข้อมูลจาก content stream ได้
      แต่ใน content stream อาจมีข้อความที่ต่างจากสิ่งที่แสดงจริงบนหน้าจอ เช่น ข้อมูลที่ซ่อนด้วยตัวอักษรสีขาว หรือการทำแบบ LaTeX ที่วาดเครื่องหมาย accent ด้วยคำสั่งแทนที่จะใช้อักขระ Unicode accent
      โดยปกติมันทำงานเป็นแอปในเครื่องบนอุปกรณ์ประสิทธิภาพต่ำของผู้ใช้ และมีโอกาสสูงที่จะไม่มีเซิร์ฟเวอร์หรือโมเดลสมัครสมาชิก จึงใช้โมเดล AI บนคลาวด์ไม่ได้
      ผู้ใช้ซอฟต์แวร์เพื่อการเข้าถึงอาจพิมพ์ออกมาแล้วเขียนด้วยปากกาได้ยาก ดังนั้นจึงต้องจัดการไม่เพียงแบบฟอร์มที่สะอาดตรงตามสเปก แต่รวมถึงแบบฟอร์มสำหรับพิมพ์ด้วย
      นี่ยังเป็นปัญหาเปิดที่ยังไม่ใกล้จะถูกแก้เลย และวิธีแก้ปัจจุบันทั้งหมดล้วนขาดตกบกพร่องในบางทาง ยังไม่มีวิธีเดียวที่แก้ทั้ง 5 อย่างข้างต้นได้ดีทั้งหมด
    • จากจุดยืนของคนที่ต้องสร้างเครื่องมือเองเพราะโมเดล vision-language ไม่นิ่งเกินไป บริษัทที่ใช้ VLM กับภาพที่ยังไม่ได้ประมวลผลมีแนวโน้มจะเจอความเจ็บปวดมาก
      มันทำ image labeling ได้ดีมาก และใช้ได้กับเอกสารง่าย ๆ เช่น ข้อความคอลัมน์เดียว หัวข้อขั้นตอนเดียวที่จัดกึ่งกลาง หรือมีรูปภาพหรือตารางหนึ่งรายการต่อหน้า
      เดโม MVP ส่วนใหญ่ก็แสดงตัวอย่างแบบนี้
      แต่สำหรับเอกสารซับซ้อนที่มีตารางและรูปภาพปะปนกัน ดูเหมือนว่ายังต้องมีพารามิเตอร์มากกว่านี้อีกมากถึงจะได้แค่ระดับ “แย่”
      ตอนนี้ hallucination รุนแรงเกินไปจนแม้แต่ตารางง่าย ๆ ที่มีหัวเรื่องด้านบน ข้อมูลอยู่ตรงกลาง และสรุปอยู่ด้านล่าง ก็ยังนำไปใช้ตรง ๆ ได้ยาก
    • ผมกำลังปรับแก้ต่อเนื่องเพื่อประมวลผล PDF เป็น Markdown และก็ชนกับ การตรวจจับ header กับปัญหาอีกหลายอย่างเหมือนบทความต้นฉบับ
      OCR สมัยนี้ยอดเยี่ยม แต่การรักษาโครงสร้างภาพรวมของเอกสารนั้นยุ่งยากกว่ามาก
      การได้ HTML ที่สม่ำเสมอจากเอกสารขนาดใหญ่ยังดูห่างไกล และถ้าให้ LLM ผ่านหลายรอบเพื่อสกัดโครงสร้างเอกสาร แล้วใส่เป็นบริบทให้การสกัดรายหน้า Markdown ก็ให้ผลลัพธ์ที่ค่อนข้างใช้ได้

  • Apple เคยจัดการปัญหานี้ได้ค่อนข้างสำเร็จมาหลายปี โดยเคล็ดลับหลักคือรับทุกอย่างเป็น โครงสร้างเชิงเรขาคณิต และพยายามแยกระยะห่างระหว่างคำกับระยะห่างระหว่างตัวอักษรด้วยการวิเคราะห์คลัสเตอร์
    มันทำงานได้ดีมากกับ PDF จำนวนมาก แต่ชนิดของ PDF หลากหลายเกินไป จึงมีกรณีที่ผลลัพธ์ไม่ดีอยู่เสมอ
    ถ้าทำใหม่ตอนนี้ ผมคิดว่าจะคงโครงสร้างเชิงเรขาคณิตไว้และหลีกเลี่ยง OCR โดยสิ้นเชิง แต่ใช้ แมชชีนเลิร์นนิง
    ข้อดีใหญ่ของแมชชีนเลิร์นนิงคือสามารถใช้เครื่องมือเดิมที่สร้าง PDF จากข้อความที่รู้อยู่แล้ว เพื่อทำให้ขั้นตอนการฝึกเป็นอัตโนมัติทั้งหมดได้
    ฉากที่ Bertrand Serlet ประกาศฟีเจอร์นี้ใน WWDC 2009: https://youtu.be/FTfChHwGFf0?si=wNCfI9wZj1aj9rY7&t=308

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

    • พูดถูก แต่ผลประโยชน์ของผู้สร้าง PDF กับผู้บริโภคต้องสอดคล้องกัน
      ในวงการ e-discovery ผู้ให้หลักฐานมักตั้งใจ dump เป็น PDF เพื่อให้ทนายฝ่ายตรงข้ามบริโภคเนื้อหาได้ยากขึ้น
      ถ้าทั้งสองฝ่ายมีเงินมากก็ไม่ใช่อุปสรรค แต่ยกตัวอย่างเช่น ทนายความที่รัฐแต่งตั้งไม่มีเงินจ้างคนมาประมวลผล PDF ให้อยู่ในรูปแบบที่อ่านง่าย ทำให้เวลาประมวลผลยาวนานขึ้นมาก และเพิ่มภาระทางจิตใจให้จำเลย
      ถึงขั้นอาจประมวลผลข้อมูลได้ไม่ถูกต้องด้วยซ้ำ
      วิธีแก้คือทำให้พฤติกรรมแบบนี้ผิดกฎหมาย
      เช่น ข้อมูลการดักฟังควรถูกส่งมอบใน รูปแบบที่เครื่องอ่านได้ ซึ่งเป็นมาตรฐาน และไม่มีเหตุผลทางจริยธรรมใดที่แรงเสียดทานทางเทคนิคเล็ก ๆ จะส่งผลต่อผลลัพธ์ของกระบวนการอาญา
    • เป็นเรื่องแปลกที่วิธีแก้ที่ดีกว่าสำหรับปัญหาของเสิร์ชเอนจินที่ต้องสกัดข้อความจาก PDF เดิม กลับเป็นคำแนะนำเรื่องวิธีสร้าง PDF
      น่าสงสัยว่าต้องใช้เวลานานแค่ไหนกว่าวิธีนี้จะเกิดผล
    • ถูกต้อง แต่ก็ทำให้เกิด ช่องโหว่ ที่เอกสารต้นฉบับอาจแตกต่างจากเนื้อหา PDF ที่เรนเดอร์ออกมาได้ตามใจ
    • ผมคิดว่า 90% ของพื้นที่ปัญหานี้น่าจะเป็น PDF เก่า (legacy PDF)
      ที่บริษัทก็มีไฟล์แบบนี้หลายพันไฟล์ บางส่วนเป็นสแกนคุณภาพแย่ บางส่วนมี Adobe OCR ฝังอยู่ แต่ส่วนใหญ่ไม่มีอะไรเลย
    • ถ้าเข้าถึงเอกสารต้นฉบับที่ใช้สร้าง PDF ได้ ก็เป็นวิธีที่ดี
      แต่โดยทั่วไปแล้วเราไม่มีอำนาจควบคุมแบบนั้น

  • PDF ด้านล่างนี้จริง ๆ แล้วเป็นไฟล์ .txt
    ถ้าบันทึกด้วยนามสกุล .pdf ก็จะเปิดได้ในโปรแกรมดู PDF และยังแก้ไขด้วยโปรแกรมแก้ไขข้อความได้ด้วย
    เช่น แก้ไขไฟล์ข้อความนี้แล้วเปลี่ยนข้อความที่แสดงบนหน้าจอเมื่อเปิด PDF, ฟอนต์, ขนาดตัวอักษร, ระยะห่างบรรทัด, จำนวนอักขระสูงสุดต่อบรรทัด, จำนวนบรรทัดต่อหน้า, ความกว้างและความสูงของกระดาษ รวมถึงแนวตั้ง/แนวนอนได้
    ตัวอย่างนี้เป็นโครงสร้าง PDF ขั้นต่ำที่เริ่มด้วย %PDF-1.4 โดยเขียน Catalog, Pages, Font, Page, Contents, xref, trailer ฯลฯ เป็นข้อความโดยตรง

    • ใน PDF อาจมี ไบนารีสตรีม ที่ฝังอยู่ด้วย
      PDF ไม่ได้ถูกสร้างมาเพื่อข้อความ แต่ถูกสร้างมาเพื่อเลย์เอาต์และกราฟิก
      ตัวอย่างนี้ดี แต่แต่ละบรรทัดอาจถูกแยกเป็นหนึ่งคำสั่งต่อหนึ่งอักขระ หรือหนึ่งคำสั่งต่อหนึ่งคำ และลำดับก็อาจสลับปนกันได้
    • “PDF” ย่อมาจาก “Portable Document Format”
      ในหัวข้อ “2.3.2 Portability” ของเอกสารอ้างอิง PDF 1.0 อธิบายไฟล์ PDF ว่าเป็นไฟล์ ASCII แบบ 7 บิต และระบุว่าแม้แต่เอกสารที่มีรูปภาพและอักขระพิเศษก็อธิบายโดยใช้เฉพาะส่วนย่อยของ ASCII ที่พิมพ์ออกมาได้
      จึงอธิบายว่าเป็นผลให้มีความพกพาได้สูงมากในสภาพแวดล้อมฮาร์ดแวร์และระบบปฏิบัติการที่หลากหลาย
      https://opensource.adobe.com/dc-acrobat-sdk-docs/pdfstandard...
    • นี่ใกล้เคียงกับ Hello World ของ PDF
      PDF ส่วนใหญ่ในปัจจุบันวัตถุทั้งหมดถูกบีบอัดด้วย deflate
      ยิ่งไปกว่านั้น เพื่อให้ตามรอยได้ยากขึ้น PDF จำนวนมากจะรวมวัตถุส่วนใหญ่ไว้ในวัตถุชนิด object stream แล้วบีบอัดอีกครั้ง
      ดังนั้นแม้จะพยายามตามหาจุดจบของ 6 0 R ก็ไม่สามารถค้นหา 6 0 Obj ในโปรแกรมแก้ไขข้อความได้

  • มีเอกสารที่ผมชอบซึ่งแสดงให้เห็นความยากที่อธิบายในบทความนี้: https://academic.oup.com/auk/article/126/4/717/5148354
    ตั้งแต่หน้าแรกก็มีข้อความแบบสองคอลัมน์ตามมาตรฐาน ชื่อเรื่องจัดกึ่งกลาง และมีกล่องข้อความแทรกอยู่ระหว่างสองคอลัมน์ ทำให้ความยาวบรรทัดและการเยื้องเปลี่ยนไป
    หลังจากนั้นยังมีหัวกระดาษที่เปลี่ยนไปตามหน้าคี่/หน้าคู่ และกฎของหัวข้อหมวดที่ต่างกันมาก
    ที่แย่กว่านั้นคือไม่มีระยะห่างเพิ่มระหว่างย่อหน้า และไม่ได้มีการเยื้องบรรทัดแรกเสมอไป จึงรวมความยุ่งยากสารพัดอย่างไว้ครบ

    • API PDF ของ CoreGraphics บน MacOS โดยพื้นฐานแล้วเคยส่งคืนข้อความรายหน้าให้ตามลำดับที่ถูกเข้ารหัสไว้ในพจนานุกรม
      ประมาณ 95% ก็ถือว่าใช้ได้ค่อนข้างดี และสำหรับ PDFKit กับ Preview บน Mac นั่นก็เพียงพอมาหลายปี
      ถ้านึกถึงแอปต้นทางที่สร้าง PDF เช่น โปรแกรมประมวลผลคำ ก็มีความเป็นไปได้สูงว่ามันเรนเดอร์ข้อความจากบัฟเฟอร์ข้อความของตัวเองไปยัง PDF context ในลำดับที่ค่อนข้างสมเหตุสมผล
      ดังนั้นแม้เป็นเอกสารสองคอลัมน์ ข้อความก็มักไหลจากคอลัมน์ซ้ายไปคอลัมน์ขวาได้ถูกต้อง และภายใน PDF ก็อยู่ในลำดับที่ถูกต้องอยู่แล้ว
      แต่สำหรับท้ายกระดาษหรือหัวกระดาษ เราไม่อาจรู้ได้ว่าแอปที่สร้าง PDF เทลงใน context ตามลำดับใด

  • การดึงข้อความจาก PDF แม้กระทั่งข้อความที่มีโครงสร้าง ไม่ใช่เรื่องง่ายเลย
    การ scrape ตารางจากเอกสาร HTML มักจะค่อนข้างตรงไปตรงมา แม้ไซต์จะใช้ antipattern ที่ทำทุกอย่างเป็น div และจะยิ่งง่ายขึ้นถ้าใช้องค์ประกอบที่มีความหมาย
    แต่ PDF ไม่เป็นแบบนั้น
    ผมไม่ใช่ผู้เชี่ยวชาญด้านฟอร์แมต จึงไม่รู้ว่ามีการรองรับโครงสร้างเชิงความหมายมากแค่ไหน แต่เคยเห็น PDF จำนวนมากที่สร้างตารางจากชุดองค์ประกอบกราฟิกและข้อความแบบหลวม ๆ ซึ่งดูเป็นตารางก็ต่อเมื่อเรนเดอร์แล้วเท่านั้น
    ในทางปฏิบัติ ผมประสบความสำเร็จพอสมควรในการดึงข้อมูลตาราง โดยใช้ยูทิลิตี้ Poppler PDF แปลง PDF เป็น HTML จากนั้นค้นหาหัวตารางที่คาดไว้ แล้วคำนวณคอลัมน์จาก พิกัด x ของแต่ละค่าเพื่อดึงค่ารายแถว
    เป็นวิธีที่เลอะเทอะ แต่ทำงานได้เสถียรสำหรับงานที่ต้องใช้ และดีกว่าข้อความธรรมดาที่มีรูปแบบซึ่งระยะห่างไม่สม่ำเสมอหรือมีการขึ้นบรรทัดใหม่แทรกกลางแถวมาก

    • เพราะหงุดหงิดที่ไม่สามารถดึงข้อมูลจาก PDF ได้เหมือนใช้ BeautifulSoup กับเว็บเพจ จึงสร้างไลบรารีที่ทำอะไรคล้าย ๆ กันได้ในระดับหนึ่ง
      มีฟีเจอร์จิปาถะอีกหลายอย่าง แต่เป้าหมายหลักคือการโต้ตอบในแบบที่ เป็นมนุษย์มากขึ้น เช่น page.find('text:bold:contains("Summary").below().extract_text()
      PDF แต่ละไฟล์เป็นฝันร้ายที่ต้องปรับเฉพาะ จึงกำลังรวบรวมตัวอย่างที่ดึงข้อมูลยาก เพื่อใช้เป็นฐานของไลบรารีเชิงวิธีการ
      https://jsoma.github.io/natural-pdf/
      https://badpdfs.com/
    • ในบรรดาเอกสารทางการของรัฐบาล ผมชอบกรณีที่ข้อความที่เรนเดอร์ออกมากับข้อความที่ได้เมื่อดึงด้วยวิธีทั่วไปแตกต่างกันโดยสิ้นเชิงที่สุด
    • หวังว่าสักวันซอฟต์แวร์จัดระเบียบข้อมูลของผมจะสามารถทำ การดึงข้อมูลตาราง จาก PDF ได้
      ถ้าใครรู้จักไลบรารีดึงตารางจาก PDF ที่ผสานเข้ากับแอป C++ ได้ และฟรีหรือราคาต่ำกว่าสองสามร้อยดอลลาร์ ช่วยบอกด้วย
    • PDF โดยแก่นแล้วเป็นรูปแบบมาร์กอัป/XML และมาตรฐานก็เปิดเผยให้เรียนรู้ได้
      วิธีสร้าง PDF เดียวกันมีมากมายจริง ๆ
      เครื่องมือบางตัวใกล้เคียงกับการส่งออกเลย์เอาต์ที่มีข้อความและกราฟิกจากโปรแกรมแก้ไขกราฟิก ขณะที่เครื่องมืออื่นใกล้เคียงกับการส่งออกข้อความและกราฟิกที่เริ่มจากคำก่อนแบบโปรแกรมประมวลผลคำ
      มุมมองของแอปที่สร้างต่อการจัดการข้อมูลมักส่งผลต่อวิธีส่งออก PDF ด้วย
      ถ้ากำลังมองหายูทิลิตี้สำเร็จรูป เครื่องมืออย่าง cisdem ถือว่าแก้ปัญหาไปได้ถึงระดับที่ดึงข้อมูลเชิงโครงสร้างให้ผู้ใช้ในเครื่องได้ค่อนข้างดี
      เครื่องมือแบบนี้มีอยู่มาก และหลายตัวก็สัญญาว่ารองรับข้อมูลเชิงโครงสร้าง แต่ต้องเหมาะกับงานที่ต้องการทำด้วย

  • PDF คือ รูปแบบสำหรับการแสดงผล
    มันถูกปรับให้เหมาะกับสายตามนุษย์และเครื่องพิมพ์ และฟีเจอร์ก็เพิ่มขึ้นเรื่อย ๆ
    ในฐานะวิธีส่งข้อมูลระหว่างเครื่อง มันแย่มาก แต่สำหรับให้คนอ่านหรือเก็บหน้า A4 หนึ่งหน้าไว้ ถือว่าดีมาก
    ถ้าเริ่มจากสมมติฐานว่า .pdf เก็บข้อความไว้ ดังนั้นสิ่งที่ต้องการก็คือข้อความนั้น ก็เหมือนกับบอกให้ไปเพิ่มขนาดดวงตาเอาเอง
    ไม่อย่างนั้นก็ต้องจัดการกับสิ่งที่ซับซ้อนมาก
    ก่อนอื่น ปัญหาอยู่ที่ว่าข้อความนั้นเป็นข้อความจริง ๆ หรือเป็นรูปภาพ
    สายตามนุษย์แค่สวมแว่นใหม่ก็อ่านได้ไม่ต่างกัน แต่พาร์เซอร์อาจพังเพราะเกิดข้อผิดพลาดในการแบ่งส่วน
    PDF มีไว้ให้คนอ่าน ดังนั้นถ้าจะอ่าน PDF ก็ต้อง เลียนแบบมนุษย์

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

    • XML+XSLT เคยเกือบจะเป็นคำตอบแบบนั้น แต่น่าเสียดายที่ตอนนี้เบราว์เซอร์ไม่รองรับไฟล์ XML แบบโลคัลแล้ว และรองรับเฉพาะ XML จากเซิร์ฟเวอร์ระยะไกลเท่านั้น