Giảm Hallucination Của LLM Trong Production: 5 Lớp Kỹ Thuật Cho Dev

Bạn ship một feature dùng LLM, demo chạy mượt, rồi production trả về một câu trả lời nghe rất thuyết phục nhưng sai hoàn toàn. Model bịa ra một citation không tồn tại, hoặc giải thích một API theo cách chẳng giống tài liệu nào. Đây là hallucination, và nó là rào cản lớn nhất khi đưa LLM vào hệ thống thật.

Bài này đi thẳng vào việc bạn làm được sau khi đọc: hiểu vì sao model bịa, và áp dụng đúng lớp kỹ thuật ở tầng application để câu trả lời trở nên grounded và verifiable.

Vì sao LLM hallucinate

Điểm mấu chốt: một LLM không "biết" câu nào đúng câu nào sai. Nó sinh text bằng cách dự đoán chuỗi token có xác suất cao nhất, dựa trên pattern học lúc training và context bạn đưa vào lúc inference. Như nguồn mô tả, model "can produce a fluent and confident answer even when it does not have enough information to answer the question correctly".

Hiểu cơ chế sinh token giúp bạn hết ngạc nhiên. Model tokenize câu hỏi, chuyển token thành embedding, đẩy qua các transformer layer với self-attention để dựng biểu diễn ngữ cảnh, rồi sinh response một token tại một thời điểm. Mỗi bước nó tính probability cho các token kế tiếp và chọn theo decoding strategy. Vì vậy một response trôi chảy không đảm bảo thông tin bên dưới là đúng.

Từ đó, các nguyên nhân hallucination gom lại thành vài nhóm quen thuộc với dev:

• Kiến thức thiếu hoặc lỗi thời — model không có dữ liệu bạn cần, hoặc dữ liệu đã cũ so với thực tế.
• Context không đủ — bạn hỏi một câu cần thông tin mà prompt không cung cấp.
• Prompt mơ hồ — model hiểu sai ý và trả lời lệch hướng.
• Bản chất probabilistic — khi thiếu thông tin, model vẫn sinh một câu "nghe hợp lý" thay vì nói "tôi không biết".

Giảm hallucination là bài toán ở tầng hệ thống, không phải chỉ prompt

Sai lầm phổ biến là nghĩ chỉnh prompt cho khéo là đủ. Nguồn nói rõ: "Reducing hallucinations requires more than improving the prompt." Một hệ thống LLM đáng tin cậy kết hợp nhiều lớp: prompt design rõ ràng, RAG, nguồn dữ liệu ngoài đáng tin, tool và function calling, structured output, fine-tuning, response verification, và evaluation có hệ thống.

Dưới đây là cách xếp các lớp đó theo thứ tự bạn nên triển khai, từ rẻ tới đắt.

1. Prompt design: thu hẹp không gian trả lời

Lớp rẻ nhất. Viết prompt sao cho model được phép nói "không đủ dữ liệu" thay vì bịa. Yêu cầu model chỉ trả lời dựa trên context được cung cấp, và nêu rõ khi thông tin thiếu. Đây là phân tích thực hành, không phải con số đo được, nhưng nó cắt được nhóm nguyên nhân "prompt mơ hồ".

2. RAG: đưa thông tin đúng vào lúc generation

Retrieval-Augmented Generation là lớp có tác động lớn nhất cho hầu hết use case doanh nghiệp. Thay vì để model dựa hoàn toàn vào kiến thức đã học, bạn retrieve tài liệu liên quan và nhét vào context ngay tại thời điểm sinh câu trả lời. Nguồn tóm gọn: "RAG can provide models with relevant information at generation time." Điều này đánh trực tiếp vào hai nguyên nhân "kiến thức lỗi thời" và "context không đủ".

Ví dụ minh hoạ (illustrative, không phải code production) cho luồng RAG cơ bản:

chunks = retriever.search(query, top_k=5)
context = "\n\n".join(c.text for c in chunks)
prompt = f"Chỉ trả lời dựa trên context sau. Nếu thiếu, nói rõ.\n\n{context}\n\nCâu hỏi: {query}"
answer = llm.generate(prompt)

3. Tool và function calling: lấy dữ liệu chính xác thay vì nhớ

Với thông tin cần độ chính xác cao hoặc luôn cập nhật — giá, tồn kho, trạng thái đơn hàng — đừng bắt model nhớ. Cho nó gọi tool. Như nguồn nói, "tools can allow them to retrieve current or precise information instead of relying entirely on learned knowledge". Model chuyển từ vai "người trả lời từ trí nhớ" sang "người điều phối truy vấn".

4. Structured output: ràng buộc hình dạng câu trả lời

Bắt model trả về JSON theo schema cố định giúp bạn validate được ngay, và giảm khoảng trống để model "nói lan man". Kết hợp với bước verification ở dưới, structured output biến câu trả lời thành thứ máy kiểm tra được.

5. Verification và evaluation: bắt lỗi trước khi user thấy

Đây là lớp hay bị bỏ. Response verification kiểm tra xem câu trả lời có được support bởi nguồn hay không; evaluation có hệ thống giúp bạn phát hiện các trường hợp câu trả lời "unsupported or incorrect". Nguồn nhấn mạnh: "Evaluation and verification can then help identify cases where the generated response is unsupported or incorrect." Một vòng verify — dù chỉ là đối chiếu câu trả lời với chunk đã retrieve — đã chặn được nhiều lỗi trước production.

Kỳ vọng đúng: grounded, không phải hoàn hảo

Đừng bán cho sếp hay khách hàng lời hứa "hết sạch hallucination". Nguồn nói thẳng: mục tiêu không phải khẳng định hallucination có thể bị loại bỏ hoàn toàn, mà là hiểu nguyên nhân và thiết kế hệ thống "more accurate, grounded, verifiable, and reliable". Với dev, đây là sự khác biệt giữa một demo và một sản phẩm dám đặt trước người dùng thật.

Bắt đầu từ đâu

Nếu hệ thống của bạn đang dựa hoàn toàn vào kiến thức nội tại của model, thứ tự triển khai thực dụng là: siết prompt để cho phép "không biết", thêm RAG cho phần kiến thức domain, chuyển các dữ kiện chính xác sang tool calling, ép structured output, rồi gắn một bước verify. Mỗi lớp cắt một nhóm nguyên nhân — cộng lại, chúng biến LLM từ một cỗ máy đoán chữ thành một component bạn tin được trong production.