Khi nào KHÔNG nên dùng LLM: 7 tình huống và 5 cổng kiểm

Bạn đang cân nhắc gắn một LLM vào luồng nghiệp vụ nào đó. Trước khi viết prompt đầu tiên, câu hỏi cần trả lời là: bài toán này cần hiểu và sinh ngôn ngữ linh hoạt, hay chỉ cần thực thi logic nghiệp vụ đã biết?

Một bài phân tích kiến trúc vừa đăng đưa ra bảy tình huống nên dừng lại, năm cổng kiểm trước khi duyệt, và một cách tính chi phí ít người làm.

Bảy tình huống không nên dùng LLM

• Output phải chính xác về số học. Đối soát tài chính, tính thuế, số dư tồn kho và giá theo hợp đồng nên dựa vào thuật toán đã được kiểm chứng và kiểu số phù hợp. LLM có thể hiểu yêu cầu, nhưng phép tính phải giữ tính tất định.
• Luồng chạy theo luật rõ ràng. Chính sách hoàn tiền với thời hạn, danh mục loại trừ và ngưỡng phê duyệt nên là rules engine hoặc state machine, không phải prompt.
• Độ trễ bị siết chặt. Vòng điều khiển công nghiệp, xử lý gói mạng tầng thấp, giao dịch tần suất cao và điều khiển thiết bị an toàn không chịu được độ trễ cộng dồn của inference và tool call.
• Câu trả lời đã nằm trong dữ liệu có cấu trúc. Nếu con số doanh thu đã có trong database, hãy query nó. LLM chỉ nên dịch câu hỏi thành truy vấn có ràng buộc, còn phân quyền và tổng hợp giữ ở tầng ứng dụng.
• Dữ liệu nhạy cảm không xử lý được dưới kiến trúc đang đề xuất. Bài viết dẫn OWASP xếp prompt injection và rò rỉ thông tin nhạy cảm vào nhóm rủi ro quan trọng của ứng dụng LLM.
• Có model chuyên dụng làm tốt hơn. Phát hiện gian lận, dự báo nhu cầu, phân loại lỗi sản phẩm, phát hiện bất thường và bảo trì dự đoán thường hợp với phương pháp thống kê hoặc ML chuyên biệt hơn.
• Bạn chưa đánh giá được model đúng hay sai. Chưa có test case đại diện, chưa định nghĩa kết quả không chấp nhận được và chưa có cơ chế review thì đừng cho chạy tự động trong production.

Năm cổng kiểm trước khi duyệt

Tác giả ghi rõ đây là một phương pháp kỹ thuật đề xuất, không phải chuẩn đã được kiểm định bên ngoài — đọc như checklist nội bộ thì hợp lý hơn.

1. Bài toán có thật sự cần trí tuệ ngôn ngữ không? Nếu không, bắt đầu bằng phần mềm tất định.
2. Một giải pháp đơn giản hơn có đạt yêu cầu không? Benchmark rules, search, API hoặc ML chuyên biệt — đừng chỉ so LLM với việc không làm gì.
3. Hệ thống chịu được hành vi xác suất không? Định nghĩa trước cách phát hiện và xử lý kết quả sai, thiếu hoặc không nhất quán.
4. LLM có đáp ứng ràng buộc vận hành không? Đo độ trễ, throughput, chi phí, khả dụng, riêng tư và bảo mật dưới tải thực tế.
5. Phần năng lực tăng thêm có xứng với độ phức tạp tăng thêm không?

Tính chi phí theo tác vụ thành công, không theo mỗi lượt gọi

Công thức bài viết đưa ra: tổng chi phí sở hữu bằng phát triển cộng hạ tầng cộng inference cộng đánh giá cộng giám sát cộng bảo trì cộng xử lý ngoại lệ. Chi phí mỗi tác vụ thành công bằng tổng chi phí vận hành chia cho số tác vụ hoàn thành.

Kịch bản minh hoạ của tác giả — họ ghi rõ đây là ví dụ giả định, không phải giá nhà cung cấp quan sát được — lấy một triệu request mỗi tháng: dịch vụ tất định tốn $0,001 mỗi lượt và dịch vụ dùng LLM tốn $0,02, thành $1.000 so với $20.000 chi phí xử lý trực tiếp. Với tỉ lệ thành công 99,9% so với 97%, chi phí mỗi tác vụ thành công rơi vào khoảng $0,001 so với $0,0206.

Việc làm được ngay hôm nay: lấy một luồng bạn đang định gắn LLM vào, tách nó thành từng bước như bài viết tách xử lý hoá đơn — trích xuất, kiểm tra trường dữ liệu, tính thuế, đối chiếu đơn mua, phát hiện sai lệch, phê duyệt — rồi hỏi riêng từng bước xem nó cần ngôn ngữ linh hoạt hay chỉ cần logic đã biết.