Proxy cho RAG pipeline: giữ nguồn và cập nhật corpus

Proxy cho RAG pipeline cần được đặt ở khâu lấy dữ liệu web, cùng quy trình giữ nguồn, phiên bản và thời điểm kiểm tra lại. ProxyVN hướng dẫn anh em thiết kế vòng refresh có kiểm soát, phân biệt nội dung đổi với lỗi tải tạm thời, rồi bàn giao dữ liệu có xuất xứ rõ ràng cho hệ thống tìm kiếm và tạo câu trả lời.

Proxy cho RAG pipeline và ranh giới của lớp lấy dữ liệu

RAG kết hợp việc tìm thông tin liên quan với quá trình tạo câu trả lời. Dữ liệu đưa vào kho tìm kiếm vì thế ảnh hưởng trực tiếp đến bằng chứng mà hệ thống có thể sử dụng. Tổng quan RAG của Azure AI Search mô tả vai trò đưa nội dung riêng vào quá trình trả lời. Tuy nhiên, bài này chỉ tập trung vào đầu vào web và vòng cập nhật nguồn, không hướng dẫn xây dựng một vector database hay lựa chọn mô hình embedding.

Proxy có thể nằm trên đường HTTP từ collector tới website được phép thu thập. Nó giúp tổ chức kiểm soát đường ra hoặc thực hiện phép thử theo môi trường mạng đã thống nhất. Proxy không đọc hiểu tài liệu thay cho parser, không đánh giá câu trả lời và không chứng minh nội dung đúng. Nếu nguồn sai, cũ hoặc không có quyền sử dụng, việc tải qua một đường mạng khác không giải quyết những vấn đề đó. Cần tách rõ trách nhiệm của từng bước ngay từ thiết kế.

Ba thời điểm cần giữ riêng

Thời điểm trang tự ghi là ngày cập nhật nội dung không đồng nghĩa với lúc collector tải trang. Thời điểm collector kiểm tra lại cũng không đồng nghĩa với lúc nội dung thay đổi. Một lần kiểm tra trả về chưa thay đổi có thể xác nhận nguồn còn phù hợp với bản đã giữ, nhưng không tạo ra nội dung mới. Nếu gộp cả ba thành một cột updated_at, nhóm vận hành sẽ khó trả lời tài liệu được sửa bởi nhà xuất bản hay chỉ được hệ thống kiểm tra lại.

Nên giữ tên trường rõ nghĩa và định nghĩa bằng văn bản. Ví dụ published_at là dữ liệu được trích từ nguồn khi có căn cứ, fetched_at là lần nhận nội dung và checked_at là lần kiểm tra gần nhất. Khi nguồn không công bố ngày, để trống thay vì tự dùng giờ tải làm ngày xuất bản. Một giá trị chưa biết giúp hệ thống đánh giá độ mới trung thực hơn một mốc thời gian có vẻ chính xác nhưng được tạo từ giả định không đúng.

Nếu cần mua proxy cho collector hợp lệ, hãy xác định trước yêu cầu tuyến, xác thực và hành vi khi proxy lỗi. Một collector được yêu cầu đi qua proxy không nên âm thầm chuyển sang đường trực tiếp mà không ghi nhận. Ngược lại, việc giữ nguyên IP không bảo đảm cùng một nội dung vì website còn có ngôn ngữ, cookie và tham số URL. Hợp đồng thu thập phải mô tả các điều kiện đó để phiên bản dữ liệu có thể được giải thích về sau.

Danh mục nguồn cho proxy cho RAG pipeline

Trước khi lập lịch tải, cần một danh mục nguồn được phê duyệt. Mỗi mục nên có hostname, đường dẫn được phép, loại dữ liệu, người phụ trách và điều kiện sử dụng. Tài liệu công khai không đồng nghĩa với mọi hình thức tái sử dụng đều được cho phép. Với nguồn đối tác hoặc nội bộ, cần giữ cả phạm vi quyền truy cập của dữ liệu. Proxy chỉ là đường truyền, không thay cho quyền đọc, lưu và đưa nội dung vào câu trả lời của một nhóm người dùng.

Đối với crawler web, RFC 9309 về robots.txt là tài liệu cần đối chiếu khi xử lý chỉ dẫn thu thập. Robots không phải cơ chế xác thực tài nguyên và không tự tạo giấy phép dùng nội dung. Hệ thống nên có chính sách rõ cho trường hợp không đọc được tệp hoặc gặp lỗi mạng. Không coi một lần timeout là tín hiệu có thể thu thập mọi đường dẫn. Chính sách của dự án phải được xác định trước khi collector bắt đầu chạy.

Danh mục nguồn được phê duyệt

URL định danh và URL thực sự được tải

Một trang có thể được tìm thấy qua nhiều URL, tham số theo dõi hoặc chuỗi chuyển hướng. Cần lưu URL được yêu cầu và URL đích đã được chấp nhận sau kiểm tra. Đừng xóa mọi query string bằng một quy tắc chung vì một số tham số xác định tài liệu hoặc ngôn ngữ. Ngược lại, không để hàng chục biến thể theo dõi trở thành hàng chục nguồn độc lập. Chuẩn hóa nên có quy tắc theo từng website và tập ví dụ kiểm thử cụ thể.

Danh sách cho phép phải được áp dụng cho cả đích chuyển hướng nếu collector có hỗ trợ chuyển hướng. Một URL ban đầu hợp lệ không bảo đảm đích tiếp theo còn nằm trong phạm vi. Với hệ thống nhận URL do người dùng gửi, còn phải kiểm soát đích mạng và nguy cơ truy cập tài nguyên nội bộ. Bài không đưa ra một bộ crawler xử lý mọi trường hợp đó; mẫu logic bên dưới nhận response từ adapter đã được dự án kiểm soát, thay vì tự mở URL tùy ý.

Danh mục cũng cần quy tắc kết thúc vòng đời. Nếu một nguồn bị rút quyền, các bản sao, đoạn trích và mục trong chỉ mục tìm kiếm phải được xử lý theo chính sách đã thống nhất. Chỉ xóa URL khỏi lịch tải không làm dữ liệu cũ biến mất khỏi kho. Quyền xem ở giao diện trả lời và quyền dùng khi xây corpus phải được nối với nhau. Nếu bỏ bước này, hệ thống có thể tiếp tục trích dẫn tài liệu mà nhóm vận hành đã ngừng được phép sử dụng.

Bản ghi nguồn trong proxy cho RAG pipeline

Một bản ghi tối thiểu nên giúp trả lời tài liệu đến từ đâu, được kiểm tra khi nào, nội dung nào đang có hiệu lực và collector đã gặp lỗi gì gần nhất. Không nên chỉ lưu một đoạn text rồi bỏ URL gốc. Khi câu trả lời sai, nhóm đánh giá cần mở đúng nguồn và đúng phiên bản đã được dùng, thay vì so với một trang hiện tại có thể đã thay đổi. Xuất xứ là điều kiện để điều tra, không chỉ là phần trang trí của câu trả lời.

Hash nội dung giúp phát hiện hai tập byte khác nhau, nhưng không chứng minh thông tin đúng hoặc được phép dùng. Cũng cần định nghĩa hash áp dụng lên bản nào: HTML gốc, text sau làm sạch hay đoạn trích. Một thay đổi trong thanh điều hướng có thể làm hash HTML đổi dù phần tài liệu chính không đổi. Vì thế, có thể giữ dấu của dữ liệu gốc và dấu của text chuẩn hóa riêng, kèm phiên bản parser để giải thích vì sao kết quả trích xuất khác nhau.

Phiên bản parser cũng là một phần của xuất xứ

Khi sửa cách loại bỏ menu, bảng hoặc chú thích, cùng một HTML có thể tạo ra text khác. Nếu chỉ ghi nội dung nguồn đã đổi, nhóm dữ liệu sẽ quy lỗi cho website trong khi nguyên nhân thực tế là parser mới. Giữ phiên bản parser, cấu hình ngôn ngữ và thời điểm chuyển đổi giúp tái tạo quá trình. Không cần đưa mọi thông tin nội bộ vào phần trích dẫn công khai; dữ liệu chi tiết có thể nằm trong kho quản trị được phân quyền.

Để giảm dữ liệu nhạy cảm, không lưu credentials proxy trong bản ghi nguồn hoặc log lỗi. Nếu URL chứa token, cần dùng định danh nội bộ và bản URL đã che ở màn hình hỗ trợ. Log có thể cần mã lần chạy, mã nguồn và loại lỗi thay vì toàn bộ header. Khi có nhu cầu lưu bản gốc để kiểm tra, nên xác định thời gian giữ và quyền đọc. Một kho xuất xứ hữu ích không cần biến thành nơi tập trung mọi bí mật của collector.

Refresh có điều kiện với proxy cho RAG pipeline

Khi máy chủ hỗ trợ, validator như ETag có thể giúp kiểm tra lại phiên bản mà không tải toàn bộ nội dung. Tài liệu ETag của MDN giải thích vai trò của định danh phiên bản tài nguyên. Collector cần lưu validator cho đúng URL và đúng biến thể đã tải. Không gửi ETag của tài liệu này khi kiểm tra tài liệu khác, cũng không tự tạo một ETag rồi cho rằng máy chủ sẽ hiểu nó như validator mà máy chủ đã cấp.

Response 304 Not Modified có ý nghĩa trong ngữ cảnh request có điều kiện. Nó không mang một tài liệu mới để parser làm sạch từ đầu. Nếu hệ thống chưa có bản nội dung trước đó mà nhận 304, cần ghi lỗi trạng thái và kiểm tra lại quá trình, thay vì ghi body rỗng vào corpus. Nếu đang có bản hợp lệ, lần kiểm tra có thể cập nhật mốc kiểm tra trong khi vẫn giữ nội dung và thời điểm nhận nội dung trước đó.

Refresh có điều kiện

Mẫu hàm quản lý trạng thái sau một lần lấy nguồn

Hàm Python dưới đây nhận kết quả do adapter cung cấp, không tự kết nối website. Adapter phải xác nhận URL, quyền thu thập, TLS, timeout, kích thước và giới hạn chuyển hướng trước khi giao dữ liệu. Đây là schema cục bộ cho bài minh họa, không phải định dạng bắt buộc của HTTP hoặc thư viện RAG. Tham số now là chuỗi thời gian do bên gọi tạo theo chuẩn nhất quán; content là text đã được bước xử lý nội dung chấp nhận.

import hashlib
 
def refresh_record(url, old, status, content, etag, now):
    if old is not None and old["source_url"] != url:
        raise ValueError("source mismatch")
    result = dict(old or {"source_url": url})
    result.update(checked_at=now, last_status=status)
    if status == 200:
        if not isinstance(content, str) or not content.strip():
            raise ValueError("accepted text required")
        result.update(
            content=content,
            content_sha256=hashlib.sha256(
                content.encode("utf-8")).hexdigest(),
            fetched_at=now, etag=etag, state="active")
    elif status == 304:
        if old is None or old.get("state") != "active":
            raise ValueError("304 requires active content")
        if etag is not None:
            result["etag"] = etag
    elif status in (404, 410):
        result["state"] = "pending_review"
    else:
        result["last_error"] = "refresh_failed"
    if status in (200, 304):
        result.pop("last_error", None)
    return result

Mẫu này chủ động đưa 404 hoặc 410 vào trạng thái chờ xem xét thay vì tự xóa lịch sử. Đây là lựa chọn quản trị của ví dụ, không phải quy tắc HTTP bắt mọi dự án làm giống nhau. Bộ phân phối corpus phải chỉ xuất bản các bản ghi active còn đáp ứng chính sách độ mới và quyền sử dụng. Với bản chờ xem xét, cần xác minh nguồn đã bị gỡ thật, đổi URL hay trả một phản hồi phụ thuộc điều kiện truy cập trước khi quyết định cuối.

Khi refresh gặp lỗi khác, hàm giữ nội dung trước và ghi lỗi mới nhất. Điều đó phục vụ điều tra chứ không tự cho phép tiếp tục dùng dữ liệu cũ vô thời hạn. Lớp quyết định xuất bản phải kiểm tra hạn sử dụng của nguồn; tài liệu giá, lịch hoặc chính sách có thể cần ngừng phục vụ nhanh hơn tài liệu tham khảo ổn định. Nếu chưa có nội dung ban đầu, bản ghi lỗi cũng không thể trở thành một tài liệu tìm kiếm chỉ vì đã có source_url và checked_at.

Adapter tải qua proxy phải có hợp đồng rõ ràng

Hàm trạng thái không thay thế HTTP client. Khi triển khai adapter, nhóm kỹ thuật cần chọn thư viện và đọc tài liệu của đúng phiên bản. Chẳng hạn urllib.request trong Python cung cấp các thành phần tạo request và proxy handler. Không nên hiểu việc khởi tạo một đối tượng proxy là đã kiểm soát mọi đường đi. Các cấu hình môi trường, quy tắc loại trừ, chuyển hướng và cách xử lý lỗi HTTP còn phải được kiểm tra trong adapter cụ thể.

Hợp đồng đầu vào cần giới hạn nguồn và loại request. Với lấy tài liệu công khai, GET thường là thao tác chính, nhưng vẫn cần xác nhận phạm vi cho từng website. Không đưa request đăng nhập hoặc hành động ghi dữ liệu vào cùng hàng đợi tải tài liệu. Nếu response trả trang xác thực, captcha hoặc lỗi quyền truy cập, collector phải phân loại nó như trạng thái truy cập. Một trang lỗi có HTML hợp lệ không có nghĩa đó là nội dung tài liệu mà corpus đang cần.

Giới hạn kích thước và thời gian không được để mặc định mơ hồ

Một timeout có thể áp dụng cho hoạt động kết nối hoặc đọc cụ thể, không nhất thiết là ngân sách thời gian của toàn bộ công việc. Hệ thống cần định nghĩa thời hạn của lần chạy và cách dừng khi quá hạn. Kích thước nên được giới hạn khi đọc thực tế, không chỉ tin Content-Length do máy chủ công bố. Nếu có giải nén, cần quan tâm cả dữ liệu sau giải nén. Bộ tải không được phép dùng hết bộ nhớ chỉ vì một nguồn trả tài liệu ngoài dự kiến.

Response có thể là PDF, HTML hoặc loại khác. Mỗi loại cần bước phân tích phù hợp và kiểm soát lỗi riêng. Không đưa byte PDF vào bộ làm sạch HTML rồi ghi kết quả rỗng như một cập nhật thành công. Một adapter nên trả status, header cần thiết và phần dữ liệu được chấp nhận theo hợp đồng, đồng thời giữ nguyên phân loại lỗi khi chưa có nội dung. Phần chuyển trạng thái sau đó mới có đủ thông tin để quyết định giữ, thay hoặc chờ xem xét.

Đối với proxy có xác thực, credentials nên được lấy từ nguồn bí mật được quản lý và không xuất hiện trong thông báo lỗi dành cho người dùng. Khi kiểm tra tuyến, dùng endpoint của dự án hoặc nguồn được phép, giữ kết quả tối thiểu cần cho chẩn đoán. Đừng ghi một lần kiểm tra thành công thành bằng chứng mọi lần tải đều đi qua cùng tuyến. Hành vi phải được xác nhận ở những trường hợp lỗi, retry và đổi worker mà cấu hình có thể bị áp dụng khác nhau.

Corpus cập nhật cần chuyển phiên bản và thu hồi đúng cách

Khi nội dung mới được chấp nhận, bước tạo đoạn trích và chỉ mục nên gắn với phiên bản nguồn cụ thể. Tránh tình huống text đã đổi nhưng citation vẫn trỏ tới metadata cũ, hoặc một phần tài liệu thuộc bản mới trong khi phần còn lại thuộc bản trước. Tùy hệ thống, có thể tạo phiên bản ứng viên rồi đổi con trỏ phục vụ sau khi kiểm tra. Mục tiêu là để truy vấn đang chạy nhìn thấy một tập dữ liệu có thể giải thích, thay vì trạng thái cập nhật dở dang.

Tài liệu bị gỡ cần được xử lý ở cả kho gốc, kho đoạn trích, chỉ mục và lớp cache câu trả lời nếu có. Giữ lịch sử kiểm toán trong phạm vi được phép khác với tiếp tục phục vụ nội dung đã thu hồi. Nếu nguồn thay đổi quyền sử dụng, quy trình cần biết những câu trả lời hoặc tập dữ liệu nào có thể bị ảnh hưởng. Một thao tác xóa trên một bảng không tự chứng minh tất cả bản sao dẫn xuất đã được loại khỏi đường phục vụ.

Chuyển phiên bản corpus

Phân biệt cập nhật byte và thay đổi thông tin có ích

Một trang có thể đổi banner, thời gian hiển thị hoặc mã theo dõi mà không đổi phần tài liệu. Nếu mọi khác biệt đều khiến tạo lại toàn bộ dữ liệu dẫn xuất, chi phí và nhiễu tăng lên. Nhưng làm sạch quá mạnh có thể xóa chú thích, đơn vị hoặc ngoại lệ quan trọng. Cách xử lý là đặt quy tắc theo loại nguồn, giữ bản đầu vào phù hợp cho đối chiếu và dùng tập kiểm tra có các thay đổi thực sự ảnh hưởng nghĩa. Không có một phép chuẩn hóa chung phù hợp mọi website.

Với nội dung đa ngôn ngữ, cần giữ ngôn ngữ của bản nguồn và quan hệ giữa các bản dịch nếu dự án có quản lý quan hệ đó. Hai URL trông tương tự có thể cập nhật lệch nhau. Không chọn ngày mới nhất của một bản rồi gán cho tất cả ngôn ngữ. Nếu có bước dịch máy, phải ghi đó là dữ liệu dẫn xuất cùng phiên bản quy trình, tránh trình bày bản dịch như nguyên văn do nhà xuất bản cung cấp. Xuất xứ càng rõ thì đánh giá câu trả lời càng ít dựa vào phỏng đoán.

Nội dung lấy từ web cũng là dữ liệu không đáng tin để điều khiển hệ thống. Hướng dẫn phòng prompt injection của OWASP là nguồn tham khảo cho rủi ro chỉ dẫn độc hại trong nội dung được đưa vào mô hình. Một trang có câu yêu cầu bỏ qua quy tắc không được trở thành lệnh quản trị. Quyền gọi công cụ, đọc bí mật và thực hiện hành động phải do ứng dụng kiểm soát, không do tài liệu truy xuất tự quyết định.

Kiểm thử vòng refresh bằng tình huống có thể kiểm chứng

Với hàm mẫu, có thể dùng fixture cục bộ để kiểm tra 200 tạo bản active, 304 giữ content và fetched_at, 404 hoặc 410 chuyển chờ xem xét, còn lỗi tạm thời giữ bản cũ kèm dấu lỗi. Cũng cần thử 304 khi chưa có bản active, URL không khớp và text rỗng. Những phép thử này kiểm chứng logic chuyển trạng thái trong hàm. Chúng không kiểm chứng proxy thật, HTTP server, quyền thu thập hoặc chất lượng câu trả lời của mô hình.

Một lần tải thành công chỉ xác nhận collector đã nhận dữ liệu theo điều kiện thử; chất lượng corpus còn phụ thuộc nguồn, phiên bản, quyền sử dụng và cách dữ liệu được đưa vào đường phục vụ.

Kế hoạch thử adapter cần có server lab được phép và các response có kiểm soát. Thử redirect ngoài phạm vi, body vượt giới hạn, TLS không hợp lệ, proxy không sẵn sàng và response lỗi có HTML giống tài liệu. Mỗi trường hợp phải có kết quả mong đợi rõ trước khi chạy. Nếu chỉ thử đường thành công, hệ thống có thể đưa trang lỗi vào corpus ở lần sự cố đầu tiên. Không lấy kết quả fixture làm số đo tỷ lệ thành công của hạ tầng mạng đang vận hành.

Kiểm thử và báo cáo riêng từng lớp

Báo cáo vận hành nên tách tải và sử dụng dữ liệu

Số nguồn kiểm tra, số nguồn thay đổi, số lỗi tải và số bản đang chờ xem xét là các nhóm khác nhau. Một nguồn có thể được kiểm tra nhiều lần nhưng chỉ tạo một phiên bản mới. Vì vậy, số request không phải số tài liệu và tỷ lệ HTTP thành công không phải tỷ lệ câu trả lời đúng. Báo cáo cần chỉ rõ mẫu số và khoảng thời gian. Nếu chưa đo chất lượng câu trả lời bằng bộ đánh giá phù hợp, không suy ra chỉ số đó từ log collector.

Một hồ sơ bàn giao tốt gồm danh mục nguồn, hợp đồng adapter, schema phiên bản, chính sách độ mới, cách thu hồi và kết quả kiểm thử đã thực hiện. Người vận hành tiếp theo cần biết nguồn nào được phép dùng, lỗi nào phải dừng và trường hợp nào được giữ dữ liệu cũ. Khi các quyết định này có chủ sở hữu, proxy mới trở thành thành phần có thể giám sát trong một hệ thống dữ liệu rõ ràng. Nếu thiếu chúng, thay proxy thường chỉ đổi triệu chứng tải mà không giải quyết chất lượng corpus.

Lịch refresh cần phản ánh giá trị của từng nguồn

Không nhất thiết kiểm tra mọi URL với cùng một chu kỳ. Một bảng thông báo dịch vụ thường xuyên đổi cần cách theo dõi khác một tài liệu khái niệm ổn định. Nhóm dữ liệu nên phân loại nguồn theo mức ảnh hưởng khi cũ, tần suất thay đổi quan sát được và giới hạn truy cập đã thống nhất. Không chọn chu kỳ ngắn chỉ vì proxy còn băng thông. Tần suất phải phục vụ độ mới cần thiết mà vẫn phù hợp với khả năng và quyền thu thập từ nguồn.

Khi nhiều worker cùng xử lý, cần tránh hai lần refresh ghi đè trạng thái theo thứ tự hoàn tất ngẫu nhiên. Một response cũ trả chậm có thể đến sau response mới. Hàm minh họa không xử lý khóa đồng thời hoặc giao dịch lưu trữ; bên triển khai phải bổ sung phiên bản bản ghi hoặc cơ chế điều phối phù hợp. Kết quả fixture của một hàm thuần không chứng minh kho dữ liệu có khả năng chống ghi đè khi nhiều tiến trình cùng chạy. Phạm vi thử phải được ghi riêng cho trường hợp này.

Đối với nguồn có nhiều trang, còn phải xác định cập nhật từng trang độc lập hay theo một bản phát hành chung. Nếu một chính sách có phần định nghĩa và phần ngoại lệ nằm ở hai URL, tải ở hai thời điểm khác nhau có thể tạo tổ hợp chưa từng tồn tại ở nguồn. Có thể cần nhóm phiên bản hoặc mốc xuất bản do nguồn cung cấp. Khi không thể bảo đảm cùng phiên bản, hệ thống nên giữ sự không chắc của dữ liệu và giới hạn cách sử dụng thay vì giấu nó trong một ngày cập nhật chung.

Một tiêu chí đóng công việc là người nhận có thể chọn một đoạn trích bất kỳ, tra lại nguồn, phiên bản text, lần kiểm tra và chính sách đang cho phép phục vụ đoạn đó. Nếu chỉ tìm được URL nhưng không biết nội dung nào đã vào corpus, xuất xứ vẫn chưa đủ cho điều tra. Có thể bắt đầu với một tập nguồn nhỏ và chứng minh chuỗi truy ngược này trước. Việc mở rộng số URL sau đó có cơ sở hơn việc tải nhiều dữ liệu rồi mới tìm cách giải thích dữ liệu đang được dùng.

Tổng kết về proxy cho RAG pipeline

Hãy bắt đầu từ nguồn được phép, giữ lịch sử phiên bản và kiểm tra vòng refresh trước khi mở rộng corpus. Theo dõi Proxy.vn - Nhà cung cấp dịch vụ proxy chất lượng hàng đầu Việt Nam để cập nhật kiến thức thu thập dữ liệu. Khi đó, anh em có cơ sở đánh giá vai trò và giới hạn của proxy cho RAG pipeline.