Show HN: Parser PDF berbasis aturan open-source untuk RAG

 (github.com/nlmatics)
1 poin oleh GN⁺ 2024-01-26 | 1 komentar | Bagikan ke WhatsApp
  • nlm-ingestor adalah kode layanan yang dihubungkan dan digunakan oleh API llmsherpa, yang menyediakan parser dokumen untuk PDF, HTML, Text, DOCX, PPTX, dan format lain yang disesuaikan untuk RAG
  • Parser PDF menggunakan data koordinat teks, grafik, dan font yang diperoleh dari versi modifikasi Tika milik nlmatics, dan jika ada halaman hasil pindai, OCR dapat diterapkan secara otomatis dengan opsi apply_ocr
  • Fitur pemrosesan PDF mencakup level bagian dan subbagian, penggabungan paragraf, pengaitan bagian-paragraf, tabel, daftar bertingkat, penggabungan konten lintas halaman, penghapusan header dan footer berulang, penghapusan watermark, serta bounding box OCR
  • Dibandingkan parser visi berbasis model, parser berbasis aturan diklaim 100x lebih cepat karena tidak perlu membuat gambar halaman PDF, dan dinilai lebih praktis untuk PDF dengan text layer ketimbang OCR serta dokumen ratusan halaman
  • Server pengembangan dapat dijalankan lewat Docker atau secara langsung, dan untuk lingkungan produksi disarankan dijalankan di belakang gateway keamanan seperti nginx atau cloud gateway

Parser dokumen yang disediakan oleh nlm-ingestor

  • nlm-ingestor adalah repositori kode layanan yang dapat dihubungkan oleh API llmsherpa
  • Menyediakan parser kustom untuk berbagai format file yang disesuaikan untuk RAG (retrieval augmented generation)

    • PDF

    • HTML

    • Text

      • DOCX, PPTX, dan format lain yang didukung Apache Tika

Cara kerja dan fitur parser PDF

  • Parser PDF bersifat berbasis aturan, dan menggunakan data koordinat teks, grafik, dan font yang diperoleh dari nlm-tika, versi modifikasi nlmatics
  • Bekerja berdasarkan text layer PDF, dan melalui opsi apply_ocr dapat menerapkan OCR secara otomatis jika PDF memiliki halaman hasil pindai
  • Fitur OCR secara internal berbasis Tika versi modifikasi nlmatics yang menggunakan tesseract
  • Notebook untuk mencoba langsung parser PDF tersedia di pdf_visual_ingestor_step_by_step
  • Fitur parser PDF meliputi:
    • Mengidentifikasi bagian, subbagian, dan setiap level
    • Menggabungkan banyak baris menjadi paragraf
    • Membuat keterkaitan antara bagian dan paragraf
    • Mengidentifikasi tabel dan bagian tempat tabel ditemukan
    • Menangani daftar dan daftar bertingkat
    • Menggabungkan konten yang melintasi halaman
    • Menghapus header dan footer yang berulang
    • Menghapus watermark
    • Menyediakan bounding box untuk hasil OCR

Pemrosesan dokumen HTML, Text, dan Office

  • Parser HTML membuat blok yang mengenali tata letak agar menghasilkan chunk dengan kualitas lebih baik untuk meningkatkan performa RAG
  • Parser Text memperkirakan daftar, tabel, header, dan elemen lain hanya dari teks tanpa informasi visual, informasi font, atau bounding box
  • DOCX, PPTX, dan format lain yang didukung Apache Tika diproses dengan memakai output HTML dari Tika lalu diteruskan ke parser HTML

Menjalankan dan menggunakan API

  • Prosedur menjalankan secara langsung terdiri dari memasang Java, menjalankan server Tika, memasang nlm-ingestor, lalu menjalankan ingestor
    • Menjalankan server Tika: java -jar <path_to_nlm_ingestor>/jars/tika-server-standard-nlm-modified-2.9.2_v2.jar
    • Instalasi: pip install nlm-ingestor
    • Menjalankan: python -m nlm_ingestor.ingestion_daemon
  • Image Docker disediakan di GitHub Container Registry publik
    • Mengambil image: docker pull ghcr.io/nlmatics/nlm-ingestor:latest
    • Contoh menjalankan: docker run -p 5010:5001 ghcr.io/nlmatics/nlm-ingestor:latest-<version>
  • Setelah server berjalan, chunk dapat diambil lewat library API llmsherpa untuk digunakan dalam proyek LLM
  • Contoh llmsherpa_url adalah http://localhost:5010/api/parseDocument?renderFormat=all
    • Menerapkan OCR: &applyOcr=yes
    • Menggunakan parser indent baru yang memakai algoritme berbeda untuk menetapkan level header: &useNewIndentParser=yes
  • Meski bisa dipakai sebagai server pengembangan, untuk lingkungan produksi disarankan konfigurasi yang menjalankannya di belakang gateway keamanan seperti nginx atau cloud gateway
  • Kode contoh untuk menguji server dengan parser llmsherpa tersedia di notebook test_llmsherpa_api

Alasan memilih parser berbasis aturan

  • Tim nlmatics memilih parser berbasis aturan setelah selama 4 tahun mengevaluasi berbagai opsi, termasuk parser visi berbasis YOLO yang dikembangkan oleh Tom Liu dan Yi Zhang
  • Parser berbasis aturan jauh lebih cepat daripada parser visi mana pun, dan deskripsi repositori menyebutnya 100x lebih cepat
    • Parser visi harus membuat gambar untuk semua halaman bahkan pada PDF yang memiliki text layer
    • Parser visi bisa menjadi pilihan lebih baik untuk PDF OCR tanpa text layer atau PDF kecil yang tersusun dari data formulir
    • Untuk PDF text layer besar yang panjangnya ratusan halaman, parser berbasis aturan dinilai lebih praktis
  • Jika tidak menggunakan fitur OCR PDF, tidak dibutuhkan perangkat keras khusus
    • Deskripsi repositori menyatakan bahwa ia bahkan dapat berjalan pada perangkat keras awal 2000-an
  • Semua parser, termasuk parser visi, dapat menghasilkan kesalahan, dan dijelaskan bahwa cara memperbaiki kesalahan parser berbasis model tidak memuaskan
    • Menambahkan lebih banyak contoh ke set pelatihan dapat menurunkan akurasi pembelajaran sebelumnya dan membuat kode yang sebelumnya bekerja menjadi tidak pasti
    • Jika masalah parser berbasis model diperbaiki dengan ide berbasis aturan, pada akhirnya tetap harus menulis banyak aturan lagi

Tika versi modifikasi nlmatics

  • Tika versi modifikasi nlmatics tersedia di branch 2.4.1-nlm
  • Untuk kemudahan, file jar yang sudah dikompilasi disertakan di folder jars/ dalam repositori
  • Beberapa PDF dapat menimbulkan error pada server Java, dan dalam kasus seperti itu kode terkait perlu diperbaiki lalu file jar dikompilasi ulang
  • File yang dimodifikasi menambahkan font dan koordinat pada setiap elemen teks PDF serta menghapus watermark
    • PDF2XHTML.java
    • AbstractPDF2XHTML.java
  • Perubahan pada GraphicsStreamProcessor.java dimaksudkan untuk menambahkan garis dan persegi panjang yang dapat membantu deteksi tabel
  • Dampak perubahan ini dapat dilihat pada bagian awal notebook pdf_visual_ingestor_step_by_step
  • Ide pekerjaan berikutnya adalah:
    • Menulis wrapper sendiri di atas pdfbox untuk menghilangkan ketergantungan pada perubahan Tika
    • Upgrade ke versi Tika terbaru
    • Merapikan format HTML yang dikembalikan agar lebih ramah CSS

Bacaan terkait

1 komentar

 
GN⁺ 2024-01-26
Opini Hacker News

  • Jika menangani makalah ilmiah, GROBID juga layak ditambahkan: https://github.com/kermitt2/grobid
    Saya menggunakannya bersama paperetl(https://github.com/neuml/paperetl)

  • Proyek yang bagus. Untuk parsing dokumen, saya sudah lama memakai Tika karena kematangannya dan cakupan format yang luas, dan output XHTML membantu untuk chunking dokumen bagi RAG
    Contohnya ada di https://neuml.hashnode.dev/build-rag-pipelines-with-txtai dan https://neuml.hashnode.dev/extract-text-from-documents
    Sebagai catatan, saya adalah penulis utama txtai(https://github.com/neuml/txtai)

    • Sedikit keluar topik, tapi saya penasaran bagaimana Tika dibandingkan dengan library parsing PDF lain
      pdfminer.six (yang dipakai unstructured) agak mengecewakan karena deteksi layout-nya cukup dasar dan gagal mem-parsing teks multi-kolom, sedangkan MuPDF menanganinya dengan sempurna
      Saat ini saya memakai kombinasi MuPDF + AWS Textract (terutama untuk tabel), dan ingin tahu apa yang dipakai orang lain

  • Sepertinya akan cukup membantu. Di perusahaan tempat saya bekerja ada alat pembanding PDF bernama “PDFC” yang membaca PDF dan membandingkan perbedaan semantik: https://www.inetsoftware.de/products/pdf-content-comparer
    Format PDF sangat kompleks sehingga parsing bisa sangat merepotkan. Kami sudah mendukung sebagian besar fungsi seperti ini, tetapi selalu ada banyak edge case, jadi pendekatan tambahan bisa membantu

  • Fallback Tesseract OCR terlihat bagus
    Sekarang ada banyak file loader untuk RAG seperti langchain, LLMindex, unstructured, dan sebagainya; saya penasaran apakah ada alasan untuk lebih memilih ini. Misalnya apakah ada bukti seperti skor benchmark yang lebih unggul

    • Tool ini tidak bisa di-build di Apple Silicon dan tidak ada image Docker ARM, jadi saya belum bisa mencobanya langsung
      Namun saya pernah memakai tool RAG semacam itu untuk parsing PDF dan kualitas output-nya cukup rendah. Karena LLM bisa sedikit mengakali masalahnya, untuk RAG masih lumayan berjalan, tetapi jika ingin jawaban berkualitas lebih tinggi dengan referensi yang benar, menurut saya memakai parser berbasis aturan sendiri adalah yang terbaik. Pada akhirnya saya juga begitu, hanya saja berbasis MuPDF, bukan Tika
      Bisa jadi para penulis tool ini punya pemikiran serupa
    • Terakhir kali saya memakai Langchain, memang sekitar 6 bulan lalu, implementasi ekstraksi konten dari file PDF dan HTML masih sangat dasar
      Cukup untuk menjalankan prototipe RAG, tetapi kurang untuk membangun sesuatu yang bisa diandalkan. Proyek ini terlihat seperti implementasi yang jauh lebih teruji di dunia nyata

  • Pekerjaan yang hebat dan sangat menarik. Namun ketika membuka GitHub, tertulis “This organization has no public members”, saya sama sekali tidak tahu siapa kalian, dan tidak bisa tahu apa lagi yang mungkin ada di dalamnya secara tidak terbuka
    Secara umum, menurut saya kita butuh titik tengah antara “grup tersembunyi tanpa nama yang mengunggah sesuatu di situs keamanan $CORP” dan cara perkenalan serta pembangunan kepercayaan tradisional, agar identifikasi dan kepercayaan bisa dibangun seiring waktu

  • Untuk mendapatkan chunk optimal dalam proyek LLM/RAG, server ini bisa dipakai bersama llmsherpa LayoutPDFReader: https://github.com/nlmatics/llmsherpa
    Lihat contoh dan notebook di repositori tersebut

  • Saya penasaran apakah ada pasangan input-output contoh di suatu tempat

  • Saya sudah mem-parsing beberapa ratus PDF dengan ini dan hasilnya cukup bagus. Kalau dikembangkan dengan Julia, saya rasa setidaknya akan 10 kali lebih cepat

  • Saya penasaran apa bedanya ini dengan Azure Document Intelligence, atau apakah pada dasarnya sama saja

    • Ini tidak melakukan hal yang sama. Kebanyakan parser cloud memakai model visi, sehingga jauh lebih lambat dan mahal, dan untuk mengekstrak chunk yang bagus Anda masih harus menulis kode tambahan di atasnya
      Jika server ini dipakai bersama library llmsherpa(https://github.com/nlmatics/llmsherpa), Anda bisa mendapatkan chunk yang ramah layout untuk proyek LLM/RAG
    • Di sini tidak ada OCR atau AI. Maksudnya, kecuali fallback standar
      Library ini dan tool seperti fitz/pymupdf mengekstrak teks langsung dari PDF, lalu memungkinkan penerapan aturan parsing dan strukturisasi. Sebagian besar PDF modern bisa diekstrak teksnya tanpa OCR
      Tentu saja jauh lebih murah, tetapi tidak terlalu skalabel untuk berbagai layout dinamis, jadi biasanya dipakai ketika bisa dikonfigurasi sesuai struktur standar. Meski begitu, untuk hal seperti makalah ilmiah, saya melihat ekstraksi teks berbasis aturan bekerja cukup dinamis dengan baik
    • Terakhir kali saya mencobanya, Azure Document Intelligence tidak terlalu pintar dalam memilih titik pemisahan. Yang ini tampaknya mengimplementasikan heuristik yang lebih baik
    • Saya juga penasaran. ADI bisa diandalkan, tetapi punya masalah edge case pada PDF yang dibuat dengan buruk
      Namun saya khawatir Tesseract OCR bisa menjadi keterbatasan potensial. Saya sudah melihatnya membuat terlalu banyak kesalahan

  • Saya penasaran apakah ada contoh. Sepertinya tidak ada satu pun file PDF di repositori

    • Contohnya bisa dilihat di proyek llmsherpa: https://github.com/nlmatics/llmsherpa
      Proyek nlm-ingestor ini menyediakan backend yang bekerja bersama llmsherpa. Library llmsherpa sangat praktis untuk mengekstrak chunk yang bagus bagi proyek LLM/RAG