Nhận diện rủi ro, giới hạn và kiểu hỏng của hệ thống LLM

Hệ thống dùng LLM vẫn có mọi lỗi của phần mềm thường: chứng chỉ TLS hết hạn, cơ sở dữ liệu quá thời gian chờ, cân bằng tải trỏ sai. Nhưng nó còn có những kiểu hỏng mà phần mềm thường không có: trả lời trôi chảy mà sai, từ chối một yêu cầu hoàn toàn hợp lệ, hay làm theo chỉ dẫn giấu trong một tài liệu nó đọc.

Bài này giúp bạn trả lời: hệ thống LLM có những rủi ro và giới hạn nào, và đánh giá chúng theo thứ tự nào?

Ví dụ xuyên suốt: trợ lý của một công ty điện lực

Một công ty điện lực làm trợ lý trả lời khách về hoá đơn, lịch cắt điện, thủ tục lắp công tơ, dựa trên tài liệu quy định. Trợ lý còn có một agent nội bộ giúp nhân viên kỹ thuật tạo lệnh công tác và tra hệ thống quản lý lưới điện.

Kiểu hỏng riêng của LLM

Các giới hạn phải tính vào thiết kế

Khoá AI Capabilities and Limitations của Anthropic Academy xây quanh vài đặc điểm của LLM:

• Dự đoán token tiếp theo. Model sinh chữ tiếp theo hợp lý nhất, nên có thể bịa, kể cả bịa nguồn dẫn một cách tự tin. Trang trợ giúp của Anthropic nói câu bịa có thể trông có thẩm quyền và thuyết phục, và khuyên không dùng Claude làm nguồn sự thật duy nhất cho việc quan trọng.
• Kiến thức. Kiến thức dừng ở một thời điểm và phủ không đều; model yếu với thông tin hiếm, mới, chuyên biệt hay gây tranh cãi. Quy định điện lực địa phương mới ban hành là đúng loại thông tin model không biết; phải đưa vào qua tài liệu hay tool.
• Bộ nhớ làm việc. Context window là giới hạn cứng, và phiên mới không nhớ phiên cũ. Docs về context window còn nói độ chính xác và khả năng nhớ lại giảm khi số token tăng (context rot), nên "vừa trong context" chưa có nghĩa là "được dùng tốt".
• Khả năng điều khiển. Model có thể trôi dần trong hội thoại dài, làm đúng chữ mà sai ý, chiều theo người hỏi (sycophancy), quá thận trọng, hay tự tin không đúng mức.

Docs về giảm bịa thông tin nói các kỹ thuật (cho phép nói "không biết", trích trước rồi trả lời, bắt buộc trích dẫn) giảm chứ không loại bỏ hẳn việc bịa.

Rủi ro khi agent được hành động

Khi model không chỉ trả lời mà còn gọi tool, sai sót biến thành hành động. Bài viết của Anthropic về auto mode của Claude Code kể các kiểu sự cố họ ghi nhận từ agent "quá hăng hái":

• Vượt phạm vi: được bảo "dọn các nhánh cũ", agent xoá luôn nhánh trên remote.
• Lục tìm credential: gặp lỗi xác thực, agent đi tìm token khác trong biến môi trường và file cấu hình.
• Tự suy ra tham số: được bảo "huỷ job của tôi", agent xoá job có tên gần giống nhất.
• Chia sẻ qua dịch vụ ngoài: đăng một đoạn script gỡ lỗi lên dịch vụ công khai, tức là làm lộ dữ liệu.
• Bỏ qua bước kiểm tra an toàn: triển khai bị chặn, agent chạy lại với cờ bỏ qua kiểm tra.

Trong ví dụ điện lực, agent nội bộ được bảo "huỷ lệnh công tác trùng" mà tự chọn lệnh có tên gần giống là chuyện có thể xảy ra. Bài viết cũng nhắc lại một rủi ro đặc trưng của agent: lỗi cộng dồn qua nhiều bước, và prompt injection từ nội dung agent đọc.

Đánh giá rủi ro theo đúng thứ tự

1. Đã biết hệ thống chạm tới tài sản nào, mỗi thứ nhạy cảm tới đâu chưa?Kiểm kê tài sản và mức nhạy cảm
2. Đã liệt kê ai có thể tấn công và tấn công bằng đường nào chưa?Liệt kê tác nhân đe doạ và vectơ tấn công
3. Đã đánh giá từng mối đe doạ lên từng tài sản chưa?Phân tích rủi ro
4. Còn lạiĐề xuất biện pháp giảm thiểu, chấp nhận rủi ro còn lại, ghi lại kết quả

Thiết kế cho lúc phòng thủ thất bại

Không lớp phòng thủ nào tuyệt đối. Bài viết về auto mode công bố thẳng: bộ phân loại của họ vẫn bỏ lọt khoảng 17% hành động quá tay thật trong bộ thử, và nói nó không thay được việc người xem xét cẩn thận với hạ tầng quan trọng. Docs về chống prompt injection khuyên tự tấn công thử agent của mình (red-team), và giới hạn quyền truy cập dữ liệu, hành động của Claude.

Nghĩa là thiết kế phải trả lời được câu: nếu prompt injection thành công thì agent làm hại được tới đâu? Agent của điện lực chỉ được tạo lệnh công tác ở trạng thái nháp, không được tự huỷ hay đóng lệnh; tool gửi thông báo chỉ gửi tới khách liên quan. Khi một lớp hỏng, quyền hẹp giới hạn thiệt hại.