Cách Di Chuyển Từ Firecrawl Đến Nstdata: Hướng Dẫn Dành Cho Nhà Phát Triển
TL;DR
Di chuyển từ Firecrawl sang Nstdata là một quá trình di chuyển bộ điều hợp, không chỉ đơn giản là thay đổi base-URL.
Lập bản đồ các đường dẫn bắt đầu, truy vấn, thu thập, chuẩn hóa và lỗi một cách riêng biệt; giữ cho lược đồ tài liệu dòng dưới của bạn ổn định.
Phần hướng dẫn nhanh và phần đường dẫn công cộng của Nstdata khác nhau về các đường dẫn quét đồng bộ, vì vậy hãy xác nhận tài liệu API trực tiếp của tài khoản bạn trước khi kết nối các yêu cầu sản xuất.
Một tích hợp đường đi hạnh phúc nhỏ có thể mất 30 phút; thời gian di chuyển toàn bộ phụ thuộc vào bộ lọc quét, xử lý lỗi và các bài kiểm tra chấp nhận của bạn.
Những thay đổi gì khi bạn di chuyển?
Hướng dẫn Crawl API của Firecrawl mô tả POST /v2/crawl, một ID công việc, truy vấn qua GET /v2/crawl/{jobId}, và một liên kết next phân trang cho kết quả đã hoàn thành. Nstdata Crawl tài liệu một đường dẫn gửi yêu cầu quét trang, tra cứu trạng thái, danh sách trang, và các lần đọc lưu trữ riêng biệt cho các tham chiếu tài liệu. Điều đó có nghĩa là ranh giới ứng dụng nên là một bộ điều hợp crawl_site() trả về các bản ghi trang của riêng bạn. Giữ cho việc phân mảnh RAG và lưu trữ vector không biết về hình dạng phản hồi của nhà cung cấp.
Trải nghiệm Nstproxy Crawl - Bắt Đầu Dùng Thử Miễn Phí Hôm Nay
Dịch URL, đường dẫn và tùy chọn giới hạn
Truy vấn công việc
GET /v2/crawl/{jobId}
GET /api/v1/crawl/status/{crawlId}
Chuẩn hóa trạng thái và lỗi cuối
Thu thập trang
Các trang kết quả quét và next
GET /api/v1/crawl/pages/{crawlId}
Phân trang cho đến khi hoàn tất
Đọc nội dung
Nội dung trang bên trong
Tham chiếu tài liệu như markdownRef
Giải quyết tham chiếu lưu trữ khi cần thiết
Ghi lại lỗi
Lỗi quét cộng với trạng thái trang
Trạng thái công việc và trang
Giữ lại các trường lỗi gốc của nhà cung cấp
Bài viết về Scrapy rất hữu ích khi bạn sở hữu việc phát hiện trong một quá trình chuyển tiếp. Tài liệu Crawl API của Nstdata là cơ quan có thẩm quyền cho các trường yêu cầu và phản hồi cụ thể của tài khoản. Phần hướng dẫn nhanh và phần đường dẫn hiện tại cho thấy các nhãn điểm cuối quét không nhất quán. Hướng dẫn này có chủ đích tránh việc phát minh một thân yêu cầu sẵn sàng cho sản xuất hoặc giả vờ rằng một đường dẫn duy nhất hoạt động cho mọi tài khoản. Sao chép ví dụ đã xác thực từ tài liệu trực tiếp của bạn, sau đó chạy bài kiểm tra chuẩn hóa bên dưới.
Trước: giữ Firecrawl sau một bộ điều hợp
Ví dụ dưới đây là minh họa và cần khóa Firecrawl và SDK đã cài đặt của bạn. Nó cho thấy đường nối cần giữ lại, thay vì một tuyên bố rằng môi trường này đã thực hiện một lần quét trả phí.
from firecrawl import Firecrawl
client = Firecrawl()result = client.crawl("https://example.com/docs", limit=50)
Tránh việc mã dòng dưới phải tiếp cận các trường cụ thể của Firecrawl trên toàn bộ ứng dụng. Lời gọi tiện lợi được tài liệu hóa .crawl() có thể ẩn việc truy vấn và phân trang. Kiểm tra kiểu trả về SDK hiện tại của nó trước khi cam kết một triển khai thay thế. Nếu pipeline của bạn sử dụng khai thác JSON, ảnh chụp màn hình, hoặc bộ lọc quét, hãy ghi lại từng tùy chọn một cách rõ ràng. Những điều đó có những tác động khác nhau về chi phí và lược đồ, được mô tả trong giá tín dụng của Firecrawl.
Sau: chuẩn hóa kết quả trước khi thay đổi nhà cung cấp
Mã Python sau đây có thể kiểm tra ngoại tuyến và chỉ sử dụng thư viện tiêu chuẩn. Cung cấp nó các từ điển trang từ một lần quét Nstdata đã xác thực sau khi xác nhận cấu trúc phản hồi hiện tại. Nó tránh việc liên kết phần còn lại của pipeline RAG của bạn với tên trường của nhà cung cấp.
from dataclasses import dataclass
from typing import Mapping, Any
@dataclass(frozen=True)classDocument: url:str markdown:str status:int|None source_id:str|Nonedefnormalize_nstdata_page(page: Mapping[str, Any], markdown:str)-> Document: url =str(page.get("url")or page.get("sourceUrl")or"")ifnot url.startswith(("http://","https://")):raise ValueError("Thiếu URL nguồn tuyệt đối") body = markdown.strip()ifnot body:raise ValueError(f"Markdown trống cho {url}") raw_status = page.get("statusCode") status =int(raw_status)if raw_status isnotNoneelseNonereturn Document(url, body, status,str(page.get("id"))if page.get("id")elseNone)
Tại đây markdown là văn bản tài liệu đã thu được; một mã thông báo markdownRef không phải là thân mình. Tài liệu Tài liệu đăng ký Nstdata cũng xem xét lưu lượng proxy là một yếu tố chi phí riêng biệt. Giữ một sổ cái cho mỗi trang với URL đầu vào, URL chuẩn, trạng thái, tham chiếu tài liệu, thời gian thu hồi và các đơn vị tính phí.
Đường phác thảo kịch bản di chuyển mà bạn có thể điều chỉnh
Sử dụng trình tự này trong một kịch bản một lần: tải một tệp tin URL cố định; gửi một cuộc thu thập dữ liệu Nstdata đã bị giới hạn; truy vấn với sự lùi lại cho đến khi kết thúc; liệt kê mỗi trang kết quả; lấy mã đánh dấu đã tham khảo; gọi normalize_nstdata_page; so sánh các URL đã chấp nhận với cơ sở dữ liệu Firecrawl; viết một tệp JSON Lines. Làm cho kịch bản có thể tiếp tục từ crawlId, vì vậy một thời gian chờ không bắt đầu một cuộc thu thập dữ liệu trả phí trùng lặp. Giới hạn độ song song và ghi lại ID yêu cầu để chẩn đoán các lỗi một phần. Không âm thầm loại bỏ các trang 403, 404, trống hoặc trùng lặp.
Một lần chạy thử đạt yêu cầu nên chứng minh rằng cùng một bộ chia nhỏ downstream chấp nhận cả hai bộ điều hợp. Nó cũng nên tìm các URL đã bị xóa, các canonical trùng lặp, thay đổi trong bảng hoặc ô mã, và sự khác biệt trong các tiêu đề. Hướng dẫn cơ sở dữ liệu RAG, chiến lược chia nhỏ, và phương pháp tỷ lệ thành công thu thập dữ liệu cung cấp các kiểm tra cho việc chuyển giao này. Bài kiểm tra nên so sánh tài liệu đã chấp nhận và chất lượng câu trả lời, không phải sự tương đương byte-for-byte của Markdown.
Thông thường mất hơn 30 phút?
Cài đặt xác thực, xác minh tuyến đường, phân trang kết quả, đọc lưu trữ vật phẩm, bộ lọc đường dẫn đã thay đổi, chính sách thử lại và giám sát mất nhiều thời gian hơn là thay thế một cuộc gọi SDK. Cho phép một bằng chứng khái niệm 30 phút cho một trang web nhỏ; ngân sách riêng cho tính tương đương sản xuất. Giữ đường dẫn Firecrawl ẩn dưới một cờ tính năng cho đến khi bộ điều hợp Nstdata vượt qua bộ dữ liệu và ngưỡng chi phí của bạn. Việc chuyển đổi hoàn tất khi các lần thu thập lại đã được lên lịch, xóa bỏ và cảnh báo lỗi hoạt động, chứ không phải khi trang đầu tiên trả về.
Trải nghiệm Nstdata — Bắt đầu dùng thử miễn phí ngay hôm nay
Chạy một so sánh có giới hạn trên một trang web mà bạn có thể thu thập và xem xét các vật phẩm trang thực tế trước khi di chuyển các công việc đã lên lịch.
Q: Tôi có thể thay thế URL cơ sở Firecrawl bằng của Nstdata không?
Không. Vòng đời công việc, tham chiếu đầu ra, phân trang và các trường lỗi cần một bộ điều hợp.
Q: Việc chuyển đổi có luôn mất dưới 30 phút không?
Không. Một mẫu nguyên mẫu nhỏ có thể, nhưng việc chuyển đổi sản xuất phụ thuộc vào các tính năng và bài kiểm tra chấp nhận mà bạn sử dụng.
Q: Tại sao một tham chiếu Markdown không đủ?
Nó xác định đầu ra đã lưu; lấy vật phẩm và xác minh nội dung của nó trước khi chia nhỏ.
Q: Chúng ta có nên thu thập lại toàn bộ bộ dữ liệu ngay lập tức không?
Bắt đầu với một mẫu đại diện có giới hạn và một quy trình triển khai có thể đảo ngược. So sánh các trang đã chấp nhận, độ mới và chi phí trước khi mở rộng.
Lena Zhou
Oct. 16th 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.
