RAG Data Quality: Tại sao Dữ liệu thu thập sạch là quan trọng
TL;DR
Chất lượng dữ liệu RAG là một chuỗi: nội dung nguồn phải có liên quan, đầy đủ, hiện tại, có cấu trúc, không trùng lặp và có thể truy xuất trước khi việc truy xuất hoạt động tốt.
Thành công của việc thu thập không phải là thành công của nội dung. Xác thực phần nội dung được trích xuất, tiêu đề, bảng, mã, phiên bản, URL chính và thời gian thu thập.
Dọn dẹp loại bỏ tiếng ồn khi trích xuất; nó không được xóa các cảnh báo hữu ích, ngữ cảnh tham số, bằng chứng hoặc liên kết nguồn.
So sánh việc nạp sạch và thô với cùng một tập hợp dữ liệu, bộ chia nhỏ, mô hình nhúng, công cụ truy xuất và bộ câu hỏi trước khi khẳng định có sự gia tăng về chất lượng.
Giới thiệu: RAG không thể truy xuất bằng chứng mà nó chưa bao giờ nhận được
Nstdata Crawl là lớp thu thập trong quy trình làm việc này; tổng quan sản phẩm của nó mô tả việc truy xuất trang và trang web cho các đường ống dữ liệu hạ nguồn.
Một hệ thống truy xuất có thể trả về các đoạn không liên quan vì mô hình nhúng của nó yếu, nhưng vấn đề có thể đã bắt đầu sớm hơn: bộ thu thập chỉ ghi lại một nửa trang, bộ dọn dẹp đã xóa một cảnh báo, hoặc việc điều hướng lặp lại đã làm đầy chỉ mục bằng các khối trùng lặp. Chất lượng dữ liệu RAG mô tả liệu các bản ghi nguồn có phù hợp cho các câu hỏi mà hệ thống được kỳ vọng trả lời không.
Tách ba lớp: chất lượng nguồn (trang có chính xác và được ủy quyền không?), chất lượng truy xuất (chỉ mục có trả về bằng chứng liên quan không?), và chất lượng sinh ra (mô hình có sử dụng bằng chứng đó một cách chính xác không?). Sự phân biệt này giúp các đội tìm ra điểm sai ở giai đoạn chính xác thay vì “tiến hành thu thập lại mọi thứ” sau mỗi câu trả lời không chính xác. Nstdata Crawl có thể trả về Markdown đã được dọn dẹp và các định dạng trang khác, nhưng đường ống của bạn vẫn cần có quy tắc chấp nhận; xem tài liệu Crawl.
Chất lượng dữ liệu RAG là gì?
Chất lượng dữ liệu RAG là sự phù hợp của tài liệu và siêu dữ liệu cho việc truy xuất và câu trả lời có căn cứ. Nó không phải là một điểm số. Một đánh giá thực tiễn bao gồm bảy chiều:
Trải nghiệm Nstproxy Crawl - Bắt Đầu Dùng Thử Miễn Phí Hôm Nay
Chiều
Kiểm tra ví dụ
Tính đầy đủ
Các phần, bảng và mã cần thiết có mặt không?
Độ chính xác/độ tin cậy của nguồn
Nguồn có thẩm quyền cho tuyên bố này không?
Tính liên quan
Bản ghi có thuộc về cơ sở tri thức này không?
Cấu trúc
Các tiêu đề, danh sách, mã và bảng có được giữ lại không?
Tính độc nhất
Các URL hay mẫu trùng lặp có tạo ra các khối trùng lặp không?
Tính mới/mẫu phiên bản
Nội dung có hiện tại cho phiên bản sản phẩm yêu cầu không?
Tính truy xuất
Mỗi khối có thể được liên kết với nguồn và thời gian thu thập không?
Các chiều này ảnh hưởng đến chất lượng truy xuất và câu trả lời theo những cách khác nhau. Nội dung chính xác từ phiên bản sai vẫn có thể tạo ra câu trả lời sai; văn bản được cấu trúc tốt từ nguồn không đáng tin cậy không trở thành có thẩm quyền chỉ vì nó đã được chuyển đổi sang Markdown.
Tại sao dữ liệu web bẩn dẫn đến câu trả lời RAG kém
Hãy tưởng tượng một trang nguồn với một menu, một bảng API, một cảnh báo xác thực, và một chân trang. Nếu menu lặp lại trên 200 URL, các khối của nó có thể xuất hiện thường xuyên trong việc truy xuất top-k. Nếu bộ dọn dẹp bỏ qua cảnh báo đó như “nội dung chuẩn,” trợ lý có thể trích dẫn một định dạng yêu cầu mà không có lưu ý của nó. Nếu bảng API mất các mối quan hệ cột, mô hình có thể ghép loại sai và mặc định.
Chuỗi truy xuất thì đơn giản: văn bản ồn ào được nhúng; tìm kiếm độ tương đồng tìm biểu diễn đó; LLM nhận nó như ngữ cảnh. Dọn dẹp có thể giảm đầu vào không liên quan, nhưng nó không thể phục hồi nội dung nguồn bị thiếu. Nếu nội dung JavaScript không được ghi lại, hãy sửa lỗi thu thập/giải mã trước khi tinh chỉnh bộ chia nhỏ.
So sánh HTML, Markdown và văn bản sạch
Định dạng
Cấu trúc
Sử dụng điển hình
Chú ý đến
HTML thô
DOM đầy đủ nhất và các thuộc tính
phân tích tùy chỉnh và gỡ lỗi
các kịch bản, điều hướng, phong cách làm tăng đầu vào
HTML đã dọn dẹp
thẻ cộng với nội dung được chọn
bảng và bộ chọn tùy chỉnh
vẫn yêu cầu quyết định phân tích
Markdown
tiêu đề, đoạn văn, danh sách, liên kết
ngữ cảnh LLM và nạp RAG
kiểm tra tính trung thực của bảng/mã
Văn bản thuần túy
định dạng tối thiểu
tìm kiếm văn bản đơn giản
mất các tiêu đề và dấu hiệu mối quan hệ
Một sự so sánh hữu ích là ghi lại cùng một trang theo hai định dạng và kiểm tra chính xác bảng API, khối mã, và các liên kết nguồn mà ứng dụng của bạn cần. Đừng khẳng định Markdown luôn tạo ra các câu trả lời chính xác hơn; đánh giá toàn bộ thiết lập truy xuất. Để biết thêm chi tiết về các tùy chọn đầu ra của Crawl, xem tài liệu định dạng.
Ví dụ thực tế: dọn dẹp một trang mà không mất đi ý nghĩa
Sử dụng một ví dụ tổng hợp được dán nhãn rõ ràng để kiểm tra quy tắc chuyển đổi:
<nav>Home | API | Pricing</nav><main><h1>Authentication</h1><p>Gửi một API key trong tiêu đề x-api-key.</p><table><tr><th>Header</th><th>Required</th></tr><tr><td>x-api-key</td><td>Có</td></tr></table><aside>Không bao giờ công bố khóa của bạn trong mã trình duyệt.</aside></main><footer>Bản quyền Ví dụ</footer>
Một đầu ra hữu ích giữ lại # Authentication, yêu cầu tiêu đề, và cảnh báo bảo mật. Nó có thể bỏ qua phần điều hướng và chân trang bản quyền nếu chúng bị lặp lại và không liên quan. Đừng loại bỏ cảnh báo chỉ vì nó xuất hiện trong một aside; vai trò ngữ nghĩa và ngữ cảnh trang quan trọng hơn tên thẻ HTML.
Giữ một bản ghi có cấu trúc xung quanh nội dung đã được làm sạch:
Đặt quy tắc chấp nhận theo loại trang. Đối với các trang tài liệu tham khảo API, yêu cầu tên điểm cuối, nhãn tham số, và ít nhất một mẫu mã mong đợi. Đối với các bài viết, kiểm tra tiêu đề và độ dài nội dung tối thiểu. Đối với mọi bản ghi, kiểm tra URL nguồn, dấu thời gian thu thập dữ liệu và phiên bản khi trang web công khai các phiên bản.
Các chỉ số hữu ích bao gồm:
Tỷ lệ nội dung trống = số bản ghi không có nội dung chấp nhận được / số bản ghi đã thử.
Sự đầy đủ của siêu dữ liệu = số bản ghi có tất cả các trường cần thiết / số bản ghi đã chấp nhận.
Tỷ lệ trùng lặp = số băm chuẩn hóa trùng lặp / số bản ghi đã chấp nhận.
Độ phủ = số trang hợp lệ trong phạm vi được thu thập / số trang dự kiến trong kho mẫu.
Tỷ lệ nội dung cũ = số trang đã lập chỉ mục cũ hơn giới hạn độ tươi của nguồn cụ thể / số trang đã lập chỉ mục.
Những số liệu này nên được phân loại theo loại trang. Tỷ lệ độ phủ tổng hợp cao có thể che giấu các trang API bị thiếu nếu tập dữ liệu chứa nhiều trang tổng quan có giá trị thấp.
Đo lường dữ liệu đã làm sạch so với dữ liệu thô mà không đoán
Để so sánh các lựa chọn làm sạch, sử dụng cùng các trang nguồn, tập URL, chính sách phân đoạn, mô hình nhúng, chỉ mục vector, cài đặt truy xuất và tập câu hỏi. Chỉ thay đổi điều trị sạch/thô. Gán thẻ cho đoạn văn nguồn liên quan cho mỗi câu hỏi trước khi chạy thí nghiệm.
Đo lường Recall@K hoặc tỷ lệ thành công, thứ hạng của chứng cứ đã đánh dấu, độ chính xác của trích dẫn, độ chính xác của câu trả lời, hành vi kiêng kỵ, số lượng token ngữ cảnh, và chi phí xử lý. Đây là thiết kế thử nghiệm, không phải là kết quả đã báo cáo. Đừng quy kết bất kỳ sự cải thiện nào cho việc làm sạch trừ khi cùng tập đánh giá và cài đặt quy trình hỗ trợ nó. Các hướng dẫn truy xuất và nhập dữ liệu của Pinecone giải thích các cân nhắc về bản ghi và siêu dữ liệu; kết quả chất lượng thực tế vẫn mang tính đặc trưng cho tập dữ liệu. Đối với hiệu ứng riêng biệt của việc chia tách và vector hóa, giữ nguyên phương pháp phân đoạn và yêu cầu nhúng không đổi giữa các lần chạy.
Xây dựng một quy trình xác thực
Một quy trình mạnh mẽ sắp xếp các bản ghi trước khi lập chỉ mục:
Tự động hóa các kiểm tra là xác định: nội dung trống, thiếu tiêu đề, mã hóa không đúng, mã không đóng, băm trùng lặp, URL không hợp lệ, và siêu dữ liệu bị thiếu. Sử dụng xem xét của con người để xác định nguồn nào là chính thức, liệu một cảnh báo có bị loại bỏ hay không, hoặc liệu một bảng có vẫn mang ý nghĩa giống nhau hay không. Giữ lại các bản ghi bị từ chối và lý do trong nhật ký truy chạy để có thể điều tra một kết quả độ phủ thấp.
Quyết định xem có nên thu thập lại, làm sạch lại, phân đoạn lại, hoặc nhúng lại không
Nếu văn bản trang dự kiến không có, hãy điều tra việc phát hiện URL hoặc kết xuất và thu thập lại.
Nếu HTML thô chứa nhưng Markdown đã chuẩn hóa thì không, hãy sửa chữa trình làm sạch.
Nếu thân trang ổn nhưng chứng cứ hữu ích bị chia tách, hãy sửa đổi trình phân đoạn.
Nếu việc truy xuất thất bại mặc dù có một khối tốt, hãy kiểm tra mô hình nhúng, bộ lọc và thiết kế truy vấn.
Nếu phiên bản nguồn đã thay đổi, hãy làm mới siêu dữ liệu và nội dung, sau đó thay thế vector cũ.
Biểu đồ quyết định này tránh việc tiêu tốn ngân sách thu thập và nhúng cho một vấn đề do bộ lọc truy xuất hoặc cấu trúc nhắc nhở gây ra.
Các vấn đề chất lượng dữ liệu thường gặp và cách khắc phục
Các mẫu lặp lại cần phải loại bỏ trùng lặp hoặc loại bỏ nội dung tĩnh. Các bảng bị hỏng cần kiểm tra khai thác và có thể sử dụng HTML đã làm sạch. Việc trộn lẫn phiên bản cần bộ lọc siêu dữ liệu. Các tham chiếu bị thiếu cần truyền bá URL nguồn. Nội dung cũ cần một quy trình cập nhật dựa trên băm. Ghi chú nguồn sai cần xác thực URL chính thức. Một lỗi thu thập nên được lưu trữ như một nỗ lực không thành công, không được lập chỉ mục như thể nó là nội dung trang.
Danh sách kiểm tra chất lượng dữ liệu RAG cuối cùng
Xác định các nguồn và loại trang được tin cậy, cho phép.
Xác minh nội dung đầy đủ, đặc biệt là mã, bảng, và cảnh báo.
Giữ lại URL chính thức, tiêu đề, phiên bản, ngôn ngữ, và thời gian thu thập.
Loại bỏ trùng lặp mà không hợp nhất các phiên bản hoặc địa điểm khác nhau.
Sử dụng các câu hỏi được gán nhãn để kiểm tra truy xuất, trích dẫn, và kiêng kỵ.
Đánh giá các tín hiệu chất lượng trước khi xử lý lại
Khi một chỉ số chất lượng giảm, hãy xem xét một mẫu nhỏ, phân loại trước khi khởi động lại toàn bộ quá trình thu thập dữ liệu. Nhóm các trang theo mẫu, chế độ hiển thị, phiên bản và loại nguồn; một vài trang tham khảo API bị hỏng có thể quan trọng hơn hàng trăm trang tổng quan khỏe mạnh. So sánh trang hiển thị trên trình duyệt, phản hồi thô, và Markdown đã chuẩn hóa để xác định giai đoạn đầu tiên nơi bằng chứng cần thiết biến mất.
Giữ một lý do từ chối cho mỗi trang: empty_body, missing_required_section, duplicate_hash, untrusted_source, hoặc stale_version. Những loại này giúp quyết định xem có nên sửa chữa phát hiện, trích xuất, làm sạch, hoặc siêu dữ liệu hay không. Chạy lại một công việc nhúng trên cùng một Markdown bị lỗi chỉ lưu trữ cùng một lỗi với chi phí cao hơn.
Kết luận
Dữ liệu thu thập được sạch là quan trọng vì việc truy xuất hoạt động dựa trên đại diện mà bạn lập chỉ mục. Một trang gọn gàng nhưng không đầy đủ vẫn là bằng chứng xấu; một trang chính xác mà không có nguồn gốc thì khó để kiểm toán. Sử dụng xác thực nhận thức nguồn, bảo tồn cấu trúc có ý nghĩa, và đo lường truy xuất trên những câu hỏi mà người dùng thực sự đặt ra.
Chất lượng dữ liệu RAG là mức độ đầy đủ, đáng tin cậy, liên quan, có cấu trúc, hiện tại, duy nhất và có thể truy nguyên của nội dung đã lập chỉ mục cho các câu hỏi mà hệ thống phải trả lời.
Q: Làm thế nào để tôi làm sạch dữ liệu web cho RAG?
Loại bỏ điều hướng lặp lại và tiếng ồn không liên quan trong khi bảo tồn tiêu đề, mã, bảng, cảnh báo, liên kết, URL nguồn và siêu dữ liệu phiên bản.
Q: Markdown có cải thiện RAG không?
Markdown có thể làm cho tiêu đề và danh sách dễ xử lý hơn so với HTML thô, nhưng giá trị của nó phụ thuộc vào độ chính xác của việc trích xuất và đánh giá truy xuất.
Q: Làm thế nào để tôi đánh giá chất lượng dữ liệu RAG?
Đo lường độ phủ trang, độ hoàn chỉnh nội dung, tỷ lệ trùng lặp và trang trống, độ hoàn chỉnh siêu dữ liệu, độ mới, tỷ lệ truy xuất, độ chính xác trích dẫn, và chất lượng câu trả lời.
Q: Tại sao RAG lại truy xuất các khối không liên quan?
Nguyên nhân bao gồm nội dung ồn ào hoặc trùng lặp, ranh giới khối kém, thiếu bộ lọc siêu dữ liệu, sự không khớp giữa các embedding, và các câu hỏi không khớp với nguồn đã lập chỉ mục.
Hiểu bảy chiều kích của chất lượng dữ liệu RAG và cách xác thực các trang web đã được thu thập, so sánh các đầu vào sạch và thô, bảo tồn nguồn gốc và chẩn đoán các thất bại trong việc truy xuất. Nó tách biệt các lỗi trích xuất, truy xuất và tạo ra để các nhóm có thể gỡ lỗi giai đoạn đúng.
Lena Zhou
Oct. 20th 2026
Thu thập toàn bộ trang web chỉ với một yêu cầu API
Tỷ lệ thành công 99,8% với kết xuất JavaScript
Nhận dữ liệu sạch, sẵn sàng cho LLM ở nhiều định dạng
Chuyển mọi trang web thành Markdown, HTML, JSON, liên kết, PDF và hơn thế nữa mà không cần quản lý hạ tầng thu thập dữ liệu.
