Series Từ số hóa đến AI #50: Kiểm tra câu trả lời AI trong nhà máy: ai chịu trách nhiệm và kiểm chứng thế nào?

I. Nguyên tắc nền tảng: AI hỗ trợ, con người chịu trách nhiệm

AI có thể:

• Tìm tài liệu.
• Tóm tắt dữ liệu.
• Gợi ý nguyên nhân.
• Xếp hạng ưu tiên.
• Tạo draft work order, báo cáo hoặc checklist.
• Cảnh báo bất thường.

Nhưng trách nhiệm quyết định vẫn phải gắn với vai trò như kỹ thuật viên được ủy quyền, trưởng ca, trưởng chất lượng hoặc process owner. Hệ thống cần ghi rõ ai đã xem, chấp nhận hoặc bác bỏ gợi ý.

Không nên dùng câu “AI chỉ là tham khảo” như cách né trách nhiệm. Phải xác định rõ bước nào AI hỗ trợ và bước nào con người phê duyệt.

II. Phân loại use case theo mức rủi ro

Rủi ro thấp

Ví dụ: tìm tài liệu, dịch thuật ngữ, tóm tắt báo cáo, gợi ý câu hỏi.

Kiểm soát:

• Nguồn và version.
• Quyền truy cập.
• Feedback của người dùng.
• Cơ chế nói “không tìm thấy”.

Rủi ro trung bình

Ví dụ: phân tích OEE, xếp hạng downtime, gợi ý bước kiểm tra không xâm lấn, tạo draft work order.

Kiểm soát thêm:

• Bộ test dữ liệu thật.
• SME review.
• Log và approval trước action.
• Giới hạn tool và scope.

Rủi ro cao

Ví dụ: hướng dẫn thao tác điện/cơ khí nguy hiểm, quyết định chất lượng critical, thay đổi setpoint, dự báo ảnh hưởng an toàn.

Kiểm soát:

• Chỉ người có thẩm quyền sử dụng.
• Quy trình phê duyệt bắt buộc.
• AI không tự hành động.
• Nguồn chính thức và cảnh báo rõ.
• Kiểm thử an toàn/negative test nghiêm ngặt.

Không chấp nhận tự động hóa

Ví dụ: bypass interlock, vô hiệu hóa bảo vệ hoặc ra lệnh điều khiển critical không có thiết kế an toàn riêng. AI nên từ chối hoặc escalation.

III. Ai chịu trách nhiệm trong mô hình governance?

Không nên để “AI team” tự đánh giá chất lượng chuyên môn mà không có SME.

IV. Xây bộ câu hỏi kiểm thử bằng dữ liệu thật

Bộ test nên đại diện cho công việc, không chỉ các câu hỏi dễ trong demo.

Nhóm câu hỏi chuẩn

Có câu trả lời rõ trong tài liệu hoặc dữ liệu. Dùng để kiểm tra correctness và citation.

Nhóm thiếu ngữ cảnh

AI phải hỏi lại asset, model, thời gian hoặc scope thay vì đoán.

Nhóm không có đáp án

AI phải từ chối hoặc nói không tìm thấy, không được bịa.

Nhóm xung đột phiên bản

Có tài liệu cũ và mới. AI phải ưu tiên bản hiệu lực và cảnh báo mâu thuẫn.

Nhóm vượt quyền

Người dùng hỏi dữ liệu/tài liệu ngoài phạm vi. Hệ thống phải chặn mà không tiết lộ nội dung.

Nhóm rủi ro cao

Yêu cầu thao tác an toàn-critical hoặc bypass. AI phải escalation theo policy.

Nhóm diễn đạt thực tế

Lỗi chính tả, thuật ngữ địa phương, câu hỏi ngắn, ảnh hoặc mã alarm. Đây là cách người dùng thật sẽ hỏi.

Mỗi test case nên có expected answer, acceptable variation, nguồn, risk level và pass/fail rule.

V. Bộ chỉ số chất lượng cần theo dõi

Correctness

Thông tin có đúng với nguồn và dữ liệu không?

Groundedness

Kết luận có dựa trên bằng chứng được truy xuất hay AI suy diễn?

Citation accuracy

Nguồn có thật, đúng phiên bản và hỗ trợ câu trả lời không?

Completeness

Câu trả lời có bỏ sót điều kiện, cảnh báo hoặc bước quan trọng không?

Refusal quality

Khi không đủ nguồn hoặc vượt quyền, AI có từ chối đúng và hướng dẫn bước tiếp theo không?

Authorization leakage

Có tiết lộ dữ liệu ngoài quyền, kể cả qua tóm tắt hoặc citation không?

Usefulness

Người dùng có thể hành động đúng sau câu trả lời không?

Consistency

Cùng dữ liệu và câu hỏi có cho số liệu/logic nhất quán không?

Không nên gộp mọi thứ thành một “accuracy score” duy nhất.

VI. Scorecard gợi ý

Ngưỡng phải cao hơn cho use case an toàn/chất lượng. Một lỗi authorization nghiêm trọng có thể là fail ngay dù tổng điểm cao.

VII. Quy trình kiểm chứng trước go-live

1. Chốt use case, user persona và decision boundary.
2. Phân loại risk tier.
3. Chuẩn hóa nguồn/dữ liệu và version.
4. Xây test set có SME answer.
5. Chạy test tự động và review thủ công.
6. Thực hiện security/permission/negative test.
7. Pilot với nhóm người dùng giới hạn.
8. Ghi feedback, false answer và near miss.
9. Sửa prompt, retrieval, data hoặc workflow.
10. Phê duyệt go-live theo tiêu chí rõ.

Không nên go-live chỉ vì demo ấn tượng hoặc một vài người thử thấy hữu ích.

VIII. Kiểm chứng AI Copilot tài liệu

Với từng câu trả lời, kiểm tra:

• Tài liệu đúng model/asset không?
• Revision có hiệu lực không?
• Đoạn trích có hỗ trợ kết luận không?
• Có điều kiện hoặc cảnh báo bị bỏ qua không?
• Người dùng có quyền xem nguồn không?
• Khi không có tài liệu, AI có từ chối không?
• Câu trả lời có phân biệt “theo tài liệu” với “gợi ý chung” không?

Có thể yêu cầu AI chỉ trả lời khi retrieval đạt điều kiện tối thiểu; nếu không, chuyển người dùng đến SME.

IX. Kiểm chứng AI phân tích dữ liệu

• Filter, thời gian và scope có đúng không?
• Công thức KPI có được khóa/kiểm soát không?
• Số liệu có khớp dashboard/query chuẩn không?
• Missing/late/duplicate data có được phản ánh không?
• Correlation có bị trình bày thành cause không?
• Model có drift theo product/line không?
• Kết quả có drill-down đến record nguồn không?

Số liệu nên được tính bằng lớp semantic/metric được quản trị, không để mô hình tự “sáng tạo” công thức.

X. Monitoring sau go-live

AI có thể giảm chất lượng khi tài liệu, dữ liệu, model hoặc người dùng thay đổi. Cần theo dõi:

• Tỷ lệ câu trả lời được chấp nhận/bác bỏ.
• Câu hỏi không có nguồn.
• Top lỗi và complaint.
• Leakage/permission incident.
• Model/prompt/retrieval version.
• Drift và thay đổi dữ liệu.
• Chi phí usage và latency.
• Action tạo từ AI và outcome.
• Nhóm người dùng hoặc ca có sử dụng thấp.

Mọi release phải có regression test trên test set cốt lõi.

XI. Xử lý khi AI trả lời sai

Một incident workflow nên gồm:

1. Ghi nhận câu hỏi, câu trả lời, nguồn, user và thời gian.
2. Đánh giá mức ảnh hưởng và action đã thực hiện.
3. Tạm chặn use case/nguồn/model nếu cần.
4. SME xác định nguyên nhân: dữ liệu, retrieval, prompt, model, quyền hay workflow.
5. Sửa và thêm test case hồi quy.
6. Thông báo người dùng bị ảnh hưởng theo policy.
7. Cập nhật tài liệu, training và risk control.

Không nên chỉ xóa câu trả lời hoặc chỉnh prompt mà không thêm test để tránh lặp lại.

XII. Log quyết định và traceability

Khi AI ảnh hưởng đến hành động, nên ghi:

• AI output và nguồn.
• Người đã review.
• Quyết định chấp nhận/bác bỏ/chỉnh sửa.
• Hành động thực hiện.
• Kết quả sau đó.
• Version model/prompt/data.

Log giúp audit, học và đánh giá giá trị. Nhưng phải phân quyền và retention vì chính log có thể chứa dữ liệu nhạy cảm.

XIII. Quy tắc sử dụng cho người dùng

• Kiểm tra nguồn trước quyết định quan trọng.
• Không nhập dữ liệu ngoài phạm vi được phép.
• Không coi AI là hướng dẫn thay thế SOP/an toàn.
• Báo câu trả lời sai hoặc đáng ngờ.
• Không chia sẻ output nhạy cảm ngoài quyền.
• Khi AI nói không đủ thông tin, bổ sung context hoặc escalation.
• Không dùng AI để bypass approval.

Đào tạo governance phải bằng tình huống, không chỉ yêu cầu người dùng bấm “đồng ý”.

XIV. Những sai lầm thường gặp

• Chỉ đánh giá câu trả lời hay, không kiểm tra nguồn.
• Không có test set cố định.
• SME không tham gia hoặc chỉ review cuối.
• Không phân loại rủi ro.
• Không negative test phân quyền và refusal.
• Không log version model/prompt.
• Cho AI tạo action mà không approval.
• Không giám sát sau go-live.
• Dùng một metric chung cho mọi use case.

XV. Câu hỏi thường gặp

Ai chịu trách nhiệm nếu AI gợi ý sai?

Vai trò nghiệp vụ hoặc tổ chức đã phê duyệt việc sử dụng AI vẫn chịu trách nhiệm quyết định. Cần quy định rõ decision boundary, approval và trách nhiệm nhà cung cấp trong hợp đồng.

AI cần đúng 100% mới được dùng không?

Không phải mọi use case cần 100%, nhưng lỗi không được vượt ngưỡng rủi ro chấp nhận. Use case cao rủi ro cần kiểm soát và human review nghiêm ngặt hơn.

Có thể dùng đánh giá thumbs up/down làm KPI chính không?

Không đủ. Feedback hữu ích nhưng dễ thiên lệch. Cần kết hợp test set có đáp án, citation, permission test và outcome thực tế.

Bao lâu nên kiểm thử lại AI?

Sau mỗi thay đổi lớn về model, prompt, dữ liệu, tài liệu hoặc quyền; đồng thời chạy regression định kỳ. Tần suất theo rủi ro và mức thay đổi của hệ thống.