Khi một mô hình Machine Learning hoặc ứng dụng LLM hoạt động chưa tốt, phản xạ quen thuộc thường là thử mô hình lớn hơn, thêm dữ liệu hoặc chỉnh tham số. Nhưng trong thực tế, cách làm hiệu quả hơn nhiều là phân tích lỗi có hệ thống để hiểu mô hình đang sai ở đâu và vì sao sai. Một báo cáo accuracy hay F1 chỉ cho bạn biết kết quả tổng thể. Nó không nói rõ mô hình hay nhầm ở nhóm câu hỏi nào, với kiểu dữ liệu nào, hay trong tình huống nào người dùng thấy khó chịu nhất. Nếu không mổ xẻ lỗi, bạn rất dễ tối ưu nhầm chỗ: sửa một vấn đề nhỏ nhưng bỏ sót nguyên nhân chính. Một quy trình phân tích lỗi đơn giản nhưng rất hữu ích có thể gồm 4 bước: 1. Thu thập mẫu sai điển hình Đừng chỉ nhìn vài ví dụ ngẫu nhiên. Hãy gom các trường hợp mô hình dự đoán sai, trả lời mơ hồ, hoặc có kết quả gây rủi ro cho sản phẩm. 2. Nhóm lỗi theo nguyên nhân Ví dụ với hệ thống phân loại văn bản, lỗi có thể đến từ: câu quá dài, từ viết tắt, dữ liệu thiếu ngữ cảnh, nhãn mơ hồ, hoặc hai lớp rất giống nhau. Với ứng dụng LLM, lỗi thường là: hiểu sai yêu cầu, bịa thông tin, bỏ sót điều kiện, hoặc phản hồi đúng ý nhưng sai định dạng. 3. Gắn lỗi với dữ liệu và quy trình Nhiều vấn đề không nằm ở mô hình mà nằm ở dữ liệu. Có thể tập huấn luyện thiếu ví dụ hiếm, nhãn không nhất quán, hoặc dữ liệu đầu vào ở production khác xa dữ liệu huấn luyện. Với LLM, đôi khi prompt quá dài, thứ tự thông tin chưa hợp lý, hoặc hệ thống truy xuất tài liệu trả về nội dung nhiễu. 4. Ưu tiên sửa theo tác động Không phải lỗi nào cũng đáng sửa ngay. Hãy ưu tiên theo mức độ ảnh hưởng đến người dùng, tần suất xảy ra và độ khó khắc phục. Một lỗi hiếm nhưng gây hậu quả lớn thường đáng xử lý hơn một lỗi phổ biến nhưng ít nghiêm trọng. Ví dụ thực tế: nếu một mô hình phân loại ticket hỗ trợ khách hàng thường nhầm giữa “khiếu nại thanh toán” và “yêu cầu hoàn tiền”, giải pháp tốt không phải lúc nào cũng là đổi thuật toán. Có thể chỉ cần bổ sung bộ dữ liệu phân biệt hai lớp này, chuẩn hóa định nghĩa nhãn, hoặc thêm vài đặc trưng ngữ cảnh như lịch sử giao dịch. Với LLM, phân tích lỗi còn giúp bạn quyết định nên sửa ở đâu trong chuỗi xử lý: prompt, retrieval, post-processing hay guardrail. Nhiều đội ngũ tiết kiệm rất nhiều thời gian vì phát hiện ra rằng mô hình không hề “ngu”, mà chỉ đang nhận đầu vào chưa đủ rõ. Lời khuyên thực dụng: mỗi khi cải tiến mô hình, hãy dành ít nhất một phần thời gian cho việc đọc lỗi thật thay vì chỉ nhìn chỉ số tổng hợp. Một danh sách lỗi được phân loại tốt thường có giá trị hơn nhiều so với vài điểm phần trăm tăng trên benchmark. Nếu muốn làm bài bản hơn, hãy duy trì một “error log” ngắn gọn gồm: mẫu đầu vào, dự đoán, kết quả đúng/sai, nhóm nguyên nhân, và hướng xử lý đề xuất. Sau vài vòng, bạn sẽ thấy mô hình tiến bộ không chỉ vì nó mạnh hơn, mà vì cả hệ thống xung quanh nó đã được hiểu rõ hơn.