Cách xây dựng một pipeline RAG từ dữ liệu web

Công cụ mở khóa web không rác và Crawl thu thập nội dung web công cộng mà các nhóm có thể chuẩn hóa, lập chỉ mục và truy xuất bên trong một pipeline RAG.

Tại sao chủ đề này quan trọng

Một pipeline sinh tạo tăng cường truy xuất cung cấp cho một mô hình ngôn ngữ quyền truy cập vào một bộ sưu tập kiến thức bên ngoài vào thời điểm trả lời. Tài liệu gốc của bài báo sinh tạo tăng cường truy xuất đã chính thức hóa sự kết hợp giữa kiến thức mô hình tham số và bộ nhớ không tham số được truy xuất. Đối với dữ liệu web, kiến trúc thực tiễn bắt đầu sớm hơn so với nhúng: hệ thống phải phát hiện các trang cho phép, lấy nội dung thực tế của chúng, loại bỏ thanh điều hướng không liên quan, bảo tồn nguồn gốc, và quyết định khi nào mỗi nguồn nên được làm mới.

Bản demo chung tải lên một vài tài liệu và đặt câu hỏi. Một hệ thống RAG web sản xuất phải xử lý các URL chính thức, các mẫu lặp lại, kết xuất JavaScript, chuyển hướng, cập nhật nội dung, các trang đã xóa, và các đoạn văn mâu thuẫn lẫn nhau. Mô hình chỉ thấy những phân đoạn tồn tại trong pipeline này. Nếu những phân đoạn đó đã cũ hoặc tách rời khỏi nguồn của chúng, một mô hình mạnh hơn không thể tạo lại chứng cứ thiếu.

Hai khía cạnh của hệ thống RAG web

Phần ngoại tuyến hoặc bất đồng bộ là pipeline lập chỉ mục. Nó phát hiện tài liệu, thu thập nội dung, phân tích văn bản có ý nghĩa, gán định danh, chia tài liệu thành các đơn vị có thể truy xuất, tạo đại diện tìm kiếm, và ghi chúng vào một chỉ mục. Thuật ngữ ngoại tuyến là tương đối: một nguồn thay đổi thường xuyên có thể được xử lý lại trong suốt cả ngày, nhưng lập chỉ mục vẫn tách biệt với câu hỏi của người dùng.

Phần trực tuyến bắt đầu với một truy vấn. Nó có thể phân loại ý định, áp dụng bộ lọc truy cập, viết lại câu hỏi, thực hiện truy xuất từ khóa hoặc vector, gộp kết quả, và xếp lại các ứng viên. Tài liệu nhúng của OpenAI mô tả nhúng như các đại diện vector hữu ích cho các nhiệm vụ liên quan, nhưng sự tương đồng vector một mình không chứng minh rằng một đoạn văn trả lời câu hỏi. Bộ lọc siêu dữ liệu, khớp từ vựng, xếp lại, và quy tắc chất lượng nguồn thường có trọng số như nhau.

Bộ sinh nhận một gói chứng cứ cố ý giới hạn. Các gợi ý tốt phân biệt văn bản nguồn từ hướng dẫn, yêu cầu trích dẫn tài liệu cung cấp, và cho phép một câu trả lời rõ ràng về việc thiếu chứng cứ. Ứng dụng sau đó xác thực các mục tiêu trích dẫn và ghi lại các đoạn văn đã sử dụng. Điều này tạo ra một dấu vết từ tuyên bố cuối cùng đến phân đoạn, tài liệu, và trang chính thức.

Các giai đoạn lập chỉ mục dữ liệu web

• Khám phá các nguồn. Bắt đầu từ sơ đồ trang, danh sách URL được chọn lọc, nguồn cấp, hoặc kết quả tìm kiếm cho phép; ghi lại lý do mỗi trang thuộc về tập hợp tài liệu.
• Thu thập nội dung. Lấy các trang tĩnh trực tiếp và chỉ sử dụng thu thập bằng cách kết xuất khi nội dung phía khách hàng thay đổi chứng cứ vật liệu.
• Chuẩn hóa tài liệu. Loại bỏ sự lặp lại trong điều hướng, bảng cookie, kịch bản, và các mẫu trùng lặp trong khi giữ lại tiêu đề, danh sách, bảng, và bối cảnh liên kết.
• Phân đoạn với nguồn gốc. Tạo các đoạn văn đồng nhất và đính kèm URL chính thức, tiêu đề, đường dẫn tiêu đề, ngôn ngữ, phạm vi truy cập, băm, và thời gian thu thập.
• Lập chỉ mục và phiên bản. Ghi lại các đại diện từ vựng và vector dưới các định danh tài liệu ổn định để những tài liệu đã thay đổi và bị xóa có thể được điều chỉnh.

Quyết định phân đoạn và truy xuất

Các cài đặt tốt nhất phụ thuộc vào hình dạng tài liệu và loại câu hỏi. Xem mỗi lựa chọn như một giả thuyết có thể kiểm chứng chứ không phải là một hằng số phổ quát.

Xây dựng Quy trình theo Các Giai đoạn Có thể Xác minh

Thực hiện từng giai đoạn với đầu vào, đầu ra, và điều kiện thử nghiệm riêng. Điều này làm cho một lần truy xuất bỏ lỡ có thể chẩn đoán mà không đổ lỗi cho mô hình vì mọi thất bại.

1. Định nghĩa hợp đồng tập hợp. Liệt kê các miền được phê duyệt, loại trang, ngôn ngữ, loại trừ, quyền sở hữu, quy tắc giữ dữ liệu, và các câu hỏi mà tập hợp phải trả lời.
2. Tạo ID tài liệu chuẩn. Chuẩn hóa URL cẩn thận, tôn trọng tín hiệu chuẩn, và tránh gộp các trang có ngữ cảnh, sản phẩm, hoặc phiên bản thay đổi ý nghĩa của chúng.
3. Bảo tồn ngữ cảnh có cấu trúc. Giữ tiêu đề, mối quan hệ bảng, ranh giới mã, và nhãn liên kết gần. Việc làm phẳng văn bản có thể phá hủy ý nghĩa của tài liệu kỹ thuật ngắn gọn.
4. Xây dựng một tập câu hỏi có nhãn. Viết câu hỏi đại diện và xác định các đoạn văn nên hỗ trợ mỗi câu trả lời. Bao gồm các trường hợp có thể trả lời, mơ hồ, và không thể trả lời.
5. Thêm điều hòa thay đổi. So sánh mã băm nội dung, thay thế các đoạn đã thay đổi một cách nguyên tử, xóa tài liệu đã bị xoá, và giữ đủ lịch sử phiên bản để giải thích các câu trả lời trước đó.

Đánh giá Truy xuất Trước Chất lượng Trả lời

Một câu trả lời lưu loát có thể che giấu một lần truy xuất bỏ lỡ, và một câu trả lời mơ hồ có thể vẫn nhận được bằng chứng hoàn hảo. Đánh giá các giai đoạn riêng biệt, sau đó đánh giá kết quả tổng thể của người dùng.

• Phạm vi tập hợp. Liệu bộ sưu tập đã chỉ mục có chứa tài liệu xác thực cho mỗi loại câu hỏi được hỗ trợ không?
• Nhớ lại truy xuất. Liệu tập ứng viên có bao gồm một đoạn văn hỗ trợ câu trả lời mong đợi không?
• Độ chính xác xếp hạng. Liệu các đoạn văn hỗ trợ có được đặt ở trên văn bản liên quan hoặc trùng lặp không?
• Hỗ trợ trích dẫn. Liệu mỗi đoạn văn được trích dẫn có chứa xác nhận cụ thể đi kèm với nó không?
• Kìm chế trả lời. Liệu hệ thống có từ chối hoặc đủ điều kiện cho một câu trả lời khi tập hợp thiếu bằng chứng đủ không?

Chế độ Thất bại Cụ thể trên Web

Nội dung Web là đầu vào không đáng tin cậy được chuyển tiếp Cách hiểu về ngữ nghĩa HTTP. Mã thu thập nên thực thi quy tắc máy chủ, loại nội dung, kích thước và chuyển hướng trước khi tài liệu đến giai đoạn phân tích hoặc mô hình.

• Ô nhiễm mẫu. Tiêu đề và chân trang lặp đi lặp lại thống trị tìm kiếm tương tự và làm choáng ngợp đoạn văn chứa câu trả lời.
• Danh tính trùng lặp. Các tham số theo dõi và các đường dẫn thay thế tạo ra nhiều bản ghi cho một trang, thổi phồng bằng chứng mà không thêm sự hỗ trợ độc lập.
• Ô nhiễm hướng dẫn. Một trang có thể chứa hướng dẫn nhắm đến các mô hình. Lưu trữ văn bản nguồn như bằng chứng được trích dẫn và không bao giờ cấp quyền cho nó kiểm soát truy xuất hoặc chính sách hệ thống.
• Nhúng cũ. Cập nhật văn bản thô mà không thay thế đại diện vector của nó để lại chỉ mục không nhất quán bên trong.
• Tổng hợp không được hỗ trợ. Bộ sinh có thể kết hợp những đoạn văn riêng lẻ thành một kết luận mà không nguồn nào nói đến.

Mẫu RAG Web

Từ Thí điểm đến Sản xuất

Một thí điểm hữu ích cho quy trình RAG từ dữ liệu web nên đủ nhỏ để kiểm tra từng bản ghi. Bắt đầu với xác định hợp đồng tập hợp: Liệt kê các miền đã được phê duyệt, loại trang, ngôn ngữ, loại trừ, quyền sở hữu, quy tắc giữ lại và các câu hỏi mà tập hợp phải trả lời. Sau đó áp dụng tạo id tài liệu chuẩn: Chuẩn hóa URL một cách cẩn thận, tôn trọng các tín hiệu chuẩn và tránh hợp nhất các trang có địa điểm, sản phẩm hoặc phiên bản thay đổi ý nghĩa của chúng. Giữ tập đầu tiên được đánh giá cố ý hỗn hợp, bao gồm các trường hợp thông thường, các trường hợp mơ hồ, bằng chứng thiếu và một hành động mà hệ thống phải từ chối hoặc giao cho người khác. Điều này cho thấy có phải quy trình làm việc hiểu ranh giới của nó trước khi khối lượng lớn che lấp lỗi thiết kế bên trong các chỉ số tổng hợp hay không.

Sự sẵn sàng sản xuất yêu cầu một chủ sở hữu cho mỗi chỉ số và hiện vật. Theo dõi phạm vi tập hợp để trả lời xem liệu bộ sưu tập đã được chỉ mục có chứa tài liệu có thẩm quyền cho mỗi loại câu hỏi được hỗ trợ không? Theo dõi nhớ truy xuất để xác định xem liệu tập hợp ứng viên có bao gồm một đoạn văn hỗ trợ câu trả lời mong đợi không? Thêm độ chính xác phân loại để nhóm có thể thấy liệu các đoạn hỗ trợ có được đặt trên văn bản liên quan hoặc trùng lặp chỉ đơn giản hay không? Các số liệu này nên liên kết với các bản ghi cơ bản thay vì chỉ tồn tại như tổng bảng điều khiển. Một người xem cần di chuyển từ một chỉ số đã thay đổi đến truy vấn, nguồn, quan sát hoặc hành động chính xác đã tạo ra nó.

Các kiểm soát hoạt động nên nhắm vào các chế độ thất bại có khả năng thay đổi quyết định kinh doanh nhất. Quy tắc xem xét đầu tiên nên bao gồm ô nhiễm mẫu: Các tiêu đề và chân trang lặp lại chiếm ưu thế trong tìm kiếm tương đồng và làm lu mờ đoạn văn chứa câu trả lời. Cuộc xem xét thoát nên bao gồm tổng hợp không được hỗ trợ: Bộ sinh có thể kết hợp những đoạn văn riêng lẻ thành một kết luận mà không nguồn nào nói đến. Các kiểm tra trích dẫn ở cấp độ yêu cầu tìm thấy khoảng trống đó. Gán một chủ sở hữu phản hồi, xác định bằng chứng nào giải quyết vấn đề, và ghi lại xem liệu kết quả có thay đổi dữ liệu, nhắc nhở, công cụ, quyền truy cập hoặc chính sách nguồn hay không. Kỷ lục đó ngăn ngừa việc phát hiện lại cùng một sai sót như một biến động chất lượng chưa được giải thích.

Mở rộng chỉ sau khi thí điểm hoạt động dự đoán. Một nhóm có thể bắt đầu với trợ lý tài liệu, nơi công việc là chỉ mục các trang sản phẩm và chính sách đã được phê duyệt với metadata phiên bản để các câu trả lời trỏ đến phần hiện tại. Một giai đoạn thứ hai có thể thêm nơi làm việc nghiên cứu, nơi quy trình làm việc phải thu thập các nguồn gốc chính, bảo tồn các đoạn văn và cho phép các nhà phân tích so sánh bằng chứng mà không làm mất dấu vết trang. Giữ cho tập thử nghiệm gốc tiếp tục hoạt động khi phạm vi mở rộng. Các nguồn, thị trường, công cụ và quyền truy cập mới nên được giới thiệu một biên giới cùng một lúc để các sự thoái lui có thể được gán cho một thay đổi cụ thể thay vì một bản viết lại nền tảng đồng thời.

Kết luận

Một quy trình RAG web thành công khi việc thu thập, chuẩn hóa, truy xuất và tạo ra chia sẻ một mô hình nguồn gốc. Mỗi câu trả lời nên có thể truy vết đến một đoạn, mỗi đoạn đến một tài liệu có phiên bản và mỗi tài liệu đến một nguồn được phép. Chuỗi đó quan trọng hơn sự lựa chọn của cơ sở dữ liệu vector.

Xây dựng tập hợp nhỏ nhất bao gồm một bộ câu hỏi thực, đánh giá truy xuất trên các ví dụ có nhãn và thêm quy tắc mới trước khi mở rộng. Quy mô web trở nên quản lý được khi mỗi nguồn mới theo cùng một danh tính, bằng chứng và hợp đồng xóa.