Mục lụcChạm để xem nhanh các phần＋
- Tìm đúng tài liệu còn phải tìm đúng tài liệu người hỏi được phép đọc.
- Kiểm tra sau khi đổi vai trò, thu hồi quyền và cập nhật tài liệu.
- Nguồn trích dẫn cũng phải giữ ranh giới truy cập.
Một câu trả lời đúng vẫn có thể lộ dữ liệu
Chatbot nội bộ có thể trả lời chính xác từ tài liệu mà người hỏi không được phép xem. Vì vậy, buổi nghiệm thu cần kiểm tra cả nội dung lẫn quyền truy cập. Một màn trình diễn bằng tài khoản quản trị sẽ không chứng minh nhân viên ở từng phòng ban được bảo vệ đúng.
RAG là cách lấy tài liệu liên quan rồi đưa cho mô hình làm căn cứ trả lời. Doanh nghiệp nên xác định rõ ai được đọc nguồn nào, nguồn thay đổi ra sao và ai chịu trách nhiệm khi quyền không còn đúng. Bài này tập trung vào nghiệm thu ranh giới dữ liệu, bổ sung cho hướng dẫn tổng quan về RAG.
Lập một ma trận nhỏ nhưng có đối chứng
Friday Works đề xuất dùng ít nhất ba vai trò thử: nhân viên kinh doanh, kế toán và quản trị nội dung. Chọn một tài liệu công khai nội bộ, một tài liệu riêng cho kế toán và một tài liệu đã thu hồi. Với mỗi cặp vai trò–tài liệu, ghi kết quả được phép hoặc bị từ chối trước khi chạy kiểm tra.
Câu hỏi nên có cả cách hỏi trực tiếp và cách diễn đạt lại. Ví dụ, tài liệu chứa bảng lương không được đọc bởi kinh doanh thì yêu cầu “tóm tắt chi phí nhân sự” cũng phải giữ ranh giới tương ứng. Đây là tình huống nghiệm thu trên dữ liệu thử, không phải hướng dẫn tìm dữ liệu của người khác.
Kiểm tra quyền ở nơi lấy dữ liệu
OWASP khuyến nghị kiểm tra quyền trên mọi yêu cầu và từ chối mặc định. Trong chatbot, điều đó có nghĩa nguồn tài liệu và công cụ truy xuất cần dựa vào danh tính hiện tại của người dùng. Chỉ viết trong lời nhắc rằng “đừng tiết lộ tài liệu mật” không thay thế kiểm tra quyền phía hệ thống.
Đội kỹ thuật cần giải thích quyền được áp dụng trước khi nội dung được đưa vào mô hình ở đâu. Người nghiệm thu không cần biết toàn bộ thuật toán tìm kiếm nhưng phải có bằng chứng: tài khoản nào hỏi, tài liệu nào được lấy và quy tắc nào cho phép hoặc từ chối. Nhật ký chỉ nên giữ phần cần thiết, tránh tạo thêm kho dữ liệu nhạy cảm.
Đổi quyền rồi hỏi lại
Một lỗi dễ bị bỏ sót là hệ thống vẫn dùng quyền hoặc câu trả lời cũ sau khi nhân viên chuyển bộ phận. Trong môi trường thử, thu hồi quyền, bắt đầu lượt hỏi mới rồi kiểm tra chatbot và đường dẫn nguồn. Làm tương tự với tài liệu bị xóa hoặc chuyển sang nhóm hạn chế.
Nếu hệ thống có bộ nhớ đệm, đội triển khai cần chỉ rõ cơ chế hết hạn hoặc xóa kết quả liên quan khi quyền đổi. Thời gian quyền mới có hiệu lực phải được thống nhất và kiểm tra thực tế. Không đánh dấu nghiệm thu đạt nếu chỉ đăng xuất rồi đăng nhập bằng tài khoản quản trị để xem lại.
Nghiệm thu cả câu trả lời lẫn nguồn
Một câu trả lời bị chặn nhưng đường dẫn tải tài liệu vẫn mở thì công việc chưa xong. Kiểm tra tên tệp, đoạn trích, đường dẫn nguồn và nội dung tải xuống bằng chính vai trò thử. Tài liệu người dùng không được xem cũng không nên được lộ qua phần gợi ý câu hỏi hoặc lịch sử dùng chung.
Biên bản cuối cần ghi trường hợp đã chạy, bằng chứng, ngoại lệ và người chấp nhận rủi ro còn lại. Doanh nghiệp chỉ mở rộng sau khi các tình huống từ chối hoạt động ổn định và có người theo dõi thay đổi quyền. Chất lượng câu trả lời cùng ranh giới dữ liệu là hai tiêu chí độc lập, cần nghiệm thu riêng.
Nguồn tham khảo
Tài liệu đã dùng để biên soạn
Ưu tiên tài liệu chính thức và nguồn kỹ thuật gốc. Truy cập để kiểm tra chi tiết hoặc theo dõi cập nhật mới nhất.