Product Management
Đăng nhập
ESC

Nhập từ khóa để tìm kiếm

↑↓ Di chuyển
Enter Mở
ESC Đóng

Bài 5 — Guardrails & giảm hallucination

Eval cho bạn biết chất lượng trung bình. Nhưng ở production, một câu trả lời sai nguy hiểm cũng đủ gây khủng hoảng: bịa chính sách hoàn tiền, tư vấn y tế sai, lộ dữ liệu mật. Guardrails là các lớp bảo vệ chặn lỗi ngay khi đang chạy; giảm hallucination là chiến lược làm mô hình bớt bịa.

Hallucination là gì và vì sao xảy ra

Hallucination là khi mô hình đưa ra thông tin nghe hợp lý nhưng sai hoặc bịa hoàn toàn. Nguyên nhân: mô hình được tối ưu để "nói tiếp một cách trôi chảy", không phải để "đúng sự thật". Khi thiếu dữ kiện, nó vẫn tự tin điền vào chỗ trống.

Chiến lược giảm hallucination (theo thứ tự ưu tiên)

  • Cấp ngữ cảnh đúng (RAG) — nguyên nhân bịa số một là thiếu dữ liệu. Cho mô hình tài liệu để bám vào.
  • Cho phép nói "không biết" — prompt phải khuyến khích từ chối khi thiếu thông tin, thay vì ép nó luôn trả lời.
  • Yêu cầu trích dẫn — bắt mô hình dẫn nguồn khiến nó bám ngữ cảnh và giúp người dùng kiểm chứng.
  • Grounding check — sau khi sinh, dùng một bước kiểm tra: câu trả lời có được ngữ cảnh hỗ trợ không? Không thì chặn hoặc gắn cờ.
  • Giảm nhiệt độ (temperature) cho tác vụ cần chính xác, tăng cho tác vụ sáng tạo.

Các loại guardrails

  • Input guardrails: lọc trước khi gửi mô hình — chặn prompt injection, nội dung cấm, PII.
  • Output guardrails: kiểm sau khi sinh — kiểm schema JSON, lọc từ ngữ độc hại, kiểm câu trả lời có bám nguồn.
  • Behavioral guardrails: giới hạn phạm vi — "chỉ trả lời về sản phẩm công ty, từ chối câu hỏi ngoài phạm vi."
  • Human-in-the-loop: với hành động rủi ro cao (gửi email, hoàn tiền, chẩn đoán), yêu cầu người duyệt.

Ví dụ cụ thể

Chatbot ngân hàng. Người dùng: "Chuyển giúp tôi 50 triệu sang tài khoản X."

  • Behavioral guardrail: bot chỉ soạn lệnh, không tự thực hiện giao dịch tiền.
  • Human/OTP-in-the-loop: yêu cầu xác thực trước khi chuyển.
  • Output guardrail: nếu bot trả lời có số dư/hạn mức, grounding check đối chiếu với API tài khoản; lệch thì chặn.
Một guardrail đúng chỗ ngăn được thảm họa mà eval trung bình không bắt được.

Khung tư duy: phòng thủ theo tầng (defense in depth)

Đừng trông vào một lớp duy nhất. Kết hợp: prompt tốt + RAG + grounding check + output validation + human-in-the-loop cho ca rủi ro cao. Mỗi lớp bắt loại lỗi khác nhau.

Checklist guardrails

  • [ ] Prompt cho phép và khuyến khích "không biết".
  • [ ] Có input filter chống prompt injection và PII.
  • [ ] Output được validate schema trước khi hiển thị/tích hợp.
  • [ ] Có grounding/faithfulness check cho câu trả lời dựa RAG.
  • [ ] Hành động rủi ro cao có human-in-the-loop hoặc xác thực.
  • [ ] UX hiển thị độ tin cậy/nguồn để người dùng tự thẩm định.
  • [ ] Có log + cảnh báo khi guardrail kích hoạt để cải tiến.

Sai lầm thường gặp

  • Ép mô hình luôn trả lời thay vì cho phép từ chối → tăng bịa.
  • Chỉ dựa vào prompt để an toàn; prompt có thể bị injection vượt qua.
  • Không validate output nên JSON hỏng làm sập tích hợp downstream.
  • Để mô hình tự thực hiện hành động tiền/xóa dữ liệu không có người duyệt.
  • Guardrails quá gắt khiến bot từ chối cả câu hợp lệ — cân bằng an toàn và hữu ích.
  • Không log lúc guardrail bật, mất cơ hội học và cải thiện.
An toàn và chính xác đã có. Còn một trục sống còn cho sản phẩm quy mô: chi phí, độ trễ, và chọn đúng giữa fine-tune/RAG/prompt — Bài 6.

Học xong bài này rồi? Tạo tài khoản miễn phí để lưu lại — lần sau vào là biết ngay đang dở ở đâu, và học hết khóa thì có chứng chỉ. Lưu tiến độ của tôi