← Tất cả bài viết
Ứng dụng thực tế 7 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 vertical AI đều gặp phải một rào cản giống nhau vào khoảng tháng thứ hai. Họ triển khai một support copilot, một trợ lý nghiên cứu pháp lý, hoặc một compliance bot. Bản demo đầu tiên thu hút được khách hàng. Sau đó dữ liệu trở nên cũ kỹ, và các câu trả lời bắt đầu xa rời thực tế.

Chúng tôi đã thấy các nhóm xây dựng phần AI rất gọn gàng nhưng phần dữ liệu lại bị xem nhẹ. Ingestion pipeline chỉ là một Python script chạy trên laptop của ai đó. Nó scrape 200 URL nguồn một lần, đẩy Markdown sạch vào một vector store, và mọi người ăn mừng. Sáu tuần sau, một nửa số câu trả lời trích dẫn các trang đã bị xóa, các API đã deprecated, hoặc các tính năng sản phẩm được ra mắt vào tháng 3 và lại ra mắt vào tháng 5.

Cách khắc phục nghe có vẻ đơn giản: recrawl mọi nguồn hàng tuần. Thực tế lại khó khăn hơn. Đến năm 2026, khoảng 60% các trang web uy tín chặn AI crawler (tăng từ 23% vào cuối năm 2023), và các lớp bảo vệ không còn là những bước kiểm tra User-Agent đơn giản nữa. Chúng xem xét session behavior, request rhythm, và các tín hiệu ở mức handshake. Một script đơn giản từng hoạt động vào tháng 1 sẽ âm thầm trả về các trang trống vào tháng 3.

Tệ hơn, một số trang web hiện cung cấp nội dung tarpit (những chuỗi ký tự vô nghĩa được tạo bằng Markov đọc giống như văn xuôi thật) cho đến khi nó làm hỏng các embeddings của bạn. Vì vậy, các kỹ sư của bạn dành nửa tuần để vá scraper thay vì triển khai sản phẩm. Chất lượng retrieval giảm sút, khách hàng nhận ra, và nhóm bạn thuê để xây dựng AI trở thành một xưởng bảo trì scraper.

Cách tiếp cận

Vấn đề recrawl được chia thành ba quyết định cụ thể phải diễn ra trên mỗi request:

  1. Render hay không? Hầu hết các cổng documentation cung cấp HTML sạch. Một tỷ lệ ngày càng tăng (bất kỳ thứ gì được xây dựng trên Next.js, bất kỳ thứ gì có client-side rendering) cần full browser rendering để trả về nội dung hữu ích.
  2. Proxy nào? Residential, datacenter, mobile, geo-pinned, ISP-specific. Lựa chọn đúng thay đổi tùy theo mục tiêu.
  3. Nó có thực sự hoạt động không? Một phản hồi 200 với empty body, hoặc một trang HTML CAPTCHA, là một HTTP request thành công nhưng là một lần crawl thất bại.

Một nền tảng như FourA xử lý từng vấn đề này như một mối quan tâm hàng đầu.

Đối với quyết định render, bạn gọi Single cho các trường hợp rẻ, nhanh và Browser cho các mục tiêu nặng về JS. Body của request có cùng cấu trúc, vì vậy ingestion code của bạn rẽ nhánh một lần dựa trên một cờ (flag) cho mỗi nguồn thay vì phải mang theo hàng trăm đặc điểm riêng biệt 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 chọn một exit hoạt động cho mỗi request, trả về opaque id 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 sử dụng lại id đó trong các lệnh gọi tiếp theo khi bạn cần giữ nguyên cùng một exit. Crawler của bạn không cần mang theo thuật toán xếp hạng proxy của riêng nó. (Chúng tôi đã viết về lý do tại sao kích thước pool không còn là yếu tố khác biệt trong bài Why Proxy Pool Size Stopped Mattering in 2026.)

Và đối với câu hỏi "nó có thực sự hoạt động không", mỗi request hỗ trợ một block validate. Bạn khai báo những gì được coi 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 body phải hoặc không được xuất hiện. FourA trả về một trong bảy kết quả, và chỉ success là bị tính phí. Một phản hồi 200 nhưng vi phạm các quy tắc nội dung của bạn sẽ được đánh dấu là application_fail và không bao giờ đi vào dataset của bạn.

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

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 đưa ra một trang trung gian Cloudflare, quy tắc validate.data.fail sẽ bắt được nó. Kết quả được ghi lại cho mức sử dụng của bạn là application_fail. Bạn không phải trả tiền cho nó, và ingestion code của bạn biết cần phải retry với một proxy khác thay vì đẩy một trang "Just a moment..." vào embeddings.

Đối với corpus rộng hơn, bạn bọc pattern tương tự vào job queue hiện có của bạn. Các nhóm chúng tôi đã trao đổi thực hiện các bản 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 các corpora 500 nguồn trong vài giờ thời gian thực. Job queue vẫn là của bạn. Sự 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 làm mới (freshness loop) sẽ trông như thế nào khi cơ sở hạ tầng không còn là nút thắt cổ chai (kịch bản minh họa dựa trên các pattern chúng tôi thấy ở các nhóm vertical AI):

  • 500 URL nguồn được recrawl 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 retrieval bị cũ: 5-7 ngày, thay vì không giới hạn
  • Tỷ lệ rác trong vector store gần như bằng không, vì các trang trung gian Cloudflare và các trang tarpit bị từ chối ở lớp validate trước khi chúng đến được embedding model của bạn
  • Chi phí dự đoán được cho mỗi nguồn, vì các lần crawl thất bại không xuất hiện trong hóa đơn

Vấn đề không phải là những thứ này có phép thuật. Vấn đề là chúng nhàm chán. Và sự nhàm chán chính là điều production AI cần. (Để biết thêm về những trường hợp mà bài toán chi phí không còn hiệu quả với hosted LLM extraction, xem When LLM Extraction Stops Paying for Itself.)

Bài học chính

Hầu hết các nhóm xây dựng vertical AI nghĩ rằng lợi thế cạnh tranh (moat) nằm ở prompt, việc chọn model, hoặc thuật toán retrieval. Không phải vậy. Lợi thế cạnh tranh chính là freshness loop: cơ sở hạ tầng không hào nhoáng nhưng giữ cho knowledge base chính xác tuần này qua tuần khác.

Các nhóm giành chiến thắng trong lĩnh vực vertical AI đến năm 2026 sẽ không phải là những nhóm có cá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 ra dữ liệu được cập nhật, bởi vì nó luôn như vậy.