Bài 35 — Explainability — XAI Cơ bản

Mở đầu — vì sao bài này quan trọng

Hãy tưởng tượng bạn là PM của một sản phẩm cho vay tiêu dùng. Mô hình AI của bạn vừa từ chối hồ sơ vay 50 triệu đồng của một khách hàng. Anh ấy gọi lên tổng đài hỏi: "Tại sao tôi bị từ chối?". Nhân viên chăm sóc nhìn vào hệ thống và chỉ thấy đúng một dòng: risk_score = 0.83, decision = REJECT. Không ai trong công ty có thể trả lời câu hỏi đó. Khách hàng tức giận, đăng bài lên Facebook, và một tuần sau Ngân hàng Nhà nước gửi văn bản yêu cầu giải trình cơ sở của quyết định tự động.

Đây chính là vấn đề mà Explainable AI (XAI) — AI có thể giải thích được sinh ra để giải quyết. Phần lớn các mô hình AI mạnh nhất hiện nay — từ deep learning đến LLM — đều là "hộp đen" (black box): chúng cho ra kết quả chính xác nhưng không tự giải thích được vì sao lại ra kết quả đó. Với tư cách một AI Product Manager, bạn sẽ liên tục đứng giữa ba bên: người dùng muốn hiểu, đội pháp chế muốn an toàn, và đội kỹ thuật muốn ship nhanh. XAI là bộ công cụ và tư duy giúp bạn cân bằng cả ba.

Bài này tập trung riêng vào explainability ở mức cơ bản: vì sao cần, các cấp độ giải thích (global vs local), những kỹ thuật phổ biến nhất, và cách bạn — một PM, không phải data scientist — đưa explainability vào sản phẩm thực tế. Đây là nền tảng để sau này bạn xây dựng được niềm tin (trust) và thiết kế các UX pattern minh bạch ở những bài tiếp theo.

Khái niệm cốt lõi

Explainability là gì và khác gì Interpretability

Hai thuật ngữ này hay bị dùng lẫn lộn, nhưng phân biệt được sẽ giúp bạn nói chuyện chính xác với đội kỹ thuật:

Interpretability (tính diễn giải): bản thân mô hình đủ đơn giản để con người hiểu trực tiếp cách nó hoạt động. Ví dụ: một cây quyết định (decision tree) với 5 nhánh, hay hồi quy tuyến tính (linear regression) với các hệ số rõ ràng. Bạn nhìn vào là hiểu ngay.
Explainability (tính giải thích): mô hình quá phức tạp để hiểu trực tiếp (như mạng neural sâu hay LLM), nên ta dùng kỹ thuật phụ trợ bên ngoài để giải thích quyết định của nó sau khi nó đã chạy. Đây gọi là phương pháp post-hoc (giải thích hậu kiểm).

Quy luật ngầm trong ngành: mô hình càng mạnh thì càng khó giải thích. Đây là sự đánh đổi (trade-off) trung tâm mà PM phải ra quyết định.

Bốn lý do bạn cần XAI

1. Regulatory — Tuân thủ pháp lý. Trong các ngành nhạy cảm như ngân hàng, bảo hiểm, y tế, tuyển dụng, pháp luật ngày càng yêu cầu "quyền được giải thích". GDPR của EU có điều khoản về quyết định tự động; EU AI Act phân loại các hệ thống tín dụng, y tế là "high-risk" và bắt buộc minh bạch. Tại Việt Nam, Ngân hàng Nhà nước và Luật Bảo vệ dữ liệu cá nhân cũng đang siết chặt các quyết định tự động ảnh hưởng đến quyền lợi người dân.

2. User trust — Niềm tin người dùng. Người dùng tin và dùng lại sản phẩm AI nhiều hơn khi họ hiểu vì sao AI gợi ý như vậy. "Gợi ý áo này vì bạn vừa mua quần cùng tông màu" thuyết phục hơn nhiều so với một gợi ý không lời.

3. Debug model — Gỡ lỗi mô hình. Khi mô hình sai, explainability cho bạn biết nó đang "nhìn vào" cái gì. Ví dụ kinh điển: một mô hình phân loại ảnh chó sói vs chó nhà hoá ra chỉ nhìn vào nền tuyết trắng chứ không nhìn con vật — XAI giúp lộ ra sai lầm này.

4. Detect bias — Phát hiện thiên kiến. Nếu mô hình đang ngầm dựa vào giới tính, vùng miền, độ tuổi để ra quyết định, explainability là công cụ đầu tiên giúp bạn phát hiện. (Cách xử lý bias sâu hơn là chủ đề của bài riêng; ở đây ta chỉ dùng XAI để phát hiện.)

Hai cấp độ explainability: Global vs Local

Đây là khái niệm quan trọng nhất của bài. Mọi giải thích đều rơi vào một trong hai cấp:

Global explainability — "Mô hình nói chung hoạt động thế nào?" Trả lời câu hỏi: trên toàn bộ tập dữ liệu, yếu tố nào quan trọng nhất với mô hình? Ví dụ: "Trong mô hình chấm điểm tín dụng của chúng ta, ba yếu tố ảnh hưởng lớn nhất là lịch sử trả nợ (35%), thu nhập (28%) và số khoản vay đang có (15%)." Global explainability giúp lãnh đạo, pháp chế và đội sản phẩm hiểu bản chất mô hình. Kỹ thuật thường dùng: Feature Importance (mức độ quan trọng của từng đặc trưng) và Partial Dependence Plots (biểu đồ cho thấy khi một yếu tố thay đổi thì dự đoán thay đổi ra sao).

Local explainability — "Vì sao mô hình ra quyết định NÀY cho trường hợp NÀY?" Trả lời câu hỏi cho một dự đoán cụ thể: tại sao hồ sơ của anh Nguyễn Văn A bị từ chối? Đây là cấp độ bạn cần để trả lời khách hàng và cơ quan quản lý. Hai kỹ thuật phổ biến nhất:

LIME (Local Interpretable Model-agnostic Explanations): tạm hiểu là xây một mô hình đơn giản (như đường thẳng) xấp xỉ mô hình phức tạp quanh đúng một điểm dữ liệu, để chỉ ra yếu tố nào đẩy quyết định theo hướng nào.
SHAP (SHapley Additive exPlanations): dựa trên lý thuyết trò chơi, phân bổ "công lao/lỗi" của mỗi đặc trưng cho kết quả cuối cùng. SHAP cho ra con số kiểu: thu nhập kéo điểm rủi ro +0.12, lịch sử trả nợ trễ kéo +0.20, tuổi tài khoản kéo -0.05. Cộng lại ra đúng quyết định. SHAP được giới PM yêu thích vì vừa dùng được cho global (gộp lại) vừa cho local (từng hồ sơ).

Explainability cho LLM thì sao?

Với LLM, explainability khó hơn nhiều vì mô hình có hàng tỷ tham số. Trong thực tế sản phẩm, PM thường không dùng SHAP/LIME cho LLM mà dùng các kỹ thuật "đủ tốt" ở tầng ứng dụng:

Citations (trích dẫn nguồn): bắt LLM chỉ ra câu trả lời lấy từ tài liệu nào — đây là dạng explainability thực dụng nhất cho sản phẩm RAG.
Chain-of-thought / reasoning trace: yêu cầu mô hình trình bày các bước suy luận.
Confidence / uncertainty signals: hiển thị mức độ chắc chắn.

Bạn không cần hiểu toán bên trong, nhưng cần biết các "đòn bẩy" này tồn tại để thiết kế sản phẩm minh bạch.

Tình huống thực tế

Tình huống 1 — Fintech cho vay tại Việt Nam và cú "phanh gấp" pháp lý

Một công ty fintech tại TP.HCM (gọi là LoanFast) triển khai mô hình gradient boosting chấm điểm tín dụng cho vay tiêu dùng, tỷ lệ duyệt tự động 70%, sai số thấp. Mọi thứ ổn cho đến khi một loạt khách hàng bị từ chối khiếu nại, và đối tác ngân hàng yêu cầu LoanFast giải trình cơ sở của từng quyết định trước khi tiếp tục hợp tác.

Đội ngũ tích hợp SHAP vào pipeline. Mỗi khi từ chối, hệ thống tự sinh "lý do top 3": ví dụ "Số khoản vay đang mở quá nhiều (đóng góp 0.22 vào điểm rủi ro)", "Thu nhập khai báo chưa được xác minh (0.18)". Họ cũng chạy global SHAP và phát hiện một điều giật mình: mô hình đang gán trọng số bất thường cao cho mã vùng số điện thoại — vô tình tạo ra thiên kiến vùng miền. Họ loại đặc trưng này khỏi mô hình.

Bài học: Local explainability cứu nguy về mặt vận hành (trả lời được khách hàng và đối tác), còn global explainability lộ ra một lỗi bias mà không ai để ý. Một công cụ, hai cấp độ, hai giá trị khác nhau. Là PM, bạn nên yêu cầu cả hai ngay từ thiết kế, đừng đợi đến khi bị "tuýt còi".

Tình huống 2 — Gợi ý sản phẩm trên sàn TMĐT và "vì sao món này"

Một sàn thương mại điện tử khu vực Đông Nam Á (tương tự Shopee/Tiki) phát hiện tỷ lệ click vào gợi ý sản phẩm thấp. Đội PM đặt giả thuyết: người dùng không tin các gợi ý vì chúng "từ trên trời rơi xuống". Họ thử nghiệm A/B: nhóm A thấy gợi ý trần trụi, nhóm B thấy gợi ý kèm một dòng giải thích ngắn — "Vì bạn đã xem điện thoại Samsung", "Người mua sản phẩm này cũng mua...".

Kết quả nhóm B có tỷ lệ click cao hơn đáng kể và tỷ lệ thêm vào giỏ tăng. Quan trọng hơn: dòng giải thích đó được sinh từ chính tín hiệu local explainability của mô hình recommendation (đặc trưng nào đẩy mạnh điểm gợi ý cho cặp người dùng–sản phẩm này).

Bài học: Explainability không chỉ là chuyện tuân thủ phòng thủ — nó là tính năng tạo giá trị. Cùng một thông tin "vì sao mô hình gợi ý X", khi đưa lên UI đúng cách, sẽ trực tiếp cải thiện chỉ số kinh doanh. PM giỏi biến explainability từ chi phí thành lợi thế.

Tình huống 3 — Trợ lý AI nội bộ và bài học "phải có nguồn"

Một ngân hàng triển khai chatbot RAG trả lời nhân viên về quy trình nội bộ. Phiên bản đầu chỉ trả lời trơn, không trích nguồn. Nhân viên không dám tin — vì nếu làm sai quy trình theo lời chatbot thì họ chịu trách nhiệm, không phải con bot. Tỷ lệ sử dụng èo uột.

Đội PM thêm một thay đổi nhỏ về explainability ở tầng ứng dụng: mỗi câu trả lời kèm trích dẫn đúng tên tài liệu, số điều khoản và đường link tới đoạn gốc; câu nào mô hình không tìm thấy nguồn thì hiển thị "Tôi không chắc, vui lòng kiểm tra với phòng nghiệp vụ". Tỷ lệ sử dụng tăng rõ rệt sau vài tuần.

Bài học: Với LLM, bạn thường không có SHAP/LIME, nhưng citations chính là explainability thực dụng và mạnh mẽ nhất. "Giải thích được nguồn" nhiều khi quan trọng hơn "giải thích được cơ chế".

Hướng dẫn từng bước

Đây là quy trình một PM có thể áp dụng để đưa explainability vào sản phẩm AI:

Xác định ai cần lời giải thích và để làm gì. Liệt kê các bên: người dùng cuối, đội chăm sóc khách hàng, pháp chế, data scientist. Mỗi bên cần cấp độ khác nhau. Người dùng cần local đơn giản ("vì 3 lý do này"); pháp chế cần global + bằng chứng có thể lưu trữ; kỹ sư cần debug chi tiết.

Phân loại mức rủi ro của quyết định. Quyết định càng ảnh hưởng đến quyền lợi/tiền bạc/sức khoẻ thì yêu cầu explainability càng cao. Gợi ý phim Netflix: nhẹ. Từ chối khoản vay hay sàng lọc CV: nặng, bắt buộc giải thích được.

Chọn cấp độ và kỹ thuật. Với mô hình ML cổ điển (bảng số liệu): dùng SHAP cho cả global và local là lựa chọn mặc định an toàn. Với LLM: dùng citations, reasoning trace, confidence. Đừng cố ép SHAP vào LLM.

Cân nhắc đánh đổi accuracy vs explainability. Tự hỏi: liệu một mô hình đơn giản hơn nhưng tự giải thích được (như logistic regression) có "đủ tốt" cho ca này không? Nhiều khi mất 2% accuracy để đổi lấy mô hình minh bạch là một giao dịch hời trong ngành được quản lý chặt.

Thiết kế cách trình bày lời giải thích trên UI. Đây là phần PM dễ bỏ quên. Một bảng SHAP đầy số chỉ dành cho kỹ sư. Người dùng cần ngôn ngữ tự nhiên: "Hồ sơ chưa được duyệt chủ yếu vì lịch sử trả nợ và số khoản vay hiện tại." Hãy biên dịch tín hiệu kỹ thuật thành câu chữ con người.

Lưu vết (logging) lời giải thích. Với ngành được quản lý, lưu lại lời giải thích của mỗi quyết định quan trọng để truy vết và giải trình về sau. Đây là yêu cầu thường bị quên cho đến khi bị thanh tra.

Kiểm thử lời giải thích với người thật. Cho 5–10 người dùng/nhân viên xem lời giải thích và hỏi: "Bạn có hiểu không? Có tin hơn không?". Lời giải thích mà người dùng không hiểu thì vô dụng dù toán học đúng.

Lỗi thường gặp & mẹo

Lỗi 1 — Nhầm "giải thích nghe hợp lý" với "giải thích đúng". Một lời giải thích trôi chảy chưa chắc phản ánh đúng cái mô hình thực sự làm. LIME/SHAP là xấp xỉ, có sai số. Đừng tuyệt đối hoá. Mẹo: với quyết định rủi ro cao, đối chiếu lời giải thích với kiến thức nghiệp vụ — nếu mô hình bảo "từ chối vì màu áo đại diện" thì rõ ràng có gì đó sai.

Lỗi 2 — Đổ quá nhiều thông tin lên người dùng. Hiển thị 30 đặc trưng với điểm SHAP cho khách hàng phổ thông là phản tác dụng. Mẹo: chọn top 3–5 yếu tố, diễn đạt bằng tiếng Việt đời thường.

Lỗi 3 — Coi explainability là việc của riêng đội data. Nếu PM không đặt yêu cầu từ đầu, đội kỹ thuật thường bỏ qua vì nó tốn thời gian và không "lên metric". Mẹo: đưa explainability vào định nghĩa "Done" của tính năng AI.

Lỗi 4 — Ép explainability cho LLM bằng công cụ của ML cổ điển. SHAP/LIME không phù hợp và không thực dụng cho LLM trong sản phẩm. Mẹo: với LLM, dùng citations, chain-of-thought và uncertainty làm "explainability tầng ứng dụng".

Lỗi 5 — Quên rằng lời giải thích cũng có thể bị lạm dụng. Nếu bạn tiết lộ quá chi tiết cơ chế chấm điểm tín dụng, kẻ xấu có thể "gaming" hệ thống. Mẹo: cân bằng giữa minh bạch đủ để tạo niềm tin và bảo mật đủ để chống lạm dụng.

Bài tập thực hành

Lập bản đồ bên liên quan. Chọn một sản phẩm AI bạn biết (gợi ý sản phẩm, duyệt vay, chấm CV...). Liệt kê 4 nhóm cần lời giải thích, và với mỗi nhóm ghi rõ họ cần global hay local, và định dạng nào (số liệu, câu chữ, biểu đồ).

Phân biệt global vs local. Viết 2 câu giải thích cho một mô hình duyệt vay: một câu mang tính global ("Mô hình nói chung dựa vào...") và một câu local ("Hồ sơ cụ thể này bị từ chối vì..."). Đảm bảo phân biệt rõ.

Biên dịch tín hiệu kỹ thuật sang ngôn ngữ người dùng. Cho dữ liệu SHAP giả định: số_khoản_vay_đang_mở: +0.22, thu_nhập_chưa_xác_minh: +0.18, tuổi_tài_khoản: -0.05. Viết một thông báo từ chối thân thiện, dễ hiểu, tối đa 3 dòng cho khách hàng Việt Nam.

Quyết định đánh đổi. Giả sử bạn có hai lựa chọn: mô hình A (accuracy 92%, hộp đen) và mô hình B (accuracy 89%, tự giải thích được). Hãy lập luận chọn mô hình nào cho (a) gợi ý nhạc, (b) sàng lọc hồ sơ tuyển dụng. Giải thích vì sao bối cảnh quyết định lựa chọn.

Tóm tắt

Explainable AI (XAI) giúp con người hiểu vì sao mô hình AI ra quyết định, đặc biệt cần thiết với các mô hình hộp đen như deep learning và LLM.
Bốn động lực chính: tuân thủ pháp lý, niềm tin người dùng, gỡ lỗi mô hình, phát hiện thiên kiến.
Phân biệt interpretability (mô hình tự đủ đơn giản để hiểu) và explainability (dùng kỹ thuật phụ trợ post-hoc để giải thích mô hình phức tạp).
Hai cấp độ cốt lõi: global ("mô hình nói chung hoạt động thế nào") và local ("vì sao quyết định cụ thể này"). Kỹ thuật phổ biến: Feature Importance cho global; LIME và SHAP cho local.
Với LLM, explainability thực dụng nằm ở tầng ứng dụng: citations, reasoning trace, confidence, chứ không phải SHAP/LIME.
Quy luật đánh đổi: mô hình càng mạnh càng khó giải thích — PM phải cân giữa accuracy và explainability tuỳ mức rủi ro của quyết định.
Vai trò PM: xác định ai cần giải thích, chọn cấp độ phù hợp, biên dịch tín hiệu kỹ thuật thành ngôn ngữ con người, lưu vết và kiểm thử với người dùng thật. Explainability không chỉ là chi phí phòng thủ — làm tốt, nó trở thành tính năng tạo niềm tin và tăng chuyển đổi.