Kiểm kê dữ liệu trước khi xây trợ lý hỏi đáp
Kiểm tra nguồn, phiên bản, mục đích sử dụng và quyền truy cập của một trợ lý hư cấu, rồi lần theo bản sao để thiết kế bài tập thu hồi tài liệu.
Một sản phẩm đầu tiên hữu ích khi xây trợ lý tra cứu sổ tay là bảng kiểm kê nhỏ, giải thích mỗi nguồn hỗ trợ nội dung nào, ai được sử dụng và thay đổi sẽ được chuyển đến các bản sao ra sao. Một thư mục chứa các tệp đọc được chưa trả lời những câu hỏi đó. Chạy tạo embedding thành công cũng vậy.
Theo tôi, nên bắt đầu bằng một câu hỏi của người đọc rồi lần theo dẫn chứng trước khi thêm tài liệu. Cách làm này biến khâu chuẩn bị dữ liệu thành công việc kỹ thuật cụ thể: xác định nguồn, giữ nguyên thông tin nhận diện, kiểm soát việc sử dụng và duy trì câu trả lời cập nhật. Những thói quen ấy cũng hữu ích khi học một hệ công nghệ AI mới vì chúng làm rõ phần việc mà một bản trình diễn mô hình dễ che khuất.
Bắt đầu với một câu hỏi và năm nguồn
Hãy xét một trợ lý nội bộ hư cấu trả lời câu hỏi: “Tôi cần gửi yêu cầu sửa máy tính xách tay ở đâu?” Đối tượng dự kiến là toàn bộ nhân viên. Người phụ trách nguồn đã đồng ý dùng sổ tay hiện hành cho mục đích tra cứu nội bộ này và trong môi trường xử lý dự kiến. Đây là ví dụ học tập có phạm vi xác định, không mô tả tài liệu của một nơi làm việc có thật.
Thư mục ứng viên chứa các bản ghi sau:
| Bản ghi | Nội dung | Quyết định ban đầu |
|---|---|---|
| H3 | Sổ tay nhân viên hiện hành: dùng Helpdesk | Đưa vào sau khi kiểm tra phiên bản và quyền truy cập của nhân viên |
| H2 | Sổ tay đã ngừng áp dụng: liên hệ Facilities | Loại khỏi câu trả lời về chính sách hiện hành |
| M1 | Biên bản họp vận hành có hạn chế truy cập | Loại khỏi kho tài liệu dành cho toàn bộ nhân viên |
| V1 | Trang xử lý sự cố công khai của nhà cung cấp | Tạm giữ ngoài kho đến khi làm rõ mục đích sử dụng và điều kiện xử lý |
| S1 | Sổ tay giả lập được viết riêng cho bài tập | Dùng trong bộ dữ liệu thử, tách rõ khỏi chính sách thật |
Bảng này ghi lại quyết định, không coi năm đầu vào có độ tin cậy ngang nhau. Chỉ dựa vào thời điểm sửa tệp mới hơn chưa thể xác định H3 đã thay thế H2. Cần đề nghị người phụ trách nguồn xác nhận tài liệu đang có hiệu lực rồi lưu quyết định đó. Một bản sao của sổ tay cũ có thể mang thời điểm sửa mới nhất trong thư mục.
Phạm vi nội dung cũng có giới hạn. H3 có thể chỉ rõ kênh tiếp nhận sửa chữa nhưng không quy định thời hạn sửa hay chính sách hoàn chi phí. Những câu hỏi đó cần dẫn chứng riêng. Bảng kiểm kê nên thể hiện khoảng trống này trước khi trợ lý bắt đầu lấp nó bằng những câu nghe có vẻ hợp lý.
Việc tiếp nhận tài liệu phụ thuộc vào mục đích, nguồn có thẩm quyền và đối tượng sử dụng. Công cụ nhập dữ liệu đọc được tệp chỉ là một điều kiện để cân nhắc.
Ghi lại quyết định để người khác có thể kiểm tra
Bài báo Datasheets for Datasets đề xuất các câu hỏi về động cơ xây dựng, thành phần, cách thu thập, tiền xử lý, mục đích sử dụng, phân phối và bảo trì bộ dữ liệu. Các câu hỏi đề cập đến thông tin nhạy cảm, cách sử dụng được phép, quyền sở hữu, cập nhật và phiên bản đã lỗi thời. Tôi thấy cấu trúc này hữu ích cho một trợ lý nhỏ ngay cả khi không cần xuất bản bộ tài liệu mô tả dữ liệu đầy đủ.
Với H3, hãy tạo một mục kiểm kê gồm các trường sau:
- Thông tin nhận diện: mã nguồn, phiên bản ghi rõ, xác nhận của người phụ trách rằng đây là nguồn có hiệu lực và giá trị băm của đúng các byte đã nhập.
- Mục đích và quyền sử dụng: cách sử dụng được phép, nơi dự kiến xử lý, người đã đồng ý và nơi lưu quyết định đó.
- Đối tượng truy cập: ai được truy xuất tài liệu, quy tắc quyền đến từ đâu và thay đổi được chuyển đến hệ thống tìm kiếm thế nào.
- Phạm vi nội dung: câu hỏi được hỗ trợ, câu hỏi chưa được hỗ trợ và các phần bị bỏ qua khi nhập.
- Vòng đời: đầu mối cập nhật, quy tắc lưu giữ, quy trình thu hồi và các bản sao phát sinh đã biết.
Giá trị băm trả lời một câu hỏi hẹp: hai chuỗi byte có khớp với giá trị băm đã ghi hay không, trong giới hạn đặc tính của hàm băm được chọn. Nó không chứng minh nguồn là đúng, có giấy phép phù hợp, đang còn hiệu lực hay đã được đồng ý sử dụng. Hãy giữ các quyết định đó ở những trường riêng thay vì gộp vào một ô “đã xác minh”.
Chưa rõ quyền sử dụng là một phát hiện hữu ích. Trong ví dụ này, V1 tiếp tục nằm ngoài kho dự kiến trong lúc người phụ trách nguồn hoặc người đánh giá phù hợp làm rõ cách sử dụng. Việc một trang có thể được truy cập công khai không giải quyết mọi câu hỏi về tái sử dụng hay xử lý. Quyền dùng tài liệu để tra cứu nội bộ cũng không tự động xác lập quyền huấn luyện mô hình hoặc gửi nội dung sang nhà cung cấp khác. Hãy ghi đúng mục đích đang xem xét thay vì coi sự đồng ý là không giới hạn.
Bài báo xem việc lập tài liệu là quá trình suy xét, không phải việc công cụ có thể tự quyết định. Phần mô tả thư mục do mô hình tạo ra có thể giảm công gõ. Nó không thay thế được quyết định còn thiếu từ người phụ trách nguồn.
Lần theo tài liệu ra ngoài tệp gốc
Giả sử H3 tạo ra các đoạn C31 và C32, các bản ghi chỉ mục I31 và I32, cùng câu trả lời được lưu đệm A7 có dẫn C31. Một bộ dữ liệu bài tập riêng S1 tạo ra T1. Giữ mã của các nguồn đầu vào trên những sản phẩm này để có thể lần theo quan hệ theo cả hai hướng.
Lúc này bảng kiểm kê có thể trả lời một câu hỏi thực tế: nếu H3 bị thu hồi, những sản phẩm nào đang phục vụ người dùng phụ thuộc vào nó? Trong ví dụ này, C31, C32, I31, I32 và A7 đều cần được xử lý. T1 không có H3 làm nguồn đầu vào nên vẫn có thể dùng cho bài tập tách biệt.
Quan hệ phụ thuộc không nhất thiết tạo thành một cây đơn giản. Một câu trả lời có thể kết hợp hai tài liệu. Nếu A7 dẫn cả H3 lẫn một nguồn khác vẫn được phép sử dụng, việc thu hồi H3 vẫn làm A7 không còn phù hợp cho mục đích này. Cần tạo lại hoặc loại bỏ câu trả lời theo chính sách sản phẩm; không giữ nguyên chỉ vì một nguồn đầu vào vẫn hợp lệ.
Mũi tên mô tả quan hệ nguồn gốc trong hệ thống đề xuất. Chúng không có nghĩa rằng xóa nguồn sẽ tự động xóa mọi sản phẩm phát sinh từ nguồn đó.
Nhật ký, bộ dữ liệu đánh giá đã xuất và bản sao lưu cũng cần được ghi rõ. Nhật ký lưu văn bản truy xuất được là một bản sao nội dung nữa. Chỉ mục vector là sản phẩm phát sinh; gọi nó là embedding không phải cơ sở để mặc định nó đã được ẩn danh hoặc nằm ngoài quy trình thu hồi.
Điều này không đồng nghĩa phải xóa ngay mọi bản sao lưu. Chính sách lưu giữ và khôi phục có thể yêu cầu cách xử lý khác. Cần ghi nhận hạn chế, kiểm soát truy cập và bảo đảm khi khôi phục sẽ áp dụng lại các quyết định thu hồi hiện hành trước khi dữ liệu trở lại phục vụ người đọc. “Đã loại khỏi tìm kiếm đang hoạt động” và “đã xóa khỏi mọi bản sao còn lưu giữ” là hai khẳng định khác nhau. Bảng kiểm kê cần thể hiện điều nào đã thực sự được xác lập.
Kiểm tra quyền tại nơi truy xuất diễn ra
Quyền truy cập tài liệu là một phần của thiết kế truy xuất. Trong ví dụ này, dịch vụ cần dùng danh tính người gọi đã được xác thực cùng quyền trên tài liệu trước khi đưa ngữ cảnh vào mô hình. Ẩn trích dẫn bị hạn chế sau khi sinh câu trả lời là quá muộn nếu nội dung đó đã đến mô hình hoặc một nơi xử lý không được phép.
Tổng quan quyền truy cập cấp tài liệu của Azure AI Search minh họa một chi tiết đáng kiểm tra ở bất kỳ hệ công nghệ nào: quyền có thể được sao chép vào chỉ mục. Các cơ chế dựa trên token được mô tả trong trang đối chiếu thông tin của người gọi với siêu dữ liệu quyền đã được lưu ở đó. Bản tổng quan được kiểm tra vào tháng 9 năm 2026 đánh dấu những cơ chế tích hợp này là tính năng xem trước và mô tả yêu cầu đồng bộ riêng cho từng nguồn. Đây là ví dụ về giới hạn cần tìm hiểu, không phải khẳng định rằng mọi sản phẩm tìm kiếm đều hoạt động giống nhau.
Vì vậy, thay đổi quyền ở nguồn cần có quy trình vận hành tương ứng. Hãy xác định khi nào siêu dữ liệu trong chỉ mục thay đổi, điều gì xảy ra trong thời gian chờ và cách ngăn tài liệu bị từ chối xuất hiện lại sau khôi phục. Phép kiểm tra quyền có thể được cài đặt đúng theo siêu dữ liệu cũ nhưng vẫn không đáp ứng thời hạn thu hồi mà sản phẩm yêu cầu.
Câu trả lời lưu đệm cũng cần được xem xét như vậy. Câu trả lời được tạo cho người đọc có quyền không được trở thành lối truy cập không hạn chế cho người tiếp theo. Chỉ tái sử dụng khi đáp ứng các điều kiện truy cập cần thiết, hoặc chưa chia sẻ câu trả lời cho đến khi hệ thống có thể thực thi các điều kiện đó. Đây là yêu cầu thiết kế cần triển khai và kiểm thử, không phải điều được bảo đảm chỉ nhờ có bảng kiểm kê.
Kết thúc bằng bài tập thu hồi
Trước khi mở rộng kho tài liệu, hãy diễn tập ba thay đổi trên bộ dữ liệu hư cấu: thu hồi H3, thay đổi đối tượng được phép đọc, và thay đoạn hướng dẫn sửa chữa bằng phiên bản H4 đã được người phụ trách nguồn đồng ý. Với mỗi thay đổi, hãy viết hành vi mong đợi của truy xuất hiện tại, các câu trả lời đã lưu đệm và một chỉ mục cũ được khôi phục.
Khi thu hồi, năm sản phẩm phụ thuộc đang hoạt động kể trên không được tiếp tục cung cấp nội dung bị thu hồi; bộ dữ liệu giả lập không liên quan vẫn phải dùng được. Khi thay đổi đối tượng, hãy kiểm tra một người gọi bị ảnh hưởng và một người không bị ảnh hưởng. Với H4, đặt lại câu hỏi về sửa chữa rồi kiểm tra cả thông tin nhận diện nguồn mới lẫn nội dung câu trả lời. Hai phiên bản có thể chứa cùng một câu, nên chỉ thấy câu trả lời khớp chưa chứng minh đã nhập đúng phiên bản mong muốn.
Đây là các phép kiểm tra được đề xuất, không phải kết quả từ một trợ lý đã triển khai. Giá trị của chúng nằm ở kết quả quan sát được và người chịu trách nhiệm cho từng phép kiểm tra. Bảng kiểm kê nhỏ vẫn tốn công duy trì; theo dõi riêng từng đối tượng tạm thời có thể trở nên rườm rà. Hãy bắt đầu bằng mã nhận diện bền vững và các bản sao có thể đến người dùng, bên xử lý hoặc hệ thống được khôi phục. Mở rộng hồ sơ khi quy trình tạo thêm một bản sao có ảnh hưởng đáng kể.
Bước học tiếp theo khi đó đã rõ: triển khai một luồng nhập và một luồng thu hồi cho bộ dữ liệu được phép sử dụng, kèm dẫn chứng rằng nguồn, quyền và các sản phẩm phát sinh vẫn liên kết với nhau.