1. Đặt vấn đề
Dữ liệu log cho biết người dùng làm gì, nhưng không cho biết đầy đủ họ cảm thấy thế nào, gặp khó khăn gì, cần cải thiện gì và tác vụ nào thật sự hữu ích. Vì vậy, phản hồi người dùng là nguồn dữ liệu không thể thiếu để cải tiến AI local.
Thu thập phản hồi cần được thiết kế thuận tiện, có cấu trúc và có người xử lý. Nếu chỉ hỏi chung “có góp ý gì không?”, phản hồi thường ít và khó dùng. Nếu thu thập quá phức tạp, người dùng sẽ không gửi.
2. Nút phản hồi ngay dưới câu trả lời
Cách đơn giản nhất là đặt nút:
- Hữu ích.
- Không hữu ích.
- Sai.
- Thiếu nguồn.
- Trả lời quá dài.
- Trả lời chưa đúng ý.
- Có nguy cơ lộ dữ liệu.
- Cần cập nhật tài liệu.
Nút phản hồi nhanh giúp thu thập tín hiệu ngay tại thời điểm sử dụng.
3. Ô góp ý ngắn
Sau khi người dùng chọn “không hữu ích” hoặc “sai”, nên có ô góp ý:
- Sai ở đâu?
- Cần sửa gì?
- Nguồn nào đúng hơn?
- Câu trả lời thiếu phần nào?
- Có tài liệu liên quan nào cần bổ sung?
Không bắt buộc quá nhiều trường để tránh gây phiền.
4. Khảo sát định kỳ
Có thể khảo sát hằng tháng hoặc sau giai đoạn thí điểm:
- Mức độ hài lòng.
- Tác vụ dùng nhiều.
- Tác vụ hữu ích nhất.
- Tác vụ chưa hiệu quả.
- Tốc độ phản hồi.
- Chất lượng câu trả lời.
- Niềm tin vào nguồn.
- Lo ngại bảo mật.
- Nhu cầu đào tạo.
- Đề xuất mở rộng.
Khảo sát định kỳ giúp có bức tranh tổng thể.
5. Phỏng vấn nhóm người dùng
Với các phòng thí điểm, nên phỏng vấn nhóm:
- Phòng QLCL.
- Phòng KHTH.
- Điều dưỡng.
- CNTT.
- CSKH.
- Lãnh đạo khoa/phòng.
Phỏng vấn giúp hiểu sâu hơn vì sao hệ thống hữu ích hoặc chưa hữu ích.
6. Nhật ký tình huống sử dụng
Có thể yêu cầu người dùng thí điểm ghi lại:
- Tác vụ đã dùng AI.
- Thời gian tiết kiệm.
- Kết quả dùng được không.
- Cần chỉnh sửa gì.
- Lỗi gặp phải.
- Đề xuất cải tiến.
Phương pháp này phù hợp trong 2–4 tuần thí điểm.
7. Thu thập ví dụ câu trả lời tốt và chưa tốt
Nên lưu có kiểm soát:
- Câu trả lời rất tốt.
- Câu trả lời sai.
- Câu trả lời thiếu nguồn.
- Câu trả lời quá chung.
- Câu trả lời vượt thẩm quyền.
- Câu hỏi không tìm được tài liệu.
Các ví dụ này dùng để cải tiến prompt, RAG và đào tạo người dùng.
8. Kênh báo lỗi nhanh
Cần có kênh riêng:
- Báo câu trả lời sai nghiêm trọng.
- Báo lộ dữ liệu.
- Báo lỗi phân quyền.
- Báo chatbot không hoạt động.
- Báo tài liệu cũ.
- Báo API chậm/lỗi.
Kênh này có thể là form nội bộ, ticket CNTT, QMS hoặc nhóm hỗ trợ.
9. Phân loại phản hồi
Phản hồi nên được phân loại:
- Lỗi model.
- Lỗi prompt.
- Lỗi RAG.
- Thiếu tài liệu.
- Tài liệu cũ.
- Lỗi phân quyền.
- Lỗi giao diện.
- Lỗi tốc độ.
- Người dùng hỏi chưa rõ.
- Tác vụ không phù hợp.
Phân loại đúng mới cải tiến đúng.
10. Quy trình xử lý phản hồi
Cần có quy trình:
- Nhận phản hồi.
- Phân loại.
- Xác định mức độ ưu tiên.
- Giao người xử lý.
- Sửa dữ liệu/prompt/model/giao diện.
- Test lại.
- Phản hồi cho người báo nếu cần.
- Ghi nhận bài học.
Nếu phản hồi không được xử lý, người dùng sẽ ngừng góp ý.
11. Kết luận
Thu thập phản hồi người dùng là điều kiện để AI local cải tiến liên tục. Cần kết hợp nút phản hồi nhanh, góp ý ngắn, khảo sát định kỳ, phỏng vấn nhóm, nhật ký thí điểm, kênh báo lỗi và quy trình xử lý phản hồi. Phản hồi người dùng giúp hệ thống AI không chỉ hoạt động về mặt kỹ thuật, mà ngày càng phù hợp hơn với công việc thật của bệnh viện.
- Đăng nhập để gửi ý kiến
