Mở đầu — vì sao bài này quan trọng
Kể từ khi ChatGPT bùng nổ cuối năm 2022, có một hội chứng lan rất nhanh trong giới làm sản phẩm ở Việt Nam: cứ nghe đến "AI" là mặc định phải gọi API của một mô hình ngôn ngữ lớn (LLM). Bạn muốn phân loại bình luận khách hàng? Gọi GPT. Bạn muốn dự đoán khách nào sắp rời bỏ dịch vụ? Gọi GPT. Bạn muốn phát hiện giao dịch gian lận? Cũng gọi GPT nốt.
Đây là một cái bẫy tốn kém, và là lý do vì sao rất nhiều "sản phẩm AI" ra mắt hoành tráng rồi âm thầm đóng cửa sau vài tháng vì hoá đơn token quá cao, độ trễ quá lớn, hoặc kết quả không ổn định.
Sự thật là: LLM chỉ là một điểm trên một dải phổ (spectrum) các kỹ thuật AI, chứ không phải là câu trả lời cho mọi bài toán. Một Product Manager hay kỹ sư giỏi về AI không phải người biết dùng LLM, mà là người biết khi nào KHÔNG nên dùng LLM và chọn đúng công cụ cho đúng việc. Bài học này sẽ trang bị cho bạn khung tư duy để đưa ra quyết định đó một cách tỉnh táo, dựa trên bản chất bài toán chứ không theo trào lưu.
Khái niệm cốt lõi
Dải phổ các kỹ thuật AI
Hãy hình dung toàn bộ các kỹ thuật xử lý "thông minh" nằm trên một trục, từ đơn giản đến phức tạp:
Rules-based → Classical ML → Deep Learning → LLM / Foundation Model
(Luật cứng) (ML cổ điển) (Học sâu) (Mô hình nền tảng)
Càng đi sang phải, mô hình càng linh hoạt và mạnh mẽ với dữ liệu phi cấu trúc (văn bản tự do, hình ảnh), nhưng đồng thời càng đắt hơn, chậm hơn, khó kiểm soát hơn và khó giải thích hơn. Điểm mấu chốt cần nhớ: mỗi vị trí trên trục này đều có chỗ đứng của nó. Nhiệm vụ của bạn không phải là "leo lên phía bên phải nhất có thể", mà là dừng lại ở điểm rẻ nhất, nhanh nhất mà vẫn giải quyết được bài toán.
Rules-based (hệ thống luật cứng): Đây là những câu lệnh if-else do con người viết ra. Ví dụ: "Nếu số tiền giao dịch > 50 triệu VND VÀ ở nước ngoài VÀ trong khung 2-4h sáng → gắn cờ nghi vấn". Không có "học" gì ở đây cả, nhưng nó cực nhanh, gần như miễn phí, và minh bạch 100% — bạn luôn giải thích được vì sao hệ thống ra quyết định đó. Với các bài toán mà quy tắc rõ ràng và ít thay đổi, đừng khinh thường luật cứng.
Classical ML (Machine Learning cổ điển): Các thuật toán như Logistic Regression, Random Forest, XGBoost, SVM. Chúng học từ dữ liệu có cấu trúc (bảng số liệu: tuổi, thu nhập, số lần mua hàng, thời gian truy cập...). Rất mạnh cho các bài toán dự đoán và phân loại kinh điển: dự đoán churn (khách rời bỏ), chấm điểm tín dụng, dự báo doanh số, gợi ý sản phẩm. Chúng rẻ để huấn luyện, chạy trong mili-giây, và có thể chạy hàng triệu lần mỗi ngày mà không đau ví.
Deep Learning (học sâu): Các mạng nơ-ron nhiều lớp (CNN cho ảnh, RNN/LSTM cho chuỗi thời gian). Đây là bước nhảy khi dữ liệu là phi cấu trúc và phức tạp: nhận diện khuôn mặt, phân loại ảnh sản phẩm, nhận dạng chữ viết tay (OCR). Cần nhiều dữ liệu và tài nguyên tính toán hơn ML cổ điển, nhưng vẫn là mô hình chuyên biệt — bạn huấn luyện nó cho một nhiệm vụ cụ thể.
LLM / Foundation Model (mô hình ngôn ngữ lớn / mô hình nền tảng): GPT, Claude, Gemini, Llama... Điểm khác biệt căn bản: đây là mô hình đa năng, được huấn luyện trước trên một lượng dữ liệu khổng lồ, và có khả năng làm nhiều việc mà không cần huấn luyện lại — chỉ cần bạn "ra lệnh" bằng ngôn ngữ tự nhiên (prompting). Nó xuất sắc ở các bài toán liên quan đến ngôn ngữ mở, suy luận, tóm tắt, sinh nội dung, hiểu ngữ cảnh mơ hồ.
Ba câu hỏi để định vị bài toán
Khi đứng trước một bài toán, hãy tự hỏi:
- Dữ liệu đầu vào là gì? Có cấu trúc (bảng số) → nghiêng về Classical ML. Phi cấu trúc và là ngôn ngữ tự nhiên → nghiêng về LLM.
- Đầu ra cần gì? Một con số/nhãn cố định (0/1, giá tiền, phân loại) → Classical ML. Một đoạn văn bản linh hoạt, một suy luận, một câu trả lời tuỳ ngữ cảnh → LLM.
- Quy mô và ràng buộc? Cần chạy hàng triệu lần/ngày với chi phí thấp và độ trễ vài mili-giây → tránh xa LLM. Chạy vài nghìn lần/ngày, chấp nhận độ trễ 1-3 giây và chi phí cao hơn → LLM chấp nhận được.
Bảng so sánh nhanh
| Tiêu chí | Classical ML | LLM |
|---|---|---|
| Dữ liệu | Có cấu trúc | Ngôn ngữ tự nhiên, phi cấu trúc |
| Chi phí mỗi lần chạy | Rất thấp (~0đ) | Cao (tính theo token) |
| Độ trễ | Mili-giây | 0.5–5 giây |
| Khả năng giải thích | Cao | Thấp (hộp đen) |
| Cần dữ liệu huấn luyện riêng | Có (nhiều) | Thường không |
| Tính ổn định đầu ra | Cao, xác định | Có thể "sáng tạo" lung tung (hallucination) |
| Thời gian đưa ra MVP | Tuần đến tháng | Ngày |
Tình huống thực tế
Tình huống 1 — Sàn TMĐT phân loại đánh giá sản phẩm (dùng sai, rồi sửa)
Một sàn thương mại điện tử tầm trung tại Việt Nam (gọi là "ShopViet") muốn tự động phân loại đánh giá của khách thành 3 nhãn: tích cực, tiêu cực, trung tính, để đội chăm sóc khách hàng ưu tiên xử lý các đánh giá tiêu cực.
Đội kỹ thuật, vì đang hào hứng với AI, quyết định gọi API GPT-4 cho mỗi đánh giá. Nó chạy được, độ chính xác tốt. Nhưng ShopViet có khoảng 200.000 đánh giá mới mỗi ngày. Với chi phí trung bình khoảng 1.500đ cho mỗi lần gọi (tính cả prompt và đầu ra), hoá đơn lên tới 300 triệu VND/ngày — hoàn toàn phi lý cho một bài toán phân loại đơn giản.
Diễn giải: Đây là bài toán phân loại văn bản (text classification) kinh điển — đầu ra chỉ là 1 trong 3 nhãn cố định. Đội đã dùng "búa tạ đập ruồi". Giải pháp đúng: thu thập vài chục nghìn đánh giá đã được gán nhãn (thậm chí có thể dùng LLM để gán nhãn một lần cho tập huấn luyện này), rồi huấn luyện một mô hình phân loại nhẹ (fine-tune một mô hình như PhoBERT — mô hình tiếng Việt của VinAI — hoặc thậm chí một mô hình Logistic Regression trên đặc trưng TF-IDF). Kết quả: chi phí mỗi lần phân loại gần như bằng 0, độ trễ vài mili-giây, chạy trên server riêng.
Bài học: Khi đầu ra là một nhãn cố định và số lượng dự đoán rất lớn, Classical ML gần như luôn thắng. LLM chỉ nên đóng vai trò công cụ tạo dữ liệu huấn luyện, không phải công cụ chạy production.
Tình huống 2 — Ngân hàng số dự đoán khách rời bỏ (Classical ML là lựa chọn đúng)
Một ngân hàng số (neobank) ở Đông Nam Á muốn dự đoán khách hàng nào có khả năng ngừng dùng thẻ tín dụng trong 3 tháng tới, để chủ động gọi điện giữ chân.
Dữ liệu ở đây hoàn toàn có cấu trúc: số dư trung bình, tần suất giao dịch, số ngày kể từ lần dùng cuối, độ tuổi, thu nhập khai báo, số lần liên hệ tổng đài... Đội dữ liệu huấn luyện một mô hình XGBoost, đạt độ chính xác cao, chạy chấm điểm cho toàn bộ 2 triệu khách hàng mỗi đêm chỉ trong vài phút, với chi phí điện toán không đáng kể.
Diễn giải: Không một ai nghĩ đến chuyện dùng LLM ở đây, và điều đó hoàn toàn đúng đắn. LLM không "nhìn" bảng số liệu tốt bằng XGBoost, không giải thích được feature nào quan trọng (điều mà bộ phận rủi ro và tuân thủ ngân hàng bắt buộc phải có), và đắt hơn hàng nghìn lần.
Bài học: Với dữ liệu bảng (tabular) và yêu cầu giải thích được (explainability) cao — đặc biệt trong tài chính, ngân hàng, bảo hiểm — Classical ML vẫn là vua. Đây không phải công nghệ "lỗi thời", mà là công cụ đúng.
Tình huống 3 — Trợ lý pháp lý cho doanh nghiệp (LLM là lựa chọn đúng)
Một startup legaltech Việt Nam xây dựng công cụ giúp doanh nghiệp SME đọc và tóm tắt hợp đồng: người dùng tải lên một hợp đồng thuê văn phòng 15 trang, hệ thống trả về các điều khoản rủi ro, nghĩa vụ tài chính, và các mốc thời gian quan trọng bằng ngôn ngữ dễ hiểu.
Ở đây, mọi thứ đảo ngược. Đầu vào là văn bản pháp lý tự do, không theo mẫu cố định. Đầu ra là một bản tóm tắt linh hoạt, cần suy luận và diễn đạt lại — mỗi hợp đồng một khác. Không có cách nào dùng Classical ML cho việc này: bạn không thể liệt kê hết mọi kiểu điều khoản, và đầu ra không phải một nhãn cố định. Đây chính xác là sân chơi của LLM. Startup dùng Claude, kết hợp kỹ thuật đưa toàn văn hợp đồng vào ngữ cảnh và yêu cầu trích xuất theo cấu trúc.
Quy mô cũng hợp lý: mỗi doanh nghiệp chỉ xử lý vài hợp đồng mỗi tuần, nên chi phí vài nghìn đồng mỗi lần gọi và độ trễ 3-4 giây là hoàn toàn chấp nhận được — thậm chí người dùng còn cảm thấy "đáng tiền" vì công việc này nếu thuê luật sư sẽ tốn hàng triệu đồng.
Bài học: Khi bài toán là ngôn ngữ mở, cần suy luận, tóm tắt hoặc sinh nội dung, với quy mô vừa phải và người dùng chấp nhận trả tiền cho giá trị cao — LLM là lựa chọn không thể thay thế.
Hướng dẫn từng bước
Đây là quy trình thực dụng để chọn kỹ thuật cho một bài toán mới:
- Mô tả bài toán bằng một câu về đầu vào và đầu ra. "Từ [X] dự đoán/tạo ra [Y]". Nếu bạn không viết ra được câu này rõ ràng, bạn chưa hiểu bài toán đủ để chọn công cụ.
- Phân loại dữ liệu đầu vào. Có cấu trúc (bảng, số) hay phi cấu trúc (văn bản tự do, ảnh)? Đây là yếu tố quyết định lớn nhất, đẩy bạn về phía trái hay phải của dải phổ.
- Phân loại đầu ra. Cố định (nhãn, số) hay linh hoạt (văn bản, suy luận)? Đầu ra cố định thường không cần đến LLM.
- Kiểm tra xem luật cứng có đủ không. Trước khi chạm vào ML, hãy tự hỏi: liệu 10-20 câu if-else có giải quyết được 80% trường hợp không? Nếu có, hãy bắt đầu từ đó. Đơn giản là một tính năng, không phải khuyết điểm.
- Ước lượng quy mô và ràng buộc. Số lần chạy mỗi ngày? Ngân sách chi phí? Độ trễ tối đa người dùng chịu được? Có yêu cầu giải thích được (compliance) không? Những con số này thường loại bỏ LLM khỏi bàn cân ngay lập tức nếu quy mô quá lớn.
- Chọn điểm rẻ nhất trên dải phổ vẫn giải quyết được bài toán. Nguyên tắc vàng: đừng dùng công cụ mạnh hơn mức cần thiết.
- Cân nhắc chiến lược lai (hybrid). Trong thực tế, các sản phẩm tốt thường kết hợp: luật cứng lọc trước → Classical ML xử lý phần lớn → LLM chỉ can thiệp ở các trường hợp khó, mơ hồ. Ví dụ hệ thống kiểm duyệt nội dung: luật cứng chặn từ khoá cấm rõ ràng, ML phân loại phần lớn, LLM chỉ xử lý các ca ranh giới cần hiểu ngữ cảnh.
- Với LLM, luôn bắt đầu bằng prototype nhanh để validate ý tưởng, rồi mới tính đến chuyện tối ưu chi phí hoặc thay bằng mô hình chuyên biệt khi quy mô tăng.
Lỗi thường gặp & mẹo
Lỗi 1 — "AI là phải LLM". Đây là lỗi phổ biến nhất và tốn kém nhất. LLM chỉ là một phần của AI. Rất nhiều bài toán được giải tốt hơn, rẻ hơn bằng ML cổ điển hoặc thậm chí luật cứng.
Lỗi 2 — Bỏ qua chi phí và độ trễ khi quy mô lớn. Một prototype LLM chạy ngon với 100 người dùng có thể phá sản khi lên 100.000 người dùng. Luôn nhân thử chi phí mỗi lần gọi với số lần gọi dự kiến mỗi ngày trước khi cam kết kiến trúc.
Lỗi 3 — Dùng LLM cho bài toán cần độ chính xác xác định. Nếu bạn cần đầu ra luôn nhất quán và không bao giờ "bịa" (ví dụ tính toán tài chính, quy tắc tuân thủ), LLM là lựa chọn rủi ro vì hiện tượng hallucination. Dùng luật cứng hoặc mã tính toán truyền thống.
Lỗi 4 — Bỏ qua yêu cầu giải thích được. Trong ngân hàng, y tế, bảo hiểm ở Việt Nam, cơ quan quản lý có thể yêu cầu bạn giải thích vì sao hệ thống ra quyết định. LLM là hộp đen — khó thoả mãn yêu cầu này. Classical ML với các kỹ thuật như SHAP dễ giải thích hơn nhiều.
Mẹo 1 — Dùng LLM làm "máy tạo dữ liệu". Bạn có thể dùng LLM để gán nhãn nhanh một tập dữ liệu huấn luyện, rồi dùng tập đó huấn luyện một mô hình nhỏ chạy production. Đây là cách kết hợp sức mạnh của cả hai thế giới.
Mẹo 2 — Ưu tiên mô hình tiếng Việt chuyên biệt cho tác vụ tiếng Việt quy mô lớn. Với phân loại/trích xuất văn bản tiếng Việt số lượng lớn, PhoBERT (VinAI) hoặc các mô hình encoder nhẹ thường cho tỷ lệ chi phí/hiệu quả tốt hơn nhiều so với gọi LLM đám mây.
Mẹo 3 — Đừng quyết định một lần rồi thôi. Lựa chọn công cụ nên được xem lại khi quy mô, ngân sách hoặc yêu cầu thay đổi. Bắt đầu bằng LLM để nhanh, chuyển sang ML chuyên biệt khi cần rẻ và nhanh ở quy mô lớn.
Bài tập thực hành
Với mỗi bài toán dưới đây, hãy: (a) xác định dữ liệu đầu vào và đầu ra, (b) chọn một điểm trên dải phổ (luật cứng / Classical ML / Deep Learning / LLM) và (c) viết 2-3 câu lý giải, có cân nhắc chi phí, độ trễ, quy mô và khả năng giải thích.
- Một ứng dụng gọi xe muốn tự động phát hiện các cuốc xe có nguy cơ gian lận (tài xế và khách thông đồng tạo cuốc ảo). Có sẵn dữ liệu: quãng đường, thời gian, lịch sử tài xế/khách, phương thức thanh toán. Chạy cho hàng triệu cuốc mỗi ngày.
- Một trang tin tức muốn tự động viết đoạn tóm tắt 3 câu cho mỗi bài báo dài, đăng khoảng 200 bài/ngày.
- Một chuỗi bán lẻ muốn chatbot trả lời câu hỏi tự do của khách về chính sách đổi trả, bảo hành, khuyến mãi — câu hỏi diễn đạt đủ kiểu khác nhau.
- Một hệ thống chấm điểm tín dụng cho công ty tài chính tiêu dùng, cần giải thích rõ với cơ quan quản lý vì sao một hồ sơ bị từ chối.
- Một ứng dụng chỉnh sửa ảnh muốn tự động nhận diện và xoá nền cho ảnh sản phẩm người dùng tải lên.
Tóm tắt
- AI không đồng nghĩa với LLM. LLM chỉ là một điểm trên dải phổ: Rules-based → Classical ML → Deep Learning → LLM. Càng sang phải càng mạnh nhưng càng đắt, chậm và khó kiểm soát.
- Ba câu hỏi định vị bài toán: dữ liệu đầu vào (có cấu trúc hay ngôn ngữ tự do?), đầu ra (nhãn cố định hay văn bản linh hoạt?), và ràng buộc quy mô (số lần chạy, chi phí, độ trễ, yêu cầu giải thích).
- Classical ML thắng ở: dữ liệu bảng, quy mô lớn, chi phí thấp, cần giải thích được (tài chính, ngân hàng). LLM thắng ở: ngôn ngữ mở, suy luận, tóm tắt, sinh nội dung, quy mô vừa phải, time-to-market nhanh.
- Nguyên tắc vàng: chọn điểm rẻ nhất trên dải phổ vẫn giải quyết được bài toán. Đừng dùng búa tạ đập ruồi.
- Chiến lược lai (luật cứng + ML + LLM) và mẹo dùng LLM để tạo dữ liệu huấn luyện cho mô hình nhỏ là những kỹ thuật thực dụng giúp cân bằng chất lượng và chi phí.