Hallucination

Mô hình trả lời rất tự tin, câu chữ mượt, kèm cả số điều khoản và tên văn bản. Chỉ có điều khoản đó là không tồn tại. Đó là hallucination. Không có dòng code nào đang hỏng và chờ người sửa — đây là hệ quả trực tiếp của cách mô hình hoạt động: chọn chuỗi chữ hợp lý nhất, chứ không tra cứu sự thật.

Bạn không loại bỏ được ảo giác. Chỉ giảm được tần suất, và thiết kế sao cho lúc nó xảy ra thì không ai mất tiền.

Vì sao mô hình bịa

Ba nguồn chính, mỗi nguồn một cách chặn:

• Không có dữ liệu. Hỏi về quy trình nội bộ mà mô hình chưa từng thấy. Nó vẫn trả lời — nó không có cơ chế im lặng. Chặn bằng RAG và ngưỡng từ chối.
• Dữ liệu có nhưng bị lẫn. Truy xuất ra ba đoạn, hai đoạn về sản phẩm A, một đoạn về sản phẩm B, mô hình trộn cả ba. Chặn bằng metadata và bộ lọc lúc truy xuất.
• Suy diễn quá tay. Tài liệu nói "áp dụng cho khách hàng cá nhân", câu hỏi về khách doanh nghiệp, mô hình suy ra "chắc cũng tương tự". Kiểu này khó chặn nhất vì câu trả lời đọc lên vẫn trơn tru. Chặn bằng ràng buộc trong prompt và bộ test có câu bẫy.

Rủi ro nghiệp vụ, xếp theo mức đau

Giá của mỗi kiểu bịa chênh nhau rất xa, và phân tầng này quyết định mức đầu tư kiểm soát.

Mức rất nặng ở đáy bảng là mức khiến pháp chế mất ngủ. Hộp chat lưu lịch sử là một bằng chứng, và trong mắt khách hàng thì con bot nói thay công ty.

Viết acceptance criteria khi đầu ra không tất định

Đây là chỗ BA hay bí nhất. Viết "hệ thống phải trả lời chính xác" thì QC không có gì để test, tới UAT sẽ cãi nhau từng câu. Cách mình dùng là chia AC ba lớp.

Lớp 1 — AC tất định về phần bao quanh. Không phụ thuộc mô hình, nên viết và test như tính năng thường:

• Mọi câu trả lời về chính sách kèm ít nhất một trích dẫn có tên tài liệu, số điều và link mở được.
• Nếu điểm tương đồng của đoạn tốt nhất dưới ngưỡng X, hệ thống trả câu từ chối chuẩn đã duyệt kèm nút chuyển tổng đài, không sinh câu trả lời tự do.
• Hệ thống không bao giờ tự sinh số tiền, ngày hết hạn hoặc số hợp đồng. Các giá trị đó chỉ lấy từ API hệ thống nguồn; API lỗi thì báo lỗi, không điền tạm.
• Mỗi câu trả lời có nút "thông tin này chưa đúng", bấm vào ghi nhận kèm ngữ cảnh.

Lớp 2 — AC theo bộ mẫu chuẩn (golden set). Đây là cách duy nhất mình biết để đo được chất lượng đầu ra sinh tự do:

• Phòng nghiệp vụ soạn và duyệt 150 câu hỏi kèm đáp án đúng, trong đó ít nhất 20 câu bẫy: điều đã hết hiệu lực, sản phẩm không tồn tại, hoặc ngoài phạm vi.
• Tiêu chí đạt, chốt bằng văn bản trước khi build: từ 90% số câu trở lên được nghiệp vụ chấm là đúng ý; không câu nào sai về số tiền hoặc điều kiện chi trả; tỉ lệ từ chối nhầm dưới 5%; với câu bẫy, hệ thống phải từ chối hoặc chuyển người.
• Bộ mẫu chạy lại mỗi khi đổi mô hình, đổi prompt hoặc nạp tài liệu mới. Nó là regression test, cứ gọi đúng tên vậy.

Lớp 3 — AC về vận hành sau khi lên. Ảo giác không dừng lại ở ngày go-live:

• Ghi log mỗi câu trả lời: câu hỏi, các đoạn truy xuất được, phiên bản prompt, phiên bản mô hình, thời điểm.
• Mỗi tuần lấy ngẫu nhiên 5% hội thoại cho nghiệp vụ chấm.
• Chốt ngưỡng cảnh báo: tỉ lệ bấm "thông tin chưa đúng" vượt mức đã định 7 ngày liên tiếp thì có người phải rà.

Còn một chỗ nhỏ mà rất đáng làm: lúc test, tách bốn loại lỗi thay vì gộp chung là "sai" — sai sự thật, đúng ý nhưng dẫn nhầm điều khoản, bịa nguồn, từ chối nhầm. Bốn loại sửa ở bốn chỗ khác nhau.

Câu phải nói với khách trước khi ký

Nghiệp vụ đòi đúng 100% thì nói thẳng là không hứa được với đầu ra sinh tự do, rồi đề xuất đổi thiết kế: phần cần chắc chắn tuyệt đối trả về nội dung tĩnh đã duyệt hoặc kết quả từ bảng quy tắc, mô hình chỉ hiểu câu hỏi và định tuyến. Thà mất một buổi giải thích còn hơn ký một cam kết không ai giữ được.