Xây dựng một Pipeline Dữ liệu Web cho Sản phẩm AI của bạn
TL;DR
Xây dựng một pipeline dữ liệu web AI xung quanh các tài liệu đã được chấp nhận và có nguồn gốc, không phải là số lượng các yêu cầu HTTP đã hoàn thành.
Tách biệt việc phát hiện, thu thập, chuyển đổi, xác thực, lưu trữ, lập chỉ mục và làm mới để mỗi giai đoạn có thể được thử lại độc lập.
Bắt đầu với một trang đại diện cho mỗi mẫu, sau đó mở rộng một manifest URL có giới hạn.
Nstdata Crawl có thể xử lý việc phát hiện trang, thu thập đệ quy, xử lý JavaScript, định tuyến proxy và nhiều định dạng đầu ra thông qua Crawl API.
Theo dõi các băm nội dung và phiên bản chỉ mục để các sửa chữa và xóa có thể được lan truyền.
Sản phẩm của một Pipeline Dữ liệu Web cho một Sản phẩm AI là gì?
Một pipeline hữu ích tạo ra một tài liệu có phiên bản hoặc bản ghi có cấu trúc mà sản phẩm có thể lần tìm nguồn gốc trở lại. Đối với RAG, đầu ra có thể là Markdown được chia thành các phần với các URL nguồn và đường dẫn tiêu đề. Đối với một tính năng trích xuất, nó có thể là một đối tượng JSON có kiểu với bằng chứng cho mỗi trường. Pipeline cũng nên tạo ra các bản ghi thất bại: một sự cố thời gian, trang bị chặn hoặc tài liệu bị từ chối là một kết quả cần điều tra, không phải là lý do để một URL biến mất một cách lặng lẽ. Sản phẩm Nstdata Crawl là một lựa chọn được quản lý cho các bước thu thập và chuyển đổi được thảo luận ở đây.
Công việc bắt đầu trước khi tải. Xác định nguồn cho phép, các loại trang mục tiêu, kỳ vọng cập nhật và câu hỏi mà sản phẩm AI phải trả lời. Một đại diện hỗ trợ được đào tạo về tài liệu sản phẩm cần một chính sách làm mới khác với một tính năng giám sát giá. Hướng dẫn Databricks RAG pipeline tách biệt việc chuẩn bị tài liệu khỏi lập chỉ mục và phục vụ; giữ những ranh giới đó rõ ràng trong thiết kế của riêng bạn.
Hướng dẫn website-to-RAG cung cấp một ví dụ cụ thể về người tiêu thụ truy xuất.
Trải nghiệm Nstproxy Crawl - Bắt Đầu Dùng Thử Miễn Phí Hôm Nay
Chuẩn bị một danh sách nguồn được chấp thuận; một trang tĩnh, một trang động và một trường hợp lỗi; một tài khoản Nstdata và mã khóa API Crawl phía máy chủ nếu sử dụng thu thập được quản lý; và một kho cho cả hồ sơ đã được chấp nhận và kết quả công việc. Định nghĩa một khóa ổn định như source_id + canonical_url + extractor_version. Một băm nội dung phát hiện thay đổi, nhưng nó không phải là sự thay thế cho danh tính URL: hai trang có thể chứa cùng một đoạn mã trong khi đại diện cho các sản phẩm khác nhau.
Đối với Nstdata Crawl, yêu cầu được tài liệu sử dụng x-api-key, Content-Type: application/json, url, và formats. Việc phát hiện trang cũng yêu cầu maxDepth, maxPages, includeUrls, và excludeUrls rõ ràng. Các công việc được quản lý tiêu chuẩn sử dụng định tuyến proxy tích hợp sẵn, vì vậy không cần cấu hình riêng biệt cho Host, Port, Username, Password hoặc Protocol. Kiểm tra giới hạn tài khoản hiện tại và quy tắc truy cập nguồn trước khi mở rộng.
Làm Thế Nào Để Xây Dựng Pipeline Hoạt Động Đầu Tiên?
Phương pháp 1: Nguyên mẫu với một URL đã biết
Sử dụng con đường này khi một ứng dụng đã biết trang cần truy xuất.
Bước 1: Định nghĩa một dụng cụ chấp nhận
Ghi lại tiêu đề dự kiến, hai cụm từ đặc trưng, các liên kết cần thiết và URL nguồn cho một trang đã được chấp thuận. Quyết định mục nào thiếu sẽ từ chối tài liệu.
Bước 2: Tải Markdown và HTML
Tài liệu Crawl cho thấy một lộ trình bắt đầu nhanh cho một trang. Lưu khóa vào NSTDATA_API_TOKEN và gửi một trang đại diện:
curl--output response.json --request POST \"https://api.nstdata.io/api/v1/crawl/scrape/submit-sync"\--header"x-api-key: ${NSTDATA_API_TOKEN}"\--header"Content-Type: application/json"\--data'{"url":"https://example.com/","formats":["markdown","html"],"onlyMainContent":true}'
Tài liệu công khai chứa những nhãn mâu thuẫn trên một số đường đi thu thập đồng bộ và bất đồng bộ khác; sử dụng lộ trình bắt đầu nhanh đã được tài liệu và so sánh yêu cầu được tạo ra bởi Playground của bạn trước khi triển khai vào sản xuất.
Bước 3: Xác thực kết quả lồng ghép
Kiểm tra data.success, data.status, và data.data.metadata.statusCode trước khi chấp nhận markdown. Nếu phản hồi chứa markdownRef hoặc htmlRef, lấy mã thông báo chính xác với GET /api/v1/crawl/storage/read?st={ref}. So sánh nội dung với dụng cụ của bạn; không coi HTTP 200 bên ngoài là bằng chứng của một trang hữu ích.
Phương pháp 2: Phát hiện một phần trang web có giới hạn
Sử dụng con đường này khi danh sách URL chính nó phải được thu thập.
Bước 1: Thiết lập ranh giới
Chọn một URL bắt đầu, maxDepth, maxPages, includeUrls, và excludeUrls. Loại trừ các đường dẫn tìm kiếm, tài khoản và đường dẫn được sinh ra từ truy vấn trừ khi chúng là một phần của phạm vi sản phẩm.
Bước 2: Gửi yêu cầu thu thập
Gọi POST /api/v1/crawl với formats:["markdown"], lưu data.id, sau đó kiểm tra GET /api/v1/crawl/status/{crawlId}. Một công việc trang web phát hiện các liên kết một cách đệ quy; nó không phải là một điểm cuối URL hàng loạt không giới hạn.
Bước 3: Đối chiếu kết quả
Lấy GET /api/v1/crawl/pages/{crawlId} và theo dõi phân trang được trả về. Lưu trữ số lượng đã gửi, đã hoàn thành, đã thất bại, đã từ chối và đã chấp nhận riêng biệt. So sánh tập hợp URL phát hiện được với bất kỳ sitemap hoặc nguồn tài nguyên nào mà bạn đã duy trì.
Phương pháp 3: Giữ cho việc thu thập dữ liệu ở địa phương
Sử dụng một khách hàng HTTP địa phương khi các nguồn là ổn định, tĩnh và trong khả năng hoạt động của bạn. Lấy thông tin với thời gian chờ, định nhịp theo từng máy chủ và giới hạn kích thước phản hồi. Phân tích HTML đã lưu, sau đó áp dụng cùng một hợp đồng chấp nhận và lưu trữ như đường dẫn được quản lý. Tùy chọn này cho bạn kiểm soát trực tiếp nhưng khiến đội ngũ của bạn chịu trách nhiệm về việc trình duyệt hiển thị, chọn proxy, thử lại và khả năng quan sát khi nguồn thay đổi.
Hướng dẫn nhập Markdown xem xét việc bảo tồn cấu trúc trước khi phân chia.
Bạn nên lưu trữ và lập chỉ mục đầu ra như thế nào?
Viết một đối tượng thu thập không thay đổi và một tài liệu đã chấp nhận riêng biệt. Hồ sơ đã chấp nhận nên chứa source_url, final_url, fetched_at, status_code, content_hash, format, extractor_version và một con trỏ đến tài sản thô. Đối với RAG, cũng lưu trữ ID chunk, đường dẫn tiêu đề và phiên bản chỉ mục. Chỉ lập chỉ mục các hồ sơ đã chấp nhận; một lần làm mới thất bại không nên thay thế một tài liệu tốt bằng một tài liệu trống.
Biến việc xuất bản vào chỉ mục tìm kiếm thành idempotent. Nếu một băm tài liệu không thay đổi, hãy bỏ qua việc tái nhúng trừ khi chunker hoặc mô hình nhúng đã thay đổi. Nếu một trang bị xóa, ghi lại một dấu mồ và xóa các chunk của nó khỏi các chỉ mục phục vụ. Giữ tách biệt thời gian nhãn của nguồn và chỉ mục để một câu trả lời có thể tiết lộ bằng chứng của nó hiện tại như thế nào. Hướng dẫn thiết kế RAG Azure nhấn mạnh đánh giá trong quá trình nhập, truy xuất và chất lượng câu trả lời.
Tài liệu kiến trúc Scrapy cung cấp sự tách biệt cụ thể giữa bộ lập lịch, trình tải xuống và xử lý mục.
Làm thế nào bạn biết rằng đường ống đang hoạt động?
Chạy bộ dụng cụ sau mỗi thay đổi bộ phân tích hoặc cấu hình. Theo dõi hồ sơ đã chấp nhận theo từng URL đã gửi, các trường cần thiết bị thiếu, các URL chính thức trùng lặp, thời gian từ sự thay đổi nguồn đến cập nhật chỉ mục và chi phí cho mỗi hồ sơ đã chấp nhận. Lấy mẫu đầu ra từ mỗi mẫu, không chỉ các trang dễ nhất. Đối với một sản phẩm AI, thêm đánh giá cấp độ câu trả lời: liệu bộ thu có thể xác định tài liệu đúng không, và mô hình có trích dẫn phần nguồn hỗ trợ câu trả lời của nó không?
Nstdata Crawl có thể giảm bớt công việc thu thập, nhưng nó không chọn sơ đồ trường của bạn hoặc đánh giá một câu trả lời. Sử dụng Cloud Browser cho các quy trình mà cần tương tác trang liên tục thay vì chuyển đổi từ trang sang dữ liệu. Giữ cho các ranh giới sản phẩm này rõ ràng khi thiết kế đường ống.
Hướng dẫn thu thập tự động hữu ích khi prototype trở thành một công việc lặp lại.
Làm thế nào bạn làm cho mỗi giai đoạn có thể phục hồi?
Cung cấp cho mỗi giai đoạn một danh tính đầu vào và đầu ra bền vững. Khám phá nên phát ra một danh sách URL với chính sách nguồn và ID chạy. Thu thập nên lưu trữ một tài sản thô và một kết quả cuối cùng cho mỗi URL, bao gồm cả thất bại. Biến đổi nên tham chiếu ID tài sản và phiên bản bộ phân tích. Lập chỉ mục nên tham chiếu phiên bản tài liệu đã chấp nhận. Với những liên kết này, một công nhân có thể thử lại giai đoạn của mình mà không cần phát lại mỗi giai đoạn trước đó.
Đối với một sản phẩm đa trang web, phân vùng danh sách theo nguồn. Một trang tài liệu, một danh mục sản phẩm, và một nguồn tin tức có tốc độ cập nhật và mẫu trang khác nhau. Giữ cho các hạn ngạch theo nguồn và ngân sách lỗi để một trang bị hỏng không tiêu tốn toàn bộ hàng đợi. Một chủ sở hữu nguồn nên có khả năng tạm dừng một phân vùng mà không dừng việc thu thập hợp lệ ở nơi khác.
Sử dụng xử lý ít nhất một lần với việc ghi idempotent khi thực hiện chính xác một lần là không thực tế. Một công nhân có thể hoàn tất việc ghi một tài liệu và bị treo trước khi xác nhận thông điệp hàng đợi của nó. Khi khởi động lại, nó sẽ thấy lại thông điệp đó. Một khóa ổn định như source_id + canonical_url + content_hash + parser_version cho phép nó nhận ra cùng một phiên bản. Đừng chỉ loại bỏ trùng lặp dựa trên băm nội dung: hai trang hợp lệ có thể chứa văn bản ngắn giống hệt nhau trong khi có ý nghĩa nguồn khác nhau.
Đặt một trạng thái cuối cùng cho các thất bại. retry_pending nên có thời gian và số lần thử hợp lệ tiếp theo. rejected nên có một lý do về chất lượng nội dung hoặc chính sách. failed_terminal nên lưu giữ lỗi cuối cùng. Một bảng điều khiển chỉ đếm complete khiến đội ngũ không thể so sánh danh sách URL với các tài liệu đã được giao.
Làm thế nào bạn ngăn chặn dữ liệu xấu đến với chỉ mục?
Sử dụng một bước khuyến mãi thay vì ghi kết quả truy vấn trực tiếp vào kho lưu trữ phục vụ. So sánh ứng cử viên với phiên bản đã được chấp nhận trước đó. Kiểm tra loại trang mong đợi, tiêu đề, nội dung liên quan tối thiểu, ngôn ngữ, trường bắt buộc và các thay đổi đáng ngờ về độ dài. Việc giảm 95% độ dài văn bản có thể là một bản viết lại hợp lệ, nhưng nó xứng đáng được xem xét trước khi thay thế tự động. Đối với các bản ghi có cấu trúc, hãy xác thực loại, tiền tệ, đơn vị và danh tính thực thể chứ không chỉ cú pháp JSON.
Giữ một phiên bản tốt nhất cuối cùng và đánh dấu chính xác tuổi của nó. Nếu một lần làm mới tạo ra một trang đăng nhập hoặc một lỗi, sản phẩm hiện tại nên hoặc là hiển thị bản ghi cũ với chỉ báo cũ hoặc ẩn nó theo trường hợp sử dụng của nó. Nó không nên xuất bản việc thu thập không thành công như nội dung hiện tại. Bước khuyến mãi đó là nơi lọc chính sách và giảm thiểu dữ liệu cá nhân thuộc về.
Đối với RAG, kiểm tra truy xuất sau khi khuyến mãi. Một công việc nhúng thành công không chứng minh rằng đoạn đúng sẽ được trả về. Duy trì một tập hợp nhỏ các câu hỏi mà câu trả lời của chúng ánh xạ đến các đoạn nguồn đã biết; so sánh truy xuất và trích dẫn sau mỗi lần thay đổi chỉ mục. Điều này tách biệt thất bại trích xuất khỏi thất bại phân đoạn hoặc xếp hạng.
Đối với trích xuất có cấu trúc, giữ lại khoảng chứng cứ cho mỗi lĩnh vực. Nếu giá thay đổi một cách bất ngờ, một người đánh giá có thể kiểm tra văn bản trang chính xác hoặc bản ghi được hiển thị đã tạo ra nó. Điều này hữu ích hơn một đối tượng JSON không có nguồn gốc. Bản ghi tương tự có thể được xác thực lại khi các quy tắc kinh doanh thay đổi, và các trường xấu có thể được sửa chữa mà không cần coi toàn bộ quá trình thu thập là không thể sử dụng.
Q: Tôi có nên lập chỉ mục mọi trang đã truy vấn không?
Không. Chỉ lập chỉ mục những trang vượt qua kiểm tra trạng thái, nội dung, phạm vi và ngữ nghĩa.
Q: Liệu một lần làm mới thành công có thể làm sản phẩm tệ hơn không?
Có. Một tường đồng ý hoặc trang chưa hoàn chỉnh mới được lấy có thể thay thế nội dung tốt trừ khi xác thực chặn việc khuyến mãi.
Q: Bài kiểm tra quy mô hữu ích đầu tiên là gì?
Kiểm tra vài mẫu và trường hợp thất bại dưới cùng một hợp đồng chấp nhận trước khi tăng khối lượng trang.
Hướng dẫn Python này di chuyển từ một trang tĩnh đến các bản ghi đã được xác thực và việc quản lý việc hiển thị. Nó bao gồm các ví dụ có thể chạy, chẩn đoán lỗi, kiểm soát nguồn và một hợp đồng dữ liệu sẵn sàng cho AI.
Marcus Chen
Oct. 29th 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.
