Mở đầu — vì sao bài này quan trọng
Là một AI Product Manager, bạn sẽ liên tục đối mặt với một câu hỏi tưởng đơn giản nhưng quyết định cả ngân sách, tiến độ và chất lượng sản phẩm: "Để model trả lời tốt hơn cho bài toán của mình, ta nên fine-tune hay chỉ cần làm tốt prompt?"
Đây không phải câu hỏi kỹ thuật thuần túy để giao cho engineer trả lời rồi quên đi. Lựa chọn sai hướng có thể khiến team đốt vài trăm triệu đồng và vài tháng để fine-tune một model, trong khi một prompt được viết khéo léo có thể giải quyết 90% vấn đề chỉ trong một buổi chiều. Ngược lại, có những bài toán mà dù bạn viết prompt giỏi đến đâu cũng chạm trần — và đó là lúc fine-tuning trở thành con đường duy nhất.
Vấn đề là phần lớn PM Việt Nam, vì áp lực "phải dùng AI cho ra dáng nghiêm túc", thường nhảy thẳng vào fine-tuning quá sớm. Họ nghĩ fine-tune nghe "xịn" hơn, "sở hữu model riêng" nghe oai hơn. Kết quả là tốn kém, chậm, và thường thua một giải pháp prompt engineering đơn giản về cả chi phí lẫn tốc độ lặp.
Trong bài này, tôi sẽ giúp bạn nhìn cả hai phương án như một dải quang phổ (spectrum) chứ không phải hai lựa chọn đối lập, và trao cho bạn một khung quyết định để biết khi nào dừng ở prompt, khi nào bước lên few-shot, và khi nào thực sự cần fine-tune. Đây là kỹ năng phân bổ nguồn lực — thứ phân biệt một PM giỏi với một PM chỉ biết gật đầu theo engineer.
Khái niệm cốt lõi
Cách hiểu hữu ích nhất là hình dung một dải tăng dần về mức độ kiểm soát và chi phí. Bạn đi từ trái (rẻ, nhanh, ít kiểm soát) sang phải (đắt, chậm, kiểm soát sâu). Nguyên tắc vàng: luôn bắt đầu từ bên trái nhất có thể, chỉ dịch sang phải khi đã chạm giới hạn thực sự.
Bậc 1 — Prompt engineering (zero-shot)
Đây là điểm xuất phát. Bạn viết hướng dẫn cho model bằng ngôn ngữ tự nhiên, không đưa ví dụ, không thay đổi một dòng code nào về model.
- Zero code change: bạn chỉ sửa văn bản prompt. Không cần training, không cần dữ liệu, không cần GPU.
- Lặp trong giờ, không phải tuần: phát hiện lỗi lúc 9 giờ sáng, sửa prompt, deploy lúc 9 giờ 30. Vòng lặp cải tiến cực nhanh.
- Kiểm soát giới hạn: bạn không thể ép model học một phong cách viết rất đặc thù hay một định dạng cực kỳ nghiêm ngặt chỉ bằng lời. Có một trần chất lượng mà prompt thuần không vượt qua được.
Bậc 2 — Few-shot trong prompt
Khi zero-shot chưa đủ, bạn nhét vài ví dụ mẫu (input → output mong muốn) ngay trong prompt. Model "bắt chước" mẫu đó. Đây vẫn là prompt engineering, vẫn zero code change, nhưng mạnh hơn đáng kể.
- Ví dụ dạy model phong cách: "Khách hỏi X → trả lời theo giọng Y". 3–8 ví dụ tốt thường tạo khác biệt rõ rệt.
- Cái giá phải trả: mỗi ví dụ tiêu tốn token, làm mỗi request đắt hơn và chậm hơn một chút. Nếu bạn cần 30 ví dụ mới đạt chất lượng, đó là tín hiệu nên cân nhắc bước tiếp theo.
Bậc 3 — RAG (đưa kiến thức vào ngữ cảnh)
Khi vấn đề là model thiếu thông tin chứ không phải thiếu kỹ năng, câu trả lời thường là RAG — nạp tài liệu liên quan vào prompt lúc chạy. Bài này không đi sâu RAG (các bài 19–25 lo phần đó), nhưng PM cần nhớ một nguyên tắc cốt lõi: fine-tuning dạy model cách hành xử, RAG dạy model nội dung gì. Nếu khách phàn nàn "AI trả lời sai chính sách công ty", đó là bài toán kiến thức, không phải bài toán fine-tune.
Bậc 4 — Fine-tuning
Đây là khi bạn thực sự cập nhật trọng số (weights) của model bằng dữ liệu của riêng mình. Bạn cần một tập dữ liệu có nhãn — thường hàng trăm đến hàng nghìn cặp input/output chất lượng cao — chạy qua quy trình huấn luyện để model "ngấm" vào trong.
Fine-tuning thật sự tỏa sáng ở mấy việc:
- Áp đặt phong cách/định dạng cực nhất quán: ví dụ luôn xuất đúng cấu trúc JSON đặc thù, luôn dùng đúng tông giọng thương hiệu, kể cả khi prompt ngắn.
- Nén prompt dài: nếu hiện tại bạn phải dùng prompt 2000 token với 20 ví dụ, fine-tune có thể đưa "kiến thức" đó vào weights, giúp prompt lúc chạy ngắn lại, rẻ hơn và nhanh hơn ở quy mô lớn.
- Xử lý tác vụ chuyên biệt hẹp mà prompt mãi không đạt độ chính xác mong muốn.
Khung quyết định nhanh cho PM
Hãy tự hỏi theo thứ tự:
- Đây là vấn đề kiến thức hay hành vi? Thiếu thông tin → RAG. Sai cách cư xử/định dạng → mới tính đến fine-tune.
- Prompt + few-shot đã chạm trần chưa? Nếu chưa thử nghiêm túc, chưa được phép nói tới fine-tune.
- Có đủ dữ liệu chất lượng không? Không có vài trăm mẫu sạch thì fine-tune sẽ thất bại.
- Quy mô có đủ lớn để tiết kiệm chi phí token bù lại chi phí train không? Vài trăm request/ngày thì hiếm khi đáng fine-tune.
Tình huống thực tế
Ví dụ 1 — Chatbot CSKH của một sàn TMĐT tại TP.HCM (prompt thắng)
Một công ty thương mại điện tử nội thất tại TP.HCM muốn chatbot trả lời câu hỏi khách hàng theo đúng giọng thương hiệu: thân thiện, xưng "shop", luôn gợi ý sản phẩm liên quan. Team kỹ thuật đề xuất fine-tune một model để "thuộc" giọng thương hiệu, dự toán khoảng 6 tuần và chi phí gắn nhãn dữ liệu đáng kể.
PM dừng lại và yêu cầu thử prompt engineering trước. Họ viết một system prompt mô tả persona, kèm 5 ví dụ few-shot về cách trả lời mẫu. Trong vòng 3 ngày, chatbot đã đạt giọng văn mà đội marketing chấm 8.5/10. Họ tiết kiệm gần như toàn bộ thời gian và chi phí của phương án fine-tune.
Bài học: Phong cách giọng văn, ở mức "đủ tốt", thường giải quyết được bằng few-shot. Fine-tune chỉ đáng cân nhắc khi bạn cần độ nhất quán tuyệt đối ở hàng triệu request, nơi prompt dài trở thành gánh nặng chi phí token.
Ví dụ 2 — Trích xuất hóa đơn cho một fintech (fine-tuning thắng)
Một startup fintech ở Hà Nội xây sản phẩm tự động đọc hóa đơn và chứng từ tiếng Việt để hạch toán cho doanh nghiệp SME. Họ cần output là JSON cực kỳ chuẩn: đúng tên trường, đúng kiểu dữ liệu, xử lý đúng định dạng số tiền kiểu Việt Nam (dấu chấm phân cách nghìn), tên hàng hóa viết tắt đặc thù theo ngành.
Họ bắt đầu bằng prompt + few-shot, nhồi khoảng 15 ví dụ. Kết quả: độ chính xác trường dữ liệu khoảng 88%, nhưng prompt đã phình to gần 3000 token, mỗi request vừa chậm vừa đắt, và với lượng vài chục nghìn chứng từ mỗi ngày, chi phí token leo thang nhanh. Quan trọng hơn, 12% lỗi định dạng là không chấp nhận được trong nghiệp vụ kế toán.
Họ chuyển sang fine-tune một model nhỏ trên khoảng 2000 cặp chứng từ đã gắn nhãn. Kết quả: độ chính xác trường vượt 96%, prompt lúc chạy rút xuống còn vài trăm token (vì model đã "ngấm" định dạng), nhờ đó chi phí mỗi request giảm mạnh dù họ đã bỏ công train.
Bài học: Khi bạn cần (1) độ chính xác cao trên tác vụ hẹp lặp lại, (2) định dạng đầu ra cực nghiêm ngặt, và (3) chạy ở quy mô lớn khiến token trở thành chi phí lớn — fine-tuning thường thắng cả về chất lượng lẫn chi phí dài hạn.
Ví dụ 3 — Trợ lý tra cứu chính sách nội bộ (chọn nhầm hướng)
Một ngân hàng số tại Việt Nam muốn trợ lý AI trả lời nhân viên về quy trình và chính sách nội bộ. Đội AI hào hứng fine-tune model trên toàn bộ kho tài liệu chính sách, kỳ vọng model "thuộc lòng" mọi quy định.
Sau khi tốn nhiều tuần, họ gặp hai vấn đề. Thứ nhất, model bịa ra (hallucinate) chi tiết chính sách nghe rất thuyết phục nhưng sai. Thứ hai, mỗi khi phòng pháp chế cập nhật một quy định, họ phải train lại toàn bộ — không thể đáp ứng tốc độ thay đổi.
Cuối cùng họ làm lại bằng RAG: lưu tài liệu trong cơ sở dữ liệu, truy xuất đoạn liên quan và nạp vào prompt. Trả lời chính xác hơn, có trích dẫn nguồn, và cập nhật chính sách mới chỉ cần thay tài liệu — không train lại gì cả.
Bài học: Đây là cái bẫy kinh điển. Fine-tuning không phải cách tốt để nhồi kiến thức hay dữ kiện hay thay đổi liên tục. Dữ kiện → RAG. Hành vi/phong cách/định dạng → fine-tune. Nhầm hai cái này là sai lầm tốn kém nhất.
Hướng dẫn từng bước
Khi đứng trước một bài toán cần model "làm tốt hơn", hãy đi theo quy trình sau:
- Phân loại vấn đề trước tiên. Hỏi rõ: model đang thiếu kiến thức hay thiếu kỹ năng/hành vi? Viết câu trả lời ra giấy. Bước này lọc ngay được rất nhiều trường hợp lẽ ra không nên fine-tune.
- Luôn dựng baseline bằng zero-shot prompt. Viết prompt rõ ràng, đo chất lượng trên một tập kiểm thử cố định (ví dụ 50–100 mẫu thực tế). Ghi lại con số. Không có baseline thì mọi so sánh sau này đều vô nghĩa.
- Nâng lên few-shot. Thêm 3–8 ví dụ chất lượng, đo lại trên đúng tập kiểm thử đó. Phần lớn dự án dừng được ở đây. Nếu đã đạt ngưỡng chất lượng kinh doanh yêu cầu — dừng lại, đừng làm thêm.
- Nếu vẫn chưa đạt, chẩn đoán "vì sao". Lỗi do thiếu thông tin → đi hướng RAG. Lỗi do định dạng/phong cách/độ chính xác tác vụ hẹp → mới đặt fine-tuning lên bàn.
- Kiểm tra điều kiện cần của fine-tuning. Bạn có ít nhất vài trăm đến vài nghìn mẫu chất lượng cao không? Quy mô request có đủ lớn để khoản tiết kiệm token bù chi phí train không? Đội ngũ có chịu được vòng lặp chậm hơn không? Thiếu một trong các điều kiện này, hãy quay lại tối ưu prompt.
- Nếu fine-tune, hãy fine-tune trên cái nhỏ và đo ROI. Bắt đầu với model nền nhỏ, tập dữ liệu vừa phải. So sánh thẳng với baseline few-shot tốt nhất của bạn: chênh lệch chất lượng có xứng đáng với chi phí và sự cứng nhắc tăng thêm không?
- Lập kế hoạch bảo trì ngay từ đầu. Ai sẽ train lại khi model nền nâng cấp? Dữ liệu huấn luyện được lưu và version hóa thế nào? PM phải đưa chi phí vòng đời này vào quyết định, không chỉ chi phí lần đầu.
Lỗi thường gặp & mẹo
Lỗi 1 — Fine-tune để nhồi kiến thức. Sai lầm phổ biến nhất. Fine-tuning dạy cách hành xử, không phải biết cái gì. Dữ kiện thay đổi liên tục thuộc về RAG.
Lỗi 2 — Nhảy vào fine-tune mà chưa khai thác hết prompt. Rất nhiều team fine-tune khi prompt của họ thậm chí còn chưa có few-shot tử tế. Hãy bắt buộc bản thân thử nghiêm túc bậc 1 và bậc 2 trước.
Lỗi 3 — Không có tập kiểm thử cố định. Nếu mỗi lần đánh giá lại dùng vài ví dụ ngẫu nhiên theo cảm tính, bạn không bao giờ biết phương án nào thực sự tốt hơn. Cố định bộ test ngay từ đầu.
Lỗi 4 — Bỏ quên chi phí lề (token cost) ở quy mô lớn. Một prompt few-shot 3000 token có vẻ ổn khi demo, nhưng nhân với hàng triệu request mỗi tháng thì khác hẳn. Đôi khi đây mới là lý do chính đáng để fine-tune.
Lỗi 5 — Quên rủi ro lỗi thời. Model nền cải thiện rất nhanh. Một fine-tune hôm nay có thể bị một model nền mới + prompt tốt vượt qua sau vài tháng. Đừng coi fine-tune là tài sản vĩnh viễn.
Mẹo: Hãy diễn đạt quyết định bằng ngôn ngữ kinh doanh khi báo cáo: "Few-shot đạt 88% với chi phí X; fine-tune đạt 96% với chi phí Y và Z tuần bảo trì/năm. Vì nghiệp vụ kế toán cần ≥95%, ta chọn fine-tune." Con số và ngưỡng giúp quyết định thuyết phục, không dựa vào cảm tính "nghe xịn".
Mẹo: Xem prompt engineering và fine-tuning không loại trừ nhau. Sản phẩm trưởng thành thường dùng cả hai: một model fine-tune cho định dạng/phong cách, vẫn nhận prompt động và RAG cho phần kiến thức.
Bài tập thực hành
- Phân loại 5 use case. Lấy 5 tính năng AI bất kỳ (ví dụ: gợi ý tiêu đề bài viết, kiểm duyệt bình luận tiếng Việt, trả lời câu hỏi về sản phẩm, viết mô tả sản phẩm theo giọng thương hiệu, trích xuất thông tin từ CV). Với mỗi cái, ghi rõ: đây là vấn đề kiến thức hay hành vi, và bạn sẽ dừng ở prompt, few-shot, RAG hay fine-tune. Giải thích lý do bằng một câu.
- Xây khung ROI. Cho tình huống fintech ở ví dụ 2, hãy liệt kê tất cả hạng mục chi phí của phương án fine-tune (gắn nhãn dữ liệu, train, bảo trì) và phương án few-shot (token mỗi request × số request/tháng). Ước lượng thô bằng con số giả định và xác định tại quy mô nào thì fine-tune bắt đầu rẻ hơn.
- Viết một "định nghĩa chạm trần". Với một sản phẩm bạn đang hoặc muốn làm, hãy viết ra tiêu chí cụ thể, đo được, để biết khi nào prompt engineering đã "chạm trần" và được phép leo lên fine-tuning. Tiêu chí phải có ngưỡng số rõ ràng (ví dụ: "độ chính xác < 93% sau khi đã thử 8 ví dụ few-shot").
Tóm tắt
- Hãy nhìn fine-tuning và prompt engineering như một dải quang phổ từ rẻ-nhanh-ít kiểm soát đến đắt-chậm-kiểm soát sâu. Luôn bắt đầu từ bên trái nhất.
- Prompt zero-shot → few-shot giải quyết phần lớn use case thương mại, với vòng lặp tính bằng giờ và zero code change.
- Quy tắc vàng: RAG cho kiến thức/dữ kiện, fine-tuning cho hành vi/phong cách/định dạng. Nhầm lẫn hai thứ này là sai lầm tốn kém nhất mà PM mắc phải.
- Fine-tuning xứng đáng khi bạn cần độ nhất quán/định dạng nghiêm ngặt, tác vụ hẹp lặp lại đòi độ chính xác cao, hoặc khi quy mô lớn khiến việc nén prompt dài vào weights tiết kiệm đáng kể chi phí token.
- Điều kiện cần của fine-tune: đủ dữ liệu chất lượng, quy mô đủ lớn, và chấp nhận chi phí bảo trì lẫn rủi ro lỗi thời.
- Là PM, vai trò của bạn là phân bổ nguồn lực đúng chỗ: ép team chứng minh đã khai thác hết prompt trước khi cho phép fine-tune, và luôn diễn đạt quyết định bằng ngưỡng số và ngôn ngữ kinh doanh.