Lựa chọn kỹ thuật theo độ phức tạp của tác vụ
Kỹ thuật (Technique) | Định nghĩa (What it is) | Khi nào nên áp dụng (When it fits) |
Zero-shot | Chỉ đưa ra chỉ dẫn (instruction), không kèm theo ví dụ. | Các tác vụ được đặc tả rõ ràng mà model đã có khả năng xử lý ổn định; là phương án mặc định nên thử đầu tiên. |
Few-shot | Đưa vào một vài ví dụ mẫu dạng input/output ngay trong prompt. | Các tác vụ mà định dạng mong muốn hoặc tiêu chuẩn đánh giá dễ truyền đạt bằng việc đưa ví dụ trực quan (show) hơn là mô tả bằng lời (describe). |
Chain-of-thought | Yêu cầu model tư duy và suy luận từng bước trước khi đưa ra câu trả lời. | Các bài toán suy luận nhiều bước, logic tính toán số học, hoặc các tác vụ mà lộ trình đi tới đáp án đóng vai trò then chốt đối với kết quả. |
Lộ trình nâng cấp cần có sự tính toán chủ đích: bắt đầu với Zero-shot, chỉ bổ sung ví dụ (Few-shot) nếu tác vụ thực sự cần, và chỉ yêu cầu suy luận tường minh (Chain-of-thought) nếu cấu trúc tác vụ bắt buộc. Mỗi bước nâng cấp đều làm tăng số lượng tokens và độ trễ (latency), vì vậy nguyên tắc là hãy chọn kỹ thuật nhẹ nhất có thể đáp ứng được yêu cầu.
Sự khác biệt về hành vi giữa các Model
Cùng một prompt sẽ không vận hành hoàn toàn giống nhau giữa các phân cấp model (model tiers) hay giữa các thế hệ model khác nhau:
Một model có năng lực cao hơn thường cần ít scaffolding hơn (cần ít ví dụ hơn, ít các chỉ dẫn từng bước chi li hơn) để đạt cùng một mức chất lượng.
Một model phân cấp thấp hơn lại đòi hỏi nhiều scaffolding và ràng buộc hơn.
Một prompt được tinh chỉnh tối ưu cho model này chỉ là điểm khởi đầu cho một model khác, chứ không phải là một sản phẩm hoàn thiện để áp dụng nguyên xi. Đây là lý do vì sao việc hoán đổi model (model swap) bắt buộc phải được đối xử như một đợt phát hành (release) và phải được kiểm soát qua một bài đánh giá (evaluation): chính sự kết hợp giữa prompt và model (prompt-model pairing) mới là thứ bạn thực sự bàn giao lên môi trường production.
Tránh đưa thiên kiến (Bias) vào quá trình xây dựng Prompt
Quá trình dựng prompt có thể vô tình đưa vào các thiên kiến mà bài toán không hề mong muốn:
Cách diễn đạt mang tính dẫn dắt / mớm cung (leading phrasing).
Các bộ ví dụ thiếu cân bằng (unbalanced examples — ví dụ: tập few-shot chỉ đưa ra toàn các trường hợp thuộc một nhóm duy nhất).
Các giả định ngầm được cài cắm sẵn vào câu lệnh.
Tất cả những yếu tố này đều có thể bẻ lái đầu ra của model theo những cách rất khó nhận ra. Kỷ luật ở đây là:
Diễn đạt một cách trung lập (neutral phrasing).
Cân bằng các ví dụ bao quát các trường hợp mà hệ thống sẽ thực sự đối mặt trên thực tế.
Kiểm tra xem liệu prompt có đang ngầm áp đặt trước câu trả lời cho điều mà lẽ ra nó phải khách quan trích xuất hay không.
Chi phí · Độ phức tạp · Rủi ro
Chi phí (Cost): Các kỹ thuật nặng hơn sẽ tiêu tốn token và độ trễ (latency) trên từng lượt gọi. Sử dụng Chain-of-thought cho một tác vụ không đòi hỏi suy luận phức tạp là một khoản chi phí phát sinh lặp đi lặp lại (recurring tax) mà không mang lại giá trị nào.
Độ phức tạp (Complexity): Các ví dụ Few-shot là phần nội dung cần phải duy trì và bảo trì: khi nghiệp vụ thay đổi, các ví dụ cũ lỗi thời sẽ âm thầm định hướng sai lệch hành vi của model.
Rủi ro (Risk): Thiên kiến đưa vào prompt không thể nhìn thấy qua một đầu ra đơn lẻ mà chỉ lộ diện khi nhìn trên dữ liệu tổng thể (in aggregate). Đó là lý do vì sao cách diễn đạt trung lập và việc cân bằng các ví dụ là một yêu cầu mang tính thiết kế kiến trúc, chứ không đơn thuần là một bước trau chuốt câu chữ.
Nội dung bài viết thuộc lộ trình chuẩn bị chứng chỉ Claude Certified Architect, được tổng hợp và biên dịch từ tài liệu đào tạo chính thức của Anthropic PBC. Bản quyền nội dung gốc thuộc về Anthropic PBC. Bản dịch tiếng Việt và chú giải thực hành bởi HungPH Blog.
Thành viên gia nhập từ 19/09/2026