Menu
ESC

Nhập từ khóa để tìm kiếm

↑↓ Di chuyển
Enter Mở
ESC Đóng

Đang tải...

Bài 35 — Few-shot vs Fine-tune — Khi nào dùng cái nào

Prompt Engineering for Business Bài 35/60

Mở đầu — vì sao bài này quan trọng

Đến bài này, bạn đã nắm rất nhiều kỹ thuật viết prompt: từ zero-shot, few-shot, chain-of-thought cho đến structured output. Nhưng có một câu hỏi lớn mà gần như mọi doanh nghiệp đều va phải khi triển khai AI thật vào công việc: "Khi nào tôi chỉ cần viết prompt cho khéo, và khi nào tôi thật sự phải bỏ tiền, bỏ dữ liệu ra để fine-tune (tinh chỉnh) một mô hình riêng?"

Đây không phải câu hỏi kỹ thuật thuần túy. Nó là câu hỏi chiến lược và tài chính. Chọn sai hướng, bạn có thể lãng phí hàng chục triệu đồng và ba tháng công sức để fine-tune một mô hình, trong khi một prompt few-shot viết trong 30 phút đã giải quyết được 90% vấn đề. Ngược lại, cố nhồi nhét mọi thứ vào prompt trong khi bài toán thật sự cần fine-tune sẽ khiến bạn trả tiền token đắt đỏ mỗi request mà kết quả vẫn không ổn định.

Bài này giúp bạn có một khung tư duy rõ ràng để đứng trước bất kỳ bài toán nào cũng biết mình đang ở đâu trên "phổ tùy biến" (spectrum of customization), và ra quyết định tự tin: dùng few-shot trong prompt, hay đầu tư fine-tune, hay kết hợp cả hai.

Khái niệm cốt lõi

Phổ tùy biến (Spectrum of customization)

Điều đầu tiên cần gỡ bỏ là suy nghĩ nhị phân "few-shot hay fine-tune". Thực tế đây không phải hai lựa chọn đối lập, mà là các điểm trên một phổ liên tục, đi từ ít can thiệp đến nhiều can thiệp:

Off-the-shelf (zero-shot)     ← Dùng model sẵn có, chỉ ra lệnh
      ↓
Few-shot trong prompt          ← Đưa vài ví dụ mẫu vào prompt
      ↓
System prompt + tools          ← Định hình persona, cho phép gọi công cụ
      ↓
RAG (retrieval)                ← Nạp kiến thức riêng từ tài liệu vào context
      ↓
Fine-tune                      ← Huấn luyện lại trọng số của model trên dữ liệu riêng

Nguyên tắc vàng: luôn đi từ trên xuống, dừng lại ngay khi đạt chất lượng chấp nhận được. Bạn chỉ leo xuống bậc tốn kém hơn khi bậc phía trên thật sự không đủ. Fine-tune nằm ở đáy vì nó đắt nhất về mọi mặt: dữ liệu, thời gian, tiền bạc và công bảo trì.

Few-shot là gì và mạnh ở đâu

Few-shot (đã học kỹ ở Bài 6) là kỹ thuật đưa vài ví dụ đầu vào–đầu ra mẫu ngay trong prompt để "dạy" model cách bạn muốn nó hành xử, ngay tại thời điểm chạy (in-context learning). Model không thay đổi gì về bản thân — nó chỉ bắt chước mẫu bạn đưa.

Sức mạnh của few-shot:

  • Không cần dữ liệu lớn: 3–10 ví dụ tốt thường là đủ.
  • Lặp lại tức thì: Sửa prompt, chạy lại, thấy kết quả trong vài giây. Không có vòng lặp huấn luyện.
  • Không tốn chi phí huấn luyện: Bạn chỉ trả tiền token khi chạy.
  • Linh hoạt: Đổi định dạng, đổi giọng văn, đổi quy tắc chỉ bằng cách sửa vài dòng.
Điểm yếu:
  • Tốn token mỗi request: Ví dụ mẫu phải nằm trong prompt mỗi lần gọi, nên request nào cũng cõng thêm chi phí và độ trễ.
  • Giới hạn context window: Không thể nhồi 500 ví dụ vào prompt (Bài 12 đã bàn về token economy).
  • Khó với tri thức chuyên sâu, ngầm: Nếu tác vụ cần "cảm nhận" tinh tế mà khó diễn đạt thành vài ví dụ, few-shot đuối.

Fine-tune là gì và mạnh ở đâu

Fine-tune là quá trình huấn luyện tiếp một mô hình nền (base model) trên tập dữ liệu riêng của bạn — thường là hàng trăm đến hàng nghìn cặp ví dụ đầu vào–đầu ra chất lượng cao. Kết quả là một phiên bản model đã "thấm" phong cách và tri thức của bạn vào chính trọng số của nó.

Sức mạnh của fine-tune:

  • Nhất quán cao: Model đã học sâu một hành vi cụ thể, ít bị lệch.
  • Prompt gọn, chi phí token thấp mỗi request: Vì hành vi đã nằm trong model, bạn không cần đưa cả tá ví dụ vào mỗi prompt nữa. Ở quy mô hàng triệu request, khoản tiết kiệm token này rất lớn.
  • Xử lý được sắc thái khó diễn đạt: Giọng thương hiệu riêng, cách phân loại đặc thù ngành, định dạng phức tạp mà chỉ vài ví dụ không truyền tải nổi.
  • Độ trễ thấp hơn: Prompt ngắn nghĩa là phản hồi nhanh hơn.
Điểm yếu:
  • Tốn dữ liệu: Cần vài trăm đến vài nghìn ví dụ sạch, gắn nhãn cẩn thận — đây thường là rào cản lớn nhất.
  • Tốn thời gian và tiền: Chuẩn bị dữ liệu, chạy huấn luyện, đánh giá — tính bằng tuần, không phải phút.
  • Cứng nhắc khi thay đổi: Muốn đổi hành vi phải huấn luyện lại. Không sửa nhanh như prompt.
  • Không dạy được tri thức mới liên tục cập nhật: Fine-tune giỏi dạy phong cách và định dạng, dở dạy sự thật thay đổi hàng ngày (giá cả, tồn kho, tin tức) — phần đó là việc của RAG.

Điểm mấu chốt: Fine-tune dạy "cách", RAG dạy "cái gì"

Đây là hiểu lầm phổ biến nhất mà tôi muốn bạn khắc cốt ghi tâm. Nhiều người nghĩ fine-tune để "nhồi kiến thức công ty vào model". Sai. Fine-tune tối ưu cho việc dạy model hành xử thế nào (giọng văn, định dạng, cách phân loại). Còn khi bạn cần model biết thông tin gì — chính sách bảo hành mới nhất, danh mục sản phẩm hôm nay — thì RAG (Bài 25) mới là công cụ đúng. Nhầm hai thứ này là nguyên nhân số một khiến các dự án fine-tune thất bại.

Tình huống thực tế

Tình huống 1 — Tiki: phân loại ticket chăm sóc khách hàng

Giả định một đội vận hành như của sàn thương mại điện tử Tiki cần tự động phân loại 8.000 ticket khách hàng mỗi ngày vào 12 nhóm: "đổi trả", "giao hàng chậm", "sai sản phẩm", "hoàn tiền"...

Đội bắt đầu với few-shot: đưa 12 ví dụ mẫu (mỗi nhóm một ví dụ) vào prompt. Kết quả độ chính xác đạt khoảng 88%. Với 8.000 request/ngày và mỗi prompt cõng thêm ~600 token ví dụ, họ tính ra phần token "thừa" chỉ để chứa ví dụ tốn khoảng 4,8 triệu token/ngày — một con số đáng kể khi nhân lên cả tháng.

Vì đây là tác vụ khối lượng cực lớn, ổn định, hành vi lặp đi lặp lại, đội quyết định fine-tune. Họ tận dụng chính lịch sử ticket đã được nhân viên gắn nhãn sẵn — 6.000 ví dụ sạch — để huấn luyện. Sau fine-tune, prompt rút xuống chỉ còn một câu lệnh ngắn (không cần ví dụ), độ chính xác lên 94%, và chi phí token mỗi request giảm mạnh nhờ prompt ngắn.

Bài học: Khi khối lượng lớn, tác vụ ổn định, và bạn đã sẵn dữ liệu gắn nhãn, fine-tune trả lại khoản đầu tư rất nhanh. Nhưng lưu ý — họ chỉ chuyển sang fine-tune sau khi few-shot đã chứng minh bài toán khả thi và cho họ một baseline để so sánh.

Tình huống 2 — Startup fintech Momo-style: tư vấn tài chính cá nhân

Một startup fintech (kiểu ví điện tử) muốn xây trợ lý gợi ý sản phẩm tài chính. Ban đầu đội kỹ thuật hào hứng đòi fine-tune ngay "cho chuyên nghiệp". May mắn là trưởng nhóm AI đã kéo họ lại.

Vấn đề: sản phẩm tài chính, lãi suất, điều kiện khuyến mãi thay đổi mỗi tuần. Nếu fine-tune, mỗi lần đổi lãi suất lại phải huấn luyện lại — bất khả thi. Đây là bài toán về tri thức luôn thay đổi, không phải về phong cách.

Giải pháp đúng là RAG kết hợp system prompt + few-shot nhẹ: nạp bảng sản phẩm và lãi suất mới nhất từ cơ sở dữ liệu vào context tại thời điểm hỏi, dùng system prompt để định hình vai trò "chuyên viên tư vấn thận trọng, luôn kèm cảnh báo rủi ro", và vài ví dụ few-shot để chuẩn hóa cách trình bày. Không cần fine-tune một dòng nào.

Bài học: Nếu tri thức thay đổi thường xuyên, fine-tune là cái bẫy. Hãy leo xuống nhánh RAG chứ đừng nhảy xuống đáy fine-tune. Câu hỏi cần tự hỏi: "Cái tôi thiếu là cách hành xử hay thông tin cập nhật?"

Tình huống 3 — Agency marketing: giọng thương hiệu riêng cho 40 khách hàng

Một agency nội dung ở TP.HCM viết bài cho 40 nhãn hàng, mỗi nhãn một giọng văn riêng. Với vài khách quan trọng có khối lượng bài lớn và giọng rất đặc thù (một nhãn mỹ phẩm cao cấp cần giọng "sang, tối giản, không dùng từ cường điệu"), few-shot mãi không ổn định — thỉnh thoảng AI vẫn "lỡ tay" viết quá màu mè.

Với 3 khách hàng lớn nhất này, họ fine-tune riêng mỗi khách một model, dùng 300–500 bài đã được biên tập viên duyệt làm dữ liệu. Kết quả: giọng văn nhất quán hẳn, biên tập viên tiết kiệm được phần lớn thời gian sửa. Còn 37 khách hàng nhỏ hơn, họ vẫn dùng few-shot vì khối lượng không đủ lớn để bõ công fine-tune.

Bài học: Quyết định không nhất thiết áp cho toàn bộ. Bạn có thể fine-tune cho những "case" khối lượng cao, sắc thái khó, và giữ few-shot cho phần đuôi dài (long tail). Ngưỡng kinh nghiệm: nếu bạn không gom nổi ~200 ví dụ chất lượng, gần như chắc chắn chưa đến lúc fine-tune.

Hướng dẫn từng bước

Đây là quy trình ra quyết định tôi khuyên bạn áp dụng cho mọi bài toán:

Bước 1 — Luôn bắt đầu bằng zero-shot rồi few-shot. Đừng bao giờ khởi động dự án bằng fine-tune. Viết prompt few-shot, đo chất lượng. Đây vừa là giải pháp có thể đủ luôn, vừa là baseline để so sánh về sau.

Bước 2 — Đặt câu hỏi: cái tôi thiếu là "cách" hay "cái gì"? Nếu model thiếu thông tin (dữ liệu riêng, luôn cập nhật) → hướng RAG. Nếu model thiếu hành vi/phong cách/định dạng nhất quán → cân nhắc nhánh fine-tune. Đừng bao giờ fine-tune để nạp tri thức thay đổi.

Bước 3 — Kiểm tra ba điều kiện cần của fine-tune. Chỉ đi tiếp nếu cả ba đều đúng:

  • Few-shot đã chạm trần chất lượng mà vẫn chưa đủ tốt.
  • Bạn có (hoặc gom được) ít nhất vài trăm ví dụ sạch, đại diện.
  • Khối lượng request đủ lớn hoặc yêu cầu nhất quán/độ trễ đủ cao để việc đầu tư đáng giá.
Bước 4 — Chuẩn bị dữ liệu như một tài sản. Nếu quyết fine-tune, dồn công vào chất lượng dữ liệu, không phải số lượng. 300 ví dụ sạch, đa dạng, đúng thắng 3.000 ví dụ lộn xộn. Loại bỏ ví dụ mâu thuẫn nhau — chúng "đầu độc" model.

Bước 5 — Fine-tune, rồi đánh giá bằng chính baseline few-shot. So sánh model fine-tune với prompt few-shot cũ trên cùng một bộ test. Nếu không hơn rõ rệt, dừng lại — bạn vừa tiết kiệm được chi phí bảo trì dài hạn.

Bước 6 — Kết hợp khi cần. Thực tế nhiều hệ thống production tốt nhất là fine-tune (cho phong cách) + RAG (cho tri thức) + một prompt gọn. Đừng nghĩ phải chọn đúng một cái.

Lỗi thường gặp & mẹo

Lỗi 1 — Nhảy thẳng vào fine-tune vì nghe "xịn". Đây là lỗi đắt tiền nhất. Fine-tune nghe chuyên nghiệp nhưng 80% bài toán doanh nghiệp giải được bằng few-shot hoặc RAG. Luôn thử bậc rẻ trước.

Lỗi 2 — Fine-tune để dạy kiến thức thay đổi. Nhồi giá cả, tồn kho, chính sách vào model qua fine-tune. Ngày mai giá đổi, model vẫn nói giá cũ và bạn không thể sửa nhanh. Đây là việc của RAG.

Lỗi 3 — Fine-tune trên dữ liệu bẩn. Model học đúng những gì bạn dạy, kể cả lỗi. Vài chục ví dụ mâu thuẫn đủ làm hỏng cả model. Chất lượng dữ liệu quan trọng hơn thuật toán.

Lỗi 4 — Không có baseline. Fine-tune xong mà không biết few-shot làm được đến đâu thì không thể chứng minh khoản đầu tư có đáng hay không.

Lỗi 5 — Quên chi phí bảo trì. Prompt sửa trong vài phút. Model fine-tune muốn đổi hành vi phải huấn luyện lại — đây là gánh nặng dài hạn ít người tính đến.

Mẹo hữu ích:

  • Dùng few-shot làm "phòng thí nghiệm": khi few-shot đã cho kết quả ổn định, chính những ví dụ và output đó là nguyên liệu tuyệt vời để sau này build tập dữ liệu fine-tune.
  • Đo bằng tiền thật: tính chi phí token của few-shot ở quy mô thật rồi so với chi phí một lần fine-tune. Ở khối lượng thấp, few-shot gần như luôn rẻ hơn.
  • Ước lượng nhanh ngưỡng: dưới ~200 ví dụ chất lượng thì chưa nên fine-tune; dưới vài nghìn request/ngày thì tiết kiệm token từ fine-tune thường chưa bù nổi công sức.

Bài tập thực hành

  • Định vị trên phổ. Lấy ba tác vụ trong công việc bạn muốn tự động bằng AI. Với mỗi tác vụ, xác định nó nên nằm ở bậc nào: zero-shot, few-shot, system prompt + tools, RAG, hay fine-tune. Viết một câu lý do cho mỗi lựa chọn.
  • Phân biệt "cách" và "cái gì". Với một tác vụ trong công ty bạn, liệt kê rạch ròi: phần nào là phong cách/định dạng (ứng viên của fine-tune) và phần nào là tri thức thay đổi (ứng viên của RAG). Bạn sẽ ngạc nhiên khi thấy nhiều bài toán tưởng cần fine-tune thực ra chỉ cần RAG.
  • Tính bài toán tiền. Chọn một tác vụ có khối lượng lớn. Ước lượng: (a) số token dôi ra do ví dụ few-shot mỗi request, (b) tổng số request/tháng, (c) chi phí token dôi ra hàng tháng. So sánh thô với công sức fine-tune một lần. Kết luận: fine-tune có đáng không?
  • Kiểm tra điều kiện cần. Với một tác vụ bạn muốn fine-tune, chấm ba điều kiện cần ở Bước 3. Nếu thiếu bất kỳ điều kiện nào, viết ra kế hoạch để đạt được nó (ví dụ: cách gom 200 ví dụ sạch) hoặc kết luận nên ở lại few-shot.

Tóm tắt

  • Few-shot và fine-tune không phải hai lựa chọn đối lập, mà là hai điểm trên phổ tùy biến: zero-shot → few-shot → system prompt + tools → RAG → fine-tune. Luôn đi từ trên xuống và dừng ngay khi đủ tốt.
  • Few-shot thắng khi: khối lượng nhỏ đến vừa, tri thức hay thay đổi, cần lặp nhanh, chưa có nhiều dữ liệu. Rẻ, linh hoạt, tức thì — nhưng tốn token mỗi request.
  • Fine-tune thắng khi: khối lượng lớn và ổn định, cần nhất quán cao, sắc thái khó diễn đạt bằng vài ví dụ, và bạn đã có vài trăm ví dụ sạch. Nhất quán, prompt gọn, token rẻ mỗi request — nhưng tốn dữ liệu, tiền và công bảo trì.
  • Nhớ nguyên tắc mấu chốt: fine-tune dạy "cách hành xử", RAG dạy "biết thông tin gì". Nhầm hai thứ này là nguyên nhân thất bại phổ biến nhất.
  • Ba điều kiện cần để fine-tune: few-shot đã chạm trần, có đủ dữ liệu sạch, và khối lượng/yêu cầu đủ lớn để đáng đầu tư. Thiếu một điều — hãy ở lại few-shot hoặc RAG.
  • Trong thực tế, hệ thống mạnh nhất thường kết hợp cả ba: fine-tune cho phong cách + RAG cho tri thức + một prompt gọn gàng.