- Ekstraksi teks dari file PDF jauh lebih sulit daripada yang diperkirakan, dan PDF pada dasarnya adalah format file berbasis grafis
- Di dalam PDF, yang ada hanyalah informasi posisi glif, dengan sangat sedikit sinyal semantik, sehingga mengidentifikasi dan merekonstruksi teks menjadi rumit
- Mesin pencari membutuhkan input yang rapi dalam bentuk HTML, tetapi alat open source yang ada memiliki keterbatasan dalam mengekstrak informasi struktural seperti judul atau paragraf
- Pendekatan visi berbasis machine learning adalah yang paling akurat, tetapi sulit diterapkan dalam skala besar karena masalah sumber daya dan performa
- Perbaikan utama mencakup penerapan algoritme identifikasi judul dan paragraf berbasis ukuran font dan statistik untuk meningkatkan akurasi ekstraksi
Tantangan mengekstrak teks dari PDF
- Mesin pencari modern kini memiliki kemampuan untuk mengindeks format file PDF
- Ekstraksi informasi dari PDF bukan masalah yang mudah, karena PDF pada awalnya adalah format grafis, bukan format teks
- Alih-alih teks yang sesungguhnya, PDF berisi glif yang ditempatkan pada koordinat tertentu, sehingga muncul masalah seperti rotasi, tumpang tindih, urutan yang kacau, dan ketiadaan informasi makna
- Informasi sebagai teks seperti yang biasa kita pahami sebenarnya tidak hadir secara langsung di dalam file
- Fakta bahwa kita bisa mencari teks dengan ctrl+f di penampil PDF sebenarnya cukup menakjubkan
Kebutuhan mesin pencari dan keterbatasan pendekatan dasar
- Input yang paling disukai mesin pencari adalah format HTML yang bersih
- Model computer vision modern berbasis machine learning menunjukkan performa terbaik, tetapi
- memproses file PDF berukuran besar (ratusan GB) di satu server tanpa GPU adalah tidak efisien
- Untungnya, bidang ini bukan wilayah yang sepenuhnya belum dikenal, sehingga
- kita bisa memanfaatkan kelas PDFBox
PDFTextStripper sebagai titik awal
- Namun, alat ini hampir tidak mampu memahami struktur semantik seperti judul—yang diekstrak hanya string
Algoritme identifikasi judul
Prinsip dasar identifikasi judul
- Biasanya, judul dapat dikenali dari teks semibold atau lebih tebal yang berdiri sendiri
- Judul tanpa huruf tebal juga umum ditemui, jadi metode ini saja punya keterbatasan
- Dalam banyak kasus, ukuran font menjadi kriteria pembeda judul
- Namun ukuran font sangat berbeda antar dokumen, sehingga mustahil memakai ambang global
Memanfaatkan statistik ukuran font
- Setiap halaman umumnya memiliki ukuran font dominan (isi utama)
- Halaman 1 (sampul) memiliki konten deskriptif dan informasi penulis, sehingga distribusi ukuran fontnya berbeda
- Karena distribusi ukuran font berbeda per halaman, menggunakan statistik per halaman, bukan seluruh dokumen, lebih efektif
- Dengan menerapkan kenaikan sekitar 20% di atas ukuran font median setiap halaman, judul dapat diidentifikasi dengan cukup akurat
Masalah penggabungan judul multi-baris
- Karena alasan gaya, judul kadang dipecah menjadi beberapa baris
- Menentukan kapan judul harus digabung tidaklah sederhana; judul dua baris atau lebih, nama penulis, dan teks penekanan terpisah bisa bercampur
- Aturan penggabungan:
- Menggabungkan baris berurutan yang memiliki ukuran font dan ketebalan yang sama bekerja cukup baik
- Namun ada banyak pengecualian—penggabungan yang serampangan bisa menghasilkan hasil yang keliru
Peningkatan identifikasi paragraf
PDFTextStripper mengidentifikasi paragraf berdasarkan jarak antarbaris dan indentasi
- Karena ambang pemisahan per baris menggunakan nilai tetap, ada keterbatasan saat menghadapi jarak baris yang berbeda-beda di tiap dokumen
- Khususnya pada draf makalah/prapublikasi, jarak baris 1,5–2 kali juga umum
- Jika nilai ambang terlalu besar, bisa muncul kesalahan ketika judul ikut masuk ke isi paragraf
Pemisahan paragraf berbasis statistik
- Seperti ukuran font, jarak antarbaris juga diperlakukan secara statistik
- Dengan memanfaatkan nilai tengah (median) jarak antarbaris, dimungkinkan pemisahan paragraf yang kokoh untuk berbagai jenis spasi baris
Kesimpulan
- Mengekstrak teks dari PDF pada dasarnya tidak mungkin benar-benar sempurna
- Karena format PDF sendiri tidak dirancang untuk tujuan tersebut
- Dalam implementasi nyata, kompromi itu wajib, dan strategi untuk mendapatkan hasil yang “cukup baik” menjadi penting
- Untuk mesin pencari, lebih efisien berfokus pada ekstraksi sinyal yang bermakna seperti judul, ringkasan, dan petunjuk struktural utama
Contoh teks referensi
- 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 komentar
Komentar Hacker News
Pernah mengalami saat mengira sesuatu itu baru dan menarik dalam hidup, lalu samar-samar teringat bahwa dulu pernah menjadi ahli di bidang itu selama berbulan-bulan atau bahkan bertahun-tahun. Sampai-sampai hal-hal yang dulu pernah dilakukan dengan sangat keren pun terasa seperti hilang dari kepala, jadi rasanya seperti mulai lagi dari nol. Ada ingatan samar bahwa sekitar 6~7 tahun lalu pernah membuat sesuatu yang luar biasa dengan PDF dan OCR. Setelah dicari di Google, nama “tesseract” terdengar familier
Sekitar 2006, sempat kesal karena di iRex, e-reader awal yang bisa di-hack, teks dari makalah ilmiah multi-kolom tidak bisa disalin. Saat itu penampil PDF-nya memakai poppler, jadi poppler dimodifikasi agar bisa menyimpulkan urutan baca pada dokumen multi-kolom. Untuk itu, algoritme OCR karya Thomas Breuel, penulis tesseract, dijadikan referensi. Ini semacam hack heuristik dan tidak terlalu cocok dengan API aksesibilitas. Fitur pemilihan multi-kolom memang sempat diperkenalkan, tetapi sulit meyakinkan para maintainer. Bagaimanapun, akhirnya kpdf punya fitur pemilihan multi-kolom berkat ini. Belakangan terasa jauh lebih masuk akal untuk langsung memakai tesseract untuk kebutuhan seperti ini
Waktu puluhan tahun umat manusia yang terbuang gara-gara format PDF tidak bisa dikembalikan. Ingin tahu kapan kegilaan ini akan berakhir
Tesseract sempat menjadi OCR open source terbaik untuk waktu yang cukup lama. Namun sekarang menurut saya docTR lebih unggul dari sisi akurasi dan akselerasi GPU. docTR adalah struktur pipeline yang memungkinkan kombinasi berbagai model deteksi dan pengenalan teks. Ia juga bisa dilatih dan di-tuning di PyTorch atau TensorFlow, jadi performanya bisa dibuat jauh lebih cocok untuk domain tertentu
Memang begitulah hidup. Setiap kali menyelesaikan proyek, muncul pikiran “sekarang aku sudah jadi ahli di bidang ini. Tapi mungkin aku tidak akan pernah mengerjakannya lagi.” Karena berikutnya kita akan mulai lagi dari nol di topik yang benar-benar baru
Belum lama ini seseorang bertanya soal C++, dan saya bilang “tidak pernah benar-benar bekerja serius dengannya.” Lalu belakangan ingat bahwa sekitar 20 tahun lalu saya pernah menulis kode klien untuk private instant messenger yang dibuat dengan Borland C++, dan dipakai ribuan orang. Hal seperti ini cukup sering terjadi
Aku tidak tahu seluruh isi kepalamu, tapi mungkin memang benar itu tesseract. Aku juga pernah mengalami hal serupa, dalam kasusku sekitar 12 tahun lalu
Saat HQ sedang populer, saya pernah membuat pemecah kuis HQ otomatis dengan tesseract. Caranya dengan mengambil screenshot layar pertanyaan di aplikasi, mengirimkannya ke API kecil, lalu mencari kalimat pertanyaan itu di Google dan menghitung berapa kali tiap jawaban muncul untuk memberi peringkat berdasarkan probabilitas. Memang tidak akurat dan sangat sederhana, tapi seru sekali dibuat
Fenomena ini tidak jauh beda dengan semut api yang saat daunnya tertiup angin, ya tinggal mencari daun lain
Itu terjadi 7~8 tahun lalu saat masih berusia 20-an, jadi ingatannya masih sangat jelas. Mungkin ada perbedaan usia yang cukup jauh. Atau saya juga menyarankan cek kesehatan
Saya berharap ada alat yang bisa “melihat” content stream PDF pada level source—BT…ET yang membungkus teks, berbagai operator yang menentukan font dan koordinat, dan seterusnya—lalu membandingkan serta menganalisisnya berdampingan dengan hasil render, seperti developer tools browser (“inspect element”). Ini berbeda dari alur model vision yang memproses PDF dengan “melihatnya”, tetapi lebih pada keinginan untuk benar-benar memahami informasi apa yang sebenarnya terkandung di dalam PDF. Memang ada beberapa alat, tetapi hanya menampilkan sampai level objek dan tidak menggali hingga ke dalam content stream. Saya ingin lingkungan tempat source stream nyata dari PDF contoh dan hasil rendernya bisa dibandingkan dan dianalisis berdampingan seperti HTML, untuk melihat bagian mana direpresentasikan dengan cara seperti apa
Jika merender PDF ke DOM menggunakan Mozilla PDF.js, saya rasa Anda bisa mendapatkan pengalaman yang hampir serupa. Misalnya operator seperti Tj atau TJ akan dikonversi menjadi <span> atau kumpulannya. Mungkin karena perlu setia pada dokumen aslinya
Saya sarankan mencoba tool cpdf (saya yang membuatnya). Dengan opsi
-output-jsondan-output-json-parse-content-streamsdi cpdf, PDF bisa diubah menjadi JSON untuk berbagai eksperimen. Sebaliknya, JSON juga bisa diubah kembali menjadi PDF. Namun, ini tidak menyediakan interaksi real-timeSepertinya Anda mencari tool gratis atau open source, tetapi dulu saat memakai Acrobat Pro, ada fitur yang hampir seperti itu. Hanya saja pendekatannya menelusuri pohon konten alih-alih memeriksa halaman, dan hanya menampilkan sampai level objek/stream tanpa turun ke tiap perintah individual
“Kami sedang membuat gabungan dari ‘model vision melihat PDF seperti manusia’ dan ‘benar-benar tahu data apa yang ada di dalam PDF’ di Tensorlake (saya bekerja di sana). Bukan sekadar membaca teks, tapi juga benar-benar memahami tabel, gambar, rumus, tulisan tangan, dan sebagainya lalu mengekstrak datanya ke Markdown/JSON agar bisa dipakai untuk aplikasi AI, LLM, dll” https://tensorlake.ai
Ini belum sampai ke tingkat yang benar-benar Anda inginkan, tetapi ada notebook yang menyediakan inspector yang menampilkan berbagai operasi drawing di dalam PDF secara ‘live’, jadi mungkin layak dilihat https://observablehq.com/@player1537/pdf-utilities
Saya pernah fokus pada masalah ini selama bertahun-tahun di Apple. Intinya adalah menerima bahwa “semuanya geometri”, lalu memakai algoritme yang membedakan spasi antar-kata dan antar-huruf melalui clustering. Untuk sebagian besar PDF ini cukup efektif, tetapi kalau dilihat lebih dekat variasinya terlalu banyak sehingga beberapa hasil tetap mengecewakan. Kalau mengerjakannya lagi sekarang, saya akan sepenuhnya membuang OCR dan tetap berbasis informasi geometri, tetapi menambahkan machine learning. Jika PDF dibuat dari teks yang sudah diketahui sebelumnya lalu dimanfaatkan untuk machine learning, pembuatan data latih juga bisa diotomatisasi. (Ada video presentasi WWDC 2009 oleh Bertrand Serlet)
Menurut saya ini bukan satu masalah “PDF to Text”, melainkan sebenarnya terbagi menjadi 3 kategori: (1) OCR yang andal (untuk pencarian, input vector DB, dll), (2) ekstraksi data terstruktur (mengambil nilai tertentu saja), (3) otomasi pipeline dokumen secara menyeluruh (misalnya otomasi hipotek). Marginalia bertujuan pada (1), dan belakangan OCR menjadi murah serta serbaguna berkat Gemini Flash dan sejenisnya. Namun (2) dan (3) jauh lebih sulit, dan untuk otomasi penuh masih butuh banyak kerja manusia seperti pembangunan dataset, desain pipeline, deteksi ketidakpastian dan intervensi manual, fine-tuning, dan sebagainya. Masa depannya ada di arah ini. (Saya menjalankan perusahaan pemrosesan dokumen berbasis LLM) https://extend.ai
Saya rasa perlu juga ada (4), yaitu OCR yang andal dan ekstraksi semantik untuk dokumen dalam beragam bentuk, yakni solusi untuk aksesibilitas. Sulitnya ini karena, tidak seperti workflow umum, jenis dokumen pengguna tidak dapat diprediksi; elemen non-teks seperti tabel, header/footer/anotasi/rumus juga harus diekstrak; error harus diminimalkan sehingga OCR tidak boleh dipakai berlebihan; teks bawaan dan hasil render bisa saja tidak cocok satu sama lain (teks tersembunyi atau kombinasi tidak baku, dll); kebanyakan berjalan sebagai aplikasi lokal sehingga sulit memanfaatkan server; dan perlu dukungan Form untuk dokumen yang ditujukan ke embosser braille, serta masih banyak masalah gabungan lainnya. Saat ini belum ada solusi yang benar-benar menyelesaikan semua hal tersebut secara penuh
Ada yang bilang pipeline OCR bisa disederhanakan dengan VLM, tetapi ini peringatan bahwa pada dokumen kompleks kenyataannya sangat sulit. Untuk label gambar sederhana memang luar biasa, dan untuk dokumen yang sangat sederhana masih lumayan berguna, tetapi pada dokumen berisi tabel, header, ringkasan terstruktur, dan semacamnya, halusinasi muncul sangat parah. Jadi secara praktis hampir tidak bisa dipakai
Saya juga mengalami berbagai isu seperti deteksi header saat mengubah ke Markdown. OCR modern memang hebat, tetapi mempertahankan struktur keseluruhan dokumen jauh lebih sulit. Saya mendapatkan hasil yang lumayan baik dengan mengekstrak struktur lewat beberapa kali lintasan LLM dan memasukkan konteks per halaman
Solusi yang lebih baik adalah melampirkan dokumen sumber yang bisa diedit di dalam PDF. Ini bisa dilakukan dengan mudah di LibreOffice. Biasanya juga tidak memakan banyak ruang, dan makna teksnya bisa diketahui dengan jelas. PDF reader yang ada sekarang pun tetap bisa memakainya tanpa masalah
Jika masalahnya adalah ekstraksi teks dari PDF yang sudah ada, saya ragu nasihat tentang cara membuat PDF benar-benar banyak membantu. Kapan kira-kira solusi seperti ini akan mulai efektif secara nyata?
Benar, tetapi ini menimbulkan risiko bahwa isi dokumen sumber dan PDF hasil render bisa benar-benar berbeda
Itu pendapat yang benar, tetapi hanya berlaku jika kepentingan pembuat PDF dan pihak yang mengonsumsi PDF itu selaras. Di bidang e-Discovery, praktik menyerahkan materi dalam bentuk PDF agar pengacara lawan sengaja kesulitan memakainya itu cukup umum. Akibatnya, pembela umum yang kekurangan sumber daya harus menghabiskan lebih banyak waktu untuk memproses materi tersebut dan mengalami kerugian nyata. Untuk mencegah hal ini, saya rasa perlu ada undang-undang yang mewajibkan berbagai data diserahkan dalam format standar yang bisa dibaca mesin
Jika punya akses ke dokumen sumbernya, melampirkannya ke dalam PDF memang sangat bagus. Namun dalam kebanyakan kasus, kita tidak punya kendali seperti itu
Sebagian besar masalah nyata ada pada PDF lama. Di perusahaan kami juga ada ribuan, dan sebagian berupa hasil scan yang kacau. Ada juga yang memiliki OCR bawaan Adobe, tetapi kebanyakan sama sekali tidak punya
PDF di bawah ini sebenarnya adalah file .txt. Ekstensinya bisa diubah menjadi .pdf lalu dibuka dengan PDF viewer, dan juga bisa langsung diedit dengan text editor untuk mengontrol berbagai hal seperti isi yang tampil di layar, font, ukuran font, jarak antarbaris, jumlah karakter per halaman, jumlah baris, ukuran kertas, dan sebagainya. (Contoh teks PDF disertakan langsung)
PDF juga bisa menyematkan stream biner. PDF bukan format teks, melainkan format yang dibuat untuk layout dan grafis. Seperti pada contoh, tiap baris bisa saja muncul sekaligus, tetapi dalam praktiknya bisa direpresentasikan per huruf, per kata, atau bahkan tanpa urutan sama sekali
PDF adalah singkatan dari “Portable Document Format”. Ia dienkode sebagai file ASCII 7-bit, sehingga sangat portabel di berbagai perangkat dan lingkungan OS. (Rujukan: tautan dokumentasi resmi Adobe)
Contoh ini adalah ‘Hello World’-nya PDF. PDF modern kebanyakan mengompresi objek (obj) dengan deflate, lalu mengelompokkan objek-objek itu di dalam stream sehingga menjadi lebih rumit. Karena itu, menganalisisnya dengan sekadar mencari "6 0 Obj" di teks biasa menjadi sangat sulit
Mengekstrak teks dari PDF, terutama teks terstruktur, sama sekali bukan pekerjaan mudah. Tabel HTML umumnya masih relatif mudah diekstrak, tetapi pada PDF sesuatu tampak seperti tabel hanya berdasarkan koordinat render, sementara sebenarnya teks dan grafiknya tersebar terpisah. Saya sendiri memakai cara mengubah PDF menjadi HTML dengan Poppler PDF utils, lalu mencari header tabel, menentukan kolom berdasarkan koordinat x tiap nilai, dan mengekstrak data per baris. Kelihatannya memang agak kasar, tetapi hasilnya lebih andal daripada memakai txt yang sudah diratakan
Saya frustrasi karena tidak bisa mengekstrak data dari PDF seperti memakai BeautifulSoup untuk webpage, jadi saya membuat sendiri library dengan antarmuka seperti itu. (contoh format
'page.find') Karena tiap PDF membawa neraka kasus yang berbeda-beda, saya mengumpulkan know-how ekstraksi dan contoh PDF aneh ke dalam library ini https://jsoma.github.io/natural-pdf/ , https://badpdfs.com/Suatu hari saya ingin mengekstrak data tabel dari PDF ke software pemrosesan data saya. Kalau ada yang tahu library gratis atau sangat murah yang bisa diintegrasikan ke aplikasi C++, tolong beri tahu
Ada dokumen-dokumen, misalnya dari lembaga pemerintah, yang teks yang bisa ditampilkan dan teks yang benar-benar diekstrak sama sekali berbeda. Kasus seperti ini cukup sering ada
PDF pada dasarnya adalah format markup/XML. PDF yang sama pun bisa dibuat dengan sangat banyak cara. Jika diekspor dari tool grafis, hasilnya bisa berupa PDF campuran grafis dan teks; jika diekspor dari pengolah kata, hasilnya bisa lebih berpusat pada teks; jadi hasilnya multidimensional. Cara aplikasi pembuat menangani informasi sangat memengaruhi bagaimana PDF dihasilkan. Untuk utilitas off-the-shelf, berbagai produk seperti cisdem lumayan berguna untuk mengekstrak sebagian data terstruktur. Tetapi tetap perlu tool yang cocok untuk tiap pekerjaan
Salah satu contoh favorit saya adalah PDF makalah ini (tautan terlampir). Di halaman pertama ada teks dua kolom yang khas, header di tengah, teks yang menyelip di antara dua kolom, serta elemen yang mengubah panjang baris dan indentasi. Header halaman juga berbeda untuk halaman ganjil/genap, dan aturan header seksi pun tidak konsisten. Paragraf juga tidak selalu memakai indentasi dan jarak antarbarisnya berubah-ubah. Ini semacam kumpulan lengkap berbagai masalah
Saat pernah membuat parser PDF sederhana sendiri, saya sempat terkejut dengan cara kerja format ini. Karena itu saya justru selalu heran mengapa format ini begitu sering dipakai untuk kebutuhan yang berpusat pada teks. Misalnya untuk invoice, sistem digital seharusnya mudah mengekstrak datanya, sementara untuk manusia lebih cocok disajikan dalam bentuk yang sudah diformat. Jadi saya berharap dunia teknologi bisa bermigrasi bertahap ke format yang lebih baik
Mengekstrak ‘informasi berguna’ dari PDF memang pekerjaan Tensorlake (https://tensorlake.ai). PDF bukan hanya berisi teks, tetapi juga tabel, gambar, rumus, tulisan tangan, coretan hapus, dan berbagai informasi lain, jadi sebagai developer kami harus bisa bukan hanya “membaca” teks, tetapi juga “memahami”-nya. (Mengungkapkan bahwa saya adalah karyawan)