Điều gì làm nên tìm kiếm tri thức doanh nghiệp đáng tin cậy

01Vấn đề của bản trình diễn

Phần lớn trợ lý tri thức đi theo cùng một mô hình, gọi là tạo sinh tăng cường truy xuất (mở trang web bên ngoài) (retrieval-augmented generation, RAG): tìm các đoạn văn khớp với câu hỏi, rồi để mô hình ngôn ngữ viết câu trả lời dựa trên các đoạn đó. Trên một thư mục chọn lọc gồm năm mươi tài liệu, cách làm này cho kết quả thuyết phục chỉ trong một tuần.

Khi vận hành thực tế, tình hình khác hẳn. Hai mươi năm ổ đĩa dùng chung, wiki, phiếu yêu cầu hỗ trợ, hợp đồng và chính sách, nhiều tài liệu bị trùng lặp, lỗi thời hoặc mật. Trong bối cảnh đó, trợ lý thất bại theo hai cách. Nó trả lời sai và người dùng thôi sử dụng. Hoặc tệ hơn, nó trả lời sai một cách tự tin và người dùng hành động theo.

Vì vậy, tìm kiếm tri thức đáng tin cậy ít liên quan đến mô hình mà liên quan nhiều hơn đến năm đặc tính của hệ thống xung quanh mô hình. Mỗi đặc tính đều có thể thiết kế và, quan trọng hơn, có thể kiểm thử.

02Phân quyền: chỉ truy xuất những gì người dùng được phép đọc

Nguyên tắc rất đơn giản: trợ lý không bao giờ được cho ai xem một đoạn văn mà họ không thể mở trong hệ thống nguồn. Điều quan trọng là thực thi ở đâu. Nếu một đoạn văn đã đến được mô hình, hãy coi như nó có thể xuất hiện trong câu trả lời. Vì vậy, quyền truy cập phải được áp dụng trước bước tạo sinh, ngay tại bước truy xuất, cho chính người đang đặt câu hỏi.

OWASP xếp cả lộ lọt thông tin nhạy cảm (mở trang web bên ngoài) lẫn điểm yếu của vector và embedding (mở trang web bên ngoài), trong đó có rò rỉ vượt ranh giới phân quyền, vào nhóm rủi ro chính của ứng dụng mô hình ngôn ngữ. Trên thực tế, điều đó dẫn đến bốn yêu cầu.

• Lưu quyền truy cập của từng tài liệu nguồn cùng với mọi đoạn (chunk) trong chỉ mục, lấy từ hệ thống nguồn thay vì định nghĩa lại bằng tay.
• Lọc theo các quyền đó tại thời điểm truy vấn, dựa trên danh tính của người dùng đã đăng nhập, trước bước xếp hạng và tạo sinh.
• Đồng bộ thay đổi về quyền ít nhất nhanh bằng thay đổi về nội dung, và thống nhất một quyền bị thu hồi phải có hiệu lực trong bao lâu.
• Kiểm thử với các vai trò thực tế. Câu hỏi “Nhân viên thử việc có tìm thấy thang lương không?” thuộc về bộ kiểm thử, không phải về buổi rà soát sau sự cố.

03Nguồn gốc: trích dẫn mà người đọc kiểm tra được

Mỗi nhận định trong câu trả lời nên dẫn đến đoạn văn mà nó được lấy ra: tiêu đề tài liệu, phiên bản hoặc ngày, người phụ trách, và một liên kết mở đúng vị trí. Hiển thị chính đoạn văn, không chỉ tên tài liệu, để người đọc thấy ngay trong vài giây trích dẫn có hỗ trợ câu văn hay không.

Thiết kế định dạng câu trả lời sao cho phần văn bản không có căn cứ trở nên nổi bật. Nếu không đoạn văn truy xuất nào hỗ trợ một câu, hệ thống nên bỏ câu đó hoặc đánh dấu nó. Sau đó kiểm tra tự động: so sánh từng đoạn được trích dẫn với nhận định mà nó cần chứng minh, và lấy mẫu kết quả để con người xem xét. Trích dẫn có tồn tại nhưng không hỗ trợ nhận định là một lỗi phổ biến và khó nhận ra.

04Tính cập nhật và thẩm quyền

Tri thức của tổ chức có nhiều phiên bản. Quy định công tác phí cũ và mới đều khớp với câu hỏi “tôi có được đặt vé hạng thương gia không?”, và chúng cho câu trả lời khác nhau. Hãy lập chỉ mục cho siêu dữ liệu giúp phân biệt chúng: ngày hiệu lực, trạng thái (dự thảo, đã phê duyệt, đã được thay thế) và người phụ trách. Xếp tài liệu hiện hành, đã phê duyệt lên trước, loại tài liệu đã được thay thế trừ khi người dùng hỏi về lịch sử, và hiển thị ngày trong mọi trích dẫn.

Xác định theo từng chủ đề đâu là nguồn có thẩm quyền. Chính sách nhân sự lấy từ cổng thông tin nhân sự, không lấy từ một email trích dẫn phiên bản năm ngoái. Đặt nhịp lập chỉ mục lại cho từng nguồn, từ gần thời gian thực cho dữ liệu hồ sơ đến hằng ngày cho wiki, và theo dõi nhịp đó: chỉ mục lỗi thời tạo ra câu trả lời trông có vẻ đúng nhưng không đúng.

05Thừa nhận khoảng trống: “Tôi không tìm thấy thông tin này”

Thường thì câu trả lời giá trị nhất là thừa nhận không có thông tin. Mô hình ngôn ngữ có thể tạo ra những nhận định trôi chảy mà không dựa trên bất cứ điều gì, hiện tượng NIST gọi là bịa đặt (mở trang web bên ngoài) (confabulation) trong hồ sơ AI tạo sinh của mình. Bám vào các đoạn văn được truy xuất giúp giảm hiện tượng này nhưng không loại bỏ được. OWASP coi hệ quả phía sau, khi con người hành động dựa trên kết quả sai, là một rủi ro riêng với tên gọi thông tin sai lệch (mở trang web bên ngoài) (misinformation).

Đặt một ngưỡng mức độ liên quan, dưới ngưỡng đó hệ thống trả lời rằng không tìm thấy nguồn đáng tin cậy và gợi ý nơi có thể hỏi. Với câu hỏi về chính sách, quyền lợi hay nghĩa vụ, đừng để mô hình lấp khoảng trống bằng kiến thức chung. Sau đó theo dõi tỷ lệ không có câu trả lời theo từng chủ đề. Trong những tháng đầu, danh sách này thường là kết quả hữu ích nhất của cả dự án: nó cho người phụ trách nội dung thấy chính xác tài liệu còn thiếu ở đâu.

06Kiến trúc đằng sau năm đặc tính

Không có điều nào ở trên đòi hỏi một bộ công nghệ đặc biệt. Điều cần thiết là phân quyền, siêu dữ liệu và các bước kiểm tra là thành phần chính của chuỗi xử lý, chứ không phải tính năng bổ sung sau buổi trình diễn.

Dữ liệu cá nhân cần được chú ý riêng. Một chỉ mục tài liệu vẫn là một hoạt động xử lý dữ liệu cá nhân có trong các tài liệu đó, vì vậy các nguyên tắc giới hạn mục đích và tối thiểu hóa dữ liệu (mở trang web bên ngoài) của GDPR (Điều 5) áp dụng khi tổ chức thuộc phạm vi GDPR. Bỏ qua các nguồn mà tình huống sử dụng không cần, bảo đảm việc xóa dữ liệu trong hệ thống nguồn được phản ánh vào chỉ mục, và đưa chỉ mục vào phạm vi khi trả lời yêu cầu truy cập dữ liệu.

Tại Việt Nam, Luật Bảo vệ dữ liệu cá nhân số 91/2025/QH15 và Nghị định số 356/2025/NĐ-CP có hiệu lực từ ngày 1/1/2026; luật áp dụng cả với tổ chức nước ngoài trực tiếp tham gia hoặc có liên quan đến hoạt động xử lý dữ liệu cá nhân của công dân Việt Nam (điểm c khoản 2 Điều 1). Nếu chỉ mục hoặc mô hình chạy trên dịch vụ điện toán đám mây, Nghị định số 356/2025/NĐ-CP yêu cầu dữ liệu cá nhân trên dịch vụ điện toán đám mây được mã hóa khi lưu trữ và khi truyền (khoản 4 Điều 12). Luật cũng yêu cầu lập hồ sơ đánh giá tác động xử lý dữ liệu cá nhân và gửi cho cơ quan chuyên trách bảo vệ dữ liệu cá nhân trong thời gian 60 ngày kể từ ngày đầu tiên xử lý (Điều 21), trừ các trường hợp được luật cho phép không áp dụng. Thiết kế chỉ mục với dữ liệu cá nhân tối thiểu giúp đáp ứng cả hai khung pháp lý cùng lúc.

07Chất lượng được đo lường, trước và sau khi vận hành

Không thể đánh giá độ tin cậy bằng cách thử vài câu hỏi trong một cuộc họp. Hãy thống nhất tiêu chí chất lượng với những người phụ trách nội dung và đo riêng từng lớp, để biết cần sửa vấn đề ở đâu.

Xây dựng tập kiểm thử từ câu hỏi thực tế: nhật ký tìm kiếm, phiếu yêu cầu hỗ trợ, những câu đồng nghiệp mới hay hỏi. Vài trăm câu hỏi với câu trả lời được người phụ trách nội dung thống nhất là điểm khởi đầu thực tế. Chạy toàn bộ tập kiểm thử ở mỗi thay đổi, dù là mô hình mới, cách chia đoạn mới hay nguồn mới. Chất lượng trôi đi lặng lẽ khi nội dung thay đổi, và chỉ một tập kiểm thử cố định mới làm sự trôi đó lộ ra.

08Đáng tin cậy trong mắt người dùng là thế nào

Với người sử dụng, tất cả những điều trên quy về một vài hành vi quan sát được. Trợ lý chỉ trả lời từ tài liệu họ được phép đọc. Mọi nhận định đều có trích dẫn mà họ mở được. Họ thấy được một nguồn cập nhật đến đâu. Họ được cho biết rõ ràng khi không có câu trả lời đáng tin cậy. Và họ biết có người đang đo chất lượng, vì họ có thể báo một câu trả lời sai và thấy nó được sửa.

Kết quả do AI tạo ra vẫn có thể sai, và có những câu hỏi nên do con người trả lời thay vì một công cụ tìm kiếm. Thiết kế công khai cho điều đó không phải điểm yếu của hệ thống. Chính điều đó khiến người dùng sẵn sàng dựa vào hệ thống cho phần còn lại.