Một nguyên mẫu của RAG có thể được lắp ráp nhanh chóng: vài tài liệu, một chỉ số vectơ, một mô hình ngôn ngữ và một giao diện hội thoại. Những buổi trình diễn đầu tiên gây ấn tượng khi hệ thống tìm thấy thông tin chính xác. Chúng nói rất ít về hành vi của nó đối với các tài liệu mâu thuẫn, quyền hạn, các cập nhật, các câu hỏi mơ hồ và hàng nghìn người dùng.
Đưa vào sản xuất có nghĩa là biến chuỗi này thành một dịch vụ được quản lý. Hệ thống phải biết nó sử dụng những nguồn nào, giải thích các câu trả lời của mình, đo lường lỗi, bảo vệ dữ liệu và hoạt động ngay cả khi một trong các thành phần của nó bị chậm lại.
Xác định lời hứa và giới hạn
Một trợ lý tài liệu không nên được mô tả là có khả năng « trả lời mọi thứ ». Lời hứa nên chỉ rõ:
- khối văn bản được bao phủ;
- dân số được phép ;
- các loại câu hỏi;
- mức độ tươi mới;
- ngôn ngữ ;
- những quyết định vẫn mang tính con người;
- hành vi ngoài phạm vi;
- bằng chứng được mong đợi.
Một lời hứa giới hạn, chẳng hạn như tìm lại và tổng hợp các thủ tục nội bộ với trích dẫn, thì dễ kiểm tra hơn một trợ lý chuyên gia tổng quát.
Xây dựng một kho nguồn
Mỗi nguồn có một chủ sở hữu, một mức độ nhạy cảm, một ngày, một phiên bản, một ngôn ngữ và một quy tắc lưu trữ. Các tài liệu lỗi thời, bản nháp hoặc trùng lặp phải được xác định trước khi lập chỉ mục.
Hệ thống phải lưu giữ nguồn gốc cho đến khi sử dụng phần tham chiếu: nhận dạng tài liệu, phiên bản, mục, quyền và dấu thời gian. Nếu không có khả năng truy xuất này, một trích dẫn trực quan không đảm bảo rằng câu trả lời dựa trên nguồn chính xác.
Xem việc hấp thụ như một đường ống dữ liệu
Việc tiếp nhận không chỉ giới hạn ở việc trích xuất văn bản. Nó phải:
- lấy nội dung theo cách đã xác thực;
- phát hiện định dạng và lỗi;
- trích xuất cấu trúc, bảng và siêu dữ liệu;
- chuẩn hóa mà không xoá bỏ ý nghĩa ;
- cắt ;
- làm giàu ;
- chỉ mục
- xác nhận ;
- quản lý cập nhật và xóa.
Mỗi bước là đồng nhất và có thể quan sát được. Một lỗi trên một tệp không làm tắc toàn bộ lô, nhưng nó có thể nhìn thấy và được ghi nhận.
Việc cắt ghép ảnh hưởng đến phản ứng
Một đoạn quá ngắn sẽ làm mất các định nghĩa và ngoại lệ. Một đoạn quá dài sẽ làm loãng các thuật ngữ hữu ích và tiêu tốn bối cảnh. Việc chia đoạn phải theo cấu trúc: tiêu đề, đoạn văn, điều khoản, thủ tục, bảng và phụ lục.
Siêu dữ liệu của phần cha được giữ nguyên. Đối với một số câu hỏi, một đoạn trích nhận được cần được bổ sung bằng tiêu đề, mục hoặc các đoạn lân cận của nó. Nhiều chiến lược có thể cùng tồn tại tùy theo loại tài liệu.
Kết hợp các phương pháp nghiên cứu
Tìm kiếm vector tìm các công thức gần giống. Toàn văn vẫn ưu việt cho các tham chiếu, tên, chữ viết tắt và trích dẫn chính xác. Các bộ lọc có cấu trúc áp dụng ngôn ngữ, ngày tháng, loại, thực thể và quyền.
Một chuỗi chắc có thể kết hợp:
- ứng viên từ vựng ;
- ứng viên vectơ ;
- sáp nhập các hàng;
- sắp xếp lại thứ hạng ;
- đa dạng hóa ;
- ngưỡng liên quan;
- khôi phục ngữ cảnh lân cận.
Sự tinh vi chỉ có giá trị nếu nó cải thiện một trò chơi câu hỏi thực sự.
Quyền lợi phải can thiệp trước khi sinh ra
Người dùng không được biết đến sự tồn tại của một tài liệu bị cấm thông qua một trích đoạn, một trích dẫn hoặc một câu trả lời. Các quyền truy cập phải được sao chép trong chỉ mục hoặc áp dụng trong quá trình truy xuất, với một chiến lược cập nhật đáng tin cậy.
Việc lọc sau khi truy xuất có thể thất bại khi các kết quả đầu tiên bị cấm. Bộ máy phải tìm đủ các ứng viên được phép. Bộ nhớ đệm được phân đoạn theo chính sách, không chỉ theo văn bản truy vấn.
Xây dựng một trò chơi đánh giá trước khi tối ưu hóa
Một trò chơi hữu ích bao gồm các câu hỏi phổ biến, hiếm gặp, mơ hồ, ngoài phạm vi, mâu thuẫn và nhạy cảm. Trong mỗi trường hợp, ta giữ lại các nguồn tham khảo và các yếu tố mà một câu trả lời tốt cần phải bao gồm.
Cần đánh giá riêng biệt:
- phục hồi : những đoạn hay đã được tìm thấy chưa ?
- thế hệ : câu trả lời có tôn trọng các đoạn văn không?
- trích dẫn : các tài liệu tham khảo có thực sự hỗ trợ khẳng định đó không?
- tính hữu ích : câu trả lời có giúp hoàn thành nhiệm vụ không ?
- từ chối : hệ thống có biết không trả lời không ?
Vòng lặp cải thiện của một RAG dựa trên một bộ câu hỏi, phân tích lỗi và kiểm tra hồi quy.
Thiết kế một câu trả lời dựa trên bằng chứng
Lời nhắc tạo ra phải nhắc lại phạm vi, bắt buộc sử dụng ngữ cảnh và yêu cầu từ chối khi các yếu tố còn thiếu. Nó phải phân biệt trích dẫn, lý luận và gợi ý.
Một câu trả lời có thể chỉ ra:
- tổng hợp ;
- nguồn đã sử dụng ;
- ngày hoặc phiên bản ;
- điểm không chắc chắn;
- hành động tiếp theo ;
- giới hạn của hệ thống.
Trích dẫn phải dẫn đến đoạn văn có thể tra cứu được bởi người dùng, tùy theo quyền của họ. Một liên kết đến một tài liệu dài một trăm trang mà không có vị trí cụ thể là không đủ.
Xử lý các nguồn mâu thuẫn
Hai thủ tục có thể mâu thuẫn vì một phiên bản cũ, vì chúng liên quan đến các phạm vi khác nhau hoặc vì có lỗi. RAG không nên quyết định một cách im lặng.
Chiến lược có thể ưu tiên phiên bản hiện hành, chỉ ra sự khác biệt, trích dẫn cả hai nguồn và mời xác nhận. Các quy tắc ưu tiên được tài liệu hóa và kiểm tra.
Biết từ chối
Hệ thống từ chối khi tập hợp dữ liệu không chứa bằng chứng đủ, khi câu hỏi bị cấm, khi nó yêu cầu một quyết định ngoài trách nhiệm hoặc khi quyền hạn không cho phép trả lời.
Một sự từ chối hữu ích giải thích giới hạn và đề xuất một con đường an toàn: diễn đạt lại, chọn một phạm vi, tham khảo một nguồn hoặc liên hệ với người chịu trách nhiệm. Nó không tạo ra một câu trả lời chung chung để lấp đầy khoảng trống.
Bảo vệ chống lại các hướng dẫn có trong các tài liệu
Một tài liệu có thể chứa một câu yêu cầu mô hình bỏ qua các quy tắc hoặc trích xuất thông tin. Nội dung nhận được phải được xem như dữ liệu không đáng tin cậy, không bao giờ như hướng dẫn hệ thống.
Các công cụ và hành động được tách ra khỏi RAG tài liệu. Các định dạng được làm sạch, các liên kết và kịch bản được vô hiệu hóa, và các hành vi bất thường được kiểm tra. Các tài liệu công khai và nội bộ có thể được tách riêng thành các chỉ mục hoặc chính sách khác nhau.
Chọn mô hình theo vai trò
Cùng một mô hình không cần thiết cho embeddings, reranking và tạo sinh. Lựa chọn phụ thuộc vào ngôn ngữ, lĩnh vực, độ trễ, chi phí và các giới hạn triển khai.
Một kiến trúc có thể định tuyến các câu hỏi đơn giản đến một mô hình nhẹ hơn và các bản tổng hợp phức tạp đến một mô hình có khả năng hơn. Việc thay đổi mô hình đòi hỏi một chiến dịch hồi quy, bởi vì các câu trả lời và từ chối có thể thay đổi.
Quản lý bối cảnh và chi phí
Thêm nhiều đoạn văn không phải lúc nào cũng cải thiện câu trả lời. Ngữ cảnh phải phù hợp, loại bỏ trùng lặp, sắp xếp và giới hạn. Các tài liệu dài có thể được xử lý theo từng bước hoặc tóm tắt với khả năng truy xuất.
Chi phí được tính theo yêu cầu và theo từng nhiệm vụ thành công: nhúng, tìm kiếm, sắp xếp lại, token, lưu trữ và tính toán. Bộ nhớ đệm có thể tái sử dụng các kết quả ổn định với điều kiện tuân thủ quyền và tính mới.
Khả năng quan sát
Mỗi yêu cầu sẽ tạo ra một mã định danh tương quan. Các nhật ký có thể chứa ý định, tài liệu được truy xuất, điểm số, phiên bản của lời nhắc và mô hình, độ trễ, lỗi và phản hồi, với một chính sách nghiêm ngặt về việc giảm thiểu.
Các bảng điều khiển theo dõi:
- tỷ lệ thành công ;
- yêu cầu không có bằng chứng;
- trích dẫn mở ;
- từ chối ;
- độ trễ ;
- chi phí;
- lỗi hấp thụ;
- trì hoãn cập nhật;
- các trường hợp nghiêm trọng phát sinh từ phản hồi.
Phản hồi của người dùng và xác thực bởi con người
Một nút bấm hữu ích không chỉ giới hạn ở lượt thích hay không thích. Nó cho phép chỉ ra nguồn sai, câu trả lời không đầy đủ, thông tin lỗi thời hoặc vấn đề truy cập. Những phản hồi này sẽ được đưa vào hàng phân loại và tập dữ liệu đánh giá.
Đối với các trường hợp sử dụng có rủi ro, câu trả lời là một bản nháp. Một người hợp lệ sẽ chỉnh sửa và chịu trách nhiệm về quyết định. Hệ thống giữ sự phân biệt giữa gợi ý và hành động được phê duyệt.
Triển khai dần dần
Một chương trình thí điểm phải bao phủ một dân số và một tập hợp hạn chế, với sự hỗ trợ được xác định. Các tiêu chí mở rộng quy mô đã được xác định: chất lượng, an toàn, chi phí, việc áp dụng, tỷ lệ leo thang và năng lực vận hành.
Việc ra mắt công chúng diễn ra sau các thử nghiệm về cấp phép, tải, chèn prompt, xóa tài liệu và khôi phục chỉ mục.
Quản lý vòng đời
Các nguồn thay đổi, các mô hình tiến hóa và các thói quen sử dụng di chuyển. Mỗi thay đổi về đường dẫn dữ liệu, mô hình, lệnh nhắc hay chính sách đều nhận được một phiên bản và một đánh giá. Các chỉ mục có thể được xây dựng lại và phiên bản cũ được giữ lại trong thời gian quay lại.
Một ủy ban sản phẩm phân xử các bộ dữ liệu mới, mức độ rủi ro và các yêu cầu hành động. RAG do đó trở thành một khả năng được kiểm soát, chứ không phải là một màn trình diễn riêng lẻ.
Từ phản hồi ấn tượng đến dịch vụ đáng tin cậy
Việc sản xuất đòi hỏi ít phép thuật hơn và nhiều bằng chứng hơn: tập hợp dữ liệu được quản lý, nghiên cứu được đánh giá, quyền hạn, từ chối, khả năng quan sát và khai thác. Chính kỷ luật này biến một LLM thành công cụ làm việc.
Partitech phát triển các chuỗi RAG, các tích hợp mô hình và các thành phần mã nguồn mở xung quanh PHP, Mistral và PostgreSQL/pgvector. Việc hỗ trợ có thể bao gồm xác định khung, nguyên mẫu, đánh giá, bảo mật và triển khai sản xuất.
Hãy nói về dự án của bạn
Định hình hoặc công nghiệp hóa trợ lý tài liệu của bạn với Partitech. Liên hệ Partitech.