Mở đầu — vì sao bài này quan trọng
Hãy tưởng tượng bạn vừa ra mắt một chatbot tư vấn bảo hiểm cho công ty mình. Một khách hàng hỏi: "Gói bảo hiểm sức khỏe của tôi có chi trả cho phẫu thuật thẩm mỹ không?" Chatbot trả lời rất tự tin, rất trôi chảy: "Có, gói Premium của bạn chi trả tới 80% chi phí phẫu thuật thẩm mỹ." Vấn đề là điều này hoàn toàn sai. Hợp đồng không hề có điều khoản đó. Khách hàng tin lời chatbot, đi phẫu thuật, rồi quay lại đòi bồi thường — và bạn có một cuộc khủng hoảng pháp lý lẫn truyền thông trên tay.
Đó chính là hallucination — hiện tượng mô hình ngôn ngữ (LLM) tạo ra những câu trả lời nghe rất hợp lý, mạch lạc, đầy tự tin nhưng lại sai sự thật. Đây không phải lỗi hiếm gặp hay sự cố kỹ thuật ngẫu nhiên. Hallucination là đặc tính cố hữu của cách LLM hoạt động: chúng dự đoán từ tiếp theo dựa trên xác suất, chứ không "biết" sự thật. Một mô hình có thể vừa giải đúng bài toán tích phân phức tạp, vừa khẳng định chắc nịch rằng "Hồ Chí Minh sinh năm 1880" (đúng phải là 1890).
Với vai trò AI Product Manager, đây là một trong những rủi ro sống còn bạn phải quản trị. Người dùng không tha thứ cho sản phẩm AI nói dối — đặc biệt trong các lĩnh vực nhạy cảm như y tế, tài chính, pháp lý. Bài này sẽ trang bị cho bạn cách phát hiện (detect) và giảm thiểu (mitigate) hallucination ở cấp độ sản phẩm, không phải cấp độ nghiên cứu hàn lâm. Bạn sẽ học cách biến một rủi ro không thể loại bỏ hoàn toàn thành một rủi ro có thể kiểm soát được tới mức chấp nhận.
Khái niệm cốt lõi
Hallucination thực chất là gì
Hallucination là khi LLM sinh ra nội dung không có cơ sở — hoặc mâu thuẫn với sự thật khách quan, hoặc mâu thuẫn với nguồn dữ liệu được cung cấp. Điều quan trọng cần khắc cốt: mô hình không "nói dối" theo nghĩa cố ý. Nó chỉ đang làm đúng việc nó được huấn luyện — tạo ra chuỗi từ có xác suất cao và nghe tự nhiên. Sự thật chỉ là sản phẩm phụ, không phải mục tiêu của quá trình sinh văn bản.
Các loại hallucination
Phân loại đúng giúp bạn chọn đúng cách xử lý. Có ba nhóm chính bạn cần phân biệt:
1. Factual hallucination (bịa đặt sự thật). Mô hình khẳng định những thông tin sai về thế giới. Ví dụ kinh điển: "Chủ tịch Hồ Chí Minh sinh năm 1880" thay vì 1890, hay "Việt Nam có 64 tỉnh thành" trong khi thực tế là 63. Loại này nguy hiểm vì nghe rất thuyết phục.
2. Faithfulness hallucination (sai lệch so với nguồn). Đây là loại quan trọng nhất trong các sản phẩm dùng RAG (truy xuất tài liệu). Bạn đưa cho mô hình một đoạn tài liệu, yêu cầu trả lời dựa trên đó, nhưng mô hình lại bịa thêm hoặc bóp méo nội dung không có trong tài liệu. Ví dụ: tài liệu nói "chính sách hoàn tiền trong 7 ngày", mô hình lại trả lời "30 ngày". Trong sản phẩm thực tế, đây là loại hallucination bạn gặp nhiều nhất và cũng dễ kiểm soát nhất.
3. Citation/reasoning hallucination (bịa nguồn trích dẫn hoặc lập luận sai). Mô hình tạo ra các trích dẫn không tồn tại — tên nghiên cứu, số điều luật, đường link giả. Có những vụ luật sư ở Mỹ bị tòa phạt vì nộp bản tranh tụng do ChatGPT viết, trong đó trích dẫn 6 vụ án hoàn toàn không có thật.
Vì sao mô hình hallucinate
Hiểu nguyên nhân giúp bạn nhắm đúng giải pháp:
- Khoảng trống kiến thức (knowledge gap): Mô hình không có thông tin nhưng vẫn cố trả lời thay vì nói "tôi không biết". Bản tính của LLM là "luôn trả lời".
- Dữ liệu huấn luyện cũ hoặc sai: Mô hình học từ internet, nơi có cả thông tin sai. Và kiến thức của nó bị "đóng băng" tại thời điểm huấn luyện (knowledge cutoff).
- Prompt mơ hồ: Câu hỏi không rõ ràng khiến mô hình "đoán" ý người dùng.
- Nhiệt độ (temperature) cao: Tham số temperature càng cao, mô hình càng sáng tạo — và càng dễ bịa.
- Áp lực ngữ cảnh: Khi context quá dài hoặc tài liệu cung cấp không đủ để trả lời, mô hình "lấp đầy chỗ trống" bằng tưởng tượng.
Hai trục để quản trị: Detection và Mitigation
Với tư cách PM, hãy nghĩ theo hai trục song song. Mitigation là các biện pháp phòng ngừa từ trước để giảm tần suất hallucination xảy ra (grounding bằng RAG, prompt tốt, hạ temperature). Detection là các cơ chế bắt lỗi sau khi mô hình đã sinh ra câu trả lời nhưng trước khi (hoặc ngay khi) nó tới tay người dùng. Một sản phẩm trưởng thành cần cả hai — phòng ngừa không bao giờ đạt 100%, nên luôn cần lưới an toàn ở tầng phát hiện.
Tình huống thực tế
Tình huống 1: Chatbot ngân hàng số tại Việt Nam bịa lãi suất
Một ngân hàng số ở TP.HCM (gọi là "TechBank") triển khai trợ lý AI trả lời câu hỏi về sản phẩm tiết kiệm. Trong tuần đầu, đội ngũ phát hiện chatbot trả lời "lãi suất tiết kiệm kỳ hạn 12 tháng là 8.5%/năm" trong khi lãi suất thực tế lúc đó chỉ 5.6%. Con số 8.5% là từ dữ liệu huấn luyện cũ năm 2022.
Diễn giải: Đây là factual hallucination kết hợp knowledge cutoff. Mô hình tự tin đưa ra con số vì trong dữ liệu huấn luyện, mức lãi 8.5% từng phổ biến. Hậu quả: khách hàng đến chi nhánh đòi mở sổ với lãi 8.5%, gây tranh cãi và mất uy tín.
Cách TechBank xử lý: Họ chuyển hoàn toàn các con số lãi suất sang RAG grounding — chatbot bắt buộc truy xuất bảng lãi suất real-time từ hệ thống core banking, và prompt được viết lại: "CHỈ trả lời con số lãi suất dựa trên dữ liệu được cung cấp dưới đây. Nếu không có dữ liệu, hãy nói 'Vui lòng kiểm tra biểu lãi suất chính thức tại...'". Tỷ lệ sai về con số giảm từ khoảng 12% xuống dưới 0.5%.
Bài học: Mọi con số có tính ràng buộc pháp lý hoặc tài chính KHÔNG BAO GIỜ được để mô hình tự sinh từ trí nhớ. Phải ground bằng nguồn dữ liệu có thẩm quyền (authoritative source).
Tình huống 2: Trợ lý tư vấn pháp lý bịa số hiệu nghị định
Một startup legaltech (giả định tên "LuatAI") xây dựng công cụ tra cứu pháp luật cho doanh nghiệp SME. Khi người dùng hỏi về thủ tục đăng ký kinh doanh, công cụ trả lời và trích dẫn "theo Nghị định 78/2021/NĐ-CP" — nhưng nghị định này về nội dung đó không tồn tại với số hiệu đó. Mô hình ghép số một cách "nghe hợp lý".
Diễn giải: Đây là citation hallucination — loại nguy hiểm nhất trong domain pháp lý, nơi một số hiệu sai có thể dẫn đến hậu quả nghiêm trọng. Người dùng tin tưởng vì câu trả lời có vẻ "có dẫn chứng".
Cách LuatAI xử lý — detection nhiều tầng:
- Tầng 1: Mọi câu trả lời có trích dẫn văn bản luật phải được đối chiếu (cross-check) ngược lại với cơ sở dữ liệu văn bản pháp luật thật. Nếu số hiệu không khớp với DB, câu trả lời bị chặn.
- Tầng 2: Dùng một mô hình thứ hai (LLM-as-a-judge) kiểm tra: "Câu trả lời này có được hỗ trợ hoàn toàn bởi các đoạn văn bản đính kèm không?" Nếu điểm faithfulness dưới ngưỡng, hệ thống yêu cầu sinh lại hoặc chuyển sang trả lời thận trọng.
- Tầng 3: Hiển thị link gốc tới văn bản để người dùng tự xác minh.
Tình huống 3: Tính năng tóm tắt sản phẩm của một sàn TMĐT Đông Nam Á
Một sàn thương mại điện tử khu vực (kiểu Shopee/Lazada) ra tính năng AI tự động tóm tắt review sản phẩm. Một sản phẩm tai nghe có 200 review, đa số trung tính, nhưng phần tóm tắt AI lại viết: "Khách hàng đặc biệt khen ngợi khả năng chống ồn chủ động (ANC) tuyệt vời" — trong khi không một review nào nhắc đến ANC, và sản phẩm thậm chí không có tính năng này.
Diễn giải: Faithfulness hallucination. Mô hình "biết" rằng tai nghe thường có ANC nên tự thêm vào tóm tắt, dù nguồn (200 review) không hề có. Đây là loại bịa nguy hiểm về thương mại — có thể dẫn đến khiếu nại quảng cáo sai sự thật.
Cách xử lý: Đội ngũ thêm bước groundedness check tự động: mỗi câu trong bản tóm tắt phải "ánh xạ" được về ít nhất một review nguồn (dùng embedding similarity). Câu nào không tìm được nguồn hỗ trợ sẽ bị loại khỏi bản tóm tắt. Họ cũng thêm dòng disclaimer "Tóm tắt được tạo bởi AI dựa trên đánh giá của người mua".
Bài học: Với các tính năng tóm tắt/tổng hợp, hãy ràng buộc mọi khẳng định về một nguồn cụ thể. "No source, no claim" — không có nguồn thì không được khẳng định.
Hướng dẫn từng bước
Đây là quy trình thực dụng để xây dựng cơ chế chống hallucination cho một tính năng AI:
Bước 1 — Phân loại rủi ro của use case. Trước khi viết một dòng code chống hallucination, hãy xác định: nếu mô hình bịa ở đây, hậu quả là gì? Một chatbot gợi ý phim sai thì không sao; một chatbot tư vấn liều thuốc sai thì chết người. Xếp use case vào ba mức: thấp / trung bình / cao. Mức rủi ro quyết định bạn đầu tư bao nhiêu vào detection.
Bước 2 — Ưu tiên grounding bằng RAG. Cách giảm hallucination mạnh nhất là không bắt mô hình dựa vào trí nhớ. Hãy cung cấp dữ liệu thật trong context và yêu cầu trả lời dựa trên đó. (Chi tiết kiến trúc RAG đã có ở các bài khác — ở đây ta chỉ nhấn mạnh nó là vũ khí số một chống hallucination.)
Bước 3 — Thiết kế prompt chống bịa. Đưa vào system prompt các chỉ dẫn rõ ràng: "Chỉ trả lời dựa trên thông tin được cung cấp", "Nếu không chắc chắn hoặc không có dữ liệu, hãy nói rõ là bạn không biết", "Không suy diễn các con số hoặc tên riêng". Cho phép mô hình "thoát" bằng cách nói "tôi không biết" — đây là điều cực kỳ quan trọng, vì mặc định LLM ghét nói không biết.
Bước 4 — Hạ temperature cho tác vụ cần độ chính xác. Với câu trả lời dựa trên sự thật, đặt temperature thấp (0 đến 0.3). Temperature cao chỉ phù hợp với tác vụ sáng tạo như viết quảng cáo, đặt tên sản phẩm.
Bước 5 — Thêm tầng detection tự động. Có ba kỹ thuật phổ biến: (a) Self-consistency — hỏi mô hình cùng câu nhiều lần, nếu các câu trả lời mâu thuẫn nhau thì khả năng cao là hallucination; (b) LLM-as-a-judge — dùng một mô hình thứ hai chấm điểm xem câu trả lời có được nguồn hỗ trợ không (faithfulness/groundedness score); (c) Fact-checking đối chiếu — so câu trả lời với một cơ sở dữ liệu sự thật có thẩm quyền.
Bước 6 — Thiết kế hành vi khi nghi ngờ. Khi detection báo nghi ngờ, sản phẩm nên làm gì? Các lựa chọn: chặn câu trả lời và xin lỗi, hiển thị cảnh báo "thông tin này cần được xác minh", chuyển sang nhân viên thật (human handoff), hoặc sinh lại câu trả lời. Đừng để câu nghi ngờ lọt thẳng tới người dùng không lời cảnh báo.
Bước 7 — Đo lường và lặp lại. Xây một bộ test (eval set) gồm các câu hỏi đã biết đáp án đúng, chạy định kỳ để đo tỷ lệ hallucination. Theo dõi chỉ số này như một metric sản phẩm chính thức, không phải việc làm một lần.
Lỗi thường gặp & mẹo
Lỗi 1: Tin rằng "model xịn hơn sẽ hết hallucination". Sai. Mô hình mạnh hơn hallucinate ít hơn nhưng không bao giờ về 0, và đôi khi còn bịa "tinh vi" hơn, khó phát hiện hơn. Đừng coi việc nâng cấp model là giải pháp duy nhất.
Lỗi 2: Không cho mô hình lối thoát "tôi không biết". Nếu prompt của bạn ngầm yêu cầu mô hình luôn phải trả lời, nó sẽ bịa. Hãy chủ động khen thưởng sự thành thật: viết rõ "Nói 'tôi không có thông tin này' là một câu trả lời tốt và được khuyến khích."
Lỗi 3: Nhầm sự tự tin của mô hình với độ chính xác. Giọng văn càng dõng dạc không có nghĩa là càng đúng. Hallucination thường được trình bày tự tin y hệt sự thật. Đừng dùng "độ trôi chảy" làm tín hiệu tin cậy.
Lỗi 4: Áp dụng cùng một mức kiểm soát cho mọi use case. Lãng phí nguồn lực kiểm tra gắt gao tính năng gợi ý nhạc, trong khi lại lơ là tính năng tư vấn y tế. Hãy phân bổ nỗ lực theo mức rủi ro.
Mẹo hữu ích:
- Yêu cầu mô hình trích dẫn nguồn cho từng khẳng định ngay trong câu trả lời. Việc buộc phải dẫn nguồn tự nó đã giảm hallucination, và giúp người dùng tự kiểm chứng.
- Dùng structured output (JSON có trường "confidence" và "source") để dễ kiểm tra tự động phần nào đáng ngờ.
- Với câu hỏi ngoài phạm vi dữ liệu, hãy thiết kế để mô hình từ chối lịch sự thay vì cố trả lời.
- Luôn có disclaimer rõ ràng rằng nội dung do AI tạo ra — vừa quản trị kỳ vọng người dùng, vừa giảm rủi ro pháp lý.
Bài tập thực hành
- Phân loại loại hallucination. Cho ba câu trả lời sai sau, xác định mỗi câu thuộc loại nào (factual / faithfulness / citation): (a) "Vịnh Hạ Long được UNESCO công nhận năm 1995" (thực tế 1994); (b) một bản tóm tắt hợp đồng thêm điều khoản không có trong hợp đồng gốc; (c) một câu trả lời trích "Thông tư 45/2020/TT-BTC" không tồn tại.
- Viết prompt chống bịa. Cho use case "chatbot trả lời chính sách đổi trả của cửa hàng thời trang", hãy viết một system prompt hoàn chỉnh áp dụng các nguyên tắc trong bài: grounding, cho phép nói "không biết", cấm suy diễn con số.
- Thiết kế tầng detection. Cho một sản phẩm trợ lý y tế tra cứu thông tin thuốc (rủi ro cao), hãy phác thảo quy trình detection 3 tầng và mô tả hành vi sản phẩm khi mỗi tầng báo nghi ngờ.
- Xây mini eval set. Tạo 10 câu hỏi có đáp án đúng đã biết cho một lĩnh vực bạn chọn (ví dụ: thông tin du lịch Việt Nam). Mô tả cách bạn sẽ dùng bộ này để đo tỷ lệ hallucination của sản phẩm hàng tuần.
- Tình huống ra quyết định. Detection báo rằng 15% câu trả lời của chatbot có dấu hiệu hallucination, nhưng nếu siết chặt thì 30% câu hỏi hợp lệ bị mô hình từ chối trả lời (over-refusal). Bạn cân bằng hai chỉ số này thế nào? Hãy lập luận như một PM, gắn với mức rủi ro của use case.
Tóm tắt
Hallucination là việc LLM tạo ra nội dung nghe hợp lý nhưng sai sự thật — không phải lỗi ngẫu nhiên mà là đặc tính cố hữu của cách mô hình hoạt động. Bạn không thể xóa bỏ nó hoàn toàn, nhưng hoàn toàn có thể kiểm soát tới mức chấp nhận được.
Ba loại cần phân biệt: factual (bịa sự thật), faithfulness (sai lệch so với nguồn cung cấp — phổ biến nhất trong sản phẩm RAG), và citation (bịa trích dẫn — nguy hiểm nhất). Quản trị theo hai trục: mitigation (phòng ngừa: grounding bằng RAG, prompt tốt, hạ temperature, cho phép "tôi không biết") và detection (bắt lỗi: self-consistency, LLM-as-a-judge, đối chiếu nguồn thật).
Là AI PM, hãy bắt đầu từ phân loại rủi ro của use case, đầu tư kiểm soát tương xứng với hậu quả, thiết kế hành vi sản phẩm rõ ràng khi nghi ngờ, và đo tỷ lệ hallucination như một metric chính thức. Bài học cốt lõi: mọi khẳng định về sự thật phải có nguồn — "no source, no claim". Một sản phẩm AI đáng tin không phải là sản phẩm không bao giờ sai, mà là sản phẩm biết khi nào nó có thể sai và xử lý điều đó một cách minh bạch.