उच्च सटीकता के साथ तेज़ी से PDF को Markdown में बदलने की तकनीक

 (github.com/VikParuchuri)
2 पॉइंट द्वारा GN⁺ 2023-12-02 | 1 टिप्पणियां | WhatsApp पर शेयर करें
  • Marker PDF के साथ-साथ इमेज, PPTX, DOCX, XLSX, HTML, EPUB दस्तावेज़ों को Markdown, JSON, chunks, HTML में तेज़ और सटीक रूप से बदलने वाला document intelligence टूल है
  • यह टेबल, फ़ॉर्म, समीकरण, inline math, लिंक, रेफ़रेंस, code block को फ़ॉर्मैट करता है, इमेज extract·save और header/footer जैसे artifacts हटाने को सपोर्ट करता है
  • सटीकता बढ़ाने के लिए --use_llm के साथ LLM का उपयोग किया जा सकता है, डिफ़ॉल्ट gemini-2.0-flash है, और Gemini, Ollama, Claude, OpenAI, Azure OpenAI आदि चुने जा सकते हैं
  • benchmark में Marker ने single PDF page के आधार पर औसतन 2.83837 सेकंड, heuristic score 95.6709, LLM score 4.23916 दर्ज किया, और H100 batch mode में 25 pages/second throughput की उम्मीद है
  • Python 3.10+ और PyTorch की ज़रूरत है, और code GPL के तहत है, जबकि model weights modified AI Pubs OpenRAIL-M लाइसेंस के तहत research, personal use, और $2M से कम startup के लिए मुफ़्त शर्तों के साथ उपलब्ध हैं

Marker किन दस्तावेज़ों को बदलता है और उसका आउटपुट

  • Marker दस्तावेज़ों को Markdown, JSON, chunks, HTML में बदलता है
  • input format में PDF, इमेज, PPTX, DOCX, XLSX, HTML, EPUB शामिल हैं और यह सभी भाषाओं के दस्तावेज़ों को प्रोसेस करता है
  • document element processing का दायरा:
    • टेबल, फ़ॉर्म, समीकरण, inline math
    • लिंक, रेफ़रेंस, code block
    • इमेज extract और save
    • header, footer, और अन्य artifacts हटाना
  • इसे अपनी formatting और logic के साथ extend किया जा सकता है
  • JSON schema देने पर structured extraction किया जा सकता है, और यह फ़ीचर beta है
  • यह GPU, CPU, MPS पर चलता है

Datalab managed platform

  • Datalab managed platform नवीनतम open source मॉडल Chandra चलाता है
  • Chandra को Marker से अधिक सटीक बताया गया है, और डिफ़ॉल्ट रूप से data retention नहीं है, साथ ही SOC 2 Type 2 और custom BAA उपलब्ध हैं
  • high-volume workload के लिए batch processing service ने प्रति सप्ताह 200M+ pages प्रोसेस किए हैं
  • signup पर $5 free credit मिलता है, और public playground भी उपलब्ध है
  • commercial self-hosting के लिए लाइसेंस चाहिए, और on-premises लाइसेंस के लिए अलग से संपर्क करना होता है

प्रदर्शन और LLM hybrid mode

  • Marker, Llamaparse, Mathpix जैसी cloud services और अन्य open source टूल्स की तुलना में अनुकूल benchmark परिणाम दिखाता है
  • README में पूरा performance result single PDF page को serial execution में चलाने के आधार पर है
  • batch mode में यह और तेज़ है, और H100 पर 25 pages/second throughput की उम्मीद है
  • सर्वोच्च सटीकता के लिए --use_llm फ़्लैग के साथ LLM का उपयोग किया जा सकता है
    • कई pages में फैली टेबल merge करना
    • inline math को प्रोसेस करना
    • टेबल formatting में सुधार
    • फ़ॉर्म से value extract करना
  • LLM hybrid mode में table benchmark accuracy, केवल Marker या केवल Gemini Flash से अधिक है

इंस्टॉलेशन और बुनियादी उपयोग

  • Python 3.10+ और PyTorch की ज़रूरत है
  • PDF-केंद्रित इंस्टॉलेशन: 
    pip install marker-pdf
  • PDF के अलावा अन्य document format प्रोसेस करने के लिए अतिरिक्त dependency इंस्टॉल करें 
    pip install marker-pdf[full]
  • single file conversion: 
    marker_single /path/to/file.pdf
  • folder स्तर पर multiple file conversion: 
    marker /path/to/input/folder
  • कई GPU पर conversion: 
    NUM_DEVICES=4 NUM_WORKERS=15 marker_chunk_convert ../pdf_in ../md_out
    • NUM_DEVICES उपयोग किए जाने वाले GPU की संख्या है, और यह 2 या उससे अधिक होनी चाहिए
    • NUM_WORKERS प्रति GPU parallel process की संख्या है

प्रमुख CLI options

  • --page_range TEXT: प्रोसेस किए जाने वाले page number और range तय करता है
  • --output_format [markdown|json|html|chunks]: output format तय करता है
  • --output_dir PATH: output file save directory तय करता है
  • --paginate_output: page number और separator जोड़कर output देता है
  • --use_llm: LLM के साथ सटीकता बढ़ाता है
  • --force_ocr: पूरे document पर OCR को force करता है, और inline math को भी सही फ़ॉर्मैट करता है
  • --block_correction_prompt: LLM mode में Marker output correction के लिए prompt तय करता है
  • --strip_existing_ocr: मौजूदा OCR text हटाकर surya से दोबारा OCR करता है
  • --redo_inline_math: --use_llm के साथ inline math conversion quality बढ़ाता है
  • --disable_image_extraction: PDF से इमेज extract नहीं करता
  • --converter_cls: डिफ़ॉल्ट marker.converters.pdf.PdfConverter या केवल table के लिए marker.converters.table.TableConverter चुनता है
  • --llm_service: --use_llm के साथ LLM service तय करता है, डिफ़ॉल्ट marker.services.gemini.GoogleGeminiService है
  • --workers: concurrent conversion worker की संख्या तय करता है
    • प्रति worker अधिकतम 5GB VRAM, औसतन 3.5GB VRAM उपयोग होता है

Python API और internal block manipulation

  • PdfConverter के साथ Python से सीधे conversion किया जा सकता है 
    from marker.converters.pdf import PdfConverter
from marker.models import create_model_dict
from marker.output import text_from_rendered

converter = PdfConverter(
    artifact_dict=create_model_dict(),
)
rendered = converter("FILEPATH")
text, _, images = text_from_rendered(rendered)
  • Markdown output का rendered, markdown, metadata, images properties रखता है
  • JSON output का rendered, children, block_type, metadata रखता है
  • ConfigParser से output format, processor, renderer, LLM service आदि configure किए जा सकते हैं
  • document page और block की tree से बना होता है, और page के भीतर फिर block हो सकते हैं
  • contained_blocks का उपयोग करके फ़ॉर्म जैसे specific block को programmatically extract किया जा सकता है

converter के प्रकार

  • PdfConverter: पूरे PDF को बदलने वाला डिफ़ॉल्ट converter है
  • TableConverter: केवल टेबल extract और convert करता है
    • force_layout_block=Table देने पर layout detection से बचते हुए सभी pages को table माना जाता है
    • output_format=json उपयोग करने पर cell bounding box भी मिल सकते हैं
  • OCRConverter: केवल OCR चलाता है
    • --keep_chars सेट करने पर individual character और bounding box बनाए रखता है
  • ExtractionConverter: beta स्थिति वाला structured extraction converter है
    • पहले LLM service configuration चाहिए
    • यह JSON output में extracted values लौटाता है
    • पिछले run के original_markdown को existing_markdown के रूप में देने पर document re-parsing को छोड़ा जा सकता है

output formats

  • Markdown output:
    • इमेज लिंक
    • formatted table
    • $$ में लिपटे LaTeX समीकरण
    • triple backticks code block
    • footnote के लिए superscript
  • HTML output:
    • img tag इमेज
    • <math> tag समीकरण
    • pre tag code
  • JSON output:
    • pages को list के रूप में दिखाता है, और हर page internal Marker schema का block होता है
    • इसमें id, block_type, html, polygon, children keys होती हैं
    • child block में अतिरिक्त section_hierarchy, images होती हैं
    • block structure tree के रूप में होता है
  • Chunks output:
    • JSON जैसा है, लेकिन सब कुछ एक single list में flatten कर देता है
    • हर block का पूरा HTML शामिल होता है, इसलिए RAG के लिए chunking में लचीले ढंग से उपयोग हो सकता है
  • सभी output format metadata लौटाते हैं
    • गणना की गई PDF table of contents यानी table_of_contents
    • page-वार text extraction method और block count वाला page_stats

समर्थित LLM services

  • --use_llm के साथ चुनी जा सकने वाली services:
    • Gemini: डिफ़ॉल्ट रूप से Gemini developer API उपयोग करता है और --gemini_api_key चाहिए
    • Google Vertex: --vertex_project_id चाहिए और marker.services.vertex.GoogleVertexService निर्दिष्ट करना होता है
    • Ollama: local model उपयोग करता है, और --ollama_base_url, --ollama_model सेट करना होता है
    • Claude: --claude_api_key, --claude_model_name सेट करना होता है
    • OpenAI: OpenAI-compatible endpoint सपोर्ट करता है, और --openai_api_key, --openai_model, --openai_base_url सेट करना होता है
    • Azure OpenAI: --azure_endpoint, --azure_api_key, --deployment_name सेट करना होता है

internal architecture और extension points

  • Marker deep learning model pipeline के रूप में काम करता है
    • text extraction, और ज़रूरत पड़ने पर OCR
    • page layout detection और reading order detection
    • हर block की सफ़ाई और formatting
    • ज़रूरत पड़ने पर LLM से quality सुधार
    • block combine करना और पूरे text की post-processing
  • OCR और layout से जुड़े चरणों में surya का उपयोग होता है
  • equation-related formatting के लिए texify उपयोग होता है
  • मुख्य components:
    • Providers: PDF जैसे source file से जानकारी देते हैं
    • Builders: शुरुआती document block बनाते हैं और text भरते हैं
    • Processors: table formatter की तरह specific block को प्रोसेस करते हैं
    • Renderers: block को output format में render करते हैं
    • Schema: सभी block type की classes
    • Converters: पूरा end-to-end pipeline चलाते हैं
  • processing behavior बदलने के लिए processors को override करें
  • नया output format जोड़ने के लिए नया renderer लिखें
  • नया input format जोड़ने के लिए नया provider लिखें

API server और deployment

  • एक सरल FastAPI server चलाया जा सकता है 
    pip install -U uvicorn fastapi python-multipart
marker_server --port 8001
  • server localhost:8001 पर उपलब्ध होगा, और localhost:8001/docs पर endpoint options देखे जा सकते हैं
  • यह API server कोई मजबूत API नहीं है और केवल छोटे पैमाने के उपयोग के लिए बनाया गया है
  • यदि अधिक robust conversion options चाहिए, तो hosted Datalab API का उपयोग किया जा सकता है
  • deployment examples में Modal के माध्यम से web endpoint deployment शामिल है

समस्या निवारण

  • accuracy समस्या हो तो --use_llm के साथ LLM उपयोग करें
    • इस स्थिति में Gemini API key को GOOGLE_API_KEY के रूप में सेट करना होगा
  • अगर text टूटा हुआ दिखे, तो force_ocr से document पर दोबारा OCR चलाएँ
  • TORCH_DEVICE से उपयोग होने वाला torch device force किया जा सकता है
  • memory error आने पर workers की संख्या कम करें या लंबे PDF को कई files में बाँटें
  • debug option detected layout और text वाली page image, तथा bounding box जानकारी वाली JSON file save करता है

benchmark परिणाम

  • full PDF conversion benchmark के लिए common crawl से निकाले गए single PDF pages से बने benchmark set का उपयोग किया गया
  • score, ground truth text segment के साथ alignment heuristic और LLM-as-judge तरीके से निकाले गए
  • full PDF conversion results:
    • marker: औसत समय 2.83837, heuristic 95.6709, LLM 4.23916
    • llamaparse: औसत समय 23.348, heuristic 84.2442, LLM 3.97619
    • mathpix: औसत समय 6.36223, heuristic 86.4281, LLM 4.15626
    • docling: औसत समय 3.69949, heuristic 86.7073, LLM 3.70429
  • marker और docling H100 पर चलाए गए, जबकि llamaparse और mathpix cloud services का उपयोग करते हैं
  • लंबे PDF throughput benchmark के लिए Think Python का उपयोग किया गया
    • marker: प्रति page 0.18 सेकंड
    • प्रति document 43.42 सेकंड
    • VRAM 3.17GB
    • H100 पर 22 individual process चलाए जा सकते हैं, इसलिए 122 pages/second throughput की उम्मीद है
  • table conversion benchmark में FinTabNet test split की HTML representation की तुलना की गई
    • marker: औसत score 0.816, कुल 99 tables
    • marker w/use_llm: औसत score 0.907, कुल 99 tables
    • gemini: औसत score 0.829, कुल 99 tables
  • FinTabNet और layout model की detection method के अंतर के कारण ground truth से align न हो सकने वाली tables को filter किया गया

सीमाएँ और लाइसेंस

  • PDF एक जटिल format है, इसलिए Marker हमेशा पूरी तरह सही काम नहीं कर सकता
  • ज्ञात सीमाएँ:
    • nested table और form वाले बहुत जटिल layout काम नहीं कर सकते
    • form rendering अच्छी तरह न हो सकती है
  • --use_llm और --force_ocr फ़्लैग देने पर इन समस्याओं का अधिकांश हिस्सा हल हो सकता है
  • model weights modified AI Pubs OpenRAIL-M लाइसेंस के तहत हैं
    • research, personal use, और funding/revenue $2M से कम वाले startup के लिए मुफ़्त हैं
  • code GPL लाइसेंस के तहत है
  • व्यापक commercial लाइसेंस या GPL आवश्यकताओं को हटाने के लिए pricing page देखें

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

1 टिप्पणियां

 
GN⁺ 2023-12-02
Hacker News की राय

  • पूरे repo में Nougat से तुलना करने का तरीका थोड़ा उलझाने वाला है
    Nougat अकादमिक दस्तावेज़ों के लिए खास तौर पर trained मॉडल है, और मुझे नहीं लगता कि कभी यह दावा किया गया कि Nougat सबसे अच्छा OCR मॉडल है। benchmark में भी लिखा है कि arXiv दस्तावेज़ों पर Nougat की accuracy ज़्यादा है। साथ ही marker यह कहता है कि वह Nougat की तुलना में formulas कम convert करता है, फिर भी speed comparison Nougat से करता है—यह बात भी थोड़ी खटकती है, क्योंकि Nougat अकादमिक दस्तावेज़ों वाला मॉडल है
    अगर गणित वाले PDF का OCR करना हो तो Nougat ज़रूर आज़माने लायक है। Python package के रूप में इसे install करना आसान है, और एक ही command से formulas, text, tables आदि को .mmd file में extract कर देता है। निजी उपयोग के लिए speed भी ठीक है; मेरे 4 साल पुराने i5 laptop पर सिर्फ CPU से 6-page document convert करने में करीब 30 सेकंड लगे

    • दो चीज़ों की तुलना करने का मतलब यह नहीं कि पुरानी चीज़ को सबसे बेहतर बताकर promote किया गया था
      यह तो नए tool को किसी परिचित चीज़ के साथ side-by-side देखने का तरीका भर है। जैसा आपने कहा, Nougat install और run करना आसान है, इसलिए उसे comparison target बनाना स्वाभाविक है। comparison में और ज़्यादा libraries शामिल हों तो बेशक और अच्छा व उपयोगी होगा
    • RPG rulebook PDF को Nougat कितनी अच्छी तरह handle करेगा, यह जानने की उत्सुकता है
      मैं ऐसा OCR model ढूंढ रहा हूं जो RPG books के कुछ हिस्सों को Markdown में बदलने में मदद करे। संभव हो तो bold या italics जैसी emphasis भी वैसी ही बनी रहे तो अच्छा होगा
      text, numbers और mathematical symbols का मेल technical/academic documents जैसा दिखता है, लेकिन अजीब formatting, margins में text boxes, और बहुत सारे diagrams अक्सर मिले-जुले रहते हैं
    • मैं लेखक हूं। मेरा use case scientific PDFs का bulk conversion है, इसलिए Nougat सबसे अच्छा समाधान था, और इसी वजह से उसे basic comparison target बनाया
      नीचे simple text extraction से भी तुलना की है। Nougat एक शानदार model है और कई PDFs को अच्छी तरह convert करता है, लेकिन मुझे कुछ तेज़ और ज़्यादा generalizable चाहिए था
    • मैं PDF के अंदर table format में मौजूद financial statements extract करना चाहता हूं; क्या Nougat ऐसे use case के लिए भी suitable होगा?

  • ऐसे tools के impact को कम करके नहीं आंकना चाहिए। क्योंकि यह “पढ़ने के लिए अच्छा, लेकिन distribution के लिए खराब” format में फंसे भारी-भरकम ज्ञान को आज़ाद करने का काम है
    सच में उत्साहित हूं। अगर pipeline बने तो अच्छा होगा: सभी PDFs → सबको Markdown में convert → सबको archive.org पर preserve

    • preservation के लिहाज़ से वह pipeline सही नहीं लगती। बेहतर क्रम होगा: सभी PDFs → original preserve → Markdown conversion
      इससे bugs fix होने और improvements आने पर conversion फिर से चलाया जा सकता है। आम तौर पर archival preservation में source material के जितना करीब हो सके, उसी रूप में store करना पसंद किया जाता है। उसके बाद के सारे conversions केवल data loss पैदा कर सकते हैं
    • PDF दरअसल distribution format के तौर पर बेहतरीन है
      end user जो document देखता है, उसे generate करने में इस्तेमाल raw data को आप अपनी पसंद के format में अदृश्य रूप से embed कर सकते हैं। उदाहरण के लिए, अगर PrinceXML से HTML render करके PDF बनाया जा रहा हो, तो text, graphs, charts आदि बनाने में इस्तेमाल किया गया original JSON PDF के अंदर रखा जा सकता है। बेशक ज़्यादातर लोग असल में ऐसा नहीं करते, लेकिन यह specification की गलती नहीं है
    • मैं लेखक हूं। इस tool को बनाने की एक वजह ठीक यही है
      https://github.com/VikParuchuri/libgen_to_txt भी देखने लायक है। अभी इसे marker के साथ integrate नहीं किया है, और फिलहाल simple text extraction इस्तेमाल करता है
    • इस तरह के tools की मांग बहुत ज़्यादा है। खासकर बड़े organizations में, जहां कई तरह के PDF documents बहुत होते हैं, रुचि होना स्वाभाविक है
      needs या use cases के सिर्फ कुछ हिस्से भी cover हों, तो भी अगर यह ठीक से काम करे तो बेहद उपयोगी होगा
    • accessibility के लिहाज़ से भी यह बहुत काम का है
      PDF accessibility को सही ढंग से लागू करना बहुत बड़ा काम है, और अगर कर भी दिया जाए, तो संभावना है कि user का PDF viewer ज़रूरी standards support न करे

  • weekend पर खुद इसे आज़माना पड़ेगा
    मैं अक्सर अज्ञात sources से आए RPG PDF scans को हाथ से transcribe करता हूं, जिनमें OCR नहीं हुआ होता ताकि selectable text न हो, या हुआ भी हो तो quality खराब होती है
    copy-paste errors ठीक करने या OCR से text बनाने के बाद errors ठीक करने की बजाय कई बार सीधे खुद type करना सचमुच ज़्यादा तेज़ होता है
    official PDF में भी formatting अक्सर बिगड़ जाती है, और शब्दों के बीच double/triple spaces या tabs आ जाते हैं। अगर यह ठीक से काम करे, तो वाकई बहुत समय बचा सकता है

    • मेरे मन में भी यही use case था। मैंने एक किताब पर पहले ही try किया, लेकिन results बहुत अच्छे नहीं थे
      tables और text boxes काफ़ी बिगड़ गए। tables के screenshots लेकर ChatGPT में paste करके Markdown table conversion करवाने पर काफी अच्छे results मिले। थोड़ा prompt दे दें, जैसे “row-wise पढ़ो। column headers X, Y, Z हैं। X text है, Y number है, Z word है”, तो irregular tables भी handle हो गए
    • RPG-related material में ऐसी चीज़ें सच में बहुत हैं जो कभी physical media पर आई ही नहीं, और intellectual property के लिहाज़ से orphaned material बन गई हैं—मुझे भी तुरंत यही ख्याल आया

  • आजकल Tesseract OCR कितना ठीक है? पहले इस्तेमाल किया था तो AWS, Azure, GCP के online OCR से काफी पीछे था

    • हाल में काफी updates आए हैं, और git में Tesseract 5 को dependency के रूप में mention किया गया है। पिछली बार इस्तेमाल करने की तुलना में यह शायद काफी बेहतर हो गया हो
      https://github.com/tesseract-ocr/tesseract/releases
      आखिरकार यह use case पर निर्भर करेगा। ऐसे personal tasks के लिए शायद काफी हो, और user info या credit card जैसी चीज़ों की भी ज़रूरत नहीं
    • उम्मीद से बेहतर था, और browser के अंदर performance भी प्रभावशाली लगी
      हालांकि यह resolution को लेकर बहुत sensitive है। image का size एक सीमा से नीचे जाते ही, इंसान को भले वह पढ़ने लायक लगे, Tesseract output बिल्कुल खराब हो गया
    • preprocessing काफी ज़्यादा चाहिए। मैंने केवल GCP solution इस्तेमाल किया है, और मेरे अनुभव में वह बेहतर था
    • हाल ही में इस्तेमाल किया था और यह बहुत basic images पर भी fail हुआ
      iOS Vision API भी try किया, लेकिन वह भी fail हुआ। test case एक किताब के page की साफ़ photo थी

  • लेखक से सवाल: Markdown क्यों? इस टूल का मुश्किल हिस्सा PDF को उच्च सटीकता से parse करना है, उसके बाद उसे किस format में export किया जाता है, यह नहीं लगता
    इसलिए अच्छा होगा अगर user output format चुन सके। अगर उच्च-सटीकता वाला PDF parser हो, तो मैं उसे EPUB बनाने के लिए इस्तेमाल करना चाहूंगा

    • कोई न कोई markup चाहिए जो structural markup को यथासंभव सुरक्षित रखे
      मैं एक university press में ebooks manage करता हूं, और conversion का इंतजार कर रही पुरानी सूची काफी बड़ी है; उनमें से कई में पुराने print editions के सिर्फ page scans बचे हैं। EPUB के रूप में उपलब्ध कराने के लिए यह जानना जरूरी है कि chapter breaks, titles, tables, charts, equations, quotations आदि कहां हैं। बाहरी vendor यह कर सकते हैं, लेकिन कुछ किताबों में conversion cost बिक्री से होने वाली कमाई से ज्यादा होती है। अगर इसका कुछ हिस्सा खुद कर सकें तो अच्छा होगा
    • मैं सहमत हूं कि intermediate format ऐसा होना चाहिए जो plain text के करीब हो और जिसे वैकल्पिक रूप से दूसरे formats में convert किया जा सके
      हालांकि यहां लगता है कि Markdown को intermediate format की तरह इस्तेमाल किया जा रहा है। यह plain text के करीब है, लेकिन साधारण layout information सुरक्षित रख सकता है। व्यवहार में शायद Markdown output लेकर उसे desired final output format में convert करने वाले tool से जोड़कर इस्तेमाल करूंगा
    • Markdown चुनने की वजह यह थी कि equations, tables, bold/italic information और headings को सुरक्षित रखना था
      equations को $/$$ में wrap किया जा सकता है। EPUB output को अभी नहीं देखा है, लेकिन ऐसी requirements की वजह से plain text को बाहर रखा गया

  • एक खास use case है जिसका अभी तक अच्छा solution नहीं मिला: construction documents पढ़ना
    drawings हमेशा PDF में आती हैं, लेकिन DXF(AutoCAD) files parse करते समय यह कहीं बेहतर काम करता था। लेकिन भले ही मैं site का general contractor हूं, architect से DXF भेजने को कहना और उसे पाना हमेशा आसान नहीं होता

  • लंबे लेख मैं मुख्यतः ebook reader पर पढ़ता हूं
    PDF, खासकर multi-column layout, Amazon Kindle या Pocketbook की default capabilities के लिए लगभग nightmare है। लगता है यह tool reading experience को काफी बेहतर कर देगा

  • अच्छा काम है
    Nougat output में दिखने वाले hallucinations कहां से आते हैं, यह सोच रहा था। Think Python example के Nougat output पर नजर डालें तो समझ में आ जाएगा कि मेरा मतलब क्या है
    दोबारा देखा तो लिखा है कि यह LLM से होकर गुजरता है, इसलिए hallucinations अपेक्षित ही थे

    • मुझे लगता है ऐसे tools तब तक जोखिम भरे हैं जब तक text या formatting की hallucination rate उस error rate से कम न हो जाए जो एक सावधान reader document को बार-बार पढ़ते समय करता है
      वह स्तर लगभग 0 के करीब है, और use case के हिसाब से सचमुच 0 होना भी जरूरी हो सकता है। अगर accurate document content महत्वपूर्ण नहीं है तो आम तौर पर ठीक होगा, लेकिन ऐसे documents बड़ी मात्रा में होना आम नहीं लगता जो न अभी किसी के लिए महत्वपूर्ण हों न भविष्य में, फिर भी PDF से ज्यादा accessible होने चाहिए

  • OneNote से मेरे notes migrate करने में मददगार tool जैसा लगता है

    • इसे आजमाना कैसा रहेगा?
      https://help.obsidian.md/import/onenote
    • OneNote में यह कैसे मदद करेगा, यह जानना चाहूंगा

  • काफी दिलचस्प। repo में conversion से पहले/बाद के examples कुछ जोड़ दिए जाएं तो अच्छा होगा
    जानना चाहूंगा कि किस तरह के PDFs के लिए इसे tune किया जा रहा है। handwritten annotations को कैसे handle करता है?