Mình đoán 90% sinh viên bây giờ đều đã mở ChatGPT hoặc Claude ít nhất một lần trong đời sinh viên của mình. Nhưng có một sự thật hơi phũ phàng: phần lớn mọi người đang dùng AI như kiểu gõ vào Google — quăng một câu ngắn cụt lủn rồi hy vọng máy đọc được ý mình. Kết quả là output ra cái gì đó chung chung, sai sai, hoặc “không phải cái em cần” rồi lại ngồi than “AI ngu thế”.
Sự thật là AI không ngu, chỉ là mình đang hỏi chưa đúng cách thôi. Prompt engineering nghe có vẻ to tát, nhưng bản chất nó giống như việc giao task cho một bạn thực tập sinh cực kỳ thông minh nhưng chưa từng làm ở công ty mình ngày nào — bạn ấy sẵn sàng làm bất cứ thứ gì, nhưng nếu mình chỉ nói “làm cái báo cáo đi” mà không nói rõ báo cáo gì, format sao, dùng dữ liệu nào, thì kết quả nhận về chắc chắn sẽ lệch pha.
Bài này mình sẽ đi qua 3 kỹ thuật prompt cốt lõi mà bất kỳ ai làm việc với AI cũng nên nắm: Zero-shot, Few-shot và Chain-of-thought (chuỗi tư duy). Để dễ hình dung, mình sẽ dùng chung một bài toán xuyên suốt cả bài — mỗi kỹ thuật mình sẽ áp dụng lại đúng bài toán đó để anh em thấy rõ sự khác biệt về output.
Bài toán xuyên suốt: Phân loại cảm xúc review sản phẩm
Giả sử mình đang làm một con bot nhỏ để tự động đọc review khách hàng để lại trên sàn thương mại điện tử, rồi phân loại xem review đó là Tích cực, Tiêu cực hay Trung lập. Đây là bài toán cực kỳ phổ biến trong thực tế — team marketing, team CSKH nào cũng cần cái này để lọc feedback nhanh mà không phải đọc tay từng dòng.
Mình sẽ dùng câu review này làm ví dụ chính:
“Giao hàng nhanh thật đấy, đúng 3 tiếng sau khi đặt là có hàng luôn. Tiếc là mở hộp ra thì sản phẩm bị móp một góc.”
Câu này hơi “khó nhằn” vì nó vừa khen (giao hàng nhanh) vừa chê (sản phẩm móp) — một tình huống rất thật trong review đời thường, không đơn giản kiểu “sản phẩm tệ quá” hay “tuyệt vời 5 sao”. Mình chọn ví dụ này có chủ đích, vì nó sẽ giúp anh em thấy rõ tại sao có những kỹ thuật prompt “cơ bản” là chưa đủ.
1. Zero-shot prompting — hỏi thẳng, không ví dụ
Zero-shot là kiểu prompt đơn giản nhất: mình chỉ mô tả yêu cầu, không đưa bất kỳ ví dụ mẫu nào, rồi để model tự hiểu và tự làm. Gọi là “zero-shot” vì model nhận “zero” (không) ví dụ nào để tham khảo — nó phải dựa hoàn toàn vào kiến thức đã học sẵn để suy ra việc cần làm.
Đây là cách đa số sinh viên đang prompt hàng ngày mà không biết nó có tên gọi. Áp dụng vào bài toán của mình, một prompt zero-shot sẽ trông như thế này:
Phân loại cảm xúc của review sau đây thành một trong ba nhãn:
Tích cực, Tiêu cực, hoặc Trung lập.
Review: "Giao hàng nhanh thật đấy, đúng 3 tiếng sau khi đặt là có hàng luôn.
Tiếc là mở hộp ra thì sản phẩm bị móp một góc."Với một model đủ mạnh như Claude hay GPT-4, prompt kiểu này thường vẫn ra kết quả khá ổn cho các case đơn giản. Nhưng vấn đề của zero-shot là mình không kiểm soát được format output và tiêu chí phân loại — model có thể trả lời dài dòng, giải thích lan man, hoặc tự đặt ra một nhãn thứ 4 kiểu “Hỗn hợp” mà mình không hề yêu cầu. Với câu review vừa khen vừa chê ở trên, có khi model này trả “Trung lập”, model khác trả “Tích cực”, không nhất quán — vì mình chưa cho nó biết mình định nghĩa “Trung lập” là gì.
Khi nào nên dùng zero-shot: task đơn giản, phổ biến, không cần format đầu ra quá chặt chẽ — như dịch một câu, tóm tắt một đoạn văn, hỏi kiến thức chung.
2. Few-shot prompting — cho model “học” từ ví dụ mẫu
Few-shot là khi mình đưa thêm vài ví dụ mẫu (thường 2-5 ví dụ) ngay trong prompt, để model nhìn vào đó mà “bắt chước” đúng pattern mình muốn — cả về logic phân loại lẫn format trả lời. Đây giống hệt việc mình đưa cho bạn thực tập sinh 3 case đã làm mẫu trước khi giao việc mới, thay vì chỉ nói miệng yêu cầu.
Áp dụng vào bài toán phân loại review, prompt few-shot sẽ như sau:
Phân loại cảm xúc review theo 3 nhãn: Tích cực, Tiêu cực, Trung lập.
Chỉ trả lời đúng 1 nhãn, không giải thích thêm.
Review: "Sản phẩm dùng rất tốt, đúng như mô tả, sẽ ủng hộ shop tiếp."
Nhãn: Tích cực
Review: "Hàng giao trễ 5 ngày, chất lượng cũng không như hình."
Nhãn: Tiêu cực
Review: "Sản phẩm bình thường, không có gì đặc biệt để nói."
Nhãn: Trung lập
Review: "Giao hàng nhanh thật đấy, đúng 3 tiếng sau khi đặt là có hàng luôn.
Tiếc là mở hộp ra thì sản phẩm bị móp một góc."
Nhãn:Với prompt này, model không chỉ hiểu đúng format cần trả lời (một từ duy nhất, không giải thích dài dòng), mà quan trọng hơn là mình đã “ngầm định nghĩa” luôn ranh giới giữa các nhãn thông qua ví dụ. Model sẽ có xu hướng nhìn vào ví dụ số 2 (vừa có điểm tốt lẫn điểm chưa tốt nhưng vẫn thiên về khen) để suy luận ra câu review móp hàng của mình nên rơi vào nhãn nào một cách nhất quán hơn.
Khi nào nên dùng few-shot: khi task có format đầu ra cụ thể, hoặc khi định nghĩa “đúng/sai” hơi mơ hồ và khó diễn đạt hết bằng lời — ví dụ phân loại, gắn nhãn dữ liệu, viết theo văn phong riêng của một brand.
3. Chain-of-thought (chuỗi tư duy) — bắt model “suy nghĩ thành tiếng”
Đây là kỹ thuật mình thấy nhiều bạn sinh viên biết tên nhưng chưa hiểu bản chất. Chain-of-thought (CoT) là kỹ thuật yêu cầu model trình bày từng bước suy luận trước khi đưa ra kết luận cuối cùng, thay vì nhảy thẳng tới đáp án. Về bản chất, nó giống việc thầy cô bắt mình “trình bày lời giải” thay vì chỉ ghi đáp số — không phải vì đáp số không quan trọng, mà vì việc viết ra từng bước sẽ giúp giảm khả năng nhảy cóc và sai logic giữa chừng.
Với câu review vừa khen vừa chê của mình, đây chính là chỗ CoT phát huy tác dụng rõ nhất, vì nó là một case “khó” cần suy luận thay vì chỉ pattern-matching đơn thuần:
Phân loại cảm xúc của review sau. Trước khi kết luận, hãy suy luận
từng bước: liệt kê các ý khen, các ý chê, đánh giá ý nào là trọng tâm
mối quan tâm của khách hàng, rồi mới đưa ra nhãn cuối cùng.
Review: "Giao hàng nhanh thật đấy, đúng 3 tiếng sau khi đặt là có hàng luôn.
Tiếc là mở hộp ra thì sản phẩm bị móp một góc."
Suy luận:
1. Ý khen: ...
2. Ý chê: ...
3. Trọng tâm khách hàng quan tâm: ...
Kết luận (nhãn):Khi được yêu cầu suy luận từng bước, model thường sẽ nhận ra: tốc độ giao hàng là yếu tố phụ, còn chất lượng sản phẩm nguyên vẹn mới là thứ khách hàng thực sự quan tâm khi mua online — và một sản phẩm bị móp là vấn đề đáng kể hơn nhiều so với việc giao nhanh hay chậm vài tiếng. Vì vậy CoT thường sẽ dẫn model tới kết luận “Tiêu cực” hoặc ít nhất là “Trung lập nghiêng về tiêu cực” một cách có căn cứ, thay vì đoán mò theo cảm tính bề mặt như câu chữ “nhanh thật đấy” nghe có vẻ tích cực ở đầu câu.
Khi nào nên dùng CoT: các bài toán cần suy luận nhiều bước — toán, logic, phân tích tình huống có nhiều yếu tố trái chiều, debug code, ra quyết định dựa trên nhiều điều kiện. Đừng dùng CoT cho câu hỏi cực kỳ đơn giản, vì nó sẽ làm output dài dòng không cần thiết và tốn token vô ích.
Kết hợp cả hai: Few-shot + Chain-of-thought
Trong thực tế, kỹ thuật mạnh nhất thường là kết hợp cả hai: đưa ví dụ mẫu kèm theo cả phần suy luận, để model vừa học được format, vừa học được “cách nghĩ” đúng đắn. Ví dụ:
Review: "Đóng gói cẩn thận, nhưng màu sắc thực tế nhạt hơn hình khá nhiều."
Suy luận: Đóng gói tốt là điểm cộng nhỏ, nhưng sai lệch màu sắc so với
mô tả ảnh hưởng trực tiếp đến quyết định mua hàng của khách - đây là
vấn đề cốt lõi.
Nhãn: Tiêu cực
Review: [câu review cần phân loại]
Suy luận:Cách làm này gọi nôm na là “few-shot CoT”, và trong nhiều benchmark thực tế nó cho kết quả ổn định hơn hẳn so với chỉ dùng một trong hai. Đánh đổi là prompt sẽ dài hơn, tốn token hơn — nên anh em cân nhắc dùng khi task thực sự cần độ chính xác cao, không phải lúc nào cũng cần “full combo” này.
Bảng so sánh nhanh
| Kỹ thuật | Đặc điểm | Dùng khi nào |
|---|---|---|
| Zero-shot | Không ví dụ, dựa vào kiến thức có sẵn của model | Task đơn giản, phổ biến, không cần format chặt |
| Few-shot | Có 2-5 ví dụ mẫu để định hình pattern | Cần format cố định, ranh giới phân loại mơ hồ |
| Chain-of-thought | Yêu cầu suy luận từng bước trước khi kết luận | Task nhiều bước, nhiều yếu tố trái chiều, cần độ chính xác cao |
Tóm lại những gì cần nhớ
- Zero-shot: hỏi thẳng, không ví dụ — nhanh gọn nhưng khó kiểm soát output.
- Few-shot: đưa ví dụ mẫu để model bắt chước đúng format và logic mình muốn.
- Chain-of-thought: bắt model trình bày suy luận từng bước trước khi kết luận, cực kỳ hữu ích cho các bài toán phức tạp hoặc có yếu tố trái chiều.
- Có thể kết hợp few-shot + CoT để có kết quả ổn định và chính xác nhất, đánh đổi là prompt dài hơn.
- Nguyên tắc chung: task càng đơn giản thì càng nên prompt đơn giản, đừng “over-engineer” một câu hỏi cơ bản bằng CoT dài dòng làm gì.
Chúc anh em code vui! 🚀
Sự thật là AI không ngu, chỉ là mình đang hỏi chưa đúng cách thôi. Prompt engineering nghe có vẻ to tát, nhưng bản chất nó giống như việc giao task cho một bạn thực tập sinh cực kỳ thông minh nhưng chưa từng làm ở công ty mình ngày nào — bạn ấy sẵn sàng làm bất cứ thứ gì, nhưng nếu mình chỉ nói “làm cái báo cáo đi” mà không nói rõ báo cáo gì, format sao, dùng dữ liệu nào, thì kết quả nhận về chắc chắn sẽ lệch pha.