Show HN: Trình phân tích PDF mã nguồn mở dựa trên luật cho RAG

 (github.com/nlmatics)
1 điểm bởi GN⁺ 2024-01-26 | 1 bình luận | Chia sẻ qua WhatsApp
  • nlm-ingestor là mã dịch vụ mà API llmsherpa kết nối sử dụng, cung cấp các trình phân tích tài liệu cho PDF·HTML·Text·DOCX·PPTX và các định dạng khác, được tối ưu cho RAG
  • Trình phân tích PDF sử dụng dữ liệu tọa độ văn bản, đồ họa và phông chữ lấy từ bản Tika đã được nlmatics chỉnh sửa; nếu có trang được quét, có thể tự động áp dụng OCR bằng tùy chọn apply_ocr
  • Các tính năng xử lý PDF bao gồm mức mục và tiểu mục, gộp đoạn văn, liên kết mục-đoạn văn, bảng, danh sách lồng nhau, kết hợp nội dung giữa các trang, loại bỏ header·footer lặp lại, xóa watermark và bounding box OCR
  • So với trình phân tích thị giác dựa trên mô hình, trình phân tích dựa trên luật được mô tả là nhanh hơn 100 lần vì không cần tạo ảnh trang PDF; cách này cũng được xem là thực tế hơn với PDF có lớp văn bản thay vì OCR và các tài liệu dài hàng trăm trang
  • Máy chủ dùng cho phát triển có thể chạy bằng Docker hoặc chạy trực tiếp, còn trong môi trường vận hành thì nên triển khai sau một cổng bảo mật như nginx hoặc cloud gateway

Các trình phân tích tài liệu mà nlm-ingestor cung cấp

  • nlm-ingestor là kho mã dịch vụ mà API llmsherpa có thể kết nối tới
  • Cung cấp nhiều trình phân tích tùy biến cho các định dạng tệp, được tối ưu cho RAG (retrieval augmented generation)

    • PDF

    • HTML

    • Text

      • DOCX, PPTX và các định dạng khác được Apache Tika hỗ trợ

Cách hoạt động và tính năng của trình phân tích PDF

  • Trình phân tích PDF dựa trên luật và sử dụng dữ liệu tọa độ văn bản, đồ họa và phông chữ lấy từ nlm-tika — bản sửa đổi của nlmatics
  • Hoạt động dựa trên lớp văn bản của PDF, và có thể tự động áp dụng OCR cho các trang được quét trong PDF thông qua tùy chọn apply_ocr
  • Tính năng OCR nội bộ dựa trên bản Tika đã được nlmatics chỉnh sửa, sử dụng tesseract
  • Có notebook pdf_visual_ingestor_step_by_step để trực tiếp thử nghiệm trình phân tích PDF
  • Các tính năng của trình phân tích PDF gồm:
    • Nhận diện mục, tiểu mục và từng cấp độ của chúng
    • Gộp nhiều dòng để tạo thành đoạn văn
    • Tạo liên kết giữa mục và đoạn văn
    • Nhận diện bảng và mục chứa bảng
    • Xử lý danh sách và danh sách lồng nhau
    • Kết hợp nội dung kéo dài qua nhiều trang
    • Loại bỏ header và footer lặp lại
    • Xóa watermark
    • Cung cấp bounding box cho kết quả OCR

Xử lý tài liệu HTML·Text·Office

  • Trình phân tích HTML tạo các khối nhận biết bố cục để tạo ra các chunk chất lượng cao hơn, giúp cải thiện hiệu năng RAG
  • Trình phân tích Text suy đoán danh sách, bảng, header và các thành phần khác chỉ từ văn bản, không có thông tin trực quan, thông tin phông chữ hay bounding box
  • DOCX, PPTX và các định dạng khác được Apache Tika hỗ trợ sẽ dùng đầu ra HTML của Tika trước, sau đó được xử lý bằng trình phân tích HTML

Chạy và sử dụng API

  • Quy trình chạy trực tiếp gồm cài Java, chạy máy chủ Tika, cài nlm-ingestor, rồi chạy ingestor
    • Chạy máy chủ Tika: java -jar <path_to_nlm_ingestor>/jars/tika-server-standard-nlm-modified-2.9.2_v2.jar
    • Cài đặt: pip install nlm-ingestor
    • Chạy: python -m nlm_ingestor.ingestion_daemon
  • Có sẵn image Docker trên GitHub Container Registry công khai
    • Tải image: docker pull ghcr.io/nlmatics/nlm-ingestor:latest
    • Ví dụ chạy: docker run -p 5010:5001 ghcr.io/nlmatics/nlm-ingestor:latest-<version>
  • Sau khi máy chủ chạy, có thể dùng thư viện API llmsherpa để lấy các chunk và sử dụng trong dự án LLM
  • Ví dụ llmsherpa_url là http://localhost:5010/api/parseDocument?renderFormat=all
    • Áp dụng OCR: &applyOcr=yes
    • Dùng trình phân tích indent mới với thuật toán khác để gán cấp độ header: &useNewIndentParser=yes
  • Có thể dùng như máy chủ phát triển, nhưng trong môi trường vận hành thì nên triển khai sau một cổng bảo mật như nginx hoặc cloud gateway
  • Mã mẫu để kiểm thử máy chủ bằng trình phân tích llmsherpa có trong notebook test_llmsherpa_api

Vì sao chọn trình phân tích dựa trên luật

  • Nhóm nlmatics đã đánh giá nhiều lựa chọn trong suốt 4 năm, bao gồm cả trình phân tích thị giác dựa trên YOLO do Tom Liu và Yi Zhang phát triển, trước khi chọn trình phân tích dựa trên luật
  • Trình phân tích dựa trên luật nhanh hơn đáng kể so với bất kỳ trình phân tích thị giác nào; phần mô tả kho mã diễn đạt điều này là nhanh hơn 100 lần
    • Trình phân tích thị giác phải tạo ảnh cho mọi trang, ngay cả với PDF có lớp văn bản
    • Trình phân tích thị giác có thể là lựa chọn tốt hơn cho PDF OCR không có lớp văn bản hoặc các PDF nhỏ chủ yếu gồm dữ liệu biểu mẫu
    • Với các PDF lớn có lớp văn bản kéo dài hàng trăm trang, trình phân tích dựa trên luật được xem là thực tế hơn
  • Nếu không dùng tính năng OCR cho PDF thì không cần phần cứng đặc biệt
    • Phần mô tả kho mã cho biết nó có thể chạy cả trên phần cứng từ đầu những năm 2000
  • Mọi trình phân tích, kể cả trình phân tích thị giác, đều có thể phát sinh lỗi; họ cũng cho biết cách sửa lỗi của trình phân tích dựa trên mô hình không đem lại sự hài lòng
    • Nếu thêm nhiều ví dụ vào tập huấn luyện thì độ chính xác của phần đã học trước đó có thể giảm, và đoạn mã vốn chạy tốt có thể trở nên khó đoán
    • Nếu sửa vấn đề của trình phân tích dựa trên mô hình bằng ý tưởng dựa trên luật thì rốt cuộc lại phải viết rất nhiều luật

Bản Tika đã được nlmatics chỉnh sửa

  • Bản Tika do nlmatics chỉnh sửa nằm ở nhánh 2.4.1-nlm
  • Để tiện sử dụng, tệp jar đã biên dịch được đưa sẵn vào thư mục jars/ của kho mã
  • Một số PDF có thể gây lỗi trên máy chủ Java; trong trường hợp đó cần sửa phần mã liên quan rồi biên dịch lại tệp jar
  • Các tệp đã sửa thêm phông chữ và tọa độ cho từng phần tử văn bản trong PDF, đồng thời xóa watermark
    • PDF2XHTML.java
    • AbstractPDF2XHTML.java
  • Thay đổi trong GraphicsStreamProcessor.java nhằm bổ sung đường thẳng và hình chữ nhật, điều này có thể giúp phát hiện bảng
  • Ảnh hưởng của các thay đổi có thể xem ở phần đầu notebook pdf_visual_ingestor_step_by_step
  • Các ý tưởng cho công việc tương lai gồm:
    • Viết wrapper riêng trên pdfbox để loại bỏ phụ thuộc vào các thay đổi của Tika
    • Nâng cấp lên phiên bản Tika mới nhất
    • Chuẩn hóa định dạng HTML trả về để thân thiện hơn với CSS

Bài viết liên quan

1 bình luận

 
GN⁺ 2024-01-26
Ý kiến trên Hacker News

  • Nếu làm việc với các bài báo khoa học thì cũng đáng thêm GROBID: https://github.com/kermitt2/grobid
    Tôi đang dùng cùng với paperetl(https://github.com/neuml/paperetl)

  • Dự án rất hay. Với việc phân tích tài liệu, tôi đã dùng Tika từ lâu vì độ trưởng thành và phạm vi định dạng được hỗ trợ rộng, và đầu ra XHTML giúp ích cho việc chia nhỏ tài liệu phục vụ RAG
    Có ví dụ tại https://neuml.hashnode.dev/build-rag-pipelines-with-txtai và https://neuml.hashnode.dev/extract-text-from-documents
    Nhân tiện, tôi là tác giả chính của txtai(https://github.com/neuml/txtai)

    • Hơi lạc đề một chút, nhưng tôi tò mò Tika so với các thư viện phân tích PDF khác thì thế nào
      pdfminer.six(thứ mà unstructured dùng) có phần phát hiện bố cục khá cơ bản nên đã làm tôi thất vọng vì không phân tích được văn bản nhiều cột, còn MuPDF thì xử lý hoàn hảo
      Hiện tôi đang dùng kết hợp MuPDF + AWS Textract(chủ yếu cho bảng), và muốn biết mọi người đang dùng gì

  • Có vẻ sẽ khá hữu ích. Công ty nơi tôi làm có một công cụ so sánh PDF tên là “PDFC”, đọc PDF và so sánh khác biệt ngữ nghĩa: https://www.inetsoftware.de/products/pdf-content-comparer
    Định dạng PDF vốn rất phức tạp nên việc phân tích có thể khá đau đầu. Chúng tôi đã hỗ trợ phần lớn các tính năng như vậy, nhưng luôn có rất nhiều trường hợp biên nên những cách tiếp cận bổ sung có thể sẽ hữu ích

  • Cơ chế dự phòng Tesseract OCR có vẻ hay
    Giờ đã có khá nhiều file loader cho RAG như langchain, LLMindex, unstructured..., nên tôi tò mò liệu có lý do gì để ưu tiên cái này không. Ví dụ như có cơ sở nào cho thấy điểm benchmark tốt hơn chẳng hạn

    • Công cụ này không build được trên Apple Silicon và cũng không có ARM Docker image nên tôi chưa tự dùng thử
      Nhưng tôi đã thử các công cụ RAG đó cho mục đích phân tích PDF, và chất lượng đầu ra khá thấp. LLM có thể phần nào lách qua vấn đề nên với RAG thì vẫn tạm chạy được, nhưng nếu muốn câu trả lời chất lượng cao hơn với tham chiếu đúng đắn đi kèm, tôi nghĩ tốt nhất là tự dùng parser dựa trên luật. Cuối cùng tôi cũng đã làm vậy, chỉ là dựa trên MuPDF chứ không phải Tika
      Có thể tác giả của công cụ này cũng có suy nghĩ tương tự
    • Lần cuối tôi dùng Langchain, dù phải thừa nhận là khoảng 6 tháng trước, thì phần triển khai trích xuất nội dung từ file PDF và HTML còn rất cơ bản
      Nó đủ để chạy prototype RAG, nhưng chưa đủ để tạo ra thứ gì đó đáng tin cậy. Dự án này trông giống một triển khai đã được kiểm chứng trong thực tế hơn nhiều

  • Công việc rất xuất sắc và cực kỳ thú vị. Nhưng khi vào GitHub thì hiện ra “This organization has no public members”, tôi hoàn toàn không biết các bạn là ai, cũng không biết bên trong còn có gì khác chưa được công khai
    Nói chung, giữa kiểu “một nhóm ẩn danh vô danh đăng cái gì đó lên trang bảo mật của $CORP” và cách giới thiệu/xây dựng niềm tin truyền thống, tôi nghĩ cần có một điểm trung gian nơi có thể dần xây dựng danh tính và sự tin cậy theo thời gian

  • Để có được các chunk tối ưu trong dự án LLM/RAG, bạn có thể dùng server này cùng với llmsherpa LayoutPDFReader: https://github.com/nlmatics/llmsherpa
    Hãy xem các ví dụ và notebook trong kho lưu trữ

  • Tôi tò mò không biết có cặp input/output ví dụ nào ở đâu đó không

  • Tôi đã thử phân tích vài trăm file PDF bằng cái này và kết quả khá ổn. Nếu được phát triển bằng Julia thì chắc ít nhất còn nhanh hơn gấp 10 lần

  • Tôi tò mò không biết cái này khác Azure Document Intelligence ở điểm nào, hay thực ra về cơ bản là giống nhau

    • Không phải là làm cùng một việc. Hầu hết parser trên cloud dùng mô hình thị giác, nên chậm hơn và đắt hơn nhiều, và để trích xuất được các chunk tốt thì còn phải viết thêm code ở phía trên
      Nếu dùng server này cùng thư viện llmsherpa(https://github.com/nlmatics/llmsherpa), bạn có thể có được các chunk thân thiện với bố cục, phù hợp cho dự án LLM/RAG
    • Ở đây không dùng OCR hay AI. Ý tôi là ngoài các cơ chế dự phòng tiêu chuẩn ra thì không dùng
      Thư viện này và các công cụ như fitz/pymupdf cho phép trích xuất trực tiếp văn bản từ PDF, rồi áp dụng các quy tắc phân tích và cấu trúc hóa. Phần lớn PDF hiện đại đều có thể trích xuất văn bản mà không cần OCR
      Dĩ nhiên như vậy rẻ hơn nhiều, nhưng không mở rộng tốt cho mọi bố cục động, nên thường sẽ dùng khi có thể cấu hình theo các cấu trúc tiêu chuẩn. Dù vậy, tôi thấy với những thứ như bài báo khoa học thì trích xuất văn bản dựa trên luật vẫn hoạt động khá linh hoạt
    • Lần cuối tôi dùng Azure Document Intelligence, nó không quá thông minh trong việc chọn các điểm chia tách. Cái này có vẻ đã triển khai heuristic tốt hơn
    • Tôi cũng tò mò. ADI đáng tin cậy, nhưng với những PDF được tạo kém thì vẫn có các vấn đề ở trường hợp biên
      Tuy nhiên tôi lo Tesseract OCR có thể là một giới hạn tiềm ẩn. Tôi đã thấy nó mắc quá nhiều lỗi

  • Tôi tò mò không biết có ví dụ nào không. Trong kho lưu trữ có vẻ không có lấy một file PDF nào

    • Có thể xem ví dụ trong dự án llmsherpa: https://github.com/nlmatics/llmsherpa
      Dự án nlm-ingestor này cung cấp backend hoạt động cùng llmsherpa. Thư viện llmsherpa rất tiện để trích xuất các chunk tốt cho các dự án LLM/RAG