Công nghệ chuyển PDF sang Markdown nhanh với độ chính xác cao

 (github.com/VikParuchuri)
2 điểm bởi GN⁺ 2023-12-02 | 1 bình luận | Chia sẻ qua WhatsApp
  • Marker là công cụ trí tuệ tài liệu có thể chuyển đổi nhanh và chính xác không chỉ PDF mà cả tài liệu hình ảnh, PPTX, DOCX, XLSX, HTML, EPUB sang Markdown, JSON, chunks và HTML
  • Hỗ trợ định dạng bảng, biểu mẫu, công thức, toán nội tuyến, liên kết, tham chiếu, khối mã; trích xuất và lưu hình ảnh; cũng như loại bỏ artifact như đầu trang/cuối trang
  • Để tăng độ chính xác, có thể dùng thêm LLM với --use_llm; mặc định là gemini-2.0-flash, và có thể chọn Gemini, Ollama, Claude, OpenAI, Azure OpenAI...
  • Trong benchmark, Marker ghi nhận trung bình 2.83837 giây cho mỗi trang PDF đơn, điểm heuristic 95.6709, điểm LLM 4.23916; ở chế độ batch trên H100, thông lượng dự kiến là 25 pages/second
  • Cần Python 3.10+ và PyTorch; mã nguồn dùng GPL, còn trọng số mô hình theo giấy phép AI Pubs OpenRAIL-M đã chỉnh sửa, miễn phí cho nghiên cứu, sử dụng cá nhân và startup dưới $2M

Tài liệu và đầu ra mà Marker chuyển đổi

  • Marker chuyển tài liệu sang Markdown, JSON, chunks và HTML
  • Định dạng đầu vào gồm PDF, hình ảnh, PPTX, DOCX, XLSX, HTML, EPUB và xử lý tài liệu ở mọi ngôn ngữ
  • Phạm vi xử lý thành phần tài liệu:
    • bảng, biểu mẫu, công thức, toán nội tuyến
    • liên kết, tham chiếu, khối mã
    • trích xuất và lưu hình ảnh
    • loại bỏ đầu trang, cuối trang và các artifact khác
  • Có thể mở rộng bằng logic và định dạng riêng
  • Có thể thực hiện trích xuất có cấu trúc nếu cung cấp JSON schema; tính năng này đang ở beta
  • Chạy trên GPU, CPU và MPS

Nền tảng được quản lý bởi Datalab

  • Nền tảng được quản lý bởi Datalab chạy mô hình mã nguồn mở mới nhất Chandra
  • Chandra được giới thiệu là có độ chính xác cao hơn Marker, mặc định không lưu giữ dữ liệu, đồng thời cung cấp SOC 2 Type 2 và BAA tùy chỉnh
  • Dịch vụ xử lý batch cho workload dung lượng lớn từng xử lý hơn 200M trang mỗi tuần
  • Khi đăng ký sẽ được $5 credit miễn phí, và cũng có playground công khai
  • Self-hosting cho mục đích thương mại cần giấy phép; giấy phép on-premise cần liên hệ riêng

Hiệu năng và chế độ hybrid với LLM

  • Marker đưa ra kết quả benchmark thuận lợi so với các dịch vụ cloud như Llamaparse, Mathpix và các công cụ mã nguồn mở khác
  • Kết quả hiệu năng đầy đủ trong README dựa trên việc chạy tuần tự từng trang PDF đơn
  • Ở chế độ batch, tốc độ nhanh hơn, với thông lượng dự kiến 25 pages/second trên H100
  • Để có độ chính xác cao nhất, có thể dùng thêm LLM bằng cờ --use_llm
    • gộp bảng kéo dài qua nhiều trang
    • xử lý toán nội tuyến
    • cải thiện định dạng bảng
    • trích xuất giá trị từ biểu mẫu
  • Chế độ hybrid với LLM cho độ chính xác benchmark bảng cao hơn so với chỉ Marker hoặc chỉ Gemini Flash

Cài đặt và cách dùng cơ bản

  • Cần Python 3.10+ và PyTorch
  • Cài đặt tập trung cho PDF: 
    pip install marker-pdf
  • Để xử lý các định dạng tài liệu ngoài PDF, cài thêm dependency 
    pip install marker-pdf[full]
  • Chuyển đổi một tệp đơn: 
    marker_single /path/to/file.pdf
  • Chuyển đổi nhiều tệp theo thư mục: 
    marker /path/to/input/folder
  • Chuyển đổi trên nhiều GPU: 
    NUM_DEVICES=4 NUM_WORKERS=15 marker_chunk_convert ../pdf_in ../md_out
    • NUM_DEVICES là số GPU sẽ dùng và phải từ 2 trở lên
    • NUM_WORKERS là số tiến trình song song trên mỗi GPU

Các tùy chọn CLI chính

  • --page_range TEXT: chỉ định số trang và phạm vi cần xử lý
  • --output_format [markdown|json|html|chunks]: chỉ định định dạng đầu ra
  • --output_dir PATH: chỉ định thư mục lưu tệp đầu ra
  • --paginate_output: xuất kèm số trang và đường phân cách
  • --use_llm: tăng độ chính xác bằng LLM
  • --force_ocr: ép áp dụng OCR cho toàn bộ tài liệu và định dạng toán nội tuyến phù hợp
  • --block_correction_prompt: chỉ định prompt để hiệu chỉnh đầu ra Marker trong chế độ LLM
  • --strip_existing_ocr: xóa văn bản OCR hiện có và OCR lại bằng surya
  • --redo_inline_math: nâng chất lượng chuyển đổi toán nội tuyến khi dùng cùng --use_llm
  • --disable_image_extraction: không trích xuất hình ảnh từ PDF
  • --converter_cls: chọn marker.converters.pdf.PdfConverter mặc định hoặc marker.converters.table.TableConverter chỉ dành cho bảng
  • --llm_service: chỉ định dịch vụ LLM khi dùng --use_llm; mặc định là marker.services.gemini.GoogleGeminiService
  • --workers: chỉ định số worker chuyển đổi đồng thời
    • mỗi worker dùng tối đa 5GB VRAM, trung bình 3.5GB VRAM

Python API và thao tác block nội bộ

  • Có thể chuyển đổi trực tiếp trong Python bằng PdfConverter 
    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)
  • rendered của đầu ra Markdown có các thuộc tính markdown, metadata, images
  • rendered của đầu ra JSON có children, block_type, metadata
  • Có thể cấu hình định dạng đầu ra, processor, renderer, dịch vụ LLM... bằng ConfigParser
  • Tài liệu được tổ chức thành cây gồm trang và block; mỗi trang lại có thể chứa các block
  • Có thể dùng contained_blocks để trích xuất theo chương trình chỉ các block cụ thể như biểu mẫu

Các loại converter

  • PdfConverter: converter mặc định để chuyển toàn bộ PDF
  • TableConverter: chỉ trích xuất và chuyển đổi bảng
    • nếu chỉ định force_layout_block=Table thì sẽ bỏ qua phát hiện layout và giả định mọi trang đều là bảng
    • dùng output_format=json có thể lấy thêm bounding box của ô
  • OCRConverter: chỉ chạy OCR
    • nếu đặt --keep_chars sẽ giữ lại từng ký tự và bounding box
  • ExtractionConverter: converter trích xuất có cấu trúc đang ở trạng thái beta
    • trước tiên cần cấu hình dịch vụ LLM
    • trả về giá trị trích xuất ở đầu ra JSON
    • nếu truyền original_markdown từ lần chạy trước vào existing_markdown thì có thể bỏ qua việc parse lại tài liệu

Định dạng đầu ra

  • Đầu ra Markdown:
    • liên kết hình ảnh
    • bảng đã định dạng
    • công thức LaTeX bọc bằng $$
    • khối mã triple backticks
    • superscript cho chú thích cuối trang
  • Đầu ra HTML:
    • hình ảnh bằng thẻ img
    • công thức bằng thẻ <math>
    • mã bằng thẻ pre
  • Đầu ra JSON:
    • biểu diễn trang dưới dạng danh sách, mỗi trang là một block theo schema nội bộ của Marker
    • có các khóa id, block_type, html, polygon, children
    • block con có thêm section_hierarchy, images
    • cấu trúc block có dạng cây
  • Đầu ra Chunks:
    • tương tự JSON nhưng làm phẳng mọi thứ thành một danh sách duy nhất
    • bao gồm toàn bộ HTML của từng block, có thể dùng linh hoạt cho chunking phục vụ RAG
  • Mọi định dạng đầu ra đều trả về metadata
    • table_of_contents là mục lục PDF được tính toán
    • page_stats chứa phương thức trích xuất văn bản và số lượng block theo từng trang

Các dịch vụ LLM được hỗ trợ

  • Các dịch vụ có thể chọn khi dùng --use_llm:
    • Gemini: mặc định dùng Gemini developer API và cần --gemini_api_key
    • Google Vertex: cần --vertex_project_id và chỉ định marker.services.vertex.GoogleVertexService
    • Ollama: dùng mô hình cục bộ, cấu hình --ollama_base_url, --ollama_model
    • Claude: cấu hình --claude_api_key, --claude_model_name
    • OpenAI: hỗ trợ endpoint tương thích OpenAI, cấu hình --openai_api_key, --openai_model, --openai_base_url
    • Azure OpenAI: cấu hình --azure_endpoint, --azure_api_key, --deployment_name

Kiến trúc nội bộ và điểm mở rộng

  • Marker hoạt động theo pipeline mô hình deep learning
    • trích xuất văn bản, OCR khi cần
    • phát hiện layout trang và thứ tự đọc
    • làm sạch và định dạng từng block
    • cải thiện chất lượng bằng LLM khi cần
    • gộp block và hậu xử lý toàn bộ văn bản
  • Các bước liên quan đến OCR và layout sử dụng surya
  • Việc định dạng liên quan đến công thức dùng texify
  • Các thành phần cốt lõi:
    • Providers: cung cấp thông tin từ tệp nguồn như PDF
    • Builders: tạo block tài liệu ban đầu và điền văn bản
    • Processors: xử lý các block cụ thể như formatter cho bảng
    • Renderers: render block sang định dạng đầu ra
    • Schema: lớp cho mọi loại block
    • Converters: chạy toàn bộ pipeline end-to-end
  • Có thể thay đổi hành vi xử lý bằng cách ghi đè processors
  • Có thể thêm định dạng đầu ra mới bằng cách viết renderer mới
  • Có thể thêm định dạng đầu vào mới bằng cách viết provider mới

API server và triển khai

  • Có thể chạy một FastAPI server đơn giản 
    pip install -U uvicorn fastapi python-multipart
marker_server --port 8001
  • Server có thể truy cập tại localhost:8001, và có thể xem các tùy chọn endpoint tại localhost:8001/docs
  • API server này không phải API mạnh mẽ và chỉ dành cho mức sử dụng nhỏ
  • Nếu cần tùy chọn chuyển đổi ổn định hơn, có thể dùng Datalab API được host sẵn
  • Ví dụ triển khai có gồm cả triển khai web endpoint qua Modal

Khắc phục sự cố

  • Nếu có vấn đề về độ chính xác, hãy dùng LLM với --use_llm
    • khi đó cần đặt Gemini API key vào GOOGLE_API_KEY
  • Nếu thấy văn bản bị lỗi, hãy OCR lại tài liệu bằng force_ocr
  • Có thể ép chỉ định torch device cần dùng bằng TORCH_DEVICE
  • Nếu gặp lỗi thiếu bộ nhớ, có thể giảm số worker hoặc chia PDF dài thành nhiều tệp
  • Tùy chọn debug sẽ lưu ảnh trang kèm layout và văn bản được phát hiện, cùng tệp JSON có thông tin bounding box

Kết quả benchmark

  • Benchmark chuyển đổi PDF đầy đủ dùng benchmark set được tạo bằng cách trích xuất từng trang PDF đơn từ common crawl
  • Điểm số được tính bằng heuristic căn chỉnh với các đoạn văn bản ground truth, cùng phương pháp LLM-as-judge
  • Kết quả chuyển đổi PDF đầy đủ:
    • marker: thời gian trung bình 2.83837, heuristic 95.6709, LLM 4.23916
    • llamaparse: thời gian trung bình 23.348, heuristic 84.2442, LLM 3.97619
    • mathpix: thời gian trung bình 6.36223, heuristic 86.4281, LLM 4.15626
    • docling: thời gian trung bình 3.69949, heuristic 86.7073, LLM 3.70429
  • marker và docling được chạy trên H100, còn llamaparse và mathpix là dịch vụ cloud
  • Benchmark thông lượng cho PDF dài dùng Think Python
    • marker: 0.18 giây mỗi trang
    • 43.42 giây mỗi tài liệu
    • VRAM 3.17GB
    • có thể chạy 22 tiến trình riêng lẻ trên H100, với thông lượng dự kiến 122 pages/second
  • Benchmark chuyển đổi bảng so sánh biểu diễn HTML của test split FinTabNet
    • marker: điểm trung bình 0.816, tổng 99 bảng
    • marker w/use_llm: điểm trung bình 0.907, tổng 99 bảng
    • gemini: điểm trung bình 0.829, tổng 99 bảng
  • Do khác biệt giữa FinTabNet và cách phát hiện của mô hình layout, các bảng không thể căn chỉnh với ground truth được lọc bỏ

Hạn chế và giấy phép

  • PDF là định dạng khó xử lý nên Marker không phải lúc nào cũng hoạt động hoàn hảo
  • Các hạn chế đã biết:
    • layout rất phức tạp có bảng lồng nhau và biểu mẫu có thể không hoạt động
    • việc render biểu mẫu có thể không tốt
  • Có thể giải quyết phần lớn các vấn đề này bằng cách truyền cờ --use_llm và --force_ocr
  • Trọng số mô hình dùng giấy phép AI Pubs OpenRAIL-M đã chỉnh sửa
    • miễn phí cho nghiên cứu, sử dụng cá nhân và startup có funding/revenue dưới $2M
  • Mã nguồn dùng giấy phép GPL
  • Giấy phép thương mại rộng hơn hoặc loại bỏ yêu cầu GPL được xử lý tại pricing page

Bài viết liên quan

1 bình luận

 
GN⁺ 2023-12-02
Ý kiến trên Hacker News

  • Cách so sánh với Nougat xuyên suốt repo hơi gây bối rối
    Nougat là một mô hình được huấn luyện chuyên biệt cho tài liệu học thuật, và tôi không nghĩ từng có ai tuyên bố Nougat là mô hình OCR tốt nhất. Ngay cả trong benchmark cũng nói rằng với tài liệu arXiv thì độ chính xác của Nougat cao hơn. Ngoài ra, việc nói rằng marker chuyển đổi công thức kém hơn Nougat nhưng lại so sánh tốc độ với Nougat cũng hơi đáng tiếc, vì đây là mô hình dành cho tài liệu học thuật
    Nếu muốn OCR PDF có toán học thì Nougat rất đáng thử. Cài đặt dễ bằng gói Python, và chỉ với một lệnh có thể trích xuất công thức, văn bản, bảng, v.v. thành tệp .mmd. Với nhu cầu cá nhân, tốc độ cũng ổn: trên laptop i5 4 năm tuổi, chỉ dùng CPU, mất khoảng 30 giây để chuyển đổi tài liệu 6 trang

    • So sánh hai thứ với nhau không có nghĩa là thứ hiện có từng được quảng bá là tốt nhất
      Đó chỉ là cách đặt công cụ mới cạnh một thứ quen thuộc để dễ nhìn nhận. Như đã nói, Nougat dễ cài và chạy, nên lấy làm đối tượng so sánh là tự nhiên. Tất nhiên nếu phần so sánh có thêm nhiều thư viện hơn thì sẽ càng tốt và hữu ích
    • Tôi tò mò không biết Nougat xử lý PDF sách luật RPG tốt đến đâu
      Tôi đang tìm một mô hình OCR có thể giúp chuyển một phần sách RPG sang Markdown. Nếu được, tôi cũng muốn các kiểu nhấn mạnh như in đậm hay in nghiêng được giữ nguyên
      Tổ hợp văn bản, số và ký hiệu toán học trông khá giống tài liệu kỹ thuật/học thuật, nhưng thường lẫn nhiều định dạng lạ, hộp văn bản ở lề và rất nhiều bảng biểu
    • Tôi là tác giả. Trường hợp sử dụng của tôi là chuyển đổi hàng loạt PDF khoa học, nên Nougat là giải pháp tốt nhất, vì vậy tôi lấy nó làm đối tượng so sánh mặc định
      Ở phía dưới tôi cũng đã so sánh với trích xuất văn bản đơn giản. Nougat là một mô hình tuyệt vời và chuyển đổi tốt nhiều PDF, nhưng tôi muốn thứ gì đó nhanh hơn và có khả năng khái quát hóa tốt hơn
    • Tôi muốn trích xuất báo cáo tài chính ở dạng bảng trong PDF; Nougat có phù hợp cho mục đích đó không?

  • Không nên đánh giá thấp tác động của những công cụ như thế này. Vì đây là việc giải phóng một khối lượng tri thức khổng lồ bị mắc kẹt trong định dạng “tốt để đọc nhưng tệ để phân phối”
    Thật sự rất đáng mong đợi. Sẽ rất hay nếu có một pipeline: tất cả PDF → chuyển tất cả sang Markdown → lưu trữ tất cả trên archive.org

    • Nếu nhằm mục đích lưu trữ, pipeline đó có vẻ không phù hợp. Thứ tự tốt hơn sẽ là tất cả PDF → lưu trữ bản gốc → chuyển đổi sang Markdown
      Như vậy mỗi khi lỗi được sửa và có cải tiến, ta có thể chạy lại quá trình chuyển đổi. Trong bảo tồn tư liệu, thông thường người ta ưu tiên lưu ở dạng gần với tài liệu gốc nhất có thể, vì mọi chuyển đổi về sau chỉ có thể gây mất dữ liệu
    • PDF thực ra là một định dạng phân phối rất tốt
      Nó có thể nhúng ẩn dữ liệu thô dùng để tạo tài liệu mà người dùng cuối nhìn thấy, theo định dạng bạn muốn. Ví dụ nếu dùng PrinceXML để render HTML thành PDF, bạn có thể đưa JSON gốc dùng để tạo toàn bộ văn bản, đồ thị, biểu đồ, v.v. vào trong PDF. Dĩ nhiên đa số không thực sự làm vậy, nhưng đó không phải lỗi của đặc tả
    • Tôi là tác giả. Đây chính là một trong những lý do tôi tạo công cụ này
      https://github.com/VikParuchuri/libgen_to_txt cũng đáng tham khảo. Tôi chưa tích hợp nó với marker, hiện tại vẫn dùng trích xuất văn bản đơn giản
    • Nhu cầu đối với loại công cụ này là cực lớn. Đặc biệt các tổ chức lớn có nhiều loại tài liệu PDF đa dạng chắc chắn sẽ rất quan tâm
      Dù chỉ xử lý được một phần nhu cầu hay trường hợp sử dụng, nếu hoạt động tốt thì nó sẽ rất hữu ích
    • Nó cũng rất hữu dụng về mặt khả năng tiếp cận
      Làm cho PDF đáp ứng đúng chuẩn truy cập là một công việc khổng lồ, và ngay cả khi làm đúng, trình xem PDF mà người dùng sử dụng vẫn có khả năng không hỗ trợ các tiêu chuẩn cần thiết

  • Cuối tuần này tôi sẽ tự thử dùng
    Tôi thường xuyên phải chép tay các bản scan PDF RPG không rõ nguồn gốc, hoặc chưa được OCR nên không có văn bản có thể chọn, hoặc có OCR nhưng chất lượng kém
    Có lúc gõ lại trực tiếp đúng nghĩa là nhanh hơn so với sửa lỗi sao chép/dán hoặc sửa lỗi sau khi OCR thành văn bản
    Ngay cả PDF chính thức cũng thường bị hỏng định dạng, khiến giữa các từ có hai, ba dấu cách hoặc tab. Nếu dùng được tử tế thì có vẻ sẽ tiết kiệm được rất nhiều thời gian

    • Tôi cũng đã nghĩ đến trường hợp sử dụng này. Tôi đã thử với một cuốn sách, nhưng kết quả không tốt lắm
      Bảng và hộp văn bản bị hỏng khá nhiều. Chụp ảnh màn hình bảng rồi dán vào ChatGPT để yêu cầu chuyển thành bảng Markdown thì cho kết quả khá tốt. Nếu gợi ý thêm một chút kiểu như “đọc theo từng hàng. Tiêu đề cột là X, Y, Z. X là văn bản, Y là số, Z là từ” thì nó cũng xử lý được cả những bảng không đều
    • Trong tài liệu liên quan đến RPG có rất nhiều thứ chưa từng được phát hành dưới dạng vật lý và đã trở thành tư liệu mồ côi về quyền sở hữu trí tuệ, nên tôi cũng nghĩ ngay đến điều đó

  • Dạo này Tesseract OCR ổn đến mức nào? Trước đây khi tôi dùng thử thì nó kém xa OCR online của AWS, Azure và GCP

    • Gần đây đã có khá nhiều cập nhật, và trong git có nhắc Tesseract 5 là dependency. Có khả năng nó đã khá hơn nhiều so với lần cuối bạn dùng thử
      https://github.com/tesseract-ocr/tesseract/releases
      Cuối cùng chắc vẫn tùy trường hợp sử dụng. Với những việc cá nhân kiểu này, khả năng cao là đủ dùng, và cũng không cần thông tin người dùng hay thẻ tín dụng gì cả
    • Nó tốt hơn tôi tưởng, và hiệu năng trong trình duyệt cũng ấn tượng
      Tuy nhiên nó rất nhạy với độ phân giải. Khi ảnh nhỏ xuống dưới một kích thước nào đó, dù người nhìn vẫn đọc đủ rõ, đầu ra của Tesseract lại trở nên rất tệ
    • Cần khá nhiều tiền xử lý. Tôi chỉ từng dùng giải pháp của GCP, và theo trải nghiệm của tôi thì bên đó tốt hơn
    • Tôi đã dùng thử khá gần đây và nó thất bại ngay cả với những ảnh rất cơ bản
      Tôi cũng thử iOS Vision API nhưng cũng thất bại. Ca kiểm thử là một bức ảnh chụp rõ nét trang sách

  • Câu hỏi dành cho tác giả: tại sao lại là Markdown? Phần khó của công cụ này có vẻ là phân tích PDF với độ chính xác cao, chứ không phải xuất ra định dạng nào sau đó
    Vì vậy sẽ tốt hơn nếu người dùng có thể chọn định dạng đầu ra. Nếu có một trình phân tích PDF chính xác cao, tôi muốn dùng nó để tạo EPUB

    • Cần một dạng markup nào đó để bảo toàn tối đa markup có cấu trúc
      Tôi quản lý sách điện tử tại một nhà xuất bản đại học, có rất nhiều danh mục cũ đang chờ chuyển đổi, và trong số đó không ít cuốn chỉ còn lại bản scan các trang của ấn bản in cũ. Để cung cấp dưới dạng EPUB, cần biết vị trí phân chương, tiêu đề, bảng, biểu đồ, công thức, trích dẫn, v.v. Đơn vị thuê ngoài có thể làm, nhưng với một số sách, chi phí chuyển đổi còn lớn hơn doanh thu bán sách. Nếu có thể tự làm dù chỉ một phần thì tốt
    • Tôi đồng ý rằng định dạng trung gian nên gần với văn bản thuần để có thể tùy chọn chuyển đổi sang các định dạng khác
      Tuy nhiên ở đây có vẻ Markdown đang được dùng làm định dạng trung gian. Nó gần với văn bản thuần nhưng vẫn có thể giữ lại thông tin bố cục đơn giản. Thực tế có lẽ sẽ lấy đầu ra Markdown rồi nối với một công cụ chuyển đổi sang định dạng đầu ra cuối cùng mong muốn
    • Lý do chọn Markdown là vì muốn bảo toàn công thức, bảng, thông tin in đậm/in nghiêng và tiêu đề
      Công thức có thể được bọc bằng $/$$. Tôi chưa xem xét đầu ra EPUB, nhưng vì những yêu cầu này nên văn bản thuần đã bị loại

  • Có một cách dùng đặc thù mà tôi vẫn chưa tìm được giải pháp tốt: đọc tài liệu xây dựng
    Bản vẽ luôn được gửi dưới dạng PDF, trong khi mọi thứ hoạt động tốt hơn nhiều khi phân tích file DXF (AutoCAD). Nhưng ngay cả khi tôi là tổng thầu tại công trường, không phải lúc nào cũng dễ yêu cầu kiến trúc sư gửi DXF

  • Các bài viết dài tôi chủ yếu đọc bằng máy đọc sách điện tử
    PDF, đặc biệt là bố cục nhiều cột, gần như là ác mộng với các tính năng mặc định của Amazon Kindle hay Pocketbook. Công cụ này có vẻ sẽ cải thiện đáng kể trải nghiệm đọc

  • Làm tốt lắm
    Tôi từng thắc mắc ảo giác thấy trong đầu ra của Nougat đến từ đâu. Chỉ cần lướt qua đầu ra Nougat của ví dụ Think Python là hiểu ý tôi
    Nhìn lại thì thấy có ghi là đi qua LLM, nên ảo giác là điều có thể dự đoán

    • Tôi cho rằng các công cụ như vậy vẫn nguy hiểm cho đến khi tỷ lệ ảo giác của văn bản hoặc định dạng thấp hơn tỷ lệ sai sót của một độc giả cẩn thận khi đọc đi đọc lại tài liệu
      Mức đó gần như bằng 0, và tùy mục đích sử dụng, có khi thực sự phải là 0. Nếu nội dung chính xác của tài liệu không quan trọng thì nhìn chung có thể ổn, nhưng có lẽ không thường xuyên tồn tại số lượng lớn tài liệu vừa không quan trọng với bất kỳ ai ở hiện tại hay tương lai, lại vừa cần dễ tiếp cận hơn PDF

  • Có vẻ là công cụ có thể giúp chuyển ghi chú của tôi ra khỏi OneNote

  • Khá thú vị. Có lẽ nên thêm vài ví dụ trước và sau khi chuyển đổi vào repo
    Tôi tò mò công cụ đang được tinh chỉnh cho loại PDF nào. Nó xử lý chú thích viết tay ra sao?