[C1.S13.Ep08] Zero-shot, Few-shot, Chain-of-Thought: Khi nào dùng gì trong Vibe Coding?

Công Nghệ 03-03-2026

Mục lục

1. Từ Prompt Engineering cơ bản đến kỹ thuật kích hoạt suy luận
2. Zero-shot Prompting: Tin vào tri thức nền của mô hình
3. Few-shot Prompting: Thu hẹp phân bố xác suất bằng ví dụ
4. Chain-of-Thought: Kích hoạt suy luận nhiều bước
5. So sánh tổng thể ba kỹ thuật
- 5.1. So sánh theo độ kiểm soát và độ tin cậy
- 5.2. So sánh theo latency và chi phí vận hành
6. Thiết kế chiến lược prompting trong AI architecture
7. Kết luận
8. Danh mục bài viết cùng chuyên đề

Từ Prompt Engineering cơ bản đến kỹ thuật kích hoạt suy luận

*Zero-shot, Few-shot, Chain-of-Thought: Khi nào dùng gì trong Vibe Coding?*

Trong các bài trước, chúng ta đã phân tích rằng Large Language Model không hiểu theo nghĩa nhận thức. Nó vận hành dựa trên next-token prediction trong kiến trúc Transformer, sử dụng Attention Mechanism để phân bổ trọng số ngữ cảnh. Điều này có một hệ quả quan trọng: cách chúng ta đặt prompt không chỉ thay đổi nội dung đầu ra, mà thay đổi cả quá trình suy luận nội bộ.

Zero-shot, few-shot và chain-of-thought không phải là “mẹo viết câu lệnh”. Chúng là ba cách khác nhau để kích hoạt hành vi xác suất của mô hình.

Khi triển khai Vibe Coding trong AI for software engineering, việc lựa chọn kỹ thuật prompting phù hợp có thể ảnh hưởng trực tiếp đến:

AI reliability
Chi phí token
Độ trễ hệ thống
Khả năng xử lý logic phức tạp

Đây không phải lựa chọn thẩm mỹ. Đây là lựa chọn kiến trúc.

Zero-shot Prompting: Tin vào tri thức nền của mô hình

Zero-shot là gì về mặt kỹ thuật?

Zero-shot prompting là hình thức tương tác cơ bản nhất với Large Language Model: đưa ra yêu cầu trực tiếp mà không cung cấp ví dụ minh họa hay mẫu cấu trúc trước đó. Ở mức kỹ thuật, điều này có nghĩa là mô hình phải dựa hoàn toàn vào tri thức đã học trong quá trình huấn luyện để thực hiện next-token prediction.

Khi một prompt được đưa vào, văn bản sẽ được token hóa, chuyển thành embedding vector và đi qua các lớp Transformer. Attention Mechanism phân bổ trọng số giữa các token trong cửa sổ ngữ cảnh, sau đó mô hình sinh ra token tiếp theo dựa trên phân phối xác suất cao nhất. Trong zero-shot, không có “điểm neo” bổ sung từ ví dụ mẫu để điều chỉnh phân bố này. Toàn bộ quá trình dựa trên những gì mô hình đã ghi nhớ trong tham số.

Ví dụ như yêu cầu: “Viết hàm Python tính lãi kép.” Đây là một nhiệm vụ phổ biến, có cấu trúc rõ ràng trong dữ liệu huấn luyện. Vì vậy, mô hình có thể dễ dàng sinh ra một lời giải chuẩn mà không cần thêm hướng dẫn. Trong trường hợp này, zero-shot hoạt động hiệu quả vì bài toán nằm trong phân bố phổ biến của dữ liệu.

Về bản chất xác suất, zero-shot đặt mô hình vào không gian tổng quát nhất. Không có ví dụ để thu hẹp phạm vi, không có cấu trúc mẫu để định hình format. Điều này khiến hành vi của mô hình phụ thuộc trực tiếp vào chất lượng clarity và context trong prompt.

Khi nào zero-shot đủ dùng?

Zero-shot phù hợp trong những tình huống mà tri thức nền của Large Language Model đã đủ mạnh để xử lý yêu cầu. Đây thường là các tác vụ có cấu trúc quen thuộc, không đòi hỏi suy luận nhiều bước hoặc kiểm soát chặt chẽ về format.

Các đặc điểm điển hình của tác vụ phù hợp zero-shot bao gồm:

Tác vụ đơn giản, có mẫu giải phổ biến
Cấu trúc đầu ra dễ dự đoán
Không yêu cầu reasoning nhiều bước
Sai số ở mức chấp nhận được

Trong Vibe Coding và AI for software engineering, zero-shot đặc biệt hiệu quả cho các nhiệm vụ như sinh boilerplate code, viết docstring, chuyển đổi định dạng dữ liệu hoặc tóm tắt tài liệu. Những nhiệm vụ này thường không yêu cầu logic phức tạp hay xử lý nhiều corner case. Tri thức nền của mô hình đủ để tạo ra output có chất lượng tương đối cao.

Ưu điểm lớn nhất của zero-shot là tốc độ và chi phí. Do không cần thêm ví dụ hay reasoning trung gian, số lượng token đầu vào và đầu ra thường thấp hơn so với few-shot hoặc chain-of-thought. Điều này giúp giảm latency và tối ưu chi phí trong production-grade AI workflow.

Trong hệ thống AI architecture quy mô lớn, zero-shot thường được sử dụng như tầng mặc định cho các tác vụ thường xuyên và ít rủi ro.

Hạn chế của zero-shot và rủi ro về độ tin cậy

Tuy nhiên, sức mạnh của zero-shot cũng chính là điểm yếu của nó. Khi không có ví dụ hay cấu trúc hướng dẫn, mô hình phải suy đoán hoàn toàn dựa trên phân bố phổ biến nhất trong dữ liệu huấn luyện. Điều này có thể dẫn đến ba vấn đề chính: suy đoán sai mục tiêu, bỏ qua corner case và tạo hallucination.

Khi yêu cầu mơ hồ, Large Language Model sẽ chọn phương án có xác suất cao nhất, không phải phương án phù hợp nhất với bối cảnh cụ thể của tổ chức. Ví dụ, nếu không chỉ định tiêu chuẩn bảo mật hoặc chuẩn coding nội bộ, mô hình có thể sinh ra lời giải hợp lý về mặt cú pháp nhưng không đáp ứng yêu cầu hệ thống.

Zero-shot vì vậy mở rộng không gian xác suất nhiều nhất trong ba kỹ thuật prompting. Attention Mechanism không có “điểm neo” để tập trung vào cấu trúc mong muốn, nên phân bố trọng số có thể lệch khỏi kỳ vọng. AI reliability trong trường hợp này phụ thuộc rất mạnh vào mức độ clarity và chất lượng context của prompt.

Trong môi trường doanh nghiệp, việc lạm dụng zero-shot cho các tác vụ phức tạp có thể làm gia tăng technical debt. Output có thể trông đúng trong giai đoạn demo nhưng thiếu tính nhất quán khi triển khai thực tế. Do đó, zero-shot nên được xem như công cụ tối ưu cho nhiệm vụ đơn giản, thay vì giải pháp mặc định cho mọi tình huống.

Hiểu rõ giới hạn của zero-shot giúp tổ chức thiết kế chiến lược prompting hợp lý hơn. Khi nhiệm vụ vượt ra khỏi phạm vi phổ biến hoặc yêu cầu reasoning nhiều bước, cần cân nhắc chuyển sang few-shot hoặc chain-of-thought để tăng mức độ kiểm soát và AI reliability.

Few-shot Prompting: Thu hẹp phân bố xác suất bằng ví dụ

Cơ chế hoạt động: Ví dụ như một “neo xác suất”

Few-shot prompting mở rộng từ zero-shot bằng cách bổ sung một số ví dụ minh họa trước khi đưa ra yêu cầu chính. Các ví dụ này không chỉ mang tính tham khảo; về mặt kỹ thuật, chúng đóng vai trò như các “neo xác suất” trong không gian embedding của mô hình.

Khi prompt chứa ví dụ, toàn bộ chuỗi – bao gồm cả ví dụ và yêu cầu – được token hóa và đưa vào Transformer. Attention Mechanism sẽ phân bổ trọng số giữa các token trong cửa sổ ngữ cảnh. Do các ví dụ xuất hiện ngay trước yêu cầu chính và có cấu trúc tương tự nhiệm vụ cần giải quyết, chúng thường nhận trọng số cao hơn trong quá trình tính toán Q, K, V.

Điều này có một hệ quả quan trọng: phân bố xác suất nội bộ của mô hình bị điều chỉnh. Thay vì dựa hoàn toàn vào mẫu hình phổ biến trong dữ liệu huấn luyện gốc, Large Language Model sử dụng các ví dụ trong prompt như tín hiệu mạnh để suy ra cách trả lời mong muốn. Nói cách khác, few-shot không thay đổi tham số mô hình, nhưng thay đổi bối cảnh xác suất mà mô hình đang vận hành.

Về mặt hành vi, few-shot khiến output có xu hướng tương đồng về cấu trúc, giọng điệu và định dạng với các ví dụ đã cho. Đây là cách Prompt Engineering can thiệp trực tiếp vào quá trình next-token prediction mà không cần fine-tuning.

Use case trong AI for software engineering

Trong AI for software engineering, few-shot đặc biệt hữu ích khi mục tiêu không chỉ là “giải bài toán”, mà là giải bài toán theo một chuẩn cụ thể. Điều này thường xảy ra trong môi trường doanh nghiệp, nơi có quy định về coding convention, logging, naming convention hoặc format tài liệu.

Few-shot phù hợp khi tổ chức muốn:

Chuẩn hóa format output giữa các lần gọi mô hình
Đảm bảo tuân thủ chuẩn coding nội bộ
Duy trì cấu trúc phản hồi nhất quán giữa nhiều thành viên

Ví dụ, nếu tổ chức yêu cầu mọi API phải có cấu trúc log chuẩn với trường timestamp, user_id và trace_id, việc đưa 2–3 ví dụ mẫu trong prompt sẽ giúp mô hình tái tạo đúng cấu trúc đó. Attention Mechanism sẽ coi các ví dụ này là “mẫu chuẩn”, và output có xu hướng bắt chước.

Khác với zero-shot, few-shot giảm đáng kể nguy cơ sai lệch format hoặc thiếu trường bắt buộc. Điều này trực tiếp cải thiện AI reliability và giảm technical debt do inconsistency. Khi mọi thành viên trong nhóm sử dụng cùng bộ ví dụ chuẩn, output của Vibe Coding trở nên đồng nhất hơn.

Few-shot vì vậy không chỉ là kỹ thuật tăng chất lượng câu trả lời, mà là công cụ chuẩn hóa hành vi mô hình trong một AI architecture có kiểm soát.

Chi phí, giới hạn và thiết kế tối ưu

Tuy nhiên, few-shot không miễn phí. Mỗi ví dụ bổ sung làm tăng số lượng token đầu vào. Điều này dẫn đến ba trade-off chính: tăng chi phí token, giảm phần context window còn lại cho nhiệm vụ chính và tăng latency.

Trong production-grade AI workflow, khi một hệ thống xử lý hàng nghìn yêu cầu mỗi ngày, việc lặp lại nhiều ví dụ trong mọi prompt có thể làm tăng chi phí đáng kể. Ngoài ra, nếu cửa sổ ngữ cảnh bị chiếm dụng bởi ví dụ quá dài, phần còn lại cho yêu cầu thực tế sẽ bị thu hẹp, làm giảm hiệu quả của Attention.

Một vấn đề khác là nguy cơ “overfitting theo prompt”. Nếu ví dụ quá cụ thể, mô hình có thể tái tạo cấu trúc một cách máy móc mà không linh hoạt điều chỉnh theo ngữ cảnh mới. Điều này làm giảm tính tổng quát và có thể gây lỗi trong tình huống khác biệt.

Do đó, few-shot cần được thiết kế và chuẩn hóa thay vì chèn ví dụ tùy tiện. Trong AI architecture doanh nghiệp, có thể xây dựng bộ ví dụ chuẩn cho từng loại tác vụ và tái sử dụng có kiểm soát. Điều này giúp cân bằng giữa AI productivity và chi phí vận hành.

Few-shot là bước trung gian giữa zero-shot và chain-of-thought: kiểm soát tốt hơn zero-shot, nhưng vẫn tiết kiệm hơn reasoning nhiều bước. Khi được sử dụng đúng chỗ, nó trở thành công cụ mạnh để thu hẹp phân bố xác suất mà không làm tăng độ trễ quá mức.

Chain-of-Thought: Kích hoạt suy luận nhiều bước

Bản chất của Chain-of-Thought trong cơ chế dự đoán token

Chain-of-Thought (CoT) prompting là kỹ thuật yêu cầu mô hình “nghĩ từng bước” thay vì nhảy thẳng đến đáp án. Ở cấp độ bề mặt, CoT có thể trông giống một yêu cầu trình bày chi tiết. Nhưng ở cấp độ hệ thống, nó là một cách can thiệp vào quá trình next-token prediction.

Thông thường, nếu prompt chỉ hỏi “kết quả là gì”, mô hình có xu hướng chọn một chuỗi token ngắn dẫn thẳng đến đáp án có xác suất cao. Với bài toán nhiều bước, đường đi ngắn này dễ sai vì mô hình phải “nhảy cóc” qua các ràng buộc trung gian. CoT buộc mô hình tạo ra các bước reasoning trước, khiến Attention Mechanism phải phân bổ trọng số và duy trì mạch logic theo trình tự.

Điều quan trọng là CoT không làm mô hình thông minh hơn theo nghĩa tăng tham số hay bổ sung tri thức. Nó chỉ thay đổi hành vi sinh token: ưu tiên chuỗi suy luận tuần tự thay vì đáp án tức thì. Khi chuỗi reasoning xuất hiện, mô hình có nhiều cơ hội tự điều chỉnh trong từng bước nhỏ, từ đó giảm sai lệch tổng thể ở các bài toán phức tạp.

Vì sao CoT cải thiện độ chính xác ở bài toán nhiều bước

Trong Transformer, mỗi token mới được sinh ra dựa trên ngữ cảnh trước đó. Khi CoT yêu cầu mô hình trình bày từng bước, chính các bước đó trở thành ngữ cảnh mới. Nói cách khác, mô hình “tự cung cấp” context cho chính mình qua từng bước reasoning.

Cơ chế này đặc biệt hữu ích khi bài toán có nhiều ràng buộc hoặc điều kiện lồng nhau. Thay vì phải giữ toàn bộ logic trong một lần dự đoán, mô hình có thể “neo” từng ràng buộc vào các câu trung gian. Điều này làm giảm nguy cơ bỏ sót điều kiện hoặc nhầm quan hệ nhân – quả.

Trong AI for software engineering, điều này thể hiện rõ khi mô hình cần phân tích luồng điều kiện, xử lý ngoại lệ hoặc tương tác giữa nhiều module. CoT giúp mô hình triển khai logic theo trình tự, giảm tình trạng code “trông đúng” nhưng sai ở corner case.

Tuy nhiên, CoT không loại bỏ hoàn toàn AI hallucination. Nó chỉ giảm xác suất sai ở những bài toán cần suy luận chuỗi dài, nơi việc bỏ qua bước trung gian là nguồn sai lệch lớn nhất.

Khi nào cần Chain-of-Thought trong thực tế

CoT phù hợp khi nhiệm vụ đòi hỏi reasoning nhiều bước, nghĩa là đáp án không thể được suy ra an toàn chỉ bằng mẫu hình phổ biến. Các tình huống tiêu biểu gồm giải toán nhiều bước, phân tích thuật toán phức tạp, debug hệ thống nhiều lớp hoặc lập kế hoạch triển khai theo chuỗi hành động.

Trong Vibe Coding, CoT có giá trị đặc biệt ở các nhiệm vụ như thiết kế logic xử lý nghiệp vụ nhiều điều kiện, phân tích nguyên nhân lỗi dựa trên log và stack trace, hoặc đề xuất cách refactor hệ thống có phụ thuộc chéo. Ở những trường hợp này, nếu dùng zero-shot, mô hình có thể đưa ra đáp án nhanh nhưng thiếu tính kiểm chứng. Nếu dùng few-shot, mô hình có thể tuân theo format nhưng vẫn sai logic nếu bài toán vượt khỏi ví dụ.

CoT là lựa chọn khi ưu tiên AI reliability hơn tốc độ. Nó phù hợp với các tác vụ “đắt” về rủi ro, nơi một lỗi logic nhỏ có thể gây hậu quả lớn khi triển khai production.

Trade-off latency, chi phí và cách dùng có kiểm soát

CoT có trade-off rõ ràng nhất trong ba kỹ thuật prompting. Vì mô hình phải sinh ra reasoning trung gian, số token đầu ra tăng mạnh. Khi token tăng, chi phí tăng và độ trễ (latency) tăng theo. Trong production-grade AI workflow, điều này có thể gây tắc nghẽn nếu CoT được bật cho mọi yêu cầu.

Ngoài ra, CoT có thể tạo ra lượng reasoning không cần thiết, đặc biệt khi tác vụ đơn giản. Điều này làm lãng phí token và tăng thời gian phản hồi mà không cải thiện chất lượng. Một rủi ro khác là reasoning trung gian đôi khi chứa thông tin nội bộ hoặc giả định sai, làm người dùng tin vào lập luận “nghe có vẻ hợp lý” dù kết quả cuối cùng vẫn sai.

Vì vậy, CoT nên được kích hoạt có điều kiện. Trong AI architecture doanh nghiệp, cách tối ưu thường là phân loại tác vụ: dùng zero-shot cho việc đơn giản, few-shot cho chuẩn hóa format, và chỉ dùng CoT cho nhiệm vụ cần suy luận nhiều bước hoặc có rủi ro cao. Khi được sử dụng đúng chỗ, CoT trở thành công cụ tăng AI reliability đáng kể mà không làm chi phí và latency vượt khỏi tầm kiểm soát.

So sánh tổng thể ba kỹ thuật

So sánh theo độ kiểm soát và độ tin cậy

Zero-shot, few-shot và Chain-of-Thought không phải ba mức “nâng cấp tuyến tính”, mà là ba cách điều chỉnh hành vi xác suất của Large Language Model trong kiến trúc Transformer. Sự khác biệt cốt lõi nằm ở mức độ kiểm soát mà Prompt Engineering áp đặt lên quá trình next-token prediction.

Nếu nhìn từ góc độ kiểm soát hành vi mô hình:

Zero-shot: Dựa hoàn toàn vào tri thức nền đã học; mức độ kiểm soát thấp nhất.
Few-shot: Thu hẹp phân bố xác suất bằng ví dụ; tăng tính nhất quán về format và cấu trúc.
Chain-of-Thought: Buộc mô hình sinh reasoning trung gian; kiểm soát tốt nhất trong bài toán nhiều bước.

Về AI reliability trong tác vụ logic phức tạp, thứ tự thường là:
Zero-shot < Few-shot < Chain-of-Thought.

Tuy nhiên, điều này không có nghĩa CoT luôn “tốt nhất”. Trong các tác vụ đơn giản, việc dùng CoT có thể không cải thiện chất lượng đáng kể mà chỉ làm tăng chi phí. Few-shot thường là điểm cân bằng hợp lý khi cần chuẩn hóa hành vi mô hình mà không kích hoạt suy luận quá sâu.

Điểm quan trọng là: độ tin cậy không chỉ phụ thuộc vào kỹ thuật prompting, mà còn phụ thuộc vào clarity, context và AI governance xung quanh hệ thống.

So sánh theo latency và chi phí vận hành

Từ góc độ AI architecture và production-grade AI workflow, trade-off về chi phí và độ trễ là yếu tố quyết định. Mỗi kỹ thuật có cấu trúc tiêu thụ token khác nhau:

Zero-shot: Ít token đầu vào và đầu ra; latency thấp nhất; chi phí thấp nhất.
Few-shot: Tăng token đầu vào do ví dụ; latency trung bình; chi phí tăng theo số lượng ví dụ.
Chain-of-Thought: Tăng mạnh token đầu ra do reasoning; latency cao nhất; chi phí cao nhất.

Thứ tự về latency và chi phí thường là:
Chain-of-Thought > Few-shot > Zero-shot.

Trong môi trường doanh nghiệp, việc kích hoạt CoT cho mọi tác vụ là không thực tế vì có thể làm hệ thống chậm và tăng chi phí vận hành. Ngược lại, chỉ dùng zero-shot cho mọi bài toán phức tạp có thể làm giảm AI reliability và tăng số vòng refinement.

Do đó, lựa chọn kỹ thuật không nên dựa trên sở thích cá nhân hay cảm giác “càng mạnh càng tốt”, mà phải dựa trên bản chất bài toán, mức độ rủi ro chấp nhận được và yêu cầu cân bằng giữa AI productivity và chi phí. Chiến lược prompting hiệu quả là chiến lược phân tầng có kiểm soát, không phải chiến lược cực đoan.

Thiết kế chiến lược prompting trong AI architecture

Trong môi trường doanh nghiệp, tối ưu không nằm ở việc chọn một kỹ thuật prompting duy nhất, mà ở việc thiết kế chiến lược phân tầng trong AI architecture:

Tầng 1: Zero-shot cho tác vụ đơn giản
Tầng 2: Few-shot cho chuẩn hóa format
Tầng 3: Chain-of-Thought cho reasoning phức tạp

Cách phân tầng này giúp cân bằng giữa hiệu suất, chi phí và kiểm soát rủi ro.

Kết luận

Zero-shot, few-shot và Chain-of-Thought không phải kỹ thuật thay thế lẫn nhau, mà là ba mức độ kiểm soát hành vi xác suất của Large Language Model. Mỗi kỹ thuật phù hợp với một loại bài toán khác nhau, tùy vào độ phức tạp và yêu cầu về AI reliability.

Trong Vibe Coding, việc lựa chọn đúng kỹ thuật giúp cân bằng giữa chi phí, latency và chất lượng đầu ra. Prompt Engineering ở cấp độ này không còn là viết câu lệnh tốt hơn, mà là thiết kế cách kích hoạt Transformer một cách có chiến lược và kiểm soát.