Bộ trích xuất rò rỉ nhiều nội dung phụ nhất nhưng vẫn không bỏ sót nội dung nào trong bộ fixture này

Sáu thư viện, một bộ fixture có gắn nhãn, một bộ chấm điểm. Trong 22 fixture tổng hợp này, thư viện có mức rò rỉ nội dung phụ cao nhất — Mozilla's Readability, ở mức 23,5% — cũng là thư viện duy nhất khôi phục được toàn bộ các đơn vị bài viết đã gắn nhãn.

Đó là một cái giá chỉ gói trong một câu, nhưng hầu hết bài viết về chủ đề này lại chẳng nói rõ điều đó, vì đa số chỉ dừng ở chuyện chấm precision rồi thôi.

Thực sự đã đo cái gì

Mỗi fixture trong bộ này đều có nhãn đúng-sai theo từng đơn vị. Mỗi khối của trang — các đoạn bài viết, thanh điều hướng, quảng cáo, sidebar, luồng bình luận, khối khuyến mãi — đều được gắn nhãn article hoặc boilerplate và đi kèm một token đánh dấu duy nhất. Vì vậy, câu hỏi “bộ trích xuất có lấy lại được đơn vị này không” được kiểm bằng cách tìm đúng chuỗi con xuất hiện hay không, chứ không phải bằng điểm tương đồng. Một sentinel còn nằm trong kết quả hoặc không còn nữa — hết.

Hai mươi hai fixture, 91 đơn vị. Sáu bộ trích xuất: Mozilla Readability 0.6.0 (thông qua jsdom 30.0.1), trafilatura 2.2.0, resiliparse 1.0.9, newspaper4k 0.9.6, goose3 3.1.22, và jusText 3.0.2. Python 3.14.2 và Node 22 chạy trên cùng một máy. Bài viết không ghi lại hệ điều hành/CPU, lệnh gọi chính xác, số lần lặp hay chính sách warm-up, nên cột thời gian ở đây chỉ là quan sát cục bộ chứ không phải benchmark có thể đem sang môi trường khác.

Tôi tự đặt ra hai nguyên tắc trước khi chạy bất kỳ thứ gì. Mỗi thư viện Python được cài vào một virtualenv trống riêng, để footprint là của chính nó chứ không bị nhiễm từ những gói mà thư viện khác kéo vào. Và không có runner nào tự tính metric — tất cả chỉ xuất raw text đã trích xuất, rồi một bộ chấm duy nhất tạo ra mọi con số, để sáu công cụ được so trên cùng một phép tính chứ không phải sáu định nghĩa “precision” chỉ trông giống nhau.

Bảng tóm tắt

Recall được tổng hợp trên toàn bộ 22 fixture. Tỷ lệ rò rỉ, precision nội dung tổng hợp và mức nhiễm dùng 11 fixture có cả đơn vị article lẫn boilerplate; “được trả lời” cho biết có bao nhiêu fixture trong nhóm đó tạo ra đầu ra. Số liệu chi tiết theo từng fixture nằm trong sixway-scores.json.

Có một dòng trong bảng đó không phải mặc định. extract_plain_text của resiliparse đặt main_content=False làm mặc định, còn tôi gọi nó với main_content=True. Khác biệt không hề nhỏ: ở chế độ mặc định, nó làm rò rỉ 17 trên 17 đơn vị boilerplate trong toàn bộ bộ dữ liệu — mọi nav, quảng cáo, sidebar, comment thread và promo — trong khi với cờ bật thì chỉ còn 1 trên 17. Tất cả các thư viện khác ở trên đều được gọi bằng mặc định. Vì vậy, tỷ lệ rò rỉ 0.0588 của resiliparse là khi bạn yêu cầu phần nội dung chính; còn extract_plain_text(html) đơn thuần là một sản phẩm khác (default-vs-main-content.json).

Hãy đọc cột đầu và cột thứ hai cùng lúc, vì chỉ nhìn một cột sẽ rất dễ chọn nhầm công cụ.

Readability không bao giờ bỏ sót. Recall hoàn hảo trên cả 22 fixture, và nó là công cụ duy nhất làm được điều đó. Nhưng cái giá phải trả là: 4 trên 17 đơn vị boilerplate bị lọt vào kết quả, 35 token gây nhiễu, tức mức rò rỉ gấp bốn lần trafilatura. Ba trong bốn lần rò rỉ của nó có cùng một kiểu — một khối promo được phân loại trung tính, nằm cạnh bài viết như một phần tử anh em, và heuristic ghép thêm phần tử anh em của nó nuốt luôn khối đó. Nếu bạn đưa đầu ra này vào mô hình, bạn đang trả tiền cho những token đó và mô hình sẽ đọc chúng như thể là nội dung bài viết.

newspaper4k là lựa chọn cân bằng nhất. Không rò rỉ, không token gây nhiễu, recall 0.9865, và có đầu ra trên cả 22 fixture. Nếu phải chọn một công cụ mà chưa biết khối lượng công việc trước, tôi sẽ chọn nó, dù đây không phải cái tên mà đa số người ta thường nghĩ tới.

goose3 có precision hoàn hảo nhưng recall tệ nhất trong bài kiểm tra. Mọi từ nội dung nó trả về đều là nội dung bài viết. Nhưng nó cũng không lấy được gì trên hai fixture và không tạo ra đầu ra ở chính hai fixture đó. Precision hoàn hảo thì rất dễ đẹp nếu bạn được phép từ chối trả lời.

Con số precision đã làm đẹp cho hai thư viện

Điểm này đáng nói rõ hơn, vì đây chính là cái bẫy mà tôi suýt nữa đã đem công bố.

Precision và F1 ở đây đều có điều kiện là phải tạo ra đầu ra. Một thư viện trả về chuỗi rỗng ở một fixture sẽ không đóng góp gì vào tử số cũng như mẫu số — nghĩa là việc im lặng là miễn phí, và precision của một bộ trích xuất thận trọng sẽ trông đẹp hơn một bộ trích xuất làm việc chăm chỉ chỉ vì nó không nói gì.

goose3 có precision tổng hợp 1.0000 trên 10 fixture được chấm trong số những fixture nó trả về đầu ra. jusText là 0.8760 trên 10 trong số 11. Readability, trafilatura, resiliparse và newspaper4k đều trả lời 11 trên 11. Bảng giờ hiển thị cả mẫu số bên cạnh precision để việc “không trả lời” không thể biến mất sau một tỷ lệ đẹp mắt.

Đã từng có một phiên bản tệ hơn của câu chuyện này. Bộ chấm đầu tiên của tôi lấy trung bình recall bài viết trên cùng nhóm 11 fixture dùng để đo độ trung thực nội dung — nhóm loại bỏ các fixture không có boilerplate, điều đó đúng khi đo rò rỉ. Nó báo resiliparse ở mức 1.0000 recall. Nhưng nếu tính trên toàn bộ 22 fixture thì resiliparse chỉ ở 0.9054, vì ở fixture mà bài viết nằm hoàn toàn trong các phần tử <li> mà không có <p> nào, nó vẫn trả kết quả nhưng lại lấy lại 0 trên 6 đơn vị bài viết. Fixture đó không có boilerplate nên bị loại khỏi phép trung bình, và một lỗi thật sự đã bị che đi sau con số hoàn hảo.

Mỗi thư viện vỡ ở đâu

Mỗi trường hợp này là một hành vi cụ thể, có thể tái hiện được, chứ không phải lời than kiểu chung chung rằng “trích xuất kém hơn”:

• resiliparse và goose3 đều giả định văn bản có đoạn. Hãy đưa cho chúng một trang mà phần thân chỉ là danh sách — changelog, đặc tả kỹ thuật, FAQ, công thức nấu ăn — và resiliparse sẽ trả về văn bản nhưng không có nội dung danh sách bên trong, còn goose3 thì trả về trắng. resiliparse ở đây nguy hiểm hơn, vì việc trả về một chút gì đó rất dễ khiến ta tưởng là đã thành công.
• jusText có một vách đá về độ dài, và nó rất gắt. Phần dưới sẽ nói rõ hơn.
• Tài liệu gần như rỗng là trường hợp mà việc không trả về gì cũng có thể xem là đúng, nên tôi không coi đó là lỗi của cả hai thư viện.

jusText: vách đá, không phải dốc thoai thoải

jusText tạo ra đầu ra trên 19 trong 22 fixture và làm rò rỉ 47% boilerplate — cao nhất trong bài kiểm tra, hoàn toàn trái với danh tiếng của nó. Nhưng con số đáng chú ý là con số khiến tôi phải chạy lại toàn bộ.

jusText phân loại từng khối dựa trên mật độ stopword so với danh sách stopword của ngôn ngữ, rồi chạy thêm một lượt theo ngữ cảnh để nâng một khối neargood lên good chỉ khi nó đứng cạnh một khối good đã tồn tại. Một khối chỉ tự đạt trạng thái good khi vượt qua length_high, mặc định là 200 ký tự. Trên tài liệu mà không khối nào vượt ngưỡng này, sẽ không có gì làm mồi cho quá trình nâng cấp, và cả trang sẽ rơi về boilerplate.

Tôi quét nó trên một tài liệu mà đoạn dài nhất chỉ 151 ký tự:

Từ 0 lên 832 ký tự khi chỉ có đúng một đoạn vượt ngưỡng, rồi sau đó không đổi dù bạn hạ thêm bao nhiêu nữa. Chỉ cần một đoạn vượt qua vạch là cả tài liệu được mở khóa.

Trước khi đi đến kết luận đó, tôi cũng quét length_low trên bốn giá trị và max_link_density trên hai giá trị — tổng cộng tám tổ hợp, tất cả đều cho kết quả bằng không. Quy tắc của dự án này là một tuyên bố về khả năng âm cần ít nhất ba dạng tham số được thử hoặc lỗi do chính nhà cung cấp đặt tên cho trường đó; còn một tham số không sinh kết quả thì chưa thể kết luận gì về thư viện. Các con số nằm trong justext-length-threshold.json.

Điều này không có nghĩa jusText trích xuất kém. Trên một trang ngôn ngữ tự nhiên thật sự, ở mặc định, nó trả về 1.190 ký tự nội dung bài viết sạch sẽ. Điều đó cho thấy jusText có một núm chỉnh rõ ràng nhưng hoạt động như một công tắc, và vị trí mặc định của công tắc này không hợp với tài liệu có đoạn ngắn.

Bạn cài đặt cái gì, và cái giá để import là bao nhiêu

Cùng fixture, cùng máy, mỗi thư viện nằm trong một virtualenv trống riêng.

Trong lần chạy này, resiliparse có giá trị cold import và median extraction thấp nhất: 15 ms và 0.06 ms. Nhưng nếu lấy tỷ lệ chéo runtime một cách cứng nhắc thì sẽ phóng đại những gì giao thức chưa hoàn chỉnh này có thể kết luận, nhất là khi lần trích xuất chậm nhất của nó lên tới 1.098 ms. Trước khi dùng những con số này để sizing serverless, cần tách riêng phân phối startup, lần gọi đầu tiên và trạng thái ổn định.

trafilatura và resiliparse gần như hòa nhau về chất lượng — 0.9697 so với 0.9681 F1 theo token nội dung, cùng mức rò rỉ 0.0588 — nên tôi không tuyên bố ai thắng chỉ vì chênh lệch nhỏ như vậy. Nhưng về footprint thì họ khác xa: 21.0 MiB so với 69.9 MiB, 5 gói so với 17. Cái đánh đổi thực sự ở đây là khả năng mù với danh sách của resiliparse đổi lấy ba phụ thuộc ít hơn của trafilatura.

Hai lỗi trong chính bộ test của tôi, được phát hiện trước khi công bố

Phần so sánh ở trên suýt nữa đã không thể xuất hiện, và lý do này đáng giá hơn bất kỳ dòng kết quả nào.

Bộ fixture ban đầu không thể nhìn thấy hai trong số sáu thư viện. Các fixture gốc viết mọi đơn vị thành một chuỗi token vô nghĩa duy nhất — zzart01vf64 zzart01v56i — chính điều đó làm cho recall chính xác. Nhưng điều này cũng có nghĩa fixture không hề chứa từ chức năng tiếng Anh nào. Readability, trafilatura và resiliparse quyết định theo cấu trúc DOM nên không bị ảnh hưởng. goose3 và jusText quyết định theo từ vựng, bằng cách đếm stopword, mà ở đây thì chẳng có gì để đếm: cả hai trả về chuỗi rỗng trên cả 22 fixture.

Một bảng mà hai thư viện bị chấm điểm bằng 0 sẽ trông rất “chính thống” nhưng lại chẳng có ý nghĩa gì. Tôi đã kiểm tra trước khi viết nó, trên một trang thật: goose3 trả về 1.017 ký tự và jusText 1.190. Nghĩa là thư viện ổn; bộ test mới là thứ không thể đại diện cho chúng.

Vì vậy, các fixture được dựng lại bằng văn xuôi tiếng Anh nhưng vẫn giữ sentinel — cùng cấu trúc, cùng class, cùng vị trí DOM, cùng ranh giới đơn vị, cùng sentinel, 1.568 token được thay thế một-một. goose3 từ 0 lên 20 trên 22.

Sau đó bản dựng lại tự làm hỏng hai thứ khác, và cả hai đều do tôi gây ra. Một từ tiếng Anh dài khoảng sáu ký tự; zzart01vf64 dài khoảng mười hai. Thay một-một như vậy đã làm giảm một nửa độ dài mọi đơn vị — 21.646 ký tự văn bản đơn vị còn 10.986, và đơn vị dài nhất giảm từ 1.513 xuống 622. Điều đó âm thầm viết lại chính những fixture mà mục đích của chúng là kiểm tra độ dài. jusText, với hành vi như một vách đá theo độ dài, từ 19/22 tụt xuống 6/22 chỉ vì điều này. Nếu tôi công bố bản bị rút ngắn một nửa đó, con số của jusText sẽ sai lệch gấp ba lần, theo hướng khiến nó trông tệ hơn thực tế.

Lỗi thứ hai: lấy mọi đơn vị từ cùng một kho ngữ liệu chung đã khôi phục mật độ stopword nhưng phá vỡ thuộc tính mà chấm điểm theo token phụ thuộc vào. Từ vựng của article và boilerplate phải tách biệt, nếu không “các token được trích xuất vốn là token boilerplate” sẽ đếm cả từ the. Mười trên 22 fixture cuối cùng có từ vựng chồng lấn, trong khi bản gốc là con số 0. Cách khắc phục là thêm hậu tố cho các từ nội dung theo từng đơn vị và để nguyên các từ chức năng — stopword thật để thư viện từ vựng có cái mà đếm, nhưng từ vựng nội dung vẫn tách biệt cho bộ chấm.

Đó cũng là lý do các cột theo token ở đây được gọi là content_token_* chứ không dùng lại số liệu đã công bố cho Readability-vs-trafilatura. Chúng là một đại lượng khác, đo trên từ nội dung בלבד, và gọi một thứ là thứ kia thì sẽ sai.

Trong lúc dựng lại, tôi còn phát hiện thêm một điều không phải do mình gây ra: ba fixture có độ dày liên kết đặt </a> bên trong một từ — <a href="/x">zzsibp015qlhf zzsi</a>bp015qbht — vì anchor được đặt theo offset ký tự để đạt đúng tỷ lệ. Văn bản hiển thị không đổi, nên phần chấm điểm ban đầu không nhận ra, nhưng bất kỳ bộ trích xuất nào làm việc theo element thay vì theo chuỗi text đều sẽ thấy hai mảnh nơi người khác chỉ thấy một từ. Đã sửa, đồng thời ghi lại chênh lệch ký tự được liên kết thay vì âm thầm chấp nhận nó.

Ai nên dùng cái gì

Đưa vào mô hình và phải trả tiền theo token? newspaper4k hoặc goose3. Cả hai đều không lọt boilerplate units và không có token gây nhiễu. newspaper4k nếu bạn muốn trang nào cũng có câu trả lời; goose3 nếu bạn thà im lặng còn hơn đoán mò, và trang của bạn có cấu trúc đoạn rõ ràng.

Tối ưu một đường xử lý Python nhạy với độ trễ? Hãy đưa resiliparse vào vòng so sánh. Nó có import lạnh và median extraction thấp nhất trong bài này, và chất lượng gần như ngang trafilatura — nhưng chỉ khi bật main_content=True, tức không phải mặc định. Kiểm tra các layout nhiều danh sách trước, và đừng biến các timing cục bộ này thành tỷ lệ tốc độ chính xác giữa hai runtime.

Lưu trữ, hoặc bất kỳ trường hợp nào mà bỏ sót nội dung còn tệ hơn thừa nội dung? Readability. Nó là công cụ duy nhất khôi phục được mọi đơn vị bài viết trên mọi fixture, và 35 token lạc là cái giá rẻ nếu lựa chọn thay thế là mất một đoạn văn.

Làm việc đa ngôn ngữ? jusText là một ứng viên đáng đưa vào vì nó có sẵn stoplist theo ngôn ngữ. Nghiên cứu này không kiểm tra trích xuất đa ngôn ngữ, nên đây là lý do để đánh giá nó chứ không phải bằng chứng nó thắng. Hãy test length_high trên các độ dài đoạn đại diện.

Bất kỳ thứ gì không phải bài viết? Không cái nào trong số này. Tất cả đều xây trên giả định rằng một trang có một khối văn xuôi chính, và một trang liệt kê sản phẩm, trang kết quả tìm kiếm hay dashboard đều phá vỡ giả định đó theo cách mà không tham số nào sửa được.

Managed API phù hợp ở đâu

Tất cả những gì ở trên đều là thư viện bạn tự chạy: bạn cung cấp HTML và nhận text. Các kiểu lỗi quan sát được thay đổi theo hình dạng trang, vì vậy hãy kiểm tra các mặc định đã chọn trên chính corpus của bạn. Việc trích xuất trường có cấu trúc và việc fetch/render không nằm trong phạm vi so sánh này.

Lưu ý của tác giả: Thunderbit là dịch vụ quản lý của chúng tôi cho các workflow nhận URL đầu vào và xuất dữ liệu có cấu trúc. Nó không được chạy qua bộ fixture này, nên không hàm ý bất kỳ so sánh chất lượng nào. Ranh giới quyết định ở đây là: bạn đã có HTML và muốn một bộ trích xuất text cục bộ, hay bạn muốn việc fetch/render và vận hành do dịch vụ xử lý.

Diễn đạt trung thực nhất là thế này: nếu bạn đã có HTML và chỉ cần text, một trong sáu công cụ này là miễn phí và đủ tốt, và bảng trên cho bạn biết nên chọn cái nào. Nếu bạn đang fetch trang ở quy mô lớn, hoặc bạn cần hàng dữ liệu hơn là văn xuôi, đó là một bài toán mua khác.

Nếu bạn đang chọn giữa các dịch vụ fetch bên ngoài, bản tổng hợp web scraping API roundup của chúng tôi bao quát mảng đó, còn so sánh chi phí của SEO và data API sẽ nói về giá. Ở phía tự host, trang tổng quan open-source scraper cho cái nhìn rộng hơn, và nếu thứ bạn thực sự cần là Markdown chứ không phải plain text, chuyển HTML sang Markdown bằng Python là nơi phần mất mát xảy ra nhiều nhất.

Dùng thử Thunderbit để trích xuất dữ liệu web

Kết luận

Không có người chiến thắng, và một bảng tuyên bố ngược lại sẽ là nói dối về một đánh đổi có thật.

Hãy xây một bộ corpus chấp nhận nhỏ trước khi chọn: gồm bài viết chỉ có danh sách, đoạn ngắn, promo cạnh bài, một trang gần như rỗng, và các ví dụ mà việc không trả lời còn tốt hơn trả lời nhiễm bẩn. Chấm riêng khả năng lấy lại bài viết, mức rò rỉ boilerplate, và việc từ chối trả lời. Trên các fixture này, Readability thiên về recall, newspaper4k cho hàng cân bằng nhất, còn resiliparse là một ứng viên độ trễ thấp nhưng có điểm mù với nội dung danh sách; những nhãn đó không nên mang ra ngoài các dạng trang đã kiểm chứng mà không đánh giá lại.

Điều tôi thực sự muốn nói ngắn gọn hơn tất cả những điều trên là: hãy chạy fixture trên chính dạng trang của bạn trước khi chọn. Hai trong sáu công cụ không nhìn thấy bộ test ban đầu, và một công cụ còn đạt recall hoàn hảo nhưng che giấu một thất bại toàn phần. Bảng so sánh chỉ là điểm khởi đầu cho việc đó, không phải sự thay thế.

Dùng thử Thunderbit để trích xuất dữ liệu web Get Started Free

Câu hỏi thường gặp

Những con số này có so sánh được với các benchmark đã công bố cho các thư viện này không? Không, và tôi cũng sẽ không trích dẫn chúng theo cách đó. Đây là các fixture có kiểm soát, với các đơn vị tổng hợp nhưng có gắn nhãn, nên cả sáu công cụ đều nhìn thấy cùng một byte và phép so sánh giữa chúng là công bằng. Các con số đã công bố như benchmark article-extraction của scrapinghub dùng corpus thực tế, đo một thứ khác và khó hơn. Hãy dùng bảng này để so sánh sáu công cụ với nhau, không phải để so với một con số trong bài báo.

Vì sao tỷ lệ rò rỉ của Readability lại cao hơn trafilatura dù cả hai đều dựa trên DOM? Vì mỗi công cụ đặt ranh giới ở một chỗ khác nhau. Ba trong bốn lần rò rỉ của Readability là các khối promo được phân loại trung tính, nằm như phần tử anh em của bài viết, và heuristic ghép thêm phần tử anh em của nó kéo chúng vào với giả định rằng nội dung dài, ít liên kết và ở sát bên có lẽ thuộc về câu chuyện. Thường thì đúng là vậy. Nhưng trên bộ fixture này, đó lại là promo. trafilatura khắt khe hơn khi nối thêm nội dung và chỉ rò rỉ một trong số các đơn vị đó.

Tôi có nên tin các con số precision của goose3 và jusText không? Chỉ khi đi kèm số mẫu. Cả hai đều được chấm trên 10 trong 11 fixture có cả article lẫn boilerplate, vì chúng trả về rỗng ở một fixture, và một fixture không có đầu ra thì không đóng góp gì cho cả tử số lẫn mẫu số. Precision 1.0000 của goose3 là thật trên những trang mà nó trả lời; recall 0.8243 trên toàn bộ 22 fixture là nửa còn lại của cùng một sự thật.

Ngưỡng độ dài của jusText có quan trọng trên trang thật không? Hoàn toàn phụ thuộc vào độ dài đoạn của bạn. Một bài báo với các đoạn 300 ký tự sẽ vượt length_high ngay từ đoạn đầu và hoạt động bình thường — đó là lý do jusText trả về 1.190 ký tự sạch trên một trang thật ở mặc định. Một trang toàn đoạn ngắn, mục danh sách hoặc mô tả sản phẩm có thể không bao giờ vượt ngưỡng đó, và khi ấy jusText sẽ trả về chuỗi rỗng thay vì câu trả lời một phần. Hãy đặt giá trị rõ ràng thay vì đợi đến lúc chạy production mới phát hiện.

Ở đây không kiểm tra những gì? Không kiểm tra trang web thực tế nào cả. Không kiểm tra trích xuất đa ngôn ngữ, dù stoplist là điểm bán hàng chính của jusText. Không kiểm tra bộ nhớ khi tải nặng. Không có trang nào không phải bài viết — không product listing, không search result, không dashboard. Không kiểm tra các trường hợp biên về mã hóa. Và hai hệ sinh thái Node/Python được so sánh ở hành vi thư viện, không phải hiệu năng runtime, nên các số mili-giây giữa hai bên nên được hiểu theo bậc độ lớn hơn là tỷ lệ chính xác.