AI không biết thì phải làm gì? Thiết kế câu trả lời có giới hạn rõ

Dành cho đội sản phẩm và CSKH xây trợ lý hỏi đáp.

Khi tài liệu không có câu trả lời, mô hình vẫn có thể tạo một lời giải thích nghe hợp lý. Thêm một câu nhắc không được bịa là chưa đủ nếu luồng làm việc vẫn ép AI phải trả lời mọi câu hỏi.

Điểm mấu chốt cần hiểu đúng

Không đủ thông tin phải dẫn tới một hành động hữu ích: hỏi rõ, chỉ nguồn phù hợp hoặc chuyển người, không đoán thay.

Hỏi lại hữu ích khi thiếu một dữ kiện khách có thể cung cấp, nhưng không nên hỏi để trì hoãn việc chuyển người trong trường hợp ngoài thẩm quyền. Chẳng hạn, trợ lý không có chính sách hoàn tiền không thể tạo chính sách bằng cách hỏi khách muốn được hoàn bao nhiêu. Quy tắc phải nối loại thiếu thông tin với bước phù hợp.

Quy trình thực hành theo bốn bước

1. Phân loại điều chưa biết

Tách câu hỏi thiếu bối cảnh, thiếu nguồn, ngoài phạm vi và nguồn mâu thuẫn. Mỗi loại cần cách xử lý khác. Hỏi khách gửi thêm chi tiết không giải quyết được trường hợp chính tài liệu nội bộ chưa có chính sách.

2. Viết mẫu phản hồi có bước tiếp

Nêu phần chưa thể xác nhận và thông tin cần để tiếp tục. Nếu chuyển người, nói khách sẽ gặp đầu mối nào theo quy trình đã có. Không hứa thời gian phản hồi mà tổ chức chưa có khả năng thực hiện.

3. Kiểm tra trường hợp nguồn yếu

Đưa câu hỏi có tên gần giống, điều kiện thiếu hoặc tài liệu cũ vào thử nghiệm. Xem AI có phân biệt được thông tin liên quan với thông tin đủ để kết luận không. Một link tìm thấy chưa tự trở thành bằng chứng.

4. Đo cả việc từ chối quá mức

Trợ lý nói không biết với mọi câu cũng không hữu ích. Kiểm tra câu hỏi có đáp án rõ mà vẫn bị chuyển người và sửa cách cung cấp nguồn. Mục tiêu là xử lý đúng giới hạn, không chỉ giảm mọi khả năng sai bằng im lặng.

Tình huống minh hoạ và cách đọc kết quả

Tình huống giả định: khách hỏi gói đang dùng có một quyền đặc biệt hay không nhưng hệ thống chưa có thông tin gói. Trợ lý yêu cầu kiểm tra tài khoản qua quy trình phù hợp, không suy ra từ bảng giá chung.

Tình huống trên dùng để kiểm tra cách áp dụng, không phải câu chuyện khách hàng hay kết quả thực đo của TTI. Khi dùng cho doanh nghiệp mình, cần thay bằng bối cảnh, dữ liệu và điều kiện đã được người có trách nhiệm xác nhận.

Mẫu làm việc để triển khai trong đội ngũ

Mẫu xử lý gồm loại khoảng trống, dữ kiện có thể xin thêm, nguồn cần tra, đầu mối tiếp nhận và lời phản hồi. Kiểm tra người nhận có thật sự nhận được ngữ cảnh hay không. Nếu chưa có cơ chế chuyển tiếp, nói rõ giới hạn và chỉ kênh hợp lệ thay vì hứa đã chuyển khi hệ thống chưa làm.

Chuyển bốn bước ở trên thành bốn hàng trong một bảng theo dõi. Mỗi hàng có đầu vào đang có, khoảng trống cần xác minh, người thực hiện, người xác nhận và bằng chứng hoàn thành. Phân biệt việc đã làm với kết quả đã kiểm tra. Với bước chưa thể thực hiện, ghi điều kiện chờ và mốc xem lại; không điền một ngày tuỳ ý chỉ để bảng đủ ô. Khi một người bàn giao, người tiếp nhận phải đọc được vì sao việc đang ở trạng thái đó mà không cần hỏi lại toàn bộ bối cảnh.

Tổ chức một vòng thử có trách nhiệm

Chọn công việc giới hạn để thí điểm

Bắt đầu bằng một tác vụ có đầu vào, đầu ra và người kiểm tra rõ. Tránh giao ngay chuỗi việc dài có quyền gửi thông tin hoặc sửa dữ liệu thật. Dùng dữ liệu đã được tổ chức cho phép và có cách xử lý thông tin nhạy cảm phù hợp. Người phụ trách nghiệp vụ quyết định thế nào là đúng; người triển khai kỹ thuật xác định công cụ thực sự làm được gì trong điều kiện đang dùng.

Lưu điều kiện để so sánh được

Ghi phiên bản nguồn, hướng dẫn, cấu hình và tập tình huống thử ở mức đủ để dựng lại kết quả. Mô hình hoặc tài liệu có thể thay đổi nên kết quả cũ không tự áp dụng mãi. Khi thử một cách mới, giữ các điều kiện khác tương đối ổn định và ghi điều gì đã đổi. Không chỉ lưu đầu ra tốt; các trường hợp phải sửa, từ chối hoặc chuyển người giúp nhìn được giới hạn cần xử lý.

Thiết kế đường quay về con người

Người dùng cần biết khi nào kết quả còn là gợi ý và ai chịu trách nhiệm xác nhận. Có thể để AI chuẩn bị bản nháp trong khi con người quyết định hành động. Khi gặp lỗi quan trọng, dừng phạm vi liên quan, bảo toàn ngữ cảnh cần để kiểm tra và sửa trước khi mở rộng. Thêm tự động hoá chỉ hợp lý khi chất lượng, công sức giám sát và hậu quả sai đã được đánh giá trên công việc thực tế.

Chỉ số nên theo dõi và cách tránh đọc sai

Theo dõi tỷ lệ trả lời sai khi nguồn không đủ và tỷ lệ chuyển người không cần thiết trên các ca đã được người có chuyên môn xác định. Hai chỉ số phải đọc cùng nhau.

Khi lập bảng theo dõi, ghi nguồn dữ liệu, thời điểm bắt đầu và kết thúc, điều kiện đưa vào mẫu cùng cách xử lý trường hợp thiếu thông tin. Giữ định nghĩa ổn định trong kỳ; nếu đổi thì chú thích để người đọc không so hai tập dữ liệu khác nghĩa. Kết hợp số tổng hợp với một số hồ sơ cụ thể để kiểm tra vì sao kết quả thay đổi.

Sai lầm cần tránh

Không coi điểm tự tin do mô hình tự ghi là xác suất đúng đã được kiểm định.

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

Chỉ viết thêm câu nếu không biết hãy nói không biết có đủ không?

Không. Cần nguồn, quy tắc chuyển tiếp và phép thử ở các tình huống thiếu hoặc mâu thuẫn thông tin. Hướng dẫn văn bản chỉ là một phần của hệ thống.

Bước tiếp theo phù hợp

Trước khi mua thêm công cụ hoặc mở rộng quy trình, hãy chọn một tình huống nhỏ trong bài và điền mẫu bằng dữ liệu của đội ngũ. Nếu cần đánh giá với Oh CRM, mang theo tác vụ, đầu ra cần kiểm tra và các điều kiện bắt buộc để trao đổi. Khả năng, giới hạn gói và công sức triển khai cần được xác nhận qua tài liệu hoặc demo phù hợp, không suy ra chỉ từ hướng dẫn tổng quát.

Tìm thêm tài liệu thực hành trong thư viện ebook

Trao đổi và kiểm tra tác vụ trong trải nghiệm dùng thử

Nguồn tham khảo và phạm vi áp dụng

NIST — Generative AI Profile, AI 600-1

Tài liệu khung quản lý rủi ro AI tạo sinh. Bộ mẫu và bước thực hành trong bài là đề xuất biên tập; không phải chứng nhận, chuẩn bắt buộc hay cam kết về độ chính xác của một mô hình.