Prompt Engineering
Kỹ năng viết chỉ dẫn cho mô hình sao cho ra đúng thứ mình cần: rõ vai trò, đủ ngữ cảnh, chốt định dạng đầu ra, nêu ràng buộc. Về bản chất giống hệt việc viết một yêu cầu không mơ hồ.
Định nghĩa
Nghe thì oách, làm thì quen: viết prompt tốt chính là viết một yêu cầu không mơ hồ. Vai trò rõ, ngữ cảnh đủ, đầu vào sạch, đầu ra chốt định dạng, ràng buộc nói thẳng. Ai từng bị dev hỏi lại ba lần vì một câu spec lấp lửng thì đã có sẵn kỹ năng này rồi.
Đây là kỹ năng đặc tả cũ, chỉ đổi người nhận từ dev sang mô hình. Ai viết spec rõ thì đã làm xong một nửa.
Cấu trúc một prompt dùng được
Sáu phần, không phải cái nào cũng cần nhưng thiếu phần bốn thì gần như chắc chắn phải làm lại:
- Vai trò — "Bạn đang đóng vai một BA làm hệ thống ngân hàng lõi."
- Nhiệm vụ — một câu, một động từ chính. Nhiều nhiệm vụ trong một prompt thì tách ra.
- Ngữ cảnh và dữ liệu — dán nguyên đoạn cần xử lý, phân tách rõ bằng dấu hiệu như ba dấu nháy ngược, để mô hình không lẫn dữ liệu với chỉ dẫn.
- Định dạng đầu ra — mô tả chính xác. Nếu cần máy đọc thì yêu cầu JSON kèm tên trường và kiểu dữ liệu.
- Ràng buộc — cái gì không được làm. "Nếu đoạn văn không có thông tin về hạn mức, để trường đó là null, không suy đoán."
- Ví dụ mẫu — hai tới năm cặp đầu vào/đầu ra. Đây là đòn bẩy mạnh nhất, mạnh hơn mọi câu chữ hoa mỹ trong phần một.
So sánh với Fine-tuning
| Prompt Engineering | Fine-tuning | |
|---|---|---|
| Chi phí bắt đầu | Gần bằng không | Chi phí huấn luyện, hạ tầng, người chuẩn bị dữ liệu |
| Cần dữ liệu | Vài ví dụ mẫu | Thường từ vài trăm tới vài nghìn cặp đã gán nhãn |
| Sửa đổi | Sửa chữ, chạy lại, xong trong vài phút | Chuẩn bị lại dataset và huấn luyện lại |
| Dạy được gì | Nhiệm vụ, định dạng, ràng buộc | Giọng văn, cấu trúc đặc thù, hành vi ổn định ở quy mô lớn |
| Chi phí lúc chạy | Prompt dài thì mỗi lượt tốn thêm token | Prompt ngắn hơn, mỗi lượt rẻ hơn |
| Ai làm được | BA tự làm | Cần team ML |
Thứ tự hợp lý: prompt trước, thấy chưa đủ thì thêm dữ liệu bằng RAG, vẫn chưa đủ mới tính tới fine-tuning. Nhảy thẳng tới bước ba thì tiền đi trước, câu trả lời đi sau. Mình gặp một team fine-tune ba tháng rồi phát hiện prompt bốn dòng giải quyết được tám phần mười bài toán.
Ví dụ thực tế
Đội vận hành một sàn ngành mẹ và bé đang chia nhau đọc tay 2.370 đánh giá sản phẩm mỗi tuần, gán vào 8 chủ đề: giao hàng, đóng gói, chất lượng, giá, chăm sóc khách hàng, hàng giả, đổi trả, khác. Người thứ ba trong nhóm đọc đó vừa xin nghỉ, và câu hỏi đặt lên bàn là có ném chỗ này cho mô hình được không.
Prompt bản một chỉ có một câu: "Phân loại đánh giá sau vào một trong 8 nhóm." Đội vận hành lấy ngẫu nhiên 100 đánh giá tự gán nhãn tay để đối chiếu, khớp được 68 cái. Chỗ sai chủ yếu là đánh giá nhắc hai chuyện cùng lúc — "hàng đẹp mà ship lâu quá" — và mô hình chọn bừa một cái.
Prompt bản hai thêm ba thứ: định nghĩa từng nhãn bằng một câu, cho phép trả về nhiều nhãn dưới dạng mảng, và kèm 5 ví dụ mẫu trong đó có hai ví dụ nhiều nhãn. Cũng 100 đánh giá đó, khớp 89 cái. Không đổi mô hình, không tốn thêm đồng nào ngoài nửa buổi ngồi viết lại prompt.
Chỗ này mới đáng ngồi lại: việc "định nghĩa từng nhãn bằng một câu" chính là việc BA phải làm dù có AI hay không. Trước giờ nó nằm trong đầu người vận hành và mỗi người hiểu một kiểu.
Mẹo khi đi làm
Lưu prompt như lưu code. Đặt trong repo hoặc một trang Confluence có phiên bản, ghi rõ ai sửa, sửa gì, ngày nào. Prompt là một phần của logic nghiệp vụ, đổi một chữ là hành vi sản phẩm đổi theo, mà nó lại không nằm trong pull request nào cả — chỗ này rất nhiều team bỏ quên.
Luôn có bộ 20–50 mẫu chuẩn để chạy lại sau mỗi lần sửa prompt. Không có nó thì bạn sửa được chỗ này, hỏng chỗ kia, mà không biết.
Và đừng viết prompt bằng lời hoa mỹ. "Hãy trả lời một cách chuyên nghiệp và đầy đủ" gần như không có tác dụng gì. "Trả lời tối đa 5 gạch đầu dòng, mỗi gạch dưới 20 từ, không dùng câu cảm thán" thì có.
