Mục lụcChạm để xem nhanh các phần+
- 2.143.0 công bố lúc 06:59 ngày 27/10 giờ Việt Nam, nhận ZIP nhiều tài liệu.
- Dùng convert_all(); mặc định gặp lỗi sẽ dừng, có lựa chọn trả lỗi rồi tiếp tục.
- Đã thử ZIP tự tạo gồm Markdown/DOCX và một tệp lỗi; chưa đo OCR hoặc hiệu quả khách hàng.
Bộ hồ sơ nén có thể đi thẳng vào bước chuyển đổi
Docling phát hành bản 2.143.0 lúc 23:59 UTC ngày 26/10/2026, tức 06:59 ngày 27/10 tại Việt Nam, bổ sung nhận đầu vào ZIP có nhiều định dạng. Đội xây tìm kiếm tài liệu hoặc trợ lý AI có thêm cách đưa một bộ hồ sơ vào quy trình chuyển đổi, đồng thời nhận kết quả riêng cho từng thành viên trong tệp nén.
Điểm cần làm ngay là kiểm tra cách gọi thư viện và xử lý lỗi. Đây là khả năng đóng gói đầu vào mới, không phải công bố độ chính xác OCR cao hơn, hỗ trợ mọi tệp nén hay một mô hình AI mới. Bản tin ngày 27/10 giữ ngày phát hành gốc theo UTC để tránh nhầm thời điểm.
Một ZIP có thể tạo nhiều kết quả
Docling là thư viện chuyển tài liệu sang cấu trúc dùng được cho các bước xử lý tiếp theo. Khi hồ sơ chứa nhiều tài liệu, một tệp ZIP không đồng nghĩa một tài liệu duy nhất. Mỗi thành viên có tên, định dạng, nội dung và trạng thái riêng; hệ thống phía sau cần giữ được sự khác biệt đó.
Theo tài liệu đi cùng thay đổi, convert() dành cho một kết quả và sẽ báo ConversionError nếu nguồn chứa nhiều tài liệu. Với ZIP nhiều thành viên, dùng convert_all(). Nếu tích hợp cũ chỉ thay đường dẫn từ DOCX sang ZIP nhưng vẫn gọi convert(), doanh nghiệp có thể gặp lỗi dù bản phát hành đã hỗ trợ ZIP.
Mặc định, convert_all() dừng khi gặp thành viên lỗi. Chọn raises_on_error=False thì chương trình có thể nhận kết quả lỗi và tiếp tục với các thành viên sau. Đây là lựa chọn nghiệp vụ cần thiết kế rõ: xử lý phần hợp lệ trước hay yêu cầu sửa đầy đủ cả bộ, không đơn thuần là bật một cờ cho hết lỗi.
Thử thật với Markdown, DOCX và một tệp không hỗ trợ
Friday Works đối chiếu API của docling-slim 2.143.0 trong môi trường thử riêng, tạo một ZIP chứa notes.md, report.docx và unsupported.bin. Kết quả nhận được là hai thành viên hợp lệ thành công, tệp nhị phân mẫu thất bại; các đường dẫn kết quả giữ tên ZIP và tên thành viên. Toàn bộ nội dung thử được tự tạo, không dùng hồ sơ khách hàng.
Khi cho tiếp tục sau lỗi, kết quả của report.docx vẫn được trả sau thành viên không hỗ trợ. Nội dung Markdown mẫu được xuất trở lại từ tài liệu đã chuyển đổi. Thử nghiệm nhỏ này xác nhận luồng tiếp nhận và trạng thái trong cấu hình đã chọn; nó chưa đo chất lượng PDF quét, tài liệu dài, bố cục phức tạp hay OCR tiếng Việt.
Ảnh thao tác là notebook Marimo thực sự gọi thư viện Docling, có mã và đầu ra chạy thật. Docling trong phép thử là thư viện Python, không có dashboard riêng được dựng thêm. Vì vậy không gọi notebook này là giao diện ứng dụng native của Docling hoặc một sản phẩm tiếp nhận hồ sơ đã triển khai cho khách.

Lỗi từng tệp phải còn nhìn thấy ở cuối quy trình
Một đơn vị có thể gửi hợp đồng DOCX cùng ghi chú Markdown trong một lần chuyển hồ sơ. Nếu chỉ ghi “ZIP xử lý thành công” sau khi nhận được kết quả đầu tiên, ứng dụng phía sau có thể bỏ sót tệp không đọc được mà người vận hành không biết. Đây là tình huống thiết kế Friday Works lưu ý, chưa phải sự cố được ghi nhận tại doanh nghiệp cụ thể.
Giữ danh sách đầu vào, trạng thái của từng thành viên và tên nguồn gốc trước khi đưa nội dung vào chỉ mục tìm kiếm. Những tài liệu còn lỗi cần hiện trong hàng chờ xử lý, có người chịu trách nhiệm và cách gửi lại. Không đưa văn bản thiếu thành viên vào một báo cáo rồi gọi đó là tổng hợp đầy đủ.
Với trợ lý trả lời dựa trên hồ sơ, cần giữ đường dẫn nguồn để người đọc kiểm tra câu trả lời đã dựa vào tệp nào. Hỗ trợ ZIP không tự giải quyết quyền truy cập tài liệu, dữ liệu trùng hay cách mô hình trích dẫn; những yêu cầu đó vẫn thuộc hệ thống tích hợp.
Giới hạn dung lượng và mô hình cần kiểm tra riêng
Tài liệu mới nêu giới hạn kích thước áp dụng cho từng thành viên và tổng dung lượng các thành viên đã đọc thành công. Vì vậy không nên chỉ giới hạn kích thước tệp ZIP đã nén. Đặt giới hạn phù hợp, kiểm tra trạng thái từ chối và thử với bộ dữ liệu được phép trước khi nhận hồ sơ ngoài tổ chức.
Docling có nhiều phần bổ trợ theo định dạng và cách chạy mô hình. Phép thử dùng Markdown/DOCX không chứng minh mọi pipeline đều nhẹ hoặc chạy offline ngay sau cài đặt. Tệp PDF quét, âm thanh và các mô hình cụ thể có thể cần thêm phụ thuộc, trọng số và điều kiện giấy phép riêng.
Trước khi áp dụng bản 2.143.0, thử bộ hồ sơ đại diện, so số lượng thành viên với số lượng kết quả và lưu lỗi có thể giải thích được. Giá trị thực tế của thay đổi là giảm phần tự xử lý đầu vào hỗn hợp; độ chính xác, chi phí và thời gian xử lý vẫn phải được đo trên tài liệu thực tế.
Nguồn tham khảo
Tài liệu đã dùng để biên soạn
Ưu tiên tài liệu chính thức và nguồn kỹ thuật gốc. Truy cập để kiểm tra chi tiết hoặc theo dõi cập nhật mới nhất.
- Docling 2.143.0, published October 26 23:59 UTC / October 27 06:59 VietnamThe Docling Contributors ↗︎
- Mixed-format ZIP implementation, documentation and maintainer testsThe Docling Contributors ↗︎
- Exact release documentation: convert_all and archive limitsThe Docling Contributors ↗︎
- Docling MIT licenceThe Docling Contributors ↗︎
- Cover and inline images: Docling 2.143.0 API trial in Marimo 0.25.2, executed and captured October 27, 2026; entirely synthetic files and values. A library notebook, not a native Docling UI. Docling MIT and Marimo Apache-2.0; actual code/output crop, proportional resizing and cover margins.The Docling Contributors / Marimo contributors; trial and capture by Friday Works ↗︎
- Image/software licence; full notices retained in research artifactsThe Docling Contributors / Marimo contributors; trial and capture by Friday Works ↗︎
- Marimo notebook interface, Apache-2.0 (not a native Docling GUI)Marimo contributors ↗︎
