Mở đầu — vì sao bài này quan trọng
Hãy tưởng tượng bạn vừa ship một tính năng trợ lý AI cho ứng dụng ngân hàng. Khách hàng hỏi: "Phí chuyển khoản liên ngân hàng của tôi là bao nhiêu?" Con AI trả lời rất tự tin: "Phí của bạn là 0 đồng, miễn phí hoàn toàn." Nghe rất mượt, rất thuyết phục. Vấn đề duy nhất: thông tin đó hoàn toàn bịa. Biểu phí thật là 11.000 đồng/giao dịch. Bây giờ bạn có một khách hàng giận dữ, một bài đăng viral trên Facebook, và một cuộc họp khẩn với phòng pháp chế.
Đó chính là hallucination — hiện tượng mô hình ngôn ngữ (LLM) tạo ra nội dung nghe hợp lý, trôi chảy, đầy tự tin nhưng sai sự thật hoặc bịa đặt. Đây không phải bug ngẫu nhiên mà là đặc tính cố hữu của cách LLM hoạt động: nó dự đoán token tiếp theo dựa trên xác suất, chứ không "biết" sự thật. Với một PM viết spec cho tính năng AI, hallucination không phải chuyện kỹ thuật để mặc cho engineer lo. Nó là rủi ro sản phẩm mà bạn phải thiết kế hàng phòng thủ ngay trong spec.
Ở các bài trước trong nhánh AI Spec, chúng ta đã định nghĩa input/output contract (Bài 29), eval criteria và test set (Bài 30), fallback khi mô hình lỗi (Bài 31), và latency budget (Bài 32). Bài này tập trung riêng vào một câu hỏi: làm sao bạn viết spec để giảm thiểu, phát hiện, và xử lý hallucination trước khi nó tới tay người dùng? Đây là phần spec mà thiếu nó, một tính năng AI có thể trông long lanh trong demo nhưng trở thành quả bom hẹn giờ khi lên production.
Khái niệm cốt lõi
Phân loại hallucination — bạn không thể chống thứ bạn không gọi tên được
Sai lầm phổ biến nhất của PM là gom tất cả vào một cục "AI nói sai". Để viết guard hiệu quả, bạn phải phân loại được hallucination theo từng kiểu, vì mỗi kiểu có cách phòng thủ khác nhau.
1. Factual hallucination (bịa sự thật) — Mô hình tạo ra dữ kiện sai: trích dẫn không tồn tại, sai ngày tháng, sai con số, sai tên người. Ví dụ: AI khẳng định "Nghị định 13/2023 quy định về bảo vệ dữ liệu cá nhân" trong khi văn bản thật là Nghị định 13/2023/NĐ-CP — hoặc tệ hơn, viện dẫn một điều luật không hề tồn tại. Đây là kiểu nguy hiểm nhất trong các domain như y tế, pháp lý, tài chính.
2. Procedural hallucination (bịa quy trình/kỹ thuật) — Mô hình bịa ra cách làm: gọi một API không tồn tại, viết sai cú pháp lệnh, hướng dẫn bấm vào một nút không có trong app. Ví dụ trợ lý lập trình gợi ý array.shuffle() trong JavaScript — một hàm không hề có. Hoặc chatbot CSKH hướng dẫn "Vào Cài đặt > Bảo mật > Xóa tài khoản" trong khi luồng thật hoàn toàn khác.
3. Persona / context hallucination (bịa danh tính, vai trò, ngữ cảnh) — Mô hình "quên" mình là ai, vượt quá thẩm quyền, hoặc bịa ra ngữ cảnh hội thoại. Ví dụ: trợ lý bán hàng tự nhận "Tôi là nhân viên tư vấn pháp lý có chứng chỉ" trong khi nó không phải. Hoặc nó tự bịa "Như anh đã nói ở tin nhắn trước, anh muốn hủy gói Premium" — trong khi người dùng chưa hề nói câu đó. Kiểu này đặc biệt nguy hiểm vì tạo cam kết giả hoặc đưa ra lời khuyên vượt thẩm quyền.
4. Reasoning hallucination (bịa lập luận) — Mô hình đưa ra chuỗi suy luận nghe logic nhưng kết luận sai, thường gặp ở bài toán số học, so sánh, tổng hợp. Ví dụ: tính sai tổng tiền đơn hàng nhưng trình bày từng bước rất "có vẻ đúng".
Ba lớp phòng thủ: Prevent — Detect — Contain
Một spec hallucination guard tốt không đặt cược vào một biện pháp duy nhất. Nó xây ba lớp:
- Prevent (ngăn ngừa) — giảm khả năng mô hình bịa ngay từ đầu: grounding bằng dữ liệu thật (RAG), prompt ràng buộc rõ ("chỉ trả lời dựa trên context được cung cấp"), giới hạn phạm vi câu hỏi.
- Detect (phát hiện) — bắt hallucination trước khi nó tới người dùng: kiểm tra citation có khớp nguồn không, validate output theo schema, dùng mô hình thứ hai làm "judge", so khớp con số với cơ sở dữ liệu.
- Contain (giảm thiểu thiệt hại) — khi không chắc, hệ thống phải hành xử an toàn: trả lời "tôi không chắc", hiển thị disclaimer, chuyển sang người thật, hoặc từ chối trả lời thay vì đoán bừa.
Định nghĩa "confidence" và ngưỡng từ chối trong spec
LLM không trả về độ tin cậy thật như một classifier truyền thống. Vì vậy spec cần định nghĩa cách hệ thống ước lượng độ chắc chắn: có grounding source không, citation có khớp không, output có pass validation không. Khi tín hiệu yếu, bạn phải định nghĩa hành vi abstain (từ chối/né tránh) thay vì trả lời. Đây là điểm khác biệt giữa một spec nghiệp dư và một spec trưởng thành.
Tình huống thực tế
Tình huống 1 — Chatbot CSKH của một sàn TMĐT Đông Nam Á bịa chính sách hoàn tiền
Một sàn thương mại điện tử lớn ở khu vực (gọi là "ShopX") triển khai chatbot AI cho 2 triệu lượt chat/tháng để giảm tải cho tổng đài. Trong tuần đầu, đội vận hành phát hiện chatbot trả lời khách: "Bạn được hoàn tiền 100% trong vòng 60 ngày kể cả khi đã dùng sản phẩm." Chính sách thật là 7 ngày với điều kiện sản phẩm còn nguyên tem. Hậu quả: hàng trăm yêu cầu hoàn tiền tranh chấp, và pháp chế lo ngại lời chatbot có thể bị coi là cam kết ràng buộc.
Diễn giải: Đây là factual hallucination kết hợp persona hallucination — chatbot vừa bịa con số, vừa hành xử như thể nó có thẩm quyền cam kết chính sách. Nguyên nhân gốc: spec ban đầu chỉ nhồi toàn bộ FAQ vào prompt và để mô hình "tự diễn giải". Không có grounding chặt, không có guard nào kiểm tra câu trả lời liên quan tới chính sách hoàn tiền.
Bài học: Sau sự cố, đội product viết lại spec theo hướng: (1) Các câu hỏi về chính sách (hoàn tiền, bảo hành, phí) được route sang luồng riêng, trả lời bằng câu trích nguyên văn từ knowledge base có version, không cho mô hình diễn đạt lại tự do. (2) Mọi câu trả lời về chính sách bắt buộc kèm nguồn "Theo Điều khoản hoàn tiền cập nhật ngày…". (3) Nếu câu hỏi không match được điều khoản nào với độ tương đồng đủ cao, chatbot abstain và chuyển sang nhân viên. Tỷ lệ hallucination về chính sách giảm từ ~4% xuống dưới 0,3%.
Tình huống 2 — Trợ lý lập trình nội bộ bịa API của chính công ty
Một công ty fintech Việt Nam xây "DevBot" — trợ lý AI giúp lập trình viên tra cứu cách dùng các internal SDK. Vấn đề: khi được hỏi cách gọi API thanh toán, DevBot tự tin sinh code gọi hàm payment.refundPartial(amount, reason). Hàm này không tồn tại; SDK thật chỉ có payment.refund(transactionId, options). Một junior dev tin theo, copy code, và mất nửa ngày debug lỗi "function is not defined".
Diễn giải: Đây là procedural hallucination kinh điển. Mô hình được train trên hàng triệu dòng code công khai nên nó "đoán" ra tên hàm nghe rất hợp lý theo thói quen đặt tên phổ biến — nhưng không khớp SDK nội bộ.
Bài học: Spec phiên bản 2 thêm hai guard. Prevent: mọi câu hỏi về SDK được RAG từ tài liệu API chính thức và file định nghĩa type (.d.ts), và prompt ràng buộc "chỉ dùng các hàm xuất hiện trong context, không bịa hàm mới". Detect: một bước post-processing dùng AST parser quét code do AI sinh ra, đối chiếu mọi lời gọi hàm với danh sách hàm hợp lệ trích từ SDK; nếu phát hiện hàm không tồn tại, gắn cảnh báo đỏ "Hàm này không có trong SDK — vui lòng kiểm tra lại" thay vì hiển thị code như thể nó đúng. Điểm hay ở đây: guard mạnh nhất không phải LLM mà là một kiểm tra xác định (deterministic) đối chiếu với nguồn sự thật.
Tình huống 3 — Trợ lý y tế bịa liều lượng thuốc
Một startup health-tech làm app tư vấn sức khỏe sơ bộ. Trong thử nghiệm nội bộ, khi người dùng hỏi về thuốc hạ sốt cho trẻ, AI gợi ý một liều paracetamol cao hơn mức an toàn cho trẻ dưới 2 tuổi. May mắn là đội QA bắt được trong giai đoạn eval, trước khi ra mắt.
Diễn giải: Đây là factual hallucination trong domain rủi ro cao nhất — sai có thể gây hại tính mạng. Không một mức "giảm thiểu" nào là chấp nhận được nếu hệ thống được phép tự đưa ra liều lượng.
Bài học: Đội quyết định một guard ở tầng chính sách sản phẩm, viết thẳng vào spec: AI tuyệt đối không được đưa ra liều lượng thuốc cụ thể. Mọi câu hỏi liên quan liều lượng kích hoạt một response template cố định: "Về liều lượng thuốc, bạn cần tham khảo bác sĩ hoặc dược sĩ. Tôi có thể giúp bạn tìm cơ sở y tế gần nhất." Đây là minh chứng cho việc đôi khi guard tốt nhất là vạch ra vùng cấm (no-go zone) — danh sách chủ đề mà AI không được phép tự sinh nội dung, dù mô hình có "tự tin" đến đâu.
Hướng dẫn từng bước
Đây là quy trình để viết phần "Hallucination Guards" trong AI spec của bạn.
Bước 1 — Lập bản đồ rủi ro theo loại hallucination. Với từng luồng tính năng, hỏi: kiểu hallucination nào có thể xảy ra (factual / procedural / persona / reasoning)? Mức độ thiệt hại nếu xảy ra? Lập một bảng nhỏ: cột là loại hallucination, dòng là mức nghiêm trọng (thấp/trung/cao). Những ô "cao" là nơi bạn đầu tư guard mạnh nhất.
Bước 2 — Xác định no-go zones. Liệt kê rõ trong spec những loại nội dung AI tuyệt đối không được tự sinh: liều lượng thuốc, tư vấn pháp lý ràng buộc, cam kết tài chính, số liệu chính sách. Mỗi no-go zone đi kèm một response template cố định và/hoặc đường escalation tới người thật.
Bước 3 — Thiết kế lớp Prevent. Ghi rõ: dữ liệu grounding lấy từ đâu (knowledge base nào, version nào, cập nhật ra sao), và prompt ràng buộc thế nào ("chỉ trả lời dựa trên context; nếu context không đủ, nói rõ là không có thông tin"). Yêu cầu mọi câu trả lời thuộc domain nhạy cảm phải kèm citation tới nguồn.
Bước 4 — Thiết kế lớp Detect. Với mỗi loại output, định nghĩa kiểm tra tự động: citation có thật và khớp nguồn không? Con số có khớp database không? Code có gọi hàm tồn tại không (đối chiếu allowlist)? Output có pass JSON schema không? Ưu tiên kiểm tra deterministic; chỉ dùng "LLM-as-judge" cho những thứ không thể kiểm bằng quy tắc cứng.
Bước 5 — Định nghĩa hành vi abstain. Viết rõ: khi tín hiệu tin cậy yếu (không tìm được grounding, citation không khớp, validation fail), hệ thống làm gì? Mẫu hành vi: "Tôi chưa có đủ thông tin chắc chắn về câu hỏi này" + đề xuất chuyển sang người thật. Đặt ngưỡng: thà từ chối nhầm còn hơn trả lời sai.
Bước 6 — Quy định disclaimer và UI surfacing. Spec cần nói rõ khi nào hiển thị disclaimer ("Thông tin AI tạo, vui lòng kiểm chứng"), khi nào hiển thị nguồn trích dẫn, khi nào gắn nhãn cảnh báo. Đây là phần liên quan tới design — phối hợp với designer (sẽ bàn ở các bài về review process).
Bước 7 — Gắn vào eval & monitoring. Liên kết với Bài 30 (eval): tạo test set gồm các câu dễ gây hallucination (adversarial prompts) và đặt ngưỡng pass. Liên kết với Bài 43 (monitoring): định nghĩa metric theo dõi production — tỷ lệ abstain, tỷ lệ citation không khớp, số report của người dùng về câu trả lời sai.
Lỗi thường gặp & mẹo
Lỗi 1 — Tin rằng "prompt tốt là đủ". Nhiều PM viết một prompt dặn dò "đừng bịa đặt" rồi nghĩ xong việc. Prompt giúp nhưng không bao giờ đủ cho domain rủi ro cao. Mẹo: luôn cặp đôi prompt (Prevent) với ít nhất một kiểm tra deterministic (Detect).
Lỗi 2 — Lẫn lộn "confidence của ngôn từ" với "độ đúng". LLM diễn đạt mọi thứ đều trôi chảy tự tin, kể cả khi sai. Đừng để giọng văn đánh lừa. Mẹo: trong spec, đừng bao giờ dùng "AI thấy tự tin" làm tín hiệu; hãy dựa vào grounding và validation.
Lỗi 3 — Không version-hóa nguồn sự thật. Chính sách, biểu phí, API thay đổi liên tục. Nếu knowledge base lỗi thời, guard "đối chiếu nguồn" vẫn cho ra câu trả lời sai một cách "hợp lệ". Mẹo: spec phải quy định quy trình cập nhật và version cho mọi nguồn grounding.
Lỗi 4 — Quên persona hallucination. Đa số chỉ lo factual mà bỏ qua chuyện AI tự nhận vai trò vượt thẩm quyền hoặc bịa ngữ cảnh hội thoại. Mẹo: thêm guard kiểm tra AI không tự xưng danh tính sai và không bịa "như bạn đã nói trước đó".
Lỗi 5 — Abstain quá đà làm sản phẩm vô dụng. Ngược lại, nếu hệ thống từ chối quá nhiều, người dùng bỏ đi. Mẹo: theo dõi tỷ lệ abstain như một counter-metric (xem Bài 15) — guard không được làm hỏng trải nghiệm chính.
Mẹo tổng: Ưu tiên guard theo thứ tự thiệt hại. Vùng có thể gây hại người, mất tiền, hoặc rủi ro pháp lý thì dùng no-go zone hoặc response cố định. Vùng rủi ro thấp thì prompt + disclaimer nhẹ là đủ. Đừng dàn đều công sức.
Bài tập thực hành
Chọn một tính năng AI cụ thể (ví dụ: chatbot CSKH cho một app gọi xe, hoặc trợ lý gợi ý món ăn cho app giao đồ ăn). Sau đó:
- Lập bảng rủi ro hallucination: liệt kê ít nhất 4 tình huống mô hình có thể bịa, phân loại theo factual / procedural / persona / reasoning, và gán mức nghiêm trọng cao/trung/thấp cho mỗi cái.
- Xác định 2 no-go zones: hai loại nội dung mà AI tuyệt đối không được tự sinh trong tính năng đó, kèm response template cố định cho mỗi cái.
- Viết một guard Detect deterministic: chọn một loại output (con số, citation, hoặc lời gọi hành động) và mô tả cách hệ thống đối chiếu nó với nguồn sự thật để bắt lỗi trước khi hiển thị.
- Viết hành vi abstain: soạn chính xác câu chữ AI sẽ trả lời khi không đủ tự tin, và mô tả điều kiện kích hoạt abstain.
- Định nghĩa 1 metric monitoring: một chỉ số bạn sẽ theo dõi trên production để biết hallucination guard có đang hoạt động không.
Tóm tắt
Hallucination là đặc tính cố hữu của LLM, không phải bug ngẫu nhiên — vì vậy nó là rủi ro sản phẩm mà PM phải thiết kế hàng phòng thủ ngay trong spec. Hãy gọi tên được bốn loại: factual (bịa sự thật), procedural (bịa quy trình/kỹ thuật), persona (bịa danh tính/ngữ cảnh), và reasoning (bịa lập luận) — vì mỗi loại cần guard khác nhau. Xây ba lớp phòng thủ: Prevent (grounding, prompt ràng buộc), Detect (đối chiếu nguồn, validation, ưu tiên kiểm tra deterministic), và Contain (abstain, disclaimer, escalation). Nguyên tắc cốt lõi: một câu "tôi không chắc" gần như luôn tốt hơn một câu sai đầy tự tin. Đừng tin prompt là đủ, đừng để giọng văn trôi chảy đánh lừa, đừng quên version-hóa nguồn sự thật, và hãy đầu tư guard mạnh nhất vào những vùng có thể gây hại người, mất tiền hoặc rủi ro pháp lý. Một spec AI trưởng thành không hỏi "liệu mô hình có bịa không" — nó giả định mô hình sẽ bịa, và mã hóa sẵn cách hệ thống ứng xử khi điều đó xảy ra.