Show HN: RAG के लिए ओपन सोर्स नियम-आधारित PDF parser

 (github.com/nlmatics)
1 पॉइंट द्वारा GN⁺ 2024-01-26 | 1 टिप्पणियां | WhatsApp पर शेयर करें
  • nlm-ingestor एक service code है जिससे llmsherpa API कनेक्ट होकर इस्तेमाल कर सकता है, और यह RAG के लिए अनुकूलित PDF·HTML·Text·DOCX·PPTX जैसे document parser प्रदान करता है
  • PDF parser, nlmatics के modified Tika से मिले text coordinates, graphics, और font data का उपयोग करता है, और अगर scanned pages हों तो apply_ocr विकल्प से OCR अपने-आप लागू किया जा सकता है
  • PDF processing features में section·subsection levels, paragraph merging, section-paragraph linking, tables, nested lists, pages के बीच content merging, repeated header·footer removal, watermark removal, और OCR bounding boxes शामिल हैं
  • मॉडल-आधारित vision parser की तुलना में, नियम-आधारित parser को PDF page images बनाने की ज़रूरत नहीं होती, इसलिए यह 100 गुना तेज़ बताया गया है; और OCR नहीं बल्कि text-layer PDF तथा सैकड़ों पेज वाले documents में इसे अधिक व्यावहारिक माना गया है
  • डेवलपमेंट server को Docker या direct execution से चलाया जा सकता है, और production environment में nginx या cloud gateway जैसे security gateway के पीछे चलाने की configuration recommended है

nlm-ingestor द्वारा उपलब्ध document parser

  • nlm-ingestor एक service code repository है जिससे llmsherpa API कनेक्ट कर सकता है
  • यह RAG(retrieval augmented generation) के लिए अनुकूलित custom parser कई file formats में प्रदान करता है

    • PDF

    • HTML

    • Text

      • DOCX, PPTX, और Apache Tika द्वारा समर्थित अन्य formats

PDF parser कैसे काम करता है और इसकी विशेषताएँ

  • PDF parser नियम-आधारित है और nlmatics के modified nlm-tika से प्राप्त text coordinates, graphics, और font data का उपयोग करता है
  • यह PDF text layer के आधार पर काम करता है, और apply_ocr विकल्प के जरिए यदि PDF में scanned pages हों तो OCR अपने-आप लागू किया जा सकता है
  • OCR feature अंदरूनी रूप से tesseract का उपयोग करने वाले nlmatics के modified Tika पर आधारित है
  • PDF parser को सीधे आज़माने के लिए pdf_visual_ingestor_step_by_step notebook उपलब्ध है
  • PDF parser की विशेषताएँ इस प्रकार हैं
    • section और subsection तथा प्रत्येक level की पहचान
    • कई lines को जोड़कर paragraph बनाना
    • section और paragraph के बीच linkage बनाना
    • tables और जिन sections में tables मिलें उनकी पहचान
    • lists और nested lists को process करना
    • pages के पार content को merge करना
    • बार-बार दोहराए जाने वाले header और footer हटाना
    • watermark हटाना
    • OCR results के लिए bounding boxes उपलब्ध कराना

HTML·Text·Office documents की processing

  • HTML parser, RAG performance बढ़ाने के लिए बेहतर quality के chunks बनाने हेतु layout-aware blocks बनाता है
  • Text parser visual information, font information, और bounding boxes के बिना सिर्फ text देखकर lists, tables, headers आदि का अनुमान लगाता है
  • DOCX, PPTX और Apache Tika द्वारा समर्थित अन्य formats पहले Tika के HTML output का उपयोग करते हैं और फिर HTML parser से process होते हैं

execution और API उपयोग

  • direct execution प्रक्रिया में Java install करना, Tika server चलाना, nlm-ingestor install करना, और ingestor चलाना शामिल है
    • Tika server चलाना: java -jar <path_to_nlm_ingestor>/jars/tika-server-standard-nlm-modified-2.9.2_v2.jar
    • install: pip install nlm-ingestor
    • run: python -m nlm_ingestor.ingestion_daemon
  • public GitHub Container Registry में Docker image उपलब्ध है
    • image pull: docker pull ghcr.io/nlmatics/nlm-ingestor:latest
    • run example: docker run -p 5010:5001 ghcr.io/nlmatics/nlm-ingestor:latest-<version>
  • server चलने के बाद llmsherpa API library के जरिए chunks लेकर उन्हें LLM projects में इस्तेमाल किया जा सकता है
  • llmsherpa_url का उदाहरण http://localhost:5010/api/parseDocument?renderFormat=all है
    • OCR लागू करना: &applyOcr=yes
    • header level assignment के लिए अलग algorithm इस्तेमाल करने वाला नया indent parser उपयोग करना: &useNewIndentParser=yes
  • इसे development server के रूप में उपयोग किया जा सकता है, लेकिन production environment में nginx या cloud gateway जैसे security gateway के पीछे चलाने की configuration recommended है
  • llmsherpa parser से server को test करने वाला sample code test_llmsherpa_api notebook में है

नियम-आधारित parser क्यों चुना गया

  • nlmatics टीम ने 4 वर्षों तक Tom Liu और Yi Zhang द्वारा विकसित YOLO-आधारित vision parser सहित कई विकल्पों का मूल्यांकन करने के बाद नियम-आधारित parser चुना
  • नियम-आधारित parser किसी भी vision parser की तुलना में काफ़ी तेज़ है, और repository description इसे 100 गुना तेज़ बताती है
    • vision parser को text layer वाले PDF में भी सभी page images बनानी पड़ती हैं
    • vision parser, text layer के बिना OCR PDF या form data से बने छोटे PDF के लिए बेहतर विकल्प हो सकता है
    • सैकड़ों pages वाले बड़े text-layer PDF के लिए नियम-आधारित parser को अधिक व्यावहारिक माना गया है
  • यदि PDF OCR feature का उपयोग नहीं किया जाता, तो किसी विशेष hardware की ज़रूरत नहीं होती
    • repository description के अनुसार यह 2000 के शुरुआती दशक के hardware पर भी चल सकता है
  • vision parser सहित सभी parser में errors आ सकते हैं, और मॉडल-आधारित parser में errors सुधारने का तरीका संतोषजनक नहीं था
    • training set में और examples जोड़ने पर पहले के training की accuracy घट सकती है और पहले से काम कर रहा code अनिश्चित हो सकता है
    • मॉडल-आधारित parser की समस्याओं को नियम-आधारित ideas से ठीक करने पर फिर से बहुत सारे rules लिखने पड़ते हैं

nlmatics का modified Tika

  • nlmatics का modified Tika 2.4.1-nlm branch में है
  • सुविधा के लिए compiled jar file repository के jars/ folder में शामिल है
  • कुछ PDF में Java server पर error आ सकती है; इस स्थिति में संबंधित code को बदलकर jar file को दोबारा compile करना होगा
  • modified files प्रत्येक PDF text element में font और coordinates जोड़ती हैं और watermark हटाती हैं
    • PDF2XHTML.java
    • AbstractPDF2XHTML.java
  • GraphicsStreamProcessor.java में बदलाव lines और rectangles जोड़ने के लिए है, जो table detection में मदद कर सकता है
  • इन बदलावों का प्रभाव pdf_visual_ingestor_step_by_step notebook के शुरुआती हिस्से में देखा जा सकता है
  • भविष्य के काम के विचार इस प्रकार हैं
    • pdfbox के ऊपर अपना wrapper लिखकर Tika modifications पर dependency हटाना
    • Tika के latest version में upgrade करना
    • लौटाए जाने वाले HTML format को अधिक CSS-friendly बनाना

संबंधित पढ़ाई

1 टिप्पणियां

 
GN⁺ 2024-01-26
Hacker News टिप्पणियाँ

  • अगर आप वैज्ञानिक शोध-पत्रों पर काम कर रहे हैं, तो GROBID को भी जोड़ना चाहिए: https://github.com/kermitt2/grobid
    मैं इसे paperetl(https://github.com/neuml/paperetl) के साथ इस्तेमाल कर रहा हूँ

  • अच्छा प्रोजेक्ट है। डॉक्यूमेंट parsing के लिए मैं लंबे समय से Tika इस्तेमाल कर रहा हूँ क्योंकि इसकी maturity और supported formats की range काफ़ी व्यापक है, और XHTML output RAG के लिए document chunking में मददगार होता है
    उदाहरण यहाँ हैं: https://neuml.hashnode.dev/build-rag-pipelines-with-txtai और https://neuml.hashnode.dev/extract-text-from-documents
    संदर्भ के लिए, मैं txtai(https://github.com/neuml/txtai) का मुख्य लेखक हूँ

    • विषय से थोड़ा हटकर, लेकिन मुझे जानना है कि Tika दूसरे PDF parsing libraries की तुलना में कैसा है
      pdfminer.six (जिसे unstructured इस्तेमाल करता है) का layout detection काफ़ी बुनियादी लगा, इसलिए वह multi-column text parsing में फेल हो गया और मैं निराश हुआ, जबकि MuPDF ने इसे पूरी तरह संभाल लिया
      अभी मैं MuPDF + AWS Textract (मुख्यतः tables के लिए) का मिश्रण इस्तेमाल कर रहा हूँ, लेकिन जानना चाहता हूँ कि दूसरे लोग क्या इस्तेमाल कर रहे हैं

  • यह काफ़ी उपयोगी लग रहा है। जिस कंपनी में मैं काम करता हूँ, वहाँ एक PDF comparison tool “PDFC” है जो PDF पढ़कर semantic differences की तुलना करता है: https://www.inetsoftware.de/products/pdf-content-comparer
    PDF format इतना जटिल है कि parsing काफ़ी सिरदर्द बन सकती है। हम पहले से ही इनमें से ज़्यादातर features को support करते हैं, लेकिन edge cases हमेशा बहुत होते हैं, इसलिए अतिरिक्त approaches मददगार हो सकती हैं

  • Tesseract OCR fallback अच्छा लग रहा है
    अब RAG के लिए langchain, LLMindex, unstructured आदि के कई file loaders हैं, तो मैं जानना चाहता हूँ कि इसे prefer करने की वजह क्या है। जैसे कि benchmark scores बेहतर हैं या ऐसा कोई आधार है

    • यह टूल Apple Silicon पर build नहीं होता और इसका कोई ARM Docker image भी नहीं है, इसलिए मैं इसे सीधे आज़मा नहीं सका
      लेकिन मैंने PDF parsing के लिए ऐसे RAG tools इस्तेमाल किए हैं और output quality काफ़ी कम थी। LLM कुछ हद तक समस्या को bypass कर देता है, इसलिए RAG में यह किसी तरह चल जाता है, लेकिन अगर आपको सही references के साथ बेहतर quality के जवाब चाहिए, तो मेरा मानना है कि rule-based parser खुद इस्तेमाल करना सबसे अच्छा है। अंत में मैंने भी यही किया, बस Tika की जगह MuPDF आधारित था
      संभव है कि इस टूल के लेखक भी इसी तरह सोचते हों
    • जब मैंने आख़िरी बार Langchain इस्तेमाल किया था, मानता हूँ लगभग 6 महीने पहले, तब PDF और HTML फ़ाइलों से content extraction का implementation बहुत बुनियादी था
      RAG prototype चलाने के लिए वह काफ़ी था, लेकिन भरोसेमंद चीज़ बनाने के लिए पर्याप्त नहीं था। यह प्रोजेक्ट कहीं ज़्यादा production-tested implementation जैसा लगता है

  • बेहतरीन काम है और बहुत दिलचस्प है। लेकिन GitHub पर जाने पर “This organization has no public members” दिखता है, और मुझे ज़रा भी पता नहीं चलता कि आप लोग कौन हैं, न ही यह कि इसके भीतर और क्या-क्या हो सकता है जो public नहीं है
    कुल मिलाकर, “एक बेनाम छिपा हुआ समूह जिसने इसे किसी $CORP security site पर डाला है” और पारंपरिक परिचय-और-विश्वास-निर्माण के तरीकों के बीच, मुझे लगता है कि समय के साथ पहचान और भरोसा बनाने वाला कोई बीच का रास्ता होना चाहिए

  • LLM/RAG projects में optimal chunks पाने के लिए इस server को llmsherpa LayoutPDFReader के साथ इस्तेमाल करें: https://github.com/nlmatics/llmsherpa
    repository में examples और notebooks देखें

  • जानना चाहता हूँ कि कहीं example input-output pairs उपलब्ध हैं या नहीं

  • मैंने इससे कुछ सौ PDFs parse किए हैं और नतीजे काफ़ी अच्छे थे। अगर यह Julia में बना होता, तो कम से कम 10 गुना तेज़ होता

  • मैं जानना चाहता हूँ कि यह Azure Document Intelligence से कैसे अलग है, या फिर क्या यह मूल रूप से वही चीज़ है

    • यह वही काम नहीं करता। ज़्यादातर cloud parsers vision models इस्तेमाल करते हैं, इसलिए वे कहीं ज़्यादा धीमे और महंगे होते हैं, और अच्छे chunks निकालने के लिए आपको उसके ऊपर और code लिखना पड़ता है
      अगर आप इस server और llmsherpa library(https://github.com/nlmatics/llmsherpa) को साथ इस्तेमाल करें, तो LLM/RAG projects के लिए layout-friendly chunks मिल सकते हैं
    • इसमें OCR या AI शामिल नहीं है। यानी standard fallback को छोड़कर
      यह library और fitz/pymupdf जैसे tools PDF से सीधे text extract करते हैं और parsing व structuring rules लागू करने देते हैं। ज़्यादातर आधुनिक PDFs में OCR के बिना text extraction संभव है
      यह स्वाभाविक रूप से बहुत सस्ता है, लेकिन dynamic layouts की पूरी range पर अच्छी तरह scale नहीं करता, इसलिए आम तौर पर इसे तब इस्तेमाल किया जाता है जब आप standard structures के अनुसार configure कर सकें। फिर भी, वैज्ञानिक शोध-पत्र जैसी चीज़ों पर rule-based text extraction काफ़ी dynamic तरीके से अच्छा काम करता हुआ मैंने देखा है
    • जब मैंने आख़िरी बार Azure Document Intelligence इस्तेमाल किया था, तब यह split points चुनने में बहुत स्मार्ट नहीं था। यह वाला बेहतर heuristics लागू करता हुआ लगता है
    • मैं भी जानना चाहता हूँ। ADI भरोसेमंद है, लेकिन badly-formed PDFs में edge case issues होते हैं
      हालांकि मुझे चिंता है कि कहीं Tesseract OCR एक संभावित सीमा न हो। मैंने इसे बहुत ज़्यादा गलतियाँ करते देखा है

  • जानना चाहता हूँ कि कोई examples हैं या नहीं। repository में एक भी PDF file दिखती नहीं

    • examples llmsherpa project में देखे जा सकते हैं: https://github.com/nlmatics/llmsherpa
      यह nlm-ingestor project एक backend देता है जो llmsherpa के साथ काम करता है। llmsherpa library LLM/RAG projects के लिए अच्छे chunks निकालने में बहुत सुविधाजनक है