← Tất cả bài viết
Ứng dụng thực tế 8 phút đọc

Vấn đề Recrawl: Giữ cho RAG Pipelines luôn được cập nhật

RAG knowledge base của bạn sẽ lỗi thời ngay trong tuần bạn triển khai. Đây là cách các nhóm recrawl hàng trăm nguồn vertical mà không làm thâm hụt ngân sách kỹ thuật.

ragai-trainingdata-collectionvertical-aiuse-case

Thách thức

Các startup AI theo ngành dọc đều gặp phải cùng một trở ngại vào khoảng tháng thứ hai. Họ phát hành một copilot hỗ trợ, một trợ lý nghiên cứu pháp lý hoặc một bot tuân thủ. Bản demo đầu tiên thu hút được khách hàng. Sau đó, dữ liệu trở nên lỗi thời và các câu trả lời bắt đầu sai lệch so với thực tế.

Chúng tôi đã chứng kiến nhiều đội ngũ xây dựng phần AI rất chỉn chu nhưng lại xem nhẹ phần dữ liệu. Pipeline thu thập dữ liệu chỉ là một script Python chạy trên laptop của ai đó. Nó cào 200 URL nguồn một lần, đẩy Markdown sạch vào vector store, và mọi người ăn mừng. Sáu tuần sau, một nửa câu trả lời trích dẫn các trang đã bị xóa, các API đã ngừng hoạt động hoặc các tính năng sản phẩm đã thay đổi giữa tháng 3 và tháng 5.

Giải pháp nghe có vẻ đơn giản: cào lại toàn bộ nguồn dữ liệu hàng tuần. Thực tế phức tạp hơn nhiều. Đến năm 2026, khoảng 60% các trang web uy tín chặn bot AI cào dữ liệu (tăng từ 23% vào cuối năm 2023), và các cơ chế bảo vệ không còn là những kiểm tra User-Agent đơn giản nữa. Chúng phân tích hành vi phiên truy cập, nhịp độ request và các tín hiệu ở cấp độ handshake. Một script đơn giản hoạt động tốt vào tháng 1 có thể âm thầm trả về các trang trống vào tháng 3.

Tệ hơn nữa, một số trang web hiện nay còn cung cấp nội dung bẫy (tarpit content, văn bản vô nghĩa do Markov tạo ra nhưng đọc giống như văn xuôi thật) cho đến khi nó làm nhiễm độc các vector embedding của bạn. Kết quả là các kỹ sư của bạn phải dành nửa tuần để sửa scraper thay vì phát triển sản phẩm. Chất lượng truy xuất giảm sút, khách hàng nhận ra, và đội ngũ bạn thuê để xây dựng AI biến thành một đội chuyên bảo trì scraper.

Giải pháp

Vấn đề cào lại dữ liệu được chia thành ba quyết định cụ thể cần xử lý trên mỗi request:

  1. Render hay không? Hầu hết các cổng tài liệu đều trả về HTML sạch. Nhưng số lượng trang cần render toàn bộ trên trình duyệt để lấy được nội dung hữu ích (bất kỳ trang nào xây dựng trên Next.js hoặc sử dụng client-side rendering) ngày càng tăng.
  2. Dùng proxy nào? Residential, datacenter, mobile, geo-pinned, hoặc theo từng ISP cụ thể. Lựa chọn phù hợp sẽ thay đổi tùy theo mục tiêu.
  3. Nó có thực sự hoạt động không? Mã 200 với body rỗng, hoặc một trang xác minh, là một HTTP request thành công nhưng lại là một lần cào dữ liệu thất bại.

Một nền tảng như FourA xử lý từng vấn đề này như một tính năng cốt lõi.

Đối với quyết định render, bạn gọi Single cho trường hợp nhanh và tiết kiệm chi phí, và Browser cho các mục tiêu phụ thuộc nhiều vào JavaScript. Cấu trúc body của lệnh gọi là như nhau, vì vậy mã thu thập dữ liệu của bạn chỉ cần rẽ nhánh một lần dựa trên cờ của từng nguồn thay vì phải xử lý hàng trăm trường hợp ngoại lệ riêng của từng trang web.

Đối với việc chọn proxy, Proxy Finder chạy như một phần của mỗi lệnh gọi Single, Browser và Auto. Nền tảng sẽ chọn một exit node hoạt động tốt cho mỗi request, trả về id ẩn danh của nó trong response (ở r.proxy cấp cao nhất trên Single/Browser, hoặc r.session.proxy trên Auto), và bạn có thể tái sử dụng id đó cho các lệnh gọi tiếp theo khi cần giữ nguyên cùng một exit node. Trình thu thập dữ liệu của bạn không cần phải tự duy trì thuật toán xếp hạng proxy riêng. (Chúng tôi đã viết về lý do tại sao quy mô pool không còn là yếu tố tạo nên khác biệt trong bài Why Proxy Pool Size Stopped Mattering in 2026.)

Và đối với câu hỏi "liệu nó có thực sự hoạt động hay không", mọi request đều hỗ trợ một khối validate. Bạn khai báo các tiêu chí được tính là thành công: các status code được chấp nhận, các giá trị header bắt buộc, các chuỗi trong body phải xuất hiện hoặc không được phép xuất hiện. FourA trả về một trong bảy kết quả, và chỉ success mới bị tính phí. Một phản hồi 200 nhưng không vượt qua các quy tắc nội dung của bạn sẽ được gắn nhãn application_fail và không bao giờ được đưa vào tập dữ liệu của bạn.

Dưới đây là cấu trúc của một lệnh gọi recrawl cho cổng tài liệu cần render JS. Chúng tôi để Auto điều phối, tự động chọn đúng sản phẩm (Single, Proxy hoặc Browser), xử lý các cơ chế phòng thủ bot và trả về bộ ba session để lần recrawl tiếp theo có thể duy trì cùng một exit node:

import requests

r = requests.post(
    "https://api.foura.ai/api/auto",
    headers={"Authorization": "Bearer pk_live_..."},
    json={
        "url": "https://docs.example.com/changelog",
        "validate": {
            "status": {"accept": [200]},
            "data":   {"accept": ["<article"], "fail": ["captcha", "Just a moment"]},
        },
    },
).json()

# r["data"] or r["body"]   — rendered content (Auto runs the right sub-product per host;
#                            Single populates "data", Browser populates "body")
# r["session"]              — { "proxy": "<base36 id>", "cookies": [...], "userAgent": "..." }
# On the next recrawl, pass r["session"]["proxy"] back as `ignoreProxies: [<id>]` to avoid
# the same exit, or via /api/single with `proxy: <id>` to stick to it.

Nếu mục tiêu trả về trang trung gian của Cloudflare, quy tắc validate.data.fail sẽ bắt được nó. Kết quả được ghi nhận vào mức sử dụng của bạn là application_fail. Bạn không phải trả tiền cho nó, và code thu thập dữ liệu của bạn biết để thử lại với một proxy khác thay vì đưa trang "Just a moment..." vào embeddings.

Đối với toàn bộ tập dữ liệu lớn hơn, bạn áp dụng cùng một mô hình vào hàng đợi tác vụ hiện có của mình. Các nhóm mà chúng tôi đã trao đổi chạy diff hàng đêm so với lần crawl trước, chỉ re-embed các tài liệu thực sự thay đổi, và làm mới tập dữ liệu 500 nguồn trong vài giờ theo thời gian thực. Hàng đợi tác vụ vẫn là của bạn. Việc luân chuyển proxy, quyết định render, và phán quyết thành công là của chúng tôi.

Kết quả

Vòng lặp độ tươi mới của dữ liệu trông như thế nào khi cơ sở hạ tầng không còn là điểm nghẽn (kịch bản minh họa dựa trên các mô hình chúng tôi thấy ở các nhóm AI chuyên ngành):

  • Crawl lại 500 URL nguồn hàng tuần, thay vì chỉ chạy một lần 200 URL lúc ra mắt
  • Thời gian kỹ thuật dành cho scraper: dưới 2 giờ mỗi tuần, giảm từ 1-2 ngày
  • Khoảng thời gian dữ liệu truy xuất bị cũ: 5-7 ngày, thay vì không có giới hạn
  • Tỷ lệ rác trong vector store gần như bằng 0, vì các trang trung gian của Cloudflare và trang tarpit bị từ chối ở tầng validate trước khi chúng đến được embedding model của bạn
  • Chi phí dự đoán được trên mỗi nguồn, vì các lần crawl thất bại không bị tính vào hóa đơn

Vấn đề không phải là những điều này kỳ diệu. Vấn đề là chúng diễn ra một cách tẻ nhạt và ổn định. Và sự tẻ nhạt, ổn định chính là điều AI trên môi trường production cần. (Để tìm hiểu thêm về thời điểm bài toán kinh tế không còn hiệu quả với trích xuất bằng hosted LLM, hãy xem When LLM Extraction Stops Paying for Itself.)

Điểm mấu chốt

Hầu hết các nhóm xây dựng AI chuyên ngành đều nghĩ rằng lợi thế cạnh tranh là prompt, lựa chọn model, hoặc thuật toán retrieval. Không phải vậy. Lợi thế nằm ở vòng lặp độ tươi mới: cơ sở hạ tầng thầm lặng giúp giữ cho cơ sở tri thức luôn chính xác tuần này qua tuần khác.

Những nhóm chiến thắng trong mảng AI chuyên ngành cho đến năm 2026 sẽ không phải là những nhóm có prompt thông minh nhất. Họ sẽ là những nhóm mà người dùng của họ không bao giờ nhận thấy dữ liệu có đang được cập nhật hay không, đơn giản vì nó luôn luôn mới.