Cách Giữ Cơ Sở Kiến Thức RAG Của Bạn Luôn Cập Nhật Tự Động
TL;DR
Độ tươi của RAG có ba đồng hồ: độ tươi của nguồn, độ tươi của chỉ mục và độ tươi của câu trả lời. Đo lường chúng một cách riêng biệt.
Xây dựng một bản kê URL và so sánh băm của nội dung đã chuẩn hóa; chỉ nhúng lại các trang đã thay đổi và giữ một bản đồ trang đến khối để thay thế và xóa.
Một lần thu thập không thành công là một trạng thái không xác định, không phải chứng cứ rằng một trang đã bị xóa. Xác nhận các mã lỗi 404, chuyển hướng và thay đổi sơ đồ trang trước khi xóa các hồ sơ đã lập chỉ mục.
Nstdata Crawl hiện tại tài liệu đang làm nhiệm vụ lấy dữ liệu thay vì webhook ra ngoài, vì vậy trình lập lịch hoặc công nhân của bạn phải kiểm tra trạng thái và phục hồi.
Giới thiệu: RAG trở nên cũ khi chỉ mục ngừng di chuyển
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 lấy trang và trang web cho các đường ống dữ liệu hạ nguồn.
Một hệ thống RAG có thể truy vấn cơ sở dữ liệu vector của nó với mỗi yêu cầu và vẫn trả về thông tin cũ. Trang nguồn có thể đã thay đổi, nhưng chỉ mục có thể chưa được thu thập lại. Hoặc các vector mới có thể tồn tại trong khi bộ dữ liệu lấy vẫn chứa các kết quả cũ. “Tươi” do đó mô tả nhiều hơn thời gian trả lời của mô hình.
Hướng dẫn này thiết kế một quy trình cập nhật theo lịch trình cho tài liệu công khai và trang kiến thức: kiểm kê → thu thập → xác thực → so sánh → khối/nhúng → upsert/xóa → xác minh. Nó giả định rằng ứng dụng của bạn kiểm soát danh sách cho phép nguồn và cơ sở dữ liệu vector. Nstdata Crawl xử lý việc lấy dữ liệu và trả về kết quả nhiệm vụ/trang; nó không quyết định xem một tài liệu có lỗi thời đối với sản phẩm của bạn hay không. Xem tài liệu API Crawl để biết các điểm cuối nhiệm vụ và kết quả hiện tại.
Trải nghiệm Nstproxy Crawl - Bắt Đầu Dùng Thử Miễn Phí Hôm Nay
Độ tươi của nguồn
Khi nào trang tự nó thay đổi lần cuối?
source_updated_at nếu có sẵn
Độ tươi của chỉ mục
Khi nào nội dung bạn chấp nhận đến cửa hàng vector?
last_indexed_at
Độ tươi của câu trả lời
Bức ảnh nguồn nào đã thông báo cho câu trả lời này?
lấy crawled_at
Một dấu thời gian thu thập không chứng minh rằng một trang đã được cập nhật, và một dấu thời gian chỉ mục không chứng minh rằng nguồn mới nhất đã được lấy. Giữ lại các dấu thời gian mà hệ thống của bạn thực sự có thể quan sát; đừng tạo ra source_updated_at nếu trang web không công khai nó.
Kiến trúc của một cơ sở dữ liệu kiến thức được cập nhật tự động
Một công việc sản xuất có một trình lập lịch, một hồ sơ tác vụ bền bỉ, một công nhân thu thập, một bộ chuẩn hóa, một so sánh băm nội dung, một giai đoạn nhúng, một người ghi vào cửa hàng vector, và một lần kiểm tra xác thực. Mỗi bước cần một khóa idempotency và một kết quả có thể nhìn thấy. Một lần chạy nên an toàn để lặp lại sau khi công nhân gặp sự cố.
Đối với bất kỳ trang nào, lưu trữ ít nhất canonical_url, last_attempt_at, last_success_at, content_hash, version, status, và các ID khối hiện tại. Giữ các artifacts thu thập lịch sử riêng biệt nếu khả năng kiểm toán quan trọng. Bản kê là mặt điều khiển cho biết quy trình làm việc những hồ sơ nào cần thay thế.
Bước 1: Xây dựng kiểm kê URL
Bắt đầu với một danh sách cho phép rõ ràng của các trang công khai hoặc một quy trình khám phá có giới hạn. Sơ đồ trang giúp liệt kê các URL có khả năng; các liên kết giúp tìm các trang bị bỏ qua. Chuẩn hóa các đoạn và tham số theo dõi, nhưng không làm sụp đổ các chuỗi truy vấn nếu chúng thay đổi nội dung trang. Các tài liệu phiên bản nên giữ sự khác biệt (/v1/ và /v2/) trừ khi ứng dụng có quy tắc rõ ràng để ngừng sử dụng một.
Một bảng bản kê tối thiểu có thể trông như thế này:
Lưu trữ kiểm kê trước một lần chạy lớn. Nếu một lần thu thập mới bị gián đoạn, bạn có thể tiếp tục từ URL đã hoàn thành cuối cùng thay vì tái khám phá những gì công việc đã làm.
Bước 2: Lên lịch thu thập lại vào khoảng thời gian thích hợp
Lịch trình làm mới nên phản ánh sự biến động của nguồn và rủi ro kinh doanh. Giá cả hoặc hành vi API có thể yêu cầu khoảng thời gian ngắn hơn so với một trang lịch sử công ty đã lưu trữ. Bắt đầu với một lịch trình, quan sát tỷ lệ phần trăm các trang thay đổi và điều chỉnh. Tránh “thu thập lại mọi thứ mỗi phút” như một mặc định: nó làm tăng yêu cầu mà không nhất thiết cải thiện câu trả lời.
Đối với các triển khai đơn giản, một mục cron có thể gọi một công việc idempotent:
Một trình lập lịch hoặc hàng đợi được quản lý là điều ưu tiên hơn khi các công việc cần thử lại, giới hạn đồng thời, tốc độ theo trang web, hoặc các điểm kiểm tra bền bỉ. Tài liệu hiện tại của Nstdata cho thấy các ID tác vụ Crawl bất đồng bộ và truy vấn trạng thái; họ cho biết rằng các webhook hiện tại không được hỗ trợ. Hãy để công nhân định kỳ kiểm tra trạng thái với một thời hạn và tăng dần thay vì chờ đợi mãi mãi cho một callback bên ngoài.
Thu thập lại toàn bộ so với thu thập lại gia tăng
Một lần quét lại toàn bộ có thể đơn giản hóa việc phát hiện khi trang web nhỏ và có giới hạn. Xử lý gia tăng giảm thiểu việc nhúng và ghi vector khi hầu hết các trang không thay đổi, nhưng nó yêu cầu một bản kê URL và so sánh băm đáng tin cậy. Nhiều hệ thống kết hợp cả hai: phát hiện lại các URL theo lịch trình chậm hơn, sau đó quét lại các trang có ưu tiên cao đã biết thường xuyên hơn.
Bước 3: Phát hiện các trang đã thay đổi, mới và bị xóa
Băm nội dung đã chuẩn hóa, không phải các byte HTML thô. Đánh dấu thô có thể thay đổi do ID yêu cầu, thời gian, hoặc bố cục trong khi văn bản hữu ích vẫn giữ nguyên. Giữ URL chính và nội dung đã chuẩn hóa với băm để bạn có thể tái tạo so sánh.
from hashlib import sha256
import re
defnormalize_for_hash(markdown:str)->str: text = markdown.replace("\r\n","\n") text = re.sub(r"\n{3,}","\n\n", text)return text.strip()defcontent_hash(markdown:str)->str:return sha256(normalize_for_hash(markdown).encode("utf-8")).hexdigest()
Nếu băm khớp với bản ghi thành công cuối cùng, hãy bỏ qua việc nhúng. Nếu nó khác, xây dựng một tập hợp các khối thay thế và xác minh trước khi ngừng sử dụng các ID cũ. Nếu trang mới, hãy tạo bản ghi ban đầu của nó. Nếu một URL biến mất khỏi sơ đồ trang, đánh dấu nó là ứng viên xóa; việc bỏ sót sơ đồ trang không đủ để xóa một tài liệu.
Xử lý các trang đã xóa và chuyển hướng một cách an toàn
Đối xử với các điều kiện phản hồi khác nhau:
Trang thành công: xác thực nội dung, so sánh băm, sau đó cập nhật nếu có sự thay đổi.
404 hoặc 410: ghi lại trạng thái và xác nhận theo chính sách của bạn trước khi xóa.
301 hoặc 302: giữ nguyên ánh xạ URL ban đầu và đánh giá đích chính; không sao chép mù quáng cả hai phiên bản.
403, 429, thời gian chờ, hoặc lỗi mạng: đánh dấu nỗ lực là không thành công/không rõ và giữ lại chỉ mục tốt nhất cuối cùng.
Một trang có thể tạm thời không thể truy cập. Sử dụng một khoảng thời gian xác nhận hoặc một kiểm tra độc lập thứ hai trước khi xóa nó. Khi một chuyển hướng hợp nhất hai trang, hãy cập nhật các trích dẫn và tham chiếu một cách có chủ ý.
Bước 4: Cắt lại và nhúng lại chỉ phiên bản mới
Cắt lại khi văn bản đã chuẩn hóa thay đổi hoặc thuật toán cắt thay đổi. Nhúng lại khi văn bản thay đổi hoặc mô hình nhúng thay đổi. Ghi lại embedding_model, chunker_version, và băm nội dung trang với việc tạo chỉ mục để một lần hoàn tác có thể xác định các bản ghi nào tương thích.
Hướng dẫn nhúng của OpenAI mô tả API từ đầu vào đến vector. Giữ một hàng đợi hoặc bảng thử lại cho các lỗi nhúng tạm thời để một lô không thành công không làm cho tất cả các URL đã xử lý thành công bị lặp lại.
Bước 5: Thay thế vector mà không để lại bản sao
Sử dụng ID khối xác định cộng với một bản kê trang. Với Chroma, upsert thay thế các ID hiện có và delete xóa các bản ghi; tài liệu hiện tại hướng dẫn API collection của nó ghi lại những thao tác đó. Với Pinecone, giữ ID mỗi trang hoặc tiền tố trang và sử dụng hướng dẫn upsert và xóa của nó. Đối với bất kỳ hệ thống nào, đừng giả định rằng một upsert sẽ xóa các khối cũ mà ID của chúng không còn trong phiên bản trang mới.
Một chuỗi thay thế an toàn là:
Ghi việc tạo ứng viên dưới ID mới hoặc một không gian tên phiên bản.
Truy vấn các bản ghi ứng viên và xác nhận các nguồn và đoạn văn dự kiến có thể lấy lại.
Chuyển đổi thế hệ hoạt động của ứng dụng hoặc thay thế con trỏ bản kê.
Xóa các ID trước đó sau khi thế hệ mới vượt qua xác minh.
Nếu cửa hàng vector của bạn không thể cung cấp một chuyển đổi phiên bản thuận tiện, hãy giữ các ID cũ trong bản kê và chỉ thay thế chúng sau khi toàn bộ quá trình upsert thành công. Đánh đổi là một khoảng thời gian chồng chéo ngắn, mà bạn có thể xử lý bằng cách lọc dựa trên metadata phiên bản hoạt động.
Bước 6: Xác thực độ mới với các thay đổi đã biết
Sử dụng một số ít trang mà bạn có thể chỉnh sửa một cách an toàn hoặc mà thay đổi một cách dễ dự đoán. Ghi lại một truy vấn mà câu trả lời chính xác phụ thuộc vào lời diễn đạt mới. Sau khi nhập, xác minh rằng khối mới nhất có thể lấy lại và khối cũ không có trong không gian tên hoạt động. Cũng kiểm tra một trang không có sẵn để xác nhận rằng quy trình không xóa bản ghi tốt trước đó của nó.
Theo dõi ít nhất:
Chỉ số
Định nghĩa
Độ trễ từ quét đến chỉ mục
last_indexed_at - last_successful_crawl_at
Tỷ lệ phát hiện thay đổi
số trang đã thay đổi / số trang đã quét thành công
Tỷ lệ trang thất bại
số lần thử trang thất bại / số lần thử trang đã gửi
Tỷ lệ khối lỗi thời gian
số phiên bản cũ đã biết vẫn hoạt động / số trang đã thay đổi được lấy mẫu
Tuổi trích dẫn
thời gian trả lời trừ thời gian quét của bản ghi được lấy
Đây là các chỉ số hoạt động, không đảm bảo chất lượng câu trả lời. Kết hợp chúng với một tập kiểm tra lấy lại và trích dẫn có nhãn.
Bước 7: Giám sát, phục hồi, và chi phí
Viết một bản ghi chạy với run_id, số lượng phát hiện, số lượng thử nghiệm, số lượng thành công, số lượng thay đổi, số lượng bị xóa, token nhúng, ghi vector, URL thất bại, và thời gian đã trôi qua. Xóa các token và bất kỳ nội dung nhạy cảm nào trên trang từ các bản ghi. Sử dụng các lần thử giới hạn với thời gian chờ tăng dần cho các lỗi tạm thời, và ghi danh sách thất bại cho các lỗi gây cố định để xem xét. Thêm một khóa chạy để hai bộ lập lịch không thay thế cùng một trang một cách đồng thời.
Đối với một tập hợp dữ liệu 10.000 trang với tỷ lệ thay đổi giả định hàng ngày 5%, tập hợp thay đổi là khoảng 500 trang trước khi xảy ra lỗi ở cấp độ trang và hiệu ứng phát hiện lại. Ước lượng chi phí thu thập cho các trang mà bạn thực sự yêu cầu, sau đó chi phí nhúng cho văn bản đã thay đổi, ghi/lưu trữ vector, lưu lượng proxy nếu được sử dụng, và các hoạt động của công nhân/ bộ lập lịch. Đây là một mô hình, không phải là một giá báo cáo. Kiểm tra giá thu thập Nstdata mới nhất và tài liệu thanh toán của nhà cung cấp nhúng/vector của bạn trước khi lập ngân sách.
Cập nhật dựa trên sự kiện so với cập nhật theo lịch
Một CMS, kho Git, hoặc nền tảng tài liệu có thể phát ra một sự kiện khi nội dung thay đổi. Sử dụng sự kiện đó để xếp hàng một URL chỉ khi hệ thống nguồn có thể xác định đáng tin cậy trang và sự kiện đó được ủy quyền. Một công việc đối chiếu định kỳ vẫn hữu ích cho các sự kiện bị bỏ lỡ và xóa bỏ. Một kích hoạt sự kiện trong ứng dụng của bạn không có nghĩa là API Thu thập cung cấp webhook; tài liệu Thu thập hiện tại hướng dẫn người dùng truy vấn trạng thái công việc.
Lỗi cập nhật phổ biến
Các lỗi gây thiệt hại nhất là xóa một trang sau khi hết thời gian, băm điều hướng không ổn định thay vì nội dung đã chuẩn hóa, tạo ID mới trong mỗi lần chạy, thay đổi mô hình nhúng mà không có việc tạo chỉ mục mới, và quên xóa các phần cũ sau khi chỉnh sửa. Một câu trả lời đã lưu trữ cũng có thể trông lỗi thời ngay cả khi chỉ mục hiện tại; làm không hợp lệ các bộ nhớ đệm truy xuất/ứng dụng hoặc bao gồm việc tạo chỉ mục trong khóa bộ nhớ đệm.
Danh sách kiểm tra cập nhật tự động hoàn chỉnh
Lưu trữ một danh sách URL chính và danh sách các phần của trang.
Phân tách các trạng thái thành công, thất bại, chuyển hướng, và bị xóa.
Băm nội dung đã chuẩn hóa và bỏ qua các nhúng không thay đổi.
Giữ phiên bản tốt cuối cùng cho đến khi các vector mới vượt qua xác thực.
Kiểm tra các thay đổi đã biết, xóa, chuyển hướng, và các lỗi tạm thời.
Giám sát độ trễ thu thập-đến-chỉ mục, tỷ lệ thất bại, phiên bản lỗi thời, tài liệu tham khảo, và chi phí.
Giữ cho cơ sở kiến thức RAG luôn cập nhật là một vấn đề vòng đời dữ liệu. Một bộ lập lịch bắt đầu công việc, nhưng sự tươi mới phụ thuộc vào danh tính bền vững, phát hiện thay đổi cẩn thận, thay thế vector an toàn, và xác thực với các câu hỏi thực tế. Xem xét các lỗi như là không xác định, không phải là xóa bỏ, và ghi lại các dấu thời gian cần thiết để giải thích điều mà hệ thống biết khi nó trả lời.
Q: Làm thế nào tôi có thể cập nhật một cơ sở kiến thức RAG tự động?
Lên lịch một công việc danh sách URL, thu thập và xác thực các trang, so sánh băm nội dung đã chuẩn hóa, nhúng lại các trang đã thay đổi, và thay thế an toàn các hồ sơ vector cũ.
Q: Tần suất cập nhật dữ liệu RAG nên như thế nào?
Đặt khoảng thời gian từ tỷ lệ thay đổi của mỗi nguồn và rủi ro của các câu trả lời lỗi thời, sau đó điều chỉnh nó theo các thay đổi quan sát được và độ trễ thu thập-đến-chỉ mục.
Q: Chỉ mục RAG gia tăng là gì?
Chỉ mục gia tăng chỉ xử lý các bản ghi nguồn mới, đã thay đổi, hoặc đã bị xóa thay vì xây dựng lại toàn bộ chỉ mục trong mỗi lần chạy.
Q: Làm thế nào tôi có thể xóa các nhúng lỗi thời?
Giữ danh sách ID trang-đến-phần, xác thực các bản ghi thay thế, và sau đó xóa các ID cũ hoặc khai tử lần tạo chỉ mục trước đó.
Q: RAG có thể cập nhật tự động không?
Có, khi ứng dụng của bạn chạy một công việc nạp theo lịch hoặc theo kích hoạt sự kiện mà lấy, xác thực, và chỉ mục các thay đổi nguồn.
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.
