Case Study: AI System Failure Analysis #18

Trả lời ngắn: AI system failure analysis là cách điều tra một sự cố bằng evidence xuyên suốt data, retrieval, prompt, model, tool, policy, UX và vận hành. Trong case này, assistant trả lời sai vì policy cache cũ; đội xử lý chặn impact, giữ timeline, tìm nguyên nhân, kiểm fix và chỉ mở lại sau canary.

Đọc xong, bạn sẽ hiểu:

• Vì sao “model trả lời sai” mới chỉ là symptom, chưa phải root cause.
• Cách phân loại severity, blast radius, owner và evidence.
• Cách đi từ signal → containment → scope → cause → fix → verify → learn.
• Vì sao rollback, canary, log tối thiểu và postmortem là một phần của thiết kế.

Lưu ý giáo dục: Đây là incident giả với dữ liệu tổng hợp. Không dùng customer transcript, PII, token, production log hoặc thao tác rollback thật cho bài tập này. Mọi tỷ lệ, timestamp và impact bên dưới chỉ minh họa cách suy nghĩ, không phải benchmark hay cam kết reliability.

1. Case study: AI system fail ở đâu?

Một nền tảng học giả lập có recommendation assistant gợi ý bài tiếp theo. Ngày thứ Hai, policy về “bài bắt buộc trước khi vào cấp độ nâng cao” được cập nhật từ v1 lên v2. Assistant vẫn đưa một số học viên thẳng tới bài nâng cao và nói chắc rằng họ đã đủ điều kiện. Support nhận ba phản ánh, dashboard thấy tỷ lệ câu trả lời bị sửa tăng, nhưng chưa ai biết lỗi nằm ở policy, retrieval hay model.

Đây là incident, tức sự kiện gây hoặc có nguy cơ gây impact cần xử lý. Câu “assistant trả lời sai” là symptom. Failure mode là cách một thành phần có thể sai hoặc hỏng; trong giả thuyết ban đầu, retrieval cache đang phục vụ policy v1 sau khi policy v2 có hiệu lực. Root cause chỉ được gọi sau khi evidence xác nhận chuỗi điều kiện, không phải sau một lần đoán.

Mục tiêu của đội không phải tìm một thành phần để đổ lỗi. Mục tiêu là giảm impact, biết phạm vi, bảo toàn bằng chứng, sửa đúng lớp và ngăn lặp lại. Cùng một output sai có thể đến từ source cũ, prompt thiếu ngày hiệu lực, tool trả dữ liệu nhầm tenant, model suy diễn, UI hiển thị quá chắc hoặc operator bỏ qua cảnh báo.

Hình 1 — Failure analysis là vòng evidence: chặn impact trước, rồi xác minh nguyên nhân và học lại.

Ví dụ đời thường: đèn báo nhiệt trên xe bật sáng. Ta chưa kết luận động cơ hỏng; cần giảm tốc, xem lúc nào bật, kiểm cảm biến, mức dầu và lịch bảo dưỡng. Tắt đèn bằng cách tháo cầu chì có thể làm dashboard yên nhưng không làm xe an toàn hơn.

2. Failure taxonomy và severity

Để không nhảy ngay vào model, lập taxonomy theo lớp:

Blast radius là phạm vi user, request hoặc flow bị ảnh hưởng. Đội có thể bắt đầu bằng các field tổng hợp: policy version, workflow version, model version, route, locale, thời gian, số request và tỷ lệ correction. Không cần copy raw transcript để biết scope. Nếu incident ảnh hưởng một cohort thử nghiệm, severity có thể khác lúc nó lan tới toàn bộ learning path.

Severity là mức độ nghiêm trọng dùng để ưu tiên. Một matrix đơn giản xét impact, duration, reversibility và sensitivity:

Mức S1–S3 ở đây chỉ là mẫu để phân loại, không phải chuẩn chung. Điều quan trọng là owner, thời hạn cập nhật và điều kiện nâng/hạ severity phải được viết ra. Nếu chưa biết impact thật, ghi UNKNOWN và điều tra; đừng dùng “không thấy lỗi thêm” làm bằng chứng đã an toàn.

Hình 2 — Một output sai có nhiều lớp nguyên nhân; taxonomy giúp điều tra không bị khóa vào model.

3. Timeline, evidence và containment

Bước đầu là tạo timeline UTC giả và gắn mỗi event với correlation ID, tức mã nối log/event của một request hoặc flow. Ví dụ:

Evidence ledger nên có event_id, timestamp, correlation ID, component/version, observation, source, confidence và next check. Containment là biện pháp chặn impact lan rộng trong khi điều tra: tạm chuyển recommendation sang policy read-only, tắt route bị lỗi, ghim câu trả lời có uncertainty hoặc rollback phiên bản đã biết là ổn. Containment không phải fix; nó mua thời gian và giảm blast radius.

Giữ log có nghĩa là giữ đúng bằng chứng cần thiết, không gom mọi raw text. Redact PII, giữ hash hoặc ID giả, policy/version, route và trạng thái. Nếu log có credential, không copy sang incident note; dừng và chuyển security. Không xóa log chỉ vì nó làm câu chuyện khó đọc. Microsoft mô tả observability cho AI theo hướng nối signal, telemetry, governance và responsible operation; NIST AI RMF cũng đặt govern, map, measure và manage xuyên vòng đời. Microsoft AI observability và NIST AI RMF Core

Hình 3 — Timeline tốt nối signal với version, owner và quyết định containment, không cần lưu raw customer text.

4. Root cause, fix và verification

Root cause không phải câu ngắn như “AI hallucinated”. Hãy viết causal chain có thể kiểm:

1. Policy v2 có effective time mới.
2. Cache refresh job chạy nhưng một region giữ policy v1.
3. Retrieval filter không kiểm effective version trước khi trả source.
4. Prompt chỉ hỏi “đủ điều kiện không?” và không bắt model nêu policy date.
5. UI hiển thị câu trả lời như assertion, không cho staff thấy source.

Mỗi mũi tên cần evidence; nếu thiếu, đánh dấu NOT_VERIFIED. Five whys có ích khi nó tìm điều kiện hệ thống và process, không dùng để ép ra một cá nhân. Root-cause matrix có thể ghi cause, evidence, confidence, fix owner và verification test.

Fix đúng lớp có thể gồm: cache invalidation theo policy version/effective time; retrieval filter từ chối source stale; prompt yêu cầu source/date/uncertainty; evaluator có test policy v1/v2 conflict; UI hiển thị source; alert theo correction rate và cache drift. Không nên sửa duy nhất câu prompt nếu source pipeline vẫn đưa bản cũ.

Verification cần tách focused test và system test. Test giả có case policy mới, cache stale, region khác nhau, missing learner field và source conflict. Canary là phát hành thử cho phạm vi nhỏ trước khi mở rộng. Theo dõi correction, unsupported claim, retrieval version mismatch và escalation trong canary; chỉ mở rộng khi owner ký gate. Nếu signal xấu, rollback đưa hệ thống về phiên bản trước theo runbook. Google nhấn mạnh security foundation production cần identity, observability và response; Azure Well-Architected AI architecture cũng coi reliability, security, operational excellence là các lớp thiết kế. Google AI security foundation và Azure AI architecture patterns

Hình 4 — Fix phải đi cùng test, canary, rollback và postmortem; patch symptom chưa phải đóng incident.

5. Sai lầm, giới hạn và fallback

Các bẫy thường gặp:

• Blame model: kết luận model sai trước khi kiểm source/version. Fallback là taxonomy và evidence ledger.
• Delete inconvenient logs: xóa event làm timeline đẹp hơn. Fallback là bảo toàn, redact và ghi access audit.
• Patch symptom: thêm câu “hãy cẩn thận” vào prompt nhưng giữ retrieval stale. Fallback là sửa lớp gây causal chain.
• False green: dashboard tổng vẫn xanh dù một cohort bị hỏng. Fallback là slice theo route, locale, version và cohort.
• Alert fatigue: cảnh báo quá nhiều nên owner bỏ qua. Fallback là severity, dedupe, threshold có owner và drill định kỳ.
• Privacy leak: incident note dán raw transcript. Fallback là ID giả, redaction và least-necessary evidence.
• Unknown cause denial: không có evidence nhưng vẫn đóng incident. Fallback là giữ NOT_VERIFIED, owner và next check.
• Repeat incident: postmortem chỉ viết narrative, không có regression gate. Fallback là thêm test, monitor và trách nhiệm theo hạn.

Phân tích cũng có giới hạn. Correlation không luôn là causation; metric tăng sau policy change chưa chứng minh policy là root cause. Một log sạch không chứng minh không có failure nếu instrumentation thiếu. Model evaluation offline có thể không bắt được drift production. Nếu data thiếu, hãy nói rõ mức confidence, mở follow-up và tránh hứa rằng một patch đã loại bỏ mọi rủi ro.

6. Practice Bridge 20 phút

Mở notes hoặc Google Sheets miễn phí, tạo incident card với các cột signal, impact, timeline, correlation_id, versions, evidence, containment, root_cause, fix, verification, owner, decision. Đặt timer 20 phút. Dùng recommendation assistant giả và policy v1/v2 giả; không dùng log thật.

Mẫu đối chiếu đã điền

Sau 20 phút, bạn phải nói được impact nào đã chặn, evidence nào xác nhận và evidence nào còn thiếu. Nếu không biết owner hoặc tiêu chí canary, ghi UNKNOWN và dừng. Mục tiêu là học cách xử lý có trách nhiệm, không phải viết postmortem nghe thật chắc chắn.

7. Tổng kết: sự cố là dữ liệu để học

a. Năm ý chính

• “Model sai” chỉ là symptom; failure analysis phải đi qua data, retrieval, prompt, model, tool, policy, UX và monitoring.
• Severity và blast radius giúp chọn owner, containment và mức giao tiếp phù hợp.
• Timeline, correlation ID, version và evidence ledger biến câu chuyện rời rạc thành điều tra có thể kiểm.
• Root cause cần causal evidence; fix phải qua regression, canary, rollback gate và verification.
• Postmortem tốt tạo test, monitor, owner và process mới; không xóa log, đổ lỗi hay hứa reliability tuyệt đối.

b. Câu hỏi tự kiểm tra

• Vì sao một câu trả lời sai chưa đủ để kết luận model là root cause?
• Containment khác fix ở điểm nào?
• Correlation ID và evidence ledger giúp reviewer làm gì?
• Khi cause chưa có evidence, trạng thái nên ghi thế nào?

c. Gợi ý đáp án

Xem gợi ý câu 1

Output sai có thể đến từ data, source stale, prompt, tool, policy, UX hoặc monitoring; cần causal evidence. Xem lại mục 1 và mục 2.

Xem gợi ý câu 2

Containment chặn impact lan rộng trong khi điều tra; fix sửa nguyên nhân và phải được verification. Xem lại mục 3 và mục 4.

Xem gợi ý câu 3

Chúng nối request với version, component, observation, source và owner để tái dựng timeline mà không cần raw transcript. Xem lại mục 3.

Xem gợi ý câu 4

Ghi `NOT_VERIFIED`, owner và next check; không biến giả thuyết thành kết luận. Xem lại mục 4 và mục 5.

d. Thuật ngữ cần nhớ

e. Nguồn tham khảo

• NIST AI RMF Core — govern, map, measure và manage.
• Microsoft AI observability — telemetry, signal, governance và operation.
• Google production AI security foundation — identity, observability và response.
• Azure AI architecture patterns — reliability, security và operational design.

Bài trước là Case Study: Multi-Agent Workflow #17. Bài tiếp theo là AI Requirements và Acceptance Criteria #19.

Để xem trọn Phase 3, mở lại Case Study: Research Agent #13, Case Study: Content Production Agent #14, Case Study: Customer Support Copilot #15 và Case Study: Coding Agent #16, rồi đối chiếu với bài multi-agent ngay trước đó.

Lưu ý giáo dục: Hãy giữ incident card ở dữ liệu giả, redact evidence và tách NOT_VERIFIED khỏi kết luận. Không xóa log, không dùng production token và không đóng incident chỉ vì một dashboard đang xanh.