Vấn đề “Hoàn thiện”  Một trong những vấn đề phổ biến nhất trong Đảm bảo chất lượng (QA) đối với việc quét trang web, tuy nhiên lại vô cùng tầm thường, là đảm bảo trình quét thu thập tất cả các mục từ trang web mục tiêu.  Đó là vấn đề hiệu chỉnh liên tục một công cụ đo lường một đối tượng thay đổi liên tục.  Tại sao nó lại xảy ra?  Từ việc dễ phát hiện nhất đến việc khó nhất (không có nghĩa là dễ giải quyết..), chúng tôi có các nguyên nhân dẫn đến việc thu thập dữ liệu không đầy đủ như sau:  trình cạp bị chặn bởi hệ thống chống bot  trình quét bị mất trong các phiên bản thử nghiệm A/B của trang web  trình cạp bị giới hạn bởi giới hạn phân trang của trang web/API  trình cạp đang xem các phần của trang web (đôi khi được tạo sau khi trình cạo được thiết kế)  Kết quả là, chúng tôi có một bộ sưu tập dữ liệu một phần.  Phát hiện lỗi sớm  Hầu hết các trường hợp sử dụng quét web đều có Thỏa thuận cấp độ dịch vụ (SLA) có thể dẫn đến các điều khoản phạt. Đảm bảo Chất lượng nhằm mục đích phát hiện vấn đề tiềm ẩn càng sớm càng tốt -   . trước khi SLA bị vi phạm  Để làm như vậy, chúng ta cần tăng Tỷ lệ phát hiện lỗi (FDR) và giảm Tỷ lệ cảnh báo sai (FAR). Với một quả anh đào trên đầu:   . giữ chi phí thấp  Cách phát hiện lỗi  Phân tích chuỗi thời gian  Chúng tôi có thể theo dõi số lượng mặt hàng theo thời gian và kích hoạt cảnh báo khi số lượng này giảm xuống. Đó là một điểm khởi đầu tốt, nhưng mặc dù hiệu quả với những thay đổi đột ngột (tức là giảm 50%), nhưng nó ít hoạt động hơn khi các biến thể tăng dần, tạo ra quá nhiều cảnh báo sai (FAR) hoặc không phát hiện được lỗi.   Điều này xảy ra bởi vì:  Trang web thay đổi nhanh chóng, đặc biệt là khi lớn  Chúng tôi không có lịch sử dữ liệu để hiểu các xu hướng hoặc thời vụ, điều này sẽ cho phép áp dụng các thuật toán chuỗi thời gian phức tạp hơn.  Hạn chế quan trọng nhất của phương pháp này là nó không phát hiện ra các mục bị thiếu nếu chúng chưa bao giờ được thu thập bởi máy cạp.   Ví dụ   Trang web thương mại điện tử thời trang có thể có danh mục “bán hàng” của trang web chỉ bật lên trong thời gian bán hàng chính thức. Nếu bạn xây dựng máy cạp của mình khi không có phần này, bạn có thể không bao giờ nhận ra mình đang bỏ lỡ các mặt hàng bán hàng.  Kiểm tra thủ công (Ground Truth)  Kiểm tra thủ công mang lại độ tin cậy cao nhất về kết quả, như đã thảo luận   . Nó cung cấp cái gọi là Sự thật cơ bản và bạn có thể so sánh số lượng vật phẩm mà bạn đã thu thập được so với số lượng vật phẩm được thực hiện thủ công. trong bài đăng này   Hạn chế:  Hầu như không khả thi đối với các trang web lớn (bạn có thể biết chắc chắn có bao nhiêu mục trên trang web   , nhưng không đáng tin cậy như vậy trên   ). Allbirds Farfetch  Khó mở rộng: Nó có thể hoạt động với một số trang web và hiếm khi được thực hiện, nhưng mọi thứ sẽ nhanh chóng trở nên khó khăn khi bạn cần nhiều trang web lớn với tần suất cao (đọc cách tiếp cận Data Boutique về vấn đề này trong bài viết về   ). Kiểm tra sự thật cơ bản  Điều này sẽ giữ Tỷ lệ cảnh báo sai (FAR) tốt nhưng không đạt được Tỷ lệ phát hiện lỗi (FDR) hợp lý, vì tần suất sẽ quá thấp.  Điểm chuẩn độc lập  Một cách thông minh để giải quyết vấn đề này là so sánh kết quả của bạn, về mặt số lượng vật phẩm, so với một bộ sưu tập độc lập.   Để phương pháp này hoạt động bình thường, dữ liệu điểm chuẩn phải là:  Độc lập: để giảm khả năng bị ảnh hưởng bởi cùng một xu hướng mã hóa  Hiệu quả về chi phí:   , việc quét web đã đủ tốn kém. Tuy nhiên  Một bộ sưu tập dữ liệu độc lập (gần như) không tương quan với bộ sưu tập dữ liệu của riêng bạn: nó tương quan với nhau vì chúng nhìn vào cùng một đối tượng, do đó, sự thất bại của đối tượng được quan sát thực sự sẽ gây ra tổn thất trong cả hai bộ sưu tập dữ liệu, nhưng mặt khác, chúng ' lại là kết quả của các quy trình độc lập, được viết bởi và được duy trì bởi các nhóm khác nhau, với các kỹ thuật khác nhau.   Việc sử dụng nguồn dữ liệu có độ tin cậy cao làm tăng đáng kể độ tin cậy của kết quả.  Giả sử Tỷ lệ phát hiện lỗi (FDR) hiện tại của bạn là 90%, nghĩa là hệ thống của bạn có thể tự động phát hiện 90% số lần một trình thu thập dữ liệu chỉ thu thập một phần từ trang web. Hay nói cách khác, tập dữ liệu của bạn, khi được xuất bản, chứa 90% số lần là một bộ sưu tập hoàn chỉnh.   Nếu chúng ta giả sử rằng dữ liệu điểm chuẩn là  a) có khả năng phát hiện lỗi như dữ liệu sản xuất  b) độc lập  Sử dụng dữ liệu bên ngoài cho QA sẽ mang lại Tỷ lệ phát hiện lỗi lên 99% (   ). xác suất kết hợp của hai sự kiện  Theo dõi tổng số mặt hàng trên bộ sưu tập dữ liệu của bạn  Điểm chuẩn nó với tổng số mặt hàng từ cùng một trang web trên Data Boutique  Khi số lượng của bạn thấp hơn điểm chuẩn, bạn sẽ phát hiện lỗi.   Tại sao Data Boutique là một sự phù hợp thông minh  Do bộ dữ liệu của   nhúng kiểm tra thủ công vào quy trình Đảm bảo chất lượng của họ, nên việc sử dụng dữ liệu của Data Boutique làm điểm chuẩn có   ,   và là cách   để cải thiện quy trình Đảm bảo chất lượng (QA) ngay cả khi bạn thực hiện quét web nội bộ vì rất có khả năng các bộ dữ liệu được xuất bản trên Data Boutique vượt quá các mức FDR đó. Data Boutique thể mở rộng tiết kiệm chi phí đáng tin cậy  Hai cấu trúc dữ liệu không nhất thiết phải giống nhau: Bạn chỉ đang so sánh số lượng mặt hàng và không cần cấu trúc giống nhau, điều này rất dễ triển khai. Chỉ có độ chi tiết phải được so sánh.  Bạn có thể chọn tần suất cho QA của mình, tần suất này có thể thấp hơn tần suất mua của bạn (nếu bạn mua các mặt hàng hàng ngày, thì bạn chỉ có thể có điểm chuẩn hàng tuần, điều này vẫn còn rất lâu trong việc cải thiện các bài kiểm tra chất lượng dữ liệu.  Vì dữ liệu của Data Boutique là Fractionable (như đã giải thích   ), chi phí mua dữ liệu này có thể rất thấp nếu so sánh với tất cả các thước đo chất lượng khác. trong bài đăng này  Nói cách khác, ngay cả khi cấu trúc dữ liệu của Data Boutique không phù hợp hoàn hảo cho trường hợp sử dụng của bạn, thì việc sử dụng nó để Kiểm tra chất lượng là một cách tiếp cận rất hiệu quả.  tham gia dự án  Data Boutique là một cộng đồng trao đổi dữ liệu web bền vững, có đạo đức, chất lượng cao. Bạn có thể   và thêm yêu cầu của mình nếu một trang web không được liệt kê. Lưu bộ dữ liệu vào danh sách sở thích của bạn sẽ cho phép người bán xác định chính xác nhu cầu về bộ dữ liệu và đưa lên nền tảng. duyệt qua danh mục hiện tại  Thông tin thêm về dự án này có thể được tìm thấy trên   . các kênh Discord của chúng tôi  Cũng được xuất bản trên  Data Boutique

The is an opinion piece based on the author’s POV and does not necessarily reflect the views of HackerNoon.

This writer has a vested interested be it monetary, business, or otherwise, with 1 or more of the products or companies mentioned within.

Read My Stories

Nghe bài viết này bằng Tiếng Anh, đọc bởi robot thông minh của HackerNoon

Cải thiện khả năng phát hiện lỗi sớm (EFD) trong quét web bằng dữ liệu điểm chuẩn

About Author

BÌNH LUẬN

chuyên mục

BÀI VIẾT NÀY CŨNG CÓ MẶT TẠI

Related Stories

287 Stories To Learn About Blockchain Development

61 Stories To Learn About Polotical Philosophy

178 Stories To Learn About Essay

145 Stories To Learn About Book

287 Stories To Learn About Blockchain Development

61 Stories To Learn About Polotical Philosophy

178 Stories To Learn About Essay

145 Stories To Learn About Book

Light-Mode

Classic

Newspaper

Minty

Dark-Mode

Neon Noir

Minty

HN StartUps